Inhalt

Einleitung

Voraussetzungen

Anforderungen

Verwendete Komponenten

Konventionen

Hintergrundinformationen

Unterstützte DTMF-Relay-Methoden für CUBE

Unterstützte In-Band-DTMF-Relay-Methoden

Unterstützte Out-Of-Band-DMTF-Relay-Methoden

Unterstützung für In-Band-Audio (DTMF bis G711)

Unterstützte DTMF-Relay-Methoden für H323

H.245 Alphanumerisch

H.245-Signal

Benannte Telefonie-Ereignisse (NTE) - RFC2833

Proprietäres Cisco RTP

Unterstützte DTMF-Relay-Methoden für SIP

NTE - RFC2833

Unsolicited NOTIFY (UN)

Key Press Markup Language (KPML)

Information (INFO)

Konfigurieren von DTMF-Relay auf CUBE

DTMF-Relay für H323 konfigurieren

DTMF-Relay für SIP konfigurieren

DTMF-Relay-Ziffernlöschung konfigurieren

DTMF-Relay validieren und Fehlerbehebung durchführen

OOB-DTMF-Relay für H323 validieren

Alphanumerische H.245-Funktionsanzeige

Beispiel für alphanumerische Übertragung in H.245

H.245 Signalfähigkeitsanzeige

Beispiel für H.245-Signalübertragung

In-Band-DTMF-Relay für H323 bestätigen

RFC2833 - Ankündigung zur Unterstützung von Funktionen

Validierung des OOB-DTMF-Relays für SIP

Beispiel für unsolicited NOTIFY (UN)-Werbung

Übertragungsbeispiel für Unsolicited NOTIFY (UN)

Beispiel für eine KPML-Werbeanzeige (Key Press Markup Language)

Beispiel für KPML-Übertragung

DTMF-Interworking

Wann sind für CUBE Transkodierungsressourcen für DTMF erforderlich?

DTMF-Interworking zwischen In-Band G711 und RFC2833

Weitere DTMF-Interworking-Optionen

Wann werden vom CUCM MTP-Ressourcen benötigt?

Von CUCM unterstützte MTP-Geräte

Software-MTP (CiscoIP Voice Media Streaming-Anwendung)

Software-MTP (basierend auf Cisco IOS)

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

Hardware-MTP (Cisco Router der Serien 2900 und 3900 mit PVDM3)

Verwendung von MTP-Software oder -Hardware

Überlegungen zur CUCM-Medienressourcengruppe (MRG) und zur Medienressourcengruppen-Liste (MRGL) für MTP

SCCP-MTP-Nachrichten

DTMF-Relay zwischen CUCM und CUBE

CUCM-SIP-Trunk zu CUBE

CUCM H323-Trunk zu CUBE

Dynamische/Asymmetrische CUBE-Payloads

Beispiel für symmetrische Payloads

DTMF-Relayverhandlung

DTMF-Relayübertragung

Beispiel für asymmetrische Payloads

DTMF-Relayverhandlung

DTMF-Relayübertragung

Welche DTMF-Relaymethode verwendet werden soll

Bevorzugte DTMF-Relay-Methoden für H.323

Bevorzugte DTMF-Relay-Methoden für SIP

Zugehörige Informationen

Einleitung

In diesem Dokument wird das Verfahren zur Konfiguration eines DTMF-Relais (Dual-Tone Multi-Frequency) für Cisco Unified Border Element (CUBE) Enterprise beschrieben.

Voraussetzungen

Anforderungen

Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen.

- Grundkenntnisse der DTMF-Töne

- Grundkenntnisse der Konfiguration und Verwendung von Cisco® IOS Voice (z. B. Dial-Peers)

- Grundkenntnisse der Konfiguration und Verwendung von CUBE

- Grundkenntnisse der von den SIP- und H323-Protokollen verwendeten Signalisierung

- Grundlegendes Wissen über das Debuggen von VoIP-Protokollen wie H323 und SIP

Verwendete Komponenten

Die Informationen in diesem Dokument basierend auf folgenden Software- und Hardware-Versionen.

- Cisco Unified Border Element für Cisco IOS.

- Cisco Unified Communications Manager 7.x oder höher

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.

Konventionen

Informationen zu Dokumentkonventionen finden Sie unter Cisco Technical Tips Conventions (Technische Tipps von Cisco zu Konventionen).

Hintergrundinformationen

Dieses Dokument enthält außerdem Informationen und Befehle zum Konfigurieren, Überprüfen und Beheben von DTMF-Weiterleitungen für die verschiedenen VoIP-Gateway-Protokolle, die von CUBE unterstützt werden.

Unterstützte DTMF-Relay-Methoden für CUBE

CUBE unterstützt zahlreiche DTMF-Weiterleitungsverfahren für In-Band- und Out-Of-Band (OOB) für die H.323- und Session Initiation Protocol (SIP)-Signalisierungsprotokolle.

Unterstützte In-Band-DTMF-Relay-Methoden

- In-Band-Audio (DTMF bis G711)

- RFC 2833

Unterstützte Out-Of-Band-DMTF-Relay-Methoden

- H.245 Alphanumerisch

- H.245-Signal

