Relé DTMF e entrelaçamento no CUBE

Introduction

Este documento descreve o processo para configurar o relay DTMF (Dual-Tone Multi-Frequency, multifrequência de tom duplo) para o Cisco Unified Border Element (CUBE) Enterprise. Além disso, ele também fornece informações e comandos sobre como configurar, verificar e solucionar problemas de retransmissão DTMF para os diferentes protocolos de gateway VoIP suportados pelo CUBE.

Contribuído por Michael Mendoza, engenheiro do TAC da Cisco.

Prerequisites

Requirements

A Cisco recomenda que você tenha conhecimento destes tópicos

• Conhecimento básico dos tons de DTMF
• Conhecimento básico de como configurar e usar a voz do Cisco IOS (como correspondentes de discagem)
• Conhecimento básico sobre como configurar e usar o CUBE
• Conhecimento básico da sinalização usada pelos protocolos SIP e H323
• Conhecimento básico de como depurar protocolos VoIP como H323 e SIP

Componentes Utilizados

As informações neste documento são baseadas nestas versões de software e hardware

• Cisco Unified Border Element executado no IOS
• Cisco Unified Communications Manager 7.x ou posterior

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. If your network is live, make sure that you understand the potential impact of any command.

Conventions

 Consulte as Convenções de Dicas Técnicas da Cisco para obter informações sobre convenções de documentos.

Métodos DTMF-relay suportados para CUBE

O CUBE suporta uma ampla variedade de métodos de retransmissão de DTMF para os protocolos de sinalização In-band e OOB (Out-Of-Band) para H.323 e Session Initiation Protocol (SIP).

Métodos de retransmissão DTMF in-band suportados

• DTMF de auditoria em banda até G711
• RFC2833

Métodos de retransmissão DMTF fora da banda suportados

• H.245 alfanumérico
• Sinal H.245
• NOTIFICAÇÃO SIP não solicitada
• KPML SIP
• INFORMAÇÕES SIP

Suporte para DTMF de áudio em banda através do G711

O áudio In-band de voz ou DTMF G711 refere-se ao transporte de tons audíveis pelo fluxo de áudio de voz, sem qualquer envolvimento adicional do protocolo de sinalização ou do DSP para sua transmissão, além de configurar a chamada normalmente e passar o áudio de ponta a ponta usando o codec G711Ulaw/Alaw. Isso significa que o CUBE/IOS somente passa o áudio dos tons que chegam de uma extremidade à outra como se fosse um áudio de voz normal. A medida importante a ser tomada para esse método é garantir que as chamadas sejam estabelecidas usando o codec G711Ulaw/Alaw especificamente porque o uso de um codec que comprima o áudio (qualquer outro codec que não G711) distorce os tons de DTMF e provavelmente os torna irreconhecíveis na extremidade receptora. Isso porque o algoritmo de compactação utilizado por codecs de compactação alta foi projetado para reconhecer e prever voz humana e não tons de DTMF.

O DTMF de áudio/G711 em banda é suportado com qualquer protocolo de sinalização VoIP e exige apenas que o codec G711 seja executado para as chamadas de ponta a ponta. É preciso também ter em mente que qualquer tratamento de transcodificação de um codec de baixa taxa de bits (LBR) para G711 provavelmente também distorce os tons.

Note: É comum que surja alguma confusão ao discutir este método de retransmissão de DTMF porque o termo In-band é usado para se referir ao transporte de DTMF dentro do fluxo de RTP chamado de Evento de Telefonia Nomeada (NTE/RFC2833) e quando são tons de áudio In-band. É sempre importante esclarecer o método real exigido/suportado para aplicar a configuração apropriada e usar a abordagem de solução de problemas correta.

Métodos de retransmissão DTMF suportados para H323

H.245 alfanumérico

