Inhoud

Inleiding

Voorwaarden

Vereisten

Gebruikte componenten

Conventies

Achtergrondinformatie

Ondersteunde DTMF-Relay methodes voor CUBE

Ondersteunde in-band DTMF Relay methodes

Ondersteunde out-of-band DMTF-relay-methoden

Ondersteuning voor In-band Audio DTMF via G711

Ondersteunde DTMF-Relay methoden voor H323

H.245 alfanumeriek

H.245-signaal

Benoemde telefonie-evenementen (NTE) - RFC2833

Cisco bedrijfseigen RTP

Ondersteunde DTMF-Relay methodes voor SIP

NTE - RFC283

Ongevraagde MELDING (VN)

Key Press Markup Language (KPML)

Informatie (INFO)

DTMF-Relay op CUBE configureren

DTMF Relay configureren voor H323

DTMF Relay voor SIP configureren

DTMF Relay Digit-Drop configureren

DTMF-relay valideren en problemen oplossen

Waardeer OOB DTMF Relay voor H323

Advertentie voor H.245 alfanumerieke mogelijkheden

Voorbeeld van H.245-alfanumerieke transmissie

Advertentie voor H.245-signaalmogelijkheid

Voorbeeld van H.245-signaaloverdracht

Bevestig in-band DTMF Relay voor H323

RFC2833-advertenties voor ondersteuning van functies

Waardeer OOB DTMF Relay voor SIP

Voorbeeld van ongevraagde MELDING (UN)

Voorbeeld van ongevraagde kennisgevingen (VN)

Key Press Markup Language (KPML) - Advertentievoorbeeld

KPML-transmissievoorbeeld

DTMF-interactie

Wanneer vereist CUBE transcoderingsresources voor DTMF

DTMF Interworking tussen Inband G711 en RFC2833

Andere opties voor DTMF-interactie

Wanneer zijn MTP-bronnen vereist door CUCM

MTP-apparaten ondersteund door CUCM

Software MTP (Cisco IP Voice Media Streaming-toepassing)

Software MTP (gebaseerd op Cisco IOS)

Hardware MTP (PVDM2, Cisco NM-HDV2 en NM-HD-1V/2V/2VE)

Hardware MTP (Cisco 2900 en 3900 Series routers met PVDM3)

Wanneer moet u software of hardware-MTP gebruiken

Overwegingen in CUCM Media Resource Group (MRG) en Media Resource Group List (MRGL) voor MTP

SCCP MTP-berichten

DTMF Relay tussen CUCM en CUBE

CUCM SIP Trunk naar CUBE

CUCM H323 trunk naar CUBE

Dynamische/asymmetrische payloads van CUBE

Voorbeeld symmetrische payloads

DTMF Relay-onderhandeling

DTMF Relay-transmissie

Voorbeeld asymmetrische payloads

DTMF Relay-onderhandeling

DTMF Relay-transmissie

Welke te gebruiken methode voor DTMF Relay

Voorkeursmethoden voor DTMF Relay voor H.323

Voorkeursmethoden voor DTMF Relay voor SIP

Gerelateerde informatie

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 methodes

- 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 gebruiken de codec G711Ulaw/Alaw 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.

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.

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.

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

Opmerking: Voeg de Sessieprotocol SIP-opdracht toe onder de dial-peer voor de SIP dtmf-relay opties om beschikbaar te worden.

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, zoekt u deze lijn binnen het bericht van de 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 kennisgevingen (VN)

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&colon;

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 optie Digi-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 om het RTP-verkeer te bewaken en NTE-gebeurtenissen te detecteren van de RFC2833-poot of om de NTE-gebeurtenissen in de RTP-stroom te injecteren indien de CUCM daarom verzoekt. 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.

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.

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 Rechtmatige 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

DTMF-conversie

Configuratievoorbeeld van Unified border-element transcodering

Cisco Unified Communications Manager gebruiken om een transcoderings- en media-afsluitpunt te configureren

DTMF Relay Digit-Drop configureren op een Cisco Unified border-element

SIP Trunk MTP-vereisten

SIP INFO Methode voor het genereren van Tonen DTMF

H.323 trunks met media-afsluitpunten

CUBE 9.0 lokale transcoderingsinterface (LTI)