- SIP Unsolicited NOTIFY

- SIP-KPML

- SIP-INFO

Unterstützung für In-Band-Audio (DTMF bis G711)

Voice In-Band-Audio oder G711 DTMF bezieht sich auf den Transport von hörbaren Tönen über den Sprach-Audio-Stream, ohne zusätzliche Beteiligung des Signalisierungsprotokolls oder des DSP für ihre Übertragung, außer um den Anruf normal einzurichten und die Audio-Ende-zu-Ende-weiterzuleiten und den G711Ulaw/Alaw-Codec zu verwenden. Das bedeutet, dass das CUBE/Cisco IOS nur den Ton der Töne weiterleitet, die von einem Ende zum anderen kommen, als ob es sich um normales Sprach-Audio handelt. Die wichtigste Maßnahme bei diesem Verfahren besteht darin, sicherzustellen, dass die Anrufe getätigt werden, und den Codec G711Ulaw/Alaw zu verwenden, da ein Codec, der die Audiodaten komprimieren würde (jeder andere Codec als G711), die DTMF-Töne verzerrt und sie für die empfangende Seite wahrscheinlich nicht erkennbar macht. Der Grund hierfür ist, dass der von Codecs mit hoher Komprimierung verwendete Komprimierungsalgorithmus für die Erkennung und Vorhersage menschlicher Sprache und nicht für DTMF-Töne entwickelt wurde.

In-Band-Audio/G711-DTMF wird von allen VoIP-Signalisierungsprotokollen unterstützt und erfordert nur, dass der G711-Codec für die End-to-End-Anrufe durchgesetzt wird. Man muss auch bedenken, dass jede Transkodierung von einem Low-Bit-Rate (LBR) Codec auf G711 wahrscheinlich auch die Töne verzerrt.

Hinweis: Bei der Erläuterung dieser DTMF-Weiterleitungsmethode kommt es häufig zu Verwirrung, da sich der Begriff "In-Band" auf den Transport von DTMF innerhalb des RTP-Streams bezieht, der als "Named Telefony Event" (NTE/RFC2833) bezeichnet wird, und wenn es sich um In-Band-Audiotöne handelt. Es ist immer wichtig, die tatsächliche Methode zu klären, die für die Anwendung der richtigen Konfiguration erforderlich/unterstützt wird, und den richtigen Ansatz für die Fehlerbehebung zu verwenden.

Unterstützte DTMF-Relay-Methoden für H323

H.245 Alphanumerisch

DTMF-Ziffern werden vom Sprachdatenstrom getrennt und nicht über den RTP-Kanal, sondern über den H.245-Signalisierungskanal OOB gesendet. Die Töne werden in H.245 User Input Indication Nachrichten übertragen. Der H.245-Signalisierungskanal ist ein zuverlässiger Kanal, und die Pakete, die die DTMF-Töne übertragen, werden garantiert bereitgestellt. Zur Unterstützung des alphanumerischen Befehls dtmf-relay h245-werden alle H.323 Version 2-konformen Systeme benötigt. Die Unterstützung des Befehls dtmf-relay h245-signal ist jedoch optional.

H.245-Signal

Das OOB-Verfahren, das dem alphanumerischen H.245-Verfahren ähnelt, ermöglicht die Übertragung der Tondauerinformationen, wodurch ein potenzielles Problem mit dem alphanumerischen Verfahren bei der Interaktion mit den Systemen anderer Anbieter gelöst wird.

Benannte Telefonie-Ereignisse (NTE) - RFC2833

Dieses Verfahren transportiert DTMF-Töne in separaten RTP-Paketen gemäß Abschnitt 3 von RFC 2833. RFC 2833 definiert Formate für NTE-RTP-Pakete, die zum Transport von DTMF-Ziffern, Hook-Flash und anderen Telefonie-Ereignissen zwischen zwei Peer-Endpunkten verwendet werden. Bei der NTE-Methode führen die Endpunkte eine anrufbasierte Aushandlung der DTMF-Weiterleitungsparameter durch, um den Nutzlasttypwert für die NTE-RTP-Pakete und die unterstützten NTE-Nummernereignisse zu bestimmen. Dadurch werden DTMF-Töne über RTP-Pakete mit einem Nutzlasttypwert übertragen, der sich von den für andere Medienpakete ausgehandelten Werten unterscheidet. Dies ist eine zuverlässige Methode, um die Ziffern zu transportieren und zu verhindern, dass sie nicht erkannt werden, wenn sie über den Codec komprimiert werden, der zur Kodierung des Sprach-, Video- oder Faxverkehrs verwendet wird.

RFC2833/NTE DTMF-Weiterleitungen gelten als In-Band-Verfahren, da die Ziffern innerhalb des RTP-Audiodatenverkehrs selbst ohne Beteiligung des GW-Signalisierungsprotokolls übertragen werden.

Es ist wichtig darauf hinzuweisen, dass das RFC2833/NTE-Verfahren nicht mit dem In-Band-Sprach-Audio oder dem G711-RTP-Stream verwechselt werden darf, da letzterer nur die hörbaren Töne ist, die als normales Audio weitergeleitet werden, ohne dass eine Relay-Signalisierungs-Methode den Prozess erkennt oder daran beteiligt ist. Das bedeutet, dass es sich nur um einfache Audiotöne handelt, die durchgängig über den G711Ulaw/Alaw-Codec übertragen werden.