Os dígitos DTMF são separados do fluxo de voz e enviados através do canal de sinalização H.245 OOB em vez de serem enviados através do canal RTP. Os tons são transportados em mensagens de indicação de entrada do usuário H.245. O canal de sinalização H.245 é um canal confiável e os pacotes que transportam os tons de DTMF são garantidos como entregues. Todos os sistemas compatíveis com a versão 2 do H.323 são necessários para suportar o comando dtmf-relay h245-alfanumérico. No entanto, o suporte ao comando dtmf-relay h245-signal é opcional.

Sinal H.245

O método OOB, que é semelhante ao H.245 alfanumérico, permite a passagem das informações de duração do tom, resolvendo um possível problema com o método alfanumérico ao interagir com os sistemas de outros fornecedores.

Eventos de Telefonia Nomeada (NTE - Named Telephony Events) - RFC2833

Esse método transporta tons de DTMF em pacotes RTP separados de acordo com a seção 3 do RFC 2833. O RFC 2833 define os formatos dos pacotes NTE RTP usados para transportar dígitos DTMF, flash de gancho e outros eventos de telefonia entre dois pontos finais correspondentes. Com o método NTE, os endpoints executam a negociação por chamada dos parâmetros de retransmissão DTMF para determinar o valor do tipo de payload para os pacotes NTE RTP e eventos de dígitos NTE suportados. Como resultado, os tons de DTMF são comunicados através de pacotes RTP com um valor de tipo de payload diferente dos valores negociados para outros pacotes de mídia; que fornece um método confiável para transportar os dígitos e evitar que eles não sejam reconhecidos quando são compactados pelo codec usado para codificar o tráfego de voz, vídeo ou fax.

RFC2833/NTE A retransmissão DTMF é considerada um método In-band porque os dígitos são transportados dentro do próprio tráfego de áudio RTP sem qualquer envolvimento do protocolo de sinalização GW.

É importante ressaltar que o método RFC2833/NTE não deve ser confundido com o áudio In-band de voz ou o fluxo RTP G711, já que o mais recente é apenas os tons audíveis sendo passados como áudio normal sem que nenhum método de sinalização de retransmissão esteja ciente ou envolvido no processo. Isso significa que eles são apenas tons de áudio simples sendo passados de ponta a ponta usando o codec G711Ulaw/Alaw.

Alguns outros fatos interessantes sobre o NTE com H323:

• H.323 suporta RFC2833 a partir de V4
• O IOS sempre anuncia seu suporte 2833 no Estudo de caso dividido em temas
• O CUCM suporta apenas NTE através de uma ICT H.323.

RTP proprietário da Cisco

Com esse método, os tons de DTMF são enviados no mesmo canal RTP que os dados de voz. No entanto, os tons de DTMF são codificados de forma diferente dos exemplos de voz e são identificados como payload tipo 121, que permite que o receptor os identifique como tons de DTMF. Este método não é suportado pelo CUCM e o seu uso foi descontinuado.

Métodos DTMF-Relay suportados para SIP

NTE - RFC2833

Os tipos de payload e atributos NTE RFC2833 em banda são negociados entre as duas extremidades da configuração da chamada usando o Session Description Protocol (SDP) na seção de corpo da mensagem SIP.

NOTIFICAÇÃO NÃO SOLICITADA (UN)

Com esse método, os dígitos são enviados como OOB como mensagens SIP NOTIFY no payload do corpo da mensagem.

Key Press Markup Language (KPML)

Com base no RFC4730, os dígitos são transportados OOB usando XML em mensagens de assinatura/NOTIFY. Ele é usado principalmente para endpoints SIP registrados no CUCM ou CME, mas também com ITSPs.

Informações (INFORMAÇÕES)

Os dígitos são retransmitidos como mensagens OOB SIP INFO entre as extremidades. Esse método não exige nenhuma configuração e é aceito e relacionado automaticamente pelo CUBE.

Note: A INFO SIP não é suportada pelo Unified CM.

