Relé DMTF e colaboração no CUBO

Introdução

Este documento descreve o processo para configurar o relé do Dual Tone Multi-frequency (DTMF) para a empresa do Cisco Unified Border Element (CUBO). Adicionalmente, igualmente fornece a informação e os comandos em como configurar, verificar e pesquisar defeitos o relé DMTF para os protocolos diferentes do Gateway VoIP apoiados pelo CUBO.

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

Pré-requisitos

Requisitos

Cisco recomenda que você tem o conhecimento destes assuntos

• Conhecimento básico dos toms DMTF
• O conhecimento básico de como configurar e usar o Cisco IOS exprime (como o dial peers)
• Conhecimento básico de como configurar e usar o CUBO
• Conhecimento básico da sinalização usada pelo SORVO e pelos protocolos de H323
• Conhecimento básico de como debugar protocolos de VoIP como H323 e SORVÊ-LOS

Componentes Utilizados

A informação neste documento é baseada nestes versão de software e hardware

• Cisco Unified Border Element que é executado em IO
• Gerente 7.x das comunicações unificadas de Cisco ou mais tarde

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 sua rede estiver ativa, certifique-se de que entende o impacto potencial de qualquer comando.

Convenções

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

Métodos apoiados do DTMF-relé para o CUBO

O CUBO apoia uma variedade larga de métodos do relé DMTF para a Em-faixa e o OOB (fora da banda) para os protocolos de sinalização de H.323 e do Session Initiation Protocol (SIP).

Métodos apoiados do relé DMTF da Em-faixa

• audtio DTMF da Em-faixa com o G711
• RFC2833

Métodos fora da banda apoiados do relé DMTF

• H.245 alfanumérico
• Sinal H.245
• O SORVO espontâneo NOTIFICA
• SORVO KPML
• INFORMAÇÃO DO SORVO

Apoio para a Em-faixa DTMF audio com o G711

O áudio da Em-faixa da Voz ou o G711 DTMF referem o transporte dos toms audíveis sobre o fluxo de áudio da Voz, sem nenhuma participação adicional do protocolo de sinalização ou o DSP para sua transmissão a não ser para setup normalmente o atendimento e para passar o End to End audio usando o codec G711Ulaw/Alaw. Isto significa que o CUBE/IOS passa somente o áudio dos tons que vêm de uma extremidade à outro como se é áudio normal da Voz. A medida importante tomar para este método é assegurar-se de que os atendimentos estejam obtendo estabelecidos usando o codec G711Ulaw/Alaw especificamente porque usar um codec que comprima o áudio (algum outro codec do que o G711) distorce os toms DMTF e sejam os tornem provavelmente irreconhecíveis à extremidade de recepção. Isto é porque o algoritmo de compactação utilizado por codecs do grande compactação foi projetado reconhecer e prever a Voz e não toms DMTF humanos.

a Em-faixa audio/G711 DTMF é apoiada com todo o protocolo de sinalização voip e exige somente o codec G711 ser reforçada para os atendimentos fim-a-fim. Um deve igualmente deve manter-se na mente que todo o tratamento transcoding de um codec do low-bit-rate (LBR) ao G711 distorce muito provavelmente os tons também.

Note: É comum para que alguma confusão elevare ao discutir este método do relé DMTF porque a Em-faixa do termo é usada para referir o transporte do DTMF dentro do córrego RTP chamado como Telefonia Nomeado Evento (NTE/RFC2833) e quando é tons audio da Em-faixa. É sempre importante esclarecer o método real exigido/apoiado para aplicar a configuração apropriada e para usar o abordagem de Troubleshooting direito.

Métodos apoiados do DTMF-relé para H323

H.245 alfanumérico

Os dígitos de DTMF são separados do fluxo de voz e enviados através H.245 do canal de sinalização OOB em vez da emissão através do canal RTP. Os tons são transportados em mensagens da indicação da entrada de usuário H.245. O canal de sinalização H.245 é um canal seguro e os pacotes que transportam os toms DMTF são garantidos para ser entregados. Todos os sistemas que são versão 2-compliant de H.323 são exigidos para apoiar o comando dtmf-relay h245-alphanumeric. Contudo, o apoio do comando dtmf-relay h245-signal é opcional.

