Configuration du relais DTMF sur CUBE
Table des matières
Introduction
Ce document décrit le processus de configuration du relais DTMF (Dual-Tone Multi-Frequency) pour Cisco Unified Border Element (CUBE) Enterprise.
Conditions préalables
Exigences
Cisco vous recommande de prendre connaissance des rubriques suivantes .
- Connaissance de base des tonalités DTMF
- Connaissances de base sur la configuration et l'utilisation de la voix Cisco® IOS (par exemple, terminaux de numérotation dial-peer)
- Connaissances de base sur la configuration et l'utilisation de CUBE
- Connaissance de base de la signalisation utilisée par les protocoles SIP et H323
- Connaissances de base sur le débogage des protocoles VoIP tels que H323 et SIP
Composants utilisés
Les informations dans ce document sont basées sur les versions de logiciel et matériel suivantes :
- Cisco Unified Border Element qui s'exécute sur Cisco IOS.
- Cisco Unified Communications Manager 7.x ou version ultérieure.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.
Conventions
Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.
Informations générales
Ce document fournit également des informations et des commandes sur la façon de configurer, vérifier et dépanner le relais DTMF pour les différents protocoles de passerelle VoIP pris en charge par CUBE.
Méthodes DTMF-Relay prises en charge pour CUBE
CUBE prend en charge une grande variété de méthodes de relais DTMF pour les protocoles de signalisation intra-bande et hors bande (OOB) pour les protocoles H.323 et Session Initiation Protocol (SIP).
Méthodes de relais DTMF intrabande prises en charge
- DTMF audio intrabande via G711
- RFC2833
Méthodes de relais DMTF hors bande prises en charge
- Alphanumérique H.245
- Signal H.245
- SIP Unsolicited NOTIFY
- KPML SIP
- INFOS SIP
Prise en charge de la DTMF audio intrabande via G711
L'audio intrabande vocal ou DTMF G711 désigne le transport de tonalités audibles sur le flux audio vocal, sans aucune intervention supplémentaire du protocole de signalisation ou du DSP pour leur transmission autre que pour établir l'appel normalement et passer l'audio de bout en bout et utiliser le codec G711Ulaw/Alaw. Cela signifie que le CUBE/Cisco IOS transmet uniquement le son des tonalités qui viennent d'une extrémité à l'autre comme s'il s'agissait d'un son vocal normal. La mesure importante à prendre pour cette méthode est de s'assurer que les appels sont établis et qu'ils utilisent le codec G711Ulaw/Alaw, précisément parce que l'utilisation d'un codec qui comprime l'audio (tout autre codec que G711) déforme les tonalités DTMF et risque de les rendre méconnaissables à l'extrémité de réception. En effet, l'algorithme de compression utilisé par les codecs à compression élevée a été conçu pour reconnaître et prévoir la voix humaine et non les tonalités DTMF.
Le DTMF audio intrabande/G711 est pris en charge avec tout protocole de signalisation VoIP et nécessite uniquement l'application du codec G711 pour les appels de bout en bout. Il faut également garder à l'esprit que tout traitement de transcodage d'un codec à faible débit binaire (LBR) vers G711 déforme très probablement les tons aussi bien.
Méthodes de relais DTMF prises en charge pour H323
Alphanumérique H.245
Les chiffres DTMF sont séparés du flux vocal et envoyés via le canal de signalisation H.245 OOB au lieu d'être envoyés via le canal RTP. Les tonalités sont transportées dans des messages H.245 User Input Indication. Le canal de signalisation H.245 est un canal fiable et les paquets qui transportent les tonalités DTMF sont garantis pour être livrés. Tous les systèmes compatibles H.323 version 2 doivent prendre en charge la commande alphanumérique dtmf-relay h245. Cependant, la prise en charge de la commande dtmf-relay h245-signal est facultative.
Signal H.245
La méthode OOB, qui est similaire à la méthode alphanumérique H.245, permet le passage des informations de durée de tonalité, ce qui permet de résoudre un problème potentiel avec la méthode alphanumérique lors de l'interfonctionnement avec les systèmes d'autres fournisseurs.
Événements de téléphonie nommés (NTE) - RFC2833
Cette méthode transporte les tonalités DTMF dans des paquets RTP distincts conformément à la section 3 de la RFC 2833. Le document RFC 2833 définit les formats des paquets RTP NTE utilisés pour transporter les chiffres DTMF, le hook flash et d'autres événements de téléphonie entre deux points d'extrémité homologues. Avec la méthode NTE, les points d'extrémité effectuent une négociation par appel des paramètres de relais DTMF afin de déterminer la valeur du type de données utiles pour les paquets NTE RTP et les événements numériques NTE pris en charge. En conséquence, les tonalités DTMF sont communiquées via des paquets RTP avec une valeur de type de données utiles différente des valeurs négociées pour d'autres paquets de support ; ce qui fournit une méthode fiable pour transporter les chiffres et éviter qu'ils ne soient pas reconnus lorsqu'ils sont compressés via le codec utilisé pour coder le trafic voix, vidéo ou fax.
Le relais DTMF RFC2833/NTE est considéré comme une méthode intrabande car les chiffres sont transportés au sein du trafic audio RTP lui-même sans aucune implication du protocole de signalisation GW.
Il est important de souligner que la méthode RFC2833/NTE ne doit pas être confondue avec le flux audio intra-bande vocal ou G711 RTP, car ce dernier n'est que les tonalités audibles qui sont transmises comme audio normal sans qu'aucune méthode de signalisation de relais ne soit informée ou impliquée dans le processus. Cela signifie qu'il ne s'agit que de tonalités audio simples transmises de bout en bout à l'aide du codec G711Ulaw/Alaw.
Quelques autres faits sur NTE avec H323 :
- H.323 prend en charge RFC2833 à partir de V4
- Cisco IOS annonce toujours sa prise en charge du 2833 dans TCS
- CUCM prend uniquement en charge NTE via un ICT H.323.
RTP propriétaire Cisco
Avec cette méthode, les tonalités DTMF sont envoyées dans le même canal RTP que les données vocales. Cependant, les tonalités DTMF sont codées différemment des échantillons vocaux, et sont identifiées en tant que type de charge utile 121, ce qui permet au récepteur de les identifier en tant que tonalités DTMF. Cette méthode n'est pas prise en charge par CUCM et son utilisation a été arrêtée.
Méthodes DTMF-Relay prises en charge pour SIP
NTE - RFC2833
Les types et attributs de charge utile NTE RFC2833 intrabande sont négociés entre les deux extrémités lors de l'établissement de l'appel qui utilisent le protocole SDP (Session Description Protocol) dans la section body du message SIP.
NOTIFY non sollicité (ONU)
Avec cette méthode, les chiffres sont envoyés OOB sous forme de messages SIP NOTIFY dans la charge utile du corps du message.
Langage KPML (Key Press Markup Language)
Sur la base de RFC4730, les chiffres sont transportés OOB en utilisant XML dans les messages Subscribe/NOTIFY. Il est principalement utilisé pour les terminaux SIP enregistrés auprès de CUCM ou CME, mais également auprès des ITSP.
Information (INFO)
Les chiffres sont relayés sous forme de messages OOB SIP INFO entre les extrémités. Cette méthode ne nécessite aucune configuration et est acceptée et associée automatiquement par CUBE.
Configuration de DTMF-Relay sur CUBE
Par défaut, le relais DTMF est désactivé pour les terminaux de numérotation dial-peer H323 et SIP (à l'exception de SIP INFO) ; il est obligatoire de configurer la méthode de relais DTMF pour qu'elle soit utilisée de bout en bout sur les terminaux de numérotation dial-peer entrants et sortants pour chaque branche d'appel.
Configuration du relais DTMF pour 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
Vous pouvez configurer plusieurs méthodes par terminal de numérotation dial-peer, en fonction des exigences des extrémités de terminaison.
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
Configuration du relais DTMF pour SIP
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
Vous pouvez configurer plusieurs méthodes par terminal de numérotation dial-peer, en fonction des exigences des extrémités de terminaison.
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
Configuration de la suppression numérique du relais DTMF
Afin d'éviter les chiffres en double en relayant les mêmes chiffres DTMF par les méthodes in-band et out-of-band vers le tronçon sortant pour les appels interagissant d'une méthode in-band (RTP-NTE spécifiquement) vers une méthode out-of-band, configurez la commande dtmf-relay rtp-nte digit-drop sur le terminal de numérotation dial-peer entrant et la méthode out-of-band souhaitée sur le terminal de numérotation dial-peer sortant. Sinon, le même chiffre est envoyé en OOB et en bande et est interprété comme des chiffres en double par l'extrémité de réception.
Lorsque l'option de suppression de chiffres est configurée dans le tronçon entrant, CUBE supprime les paquets NTE et ne relaie que les chiffres qui utilisent la méthode OOB configurée sur le tronçon sortant.
Comme l'illustre cette image, l'option d'extraction de chiffres n'est disponible que lors de l'interfonctionnement entre ces méthodes de relais DTMF.
Par exemple, configurez la commande dtmf-relay rtp-nte digit-drop sur le terminal de numérotation dial-peer entrant pour une branche SIP envoyant des chiffres via RFC2833, puis sur le côté H.323 sortant configurez soit dtmf-relay h245-alphanumérique soit dtmf-relay h245-signal ; cela doit entraîner la suppression par CUBE des paquets NTE et l'envoi seulement des événements H245 OOB à la place.
Pour plus d'informations, consultez DTMF Relay Digit Drop.
Validation et dépannage du relais DTMF
Validation du relais OOB DTMF pour H323
Annonce de capacité alphanumérique H.245
Afin de valider si un point d'extrémité annonce la capacité alphanumérique H.245, recherchez cette ligne dans le message H.245 Terminal Capability Set (TCS) en utilisant debug h245 asn1.
capability receiveUserInputCapability : basicString : NULL
Exemple de transmission alphanumérique H.245
Voici un exemple d'un point d'extrémité transmettant le chiffre 1 à l'aide de la méthode alphanumérique H245 utilisant debug h245 asn1.
000510: Sep 28 19:02:02.716: H245 MSC OUTGOING PDU ::= value MultimediaSystemControlMessage ::= indication : userInput : alphanumeric : "1“
Annonce de capacité de signal H.245
Afin de confirmer si un point d'extrémité annonce la capacité du signal H.245, recherchez cette ligne à l'intérieur du message TCS (Terminal Capability Set) H.245 qui utilise debug h245 asn1.
capability receiveUserInputCapability : dtmf : NULL
Exemple de transmission de signal H.245
Il s’agit d’un exemple de point d’extrémité transmettant le chiffre 1 avec une durée de 100 ms à l’aide de la méthode du signal H245. Il y a deux messages, le premier message indique le chiffre en cours de composition avec une durée de 4s. Cependant, le second signal (signalUpdate) met à jour la valeur de durée du chiffre à 100 ms à la place.
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
}
Confirmer le relais DTMF intrabande pour H323
Les terminaux dotés de la norme H.323 V5 peuvent indiquer qu'ils prennent en charge la norme RFC2833 via un message de capacité dans le message TerminalCapabilitySet (TCS).
Annonce de prise en charge des fonctionnalités RFC2833
Afin de confirmer si un terminal annonce la capacité RFC2833, recherchez cette structure dans le message H.245 TCS qui utilise debug h245 asn1 (dans l'exemple, le type de données utiles 101 est annoncé pour les événements de 0 à 16).
capabilityTableEntryNumber 34
capability receiveRTPAudioTelephonyEventCapability :
{
dynamicRTPPayloadType 101
audioTelephoneEvent "0-16"
}
Valider le relais OOB DTMF pour SIP
Exemple de publicité non sollicitée NOTIFY (UN)
Afin de confirmer si un terminal annonce la fonctionnalité Unsolicited NOTIFY (UN), recherchez cette ligne dans le message INVITE et/ou les messages de réponse à INVITE en utilisant les messages debug ccsip.
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“
Exemple de transmission de notification non sollicitée (UN)
La méthode UN transmet les chiffres sous forme de données binaires à l'intérieur du message NTFY ; vous ne pouvez donc pas voir quel chiffre est transporté à l'aide des messages debug ccsip. Vous pouvez avoir besoin d'une capture de paquet (PCAP) ou avoir à exécuter la commande debug ccsip all pour voir le chiffre dans les sorties de données binaires.
Exemple de la façon dont le même chiffre 7 composé ressemblerait lors de l'exécution de la commande debug ccsip all.
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
Langage KPML (Key Press Markup Language) AExemple de publicité
La fonctionnalité KPML est répertoriée dans l'en-tête SIP Allow-Events. Pour les transmissions de chiffres KPML, le point d'extrémité de transmission doit d'abord envoyer un abonnement au service KPML ; un message SUBSCRIBE demandant la capacité est transmis ; suivi d'un message NOTIFY de l'extrémité de réception marquant l'état d'abonnement pour les événements KPML comme étant actif.
INVITE initiale annonçant la capacité.
INVITE sip:95554445001@192.168.105.25:5060 SIP/2.0 Allow-Events: kpml, telephone-event
La terminaison demande l'abonnement aux événements KMPL.
SUBSCRIBE sip:2010@192.168.106.50:5060 SIP/2.0 Event: kpml Content-Type: application/kpml-request+xml
L'extrémité d'origine répond avec un paramètre NOTIFY définissant l'état sur actif.
NOTIFY sip:192.168.105.25:5060 SIP/2.0 Event: kpml Subscription-State: active
KPML TExemple de transmission
Une fois l'abonnement effectué, les terminaux peuvent transmettre les chiffres à l'aide de messages NOTIFY avec des événements KPML via XML. Exemple de transmission du chiffre 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"/>
Interfonctionnement DTMF
CUBE prend en charge environ 30 types différents d'interfonctionnement DTMF. Il peut interagir et transcoder entre différentes méthodes de relais basées sur la commande dtmf-relay configurée dans les terminaux de numérotation dial-peer entrants et sortants correspondants pour l'appel.
Référez-vous à la section Table d'interopérabilité DTMF du Guide de configuration CUBE pour plus de détails sur la prise en charge de l'interopérabilité DTMF.
Quand CUBE requiert-il des ressources de transcodage pour DTMF ?
CUBE nécessite des ressources de transcodage enregistrées localement dans ces scénarios
- Interfonctionnement entre RFC2833 et voix intra-bande
- Interfonctionnement entre une méthode OOB et RFC2833 pour les appels de contournement
CUBE est capable d'interagir entre toutes les autres méthodes de relais DTMF avec des appels en flux continu sans avoir besoin d'un transcodeur.
Interfonctionnement DTMF entre G711 intrabande et RFC2833
CUBE est capable d'interagir entre les DTMF intrabande G711 (tonalités audio brutes) et RFC2833. Toutefois, ces exigences doivent être respectées
- Le codec utilisé doit être G711 de bout en bout. Il s'agit d'une restriction car si un codec LBR devait être utilisé, les tonalités seraient déformées en raison de la perte de compression.
- Les ressources de transcodage doivent être disponibles et enregistrées auprès du CUBE en conséquence. Cela est dû au fait que le CUBE doit allouer une ressource de transcodage (plus spécifiquement : une ressource DSP) au flux RTP multimédia pour injecter ou écouter des tonalités dans le flux audio.
- Aucune commande de relais DTMF ne doit être configurée sur le terminal de numérotation dial-peer pour le segment des tonalités intrabandes. Cette exigence n'est plus nécessaire pour IOS XE 16.12.x ou version ultérieure. CUBE peut allouer dynamiquement un transcodeur même si le terminal de numérotation dial-peer entrant/ITSP a dtmf-relay rtp-net configuré. La décision d'allouer un transcodeur peut dépendre de la négociation SDP entre les périphériques homologues.
- Le terminal de numérotation dial-peer pour le tronçon RFC2833 doit avoir dtmf-relay rtp-net configuré.
- N'activez pas la suppression des chiffres sur les terminaux de numérotation dial-peer impliqués dans l'appel.
Autres options d'interfonctionnement DTMF
Il existe également un ensemble supplémentaire de commandes d'interfonctionnement qui peuvent être requises sur des scénarios d'appel spécifiques ; ces commandes peuvent être configurées globalement ou au niveau dial-peer.
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.
Quand les ressources MTP sont-elles requises par CUCM ?
La ressource MTP devient nécessaire lorsque CUCM a besoin d'interagir différentes méthodes DTMF entre deux périphériques, l'un d'eux utilisant la méthode RFC2833 spécifiquement et l'autre une méthode OOB. Dans ce scénario, le CUCM doit allouer les ressources nécessaires pour transmettre et/ou détecter les tonalités intrabande en raison d'une non-concordance du relais DTMF entre les deux extrémités.
Le rôle du MTP est de surveiller le trafic RTP et de détecter les événements NTE à partir de la branche RFC2833 ou d'injecter les événements NTE dans le flux RTP si le CUCM le demande. Si le MTP détecte des événements NTE entrants du point d'extrémité qui prennent uniquement en charge RFC2833, il envoie un SCCP StationNOTIFYDtmfToneMessage au CUCM et l'informe de la tonalité qui a été détectée dans le flux. Le CUCM envoie à son tour le même chiffre et utilise le protocole de signalisation (OOB) à l'autre extrémité. Si le CUCM reçoit un signal DTMF OOB du point d'extrémité DTMF OOB, il envoie un StationSendDtmfToneMessage SCCP au MTP afin que ce dernier puisse injecter la tonalité demandée dans le flux RTP sous la forme d'événements NTE.
Périphériques MTP pris en charge par CUCM
Logiciel MTP (Cisco IP Voice Media Streaming Application)
Le MTP logiciel est un périphérique mis en oeuvre en activant l'application Cisco IP Voice Media Streaming sur un serveur CUCM. Lorsque l'application installée est configurée comme application MTP, elle s'enregistre auprès d'un noeud CUCM et informe CUCM du nombre de ressources MTP qu'elle prend en charge. Un périphérique MTP logiciel ne prend en charge que les flux G.711. Les paramètres par défaut de CUCM lui permettent de traiter jusqu'à 48 appels selon le MTP logiciel. Pour plus d'informations sur la façon de modifier les paramètres de service, référez-vous à la version appropriée du Guide d'administration de Cisco Unified Communications Manager.
MTP logiciel (basé sur Cisco IOS)
Ce MTP permet la configuration de n'importe lequel de ces codecs, mais un seul peut être configuré à la fois G.711 mu-law et a-law, G.729a, G.729, G.729ab, G.729b et passthrough. Certaines d'entre elles ne sont pas pertinentes pour une implémentation CUCM.
Les configurations de routeur autorisent jusqu'à 1 000 flux individuels, qui prennent en charge 500 sessions transcodées générant 10 Mo de trafic. Les routeurs Cisco ISR G2 et ASR peuvent prendre en charge des nombres beaucoup plus élevés que ceux-ci.
Ce MTP utilise des cycles CPU pour fonctionner. Notez le nombre de sessions activées, car cela pourrait avoir un impact sur les performances du processeur et déclencher une utilisation élevée du processeur.
Matériel MTP (PVDM2, Cisco NM-HDV2 et NM-HD-1V/2V/2VE)
Ce matériel utilise les modules PVDM-2 pour fournir des DSP.
Matériel MTP (routeurs des gammes Cisco 2900 et 3900 avec PVDM3)
Ces routeurs utilisent les DSP PVDM3 nativement sur les cartes mères ou PVDM2 avec un adaptateur sur la carte mère ou sur les modules de service.
Quand utiliser le MTP logiciel ou matériel
Le type de protocole MTP à déployer sur votre réseau dépend de paramètres de codec spécifiques pris en charge par les terminaux, les passerelles et les liaisons dans le flux d'appels
- Les saveurs du codec à utiliser
- Taille de paquet du codec à utiliser (mise en paquets)
- Utilisation des télécopies T.38 (nécessite la prise en charge de Codec Pass-Through)
Sur la base de ces paramètres, vous pouvez choisir et déployer en toute sécurité les ressources correctes requises par votre réseau.
Comme le montre le tableau, les différentes fonctionnalités sont prises en charge par différents types de MTP et de transcodeur
| Type |
Mêmes codecs |
Différents codecs |
Packetisation différente |
Codec Passthrough |
Remarques |
| CUCM SW MTP |
Oui |
Non |
Oui |
Non |
G711 Alaw-Ulaw transcodage et repaquetage |
| MTP matériel Cisco IOS |
Oui |
Non |
Non |
Oui |
Prise en charge de tout codec (et même saveur) tant que la même mise en paquets. Pas de transcodage. |
| Logiciel Cisco IOS MTP |
Oui |
Non |
Non |
Oui |
Prendre en charge n'importe quel codec (et même saveur) tant que la même mise en paquets. Pas de transcodage. |
| Xcoder régulier Cisco IOS |
Oui |
Oui |
Oui |
Oui |
Tant qu'au moins un côté est G711u/G711a, il prend en charge tout repaquetage et transcodage. |
| Xcoder universel Cisco IOS |
Oui |
Oui |
Oui |
Oui |
Prise en charge de tout codec, paquettisation et transcodage. |
Pour plus d'informations sur la configuration MTP dans CUCM, veuillez vous reporter à l'Exemple de configuration de point de terminaison de support .
Considérations relatives au groupe de ressources multimédias (MRG) et à la liste de groupes de ressources multimédias (MRGL) CUCM pour MTP
Lors de la création et de l'affectation de ressources multimédias à des groupes de ressources multimédias (MRG) et à des listes de groupes de ressources multimédias (MRGL), prenez en compte certains points supplémentaires afin d'éviter un surabonnement aux meilleures ressources pour des flux d'appels spécifiques et de les hiérarchiser en conséquence. CUCM ne peut pas sélectionner le meilleur périphérique à utiliser, lorsqu'il sélectionne une ressource multimédia pour un appel, à partir d'une liste donnée de MTP et de transcodeurs s'ils ont la même priorité ou le même ordre. Au lieu de cela, il choisit le premier périphérique qui prend en charge les fonctionnalités demandées. Ainsi, même si l'appel utilise G711 sur les deux branches, si le premier périphérique qu'il trouve est un transcodeur, il l'alloue en tant que MTP pour l'appel et ne recherche pas de ressource MTP plus loin dans la liste.
Un autre comportement similaire se produit lorsque vous avez à la fois des transcodeurs universels et réguliers. Le CUCM peut utiliser les transcodeurs réguliers d'abord sur un appel où l'un des tronçons était G711, puis échouer lorsqu'un appel est transféré vers une destination qui utilise un codec non G711, parce que le CUCM ne va pas libérer le transcodeur actuel et en obtenir un autre lorsque l'appel est transféré.
La meilleure pratique de conception pour contourner ce comportement est d'attribuer tous les périphériques MTP uniquement dans un MRG unique, puis les transcodeurs universels à un autre MRG et les transcodeurs réguliers à un troisième MRG ; puis de les hiérarchiser dans le même ordre dans le MRGL. Cette conception ne peut pas fonctionner pour toutes les topologies et doit être examinée au cas par cas.
Messages SCCP MTP
Ces messages SCCP sont échangés entre les ressources CUCM et MTP pour la gestion DTMF.
- CapacitéStationRes
- FonctionnalitésStationUpdate
- StationSubscribeDtmfPayloadReq
- StationSubscribeDTMFPayloadErrv
- StationSubscribeDtmfPayloadRes
- StationUnsubscribeDtmfPayloadErr
- StationNOTIFYDtmfToneMessage
- MessageTonalitéDtmfÉmissionStation
- StationUnsubscribeDtmfPayloadReq
- StationUnsubscribeDtmfPayloadRes
Relais DTMF entre CUCM et CUBE
CUCM SIP Trunk vers CUBE
CUBE prend en charge KPML, NTE ou Unsolicited Notify comme mécanisme DTMF, selon sa configuration. Comme il peut y avoir plusieurs terminaux dans le système, plusieurs méthodes peuvent être configurées simultanément sur le CUBE afin de minimiser les exigences MTP.
Sur CUBE, configurez sip-kpml et rtp-net en tant que méthodes de relais DTMF sous les terminaux de numérotation dial-peer SIP. Cette configuration permet l'échange DTMF avec tous les types de terminaux, y compris ceux qui prennent en charge uniquement NTE et ceux qui prennent en charge uniquement les méthodes OOB, sans avoir besoin de ressources MTP. Avec cette configuration, la passerelle négocie à la fois NTE et KPML avec CUCM. Si NTE n'est pas pris en charge par le terminal Unified CM, KPML est utilisé pour l'échange DTMF. Si les deux méthodes sont négociées avec succès, la passerelle s'appuie sur NTE pour recevoir les chiffres et ne s'abonne pas à KPML.
CUBE a également la possibilité d'utiliser la méthode Unsolicited Notify (UN) pour DTMF. La méthode UN envoie un message SIP Notify avec un corps contenant du texte décrivant la tonalité DTMF. Cette méthode est également prise en charge sur Unified CM et peut être utilisée si sip-kpml n'est pas disponible. Configurez sip-notify comme méthode de relais DTMF. Notez que cette méthode est propriétaire de Cisco.
Les CUBE configurés uniquement pour le relais NTE, ou qui, en raison d'une certaine limitation d'interfonctionnement, ne peuvent fournir que des ressources NTE et MTP requises à allouer du côté de CUCM lors de la communication avec des points d'extrémité qui ne prennent pas en charge NTE.
Vous trouverez plus d'informations sur les exigences CUCM SIP Trunk MTP
Liaison CUCM H323 vers CUBE
CUCM choisit dynamiquement la méthode de transport DTMF pour les liaisons H323 ; il n'y a donc pas d'options configurables pour choisir l'une plutôt que l'autre. Si vous souhaitez forcer une méthode de relais DTMF spécifique, vous pouvez le faire à partir de la configuration de partenaire de numérotation CUBE pour cette agrégation.
Même lorsque les CUBE H323 prennent en charge NTE, l'option NTE ne doit pas être utilisée car elle n'est pas prise en charge sur CUCM pour les passerelles/agrégations H.323 à l'heure actuelle ; CUCM n'annonce donc pas cette capacité au moment de l'échange des capacités de support H245. L'option préférée de CUCM est H.245 Signal.
Des ressources MTP sont nécessaires pour établir des appels vers un CUBE H.323 si l'autre point d'extrémité ne dispose pas d'une fonctionnalité de signalisation en commun avec CUCM. Par exemple, un téléphone IP Cisco Unified 7960 qui exécute la pile SIP ne prend en charge que les NTE. Par conséquent, un MTP est nécessaire avec une liaison H.323 afin que H245 Alphanumeric puisse être utilisé sur la branche H323.
Charges utiles dynamiques/asymétriques CUBE
À partir de la version 15.1(1)T de Cisco IOS (CUBE 1.4), la prise en charge de l'interfonctionnement dynamique des types de données utiles pour les paquets DTMF et Codec pour les appels SIP à SIP a été introduite.
Cette fonctionnalité permet au CUBE de gérer l'interfonctionnement de : types de données utiles dynamiques pour les codecs audio/vidéo, NSE et DTMF ; qui jusqu'à ce point était limité parce que Cisco IOS réservait une plage statique et autorisait seulement les mêmes types de données utiles à négocier sur les deux branches d'appel et rejetait l'appel avec une réponse d'erreur 488 pour les codecs audio/vidéo/NSE non concordants (ou de secours pour les données utiles vocales intrabande G711 DTMF) pour les données utiles NTE non concordantes. Par conséquent, la fonctionnalité permet au CUBE d'annuler la réservation ou de libérer des types de charge utile de manière dynamique pour l'interfonctionnement avec des fournisseurs SIP ou des périphériques tiers qui utilisent une plage différente de types de charge utile vers une autre branche qui ne les prendrait pas en charge ou qui nécessite un mappage différent en particulier.
Une branche d'appel sur CUBE est considérée comme symétrique ou asymétrique en fonction de la valeur du type de données utiles échangée via SDP pendant l'offre et la réponse avec le point d'extrémité.
- Un point d'extrémité symétrique accepte et envoie le même type de données utiles pour les événements NTE ou un codec spécifique pour un segment d'appel.
- Un point d'extrémité asymétrique peut accepter et envoyer différents types de données utiles pour les événements NTE ou un codec spécifique pour une branche d'appel.
Cette commande est disponible pour spécifier l'utilisation de charges utiles asymétriques ; elle peut être appliquée globalement sous le mode de configuration voice service voip enter sip ou au niveau dial-peer à l'aide de l'interface de ligne de commande voice-class sip
asymmetric payload {dtmf | dynamic-codecs | full | system}
Pour plus d'informations sur les données utiles dynamiques/asymétriques, accédez à Interopérabilité de type de données utiles dynamiques pour les paquets DTMF et codec pour les appels SIP à SIP
Exemple de charges utiles symétriques
Voici un exemple de la façon dont le SDP ressemblerait pour une négociation de charge utile symétrique et la sortie de la session debug voip rtp nommée event pendant que les tonalités DTMF sont transmises. Notez que la configuration utilisée pour forcer Cisco IOS peut utiliser un type de données utiles différent pour les événements NTE qui utilisent la commande rtp payload-type nte.
Négociation de relais DTMF
Transmission par relais DTMF
Exemple de charges utiles asymétriques
Voici un exemple de la façon dont le SDP ressemblerait pour une négociation de charge utile asymétrique et le résultat de la commande debug voip rtp session named event pendant que les tonalités DTMF sont transmises. Notez la configuration utilisée pour forcer Cisco IOS à utiliser un type de données utiles différent pour les événements NTE et utilise les commandes rtp payload-type nte et la CLI voice-class sip asymmetric payload dtmf.
Négociation de relais DTMF
Transmission par relais DTMF
Quelle méthode de relais DTMF utiliser ?
Lorsque vous choisissez le relais DTMF à utiliser, vous devez tenir compte de ces variables.
- Périphériques et plates-formes concernés.
- Protocoles VoIP impliqués.
- Chemin média et codecs pris en charge.
- Méthodes de relais DTMF prises en charge ou préférées.
Méthodes de relais DTMF préférées pour H.323
La méthode préférée pour H323 serait d'utiliser OOB à H.245 alphanumérique ou signal dans presque tous les scénarios. Vous pouvez également utiliser RFC2833 tant que CUCM n'est pas impliqué.
Méthodes de relais DTMF préférées pour SIP
- Liaisons SIP vers les fournisseurs de services - chaque fois qu'une liaison SIP est établie avec un fournisseur SIP impliqué ou qu'une interaction avec 3rd Les périphériques SIP ou les systèmes IVR tiers sont alors préférés via RFC2833.
- Ligne principale SIP vers CUCM ou CME - activer RFC2833 et KPML.
- Ligne principale SIP vers CUE - la méthode par défaut pour CUE est UN, mais vous pouvez également la configurer pour utiliser NTE ; qui est également la meilleure option si l'appel provient d'un fournisseur SIP vers le système CUE.
Informations connexes
Prise en charge du transcodage vocal universel pour les passerelles IP à IP
Exemple de configuration de transcodage Unified Border Element
Configuration de la suppression numérique du relais DTMF sur un élément de périphérie unifié Cisco
Configuration requise pour SIP Trunk MTP
Méthode SIP INFO pour la génération de tonalités DTMF
Historique de révision
| Révision | Date de publication | Commentaires |
|---|---|---|
2.0 |
15-May-2023 |
Texte de remplacement et informations d'arrière-plan ajoutés.
Introduction, exigences de marque, référencement, traduction automatique, exigences de style, fonds et formatage mis à jour |
1.0 |
30-Mar-2016 |
Première publication |
CommentairesContacter Cisco
- Ouvrir un dossier d’assistance
- (Un contrat de service de Cisco est requis)