Explicar o roteamento de chamadas do Cisco IOS e IOS XE

Introdução

Este documento descreve uma explicação do roteamento de chamadas do Cisco IOS® e do Cisco IOS XE.

Pré-requisitos

Requisitos

Embora não haja pré-requisitos formais necessários para ler este documento, ele é escrito com a expectativa de que o leitor já tenha algum conhecimento dos protocolos subjacentes de sinalização de voz que são usados para estabelecer e conectar chamadas telefônicas. Esses protocolos são referenciados várias vezes ao longo do processo.

Protocolos de sinalização: Session Initiation Protocol (SIP), H323 (h225 / h245), Media Gateway Control Protocol (MGCP), Skinny Client Control Protocol (SCCP), ISDN Q931, E1 R2.

Protocolos de mídia: Real Time Protocol (RTP), codecs de voz, codecs de vídeo.

Tecnologias analógicas: Ear and Mouth (E&M), Foreign Exchange Subscriber (FXS) e Foreign Exchange Office (FXO).

Componentes Utilizados

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

• Gateways Cisco IOS e IOS XE
• 2800 / 3800 / 2900 / 3900 / 4300 / 4400 / CSR1000v / CAT8000v / ASR100X / C8200 / C8300 / ISR1100

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.

Informações de Apoio

Este documento aborda os mecanismos por trás da correspondência de peer de discagem de entrada e saída com trechos de chamada de Rede de Serviço Telefônico Tradicional Comum (POTS - Plain Old Telephone Service) e Voz sobre IP (VoIP - Voice over IP).

Além das informações do dial-peer, este documento aborda tópicos importantes que pertencem ao roteamento de chamadas. Isso inclui manipulação de dígitos, uma rápida visão geral da manipulação de mensagens do Session Initiation Protocol (SIP), alguns métodos para restringir os recursos de chamada, uma rápida visão geral de vinculação de sinalização e mídia e, finalmente, um pouco de solução de problemas.

Este documento utiliza exemplos de configuração, bem como saídas dos comandos debug e show como pontos de referência. Os vários recursos neste documento estão claramente marcados com a versão que o recurso foi introduzido no Cisco IOS e no Cisco IOS XE. Essas informações também podem ser consultadas rapidamente na seção Command and Feature Roadmap. Se há um defeito muito notável, ele é vinculado dentro do texto para que os leitores estejam cientes.

Definições comuns

Roteiro de comandos e recursos

Fundamentos de roteamento de chamadas do Cisco IOS / Cisco IOS XE

Os gateways Cisco IOS e Cisco IOS XE utilizam um conceito de peer de discagem para controlar o roteamento de chamadas e a negociação de recursos para cada trecho de uma chamada. Um leg da chamada é a comunicação bidirecional entre dois agentes de chamadas. Um agente de chamadas é um dispositivo que inicia, processa ou encaminha chamadas telefônicas. Isso pode ser e não está limitado ao equipamento do provedor de telefonia, um gateway Cisco, um telefone IP, um Cisco Unified Communication Manager (CUCM), conexão Cisco Unity (CUC), etc. Há muitos agentes de chamadas para listar.

Cenário: uma chamada chega a um gateway Cisco de outro agente de chamadas e é o trecho da chamada de entrada (no trecho). O gateway processa a chamada e, com base em seu processamento, envia a chamada para o próximo agente de chamada. Este é o trecho de chamada de saída (trecho de saída).

A imagem 1 mostra uma chamada do roteamento PSTN para CUCM por meio de um gateway de voz Cisco e as respectivas informações de trecho de chamada de entrada e de saída.

Imagem 1 - Trechos de chamada de entrada e saída ilustrados

Uma chamada bem-sucedida por meio de um Gateway Cisco SEMPRE (consulte a observação) corresponde a um correspondente de discagem de entrada ou de saída para rotear corretamente. Os peers de discagem de entrada e de saída são semelhantes aos trechos de chamada mencionados anteriormente. Na Imagem 1, a chamada chega do PSTN no gateway Cisco e precisa corresponder a um peer de discagem de entrada. Em seguida, o gateway utiliza um peer de discagem de saída para rotear a chamada para o próximo agente de chamada. É importante lembrar que esses termos são definidos da perspectiva do Cisco Gateway.

Ao fazer a correspondência de um correspondente de discagem para cada lado da chamada, um administrador tem o poder de controlar muitos aspectos de cada segmento de chamada específico. Exemplos disso incluem codecs de voz, preferências DTMF, manipulação de dígitos, onde a chamada deve ser roteada e muitas outras configurações. Os peers de discagem podem ser configurados com instruções de correspondência de entrada e de saída, portanto a correspondência do mesmo peer de discagem para o trecho de entrada e o trecho de saída será possível se uma configuração de correspondência de entrada e de saída válida for aplicada a esse peer de discagem específico.

A Imagem 2 ilustra os mesmos trechos de chamada de entrada e de saída que a Imagem 1, mas com os correspondentes de discagem para uma chamada do roteamento PSTN para CUCM por meio de um gateway de voz Cisco.

Imagem 2 - Peers de discagem de entrada e de saída ilustrados

Os Cisco Voice Gateways podem interagir com muitos tipos diferentes de chamadas de voz e protocolos, incluindo IP para IP, POTS para POTS e IP para POTS ou vice-versa.

A Imagem 3 ilustra uma chamada VoIP para VoIP através do Cisco Unified Border Element (CUBE).

Imagem 3 - Peers de discagem de entrada e de saída para uma chamada VoIP para Voip

A imagem 4 exibe uma chamada POTS para POTS através de um gateway Cisco.

Imagem 4 - Peers de discagem de entrada e de saída para uma chamada POTS para POTS

Tipos de correspondentes de discagem de voz

Observação: o número máximo de peers de discagem que podem ser configurados em um gateway Cisco depende da memória disponível (DRAM). Cada peer de discagem consome aproximadamente 6KB de memória, portanto, certifique-se de que o gateway tenha pelo menos 20% da memória total reservada para outros processos da CPU. Um grande número de correspondentes de discagem configurados pode ser adicionado ao atraso para rotear uma chamada. Isso pode ser significativo à medida que o aplicativo de voz da Cisco procura os peers de discagem de cima para baixo, semelhante a uma ACL (Access Control List, lista de controle de acesso). Normalmente, isso não é um problema em gateways Cisco mais novos.

Exemplo de erro:

May 26 12:59:46.406: %DIALPEER_DB-3-ADDPEER_MEM_THRESHOLD: Addition of dial-peers limited by available memory

Correspondência de Peer de Discagem de Entrada

Quando um Gateway Cisco recebe uma solicitação de configuração de chamada, o gateway começa a procurar um correspondente de discagem de entrada aplicável para essa chamada. Essa não é uma análise dígito por dígito; em vez disso, a mensagem completa é utilizada para determinar qual peer de discagem de entrada é selecionado. A ordem dos itens na mensagem verificada depende muito do protocolo da chamada, conforme indicado pelas listas de preferências definidas na Tabela 1, Tabela 2 e Tabela 3. Um peer de discagem só precisa satisfazer uma das condições de correspondência. Não é necessário que todos os atributos sejam configurados no peer de discagem ou que cada atributo corresponda às informações de configuração de chamada. Todos os correspondentes de discagem são pesquisados com base nos primeiros critérios de correspondência. O gateway passa para o próximo critério somente se nenhuma correspondência for encontrada.

Tabela 1. Preferência de Seleção de Ponto de Discagem SIP de Entrada

Observação: os correspondentes de discagem de entrada qualificados podem ser filtrados por VRF ou Locatário. se o recurso aplicável estiver configurado. Para obter mais informações, consulte as seções Virtual Routing and Forwarding (VRF) e Dial-Peer Hunting e Voice Class Tenants .

Tabela 2. Preferência de seleção de peer de discagem H323 de entrada

Tabela 3. Preferência de Seleção de Ponto de Discagem POTS de Enbloc de Entrada

Quando não há correspondências / Correspondente de discagem padrão 0 peer_tag=0, pid:0

Quando não há correspondências qualificadas para um peer de discagem de entrada para chamadas POTS ou VoIP, o gateway aloca o peer de discagem 0. Isso não é ideal, pois o correspondente de discagem 0 tem recursos limitados e pode causar problemas com as chamadas. O ponto negativo disso são os protocolos SCCP e MGCP que não usam correspondentes de discagem para rotear chamadas. Consulte a seção MGCP e SCCP para obter mais detalhes.

recursos do dial-peer 0

• Sem mecanismos de retransmissão dtmf.
• Anunciados todos os codecs de voz para chamadas VoIP.
• Voz com taxa de fax.
• A Detecção de Atividade de Voz (VAD - Voice Activity Detection) está ativada.
• Sem suporte a RSVP.
• Não há suporte de aplicativo IVR para chamadas POTS.
• A discagem interna direta está ativada.
• Não suporta VRF.

Correspondência de Peer de Discagem de Saída

Os peers de discagem de saída são utilizados para rotear chamadas POTS ou VoIP do gateway para o próximo agente de chamada. Como a correspondência de peer de discagem de entrada, há uma lista de itens que o gateway pode usar para corresponder peers de discagem com base na ordem de preferência para o protocolo específico. No entanto, ao contrário dos peers de discagem de entrada, se não houver nenhum peer de discagem de saída qualificado para rotear a chamada, a chamada falhará. Como a correspondência de peer de discagem de entrada, todos os peers de discagem são pesquisados com base nos critérios de primeira correspondência. O gateway passa para o próximo critério somente se nenhuma correspondência for encontrada.

Tabela 4. Preferência de Seleção de Ponto de Discagem SIP de Saída

Tabela 5. Preferência de seleção de dial peer H323 de saída

Tabela 6. Preferência de Seleção de Ponto de Discagem POTS de Saída

Observação: as seções Number String Dial-Peer Hunting e URI Dial-Peer Hunting vão para como o gateway avalia uma lista de comandos potenciais para cada linha de critérios de correspondência antes de passar para o próximo critério de correspondência. Por exemplo, ele avalia todas as possíveis correspondências destination-pattern e os comandos destination e164-pattern-map matching antes de examinar os comandos do número de chamada.

Busca de correspondente de discagem de cadeia de caracteres de número

Preferência de string numérica:

Assim como os URIs têm uma ordem específica de operações para avaliar correspondências, também há um conjunto de regras usadas ao avaliar uma sequência de dígitos numéricos. O esquema de busca de peer de discagem padrão para um gateway Cisco é definido como 0. Isso significa que o gateway procura um padrão com a correspondência mais longa (mais específica). Se houver dois peers de discagem com o mesmo comprimento de correspondência, o gateway examinará a preferência de peer de discagem explicitamente definida. Por fim, se ambos forem iguais, ele escolhe um em ordem aleatória.

Há outros esquemas de busca de peer de discagem disponíveis para configuração; no entanto, a maioria das implantações mantém o padrão de 0.

Dica: se os peers de discagem estiverem sendo combinados fora da ordem padrão, um administrador pode examinar a configuração atual para um esquema de busca de peer de discagem não padrão.

Gateway(config)# dial-peer hunt ?
  <0-7>  Dial-peer hunting choices, listed in hunting order within each choice:
  0 - Longest match in phone number, explicit preference, random selection.
  1 - Longest match in phone number, explicit preference, least recent use.
  2 - Explicit preference, longest match in phone number, random selection.
  3 - Explicit preference, longest match in phone number, least recent use.
  4 - Least recent use, longest match in phone number, explicit preference.
  5 - Least recent use, explicit preference, longest match in phone number.
  6 - Random selection.
  7 - Least recent use.

Cenário: Os correspondentes de discagem qualificados foram configurados com essas correspondências possíveis, e o gateway está avaliando uma sequência de caracteres de dígito de 2001. O correspondente de discagem 1 pode corresponder a qualquer número de 2000 a 2999, enquanto o correspondente de discagem 2 pode corresponder a 2000 a 2009. O correspondente de discagem 2 seria correspondido para essa chamada, pois é a correspondência mais longa (mais específica) para a string de dígito 2001 quando o mecanismo de busca do correspondente de discagem padrão é empregado (busca do correspondente de discagem 0). Em outras palavras, a sequência de números 200 é a maior sequência que corresponde exatamente a uma sequência de números na sequência numérica 2001.

!
dial-peer voice 1 voip
 destination-pattern 2...
!
dial-peer voice 2 voip
 destination-pattern 200.
!

A preferência é definida como o peso definido pelo administrador para cada correspondente de discagem. Os administradores podem configurar uma preferência para que a chamada sempre use um correspondente de discagem específico antes dos outros. Por padrão, todos os peers de discagem são preferidos como 0. Um peer de discagem com preferência 0 é correspondido antes de outro peer de discagem com preferência de 1 a 10. A maioria dos administradores configura vários peers de discagem para enviar uma chamada para um assinante CUCM específico com um assinante de backup ou outro agente de chamada sendo configurado usando outro peer de discagem com uma preferência mais baixa (que é configurada com um número maior).

Cenário: Dois peers de discagem são configurados com o mesmo comprimento de correspondência para a sequência de caracteres de dígito de 2001. O administrador define uma preferência explícita. O gateway avalia os dois peers de discagem da mesma forma, já que seu comprimento de correspondência é o mesmo. No entanto, o administrador define o correspondente de discagem 1 com uma preferência mais alta, de modo que o correspondente de discagem seja escolhido como o primeiro correspondente de discagem usado no roteamento da chamada. O correspondente de discagem 2 permaneceria como uma opção secundária caso ocorresse uma falha no primeiro correspondente de discagem.

!
dial-peer voice 1 voip
 destination-pattern 2...
 preference 1
!
dial-peer voice 2 voip
 destination-pattern 2...
 preference 2
!

Um gateway Cisco tenta rotear uma chamada apenas por meio de um peer de discagem de saída qualificado de cada vez. Se uma condição de falha for observada no primeiro peer de discagem selecionado, o gateway tentará rotear a chamada para o próximo peer de discagem qualificado. Isso continua até que a chamada seja bem-sucedida ou falhe, pois não há mais correspondentes de discagem qualificados para tentar. Um sintoma comum de caçada e falha do peer de discagem é um atraso notável no retorno de chamada durante as chamadas. As depurações geralmente são necessárias para verificar exatamente por que a chamada está falhando em um determinado peer de discagem. O comando huntstop pode ser empregado em um peer de discagem se um administrador não quiser que um gateway procure outro peer de discagem quando uma condição de falha for observada.

Cenário: Dois peers de discagem são configurados com o mesmo comprimento de correspondência para a sequência de caracteres de dígito de 2001. O administrador definiu uma preferência explícita e não deseja corresponder o correspondente de discagem 2 para essa chamada específica. Como há dois peers de discagem com o mesmo comprimento de correspondência, a preferência é usada para determinar o peer de discagem. O correspondente de discagem 1 tem o menor número de preferência configurado, portanto, é usado para rotear a chamada. Se ocorrer uma condição de falha no trecho da chamada de saída usando o correspondente de discagem 1, o gateway interromperá imediatamente a busca do correspondente de discagem, já que o comando huntstop está configurado. Neste cenário, o peer de discagem 2 nunca é utilizado para roteamento de saída. 

!
dial-peer voice 1 voip
 destination-pattern 2...
 preference 1
 huntstop
!
dial-peer voice 2 voip
 destination-pattern 2...
 preference 2
!

Observação: os comandos huntstop e preference também podem ser usados em conjunto com instruções de correspondência de URI, pois são comandos de configuração de dial peer gerais. Além disso, as configurações de grupo de servidores de classe de voz podem utilizar os comandos huntstop na versão 17.4.1a. Consulte a seção Destination Server-Groups para obter mais detalhes sobre isso.

Busca de correspondente de discagem URI