Sinal H.245

O método OOB que é similar ao H.245 alfanumérico permite a passagem da informação da duração do tom, endereçando desse modo um problema potencial com o método alfanumérico ao colaborar com sistemas do outro fornecedor.

Telefonia Nomeado Evento (NTE) - RFC2833

Este método transporta toms DMTF em uns pacotes RTP separados de acordo com a seção 3 do RFC 2833. O RFC 2833 define formatos dos pacotes RTP NTE usados para transportar dígitos de DTMF, engancha o flash, e os outros eventos da telefonia entre dois valores-limite do par. Com o método NTE, os valores-limite executam a negociação do por-atendimento dos parâmetros do relé DMTF para determinar o valor do tipo de payload para os pacotes RTP NTE e os eventos apoiados do dígito NTE. Em consequência, os toms DMTF são comunicados através dos pacotes RTP com um valor do tipo de payload diferente dos valores negociados para outros pacotes de mídias; qual fornece um método confiável para transportar os dígitos e para os evitar que não estão sendo reconhecidos quando obtiverem comprimidos através do codec usado para codificar o tráfego da Voz, do vídeo ou do fax.

O relé DMTF RFC2833/NTE é considerado um método da Em-faixa porque os dígitos são transportados dentro do tráfego de áudio próprio RTP sem nenhuma participação do protocolo de sinalização GW.

É importante indicar que o método RFC2833/NTE não deve ser confundido com o áudio da Em-faixa da Voz ou o córrego G711 RTP desde que mais atrasados está apenas os toms audíveis que estão sendo passados como áudio normal sem nenhum método da sinalização do relé que é ciente ou involvido no processo. Significa que são apenas tons audio lisos que estão sendo passados fim-a-fim usando o codec G711Ulaw/Alaw.

Alguns outros fatos interessantes sobre o NTE com H323:

• RFC2833 dos apoios de H.323 até à data do V4
• Os IO anunciam sempre seu apoio 2833 no TCS
• CUCM apoia somente o NTE com H.323 ICT.

Cisco RTP proprietário

Com este método os toms DMTF são enviados no mesmo canal RTP que dados de voz. Contudo, os toms DMTF são codificados diferentemente dos exemplos de voz e identificados como o tipo de payload 121, que permite o receptor dos identificar como toms DMTF. Este método não é apoiado por CUCM e seu uso foi interrompido.

Métodos apoiados do DTMF-relé para o SORVO

NTE - RFC2833

os tipos de payload e os atributos do RFC2833 NTE da Em-faixa são negociados entre as duas extremidades na configuração de chamada usando o protocolo session description (SDP) dentro da seção do corpo da mensagem do SORVO.

Espontâneo NOTIFIQUE (o UN)

Com este método os dígitos são enviados a OOB como mensagens NOTIFY do SORVO dentro do payload do corpo da mensagem.

Linguagem de marcação chave da imprensa (KPML)

Baseado no RFC4730, os dígitos são OOB transportados usando o XML dentro das mensagens Subscribe/NOTIFY. É usado na maior parte para os valores-limite do SORVO registrados a CUCM ou a CME mas igualmente com ITSP.

Informação (INFORMAÇÃO)

Os dígitos são retransmitidos como mensagens de informação do SORVO OOB entre as extremidades. Este método não exige nenhuma configuração e é aceitado e relacionado pelo CUBO automaticamente.

Note: A INFORMAÇÃO do SORVO não é apoiada pelo CM unificado.

Note: Quando os métodos UN e NTE são negociados, os IO escolhem sempre o UN sobre o NTE evitar tons dobro e o pacote da Em-faixa 2833 NTE é suprimido. Também, para CUCM, o UN é usado somente quando nenhuma outra opção está disponível. Igualmente, se KPML e o UN estam presente, o Cisco Call Manager (CCM) escolhe KPML sobre o UN.

Configurar o DTMF-relé no CUBO

À revelia, o relé DMTF é desabilitado para ambo o H323 e dial peers do SORVO (à exceção da INFORMAÇÃO do SORVO); é imperativo configurar o método do relé DMTF para ser fim-a-fim usado em ambos os dial peer de entrada e de saída para cada trecho de chamada.

