Explicação detalhada do roteamento de chamada do Cisco IOS e do IOS-XE
Contents
Introduction
A finalidade deste documento é explicar o roteamento de chamada IOS e IOS-XE e os mecanismos por trás da correspondência de peer de discagem de entrada e saída com trechos de chamada de serviço telefônico tradicional (POTS - Plain Old Telephone Service) e de rede de voz sobre IP (VoIP - Voice over IP).
Além das informações de peer de discagem, este documento aborda tópicos importantes relacionados ao roteamento de chamadas. Isso inclui manipulação de dígitos, uma visão geral rápida da manipulação de mensagens do Protocolo de Iniciação da Sessão (SIP - Session Initiation Protocol), alguns métodos para restringir os recursos de chamada, uma visão geral rápida da mídia e da associação de sinalização e, por fim, 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 muitos recursos neste documento estão claramente marcados com a versão em que o recurso foi introduzido no IOS e no IOS-XE. Essas informações também podem ser consultadas rapidamente, verificando a seção Roteiro de Comandos e Recursos. Se houver um defeito muito notável, ele é vinculado ao texto para que os leitores saibam.
Contribuído por Kyzer Davis e editado por Ramiro Amaya, engenheiro do TAC da Cisco
Prerequisites
Requirements
Embora não haja pré-requisitos formais necessários para ler este documento, ele é escrito na expectativa de que o leitor já tenha algum conhecimento funcional dos protocolos subjacentes de sinalização de voz que são usados para estabelecer e conectar chamadas telefônicas. Esses protocolos são citados muitas vezes por todo o livro.
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: Protocolo em tempo real (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 / C830 / ISR1100
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.
Definições comuns
| Atributo | Descrição |
|---|---|
| String de dígito | Também conhecido como número de sequência, número de telefone, número ou número E164.Consiste inteiramente de dígitos de 0 a 9 com um símbolo de adição (+) opcional à esquerda.
|
| Serviço de identificação de número discado (DNIS) | Este é o Número chamado ou o Número de destino de uma chamada. |
| Identificação automática de número (ANI) | Este é o Número de chamada ou o Número de chamada de origem de uma chamada.Também pode ser chamado de Identificador de linha de chamada (CLID), que também pode ser denominado ID de chamada |
| Uniform Resource Identifier (URI) | Um URI é um sip: ou tel: string mais comumente usada com os Protocolos VoIP SIP e H323.
|
| ID da portadora | Exemplos de CID: |
| Route-String | Um cabeçalho proprietário da Cisco para séries de rota ILS usadas com SIP.
|
| ENUM | ENUM é um protocolo que usa o Domain Name Service (DNS) para converter números de telefone E164 em URIs. Isso não é abordado neste documento. |
| PSTN | Rede telefônica pública comutada |
| ITSP | Provedor de serviços de telefonia pela Internet |
| SBC | Session Border Controller. Este é o dispositivo que serve como ponto de demarcação entre uma LAN de cliente e uma rede ITSP/PSTN |
Roteiro de comando e recursos
| Recurso | Versão do IOS | Versão IOS-XE |
| Expansão de número (num-exp) Peers de discagem (POTS e VOIP) answer-address padrão de destino número chamado de entrada destino da sessão (IPv4 e DNS) Máx. de conexões (max-conn) direct-inward-dial forward-digits (POTS) prefixo (POTS) timeouts entre dígitos (porta de voz) |
11.3(1)T | Todos |
| dial-peer terminator |
12.0 | Todos |
| caça |
12.0(5)T | Todos |
| Mapas ISDN | 12,0(6)T | Todos |
| Esquemas de busca de peer de discagem |
12,0(7)XK | Todos |
| Regra e perfil de conversão de voz translate-outgoing tipo de numeração faixa de dígitos (POTS) |
12.0.(7)XR1 | Todos |
| session target (sip-server) | 12.1(1)T | Todos |
| Grupo de Troncos POTS | 12.1(3)T | Todos |
| Mapa DNIS (Saída) | 12.2(2)XB |
Todos |
| trunk-group-label | 12.2(11)T |
Todos |
| Ponto de discagem (dados) | 12.2(13)T |
Todos |
| URI de classe de voz (saída) | 12.3(4)T |
Todos |
| destino da sessão (IPv6) | 12.4(22)T |
Todos |
| Perfis SIP (Saída) | 15,0 (1) M |
Todos |
| URI de classe de voz (entrada) voice source-group |
15.1(2)T |
3,8 S |
| Lista de cópias SIP session target (Registrar) |
15.1(3)T |
3,6 S |
| call-route (url) |
15.2(1)T |
3,3S |
| largura de banda máxima |
15.2(2)T |
3,7 S |
| E164-Pattern-Maps (Outbound) | 15,2(4)M | 3,7 S |
| Route-String de Classe de Voz call-route (dest-route-string) |
15,3 M | 3,10S |
| Grupos de correspondentes de discagem (VOIP) E164-Pattern-Maps (Entrada) Grupo de Servidores de Destino requri-pass session target (sip-uri) |
15.4(1)T |
3,11S |
| Política de provisão de peer de discagem Perfis SIP (entrada) |
15.4(2)T | 3,12S |
| Dial-Peer Group (POTS) | 15.5(1)T | 3,14S |
| Locatários de classe de voz | 15.6(2)T | 16.3.1 |
| Filtragem de VRF para peers de discagem | 15,6 (3) M | 16.3.1 |
| e164-translation | n/a | 16.8.1 |
| DSAPP SIP | n/a | 16.12.1 |
| Huntstop para grupos de servidores | n/a | 17.4.1 |
| porta de escuta SIP para o espaço Filtragem de espaço para correspondentes de discagem |
n/a | 17.8.1 |
Fundamentos de roteamento de chamada IOS/IOS-XE
Os gateways IOS e IOS-XE da Cisco utilizam um conceito de um 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 chamada. Um agente de chamada é um dispositivo que inicia, processa ou encaminha chamadas telefônicas. Isso pode ser, e não se limita a, equipamento do Provedor de Telefonia, um Gateway Cisco, um Telefone IP, um Cisco Unified Communication Manager (CUCM), Cisco Unity Connection (CUC) etc. Há muitos agentes de chamada para listar.
Cenário: Uma chamada que chega a um gateway da Cisco de outro agente de chamada é o leg da chamada de entrada (in-leg). O gateway processa a chamada e, com base em seu processamento, envia a chamada para o próximo agente de chamada. Este é o leg da chamada de saída (out-leg).
Imagem 1 mostra uma chamada do roteamento PSTN para CUCM por meio de um Cisco Voice Gateway e as respectivas informações de segmento de chamada de entrada e de saída.
Imagem 1: Legs de chamada de entrada e de saída ilustradas
Uma chamada bem-sucedida através de um Cisco Gateway ALWAYS* corresponde a um peer 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 que chega do PSTN no Cisco Gateway 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 combinar um peer de discagem para cada lado da chamada, um administrador tem a capacidade de controlar muitos aspectos de cada trecho de chamada específico. Exemplos disso incluem codecs de voz, preferências de DTMF, manipulação de dígitos, onde a chamada deve ser roteada e muitas outras configurações. Os correspondentes de discagem podem ser configurados com instruções de correspondência de entrada e saída, de modo que a correspondência do mesmo peer de discagem para o segmento interno e externo seja possível se uma configuração de correspondência de entrada e 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 saída que a Imagem 1, mas com os respectivos peers de discagem para uma chamada do roteamento PSTN para CUCM através de um Cisco Voice Gateway.
Imagem 2 - Peers de discagem de entrada e saída ilustrados
Os gateways de voz da Cisco podem intertrabalhar vários tipos diferentes de chamadas de voz e protocolos, incluindo IP para IP, POTS para POTS e IP para POTS ou vice-versa.
Imagem 3 ilustra uma chamada VoIP para VoIP através do Cisco Unified Border Element (CUBE).
Imagem 3 - Peers de discagem de entrada e 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 saída para uma chamada POTS para POTS
Tipos de peer de discagem de voz
| POTS | Os peers de discagem simples do serviço de telefonia antiga são correspondentes para conexões analógicas como conexões analógicas FXS, FXO, ISDN T1 / E1s, E1 R2 e Ear and Mouth (E&M). Eles enviam ou recebem uma chamada para / de uma porta de voz física no gateway. |
| VOIP | Os peers de discagem de voz sobre IP são usados principalmente para controlar conexões H323 e SIP de e para o gateway. Esses correspondentes de discagem enviam e recebem sinalização de endereços IPv4 e IPv6, bem como de Nomes de Domínio Totalmente Qualificados (FQDN) usando o Sistema de Nomes de Domínio (DNS). — Os peers de discagem VoIP também podem ser usados para sinalização de Voz sobre Frame Relay (VoFR), Voz sobre ATM (VoATM), Voz sobre Controle de Enlace de Dados de Alto Nível (VoHDLC) e Registro, Admissão e Status (RAS) e os alvos de sessão para esses peers de discagem também podem incluir ajustes e valores ENUM. Note: Alguns desses tipos de configuração são tecnologias mais antigas não vistas em redes mais novas e com o IOS-XE algumas não são mais suportadas. Como resultado, eles não são abordados neste documento. |
| MMOIP | Os peers de discagem de e-mail sobre IP multimídia são utilizados para enviar e-mails para servidores de troca. Eles são utilizados principalmente para fax t37 on-ramp / off-ramp. Esses tipos de peer de discagem não estão no escopo deste documento. |
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, ele começa a procurar um correspondente de discagem de entrada aplicável para essa chamada. Esta não é uma análise de dígito por dígito; em vez disso, a mensagem completa é utilizada para determinar qual peer de discagem de entrada está selecionado. A ordem dos itens na mensagem verificada depende em grande parte 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 atender a 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 peers de discagem são pesquisados com base nos critérios de primeira correspondência. O gateway passa para os próximos critérios somente se não for encontrada nenhuma correspondência.
Tabela 1. Preferência de seleção de peer de discagem SIP de entrada
| Preferência | Corresponder critérios |
Comandos de peer de discagem |
| 1 | URI |
uri de entrada via <uri-tag> |
| 2 | URI |
solicitação de uri de entrada <uri-tag> |
| 3 | URI | uri de entrada para <uri-tag> |
| 4 | URI | uri de entrada de <uri-tag> |
| 5 | Número chamado |
incoming called-number <number-string> incoming called e164-pattern-map <pattern-map-number> |
| 6 | Número de chamada | entrando chamando e164-pattern-map <número-do-mapa-padrão> answer-address <number-string> |
| 7 | Padrão de destino (ANI) | destination-pattern <number-string> |
| 8 | ID da portadora | carrier-id source <string> |
Note: Os peers 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
| Preferência | Corresponder critérios | Comandos de peer de discagem |
| 1 | URI | uri de entrada chamado <uri-tag> URI de entrada chamando <uri-tag> |
| 2 | Número chamado | incoming called-number <number-string> incoming called e164-pattern-map <pattern-map-number> |
| 3 | Número de chamada | entrando chamando e164-pattern-map <número-do-mapa-padrão> answer-address <number-string> |
| 4 | Padrão de destino (ANI) |
destination-pattern <number-string> |
| 5 | ID da portadora |
carrier-id source <string> |
Tabela 3. Preferência de seleção de peer de discagem POTS de entrada
| Preferência | Corresponder critérios | Comandos de peer de discagem |
| 1 | Número chamado | incoming called-number <number-string> |
| 2 | Número de chamada | answer-address <number-string> |
| 3 | Padrão de destino (ANI) | destination-pattern <number-string> |
| 4 | Porta de voz | port <voice-port-number> |
Quando não houver correspondência / Peer 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 porque o peer de discagem 0 tem capacidades limitadas e pode causar problemas com chamadas. O que há de mais avançado nisso são os protocolos SCCP e MGCP que não usam peers de discagem para rotear chamadas. Consulte a seção MGCP e SCCP para obter mais detalhes.
recursos de peer de discagem 0
- Nenhum mecanismo dtmf-relay
- 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 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 os peers de discagem com base na ordem de preferência do protocolo específico. No entanto, ao contrário dos correspondentes de discagem de entrada, se não houver um correspondente 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 os próximos critérios somente se não for encontrada nenhuma correspondência.
Tabela 4. Preferência de seleção de peer de discagem SIP de saída
| Preferência | Corresponder critérios | Comandos de peer de discagem* |
| 1 | Ponto de discagem do grupo de correspondentes | destination dpg <dpg-tag> (DPG configurado no peer de discagem de entrada) |
| 2 | URI da política de provisão de peer de discagem | destination uri-from <uri-tag> (DPP configurado no peer de discagem de entrada) |
| 3 | String de rota ILS | destination route-string <route-string-tag> |
| 4 | URI e Carrier-ID | destination uri <uri-tag> AND carrier-id target <string> |
| 5 | Número chamado e ID da transportadora | destination-pattern <number-string> AND carrier-id target <string> |
| 6 | URI | destination uri <uri-tag> |
| 7 | Número chamado | destination-pattern <DNIS-number> destination e164-pattern-map <pattern-map-number> dnis-map <dnis-map-number> |
| 8 | Número de chamada | destination call e164-pattern-map <pattern-map-number> |
Tabela 5. Preferência de seleção de peer de discagem H323 de saída
| Preferência | Corresponder critérios | Comandos de peer de discagem* |
| 1 | Ponto de discagem do grupo de correspondentes | destination dpg <dpg-tag> (configurado no peer de discagem de entrada) |
| 2 | URI e Carrier-ID | destination uri <uri-tag> AND carrier-id target <string> |
| 3 | Número chamado e ID da transportadora | destination-pattern <number-string> AND carrier-id target <string> |
| 4 | URI | destination uri <uri-tag> |
| 5 | Número chamado | destination-pattern <number-string> destination e164-pattern-map <pattern-map-number> dnis-map <dnis-map-number> |
| 6 | Número de chamada | destination call e164-pattern-map <pattern-map-number> |
Tabela 6. Preferência de seleção de peer de discagem POTS de saída
| Preferência | Corresponder critérios | Comandos de peer de discagem* |
| 1 | Ponto de discagem do grupo de correspondentes | destination dpg <dpg-tag> (configurado no peer de discagem de entrada) |
| 2 | URI e Carrier-ID | destination uri <uri-tag> AND carrier-id target <string> |
| 3 | Número chamado e ID da transportadora | destination-pattern <number-string> AND carrier-id target <string> |
| 4 | URI | destination uri <uri-tag> |
| 5 | Número chamado | destination-pattern <DNIS-number> dnis-map <map-number> |
Caça ao correspondente de discagem por sequência de caracteres numéricos
Preferência de cadeia de caracteres do número:
Assim como as URIs têm uma ordem específica de operações para avaliação de correspondências, também há um conjunto de regras usadas para avaliar uma string de dígito numérico. 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 observará a preferência de peer de discagem explicitamente definida. Por fim, se ambos forem iguais, escolhe um em ordem aleatória.
Há outros esquemas de busca de dial peer disponíveis para configuração; no entanto, a maioria das implantações mantém o padrão de 0.
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 peers de discagem qualificados foram configurados com as seguintes correspondências possíveis, e o gateway está avaliando uma string de dígitos de 2001. O peer de discagem 1 pode corresponder a qualquer número de 2000 a 2999, enquanto o peer de discagem 2 pode corresponder a 2000 a 2009. O correspondente de discagem 2 seria correspondido para esta chamada, pois é a correspondência mais longa (mais específica) para a string de dígito 2001 quando os mecanismos padrão de caça de peer de discagem são empregados (busca de peer 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 peer de discagem. Os administradores podem configurar uma preferência para que a chamada sempre use um peer de discagem específico antes de outros. Por padrão, todos os peers de discagem são a preferência 0. Um peer de discagem com preferência 0 corresponde 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 é configurado com um número mais alto).
Cenário: dois correspondentes de discagem são configurados com o mesmo comprimento de correspondência para a string de dígito de 2001. O administrador define uma preferência explícita. O gateway avalia ambos os peers de discagem da mesma forma, pois seu comprimento de correspondência é o mesmo. No entanto, o administrador define o peer de discagem 1 com uma preferência maior, de modo que o peer de discagem seja escolhido como o primeiro peer de discagem usado no roteamento da chamada. O correspondente de discagem 2 permaneceria como uma opção secundária caso ocorra 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 da 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 fora do próximo peer de discagem elegível. Isso continua até que a chamada seja bem-sucedida ou falhe porque não há mais peers de discagem qualificados para tentar. Um sintoma comum de busca e falha de peer de discagem é um retardo notável no toque enquanto faz 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 correspondentes de discagem são configurados com o mesmo comprimento de correspondência para a string de dígito de 2001. O administrador definiu uma preferência explícita e não deseja corresponder o correspondente de discagem 2 para esta chamada específica. Como há dois correspondentes de discagem com o mesmo comprimento de correspondência, a preferência é usada para determinar o correspondente 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 de chamada de saída usando dial-peer 1, o gateway interrompe imediatamente a busca do peer de discagem, pois 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 !
Busca de peer de discagem URI
O gateway examina cada critério de correspondência e o esgota antes de se mover para o próximo critério de correspondência. Um exemplo disso seria uma chamada SIP de entrada. Com base na Tabela 1. Preferência de seleção de peer de discagem SIP de entrada, a primeira coisa que o gateway da Cisco verifica é o URI e avalia todos os possíveis comandos URI para encontrar um que se ajuste. Se não houver correspondência OU nenhuma for configurada, o gateway se move para o próximo item correspondente e executa uma avaliação desse critério. 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 ser verificado.
Quando um peer de discagem de entrada ou de saída é configurado com um comando URI, o gateway examina a URI que foi recebida em vários cabeçalhos para uma possível correspondência. A preferência de correspondência é baseada na correspondência mais específica e a preferência exata é a correspondência de URI total, parte do host, parte do usuário ou URI do telefone. Saber a ordem das operações para correspondência de URI pode ajudar muito na correspondência de peer de discagem com implantações de 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:
- A parte Host do URI. Examples: (@a.b.c.d ou @host.domain.name)
- A parte Usuário do URI. Examples: (sip:8675309 ou sip:user)
- O teluri. Exemplo: (tel: 18005532447)
- Correspondência exata para o URI completo. Examples: (user@host.domain.name, user@a.b.c.d, 8675309@host.domain.name, 8675309@host.domain.name)
Documento de suporte: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-inbnd-dp-match-uri.pdf
Cenário: Um administrador configurou os correspondentes de discagem abaixo e envia uma chamada para o gateway. O cabeçalho FROM no CONVITE recebido é "De: <sip:testuser@10.10.10.10>" O gateway pode potencialmente corresponder a dois correspondentes de discagem diferentes com base nesse cabeçalho. Peer de discagem 1 com base na parte do usuário e no peer de discagem 2 com base na parte do host. No entanto, como uma correspondência de host é uma preferência acima de 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 peers de discagem de entrada e saída permite que um administrador tenha a capacidade e a flexibilidade de executar correspondências em mais de uma cadeia 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, um URI de solicitação tinha que conter um "user@host" alfanumérico; caso contrário, um gateway da 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. ou seja, sip:cisco.com.
Além disso, antes do IOS 15.4(1)T e IOS-XE 3.11S voice-class URI user-ids só podiam ser valores e.164 numéricos (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 usuário de um uri de classe de voz pode conter padrões de expressões regulares (regex) que expandem muito os possíveis valores que podem ser correspondidos.
Gateway(config-voice-uri-class)# user-id .) % unmatched ()user-id pattern should be of format ^([][0-9A-Za-z\|\/()*+^$&?#--.])*$
Gateway(config-voice-uri-class)# host .)
% unmatched ()host pattern should be of format ^([][0-9A-Za-z\|@\/()*+^$&?#--.])*$
Gateway(config-voice-uri-class)# pattern .)
% unmatched ()pattern pattern should be of format ^([][0-9A-Za-z\|@;:=%!~\/()*+^$&?#--.])*$
Exemplo de URIs de classe de voz
! voice class uri HOST sip host webex.com host dns:cisco.webex.com host ipv4:14.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 user-id podem ser configurados por uri de classe de voz, como demonstra o exemplo a seguir. Se for necessário combinar mais itens, é recomendável usar o Regex.
Gateway(config)# voice class uri TEST sip Gateway(config-voice-uri-class)#host ipv4:1.1.1.1 Gateway(config-voice-uri-class)#host ipv4:2.2.2.2 Gateway(config-voice-uri-class)#host ipv4:3.3.3.3 Gateway(config-voice-uri-class)#host ipv4:4.4.4.4 Gateway(config-voice-uri-class)#host ipv4:5.5.5.5 Gateway(config-voice-uri-class)#host ipv4:6.6.6.6 Gateway(config-voice-uri-class)#host ipv4:7.7.7.7 Gateway(config-voice-uri-class)#host ipv4:8.8.8.8 Gateway(config-voice-uri-class)#host ipv4:9.9.9.9 Gateway(config-voice-uri-class)#host ipv4:10.10.10.10 Gateway(config-voice-uri-class)#host ipv4:11.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 peer de discagem de URI de entrada
Esse 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. A URI de entrada foi adotada por muitos clientes em relação ao número chamado de entrada para chamadas SIP, pois são os primeiros critérios de correspondência marcados ao selecionar correspondentes de discagem de entrada. O comando também permite aos administradores a capacidade de combinar melhor as chamadas provenientes de um agente ou usuário de chamada específico.
Documentação completa: http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-inbnd-dp-match-uri.html
Casos de uso comuns
- Um correspondente de discagem de entrada correspondente na parte do host do URI para responder às solicitações de ping OPÇÕES do CUCM.
- Um peer de discagem de entrada correspondente na parte do host do URI para controlar as chamadas de entrada de um provedor de serviços de telefonia pela Internet (ITSP)
- Um correspondente de discagem de entrada correspondente na parte id do usuário do URi para tratamento de chamadas de determinados usuários ou números.
Exemplo de configuração
A saída de exemplo abaixo corresponde ao peer de discagem 777 para qualquer origem de solicitação SIP dos dois IPs HOST definidos no uri da classe de voz. O cabeçalho observado é definido como o cabeçalho FROM no peer de discagem; no entanto, um administrador pode definir muitas outras, incluindo VIA, TO e REQUEST (Solicitar URI). Se o CUCM enviar um ping OPTIONS ao CUBE agora corresponde ao peer de discagem 777 e origem minha resposta 200 OK às OPÇÕES da interface especificada. Se o meu CUCM enviar um CONVITE ao CUBE corresponde ao peer de discagem 777 como o peer de discagem de entrada.
! voice class uri CUCM sip
host ipv4:14.50.244.2
host ipv4:14.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 peer de discagem de URI de saída
Os gateways do Cisco IOS podem corresponder um peer de discagem de saída usando uma URI aplicando uma uri de classe de voz para um peer de discagem de saída e adicionando a url call-route à configuração global. Quando isso estiver presente, o CUBE tentará rotear chamadas com base no URI de solicitação. Esse recurso foi adicionado no IOS 12.3(4)T e está presente em todas as versões do IOS-XE. Deve-se observar que, por padrão, o Request-URI do SIP de saída e o URI do cabeçalho To terão o destino da sessão do peer de discagem de saída. Isso pode ser desativado usando o comando requri-pass que permite que o gateway passe a parte do host URI in-leg para o out-leg, em vez de substituir a parte do host URI pelo destino da sessão. O comando requri-pass foi adicionado em 15.4(1)T e 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 !
Além de uri de classe de voz, os administradores podem usar um dial-peer provision-policy (DPP) para corresponder um URI no leg de uma correspondência de peer de discagem de saída. Esse recurso foi adicionado no IOS 15.4(2)T e no IOS-XE 3.12S. R dial-peer provision-policy O requer a definição de um atributo de correspondência principal com um atributo de correspondência secundário sendo opcional. A política de provisionamento é 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 baseada no atributo da dial-peer provision-policy.
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 Para. Para uma correspondência OR, uma diretiva de provisão de peer de discagem é configurada que contém duas preferências. O cabeçalho De é a primeira preferência e o cabeçalho To é a preferência de backup. O correspondente de discagem 1234 foi criado para aplicar a política de provisão para correspondência de entrada. Em seguida, o peer de discagem 1111 e 22222 que aplicam os comandos uri-de destino e uri-de-destino respectivamente. Esses comandos apontam de volta para sua URI de classe de voz. Para a chamada que receberemos o CONVITE, faça a correspondência do correspondente de discagem 1234 e verifique a política de provisão. O dispositivo tentará rotear primeiro no cabeçalho De, que como uma correspondência aplicável no peer de discagem 1111. Se isso falhar, também podemos tentar rotear no cabeçalho para com 22222.
O exemplo também detalha como obter uma correspondência AND com políticas de provisão de peer de discagem. Supondo que o mesmo CONVITE seja recebido, podemos definir dois cabeçalhos em uma preferência e aplicá-lo ao correspondente de discagem de entrada.
Agora, quando o convite for recebido, ele verificará se há peers de discagem de saída qualificados que satisfazem ambos os critérios de correspondência definidos na política de provisão. Nesse exemplo, nosso peer de discagem de saída precisa ser definido com o cabeçalho TO e FROM para ser correspondido. Se não houver uma correspondência válida, esse peer de discagem 12345 não será usado.
Note: Embora estejamos roteando a chamada no cabeçalho FROM, o CONVITE que sai do gateway ainda tem o URI de solicitação original. Simplesmente usamos a política de provisionamento de peer de discagem para corresponder a um peer de discagem de saída e não alterar a URI de solicitação.
Exemplo de configuração:
### Recieved 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
!
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 correspondentes de discagem de saída separados.
Depois dessa versão, um administrador pode configurar um peer de discagem para atender a vários hosts para o mesmo usuário. ou seja, testuser@cisco.com e testuser@webex.com no mesmo dial-peer. O uso do comando session target sip-uri aciona a resolução de DNS do domínio de retorno URI de CONVITE recebido e determina dinamicamente o IP de destino da sessão.
Exemplo de configuração:
O gateway recebe dois CONVITE SIP com os seguintes cabeçalhos CONVITE SIp:testuser@cisco.com:5060 SIP/2.0 CONVITE 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 peer de discagem 1 devido ao comando uri de entrada e à definição de id de usuário corresponde a "testuser". O comando voice-class sip call-route url estando presente significa que avaliamos peers de discagem de saída com base na URI de solicitação deste CONVITE de entrada. Nós combinamos o peer de discagem 2 devido aos mesmos motivos que combinamos o peer de discagem 1, o id de usuário do "testuser". O destino da sessão desse peer de discagem é o sip-uri original, conforme definido por "session target sip-uri", que era um FQDN. Depois que uma resolução DNS tiver ocorrido e alterar cisco.com e webex.com para um IP para roteamento da camada 3, enviamos 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 do 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 cadeia de caracteres numérica. Eles incluem destination-pattern, incoming called-number, e164-pattern-maps e answer-address, bem como o comando prefix. Os curingas de peer de discagem são expressões regulares (regex) disponíveis para configuração que permitem maior flexibilidade na correspondência de peers de discagem.
Tabela curinga
| Caractere | Definição | Examples |
| * | Em um peer de discagem, esse é um valor literal de * (estrela) no teclado. | 12345 * |
| Nº | Em um peer de discagem, esse é um valor literal de # (libra) no teclado. | Nº 8675309 |
| , | Insere uma pausa de 1 segundo entre os dígitos. Uma vírgula também pode ser usada entre colchetes [ ] para quebrar um intervalo contínuo. |
9,,,,,555 91[1-3,5-9]8675309 |
| . | Caractere Regex para correspondência de qualquer valor de 0 a 9, A-F e *, #, + Até 15 caracteres de ponto podem ser definidos por peer de discagem, embora a CLI permita que um administrador configure quantos forem considerados adequados. Se for necessário mais de 15 pontos, use T. |
2.... 91[2-9]...[2-9]...... |
| % | Regex para dígito precedente que ocorre zero ou mais vezes. | |
| + | Quando usado no início de uma string significa um + literal usado em números E164. Quando usado em qualquer outro lugar da string, é um valor regex para o dígito anterior que ocorre uma ou mais vezes. |
+19191112222 |
| ? | Regex para o dígito precedente que ocorre em zero ou uma vez. | (206)?5015111 (1)?(1)?21933... |
| ^ | Caractere Regex para indicar o início da string quando usado fora dos colchetes Quando usado entre colchetes, é tratado como uma exclusão ou como uma instrução DO NO MATCH Isso não é mais necessário em versões posteriores, pois o gateway assume automaticamente um ^ ao processar uma string regex sem um ^. |
^8675309 91[^135]555 |
| $ | Regex character para indicar o fim de uma string. | 8675309$ |
| \ | Caractere de escape para um valor literal |
|
| [ ] | Os suportes definem um intervalo de caracteres para uma única posição. Os vírgulas devem ser usados para quebrar strings contínuas. |
[1-5]0000 [2,5-8]0000 |
| ( ) | Os parênteses definem um grupo de caracteres em um conjunto. |
9(258) 7777 |
| T | Uma correspondência de comprimento de variável de até 32 dígitos. O roteador espera que o tempo limite entre dígitos ocorra antes de rotear a chamada. O valor padrão para o intervalo entre dígitos é de 10 segundos e pode ser modificado por meio de intervalos entre dígitos em uma porta de voz. T também faz referência ao temporizador T302 |
9011T |
| - | Usado entre colchetes para definir o intervalo. |
[5-9]1234 |
Saída do Gateway exibindo as possíveis entradas de expressão regular
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 correspondentes de discagem podem estar em um de dois estados operacionais.
- Para cima
- Down
Para que um peer de discagem esteja em um estado operacional válido e qualificado para uso com roteamento de chamada, ele precisa estar no estado UP. Para peers de discagem VOIP de saída, isso significa que deve haver mecanismos válidos de correspondência de saída, bem como um destino de sessão válido para rotear a chamada. Para peers de discagem POTS de saída, devem ser configurados um mecanismo de correspondência de saída válido e uma porta de voz válida. Com correspondentes de discagem de entrada, somente 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 falhou nos parâmetros desse mecanismo keepalive. Em seguida, o gateway move o peer de discagem para um estado busyout para que não seja mais usado para decisões de roteamento de chamadas e quando o mecanismo keepalive é preenchido novamente, o gateway coloca o peer 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 de busyout, o gateway falhará na chamada com um código de causa 188.
Juntamente com os estados operacionais existem estados administrativos.
- Para cima
- 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, digite no shutdown.
Note: Um peer de discagem com uma porta de voz desativada, desligada ou não operacional permanece no estado operacional UP, no entanto, o estado de saída mostra como desativado
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:14.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 peer 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 da Cisco podem corresponder os peers de discagem de entrada usando IDs de VRF. Para aproveitar isso, um administrador deve vincular o peer de discagem de entrada a uma interface que, por sua vez, vincula o peer de discagem à ID do VRF na interface especificada. Depois que a associação for concluída, as chamadas de entrada serão filtradas pelo Cisco Gateway para incluir somente peers de discagem de entrada qualificados que correspondam ao ID do VRF da interface na qual o pacote foi recebido. A partir daqui, o peer de discagem de entrada é correspondido com base na ordem de operações de correspondência de peer de discagem regular.
Antes dessas versões do IOS/IOS-XE, o Cisco Gateway faria uma seleção de entrada com base na correspondência regular de peer de discagem de entrada sem nenhuma filtragem. Isso significa que uma chamada VRF1 pode ser correspondida por um peer de discagem VRF2. Além disso, como apenas um VRF era suportado pelo H323 e SIP antes dessas versões, outros problemas surgem ao tentar usar os recursos multi-VRF. O uso de um único VRF para aplicativos de voz era conhecido como configuração com VRF.
Documentação completa com reconhecimento de VRF: http://www.cisco.com/c/en/us/td/docs/ios/12_4t/12_4t15/vrfawvgw.html
Documentação completa de vários VRF: http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-cube-multi-vrf.html
Correspondência de peer de discagem de saída com VRF
Os Cisco Gateways têm a capacidade de ligar 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 para saída em um peer de discagem para VRF2 se a seleção normal de correspondência de peer de discagem de saída for atendida. Grupos de correspondentes de discagem podem ser empregados para forçar o gateway da Cisco a manter a chamada dentro do mesmo VRF.
Exemplo de configuração de VRF e grupo de correspondentes de discagem
Este exemplo de configuração tem VRF1 e VRF2 com dois intervalos de IP sobrepostos e dois intervalos de números de telefone sobrepostos.
Usamos a associação de VRF para garantir que o peer de discagem de entrada correto seja combinado e que os grupos de peer de discagem de discagem para garantir que o peer de discagem de saída de VRF correto seja comparado.\ Se um pacote SIP para uma chamada para 8675309 chegar em gig0/0/1.2, o gateway filtra todos os peers de discagem de entrada disponíveis com base na ID de VRF2. Isso significa que não podemos corresponder o peer de discagem 10. Agora que verificamos a string de dígito correspondente ao peer de discagem 20. O peer de discagem 20 tem um grupo de peer de discagem que diz 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 corresponder o peer de discagem 10 e cruzar uma chamada vinda de VRF1 para VRF2. A partir daí, a chamada deve continuar 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
Ao longo dos anos, à medida que as necessidades comerciais crescem, a empresa expande e exige mais DIDs para que os administradores corporativos descubram que os correspondentes básicos de discagem não atendem bem à escala. Pode haver situações de ausência temporária que precisam ser abordadas, ou talvez haja apenas muitos correspondentes de discagem em geral. Ter milhares de correspondentes de discagem não facilita a administração e a solução de problemas. Ter um peer de discagem para cada servidor ou agente de chamada CUCM específico começa a compor o problema de muitos peers de discagem porque agora um administrador precisa configurar um peer de discagem para cada string de dígito. Talvez haja mais de um provedor SIP se conectando a um gateway ou alguns clientes diferentes usando o mesmo CUBE. Isso torna o isolamento de um espaço específico muito difícil.
A Cisco recebeu esse feedback e criou um conjunto de itens que podem resolver problemas em tantos e muito mais. Grupos de peer de discagem, usuários de classe de voz, grupos de servidores de destino, mapas de padrões e164 e grupos de troncos de POTS permitem que um administrador resolva todos os problemas acima e muitos outros não listados.
Grupos de correspondentes de discagem
Grupos de correspondentes de discagem foram adicionados no IOS 15.4(1)T e 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 correspondente. Quando um peer de discagem de entrada com um grupo de peer de discagem configurado for correspondido, a chamada usará 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 ser UP, portanto, um método de correspondência de saída deve ser configurado, mas isso não é realmente usado para rotear a chamada.
A melhor maneira de descrever grupos de peer de discagem é compará-los ao conceito de rotas estáticas em uma tabela de roteamento. Essas são decisões estáticas de entrada para saída de roteamento que retiram algumas adivinhações para o gateway, pois estão dizendo exatamente como rotear a chamada.
Documentação completa: http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/multiple-outbound-dial-peer.html
Exemplo de configuração
Com o exemplo a seguir, o número chamado é 8675309. Corresponde ao peer de discagem 1234 com base na instrução de número chamado recebida. Esse peer de discagem é configurado com um grupo de peer de discagem que afirma que a chamada deve agora rotear os correspondentes de discagem 2, 3 e finalmente 1 se o correspondente de discagem 2 falhar. Sabendo disso, o gateway agora tenta rotear o peer de discagem de saída 2, pois ele foi explicitamente informado pelo grupo de peer de discagem que é isso que ele deve fazer.
Observe como o padrão de destino no peer de discagem 1, 2 e 3 não é o número chamado de 8675309. Isso é aceitável e a chamada ainda é roteada sem problemas. Lembre-se de que, conforme discutido na seção "estados de peer de discagem", precisamos de algo/qualquer coisa configurada como uma instrução de correspondência de saída. Em nosso caso, o padrão de destino é apenas trazer o peer de discagem para um estado operacional UP e a sequência de dígitos desse comando nunca é avaliada. Recomenda-se configurar um padrão como "destination-pattern AAAA", pois esse é um padrão de destino válido. Já que, tecnicamente, é um peer de discagem válido, outras chamadas podem corresponder a ele. Assim, a string de dígito AAAA significa que nunca podemos usá-la para nada além do nosso cenário específico envolvendo um grupo de peer de discagem, já que a probabilidade de uma chamada entrar para AAAA é 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 muitas correspondências de número possíveis (padrões de destino, número chamado recebido, etc.) em um único mapa de padrões. O suporte a peer de discagem de saída e164-pattern-map foi adicionado no IOS 15.2(4)M e no IOS-XE 3.7S, enquanto o e164-pattern-map suportado foi adicionado no IOS 15.4(1)T e no IOS-XE 3.11S.
Um mapa de padrões e164 pode ser configurado via CLI ou pré-configurado e salva como um arquivo .cfg. O arquivo .cfg é então adicionado à memória flash do gateway e, em seguida, referenciado ao configurar o resto do comando. O arquivo .cfg pode utilizar 5000 entradas.
As entradas em ambos os métodos de configuração podem utilizar todos os curingas normais de peer de discagem para maior agregação!
Documentação completa:http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/vd-mdp-dialpeer.html
Exemplo de configuração de CLI - Números chamadores
! 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 de 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
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
- CSCva64393
- e164-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 usando o comando hunt-plan round-robin. Os grupos de servidores foram adicionados ao IOS 15.4(1)T e ao IOS-XE 3.11S. No IOS-XE 17.4.1um código de erro huntstop configurável foi adicionado às configurações de grupo de servidores de classe de voz. Ou seja, você pode configurar um único código de erro, digamos que o erro 404 Not Found 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 no grupo de servidores; caçar vai parar. Eles também podem ser configurados para um intervalo como: huntstop 1 resp-code 401 a 599.
Note: O número máximo de entradas é 5 por grupo de servidores.
Documentação completa: http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/multiple-server-groups.html
Exemplo de configuração - Normal
! voice class server-group 1 hunt-scheme round-robin ipv4 14.50.244.2 port 5060 preference 1 ipv4 14.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 14.50.244.2 5060
0 ipv4 14.50.244.62
3 ipv6 2010:AB8:0:2::1 2323
0 ipv6 2010:AB8:0:2::2 2222
[..truncated..]
Manutenção de atividade do grupo de servidores de destino e das OPÇÕES
Vale observar que os grupos de servidores não seguem os mecanismos normais de manutenção de atividade das OPÇÕES fora de diálogo. Eles utilizam um recurso chamado option-keepalive profile. 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 14.50.244.2 ipv4 14.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:14.50.244.2 Transport: system Sip Profiles: 0 OOD SessID: 2 OOD Stat: Active Target: ipv4:14.50.244.62 Transport: system Sip Profiles: 0
Grupos de Troncos POTS
Os grupos de troncos são uma coleção 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 troncos foram introduzidos no IOS em 12.1(3)T e estão presentes em todas as versões do IOS-XE.
Documentação completa: http://www.cisco.com/c/en/us/td/docs/ios/12_2/12_2x/12_2xu/feature/guide/ftpg_str.html#wp1034848
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 de classe de voz
O IOS 15.6(2)T e o IOS-XE 16.3.1 introduziram espaços de classe de voz que permitem que cada espaço tenha suas próprias configurações individuais. Um usuário pode ser um provedor de telefonia, o Cisco Unified Communication Manager (CUCM) ou qualquer outro agente de chamada 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 espaço da classe de voz é então aplicado ao correspondente de discagem ou à escolha específica. Essa nova configuração dá aos administradores outro nível de controle sobre as chamadas além dos peers de discagem e da configuração global.
Começando em 17.8.1a, as configurações de Locatário de Classe de Voz podem ser configuradas com um comando sip-Listen (juntamente com o comando apropriado SIP control binding) para definir a porta não segura ou segura que o locatário. Isso significa que o locatário 1 pode ouvir SIP inseguro no UDP 5060 + VRF vermelho enquanto o locatário 2 escuta SIP no TCP TLS 5070 + VRF azul. Depois de corresponder o espaço com base na porta de escuta + bind + peers de discagem de entrada vrf opcionais são filtrados para aqueles que têm o espaço aplicado.
Documentação completa:http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-cube-multi-tenants.html
Escute o SIP no espaço:https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_voi-cube-multi-tenants.html
Ordem normal de preferência de comando sem locatários
- Comando dial-peer
- Comando global (voice service voip e sip-ua)
Ordem de preferência do comando com locatários
- Comando de peer de discagem
- Comando de espaço
- Comando global (voice service voip e sip-ua)
Exemplo de configuração para vários usuários
Temos dois inquilinos 777 e 999. Nós os configuramos com configurações ligeiramente diferentes e as aplicamos aos nossos peers de discagem. Isso significa que as chamadas que usam os diferentes peers de discagem têm as configurações baseadas em peer de discagem, bem como as configurações específicas do espaço. As opções abaixo são apenas um trecho do poder dos usuários de classe de voz. Consulte a documentação para ver o que tudo pode ser configurado em um espaço. É recomendável empregar mecanismos de correspondência rígidos, como o uri de classe de voz ou etiquetar números com determinadas cadeias de caracteres de número para separar a correspondência de peer de discagem do espaço, ou mesmo configurar VRFs de modo que o Espaço A nunca se sobreponha ao Espaço B e combine acidentalmente com um peer de discagem que não deve.
!
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
No momento, não há nenhum comando individual para ver as configurações de espaço de classe de voz. O comando a seguir deve ser suficiente para filtrar a configuração atual apenas para as informações do espaço.
show run | sec tenant
Nota: CSCvf28730 , onde show sip-ua register status não reflete o status do registro de tronco SIP em um espaço de classe de voz.
ILS URI Calls CUBE (voice class Route-String)
As sequências de caracteres de rota são usadas com o CUCM Intercluster Lookup Service (ILS) e podem ser configuradas para permitir que os gateways Cisco roteiem chamadas VoIP através da cadeia de caracteres de rota incluída no CONVITE SIP recebido de um CUCM 9.5+ executando o serviço ILS. Esse recurso foi adicionado no IOS 15.3(3)M e no IOS-XE 3.10S. A maioria das conexões ILS são CUCM para CUCM e os administradores não se incomodam em envolver um CUBE para entroncamento entre clusters. No entanto, se precisarmos executar a função com o CUBE no meio, as opções estarão disponíveis. 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 CUBE
Documentação completa:http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube_interop/configuration/15-mt/cube-interop-15-mt-book/voi-cube-ils-service.html
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 utilizar esses comandos em configurações modernas. Este documento só os aborda porque eles podem ser encontrados ao trabalhar com configurações antigas ou ao executar atualizações.
DNIS-Map
Os mapas DNIS podem ser considerados o precursor do que seria agora um mapa de padrões E164. Mapas DNIS foram adicionados ao IOS em 12.2(2)XB e sempre existiram no IOS-XE.
Se houver mapas de DNIS configurados, vale a pena convertê-los para o recurso e164-pattern-map mais robusto.
Sintaxe do comando: http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr2/vcr2-cr-book/vcr-d2.html#wp3372710070
Exemplo de configuração:
! voice dnis-map 34 dnis 8675309 ! dial-peer voice 88 voip dnis-map 34 !
Rótulos de Grupo de Troncos
Rótulos do grupo de troncos foram adicionados no IOS 12.2(11)T e existem em todas as versões do IOS-XE. A finalidade de um trunk-group-label é semelhante a um Carrier-ID no sentido de que ele pode ser usado para aumentar a correspondência de peers de discagem. 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: http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr5/vcr5-cr-book/vcr-t3.html#wp2051313870
Exemplo de configuração:
! dial-peer voice 112 pots trunk-group-label source north3 trunk-group-label target east17 !
Tipo de numeração
Com as integrações de ISDN Q.931 existe a capacidade de corresponder um peer de discagem com base no número chamado ou chamado, bem como o tipo de número de ITU específico da mensagem de CONFIGURAÇÃO Q.931. Isso é configurável por meio do comando numerering-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 a condição da instrução de correspondência de entrada/saída E o tipo de número deve corresponder para ser um sucesso para o peer de discagem ser considerado para roteamento de chamadas de entrada e saída.
A correspondência de numeração pode ser considerada como um mecanismo de filtragem de peer de discagem em vez de um mecanismo correspondente. Isso ocorre porque um peer de discagem com e sem um comando de tipo de numeração aplicado é considerado o mesmo peso de preferência padrão se nenhuma preferência de administrador for aplicada. Isso é diferente do ID da portadora que, quando aplicado a um peer de discagem ao lado de outro mecanismo de correspondência, adiciona preferência a esse peer de discagem em vez de outros, se ambas as condições forem verdadeiras.
A correspondência de Tipo de Numeração foi adicionada no IOS 12.0(7)XR1 e está presente em todas as versões do 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: http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr3/vcr3-cr-book/vcr-n1.html#wp3304694174
Exemplo de configuração:
Esse peer de discagem pode corresponder a 4085150000 a 408515999 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 !
Possíveis tipos de números:
| Abreviado | Representação abreviada do número completo como suportado por esta rede |
| Internacional | Número chamado para acessar um assinante em outro país |
| Nacional | Número chamado para acessar um assinante no mesmo país, mas fora da rede local |
| Rede | Número administrativo ou de serviço específico da rede de serviço |
| Reservado | Reservado para extensão |
| Assinante | Número chamado para acessar um assinante na mesma rede local |
| Desconhecido | O tipo de número é desconhecido pela rede |
Dados do peer de discagem
Os correspondentes de discagem de dados foram apresentados no IOS 12.2(13)T e o útil desses peers de discagem era para chamadas de modem de dados recebidas em um Cisco Gateway. Esse peer de discagem é apenas para uso na direção de entrada e raramente visto em implantações modernas.
Sintaxe do comando: http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr2/vcr2-cr-book/vcr-d1.html#wp1448833490
Exemplo de configuração:
! dial-peer data 100 pots incoming called-number 100 !
Grupo de origem de voz
Este recurso foi adicionado em 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 do CUBE Application Security pode ser vista no white paper a seguir, iniciando na seção 4.2.
Sintaxe do comando: https://www.cisco.com/c/en/us/support/docs/voice-unified-communications/unified-border-element/116440-configure-vsg-00.html
Permissões de peer de discagem
Essa configuração permite que um administrador restrinja um peer de discagem para permitir conexões de entrada somente (termo/fim) ou conexões de saída (orig/originate). Isso seria como configurar explicitamente um peer de discagem de entrada para ser usado somente 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 saída. Essa 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
Manipulação de URI e dígito
Em algum momento de uma implantação de colaboração, um administrador pode precisar manipular dígitos ou um cabeçalho URI/SIP. Os gateways da Cisco têm vários métodos para manipulação de dígitos, o que permite que um administrador controle completo sobre como e quando um dígito deve ser manipulado. No entanto, isso pode ser assustador para alguns, pois eles estão sobrecarregados com as diferentes opções OU o administrador não sabe que existe uma opção.
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 exclusivas que os peers de discagem VOIP não têm.
A primeira é a remoção de dígitos justificados explicitamente definidos pela esquerda em um padrão de destino. Isso pode ser desativado usando o comando no digits-strip no dial-peer POTS.
Exemplo:
Neste exemplo, definimos 9011T como a string para o padrão de destino.
Com isso em vigor, recebemos uma chamada para 90113227045555. Isso corresponde ao nosso peer de discagem para roteamento de chamada de saída e os dígitos explicitamente definidos do 9011 são removidos antes da chamada ser roteada para fora da porta de voz.
! dial-peer voice 1 pots destination-pattern 9011T port 0/0/0:23 !
O exemplo a seguir mostra uma configuração sem uma 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 !
A segunda é a capacidade de especificar quantos dígitos gostaríamos de encaminhar no peer de discagem POTS.
Tome o exemplo a seguir quando recebemos uma chamada para 918005532447 do CUCM. Nessa situação, queremos remover o 9, mas enviar o restante do número começando com o 1.
Se configurarmos o comando forward-digits no peer de discagem POTS, poderemos especificar exatamente quantos dígitos enviamos.
! 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 para fora da porta de voz. O exemplo a seguir 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 via regras e perfis de tradução de voz
As regras de conversão de voz são expressões regulares (regex) usadas para transformar dígitos. As regras de tradução e os perfis foram adicionados ao IOS em 12.0(7)XR1. Uma regra de tradução é aplicada aos perfis de tradução de voz que são aplicados a um peer 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 correspondência e uma entrada de modificação para o plano e tipo de ISDN. A combinação de string, plano e tipo de número de correspondência é considerada uma correspondência AND. Isso significa que todas as entradas correspondentes definidas devem ser verdadeiras para que a tradução ocorra.
As regras de conversão podem alterar os protocolos de sinalização Chamada, Chamada, Chamada de redirecionamento, Destino de Redirecionamento e Número de Retorno de Chamada em ISDN, SIP e H323. As regras de tradução correspondem com base em uma pesquisa de cima para baixo, de modo que a ordem das regras é de extrema importância. Se uma correspondência for encontrada em uma regra mais alta, o gateway imediatamente para de procurar e processar a tradução. As regras de traduçã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
- Perfil de conversão de voz recebido na porta de voz
- Perfil de conversão de voz de entrada no grupo de troncos aplicado à interface serial
- Perfil de conversão de voz de entrada no peer de discagem de entrada
- Perfil de tradução de voz de entrada definido através de portas de serviço de voz
- Perfil de conversão de voz recebido definido por meio do 'voip-incoming translation-profile' global
- Perfil de tradução de voz de saída definido por portas de serviço de voz
- Perfil de tradução de voz de saída ou de saída de tradução no peer de discagem de saída
- Perfil de conversão de voz de saída no grupo de troncos aplicado à interface serial
- Perfil de tradução de voz de saída na porta de voz
Além do regex do peer de discagem e as regras de conversão de curingas têm seus próprios caracteres regex.
| Caractere | Definição |
| * | Quando usado em translation-rules, este é regex para 0 ou mais do caractere anterior. Para corresponder a um literal * use um caractere de escape: \* |
| \ | Geralmente usado para conjuntos de escape na regra de tradução \( \) |
| & | O Ampersand é usado para ativar qualquer correspondência no conjunto de correspondências inicial para o conjunto de modificações |
| ( ) | Os itens entre parênteses são considerados um conjunto. |
| ^ | Define o início explícito de uma string. Diferentemente das regras de conversão de peers de discagem, as regras não definem o início da cadeia de caracteres. Isso significa que definir uma string sem um ^ pode corresponder em qualquer lugar na string de entrada, o que pode levar a conversões indesejadas no meio de um número. |
Conjuntos de Modificações
- Os conjuntos são especificados como \0, \1, \2, etc.
- \0 corresponde a qualquer coisa entre o primeiro conjunto de correspondências. Isso também pode ser feito por meio de um caractere de ampersand: &.
- \1 corresponde ao primeiro conjunto de ( ) no conjunto de correspondências
- \2 corresponde ao segundo conjunto de ( ) no conjunto de correspondências
- E assim por diante.
Exemplo de regra de tradução com dois conjuntos
Neste exemplo, examinamos o número 000111000222.
Queremos remover os 0s do número e obter um número final de 111222.
Para fazer isso, configuramos set 1 e 2 para capturar o 111 e o 222, respectivamente, enquanto soltamos 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
Truncando 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
Tirar 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 antes 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> !
Depurando regras e perfis de tradução de voz
debug voip ccapi inout debug voice translation debug dialpeer test voice translation-rule <number> <string> type <type> plan <plan>
Tradução de classe de voz e164
O recurso de conversão de classe de voz e164 é um recurso IOS-XE mais recente que permite que um administrador crie uma lista de declarações de correspondência e modifique 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 do 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 tradução. Para obter mais informações, consulte a referência de comando de voz do Cisco IOS
Siga a sintaxe abaixo para o arquivo .cfg:
pattern1_to_be_matched<tab>replaced_pattern<space><enter> pattern1_to_be_matched<tab>replaced_pattern<space><enter>
Note: O espaço final é muito importante e a importação falhará sem essa etapa extra de formatação.
Exemplo.cfg
+111111 8897 +222222 8312 928747 +123456789 737362 +987654321
Este arquivo é então referenciado como tal:
voice class e164-translation 164 url ftp://username:password@10.10.10.10/sample.cfg
Agora você se aplica a um perfil de tradução normalmente e, a partir daí, aplica-se a correspondentes de discagem usando a sintaxe normal do perfil de tradução.
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 tradução.
Obrigado a Swati Sharma por detalhar este processo para o documento
Manipulação de dígitos via mapas ISDN
MAPAS ISDN são uma técnica mais antiga para modificar dígitos. Isso foi adicionado no IOS 12.0(6)T e a maioria das novas configurações não utiliza esse recurso, pois elas 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úmeros (num-exp)
Como os mapas ISDN, a expansão de números é uma técnica antiga adicionada ao IOS 11.3(1)T e pouco usada em novas redes. Este recurso foi adicionado antes da existência de regras e perfis de conversão de voz. A expansão de números é uma alteração global de dígitos aplicados a todos os peers de discagem em um gateway Cisco. A modificação é aplicada ao número chamado APÓS a correspondência do peer de discagem e imediatamente antes da chamada ser enviada ao 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 regular (regex) robustas que permitem que um administrador altere qualquer aspecto de uma mensagem SIP, incluindo cabeçalhos SDP e SIP. Elas podem ser ativadas globalmente, por peer de discagem ou por locatário. Os perfis SIP estão disponíveis para modificações de entrada que começam com IOS 15.4(2)T e 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.
Principais pontos sobre os perfis SIP de entrada/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 APÓS o CUBE ter processado o roteamento de chamada e antes que a mensagem seja enviada ao próximo salto.
Outras observações sobre a configuração de perfil sip:
- Os perfis SIP não podem manipular atributos SDP m=image. A melhoria foi registrada no CSCsr20474 . Além disso, os perfis SIP não podem remover ou adicionar valores ao SDP. Só podemos modificar esses valores. No entanto, é possível modificar um valor SDP em um valor nulo especificando o valor inteiro e, em seguida, definindo a saída como um conjunto de orçamentos vazios sem espaço.
- Não há verificações executadas para ver se o comando atual que está sendo inserido já existe ou se uma versão desse comando já existe ao inserir comandos dentro do perfil sip de classe de voz. Se um administrador colar uma linha 7 vezes em um perfil sip, ele será exibido 7 vezes na configuração em execução. Recomenda-se remover o comando sendo modificado e inserir o novo comando ao editar perfis sip para evitar a presença de vários comandos.
Documentação completa: http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-sip-param-mod.html?bookSearch=true
Ferramenta de teste de perfil SIP:https://cway.cisco.com/tools/SipProfileTest/
Sintaxe de exemplo 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 de 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 de perfil SIP de entrada
Observe: É necessário ativar "entrada de perfil sip" no voice service voip sip se o aplicativo global, o espaço ou o aplicativo dial-peer é 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 OPÇÕES
!
voice class sip-options-keepalive 200
transport tcp tls
sip-profiles 299
!
Exemplo de perfil SIP 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>" !
Exemplo de perfil SIP 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 !
Exemplo de perfil SIP para modificar a parte do nome do identificador de chamada 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 sem sentido 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
Exemplo de perfil SIP 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 no perfil SIP. Esse é o mesmo conceito dos 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 das quebras de linha nova com um perfil SIP.
As quebras de linha nova são suportadas em perfis SIP, no entanto, há apenas um caso de uso muito específico para elas. Como os perfis SIP não têm nenhum IF, então, a lógica Else agora há uma maneira de executar modificações em um cabeçalho com base em uma entrada de outro cabeçalho. Ou seja, um administrador somente deseja modificar um cabeçalho de desvio se o cabeçalho FROM contiver 1234@cisco.com. Utilizando a quebra da nova linha, podemos "falsificar" a instrução IF dentro de um perfil SIP. Veja o exemplo de configuração abaixo: Nós combinamos 1234 em qualquer domínio no cabeçalho De. Em seguida, exibimos o primeiro conjunto e adicionamos uma nova quebra de linha "\x0D\x0AD". Finalmente, adicionamos o cabeçalho desejado. Veja que esse método permite que apenas adicionemos um cabeçalho. Não há como modificar outro cabeçalho. Portanto, isso atende apenas parcialmente aos requisitos que um administrador queria atingir acima.
!
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 da camada 7 através do 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
Copylist SIP são uma extensão de perfis SIP que permite que o gateway COPIE um cabeçalho do segmento interno de uma chamada e, em seguida, PASTE para outro ponto na mensagem SIP de saída no segmento externo. O suporte a Copylist SIP foi adicionado no IOS 15.1(3)T e no IOS-XE 3.6S. Essa é uma forma poderosa de criar cabeçalhos dinâmicos com base em outros cabeçalhos do segmento interno 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 e de identificação de chamada.
Documentação completa: http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/copy_sip_headers.html?bookSearch=true
Exemplo de lista de cópias 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@14.50.244.2>" ! ! Apply the SIP profile to an outbound dial-peer ! dial-peer voice <tag> voip voice-class sip profiles <number>
!
Depuração de perfis SIP e lista de cópias
debug voip ccapi inout debug ccsip mess debug ccsip info debug ccsip feature sip-profile
Saída de depuração da lista de cópias SIP de exemplo
### Ingress from CUCM Received: INVITE sip:1001@14.50.228.61:5060 SIP/2.0 Via: SIP/2.0/TCP 14.50.244.3:5060;branch=z9hG4bKaad21bc3ae7e From: "5001" <sip:5001@14.50.244.3>;tag=100442~cdffff43-5020-4e79-a10b-99d406971010-36470319 Contact: <sip:5001@14.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@14.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 : : @165.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@165.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@165.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 14.50.228.61:5060;branch=z9hG4bK3C7CD Remote-Party-ID: "5001" <sip:5001@14.50.228.61>;party=calling;screen=yes;privacy=off From: "5001" <sip:5001@14.50.228.61>;tag=34C458-D6 Contact: <sip:5001@165.117.64.94>
Notas especiais
Sinalização de protocolo e vinculação de mídia
Todos os protocolos de sinalização permitem aos administradores a capacidade de vincular a sinalização a uma interface específica. Por padrão, um gateway sem um enlace definido estático gera a sinalização para uma chamada da interface física pela qual o pacote atravessa. Com a ligaçã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 associação de peer de discagem sempre substitui a associação de voz de locatário de classe de voz e serviço de voz global com o Session Initiation Protocol (SIP).
Muitas vezes, os administradores vinculam a sinalização a um loopback. Ser uma interface lógica significa que nenhum pacote atravessa essa essa interface. Para executar capturas de pacote, 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 destino/IP remoto, mesmo que a configuração esteja vinculada a uma interface virtual.
A associaçã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 de/para 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.
Mesmo que a mídia e a sinalização (controle) estejam ligadas ao loopback 1 o 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 das operações para vinculação de aplicativos da camada 7
- De acordo com a declaração bind no correspondente de discagem de entrada/saída correspondente
- De acordo com os vínculos sob o espaço de classe de voz atribuído ao correspondente de discagem de entrada/saída correspondente
- De acordo com a declaração global vinculativa
- De acordo com a interface física da camada 3, espera-se que o pacote saia com base 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 de 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> !
DNS e correspondentes de discagem VoIP
O DNS com VOIP é empregado em qualquer outra solução DNS. Uma configuração comum é utilizar session target 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 estejamos desabilitando o DNS, os peers de discagem VOIP ainda resolvem a entrada DNS. No entanto,Recentemente, no IOS-XE 3.16S, houve algumas alterações na funcionalidade de DNS geral nas plataformas IOS-XE.
Depois dessa alteração, os peers de discagem configurados com session target dns:FQDN.com agora observam o fato de que o DNS está desabilitado sem pesquisa de domínio ip.
Recomendo sempre que o comando "ip domain lookup" seja configurado ao trabalhar com o DNS para evitar esse problema.
Para conexões SIP de saída, executamos a seguinte ordem de operações para resolução de DNS.
- pesquisa de consulta SRV
- Uma pesquisa de registro
- 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: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-cube-sip-dns-srv-rfc2782.html
Para conexões SIP de entrada em que um gateway IOS precisa resolver um cabeçalho para responder a uma mensagem, o gateway usará a seguinte ordem de operações para a resolução DNS
- Uma pesquisa de registro
- Pesquisa de registro AAAA
Exemplos 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 SRV de DNS no IOS-XE é suportado em 15.6(1)S / 3.17.00.S e posterior
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 DNS 3.15S e abaixo
### 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 14.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: 14.50.244.2
Teste 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 14.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=1.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 podem ser utilizadas, pode ser útil empregar os comandos max-conn ou max-bandwidth. max-conn foi adicionado no IOS 11.3(1)T e está presente em todas as versões do IOS-XE enquanto max-bandwidth foi adicionada em 15.2(2)T e IOS-XE 3.7S
Exemplo de configuração:
Abaixo, estamos dizendo ao gateway para limitar as chamadas de peer de discagem 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 ultrapassemos 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 limite de max-conn é cruzado
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=1.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 14.50.244.62:5060;branch=z9hG4bKb78c35aa21b0 From: <sip:9001@14.50.244.62>;tag=72531~2e8ca155-3f0b-4f07-a1b2-b14ef77ceb7f-26250846 To: <sip:1234@14.50.245.70>;tag=3E19564D-1684 Date: Thu, 05 Oct 2017 19:01:02 GMT Call-ID: 86b07080-9d61816e-b762-3ef4320e@14.50.244.62 CSeq: 101 INVITE Allow-Events: telephone-event Warning: 399 14.50.245.70 "Maximum Number of Connections reached for dial-peer 1" Server: Cisco-SIPGateway/IOS-15.4.3.S4 Content-Length: 0
Direct Inward Dial (DID)
Discagem em um estágio
Com a Discagem direta interna ativada nos peers de discagem POTS, a mensagem de entrada deve conter todos os dígitos necessários para rotear a chamada. O Cisco Gateway não deve fazer a coleta de dígitos subsequente. Quando o roteador ou gateway procura um peer de discagem de saída, o dispositivo usa toda a cadeia de discagem de entrada. Essa correspondência é de comprimento variável por padrão. Essa correspondência não é feita dígito por dígito porque, por definição DID, todos os dígitos foram recebidos. Estas são as configurações padrão para peers de discagem POTS.
Documentação completa: http://www.cisco.com/c/en/us/support/docs/voice/digital-ccs/14072-direct-inward-dial.html
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 nenhuma discagem interna direta, o roteador ou gateway entra no modo de coleta de dígitos (os dígitos são coletados em 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 de peer de discagem depois que o dispositivo recebe cada dígito e 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
!Bloquear chamadas
Cada protocolo lida com o bloqueio de chamadas um pouco diferente. A maioria dos protocolos pode usar o padrão de rejeição da regra de tradução que bloqueia com base em uma string de dígito. Se um administrador ainda quiser aplicar um perfil de conversão de entrada para manipulação normal de dígitos, mas não bloquear nenhum número dentro, há uma 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 a coleta de chamadas. Isso é observado e empregado principalmente em implantações no Brasil, mas pode ser configurado por meio de qualquer grupo personalizado caso a caso.
As duas opções são:
- Bloqueie a chamada coletada recebida com base na categoria II-8 recebida do switch da companhia telefônica. Esse é o mecanismo padrão e todos os Cisco Gateways executam isso sem nenhuma configuração. Esse método de bloqueio exige um switch telco mais recente que suporte marcação baseada em categoria. Para desabilitar esse método, use o comando collection-call-enable no grupo cas-customer
- Utilize o recurso de resposta dupla em um grupo personalizado de cas R1 R2 digital r2. A configuração de resposta dupla desativa o bloqueio baseado em categoria e a substitui pelo recurso de resposta dupla. Isso funciona atendo 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 deve, então, enviar um FWD CLEAR para o gateway e a chamada deve ser desconectada. Um temporizador começa depois que o gateway envia o CLEAR BWD e, se esse temporizador expirar, o gateway enviará outro sinal de RESPOSTA, presumindo-se que a chamada não é uma chamada coletada e, daqui, a chamada prossegue normalmente. Esse temporizador pode ser configurado usando cc-reanswer-to no grupo cas-custom.
Categoria II-8 Bloquear mensagem (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 de 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 de 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
Recepção de sobreposição de ISDN
Há implicações para a correspondência de peer de discagem de entrada quando o comando isdn replace-receive é configurado em 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á encaminhada imediatamente (para o aplicativo de sessão nesse caso) sem esperar por 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 do 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) em mensagens de informações do Q.931.
Número chamado vazio
A mensagem de aviso mostrada abaixo é exibida quando o peer de discagem é configurado com o número chamado T de entrada
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
Notas especiais sobre correspondência de peer de discagem de entrada 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, um 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 em answer-address ou port-number.
-
Em caso de discagem sobreposta, um número chamado "nulo" não corresponde a "número chamado de entrada T" porque o tempo limite não ocorreu.
-
Um número chamado "nulo" pode corresponder ao "número chamado de entrada T" somente no caso do ENBLOCK e não há correspondência devido ao endereço de resposta e ao número de porta. O aviso exibido mostra quando um administrador configura o "número chamado de entrada T" para este caso específico.
Classe de restrição
A classe de restrição é uma forma de limitar as chamadas em um gateway Cisco. O COR é frequentemente descrito como um mecanismo de bloqueio e chave. Os bloqueios são atribuídos a correspondentes de discagem com uma lista de COR de saída. As chaves são atribuídas aos correspondentes de discagem com uma lista de 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 resto dos métodos de correspondência de peer de discagem de saída sejam verificados.
Duas regras importantes com classe de restrição:
- Se não houver uma lista de COR de saída aplicada, a chamada será sempre roteada
- Se não houver uma lista de COR de entrada, a chamada será sempre roteada
A configuração da Classe de Restrição (COR - Class of Restriction), da Classe de Restrição de Particionamento Lógico (LPCOR - Logical Partitioning Class of Restriction) e do LPCOR com Códigos de Autorização Forçados (FAC - Forced Authorization Codes) estão fora do escopo deste documento, mas os seguintes documentos podem ser consultados para leitura posterior.
Correspondentes de discagem do Cisco Unified Communications Manager Express (CUCME)
O CME cria peers de discagem do sistema para telefones e pools de registro de voz. Eles não podem ser vistos na configuração atual. Para fazer alterações nos peers de discagem 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 peer de discagem começando com 2000 são telefones SCCP e os peers de discagem iniciando com 4000 são pools de registro de voz SIP. Esse peer de discagem é exibido 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.
Exemplo de saída 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
Exemplo de saída 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 devem ser configurados com a porta de voz desejada para a chamada. O restante é tratado pelo processo STCAPP e MGCPAPP. Quando examinamos 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 deve tratar.
Ao depurar esses protocolos, a saída nunca exibe uma correspondência de peer de discagem de entrada. Isso sempre deve aparecer como dial-peer 0. Porque não existe. O Agente de Chamada que manipula o aplicativo já escolheu a porta para a qual enviar a chamada e a correspondência de peer de discagem de entrada é inútil, pois o gateway não tem controle sobre esse trecho da chamada. No entanto, uma correspondência de peer de discagem de saída pode ser observada. Isso é apenas para exibição, pois o agente de chamada que trata do processo também tem controle sobre esse lado da chamada.
Lembre-se, o peer de discagem informa somente ao aplicativo de escolha qual porta de voz física controlar. Como a maioria disso é controlada por um agente de chamada externo e o gateway está apenas fazendo o que é dito que vamos ignorar o "como" subjacente nesta 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: http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cminterop/configuration/15-mt/dia-15-mt-book/vc-ucm-mgcp-gw.html
Exemplo de configuração de SCCP/STCAPP [com configuração automática de 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
!
Documentação completa do SCCP: http://www.cisco.com/c/en/us/td/docs/routers/access/vg202\_vg204/software/vg2\_vg4\_scg/vg2\_vg4\_voip.html
* Se um administrador não quiser que o CUCM configure o gateway, basta remover os comandos "ccm-manager". Incluímos a configuração do peer de discagem para trazer para casa o ponto sobre como o conceito funciona. Com as configurações do gerenciador ccm presentes, o CUCM cria esses peers de discagem com base na configuração de porta no CUCM, de modo que não há necessidade de definir realmente o peer de discagem. Os peers de discagem criados pelo CUCM normalmente começam com 999 e são, então, mais três dígitos.
DSAPP SIP com correspondentes de discagem
O SIP DSAPP foi adicionado em IOS-XE 16.12.1+ e CUCM 12.5.1SU+
Com esse recurso, portas de voz analógicas como FXS podem ser registradas e gerenciadas pelo CUCM. O roteamento de chamadas com DSAPP é um pouco diferente de MGCP ou SCCP, pois os peers de discagem ainda são correspondidos normalmente. Ou seja, o gateway coletará dígitos da porta FXS e fará uma pesquisa de peer de discagem nos peers de discagem VOIP. Depois que uma correspondência é encontrada, o CONVITE é enviado para o bloco CUCM para que o CUCM execute uma análise de dígitos adicional.
Exemplo de configuração do SIP DSAPP [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 DSAPP SIP completa: https://www.cisco.com/c/en/us/td/docs/routers/access/vg450/software/configuration/guide/vg450-scg/vg450-scg_chapter_010.html#wp3621733520
Troubleshooting e Verificação de Roteamento de Chamadas
Esta seção foi removida em 2022. Consulte o novo documento para obter informações mais detalhadas
Histórico de revisões
| Revisão | Data de publicação | Comentários |
|---|---|---|
3.0 |
27-Apr-2022 |
republicação após pequenas alterações. |
1.0 |
30-May-2017 |
Versão inicial |
FeedbackContate a Cisco
- Abrir um caso de suporte
- (É necessário um Contrato de Serviço da Cisco)
Nota: * A exceção a esta regra é com portas de voz MGCP e SCCP. Esses protocolos de sinalização não seguem o mecanismo normal de correspondência de peer de discagem durante o roteamento de chamada. Consulte a seção SCCP e MGCP para obter mais detalhes.