O gateway examina cada critério de correspondência e o esgota antes de passar para o próximo critério de correspondência. Um exemplo disso seria em uma chamada SIP de entrada. Com base na Tabela 1. Preferência de seleção de ponto de discagem SIP de entrada, a primeira coisa que o gateway Cisco verifica é o URI e avalia todos os comandos URI em potencial para encontrar um que se encaixe. Se não houver correspondência ou se nenhuma estiver configurada, o gateway passará para o próximo item correspondente e executará uma avaliação com base nesses critérios. Esse processo se repete até que a chamada seja roteada com base em uma correspondência ou o gateway fique sem critérios de correspondência para verificar.

Quando um peer de discagem de entrada ou de saída é configurado com um comando URI, o gateway examina o URI que foi recebido em vários cabeçalhos para uma correspondência potencial. A preferência de correspondência se baseia na correspondência mais específica e a preferência exata se transforma em Correspondência completa de URI, Porção de host, Porção de usuário ou URI de telefone. Conhecer a ordem das operações para correspondência de URI pode ajudar muito na correspondência de peer de discagem com implantações SIP e CUBE.

Essa ordem de preferência pode ser manipulada usando o comando voice class uri sip preference para especificar o user-id como a primeira opção em vez de host.

Preferência de URI:

1. A parte de Host do URI. Exemplos: (@a.b.c.d ou @host.domain.name)
2. A parte do Usuário do URI. Exemplos: (sip:8675309 ou sip:user)
3. O tele-uri. Exemplo: (tel:18005532447)
4. Correspondência exata para o URI completo. Exemplos: (user@host.domain.name, user@a.b.c.d, 8675309@host.domain.name, 8675309@host.domain.name)

Documento de suporte: Guia de configuração do Cisco Unified Border Element - Cisco IOS XE 17.6 em diante

Cenário: um administrador configurou esses peers de discagem e envia uma chamada para o gateway. O cabeçalho De no Convite recebido é De: <sip:testuser@10.10.10.10>. O gateway pode corresponder potencialmente dois peers de discagem diferentes com base nesse cabeçalho. Dial-Peer 1 baseado na parte do usuário e dial-peer 2 baseado na parte do host. No entanto, como uma correspondência de host é uma preferência sobre uma correspondência de usuário, o peer de discagem 2 é usado para o peer de discagem de entrada na chamada.

!
voice class uri URI1 sip
 user-id testuser 
!
voice class uri URI2 sip
 host ipv4:10.10.10.10
!
dial-peer voice 1 voip
 sess protocol sipv2
 incoming uri FROM URI1
!
dial-peer voice 2 voip
 sess protocol sipv2
 incoming uri FROM URI2
!

URI de Classe de Voz 

A correspondência de URI para correspondentes de discagem de entrada e saída permite ao administrador a capacidade e a flexibilidade de executar correspondências em mais de uma sequência de números de telefone para protocolos VoIP que suportam URIs em suas mensagens. Antes do IOS 15.4(1)T e do IOS-XE 3.11S, uma URI de solicitação tinha que conter um user@host alfanumérico; caso contrário, um gateway Cisco rejeitaria a chamada com uma mensagem 4xx. Agora um URI pode conter apenas a parte do host e o gateway roteia a chamada com base apenas no host fornecido. Por exemplo, sip:cisco.com.

Além disso, antes do IOS 15.4(1)T e do IOS-XE 3.11S as IDs de usuário URI de classe de voz só podiam ser valores numéricos e.164 (sip:1234@host.com). Isso foi alterado para que os administradores possam configurar IDs de usuário alfanuméricos no CUBE (sip:user@host.com).

A parte do host ou do usuário de um uri de classe de voz pode conter padrões de expressões regulares (regex) que expandem muito os valores possíveis que podem ser correspondidos.