Configurar o relé DMTF 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 pelo dial-peer, segundo as exigências 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 relé DMTF para o SORVO

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 pelo dial-peer, segundo as exigências 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: Adicionar o comando do sorvo do protocolo de sessão sob o dial-peer para que as opções do DTMF-relé do SORVO tornem-se disponível.

Configurar a Dígito-gota do relé DMTF

A fim evitar dígitos duplicados retransmitindo os mesmos dígitos de DTMF através da em-faixa e fora dos métodos da faixa ao pé que parte para os atendimentos que colaboram de uma em-faixa (RTP-NTE especificamente) ao fora do método da faixa, configurar o comando da dígito-gota do DTMF-relé RTP-NTE no dial peer de entrada e o método out-of-band desejado no dial peer de saída. Se não, o mesmo dígito é enviado em OOB assim como em em-faixa e obtém interpretado como dígitos duplicados pela extremidade de recepção.

Quando a opção da dígito-gota é configurada no pé de entrada, o CUBO suprime pacotes NTE e somente dígitos do relé usando o método OOB configurado no pé de partida.

Segundo as indicações desta imagem, a opção da dígito-gota está disponível somente ao colaborar entre estes métodos do relé DMTF.

Por exemplo, configurar o comando da dígito-gota do DTMF-relé RTP-NTE no dial peer de entrada para um pé do SORVO que envia dígitos com o RFC2833 e então no lado de partida de H.323 configurar o DTMF-relé h245-alphanumeric ou o DTMF-relé h245-signal; isto deve conduzir ao CUBO que suprime os pacotes NTE e mandar somente os eventos OOB H245 pelo contrário.

Para mais informação veja a gota do dígito do relé DMTF.

Valide e pesquise defeitos o relé DMTF

Validando o relé DMTF OOB para H323

Propaganda alfanumérica da capacidade H.245

A fim validar se um valor-limite está anunciando a capacidade H.245 alfanumérica, procure esta linha dentro dos recursos de terminal que H.245 a utilização ajustada da mensagem (TCS) debuga o asn1 h245.

capability receiveUserInputCapability : basicString : NULL

Exemplo alfanumérico da transmissão H.245

Está aqui um exemplo de um valor-limite que transmite o dígito 1 usando o H245 que a utilização alfanumérica do método debuga o asn1 h245.

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

Propaganda da capacidade do sinal H.245

A fim confirmar se um valor-limite está anunciando a capacidade do sinal H.245, procure esta linha dentro dos recursos de terminal que H.245 a utilização ajustada da mensagem (TCS) debuga o asn1 h245.

capability receiveUserInputCapability : dtmf : NULL

O H.245 sinaliza o exemplo da transmissão

Este é um exemplo de um valor-limite que transmite o dígito 1 com duração de 100 milissegundos usando o método do sinal H245. Há duas mensagens, a primeira mensagem indica o dígito que está sendo discado com uma duração de 4s. Contudo, o segundo sinal (signalUpdate) atualiza o valor da duração de dígito a 100msec pelo contrário.

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
		      }

Confirme o relé DMTF da Em-faixa para H323

Os valores-limite que têm H.323 V5 podem indicar que apoiam o RFC2833 através de uma mensagem da capacidade dentro da mensagem de TerminalCapabilitySet (TCS).

Propaganda do apoio da capacidade do RFC2833

A fim confirmar se um valor-limite está anunciando a capacidade do RFC2833, procure esta estrutura dentro da utilização da mensagem H.245 TCS debugam o asn1 h245 (no tipo de payload do exemplo 101 está sendo anunciado para os eventos de 0 a 16).

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

Valide o relé DMTF OOB para o SORVO

Espontâneo NOTIFIQUE o exemplo da propaganda (UN)

A fim confirmar se um valor-limite está anunciando o espontâneo NOTIFIQUE a capacidade (UN), procuram esta linha dentro do mensagem INVITE e/ou os mensagens de resposta à utilização do CONVITE debugam mensagens de ccsip.

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“

Espontâneo NOTIFIQUE o exemplo da transmissão (UN)

O método UN transmite os dígitos como dados binários dentro da mensagem NTFY; assim você não poderá ver que que dígito está sendo transportado usando debugar mensagens de ccsip. Você precisará uma captura de pacote de informação (PCAP) ou terá que ser executado debuga o comando all do ccsip ver o dígito dentro das saídas de dados binários.

