O conjunto de documentação deste produto faz o possível para usar uma linguagem imparcial. Para os fins deste conjunto de documentação, a imparcialidade é definida como uma linguagem que não implica em discriminação baseada em idade, deficiência, gênero, identidade racial, identidade étnica, orientação sexual, status socioeconômico e interseccionalidade. Pode haver exceções na documentação devido à linguagem codificada nas interfaces de usuário do software do produto, linguagem usada com base na documentação de RFP ou linguagem usada por um produto de terceiros referenciado. Saiba mais sobre como a Cisco está usando a linguagem inclusiva.
A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.
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.
A Cisco recomenda que você tenha conhecimento destes tópicos
As informações neste documento são baseadas nestas versões de software e hardware
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.
Consulte as Convenções de Dicas Técnicas da Cisco para obter informações sobre convenções de documentos.
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
Métodos de retransmissão DMTF fora da banda suportados
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.
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.
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.
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:
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.
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.
Com esse método, os dígitos são enviados como OOB como mensagens SIP NOTIFY no payload do corpo da mensagem.
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.
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.
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.
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
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.
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.
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
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“
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
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 }
Os endpoints com H.323 V5 podem indicar que suportam RFC2833 através de uma mensagem de capacidade na mensagem TerminalCapabilitySet (TCS).
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" }
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“
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
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
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"/>
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.
O CUBE exige recursos de transcodificação registrados localmente nesses cenários
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.
O CUBE é capaz de interagir entre DTMF G711 de banda interna (tons de áudio bruto) para RFC2833. No entanto, esses requisitos precisam ser atendidos
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.
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.
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.
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.
Esse hardware usa os módulos PVDM-2 para fornecer DSPs.
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.
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
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 .
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.
Essas mensagens SCCP são trocadas entre os recursos CUCM e MTP para o tratamento de DTMF
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
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.
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
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
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.
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.
Ao escolher o relé DTMF a ser usado, você precisa levar em consideração estas variáveis
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.
Suporte à transcodificação de voz universal para gateways IP para IP
Exemplo de configuração de transcodificação de elemento de borda unificado
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