Explicar o roteamento de chamadas do Cisco IOS e IOS XE
Contents
Introdução
Este documento descreve uma explicação do Cisco IOS® e do Cisco IOS XE Call Routing.
Pré-requisitos
Requisitos
Embora não haja pré-requisitos formais necessários para ler este documento, ele é escrito com a expectativa de que o leitor já tenha algum conhecimento dos protocolos subjacentes de sinalização de voz que são usados para estabelecer e conectar chamadas telefônicas. Esses protocolos são referenciados várias vezes ao longo do processo.
Protocolos de sinalização: Session Initiation Protocol (SIP), H323 (h225 / h245), Media Gateway Control Protocol (MGCP), Skinny Client Control Protocol (SCCP), ISDN Q931, E1 R2.
Protocolos de mídia: Real Time Protocol (RTP), codecs de voz, codecs de vídeo.
Tecnologias analógicas: Ear and Mouth (E&M), Foreign Exchange Subscriber (FXS) e Foreign Exchange Office (FXO).
Componentes Utilizados
As informações neste documento são baseadas nestas versões de software e hardware:
- Gateways Cisco IOS e IOS XE
- 2800 / 3800 / 2900 / 3900 / 4300 / 4400 / CSR1000v / CAT8000v / ASR100X / C8200 / C8300 / ISR1100
As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.
Informações de Apoio
Este documento aborda os mecanismos por trás da correspondência de peer de discagem de entrada e saída com trechos de chamada de Rede de Serviço Telefônico Tradicional Comum (POTS - Plain Old Telephone Service) e Voz sobre IP (VoIP - Voice over IP).
Além das informações do dial-peer, este documento aborda tópicos importantes que pertencem ao roteamento de chamadas. Isso inclui manipulação de dígitos, uma rápida visão geral da manipulação de mensagens do Session Initiation Protocol (SIP), alguns métodos para restringir os recursos de chamada, uma rápida visão geral de vinculação de sinalização e mídia e, finalmente, um pouco de solução de problemas.
Este documento utiliza exemplos de configuração, bem como saídas dos comandos debug e show como pontos de referência. Os vários recursos neste documento estão claramente marcados com a versão que o recurso foi introduzido no Cisco IOS e no Cisco IOS XE. Essas informações também podem ser consultadas rapidamente na seção Command and Feature Roadmap. Se há um defeito muito notável, ele é vinculado dentro do texto para que os leitores estejam cientes.
Definições comuns
| Atributo |
Descrição |
|---|---|
| Cadeia de Caracteres de Dígito |
Também conhecido como cadeia de caracteres do número, número de telefone, número ou número E164. Consiste inteiramente em dígitos de 0 a 9 com um símbolo de adição (+) à esquerda opcional.
|
| Serviço de Identificação de Número Discado (DNIS) |
Esse é o Número Chamado ou o Número de Destino de uma chamada. |
| Identificação Automática de Número (ANI) |
Esse é o Número que faz a chamada ou o Número que faz a chamada de origem de uma chamada. Isso também pode ser chamado de identificador de linha chamadora (CLID), que também pode ser chamado de identificador de chamada. |
| URI (Uniform Resource Identifier, Identificador Uniforme de Recursos) |
Um URI é uma sequência de caracteres sip: ou tel: usada com mais frequência com os protocolos VoIP SIP e H323.
|
| ID da operadora |
Exemplos de CID: |
| String de Rota |
Um cabeçalho de propriedade da Cisco para sequências 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. Este documento não trata dessa questão. |
| PSTN |
Rede de telefonia pública comutada |
| ITSP |
Provedor de serviços de telefonia via Internet |
| SBC |
Session Border Controller (Controlador de fronteiras da sessão). Este é o dispositivo que serve como ponto de demarcação entre a LAN do cliente e uma rede ITSP/PSTN |
Roteiro de comandos e recursos
| Recurso | Versão do IOS | Versão do IOS XE |
| Expansão de Número (num-exp) Peers de discagem (POTS e VOIP) answer-address padrão de destino incoming called-number destino da sessão (IPv4 e DNS) Máximo de conexões (max-conn) direct-inward-dial dígitos de encaminhamento (POTS) prefixo (POTS) timeouts inter-digit (porta de voz) |
11.3(1)T |
Todos |
| terminador de dial peer |
12.0 |
Todos |
| huntstop |
12.0(5)T |
Todos |
| Mapas ISDN |
12.0(6)T |
Todos |
| Esquemas de busca de correspondentes de discagem |
12.0(7)XK |
Todos |
| Regra e perfil de conversão de voz translate-outgoing numbering-type 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 |
| DNIS-Map (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 |
| proxy de saída |
12.4(15)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,8S |
| Lista de cópias SIP destino de sessão (Registrador) |
15.1(3)T |
3,6S |
| rota de chamada (url) |
15.2(1)T |
3,3S |
| max-bandwidth |
15.2(2)T |
3,7S |
| E164-Pattern-Maps (Outbound) |
15,2(4)M |
3,7S |
| String de Rota de Classe de Voz call-route (dest-route-string) |
15,3 (3)M |
3,10S |
| Grupos de correspondentes de discagem (VOIP) E164-Pattern-Maps (Inbound) Grupo de Servidores de Destino passagem de requisição destino de sessão (sip-uri) |
15.4(1)T |
3,11S |
| Política de Provisionamento de Ponto de Discagem Perfis SIP (Entrada) |
15.4(2)T |
3,12S |
| Grupo de Correspondente de Discagem (POTS) |
15.5(1)T |
3,14S |
| Locatários da Classe de Voz |
15.6(2)T |
16.3.1 |
| Filtragem VRF para correspondentes 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 locatário Filtragem para pares de discagem |
n/a |
17.8.1 |
| Manutenção de atividade da opção baseada em SRV DNS |
n/a |
17.9.1 |
Fundamentos de roteamento de chamadas do Cisco IOS / Cisco IOS XE
Os gateways Cisco IOS e Cisco IOS XE utilizam um conceito de peer de discagem para controlar o roteamento de chamadas e a negociação de recursos para cada trecho de uma chamada. Um leg da chamada é a comunicação bidirecional entre dois agentes de chamadas. Um agente de chamadas é um dispositivo que inicia, processa ou encaminha chamadas telefônicas. Isso pode ser e não está limitado ao equipamento do provedor de telefonia, um gateway Cisco, um telefone IP, um Cisco Unified Communication Manager (CUCM), conexão Cisco Unity (CUC), etc. Há muitos agentes de chamadas para listar.
Cenário: uma chamada chega a um gateway Cisco de outro agente de chamadas e é o trecho da chamada de entrada (no trecho). O gateway processa a chamada e, com base em seu processamento, envia a chamada para o próximo agente de chamada. Este é o trecho de chamada de saída (trecho de saída).
A imagem 1 mostra uma chamada do roteamento PSTN para CUCM por meio de um gateway de voz Cisco e as respectivas informações de trecho de chamada de entrada e saída.
Imagem 1 - Trechos de chamada de entrada e saída ilustrados
Uma chamada bem-sucedida por meio de um Gateway Cisco SEMPRE (consulte a observação) corresponde a um correspondente de discagem de entrada ou de saída para rotear corretamente. Os peers de discagem de entrada e de saída são semelhantes aos trechos de chamada mencionados anteriormente. Na Imagem 1, a chamada chega do PSTN no gateway Cisco e precisa corresponder a um peer de discagem de entrada. Em seguida, o gateway utiliza um peer de discagem de saída para rotear a chamada para o próximo agente de chamada. É importante lembrar que esses termos são definidos da perspectiva do Cisco Gateway.
Ao fazer a correspondência de um correspondente de discagem para cada lado da chamada, um administrador tem o poder de controlar muitos aspectos de cada segmento de chamada específico. Exemplos disso incluem codecs de voz, preferências DTMF, manipulação de dígitos, onde a chamada deve ser roteada e muitas outras configurações. Os peers de discagem podem ser configurados com instruções de correspondência de entrada e de saída, portanto a correspondência do mesmo peer de discagem para o trecho de entrada e o trecho de saída será possível se uma configuração de correspondência de entrada e de saída válida for aplicada a esse peer de discagem específico.
A Imagem 2 ilustra os mesmos trechos de chamada de entrada e de saída que a Imagem 1, mas com os correspondentes de discagem para uma chamada do roteamento PSTN para CUCM por meio de um gateway de voz Cisco.
Imagem 2 - Peers de discagem de entrada e de saída ilustrados
Os Cisco Voice Gateways podem interagir com muitos tipos diferentes de chamadas de voz e protocolos, incluindo IP para IP, POTS para POTS e IP para POTS ou vice-versa.
A Imagem 3 ilustra uma chamada VoIP para VoIP através do Cisco Unified Border Element (CUBE).
Imagem 3 - Peers de discagem de entrada e de saída para uma chamada VoIP para Voip
A imagem 4 exibe uma chamada POTS para POTS através de um gateway Cisco.
Imagem 4 - Peers de discagem de entrada e de saída para uma chamada POTS para POTS
Tipos de correspondentes de discagem de voz
| POTS |
Os peers de discagem Plain Old Telephony Service são combinados para conexões analógicas como FXS analógico, FXO, ISDN T1 / E1s, E1 R2 e conexões de ouvido e boca (E&M). Eles enviam ou recebem uma chamada de/para 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 peers de discagem enviam e recebem sinalização de endereços IPv4 e IPv6, bem como nomes de domínio totalmente qualificados (FQDN) usando o Sistema de Nome de Domínio (DNS). — Os peers de discagem VoIP também podem ser usados para sinalização VoFR (Voice over Frame Relay), VoATM (Voice over ATM), VoHDLC (Voice over High-Level Data Link Control) e RAS (Registration, Admission, and Status) e os destinos de sessão para esses peers de discagem também podem incluir acordos e valores ENUM. Observação: 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 serão abordados neste documento. |
| MMOIP |
Os peers de discagem Multimídia Mail Over IP são utilizados para enviar e-mails para servidores do Exchange. Eles são utilizados principalmente para fax t37 on-ramp / off-ramp. Esses tipos de peer de discagem não estão dentro do 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, o gateway começa a procurar um correspondente de discagem de entrada aplicável para essa chamada. Essa não é uma análise dígito por dígito; em vez disso, a mensagem completa é utilizada para determinar qual peer de discagem de entrada é selecionado. A ordem dos itens na mensagem verificada depende muito do protocolo da chamada, conforme indicado pelas listas de preferências definidas na Tabela 1, Tabela 2 e Tabela 3. Um peer de discagem só precisa satisfazer uma das condições de correspondência. Não é necessário que todos os atributos sejam configurados no peer de discagem ou que cada atributo corresponda às informações de configuração de chamada. Todos os correspondentes de discagem são pesquisados com base nos primeiros critérios de correspondência. O gateway passa para o próximo critério somente se nenhuma correspondência for encontrada.
Tabela 1. Preferência de Seleção de Ponto de Discagem SIP de Entrada
| Preferência |
Critérios de Correspondência |
Comandos de peer de discagem |
| 1 |
URI |
uri de entrada via <uri-tag> |
| 2 |
URI |
requisiçã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> chamada de entrada e164-pattern-map <número-do-mapa-padrão> |
| 6 |
Número de chamada |
chamada recebida e164-pattern-map <número-do-mapa-padrão> answer-address <number-string> |
| 7 |
Padrão de destino (ANI) |
destination-pattern <cadeia_de_números> |
| 8 |
ID da operadora |
carrier-id source <string> |
Observação: os correspondentes de discagem de entrada qualificados podem ser filtrados por VRF ou Locatário. se o recurso aplicável estiver configurado. Para obter mais informações, consulte as seções Virtual Routing and Forwarding (VRF) e Dial-Peer Hunting e Voice Class Tenants .
Tabela 2. Preferência de seleção de peer de discagem H323 de entrada
| Preferência |
Critérios de Correspondência |
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> chamada de entrada e164-pattern-map <número-do-mapa-padrão> |
| 3 |
Número de chamada |
chamada recebida e164-pattern-map <número-do-mapa-padrão> answer-address <number-string> |
| 4 |
Padrão de destino (ANI) |
destination-pattern <cadeia_de_números> |
| 5 |
ID da operadora |
carrier-id source <string> |
Tabela 3. Preferência de Seleção de Ponto de Discagem POTS de Enbloc de Entrada
| Preferência |
Critérios de Correspondência |
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 <cadeia_de_números> |
| 4 |
Porta de voz |
port <voice-port-number> |
Quando não há correspondências / Correspondente de discagem padrão 0 peer_tag=0, pid:0
Quando não há correspondências qualificadas para um peer de discagem de entrada para chamadas POTS ou VoIP, o gateway aloca o peer de discagem 0. Isso não é ideal, pois o correspondente de discagem 0 tem recursos limitados e pode causar problemas com as chamadas. O ponto negativo disso são os protocolos SCCP e MGCP que não usam correspondentes de discagem para rotear chamadas. Consulte a seção MGCP e SCCP para obter mais detalhes.
recursos do dial-peer 0
- Sem mecanismos de retransmissão dtmf.
- Anunciados todos os codecs de voz para chamadas VoIP.
- Voz com taxa de fax.
- A Detecção de Atividade de Voz (VAD - Voice Activity Detection) está ativada.
- Sem suporte a RSVP.
- Não há suporte de aplicativo IVR para chamadas POTS.
- A discagem interna direta está ativada.
- Não suporta VRF.
Correspondência de Peer de Discagem de Saída
Os peers de discagem de saída são utilizados para rotear chamadas POTS ou VoIP do gateway para o próximo agente de chamada. Como a correspondência de peer de discagem de entrada, há uma lista de itens que o gateway pode usar para corresponder peers de discagem com base na ordem de preferência para o protocolo específico. No entanto, ao contrário dos peers de discagem de entrada, se não houver nenhum peer de discagem de saída qualificado para rotear a chamada, a chamada falhará. Como a correspondência de peer de discagem de entrada, todos os peers de discagem são pesquisados com base nos critérios de primeira correspondência. O gateway passa para o próximo critério somente se nenhuma correspondência for encontrada.
Tabela 4. Preferência de Seleção de Ponto de Discagem SIP de Saída
| Preferência |
Critérios de Correspondência |
Comandos de peer de discagem |
| 1 |
Ponto de Discagem do Grupo de Peers de Discagem |
destination dpg <dpg-tag> (DPG configurado no peer de discagem de entrada) |
| 2 |
URI da Política de Provisionamento de Ponto de Discagem |
uri-from de destino <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 |
uri de destino <uri-tag> AND carrier-id de destino <string> |
| 5 |
Número chamado e ID da operadora |
destination-pattern <cadeia_de_caracteres> AND carrier-id target <cadeia_de_caracteres> |
| 6 |
URI |
uri de destino <uri-tag> |
| 7 |
Número Chamado |
destination-pattern <DNIS-number> destination e164-pattern-map <número do mapa de padrões> dnis-map <dnis-map-number> |
| 8 |
Número de chamada |
destination calling e164-pattern-map <número-do-mapa-padrão> |
Tabela 5. Preferência de seleção de dial peer H323 de saída
| Preferência |
Critérios de Correspondência |
Comandos de peer de discagem |
| 1 |
Ponto de Discagem do Grupo de Peers de Discagem |
destination dpg <dpg-tag> (configurado no peer de discagem de entrada) |
| 2 |
URI e Carrier-ID |
uri de destino <uri-tag> AND carrier-id de destino <string> |
| 3 |
Número chamado e ID da operadora |
destination-pattern <cadeia_de_caracteres> AND carrier-id target <cadeia_de_caracteres> |
| 4 |
URI |
uri de destino <uri-tag> |
| 5 |
Número Chamado |
destination-pattern <cadeia_de_números> destination e164-pattern-map <número do mapa de padrões> dnis-map <dnis-map-number> |
| 6 |
Número de chamada |
destination calling e164-pattern-map <número-do-mapa-padrão> |
Tabela 6. Preferência de Seleção de Ponto de Discagem POTS de Saída
| Preferência |
Critérios de Correspondência |
Comandos de peer de discagem* |
| 1 |
Ponto de Discagem do Grupo de Peers de Discagem |
destination dpg <dpg-tag>(configurado no peer de discagem de entrada) |
| 2 |
URI e Carrier-ID |
uri de destino <uri-tag> AND carrier-id de destino <string> |
| 3 |
Número chamado e ID da operadora |
destination-pattern <cadeia_de_caracteres> AND carrier-id target <cadeia_de_caracteres> |
| 4 |
URI |
uri de destino <uri-tag> |
| 5 |
Número Chamado |
destination-pattern <DNIS-number>dnis-map <map-number> |
Busca de correspondente de discagem de cadeia de caracteres de número
Preferência de string numérica:
Assim como os URIs têm uma ordem específica de operações para avaliar correspondências, também há um conjunto de regras usadas ao avaliar uma sequência de dígitos numéricos. O esquema de busca de peer de discagem padrão para um gateway Cisco é definido como 0. Isso significa que o gateway procura um padrão com a correspondência mais longa (mais específica). Se houver dois peers de discagem com o mesmo comprimento de correspondência, o gateway examinará a preferência de peer de discagem explicitamente definida. Por fim, se ambos forem iguais, ele escolhe um em ordem aleatória.
Há outros esquemas de busca de peer de discagem disponíveis para configuração; no entanto, a maioria das implantações mantém o padrão de 0.
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.
O algoritmo de correspondente de discagem da cadeia de caracteres de número de correspondência mais longa localiza o correspondente de discagem com a maioria dos números em uma sequência que corresponde exatamente a uma sequência de números em uma cadeia de caracteres de número. Este conceito é clarificado no cenário subsequente.
Cenário: Os correspondentes de discagem qualificados foram configurados com essas correspondências possíveis, e o gateway está avaliando uma sequência de caracteres de dígito de 2001. O correspondente de discagem 1 pode corresponder a qualquer número de 2000 a 2999, enquanto o correspondente de discagem 2 pode corresponder a 2000 a 2009. O correspondente de discagem 2 seria correspondido para essa chamada, pois é a correspondência mais longa (mais específica) para a string de dígito 2001 quando o mecanismo de busca do correspondente de discagem padrão é empregado (busca do correspondente de discagem 0). Em outras palavras, a sequência de números 200 é a maior sequência que corresponde exatamente a uma sequência de números na sequência numérica 2001.
!
dial-peer voice 1 voip
destination-pattern 2...
!
dial-peer voice 2 voip
destination-pattern 200.
!
A preferência é definida como o peso definido pelo administrador para cada correspondente de discagem. Os administradores podem configurar uma preferência para que a chamada sempre use um correspondente de discagem específico antes dos outros. Por padrão, todos os peers de discagem são preferidos como 0. Um peer de discagem com preferência 0 é correspondido antes de outro peer de discagem com preferência de 1 a 10. A maioria dos administradores configura vários peers de discagem para enviar uma chamada para um assinante CUCM específico com um assinante de backup ou outro agente de chamada sendo configurado usando outro peer de discagem com uma preferência mais baixa (que é configurada com um número maior).
Cenário: Dois peers de discagem são configurados com o mesmo comprimento de correspondência para a sequência de caracteres de dígito de 2001. O administrador define uma preferência explícita. O gateway avalia os dois peers de discagem da mesma forma, já que seu comprimento de correspondência é o mesmo. No entanto, o administrador define o correspondente de discagem 1 com uma preferência mais alta, de modo que o correspondente de discagem seja escolhido como o primeiro correspondente de discagem usado no roteamento da chamada. O correspondente de discagem 2 permaneceria como uma opção secundária caso ocorresse uma falha no primeiro correspondente de discagem.
!
dial-peer voice 1 voip
destination-pattern 2...
preference 1
!
dial-peer voice 2 voip
destination-pattern 2...
preference 2
!
Um gateway Cisco tenta rotear uma chamada apenas por meio de um peer de discagem de saída qualificado de cada vez. Se uma condição de falha for observada no primeiro peer de discagem selecionado, o gateway tentará rotear a chamada para o próximo peer de discagem qualificado. Isso continua até que a chamada seja bem-sucedida ou falhe, pois não há mais correspondentes de discagem qualificados para tentar. Um sintoma comum de caçada e falha do peer de discagem é um atraso notável no retorno de chamada durante as chamadas. As depurações geralmente são necessárias para verificar exatamente por que a chamada está falhando em um determinado peer de discagem. O comando huntstop pode ser empregado em um peer de discagem se um administrador não quiser que um gateway procure outro peer de discagem quando uma condição de falha for observada.
Cenário: Dois peers de discagem são configurados com o mesmo comprimento de correspondência para a sequência de caracteres de dígito de 2001. O administrador definiu uma preferência explícita e não deseja corresponder o correspondente de discagem 2 para essa chamada específica. Como há dois peers de discagem com o mesmo comprimento de correspondência, a preferência é usada para determinar o peer de discagem. O correspondente de discagem 1 tem o menor número de preferência configurado, portanto, é usado para rotear a chamada. Se ocorrer uma condição de falha no trecho da chamada de saída usando o correspondente de discagem 1, o gateway interromperá imediatamente a busca do correspondente de discagem, já que o comando huntstop está configurado. Neste cenário, o peer de discagem 2 nunca é utilizado para roteamento de saída.
! dial-peer voice 1 voip destination-pattern 2... preference 1 huntstop ! dial-peer voice 2 voip destination-pattern 2... preference 2 !
Busca de correspondente de discagem URI
O gateway examina cada critério de correspondência e o esgota antes de passar para o próximo critério de correspondência. Um exemplo disso seria em uma chamada SIP de entrada. Com base na Tabela 1. Preferência de seleção de ponto de discagem SIP de entrada, a primeira coisa que o gateway Cisco verifica é o URI e avalia todos os comandos URI em potencial para encontrar um que se encaixe. Se não houver correspondência ou se nenhuma estiver configurada, o gateway passará para o próximo item correspondente e executará uma avaliação com base nesses critérios. Esse processo se repete até que a chamada seja roteada com base em uma correspondência ou o gateway fique sem critérios de correspondência para verificar.
Quando um peer de discagem de entrada ou de saída é configurado com um comando URI, o gateway examina o URI que foi recebido em vários cabeçalhos para uma correspondência potencial. A preferência de correspondência se baseia na correspondência mais específica e a preferência exata se transforma em Correspondência completa de URI, Porção de host, Porção de usuário ou URI de telefone. Conhecer a ordem das operações para correspondência de URI pode ajudar muito na correspondência de peer de discagem com implantações SIP e CUBE.
Essa ordem de preferência pode ser manipulada usando o comando voice class uri sip preference para especificar o user-id como a primeira opção em vez de host.
Preferência de URI:
- A parte de Host do URI. Exemplos: (@a.b.c.d ou @host.domain.name)
- A parte do Usuário do URI. Exemplos: (sip:8675309 ou sip:user)
- O tele-uri. Exemplo: (tel:18005532447)
- Correspondência exata para o URI completo. Exemplos: (user@host.domain.name, user@a.b.c.d, 8675309@host.domain.name, 8675309@host.domain.name)
Documento de suporte: Guia de configuração do Cisco Unified Border Element - Cisco IOS XE 17.6 em diante
Cenário: um administrador configurou esses peers de discagem e envia uma chamada para o gateway. O cabeçalho De no Convite recebido é De: <sip:testuser@10.10.10.10>. O gateway pode corresponder potencialmente dois peers de discagem diferentes com base nesse cabeçalho. Dial-Peer 1 baseado na parte do usuário e dial-peer 2 baseado na parte do host. No entanto, como uma correspondência de host é uma preferência sobre uma correspondência de usuário, o peer de discagem 2 é usado para o peer de discagem de entrada na chamada.
! voice class uri URI1 sip user-id testuser ! voice class uri URI2 sip host ipv4:10.10.10.10 ! dial-peer voice 1 voip sess protocol sipv2 incoming uri FROM URI1 ! dial-peer voice 2 voip sess protocol sipv2 incoming uri FROM URI2 !
URI de Classe de Voz
A correspondência de URI para correspondentes de discagem de entrada e saída permite ao administrador a capacidade e a flexibilidade de executar correspondências em mais de uma sequência de números de telefone para protocolos VoIP que suportam URIs em suas mensagens. Antes do IOS 15.4(1)T e do IOS-XE 3.11S, uma URI de solicitação tinha que conter um user@host alfanumérico; caso contrário, um gateway Cisco rejeitaria a chamada com uma mensagem 4xx. Agora um URI pode conter apenas a parte do host e o gateway roteia a chamada com base apenas no host fornecido. Por exemplo, sip:cisco.com.
Além disso, antes do IOS 15.4(1)T e do IOS-XE 3.11S as IDs de usuário URI de classe de voz só podiam ser valores numéricos e.164 (sip:1234@host.com). Isso foi alterado para que os administradores possam configurar IDs de usuário alfanuméricos no CUBE (sip:user@host.com).
A parte do host ou do usuário de um uri de classe de voz pode conter padrões de expressões regulares (regex) que expandem muito os valores possíveis que podem ser correspondidos.
Gateway(config-voice-uri-class)# user-id .) % unmatched ()user-id pattern can be of format ^([][0-9A-Za-z\|\/()*+^$&?#--.])*$
Gateway(config-voice-uri-class)# host .)
% unmatched ()host pattern can be of format ^([][0-9A-Za-z\|@\/()*+^$&?#--.])*$
Gateway(config-voice-uri-class)# pattern .)
% unmatched ()pattern pattern can be of format ^([][0-9A-Za-z\|@;:=%!~\/()*+^$&?#--.])*$
Exemplo: URIs de classe de voz
! voice class uri HOST sip host webex.com host dns:cisco.webex.com host ipv4:10.50.244.2 host ipv6:[2001:4860:4860::8888] ! voice class uri USER sip user-id username ! voice class uri PATTERN sip pattern 8675309 ! voice class uri HostRegex sip host (.*)cisco.com !
voice class uri ipRegex sip
host 172\.18\.110\.20[567]
! voice class uri PatternRegex sip pattern 555(.*) !
voice class uri ipRegex sip
pattern (172\.18\.110\.10[134]|10\.10\.10\.10)
! One Line that matches 172.18.110.101, 172.18.110.103, 172.18.110.104 OR 10.10.10.10
! voice class uri UserRegex sip user-id test(.*) !
Apenas 10 hosts, 1 padrão ou 1 id de usuário podem ser configurados por uri de classe de voz, como este exemplo demonstra. Se for necessário combinar mais itens, é recomendável usar Regex.
Gateway(config)# voice class uri TEST sip Gateway(config-voice-uri-class)#host ipv4:10.1.1.1 Gateway(config-voice-uri-class)#host ipv4:10.2.2.2 Gateway(config-voice-uri-class)#host ipv4:10.3.3.3 Gateway(config-voice-uri-class)#host ipv4:10.4.4.4 Gateway(config-voice-uri-class)#host ipv4:10.5.5.5 Gateway(config-voice-uri-class)#host ipv4:10.6.6.6 Gateway(config-voice-uri-class)#host ipv4:10.7.7.7 Gateway(config-voice-uri-class)#host ipv4:10.8.8.8 Gateway(config-voice-uri-class)#host ipv4:10.9.9.9 Gateway(config-voice-uri-class)#host ipv4:10.10.10.10 Gateway(config-voice-uri-class)#host ipv4:10.11.11.11 Error:Maximum of 10 hosts can only be configured. Gateway(config)# voice class uri TEST2 sip Gateway(config-voice-uri-class)#host dns:1.com Gateway(config-voice-uri-class)#host dns:2.com Gateway(config-voice-uri-class)#host dns:3.com Gateway(config-voice-uri-class)#host dns:4.com Gateway(config-voice-uri-class)#host dns:5.com Gateway(config-voice-uri-class)#host dns:6.com Gateway(config-voice-uri-class)#host dns:7.com Gateway(config-voice-uri-class)#host dns:8.com Gateway(config-voice-uri-class)#host dns:9.com Gateway(config-voice-uri-class)#host dns:10.com Gateway(config-voice-uri-class)#host dns:11.com Error:Maximum of 10 hosts can only be configured. Gateway(config)# voice class uri TEST3 sip Gateway(config-voice-uri-class)#user-id 8675309 Gateway(config-voice-uri-class)#user-id 123456789 Gateway(config-voice-uri-class)#do sh run | s TEST3 voice class uri TEST3 sip user-id 123456789 Gateway(config)# voice class uri TEST4 sip Gateway(config-voice-uri-class)#pattern 8675309 Gateway(config-voice-uri-class)#pattern 123456789 Gateway(config-voice-uri-class)#do sh run | s TEST4 voice class uri TEST4 sip pattern 123456789
Correspondência de Ponto de Discagem URI de Entrada
Este recurso foi adicionado no IOS 15.1(2)T e no IOS-XE 3.8S e utiliza um URI de classe de voz configurado e aplicado a um peer de discagem de entrada. O URI de entrada foi adotado por muitas pessoas sobre a instrução incoming called-number tradicional para chamadas SIP, pois ele é o primeiro critério de correspondência verificado ao selecionar peers de discagem de entrada. O comando também permite que os administradores correspondam melhor as chamadas que vêm de um determinado agente de chamadas ou usuário.
Documentação completa: Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 em diante
Casos de uso comuns
- 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 correspondente de discagem de entrada correspondente na parte do host do URI para controlar chamadas de entrada de um Provedor de Serviços de Telefonia pela Internet (ITSP)
- Um peer de discagem de entrada que corresponde na parte da ID do usuário do URi para tratamento de chamada de determinados usuários ou números.
Exemplo de configuração
Esta saída de exemplo corresponde ao dial-peer 777 para qualquer requisição SIP originada dos dois IPs HOST definidos no URI de classe de voz. O cabeçalho observado é definido como o cabeçalho De no peer de discagem; no entanto, um administrador pode definir muitos outros, incluindo VIA, TO e REQUEST (Request URI). Se o CUCM enviar um ping OPÇÕES para o CUBE agora corresponder ao dial-peer 777 e originar minha resposta 200 OK para as OPÇÕES da interface especificada. Se o CUCM enviar um convite para o CUBE corresponder ao dial-peer 777 como o dial-peer de entrada.
! voice class uri CUCM sip
host ipv4:10.50.244.2
host ipv4:10.50.244.20 ! dial-peer voice 777 voip description INCOMING URI session protocol sipv2 incoming uri from CUCM voice-class sip bind control source-interface Loopback777 voice-class sip bind media source-interface Loopback777 !
Correspondência de Ponto de Discagem URI de Saída
Os gateways do Cisco IOS podem corresponder a um peer de discagem de saída usando um URI aplicando um uri de classe de voz a um peer de discagem de saída e adicionando um url de rota de chamada à configuração global. Quando ele estiver presente, o CUBE poderá tentar rotear chamadas com base no URI de solicitação. Este recurso foi adicionado no IOS 12.3(4)T e está presente em todas as versões do IOS XE. Pode-se observar que, por padrão, o URI de solicitação SIP de saída e o URI de cabeçalho Para têm o destino de sessão do peer de discagem de saída. Isso pode ser desativado usando o comando requri-passing que permite que o gateway passe a parte do host do URI de entrada para o trecho de saída, em vez de substituir a parte do host do URI pelo destino da sessão. O comando requri-passing foi adicionado no 15.4(1)T e no IOS XE 3.11S.
Exemplo de configuração
voice service voip
sip
call-route url
requri-passing
! voice class uri CUCM sip
host dns:.*.com ! dial-peer voice 777 voip description OUTGOING URI session protocol sipv2 destination uri CUCM
session target sip-uri !
Fonte: Guia de configuração do Cisco Unified Border Element - Cisco IOS XE 17.6 em diante
Além do URI de classe de voz, os administradores podem usar uma política de provisionamento de peer de discagem (DPP) para corresponder um URI em trecho para uma correspondência de peer de discagem de saída. Este recurso foi adicionado no IOS 15.4(2)T e no IOS XE 3.12S. Uma política de provisionamento de peer de discagem requer a definição de um atributo de correspondência primário com um atributo de correspondência secundário sendo opcional. A política de provisão é aplicada a um peer de discagem de entrada e, quando esse peer de discagem é selecionado para uso em um leg da chamada de entrada, a política é chamada. O resultado é uma seleção de peer de discagem de saída com base no atributo da política de provisionamento de peer de discagem.
A correspondência de saída pode ser um único cabeçalho ou vários cabeçalhos, que devem ser todos verdadeiros para corresponder ao correspondente de discagem.
No exemplo, há um uri de classe de voz para os cabeçalhos De e Até. Para uma correspondência OR, é configurada uma política de provisionamento de peer de discagem que contém duas preferências. O cabeçalho De é a primeira preferência e o cabeçalho Para é a preferência de backup. O correspondente de discagem 1234 é criado para aplicar a política de provisão para correspondência de entrada. Em seguida, crie 11111 e 22222 de correspondentes de discagem que apliquem os comandos destination uri-from e destination uri-to, respectivamente. Esses comandos apontam de volta para o URI da classe de voz. Para a chamada, você pode receber o convite, corresponder o dial-peer 1234 e verificar a política de provisão. O dispositivo pode então tentar rotear no cabeçalho De primeiro, que é uma correspondência aplicável em 11111 de dial peer. Se isso falhar, você também pode tentar rotear no cabeçalho para com 22222.
O exemplo também detalha como obter uma correspondência And com as políticas de provisão de peer de discagem. Supondo que o mesmo convite seja recebido, você pode definir dois cabeçalhos em uma preferência e aplicá-lo ao correspondente de discagem de entrada.
Agora, quando o convite é recebido, ele pode verificar os correspondentes de discagem de saída qualificados que satisfazem os dois critérios de correspondência definidos na política de provisão. Neste exemplo, seu peer de discagem de saída precisa ser definido com o cabeçalho TO e FROM para ser correspondido. Se nenhum dos dois for uma correspondência válida, esse 12345 de peer de discagem não será usado.
Observação: embora estejamos roteando a chamada no cabeçalho De, o convite que sai do gateway ainda tem o URI de solicitação original. Simplesmente usamos a política de provisão de peer de discagem para corresponder a um peer de discagem de saída e não alterar o URI da solicitação.
Exemplo de configuração:
### Received INVITE
Received:
INVITE sip:8675309@172.18.110.58:5060 SIP/2.0
From: sipp <sip:sipp@172.18.110.65>;tag=1
To: sut <sip:cube@172.18.110.58:5060>
### Common Configurations
!
voice class uri FROM sip
user-id sipp
!
voice class uri TO sip
user-id cube
!
### OR Match
!
voice class dial-peer provision-policy 1
description match from header. If false, try to header
preference 1 from
preference 2 to
!
dial-peer voice 1234 voip
session protocol sipv2
destination provision-policy 1
incoming called-number .
!
dial-peer voice 11111 voip
destination uri-from FROM
session protocol sipv2
session target ipv4:172.18.110.48
!
dial-peer voice 22222 voip
destination uri-to TO
session protocol sipv2
session target ipv4:172.18.110.48
!
### AND Match
!
voice class dial-peer provision-policy 2
description match from AND to headers
preference 1 from to
!
dial-peer voice 1234 voip
session protocol sipv2
destination provision-policy 2
incoming called-number .
!
dial-peer voice 12345 voip
destination uri-from FROM
destination uri-to TO
session protocol sipv2
session target ipv4:172.18.110.48
!
Fonte: Guia de configuração do Cisco Unified Border Element por meio do Cisco IOS XE 17.5
session target sip-uri
Antes do IOS 15.4(1)T e do IOS XE 3.11S, se a parte do host de um URI fosse diferente, mas o usuário fosse o mesmo, isso exigiria dois peers de discagem de saída separados.
Após essa versão, um administrador pode configurar um ponto de discagem para atender a vários hosts para o mesmo usuário. Por exemplo, testuser@cisco.com e testuser@webex.com no mesmo peer de discagem. O uso do sip-uri de destino de sessão aciona a resolução DNS do domínio do Convidar Req-URI de entrada e determina dinamicamente o IP de destino da sessão.
Exemplo de configuração:
O gateway recebe dois convites SIP com esses cabeçalhos Invite sip:testuser@cisco.com:5060 SIP/2.0 Invite sip:testuser@webex.com:5060 SIP/2.0 O gateway corresponde à solicitação SIP de entrada de testuser@cisco.com e testuser@webex.com no dial-peer 1 devido ao comando URI de entrada e à definição de id de usuário corresponderem ao usuário de teste. O comando voice-class sip call-route url is present significa que você avalia os peers de discagem de saída com base no URI de solicitação deste Convite de entrada. Você faz a correspondência do dial-peer 2 devido aos mesmos motivos pelos quais você fez a correspondência do dial-peer 1, o user-id de testuser. O destino de sessão desse peer de discagem é o sip-uri original, conforme definido pelo sip-uri de destino de sessão "que era um FQDN. Depois que ocorrer uma resolução de DNS e alterar cisco.com e webex.com para um IP para o roteamento de camada 3, você envia uma mensagem para fora do gateway.
!
ip host cisco.com 10.10.10.10
ip host webex.com 10.10.10.10
!
voice class uri TEST-IN sip
user-id testuser
!
dial-peer voice 1 voip
description INCOMING dial-peer
incoming uri request TEST
session protocol sipv2
voice-class sip call-route url
!
dial-peer voice 2 voip
description OUTBOUND dial-peer
destination uri TEST
session protocol sipv2
session target sip-uri
!
Verificação:
show voice class uri <uri-name> show voice class dial-peer provision-policy <number> debug voip uri
Caracteres Curinga de Peer de Discagem
Um administrador pode utilizar curingas de peer de discagem ao definir mecanismos de correspondência de entrada e saída que envolvem uma sequência numérica. Isso inclui destination-pattern, incoming called-number, e164-pattern-maps, answer-address e o comando prefix. Os curingas de peer de discagem são expressões regulares (regex) disponíveis para configuração que permitem maior flexibilidade sobre a correspondência de peers de discagem.
Tabela Curinga
| Caractere |
Definição |
Examples |
| * |
Em um correspondente de discagem, esse é um valor literal de * (estrela) no teclado. |
12345 * |
| # |
Em um peer de discagem, esse é um valor literal de # (libra) no teclado. |
8675309# |
| , |
Insere uma pausa de 1 segundo entre os dígitos.Uma vírgula também pode ser usada entre colchetes [ ] para separar um intervalo contínuo. |
9,,,,55591[1-3,5-9]8675309 |
| . | Caractere Regex para correspondência com qualquer valor 0-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 for necessário. Se forem necessários mais de 15 pontos, utilize 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 na string, é um valor regex para o dígito anterior que ocorre uma ou mais vezes. |
+19191112222 |
| ? |
Regex para o dígito precedente que ocorre zero ou uma vez. |
(206)?5015111 (0)?(1)?(1)?21933... |
| ^ |
Caractere Regex para indicar o início da string quando usado fora dos colchetes Quando usado entre colchetes, é tratado como uma instrução exclude ou 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 |
| $ |
Caractere Regex para indicar o fim de uma string. |
8675309$ |
| \ | Caractere de escape para significar um valor literal |
|
| [ ] | Os colchetes definem um intervalo de caracteres para uma única posição. As vírgulas devem ser usadas para separar cadeias de caracteres 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 variável de até 32 dígitos. O roteador espera o timeout entre dígitos para ocorrer antes de rotear a chamada. O valor padrão para o intervalo entre dígitos é de 10 segundos e pode ser modificado através de intervalos entre dígitos em uma porta de voz. T também faz referência ao temporizador T302. |
9011T |
| - | Usado entre parênteses para definir o intervalo. |
[5-9]1234 |
Saída do Gateway que exibe as possíveis entradas de expressões regulares.
Gateway(config-dial-peer)# destination-pattern asdfqw4r3~2
Incorrect format for E.164 Number
regular expression must be of the form ^[][^0-9,A-F#*.?+%()-]*T?(\$)?$
Estados de Peer de Discagem
Os peers de discagem podem estar em um de dois estados Operacionais.
- Para cima
- Down
Para que um peer de discagem esteja em um estado operacional válido e qualificado para uso com roteamento de chamadas, ele precisa estar no estado UP. Para peers de discagem VOIP de saída, isso significa que pode haver um mecanismo de correspondência de saída válido, bem como um destino de sessão válido para rotear a chamada. Para peers de discagem POTS de saída, um mecanismo de correspondência de saída válido e uma porta de voz válida podem ser configurados. Somente com peers de discagem de entrada, um mecanismo de correspondência de entrada válido deve ser configurado.
O estado busyout é visto quando um peer de discagem é configurado com um mecanismo keepalive e o destino remoto falha nos parâmetros desse mecanismo keepalive. Em seguida, o gateway move o correspondente de discagem para um estado busyout para que ele não seja mais usado para decisões de roteamento de chamadas e, quando o mecanismo keepalive é executado novamente, o gateway coloca o correspondente de discagem de volta em um estado ativo. Se um peer de discagem for selecionado como um peer de discagem de saída e esse peer de discagem estiver em um estado busyout, o gateway falhará a chamada com um código de causa 188.
Junto com os estados operacionais, existem os estados Administrativos.
- 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, insira no shutdown.
Observação: um correspondente de discagem com uma porta de voz que está inativa, desligada ou não operacional permanece no estado operacional Ativo, mas o Estado de Saída é mostrado como Inativo.
Verificação
Gateway# show dial-peer voice summary
dial-peer hunt 0
AD PRE PASS OUT
TAG TYPE MIN OPER PREFIX DEST-PATTERN FER THRU SESS-TARGET STAT PORT KEEPALIVE
1 voip up up 0 syst
777 voip up up 9... 0 syst ipv4:10.50.244.2
555 voip up down 555 0 syst
888 pots up up 888 0 up 0/2/0
999 pots up up 999 0 down 0/2/0
123 voip up up 123 0 syst ipv4:10.10.10.10 busyout
Roteamento e encaminhamento virtual (VRF) e busca de correspondentes de discagem
Correspondência de Peer de Discagem de Entrada com VRF
Começando com IOS 15.6(3)M e IOS-XE 16.3.1, os gateways Cisco podem combinar correspondentes de discagem de entrada usando IDs de VRF. Para tirar proveito disso, um administrador deve vincular o peer de discagem de entrada a uma interface que, por sua vez, vincula o peer de discagem ao ID de VRF na interface especificada. Após a conclusão da vinculação, as chamadas de entrada são filtradas pelo Cisco Gateway para incluir apenas correspondentes de discagem de entrada qualificados que correspondam ao ID de VRF da interface em que o pacote foi recebido. A partir daqui, o correspondente de discagem de entrada é correspondido com base na ordem de operações de correspondência do correspondente de discagem regular.
Antes dessas versões do IOS/IOS-XE, o Cisco Gateway fazia uma seleção de entrada com base na correspondência regular de correspondentes de discagem de entrada sem nenhuma filtragem. Isso significa que uma chamada VRF1 pode ser combinada por um peer de discagem VRF2. Além disso, como apenas um VRF era compatível com H323 e SIP antes dessas versões, surgem outros problemas ao tentar usar recursos de vários VRF. O uso de um único VRF para aplicativos de voz era conhecido como configuração VRF-Aware.
Documentação completa com reconhecimento de VRF: VRF-Aware H.323 e SIP para gateways de voz
Documentação completa do Multi-VRF: Guia de configuração do Cisco Unified Border Element - Cisco IOS XE 17.6 em diante
Correspondência de Peer de Discagem de Saída com VRF
Os gateways Cisco têm a capacidade de fazer a ponte de chamadas através de VRFs sem a necessidade de configurar vazamentos de rota. Isso significa que uma chamada de entrada no VRF1 pode ser roteada de saída em um correspondente de discagem para o VRF2 se a seleção de correspondência de correspondente de discagem de saída normal for satisfeita. Grupos de correspondentes de discagem podem ser empregados para forçar o gateway Cisco a manter a chamada dentro do mesmo VRF.
Exemplo de configuração de grupo de correspondentes de discagem e VRF
Este exemplo de configuração tem VRF1 e VRF2 com dois intervalos IP sobrepostos e dois intervalos de números de telefone sobrepostos.
Utilize a vinculação VRF para garantir que o correspondente de discagem de entrada correto seja correspondido e os grupos de correspondentes de discagem para garantir que o correspondente de discagem de saída associado ao VRF correto seja correspondido. Se um pacote SIP de uma chamada para 8675309 chega em gig0/0/1.2, o gateway filtra todos os peers de discagem de entrada disponíveis com base no ID do VRF2. Isso significa que você não pode fazer a correspondência do correspondente de discagem 10. Agora, quando você verifica a sequência de dígitos, você pode fazer a correspondência do correspondente de discagem 20. O peer de discagem 20 tem um grupo de peer de discagem que informa ao gateway que o único peer de discagem de saída que pode ser combinado também é o peer de discagem 20. Esse grupo de peer de discagem permite evitar a correspondência do peer de discagem 10 e o cruzamento de uma chamada proveniente do VRF1 para o VRF2. A partir daí, a chamada pode prosseguir normalmente.
! interface GigabitEthernet0/0/1.1 description VRF1 encapsulation dot1Q 10 ip vrf forwarding VRF1 ip address 10.10.10.10 255.255.255.0 ! interface GigabitEthernet0/0/1.2 description VRF2 encapsulation dot1Q 20 ip vrf forwarding VRF2 ip address 10.10.10.10 255.255.255.0 ! voice service voip no ip address trusted authenticate media-address voice-vrf VRF1 media-address voice-vrf VRF2 allow-connections sip to sip sip ! voice class dpg 10 description INBOUND VRF1 to OUTBOUND VRF1 dial-peer 10 preference 1 ! voice class dpg 20 description INBOUND VRF2 to OUTBOUND VRF2 dial-peer 20 preference 1 ! dial-peer voice 10 voip description VRF1 destination-pattern 8675309 session protocol sipv2 session target ipv4:10.10.10.20 destination dpg 10 incoming called-number 8675309 voice-class sip bind control source-interface GigabitEthernet0/0/1.1 voice-class sip bind media source-interface GigabitEthernet0/0/1.1 ! dial-peer voice 20 voip description VRF2 destination-pattern 8675309 session protocol sipv2 session target ipv4:10.10.10.20 destination dpg 20 incoming called-number 8675309 voice-class sip bind control source-interface GigabitEthernet0/0/1.2 voice-class sip bind media source-interface GigabitEthernet0/0/1.2 !
Verificação
Gateway# show vrf brief | i VRF VRF1 1:1 ipv4 Gi0/0/1.1 VRF2 2:2 ipv4 Gi0/0/1.2
Gateway# show dial-peer voice summary TAG TYPE MIN OPER PREFIX DEST-PATTERN FER THRU SESS-TARGET STAT PORT KEEPALIVE VRF 10 voip up up 8675309 0 syst ipv4:10.10.10.20 VRF1 20 voip up up 8675309 0 syst ipv4:10.10.10.20 VRF2
Gateway# show voice class dpg 10 Voice class dpg: 10 AdminStatus: Up Description: INBOUND to OUTBOUND VRF1 Total dial-peer entries: 1 Peer Tag Pref -------- ---- 10 1 -------------------------------------
Gateway# show voice class dpg 20 Voice class dpg: 20 AdminStatus: Up Description: INBOUND to OUTBOUND VRF2 Total dial-peer entries: 1 Peer Tag Pref -------- ---- 20 1 -------------------------------------
Técnicas avançadas de roteamento de chamadas
Com o passar dos anos, à medida que as necessidades empresariais crescem, a empresa se expande e exige mais DIDs, e os administradores corporativos podem descobrir que os correspondentes de discagem básicos não atendem bem à escala. Pode haver situações de ativação/desativação que precisam ser resolvidas, ou talvez haja um número excessivo de peers de discagem em geral. Ter milhares de peers de discagem não facilita a administração e a solução de problemas. Ter um peer de discagem para cada servidor CUCM específico ou agente de chamada começa a agravar o problema de muitos peers de discagem, porque agora um administrador precisa configurar um peer de discagem para cada sequência de dígitos. Se houver mais de um provedor SIP conectado a um gateway, ou algumas pessoas diferentes usando o mesmo CUBE, isso torna o isolamento de um espaço específico muito difícil.
A Cisco aproveitou esse feedback e criou um conjunto de itens que podem resolver esses problemas e muito mais. Grupos de correspondentes de discagem, locatários de classe de voz, grupos de servidores de destino, mapas de padrão e164 e grupos de troncos POTS permitem que um administrador resolva todos os problemas listados e muitos outros não listados.
Grupos de Peer de Discagem
Os grupos de correspondentes de discagem foram adicionados no IOS 15.4(1)T e no IOS-XE 3.11S e os correspondentes de discagem POTS foram adicionados como uma opção no IOS 15.5(1)T e no IOS-XE 3.14S. Um grupo de peer de discagem permite que os administradores especifiquem um peer de discagem exato para o roteamento de saída com base no peer de discagem de entrada correspondido. Quando um peer de discagem de entrada com um grupo de peer de discagem configurado é correspondido, a chamada usa o peer de discagem definido no grupo de peer de discagem, mesmo que o padrão de destino não corresponda. O único pré-requisito é que o peer de discagem de saída deve estar ativo, de modo que um método de correspondência de saída deve ser configurado, no entanto, isso não é realmente usado para rotear a chamada.
A melhor maneira de descrever grupos de correspondentes de discagem é associá-los ao conceito de rotas estáticas em uma tabela de roteamento. Essas são decisões de roteamento de entrada estática para saída que eliminam algumas suposições do gateway porque estão informando exatamente como rotear a chamada.
Documentação completa: Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 em diante
Exemplo de configuração
Neste exemplo, o número chamado é 8675309. Isso corresponde ao peer de discagem 1234 com base na instrução incoming called-number. Esse peer de discagem é configurado com um grupo de peer de discagem que afirma que a chamada agora pode rotear os peers de discagem 2, depois 3 e, finalmente, 1 se o peer de discagem 2 falhar. Este é o gateway, então agora tente rotear a chamada para o dial-peer 2 como foi explicitamente dito através do grupo de dial-peer que é o que ele pode fazer.
Observação: o padrão de destino no dial-peer 1, 2 e 3 não é o número chamado de 8675309. Isso é bom e a chamada ainda é roteada sem problemas.
Lembre-se de que, conforme discutido na seção de estados do peer de discagem, você precisa de algo/qualquer coisa configurado como uma instrução de correspondência de saída. Nesse caso, o padrão de destino é apenas para trazer o correspondente de discagem para um estado operacional Ativo, e a sequência de dígitos desse comando nunca é avaliada. É recomendável configurar um padrão como destination-pattern AAAA, pois esse é um padrão de destino válido. Como esse é tecnicamente um peer de discagem válido, outras chamadas podem corresponder a ele. Assim, a sequência de dígitos AAAA significa que você nunca poderá usá-la para nada além de um cenário específico envolvendo um grupo de correspondentes de discagem, pois a probabilidade de uma chamada recebida para AAAA é muito, muito baixa.
!
dial-peer voice 1 voip
description Server 1
destination-pattern ^1234$
session target ipv4:1.1.1.1
!
dial-peer voice 2 voip
description Server 2
destination-pattern ^5678$
session target ipv4:2.2.2.2
!
dial-peer voice 3 voip
description Server 3
destination-pattern AAAA
session target ipv4:3.3.3.3
!
voice class dpg 1
description Dial-peer Group for specific called number 8675309
dial-peer 2 preference 1
dial-peer 3 preference 2
dial-peer 1 preference 3
!
dial-peer voice 1234 voip
description INCOMING dial-peer with DPG
incoming called-number ^8675309$
destination dpg 1
!Verificação
Gateway# show voice class dpg 1 Voice class dpg: 1 AdminStatus: Up Description: Dial-peer Group for specific called number 1234 Total dial-peer entries: 3 Peer Tag Pref -------- ---- 2 1 3 2 1 3 -------------------------------------
E164-Pattern-Maps
Esse recurso permite que os administradores reduzam o número total de correspondentes de discagem combinando várias correspondências de número possíveis (padrões de destino, número chamado de entrada etc.) em um único mapa de padrões. O suporte ao mapa de padrão e164 do correspondente de discagem de saída foi adicionado no IOS 15.2(4)M e no IOS-XE 3.7S, enquanto o suporte ao mapa de padrão e164 do correspondente de discagem de entrada foi adicionado no IOS 15.4(1)T e no IOS-XE 3.11S.
Um mapa de padrões e164 pode ser configurado por meio da CLI ou pré-configurado e é salvo como um arquivo .cfg. O arquivo .cfg é adicionado à memória flash do gateway e referenciado ao configurar o restante do comando. O arquivo .cfg pode utilizar 5.000 entradas.
As entradas em ambos os métodos de configuração podem utilizar todos os curingas normais do correspondente de discagem para agregação adicional!
Documentação completa: Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 em diante
Exemplo de configuração de CLI - Números de chamada
! voice class e164-pattern-map 1 description E164 Pattern Map for calling numbers e164 919574100. e164 919574300. e164 8675309 ! dial-peer voice 1 voip description INBOUND Dial-peer based on CALLING # incoming calling e164-pattern-map 1 !
dial-peer voice 11 voip
description OUTBOUND Dial-peer based on CALLING #
destination calling e164-pattern-map 1
!
Exemplo de configuração CLI - Número chamado
! voice class e164-pattern-map 2 description E164 Pattern Map for called 800 numbers e164 91800T e164 91855T e164 91888T ! dial-peer voice 2 voip description INBOUND Dial-peer based on CALLED # incoming called e164-pattern-map 2 ! dial-peer voice 22 voip description OUTBOUND Dial-peer based on CALLED # destination e164-pattern-map 2 !
Exemplo de configuração de Flash
! voice class e164-pattern-map <tag> description FILEPATH for E164 Pattern Map url flash:<filepath>/e164-pattern-list.cfg ! dial-peer voice ### voip description E164 Pattern Map Dial-peer incoming calling e164-pattern-map <tag> !
voice class e164-pattern-map load
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
ID de bug da Cisco 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 quando você usa o comando hunt-scheme round-robin. Grupos de servidores foram adicionados no Cisco IOS 15.4(1)T e no Cisco IOS XE 3.11S. No Cisco IOS XE 17.4.1um código de erro de huntstop configurável foi adicionado às configurações de grupo de servidor de classe de voz. Ou seja, você pode configurar um único código de erro, digamos 404 Não encontrado, e o erro SIP normalmente acionaria o dispositivo para tentar a próxima opção no grupo de servidores. Com a configuração huntstop 1 resp-code 404 no lugar dentro do grupo de servidores, a caça pode parar. Eles também podem ser configurados para um intervalo como: huntstop 1 resp-code 401 a 599.
Observação: o número máximo de entradas é 5 por grupo de servidores.
Documentação completa: Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 em diante
Exemplo de configuração - Normal
! voice class server-group 1 hunt-scheme round-robin ipv4 10.50.244.2 port 5060 preference 1 ipv4 10.50.244.62
ipv6 2010:AB8:0:2::1 port 2323 preference 3
ipv6 2010:AB8:0:2::2 port 2222 ! dial-peer voice 1 voip session protocol sipv2
destination-pattern 8675309 session server-group 1 !
Verificação
Gateway# show voice class server-group 1 Voice class server-group: 1 AdminStatus: Up OperStatus: Up
Hunt-Scheme: round-robin Last returned server:
Description:
Total server entries: 4
Pref Type IP Address IP Port
---- ---- ---------- -------
1 ipv4 10.50.244.2 5060
0 ipv4 10.50.244.62
3 ipv6 2010:AB8:0:2::1 2323
0 ipv6 2010:AB8:0:2::2 2222
[..truncated..]
Grupo de servidores de destino e manutenção de atividade de OPÇÕES
Lembre-se de que os grupos de servidores não seguem os mecanismos normais de manutenção de atividade de OPÇÕES fora do diálogo. Eles utilizam um recurso chamado perfil option-keepalive. Isso permite que o gateway monitore cada agente de chamada definido no grupo de servidores específico.
Exemplo de manutenção de atividade opcional com grupo de servidores
! voice class server-group 1 hunt-scheme round-robin ipv4 10.50.244.2 ipv4 10.50.244.62 ! dial-peer voice 1 voip session protocol sipv2 session server-group 1 voice-class sip options-keepalive profile 1 !
Verificação
Gateway# show voice class sip-options-keepalive 1 Voice class sip-options-keepalive: 1 AdminStat: Up Description: Transport: system Sip Profiles: 0 Interval(seconds) Up: 5 Down: 5 Retry: 5 Peer Tag Server Group OOD SessID OOD Stat IfIndex -------- ------------ ---------- -------- ------- 1 1 Active 87 Server Group: 1 OOD Stat: Active OOD SessID OOD Stat ---------- -------- 1 Active 2 Active OOD SessID: 1 OOD Stat: Active Target: ipv4:10.50.244.2 Transport: system Sip Profiles: 0 OOD SessID: 2 OOD Stat: Active Target: ipv4:10.50.244.62 Transport: system Sip Profiles: 0
Proxy de saída
A configuração do Proxy de Saída SIP pode ser adicionada às configurações de voip de serviço de voz, locatário de classe de voz ou peer de discagem para especificar o destino de um Pacote SIP de Camada 3.
Ou seja, o destino da sessão em um peer de discagem pode ser usado para criar o Pacote SIP, mas o proxy de saída pode ser o local para onde o pacote é enviado na Camada 3.
!
voice service voip
sip
outbound-proxy dns:la01.sipconnect-us10.cisco-bcld.com
!
voice class tenant 100
outbound-proxy dns:la01.sipconnect-us10.cisco-bcld.com
!
dial-peer voice 100 voip
session target ipv4:192.168.1.1
voice-class sip outbound-proxy dns:la01.sipconnect-us10.cisco-bcld.com
!
Pode-se observar que a configuração padrão para um peer de discagem é o sistema de proxy de saída sip de classe de voz, que pode fazer com que um peer de discagem use a configuração voip > sip do serviço de voz global.
Esse comportamento pode ser desativado e forçar um peer de discagem a recuar e usar o destino da sessão como o destino da camada 3 por peer de discagem com esta configuração:
dial-peer voice 777 voip
no voice-class sip outbound-proxy
Grupos de Troncos POTS
Os grupos de troncos são um conjunto de portas de voz físicas com recursos de sinalização semelhantes. Esse é um recurso que pode ser empregado para reduzir o número total de peers de discagem POTS que precisam ser configurados. Os grupos de tronco foram introduzidos no IOS na versão 12.1(3)T e estão presentes em todas as versões do Cisco IOS XE.
Documentação completa: aprimoramentos de tronco de gateway e roteamento baseado em operadora
Exemplo de configuração
! trunk group PSTN description PSTN voice-ports !
trunk group FXO
description FXO voice-ports
! voice-port 0/2/0 trunk-group PSTN 1 ! voice-port 0/2/1 trunk-group PSTN 2 !
voice-port 0/2/2
trunk-group FXO 1
!
voice-port 0/2/3
trunk-group FXO 2
! dial-peer voice 1234 pots trunkgroup PSTN 1 trunkgroup FXO 2 !
Locatários da Classe de Voz
O Cisco IOS 15.6(2)T e o Cisco IOS XE 16.3.1 introduziram locatários de classe de voz que permitem que cada locatário tenha suas próprias configurações individuais. Um locatário pode ser um provedor de telefonia, o Cisco Unified Communication Manager (CUCM) ou qualquer outro agente de chamadas de terceiros para o qual um administrador gostaria de ter configurações globais específicas. Primeiro, um administrador cria um espaço de classe de voz e define os parâmetros. O locatário de classe de voz é então aplicado ao peer de discagem ou escolha específica. Essa nova configuração dá aos administradores outro nível de controle sobre as chamadas além dos correspondentes de discagem e da configuração global.
Com a versão 17.8.1a, as configurações do locatário de classe de voz podem ser configuradas com um comando sip-listen (juntamente com o comando de vinculação de controle SIP apropriado) para definir a porta não segura ou segura desse locatário. Isso significa que o locatário 1 pode ouvir SIP não seguro em UDP 5060 + VRF Red, enquanto o locatário 2 ouve SIP em TCP TLS 5070 + VRF Blue. Após corresponder o espaço com base em listen-port + bind + dial-peers de entrada vrf opcionais são filtrados para aqueles que têm o espaço aplicado.
Documentação completa: Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 em diante
Ordem normal de preferência de comando sem espaços
- Comando dial peer
- Comando global (serviço de voz voip e sip-ua)
Ordem de preferência de comando com espaços
- comando dial peer
- Comando de locatário
- Comando global (serviço de voz voip e sip-ua)
Exemplo de configuração de multiusuário
Você tem dois espaços 777 e 999. Você os configurou com configurações ligeiramente diferentes e os aplicou aos peers de discagem. Isso significa que as chamadas que usam os diferentes peers de discagem têm as configurações baseadas no peer de discagem, bem como as configurações específicas do locatário. As opções listadas são apenas um trecho do poder dos locatários de classe de voz. Consulte a documentação para ver o que pode ser configurado em um espaço. É recomendável empregar mecanismos de correspondência estrita, como uri de classe de voz ou números de marcação com determinadas cadeias de caracteres de números para separar a correspondência do correspondente de discagem do locatário, ou mesmo configurar VRFs para que o Locatário A nunca se sobreponha ao Locatário B e corresponda acidentalmente a um correspondente de discagem que ele não pode.
!
voice class tenant 999 asymmetric payload full bind control source-interface GigabitEthernet0/0/0.228 bind media source-interface GigabitEthernet0/0/0.228 g729 annexb-all ! voice class tenant 777 sip-server ipv4:192.168.1.2 bind control source-interface Loopback0 bind media source-interface Loopback0 pass-thru content sdp ! dial-peer voice 999 voip destination-pattern 8675309 session protocol sipv2 incoming called-number 8675309 voice-class sip tenant 999 ! dial-peer voice 777 voip destination-pattern 8675309 session protocol sipv2 session target sip-server voice-class sip tenant 777 !
Verificação
Atualmente, não há comandos individuais para ver as configurações de locatário da classe de voz. Esse comando pode ser suficiente para filtrar a configuração atual apenas para as informações do espaço.
show run | sec tenant
Observação: o bug da Cisco ID CSCvf28730 é onde show sip-ua register status não reflete o status do registro de tronco SIP em um locatário de classe de voz.
O ILS URI chama o CUBE (string de rota de classe de voz)
As sequências de rota são usadas com o CUCM Intercluster Lookup Service (ILS) e podem ser configuradas para permitir que os Cisco Gateways roteiem chamadas VoIP através da sequência de rota incluída no convite SIP recebido de um CUCM 9.5+ executando o serviço ILS. Esse recurso foi adicionado no Cisco IOS 15.3(3)M e no Cisco IOS XE 3.10S. A maioria das conexões ILS é de CUCM para CUCM e os administradores não se preocupam em envolver um CUBE para entroncamento entre clusters. No entanto, se você precisar executar a função com CUBE no meio, as opções estarão lá. O CUCM precisa ter a configuração Send ILS Learned Destination Route String habilitada no perfil SIP aplicado ao tronco SIP para enviar o cabeçalho x-cisco-dest-route-string para o CUBE
Documentação completa: Enterprise Application Interoperability for H.323-to-SIP and SIP-to-SIP Configuration Guide, Cisco IOS Release 15M&T
Exemplo de configuração CUCM - SIP - CUBE - SIP - CUCM
!
voice service voip sip call-route dest-route-string ! voice class route-string rt1 pattern london.uk.eu ! voice class sip route-string rt2 pattern *.eu ! voice class sip-hdr-passthrulist hdr1 passthru-hdr x-cisco-dest-route-string ! dial-peer voice 1 voip description INBOUND dial-peer session protocol sipv2 voice-class sip pass-thru headers hdr1
incoming called-number .
! dial-peer voice 2 voip description OUTBOUND dial-peer destination route-string rt2 session protocol sipv2 session target ipv4:172.16.104.178 !
Verificação
show voice class route-string
Técnicas de roteamento de chamadas antigas
Os itens abordados nesta seção são considerados técnicas antigas. Embora a capacidade de configurá-los ainda esteja presente em um Cisco Gateway, não é recomendável usar esses comandos em configurações modernas. Este documento aborda apenas esses itens porque eles podem ser encontrados ao trabalhar com configurações herdadas ou ao executar atualizações.
Mapa de DNIS
Os mapas DNIS podem ser considerados o precursor do que seria agora um mapa padrão E164. Os mapas DNIS foram adicionados ao Cisco IOS na versão 12.2(2)XB e sempre existiram no Cisco IOS XE.
Se houver mapas DNIS configurados, valeria a pena convertê-los para o recurso de mapa de padrão e164 mais robusto.
Sintaxe de comando: Referência de comando de voz do Cisco IOS - D a I
Exemplo de configuração
! voice dnis-map 34 dnis 8675309 ! dial-peer voice 88 voip dnis-map 34 !
Rótulos do Grupo de Troncos
Os rótulos do grupo de troncos foram adicionados ao Cisco IOS 12.2(11)T e existem em todas as versões do Cisco IOS XE. A finalidade de um trunk-group-label é semelhante a um Carrier-ID no sentido de que pode ser usado para aumentar a correspondência de peers de discagem. Ele está disponível para configuração em grupos de troncos POTS, peers de discagem VOIP e POTS, bem como grupos de origem de voz. O uso de Rótulos de Grupo de Troncos é raramente visto em configurações modernas do Cisco Gateway.
Sintaxe do comando: Referência do comando de voz do Cisco IOS - T a Z
Exemplo de configuração
! dial-peer voice 112 pots trunk-group-label source north3 trunk-group-label target east17 !
Tipo de Numeração
Com integrações ISDN Q.931, existe a capacidade de corresponder um peer de discagem com base no número chamado ou chamador, bem como o tipo de número ITU específico da mensagem CONFIGURAÇÃO Q.931. Isso é configurável através do comando numbering-type em um peer de discagem VOIP ou POTS. O tipo de numeração não pode ser usado sozinho e deve ser usado em conjunto com destination-pattern, answer-address ou incoming called-number. Isso significa que tanto a condição da instrução de correspondência de entrada/saída quanto o tipo de número devem ser correspondentes para que o peer de discagem seja considerado para o roteamento de chamadas de entrada e de saída.
A correspondência de numeração pode ser pensada como um mecanismo de filtragem de peer de discagem, em vez de um mecanismo de correspondência. Isso ocorre porque um peer de discagem com e sem um comando de tipo de numeração aplicado será considerado o mesmo peso de preferência padrão se nenhuma preferência de administrador for aplicada. Isso é diferente de carrier-id que, quando aplicado a um peer de discagem ao lado de outro mecanismo de correspondência, adiciona preferência a esse peer de discagem sobre outros se ambas as condições forem verdadeiras.
A correspondência de tipo de numeração foi adicionada no Cisco IOS 12.0(7)XR1 e está presente em todas as versões do Cisco IOS XE. Com o declínio das linhas ISDN POTS tradicionais sendo implantadas em redes de colaboração, o uso do tipo de numeração raramente é visto em implantações modernas.
Sintaxe do comando: Referência do comando de voz do Cisco IOS - K a R
Exemplo de configuração
Esse peer de discagem pode corresponder 4085150000 através do 4085159999 somente se o tipo de número ISDN for National (Nacional).
! dial-peer voice 408 voip numbering-type national destination-pattern 408515.... session target ipv4:10.1.1.2 !
Tipos de números possíveis:
| 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 atendimento |
| 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 de Peer de Discagem
Os peers de discagem de dados foram introduzidos no Cisco IOS 12.2(13)T e o uso desses peers de discagem foi para chamadas de modem de dados de entrada em um gateway Cisco. Esse peer de discagem deve ser usado somente na direção de entrada e raramente é visto em implantações modernas.
Sintaxe de comando: Referência de comando de voz do Cisco IOS - D a I
Exemplo de configuração
! dial-peer data 100 pots incoming called-number 100 !
Grupo de origem de voz
Este recurso foi adicionado na versão 15.1(2)T, mas não é implementado em muitas implantações modernas. Outros métodos de segurança para IOS/CUBE geralmente são implantados.
A visão geral da segurança de aplicativos do CUBE pode ser vista neste white paper a partir da seção 4.2.
Especificação de gerenciamento e capacidade de gerenciamento do Cisco Unified Border Element (CUBE)
Sintaxe do comando: recurso Grupo de origem de voz
Permissões de Peer de Discagem
Essa configuração permite que um administrador restrinja um peer de discagem para permitir somente conexões de entrada (termo / término) ou conexões de saída (origem / origem). Isso seria como configurar explicitamente um peer de discagem de entrada para ser usado apenas para chamadas de entrada e um peer de discagem de saída para chamadas de saída. O padrão para qualquer peer de discagem é permitir conexões de entrada e de saída. Esta CLI não é frequentemente implantada em implantações modernas.
Router(config)# dial-peer voice 1 voip
Router(config-dial-peer)# permission ?
both allow both orig/term on this dialpeer
none no orig/term allowed on this dialpeer
orig allow only orig on this dialpeer
term allow only term on this dialpeer
URI e manipulação de dígitos
Em algum ponto de uma implantação de colaboração, um administrador pode precisar manipular dígitos ou um cabeçalho URI/SIP. Os gateways Cisco têm vários métodos para manipulação de dígitos que permitem que um administrador controle completo sobre como e quando um dígito pode ser manipulado. No entanto, isso nem sempre é fácil e algumas pessoas ficam sobrecarregadas com as diferentes opções ou o administrador não sabe que uma opção existe.
Manipulação de dígitos via correspondentes de discagem POTS
Os peers de discagem POTS têm algumas técnicas exclusivas de manipulação de dígitos que os peers de discagem VOIP não têm.
A primeira é a remoção de dígitos justificados à esquerda explicitamente definidos em um padrão de destino. Isso pode ser desativado usando o comando no digit-strip no peer de discagem POTS.
Exemplo:
Neste exemplo, 9011T é definido como a string para o padrão de destino.
Com isso estabelecido, você pode receber uma chamada para 90113227045555. Isso corresponde ao peer de discagem para roteamento de chamada de saída, e os dígitos explicitamente definidos de 9011 são removidos antes que a chamada seja roteada pela porta de voz.
! dial-peer voice 1 pots destination-pattern 9011T port 0/0/0:23 !
Este exemplo mostra uma configuração sem faixa de dígitos no lugar.
Se o mesmo número for chamado, o 9011 será enviado .
! dial-peer voice 1 pots destination-pattern 9011T port 0/0/0:23
no digit-strip !
O segundo é a capacidade de especificar quantos dígitos você gostaria de encaminhar no peer de discagem POTS.
Tome este exemplo onde você recebe uma chamada para 918005532447 do CUCM. Nessa situação, você deseja remover o 9, mas enviar o restante do número começando com o 1.
Se você configurar o comando forward-digits no peer de discagem POTS, você poderá especificar exatamente quantos dígitos enviará.
! dial-peer voice 1 pots destination-pattern 918005532447 forward-digits 11 port 0/2/0 !
Por fim, os peers de discagem POTS podem usar o comando prefix para adicionar dígitos a uma chamada antes de rotear a porta de voz. Este exemplo retira o 91 explicitamente definido e o prefixo 007 para o número antes de enviar a chamada pela porta de voz.
! dial-peer voice 1 pots destination-pattern 91T prefix 007 port 0/1/0:15 !
Manipulação de dígitos através de regras e perfis de conversão de voz
As regras de conversão de voz são expressões regulares (regex) usadas para transformar dígitos. As regras de conversão e os perfis foram adicionados ao Cisco IOS na versão 12.0(7)XR1. Uma regra de conversão é aplicada aos perfis de conversão de voz que são aplicados a um correspondente de discagem ou porta de voz. As regras de conversão contêm uma entrada de correspondência e uma saída de modificação. Juntamente com a entrada de correspondência no número, há uma entrada de correspondência e modificação para o plano e o tipo de ISDN. A combinação de string de número de correspondência, plano e tipo é considerada uma correspondência. Isso significa que todas as entradas de correspondência definidas devem ser verdadeiras para que a conversão ocorra.
As regras de conversão têm a capacidade de alterar Chamada, Chamada, chamada de redirecionamento, destino de redirecionamento e número de retorno de chamada nos protocolos de sinalização ISDN, SIP e H323. As regras de tradução combinam com base em uma pesquisa de cima para baixo, portanto, a ordem das regras é de extrema importância. Se uma correspondência for encontrada em uma regra superior, o gateway interromperá imediatamente a pesquisa e processará a conversão. As regras de conversão não podem alterar cabeçalhos sip não numéricos, como testuser@10.10.10.10. Para essa manipulação, utilize um perfil SIP.
As regras de transição podem ser usadas para bloquear chamadas nos Cisco Gateways.
Preferência de seleção de perfil de tradução
- Perfil de conversão de voz de entrada na porta de voz
- Perfil de conversão de voz de entrada no Grupo de Troncos aplicado à Interface Serial
- Incoming voice translation-profile no peer de discagem de entrada
- Perfil de conversão de voz de entrada definido através de portas de serviço de voz
- Perfil de conversão de voz de entrada definido via 'voip-incoming translation-profile' global
- Perfil de tradução de voz de saída definido através de portas de serviço de voz
- Outbound voice translation-profile ou translate-outgoing no dial-peer 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 dial-peer regex e as regras de conversão de curingas têm seus próprios caracteres regex.
| Caractere |
Definição |
| * | Quando usado em regras de tradução, este é o 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 conversão \( \) |
| e |
O E comercial é usado para trazer qualquer item correspondente no conjunto de correspondência inicial do conjunto de modificação |
| ( ) |
Os itens entre parênteses são considerados um conjunto. |
| ^ | Define o início explícito de uma string. Diferentemente dos peers de discagem, as regras de conversão não definem o início da string. Isso significa definir uma string sem um ^ pode ser uma correspondência possível em qualquer lugar na string de entrada, o que pode levar a traduções indesejadas no meio de um número. |
Conjuntos de Modificação
- Os conjuntos são especificados como \0, \1, \2 e assim por diante.
- \0 corresponde a qualquer item entre o primeiro conjunto de correspondências. Isso também pode ser feito através de um caractere de E comercial: &.
- \1 corresponde ao primeiro conjunto de ( ) no conjunto de correspondência
- \2 corresponde ao segundo conjunto de ( ) no conjunto de correspondência
- E assim por diante.
Exemplo de regra de tradução com dois conjuntos
Neste exemplo, você pode examinar o número 000111000222.
Você deseja remover os 0s do número e obter um número final de 111222.
Para fazer isso, configure os conjuntos 1 e 2 para capturar o 111 e o 222, respectivamente, enquanto solta os 0s.
! voice translation-rule 333 rule 1 /000\(111\)000\(222\)/ /\1\2/ ! voice translation-profile SET-EXAMPLE translate called 333 ! Gateway# test voice translation-rule 333 000111000222 Matched with rule 1 Original number: 000111000222 Translated number: 111222 Original number type: none Translated number type: none Original number plan: none Translated number plan: none
Exemplo para retirar o padrão de discagem externa 9 de um número chamado
! voice translation-rule 9 rule 1 /^9\(.*\)/ /\1/ ! voice translation-profile STRIP-9 translate called 9 ! dial-peer voice 9 voip translation-profile outgoing STRIP-9 ! voice-port 0/0/0 translation-profile outgoing STRIP-9 ! Gateway# test voice translation-rule 9 918675309 Matched with rule 1 Original number: 918675309 Translated number: 18675309 Original number type: none Translated number type: none Original number plan: none Translated number plan: none
Truncar o número chamado para 4 dígitos
! voice translation-rule 4 rule 1 /.*\(....\)/ /\1/ ! voice translation-profile STRIP-TO-4 translate called 4 ! Gateway# test voice translation-rule 4 8675309 Matched with rule 1 Original number: 8675309 Translated number: 5309 Original number type: none Translated number type: none Original number plan: none Translated number plan: none
Remoção do sinal de mais + do número chamado
! voice translation-rule 999 rule 1 /\+\(.*\)/ /\1/ ! voice translation-profile STRIP-PLUS translate called 999 ! Gateway# test voice translation-rule 999 +8675309 Matched with rule 1 Original number: +8675309 Translated number: 8675309 Original number type: none Translated number type: none Original number plan: none Translated number plan: none
As regras de tradução também podem ser aplicadas diretamente a um peer de discagem sem primeiro serem aplicadas a um perfil de tradução.
! voice translation-rule 1 rule 1 /1234/ /8678309/ ! voice translation-rule 2 rule 2 /^4...$/ /1408515\0/ ! dial-peer voice 1 voip translate-outgoing called 1 ! dial-peer voice 2 voip translate-outgoing calling 2 !
Perfil de Tradução no Grupo de Troncos
! trunk group <name> translation-profile incoming <profile-name> translation-profile outgoing <profile-name> !
Depurar regras e perfis de conversão de voz
debug voip ccapi inout debug voice translation debug dialpeer test voice translation-rule <number> <string> type <type> plan <plan>
Voice Class e164-translation
O recurso de conversão de voz classe e164 é um recurso mais recente do Cisco IOS XE que permite que um administrador crie uma lista de instruções de correspondência e modifique as instruções a serem carregadas através de um arquivo de configuração da flash ou de um diretório de rede. Isso é semelhante ao conceito para o recurso e164-pattern-map discutido neste documento. Isso permite que um administrador configure até 100 conversões dentro de um arquivo de configuração e as aplique em um único perfil de conversões. Para obter mais informações, consulte a Referência de Comandos de Voz do Cisco IOS
Siga esta sintaxe para o arquivo .cfg:
pattern1_to_be_matched<tab>replaced_pattern<space><enter> pattern1_to_be_matched<tab>replaced_pattern<space><enter>
Observação: o espaço à direita é muito importante, e a importação pode falhar sem essa etapa de formatação extra.
Exemplo.cfg
+111111 8897 +222222 8312 928747 +123456789 737362 +987654321
Esse arquivo então faz referência como:
voice class e164-translation 164 url ftp://username:password@10.10.10.10/sample.cfg
Agora você aplica a um perfil de tradução normalmente e, a partir daí, aplica-se a correspondentes de discagem usando a sintaxe de perfil de tradução normal.
voice translation-profile e164 translate calling voice-class e164-translation 164 translate called voice-class e164-translation 164
O comando show voice class e164-translation e164-translation-number pode ser usado para exibir o conteúdo do perfil de conversão.
Manipulação de dígitos via mapas ISDN
MAPS ISDN são uma técnica mais antiga para modificar dígitos. Isso foi adicionado no Cisco IOS 12.0(6)T e a maioria das novas configurações não utiliza esse recurso, pois não são tão robustas quanto regras e perfis de conversão de voz. Os mapas ISDN são definidos na interface serial.
Exemplo de configuração
Serial0/0/0:23 isdn map address ^911 plan isdn type unknown isdn map address ^1.......... plan isdn type national isdn map address ^2......... plan isdn type national isdn map address ^3......... plan isdn type national isdn map address ^4......... plan isdn type national isdn map address ^5......... plan isdn type national isdn map address ^6......... plan isdn type national isdn map address ^7......... plan isdn type national isdn map address ^8......... plan isdn type national isdn map address ^9......... plan isdn type national
Manipulação de Dígitos via Expansão de Número (num-exp)
Como os mapas ISDN, a expansão de números é uma técnica mais antiga adicionada ao Cisco IOS 11.3(1)T e pouco usada em redes novas. Este recurso foi adicionado antes de existirem regras e perfis de conversão de voz. A expansão de número é uma alteração global de dígitos aplicada a todos os correspondentes de discagem em um gateway Cisco. A modificação é aplicada ao número chamado após a correspondência do correspondente de discagem e imediatamente antes do envio da chamada para o próximo agente de chamada.
Exemplo de configuração
num-exp 4... 18005554...
num-exp 1234 8675309
Perfis SIP de entrada/saída
Os perfis SIP são instruções de Correspondência de Expressão Regular (regex) robustas que permitem que um administrador altere qualquer aspecto de uma mensagem SIP que inclua cabeçalhos SDP e SIP. Eles podem ser ativados globalmente, por peer de discagem ou por locatário. Os perfis SIP estão disponíveis para modificações de entrada começando com o Cisco IOS 15.4(2)T e o Cisco IOS XE 3.12S . Como os perfis SIP são tão robustos, este documento aborda apenas alguns exemplos específicos. Os perfis SIP também adicionam a capacidade de os cabeçalhos SIP personalizados serem modificados ou adicionados no IOS 15.5(2)T e no IOS-XE 3.13S.
Pontos principais sobre perfis SIP de entrada versus de saída
- Os perfis SIP de entrada alteram a mensagem ANTES que o CUBE processe a mensagem para roteamento de chamada.
- Os perfis SIP de saída alteram a mensagem DEPOIS que o CUBE processa o roteamento de chamadas e antes que a mensagem seja enviada para o próximo salto.
Outras observações sobre a configuração sip-profile:
- Os perfis SIP não podem manipular atributos SDP m=image. A melhoria para isso foi arquivada sob a ID de bug Cisco CSCsr20474 Além disso, os perfis SIP não podem remover ou adicionar valores ao SDP. Somente você pode modificar esses valores. No entanto, é possível modificar um valor SDP para um valor nulo especificando o valor inteiro e, em seguida, definindo a saída para um conjunto de aspas vazias sem espaço.
- Não há verificações realizadas para ver se o comando atual sendo inserido já existe ou se uma versão desse comando já existe ao inserir comandos dentro da classe de voz sip-profile. Se um administrador colar uma linha 7 vezes em um perfil sip, ele exibirá 7 vezes a configuração atual. Recomenda-se remover o comando que está sendo modificado e, em seguida, inserir o novo comando ao editar perfis sip para evitar a presença de vários comandos.
Documentação completa: Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 em diante
Ferramenta de teste de perfil SIP: Ferramenta de teste de perfil SIP
Exemplo de Sintaxe de Perfil SIP de Entrada/Saída
! voice class sip-profiles <number> request <message-type> sip-header <header> modify "match-pattern" "replace-pattern" request <message-type> sip-header <header> add "add-pattern" request <message-type> sip-header <header> remove
request <message-type> sdp-header <header> modify "match-pattern" "replace-pattern" request <message-type> sdp-header <header> add "add-pattern" request <message-type> sdp-header <header> remove
response <number> sip-header <header> modify "match-pattern" "replace-pattern" response <number> sip-header <header> add "add-pattern" response <number> sip-header <header> remove
response <number> sdp-header <header> modify "match-pattern" "replace-pattern" response <number> sdp-header <header> add "add-pattern" response <number> sdp-header <header> remove !
Exemplo de Perfil SIP de Entrada/Saída com Números
voice class sip-profiles 200
rule 1 response ANY sip-header Remote-Party-ID modify "match-pattern" "replace-pattern" rule 2 response ANY sdp-header Audio-Attribute modify "match-pattern" "replace-pattern"
Métodos de Aplicação do Perfil SIP de Saída
! Global Application voice service voip sip sip-profiles <number> !
! Tenant Application
voice class tenant <tag>
sip-profiles <tag>
!
! Dial-peer Application
dial-peer voice <tag> voip
voice-class sip profiles <number>
!
Métodos de Aplicação do Perfil SIP de Entrada
Observação: é necessário habilitar a entrada do perfil sip no serviço de voz voip sip se o aplicativo global, o locatário ou o aplicativo de peer de discagem for usado.
! Global Application voice service voip sip sip-profiles inbound sip-profiles <number> inbound !
! Tenant Application
voice service voip
sip
sip-profiles inbound
! voice class tenant <tag>
sip-profiles <tag> inbound
!
! Dial-Peer Application
voice service voip
sip
sip-profiles inbound
! dial-peer voice <tag> voip voice-class sip profiles <number> inbound !
Exemplo de perfil SIP para modificar mensagens de keepalive OPTIONS.
!
voice class sip-options-keepalive 200
transport tcp tls
sip-profiles 299
!
Perfil SIP de Exemplo para modificar Host, Domínio ou ambas as partes de um URI.
! Host ! voice class sip-profiles 1 request ANY sip-header Contact modify "sip:(.*)@" "sip:8675309@" ! ! Domain ! voice class sip-profiles 2 request ANY sip-header Contact modify "10.67.138.241:5060" "cisco.com" ! ! Note: Port is optional ! ! Modify Both User and Host ! voice class sip-profiles 3 request ANY sip-header Contact modify "sip:(.*)>" "sip:8675309@cisco.com>" !
Perfil SIP de Exemplo para adicionar, modificar ou remover cabeçalhos de Desvio.
! Add ! voice class sip-profiles 777 request INVITE sip-header Diversion add "Diversion: <sip:1234@cisco.com>" ! ! ! Modify ! voice class sip-profiles 888 request INVITE sip-header Diversion modify "sip:(.*)>" "sip:1234@cisco.com>" ! ! ! Remove ! voice class sip-profiles 999 request INVITE sip-header Diversion remove !
Perfil SIP de exemplo para modificar a parte do nome do ID do chamador dos cabeçalhos SIP.
! voice class sip-profiles 123 request INVITE sip-header From modify "\".*\"" "\"TEST CLID*\"" !
Exemplo de perfil SIP para alterar uma sessão 183 em andamento para um toque 180.
! voice class sip-profiles 789 response 183 sip-header SIP-StatusLine modify "SIP/2.0 183 Session in Progress" "SIP/2.0 180 Ringing" !
Exemplo de perfil SIP para interoperabilidade de áudio unidirecional ou não-unidirecional com um provedor.
!
voice class sip-profiles 200 request ANY sdp-header Audio-Attribute modify "a=inactive" "a=sendrecv" request ANY sdp-header Audio-Connection-Info modify "0.0.0.0" "10.10.10.10"
!
! where 10.10.10.10 is CUBE's provider facing IP address
Perfil SIP de exemplo para remover o método UPDATE para problemas de interoperabilidade.
!
voice class sip-profiles 200
request ANY sip-header Allow-Header modify ", UPDATE" ""
!
Exemplo de perfil SIP mostrando o uso do SET dentro do perfil SIP. Esse é o mesmo conceito de Conjuntos descritos na seção voice translation-rule.
!
voice class sip-profiles 1 request ANY sip-header Contact modify "sip:(.*)@" "sip:\1@"
!
A configuração da lógica IF e quebras de nova linha com um perfil SIP.
As quebras de nova linha são suportadas em perfis SIP, no entanto, há apenas um caso de uso muito específico para eles. Como os perfis SIP não têm nenhuma lógica If, Then, Else, agora há uma maneira de executar modificações em um cabeçalho com base em uma entrada de outro cabeçalho. Por exemplo, um administrador só deseja modificar um cabeçalho de desvio se o cabeçalho FROM contiver 1234@cisco.com. Utilizando a quebra de nova linha, podemos falsificar a instrução IF em um perfil SIP. Consulte o exemplo de configuração: Você pode corresponder a 1234 em qualquer domínio no cabeçalho De. Em seguida, traga o primeiro conjunto e adicione uma nova quebra de linha \x0D\x0AD. Finalmente, você adiciona o cabeçalho desejado. Veja que esse método permite apenas ADICIONAR um cabeçalho. Não há como modificar outro cabeçalho. Assim, isso atende apenas parcialmente aos requisitos que um administrador desejava atingir anteriormente.
!
voice class sip-profiles 1 request INVITE sip-header From modify “(.*sip:1234@.*)” “\1\x0D\x0ADiversion: <sip:5678@example.com>” !
Exemplo de perfil SIP com lógica OR.
!
voice class sip-profiles 123 request ANY sdp-header Audio-Attribute modify "(a=sendonly|a=recvonly|a=inactive)" "a=sendrecv" response ANY sdp-header Audio-Attribute modify "(a=sendonly|a=recvonly|a=inactive)" "a=sendrecv" !
Exemplo de Inspeção SIP de Camada 7 via Perfil SIP.
### Usage 10.21.15.10 replace with private IP of CUBE a.b.c.d replace with public IP ------------------------------------------------------ ### Inbound from ITSP Layer 7 Fixup !
voice class sip-profiles 888 request INVITE sip-header SIP-Req-URI modify "@.*;" "@10.21.15.100;" ! voice service voip sip sip-profiles inbound ! ### Outbound Layer 7 Fixup ! voice class sip-profiles 777 request ANY sip-header Contact modify "<sip:(.*)@10.21.15.100:5060>" "<sip:\1 a.b.c.d:5060>" response ANY sip-header Contact modify "<sip:(.*)@10.21.15.100:5060>" "<sip:\1 a.b.c.d:5060>" request ANY sip-header Via modify "SIP(.*) 10.21.15.100(.*)" "SIP\1 a.b.c.d\2" request ANY sdp-header Session-Owner modify "(.*IP4 ).*" "\1a.b.c.d" request ANY sdp-header Connection-Info modify "IN IP4 10.21.15.100" "IN IP4 a.b.c.d" request ANY sdp-header Audio-Connection-Info modify "IN IP4 10.21.15.100" "IN IP4 a.b.c.d" response ANY sdp-header Session-Owner modify "(.*IP4 ).*" "\1a.b.c.d" response ANY sdp-header Audio-Connection-Info modify "IN IP4 10.21.15.100" "IN IP4 a.b.c.d" response ANY sdp-header Connection-Info modify "IN IP4 10.21.15.100" "IN IP4 a.b.c.d" request ANY sip-header Remote-Party-ID modify "<sip:(.*)@10.21.15.100>" "<sip:\1 a.b.c.d>" response ANY sip-header Remote-Party-ID modify "<sip:(.*)@10.21.15.100>" "<sip:\1 a.b.c.d>" !
### Apply to dial-peers for the side of the CUBE facing the ITSP
!
dial-peer voice 1 voip
voice-class sip profiles 777
voice-class sip profile 888 inbound
!
dial-peer voice 2 voip
voice-class sip profiles 777
voice-class sip profile 888 inbound
!
Lista de cópias SIP
As Listas de Cópias SIP são uma extensão dos Perfis SIP que permitem que o gateway COPIE um cabeçalho do trecho interno de uma chamada e, em seguida, COLE em outro ponto da mensagem SIP de saída no trecho externo. O suporte à lista de cópias SIP foi adicionado no Cisco IOS 15.1(3)T e no Cisco IOS XE 3.6S. Essa é uma maneira muito eficiente de criar cabeçalhos dinâmicos com base em outros cabeçalhos da parte interna da chamada.
O caso de uso mais comum é copiar dinamicamente um cabeçalho FROM para um cabeçalho diferente, como desvio ou p-asserted-id, de modo que o valor da parte do usuário seja o do usuário. Isso é feito principalmente para fins de autenticação, bem como para fins de identificação do chamador.
Documentação completa: Cisco Unified Border Element Configuration Guide - Cisco IOS XE 17.6 em diante
Exemplo de lista de cópia SIP
! ! Create Copylist to copy the FROM header on the inbound message specified later. ! voice class sip-copylist <number> sip-header From ! ! Apply this to the inbound dial-peer of the call. ! dial-peer voice <tag> voip voice-class sip copy-list <number> ! ! Create SIP Profile to take From (peer-header) stored as variable "u01" and apply to a header of choice. ! This example modifies the user portion of the Contact by copying the user portion of the From header to the user portion of the Contact header. ! voice class sip-profiles <number> request INVITE peer-header sip From copy "<sip:(.*)@" u01 request INVITE sip-header Contact modify "<sip:(.*)>" "<sip:\u01@10.50.244.2>" ! ! Apply the SIP profile to an outbound dial-peer ! dial-peer voice <tag> voip voice-class sip profiles <number>
!
Depurando perfis SIP e lista de cópia
debug voip ccapi inout debug ccsip mess debug ccsip info debug ccsip feature sip-profile
Saída de depuração da lista de cópia SIP de exemplo
### Ingress from CUCM Received: INVITE sip:1001@10.50.228.61:5060 SIP/2.0 Via: SIP/2.0/TCP 10.50.244.3:5060;branch=z9hG4bKaad21bc3ae7e From: "5001" <sip:5001@10.50.244.3>;tag=100442~cdffff43-5020-4e79-a10b-99d406971010-36470319 Contact: <sip:5001@10.50.244.3:5060;transport=tcp> ### Copylist Details 00440: Mar 8 18:59:49.796: //-1/xxxxxxxxxxxx/SIP/Info/info/64/sip_profiles_application_peer_copy_pattern: sed_match succeeded 000441: Mar 8 18:59:49.797: //187/D6138E000000/SIP/Info/info/64/sip_profiles_application_peer_copy_pattern: SIP Profiles COPY variables AVL tree created 000442: Mar 8 18:59:49.797: //-1/xxxxxxxxxxxx/SIP/Info/info/64/sip_profiles_prefix_slash_in_copy_var_val: ret_dst: 5001 000443: Mar 8 18:59:49.797: //187/D6138E000000/SIP/Info/info/64/sip_profiles_application_peer_copy_pattern: SIP Profiles COPY variable: u1 val: 5001 000444: Mar 8 18:59:49.797: //-1/xxxxxxxxxxxx/SIP/Info/info/64/sip_profiles_application_modify_remove_header: Header before modification : Contact: <sip:5001@10.50.228.61:5060> 000445: Mar 8 18:59:49.797: //187/D6138E000000/SIP/Info/info/64/sip_profiles_check_and_get_variables_in_replace_pattern: Node found: COPY variable: u1 val: 5001 000446: Mar 8 18:59:49.797: //187/D6138E000000/SIP/Info/info/64/sip_profiles_check_and_get_variables_in_replace_pattern: substituted_replace_pattern : : @168.117.64.94> 000448: Mar 8 18:59:49.797: //187/D6138E000000/SIP/Info/info/64/sip_profiles_check_and_get_variables_in_replace_pattern: Final substituted_replace_pattern : <sip:5001@168.117.64.94> 000449: Mar 8 18:59:49.797: //-1/xxxxxxxxxxxx/SIP/Info/info/64/sip_profiles_app_modify_header: Passing substituted replace pattern 000450: Mar 8 18:59:49.798: //-1/xxxxxxxxxxxx/SIP/Info/info/64/sip_profiles_application_modify_remove_header: Header after modification : Contact: <sip:5001@168.117.64.94> 000451: Mar 8 18:59:49.798: //187/D6138E000000/SIP/Msg/ccsipDisplayMsg: ### Egress from CUBE Sent: INVITE sip:1001@14.50.228.63:5060 SIP/2.0 Via: SIP/2.0/UDP 10.50.228.61:5060;branch=z9hG4bK3C7CD Remote-Party-ID: "5001" <sip:5001@10.50.228.61>;party=calling;screen=yes;privacy=off From: "5001" <sip:5001@10.50.228.61>;tag=34C458-D6 Contact: <sip:5001@168.117.64.94>
Observações especiais
Sinalização de protocolo e vinculação de mídia
Todos os protocolos de sinalização permitem que os administradores associem a sinalização a uma interface específica. Por padrão, um gateway sem uma associação estática definida, o gateway origina a sinalização para uma chamada da interface física pela qual o pacote atravessa. Com a vinculação em um peer de discagem, o pacote apresenta cabeçalhos de origem, mensagens e pacotes da interface especificada, mas o pacote real ainda roteia pela interface física. A ligação de peer de discagem sempre substitui a ligação de voz de classe de locatário e serviço de voz global com o Session Initiation Protocol (SIP).
Muitas vezes, os administradores ligam a sinalização a um loopback. Ser uma interface lógica significa que nenhum pacote passa por essa interface. Para realizar capturas de pacotes, a captura deve ser realizada em uma interface física. O comando show ip cef <remote-ip> exibe a interface física que um pacote utiliza para rotear para o IP de destino/remoto, mesmo que a configuração esteja vinculada a uma interface virtual.
A ligação de mídia e sinalização nem sempre precisa ser o mesmo IP. Se um administrador precisa se vincular a uma interface específica para sinalização para/de um CUCM, mas o áudio/mídia entre o telefone e o gateway pode precisar se vincular a outra interface.
Exemplo de configuração
Este exemplo mostra um peer de discagem associado ao loopback 1 e recebe uma chamada do CUCM.
Mesmo que a mídia e a sinalização (controle) estejam vinculadas ao loopback 1, show ip cef mostra que todos os pacotes enviados ao CUCM deixam a interface física GigabitEthernet0/0/1.
! dial-peer voice 2 voip description "Incoming call from CUCM" session protocol sipv2 incoming called-number . voice-class sip bind control source-interface Loopback1 voice-class sip bind media source-interface Loopback1 !
Ordem de operações para vinculação de aplicação da camada 7
- De acordo com a instrução bind no peer de discagem de entrada/saída correspondente.
- De acordo com as associações sob o locatário da classe de voz atribuído ao correspondente de discagem de entrada/saída correspondente.
- De acordo com a declaração de vinculação global.
- De acordo com a interface física da camada 3, espera-se que o pacote saia baseado na tabela de roteamento.
Comandos de vinculação SIP
! Per Dial-peer
!
dial-peer voice 1 voip voice-class sip bind control source-interface <interface> voice-class sip bind media source-interface <interface> !
! Global Binding
! voice service voip sip bind control source-interface <interface> bind media source-interface <interface> !
Comandos de vinculação MGCP
!
mgcp bind control source-interface <interface> mgcp bind media source-interface <interface>
!
Comandos de vinculação SCCP
!
sccp local <interface> ! sccp ccm group <number> bind interface <interface> !
Comandos de vinculação H323
! inteface <interface> ! ! Media Bind Command: h323-gateway voip interface ! ! Signaling Bind Command: h323-gateway voip bind srcaddr <a.b.c.d> !
Peers de discagem DNS e VoIP
O DNS com VOIP é empregado como qualquer outra solução DNS. Uma configuração comum é utilizar o destino de sessão dns:FQDN.com.
Um gateway Cisco executa uma resolução DNS mesmo quando nenhuma pesquisa de domínio ip é configurada globalmente no gateway. Isso significa que mesmo que você esteja desabilitando o DNS, os peers de discagem VOIP ainda resolvem a entrada DNS. No entanto,Recentemente, no Cisco IOS XE 3.16S, houve algumas alterações na funcionalidade geral do DNS nas plataformas Cisco IOS XE.
Após essa alteração, os peers de discagem configurados com o destino da sessão dns:FQDN.com obedecem agora ao fato de que o DNS está desabilitado sem nenhuma pesquisa de domínio ip.
Recomendo sempre garantir que o comando "ip domain lookup" esteja configurado ao trabalhar com o DNS para evitar esse problema.
Para conexões SIP de saída, o CUBE executa essa ordem de operações para a resolução DNS.
- 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: Guia de configuração do Cisco Unified Border Element - Cisco IOS XE 17.6 em diante
Para conexões SIP de entrada em que um gateway IOS precisa resolver um cabeçalho para responder a uma mensagem, o gateway pode usar essa ordem de operações para Resolução DNS
- Uma Pesquisa de Registro
- Pesquisa de Registro AAAA
No Cisco IOS XE 17.9.1, o CUBE pode verificar a acessibilidade de destinos de sessão DNS por meio de mecanismos de manutenção de atividade de opções. Veja a documentação completa:
Guia de configuração do Cisco Unified Border Element - Cisco IOS XE 17.6 em diante
Amostras de configuração do IOS DNS
ip host _sip._udp.cucmgroup.lab.local srv 1 50 5060 cucm1.lab.local ip host _sip._udp.cucmgroup.lab.local srv 1 50 5060 cucm2.lab.local ip host _sip._udp.cucmgroup.lab.local srv 1 50 5060 cucm3.lab.local ip host cucm1.lab.local 10.0.0.1 ip host cucm2.lab.local 10.0.0.2 ip host cucm3.lab.local 10.0.0.3 ip domain name lab.local ip name-server 8.8.8.8
Observação: o suporte a DNS SRV no Cisco IOS XE é suportado no 15.6(1)S / 3.17.00.S e superior.
Depurações de DNS e comandos de verificação
show host clear host all * ! debug ip dns view debug ip domain debug ccsip info
debug ccsip error
Teste de DNS 3.15S e posterior
### Domain Name Verification
Gateway# sh run | s lookup
no ip domain lookup
### Checking the host table for no entry
Gateway# show host
Name lookup view: Global
Default domain is cisco.com
Name/address lookup uses static mappings
Codes: UN - unknown, EX - expired, OK - OK, ?? - revalidate
temp - temporary, perm - permanent
NA - Not Applicable None - Not defined
Host Port Flags Age Type Address(es)
### Verification of no PING on a FQDN
Gateway# ping cucm.cisco.com
Translating "cucm.cisco.com"
% Unrecognized host or address, or protocol not running.
### Made a test call here
### Checking logs to see if it worked
Gateway# sh log | s INVITE sip:
INVITE sip:9001@14.50.228.70:5060 SIP/2.0
INVITE sip:5001@cucm.cisco.com:5060 SIP/2.0
### Host Table now has an entry
Gateway# sh host
Name lookup view: Global
Default domain is cisco.com
Name/address lookup uses static mappings
Codes: UN - unknown, EX - expired, OK - OK, ?? - revalidate
temp - temporary, perm - permanent
NA - Not Applicable None - Not defined
Host Port Flags Age Type Address(es)
cucm.cisco.com None (temp, OK) 0 IP 10.50.244.2
### CCSIP All output showing a proper DNS Query for the FQDN on the dial-peer.
001338: Mar 9 15:29:07.437: //-1/xxxxxxxxxxxx/SIP/Info/info/1024/httpish_msg_free: Freed msg=0x7FE9873AE560
001339: Mar 9 15:29:07.437: //-1/xxxxxxxxxxxx/SIP/Info/notify/8192/sip_dns_type_srv_query: TYPE SRV query for _sip._udp.cucm.cisco.com and type:1
001340: Mar 9 15:29:07.438: //-1/xxxxxxxxxxxx/SIP/Info/info/8192/sip_dns_type_a_aaaa_query: DNS query for cucm.cisco.com and type:1
001341: Mar 9 15:29:07.441: //-1/xxxxxxxxxxxx/SIP/Info/notify/8192/sip_dns_type_a_query: TYPE A query successful for cucm.cisco.com
001342: Mar 9 15:29:07.441: //-1/xxxxxxxxxxxx/SIP/Info/info/8192/sip_dns_type_a_query: ttl for A records = 3600 seconds
001343: Mar 9 15:29:07.441: //-1/xxxxxxxxxxxx/SIP/Info/info/8192/sip_dns_type_a_aaaa_query: IP Address of cucm.cisco.com is:
001344: Mar 9 15:29:07.441: //-1/xxxxxxxxxxxx/SIP/Info/info/8192/sip_dns_type_a_aaaa_query: 10.50.244.2
Teste de DNS 3.16S e superior.
### Checking the command is present Gateway# sh run | s lookup no ip domain lookup ### Verifying the gateway cannot ping a FQDN Gateway# ping cucm.cisco.com % Unrecognized host or address, or protocol not running. ### Checking the Host Table for entries Gateway# sh host Default domain is cisco.com Name servers are 10.50.244.52 NAME TTL CLASS TYPE DATA/ADDRESS ----------------------------------------- ### Made a test call here ### CCSIP All Outbound showing the failed call 000974: *Mar 9 15:53:01.222: //-1/xxxxxxxxxxxx/SIP/Info/info/1024/httpish_msg_free: Freed msg=0x7FF31DAAA848 000975: *Mar 9 15:53:01.222: //-1/xxxxxxxxxxxx/SIP/Info/notify/8192/sip_dns_type_srv_query: TYPE SRV query for _sip._udp.cucm.cisco.com and type:1 000976: *Mar 9 15:53:01.224: //-1/xxxxxxxxxxxx/SIP/Info/info/8192/sip_dns_type_a_aaaa_query: DNS query for cucm.cisco.com and type:1 000977: *Mar 9 15:53:01.225: //-1/xxxxxxxxxxxx/SIP/Error/sip_dns_type_a_query: TYPE A query failed for cucm.cisco.com 000978: *Mar 9 15:53:01.225: //-1/xxxxxxxxxxxx/SIP/Error/_send_dns_fail: DNS Query for cucm.cisco.com failed 000984: *Mar 9 20:53:01.225: %VOICE_IEC-3-GW: SIP: Internal Error (DNS query fail): IEC=10.1.128.7.47.0 on callID 6 GUID=37B668DF044111E7A950D832C82B325C
Máximo de conexões e largura de banda
Por padrão, os peers de discagem VOIP e POTS permitem conexões ilimitadas (chamadas) e largura de banda (somente peers de discagem VOIP). Para troncos que têm um limite no número de chamadas ou na largura de banda que pode ser utilizada, pode ser útil empregar os comandos max-conn ou max-bandwidth. max-conn foi adicionado no Cisco IOS 11.3(1)T e está presente em todas as versões do Cisco IOS XE, enquanto max-bandwidth foi adicionado no 15.2(2)T e no IOS-XE 3.7S.
Exemplo de configuração:
Aqui você diz ao gateway para limitar as chamadas do correspondente de discagem de 1 a 30 usando "max-conn 30".
O peer de discagem 2 está limitando a largura de banda desse peer de discagem para que não excedamos o limite alocado.
! dial-peer voice 1 voip description ITSP SIP Trunk - 30 Max Calls! session protocol sipv2 sess target ipv4:10.10.10.10 destination-pattern 8675309$ max-conn 30 !
dial-peer voice 2 voip
description SIP Trunk with Bandwidth Restrictions!
session protocol sipv2
sess target ipv4:10.10.10.10
destination-pattern 123456789$
max-bandwidth 400
!
Exemplo de erro quando o limiar max-conn é ultrapassado.
000308: Oct 5 19:01:02.603: %CALL_CONTROL-6-MAX_CONNECTIONS: Maximum number of connections reached for dial-peer 1 000309: Oct 5 19:01:02.603: %VOICE_IEC-3-GW: CCAPI: Internal Error (Dial-peer connections exceeded): IEC=10.1.181.1.21.0 on callID 0 000310: Oct 5 19:01:02.604: %SIP-3-MAXCONNCAC: Call rejected due to CAC based on maximum number of connections on dial-peer 1, sent response 503 000311: Oct 5 19:01:02.604: //17084/86B070800000/SIP/Msg/ccsipDisplayMsg: Sent: SIP/2.0 503 Service Unavailable Via: SIP/2.0/TCP 10.50.244.62:5060;branch=z9hG4bKb78c35aa21b0 From: <sip:9001@10.50.244.62>;tag=72531~2e8ca155-3f0b-4f07-a1b2-b14ef77ceb7f-26250846 To: <sip:1234@10.50.245.70>;tag=3E19564D-1684 Date: Thu, 05 Oct 2017 19:01:02 GMT Call-ID: 86b07080-9d61816e-b762-3ef4320e@10.50.244.62 CSeq: 101 INVITE Allow-Events: telephone-event Warning: 399 10.50.245.70 "Maximum Number of Connections reached for dial-peer 1" Server: Cisco-SIPGateway/IOS-15.4.3.S4 Content-Length: 0
Discagem interna direta (DID)
Discagem em um estágio
Com a Direct Inward Dial ativada nos peers de discagem POTS, as mensagens de entrada podem conter todos os dígitos necessários para rotear a chamada. O Cisco Gateway não pode fazer a coleta de dígitos subsequente. Quando o roteador ou gateway procura um peer de discagem de saída, o dispositivo usa a string de discagem de entrada inteira. Essa correspondência é de comprimento variável por padrão. Essa correspondência não é feita dígito por dígito porque, pela definição DID, todos os dígitos foram recebidos. Esta é a configuração padrão para peers de discagem POTS.
Documentação Completa: Entendendo Direct-Inward-Dial (DID) em Interfaces Digitais de Voz (T1/E1) do IOS
Exemplo de configuração
! dial-peer voice 1 pots incoming called-number 8675309 voice-port 0/0/0 direct-inward-dial !
Discagem em dois estágios
Se o peer de discagem POTS de entrada estiver configurado com no direct-inward-dial, o roteador ou gateway entra no modo de coleta de dígitos (os dígitos são coletados na banda). A correspondência de peer de discagem de saída é feita dígito por dígito. O roteador ou gateway verifica as correspondências do peer de discagem depois que o dispositivo recebe cada dígito e, em seguida, roteia a chamada quando uma correspondência completa é feita.
Exemplo de configuração
!
dial-peer voice 1 pots
incoming called-number 8675309
voice-port 0/0/0
no direct-inward-dial
!Bloqueando chamadas
Cada protocolo lida com o bloqueio de chamadas de forma um pouco diferente. A maioria dos protocolos pode fazer uso do padrão de rejeição da regra de tradução que bloqueia com base em uma sequência de caracteres de dígitos. Se um administrador ainda quiser aplicar um perfil de conversão de entrada para manipulação normal de dígitos, mas não quiser bloquear nenhum número dentro dele, existe a opção de implementar um bloco de chamadas usando o comando call-block translation-profile.
! voice translation-rule 164 rule 1 reject /8675309/ ! voice translation-profile CALLBLOCK translate calling 164 !
dial-peer voice 1 pots
desc INCOMING VOICE-PORT with BLOCK
translation-profile incoming ANOTHER
call-block translation-profile incoming CALLBLOCK
call-block disconnect-cause incoming invalid-number
incoming called-number .
port 0/0/0:23
! Gateway#test voice translation-rule 164 8675309 8675309 blocked on rule 1
No E1 R2, existe a capacidade de um administrador bloquear chamadas de coleta. Isso é visto e empregado principalmente em implantações no Brasil, mas pode ser configurado por meio de qualquer grupo cas-custom.
As duas opções são:
- Bloqueie a chamada de coleta recebida com base na categoria II-8 recebida do switch telco. Esse é o mecanismo padrão e todos os Cisco Gateways executam isso sem nenhuma configuração. Esse método de bloqueio requer um switch telco mais novo que suporte a marcação baseada em categoria. Para desativar esse método, use o comando collect-call-enable no grupo cas-customer.
- Utilize o recurso double-answer em um grupo cas-custom de E1 R2 digital R2. A configuração de resposta dupla desativa o bloqueio baseado em categoria e o substitui pelo recurso de resposta dupla. Isso funciona respondendo primeiro a chamada recebida e iniciando um temporizador de 1 segundo. Após 1 segundo, o gateway envia uma versão na forma de um comando CLEAR BWD. A Telco pode enviar um FWD LIMPO para o gateway e a chamada pode ser desconectada. Um temporizador é iniciado depois que o gateway envia o CLEAR BWD e, se esse temporizador expirar, o gateway enviará outro sinal de ATENDIMENTO, assumindo que a chamada não é uma chamada de coleta e, a partir daí, a chamada continua normalmente. Esse temporizador pode ser configurado usando cc-reanswer-to dentro do grupo cas-custom.
Mensagem de bloqueio de Categoria II-8 (debug vpm signal)
009228: Nov 21 12:02:00.955 GMT: //-1/BF12BE36BAC8/VTSP:(0/0/0:0):-1:1:2/vtsp_report_cas_digit: Begin Digit=8, Mode=CC_TONE_R2_MF_BACKWARD_MODE 009229: Nov 21 12:02:00.955 GMT: htsp_digit_ready_up(0/0/0:0(2)): Rx digit='8' 009230: Nov 21 12:02:00.955 GMT: R2 Incoming Voice(0/0): DSX (E1 0/0/0:1): STATE: R2_IN_CATEGORY R2 Got Event 8 009231: Nov 21 12:02:00.955 GMT: Enter r2_comp_category 009232: Nov 21 12:02:00.955 GMT: R2 Event : 8 009233: Nov 21 12:02:00.955 GMT: #######R2_II8 TRUE######## 009234: Nov 21 12:02:00.955 GMT: ####### collect_call_enable = 0 009235: Nov 21 12:02:00.955 GMT: ############sending B7 ########## 009236: Nov 21 12:02:00.955 GMT: r2_reg_generate_digits(0/0/0:0(2)): Tx digit '7' 009237: Nov 21 12:02:01.055 GMT: //-1/BF12BE36BAC8/VTSP:(0/0/0:0):-1:1:2/vtsp_report_cas_digit: End Digit=8, Mode=CC_TONE_R2_MF_BACKWARD_MODE 009238: Nov 21 12:02:01.055 GMT: htsp_digit_ready(0/0/0:0(2)): Rx digit='#' 009239: Nov 21 12:02:01.055 GMT: R2 Incoming Voice(0/0): DSX (E1 0/0/0:1): STATE: R2_IN_CATEGORY R2 Got Event R2_TONE_OFF 009240: Nov 21 12:02:01.055 GMT: Enter r2_comp_category 009241: Nov 21 12:02:01.055 GMT: r2_reg_generate_digits(0/0/0:0(2)): Tx digit '#' 009242: Nov 21 12:02:01.359 GMT: htsp_dsp_message: SEND_SIG_STATUS: state=0x8 timestamp=22365 systime=225097425 009243: Nov 21 12:02:01.359 GMT: htsp_process_event: [0/0/0:0(2), R2_Q421_IC_WAIT_ANSWER, E_DSP_SIG_1000] 009244: Nov 21 12:02:01.359 GMT: r2_q421_ic_clr_fwd_idle(0/0/0:0(2)) Rx CLEAR FWD 009245: Nov 21 12:02:01.359 GMT: r2_reg_channel_disconnected(0/0/0:0(2)) 009246: Nov 21 12:02:01.359 GMT: R2 Incoming Voice(0/0): DSX (E1 0/0/0:1): STATE: R2_IN_CATEGORY R2 Got Event R2_STOP 009247: Nov 21 12:02:01.359 GMT: Enter r2_comp_category 009248: Nov 21 12:02:01.359 GMT: htsp_timer - 2000 msec 009249: Nov 21 12:02:01.359 GMT: htsp_process_event: [0/0/0:0(2), R2_Q421_IC_CLR_FWD, E_HTSP_RELEASE_REQ] 009250: Nov 21 12:02:01.359 GMT: r2_q421_null_release(0/0/0:0(2)) E_HTSP_RELEASE_REQ 009251: Nov 21 12:02:01.359 GMT: r2_reg_process_event: [0/0/0:0(2), R2_REG_COLLECTING, E_R2_REG_DISCONNECT(91)] 009252: Nov 21 12:02:01.359 GMT: r2_reg_disconnect_collect(0/0/0:0(2)) 009253: Nov 21 12:02:01.359 GMT: r2_reg_timer_stop(0/0/0:0(2)) 009254: Nov 21 12:02:01.711 GMT: htsp_process_event: [0/0/0:0(1), R2_Q421_IC_CLR_FWD, E_HTSP_EVENT_TIMER] 009255: Nov 21 12:02:01.711 GMT: htsp_timer_stop 009256: Nov 21 12:02:01.711 GMT: r2_q421_clr_fwd_idle(0/0/0:0(1)) Tx IDLEvnm_dsp_set_sig_state:[R2 Q.421 0/0/0:0(1)] set signal state = 0x8 009257: Nov 21 12:02:01.711 GMT: r2_reg_channel_disconnected(0/0/0:0(1)) 009258: Nov 21 12:02:01.711 GMT: //682206/0C63B263B9C9/VTSP:(0/0/0:0):0:1:1/vtsp_do_call_history: Coder Rate=5 009259: Nov 21 12:02:01.711 GMT: r2_reg_process_event: [0/0/0:0(1), R2_REG_IDLE, E_R2_REG_DISCONNECT(91)]
Exemplo de Configuração com Resposta Dupla
! controller e1 0/0/0 ds0-group 0 timeslots 1-15,17-31 type r2-digital r2-compelled ani cas-custom 0 country brazil double-answer cc-reanswer-to 3000 !
Depurações com Resposta Dupla (debug vpm signal)
### Answer the call and start a 1 second timer May 23 09:52:59.180 BR: r2_q421_ic_answer(0/0/0:0(18)) Tx ANSWER seizure: delay 0 ms,elapsed 12404 msvnm_dsp_set_sig_state:[R2 Q.421 0/0/0:0(18)] set signal state = 0x4 May 23 09:52:59.180 BR: r2_reg_channel_connected(0/0/0:0(18)) May 23 09:52:59.180 BR: htsp_timer - 1000 msec May 23 09:52:59.180 BR: //23899578/92233E71B421/CCAPI/cc_api_voice_mode_event: Call Id=23899578 May 23 09:52:59.180 BR: //23899578/92233E71B421/CCAPI/cc_api_voice_mode_event: Call Entry(Context=0x1E73AD8) May 23 09:52:59.180 BR: htsp_process_event: [0/0/0:0(18), R2_Q421_IC_DOUBLE_ANS_ANS, E_HTSP_VOICE_CUT_THROUGH] all May 23 09:52:59.184 BR: //23899578/92233E71B421/CCAPI/cc_process_notify_bridge_done: Conference Id=0x10AD1, Call Id1=23899578, Call Id2=23899579 May 23 09:52:59.184 BR: r2_reg_process_event: [0/0/0:0(18), R2_REG_WAIT_FOR_CONNECT, E_R2_REG_CONNECT(90)] May 23 09:52:59.184 BR: r2_reg_connect(0/0/0:0(18)) ### One Second Passes and we clear the call and start a 2 second timer May 23 09:53:00.180 BR: htsp_process_event: [0/0/0:0(18), R2_Q421_IC_DOUBLE_ANS_ANS, E_HTSP_EVENT_TIMER] May 23 09:53:00.180 BR: r2_q421_ic_d_answ_answ_to(0/0/0:0(18)) E_TIMER_EVENT May 23 09:53:00.180 BR: htsp_timer - 2000 msec May 23 09:53:00.180 BR: r2_q421_ic_d_answ_answ_to(0/0/0:0(18)) Tx CLEAR BWDvnm_dsp_set_sig_state:[R2 Q.421 0/0/0:0(18)] set signal state = 0xC May 23 09:53:00.824 BR: htsp_process_event: [0/0/0:0(18), R2_Q421_IC_DOUBLE_ANS_RLS, E_DSP_SIG_1000] May 23 09:53:00.824 BR: r2_q421_ic_answer_clr_fwd(0/0/0:0(18)) Rx CLEAR FWD May 23 09:53:00.824 BR: r2_reg_channel_disconnected(0/0/0:0(18)) May 23 09:53:00.824 BR: htsp_timer - 2000 msec May 23 09:53:00.824 BR: r2_reg_process_event: [0/0/0:0(18), R2_REG_CONNECTED, E_R2_REG_DISCONNECT(91)] May 23 09:53:00.824 BR: r2_reg_disconnect_idle(0/0/0:0(18)) May 23 09:53:00.824 BR: R2 Incoming Voice(0/0): DSX (E1 0/0/0:17): STATE: R2_IN_IDLE R2 Got Event R2_STOP May 23 09:53:00.824 BR: r2_reg_timer_stop(0/0/0:0(18)) ### 2 second passes and the gateway release the call May 23 09:53:02.824 BR: htsp_process_event: [0/0/0:0(18), R2_Q421_IC_CLR_FWD, E_HTSP_EVENT_TIMER] May 23 09:53:02.824 BR: htsp_timer_stop May 23 09:53:02.824 BR: r2_reg_channel_disconnected(0/0/0:0(18)) May 23 09:53:02.824 BR: //23899578/92233E71B421/VTSP:(0/0/0:0):17:1:1/vtsp_cc_call_disconnected: Cause Value=16 May 23 09:53:02.824 BR: //23899578/92233E71B421/CCAPI/cc_api_call_disconnected: Cause Value=16, Interface=0xB41CEBC, Call Id=23899578
ISDN overlap-receiving
Há implicações para a correspondência de peer de discagem de entrada quando o comando isdn overlap-receiving é configurado nas interfaces ISDN. Depois que cada dígito é recebido na camada ISDN, os correspondentes de discagem são verificados quanto a correspondências. Se uma correspondência completa for feita, a chamada será roteada imediatamente (para o aplicativo da sessão, nesse caso) sem esperar dígitos adicionais. O terminador T pode ser usado para suspender essa correspondência dígito por dígito e forçar o roteador ou gateway a esperar até que todos os dígitos sejam recebidos. O T refere-se ao temporizador interdígitos T302 no nível ISDN, configurável na interface serial associada à interface ISDN. A ISDN também fornece outros mecanismos para indicar o fim dos dígitos, como a configuração do Sending Complete Information Element (IE) nas mensagens de informação Q.931.
Número Chamado Vazio
A mensagem de aviso mostrada é exibida quando o correspondente de discagem está configurado com incoming called-number T.
Saída de exemplo
Gateway(config)# dial-peer voice 1 pots
Gateway(config-dial-peer)# incoming called-number T
Warning: Pattern T defines a match with zero or more digits and hence could
match with an empty number. If this is not the desired behaviour please
configure pattern .T instead to match on one or more digits
Observações especiais sobre a correspondência do correspondente de discagem recebido com um número chamado vazio.
-
Um número chamado nulo é considerado menos qualificado em comparação a uma porta de voz e/ou, em alguns casos, endereço de resposta. Portanto, uma correspondência com base em um número chamado nulo pode ocorrer somente se não houver correspondência com base no endereço de resposta ou no número de porta.
-
No caso de discagem sobreposta, um número chamado nulo não corresponde ao número chamado T de entrada porque o tempo limite não ocorreu.
-
Um número chamado nulo pode corresponder ao número chamado de entrada T somente no caso de ENBLOCK e não há correspondência por causa do endereço de resposta e do número de porta. O aviso exibido quando um administrador configura o número chamado T de entrada se refere a esse caso específico.
Classe de restrição
A Classe de Restrição (COR) é uma forma de limitar as chamadas em um Gateway Cisco. O COR é frequentemente descrito como um mecanismo de cadeado e chave. Os bloqueios são atribuídos aos correspondentes de discagem com uma lista de COR de saída. As chaves são atribuídas aos correspondentes de discagem com uma lista COR de entrada. Quando as Listas COR são aplicadas, os correspondentes de discagem de saída disponíveis são aqueles que a chave pode desbloquear. Essa filtragem ocorre antes que o restante dos métodos de correspondência do ponto de discagem de saída sejam verificados.
Duas regras importantes com classe de restrição:
- Se não houver nenhuma lista de COR de saída aplicada, a chamada será sempre roteada.
- Se não houver nenhuma lista de COR de entrada, a chamada será sempre roteada.
A configuração de Classe de Restrição (COR), Classe de Restrição de Particionamento Lógico (LPCOR) e LPCOR com Códigos de Autorização Forçada (FAC) estão fora do escopo deste documento, mas esses documentos podem ser consultados para leitura posterior.
| COR |
|
| LPCOR com CME |
|
| LPCOR com CME e FAC |
Guia do Administrador do Sistema do Cisco Unified Communications Manager Express |
Correspondentes de discagem do Cisco Unified Communications Manager Express (CUCME)
O CME cria correspondentes de discagem do sistema para ephones e pools de registro de voz. Eles não podem ser vistos na configuração atual. Para fazer alterações nos peers de discagem do CME, as alterações precisam ser feitas no ephone real ou no pool de registro de voz. Ao visualizar as saídas show dial-peer voice summary, o correspondente de discagem que começa com 2000 são ephones SCCP e os correspondentes de discagem que começam com 4000 são pools de registro de voz SIP. Esse peer de discagem aparece como o peer de discagem de entrada para chamadas de telefones registrados CME e o peer de discagem de saída em depurações para chamadas para telefones registrados CME.
Saída de exemplo para show dial-peer voice summary com CME.
Gateway# show dial-peer voice sum | s 2000|4000 20001 pots up up 1001$ 0 50/0/1 20002 pots up up 4001$ 0 50/0/2 20003 pots up up 4002$ 0 50/0/3 20004 pots up up 7001$ 0 50/0/4 20005 pots up up 3009$ 0 50/0/5 20006 pots up up 8810....$ 0 50/0/10 20007 pots up up 8811....$ 0 50/0/11 40001 voip up up 14085151111$ 0 syst ipv4:14.50.214.67:50 40002 voip up up 19725252222$ 0 syst ipv4:14.50.214.67:50 40003 voip up up 85225353333$ 0 syst ipv4:14.50.214.67:50 40004 voip up up 442084445555$ 0 syst ipv4:14.50.214.67:50 40005 voip up up 911$ 0 syst ipv4:14.50.214.67:50 40006 voip up up 18005550100$ 0 syst ipv4:14.50.214.67:50 40008 voip up up 2001$ 0 syst ipv4:14.50.214.51:50
Saída de exemplo para show voice register dial-peers com SIP CME.
Gateway# show voice register dial-peers Dial-peers for Pool 2: dial-peer voice 40006 voip destination-pattern 14085151111$ session target ipv4:14.50.214.67:5060 session protocol sipv2 dtmf-relay rtp-nte digit collect kpml codec g711ulaw bytes 160 no vad call-fwd-all 8888 after-hours-exempt FALSE dial-peer voice 40005 voip destination-pattern 19725252222$ session target ipv4:14.50.214.67:5060 session protocol sipv2 dtmf-relay rtp-nte digit collect kpml codec g711ulaw bytes 160 no vad after-hours-exempt FALSE
MGCP e SCCP com correspondentes de discagem
O MGCP e o SCCP seguem suas próprias regras para peers de discagem. O único conceito que eles utilizam é que eles devem ser configurados com a porta de voz desejada para a chamada. O restante é tratado pelos processos STCAPP e MGCPAPP. Quando você examina a configuração desses peers de discagem, eles têm o comando service mgcpapp ou service stcapp. Eles habilitam o peer de discagem para o aplicativo de sua escolha, bem como informam ao aplicativo qual peer de discagem ele pode manipular.
Ao depurar esses protocolos, a saída nunca exibe uma correspondência de peer de discagem de entrada. Isso sempre pode ser exibido como dial-peer 0. Porque não existe. O Agente de Chamada que está tratando do aplicativo já escolheu para qual porta enviar a chamada e a correspondência do correspondente de discagem de entrada é inútil, já que o gateway não tem controle sobre essa parte da chamada. No entanto, uma correspondência de dial peer de saída pode ser observada. Isso é apenas para exibição, pois, em última análise, o agente de chamadas que trata do processo também tem controle sobre esse lado da chamada.
Lembre-se de que o correspondente de discagem informa apenas ao aplicativo de escolha qual porta de voz física controlar. Como a maior parte disso é controlada por um agente de chamadas externo e o gateway, ele apenas faz o que lhe é dito. Você vai ignorar as instruções básicas desta seção e fornecer algumas configurações para começar.
Exemplo de configuração de MGCP [com Configuração automática de CUCM*]
!
mgcp call-agent 10.10.10.10
mgcp
!
ccm-manager mgcp [codec-all]
ccm-manager config server 10.10.10.10
ccm-manager config
ccm-manger redundant-host 10.10.10.20
!
voice-port 0/0/0
description The MGCP port to register
no shut
!
dial-peer voice 1 pots
description Defining the Port for the MGCP application
service mgcpapp
port 0/0/0
!
hostname myrouter
ip domain name cisco.com
ip name server 10.10.10.30
!
ip tftp source-interface gig0/0/0
!
Documentação completa do MGCP: Cisco Unified Communications Manager and Interoperability Configuration Guide, Cisco IOS Release 15M&T
Exemplo de configuração SCCP / STCAPP [com Configuração automática do CUCM*]
!
stcapp ccm-group 1
stcapp
!
sccp local gig0/0/0
sccp ccm 10.10.10.10 id 1 priority 1 version 7.0+
sccp ccm 10.10.10.20 id 1 priority 2 version 7.0+
sccp
!
sccp ccm group 1
bind interface gig0/0/0
associate ccm 1 priority 1
associate ccm 2 priority 2
!
ccm-manager config server 10.10.10.10
ccm-manager sccp local gig0/0/0
ccm-manager sccp
!
voice-port 0/0/0
description The SCCP port to register
no shut
!
dial-peer voice 1 pots
description Defining the Port for the SCCP application
service stcapp
port 0/0/0
!
ip tftp source-interface gig0/0/0
!
Se um administrador não quiser que o CUCM configure o gateway, basta remover os comandos ccm-manager. A configuração do peer de discagem é incluída para direcionar para casa o ponto sobre como o conceito funciona. Com as configurações do gerenciador de ccm presentes, o CUCM cria esses peers de discagem com base na configuração de porta no CUCM, portanto não há necessidade de realmente definir o peer de discagem. Os peers de discagem criados pelo CUCM geralmente começam com 999 e depois têm mais três dígitos.
DSAPP SIP com correspondentes de discagem
SIP DSAPP foi adicionado no Cisco IOS XE 16.12.1+ e CUCM 12.5.1SU+
Com esse recurso, as portas de voz analógicas, como FXS, podem ser registradas e gerenciadas pelo CUCM. O roteamento de chamadas com DSAPP é ligeiramente diferente do MGCP ou SCCP, pois os peers de discagem ainda são correspondidos normalmente. Ou seja, o gateway pode coletar dígitos da porta FXS e fazer uma pesquisa de peer de discagem nos peers de discagem VOIP. Depois que uma correspondência é encontrada, o CONVITE é enviado ao bloco CUCM para que o CUCM execute uma análise de dígitos adicional.
Exemplo de configuração DSAPP SIP [com Configuração automática do CUCM*] | IOS-XE 16.12.1+ e CUCM 12.5.1SU+
!
dsapp line
!
voice service voip
sip
bind control source-interface GigabitEthernet0/0/0
bind media source-interface GigabitEthernet0/0/0
session transport tcp
!
application
service dsapp
param dialpeer 777
!
global
service default dsapp
!
ccm-manager config server 10.10.10.10
ccm-manager sipana auto-config local GigabitEthernet0/0/0
!
dial-peer voice 777 voip
destination-pattern 9T
session protocol sipv2
session target ipv4:10.10.10.10
session transport tcp
incoming called-number .
voice-class sip extension gw-ana
voice-class sip bind control source-interface GigabitEthernet0/0/0
dtmf-relay rtp-nte
codec g711ulaw
!
dial-peer voice 19990100 pots
service dsapp
destination-pattern 7776
voice-class sip extension gw-ana
port 0/1/0
!
sip-ua
registrar ipv4:10.10.10.10 expires 3600 tcp
!
Documentação completa do SIP DSAPP: Guia de configuração do software de gateway de voz Cisco VG450
Solução de problemas de roteamento de chamadas e verificação
Consulte este documento para obter informações mais detalhadas.
Histórico de revisões
| Revisão | Data de publicação | Comentários |
|---|---|---|
4.0 |
24-May-2023 |
PII removido.
Título atualizado, Introdução, SEO, Requisitos de marca, Requisitos de estilo, Tradução automática, Texto alternativo e Formatação. |
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)
Observação: a exceção a essa regra é com as portas de voz MGCP e SCCP. Esses protocolos de sinalização não seguem o mecanismo de correspondência de peer de discagem normal durante o roteamento de chamadas. Consulte a seção SCCP e MGCP para obter mais detalhes.