Weitere Fakten über NTE bei H323:

- H.323 unterstützt RFC2833 ab V4

- Cisco IOS kündigt seine 2833-Unterstützung immer im TCS an

- CUCM unterstützt NTE nur über einen H.323-Intercluster-Trunk.

Proprietäres Cisco RTP

Bei dieser Methode werden DTMF-Töne im gleichen RTP-Kanal wie Sprachdaten gesendet. Die DTMF-Töne werden jedoch anders als die Sprachmuster codiert und als Nutzlasttyp 121 identifiziert, sodass der Empfänger sie als DTMF-Töne identifizieren kann. Diese Methode wird von CUCM nicht unterstützt und wird nicht mehr verwendet.

Unterstützte DTMF-Relay-Methoden für SIP

NTE - RFC2833

In-Band-RFC2833-NTE-Nutzlasttypen und -Attribute werden zwischen den beiden Enden beim Verbindungsaufbau ausgehandelt, die das Session Description Protocol (SDP) im Hauptabschnitt der SIP-Nachricht verwenden.

Unsolicited NOTIFY (UN)

Bei diesem Verfahren werden die Ziffern OOB als SIP NOTIFY-Nachrichten innerhalb der Nutzlast des Nachrichtentexts gesendet.

Key Press Markup Language (KPML)

Basierend auf RFC4730 werden Ziffern OOB mithilfe von XML innerhalb von Subscribe-/NOTIFY-Nachrichten übertragen. Sie wird hauptsächlich für SIP-Endpunkte verwendet, die für CUCM oder CME registriert sind, aber auch für ITSPs.

Information (INFO)

Ziffern werden zwischen den Enden als OOB-SIP-INFO-Nachrichten weitergeleitet. Für diese Methode ist keine Konfiguration erforderlich. Sie wird von CUBE automatisch akzeptiert und in Beziehung gesetzt.

Hinweis: SIP INFO wird von Unified CM nicht unterstützt.

Hinweis: Wenn sowohl die UN- als auch die NTE-Methode verhandelt werden, wählt Cisco IOS immer "UN over NTE" aus, um Doppeltöne zu vermeiden, und das In-Band-2833-NTE-Paket wird unterdrückt. Außerdem wird UN für CUCM nur verwendet, wenn keine andere Option verfügbar ist. Wenn sowohl KPML als auch UN vorhanden sind, wählt der Cisco Call Manager (CCM) KPML anstelle von UN.

Konfigurieren von DTMF-Relay auf CUBE

Standardmäßig ist die DTMF-Weiterleitung sowohl für H323- als auch für SIP-Dial-Peers deaktiviert (mit Ausnahme von SIP INFO). Die DTMF-Weiterleitungsmethode muss so konfiguriert werden, dass sie End-to-End für eingehende und ausgehende Dial-Peers für jeden Anrufabschnitt verwendet wird.

DTMF-Relay für H323 konfigurieren

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

Je nach den Anforderungen der Terminierungsenden können Sie mehr als eine Methode pro Dial-Peer konfigurieren.

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 für SIP konfigurieren

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

Je nach den Anforderungen der Terminierungsenden können Sie mehr als eine Methode pro Dial-Peer konfigurieren.

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

Hinweis: Fügen Sie den Befehl session protocol sip unter dem Dial-Peer hinzu, damit die SIP-dtmf-relay-Optionen verfügbar sind.

DTMF-Relay-Ziffernlöschung konfigurieren

Um doppelte Ziffern zu vermeiden, indem dieselben DTMF-Ziffern über In-Band- und Out-of-Band-Methoden an den ausgehenden Abschnitt für Anrufe weitergeleitet werden, die von einem In-Band-Verfahren (insbesondere RTP-NTE) zu einem Out-of-Band-Verfahren interagieren, konfigurieren Sie den Befehl dtmf-relay rtp-nte digit-drop auf dem eingehenden Dial-Peer und das gewünschte Out-of-of-Band-Verfahren auf dem ausgehender Dial-Peer Andernfalls wird dieselbe Ziffer sowohl im OOB als auch im Inband gesendet und vom empfangenden Ende als doppelte Ziffer interpretiert.

Wenn die Option "Digit-Drop" für den eingehenden Abschnitt konfiguriert ist, unterdrückt CUBE NTE-Pakete und nur Relay-Ziffern, die die für den ausgehenden Abschnitt konfigurierte OOB-Methode verwenden.

Wie in diesem Bild gezeigt, steht die Option "Digit-Drop" nur zur Verfügung, wenn diese DTMF-Weiterleitungsmethoden zusammenarbeiten.

Konfigurieren Sie beispielsweise den Befehl dtmf-relay rtp-nte digit-drop auf dem eingehenden Dial-Peer für eine SIP-Verbindung, die Ziffern über RFC2833 sendet, und konfigurieren Sie dann auf der Seite für ausgehende H.323 entweder dtmf-relay h245-alphanumerisch oder dtmf-relay h2 45-Signal; dies muss dazu führen, dass CUBE die NTE-Pakete unterdrückt und stattdessen nur die OOB H245-Ereignisse sendet.