Note: Quando os métodos UN e NTE são negociados, o IOS sempre escolhe UN sobre NTE para evitar dois tons e o pacote NTE 2833 in-band é suprimido. Além disso, para o CUCM, a ONU é usada somente quando não há outra opção disponível. Da mesma forma, se a KPML e a UN estiverem presentes, o Cisco Call Manager (CCM) escolhe a KPML sobre UN.

Configurar DTMF-Relay no CUBE

Por padrão, o relé DTMF é desabilitado para peers de discagem H323 e SIP (exceto para INFO SIP); é obrigatório configurar o método de retransmissão de DTMF a ser usado de ponta a ponta nos peers de discagem de entrada e de saída para cada trecho de chamada.

Configurar o relé DTMF para 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

Você pode configurar mais de um método por peer de discagem, dependendo dos requisitos das extremidades de terminação.

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

Configurar o relay DTMF para 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

 Você pode configurar mais de um método por peer de discagem, dependendo dos requisitos das extremidades de terminação.

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 SUBCRIBE/NOTIFY 
  sip-NOTIFY          DTMF Relay via SIP NOTIFY  messages

Note: Adicione o comando session protocol sip no dial-peer para as opções SIP dtmf-relay se tornarem disponíveis.

Configurar DTMF Relay Digit-Drop

Para evitar a duplicação de dígitos ao transmitir os mesmos dígitos de DTMF através de métodos dentro e fora da banda para o segmento de saída para chamadas que interajam de um método dentro da banda (RTP-NTE especificamente) para um método fora da banda, configure o comando dtmf-relay rtp-nte digits-drop no peer de discagem de entrada e o método out-of-band desejado no dial de saída par. Caso contrário, o mesmo dígito é enviado em OOB e em banda e é interpretado como dígitos duplicados pela extremidade de recebimento.

Quando a opção de queda de dígito é configurada no segmento de entrada, o CUBE suprime os pacotes NTE e apenas os dígitos de retransmissão usando o método OOB configurado no segmento de saída.

Como mostrado nesta imagem, a opção de queda de dígito está disponível somente ao interfuncionamento entre esses métodos de retransmissão DTMF.

Por exemplo, configure o comando dtmf-relay rtp-nte digits-drop no peer de discagem de entrada para um trecho SIP enviando dígitos através de RFC2833 e, em seguida, no lado de saída H.323 configure dtmf-relay h245-alfanumérico ou dtmf-relay o sinal h245; isso deve fazer com que o CUBE suprima os pacotes NTE e envie somente os eventos OB H245.

Para obter mais informações, consulte DTMF Relay Digit Drop.

Validar e solucionar problemas de retransmissão de DTMF

Validando o relé OOB DTMF para H323

Anúncio de capacidade alfanumérica H.245

Para validar se um endpoint está anunciando o recurso alfanumérico H.245, procure essa linha dentro da mensagem H.245 Terminal Capability Set (TCS) usando debug h245 asn1.

capability receiveUserInputCapability : basicString : NULL

Exemplo de transmissão alfanumérica H.245

Aqui está um exemplo de um endpoint transmitindo o dígito 1 usando o método alfanumérico H245 usando debug h245 asn1.

000510: Sep 28 19:02:02.716: H245 MSC OUTGOING PDU ::=
	value MultimediaSystemControlMessage ::= indication : userInput : alphanumeric : "1“ 

Anúncio de capacidade de sinal H.245

Para confirmar se um endpoint está anunciando o recurso de sinal H.245, procure essa linha dentro da mensagem do conjunto de recursos de terminal (TCS) H.245 usando debug h245 asn1.

capability receiveUserInputCapability : dtmf : NULL

Exemplo de transmissão de sinal H.245

Este é um exemplo de um endpoint transmitindo o dígito 1 com duração de 100 ms usando o método de sinal H245. Há duas mensagens, a primeira mensagem indica que o dígito está sendo discado com uma duração de 4s. No entanto, o segundo sinal (signalUpdate) atualiza o valor da duração do dígito para 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
		      }

