Configurar o DTMF Relay no CUBE
Contents
Introdução
Este documento descreve o processo para configurar a retransmissão Dual-Tone Multi-Frequency (DTMF) para o Cisco Unified Border Element (CUBE) Enterprise.
Pré-requisitos
Requisitos
A Cisco recomenda que você tenha conhecimento destes tópicos.
- Conhecimento básico de tons DTMF
- Conhecimento básico de como configurar e usar voz do Cisco® IOS (como peers de discagem)
- Conhecimento básico de 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 Cisco IOS.
- Cisco Unified Communications Manager 7.x ou posterior.
As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.
Conventions
Consulte as Convenções de Dicas Técnicas da Cisco para obter informações sobre convenções de documentos.
Informações de Apoio
Este documento 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.
Métodos DTMF-Relay suportados para CUBE
O CUBE suporta uma ampla variedade de métodos de retransmissão DTMF para In-band e Out-Of-Band (OOB) para os protocolos de sinalização H.323 e Session Initiation Protocol (SIP).
Métodos de relé DTMF in-band suportados
- Áudio em banda DTMF através de G711
- RFC2833
Métodos de relé DMTF fora de banda suportados
- H.245 Alfanumérico
- Sinal H.245
- SIP Unsolicited NOTIFY
- KPML SIP
- INFORMAÇÕES SIP
Suporte para DTMF de áudio em banda através do G711
O áudio de voz em banda ou DTMF G711 refere-se ao transporte de tons audíveis sobre o 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 e usar o codec G711Ulaw/Alaw. Isso significa que o CUBE/Cisco IOS passa apenas o áudio dos tons que vêm de uma extremidade à outra como se fosse o áudio de voz normal. A medida importante a ser tomada para esse método é garantir que as chamadas sejam estabelecidas e usem o codec G711Ulaw/Alaw especificamente porque usar um codec que compacte o áudio (qualquer outro codec que não o G711) distorce os tons DTMF e provavelmente os torna irreconhecíveis para a extremidade receptora. Isso ocorre 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 DTMF.
O áudio in-band/G711 DTMF é suportado com qualquer protocolo de sinalização VoIP e requer apenas que o codec G711 seja aplicado para as chamadas fim-a-fim. Deve-se também ter em mente que o tratamento de transcodificação any de um codec de baixa taxa de bits (LBR) para G711 provavelmente distorce os tons também.
Métodos DTMF-Relay 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 enviados através do canal RTP. Os tons são transportados em mensagens de indicação de entrada de usuário H.245. O canal de sinalização H.245 é um canal confiável e os pacotes que transportam os tons DTMF têm garantia de serem entregues. Todos os sistemas compatíveis com H.323 Versão 2 são necessários para suportar o comando dtmf-relay h245-alphanumeric. No entanto, o suporte do comando dtmf-relay h245-signal é opcional.
Sinal H.245
O método OOB, que é semelhante ao alfanumérico H.245, permite a passagem das informações de duração de tom, abordando, assim, um problema potencial com o método alfanumérico ao interagir com sistemas de outros fornecedores.
Named Telephony Events (NTE) - RFC2833
Esse método transporta tons DTMF em pacotes RTP separados de acordo com a seção 3 do RFC 2833. O RFC 2833 define formatos de pacotes NTE RTP usados para transportar dígitos DTMF, flash de gancho e outros eventos de telefonia entre dois pontos terminais de peer. 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 RTP NTE e eventos de dígito NTE suportados. Como resultado, os tons 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; o que fornece um método confiável para transportar os dígitos e evitar que eles não sejam reconhecidos quando forem compactados através do codec usado para codificar o tráfego de voz, vídeo ou fax.
A retransmissão DTMF RFC2833/NTE é 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 fluxo de voz In-band audio ou G711 RTP, uma vez que o último é apenas os tons audíveis que são passados como áudio normal sem que qualquer 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 sobre NTE com H323:
- O H.323 suporta RFC2833 a partir do V4
- O Cisco IOS sempre anuncia seu suporte para 2833 no Estudo de caso dividido em temas
- O CUCM suporta apenas NTE através de uma ICT H.323.
RTP de propriedade da Cisco
Com esse método, os tons DTMF são enviados no mesmo canal RTP que os dados de voz. No entanto, os tons DTMF são codificados de forma diferente dos exemplos de voz e são identificados como tipo de payload 121, o que permite que o receptor os identifique como tons DTMF. Este método não é suportado pelo CUCM e seu uso foi descontinuado.
Métodos DTMF-Relay suportados para SIP
NTE - RFC2833
Os tipos de payload e atributos de NTE RFC2833 in-band são negociados entre as duas extremidades na configuração da chamada que usam o Session Description Protocol (SDP) dentro da 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 dentro do payload do corpo da mensagem.
KPML (Key Press Markup Language)
Com base no RFC4730, os dígitos são transportados OOB usando XML nas mensagens Subscribe/NOTIFY. É usado principalmente para endpoints SIP registrados para CUCM ou CME, mas também com ITSPs.
Informações (INFO)
Os dígitos são retransmitidos como mensagens SIP INFO OOB entre as extremidades. Esse método não requer nenhuma configuração e é aceito e relacionado automaticamente pelo CUBE.
Configurar DTMF-Relay no CUBE
Por padrão, a retransmissão DTMF está desabilitada para os peers de discagem H323 e SIP (exceto para SIP INFO); é obrigatório configurar o método de retransmissão DTMF para ser usado fim-a-fim nos peers de discagem de entrada e de saída para cada trecho da chamada.
Configurar DTMF Relay 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 DTMF Relay 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 SUBSCRIBE/NOTIFY sip-NOTIFY DTMF Relay via SIP NOTIFY messages
Configurar DTMF Relay Digit-Drop
Para evitar dígitos duplicados, retransmitindo os mesmos dígitos DTMF através de métodos in-band e out-of-band para o segmento de saída de chamadas interconectadas de um método in-band (especificamente RTP-NTE) para um método out-of-band, configure o comando dtmf-relay rtp-nte digit-drop no correspondente de discagem de entrada e o método out-of-band desejado no correspondente de discagem de saída. Caso contrário, o mesmo dígito é enviado em OOB e em banda e é interpretado como dígitos duplicados pela extremidade receptora.
Quando a opção de perda de dígitos é configurada no segmento de entrada, o CUBE suprime os pacotes NTE e apenas retransmite os dígitos que usam o método OOB configurado no segmento de saída.
Como mostrado nesta imagem, a opção de perda de dígitos está disponível somente quando há entrelaçamento entre esses métodos de retransmissão DTMF.
Por exemplo, configure o comando dtmf-relay rtp-nte digit-drop no peer de discagem de entrada para um segmento SIP que envia dígitos através do sinal RFC2833 e, em seguida, no lado H.323 de saída, configure dtmf-relay h245-alphanumeric ou dtmf-relay h245-signal; isso deve resultar na supressão do CUBE dos pacotes NTE e no envio apenas dos eventos H245 do OOB.
Para obter mais informações, consulte DTMF Relay Digit Drop.
Validar e solucionar problemas do DTMF Relay
Validar Retransmissão DTMF OOB para H323
Anúncio de capacidade alfanumérica H.245
Para validar se um ponto final está anunciando a capacidade alfanumérica do 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 ponto final 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 a capacidade do sinal H.245, procure essa linha na mensagem do Conjunto de Capacidade de Terminal (TCS - Terminal Capability Set) do H.245 que usa debug h245 asn1.
capability receiveUserInputCapability : dtmf : NULL
Exemplo de transmissão de sinal H.245
Este é um exemplo de um ponto final transmitindo o dígito 1 com duração de 100 ms usando o método de sinal H245. Há duas mensagens, a primeira indica o dígito que 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 100 ms.
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 relé DTMF na banda para H323
Endpoints com H.323 V5 podem indicar que oferecem suporte a RFC2833 por meio de uma mensagem de recurso na mensagem TerminalCapabilitySet (TCS).
RFC2833 Anúncio de suporte de capacidade
Para confirmar se um endpoint está anunciando o recurso RFC2833, procure essa estrutura na mensagem do TCS H.245 que usa 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 Retransmissão DTMF OOB para SIP
Exemplo de anúncio de NOTIFY (UN) não solicitado
Para confirmar se um endpoint está anunciando o recurso Unsolicited NOTIFY (UN), procure essa linha dentro da mensagem INVITE e/ou das mensagens de resposta para o INVITE usando as mensagens ccsip de depuração.
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 UN transmite os dígitos como dados binários dentro da mensagem NTFY; assim, você não pode ver qual dígito está sendo transportado usando mensagens ccsip de depuração. Você pode 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 seria o mesmo dígito 7 discado 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
KPML (Key Press Markup Language) AExemplo de anúncio
O recurso KPML está listado no cabeçalho SIP Allow-Events. Para transmissões de dígitos KPML, o ponto final de transmissão precisa primeiro enviar uma assinatura para o serviço KPML; a mensagem SUBSCRIBE solicitando que o recurso seja transmitido; seguida por uma mensagem NOTIFY da extremidade de recebimento marcando o estado da assinatura para os eventos KPML como ativo.
CONVITE inicial anunciando o recurso.
INVITE sip:95554445001@192.168.105.25:5060 SIP/2.0 Allow-Events: kpml, telephone-event
A assinatura de solicitações finais de término para os 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 um NOTIFY definindo o estado como ativo.
NOTIFY sip:192.168.105.25:5060 SIP/2.0 Event: kpml Subscription-State: active
KPML TExemplo de transmissão
Após a assinatura, os endpoints podem transmitir os dígitos usando mensagens NOTIFY com eventos KPML por meio de XML. Exemplo do 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 interfuncionamento DTMF. Ele é capaz de interfuncionar e transcodificar entre diferentes métodos de retransmissão com base no comando dtmf-relay configurado dentro dos correspondentes de discagem de entrada e de 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 requer recursos de transcodificação registrados localmente nesses cenários
- Entrelaçamento entre RFC2833 e voz em banda
- Entrelaçamento entre um método OOB e RFC2833 para chamadas de fluxo
O CUBE é capaz de interagir com todos os outros métodos de retransmissão DTMF com chamadas de passagem de fluxo sem a necessidade de um transcodificador.
Interfuncionamento DTMF entre Inband G711 a RFC2833
O CUBE é capaz de interfuncionar entre Inband G711 DTMF (tons de áudio bruto) para RFC2833. No entanto, esses requisitos precisam ser atendidos
- O codec usado deve ser G711 fim-a-fim. Essa é uma restrição porque, se um codec LBR fosse usado, os tons seriam 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) para o fluxo RTP de mídia para injetar ou ouvir tons no fluxo de áudio.
- O peer de discagem para o segmento de tons de inband não deve ter nenhum comando de retransmissão DTMF configurado. Esse requisito não é mais necessário para o IOS XE 16.12.x ou posterior. O CUBE pode alocar dinamicamente um transcodificador mesmo se o correspondente de discagem de entrada/ITSP tiver o dtmf-relay rtp-net configurado. A decisão de alocar um transcodificador pode depender da negociação SDP entre os dispositivos pares.
- O peer de discagem para o segmento RFC2833 deve ter o dtmf-relay rtp-net configurado.
- Não ative o recurso de queda de dígitos em nenhum dos correspondentes de discagem envolvidos na chamada.
Outras opções de entrelaçamento 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 do correspondente de discagem.
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 exigidos pelo CUCM
O recurso MTP torna-se necessário quando o CUCM precisa interagir com diferentes métodos DTMF entre dois dispositivos, um deles usando especificamente o método RFC2833 e o outro um método OOB. Neste cenário, o CUCM precisa alocar os recursos necessários para transmitir e/ou detectar os tons in-band devido à incompatibilidade de retransmissão de DTMF entre as duas extremidades.
A função do MTP é monitorar o tráfego RTP e detectar eventos NTE do trecho RFC2833 ou injetar os eventos NTE no fluxo RTP, se solicitado pelo CUCM. Se o MTP detectar eventos NTE de entrada do ponto de extremidade que suportam somente RFC2833, ele enviará um StationNOTIFYDtmfToneMessage SCCP para o CUCM e o informará sobre o tom detectado no fluxo. O CUCM, por sua vez, envia o mesmo dígito e usa o protocolo de sinalização (OOB) para a outra extremidade. Se o CUCM receber um sinal OOB DTMF do endpoint OOB DTMF, ele enviará uma StationSendDtmfToneMessage SCCP ao MTP para que o MTP possa injetar o tom solicitado no fluxo de RTP na forma de eventos NTE.
Dispositivos MTP suportados pelo CUCM
Software MTP (Cisco IP Voice Media Streaming Application)
O software MTP é um dispositivo implementado pela ativação do aplicativo Cisco IP Voice Media Streaming 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 tratar até 48 chamadas de acordo com o MTP de software. Para obter detalhes sobre como modificar os parâmetros de 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, no entanto, 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 passthrough. Alguns deles não são pertinentes a uma implementação de 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 maiores do que este.
Esse MTP consome ciclos de CPU para operar. Anote o número de sessões habilitadas, pois isso poderia 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.
MTP de hardware (Cisco 2900 e 3900 Series Routers com PVDM3)
Esses roteadores usam os DSPs PVDM3 nativamente nas placas-mãe ou PVDM2 com um adaptador na placa-mãe ou nos módulos de serviço.
Quando usar o MTP de software ou hardware
O tipo de MTP a ser implantado na rede depende dos parâmetros específicos de codec suportados pelos pontos de extremidade, gateways e troncos no fluxo de chamadas
- Os sabores de Codec a serem usados
- O tamanho do pacote de Codec a ser usado (empacotamento)
- Uso de fax T.38 (requer suporte para passagem de codec)
Com base nesses parâmetros, você pode escolher e implantar com segurança os recursos corretos exigidos pela sua rede.
Como mostrado na tabela, os diferentes recursos suportados pelos diferentes tipos de MTP e transcodificador
| Tipo |
Mesmos codecs |
Codecs diferentes |
Empacotamento diferente |
Codec Passagem |
Notas |
| MTP CUCM SW |
Yes |
No |
Yes |
No |
Transcodificação e reempacotamento de G711 Alaw-Ulaw |
| MTP de HW do Cisco IOS |
Yes |
No |
No |
Yes |
Suporte para qualquer codec (e mesmo tipo), desde que a mesma empacotamento. Sem transcodificação. |
| MTP Cisco IOS SW |
Yes |
No |
No |
Yes |
Suportar qualquer codec (e mesmo tipo), desde que a mesma empacotamento. Sem transcodificação. |
| Xcoder Regular do Cisco IOS |
Yes |
Yes |
Yes |
Yes |
Desde que pelo menos um lado seja G711u/G711a, ele suporta qualquer reempacotamento e transcodificação. |
| Xcoder universal do Cisco IOS |
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 do Ponto de Terminação de Mídia .
Considerações sobre Grupo de recursos de mídia (MRG) e Lista de grupos de recursos de mídia (MRGL) do CUCM para MTP
Ao criar e atribuir recursos de mídia a grupos de recursos de mídia (MRG) e listas de grupos de recursos de mídia (MRGL), leve em consideração alguns pontos adicionais para evitar a assinatura em excesso dos melhores recursos para fluxos de chamadas específicos e priorize-os adequadamente. O CUCM é incapaz de selecionar o melhor dispositivo para usar, quando seleciona um recurso de mídia para uma chamada, 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 se a chamada estiver usando G711 em ambos os lados, se o primeiro dispositivo que encontrar for um transcodificador, ele a alocará como um MTP para a chamada e não procurará um recurso MTP mais abaixo na 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 um dos trechos era 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 é transferida.
A melhor prática de design para contornar esse comportamento é atribuir todos os dispositivos somente MTP em uma única MRG, depois os transcodificadores universais a outra MRG e os transcodificadores regulares a uma terceira MRG e, em seguida, priorizá-los na mesma ordem dentro da MRGL. Agora, esse projeto não pode funcionar para todas as topologias e deve ser analisado caso a caso.
Mensagens SCCP MTP
Essas mensagens SCCP são trocadas entre os recursos CUCM e MTP para tratamento de DTMF.
- FunçõesdaEstação
- FunçõesdeAtualizaçãodaEstação
- StationSubscribeDtmfPayloadReq
- StationSubscribeDTMFPayloadErrv
- StationSubscribeDtmfPayloadRes
- StationUnsubscribeDtmfPayloadErr
- StationNOTIFYDtmfToneMessage
- MensagemDeTomDeDtmfDeEstação
- StationUnsubscribeDtmfPayloadReq
- EstaçãoCancelarAssinaturaDtmfPayloadRes
Retransmissão DTMF entre CUCM e CUBE
Tronco SIP de CUCM para CUBE
O CUBE suporta KPML, NTE ou Unsolicited Notify 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 sip-kpml e rtp-nte como métodos de retransmissão DTMF nos pontos 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 tanto NTE quanto KPML com CUCM. Se o NTE não for suportado pelo ponto final do Unified CM, o KPML será usado para troca DTMF. Se ambos os métodos forem negociados com êxito, o gateway depende do NTE para receber dígitos e não se inscreve no 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 DTMF. Esse método também é suportado no Unified CM e pode ser usado se o sip-kpml não estiver disponível. Configure sip-notify como o método de retransmissão DTMF. Observe que esse método é de propriedade da Cisco.
Os CUBEs configurados somente para retransmissão NTE, ou que devido a alguma limitação de entrelaçamento, só podem fornecer NTE e os recursos MTP necessários a serem alocados no lado do CUCM ao se comunicar com pontos finais 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
O 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 desejar forçar um método de retransmissão DTMF específico, você poderá fazer isso na configuração do peer de discagem do 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 preferida do CUCM é o sinal H.245.
Os recursos MTP são necessários para estabelecer chamadas para um CUBE H.323 se o outro endpoint não tiver capacidade de sinalização em comum com o CUCM. Por exemplo, um Cisco Unified IP Phone 7960 que executa a pilha SIP suporta apenas NTEs, portanto um MTP é necessário com um tronco H.323 para que o 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 (CUBE 1.4) do Cisco IOS, foi introduzido o suporte para Interfuncionamento de Tipo de Carga Dinâmica para Pacotes DTMF e Codec para Chamadas SIP para SIP.
Esse recurso permite que o CUBE manipule o entrelaçamento de: tipos de payload dinâmico para codecs de áudio/vídeo, NSE e DTMF; que até esse ponto era limitado porque o Cisco IOS reservaria um intervalo estático e permitiria que apenas os mesmos tipos de payload fossem negociados em ambos os trechos de chamada e rejeitasse a chamada com uma resposta de erro 488 para codecs de áudio/vídeo /NSE incompatíveis (ou fallback para voz na banda G711 DTMF) para payloads NTE incompatíveis. Portanto, o recurso permite que o CUBE cancele a reserva ou libere tipos de payload dinamicamente para o interfuncionamento com provedores SIP ou dispositivos de terceiros que usam uma faixa diferente de tipos de payload para outra perna que não seria compatível ou que requer um mapeamento diferente especificamente.
Um trecho de chamada no CUBE é considerado simétrico ou assimétrico com base no valor do tipo de payload trocado por SDP durante a oferta e a 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 no modo de configuração voice service voip enter sip ou no nível do correspondente de discagem usando a CLI voice-class sip
asymmetric payload {dtmf | dynamic-codecs | full | system}
Para obter mais informações sobre cargas dinâmicas/assimétricas, navegue até Interfuncionamento do tipo de carga dinâmica para pacotes DTMF e codec para chamadas SIP para SIP
Exemplo de Cargas Simétricas
Aqui está um exemplo de como seria a aparência do SDP para uma negociação de payload simétrica e a saída da sessão debug voip rtp chamada event enquanto os tons DTMF estão sendo transmitidos. Observe que a configuração usada para forçar o Cisco IOS pode usar um tipo de payload diferente para eventos NTE que usam o comando rtp payload-type nte.
Negociação de relé DTMF
Transmissão de relé DTMF
Exemplo de Cargas Assimétricas
Aqui está um exemplo de como seria a aparência do SDP para uma negociação de payload assimétrica e a saída do comando debug voip rtp session named event enquanto os tons DTMF estão sendo transmitidos. Observe a configuração usada para forçar o Cisco IOS a usar um tipo de payload diferente para eventos NTE e usa os comandos rtp payload-type nte e a CLI voice-class sip asymmetric payload dtmf.
Negociação de relé DTMF
Transmissão de relé DTMF
Qual método de DTMF Relay usar
Ao escolher o DTMF-relay a ser usado, você precisa levar em consideração essas 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 DTMF Relay Preferenciais para H.323
O método preferido para H323 seria usar OOB através de H.245 alfanumérico ou sinal em quase todos os cenários. Você também pode usar RFC2833 desde que o CUCM não esteja envolvido.
Métodos DTMF Relay Preferenciais para SIP
- Troncos SIP para provedores de serviços - sempre que houver um tronco SIP para um provedor SIP envolvido ou interação com 3rd dispositivos SIP de terceiros ou sistemas IVR, em seguida, em banda através de RFC2833 é preferível.
- 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 vier de um provedor SIP para o sistema CUE.
Informações Relacionadas
Suporte à transcodificação universal de voz para gateways IP para IP
Exemplo de configuração de transcodificação do Unified Border Element
Configurando DTMF Relay Digit-Drop em um Cisco Unified Border Element
Requisitos de MTP de tronco SIP
Método SIP INFO para geração de tom DTMF
Histórico de revisões
| Revisão | Data de publicação | Comentários |
|---|---|---|
2.0 |
15-May-2023 |
Texto Alt e Informações de Plano de Fundo Adicionados.
Introdução atualizada, requisitos de marca, SEO, tradução automática, requisitos de estilo, gerúndios e formatação |
1.0 |
30-Mar-2016 |
Versão inicial |
FeedbackContate a Cisco
- Abrir um caso de suporte
- (É necessário um Contrato de Serviço da Cisco)