O exemplo de como o mesmo dígito 7 discado olharia como ao ser executado debuga o comando all do ccsip.

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

Exemplo chave da propaganda do linguagem de marcação da imprensa (KPML)

A capacidade KPML está listada dentro do encabeçamento do SORVO dos Permitir-eventos. Para transmissões do dígito KPML, o valor-limite transmissor precisa de enviar primeiramente uma assinatura ao serviço KPML; O mensagem de SUBSCRIBE que pede a capacidade é transmitido; seguido por um mensagem NOTIFY da extremidade de recepção que marca o assinatura-estado para os eventos KPML como o active.

A inicial CONVIDA o anúncio da capacidade.

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

A extremidade de terminação pede a assinatura aos eventos KMPL.

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

A extremidade origem responde com uma NOTIFICAÇÃO que ajusta o estado ao active.

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

Exemplo da transmissão KPML

Depois que a assinatura ocorreu, os valores-limite podem transmitir os dígitos usando mensagens NOTIFY com eventos KPML com o XML. Exemplo do dígito 1 que está 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"/> 

DTMF que colabora

Apoios do CUBO em torno de 30 tipos diferentes de DTMF que colaboram. Pode colaborar e transcode entre os métodos diferentes do relé baseados no comando dtmf-relay configurado dentro dos dial peer de entrada e de saída combinados para o atendimento.

Refira a seção da tabela da Interoperabilidade DTMF do manual de configuração do CUBO para detalhes no apoio de colaboração DTMF. 

Quando o CUBO exige recursos transcoding para o DTMF?

O CUBO exige os recursos transcoding registrados localmente nestas encenações

• Colaboração entre o RFC2833 e a Em-faixa da Voz
• Colaboração entre um método OOB e o RFC2833 para fluxo-em torno de atendimentos

O CUBO pode colaborar por fluxo entre todos métodos restantes do relé DMTF com atendimentos sem a necessidade de um transcodificador.

DTMF que colabora entre o G711 Inband ao RFC2833

O CUBO pode colaborar entre G711 Inband DTMF (tons audio crus) ao RFC2833. Contudo, estas exigências precisam de ser cumpridas

• O codec usado deve ser G711 fim-a-fim. Esta é uma limitação porque se um codec LBR devia ser usada então os tons obteriam distorcido devido à perda da compressão.
• Os recursos Transcoding devem ser disponíveis e registrados com o CUBO em conformidade. Isto porque o CUBO precisa de atribuir um recurso transcoding (mais especificamente: uns recursos de DSP) ao córrego dos media RTP para injetar ou escutar tons dentro do fluxo de áudio.
• O dial-peer para o pé dos inband-tons não deve ter nenhum comando dtmf relay configurado.
• O dial-peer para o pé do RFC2833 deve ter o DTMF-relé RTP-NTE configurado.
• Não permita a dígito-gota em algum do dial peers envolvido com o atendimento.

Outras opções de colaboração DTMF

Há igualmente um grupo adicional de comandos de colaboração que poderiam ser exigidos em cenários de chamada específicos; qual pode ser configurado globalmente ou no dial-peer em nível.

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 de MTP são exigidos por CUCM?

Os recursos de MTP transformam-se quando CUCM precisa de colaborar métodos diferentes DTMF entre dois dispositivos, o necessário deles que usam o método do RFC2833 especificamente e o outro um método OOB. Nesta encenação, o CUCM precisa de atribuir os recursos necessários para transmitir e/ou detectar os toms in-band devido à má combinação do relé DMTF entre as duas extremidades.

O papel do MTP é monitorar o tráfego RTP e detectar eventos NTE do pé do RFC2833 ou injetar os eventos NTE no RTP fluem se pedido pelo CUCM. Se o MTP detecta os eventos de entrada NTE do valor-limite que apoiam somente o RFC2833 então ele envia um SCCP StationNOTIFYDtmfToneMessage ao CUCM que informa o do tom que esteve detectado no córrego. O CUCM envia por sua vez o mesmo dígito usando o protocolo de sinalização (OOB) à outra extremidade. Se o CUCM recebe um sinal OOB DTMF do valor-limite OOB DTMF então envia um SCCP StationSendDtmfToneMessage ao MTP de modo que o MTP possa injetar o tom pedido no córrego RTP sob a forma dos eventos NTE.