Confirmar retransmissão DTMF na banda para H323

Os endpoints com H.323 V5 podem indicar que suportam RFC2833 através de uma mensagem de capacidade na mensagem TerminalCapabilitySet (TCS).

Anúncio de suporte de recurso RFC2833

Para confirmar se um endpoint está anunciando o recurso RFC2833, procure essa estrutura dentro da mensagem do Estudo de caso dividido em temas H.245 usando debug h245 asn1 (no exemplo, payload-type 101 está sendo anunciado para os eventos de 0 a 16).

capabilityTableEntryNumber 34
          capability receiveRTPAudioTelephonyEventCapability :
          {
            dynamicRTPPayloadType 101
            audioTelephoneEvent "0-16"
          }

Validar o relé OOB DTMF para SIP

Exemplo de anúncio de NOTIFY (UN) não solicitado

Para confirmar se um endpoint está anunciando o recurso NOTIFY não solicitado (UN), procure essa linha dentro da mensagem CONVITE e/ou mensagens de resposta ao CONVITE usando debug ccsip messages.

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“

Exemplo de transmissão de NOTIFY (UN) não solicitado

O método ONU transmite os dígitos como dados binários dentro da mensagem NTFY; assim, você não poderá ver qual dígito está sendo transportado usando debug ccsip messages. Você precisará de uma captura de pacote (PCAP) ou executará o comando debug ccsip all para ver o dígito nas saídas de dados binários.

Exemplo de como o mesmo dígito 7 discado seria ao executar o 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

Key Press Markup Language (KPML) AExemplo de anúncio

O recurso KPML está listado no cabeçalho SIP Allow-Events. Para as transmissões de dígitos KPML, o ponto final transmissor precisa primeiro de enviar uma assinatura ao serviço KPML; A mensagem SUBSCRIBE solicitando a transmissão do recurso; seguido por uma mensagem NOTIFY da extremidade de recebimento marcando o estado da assinatura dos eventos KPML como ativos.

CONVITE inicial anunciando o recurso.

INVITE sip:95554445001@192.168.105.25:5060 SIP/2.0 
Allow-Events: kpml, telephone-event

A terminação solicita a assinatura dos eventos KMPL.

SUBSCRIBE sip:2010@192.168.106.50:5060 SIP/2.0
Event: kpml 
Content-Type: application/kpml-request+xml 

A extremidade de origem responde com uma configuração NOTIFY como ative (NOTIFICAR).

NOTIFY  sip:192.168.105.25:5060 SIP/2.0
Event: kpml 
Subscription-State: active

KPML TExemplo de transmissão

Depois que a assinatura tiver ocorrido, os endpoints poderão transmitir os dígitos usando mensagens NOTIFY com eventos KPML através de XML. Exemplo de dígito 1 sendo transmitido.

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

Interfuncionamento DTMF

O CUBE suporta cerca de 30 tipos diferentes de entrelaçamento DTMF. Ele é capaz de intertrabalhar e transcodificar entre diferentes métodos de retransmissão com base no comando dtmf-relay configurado nos correspondentes de discagem de entrada e saída correspondentes para a chamada.

Consulte a seção Tabela de Interoperabilidade DTMF do Guia de Configuração do CUBE para obter detalhes sobre o Suporte de Interfuncionamento DTMF. 

Quando o CUBE exige recursos de transcodificação para DTMF?

O CUBE exige recursos de transcodificação registrados localmente nesses cenários

• Interfuncionamento entre RFC2833 e Voice In-band
• Interfuncionamento entre um método OOB e RFC2833 para chamadas em fluxo

O CUBE é capaz de interagir entre todos os outros métodos de retransmissão de DTMF com chamadas de passagem de fluxo sem a necessidade de um transcodificador.

Interfuncionamento DTMF entre Inband G711 e RFC2833

O CUBE é capaz de interagir entre DTMF G711 de banda interna (tons de áudio bruto) para RFC2833. No entanto, esses requisitos precisam ser atendidos