Weitere Informationen finden Sie unter DTMF Relay Digit Drop.

DTMF-Relay validieren und Fehlerbehebung durchführen

OOB-DTMF-Relay für H323 validieren

Alphanumerische H.245-Funktionsanzeige

Um zu überprüfen, ob ein Endpunkt die alphanumerische H.245-Funktion ankündigt, suchen Sie diese Zeile in der H.245 Terminal Capability Set (TCS)-Nachricht unter Verwendung von debug h245 asn1.

capability receiveUserInputCapability : basicString : NULL

Beispiel für alphanumerische Übertragung in H.245

Hier ist ein Beispiel für einen Endpunkt, der die Ziffer 1 mithilfe der alphanumerischen H245-Methode mit debug h245 asn1 überträgt.

000510: Sep 28 19:02:02.716: H245 MSC OUTGOING PDU ::=

value MultimediaSystemControlMessage ::= indication : userInput : alphanumeric : "1“

H.245 Signalfähigkeitsanzeige

Um zu überprüfen, ob ein Endpunkt H.245-Signalfähigkeit ankündigt, suchen Sie in der H.245 Terminal Capability Set (TCS)-Meldung, die debug h245 asn1 verwendet, nach dieser Zeile.

capability receiveUserInputCapability : dtmf : NULL

Beispiel für H.245-Signalübertragung

Dies ist ein Beispiel für einen Endpunkt, der die Ziffer 1 mit einer Dauer von 100 ms nach dem H245-Signalverfahren überträgt. Es gibt zwei Nachrichten. Die erste Nachricht gibt die gewählte Ziffer mit einer Dauer von vier Sekunden an. Das zweite Signal (signalUpdate) aktualisiert jedoch den Wert für die Zifferndauer auf 100 ms.

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

}

In-Band-DTMF-Relay für H323 bestätigen

Endpunkte mit H.323 V5 können angeben, dass sie RFC2833 über eine Funktionsmeldung in der TerminalCapabilitySet (TCS)-Meldung unterstützen.

RFC2833 - Ankündigung zur Unterstützung von Funktionen

Um zu überprüfen, ob ein Endpunkt RFC2833-Funktionalität ankündigt, suchen Sie in der H.245-TCS-Nachricht nach dieser Struktur, die debug h245 asn1 verwendet (im Beispiel wird für die Ereignisse von 0 bis 16 der Payload-Typ 101 angekündigt).

capabilityTableEntryNumber 34

capability receiveRTPAudioTelephonyEventCapability :

{

dynamicRTPPayloadType 101

audioTelephoneEvent "0-16"

}

Validierung des OOB-DTMF-Relays für SIP

Beispiel für unsolicited NOTIFY (UN)-Werbung

Um zu überprüfen, ob ein Endpunkt die UNO-Funktion (Unsolicited NOTIFY) ankündigt, suchen Sie in der INVITE-Nachricht nach dieser Zeile und/oder in den INVITE-Antwortnachrichten mithilfe von Debug-CSIP-Nachrichten.

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“

Übertragungsbeispiel für Unsolicited NOTIFY (UN)

Die UN-Methode überträgt die Ziffern als Binärdaten innerhalb der NTFY-Nachricht. Sie können daher nicht sehen, welche Ziffern mithilfe von Debug-CSCIP-Nachrichten übertragen werden. Sie können entweder eine Paketerfassung (PCAP) benötigen oder den Befehl debug ccsip all ausführen, um die Ziffer in den Binärdatenausgaben anzuzeigen.

Beispiel dafür, wie dieselbe Ziffer 7 wie beim Ausführen des Befehls debug ccsip all aussehen würde.

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) AWerbebeispiel

Die KPML-Funktion wird im Allow-Events-SIP-Header aufgeführt. Bei KPML-Ziffernübertragungen muss der sendende Endpunkt zuerst ein Abonnement an den KPML-Dienst senden; es wird eine SUBSCRIBE-Nachricht mit der Anforderung der Funktion gesendet; anschließend wird eine NOTIFY-Nachricht vom empfangenden Ende gesendet, die den Abonnementstatus für die KPML-Ereignisse als aktiv markiert.

Anfängliche INVITE-Ankündigung der Funktion.

INVITE sip:95554445001@192.168.105.25:5060 SIP/2.0

Allow-Events: kpml, telephone-event

Das Abonnement für die KMPL-Ereignisse, das das Beenden von Endanforderungen erfordert.

SUBSCRIBE sip:2010@192.168.106.50:5060 SIP/2.0

Event: kpml

Content-Type: application/kpml-request+xml

Das ursprüngliche Ende antwortet mit einer NOTIFY-Einstellung, mit der der Status aktiviert wird.

NOTIFY  sip:192.168.105.25:5060 SIP/2.0

Event: kpml

Subscription-State: active

KPML TÜbertragungsbeispiel

Nach Abschluss des Abonnements können die Endpunkte die Ziffern mithilfe von NOTIFY-Nachrichten mit KPML-Ereignissen über XML übertragen. Beispiel für die übertragene Ziffer 1.

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