Dispositivos MTP apoiados por CUCM

Software MTP (aplicativo fluente das mídias de voz IP de Cisco)

O software MTP é um dispositivo que seja executado permitindo o aplicativo fluente das mídias de voz IP de Cisco em um server CUCM. Quando o aplicativo instalado é configurado como um aplicativo MTP, registra-se com um nó CUCM e informa-se CUCM de quantos recursos de MTP apoia. Córregos de G.711 dos suportes do dispositivo do software Um MTP somente. As configurações padrão de CUCM permitem que segure até 48 atendimentos conforme pelo software MTP. Para detalhes em como alterar os parâmetros de serviço, refira a versão apropriada do guia da administração do gerenciador das comunicações unificadas de Cisco.

Software MTP (baseado no Cisco IOS)

Este MTP permite a configuração de qualquens um codecs, porém somente um pode ser Mu-law em um dado momento configurado e a-law de G.711, G.729a, G.729, G.729ab, G.729b, e transmissão. Alguma destes não é pertinente a uma aplicação CUCM.

As configurações de roteador permitem até 1,000 córregos individuais, que apoiam 500 sessões transcoded que gerencie os Mbytes 10 do tráfego. Cisco ISR G2 e roteadores ASR pode apoiar uns números significativamente mais altos do que este.

Este MTP consome ciclos de CPU para operar-se. Faça uma anotação do número de sessões permitidas como ele poderia impactar a utilização elevada da CPU do desempenho e do disparador do CPU.

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

Este hardware usa os módulos PVDM-2 fornecendo DSP.

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

Este Roteadores usa o PVDM3 DSP nativamente nos cartões-matrizes ou no PVDM2 com um adaptador no cartão-matriz ou nos módulos de serviço.

Note: Você não pode configurar G.729 ou G.729b ao configurar recursos de MTP do hardware no Cisco IOS. Contudo, o CM unificado pode usar recursos transcoding do hardware como MTP se todos recursos de MTP restantes são esgotados ou de outra maneira não disponível.

Quando usar o software ou o hardware MTP?

O tipo de MTP a distribuir em sua rede depende dos parâmetros codec específicos apoiados pelos valores-limite, pelos gateways e pelos troncos no fluxo de chamadas

• Os sabores do codec a ser usados
• O tamanho do pacote do codec a ser usado (empacotamento)
• T.38 que envia o uso (exige o codec Passagem-através do apoio)

Baseado nestes parâmetros você pode com segurança escolher e distribuir os recursos corretos exigidos por sua rede.

Segundo as indicações da tabela, as características diferentes apoiadas por tipos diferentes MTP e de transcodificador

Para obter mais informações sobre da configuração MTP em CUCM refira por favor o exemplo de configuração do Media Termination Point.

Grupo dos recursos de mídia CUCM (MRG) e de lista do grupo dos recursos de mídia considerações (MRGL) para o MTP

Ao criar e ao atribuir recursos de mídia aos grupos dos recursos de mídia (MRG) e às lista do grupo dos recursos de mídia (MRGL), tome alguns pontos adicionais à consideração para evitar a assinatura em excesso dos melhores recursos para fluxos de chamadas específicos e para lhes dar a prioridade em conformidade, porque CUCM é incapaz de escolher o melhor dispositivo para se usar, ao selecionar uns recursos de mídia para um atendimento, de uma lista dada de MTP e de transcodificadores se têm a mesma prioridade ou a pedem. Em lugar de, escolhe o primeiro dispositivo que apoia as capacidades pedidas. Assim mesmo se o atendimento está usando o G711 em ambos os pés, se o primeiro dispositivo que encontra é um transcodificador então o atribui enquanto um MTP para o atendimento e para não procurar uma pena mais adicional dos recursos de MTP a lista.

Um outro comportamento similar ocorre quando você tem transcodificadores universais e regulares. O CUCM poderia usar os transcodificadores regulares primeiramente em um atendimento onde um dos pés fosse G711, e então falhar quando um atendimento obtém transferido a um destino que usasse um codec do non-G711, porque o CUCM não está indo liberar o transcodificador atual e obter outro quando o atendimento é transferido.

