Sommario

Introduzione

Prerequisiti

Requisiti

Componenti usati

Convenzioni

Premesse

Metodi DTMF-Relay supportati per CUBE

Metodi di inoltro DTMF in banda supportati

Metodi di inoltro DMTF fuori banda supportati

Supporto per DTMF audio in-band tramite G711

Metodi DTMF-Relay supportati per H323

Alfanumerico H.245

Segnale H.245

NTE (Named Telephony Events) - RFC283

RTP di proprietà Cisco

Metodi DTMF-Relay supportati per SIP

NOTA - RFC283

UNSOLLECITATO NOTIFY (UN)

Linguaggio KPML (Key Press Markup Language)

Informazioni (INFO)

Configurazione di DTMF-Relay sul CUBO

Configurazione di DTMF Relay per H323

Configurazione di DTMF Relay per SIP

Configura Digit-Drop relay DTMF

Convalida e risoluzione dei problemi di DTMF Relay

Convalida OOB DTMF Relay per H323

Pubblicità sulla funzionalità alfanumerica H.245

Esempio di trasmissione alfanumerica H.245

Annuncio funzionalità segnale H.245

Esempio di trasmissione del segnale H.245

Conferma relè DTMF in-band per H323

RFC 2833 - Annuncio di supporto delle funzionalità

Convalida OOB DTMF Relay per SIP

Esempio di annuncio NON SOLLECITATO NOTIFY (UN)

Esempio di trasmissione di NOTIFY (UN) non sollecitato

Esempio di annuncio Key Press Markup Language (KPML)

Esempio di trasmissione KPML

Interoperabilità DTMF

Quando CUBE richiede risorse di transcodifica per DTMF

Interoperabilità DTMF tra Inband G711 e RFC283

Altre opzioni di interworking DTMF

Quando sono richieste le risorse MTP da CUCM?

Dispositivi MTP supportati da CUCM

Software MTP (applicazione Cisco IP Voice Media Streaming)

Software MTP (basato su Cisco IOS)

MTP hardware (PVDM2, Cisco NM-HDV2 e NM-HD-1V/2V/2VE)

MTP hardware (Cisco serie 2900 e 3900 Router con PVDM3)

Quando utilizzare l'MTP software o hardware

Considerazioni su MRG (Media Resource Group) e MRGL (Media Resource Group List) CUCM per MTP

Messaggi SCCP MTP

Trasmissione DTMF tra CUCM e CUBE

CUCM SIP Trunk su CUBE

CUCM H323 trunk to CUBE

Payload dinamici/asimmetrici CUBE

Esempio di payload simmetrici

Negoziazione relay DTMF

Trasmissione relay DTMF

Esempio di payload asimmetrici

Negoziazione relay DTMF

Trasmissione relay DTMF

Metodo di inoltro DTMF da utilizzare

Metodi di inoltro DTMF preferiti per H.323

Metodi di inoltro DTMF preferiti per SIP

Informazioni correlate

Introduzione

Questo documento descrive il processo di configurazione del relay DTMF (Dual-Tone Multi-Frequency) per Cisco Unified Border Element (CUBE) Enterprise.

Prerequisiti

Requisiti

Cisco raccomanda la conoscenza dei seguenti argomenti.

- Conoscenze base dei toni DTMF

- Conoscenze base di come configurare e utilizzare la voce di Cisco® IOS (ad esempio, dial-peer)

- Conoscenze base di configurazione e utilizzo di CUBE

- Conoscenze base dei segnali usati dai protocolli SIP e H323

- Conoscenze base di come eseguire il debug dei protocolli VoIP, ad esempio H323 e SIP

Componenti usati

Le informazioni fornite in questo documento si basano sulle seguenti versioni software e hardware.

- Cisco Unified Border Element eseguito su Cisco IOS.

- Cisco Unified Communications Manager 7.x o versioni successive.

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Convenzioni

Per ulteriori informazioni sulle convenzioni usate, consultare il documento Cisco sulle convenzioni nei suggerimenti tecnici.

Premesse

In questo documento vengono forniti anche informazioni e comandi su come configurare, verificare e risolvere i problemi di relay DTMF per i diversi protocolli gateway VoIP supportati da CUBE.

Metodi DTMF-Relay supportati per CUBE

CUBE supporta un'ampia varietà di metodi di inoltro DTMF per i protocolli di segnalazione In-band e Out-Of-Band (OOB) per H.323 e Session Initiation Protocol (SIP).