CUBE unterstützt etwa 30 verschiedene Arten von DTMF-Interworking. Er kann zwischen verschiedenen Relay-Methoden interagieren und transkodieren, basierend auf dem dtmf-relay-Befehl, der innerhalb der entsprechenden Dial-Peers für ein- und ausgehende Anrufe konfiguriert wurde.

Weitere Informationen zur Unterstützung des DTMF-Interworking finden Sie in der Interoperabilitätstabelle des CUBE-Konfigurationsleitfadens.

Wann sind für CUBE Transkodierungsressourcen für DTMF erforderlich?

CUBE erfordert lokal registrierte Transkodierungsressourcen in diesen Szenarien.

- Interworking zwischen RFC2833 und Voice In-Band

- Kompatibilität zwischen einer OOB-Methode und RFC2833 für Flow-around-Anrufe

CUBE ist in der Lage, ohne Transcoder mit allen anderen DTMF-Weiterleitungsmethoden mit Flow-Through-Anrufen zusammenzuarbeiten.

DTMF-Interworking zwischen In-Band G711 und RFC2833

CUBE kann Inband G711 DTMF (Raw-Audio-Töne) mit RFC 2833 interagieren. Diese Anforderungen müssen jedoch erfüllt werden

- Als Codec muss G711 End-to-End verwendet werden. Dies ist eine Einschränkung, da die Töne bei Verwendung eines LBR-Codecs aufgrund des Komprimierungsverlusts verzerrt würden.

- Die Umkodierungsressourcen müssen entsprechend verfügbar und beim CUBE registriert sein. Dies liegt daran, dass CUBE eine Transkodierungsressource (genauer: eine DSP-Ressource) dem RTP-Medien-Stream zuweisen muss, um Töne in den Audio-Stream einzufügen oder abzuhören.

- Auf dem Dial-Peer für die In-Band-Töne-Komponente darf kein DTMF-Relay-Befehl konfiguriert sein. Diese Anforderung wird für IOS XE 16.12.x oder höher nicht mehr benötigt. CUBE kann einen Transcoder dynamisch zuweisen, selbst wenn für den eingehenden/ITSP-Dial-Peer "dtmf-relay rtp-nte" konfiguriert ist. Die Entscheidung für die Zuweisung eines Transcoders kann von der SDP-Aushandlung zwischen den Peer-Geräten abhängen.

- Für den Dial-Peer für die RFC2833-Komponente muss "dtmf-relay rtp-nte" konfiguriert sein.

- Aktivieren Sie das Verwerfen von Ziffern auf keinen der DFÜ-Peers, die an dem Anruf beteiligt sind.

Weitere DTMF-Interworking-Optionen

Für bestimmte Anrufszenarien können zusätzliche Interworking-Befehle erforderlich sein, die entweder global oder auf Dial-Peer-Ebene konfiguriert werden können.

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.

Wann werden vom CUCM MTP-Ressourcen benötigt?

Eine MTP-Ressource ist erforderlich, wenn der CUCM verschiedene DTMF-Methoden zwischen zwei Geräten zusammenarbeiten muss, von denen eines speziell das RFC 2833-Verfahren und das andere ein OOB-Verfahren verwendet. In diesem Szenario muss der CUCM die erforderlichen Ressourcen zum Senden und/oder Erkennen der In-Band-Töne aufgrund der DTMF-Relay-Diskrepanz zwischen den beiden Enden zuweisen.

Die Rolle des MTP besteht darin, den RTP-Verkehr zu überwachen und NTE-Ereignisse vom RFC2833-Abschnitt zu erkennen oder die NTE-Ereignisse in den RTP-Stream zu injizieren, wenn der CUCM dies verlangt. Wenn das MTP eingehende NTE-Ereignisse vom Endpunkt erkennt, der nur RFC2833 unterstützt, sendet es eine SCCP-StationNOTIFYDtmfToneMessage an den CUCM und informiert diesen über den im Stream erkannten Ton. Der CUCM sendet wiederum dieselbe Ziffer und verwendet das Signalisierungsprotokoll (OOB) am anderen Ende. Wenn der CUCM ein OOB-DTMF-Signal vom OOB-DTMF-Endpunkt empfängt, sendet er eine SCCP-StationSendDtmfToneMessage an den MTP, damit dieser den angeforderten Ton in Form von NTE-Ereignissen in den RTP-Stream einspeisen kann.

Von CUCM unterstützte MTP-Geräte

Software-MTP (Cisco IP Voice Media Streaming-Anwendung)

Software-MTP wird implementiert, indem die Cisco IP Voice Media Streaming-Anwendung auf einem CUCM-Server aktiviert wird. Wenn die installierte Anwendung als MTP-Anwendung konfiguriert ist, registriert sie sich bei einem CUCM-Knoten und teilt dem CUCM mit, wie viele MTP-Ressourcen sie unterstützt. Ein Software-MTP-Gerät unterstützt nur G.711-Streams. Mit den Standardeinstellungen von CUCM können bis zu 48 Anrufe pro MTP-Software verarbeitet werden. Weitere Informationen zum Ändern der Service-Parameter finden Sie in der entsprechenden Version des Cisco Unified Communications Manager Administration Guide.

