DTMF-Relay auf CUBE konfigurieren
Inhalt
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.
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.
DTMF-Relay auf CUBE konfigurieren
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 die eingehenden und ausgehenden 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
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: 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.
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
Konfigurationsbeispiel für die Unified Border Element-Umkodierung
Konfigurieren des DTMF-Relay-Digit-Drop auf einem Cisco Unified Border-Element
SIP-INFO-Verfahren zur DTMF-Tonerzeugung
Revisionsverlauf
| Überarbeitung | Veröffentlichungsdatum | Kommentare |
|---|---|---|
2.0 |
15-May-2023 |
Alt-Text und Hintergrundinformationen hinzugefügt.
Aktualisierte Einführung, Branding-Anforderungen, SEO, maschinelle Übersetzung, Stilanforderungen, Grundlagen und Formatierung |
1.0 |
30-Mar-2016 |
Erstveröffentlichung |
FeedbackCisco kontaktieren
- Eine Supportanfrage öffnen
- (Erfordert einen Cisco Servicevertrag)