Metodi di inoltro DTMF in banda supportati

- Audio in-band DTMF tramite G711

- RFC 283

Metodi di inoltro DMTF fuori banda supportati

- Alfanumerico H.245

- Segnale H.245

- SIP Unsolicited NOTIFY

- SIP KPML

- INFORMAZIONI SIP

Supporto per DTMF audio in-band tramite G711

L'audio in-band Voice o il DTMF G711 si riferisce al trasporto di toni acustici sul flusso audio vocale, senza alcun coinvolgimento aggiuntivo del protocollo di segnalazione o del DSP per la loro trasmissione, a parte la configurazione normale della chiamata e il passaggio dell'audio da un'estremità all'altra e l'utilizzo del codec G711Ulaw/Alaw. Ciò significa che CUBE/Cisco IOS trasmette l'audio dei toni provenienti da un'estremità all'altra come se si trattasse di un normale audio vocale. La misura importante da adottare per questo metodo è garantire che le chiamate vengano stabilite e utilizzare il codec G711Ulaw/Alaw, in particolare perché l'uso di un codec che comprimerebbe l'audio (qualsiasi codec diverso da G711) distorce i toni DTMF e probabilmente li rende irriconoscibili per l'estremità ricevente. Questo perché l'algoritmo di compressione usato dai codec ad alta compressione è stato progettato per riconoscere e prevedere la voce umana e non i toni DTMF.

Audio in-band/G711 DTMF è supportato con qualsiasi protocollo di segnalazione VoIP e richiede solo l'applicazione del codec G711 per le chiamate end-to-end. Si deve anche tenere a mente che qualsiasi trattamento di trascodifica da un codec a basso bit-rate (LBR) a G711 molto probabilmente distorce anche i toni.

Nota: quando si discute di questo metodo di trasmissione DTMF, spesso si crea confusione, in quanto il termine In-band viene utilizzato per riferirsi al trasporto del DTMF all'interno del flusso RTP, denominato evento di telefonia con nome (NTE/RFC2833), e quando si tratta di toni audio in-band. È sempre importante chiarire il metodo richiesto/supportato per applicare la configurazione corretta e utilizzare l'approccio corretto per la risoluzione dei problemi.

Metodi DTMF-Relay supportati per H323

Alfanumerico H.245

Le cifre DTMF sono separate dal flusso vocale e inviate tramite il canale di segnalazione H.245 OOB invece di essere inviate tramite il canale RTP. I toni vengono trasportati nei messaggi H.245 User Input Indication. Il canale di segnalazione H.245 è un canale affidabile e la consegna dei pacchetti che trasportano i toni DTMF è garantita. Tutti i sistemi conformi allo standard H.323 versione 2 devono supportare il comando alfanumerico dtmf-relay h245. Tuttavia, il supporto del comando dtmf-relay h245-signal è facoltativo.

Segnale H.245

Il metodo OOB, simile all'alfanumerico H.245, permette il passaggio delle informazioni sulla durata del tono, quindi risolve un potenziale problema con il metodo alfanumerico quando si lavora con i sistemi di altri fornitori.

NTE (Named Telephony Events) - RFC283

Questo metodo trasporta i toni DTMF in pacchetti RTP separati secondo la sezione 3 della RFC 2833. La RFC 2833 definisce i formati dei pacchetti RTP NTE utilizzati per trasportare cifre DTMF, flash hook e altri eventi di telefonia tra due endpoint peer. Con il metodo NTE, gli endpoint eseguono la negoziazione per chiamata dei parametri del relay DTMF per determinare il valore del tipo di payload per i pacchetti NTE RTP e gli eventi numerici NTE supportati. Di conseguenza, i toni DTMF vengono comunicati tramite pacchetti RTP con un valore del tipo di payload diverso dai valori negoziati per altri pacchetti multimediali; questo fornisce un metodo affidabile per trasportare le cifre ed evitare che non vengano riconosciute quando vengono compresse tramite il codec utilizzato per codificare il traffico voce, video o fax.

RFC2833/NTE DTMF relay è considerato un metodo in-band perché le cifre vengono trasportate all'interno del traffico audio RTP stesso senza alcun coinvolgimento del protocollo di segnalazione GW.