Software-MTP (basierend auf Cisco IOS)

Dieser MTP ermöglicht die Konfiguration eines dieser Codecs. Es kann jedoch jeweils nur ein Codec konfiguriert werden: G.711 mu-law und a-law, G.729a, G.729, G.729ab, G.729b und Passthrough. Einige dieser Aspekte sind für eine CUCM-Implementierung nicht relevant.

Routerkonfigurationen ermöglichen bis zu 1.000 einzelne Streams, die 500 transkodierte Sitzungen unterstützen, die 10 MB Datenverkehr generieren. Die Cisco ISR G2- und ASR-Router können deutlich mehr unterstützen.

Der Betrieb dieses MTP nimmt CPU-Zyklen in Anspruch. Notieren Sie sich die Anzahl der aktivierten Sitzungen, da diese die CPU-Leistung beeinträchtigen und eine hohe CPU-Auslastung auslösen können.

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

Diese Hardware verwendet die PVDM-2-Module zur Bereitstellung von DSPs.

Hardware-MTP (Cisco Router der Serien 2900 und 3900 mit PVDM3)

Diese Router verwenden die PVDM3 DSPs nativ auf den Motherboards oder PVDM2 mit einem Adapter auf dem Motherboard oder auf Servicemodulen.

Hinweis: Sie können G.729 oder G.729b nicht konfigurieren, wenn Sie Hardware-MTP-Ressourcen in Cisco IOS konfigurieren. Unified CM kann jedoch Hardware-Umkodierungsressourcen als MTPs verwenden, wenn alle anderen MTP-Ressourcen erschöpft sind oder anderweitig nicht verfügbar sind.

Verwendung von MTP-Software oder -Hardware

Der in Ihrem Netzwerk bereitzustellende MTP-Typ hängt von bestimmten Codec-Parametern ab, die von den Endpunkten, Gateways und Trunks im Anruffluss unterstützt werden

- Die zu verwendenden Codec-Varianten

- Die zu verwendende Codec-Paketgröße (Packetisierung)

- T.38-Faxnutzung (erfordert Codec-Passthrough-Unterstützung)

Basierend auf diesen Parametern können Sie die für Ihr Netzwerk erforderlichen Ressourcen sicher auswählen und bereitstellen.

Wie in der Tabelle dargestellt, werden die verschiedenen Funktionen, die von verschiedenen MTP- und Transcoder-Typen unterstützt werden,

Typ

Selbe Codecs

Unterschiedliche Codecs

Unterschiedliche Packetisierung

Codec

Pass-Through

Hinweise

CUCM-SW-MTP

Ja

Nein

Ja

Nein

G711 Alaw-Ulaw-Transkodierung und -Neupaketisierung

Cisco IOS HW-MTP

Ja

Nein

Nein

Ja

Unterstützung für jeden Codec (und dieselbe Variante), solange dieselbe Paketisierung verwendet wird. Keine Umkodierung.

Cisco IOS SW MTP

Ja

Nein

Nein

Ja

Unterstützung beliebiger Codecs (und gleicher Aroma), solange dieselbe Paketisierung verwendet wird. Keine Umkodierung.

Cisco IOS - regulärer Xcoder

Ja

Ja

Ja

Ja

Solange mindestens eine Seite G711u/G711a ist, unterstützt es jegliche Neupaketisierung und Transkodierung.

Cisco IOS Universal-Xcoder

Ja

Ja

Ja

Ja

Unterstützung für jeden Codec, Paketisierung und Transkodierung.

Weitere Informationen zur MTP-Konfiguration in CUCM finden Sie im Beispiel zur Konfiguration eines Medienanschlusspunkts.

Überlegungen zur CUCM-Medienressourcengruppe (MRG) und zur Medienressourcengruppen-Liste (MRGL) für MTP

Beim Erstellen und Zuweisen von Medienressourcen zu Medienressourcengruppen (MRG) und Medienressourcengruppen-Listen (MRGL) sollten Sie einige zusätzliche Punkte berücksichtigen, um eine Überbelegung der besten Ressourcen für bestimmte Anrufverläufe zu vermeiden und diese entsprechend zu priorisieren. Der CUCM kann bei der Auswahl einer Medienressource für einen Anruf aus einer bestimmten Liste von MTPs und Transcodern, die dieselbe Priorität oder Reihenfolge haben, nicht das beste Gerät für die Verwendung auswählen. Stattdessen wird das erste Gerät ausgewählt, das die angeforderten Funktionen unterstützt. Selbst wenn der Anruf G711 auf beiden Beinen verwendet und das erste gefundene Gerät ein Transcoder ist, ordnet es diesen als MTP für den Anruf zu und sucht nicht weiter unten in der Liste nach einer MTP-Ressource.

Ein weiteres ähnliches Verhalten tritt auf, wenn Sie sowohl universelle als auch regelmäßige Transcoder haben. Der CUCM kann die regulären Transcoder zuerst bei einem Anruf verwenden, bei dem einer der beiden Verbindungspunkte G711 war, und dann fehlschlagen, wenn ein Anruf an ein Ziel weitergeleitet wird, das einen anderen Codec als G711 verwendet, da der CUCM den aktuellen Transcoder nicht freigibt und einen weiteren erhält, wenn der Anruf weitergeleitet wird.

