Configura inoltro DTMF su CUBE
Sommario
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.
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.
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
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 relè 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 Terminal CapabilitySet (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: 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. 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.
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
Esempio di configurazione della trascodifica degli elementi del bordo unificato
Configurazione di DTMF Relay Digit-Drop su un Cisco Unified Border Element
Metodo SIP INFO per la generazione del tono DTMF
Cronologia delle revisioni
| Revisione | Data di pubblicazione | Commenti |
|---|---|---|
2.0 |
15-May-2023 |
Sono state aggiunte informazioni sullo sfondo e sul testo alternativo.
Introduzione aggiornata, Requisiti di branding, SEO, traduzione automatica, requisiti di stile, gerund e formattazione |
1.0 |
30-Mar-2016 |
Versione iniziale |
Feedback