È importante sottolineare che il metodo RFC2833/NTE non deve essere confuso con l'audio in-band della voce o con lo streaming RTP G711 in quanto quest'ultimo è costituito solo dai toni udibili che vengono passati come audio normale senza che alcun metodo di segnalazione relè sia a conoscenza o sia coinvolto nel processo. Significa che si tratta di semplici toni audio passati da un'estremità all'altra utilizzando il codec G711Ulaw/Alaw.

Ecco altri fatti relativi a NTE con H323:

- H.323 supporta RFC2833 a partire dalla versione V4

- Cisco IOS pubblicizza sempre il supporto 2833 in TCS

- CUCM supporta NTE solo attraverso un H.323 ICT.

RTP di proprietà Cisco

Con questo metodo, i toni DTMF vengono inviati nello stesso canale RTP dei dati vocali. Tuttavia, i toni DTMF sono codificati in modo diverso dai campioni di voce e sono identificati come payload di tipo 121, che consente al ricevitore di identificarli come toni DTMF. Questo metodo non è supportato da CUCM e il suo utilizzo è stato interrotto.

Metodi DTMF-Relay supportati per SIP

NOTA - RFC283

I tipi di payload NTE RFC2833 in-band e gli attributi vengono negoziati tra le due estremità durante l'impostazione della chiamata che utilizzano il protocollo SDP (Session Description Protocol) all'interno della sezione body del messaggio SIP.

UNSOLLECITATO NOTIFY (UN)

Con questo metodo, le cifre vengono inviate OOB come messaggi SIP NOTIFY nel payload del corpo del messaggio.

Linguaggio KPML (Key Press Markup Language)

In base a RFC4730, le cifre vengono trasportate fuori banda utilizzando XML nei messaggi Subscribe/NOTIFY. Viene utilizzato principalmente per gli endpoint SIP registrati in CUCM o CME, ma anche con ITSP.

Informazioni (INFO)

Le cifre vengono inoltrate come messaggi INFO SIP OOB tra le estremità. Questo metodo non richiede alcuna configurazione e viene accettato e correlato automaticamente da CUBE.

Nota: SIP INFO non è supportato da Unified CM.

Nota: quando entrambi i metodi UN e NTE vengono negoziati, Cisco IOS sceglie sempre UN over NTE per evitare i doppi toni e il pacchetto in-band 2833 NTE viene soppresso. Inoltre, per CUCM, un viene utilizzato solo quando non è disponibile alcuna altra opzione. Analogamente, se sono presenti sia KPML che UN, Cisco Call Manager (CCM) sceglie KPML su UN.

Configurazione di DTMF-Relay sul CUBO

Per impostazione predefinita, il relay DTMF è disabilitato sia per i peer di connessione H323 che per i peer di connessione SIP (ad eccezione di SIP INFO). È obbligatorio configurare il metodo di relè DTMF in modo che venga utilizzato end-to-end sui peer di connessione in entrata e in uscita per ciascun segmento di chiamata.

Configurazione di DTMF Relay per 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

È possibile configurare più metodi per ogni dial-peer, a seconda dei requisiti delle estremità di terminazione.

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

Configurazione di DTMF Relay per 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

È possibile configurare più metodi per ogni dial-peer, a seconda dei requisiti delle estremità di terminazione.

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

Nota: aggiungere il comando session protocol sip nel dial-peer per rendere disponibili le opzioni SIP dtmf-relay.

Configura Digit-Drop relay DTMF

Per evitare la presenza di cifre duplicate, inoltrando le stesse cifre DTMF attraverso metodi in-band e fuori banda alla gamba in uscita per le chiamate che interagiscono da un metodo in-band (in particolare RTP-NTE) a un metodo fuori banda, configurare il comando dtmf-relay rtp-net digit-drop sul dial-peer in entrata e il metodo fuori banda desiderato sul dial-peer in uscita. In caso contrario, la stessa cifra viene inviata sia in OOB che in banda e viene interpretata come cifra duplicata dall'estremità ricevente.

Quando l'opzione digit-drop è configurata nel segmento in entrata, CUBE sopprime i pacchetti NTE e solo le cifre relay che utilizzano il metodo OOB configurato nel segmento in uscita.

Come mostrato in questa immagine, l'opzione di rilascio delle cifre è disponibile solo quando si interagisce con questi metodi di inoltro DTMF.

Ad esempio, configurare il comando dtmf-relay rtp-net digit-drop sul dial-peer in entrata per un segmento SIP che invia cifre tramite RFC2833, quindi configurare sul lato H.323 in uscita il segnale h245 alfanumerico o dtmf-relay h245; in questo modo il CUBE deve sopprimere i pacchetti NTE e inviare solo gli eventi H245 OOB.