A melhor prática do projeto obter em torno deste comportamento é atribuir todos os dispositivos MTP-somente em um único MRG, então os transcodificadores universais a um outro MRG e os transcodificadores regulares a um terceiro MRG; e dê-lhes a prioridade então que a mesma ordem dentro do MRGL. Agora, este projeto não pode trabalhar para cada topologia e deve ser revisto em uma base da caso-por-base.

Mensagens SCCP MTP

Estes mensagens de SCCP são trocados entre o CUCM e os recursos de MTP pela manipulação DTMF

•  StationCapabilitiesRes
•  StationUpdateCapabilities
•  StationSubscribeDtmfPayloadReq
•  StationSubscribeDTMFPayloadErrv
•  StationSubscribeDtmfPayloadRes
•  StationUnsubscribeDtmfPayloadErr
•  StationNOTIFYDtmfToneMessage
•  StationSendDtmfToneMessage
•  StationUnsubscribeDtmfPayloadReq
•  StationUnsubscribeDtmfPayloadRes

Tronco do SORVO CUCM A CUBAR

O CUBO apoia KPML, NTE, ou espontâneo notifique como o mecanismo DTMF, segundo sua configuração. Porque pode haver uma mistura de valores-limite no sistema, os métodos múltiplos podem ser configurados no CUBO simultaneamente a fim minimizar exigências MTP.

No CUBO, configurar o sorvo-kpml e o RTP-NTE como métodos do relé DMTF sob dial peer do SORVO. Esta configuração permite a troca DTMF com todos os tipos de valores-limite, incluindo aqueles que apoiam somente o NTE e aqueles que apoiam somente métodos OOB, sem a necessidade para recursos de MTP. Com esta configuração, o gateway negocia o NTE e o KPML com o CUCM. Se o NTE não é apoiado pelo valor-limite unificado CM, a seguir KPML está usado para a troca DTMF. Se ambos os métodos são negociados com sucesso, a seguir o gateway confia no NTE para receber dígitos e não subscreve a KPML.

O CUBO igualmente tem a capacidade para usar espontâneo notifica o método (UN) para o DTMF. O método UN envia um SORVO notifica a mensagem com um corpo que contenha o texto que descreve o tom DMTF. Este método igualmente está apoiado no CM unificado e pode ser usado se o sorvo-kpml não está disponível. Configure sorvo-notifica como o método do relé DMTF. Note que este método é proprietário de Cisco.

Os cubos configurados para somente o relé NTE, ou essa dívida a alguma limitação de colaboração, podem somente fornecer o NTE e os recursos de MTP exigidos a ser atribuídos no lado CUCM ao comunicar-se com os valores-limite que não apoiam o NTE.

Você pode encontrar mais informação em exigências do tronco MTP do SORVO CUCM

Tronco CUCM H323 A CUBAR

CUCM escolhe dinamicamente o método do transporte DTMF para troncos de H323; tão não há nenhuma opção configurável escolher um sobre o outro. Se você quer forçar um método específico do relé DMTF, a seguir você pode fazer assim da configuração de dial peer do CUBO para este tronco.

Mesmo quando os cubos de H323 apoiam o NTE, a opção NTE não deve ser usada porque não é apoiada em CUCM para Gateways H.323/troncos neste tempo; assim CUCM não anuncia esta capacidade no momento em que as capacidades dos media H245 são trocadas. A opção preferida Do CUCM é o sinal H.245.

Os recursos de MTP estão exigidos estabelecendo atendimentos a um CUBO de H.323 se o outro valor-limite não tem a potencialidade de sinalização em comum com CUCM. Por exemplo, Cisco unificou o telefone IP 7960 que executa os apoios somente NTE da pilha do SORVO, assim que um MTP é precisado com um tronco de H.323 assim que o H245 alfanumérico pode ser usado no pé de H323.

Cargas úteis dinâmicas/assimétricas do CUBO

Até à data do apoio da Versão do IOS 15.1(1)T (CUBO 1.4) para o tipo de payload dinâmico colaborar para o DTMF e os pacotes do codec para que o SORVO SORVA atendimentos foi introduzida.