• O codec usado deve ser G711 de ponta a ponta. Essa é uma restrição porque se um codec LBR fosse usado, os tons ficariam distorcidos devido à perda de compactação.
• Os recursos de transcodificação devem estar disponíveis e registrados no CUBE de acordo. Isso porque o CUBE precisa alocar um recurso de transcodificação (mais especificamente: um recurso DSP) ao fluxo de RTP de mídia para injetar ou ouvir tons dentro do fluxo de áudio.
• O peer de discagem para o trecho de tons de inband não deve ter nenhum comando de retransmissão DTMF configurado.
• O peer de discagem para o trecho RFC2833 deve ter dtmf-relay rtp-nte configurado.
• Não habilite a queda de dígitos em nenhum dos peers de discagem envolvidos com a chamada.

Outras opções de interfuncionamento DTMF

Há também um conjunto adicional de comandos de entrelaçamento que podem ser necessários em cenários de chamada específicos; que podem ser configurados globalmente ou no nível de 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 os recursos MTP são necessários para o CUCM?

O recurso MTP torna-se necessário quando o CUCM precisa intertrabalhar diferentes métodos DTMF entre dois dispositivos, um deles usando o método RFC2833 especificamente e o outro um método OOB. Nesse cenário, o CUCM precisa alocar os recursos necessários para transmitir e/ou detectar os tons em banda devido à incompatibilidade de transmissão de DTMF entre as duas extremidades.

A função do MTP é monitorar o tráfego de RTP e detectar eventos de NTE do segmento de RFC2833 ou injetar os eventos de NTE no fluxo de RTP, se solicitado pelo CUCM. Se o MTP detectar eventos NTE de entrada do ponto final que suportam somente RFC2833, ele enviará uma Estação SCCP NOTIFYDtmfToneMessage ao CUCM informando-o do tom detectado no fluxo. O CUCM, por sua vez, envia o mesmo dígito usando o protocolo de sinalização (OOB) para a outra extremidade. Se o CUCM receber um sinal OOB DTMF do ponto de extremidade OOB DTMF, ele enviará uma SCCP StationSendDtmfToneMessage para o MTP para que o MTP possa injetar o tom solicitado no fluxo RTP na forma de eventos NTE.

Dispositivos MTP suportados pelo CUCM

Software MTP (Cisco IP Voice Media Streaming Application)

O MTP de software é um dispositivo implementado pela ativação do aplicativo de transmissão de mídia de voz IP da Cisco em um servidor CUCM. Quando o aplicativo instalado é configurado como um aplicativo MTP, ele se registra com um nó CUCM e informa ao CUCM quantos recursos MTP ele suporta. Um dispositivo MTP de software suporta apenas fluxos G.711. As configurações padrão do CUCM permitem que ele trate até 48 chamadas de acordo com o MTP do software. Para obter detalhes sobre como modificar os parâmetros do serviço, consulte a versão apropriada do Guia de Administração do Cisco Unified Communications Manager.

Software MTP (baseado no Cisco IOS)

Esse MTP permite a configuração de qualquer um desses codecs, entretanto, apenas um pode ser configurado em um determinado momento G.711 mu-law e a-law, G.729a, G.729, G.729ab, G.729b e passagem. Alguns deles não são pertinentes a uma implementação do CUCM.

As configurações do roteador permitem até 1.000 fluxos individuais, que suportam 500 sessões transcodificadas que geram 10 Mbytes de tráfego. Os roteadores Cisco ISR G2s e ASR podem suportar números significativamente mais altos do que isso.

Esse MTP consome ciclos de CPU para operar. Anote o número de sessões habilitadas, pois isso pode afetar o desempenho da CPU e acionar a alta utilização da CPU.

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

Esse hardware usa os módulos PVDM-2 para fornecer DSPs.

Hardware MTP (Cisco 2900 e 3900 Series Routers com PVDM3)