Per ulteriori informazioni, vedere DTMF Relay Digit Drop.

Convalida e risoluzione dei problemi di DTMF Relay

Convalida OOB DTMF Relay per H323

Pubblicità sulla funzionalità alfanumerica H.245

Per verificare se un endpoint annuncia la funzionalità alfanumerica H.245, cercare questa riga nel messaggio H.245 Terminal Capability Set (TCS) con il comando debug h245 asn1.

capability receiveUserInputCapability : basicString : NULL

Esempio di trasmissione alfanumerica H.245

Di seguito è riportato un esempio di endpoint che trasmette la cifra 1 con il metodo alfanumerico H245 con il comando debug h245 asn1.

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

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

Annuncio funzionalità segnale H.245

Per verificare se un endpoint annuncia la funzionalità di segnale H.245, cercare questa linea nel messaggio H.245 Terminal Capability Set (TCS) che usa il comando debug h245 asn1.

capability receiveUserInputCapability : dtmf : NULL

Esempio di trasmissione del segnale H.245

Questo è un esempio di endpoint che trasmette la cifra 1 con durata di 100 msec usando il metodo di segnale H245. Sono presenti due messaggi, il primo indica la cifra da comporre con una durata di 4 s. Tuttavia, il secondo segnale (signalUpdate) aggiorna il valore della durata della cifra a 100msec.

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

}

Conferma relè DTMF in-band per H323

Gli endpoint con H.323 V5 possono supportare RFC2833 tramite un messaggio sulle funzionalità all'interno del messaggio TerminalCapabilitySet (TCS).

RFC 2833 - Annuncio di supporto delle funzionalità

Per confermare se un endpoint sta annunciando la funzionalità RFC2833, cercare questa struttura all'interno del messaggio H.245 TCS che usa il debug h245 asn1 (nell'esempio viene annunciato il tipo di payload 101 per gli eventi da 0 a 16).

capabilityTableEntryNumber 34

capability receiveRTPAudioTelephonyEventCapability :

{

dynamicRTPPayloadType 101

audioTelephoneEvent "0-16"

}

Convalida OOB DTMF Relay per SIP

Esempio di annuncio NON SOLLECITATO NOTIFY (UN)

Per confermare se un endpoint annuncia la funzionalità UN (Unsolicited NOTIFY), cercare questa riga all'interno del messaggio INVITE e/o nei messaggi di risposta a INVITE utilizzando i messaggi CSIP di debug.

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“

Esempio di trasmissione di NOTIFY (UN) non sollecitato

Il metodo UN trasmette le cifre come dati binari all'interno del messaggio NTFY, pertanto non è possibile visualizzare la cifra trasportata tramite i messaggi CSIP di debug. È possibile che sia necessario un comando packet capture (PCAP) o che sia necessario eseguire il comando debug ccsip all per visualizzare la cifra negli output dei dati binari.

Esempio di come apparirebbe la stessa cifra 7 quando si esegue il comando 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

Linguaggio KPML (Key Press Markup Language) AEsempio di annuncio

La funzionalità KPML è elencata nell'intestazione SIP Allow-Events. Per le trasmissioni di cifre KPML, l'endpoint di trasmissione deve prima inviare una sottoscrizione al servizio KPML; viene trasmesso il messaggio SUBSCRIBE che richiede la funzionalità; seguito da un messaggio NOTIFY inviato dall'estremità di ricezione che contrassegna lo stato di sottoscrizione per gli eventi KPML come attivo.

Iniziale INVITE che annuncia la capacità.

INVITE sip:95554445001@192.168.105.25:5060 SIP/2.0

Allow-Events: kpml, telephone-event

Chiusura della sottoscrizione delle richieste finali agli eventi KMPL.

SUBSCRIBE sip:2010@192.168.106.50:5060 SIP/2.0

Event: kpml

Content-Type: application/kpml-request+xml

L'estremità di origine risponde con un NOTIFY che imposta lo stato su attivo.

NOTIFY  sip:192.168.105.25:5060 SIP/2.0

Event: kpml

Subscription-State: active

KPML TEsempio di trasmissione

Dopo l'esecuzione della sottoscrizione, gli endpoint possono trasmettere le cifre utilizzando i messaggi NOTIFY con eventi KPML tramite XML. Esempio di cifra 1 trasmessa.

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"/>

Interoperabilità DTMF