Esta característica permite que o CUBO segure a colaboração de: tipos de payload dinâmicos para codecs audio/video, NSE e DTMF; qual até este ponto era limitado porque os IO reservariam uma escala estática e permitiriam somente que os mesmos tipos de payload fossem negociados em ambos os trechos de chamada e rejeitariam o atendimento com uma resposta de erro 488 para que codecs audio/video da combinação errônea de /NSE (ou a reserva exprima G711 inband DTMF) para combinar mal cargas úteis NTE. Consequentemente, a característica permite a un-reserva do CUBO ou os tipos de payload livres dinamicamente a colaboração com fornecedores ou dispositivos de terceiros do SORVO que usam uma escala diferente dos tipos de payload a um outro pé que não os apoiem ou que exigisse um traço diferente especificamente.

Um trecho de chamada no CUBO é considerado ser simétrico ou assimétrico baseado no valor do tipo de payload trocado com o SDP durante a oferta e a resposta com o valor-limite

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

Este comando está disponível para especificar o uso de cargas úteis assimétricas; o comando pode ser aplicado globalmente sob o serviço de voz que o voip incorpora o modo de configuração do sorvo ou no dial-peer em nível usando o sorvo CLI da Voz-classe

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

Para obter mais informações sobre cargas úteis dinâmicas/assimétricas satisfaça navegam ao tipo de payload dinâmico que colabora para o DTMF e os pacotes do codec para que o SORVO SORVA atendimentos

Exemplo simétrico das cargas úteis

Está aqui um exemplo de como o SDP olharia como para uma negociação simétrica do payload e a saída da sessão do rtp do voip debugar nomeou o evento quando os toms DMTF forem transmitidos. Note por favor que a configuração usada para forçar os IO deve usar um tipo de payload diferente para eventos NTE usando o comando do nte do tipo de payload do rtp.

Negociação do relé DMTF

Transmissão do relé DMTF

Exemplo assimétrico das cargas úteis

Está aqui um exemplo de como o SDP olharia como para uma negociação assimétrica do payload e a saída da sessão do rtp do voip debugar nomeou o comando event quando os toms DMTF forem transmitidos. Note por favor a configuração usada para forçar os IO para usar um tipo de payload diferente para eventos NTE usando os comandos do nte do tipo de payload do rtp e o dtmf assimétrico CLI do payload do sorvo da Voz-classe.

Negociação do relé DMTF

Transmissão do relé DMTF

Que método do relé DMTF a se usar?

 Ao escolher o DTMF-relé usá-lo precise de tomar na consideração estas variáveis

• Dispositivos e Plataformas envolvidos
• Protocolos de VoIP envolvidos
• Trajeto dos media e codecs apoiados
• Métodos apoiados ou preferidos do relé DMTF

Métodos preferidos do relé DMTF para H.323

O método preferido para H323 estaria usando OOB com o H.245 alfanumérico ou sinal quase em todos os cenários. Você pode igualmente usar o RFC2833 enquanto CUCM não é involvido.

Métodos preferidos do relé DMTF para o SORVO

• SORVA troncos aos provedores de serviços - sempre que há um tronco do SORVO a um fornecedor do SORVO envolvido ou a interação com os dispositivos do SORVO da 3ª parte ou a em-faixa dos sistemas IVR com o RFC2833 é preferida então.
• SORVA o tronco a CUCM ou a CME - permita o RFC2833 e o KPML.
• SORVA o tronco PARA CUE - o método padrão para a SUGESTÃO é UN mas você pode igualmente configurar-lo para usar o NTE; qual é igualmente a melhor opção se o atendimento vem de um fornecedor do SORVO ao sistema da SUGESTÃO.

Informações Relacionadas

Apoio Transcoding da Voz universal para os gateways IP-à-IP

Conversão DTMF

Exemplo de configuração Transcoding unificado do elemento da beira

Usando o gerente das comunicações unificadas de Cisco para configurar Transcoding e Media Termination Point

Configurando a Dígito-gota do relé DMTF em um Cisco Unified Border Element

Exigências do tronco MTP do SORVO

Método da INFORMAÇÃO do SORVO para a geração do tom DMTF

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

Relação Transcoding local do CUBO 9.0 (LTI)