Esses roteadores usam DSPs PVDM3 nativamente nas placas-mãe ou PVDM2 com um adaptador na placa-mãe ou nos módulos de serviço.

Note: Você não pode configurar o G.729 ou o G.729b ao configurar recursos de MTP de hardware no Cisco IOS. No entanto, o Unified CM pode usar recursos de transcodificação de hardware como MTPs se todos os outros recursos de MTP estiverem esgotados ou não estiverem disponíveis.

Quando usar MTP de software ou hardware?

O tipo de MTP a ser implantado na rede depende dos parâmetros específicos do codec suportados pelos endpoints, gateways e troncos no fluxo de chamadas

• Os sabores do codec a serem usados
• O tamanho do pacote Codec a ser usado (empacotamento)
• Uso de fax T.38 (requer suporte de passagem de codec)

Com base nesses parâmetros, você pode escolher e implantar com segurança os recursos corretos exigidos pela rede.

Como mostrado na tabela, os diferentes recursos suportados por diferentes tipos de MTP e transcodificadores

Tipo	Os mesmos codecs	Codecs diferentes	Pacote diferente	Codec Passagem	Notas
CUCM SW MTP	Yes	No	Yes	No	Transcodificação e reposicionamento Alaw-Ulaw G711
IOS HW MTP	Yes	No	No	Yes	Suporte para qualquer codec (e mesmo sabor), desde que a mesma empacotamento. Sem transcodificação.
IOS SW MTP	Yes	No	No	Yes	Suportar qualquer codec (e mesmo sabor), desde que a mesma empacotamento. Sem transcodificação.
Xcoder Regular IOS	Yes	Yes	Yes	Yes	Desde que pelo menos um lado seja G711u/G711a, ele suporta qualquer repacotização e transcodificação.
IOS Universal Xcoder	Yes	Yes	Yes	Yes	Suporte em qualquer codec, empacotamento e transcodificação.

Para obter mais informações sobre a configuração de MTP no CUCM, consulte o Exemplo de Configuração de Ponto de Terminação de Mídia .

Considerações do Grupo de Recursos de Mídia (MRG - Media Resource Group) e da Lista de Grupos de Recursos de Mídia (MRGL - Media Resource Group) do CUCM para MTP

Ao criar e atribuir recursos de mídia a grupos de recursos de mídia (MRG) e a listas de grupos de recursos de mídia (MRGL), considere alguns pontos adicionais para evitar o excesso de assinaturas dos melhores recursos para fluxos de chamadas específicas e priorizá-los de acordo com isso, porque o CUCM não consegue escolher o melhor dispositivo a ser usado ao selecionar um recurso de mídia para uma chamada a partir de uma determinada lista de MTPs e transcodificadores se eles tiverem a mesma prioridade ou ordem. Em vez disso, ele escolhe o primeiro dispositivo que suporta os recursos solicitados. Assim, mesmo que a chamada esteja usando G711 em ambas as pernas, se o primeiro dispositivo encontrado for um transcodificador, ele a aloca como um MTP para a chamada e não procura um recurso MTP mais abaixo da lista.

Outro comportamento semelhante ocorre quando você tem transcodificadores universais e regulares. O CUCM pode usar os transcodificadores regulares primeiro em uma chamada em que uma das pernas é G711, e depois falhar quando uma chamada é transferida para um destino que usa um codec não G711, porque o CUCM não vai liberar o transcodificador atual e obter outro quando a chamada for transferida.

A melhor prática de concepção para contornar este comportamento consiste em atribuir todos os dispositivos MTP apenas num único MRG, em seguida os transcodificadores universais a outro MRG e os transcodificadores regulares a um terceiro MRG; e priorizá-los na mesma ordem dentro da MRGL. Agora, esse projeto não pode funcionar para todas as topologias e deve ser revisado caso a caso.

Mensagens de SCCP MTP

Essas mensagens SCCP são trocadas entre os recursos CUCM e MTP para o tratamento de DTMF