CUBE supporta circa 30 tipi diversi di interoperabilità DTMF. È in grado di interagire e transcodificare tra diversi metodi di inoltro in base al comando dtmf-relay configurato nei dial-peer in entrata e in uscita corrispondenti per la chiamata.

Fare riferimento alla sezione DTMF Interoperability Table della CUBE Configuration Guide per i dettagli sul supporto dell'interoperabilità DTMF.

Quando CUBE richiede risorse di transcodifica per DTMF

CUBE richiede la transcodifica di risorse registrate localmente in questi scenari

- Interoperabilità tra RFC 2833 e Voice In-band

- Interoperabilità tra un metodo OOB e RFC2833 per le chiamate di flusso

CUBE è in grado di interagire tra tutti gli altri metodi di relay DTMF con chiamate di flusso-through senza la necessità di un transcodificatore.

Interoperabilità DTMF tra Inband G711 e RFC283

CUBE è in grado di interagire tra il segnale DTMF (raw audio tones) in banda G711 e l'RFC2833. Tuttavia, tali requisiti devono essere soddisfatti

- Il codec utilizzato deve essere G711 end-to-end. Si tratta di una restrizione perché, se si dovesse utilizzare un codec LBR, i toni risulterebbero distorti a causa della perdita di compressione.

- Le risorse di transcodifica devono essere disponibili e registrate con il CUBE di conseguenza. Questo perché il CUBE deve allocare una risorsa di transcodifica (più specificamente: una risorsa DSP) al flusso RTP multimediale per inserire o ascoltare i toni all'interno del flusso audio.

- Il dial-peer per il segmento dei toni in banda non deve avere alcun comando di relay DTMF configurato. Questo requisito non è più necessario per IOS XE 16.12.x o versioni successive. CUBE può allocare dinamicamente un Transcoder anche se il dial-peer in entrata/ITSP ha configurato il dtmf-relay rtp-net. La decisione di allocare un transcodificatore può dipendere dalla negoziazione SDP tra i dispositivi peer.

- Il dial-peer per il segmento RFC2833 deve avere dtmf-relay rtp-net configurato.

- Non abilitare il digit-drop su nessuno dei peer della chiamata coinvolti nella chiamata.

Altre opzioni di interworking DTMF

È inoltre disponibile un set aggiuntivo di comandi di interworking che potrebbero essere richiesti in scenari di chiamata specifici; tali comandi possono essere configurati a livello globale o a livello di 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.

Quando sono richieste le risorse MTP da CUCM?

La risorsa MTP diventa necessaria quando CUCM deve interagire con metodi DTMF diversi tra due dispositivi, uno dei quali utilizza specificamente il metodo RFC2833 e l'altro un metodo OOB. In questo scenario, il CUCM deve allocare le risorse necessarie per trasmettere e/o rilevare i toni in-band a causa della mancata corrispondenza del relay DTMF tra le due estremità.

Il ruolo dell'MTP è monitorare il traffico RTP e rilevare eventi NTE dal segmento RFC2833 o inserire gli eventi NTE nel flusso RTP se richiesto dal CUCM. Se l'MTP rileva eventi NTE in entrata dall'endpoint che supportano solo RFC2833, invia un messaggio SCCP StationNOTIFYDtmfToneMessage al CUCM e lo informa del segnale rilevato nel flusso. Il CUCM a sua volta invia la stessa cifra e utilizza il protocollo di segnalazione (OOB) all'altra estremità. Se il CUCM riceve un segnale DTMF OOB dall'endpoint DTMF OOB, invia un messaggio StationSendDtmfToneMessage SCCP all'MTP in modo che l'MTP possa iniettare il tono richiesto nel flusso RTP sotto forma di eventi NTE.

Dispositivi MTP supportati da CUCM

Software MTP (applicazione Cisco IP Voice Media Streaming)

Il protocollo MTP del software è un dispositivo implementato abilitando l'applicazione Cisco IP Voice Media Streaming su un server CUCM. Quando l'applicazione installata è configurata come applicazione MTP, si registra con un nodo CUCM e comunica a CUCM il numero di risorse MTP supportate. Un dispositivo MTP software supporta solo flussi G.711. Le impostazioni predefinite di CUCM consentono di gestire fino a 48 chiamate in base all'MTP del software. Per i dettagli su come modificare i parametri del servizio, consultare la versione appropriata della Guida all'amministrazione di Cisco Unified Communications Manager.