Die beste Designpraxis, um dieses Verhalten zu umgehen, besteht darin, alle MTP-Geräte in einer einzigen MRG zuzuweisen, dann die universellen Transcoder zu einer anderen MRG und die regulären Transcoder zu einer dritten MRG und sie dann in derselben Reihenfolge innerhalb der MRGL zu priorisieren. Nun kann dieses Design nicht für jede Topologie verwendet werden und muss von Fall zu Fall überprüft werden.

SCCP-MTP-Nachrichten

Diese SCCP-Nachrichten werden zwischen den CUCM- und MTP-Ressourcen zur DTMF-Verarbeitung ausgetauscht.

- StationFunktionenRe

- StationUpdateFunktionen

- StationAbonnierenDtmfPayloadReq

- StationAbonnierenDTMFPayloadErrv

- StationAbonnierenDtmfPayloadRes

- StationAbbestellenDtmfPayloadErr

- StationNOTIFYDtmfTonmeldung

- StationDtmfTonMeldung

- StationAbbestellenDtmfPayloadReq

- StationAbbestellenDtmfPayloadRes

DTMF-Relay zwischen CUCM und CUBE

CUCM-SIP-Trunk zu CUBE

CUBE unterstützt je nach Konfiguration KPML, NTE oder Unsolicited Notify als DTMF-Mechanismus. Da das System aus mehreren Endpunkten besteht, können auf dem CUBE mehrere Methoden gleichzeitig konfiguriert werden, um die MTP-Anforderungen zu minimieren.

Konfigurieren Sie auf CUBE sowohl sip-kpml als auch rtp-nte als DTMF-Weiterleitungsmethoden unter SIP-Dial-Peers. Diese Konfiguration ermöglicht den DTMF-Austausch mit allen Endgerätetypen, einschließlich Endgeräten, die nur NTE und OOB-Methoden unterstützen, ohne dass MTP-Ressourcen erforderlich sind. Bei dieser Konfiguration handelt das Gateway NTE und KPML mit CUCM aus. Wenn NTE vom Unified CM-Endpunkt nicht unterstützt wird, wird KPML für den DTMF-Austausch verwendet. Wenn beide Methoden erfolgreich verhandelt wurden, benötigt das Gateway NTE zum Empfangen von Ziffern und abonniert KPML nicht.

CUBE kann auch die Unsolicited Notify (UN)-Methode für DTMF verwenden. Die UN-Methode sendet eine SIP Notify-Nachricht mit einem Text, der den DTMF-Ton beschreibt. Diese Methode wird auch auf Unified CM unterstützt und kann verwendet werden, wenn sip-kpml nicht verfügbar ist. Konfigurieren Sie sip-notify als DTMF-Weiterleitungsmethode. Beachten Sie, dass diese Methode von Cisco stammt.

CUBEs, die nur für NTE-Relays konfiguriert sind oder die aufgrund einer Interworking-Beschränkung nur NTE- und erforderliche MTP-Ressourcen bereitstellen können, die auf der CUCM-Seite zugewiesen werden, wenn mit Endpunkten kommuniziert wird, die NTE nicht unterstützen.

Weitere Informationen zu den MTP-Anforderungen des CUCM-SIP-Trunks

CUCM H323-Trunk zu CUBE

Der CUCM wählt die DTMF-Transportmethode für H323-Trunks dynamisch aus. Es gibt daher keine konfigurierbaren Optionen, um eine Option der anderen auszuwählen. Wenn Sie eine bestimmte DTMF-Weiterleitungsmethode erzwingen möchten, können Sie dies über die CUBE-Dial-Peer-Konfiguration für diesen Trunk tun.

Auch wenn H323-CUBEs NTE unterstützen, darf die NTE-Option nicht verwendet werden, da sie derzeit auf CUCM für H.323-Gateways/Trunks nicht unterstützt wird. Daher kündigt CUCM diese Funktion beim Austausch von H245-Medienfunktionen nicht an. Die bevorzugte Option des CUCM ist H.245 Signal.

MTP-Ressourcen sind erforderlich, um Anrufe an ein H.323-CUBE herzustellen, wenn der andere Endpunkt keine mit dem CUCM gemeinsame Signalisierungsfunktion hat. Beispielsweise unterstützt ein Cisco Unified IP-Telefon 7960, das den SIP-Stack ausführt, nur NTEs, sodass ein MTP mit einem H.323-Trunk erforderlich ist, damit auf der H323-Strecke ein alphanumerisches H245 verwendet werden kann.

Dynamische/Asymmetrische CUBE-Payloads

Ab Cisco IOS-Version 15.1(1)T (CUBE 1.4) wird Unterstützung für Dynamic Payload Type Interworking für DTMF- und Codec-Pakete für SIP-SIP-Anrufe eingeführt.