Gateway(config-voice-uri-class)# user-id .)
% unmatched ()user-id pattern can be of format ^([][0-9A-Za-z\|\/()*+^$&?#--.])*$

Gateway(config-voice-uri-class)# host .)
% unmatched ()host pattern can be of format ^([][0-9A-Za-z\|@\/()*+^$&?#--.])*$

Gateway(config-voice-uri-class)# pattern .)
% unmatched ()pattern pattern can be of format ^([][0-9A-Za-z\|@;:=%!~\/()*+^$&?#--.])*$

Exemplo: URIs de classe de voz

!
voice class uri HOST sip
 host webex.com
 host dns:cisco.webex.com
 host ipv4:10.50.244.2
 host ipv6:[2001:4860:4860::8888]
!
voice class uri USER sip
 user-id username
!
voice class uri PATTERN sip
 pattern 8675309
!
voice class uri HostRegex sip
 host (.*)cisco.com
!
voice class uri ipRegex sip
 host 172\.18\.110\.20[567]
!
voice class uri PatternRegex sip
 pattern 555(.*)
!
voice class uri ipRegex sip
 pattern (172\.18\.110\.10[134]|10\.10\.10\.10)
 ! One Line that matches 172.18.110.101, 172.18.110.103, 172.18.110.104 OR 10.10.10.10
!
voice class uri UserRegex sip
 user-id test(.*)
!

Apenas 10 hosts, 1 padrão ou 1 id de usuário podem ser configurados por uri de classe de voz, como este exemplo demonstra. Se for necessário combinar mais itens, é recomendável usar Regex.

Gateway(config)# voice class uri TEST sip
Gateway(config-voice-uri-class)#host ipv4:10.1.1.1
Gateway(config-voice-uri-class)#host ipv4:10.2.2.2
Gateway(config-voice-uri-class)#host ipv4:10.3.3.3
Gateway(config-voice-uri-class)#host ipv4:10.4.4.4
Gateway(config-voice-uri-class)#host ipv4:10.5.5.5
Gateway(config-voice-uri-class)#host ipv4:10.6.6.6
Gateway(config-voice-uri-class)#host ipv4:10.7.7.7
Gateway(config-voice-uri-class)#host ipv4:10.8.8.8
Gateway(config-voice-uri-class)#host ipv4:10.9.9.9
Gateway(config-voice-uri-class)#host ipv4:10.10.10.10
Gateway(config-voice-uri-class)#host ipv4:10.11.11.11
Error:Maximum of 10 hosts can only be configured.
 
Gateway(config)# voice class uri TEST2 sip
Gateway(config-voice-uri-class)#host dns:1.com
Gateway(config-voice-uri-class)#host dns:2.com
Gateway(config-voice-uri-class)#host dns:3.com
Gateway(config-voice-uri-class)#host dns:4.com
Gateway(config-voice-uri-class)#host dns:5.com
Gateway(config-voice-uri-class)#host dns:6.com
Gateway(config-voice-uri-class)#host dns:7.com
Gateway(config-voice-uri-class)#host dns:8.com
Gateway(config-voice-uri-class)#host dns:9.com
Gateway(config-voice-uri-class)#host dns:10.com
Gateway(config-voice-uri-class)#host dns:11.com
Error:Maximum of 10 hosts can only be configured.
 
Gateway(config)# voice class uri TEST3 sip
Gateway(config-voice-uri-class)#user-id 8675309
Gateway(config-voice-uri-class)#user-id 123456789
Gateway(config-voice-uri-class)#do sh run | s TEST3
voice class uri TEST3 sip
user-id 123456789
 
Gateway(config)# voice class uri TEST4 sip
Gateway(config-voice-uri-class)#pattern 8675309
Gateway(config-voice-uri-class)#pattern 123456789
Gateway(config-voice-uri-class)#do sh run | s TEST4
voice class uri TEST4 sip
pattern 123456789

Correspondência de Ponto de Discagem URI de Entrada

Este recurso foi adicionado no IOS 15.1(2)T e no IOS-XE 3.8S e utiliza um URI de classe de voz configurado e aplicado a um peer de discagem de entrada. O URI de entrada foi adotado por muitas pessoas sobre a instrução incoming called-number tradicional para chamadas SIP, pois ele é o primeiro critério de correspondência verificado ao selecionar peers de discagem de entrada. O comando também permite que os administradores correspondam melhor as chamadas que vêm de um determinado agente de chamadas ou usuário.

Documentação completa: Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 em diante

Casos de uso comuns

1. Um correspondente de discagem de entrada correspondente na parte do host do URI para responder às solicitações de ping OPÇÕES do CUCM.
2. Um correspondente de discagem de entrada correspondente na parte do host do URI para controlar chamadas de entrada de um Provedor de Serviços de Telefonia pela Internet (ITSP)
3. Um peer de discagem de entrada que corresponde na parte da ID do usuário do URi para tratamento de chamada de determinados usuários ou números.

Exemplo de configuração

Esta saída de exemplo corresponde ao dial-peer 777 para qualquer requisição SIP originada dos dois IPs HOST definidos no URI de classe de voz. O cabeçalho observado é definido como o cabeçalho De no peer de discagem; no entanto, um administrador pode definir muitos outros, incluindo VIA, TO e REQUEST (Request URI). Se o CUCM enviar um ping OPÇÕES para o CUBE agora corresponder ao dial-peer 777 e originar minha resposta 200 OK para as OPÇÕES da interface especificada. Se o CUCM enviar um convite para o CUBE corresponder ao dial-peer 777 como o dial-peer de entrada.

!
voice class uri CUCM sip
 host ipv4:10.50.244.2
 host ipv4:10.50.244.20
!
dial-peer voice 777 voip
 description INCOMING URI
 session protocol sipv2
 incoming uri from CUCM
 voice-class sip bind control source-interface Loopback777
 voice-class sip bind media source-interface Loopback777
!

Correspondência de Ponto de Discagem URI de Saída

Os gateways do Cisco IOS podem corresponder a um peer de discagem de saída usando um URI aplicando um uri de classe de voz a um peer de discagem de saída e adicionando um url de rota de chamada à configuração global. Quando ele estiver presente, o CUBE poderá tentar rotear chamadas com base no URI de solicitação. Este recurso foi adicionado no IOS 12.3(4)T e está presente em todas as versões do IOS XE. Pode-se observar que, por padrão, o URI de solicitação SIP de saída e o URI de cabeçalho Para têm o destino de sessão do peer de discagem de saída. Isso pode ser desativado usando o comando requri-passing que permite que o gateway passe a parte do host do URI de entrada para o trecho de saída, em vez de substituir a parte do host do URI pelo destino da sessão. O comando requri-passing foi adicionado no 15.4(1)T e no IOS XE 3.11S.

Exemplo de configuração

voice service voip
 sip
  call-route url
  requri-passing
!
voice class uri CUCM sip
 host dns:.*.com
!
dial-peer voice 777 voip
 description OUTGOING URI
 session protocol sipv2
 destination uri CUCM
 session target sip-uri
!

Fonte: Guia de configuração do Cisco Unified Border Element - Cisco IOS XE 17.6 em diante

Além do URI de classe de voz, os administradores podem usar uma política de provisionamento de peer de discagem (DPP) para corresponder um URI em trecho para uma correspondência de peer de discagem de saída. Este recurso foi adicionado no IOS 15.4(2)T e no IOS XE 3.12S. Uma política de provisionamento de peer de discagem requer a definição de um atributo de correspondência primário com um atributo de correspondência secundário sendo opcional. A política de provisão é aplicada a um peer de discagem de entrada e, quando esse peer de discagem é selecionado para uso em um leg da chamada de entrada, a política é chamada. O resultado é uma seleção de peer de discagem de saída com base no atributo da política de provisionamento de peer de discagem.

A correspondência de saída pode ser um único cabeçalho ou vários cabeçalhos, que devem ser todos verdadeiros para corresponder ao correspondente de discagem.

No exemplo, há um uri de classe de voz para os cabeçalhos De e Até. Para uma correspondência OR, é configurada uma política de provisionamento de peer de discagem que contém duas preferências. O cabeçalho De é a primeira preferência e o cabeçalho Para é a preferência de backup. O correspondente de discagem 1234 é criado para aplicar a política de provisão para correspondência de entrada. Em seguida, crie 11111 e 22222 de correspondentes de discagem que apliquem os comandos destination uri-from e destination uri-to, respectivamente. Esses comandos apontam de volta para o URI da classe de voz. Para a chamada, você pode receber o convite, corresponder o dial-peer 1234 e verificar a política de provisão. O dispositivo pode então tentar rotear no cabeçalho De primeiro, que é uma correspondência aplicável em 11111 de dial peer. Se isso falhar, você também pode tentar rotear no cabeçalho para com 22222.

O exemplo também detalha como obter uma correspondência And com as políticas de provisão de peer de discagem. Supondo que o mesmo convite seja recebido, você pode definir dois cabeçalhos em uma preferência e aplicá-lo ao correspondente de discagem de entrada.

Agora, quando o convite é recebido, ele pode verificar os correspondentes de discagem de saída qualificados que satisfazem os dois critérios de correspondência definidos na política de provisão. Neste exemplo, seu peer de discagem de saída precisa ser definido com o cabeçalho TO e FROM para ser correspondido. Se nenhum dos dois for uma correspondência válida, esse 12345 de peer de discagem não será usado.

Observação: embora estejamos roteando a chamada no cabeçalho De, o convite que sai do gateway ainda tem o URI de solicitação original. Simplesmente usamos a política de provisão de peer de discagem para corresponder a um peer de discagem de saída e não alterar o URI da solicitação.

Exemplo de configuração:

### Received INVITE
Received: 
INVITE sip:8675309@172.18.110.58:5060 SIP/2.0
From: sipp <sip:sipp@172.18.110.65>;tag=1
To: sut <sip:cube@172.18.110.58:5060>

### Common Configurations
!
voice class uri FROM sip
 user-id sipp
!
voice class uri TO sip
 user-id cube
!

### OR Match
!
voice class dial-peer provision-policy 1
 description match from header. If false, try to header
 preference 1 from
 preference 2 to
!
dial-peer voice 1234 voip
 session protocol sipv2
 destination provision-policy 1
 incoming called-number .
!
dial-peer voice 11111 voip
 destination uri-from FROM
 session protocol sipv2
 session target ipv4:172.18.110.48
!
dial-peer voice 22222 voip
 destination uri-to TO
 session protocol sipv2
 session target ipv4:172.18.110.48
!

### AND Match
!
voice class dial-peer provision-policy 2
 description match from AND to headers
 preference 1 from to
!
dial-peer voice 1234 voip
 session protocol sipv2
 destination provision-policy 2
 incoming called-number .
!
dial-peer voice 12345 voip
 destination uri-from FROM
 destination uri-to TO
 session protocol sipv2
 session target ipv4:172.18.110.48
!

Fonte: Guia de configuração do Cisco Unified Border Element por meio do Cisco IOS XE 17.5

session target sip-uri

Antes do IOS 15.4(1)T e do IOS XE 3.11S, se a parte do host de um URI fosse diferente, mas o usuário fosse o mesmo, isso exigiria dois peers de discagem de saída separados.

Após essa versão, um administrador pode configurar um ponto de discagem para atender a vários hosts para o mesmo usuário. Por exemplo, testuser@cisco.com e testuser@webex.com no mesmo peer de discagem. O uso do sip-uri de destino de sessão aciona a resolução DNS do domínio do Convidar Req-URI de entrada e determina dinamicamente o IP de destino da sessão.

Exemplo de configuração:

O gateway recebe dois convites SIP com esses cabeçalhos Invite sip:testuser@cisco.com:5060 SIP/2.0 Invite sip:testuser@webex.com:5060 SIP/2.0 O gateway corresponde à solicitação SIP de entrada de testuser@cisco.com e testuser@webex.com no dial-peer 1 devido ao comando URI de entrada e à definição de id de usuário corresponderem ao usuário de teste. O comando voice-class sip call-route url is present significa que você avalia os peers de discagem de saída com base no URI de solicitação deste Convite de entrada. Você faz a correspondência do dial-peer 2 devido aos mesmos motivos pelos quais você fez a correspondência do dial-peer 1, o user-id de testuser. O destino de sessão desse peer de discagem é o sip-uri original, conforme definido pelo sip-uri de destino de sessão "que era um FQDN. Depois que ocorrer uma resolução de DNS e alterar cisco.com e webex.com para um IP para o roteamento de camada 3, você envia uma mensagem para fora do gateway.

!
ip host cisco.com 10.10.10.10
ip host webex.com 10.10.10.10
!
voice class uri TEST-IN sip
 user-id testuser
!
dial-peer voice 1 voip
 description INCOMING dial-peer
 incoming uri request TEST
 session protocol sipv2
 voice-class sip call-route url
!
dial-peer voice 2 voip
 description OUTBOUND dial-peer
 destination uri TEST
 session protocol sipv2
 session target sip-uri
!

Verificação: 

show voice class uri <uri-name>
show voice class dial-peer provision-policy <number>
debug voip uri

Caracteres Curinga de Peer de Discagem

Um administrador pode utilizar curingas de peer de discagem ao definir mecanismos de correspondência de entrada e saída que envolvem uma sequência numérica. Isso inclui destination-pattern, incoming called-number, e164-pattern-maps, answer-address e o comando prefix. Os curingas de peer de discagem são expressões regulares (regex) disponíveis para configuração que permitem maior flexibilidade sobre a correspondência de peers de discagem.

Tabela Curinga

Saída do Gateway que exibe as possíveis entradas de expressões regulares.

Gateway(config-dial-peer)# destination-pattern asdfqw4r3~2
Incorrect format for E.164 Number
        regular expression must be of the form  ^[][^0-9,A-F#*.?+%()-]*T?(\$)?$

Estados de Peer de Discagem

Os peers de discagem podem estar em um de dois estados Operacionais.

1. Para cima
2. Down

Para que um peer de discagem esteja em um estado operacional válido e qualificado para uso com roteamento de chamadas, ele precisa estar no estado UP. Para peers de discagem VOIP de saída, isso significa que pode haver um mecanismo de correspondência de saída válido, bem como um destino de sessão válido para rotear a chamada. Para peers de discagem POTS de saída, um mecanismo de correspondência de saída válido e uma porta de voz válida podem ser configurados. Somente com peers de discagem de entrada, um mecanismo de correspondência de entrada válido deve ser configurado.

O estado busyout é visto quando um peer de discagem é configurado com um mecanismo keepalive e o destino remoto falha nos parâmetros desse mecanismo keepalive. Em seguida, o gateway move o correspondente de discagem para um estado busyout para que ele não seja mais usado para decisões de roteamento de chamadas e, quando o mecanismo keepalive é executado novamente, o gateway coloca o correspondente de discagem de volta em um estado ativo. Se um peer de discagem for selecionado como um peer de discagem de saída e esse peer de discagem estiver em um estado busyout, o gateway falhará a chamada com um código de causa 188.

Junto com os estados operacionais, existem os estados Administrativos.

1. Para cima
2. Down

Um administrador pode desativar um peer de discagem sem removê-lo da configuração inserindo o comando shutdown no peer de discagem. Para reativar o dial-per, insira no shutdown.

Observação: um correspondente de discagem com uma porta de voz que está inativa, desligada ou não operacional permanece no estado operacional Ativo, mas o Estado de Saída é mostrado como Inativo.

 Verificação 

Gateway# show dial-peer voice summary
dial-peer hunt 0
             AD                                    PRE PASS                OUT
TAG    TYPE  MIN  OPER PREFIX    DEST-PATTERN      FER THRU SESS-TARGET    STAT PORT    KEEPALIVE
1      voip  up   up                                0  syst
777    voip  up   up             9...               0  syst ipv4:10.50.244.2
555    voip  up   down           555                0  syst
888    pots  up   up             888                0                      up   0/2/0
999    pots  up   up             999                0                      down 0/2/0
123    voip  up   up             123                0  syst ipv4:10.10.10.10            busyout

Roteamento e encaminhamento virtual (VRF) e busca de correspondentes de discagem

Correspondência de Peer de Discagem de Entrada com VRF

Começando com IOS 15.6(3)M e IOS-XE 16.3.1, os gateways Cisco podem combinar correspondentes de discagem de entrada usando IDs de VRF. Para tirar proveito disso, um administrador deve vincular o peer de discagem de entrada a uma interface que, por sua vez, vincula o peer de discagem ao ID de VRF na interface especificada. Após a conclusão da vinculação, as chamadas de entrada são filtradas pelo Cisco Gateway para incluir apenas correspondentes de discagem de entrada qualificados que correspondam ao ID de VRF da interface em que o pacote foi recebido. A partir daqui, o correspondente de discagem de entrada é correspondido com base na ordem de operações de correspondência do correspondente de discagem regular.

Antes dessas versões do IOS/IOS-XE, o Cisco Gateway fazia uma seleção de entrada com base na correspondência regular de correspondentes de discagem de entrada sem nenhuma filtragem. Isso significa que uma chamada VRF1 pode ser combinada por um peer de discagem VRF2. Além disso, como apenas um VRF era compatível com H323 e SIP antes dessas versões, surgem outros problemas ao tentar usar recursos de vários VRF. O uso de um único VRF para aplicativos de voz era conhecido como configuração VRF-Aware.

Documentação completa com reconhecimento de VRF: VRF-Aware H.323 e SIP para gateways de voz

Documentação completa do Multi-VRF: Guia de configuração do Cisco Unified Border Element - Cisco IOS XE 17.6 em diante

Correspondência de Peer de Discagem de Saída com VRF

Os gateways Cisco têm a capacidade de fazer a ponte de chamadas através de VRFs sem a necessidade de configurar vazamentos de rota. Isso significa que uma chamada de entrada no VRF1 pode ser roteada de saída em um correspondente de discagem para o VRF2 se a seleção de correspondência de correspondente de discagem de saída normal for satisfeita. Grupos de correspondentes de discagem podem ser empregados para forçar o gateway Cisco a manter a chamada dentro do mesmo VRF.

Exemplo de configuração de grupo de correspondentes de discagem e VRF

Este exemplo de configuração tem VRF1 e VRF2 com dois intervalos IP sobrepostos e dois intervalos de números de telefone sobrepostos.

Utilize a vinculação VRF para garantir que o correspondente de discagem de entrada correto seja correspondido e os grupos de correspondentes de discagem para garantir que o correspondente de discagem de saída associado ao VRF correto seja correspondido. Se um pacote SIP de uma chamada para 8675309 chega em gig0/0/1.2, o gateway filtra todos os peers de discagem de entrada disponíveis com base no ID do VRF2. Isso significa que você não pode fazer a correspondência do correspondente de discagem 10. Agora, quando você verifica a sequência de dígitos, você pode fazer a correspondência do correspondente de discagem 20. O peer de discagem 20 tem um grupo de peer de discagem que informa ao gateway que o único peer de discagem de saída que pode ser combinado também é o peer de discagem 20. Esse grupo de peer de discagem permite evitar a correspondência do peer de discagem 10 e o cruzamento de uma chamada proveniente do VRF1 para o VRF2. A partir daí, a chamada pode prosseguir normalmente.

!
interface GigabitEthernet0/0/1.1
 description VRF1
 encapsulation dot1Q 10
 ip vrf forwarding VRF1
 ip address 10.10.10.10 255.255.255.0
!
interface GigabitEthernet0/0/1.2
 description VRF2
 encapsulation dot1Q 20
 ip vrf forwarding VRF2
 ip address 10.10.10.10 255.255.255.0
!
voice service voip
 no ip address trusted authenticate
 media-address voice-vrf VRF1
 media-address voice-vrf VRF2
 allow-connections sip to sip
 sip
!
voice class dpg 10
 description INBOUND VRF1 to OUTBOUND VRF1
 dial-peer 10 preference 1
!
voice class dpg 20
 description INBOUND VRF2 to OUTBOUND VRF2
 dial-peer 20 preference 1
!
dial-peer voice 10 voip
 description VRF1
 destination-pattern 8675309
 session protocol sipv2
 session target ipv4:10.10.10.20
 destination dpg 10
 incoming called-number 8675309
 voice-class sip bind control source-interface GigabitEthernet0/0/1.1
 voice-class sip bind media source-interface GigabitEthernet0/0/1.1
!
dial-peer voice 20 voip
 description VRF2
 destination-pattern 8675309
 session protocol sipv2
 session target ipv4:10.10.10.20
 destination dpg 20
 incoming called-number 8675309
 voice-class sip bind control source-interface GigabitEthernet0/0/1.2
 voice-class sip bind media source-interface GigabitEthernet0/0/1.2
!

Verificação

Gateway# show vrf brief | i VRF
  VRF1                             1:1                   ipv4        Gi0/0/1.1
  VRF2                             2:2                   ipv4        Gi0/0/1.2

Gateway# show dial-peer voice summary
TAG    TYPE  MIN  OPER PREFIX    DEST-PATTERN      FER THRU SESS-TARGET    STAT PORT    KEEPALIVE    VRF
10     voip  up   up             8675309            0  syst ipv4:10.10.10.20                         VRF1
20     voip  up   up             8675309            0  syst ipv4:10.10.10.20                         VRF2

Gateway# show voice class dpg 10
Voice class dpg: 10      AdminStatus: Up
 Description: INBOUND to OUTBOUND VRF1
 Total dial-peer entries: 1

 Peer Tag       Pref
 --------       ----
 10             1
-------------------------------------

Gateway# show voice class dpg 20
Voice class dpg: 20      AdminStatus: Up
 Description: INBOUND to OUTBOUND VRF2
 Total dial-peer entries: 1

 Peer Tag       Pref
 --------       ----
 20             1
-------------------------------------

Técnicas avançadas de roteamento de chamadas

Com o passar dos anos, à medida que as necessidades empresariais crescem, a empresa se expande e exige mais DIDs, e os administradores corporativos podem descobrir que os correspondentes de discagem básicos não atendem bem à escala. Pode haver situações de ativação/desativação que precisam ser resolvidas, ou talvez haja um número excessivo de peers de discagem em geral. Ter milhares de peers de discagem não facilita a administração e a solução de problemas. Ter um peer de discagem para cada servidor CUCM específico ou agente de chamada começa a agravar o problema de muitos peers de discagem, porque agora um administrador precisa configurar um peer de discagem para cada sequência de dígitos. Se houver mais de um provedor SIP conectado a um gateway, ou algumas pessoas diferentes usando o mesmo CUBE, isso torna o isolamento de um espaço específico muito difícil.

A Cisco aproveitou esse feedback e criou um conjunto de itens que podem resolver esses problemas e muito mais. Grupos de correspondentes de discagem, locatários de classe de voz, grupos de servidores de destino, mapas de padrão e164 e grupos de troncos POTS permitem que um administrador resolva todos os problemas listados e muitos outros não listados.

Grupos de Peer de Discagem

Os grupos de correspondentes de discagem foram adicionados no IOS 15.4(1)T e no IOS-XE 3.11S e os correspondentes de discagem POTS foram adicionados como uma opção no IOS 15.5(1)T e no IOS-XE 3.14S. Um grupo de peer de discagem permite que os administradores especifiquem um peer de discagem exato para o roteamento de saída com base no peer de discagem de entrada correspondido. Quando um peer de discagem de entrada com um grupo de peer de discagem configurado é correspondido, a chamada usa o peer de discagem definido no grupo de peer de discagem, mesmo que o padrão de destino não corresponda. O único pré-requisito é que o peer de discagem de saída deve estar ativo, de modo que um método de correspondência de saída deve ser configurado, no entanto, isso não é realmente usado para rotear a chamada.

A melhor maneira de descrever grupos de correspondentes de discagem é associá-los ao conceito de rotas estáticas em uma tabela de roteamento. Essas são decisões de roteamento de entrada estática para saída que eliminam algumas suposições do gateway porque estão informando exatamente como rotear a chamada. 

Documentação completa: Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 em diante

Exemplo de configuração

Neste exemplo, o número chamado é 8675309. Isso corresponde ao peer de discagem 1234 com base na instrução incoming called-number. Esse peer de discagem é configurado com um grupo de peer de discagem que afirma que a chamada agora pode rotear os peers de discagem 2, depois 3 e, finalmente, 1 se o peer de discagem 2 falhar. Esse é o gateway, então agora tente rotear o peer de discagem de chamada de saída 2 como foi explicitamente informado através do grupo de peer de discagem que é o que ele pode fazer.

Observação: o padrão de destino no dial-peer 1, 2 e 3 não é o número chamado de 8675309. Isso é bom e a chamada ainda é roteada sem problemas.

Lembre-se de que, conforme discutido na seção de estados do peer de discagem, você precisa de algo/qualquer coisa configurado como uma instrução de correspondência de saída. Nesse caso, o padrão de destino é apenas para trazer o correspondente de discagem para um estado operacional Ativo, e a sequência de dígitos desse comando nunca é avaliada. É recomendável configurar um padrão como destination-pattern AAAA, pois esse é um padrão de destino válido. Como esse é tecnicamente um peer de discagem válido, outras chamadas podem corresponder a ele. Assim, a sequência de dígitos AAAA significa que você nunca poderá usá-la para nada além de um cenário específico envolvendo um grupo de correspondentes de discagem, pois a probabilidade de uma chamada recebida para AAAA é muito, muito baixa.

!
dial-peer voice 1 voip
 description Server 1
 destination-pattern ^1234$
 session target ipv4:1.1.1.1
!
dial-peer voice 2 voip
 description Server 2
 destination-pattern ^5678$
 session target ipv4:2.2.2.2
!
dial-peer voice 3 voip
 description Server 3
 destination-pattern AAAA
 session target ipv4:3.3.3.3
!
voice class dpg 1
 description Dial-peer Group for specific called number 8675309
 dial-peer 2 preference 1
 dial-peer 3 preference 2
 dial-peer 1 preference 3
!
dial-peer voice 1234 voip
 description INCOMING dial-peer with DPG
 incoming called-number ^8675309$
 destination dpg 1
!

Verificação

Gateway# show voice class dpg 1
Voice class dpg: 1       AdminStatus: Up
 Description: Dial-peer Group for specific called number 1234
 Total dial-peer entries: 3

 Peer Tag       Pref
 --------       ----
 2              1
 3              2
 1              3
-------------------------------------

E164-Pattern-Maps

Esse recurso permite que os administradores reduzam o número total de correspondentes de discagem combinando várias correspondências de número possíveis (padrões de destino, número chamado de entrada etc.) em um único mapa de padrões. O suporte ao mapa de padrão e164 do correspondente de discagem de saída foi adicionado no IOS 15.2(4)M e no IOS-XE 3.7S, enquanto o suporte ao mapa de padrão e164 do correspondente de discagem de entrada foi adicionado no IOS 15.4(1)T e no IOS-XE 3.11S.

Um mapa de padrões e164 pode ser configurado por meio da CLI ou pré-configurado e é salvo como um arquivo .cfg. O arquivo .cfg é então adicionado à flash do gateway e referenciado ao configurar o restante do comando. O arquivo .cfg pode utilizar 5.000 entradas.

As entradas em ambos os métodos de configuração podem utilizar todos os curingas normais do correspondente de discagem para agregação adicional!

Documentação completa: Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 em diante

Exemplo de configuração de CLI - Números de chamada

!
voice class e164-pattern-map 1
 description E164 Pattern Map for calling numbers
 e164 919574100.
 e164 919574300.
 e164 8675309
!
dial-peer voice 1 voip
 description INBOUND Dial-peer based on CALLING #
 incoming calling e164-pattern-map 1
!
dial-peer voice 11 voip
 description OUTBOUND Dial-peer based on CALLING #
 destination calling e164-pattern-map 1
!

Exemplo de configuração CLI - Número chamado

!
voice class e164-pattern-map 2
 description E164 Pattern Map for called 800 numbers
 e164 91800T
 e164 91855T
 e164 91888T
!
dial-peer voice 2 voip
 description INBOUND Dial-peer based on CALLED #
 incoming called e164-pattern-map 2
!
dial-peer voice 22 voip
 description OUTBOUND Dial-peer based on CALLED #
 destination e164-pattern-map 2
!

Exemplo de configuração de Flash

!
voice class e164-pattern-map <tag>
 description FILEPATH for E164 Pattern Map
 url flash:<filepath>/e164-pattern-list.cfg
!
dial-peer voice ### voip
 description E164 Pattern Map Dial-peer
 incoming calling e164-pattern-map <tag>
!

voice class e164-pattern-map load <tag>

Verificação

Gateway# show voice class e164-pattern-map 1

e164-pattern-map 1
-----------------------------------------
  Description: CUCM phones
  It has 3 entries
  It is not populated from a file.
  Map is valid.

E164 pattern
-------------------
8675309
1...
[2-5]...$

Defeitos notáveis

O bug da Cisco ID CSCva64393e164-pattern-map não analisa a última linha do arquivo de configuração.

Grupos de servidores de destino

Os grupos de servidores permitem que os administradores configurem vários destinos (destinos de sessão) no mesmo peer de discagem VOIP. Por padrão, a ordem de classificação é a preferência definida nas entradas do grupo de servidores. A caça de rodízio pode ser empregada quando você usa o comando hunt-scheme round-robin. Grupos de servidores foram adicionados no Cisco IOS 15.4(1)T e no Cisco IOS XE 3.11S. No Cisco IOS XE 17.4.1um código de erro de huntstop configurável foi adicionado às configurações de grupo de servidor de classe de voz. Ou seja, você pode configurar um único código de erro, digamos 404 Não encontrado, e o erro SIP normalmente acionaria o dispositivo para tentar a próxima opção no grupo de servidores. Com a configuração huntstop 1 resp-code 404 no lugar dentro do grupo de servidores, a caça pode parar. Eles também podem ser configurados para um intervalo como: huntstop 1 resp-code 401 a 599.

Observação: o número máximo de entradas é 5 por grupo de servidores.

Documentação completa: Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 em diante

Exemplo de configuração - Normal

!
voice class server-group 1
 hunt-scheme round-robin
 ipv4 10.50.244.2 port 5060 preference 1
 ipv4 10.50.244.62
 ipv6 2010:AB8:0:2::1 port 2323 preference 3
 ipv6 2010:AB8:0:2::2 port 2222
!
dial-peer voice 1 voip
 session protocol sipv2
 destination-pattern 8675309
 session server-group 1
!

Verificação

Gateway# show voice class server-group 1
Voice class server-group: 1
 AdminStatus: Up OperStatus: Up
 Hunt-Scheme: round-robin Last returned server:
 Description:
 Total server entries: 4

 Pref Type IP Address IP Port
 ---- ---- ---------- -------
 1 ipv4 10.50.244.2     5060
 0 ipv4 10.50.244.62
 3 ipv6 2010:AB8:0:2::1 2323
 0 ipv6 2010:AB8:0:2::2 2222
[..truncated..]

Grupo de servidores de destino e manutenção de atividade de OPÇÕES

Lembre-se de que os grupos de servidores não seguem os mecanismos normais de manutenção de atividade de OPÇÕES fora do diálogo. Eles utilizam um recurso chamado perfil option-keepalive. Isso permite que o gateway monitore cada agente de chamada definido no grupo de servidores específico.

Exemplo de manutenção de atividade opcional com grupo de servidores

!
voice class server-group 1
 hunt-scheme round-robin
 ipv4 10.50.244.2
 ipv4 10.50.244.62
!
dial-peer voice 1 voip
 session protocol sipv2
 session server-group 1
 voice-class sip options-keepalive profile 1
!

Verificação

Gateway# show voice class sip-options-keepalive 1
Voice class sip-options-keepalive: 1             AdminStat: Up
 Description:
 Transport: system               Sip Profiles: 0
 Interval(seconds) Up: 5                 Down: 5
 Retry: 5

  Peer Tag      Server Group    OOD SessID      OOD Stat        IfIndex
  --------      ------------    ----------      --------        -------
  1             1                               Active          87

  Server Group: 1                OOD Stat: Active
   OOD SessID   OOD Stat
   ----------   --------
   1            Active
   2            Active

 OOD SessID: 1                   OOD Stat: Active
  Target: ipv4:10.50.244.2
  Transport: system              Sip Profiles: 0

 OOD SessID: 2                   OOD Stat: Active
  Target: ipv4:10.50.244.62
  Transport: system              Sip Profiles: 0

Proxy de saída

A configuração do Proxy de Saída SIP pode ser adicionada às configurações de voip de serviço de voz, locatário de classe de voz ou peer de discagem para especificar o destino de um Pacote SIP de Camada 3.

Ou seja, o destino da sessão em um peer de discagem pode ser usado para criar o Pacote SIP, mas o proxy de saída pode ser o local para onde o pacote é enviado na Camada 3.

!
voice service voip
 sip
  outbound-proxy dns:la01.sipconnect-us10.cisco-bcld.com
!
voice class tenant 100
 outbound-proxy dns:la01.sipconnect-us10.cisco-bcld.com
!
dial-peer voice 100 voip
 session target ipv4:192.168.1.1
 voice-class sip outbound-proxy dns:la01.sipconnect-us10.cisco-bcld.com
!

Pode-se observar que a configuração padrão para um peer de discagem é o sistema de proxy de saída sip de classe de voz, que pode fazer com que um peer de discagem use a configuração voip > sip do serviço de voz global.

Esse comportamento pode ser desativado e forçar um peer de discagem a recuar e usar o destino da sessão como o destino da camada 3 por peer de discagem com esta configuração:

dial-peer voice 777 voip
 no voice-class sip outbound-proxy

Grupos de Troncos POTS

Os grupos de troncos são um conjunto de portas de voz físicas com recursos de sinalização semelhantes. Esse é um recurso que pode ser empregado para reduzir o número total de peers de discagem POTS que precisam ser configurados. Os grupos de tronco foram introduzidos no IOS na versão 12.1(3)T e estão presentes em todas as versões do Cisco IOS XE.

Documentação completa: aprimoramentos de tronco de gateway e roteamento baseado em operadora

Exemplo de configuração

!
trunk group PSTN
 description PSTN voice-ports
!
trunk group FXO
 description FXO voice-ports
!
voice-port 0/2/0
 trunk-group PSTN 1
!
voice-port 0/2/1
 trunk-group PSTN 2
!
voice-port 0/2/2
 trunk-group FXO 1
!
voice-port 0/2/3
 trunk-group FXO 2
!
dial-peer voice 1234 pots
 trunkgroup PSTN 1
 trunkgroup FXO 2
!

Locatários da Classe de Voz

O Cisco IOS 15.6(2)T e o Cisco IOS XE 16.3.1 introduziram locatários de classe de voz que permitem que cada locatário tenha suas próprias configurações individuais. Um locatário pode ser um provedor de telefonia, o Cisco Unified Communication Manager (CUCM) ou qualquer outro agente de chamadas de terceiros para o qual um administrador gostaria de ter configurações globais específicas. Primeiro, um administrador cria um espaço de classe de voz e define os parâmetros. O locatário de classe de voz é então aplicado ao peer de discagem ou escolha específica. Essa nova configuração dá aos administradores outro nível de controle sobre as chamadas além dos correspondentes de discagem e da configuração global.

Com a versão 17.8.1a, as configurações do locatário de classe de voz podem ser configuradas com um comando sip-listen (juntamente com o comando de vinculação de controle SIP apropriado) para definir a porta não segura ou segura desse locatário. Isso significa que o locatário 1 pode ouvir SIP não seguro em UDP 5060 + VRF Red, enquanto o locatário 2 ouve SIP em TCP TLS 5070 + VRF Blue. Após corresponder o espaço com base em listen-port + bind + dial-peers de entrada vrf opcionais são filtrados para aqueles que têm o espaço aplicado.

Documentação completa: Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 em diante

Ordem normal de preferência de comando sem espaços

1. Comando dial peer
2. Comando global (serviço de voz voip e sip-ua)

Ordem de preferência de comando com espaços

1. comando dial peer
2. Comando de locatário
3. Comando global (serviço de voz voip e sip-ua)

Exemplo de configuração de multiusuário

Você tem dois espaços 777 e 999. Você os configurou com configurações ligeiramente diferentes e os aplicou aos peers de discagem. Isso significa que as chamadas que usam os diferentes peers de discagem têm as configurações baseadas no peer de discagem, bem como as configurações específicas do locatário. As opções listadas são apenas um trecho do poder dos locatários de classe de voz. Consulte a documentação para ver o que pode ser configurado em um espaço. É recomendável empregar mecanismos de correspondência estrita, como uri de classe de voz ou números de marcação com determinadas cadeias de caracteres de números para separar a correspondência do correspondente de discagem do locatário, ou mesmo configurar VRFs para que o Locatário A nunca se sobreponha ao Locatário B e corresponda acidentalmente a um correspondente de discagem que ele não pode.

!
voice class tenant 999
 asymmetric payload full
 bind control source-interface GigabitEthernet0/0/0.228
 bind media source-interface GigabitEthernet0/0/0.228
 g729 annexb-all
!
voice class tenant 777
 sip-server ipv4:192.168.1.2
 bind control source-interface Loopback0
 bind media source-interface Loopback0
 pass-thru content sdp
!
dial-peer voice 999 voip
 destination-pattern 8675309
 session protocol sipv2
 incoming called-number 8675309
 voice-class sip tenant 999
!
dial-peer voice 777 voip
 destination-pattern 8675309
 session protocol sipv2
 session target sip-server
 voice-class sip tenant 777
!

Verificação

Atualmente, não há comandos individuais para ver as configurações de locatário da classe de voz. Esse comando pode ser suficiente para filtrar a configuração atual apenas para as informações do espaço.

show run | sec tenant

Observação: o bug da Cisco ID CSCvf28730 é onde show sip-ua register status não reflete o status do registro de tronco SIP em um locatário de classe de voz.

O ILS URI chama o CUBE (string de rota de classe de voz)

As sequências de rota são usadas com o CUCM Intercluster Lookup Service (ILS) e podem ser configuradas para permitir que os Cisco Gateways roteiem chamadas VoIP através da sequência de rota incluída no convite SIP recebido de um CUCM 9.5+ executando o serviço ILS. Esse recurso foi adicionado no Cisco IOS 15.3(3)M e no Cisco IOS XE 3.10S. A maioria das conexões ILS é de CUCM para CUCM e os administradores não se preocupam em envolver um CUBE para entroncamento entre clusters. No entanto, se você precisar executar a função com CUBE no meio, as opções estarão lá. O CUCM precisa ter a configuração Send ILS Learned Destination Route String habilitada no perfil SIP aplicado ao tronco SIP para enviar o cabeçalho x-cisco-dest-route-string para o CUBE

Documentação completa: Enterprise Application Interoperability for H.323-to-SIP and SIP-to-SIP Configuration Guide, Cisco IOS Release 15M&T

Exemplo de configuração CUCM - SIP - CUBE - SIP - CUCM

!
voice service voip
 sip
  call-route dest-route-string
!
voice class route-string rt1
 pattern london.uk.eu
!
voice class sip route-string rt2
 pattern *.eu
!
voice class sip-hdr-passthrulist hdr1
 passthru-hdr x-cisco-dest-route-string
!
dial-peer voice 1 voip
 description INBOUND dial-peer
 session protocol sipv2
 voice-class sip pass-thru headers hdr1
 incoming called-number .
!
dial-peer voice 2 voip
 description OUTBOUND dial-peer
 destination route-string rt2
 session protocol sipv2
 session target ipv4:172.16.104.178
!

Verificação

show voice class route-string

Técnicas de roteamento de chamadas antigas

Os itens abordados nesta seção são considerados técnicas antigas. Embora a capacidade de configurá-los ainda esteja presente em um Cisco Gateway, não é recomendável usar esses comandos em configurações modernas. Este documento aborda apenas esses itens porque eles podem ser encontrados ao trabalhar com configurações herdadas ou ao executar atualizações.

Mapa de DNIS

Os mapas DNIS podem ser considerados o precursor do que seria agora um mapa padrão E164. Os mapas DNIS foram adicionados ao Cisco IOS na versão 12.2(2)XB e sempre existiram no Cisco IOS XE.

Se houver mapas DNIS configurados, valeria a pena convertê-los para o recurso de mapa de padrão e164 mais robusto.

Sintaxe de comando: Referência de comando de voz do Cisco IOS - D a I

Exemplo de configuração

!
voice dnis-map 34
 dnis 8675309
!
dial-peer voice 88 voip
 dnis-map 34
!

Rótulos do Grupo de Troncos

Os rótulos do grupo de troncos foram adicionados ao Cisco IOS 12.2(11)T e existem em todas as versões do Cisco IOS XE. A finalidade de um trunk-group-label é semelhante a um Carrier-ID no sentido de que pode ser usado para aumentar a correspondência de peers de discagem. Ele está disponível para configuração em grupos de troncos POTS, peers de discagem VOIP e POTS, bem como grupos de origem de voz. O uso de Rótulos de Grupo de Troncos é raramente visto em configurações modernas do Cisco Gateway.

Sintaxe do comando: Referência do comando de voz do Cisco IOS - T a Z

Exemplo de configuração

!
dial-peer voice 112 pots
 trunk-group-label source north3
 trunk-group-label target east17
!

Tipo de Numeração

Com integrações ISDN Q.931, existe a capacidade de corresponder um peer de discagem com base no número chamado ou chamador, bem como o tipo de número ITU específico da mensagem CONFIGURAÇÃO Q.931. Isso é configurável através do comando numbering-type em um peer de discagem VOIP ou POTS. O tipo de numeração não pode ser usado sozinho e deve ser usado em conjunto com destination-pattern, answer-address ou incoming called-number. Isso significa que tanto a condição da instrução de correspondência de entrada/saída quanto o tipo de número devem ser correspondentes para que o peer de discagem seja considerado para o roteamento de chamadas de entrada e de saída.

A correspondência de numeração pode ser pensada como um mecanismo de filtragem de peer de discagem, em vez de um mecanismo de correspondência. Isso ocorre porque um peer de discagem com e sem um comando de tipo de numeração aplicado será considerado o mesmo peso de preferência padrão se nenhuma preferência de administrador for aplicada. Isso é diferente de carrier-id que, quando aplicado a um peer de discagem ao lado de outro mecanismo de correspondência, adiciona preferência a esse peer de discagem sobre outros se ambas as condições forem verdadeiras.

A correspondência de tipo de numeração foi adicionada no Cisco IOS 12.0(7)XR1 e está presente em todas as versões do Cisco IOS XE. Com o declínio das linhas ISDN POTS tradicionais sendo implantadas em redes de colaboração, o uso do tipo de numeração raramente é visto em implantações modernas.

Sintaxe do comando: Referência do comando de voz do Cisco IOS - K a R

Exemplo de configuração

Esse peer de discagem pode corresponder 4085150000 através do 4085159999 somente se o tipo de número ISDN for Nacional.

!
dial-peer voice 408 voip
 numbering-type national
 destination-pattern 408515....
 session target ipv4:10.1.1.2
!

Tipos de números possíveis:

Dados de Peer de Discagem

Os peers de discagem de dados foram introduzidos no Cisco IOS 12.2(13)T e o uso desses peers de discagem foi para chamadas de modem de dados de entrada em um gateway Cisco. Esse peer de discagem deve ser usado somente na direção de entrada e raramente é visto em implantações modernas.

Sintaxe de comando: Referência de comando de voz do Cisco IOS - D a I

Exemplo de configuração

!
dial-peer data 100 pots
 incoming called-number 100
!

Grupo de origem de voz

Este recurso foi adicionado na versão 15.1(2)T, mas não é implementado em muitas implantações modernas. Outros métodos de segurança para IOS/CUBE geralmente são implantados.

A visão geral da segurança de aplicativos do CUBE pode ser vista neste white paper a partir da seção 4.2.

Especificação de gerenciamento e capacidade de gerenciamento do Cisco Unified Border Element (CUBE)

Sintaxe do comando: recurso Grupo de origem de voz

Permissões de Peer de Discagem

Essa configuração permite que um administrador restrinja um peer de discagem para permitir somente conexões de entrada (termo / término) ou conexões de saída (origem / origem). Isso seria como configurar explicitamente um peer de discagem de entrada para ser usado apenas para chamadas de entrada e um peer de discagem de saída para chamadas de saída. O padrão para qualquer peer de discagem é permitir conexões de entrada e de saída. Esta CLI não é frequentemente implantada em implantações modernas.

Router(config)# dial-peer voice 1 voip
Router(config-dial-peer)# permission ?
 both allow both orig/term on this dialpeer
 none no orig/term allowed on this dialpeer
 orig allow only orig on this dialpeer
 term allow only term on this dialpeer

URI e manipulação de dígitos

Em algum ponto de uma implantação de colaboração, um administrador pode precisar manipular dígitos ou um cabeçalho URI/SIP. Os gateways Cisco têm vários métodos para manipulação de dígitos que permitem que um administrador controle completo sobre como e quando um dígito pode ser manipulado. No entanto, isso nem sempre é fácil e algumas pessoas ficam sobrecarregadas com as diferentes opções ou o administrador não sabe que uma opção existe.

Manipulação de dígitos via correspondentes de discagem POTS

Os peers de discagem POTS têm algumas técnicas exclusivas de manipulação de dígitos que os peers de discagem VOIP não têm.

A primeira é a remoção de dígitos justificados à esquerda explicitamente definidos em um padrão de destino. Isso pode ser desativado usando o comando no digit-strip no peer de discagem POTS.

Exemplo:

Neste exemplo, 9011T é definido como a string para o padrão de destino.

Com isso estabelecido, você pode receber uma chamada para 90113227045555. Isso corresponde ao peer de discagem para roteamento de chamada de saída, e os dígitos explicitamente definidos de 9011 são removidos antes que a chamada seja roteada pela porta de voz. 

!
dial-peer voice 1 pots
 destination-pattern 9011T
 port 0/0/0:23
!

Este exemplo mostra uma configuração sem faixa de dígitos no lugar.

Se o mesmo número for chamado, o 9011 será enviado .

!
dial-peer voice 1 pots
 destination-pattern 9011T
 port 0/0/0:23
 no digit-strip
!

O segundo é a capacidade de especificar quantos dígitos você gostaria de encaminhar no peer de discagem POTS.

Tome este exemplo onde você recebe uma chamada para 918005532447 do CUCM. Nessa situação, você deseja remover o 9, mas enviar o restante do número começando com o 1.

Se você configurar o comando forward-digits no peer de discagem POTS, você poderá especificar exatamente quantos dígitos enviará.

!
dial-peer voice 1 pots
 destination-pattern 918005532447
 forward-digits 11
 port 0/2/0
!

Por fim, os peers de discagem POTS podem usar o comando prefix para adicionar dígitos a uma chamada antes de rotear a porta de voz. Este exemplo retira o 91 explicitamente definido e o prefixo 007 para o número antes de enviar a chamada pela porta de voz.

!
dial-peer voice 1 pots
 destination-pattern 91T
 prefix 007
 port 0/1/0:15
!

Manipulação de dígitos através de regras e perfis de conversão de voz

As regras de conversão de voz são expressões regulares (regex) usadas para transformar dígitos. As regras de conversão e os perfis foram adicionados ao Cisco IOS na versão 12.0(7)XR1. Uma regra de conversão é aplicada aos perfis de conversão de voz que são aplicados a um correspondente de discagem ou porta de voz. As regras de conversão contêm uma entrada de correspondência e uma saída de modificação. Juntamente com a entrada de correspondência no número, há uma entrada de correspondência e modificação para o plano e o tipo de ISDN. A combinação de string de número de correspondência, plano e tipo é considerada uma correspondência. Isso significa que todas as entradas de correspondência definidas devem ser verdadeiras para que a conversão ocorra. 

As regras de conversão têm a capacidade de alterar Chamada, Chamada, chamada de redirecionamento, destino de redirecionamento e número de retorno de chamada nos protocolos de sinalização ISDN, SIP e H323. As regras de tradução combinam com base em uma pesquisa de cima para baixo, portanto, a ordem das regras é de extrema importância. Se uma correspondência for encontrada em uma regra superior, o gateway interromperá imediatamente a pesquisa e processará a conversão. As regras de conversão não podem alterar cabeçalhos sip não numéricos, como testuser@10.10.10.10. Para essa manipulação, utilize um perfil SIP.

As regras de transição podem ser usadas para bloquear chamadas nos Cisco Gateways.

Preferência de seleção de perfil de tradução

1. Perfil de conversão de voz de entrada na porta de voz
2. Perfil de conversão de voz de entrada no Grupo de Troncos aplicado à Interface Serial
3. Incoming voice translation-profile no peer de discagem de entrada
4. Perfil de conversão de voz de entrada definido através de portas de serviço de voz
5. Perfil de conversão de voz de entrada definido via 'voip-incoming translation-profile' global
6. Perfil de tradução de voz de saída definido através de portas de serviço de voz
7. Outbound voice translation-profile ou translate-outgoing no dial-peer de saída
8. Perfil de conversão de voz de saída no grupo de troncos aplicado à interface serial
9. Perfil de tradução de voz de saída na porta de voz

Além do dial-peer regex e as regras de conversão de curingas têm seus próprios caracteres regex.

Conjuntos de Modificação

• Os conjuntos são especificados como \0, \1, \2 e assim por diante.
• \0 corresponde a qualquer item entre o primeiro conjunto de correspondências. Isso também pode ser feito através de um caractere de E comercial: &.
• \1 corresponde ao primeiro conjunto de ( ) no conjunto de correspondência
• \2 corresponde ao segundo conjunto de ( ) no conjunto de correspondência
• E assim por diante.

Exemplo de regra de tradução com dois conjuntos

Neste exemplo, você pode examinar o número 000111000222.

Você deseja remover os 0s do número e obter um número final de 111222.

Para fazer isso, configure os conjuntos 1 e 2 para capturar o 111 e o 222, respectivamente, enquanto solta os 0s.

!
voice translation-rule 333
 rule 1 /000\(111\)000\(222\)/ /\1\2/
!
voice translation-profile SET-EXAMPLE
 translate called 333
!

Gateway# test voice translation-rule 333 000111000222
Matched with rule 1
Original number: 000111000222   Translated number: 111222
Original number type: none      Translated number type: none
Original number plan: none      Translated number plan: none

Exemplo para retirar o padrão de discagem externa 9 de um número chamado

!
voice translation-rule 9
 rule 1 /^9\(.*\)/ /\1/
!
voice translation-profile STRIP-9
 translate called 9
!
dial-peer voice 9 voip
 translation-profile outgoing STRIP-9
!
voice-port 0/0/0
 translation-profile outgoing STRIP-9
!

Gateway# test voice translation-rule 9 918675309
Matched with rule 1
Original number: 918675309      Translated number: 18675309
Original number type: none      Translated number type: none
Original number plan: none      Translated number plan: none

Truncar o número chamado para 4 dígitos

!
voice translation-rule 4
 rule 1 /.*\(....\)/ /\1/
!
voice translation-profile STRIP-TO-4
 translate called 4
!

Gateway# test voice translation-rule 4 8675309
Matched with rule 1
Original number: 8675309        Translated number: 5309
Original number type: none      Translated number type: none
Original number plan: none      Translated number plan: none

Remoção do sinal de mais + do número chamado

!
voice translation-rule 999
 rule 1 /\+\(.*\)/ /\1/
!
voice translation-profile STRIP-PLUS
 translate called 999
!
Gateway# test voice translation-rule 999 +8675309
Matched with rule 1
Original number: +8675309       Translated number: 8675309
Original number type: none      Translated number type: none
Original number plan: none      Translated number plan: none 

As regras de tradução também podem ser aplicadas diretamente a um peer de discagem sem primeiro serem aplicadas a um perfil de tradução.

!
voice translation-rule 1
 rule 1 /1234/ /8678309/
!
voice translation-rule 2
 rule 2 /^4...$/ /1408515\0/
!
dial-peer voice 1 voip
 translate-outgoing called 1
!
dial-peer voice 2 voip
 translate-outgoing calling 2
!

Perfil de Tradução no Grupo de Troncos

!
trunk group <name>
 translation-profile incoming <profile-name>
 translation-profile outgoing <profile-name>
!

Depurar regras e perfis de conversão de voz

debug voip ccapi inout
debug voice translation
debug dialpeer
test voice translation-rule <number> <string> type <type> plan <plan>

Voice Class e164-translation

O recurso de conversão de voz classe e164 é um recurso mais recente do Cisco IOS XE que permite que um administrador crie uma lista de instruções de correspondência e modifique as instruções a serem carregadas através de um arquivo de configuração da flash ou de um diretório de rede. Isso é semelhante ao conceito para o recurso e164-pattern-map discutido neste documento. Isso permite que um administrador configure até 100 conversões dentro de um arquivo de configuração e as aplique em um único perfil de conversões. Para obter mais informações, consulte a Referência de Comandos de Voz do Cisco IOS

Siga esta sintaxe para o arquivo .cfg:

pattern1_to_be_matched<tab>replaced_pattern<space><enter>
pattern1_to_be_matched<tab>replaced_pattern<space><enter>

Observação: o espaço à direita é muito importante, e a importação pode falhar sem essa etapa de formatação extra.

Exemplo.cfg

+111111	8897 
+222222	8312 
928747	+123456789 
737362	+987654321 

Esse arquivo então faz referência como:

voice class e164-translation 164
 url ftp://username:password@10.10.10.10/sample.cfg

Agora você aplica a um perfil de tradução normalmente e, a partir daí, aplica-se a correspondentes de discagem usando a sintaxe de perfil de tradução normal.

voice translation-profile e164
 translate calling voice-class e164-translation 164
 translate called voice-class e164-translation 164

O comando show voice class e164-translation e164-translation-number pode ser usado para exibir o conteúdo do perfil de conversão.

Manipulação de dígitos via mapas ISDN

MAPS ISDN são uma técnica mais antiga para modificar dígitos. Isso foi adicionado no Cisco IOS 12.0(6)T e a maioria das novas configurações não utiliza esse recurso, pois não são tão robustas quanto regras e perfis de conversão de voz. Os mapas ISDN são definidos na interface serial.

Exemplo de configuração

Serial0/0/0:23
 isdn map address ^911 plan isdn type unknown
 isdn map address ^1.......... plan isdn type national
 isdn map address ^2......... plan isdn type national
 isdn map address ^3......... plan isdn type national
 isdn map address ^4......... plan isdn type national
 isdn map address ^5......... plan isdn type national
 isdn map address ^6......... plan isdn type national
 isdn map address ^7......... plan isdn type national
 isdn map address ^8......... plan isdn type national
 isdn map address ^9......... plan isdn type national

Manipulação de Dígitos via Expansão de Número (num-exp)

Como os mapas ISDN, a expansão de números é uma técnica mais antiga adicionada ao Cisco IOS 11.3(1)T e pouco usada em redes novas. Este recurso foi adicionado antes de existirem regras e perfis de conversão de voz. A expansão de número é uma alteração global de dígitos aplicada a todos os correspondentes de discagem em um gateway Cisco. A modificação é aplicada ao número chamado após a correspondência do correspondente de discagem e imediatamente antes do envio da chamada para o próximo agente de chamada.

Exemplo de configuração

num-exp 4... 18005554...
num-exp 1234 8675309

Perfis SIP de entrada/saída

Os perfis SIP são instruções de Correspondência de Expressão Regular (regex) robustas que permitem que um administrador altere qualquer aspecto de uma mensagem SIP que inclua cabeçalhos SDP e SIP. Eles podem ser ativados globalmente, por peer de discagem ou por locatário. Os perfis SIP estão disponíveis para modificações de entrada começando com o Cisco IOS 15.4(2)T e o Cisco IOS XE 3.12S . Como os perfis SIP são tão robustos, este documento aborda apenas alguns exemplos específicos. Os perfis SIP também adicionam a capacidade de os cabeçalhos SIP personalizados serem modificados ou adicionados no IOS 15.5(2)T e no IOS-XE 3.13S.

Pontos principais sobre perfis SIP de entrada versus de saída

• Os perfis SIP de entrada alteram a mensagem ANTES que o CUBE processe a mensagem para roteamento de chamada.
• Os perfis SIP de saída alteram a mensagem DEPOIS que o CUBE processa o roteamento de chamadas e antes que a mensagem seja enviada para o próximo salto.

Outras observações sobre a configuração sip-profile: 

• Os perfis SIP não podem manipular atributos SDP m=image. O aprimoramento para isso foi arquivado sob a ID de bug Cisco CSCsr20474  Além disso, os perfis SIP não podem remover ou adicionar valores ao SDP. Somente você pode modificar esses valores. No entanto, é possível modificar um valor SDP para um valor nulo especificando o valor inteiro e, em seguida, definindo a saída para um conjunto de aspas vazias sem espaço.
• Não há verificações realizadas para ver se o comando atual sendo inserido já existe ou se uma versão desse comando já existe ao inserir comandos dentro da classe de voz sip-profile. Se um administrador colar uma linha 7 vezes em um perfil sip, ele exibirá 7 vezes a configuração atual. Recomenda-se remover o comando que está sendo modificado e, em seguida, inserir o novo comando ao editar perfis sip para evitar a presença de vários comandos.

Documentação completa: Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 em diante

Ferramenta de teste de perfil SIP: Ferramenta de teste de perfil SIP

Exemplo de Sintaxe de Perfil SIP de Entrada/Saída

!
voice class sip-profiles <number>
 request <message-type> sip-header <header> modify "match-pattern" "replace-pattern"
 request <message-type> sip-header <header> add "add-pattern"
 request <message-type> sip-header <header> remove 

 request <message-type> sdp-header <header> modify "match-pattern" "replace-pattern"
 request <message-type> sdp-header <header> add "add-pattern"
 request <message-type> sdp-header <header> remove

 response <number> sip-header <header> modify "match-pattern" "replace-pattern"
 response <number> sip-header <header> add "add-pattern"
 response <number> sip-header <header> remove

 response <number> sdp-header <header> modify "match-pattern" "replace-pattern"
 response <number> sdp-header <header> add "add-pattern"
 response <number> sdp-header <header> remove
!

Exemplo de Perfil SIP de Entrada/Saída com Números

voice class sip-profiles 200
 rule 1 response ANY sip-header Remote-Party-ID modify "match-pattern" "replace-pattern"
 rule 2 response ANY sdp-header Audio-Attribute modify "match-pattern" "replace-pattern"

Métodos de Aplicação do Perfil SIP de Saída

! Global Application 
voice service voip
 sip
  sip-profiles <number>
!
! Tenant Application
voice class tenant <tag>
 sip-profiles <tag>
!
! Dial-peer Application
dial-peer voice <tag> voip
 voice-class sip profiles <number>
!

Métodos de Aplicação do Perfil SIP de Entrada

Observação: é necessário habilitar a entrada do perfil sip no serviço de voz voip sip se o aplicativo global, o locatário ou o aplicativo de peer de discagem for usado.

! Global Application 
voice service voip
 sip
  sip-profiles inbound
  sip-profiles <number> inbound
!

! Tenant Application
voice service voip
 sip
  sip-profiles inbound
!
voice class tenant <tag>
 sip-profiles <tag> inbound
!

! Dial-Peer Application
voice service voip
 sip
  sip-profiles inbound
!
dial-peer voice <tag> voip
 voice-class sip profiles <number> inbound
!

Exemplo de perfil SIP para modificar mensagens de keepalive OPTIONS.

!
voice class sip-options-keepalive 200
 transport tcp tls
 sip-profiles 299
!

Perfil SIP de Exemplo para modificar Host, Domínio ou ambas as partes de um URI.

! Host
!
voice class sip-profiles 1
 request ANY sip-header Contact modify "sip:(.*)@" "sip:8675309@"
!
! Domain
!
voice class sip-profiles 2
 request ANY sip-header Contact modify "10.67.138.241:5060" "cisco.com"
!
! Note: Port is optional
!
! Modify Both User and Host
!
voice class sip-profiles 3
 request ANY sip-header Contact modify "sip:(.*)>" "sip:8675309@cisco.com>"
!

Perfil SIP de Exemplo para adicionar, modificar ou remover cabeçalhos de Desvio.

! Add
!
voice class sip-profiles 777
 request INVITE sip-header Diversion add "Diversion: <sip:1234@cisco.com>"
!
!
! Modify
!
voice class sip-profiles 888
 request INVITE sip-header Diversion modify "sip:(.*)>" "sip:1234@cisco.com>"
!
!
! Remove
!
voice class sip-profiles 999
 request INVITE sip-header Diversion remove
!

Perfil SIP de exemplo para modificar a parte do nome do ID do chamador dos cabeçalhos SIP.

!
voice class sip-profiles 123
 request INVITE sip-header From modify "\".*\"" "\"TEST CLID*\""
!

Exemplo de perfil SIP para alterar uma sessão 183 em andamento para um toque 180.

!
voice class sip-profiles 789
 response 183 sip-header SIP-StatusLine modify "SIP/2.0 183 Session in Progress" "SIP/2.0 180 Ringing"
!

Exemplo de perfil SIP para interoperabilidade de áudio unidirecional ou não-unidirecional com um provedor.

!
voice class sip-profiles 200
 request ANY sdp-header Audio-Attribute modify "a=inactive" "a=sendrecv"
 request ANY sdp-header Audio-Connection-Info modify "0.0.0.0" "10.10.10.10" 
!
! where 10.10.10.10 is CUBE's provider facing IP address

Perfil SIP de exemplo para remover o método UPDATE para problemas de interoperabilidade.

!
voice class sip-profiles 200
 request ANY sip-header Allow-Header modify ", UPDATE" ""
!

Exemplo de perfil SIP mostrando o uso do SET dentro do perfil SIP. Esse é o mesmo conceito de Conjuntos descritos na seção voice translation-rule.

!
voice class sip-profiles 1
 request ANY sip-header Contact modify "sip:(.*)@" "sip:\1@"
!

A configuração da lógica IF e quebras de nova linha com um perfil SIP.

As quebras de nova linha são suportadas em perfis SIP, no entanto, há apenas um caso de uso muito específico para eles. Como os perfis SIP não têm nenhuma lógica If, Then, Else, agora há uma maneira de executar modificações em um cabeçalho com base em uma entrada de outro cabeçalho. Por exemplo, um administrador só deseja modificar um cabeçalho de desvio se o cabeçalho FROM contiver 1234@cisco.com. Utilizando a quebra de nova linha, podemos falsificar a instrução IF em um perfil SIP. Consulte o exemplo de configuração: Você pode corresponder a 1234 em qualquer domínio no cabeçalho De. Em seguida, traga o primeiro conjunto e adicione uma nova quebra de linha \x0D\x0AD. Finalmente, você adiciona o cabeçalho desejado. Veja que esse método permite apenas ADICIONAR um cabeçalho. Não há como modificar outro cabeçalho. Assim, isso atende apenas parcialmente aos requisitos que um administrador desejava atingir anteriormente.

!
voice class sip-profiles 1
 request INVITE sip-header From modify “(.*sip:1234@.*)” “\1\x0D\x0ADiversion: <sip:5678@example.com>”
!

Exemplo de perfil SIP com lógica OR.

!
voice class sip-profiles 123
 request ANY sdp-header Audio-Attribute modify "(a=sendonly|a=recvonly|a=inactive)" "a=sendrecv"
 response ANY sdp-header Audio-Attribute modify "(a=sendonly|a=recvonly|a=inactive)" "a=sendrecv"
!

Exemplo de Inspeção SIP de Camada 7 via Perfil SIP.

### Usage
10.21.15.10 replace with private IP of CUBE
a.b.c.d replace with public IP
------------------------------------------------------

### Inbound from ITSP Layer 7 Fixup
!
voice class sip-profiles 888
 request INVITE sip-header SIP-Req-URI modify "@.*;" "@10.21.15.100;"
!
voice service voip
 sip
  sip-profiles inbound
!

### Outbound Layer 7 Fixup
!
voice class sip-profiles 777
 request ANY sip-header Contact modify "<sip:(.*)@10.21.15.100:5060>" "<sip:\1 a.b.c.d:5060>" 
 response ANY sip-header Contact modify "<sip:(.*)@10.21.15.100:5060>" "<sip:\1 a.b.c.d:5060>" 
 request ANY sip-header Via modify "SIP(.*) 10.21.15.100(.*)" "SIP\1 a.b.c.d\2" 
 request ANY sdp-header Session-Owner modify "(.*IP4 ).*" "\1a.b.c.d" 
 request ANY sdp-header Connection-Info modify "IN IP4 10.21.15.100" "IN IP4 a.b.c.d" 
 request ANY sdp-header Audio-Connection-Info modify "IN IP4 10.21.15.100" "IN IP4 a.b.c.d" 
 response ANY sdp-header Session-Owner modify "(.*IP4 ).*" "\1a.b.c.d" 
 response ANY sdp-header Audio-Connection-Info modify "IN IP4 10.21.15.100" "IN IP4 a.b.c.d" 
 response ANY sdp-header Connection-Info modify "IN IP4 10.21.15.100" "IN IP4 a.b.c.d"
 request ANY sip-header Remote-Party-ID modify "<sip:(.*)@10.21.15.100>" "<sip:\1 a.b.c.d>" 
 response ANY sip-header Remote-Party-ID modify "<sip:(.*)@10.21.15.100>" "<sip:\1 a.b.c.d>"
!

### Apply to dial-peers for the side of the CUBE facing the ITSP
!
dial-peer voice 1 voip
 voice-class sip profiles 777
 voice-class sip profile 888 inbound
!
dial-peer voice 2 voip
 voice-class sip profiles 777
 voice-class sip profile 888 inbound
!

Lista de cópias SIP

As Listas de Cópias SIP são uma extensão dos Perfis SIP que permitem que o gateway COPIE um cabeçalho do trecho interno de uma chamada e, em seguida, COLE em outro ponto da mensagem SIP de saída no trecho externo. O suporte à lista de cópias SIP foi adicionado no Cisco IOS 15.1(3)T e no Cisco IOS XE 3.6S. Essa é uma maneira muito eficiente de criar cabeçalhos dinâmicos com base em outros cabeçalhos da parte interna da chamada.

O caso de uso mais comum é copiar dinamicamente um cabeçalho FROM para um cabeçalho diferente, como desvio ou p-asserted-id, de modo que o valor da parte do usuário seja o do usuário. Isso é feito principalmente para fins de autenticação, bem como para fins de identificação do chamador.

Documentação completa: Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 em diante

Exemplo de lista de cópia SIP

!
! Create Copylist to copy the FROM header on the inbound message specified later.
!
voice class sip-copylist <number>
 sip-header From
!
! Apply this to the inbound dial-peer of the call.
!
dial-peer voice <tag> voip
 voice-class sip copy-list <number>
!
! Create SIP Profile to take From (peer-header) stored as variable "u01" and apply to a header of choice.
! This example modifies the user portion of the Contact by copying the user portion of the From header to the user portion of the Contact header.
!
voice class sip-profiles <number>
 request INVITE peer-header sip From copy "<sip:(.*)@" u01
 request INVITE sip-header Contact modify "<sip:(.*)>" "<sip:\u01@10.50.244.2>" 
!
! Apply the SIP profile to an outbound dial-peer
!
dial-peer voice <tag> voip
 voice-class sip profiles <number>
!

Depurando perfis SIP e lista de cópia

debug voip ccapi inout
debug ccsip mess
debug ccsip info
debug ccsip feature sip-profile 

Saída de depuração da lista de cópia SIP de exemplo

### Ingress from CUCM
Received:
INVITE sip:1001@10.50.228.61:5060 SIP/2.0
Via: SIP/2.0/TCP 10.50.244.3:5060;branch=z9hG4bKaad21bc3ae7e
From: "5001" <sip:5001@10.50.244.3>;tag=100442~cdffff43-5020-4e79-a10b-99d406971010-36470319
Contact: <sip:5001@10.50.244.3:5060;transport=tcp>

### Copylist Details
00440: Mar  8 18:59:49.796: //-1/xxxxxxxxxxxx/SIP/Info/info/64/sip_profiles_application_peer_copy_pattern: sed_match succeeded
000441: Mar  8 18:59:49.797: //187/D6138E000000/SIP/Info/info/64/sip_profiles_application_peer_copy_pattern: SIP Profiles COPY variables AVL tree created
000442: Mar  8 18:59:49.797: //-1/xxxxxxxxxxxx/SIP/Info/info/64/sip_profiles_prefix_slash_in_copy_var_val: ret_dst: 5001
000443: Mar  8 18:59:49.797: //187/D6138E000000/SIP/Info/info/64/sip_profiles_application_peer_copy_pattern: SIP Profiles COPY variable: u1 val: 5001
000444: Mar  8 18:59:49.797: //-1/xxxxxxxxxxxx/SIP/Info/info/64/sip_profiles_application_modify_remove_header: Header before modification : Contact: <sip:5001@10.50.228.61:5060>
000445: Mar  8 18:59:49.797: //187/D6138E000000/SIP/Info/info/64/sip_profiles_check_and_get_variables_in_replace_pattern: Node found: COPY variable: u1 val: 5001
000446: Mar  8 18:59:49.797: //187/D6138E000000/SIP/Info/info/64/sip_profiles_check_and_get_variables_in_replace_pattern: substituted_replace_pattern :  : @168.117.64.94>
000448: Mar  8 18:59:49.797: //187/D6138E000000/SIP/Info/info/64/sip_profiles_check_and_get_variables_in_replace_pattern: Final substituted_replace_pattern : <sip:5001@168.117.64.94>
000449: Mar  8 18:59:49.797: //-1/xxxxxxxxxxxx/SIP/Info/info/64/sip_profiles_app_modify_header: Passing substituted replace pattern
000450: Mar  8 18:59:49.798: //-1/xxxxxxxxxxxx/SIP/Info/info/64/sip_profiles_application_modify_remove_header: Header after modification : Contact: <sip:5001@168.117.64.94>
000451: Mar  8 18:59:49.798: //187/D6138E000000/SIP/Msg/ccsipDisplayMsg:

### Egress from CUBE
Sent:
INVITE sip:1001@14.50.228.63:5060 SIP/2.0
Via: SIP/2.0/UDP 10.50.228.61:5060;branch=z9hG4bK3C7CD
Remote-Party-ID: "5001" <sip:5001@10.50.228.61>;party=calling;screen=yes;privacy=off
From: "5001" <sip:5001@10.50.228.61>;tag=34C458-D6
Contact: <sip:5001@168.117.64.94>

Observações especiais

Sinalização de protocolo e vinculação de mídia

Todos os protocolos de sinalização permitem que os administradores associem a sinalização a uma interface específica. Por padrão, um gateway sem uma associação estática definida, o gateway origina a sinalização para uma chamada da interface física pela qual o pacote atravessa. Com a vinculação em um peer de discagem, o pacote apresenta cabeçalhos de origem, mensagens e pacotes da interface especificada, mas o pacote real ainda roteia pela interface física. A ligação de peer de discagem sempre substitui a ligação de voz de classe de locatário e serviço de voz global com o Session Initiation Protocol (SIP).

Muitas vezes, os administradores ligam a sinalização a um loopback. Ser uma interface lógica significa que nenhum pacote passa por essa interface. Para realizar capturas de pacotes, a captura deve ser realizada em uma interface física. O comando show ip cef <remote-ip> exibe a interface física que um pacote utiliza para rotear para o IP de destino/remoto, mesmo que a configuração esteja vinculada a uma interface virtual.

A ligação de mídia e sinalização nem sempre precisa ser o mesmo IP. Se um administrador precisa se vincular a uma interface específica para sinalização para/de um CUCM, mas o áudio/mídia entre o telefone e o gateway pode precisar se vincular a outra interface.

Exemplo de configuração

Este exemplo mostra um peer de discagem associado ao loopback 1 e recebe uma chamada do CUCM.

Embora a mídia e a sinalização (controle) estejam vinculadas ao loopback 1, o comando show ip cef mostra que todos os pacotes enviados ao CUCM saem na interface física GigabitEthernet0/0/1.

!
dial-peer voice 2 voip
 description "Incoming call from CUCM"
 session protocol sipv2
 incoming called-number .
 voice-class sip bind control source-interface Loopback1
 voice-class sip bind media source-interface Loopback1
!

Ordem de operações para vinculação de aplicação da camada 7

1. De acordo com a instrução bind no peer de discagem de entrada/saída correspondente.
2. De acordo com as associações sob o locatário da classe de voz atribuído ao correspondente de discagem de entrada/saída correspondente.
3. De acordo com a declaração de vinculação global.
4. De acordo com a interface física da camada 3, espera-se que o pacote saia baseado na tabela de roteamento.

Comandos de vinculação SIP

! Per Dial-peer
!
dial-peer voice 1 voip
 voice-class sip bind control source-interface <interface>
 voice-class sip bind media source-interface <interface>
!
! Global Binding
!
voice service voip
 sip
   bind control source-interface <interface>
   bind media source-interface <interface>
!

Comandos de vinculação MGCP

!
mgcp bind control source-interface <interface>
mgcp bind media source-interface <interface>
!

Comandos de vinculação SCCP

!
sccp local <interface>
!
sccp ccm group <number>
 bind interface <interface>
!

Comandos de vinculação H323

!
inteface <interface>
 !
 ! Media Bind Command:
 h323-gateway voip interface
 !
 ! Signaling Bind Command:
 h323-gateway voip bind srcaddr <a.b.c.d>
!

Peers de discagem DNS e VoIP

O DNS com VOIP é empregado como qualquer outra solução DNS. Uma configuração comum é utilizar o destino de sessão dns:FQDN.com.

Um gateway Cisco executa uma resolução DNS mesmo quando nenhuma pesquisa de domínio ip é configurada globalmente no gateway. Isso significa que mesmo que você esteja desabilitando o DNS, os peers de discagem VOIP ainda resolvem a entrada DNS. No entanto, recentemente, no Cisco IOS XE 3.16S, houve algumas alterações na funcionalidade geral do DNS nas plataformas Cisco IOS XE.

Após essa alteração, os peers de discagem configurados com o destino da sessão dns:FQDN.com obedecem agora ao fato de que o DNS está desabilitado sem nenhuma pesquisa de domínio ip.
Recomendo sempre garantir que o comando "ip domain lookup" esteja configurado ao trabalhar com o DNS para evitar esse problema.

Para conexões SIP de saída, o CUBE executa essa ordem de operações para a resolução DNS.

1. Pesquisa de consulta SRV
2. Uma Pesquisa de Registro
3. Pesquisa de Registro AAAA

Para obter informações sobre como o SRV é criado ou como ignorar o SRV e executar uma consulta de registro A em um destino de sessão, consulte a documentação completa: Guia de configuração do Cisco Unified Border Element - Cisco IOS XE 17.6 em diante

Para conexões SIP de entrada em que um gateway IOS precisa resolver um cabeçalho para responder a uma mensagem, o gateway pode usar essa ordem de operações para Resolução DNS

1. Uma Pesquisa de Registro
2. Pesquisa de Registro AAAA

No Cisco IOS XE 17.9.1, o CUBE pode verificar a acessibilidade de destinos de sessão DNS por meio de mecanismos de manutenção de atividade de opções. Veja a documentação completa:

Guia de configuração do Cisco Unified Border Element - Cisco IOS XE 17.6 em diante

Amostras de configuração do IOS DNS

ip host _sip._udp.cucmgroup.lab.local srv 1 50 5060 cucm1.lab.local
ip host _sip._udp.cucmgroup.lab.local srv 1 50 5060 cucm2.lab.local
ip host _sip._udp.cucmgroup.lab.local srv 1 50 5060 cucm3.lab.local

ip host cucm1.lab.local 10.0.0.1
ip host cucm2.lab.local 10.0.0.2
ip host cucm3.lab.local 10.0.0.3

ip domain name lab.local
ip name-server 8.8.8.8

Observação: o suporte a DNS SRV no Cisco IOS XE é suportado no 15.6(1)S / 3.17.00.S e superior.

Depurações de DNS e comandos de verificação

show host
clear host all *
!
debug ip dns view
debug ip domain
debug ccsip info
debug ccsip error

Teste de DNS 3.15S e posterior

### Domain Name Verification
Gateway# sh run | s lookup
no ip domain lookup

### Checking the host table for no entry
Gateway# show host
Name lookup view: Global
Default domain is cisco.com
Name/address lookup uses static mappings

Codes: UN - unknown, EX - expired, OK - OK, ?? - revalidate
       temp - temporary, perm - permanent
       NA - Not Applicable None - Not defined

Host                      Port  Flags      Age Type   Address(es)

### Verification of no PING on a FQDN
Gateway# ping cucm.cisco.com
Translating "cucm.cisco.com"
% Unrecognized host or address, or protocol not running.

### Made a test call here

### Checking logs to see if it worked
Gateway# sh log | s INVITE sip:
INVITE sip:9001@14.50.228.70:5060 SIP/2.0
INVITE sip:5001@cucm.cisco.com:5060 SIP/2.0

### Host Table now has an entry
Gateway# sh host
Name lookup view: Global
Default domain is cisco.com
Name/address lookup uses static mappings

Codes: UN - unknown, EX - expired, OK - OK, ?? - revalidate
       temp - temporary, perm - permanent
       NA - Not Applicable None - Not defined

Host                      Port  Flags      Age Type   Address(es)
cucm.cisco.com            None  (temp, OK)  0   IP    10.50.244.2

### CCSIP All output showing a proper DNS Query for the FQDN on the dial-peer.
001338: Mar  9 15:29:07.437: //-1/xxxxxxxxxxxx/SIP/Info/info/1024/httpish_msg_free: Freed msg=0x7FE9873AE560
001339: Mar  9 15:29:07.437: //-1/xxxxxxxxxxxx/SIP/Info/notify/8192/sip_dns_type_srv_query: TYPE SRV query for _sip._udp.cucm.cisco.com and type:1
001340: Mar  9 15:29:07.438: //-1/xxxxxxxxxxxx/SIP/Info/info/8192/sip_dns_type_a_aaaa_query: DNS query for cucm.cisco.com and type:1
001341: Mar  9 15:29:07.441: //-1/xxxxxxxxxxxx/SIP/Info/notify/8192/sip_dns_type_a_query: TYPE A query successful for cucm.cisco.com
001342: Mar  9 15:29:07.441: //-1/xxxxxxxxxxxx/SIP/Info/info/8192/sip_dns_type_a_query: ttl for A records = 3600 seconds
001343: Mar  9 15:29:07.441: //-1/xxxxxxxxxxxx/SIP/Info/info/8192/sip_dns_type_a_aaaa_query: IP Address of cucm.cisco.com is:
001344: Mar  9 15:29:07.441: //-1/xxxxxxxxxxxx/SIP/Info/info/8192/sip_dns_type_a_aaaa_query: 10.50.244.2

Teste de DNS 3.16S e superior.

### Checking the command is present
Gateway# sh run | s lookup
no ip domain lookup

### Verifying the gateway cannot ping a FQDN
Gateway# ping cucm.cisco.com
% Unrecognized host or address, or protocol not running.

### Checking the Host Table for entries
Gateway# sh host
Default domain is cisco.com
Name servers are 10.50.244.52
NAME  TTL  CLASS   TYPE      DATA/ADDRESS
-----------------------------------------

### Made a test call here

### CCSIP All Outbound showing the failed call
000974: *Mar  9 15:53:01.222: //-1/xxxxxxxxxxxx/SIP/Info/info/1024/httpish_msg_free: Freed msg=0x7FF31DAAA848
000975: *Mar  9 15:53:01.222: //-1/xxxxxxxxxxxx/SIP/Info/notify/8192/sip_dns_type_srv_query: TYPE SRV query for _sip._udp.cucm.cisco.com and type:1
000976: *Mar  9 15:53:01.224: //-1/xxxxxxxxxxxx/SIP/Info/info/8192/sip_dns_type_a_aaaa_query: DNS query for cucm.cisco.com and type:1
000977: *Mar  9 15:53:01.225: //-1/xxxxxxxxxxxx/SIP/Error/sip_dns_type_a_query:
 TYPE A query failed for cucm.cisco.com
000978: *Mar  9 15:53:01.225: //-1/xxxxxxxxxxxx/SIP/Error/_send_dns_fail:
 DNS Query for cucm.cisco.com failed
000984: *Mar  9 20:53:01.225: %VOICE_IEC-3-GW: SIP: Internal Error (DNS query fail): IEC=10.1.128.7.47.0 on callID 6 GUID=37B668DF044111E7A950D832C82B325C

Máximo de conexões e largura de banda

Por padrão, os peers de discagem VOIP e POTS permitem conexões ilimitadas (chamadas) e largura de banda (somente peers de discagem VOIP). Para troncos que têm um limite no número de chamadas ou na largura de banda que pode ser utilizada, pode ser útil empregar os comandos max-conn ou max-bandwidth. max-conn foi adicionado no Cisco IOS 11.3(1)T e está presente em todas as versões do Cisco IOS XE, enquanto max-bandwidth foi adicionado no 15.2(2)T e no IOS-XE 3.7S.

Exemplo de configuração:

Aqui você diz ao gateway para limitar as chamadas do correspondente de discagem de 1 a 30 usando "max-conn 30".
O peer de discagem 2 está limitando a largura de banda desse peer de discagem para que não excedamos o limite alocado.

!
dial-peer voice 1 voip
 description ITSP SIP Trunk - 30 Max Calls!
 session protocol sipv2
 sess target ipv4:10.10.10.10
 destination-pattern 8675309$
 max-conn 30
!
dial-peer voice 2 voip
 description SIP Trunk with Bandwidth Restrictions!
 session protocol sipv2
 sess target ipv4:10.10.10.10
 destination-pattern 123456789$
 max-bandwidth 400
!

Exemplo de erro quando o limiar max-conn é ultrapassado.

000308: Oct  5 19:01:02.603: %CALL_CONTROL-6-MAX_CONNECTIONS: Maximum number of connections reached for dial-peer 1
 
000309: Oct  5 19:01:02.603: %VOICE_IEC-3-GW: CCAPI: Internal Error (Dial-peer connections exceeded): IEC=10.1.181.1.21.0 on callID 0
000310: Oct  5 19:01:02.604: %SIP-3-MAXCONNCAC: Call rejected due to CAC based on maximum number of connections on dial-peer 1, sent response 503

000311: Oct  5 19:01:02.604: //17084/86B070800000/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 503 Service Unavailable
Via: SIP/2.0/TCP 10.50.244.62:5060;branch=z9hG4bKb78c35aa21b0
From: <sip:9001@10.50.244.62>;tag=72531~2e8ca155-3f0b-4f07-a1b2-b14ef77ceb7f-26250846
To: <sip:1234@10.50.245.70>;tag=3E19564D-1684
Date: Thu, 05 Oct 2017 19:01:02 GMT
Call-ID: 86b07080-9d61816e-b762-3ef4320e@10.50.244.62
CSeq: 101 INVITE
Allow-Events: telephone-event
Warning: 399 10.50.245.70 "Maximum Number of Connections reached for dial-peer 1"
Server: Cisco-SIPGateway/IOS-15.4.3.S4
Content-Length: 0

Discagem interna direta (DID)

Discagem em um estágio

Com a Direct Inward Dial ativada nos peers de discagem POTS, as mensagens de entrada podem conter todos os dígitos necessários para rotear a chamada. O Cisco Gateway não pode fazer a coleta de dígitos subsequente. Quando o roteador ou gateway procura um peer de discagem de saída, o dispositivo usa a string de discagem de entrada inteira. Essa correspondência é de comprimento variável por padrão. Essa correspondência não é feita dígito por dígito porque, pela definição DID, todos os dígitos foram recebidos. Esta é a configuração padrão para peers de discagem POTS.

Documentação Completa: Entendendo Direct-Inward-Dial (DID) em Interfaces Digitais de Voz (T1/E1) do IOS

Exemplo de configuração

!
dial-peer voice 1 pots
 incoming called-number 8675309
 voice-port 0/0/0
 direct-inward-dial
!

Discagem em dois estágios

Se o peer de discagem POTS de entrada estiver configurado com no direct-inward-dial, o roteador ou gateway entra no modo de coleta de dígitos (os dígitos são coletados na banda). A correspondência de peer de discagem de saída é feita dígito por dígito. O roteador ou gateway verifica as correspondências do peer de discagem depois que o dispositivo recebe cada dígito e, em seguida, roteia a chamada quando uma correspondência completa é feita.

Exemplo de configuração

!
dial-peer voice 1 pots
 incoming called-number 8675309
 voice-port 0/0/0
 no direct-inward-dial
!

Bloqueando chamadas

Cada protocolo lida com o bloqueio de chamadas de forma um pouco diferente. A maioria dos protocolos pode fazer uso do padrão de rejeição da regra de tradução que bloqueia com base em uma sequência de caracteres de dígitos. Se um administrador ainda quiser aplicar um perfil de conversão de entrada para manipulação normal de dígitos, mas não quiser bloquear nenhum número dentro dele, existe a opção de implementar um bloco de chamadas usando o comando call-block translation-profile.

!
voice translation-rule 164
 rule 1 reject /8675309/
!
voice translation-profile CALLBLOCK
 translate calling 164
!
dial-peer voice 1 pots
 desc INCOMING VOICE-PORT with BLOCK
 translation-profile incoming ANOTHER
 call-block translation-profile incoming CALLBLOCK
 call-block disconnect-cause incoming invalid-number
 incoming called-number .
 port 0/0/0:23
!

Gateway#test voice translation-rule 164 8675309
8675309 blocked on rule 1

No E1 R2, existe a capacidade de um administrador bloquear chamadas de coleta. Isso é visto e empregado principalmente em implantações no Brasil, mas pode ser configurado por meio de qualquer grupo cas-custom.

As duas opções são:

1. Bloqueie a chamada de coleta recebida com base na categoria II-8 recebida do switch telco. Esse é o mecanismo padrão e todos os Cisco Gateways executam isso sem nenhuma configuração. Esse método de bloqueio requer um switch telco mais novo que suporte a marcação baseada em categoria. Para desativar esse método, use o comando collect-call-enable no grupo cas-customer.
2. Utilize o recurso double-answer em um grupo cas-custom de E1 R2 digital R2. A configuração de resposta dupla desativa o bloqueio baseado em categoria e o substitui pelo recurso de resposta dupla. Isso funciona respondendo primeiro a chamada recebida e iniciando um temporizador de 1 segundo. Após 1 segundo, o gateway envia uma versão na forma de um comando CLEAR BWD. A Telco pode enviar um FWD LIMPO para o gateway e a chamada pode ser desconectada. Um temporizador é iniciado depois que o gateway envia o CLEAR BWD e, se esse temporizador expirar, o gateway enviará outro sinal de ATENDIMENTO, assumindo que a chamada não é uma chamada de coleta e, a partir daí, a chamada continua normalmente. Esse temporizador pode ser configurado usando cc-reanswer-to dentro do grupo cas-custom.

Mensagem de bloqueio de Categoria II-8 (debug vpm signal)

009228: Nov 21 12:02:00.955 GMT: //-1/BF12BE36BAC8/VTSP:(0/0/0:0):-1:1:2/vtsp_report_cas_digit: 
   Begin Digit=8, Mode=CC_TONE_R2_MF_BACKWARD_MODE
009229: Nov 21 12:02:00.955 GMT: htsp_digit_ready_up(0/0/0:0(2)): Rx digit='8'
009230: Nov 21 12:02:00.955 GMT: R2 Incoming Voice(0/0): DSX (E1 0/0/0:1): STATE: R2_IN_CATEGORY R2 Got Event 8
009231: Nov 21 12:02:00.955 GMT: Enter r2_comp_category
009232: Nov 21 12:02:00.955 GMT:  R2 Event : 8
009233: Nov 21 12:02:00.955 GMT:  #######R2_II8 TRUE########
009234: Nov 21 12:02:00.955 GMT:  ####### collect_call_enable = 0
009235: Nov 21 12:02:00.955 GMT:  ############sending B7 ##########
009236: Nov 21 12:02:00.955 GMT: r2_reg_generate_digits(0/0/0:0(2)): Tx digit '7'
009237: Nov 21 12:02:01.055 GMT: //-1/BF12BE36BAC8/VTSP:(0/0/0:0):-1:1:2/vtsp_report_cas_digit: 
   End Digit=8, Mode=CC_TONE_R2_MF_BACKWARD_MODE
009238: Nov 21 12:02:01.055 GMT: htsp_digit_ready(0/0/0:0(2)): Rx digit='#'
009239: Nov 21 12:02:01.055 GMT: R2 Incoming Voice(0/0): DSX (E1 0/0/0:1): STATE: R2_IN_CATEGORY R2 Got Event R2_TONE_OFF
009240: Nov 21 12:02:01.055 GMT: Enter r2_comp_category
009241: Nov 21 12:02:01.055 GMT: r2_reg_generate_digits(0/0/0:0(2)): Tx digit '#'
009242: Nov 21 12:02:01.359 GMT: htsp_dsp_message: SEND_SIG_STATUS: state=0x8 timestamp=22365 systime=225097425
009243: Nov 21 12:02:01.359 GMT: htsp_process_event: [0/0/0:0(2), R2_Q421_IC_WAIT_ANSWER, E_DSP_SIG_1000]
009244: Nov 21 12:02:01.359 GMT: r2_q421_ic_clr_fwd_idle(0/0/0:0(2)) Rx CLEAR FWD
009245: Nov 21 12:02:01.359 GMT: r2_reg_channel_disconnected(0/0/0:0(2))
009246: Nov 21 12:02:01.359 GMT: R2 Incoming Voice(0/0): DSX (E1 0/0/0:1): STATE: R2_IN_CATEGORY R2 Got Event R2_STOP
009247: Nov 21 12:02:01.359 GMT: Enter r2_comp_category
009248: Nov 21 12:02:01.359 GMT: htsp_timer - 2000 msec
009249: Nov 21 12:02:01.359 GMT: htsp_process_event: [0/0/0:0(2), R2_Q421_IC_CLR_FWD, E_HTSP_RELEASE_REQ]
009250: Nov 21 12:02:01.359 GMT: r2_q421_null_release(0/0/0:0(2)) E_HTSP_RELEASE_REQ
009251: Nov 21 12:02:01.359 GMT: r2_reg_process_event: [0/0/0:0(2), R2_REG_COLLECTING, E_R2_REG_DISCONNECT(91)]
009252: Nov 21 12:02:01.359 GMT: r2_reg_disconnect_collect(0/0/0:0(2))
009253: Nov 21 12:02:01.359 GMT: r2_reg_timer_stop(0/0/0:0(2))
009254: Nov 21 12:02:01.711 GMT: htsp_process_event: [0/0/0:0(1), R2_Q421_IC_CLR_FWD, E_HTSP_EVENT_TIMER]
009255: Nov 21 12:02:01.711 GMT: htsp_timer_stop
009256: Nov 21 12:02:01.711 GMT: r2_q421_clr_fwd_idle(0/0/0:0(1)) Tx IDLEvnm_dsp_set_sig_state:[R2 Q.421 0/0/0:0(1)] set signal state = 0x8
009257: Nov 21 12:02:01.711 GMT: r2_reg_channel_disconnected(0/0/0:0(1))
009258: Nov 21 12:02:01.711 GMT: //682206/0C63B263B9C9/VTSP:(0/0/0:0):0:1:1/vtsp_do_call_history: 
   Coder Rate=5
009259: Nov 21 12:02:01.711 GMT: r2_reg_process_event: [0/0/0:0(1), R2_REG_IDLE, E_R2_REG_DISCONNECT(91)]

Exemplo de Configuração com Resposta Dupla

!
controller e1 0/0/0
 ds0-group 0 timeslots 1-15,17-31 type r2-digital r2-compelled ani
 cas-custom 0
  country brazil
  double-answer
  cc-reanswer-to 3000
!

Depurações com Resposta Dupla (debug vpm signal)

### Answer the call and start a 1 second timer
May 23 09:52:59.180 BR: r2_q421_ic_answer(0/0/0:0(18)) Tx ANSWER seizure: delay 0 ms,elapsed 12404 msvnm_dsp_set_sig_state:[R2 Q.421 0/0/0:0(18)] set signal state = 0x4
May 23 09:52:59.180 BR: r2_reg_channel_connected(0/0/0:0(18))
May 23 09:52:59.180 BR: htsp_timer - 1000 msec
May 23 09:52:59.180 BR: //23899578/92233E71B421/CCAPI/cc_api_voice_mode_event:
   Call Id=23899578
May 23 09:52:59.180 BR: //23899578/92233E71B421/CCAPI/cc_api_voice_mode_event:
   Call Entry(Context=0x1E73AD8)
May 23 09:52:59.180 BR: htsp_process_event: [0/0/0:0(18), R2_Q421_IC_DOUBLE_ANS_ANS, E_HTSP_VOICE_CUT_THROUGH] all
May 23 09:52:59.184 BR: //23899578/92233E71B421/CCAPI/cc_process_notify_bridge_done:
   Conference Id=0x10AD1, Call Id1=23899578, Call Id2=23899579
May 23 09:52:59.184 BR: r2_reg_process_event: [0/0/0:0(18), R2_REG_WAIT_FOR_CONNECT, E_R2_REG_CONNECT(90)] 
May 23 09:52:59.184 BR: r2_reg_connect(0/0/0:0(18))

### One Second Passes and we clear the call and start a 2 second timer
May 23 09:53:00.180 BR: htsp_process_event: [0/0/0:0(18), R2_Q421_IC_DOUBLE_ANS_ANS, E_HTSP_EVENT_TIMER]
May 23 09:53:00.180 BR: r2_q421_ic_d_answ_answ_to(0/0/0:0(18)) E_TIMER_EVENT
May 23 09:53:00.180 BR: htsp_timer - 2000 msec
May 23 09:53:00.180 BR: r2_q421_ic_d_answ_answ_to(0/0/0:0(18)) Tx CLEAR BWDvnm_dsp_set_sig_state:[R2 Q.421 0/0/0:0(18)] set signal state = 0xC
May 23 09:53:00.824 BR: htsp_process_event: [0/0/0:0(18), R2_Q421_IC_DOUBLE_ANS_RLS, E_DSP_SIG_1000]
May 23 09:53:00.824 BR: r2_q421_ic_answer_clr_fwd(0/0/0:0(18)) Rx CLEAR FWD
May 23 09:53:00.824 BR: r2_reg_channel_disconnected(0/0/0:0(18))
May 23 09:53:00.824 BR: htsp_timer - 2000 msec
May 23 09:53:00.824 BR: r2_reg_process_event: [0/0/0:0(18), R2_REG_CONNECTED, E_R2_REG_DISCONNECT(91)] 
May 23 09:53:00.824 BR: r2_reg_disconnect_idle(0/0/0:0(18))
May 23 09:53:00.824 BR: R2 Incoming Voice(0/0): DSX (E1 0/0/0:17): STATE: R2_IN_IDLE R2 Got Event R2_STOP
May 23 09:53:00.824 BR: r2_reg_timer_stop(0/0/0:0(18))

### 2 second passes and the gateway release the call
May 23 09:53:02.824 BR: htsp_process_event: [0/0/0:0(18), R2_Q421_IC_CLR_FWD, E_HTSP_EVENT_TIMER]
May 23 09:53:02.824 BR: htsp_timer_stop 
May 23 09:53:02.824 BR: r2_reg_channel_disconnected(0/0/0:0(18))
May 23 09:53:02.824 BR: //23899578/92233E71B421/VTSP:(0/0/0:0):17:1:1/vtsp_cc_call_disconnected:  
   Cause Value=16
May 23 09:53:02.824 BR: //23899578/92233E71B421/CCAPI/cc_api_call_disconnected:
   Cause Value=16, Interface=0xB41CEBC, Call Id=23899578

ISDN overlap-receiving

Há implicações para a correspondência de peer de discagem de entrada quando o comando isdn overlap-receiving é configurado nas interfaces ISDN. Depois que cada dígito é recebido na camada ISDN, os correspondentes de discagem são verificados quanto a correspondências. Se uma correspondência completa for feita, a chamada será roteada imediatamente (para o aplicativo da sessão, nesse caso) sem esperar dígitos adicionais. O terminador T pode ser usado para suspender essa correspondência dígito por dígito e forçar o roteador ou gateway a esperar até que todos os dígitos sejam recebidos. O T refere-se ao temporizador interdígitos T302 no nível ISDN, configurável na interface serial associada à interface ISDN. A ISDN também fornece outros mecanismos para indicar o fim dos dígitos, como a configuração do Sending Complete Information Element (IE) nas mensagens de informação Q.931.

Número Chamado Vazio

A mensagem de aviso mostrada é exibida quando o correspondente de discagem está configurado com incoming called-number T.

Saída de exemplo

Gateway(config)# dial-peer voice 1 pots
Gateway(config-dial-peer)# incoming called-number T
Warning: Pattern T defines a match with zero or more digits and hence could 
match with an empty number. If this is not the desired behaviour please 
configure pattern .T instead to match on one or more digits

Observações especiais sobre a correspondência do correspondente de discagem recebido com um número chamado vazio.

• Um número chamado nulo é considerado menos qualificado em comparação a uma porta de voz e/ou, em alguns casos, endereço de resposta. Portanto, uma correspondência com base em um número chamado nulo pode ocorrer somente se não houver correspondência com base no endereço de resposta ou no número de porta.

• No caso de discagem sobreposta, um número chamado nulo não corresponde ao número chamado T de entrada porque o tempo limite não ocorreu.

• Um número chamado nulo pode corresponder ao número chamado de entrada T somente no caso de ENBLOCK e não há correspondência por causa do endereço de resposta e do número de porta. O aviso exibido quando um administrador configura o número chamado T de entrada se refere a esse caso específico.

Classe de restrição

A Classe de Restrição (COR) é uma forma de limitar as chamadas em um Gateway Cisco. O COR é frequentemente descrito como um mecanismo de cadeado e chave. Os bloqueios são atribuídos aos correspondentes de discagem com uma lista de COR de saída. As chaves são atribuídas aos correspondentes de discagem com uma lista COR de entrada. Quando as Listas COR são aplicadas, os correspondentes de discagem de saída disponíveis são aqueles que a chave pode desbloquear. Essa filtragem ocorre antes que o restante dos métodos de correspondência do ponto de discagem de saída sejam verificados.

Duas regras importantes com classe de restrição:

1. Se não houver nenhuma lista de COR de saída aplicada, a chamada será sempre roteada.
2. Se não houver nenhuma lista de COR de entrada, a chamada será sempre roteada.

A configuração de Classe de Restrição (COR), Classe de Restrição de Particionamento Lógico (LPCOR) e LPCOR com Códigos de Autorização Forçada (FAC) estão fora do escopo deste documento, mas esses documentos podem ser consultados para leitura posterior.

Correspondentes de discagem do Cisco Unified Communications Manager Express (CUCME)

O CME cria correspondentes de discagem do sistema para ephones e pools de registro de voz. Eles não podem ser vistos na configuração atual. Para fazer alterações nos peers de discagem do CME, as alterações precisam ser feitas no ephone real ou no pool de registro de voz. Ao visualizar as saídas show dial-peer voice summary, o correspondente de discagem que começa com 2000 são ephones SCCP e os correspondentes de discagem que começam com 4000 são pools de registro de voz SIP. Esse peer de discagem aparece como o peer de discagem de entrada para chamadas de telefones registrados CME e o peer de discagem de saída em depurações para chamadas para telefones registrados CME.

Saída de exemplo para show dial-peer voice summary com CME.

Gateway# show dial-peer voice sum | s 2000|4000
20001  pots  up   up             1001$              0                           50/0/1
20002  pots  up   up             4001$              0                           50/0/2
20003  pots  up   up             4002$              0                           50/0/3
20004  pots  up   up             7001$              0                           50/0/4
20005  pots  up   up             3009$              0                           50/0/5
20006  pots  up   up             8810....$          0                           50/0/10
20007  pots  up   up             8811....$          0                           50/0/11
40001  voip  up   up             14085151111$       0  syst ipv4:14.50.214.67:50
40002  voip  up   up             19725252222$       0  syst ipv4:14.50.214.67:50
40003  voip  up   up             85225353333$       0  syst ipv4:14.50.214.67:50
40004  voip  up   up             442084445555$      0  syst ipv4:14.50.214.67:50
40005  voip  up   up             911$               0  syst ipv4:14.50.214.67:50
40006  voip  up   up             18005550100$       0  syst ipv4:14.50.214.67:50
40008  voip  up   up             2001$              0  syst ipv4:14.50.214.51:50

 Saída de exemplo para show voice register dial-peers com SIP CME.

Gateway# show voice register dial-peers
Dial-peers for Pool 2:

dial-peer voice 40006 voip
 destination-pattern 14085151111$
 session target ipv4:14.50.214.67:5060
 session protocol sipv2
 dtmf-relay rtp-nte
 digit collect kpml
 codec  g711ulaw bytes 160
 no vad
  call-fwd-all         8888
  after-hours-exempt   FALSE

dial-peer voice 40005 voip
 destination-pattern 19725252222$
 session target ipv4:14.50.214.67:5060
 session protocol sipv2
 dtmf-relay rtp-nte
 digit collect kpml
 codec  g711ulaw bytes 160
 no vad
  after-hours-exempt   FALSE

MGCP e SCCP com correspondentes de discagem

O MGCP e o SCCP seguem suas próprias regras para peers de discagem. O único conceito que eles utilizam é que eles devem ser configurados com a porta de voz desejada para a chamada. O restante é tratado pelos processos STCAPP e MGCPAPP. Quando você examina a configuração desses peers de discagem, eles têm o comando service mgcpapp ou service stcapp. Eles habilitam o peer de discagem para o aplicativo de sua escolha, bem como informam ao aplicativo qual peer de discagem ele pode manipular.

Ao depurar esses protocolos, a saída nunca exibe uma correspondência de peer de discagem de entrada. Isso sempre pode ser exibido como dial-peer 0. Porque não existe. O Agente de Chamada que está tratando do aplicativo já escolheu para qual porta enviar a chamada e a correspondência do correspondente de discagem de entrada é inútil, já que o gateway não tem controle sobre essa parte da chamada. No entanto, uma correspondência de dial peer de saída pode ser observada. Isso é apenas para exibição, pois, em última análise, o agente de chamadas que trata do processo também tem controle sobre esse lado da chamada.

Lembre-se de que o correspondente de discagem informa apenas ao aplicativo de escolha qual porta de voz física controlar. Como a maior parte disso é controlada por um agente de chamadas externo e o gateway, ele apenas faz o que lhe é dito. Você vai ignorar as instruções básicas desta seção e fornecer algumas configurações para começar.

Exemplo de configuração de MGCP [com Configuração automática de CUCM*]

!
mgcp call-agent 10.10.10.10
mgcp
!
ccm-manager mgcp [codec-all]
ccm-manager config server 10.10.10.10
ccm-manager config
ccm-manger redundant-host 10.10.10.20
!
voice-port 0/0/0
 description The MGCP port to register
 no shut
!
dial-peer voice 1 pots
 description Defining the Port for the MGCP application
 service mgcpapp
 port 0/0/0
!
hostname myrouter
ip domain name cisco.com
ip name server 10.10.10.30
!
ip tftp source-interface gig0/0/0
!

Documentação completa do MGCP: Cisco Unified Communications Manager and Interoperability Configuration Guide, Cisco IOS Release 15M&T

Exemplo de configuração SCCP / STCAPP [com Configuração automática do CUCM*]

!
stcapp ccm-group 1
stcapp
!
sccp local gig0/0/0
sccp ccm 10.10.10.10 id 1 priority 1 version 7.0+
sccp ccm 10.10.10.20 id 1 priority 2 version 7.0+
sccp
!
sccp ccm group 1
 bind interface gig0/0/0
 associate ccm 1 priority 1
 associate ccm 2 priority 2
!
ccm-manager config server 10.10.10.10
ccm-manager sccp local gig0/0/0
ccm-manager sccp
!
voice-port 0/0/0
 description The SCCP port to register
 no shut
!
dial-peer voice 1 pots
 description Defining the Port for the SCCP application
 service stcapp
 port 0/0/0
!
ip tftp source-interface gig0/0/0
!

Se um administrador não quiser que o CUCM configure o gateway, basta remover os comandos ccm-manager. A configuração do peer de discagem é incluída para direcionar para casa o ponto sobre como o conceito funciona. Com as configurações do gerenciador de ccm presentes, o CUCM cria esses peers de discagem com base na configuração de porta no CUCM, portanto não há necessidade de realmente definir o peer de discagem. Os peers de discagem criados pelo CUCM geralmente começam com 999 e depois têm mais três dígitos.

DSAPP SIP com correspondentes de discagem

SIP DSAPP foi adicionado no Cisco IOS XE 16.12.1+ e CUCM 12.5.1SU+

Com esse recurso, as portas de voz analógicas, como FXS, podem ser registradas e gerenciadas pelo CUCM. O roteamento de chamadas com DSAPP é ligeiramente diferente do MGCP ou SCCP, pois os peers de discagem ainda são correspondidos normalmente. Ou seja, o gateway pode coletar dígitos da porta FXS e fazer uma pesquisa de peer de discagem nos peers de discagem VOIP. Depois que uma correspondência é encontrada, o CONVITE é enviado ao bloco CUCM para que o CUCM execute uma análise de dígitos adicional.

Exemplo de configuração DSAPP SIP [com Configuração automática do CUCM*] | IOS-XE 16.12.1+ e CUCM 12.5.1SU+

!
dsapp line
!
voice service voip
 sip
  bind control source-interface GigabitEthernet0/0/0
  bind media source-interface GigabitEthernet0/0/0
  session transport tcp
!
application
 service dsapp
  param dialpeer 777
!
global
 service default dsapp
!
ccm-manager config server 10.10.10.10
ccm-manager sipana auto-config local GigabitEthernet0/0/0
!
dial-peer voice 777 voip
 destination-pattern 9T
 session protocol sipv2
 session target ipv4:10.10.10.10
 session transport tcp
 incoming called-number .
 voice-class sip extension gw-ana
 voice-class sip bind control source-interface GigabitEthernet0/0/0
 dtmf-relay rtp-nte
 codec g711ulaw
!
dial-peer voice 19990100 pots
 service dsapp
 destination-pattern 7776
 voice-class sip extension gw-ana
 port 0/1/0
!
sip-ua
 registrar ipv4:10.10.10.10 expires 3600 tcp
!

Documentação completa do SIP DSAPP: Guia de configuração do software de gateway de voz Cisco VG450

Solução de problemas de roteamento de chamadas e verificação

Consulte este documento para obter informações mais detalhadas.

Configurar a Coleta de Depuração para Gateways Unified Border Element (CUBE) e Time-Division Multiplexing (TDM)