Software MTP (basato su Cisco IOS)

Questo MTP consente di configurare uno qualsiasi di questi codec, tuttavia è possibile configurarne solo uno alla volta con i formati G.711 mu-law e a-law, G.729a, G.729, G.729ab, G.729b e passthrough. Alcune di queste non sono pertinenti per un'implementazione CUCM.

Le configurazioni dei router consentono fino a 1.000 singoli flussi, che supportano 500 sessioni trascodificate che generano 10 Mbyte di traffico. I Cisco ISR G2 e i router ASR possono supportare numeri notevolmente più alti di questo.

Questo MTP utilizza i cicli della CPU per funzionare. Prendere nota del numero di sessioni abilitate in quanto potrebbero influire sulle prestazioni della CPU e provocare un elevato utilizzo della CPU.

MTP hardware (PVDM2, Cisco NM-HDV2 e NM-HD-1V/2V/2VE)

Questo hardware utilizza i moduli PVDM-2 per fornire i DSP.

MTP hardware (Cisco serie 2900 e 3900 Router con PVDM3)

Questi router utilizzano i DSP PVDM3 in modo nativo sulle schede madri o il PVDM2 con un adattatore sulla scheda madre o sui moduli di assistenza.

Nota: non è possibile configurare G.729 o G.729b durante la configurazione delle risorse MTP hardware in Cisco IOS. Tuttavia, Unified CM può utilizzare le risorse di trascodifica hardware come MTP se tutte le altre risorse MTP sono esaurite o non sono disponibili per altri motivi.

Quando utilizzare l'MTP software o hardware

Il tipo di MTP da distribuire nella rete dipende dai parametri specifici del codec supportati dagli endpoint, dai gateway e dai trunk nel flusso di chiamate

- I gusti del codec da utilizzare

- Le dimensioni del pacchetto del codec da usare (pacchettizzazione)

- Utilizzo fax T.38 (richiede supporto pass-through codec)

In base a questi parametri è possibile scegliere e distribuire in modo sicuro le risorse corrette richieste dalla rete.

Come mostrato nella tabella, le diverse funzioni supportate dai diversi tipi di MTP e transcodificatore

Tipo

Stessi codec

Codec diversi

Diversa pacchettizzazione

Codec

Pass-through

Note

CUCM SW MTP

Sì

No

Sì

No

G711 Trascodifica e repacchettizzazione di malware-Ulaw

Cisco IOS HW MTP

Sì

No

No

Sì

Supporto per qualsiasi codec (e stesso sapore) fino alla stessa pacchettizzazione. Nessuna trascodifica.

Cisco IOS SW MTP

Sì

No

No

Sì

Supporto di qualsiasi codec (e stesso sapore) fino alla stessa pacchettizzazione. Nessuna trascodifica.

Cisco IOS Regular Xcoder

Sì

Sì

Sì

Sì

Finché almeno un lato è G711u/G711a, supporta la repacchettizzazione e la transcodifica.

Cisco IOS Universal Xcoder

Sì

Sì

Sì

Sì

Supporto in qualsiasi codec, pacchettizzazione e transcodifica.

Per ulteriori informazioni sulla configurazione MTP in CUCM, fare riferimento all'esempio di configurazione del punto di terminazione multimediale.

Considerazioni su MRG (Media Resource Group) e MRGL (Media Resource Group List) CUCM per MTP

Quando si creano e si assegnano risorse multimediali a gruppi di risorse multimediali (MRG) e a elenchi di gruppi di risorse multimediali (MRGL), tenere presenti alcune considerazioni aggiuntive per evitare sottoscrizioni eccessive delle risorse migliori per flussi di chiamate specifici e assegnare loro una priorità di conseguenza. CUCM non è in grado di scegliere il dispositivo migliore da utilizzare, quando seleziona una risorsa multimediale per una chiamata, da un determinato elenco di MTP e transcoder se hanno la stessa priorità o lo stesso ordine. Viene invece scelto il primo dispositivo che supporta le funzionalità richieste. Quindi anche se la chiamata sta usando il G711 su entrambe le gambe, se il primo dispositivo che trova è un transcodificatore allora lo alloca come MTP per la chiamata e non cerca una risorsa MTP più in basso nell'elenco.

Un altro comportamento simile si verifica quando si hanno sia trascodificatori universali che regolari. Il CUCM può utilizzare i trascodificatori regolari prima su una chiamata in cui una delle gambe era G711, e poi fallire quando una chiamata viene trasferita a una destinazione che utilizza un codec non-G711, perché il CUCM non rilascerà il trascodificatore corrente e ne otterrà un altro quando la chiamata viene trasferita.