•  FunçõesEstaçãoRes
•  RecursosStationUpdate
•  StationSubscribeDtmfPayloadReq
•  StationSubscribeDTMFPayloadErrv
•  StationSubscribeDtmfPayloadRes
•  StationUnsubscribeDtmfPayloadErr
•  StationNOTIFYDtmfToneMessage
•  StationSendDtmfToneMessage
•  StationUnsubscribeDtmfPayloadReq
•  StationUnsubscribeDtmfPayloadRes

Tronco SIP CUCM para CUBE

O CUBE suporta KPML, NTE ou Notificação não solicitada como o mecanismo DTMF, dependendo de sua configuração. Como pode haver uma combinação de endpoints no sistema, vários métodos podem ser configurados no CUBE simultaneamente para minimizar os requisitos de MTP.

No CUBE, configure os métodos sip-kpml e rtp-nte como métodos de retransmissão DTMF em peers de discagem SIP. Essa configuração permite a troca de DTMF com todos os tipos de endpoints, incluindo aqueles que suportam apenas NTE e aqueles que suportam apenas métodos OOB, sem a necessidade de recursos MTP. Com essa configuração, o gateway negocia NTE e KPML com CUCM. Se o NTE não for suportado pelo ponto de extremidade do Unified CM, o KPML será usado para troca de DTMF. Se ambos os métodos forem negociados com êxito, o gateway depende do NTE para receber dígitos e não subscreve o KPML.

O CUBE também pode usar o método de Notificação não solicitada (UN) para DTMF. O método UN envia uma mensagem de notificação SIP com um corpo que contém texto descrevendo o tom de DTMF. Este método também é suportado no Unified CM e pode ser usado se sip-kpml não estiver disponível. Configure sip-notify como o método de retransmissão DTMF. Observe que esse método é proprietário da Cisco.

Os CUBEs configurados somente para retransmissão NTE, ou que devido a alguma limitação de interfuncionamento, podem somente fornecer NTE e recursos MTP necessários para serem alocados no lado do CUCM ao se comunicar com endpoints que não suportam NTE.

Você pode encontrar mais informações sobre os requisitos de MTP do tronco SIP do CUCM

Tronco CUCM H323 para CUBE

CUCM escolhe dinamicamente o método de transporte DTMF para troncos H323; portanto, não há opções configuráveis para escolher uma em vez da outra. Se quiser forçar um método de retransmissão DTMF específico, você poderá fazer isso a partir da configuração do peer de discagem CUBE para esse tronco.

Mesmo quando os CUBEs H323 suportam NTE, a opção NTE não deve ser usada porque não é suportada no CUCM para gateways/troncos H.323 no momento; portanto, o CUCM não anuncia esse recurso no momento em que os recursos de mídia H245 são trocados. A opção preferencial do CUCM é o sinal H.245.

Os recursos de MTP são necessários para estabelecer chamadas para um CUBE H.323 se o outro endpoint não tiver recursos de sinalização em comum com o CUCM. Por exemplo, um Cisco Unified IP Phone 7960 executando a pilha SIP suporta apenas NTEs, de modo que um MTP é necessário com um tronco H.323 para que H245 Alfanumérico possa ser usado no segmento H323.

Cargas dinâmicas/assimétricas do CUBE

A partir da versão 15.1(1)T do IOS (CUBE 1.4), foi apresentado o suporte ao entrelaçamento dinâmico de tipo de payload para pacotes DTMF e codec para chamadas SIP para SIP.

Esse recurso permite que o CUBE gerencie o entrelaçamento de: tipos de payload dinâmico para codecs de áudio/vídeo, NSE e DTMF; o que até este ponto era limitado porque o IOS reservaria um intervalo estático e permitiria apenas que os mesmos tipos de payload fossem negociados em ambos os segmentos de chamada e rejeitaria a chamada com uma resposta de erro 488 para codecs de áudio/vídeo/NSE incompatíveis (ou fallback para DTMF G711 de voz na banda) para payloads de NTE incompatíveis. Portanto, o recurso permite que o CUBE poupe ou liberte os tipos de payload dinamicamente para o interfuncionamento com provedores SIP ou dispositivos de terceiros que usam uma faixa diferente de tipos de payload para outro trecho que não os suportaria ou que exige especificamente um mapeamento diferente.

