DTMF Relay op CUBE configureren
Inhoud
Inleiding
Dit document beschrijft het proces om DTMF-relay (Dual Tone Multi-Frequency) te configureren voor Cisco Unified Border Element (CUBE) Enterprise.
Voorwaarden
Vereisten
Cisco raadt kennis van de volgende onderwerpen aan.
- Basiskennis van DTMF-tonen
- Basiskennis van de configuratie en het gebruik van Cisco® IOS-spraak (zoals dial-peers)
- Basiskennis van het configureren en gebruiken van CUBE
- Basiskennis van de signalering die wordt gebruikt door de SIP- en H323-protocollen
- Basiskennis van het debuggen van VoIP-protocollen zoals H323 en SIP
Gebruikte componenten
De informatie in dit document is gebaseerd op de volgende software- en hardware-versies.
- Cisco Unified border-element dat op Cisco IOS wordt uitgevoerd.
- Cisco Unified Communications Manager 7.x of hoger.
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.
Conventies
Raadpleeg de Cisco Technical Tips Conventions voor informatie over documentconventies.
Achtergrondinformatie
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.
Ondersteunde DTMF-Relay methodes voor CUBE
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.
Ondersteunde in-band DTMF Relay-methoden
- In-band audio DTMF via G711
- RFC 283
Ondersteunde out-of-band DMTF-relay-methoden
- H.245 alfanumeriek
- H.245-signaal
- SIP ongevraagde MELDING
- SIP-KPML
- SIP-INFO
Ondersteuning voor In-band Audio DTMF via G711
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.
Ondersteunde DTMF-Relay methoden voor H323
H.245 alfanumeriek
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.
H.245-signaal
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.
Benoemde telefonie-evenementen (NTE) - RFC2833
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:
- H.323 ondersteunt RFC283 vanaf V4
- Cisco IOS adverteert altijd met de 2833-ondersteuning in TCS
- CUCM ondersteunt alleen NTE via een H.323 ICT.
Cisco bedrijfseigen RTP
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.
Ondersteunde DTMF-Relay methodes voor SIP
NTE - RFC283
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.
Ongevraagde MELDING (VN)
Met deze methode worden de cijfers OOB verzonden als SIP MELDEN berichten binnen de payload van de berichttekst.
Key Press Markup Language (KPML)
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.
Informatie (INFO)
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.
DTMF-Relay op CUBE configureren
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.
DTMF Relay configureren voor H323
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
DTMF Relay voor SIP configureren
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
DTMF Relay Digit-Drop configureren
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.
DTMF-relay valideren en problemen oplossen
Waardeer OOB DTMF Relay voor H323
Advertentie voor H.245 alfanumerieke mogelijkheden
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
Voorbeeld van H.245-alfanumerieke transmissie
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“
Advertentie voor H.245-signaalmogelijkheid
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
Voorbeeld van H.245-signaaloverdracht
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
}
Bevestig in-band DTMF Relay voor H323
Endpoints die H.323 V5 hebben, kunnen aangeven dat zij RFC2833 ondersteunen via een vermogensbericht binnen het TerminalCapabilitySet (TCS)-bericht.
RFC2833-advertenties voor ondersteuning van functies
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"
}
Waardeer OOB DTMF Relay voor SIP
Voorbeeld van ongevraagde MELDING (UN)
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“
Voorbeeld van ongevraagde (UN) MELDING
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
Key Press Markup Language (KPML) AVoorbeeld van decodering
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
KPML TVoorbeeld van transmissie
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"/>
DTMF-interactie
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.
Wanneer vereist CUBE transcoderingsresources voor DTMF
CUBE vereist transcoderingsresources die lokaal zijn geregistreerd in deze scenario's
- Interactie tussen RFC2833 en Voice in-band
- Interactie tussen een OOB-methode en RFC2833 voor flow-around-oproepen
CUBE is in staat om tussen alle andere DTMF relay methodes met flow-through vraag zonder de behoefte van een transcoder te werken.
DTMF Interworking tussen Inband G711 en RFC2833
CUBE is in staat om te werken tussen Inband G711 DTMF (rauwe audiotonen) en RFC2833. Aan deze vereisten moet echter worden voldaan
- De gebruikte codec moet een G711 end-to-end zijn. Dit is een beperking omdat als een LBR codec zou worden gebruikt, dan zouden de tonen vervormd worden toe te schrijven aan het compressieverlies.
- De transcoderingsmiddelen moeten dienovereenkomstig beschikbaar zijn en bij de CUBE worden geregistreerd. Dit omdat de CUBE een transcoderingsresource (meer specifiek: een DSP-resource) aan de media RTP-stream moet toewijzen om tonen in de audiostream te injecteren of naar tonen te luisteren.
- De dial-peer voor de inband-tones poot mag geen DTMF relay-opdracht geconfigureerd hebben. Deze vereiste is niet langer nodig voor IOS XE 16.12.x of hoger. CUBE kan een transcoder dynamisch toewijzen, zelfs als de inkomende/ITSP-dial-peer dtmf-relay rtp-net geconfigureerd heeft. De beslissing om een transcoder toe te wijzen kan afhangen van de SDP-onderhandeling tussen de peer-apparaten.
- De dial-peer voor de RFC2833-poot moet geconfigureerd zijn met dtmf-relay rtp-net.
- Schakel de digit-drop niet in op de dial-peers die bij de aanroep betrokken zijn.
Andere opties voor DTMF-interactie
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.
Wanneer zijn MTP-bronnen vereist door CUCM
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.
MTP-apparaten ondersteund door CUCM
Software MTP (Cisco IP Voice Media Streaming-toepassing)
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.
Software MTP (gebaseerd op Cisco IOS)
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.
Hardware MTP (PVDM2, Cisco NM-HDV2 en NM-HD-1V/2V/2VE)
Deze hardware gebruikt de PVDM-2 modules voor het leveren van DSP’s.
Hardware MTP (Cisco 2900 en 3900 Series routers met PVDM3)
Deze routers gebruiken de PVDM3 DSPs op de moederborden of PVDM2 met een adapter op het moederbord of op servicemodules.
Wanneer moet u software of hardware-MTP gebruiken
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
- De te gebruiken codecsmaakstoffen
- De te gebruiken codec-pakketgrootte (pakketvorming)
- T.38-faxgebruik (hiervoor is ondersteuning van Codec Pass-Through nodig)
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.
Overwegingen in CUCM Media Resource Group (MRG) en Media Resource Group List (MRGL) voor MTP
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.
SCCP MTP-berichten
Deze SCCP-berichten worden uitgewisseld tussen de CUCM- en MTP-bronnen voor DTMF-verwerking.
- StationsmogelijkhedenRes
- StationUpdate-functies
- StationSubscriberDTMFpayloadReq
- StationSubscriberDTMFPayloadErv
- StationSubscriberDTMFpayloadRes
- DTMFpayloadFout bij uitschrijven van station
- StationKENNISGEVINGDtmfToneBericht
- StationVerzendDTMFtoneBericht
- StationAbonnement opzeggenDTMFpayloadReq
- Abonnement op DTMFpayloadRes opzeggen
DTMF Relay tussen CUCM en CUBE
CUCM SIP Trunk naar CUBE
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 H323 trunk naar CUBE
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.
Dynamische/asymmetrische payloads van CUBE
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.
- Een symmetrisch eindpunt accepteert en verstuurt hetzelfde payloadtype voor NTE-gebeurtenissen of een specifieke codec voor een call leg.
- Een asymmetrisch eindpunt kan verschillende payloadtypes accepteren en verzenden voor NTE-gebeurtenissen of een specifieke codec voor een call leg.
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
Voorbeeld symmetrische payloads
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.
DTMF Relay-onderhandeling
DTMF Relay-transmissie
Voorbeeld asymmetrische payloads
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.
DTMF Relay-onderhandeling
DTMF Relay-transmissie
Welke te gebruiken methode voor DTMF Relay
Wanneer u het te gebruiken DTMF-relay kiest, moet u met deze variabelen rekening houden.
- betrokken apparaten en platforms.
- VoIP-protocollen in kwestie.
- Mediapad en ondersteunde codecs.
- Ondersteunde of voorkeursmethoden voor DTMF-relay.
Voorkeursmethoden voor DTMF Relay voor H.323
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.
Voorkeursmethoden voor DTMF Relay voor SIP
- SIP-trunks voor serviceproviders - wanneer er een SIP-trunk is naar een betrokken SIP-provider of interactie met 3rood partij SIP-apparaten of IVR-systemen, dan in-band via RFC2833, hebben de voorkeur.
- SIP-trunk naar CUCM of CME - schakelt zowel RFC2833 als KPML in.
- SIP-trunk naar CUE - de standaardmethode voor CUE is UN, maar u kunt ook configureren om NTE te gebruiken; wat ook de beste optie is als de oproep van een SIP-provider naar het CUE-systeem komt.
Gerelateerde informatie
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
Revisiegeschiedenis
| 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 |
FeedbackContact Cisco
- Een ondersteuningscase openen
- (Vereist een Cisco-servicecontract)