Per ovviare a questo problema, è consigliabile assegnare tutti i dispositivi solo MTP in un unico MRG, quindi i trascodificatori universali in un altro MRG e i trascodificatori regolari in un terzo MRG e infine assegnare loro la priorità nello stesso ordine all'interno del MRGL. Ora questo progetto non può funzionare per ogni topologia e deve essere rivisto caso per caso.

Messaggi SCCP MTP

Questi messaggi SCCP vengono scambiati tra le risorse CUCM e MTP per la gestione del DTMF.

- CapacitàStazioneRes

- FunzionalitàAggiornamentoStazione

- RichiestaPayloadDtmfSottoscrizioneStazione

- IscrizioneStazioneDTMFPayloadErrv

- StazioniSottoscriviDtmfPayloadRes

- Annulla sottoscrizioneDtmfPayloadErr

- NotificaStazioneMessaggioTmfTono

- InviaMessaggioTonoDtm

- ReqPayloadDtmfStazioniAnnullaSottoscrizione

- Annulla sottoscrizioneDtmfPayloadRes

Trasmissione DTMF tra CUCM e CUBE

CUCM SIP Trunk su CUBE

CUBE supporta KPML, NTE o Unsolicited Notify come meccanismo DTMF, a seconda della configurazione. Poiché nel sistema possono essere presenti più endpoint, è possibile configurare contemporaneamente più metodi sul CUBO per ridurre al minimo i requisiti MTP.

Su CUBE, configurare sia sip-kpml che rtp-net come metodi di inoltro DTMF in peer di composizione SIP. Questa configurazione consente lo scambio DTMF con tutti i tipi di endpoint, inclusi quelli che supportano solo NTE e quelli che supportano solo i metodi OOB, senza la necessità di risorse MTP. Con questa configurazione, il gateway negozia sia NTE che KPML con CUCM. Se NTE non è supportato dall'endpoint CM unificato, per lo scambio DTMF viene utilizzato KPML. Se entrambi i metodi vengono negoziati correttamente, il gateway si basa su NTE per ricevere le cifre e non sottoscrive il KPML.

CUBE consente inoltre di utilizzare il metodo di notifica non richiesta (UN, Unsolicited Notify) per DTMF. Il metodo UN invia un messaggio SIP Notify con un corpo contenente il testo che descrive il tono DTMF. Questo metodo è supportato anche in Unified CM e può essere utilizzato se sip-kpml non è disponibile. Configurare la notifica sip come metodo di inoltro DTMF. Tale metodo è di proprietà di Cisco.

I CUBE configurati solo per il relay NTE o che, a causa di alcune limitazioni di interworking, possono solo fornire risorse NTE e MTP richieste da allocare sul lato CUCM quando comunicano con endpoint che non supportano NTE.

Ulteriori informazioni sui requisiti MTP per SIP Trunk CUCM

CUCM H323 trunk to CUBE

CUCM sceglie in modo dinamico il metodo di trasporto DTMF per i trunk H323, pertanto non sono disponibili opzioni configurabili per scegliere l'una rispetto all'altra. Se si desidera forzare un metodo di inoltro DTMF specifico, è possibile farlo dalla configurazione dial-peer CUBE per questo trunk.

Anche quando H323 CUBE supporta NTE, l'opzione NTE non deve essere utilizzata perché al momento non è supportata su CUCM per gateway/trunk H.323; pertanto CUCM non annuncia questa funzionalità al momento dello scambio delle funzionalità multimediali di H245. L'opzione preferita dal CUCM è il segnale H.245.

Le risorse MTP sono richieste per stabilire chiamate a un CUBE H.323 se l'altro endpoint non ha funzionalità di segnalazione in comune con CUCM. Ad esempio, un Cisco Unified 7960 IP Phone con stack SIP supporta solo NTE, quindi è necessario un MTP con trunk H.323 in modo da poter usare il formato H245 alfanumerico sul segmento H323.

Payload dinamici/asimmetrici CUBE

A partire dalla versione 15.1(1)T (CUBE 1.4) di Cisco IOS è stato introdotto il supporto per l'interoperabilità dinamica dei tipi di payload per i pacchetti DTMF e Codec per le chiamate SIP-SIP.

