Table des matières

Introduction

Conditions préalables

Exigences

Composants utilisés

Conventions

Informations générales

Méthodes DTMF-Relay prises en charge pour CUBE

Méthodes de relais DTMF intrabande prises en charge

Méthodes de relais DMTF hors bande prises en charge

Prise en charge de la DTMF audio intrabande via G711

Méthodes de relais DTMF prises en charge pour H323

Alphanumérique H.245

Signal H.245

Événements de téléphonie nommés (NTE) - RFC2833

RTP propriétaire Cisco

Méthodes DTMF-Relay prises en charge pour SIP

NTE - RFC2833

NOTIFY non sollicité (ONU)

Langage KPML (Key Press Markup Language)

Information (INFO)

Configuration de DTMF-Relay sur CUBE

Configuration du relais DTMF pour H323

Configuration du relais DTMF pour SIP

Configuration de la suppression numérique du relais DTMF

Validation et dépannage du relais DTMF

Validation du relais OOB DTMF pour H323

Annonce de capacité alphanumérique H.245

Exemple de transmission alphanumérique H.245

Annonce de capacité de signal H.245

Exemple de transmission de signal H.245

Confirmer le relais DTMF intrabande pour H323

Annonce de prise en charge des fonctionnalités RFC2833

Valider le relais OOB DTMF pour SIP

Exemple de publicité non sollicitée NOTIFY (UN)

Exemple de transmission de notification non sollicitée (UN)

Exemple d'annonce KPML (Key Press Markup Language)

Exemple de transmission KPML

Interfonctionnement DTMF

Quand CUBE requiert-il des ressources de transcodage pour DTMF ?

Interfonctionnement DTMF entre G711 intrabande et RFC2833

Autres options d'interfonctionnement DTMF

Quand les ressources MTP sont-elles requises par CUCM ?

Périphériques MTP pris en charge par CUCM

Logiciel MTP (CiscoIP Voice Media Streaming Application)

MTP logiciel (basé sur CiscoIOS)

Matériel MTP (PVDM2, Cisco NM-HDV2 et NM-HD-1V/2V/2VE)

Matériel MTP (routeurs des gammes Cisco 2900 et 3900 avec PVDM3)

Quand utiliser le MTP logiciel ou matériel

Considérations relatives au groupe de ressources multimédias (MRG) et à la liste de groupes de ressources multimédias (MRGL) CUCM pour MTP

Messages SCCP MTP

Relais DTMF entre CUCM et CUBE

CUCM SIP Trunk vers CUBE

Liaison CUCM H323 vers CUBE

Charges utiles dynamiques/asymétriques CUBE

Exemple de charges utiles symétriques

Négociation de relais DTMF

Transmission par relais DTMF

Exemple de charges utiles asymétriques

Négociation de relais DTMF

Transmission par relais DTMF

Quelle méthode de relais DTMF utiliser ?

Méthodes de relais DTMF préférées pour H.323

Méthodes de relais DTMF préférées pour SIP

Informations connexes

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.

Remarque : il est courant qu'une certaine confusion se produise lorsque vous discutez de cette méthode de relais DTMF, car le terme In-band est utilisé pour désigner le transport de DTMF dans le flux RTP appelé Named Telephony Event (NTE/RFC2833) et lorsqu'il s'agit de tonalités audio intra-bande. Il est toujours important de clarifier la méthode réelle requise/prise en charge pour appliquer la configuration appropriée et utiliser la bonne approche pour le dépannage.

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.

Remarque : Unified CM ne prend pas en charge SIP INFO.

Remarque : lorsque les méthodes UN et NTE sont négociées, Cisco IOS choisit toujours UN sur NTE pour éviter les doubles tonalités et le paquet NTE 2833 intrabande est supprimé. En outre, pour CUCM, UN est utilisé uniquement lorsqu'aucune autre option n'est disponible. De même, si KPML et UN sont présents, Cisco Call Manager (CCM) choisit KPML plutôt qu'UN.

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

Remarque : ajoutez la commande session protocol sip sous le terminal de numérotation dial-peer pour que les options SIP dtmf-relay deviennent disponibles.

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

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.

Remarque : vous ne pouvez pas configurer G.729 ou G.729b lors de la configuration des ressources matérielles MTP dans Cisco IOS. Cependant, Unified CM peut utiliser des ressources de transcodage matériel en tant que MTP si toutes les autres ressources MTP sont épuisées ou indisponibles.

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 SIP dial-peer. 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, de sorte qu'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

Conversion DTMF

Exemple de configuration de transcodage Unified Border Element

Utilisation de Cisco Unified Communications Manager pour configurer le transcodage et le point de terminaison du support

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

Liaisons H.323 avec points de terminaison média

Interface de transcodage local (LTI) CUBE 9.0