De documentatie van dit product is waar mogelijk geschreven met inclusief taalgebruik. Inclusief taalgebruik wordt in deze documentatie gedefinieerd als taal die geen discriminatie op basis van leeftijd, handicap, gender, etniciteit, seksuele oriëntatie, sociaaleconomische status of combinaties hiervan weerspiegelt. In deze documentatie kunnen uitzonderingen voorkomen vanwege bewoordingen die in de gebruikersinterfaces van de productsoftware zijn gecodeerd, die op het taalgebruik in de RFP-documentatie zijn gebaseerd of die worden gebruikt in een product van een externe partij waarnaar wordt verwezen. Lees meer over hoe Cisco gebruikmaakt van inclusief taalgebruik.
Cisco heeft dit document vertaald via een combinatie van machine- en menselijke technologie om onze gebruikers wereldwijd ondersteuningscontent te bieden in hun eigen taal. Houd er rekening mee dat zelfs de beste machinevertaling niet net zo nauwkeurig is als die van een professionele vertaler. Cisco Systems, Inc. is niet aansprakelijk voor de nauwkeurigheid van deze vertalingen en raadt aan altijd het oorspronkelijke Engelstalige document (link) te raadplegen.
Dit document beschrijft het proces om DTMF-relay (Dual Tone Multi-Frequency) te configureren voor Cisco Unified Border Element (CUBE) Enterprise.
Cisco raadt kennis van de volgende onderwerpen aan.
De informatie in dit document is gebaseerd op de volgende software- en hardware-versies.
De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u zorgen dat u de potentiële impact van elke opdracht begrijpt.
Raadpleeg de Cisco Technical Tips Conventions voor informatie over documentconventies.
Dit document bevat ook informatie en opdrachten over de configuratie, verificatie en probleemoplossing van DTMF-relay voor de verschillende VoIP-gatewayprotocollen die door CUBE worden ondersteund.
CUBE ondersteunt een grote verscheidenheid aan DTMF-relay-methoden voor zowel in-band als out-of-band (OOB) voor de H.323 en Session Initiation Protocol (SIP) signaleringsprotocollen.
Voice In-band audio of G711 DTMF verwijst naar het transport van hoorbare tonen via de spraak audio stream, zonder enige verdere betrokkenheid van het signaleringsprotocol of de DSP voor hun transmissie anders dan het normaal instellen van de oproep en het doorvoeren van het audio-einde om te beëindigen en gebruik de G711Ulaw/Alaw codec. Dit betekent dat de CUBE/Cisco IOS alleen de audio van de tonen doorgeeft die van het ene naar het andere uiteinde komen, alsof het normale spraak-audio is. De belangrijke maatregel die voor deze methode moet worden genomen is ervoor te zorgen dat de oproepen worden gevestigd en de codec G711Ulaw/Alaw gebruiken specifiek omdat om een codec te gebruiken die de audio (een andere codec dan G711) zou samenpersen de tonen DTMF vertekent en waarschijnlijk hen aan het ontvangende eind onherkenbaar maakt. Dit komt doordat het compressie algoritme gebruikt door hoge compressie codecs is ontworpen om menselijke stem te herkennen en te voorspellen en niet DTMF tonen.
In-band audio/G711 DTMF wordt ondersteund met elk VoIP-signaleringsprotocol en vereist alleen dat de G711-codec wordt afgedwongen voor de gesprekken van end-to-end. Men moet ook in gedachten houden dat de enige transcodering behandeling van een low-bit-rate (LBR) codec naar G711 waarschijnlijk ook de tonen vervormt.
Opmerking: Het is gebruikelijk dat er enige verwarring ontstaat wanneer u deze DTMF relay methode bespreekt, omdat de term In-band wordt gebruikt om te verwijzen naar het transport van DTMF binnen de RTP-stroom die wordt aangeduid als Named Telephony Event (NTE/RFC2833) en wanneer het in-band audiotonen is. Het is altijd belangrijk om de daadwerkelijke methode te verduidelijken die wordt/wordt gesteund om de juiste configuratie toe te passen en de juiste benadering te gebruiken om problemen op te lossen.
DTMF-cijfers worden gescheiden van de spraakstroom en verzonden via het H.245 signaleringskanaal OOB in plaats van verzonden via het RTP-kanaal. De tonen worden getransporteerd in H.245 User Input Indication-berichten. Het H.245 signaleringskanaal is een betrouwbaar kanaal en de pakketten die de DTMF tonen vervoeren worden gegarandeerd geleverd. Alle systemen die H.323, versie 2-compatibel zijn, zijn vereist om de dtmf-relay h245-alfanumerieke opdracht te ondersteunen. Ondersteuning van de opdracht h245-signaal voor dtmf-relay is echter optioneel.
OOB-methode die vergelijkbaar is met H.245 alfanumeriek, maakt het mogelijk om de informatie over de duur van de toon te laten passeren, waardoor het een mogelijk probleem met de alfanumerieke methode aanpakt bij de interactie met systemen van andere leveranciers.
Deze methode transporteert DTMF-tonen in afzonderlijke RTP-pakketten volgens sectie 3 van RFC 2833. RFC 2833 definieert indelingen van NTE RTP-pakketten die worden gebruikt om DTMF-cijfers, haaksflitser en andere telefoniegebeurtenissen tussen twee peer-endpoints te transporteren. Met de NTE methode, voeren de eindpunten per-vraag onderhandeling van de DTMF relay parameters uit om de payload type waarde voor de NTE RTP pakketten en de ondersteunde NTE cijfergebeurtenissen te bepalen. Dientengevolge, worden de tonen DTMF via RTP pakketten met een payload type waarde meegedeeld verschillend van de waarden die voor andere media pakketten worden besproken; die een betrouwbare methode verstrekt om de cijfers te vervoeren en te vermijden die niet worden herkend wanneer zij worden gecomprimeerd via codec worden gebruikt om de stem, video of faxverkeer te coderen.
RFC2833/NTE DTMF-relay wordt beschouwd als een in-band methode omdat de cijfers binnen het RTP-audioverkeer zelf worden getransporteerd zonder enige betrokkenheid van het GW-signaleringsprotocol.
Het is belangrijk om erop te wijzen dat de methode RFC2833/NTE niet met de stem In-band audio of de stroom van G711 RTP moet worden verward aangezien later enkel de hoorbare tonen is die als normale audio zonder enige relais signaleringsmethode worden overgegaan die zich bewust of betrokken bij het proces zijn. Het betekent dat het gewoon gewone audiotonen zijn die van begin tot eind worden doorgegeven met behulp van de G711Ulaw/Alaw codec.
Enkele andere feiten over NTE met H323:
Met deze methode worden DTMF-tonen in hetzelfde RTP-kanaal verzonden als spraakgegevens. De DTMF-tonen worden echter anders gecodeerd dan de spraakmonsters en worden geïdentificeerd als payloadtype 121, waardoor de ontvanger ze als DTMF-tonen kan identificeren. Deze methode wordt niet ondersteund door CUCM en het gebruik ervan is gestaakt.
In-band RFC2833 NTE payloadtypen en -kenmerken worden besproken tussen de twee uiteinden bij call setup die gebruik maken van het Session Description Protocol (SDP) in het hoofdgedeelte van het SIP-bericht.
Met deze methode worden de cijfers OOB verzonden als SIP MELDEN berichten binnen de payload van de berichttekst.
Gebaseerd op RFC4730, worden de cijfers vervoerd OOB die XML binnen Subscriber/NOTIFY berichten gebruiken. Het wordt meestal gebruikt voor SIP-endpoints die zijn geregistreerd bij CUCM of CME, maar ook bij ITSP’s.
De cijfers worden tussen de eindjes als OOB SIP INFO-berichten doorgestuurd. Deze methode vereist geen configuratie en wordt automatisch geaccepteerd en aan elkaar gerelateerd door CUBE.
Opmerking: SIP INFO wordt niet ondersteund door Unified CM.
Opmerking: wanneer zowel de VN- als NTE-methoden worden overeengekomen, kiest Cisco IOS altijd UN over NTE om dubbele tonen te voorkomen en wordt in-band 2833 NTE-pakket onderdrukt. Ook voor CUCM wordt UN alleen gebruikt als er geen andere optie beschikbaar is. Op dezelfde manier kiest Cisco Call Manager (CCM) KPML in plaats van UN als zowel KPML als UN aanwezig zijn.
Door gebrek, is het relay DTMF gehandicapt voor zowel H323 als SIP wijzerplaat-peers (behalve SIP INFO); het is verplicht om de DTMF relay methode te vormen die van begin tot eind op zowel inkomende als uitgaande wijzerplaat-peers voor elk vraagbeen moet worden gebruikt.
Router(config)#dial-peer voice 1 voip Router(config-dial-peer)#dtmf-relay ? cisco-rtp Cisco Proprietary RTP h245-alphanumeric DTMF Relay via H245 Alphanumeric IE h245-signal DTMF Relay via H245 Signal IE rtp-nte RTP Named Telephone Event RFC 2833
U kunt meer dan één methode per dial-peer configureren, afhankelijk van de vereisten van de afsluitende eindpunten.
Router(config-dial-peer)#dtmf-relay rtp-nte ? cisco-rtp Cisco Proprietary RTP digit-drop Digits to be passed out-of-band and in-band digits dropped h245-alphanumeric DTMF Relay via H245 Alphanumeric IE h245-signal DTMF Relay via H245 Signal IE
Router(config)#dial-peer voice 1 voip Router(config-dial-peer)#dtmf-relay ? cisco-rtp Cisco Proprietary RTP h245-alphanumeric DTMF Relay via H245 Alphanumeric IE h245-signal DTMF Relay via H245 Signal IE rtp-nte RTP Named Telephone Event RFC 2833 sip-kpml DTMF Relay via KPML over SIP SUBCRIBE/NOTIFY sip-NOTIFY DTMF Relay via SIP NOTIFY messages
U kunt meer dan één methode per dial-peer configureren, afhankelijk van de vereisten van de afsluitende eindpunten.
Router(config-dial-peer)#dtmf-relay rtp-nte ? cisco-rtp Cisco Proprietary RTP digit-drop Digits to be passed out-of-band and in-band digits dropped h245-alphanumeric DTMF Relay via H245 Alphanumeric IE h245-signal DTMF Relay via H245 Signal IE sip-kpml DTMF Relay via KPML over SIP SUBSCRIBE/NOTIFY sip-NOTIFY DTMF Relay via SIP NOTIFY messages
Opmerking: Voeg de Sessieprotocol SIP-opdracht toe onder de dial-peer voor de SIP dtmf-relay opties om beschikbaar te worden.
Om dubbele cijfers te voorkomen door dezelfde DTMF-cijfers via in-band en out-of-band methoden door te geven aan de uitgaande poot voor oproepen die van een in-band (RTP-NTE specifiek) samenwerken met een out-of-band methode, moet u de dtmf-relay rtp-net digit-drop-opdracht op de inkomende dial-peer en de gewenste out-of-band-methode op de uitgaande dial-peer configureren. Anders wordt hetzelfde cijfer zowel in OOB als in-band verzonden en wordt het geïnterpreteerd als dubbele cijfers door het ontvangende eind.
Wanneer de digit-drop optie in het inkomende been wordt geconfigureerd, onderdrukt CUBE NTE-pakketten en alleen relay-cijfers die de OOB-methode gebruiken die op het uitgaande been is geconfigureerd.
Zoals in dit beeld wordt getoond, is de digit-drop optie alleen beschikbaar bij interworking tussen deze DTMF relay methodes.
Configureer bijvoorbeeld de opdracht dtmf-relay rtp-net digit-drop op de inkomende dial-peer voor een SIP-poot die cijfers doorstuurt via RFC2833, en configureer vervolgens aan de uitgaande H.323-kant dtmf-relay h245-alfanumeriek of dtmf-relay h245-signaal; dit moet ertoe leiden dat CUBE de NTE-pakketten onderdrukt en in plaats daarvan alleen de OOB H245-gebeurtenissen verstuurt.
Voor meer informatie, zie DTMF Relay Digit Drop.
Om te valideren of een eindpunt adverteert met de alfanumerieke capaciteit van H.245, moet u deze lijn zoeken binnen het bericht H.245 Terminal Capability Set (TCS) met debug h245 asn1.
capability receiveUserInputCapability : basicString : NULL
Hier is een voorbeeld van een eindpunt dat cijfer 1 overbrengt met behulp van de alfanumerieke methode H245 met behulp van debug h245 asn1.
000510: Sep 28 19:02:02.716: H245 MSC OUTGOING PDU ::= value MultimediaSystemControlMessage ::= indication : userInput : alphanumeric : "1“
Om te bevestigen of een eindpunt reclameH.245 signaalvermogen is, zoek deze lijn binnen het H.245 Terminal Capability Set (TCS) bericht dat gebruikt debug h245 asn1.
capability receiveUserInputCapability : dtmf : NULL
Dit is een voorbeeld van een eindpunt dat het cijfer 1 met een duur van 100 msec verzendt met behulp van de H245-signaalmethode. Er zijn twee berichten, het eerste bericht geeft het cijfer aan dat met een duur van 4s wordt gedraaid. Bij het tweede signaal (signalUpdate) wordt de waarde voor de cijferduur echter bijgewerkt tot 100 msec.
000555: Sep 28 19:12:05.364: H245 MSC OUTGOING PDU ::= value MultimediaSystemControlMessage ::= indication : userInput : signal : { signalType "1" duration 4000 } 000558: Sep 28 19:12:05.368: H245 MSC OUTGOING PDU ::= value MultimediaSystemControlMessage ::= indication : userInput : signalUpdate : { duration 100 rtp { logicalChannelNumber 2 }
Endpoints die H.323 V5 hebben, kunnen aangeven dat zij RFC2833 ondersteunen via een vermogensbericht binnen het TerminalCapabilitySet (TCS)-bericht.
Om te bevestigen of een eindpunt RFC2833 vermogen adverteert, zoek deze structuur binnen het H.245 TCS bericht dat gebruikt debug h245 asn1 (in het voorbeeld payload-type 101 wordt geadverteerd voor de gebeurtenissen van 0 tot 16).
capabilityTableEntryNumber 34 capability receiveRTPAudioTelephonyEventCapability : { dynamicRTPPayloadType 101 audioTelephoneEvent "0-16" }
Om te bevestigen of een eindpunt adverteert met de mogelijkheid van de ongevraagde KENNISGEVING (VN), zoek deze lijn in het INVITE-bericht en/of antwoordberichten op de INVITE met behulp van debug cisco-berichten.
INVITE sip:9999@192.168.106.66:5060 SIP/2.0 Call-Info: <sip:192.168.106.50:5060>;method="NOTIFY ;Event=telephone-event;Duration=2000“
De methode van de VN brengt de cijfers als binaire gegevens binnen het NTFY- bericht over; zodat kunt u niet zien welk cijfer door te gebruiken debug cisco-berichten wordt vervoerd. U kunt of een pakketopname (PCAP) nodig hebben of debug csip all-opdracht moeten uitvoeren om het cijfer binnen de binaire gegevensuitgangen te zien.
Voorbeeld van hoe hetzelfde gedraaide cijfer 7 er zou uitzien als bij het uitvoeren van debug ccsip all commando.
001738: Oct 9 15:37:24.577: //-1/xxxxxxxxxxxx/SIP/Msg/sipDisplayBinaryData: Sending: Binary Message Body 001739: Oct 9 15:37:24.577: Content-Type: audio/telephone-event 07 00 07 D0 001756: Oct 9 15:37:24.577: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Sent: NOTIFY sip:9999@192.168.106.66:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.106.50:5060;branch=z9hG4bK10E8E5C From: <sip:2010@192.168.105.189>;tag=557BFE8-9EE To: <sip:9999@192.168.106.66>;tag=cuecebad539 Call-ID: 87C4CAE-115E11E2-8184AAE4-EF882E8F@192.168.253.1 CSeq: 106 NOTIFY Event: telephone-event Subscription-State: active Contact: <sip:192.168.106.50:5060> Content-Type: audio/telephone-event Content-Length: 4 001763: Oct 9 15:37:24.593: //0/000000000000/SIP/Msg/ccsipDisplayMsg: Received: SIP/2.0 200 Ok Via: SIP/2.0/UDP 192.168.106.50:5060;branch=z9hG4bK10E8E5C To: <sip:9999@192.168.106.66>;tag=cuecebad539 From: <sip:2010@192.168.105.189>;tag=557BFE8-9EE Call-ID: 87C4CAE-115E11E2-8184AAE4-EF882E8F@192.168.253.1 CSeq: 106 NOTIFY Content-Length: 0 Allow-Events: refer Allow-Events: telephone-event Allow-Events: message-summary
De KPML-mogelijkheid wordt vermeld in de SSIP-header Allow-Events. Voor KPML-cijfertransmissies moet het verzendende eindpunt eerst een abonnement naar de KPML-service sturen; een ABONNEMENTSbericht verzenden waarin wordt gevraagd om de mogelijkheid, gevolgd door een MELDING vanaf het ontvangende einde waarin de abonnementsstatus voor de KPML-gebeurtenissen als actief wordt gemarkeerd.
Eerste INVITE reclame maken voor de mogelijkheid.
INVITE sip:95554445001@192.168.105.25:5060 SIP/2.0 Allow-Events: kpml, telephone-event
Het afsluitende einde vraagt een abonnement op de KMPL-evenementen.
SUBSCRIBE sip:2010@192.168.106.50:5060 SIP/2.0 Event: kpml Content-Type: application/kpml-request+xml
Het voortkomende einde reageert met een MELDING waarbij de status wordt geactiveerd.
NOTIFY sip:192.168.105.25:5060 SIP/2.0 Event: kpml Subscription-State: active
Nadat het abonnement heeft plaatsgevonden, kunnen de eindpunten de cijfers verzenden met behulp van NOTIFY-berichten met KPML-gebeurtenissen via XML. Voorbeeld van cijfer 1 dat wordt doorgegeven.
NOTIFY sip:192.168.105.25:5060 SIP/2.0 Event: kpml <?xml version="1.0" encoding="UTF-8"?>
<kpml-response version="1.0" code="200" text="OK" digits="1" tag="dtmf"/>
CUBE ondersteunt ongeveer 30 verschillende typen DTMF-interworking. Het is in staat om te interageren en te transcoderen tussen verschillende relay methodes die op het dtmf-relay bevel gebaseerd zijn dat binnen de overeenstemmende inkomende en uitgaande wijzerplaat-peers voor de vraag wordt gevormd.
Raadpleeg het gedeelte DTMF Interoperability Table van de CUBE Configuration Guide voor meer informatie over ondersteuning van DTMF Interworking.
CUBE vereist transcoderingsresources die lokaal zijn geregistreerd in deze scenario's
CUBE is in staat om tussen alle andere DTMF relay methodes met flow-through vraag zonder de behoefte van een transcoder te werken.
CUBE is in staat om te werken tussen Inband G711 DTMF (rauwe audiotonen) en RFC2833. Aan deze vereisten moet echter worden voldaan
Er is ook een extra set interworking commando's die vereist kunnen zijn bij specifieke call scenario's; die globaal kunnen worden geconfigureerd of op dial-peer niveau.
dtmf-interworking {rtp-nte | standard | system} rtp-nte Enables a delay between the dtmf-digit begin and dtmf-digit end events of RTP NTE packets. Standard Generates RTP NTE packets that are RFC 4733 compliant. System Specifies the default global DTMF interworking configuration. This keyword is available only in dial peer voice configuration mode.
MTP-bron wordt noodzakelijk wanneer CUCM verschillende DTMF-methoden moet uitwisselen tussen twee apparaten, waarvan de ene specifiek de RFC2833-methode gebruikt en de andere een OOB-methode. In dit scenario moet de CUCM de nodige middelen toewijzen om de in-band tonen te verzenden en/of te detecteren vanwege de DTMF-relay mismatch tussen de twee uiteinden.
De rol van MTP is het verkeer van RTP te controleren en gebeurtenissen NTE van het been te ontdekken RFC2833 of de gebeurtenissen van NTE in de stroom van RTP te injecteren indien gevraagd door CUCM. Als de MTP inkomende NTE-gebeurtenissen detecteert vanaf het eindpunt dat alleen RFC2833 ondersteunt, wordt een SCCP-stationNOTIFYDtmfToneMessage naar de CUCM verzonden en wordt het op de hoogte gesteld van de toon die in de stream is gedetecteerd. De CUCM stuurt dan weer hetzelfde cijfer en gebruikt het signaleringsprotocol (OOB) aan de andere kant. Als de CUCM een OOB DTMF signaal van het OOB DTMF eindpunt ontvangt dan verzendt het een SCCP StationSendDtmfToneMessage naar MTP zodat MTP de gevraagde toon in de RTP stroom in de vorm van NTE gebeurtenissen kan inspuiten.
Software MTP is een apparaat dat wordt geïmplementeerd door de Cisco IP Voice Media Streaming-toepassing op een CUCM-server in te schakelen. Wanneer de geïnstalleerde applicatie is geconfigureerd als een MTP-toepassing, registreert het bij een CUCM-knooppunt en informeert het CUCM over hoeveel MTP-bronnen het ondersteunt. Een software MTP apparaat ondersteunt alleen G.711 stromen. De standaardinstellingen van CUCM maken het mogelijk om tot 48 oproepen te verwerken per software MTP. Raadpleeg voor meer informatie over het wijzigen van de serviceparameters de juiste versie van de Cisco Unified Communications Manager Administration Guide.
Deze MTP staat configuratie van een van deze codecs toe, maar slechts één kan worden geconfigureerd op een gegeven tijd G.711 mu-wet en a-wet, G.729a, G.729, G.729ab, G.729b, en passthrough. Sommige van deze zijn niet relevant voor een CUCM-implementatie.
Routerconfiguraties maken tot 1.000 afzonderlijke stromen mogelijk, die 500 getranscodeerde sessies ondersteunen die 10 bytes aan verkeer genereren. De Cisco ISR G2s- en ASR-routers kunnen aanzienlijk hogere getallen ondersteunen.
Deze MTP gebruikt CPU-cycli om te werken. Noteer het aantal sessies dat is ingeschakeld omdat dit van invloed kan zijn op de prestaties van de CPU en een hoog CPU-gebruik kan veroorzaken.
Deze hardware gebruikt de PVDM-2 modules voor het leveren van DSP’s.
Deze routers gebruiken de PVDM3 DSPs op de moederborden of PVDM2 met een adapter op het moederbord of op servicemodules.
Opmerking: u kunt G.729 of G.729b niet configureren bij het configureren van hardware-MTP-bronnen in Cisco IOS. Unified CM kan echter hardware transcoderingsbronnen als MTP's gebruiken als alle andere MTP-bronnen uitgeput of anderszins niet beschikbaar zijn.
Het type MTP dat in uw netwerk moet worden geïmplementeerd, is afhankelijk van specifieke codec-parameters die worden ondersteund door de endpoints, gateways en trunks in de oproepstroom
Op basis van deze parameters kunt u veilig de juiste bronnen kiezen en implementeren die vereist zijn voor uw netwerk.
Zoals getoond in de tabel, de verschillende functies ondersteund door verschillende MTP en transcoder types
Type |
Dezelfde codecs |
Verschillende codecs |
Verschillende pakketvorming |
Codec Doorslag |
Opmerkingen |
CUCM SW MTP |
Ja |
Nee |
Ja |
Nee |
G711 Recht-Onrecht transcodering en repacketisering |
Cisco IOS HW MTP |
Ja |
Nee |
Nee |
Ja |
Ondersteuning voor elke codec (en dezelfde smaak) zolang dezelfde pakketvorming. Geen transcodering. |
Cisco IOS SW MTP |
Ja |
Nee |
Nee |
Ja |
Ondersteun elke codec (en dezelfde smaak) zolang dezelfde pakketvorming. Geen transcodering. |
Cisco IOS reguliere xcoder |
Ja |
Ja |
Ja |
Ja |
Zolang ten minste één kant G711u/G711a is, ondersteunt het elke repacketisering en transcodering. |
Cisco IOS universele xcoder |
Ja |
Ja |
Ja |
Ja |
Ondersteuning in elke codec, pakketvorming en transcodering. |
Raadpleeg voor meer informatie over de MTP-configuratie in CUCM het configuratievoorbeeld van het afsluitpunt van media.
Wanneer het creëren van en de toewijzing van media middelen aan media resourcegroepen (MRG) en media resourcegroepslijsten (MRGL), neem sommige extra punten om over-abonnement van de beste middelen voor specifieke vraagstromen te overwegen te vermijden en aan hen dienovereenkomstig voorrang te geven. CUCM is niet in staat om het beste te gebruiken apparaat te kiezen, wanneer het een media bron voor een vraag selecteert, uit een bepaalde lijst van MTPs en transcoders als zij de zelfde prioriteit of orde hebben. In plaats daarvan, kiest het het eerste apparaat dat de gevraagde mogelijkheden steunt. Dus zelfs als de oproep G711 op beide benen gebruikt, als het eerste apparaat dat hij vindt een transcoder is dan wijst hij het toe als een MTP voor de oproep en zoekt niet verder naar een MTP bron.
Een ander gelijkaardig gedrag komt voor wanneer u zowel universele als regelmatige transcoders hebt. De CUCM kon de reguliere transcoders eerst gebruiken op een oproep waar een van de benen G711 was, en vervolgens falen wanneer een oproep wordt overgebracht naar een bestemming die een niet-G711 codec gebruikt, omdat de CUCM niet gaat de huidige transcoder vrijgeven en een andere krijgt wanneer de oproep wordt overgebracht.
De beste ontwerppraktijk om dit gedrag te omzeilen is alle MTP-apparaten in één MRG toe te wijzen, dan de universele transcoders aan een andere MRG en de regelmatige transcoders aan een derde MRG; en dan hen in die zelfde orde binnen MRGL voorrang te geven. Dit ontwerp kan niet voor elke topologie werken en moet geval per geval worden bekeken.
Deze SCCP-berichten worden uitgewisseld tussen de CUCM- en MTP-bronnen voor DTMF-verwerking.
CUBE ondersteunt KPML, NTE of Unsolicited Notify als het DTMF mechanisme, afhankelijk van de configuratie ervan. Omdat er een mix van eindpunten in het systeem kan zijn, kunnen meerdere methoden tegelijkertijd op de CUBE worden geconfigureerd om MTP-vereisten te minimaliseren.
Voor CUBE, vorm zowel sip-kpml als rtp-net als DTMF relay methodes onder SIP wijzerplaatpeers. Deze configuratie maakt DTMF-uitwisseling mogelijk met alle typen endpoints, inclusief die welke alleen NTE ondersteunen en die welke alleen OOB-methoden ondersteunen, zonder dat MTP-bronnen nodig zijn. Met deze configuratie, onderhandelt de gateway zowel NTE als KPML met CUCM. Als NTE niet wordt ondersteund door het Unified CM-eindpunt, wordt KPML gebruikt voor DTMF-uitwisseling. Als beide methodes met succes worden besproken, dan vertrouwt de gateway op NTE om cijfers te ontvangen en onderschrijft niet aan KPML.
CUBE heeft ook de mogelijkheid om de Unsolicited Notify (UN) methode voor DTMF te gebruiken. De VN-methode stuurt een SIP-waarschuwingsbericht met een tekst die de DTMF-tint beschrijft. Deze methode wordt ook ondersteund op Unified CM en kan worden gebruikt als sip-kpml niet beschikbaar is. Configureer de sip-details als de DTMF Relay methode. Let op dat deze methode Cisco-eigendom is.
CUBE's die alleen voor NTE-relay zijn geconfigureerd, of die vanwege een bepaalde interworking-beperking alleen NTE en vereiste MTP-bronnen kunnen leveren die aan de CUCM-kant moeten worden toegewezen bij communicatie met eindpunten die NTE niet ondersteunen.
U kunt Meer informatie vinden over CUCM SIP Trunk MTP-vereisten
CUCM kiest dynamisch de DTMF transportmethode voor H323 trunks; er zijn dus geen configureerbare opties om een over de andere te kiezen. Als u een specifieke DTMF relay methode wilt forceren, dan kunt u dit doen vanuit de CUBE wijzerplaat-peer configuratie voor deze trunk.
Zelfs wanneer H323 CUBE's NTE ondersteunen, mag de NTE-optie niet worden gebruikt omdat deze op dit moment niet wordt ondersteund op CUCM voor H.323 gateways/trunks; dus CUCM maakt deze mogelijkheid niet bekend op het moment dat H245-mediamogelijkheden worden uitgewisseld. De voorkeursoptie van de CUCM is H.245-signaal.
MTP-bronnen zijn vereist om oproepen naar een H.323 CUBE vast te stellen als het andere eindpunt geen signaleringsmogelijkheid heeft die gelijk is aan CUCM. Bijvoorbeeld, een Cisco Unified IP-telefoon 7960 die de SIP stack draait ondersteunt alleen NTE's, zodat een MTP nodig is met een H.323-trunk, zodat H245 Alphanumeric kan worden gebruikt op de H323-poot.
Sinds Cisco IOS versie 15.1(1)T (CUBE 1.4) is ondersteuning voor Dynamic Payload Type Interworking voor DTMF en Codec Packets voor SIP naar SIP Call geïntroduceerd.
Deze eigenschap staat de CUBE toe om de interworking van te behandelen: dynamische payloadtypes voor audio/video-codecs, NSE en DTMF; die tot dit punt beperkt waren omdat Cisco IOS een statisch bereik zou reserveren en alleen toe te staan dat dezelfde payloadtypes worden onderhandeld op beide call-legs en de oproep af te wijzen met een 488 error response voor het niet goed op elkaar afstemmen van audio/video/NSE-codecs (of fallback naar spraak inband G711 DTMF) voor het niet op elkaar aansluiten van NTE-payloads. Daarom stelt de functie de CUBE in staat om storingen of gratis payloadtypes dynamisch uit te schakelen voor de samenwerking met SIP-providers of externe apparaten die een andere reeks payloadtypes gebruiken voor een andere poot die ze niet zou ondersteunen of die een andere specifieke mapping vereist.
Een call leg op CUBE wordt beschouwd als symmetrisch of asymmetrisch gebaseerd op de payload type waarde die via SDP tijdens het aanbod en antwoord met het eindpunt wordt uitgewisseld.
Deze opdracht is beschikbaar om het gebruik van asymmetrische payloads te specificeren; de opdracht kan globaal worden toegepast onder de voip van de spraakservice enter sip config mode of op dial-peer niveau met behulp van de spraak-klasse sip CLI
asymmetric payload {dtmf | dynamic-codecs | full | system}
Voor meer informatie over Dynamische/Asymmetrische payloads, navigeer naar Dynamic payload type interworking voor DTMF en codec pakketten voor SIP naar SIP gesprekken
Hier is een voorbeeld van hoe de SDP zou kijken naar een symmetrische payloadonderhandeling en de output van de debug voip rtp sessie met de naam event terwijl DTMF tonen worden verzonden. Houd er rekening mee dat de configuratie die wordt gebruikt om Cisco IOS te forceren een ander payloadtype kan gebruiken voor NTE-gebeurtenissen die gebruik maken van het commando rtp payload-type net.
Hier is een voorbeeld van hoe de SDP eruit zou zien als een asymmetrische payloadonderhandeling en de output van de debug voip rtp sessie met de naam event commando terwijl DTMF tonen worden verzonden. Let op de configuratie die gebruikt wordt om Cisco IOS te dwingen een ander payloadtype te gebruiken voor NTE-gebeurtenissen en gebruik de opdrachten van het type rtp payload-net en de asymmetrische payload-klasse van het sip-type dtmf CLI.
Wanneer u het te gebruiken DTMF-relay kiest, moet u met deze variabelen rekening houden.
De voorkeursmethode voor H323 zou zijn om OOB via H.245 alfanumeriek of signaal in bijna alle scenario's te gebruiken. U kunt ook RFC2833 gebruiken zolang CUCM niet betrokken is.
Ondersteuning van universele spraaktranscodering voor IP-naar-IP gateways
Configuratievoorbeeld van Unified border-element transcodering
DTMF Relay Digit-Drop configureren op een Cisco Unified border-element
SIP INFO Methode voor het genereren van Tonen DTMF
Revisie | Publicatiedatum | Opmerkingen |
---|---|---|
2.0 |
15-May-2023 |
Toegevoegd Alt Text en achtergrond info.
Bijgewerkte Inleiding, Branding Vereisten, SEO, Machinevertaling, Stijl Vereisten, Rondingen, en het Formatteren |
1.0 |
30-Mar-2016 |
Eerste vrijgave |