Questa funzione consente al CUBE di gestire l'interoperabilità di: tipi di payload dinamici per codec audio/video, NSE e DTMF; che fino a questo punto era limitato perché Cisco IOS riservava un intervallo statico e consentiva solo la negoziazione degli stessi tipi di payload su entrambe le gambe di chiamata e rifiutava la chiamata con una risposta di errore 488 per codec audio/video/NSE non corrispondenti (o fallback a voice inband G711 DTMF) per payload NTE non corrispondenti. Pertanto, la funzione consente al CUBE di annullare la riserva o liberare dinamicamente tipi di payload per l'interoperabilità con i provider SIP o dispositivi di terze parti che utilizzano un intervallo diverso di tipi di payload a un'altra gamba che non li supporta o che richiede specificamente un mapping diverso.

Una tappa di chiamata su CUBE è considerata simmetrica o asimmetrica in base al valore del tipo di payload scambiato tramite SDP durante l'offerta e alla risposta con l'endpoint.

- Un endpoint simmetrico accetta e invia lo stesso tipo di payload per gli eventi NTE o un codec specifico per un segmento di chiamata.

- Un endpoint asimmetrico può accettare e inviare diversi tipi di payload per gli eventi NTE o un codec specifico per un segmento di chiamata.

Questo comando è disponibile per specificare l'uso dei payload asimmetrici. Il comando può essere applicato globalmente nel comando voice service voip enter sip config mode o a livello dial-peer usando la CLI sip-class

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

Per ulteriori informazioni sui payload dinamici/asimmetrici, passare a Interoperabilità del tipo di payload dinamico per DTMF e pacchetti codec per chiamate SIP-SIP

Esempio di payload simmetrici

Di seguito è riportato un esempio di come l'SDP dovrebbe apparire per una negoziazione del payload simmetrico e l'output dell'evento denominato debug voip rtp session mentre vengono trasmessi i toni DTMF. Notare che la configurazione utilizzata per forzare Cisco IOS può usare un tipo di payload diverso per gli eventi NTE che usano il comando rtp payload-type net.

Negoziazione relay DTMF

Trasmissione relay DTMF

Esempio di payload asimmetrici

Di seguito è riportato un esempio di come l'SDP dovrebbe apparire per una negoziazione asimmetrica del payload e l'output del comando debug voip rtp session denominato event mentre vengono trasmessi i toni DTMF. Notare la configurazione usata per forzare Cisco IOS a usare un tipo di payload diverso per gli eventi NTE e usa i comandi rtp payload-type e la CLI dtmf asymmetric payload sip di classe vocale.

Negoziazione relay DTMF

Trasmissione relay DTMF

Metodo di inoltro DTMF da utilizzare

Quando si sceglie il relè DTMF da utilizzare, è necessario prendere in considerazione queste variabili.

- Dispositivi e piattaforme interessati.

- Protocolli VoIP interessati.

- Percorso del supporto e codec supportati.

- Metodi di inoltro DTMF supportati o preferiti.

Metodi di inoltro DTMF preferiti per H.323

Il metodo preferito per l'H323 sarebbe l'utilizzo di segnali alfanumerici o OOB-H.245 in quasi tutti gli scenari. È inoltre possibile utilizzare la RFC2833 a condizione che non si utilizzi CUCM.

Metodi di inoltro DTMF preferiti per SIP

- SIP trunk per provider di servizi - quando è presente un trunk SIP verso un provider SIP coinvolto o quando si interagisce con 3rd si preferiscono i dispositivi SIP di terze parti o i sistemi IVR in banda tramite RFC2833.

- Trunk SIP su CUCM o CME: abilitare sia RFC2833 che KPML.

- SIP trunk to CUE - il metodo predefinito per CUE è UN, ma è possibile anche configurarlo in modo da utilizzare NTE. Questa è anche l'opzione migliore se la chiamata proviene da un provider SIP al sistema CUE.

Informazioni correlate

Supporto trascodifica voce universale per gateway IP-to-IP

Conversione DTMF

Esempio di configurazione della trascodifica degli elementi del bordo unificato

Uso di Cisco Unified Communications Manager per configurare la trascodifica e il punto di terminazione multimediale

Configurazione di DTMF Relay Digit-Drop su un Cisco Unified Border Element

Requisiti SIP Trunk MTP

Metodo SIP INFO per la generazione del tono DTMF

Trunk H.323 con media termination point

CUBE 9.0 Local Transcoding Interface (LTI)