Diese Funktion ermöglicht dem CUBE die Verarbeitung folgender Interworking-Arten: dynamische Payload-Typen für Audio-/Video-Codecs, NSE und DTMF; diese waren bisher begrenzt, da das Cisco IOS einen statischen Bereich reservieren und nur die Aushandlung derselben Payload-Typen auf beiden Anrufabschnitten zulassen würde und den Anruf mit einer 488-Fehlerantwort wegen nicht übereinstimmender Audio-/Video-/NSE-Codecs (oder Fallback auf Sprach-In-Band G778) ablehnen würde 11 DTMF) bei nicht übereinstimmenden NTE-Payloads unterstützt. Daher ermöglicht die Funktion dem CUBE, die Reservierung oder Freigabe von Payload-Typen dynamisch für die Interaktion mit SIP-Anbietern oder Drittanbietergeräten aufzuheben, die einen anderen Payload-Typ-Bereich verwenden, der diese nicht unterstützt oder eine andere Zuordnung erfordert.

Eine Anrufstrecke in CUBE gilt als symmetrisch oder asymmetrisch, basierend auf dem Wert des Payload-Typs, der während des Angebots- und Antwortvorgangs mit dem Endpunkt über SDP ausgetauscht wird.

- Ein symmetrischer Endpunkt akzeptiert und sendet den gleichen Payload-Typ für NTE-Ereignisse oder einen bestimmten Codec für eine Anrufstrecke.

- Ein asymmetrischer Endpunkt kann verschiedene Payload-Typen für NTE-Ereignisse oder einen bestimmten Codec für einen Anrufabschnitt annehmen und senden.

Mit diesem Befehl kann die Verwendung asymmetrischer Payloads angegeben werden. Der Befehl kann global unter dem Sprachdienst voip enter sip config mode oder auf DFÜ-Peer-Ebene mit der Sprachklasse sip CLI angewendet werden.

asymmetric payload {dtmf | dynamic-codecs | full | system}

Weitere Informationen zu dynamischen/asymmetrischen Payloads finden Sie unter Dynamisches Payload-Typ-Interworking für DTMF- und Codec-Pakete für SIP-SIP-Anrufe.

Beispiel für symmetrische Payloads

Im Folgenden finden Sie ein Beispiel dafür, wie das SDP für eine symmetrische Payload-Aushandlung und die Ausgabe der Debug-VoIP-RTP-Sitzung mit dem Namen event aussehen würde, während DTMF-Töne übertragen werden. Beachten Sie, dass die Konfiguration, die das Cisco IOS erzwingt, einen anderen Payload-Typ für NTE-Ereignisse verwenden kann, die den Befehl rtp payload-type nte verwenden.

DTMF-Relayverhandlung

DTMF-Relayübertragung

Beispiel für asymmetrische Payloads

Das folgende Beispiel zeigt, wie das SDP für eine asymmetrische Payload-Aushandlung und die Ausgabe des Befehls debug voip rtp session mit dem Namen event aussehen würde, während DTMF-Töne übertragen werden. Beachten Sie die Konfiguration, die verwendet wird, um zu erzwingen, dass das Cisco IOS einen anderen Payload-Typ für NTE-Ereignisse verwendet, und verwendet die rtp payload-type-Befehle und die Sprachklasse sip asymmetric payload dtmf CLI.

DTMF-Relayverhandlung

DTMF-Relayübertragung

Welche DTMF-Relaymethode verwendet werden soll

Wenn Sie das zu verwendende DTMF-Relay auswählen, müssen Sie diese Variablen berücksichtigen.

- Betroffene Geräte und Plattformen

- involvierte VoIP-Protokolle

- Medienpfad und unterstützte Codecs.

- Unterstützte oder bevorzugte DTMF-Weiterleitungsmethoden.

Bevorzugte DTMF-Relay-Methoden für H.323

Die bevorzugte Methode für H323 wäre die Verwendung von OOB bis H.245 alphanumerisch oder signal in fast allen Szenarien. Sie können RFC2833 auch verwenden, solange CUCM nicht beteiligt ist.

Bevorzugte DTMF-Relay-Methoden für SIP

- SIP-Trunks zu Service Providern - wann immer ein SIP-Trunk zu einem SIP-Provider vorhanden ist oder eine Interaktion mit 3Rot SIP-Geräte oder IVR-Systeme von Drittanbietern sowie In-Band bis RFC2833 bevorzugt.

- SIP-Trunk zu CUCM oder CME - Aktivieren Sie RFC2833 und KPML.

- SIP-Trunk zu CUE - die Standardmethode für CUE ist UN, Sie können sie jedoch auch für die Verwendung von NTE konfigurieren. Dies ist auch die beste Option, wenn der Anruf von einem SIP-Anbieter an das CUE-System geht.

Zugehörige Informationen

Universelle Sprachumkodierungsunterstützung für IP-to-IP Gateways

DTMF-Umwandlung

Konfigurationsbeispiel für die Unified Border Element-Umkodierung

Verwenden von Cisco Unified Communications Manager zum Konfigurieren des Umkodierungs- und Medienanschlusspunkts

Konfigurieren des DTMF-Relay-Digit-Drop auf einem Cisco Unified Border-Element

SIP-Trunk - MTP-Anforderungen

SIP-INFO-Verfahren zur DTMF-Tonerzeugung

H.323-Trunks mit Media Termination Points

CUBE 9.0 Local Transcoding Interface (LTI)