Um trecho de chamada no CUBE é considerado simétrico ou assimétrico com base no valor do tipo de payload trocado através do SDP durante a oferta e resposta com o endpoint

• Um endpoint simétrico aceita e envia o mesmo tipo de payload para eventos NTE ou um codec específico para um leg da chamada.
• Um endpoint assimétrico pode aceitar e enviar diferentes tipos de payload para eventos NTE ou um codec específico para um leg da chamada.

Esse comando está disponível para especificar o uso de payloads assimétricos; o comando pode ser aplicado globalmente sob o voice service voip enter sip config mode ou no dial-peer level usando o voice-class sip CLI

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

Para obter mais informações sobre payloads dinâmicos/assimétricos, navegue para interfuncionamento de tipo de payload dinâmico para pacotes DTMF e codec para chamadas SIP para SIP

Exemplo de payloads simétricos

Aqui está um exemplo de como o SDP seria para uma negociação de payload simétrica e a saída do evento nomeado debug voip rtp session enquanto os tons de DTMF estão sendo transmitidos. Observe que a configuração usada para forçar o IOS deve usar um tipo de payload diferente para eventos NTE usando o comando rtp payload-type nte.

Negociação de retransmissão de DTMF

Transmissão de retransmissão DTMF

Exemplo de payloads assimétricos

Aqui está um exemplo de como o SDP seria para uma negociação de payload assimétrica e a saída do comando debug voip rtp session nomeado event enquanto os tons de DTMF estão sendo transmitidos. Observe a configuração usada para forçar o IOS a usar um tipo de payload diferente para eventos NTE usando os comandos rtp payload-type nte e a voice-class sip asymmetric payload dtmf CLI.

Negociação de retransmissão de DTMF

Transmissão de relé DTMF

Qual método de retransmissão DTMF deve ser usado?

 Ao escolher o relé DTMF a ser usado, você precisa levar em consideração estas variáveis

• Dispositivos e plataformas envolvidos
• Protocolos VoIP envolvidos
• Caminho de mídia e codecs suportados
• Métodos de retransmissão DTMF suportados ou preferenciais

Métodos de retransmissão DTMF preferidos para H.323

O método preferido para H323 seria usar OOB através de sinal ou alfanumérico H.245 em quase todos os cenários. Você também pode usar o RFC2833 desde que o CUCM não esteja envolvido.

Métodos de retransmissão DTMF preferidos para SIP

• Troncos SIP para provedores de serviços - sempre que houver um tronco SIP para um provedor SIP envolvido ou interação com 3^rd dispositivos SIP de terceiros ou sistemas IVR, então, é preferível na banda através do RFC2833.
• Tronco SIP para CUCM ou CME - habilite RFC2833 e KPML.
• Tronco SIP para CUE - o método padrão para CUE é UN, mas você também pode configurá-lo para usar NTE; que também é a melhor opção se a chamada vem de um provedor SIP para o sistema CUE.

Informações Relacionadas

Suporte à transcodificação de voz universal para gateways IP para IP

Conversão de DTMF

Exemplo de configuração de transcodificação de elemento de borda unificado

Usando o Cisco Unified Communications Manager para configurar a transcodificação e o ponto de terminação de mídia

Configurando o DTMF Relay Digit-Drop em um Cisco Unified Border Element

Requisitos de MTP do tronco SIP

Método de INFORMAÇÕES SIP para geração de tom de DTMF

Troncos H.323 com pontos de terminação de mídia

Interface de Transcodificação Local (LTI - Local Transcoding Interface) do CUBE 9.0