Contents

Introdução

Pré-requisitos

Requisitos

Componentes Utilizados

Informações de Apoio

Definições comuns

Roteiro de comandos e recursos

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

Tipos de correspondentes de discagem de voz

Correspondência de Peer de Discagem de Entrada

Quando não há correspondências /Default Dial-Peer 0 peer_tag=0, pid:0

Correspondência de Peer de Discagem de Saída

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

Busca de correspondente de discagem URI

URI de Classe de Voz

Correspondência de Ponto de Discagem URI de Entrada

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

Caracteres Curinga de Peer de Discagem

Estados de Peer de Discagem

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

Correspondência de Peer de Discagem de Entrada com VRF

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

Técnicas avançadas de roteamento de chamadas

Grupos de Peer de Discagem

E164-Pattern-Maps

Grupos de servidores de destino

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

Proxy de saída

Grupos de Troncos POTS

Locatários da Classe de Voz

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

Técnicas de roteamento de chamadas antigas

Mapa de DNIS

Rótulos do Grupo de Troncos

Tipo de Numeração

Dados de Peer de Discagem

Grupo de origem de voz

Permissões de Peer de Discagem

URI e manipulação de dígitos

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

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

Voice Class e164-translation

Manipulação de dígitos via mapas ISDN

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

Perfis SIP de entrada/saída

Lista de cópias SIP

Observações especiais

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

Peers de discagem DNS e VoIP

Máximo de conexões e largura de banda

Discagem interna direta (DID)

Discagem em um estágio

Discagem em dois estágios

Bloqueando chamadas

ISDN overlap-receiving

Número Chamado Vazio

Classe de restrição

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

MGCP e SCCP com correspondentes de discagem

DSAPP SIP com correspondentes de discagem

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

Introdução

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

Pré-requisitos

Requisitos

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

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

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

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

Componentes Utilizados

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

- Gateways Cisco IOS e IOS XE

- 2800 / 3800 / 2900 / 3900 / 4300 / 4400 / CSR1000v / CAT8000v / ASR100X / C8200 / C8300 / ISR1100

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

Informações de Apoio

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

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

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

Definições comuns

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.

Exemplo:

8675309

123456789

+1972525222

+442084445555

+85225353333

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.

Exemplos de URL:

sip:user@host.com

sip:user@sub.host.com

sip:user@10.10.10.10

sip:user@2001:4860:4860::8888

tel.: 8675309

sip:host.com

ID da operadora

Exemplos de CID:

cid:orange@host.com

cid:orange@sub.host.com

cid:orange@10.10.10.10

cid:orange@2001:4860:4860::8888

Observação: o bug da Cisco ID CSCua14749 Carrier-ID não funciona em plataformas IOS XE.

String de Rota

Um cabeçalho de propriedade da Cisco para sequências de rota ILS usadas com SIP.

Exemplo:

X-cisco-dest-route-string: <sip:configured-value>

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 de saída.

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

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

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

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.

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 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.

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

Exemplo de erro:

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

Correspondência de Peer de Discagem de Entrada

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

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

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>

uri-to <uri-tag> de destino

uri-via de destino <uri-tag>

destination uri-diversion <uri-tag>

uri-referred-by <uri-tag> de destino

(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>

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

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

Preferência de string numérica:

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

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

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

Gateway(config)# dial-peer hunt ?

<0-7>  Dial-peer hunting choices, listed in hunting order within each choice:

0 - Longest match in phone number, explicit preference, random selection.

1 - Longest match in phone number, explicit preference, least recent use.

2 - Explicit preference, longest match in phone number, random selection.

3 - Explicit preference, longest match in phone number, least recent use.

4 - Least recent use, longest match in phone number, explicit preference.

5 - Least recent use, explicit preference, longest match in phone number.

6 - Random selection.

7 - Least recent use.

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

!

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

Busca de correspondente de discagem URI

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

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

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

Preferência de URI:

1. A parte de Host do URI. Exemplos: (@a.b.c.d ou @host.domain.name)

2. A parte do Usuário do URI. Exemplos: (sip:8675309 ou sip:user)

3. O tele-uri. Exemplo: (tel:18005532447)

4. Correspondência exata para o URI completo. Exemplos: (user@host.domain.name, user@a.b.c.d, 8675309@host.domain.name, 8675309@host.domain.name)

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

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

!

voice class uri URI1 sip

user-id testuser

!

voice class uri URI2 sip

host ipv4:10.10.10.10

!

dial-peer voice 1 voip

sess protocol sipv2

incoming uri FROM URI1

!

dial-peer voice 2 voip

sess protocol sipv2

incoming uri FROM URI2

!

URI de Classe de Voz

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

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

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

Gateway(config-voice-uri-class)# user-id .)

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

Gateway(config-voice-uri-class)# host .)

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

Gateway(config-voice-uri-class)# pattern .)

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

Exemplo: URIs de classe de voz

!

voice class uri HOST sip

host webex.com

host dns:cisco.webex.com

host ipv4:10.50.244.2

host ipv6:[2001:4860:4860::8888]

!

voice class uri USER sip

user-id username

!

voice class uri PATTERN sip

pattern 8675309

!

voice class uri HostRegex sip

host (.*)cisco.com

!

voice class uri ipRegex sip

host 172\.18\.110\.20[567]

!

voice class uri PatternRegex sip

pattern 555(.*)

!

voice class uri ipRegex sip

pattern (172\.18\.110\.10[134]|10\.10\.10\.10)

! One Line that matches 172.18.110.101, 172.18.110.103, 172.18.110.104 OR 10.10.10.10

!

voice class uri UserRegex sip

user-id test(.*)

!

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

Gateway(config)# voice class uri TEST sip

Gateway(config-voice-uri-class)#host ipv4:10.1.1.1

Gateway(config-voice-uri-class)#host ipv4:10.2.2.2

Gateway(config-voice-uri-class)#host ipv4:10.3.3.3

Gateway(config-voice-uri-class)#host ipv4:10.4.4.4

Gateway(config-voice-uri-class)#host ipv4:10.5.5.5

Gateway(config-voice-uri-class)#host ipv4:10.6.6.6

Gateway(config-voice-uri-class)#host ipv4:10.7.7.7

Gateway(config-voice-uri-class)#host ipv4:10.8.8.8

Gateway(config-voice-uri-class)#host ipv4:10.9.9.9

Gateway(config-voice-uri-class)#host ipv4:10.10.10.10

Gateway(config-voice-uri-class)#host ipv4:10.11.11.11

Error:Maximum of 10 hosts can only be configured.

Gateway(config)# voice class uri TEST2 sip

Gateway(config-voice-uri-class)#host dns:1.com

Gateway(config-voice-uri-class)#host dns:2.com

Gateway(config-voice-uri-class)#host dns:3.com

Gateway(config-voice-uri-class)#host dns:4.com

Gateway(config-voice-uri-class)#host dns:5.com

Gateway(config-voice-uri-class)#host dns:6.com

Gateway(config-voice-uri-class)#host dns:7.com

Gateway(config-voice-uri-class)#host dns:8.com

Gateway(config-voice-uri-class)#host dns:9.com

Gateway(config-voice-uri-class)#host dns:10.com

Gateway(config-voice-uri-class)#host dns:11.com

Error:Maximum of 10 hosts can only be configured.

Gateway(config)# voice class uri TEST3 sip

Gateway(config-voice-uri-class)#user-id 8675309

Gateway(config-voice-uri-class)#user-id 123456789

Gateway(config-voice-uri-class)#do sh run | s TEST3

voice class uri TEST3 sip

user-id 123456789

Gateway(config)# voice class uri TEST4 sip

Gateway(config-voice-uri-class)#pattern 8675309

Gateway(config-voice-uri-class)#pattern 123456789

Gateway(config-voice-uri-class)#do sh run | s TEST4

voice class uri TEST4 sip

pattern 123456789

Correspondência de Ponto de Discagem URI de Entrada

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

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

Casos de uso comuns

1. Um correspondente de discagem de entrada correspondente na parte do host do URI para responder às solicitações de ping OPÇÕES do CUCM.

2. Um correspondente de discagem de entrada correspondente na parte do host do URI para controlar chamadas de entrada de um Provedor de Serviços de Telefonia pela Internet (ITSP)

3. Um peer de discagem de entrada que corresponde na parte da ID do usuário do URi para tratamento de chamada de determinados usuários ou números.

Exemplo de configuração

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

!

voice class uri CUCM sip

host ipv4:10.50.244.2

host ipv4:10.50.244.20

!

dial-peer voice 777 voip

description INCOMING URI

session protocol sipv2

incoming uri from CUCM

voice-class sip bind control source-interface Loopback777

voice-class sip bind media source-interface Loopback777

!

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

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

Exemplo de configuração

voice service voip

sip

call-route url

requri-passing

!

voice class uri CUCM sip

host dns:.*.com

!

dial-peer voice 777 voip

description OUTGOING URI

session protocol sipv2

destination uri CUCM

session target sip-uri

!

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

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

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

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

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

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

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

Exemplo de configuração:

### Received INVITE

Received:

INVITE sip:8675309@172.18.110.58:5060 SIP/2.0

From: sipp <sip:sipp@172.18.110.65>;tag=1

To: sut <sip:cube@172.18.110.58:5060>

### Common Configurations

!

voice class uri FROM sip

user-id sipp

!

voice class uri TO sip

user-id cube

!

### OR Match

!

voice class dial-peer provision-policy 1

description match from header. If false, try to header

preference 1 from

preference 2 to

!

dial-peer voice 1234 voip

session protocol sipv2

destination provision-policy 1

incoming called-number .

!

dial-peer voice 11111 voip

destination uri-from FROM

session protocol sipv2

session target ipv4:172.18.110.48

!

dial-peer voice 22222 voip

destination uri-to TO

session protocol sipv2

session target ipv4:172.18.110.48

!

### AND Match

!

voice class dial-peer provision-policy 2

description match from AND to headers

preference 1 from to

!

dial-peer voice 1234 voip

session protocol sipv2

destination provision-policy 2

incoming called-number .

!

dial-peer voice 12345 voip

destination uri-from FROM

destination uri-to TO

session protocol sipv2

session target ipv4:172.18.110.48

!

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

session target sip-uri

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

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

Exemplo de configuração:

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

!

ip host cisco.com 10.10.10.10

ip host webex.com 10.10.10.10

!

voice class uri TEST-IN sip

user-id testuser

!

dial-peer voice 1 voip

description INCOMING dial-peer

incoming uri request TEST

session protocol sipv2

voice-class sip call-route url

!

dial-peer voice 2 voip

description OUTBOUND dial-peer

destination uri TEST

session protocol sipv2

session target sip-uri

!

Verificação:

show voice class uri <uri-name>

show voice class dial-peer provision-policy <number>

debug voip uri

Caracteres Curinga de Peer de Discagem

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

Tabela Curinga

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.

Os administradores podem encerrar o tempo limite entre dígitos usando # no teclado. Isso pode ser modificado por meio do terminador de peer de discagem de comando configurado globalmente.

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.

1. Para cima

2. Down

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

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

Junto com os estados operacionais, existem os estados Administrativos.

1. Para cima

2. Down

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

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

Verificação

Gateway# show dial-peer voice summary

dial-peer hunt 0

AD                                    PRE PASS                OUT

TAG    TYPE  MIN  OPER PREFIX    DEST-PATTERN      FER THRU SESS-TARGET    STAT PORT    KEEPALIVE

1      voip  up   up                                0  syst

777    voip  up   up             9...               0  syst ipv4:10.50.244.2

555    voip  up   down           555                0  syst

888    pots  up   up             888                0                      up   0/2/0

999    pots  up   up             999                0                      down 0/2/0

123    voip  up   up             123                0  syst ipv4:10.10.10.10            busyout

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

Correspondência de Peer de Discagem de Entrada com VRF

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

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

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

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

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

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

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

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

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

!

interface GigabitEthernet0/0/1.1

description VRF1

encapsulation dot1Q 10

ip vrf forwarding VRF1

ip address 10.10.10.10 255.255.255.0

!

interface GigabitEthernet0/0/1.2

description VRF2

encapsulation dot1Q 20

ip vrf forwarding VRF2

ip address 10.10.10.10 255.255.255.0

!

voice service voip

no ip address trusted authenticate

media-address voice-vrf VRF1

media-address voice-vrf VRF2

allow-connections sip to sip

sip

!

voice class dpg 10

description INBOUND VRF1 to OUTBOUND VRF1

dial-peer 10 preference 1

!

voice class dpg 20

description INBOUND VRF2 to OUTBOUND VRF2

dial-peer 20 preference 1

!

dial-peer voice 10 voip

description VRF1

destination-pattern 8675309

session protocol sipv2

session target ipv4:10.10.10.20

destination dpg 10

incoming called-number 8675309

voice-class sip bind control source-interface GigabitEthernet0/0/1.1

voice-class sip bind media source-interface GigabitEthernet0/0/1.1

!

dial-peer voice 20 voip

description VRF2

destination-pattern 8675309

session protocol sipv2

session target ipv4:10.10.10.20

destination dpg 20

incoming called-number 8675309

voice-class sip bind control source-interface GigabitEthernet0/0/1.2

voice-class sip bind media source-interface GigabitEthernet0/0/1.2

!

Verificação

Gateway# show vrf brief | i VRF

VRF1                             1:1                   ipv4        Gi0/0/1.1

VRF2                             2:2                   ipv4        Gi0/0/1.2

Gateway# show dial-peer voice summary

TAG    TYPE  MIN  OPER PREFIX    DEST-PATTERN      FER THRU SESS-TARGET    STAT PORT    KEEPALIVE    VRF

10     voip  up   up             8675309            0  syst ipv4:10.10.10.20                         VRF1

20     voip  up   up             8675309            0  syst ipv4:10.10.10.20                         VRF2

Gateway# show voice class dpg 10

Voice class dpg: 10      AdminStatus: Up

Description: INBOUND to OUTBOUND VRF1

Total dial-peer entries: 1

Peer Tag       Pref

--------       ----

10             1

-------------------------------------

Gateway# show voice class dpg 20

Voice class dpg: 20      AdminStatus: Up

Description: INBOUND to OUTBOUND VRF2

Total dial-peer entries: 1

Peer Tag       Pref

--------       ----

20             1

-------------------------------------

Técnicas avançadas de roteamento de chamadas

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

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

Grupos de Peer de Discagem

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

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

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

Exemplo de configuração

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

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

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

!

dial-peer voice 1 voip

description Server 1

destination-pattern ^1234$

session target ipv4:1.1.1.1

!

dial-peer voice 2 voip

description Server 2

destination-pattern ^5678$

session target ipv4:2.2.2.2

!

dial-peer voice 3 voip

description Server 3

destination-pattern AAAA

session target ipv4:3.3.3.3

!

voice class dpg 1

description Dial-peer Group for specific called number 8675309

dial-peer 2 preference 1

dial-peer 3 preference 2

dial-peer 1 preference 3

!

dial-peer voice 1234 voip

description INCOMING dial-peer with DPG

incoming called-number ^8675309$

destination dpg 1

!

Verificação

Gateway# show voice class dpg 1

Voice class dpg: 1       AdminStatus: Up

Description: Dial-peer Group for specific called number 1234

Total dial-peer entries: 3

Peer Tag       Pref

--------       ----

2              1

3              2

1              3

-------------------------------------

E164-Pattern-Maps

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

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

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

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

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

!

voice class e164-pattern-map 1

description E164 Pattern Map for calling numbers

e164 919574100.

e164 919574300.

e164 8675309

!

dial-peer voice 1 voip

description INBOUND Dial-peer based on CALLING #

incoming calling e164-pattern-map 1

!

dial-peer voice 11 voip

description OUTBOUND Dial-peer based on CALLING #

destination calling e164-pattern-map 1

!

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

!

voice class e164-pattern-map 2

description E164 Pattern Map for called 800 numbers

e164 91800T

e164 91855T

e164 91888T

!

dial-peer voice 2 voip

description INBOUND Dial-peer based on CALLED #

incoming called e164-pattern-map 2

!

dial-peer voice 22 voip

description OUTBOUND Dial-peer based on CALLED #

destination e164-pattern-map 2

!

Exemplo de configuração de Flash

!

voice class e164-pattern-map <tag>

description FILEPATH for E164 Pattern Map

url flash:<filepath>/e164-pattern-list.cfg

!

dial-peer voice ### voip

description E164 Pattern Map Dial-peer

incoming calling e164-pattern-map <tag>

!

voice class e164-pattern-map load <tag>

Verificação

Gateway# show voice class e164-pattern-map 1

e164-pattern-map 1

-----------------------------------------

Description: CUCM phones

It has 3 entries

It is not populated from a file.

Map is valid.

E164 pattern

-------------------

8675309

1...

[2-5]...$

Defeitos notáveis

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

Grupos de servidores de destino

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

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

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

Exemplo de configuração - Normal

!

voice class server-group 1

hunt-scheme round-robin

ipv4 10.50.244.2 port 5060 preference 1

ipv4 10.50.244.62

ipv6 2010:AB8:0:2::1 port 2323 preference 3

ipv6 2010:AB8:0:2::2 port 2222

!

dial-peer voice 1 voip

session protocol sipv2

destination-pattern 8675309

session server-group 1

!

Verificação

Gateway# show voice class server-group 1

Voice class server-group: 1

AdminStatus: Up OperStatus: Up

Hunt-Scheme: round-robin Last returned server:

Description:

Total server entries: 4

Pref Type IP Address IP Port

---- ---- ---------- -------

1 ipv4 10.50.244.2     5060

0 ipv4 10.50.244.62

3 ipv6 2010:AB8:0:2::1 2323

0 ipv6 2010:AB8:0:2::2 2222

[..truncated..]

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

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

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

!

voice class server-group 1

hunt-scheme round-robin

ipv4 10.50.244.2

ipv4 10.50.244.62

!

dial-peer voice 1 voip

session protocol sipv2

session server-group 1

voice-class sip options-keepalive profile 1

!

Verificação

Gateway# show voice class sip-options-keepalive 1

Voice class sip-options-keepalive: 1             AdminStat: Up

Description:

Transport: system               Sip Profiles: 0

Interval(seconds) Up: 5                 Down: 5

Retry: 5

Peer Tag      Server Group    OOD SessID      OOD Stat        IfIndex

--------      ------------    ----------      --------        -------

1             1                               Active          87

Server Group: 1                OOD Stat: Active

OOD SessID   OOD Stat

----------   --------

1            Active

2            Active

OOD SessID: 1                   OOD Stat: Active

Target: ipv4:10.50.244.2

Transport: system              Sip Profiles: 0

OOD SessID: 2                   OOD Stat: Active

Target: ipv4:10.50.244.62

Transport: system              Sip Profiles: 0

Proxy de saída

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

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

!

voice service voip

sip

outbound-proxy dns:la01.sipconnect-us10.cisco-bcld.com

!

voice class tenant 100

outbound-proxy dns:la01.sipconnect-us10.cisco-bcld.com

!

dial-peer voice 100 voip

session target ipv4:192.168.1.1

voice-class sip outbound-proxy dns:la01.sipconnect-us10.cisco-bcld.com

!

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

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

dial-peer voice 777 voip

no voice-class sip outbound-proxy

Grupos de Troncos POTS

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

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

Exemplo de configuração

!

trunk group PSTN

description PSTN voice-ports

!

trunk group FXO

description FXO voice-ports

!

voice-port 0/2/0

trunk-group PSTN 1

!

voice-port 0/2/1

trunk-group PSTN 2

!

voice-port 0/2/2

trunk-group FXO 1

!

voice-port 0/2/3

trunk-group FXO 2

!

dial-peer voice 1234 pots

trunkgroup PSTN 1

trunkgroup FXO 2

!

Locatários da Classe de Voz

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

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

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

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

1. Comando dial peer

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

Ordem de preferência de comando com espaços

1. comando dial peer

2. Comando de locatário

3. Comando global (serviço de voz voip e sip-ua)

Exemplo de configuração de multiusuário

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

!

voice class tenant 999

asymmetric payload full

bind control source-interface GigabitEthernet0/0/0.228

bind media source-interface GigabitEthernet0/0/0.228

g729 annexb-all

!

voice class tenant 777

sip-server ipv4:192.168.1.2

bind control source-interface Loopback0

bind media source-interface Loopback0

pass-thru content sdp

!

dial-peer voice 999 voip

destination-pattern 8675309

session protocol sipv2

incoming called-number 8675309

voice-class sip tenant 999

!

dial-peer voice 777 voip

destination-pattern 8675309

session protocol sipv2

session target sip-server

voice-class sip tenant 777

!

Verificação

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

show run | sec tenant

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

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

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

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

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

!

voice service voip

sip

call-route dest-route-string

!

voice class route-string rt1

pattern london.uk.eu

!

voice class sip route-string rt2

pattern *.eu

!

voice class sip-hdr-passthrulist hdr1

passthru-hdr x-cisco-dest-route-string

!

dial-peer voice 1 voip

description INBOUND dial-peer

session protocol sipv2

voice-class sip pass-thru headers hdr1

incoming called-number .

!

dial-peer voice 2 voip

description OUTBOUND dial-peer

destination route-string rt2

session protocol sipv2

session target ipv4:172.16.104.178

!

Verificação

show voice class route-string

Técnicas de roteamento de chamadas antigas

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

Mapa de DNIS

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

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

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

Exemplo de configuração

!

voice dnis-map 34

dnis 8675309

!

dial-peer voice 88 voip

dnis-map 34

!

Rótulos do Grupo de Troncos

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

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

Exemplo de configuração

!

dial-peer voice 112 pots

trunk-group-label source north3

trunk-group-label target east17

!

Tipo de Numeração

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

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

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

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

Exemplo de configuração

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

!

dial-peer voice 408 voip

numbering-type national

destination-pattern 408515....

session target ipv4:10.1.1.2

!

Tipos de números possíveis:

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

1. Perfil de conversão de voz de entrada na porta de voz

2. Perfil de conversão de voz de entrada no Grupo de Troncos aplicado à Interface Serial

3. Incoming voice translation-profile no peer de discagem de entrada

4. Perfil de conversão de voz de entrada definido através de portas de serviço de voz

5. Perfil de conversão de voz de entrada definido via 'voip-incoming translation-profile' global

6. Perfil de tradução de voz de saída definido através de portas de serviço de voz

7. Outbound voice translation-profile ou translate-outgoing no dial-peer de saída

8. Perfil de conversão de voz de saída no grupo de troncos aplicado à interface serial

9. Perfil de tradução de voz de saída na porta de voz

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

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 \( \)

&

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. O aprimoramento para isso foi arquivado sob a ID de bug Cisco CSCsr20474  Além disso, os perfis SIP não podem remover ou adicionar valores ao SDP. Somente você pode modificar esses valores. No entanto, é possível modificar um valor SDP para um valor nulo especificando o valor inteiro e, em seguida, definindo a saída para um conjunto de aspas vazias sem espaço.

- Não há verificações realizadas para ver se o comando atual sendo inserido já existe ou se uma versão desse comando já existe ao inserir comandos dentro da classe de voz sip-profile. Se um administrador colar uma linha 7 vezes em um perfil sip, ele exibirá 7 vezes a configuração atual. Recomenda-se remover o comando que está sendo modificado e, em seguida, inserir o novo comando ao editar perfis sip para evitar a presença de vários comandos.

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

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

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

!

voice class sip-profiles <number>

request <message-type> sip-header <header> modify "match-pattern" "replace-pattern"

request <message-type> sip-header <header> add "add-pattern"

request <message-type> sip-header <header> remove

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

request <message-type> sdp-header <header> add "add-pattern"

request <message-type> sdp-header <header> remove

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

response <number> sip-header <header> add "add-pattern"

response <number> sip-header <header> remove

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

response <number> sdp-header <header> add "add-pattern"

response <number> sdp-header <header> remove

!

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

voice class sip-profiles 200

rule 1 response ANY sip-header Remote-Party-ID modify "match-pattern" "replace-pattern"

rule 2 response ANY sdp-header Audio-Attribute modify "match-pattern" "replace-pattern"

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

! Global Application

voice service voip

sip

sip-profiles <number>

!

! Tenant Application

voice class tenant <tag>

sip-profiles <tag>

!

! Dial-peer Application

dial-peer voice <tag> voip

voice-class sip profiles <number>

!

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

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

! Global Application

voice service voip

sip

sip-profiles inbound

sip-profiles <number> inbound

!

! Tenant Application

voice service voip

sip

sip-profiles inbound

!

voice class tenant <tag>

sip-profiles <tag> inbound

!

! Dial-Peer Application

voice service voip

sip

sip-profiles inbound

!

dial-peer voice <tag> voip

voice-class sip profiles <number> inbound

!

Exemplo de perfil SIP para modificar mensagens de keepalive OPTIONS.

!

voice class sip-options-keepalive 200

transport tcp tls

sip-profiles 299

!

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

! Host

!

voice class sip-profiles 1

request ANY sip-header Contact modify "sip:(.*)@" "sip:8675309@"

!

! Domain

!

voice class sip-profiles 2

request ANY sip-header Contact modify "10.67.138.241:5060" "cisco.com"

!

! Note: Port is optional

!

! Modify Both User and Host

!

voice class sip-profiles 3

request ANY sip-header Contact modify "sip:(.*)>" "sip:8675309@cisco.com>"

!

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

! Add

!

voice class sip-profiles 777

request INVITE sip-header Diversion add "Diversion: <sip:1234@cisco.com>"

!

!

! Modify

!

voice class sip-profiles 888

request INVITE sip-header Diversion modify "sip:(.*)>" "sip:1234@cisco.com>"

!

!

! Remove

!

voice class sip-profiles 999

request INVITE sip-header Diversion remove

!

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

!

voice class sip-profiles 123

request INVITE sip-header From modify "\".*\"" "\"TEST CLID*\""

!

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

!

voice class sip-profiles 789

response 183 sip-header SIP-StatusLine modify "SIP/2.0 183 Session in Progress" "SIP/2.0 180 Ringing"

!

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

!

voice class sip-profiles 200

request ANY sdp-header Audio-Attribute modify "a=inactive" "a=sendrecv"

request ANY sdp-header Audio-Connection-Info modify "0.0.0.0" "10.10.10.10"

!

! where 10.10.10.10 is CUBE's provider facing IP address

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

!

voice class sip-profiles 200

request ANY sip-header Allow-Header modify ", UPDATE" ""

!

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

!

voice class sip-profiles 1

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

!

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

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

!

voice class sip-profiles 1

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

!

Exemplo de perfil SIP com lógica OR.

!

voice class sip-profiles 123

request ANY sdp-header Audio-Attribute modify "(a=sendonly|a=recvonly|a=inactive)" "a=sendrecv"

response ANY sdp-header Audio-Attribute modify "(a=sendonly|a=recvonly|a=inactive)" "a=sendrecv"

!

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

### Usage

10.21.15.10 replace with private IP of CUBE

a.b.c.d replace with public IP

------------------------------------------------------

### Inbound from ITSP Layer 7 Fixup

!

voice class sip-profiles 888

request INVITE sip-header SIP-Req-URI modify "@.*;" "@10.21.15.100;"

!

voice service voip

sip

sip-profiles inbound

!

### Outbound Layer 7 Fixup

!

voice class sip-profiles 777

request ANY sip-header Contact modify "<sip:(.*)@10.21.15.100:5060>" "<sip:\1 a.b.c.d:5060>"

response ANY sip-header Contact modify "<sip:(.*)@10.21.15.100:5060>" "<sip:\1 a.b.c.d:5060>"

request ANY sip-header Via modify "SIP(.*) 10.21.15.100(.*)" "SIP\1 a.b.c.d\2"

request ANY sdp-header Session-Owner modify "(.*IP4 ).*" "\1a.b.c.d"

request ANY sdp-header Connection-Info modify "IN IP4 10.21.15.100" "IN IP4 a.b.c.d"

request ANY sdp-header Audio-Connection-Info modify "IN IP4 10.21.15.100" "IN IP4 a.b.c.d"

response ANY sdp-header Session-Owner modify "(.*IP4 ).*" "\1a.b.c.d"

response ANY sdp-header Audio-Connection-Info modify "IN IP4 10.21.15.100" "IN IP4 a.b.c.d"

response ANY sdp-header Connection-Info modify "IN IP4 10.21.15.100" "IN IP4 a.b.c.d"

request ANY sip-header Remote-Party-ID modify "<sip:(.*)@10.21.15.100>" "<sip:\1 a.b.c.d>"

response ANY sip-header Remote-Party-ID modify "<sip:(.*)@10.21.15.100>" "<sip:\1 a.b.c.d>"

!

### Apply to dial-peers for the side of the CUBE facing the ITSP

!

dial-peer voice 1 voip

voice-class sip profiles 777

voice-class sip profile 888 inbound

!

dial-peer voice 2 voip

voice-class sip profiles 777

voice-class sip profile 888 inbound

!

Lista de cópias SIP

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

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

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

Exemplo de lista de cópia SIP

!

! Create Copylist to copy the FROM header on the inbound message specified later.

!

voice class sip-copylist <number>

sip-header From

!

! Apply this to the inbound dial-peer of the call.

!

dial-peer voice <tag> voip

voice-class sip copy-list <number>

!

! Create SIP Profile to take From (peer-header) stored as variable "u01" and apply to a header of choice.

! This example modifies the user portion of the Contact by copying the user portion of the From header to the user portion of the Contact header.

!

voice class sip-profiles <number>

request INVITE peer-header sip From copy "<sip:(.*)@" u01

request INVITE sip-header Contact modify "<sip:(.*)>" "<sip:\u01@10.50.244.2>"

!

! Apply the SIP profile to an outbound dial-peer

!

dial-peer voice <tag> voip

voice-class sip profiles <number>

!

Depurando perfis SIP e lista de cópia

debug voip ccapi inout

debug ccsip mess

debug ccsip info

debug ccsip feature sip-profile

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

### Ingress from CUCM

Received:

INVITE sip:1001@10.50.228.61:5060 SIP/2.0

Via: SIP/2.0/TCP 10.50.244.3:5060;branch=z9hG4bKaad21bc3ae7e

From: "5001" <sip:5001@10.50.244.3>;tag=100442~cdffff43-5020-4e79-a10b-99d406971010-36470319

Contact: <sip:5001@10.50.244.3:5060;transport=tcp>

### Copylist Details

00440: Mar  8 18:59:49.796: //-1/xxxxxxxxxxxx/SIP/Info/info/64/sip_profiles_application_peer_copy_pattern: sed_match succeeded

000441: Mar  8 18:59:49.797: //187/D6138E000000/SIP/Info/info/64/sip_profiles_application_peer_copy_pattern: SIP Profiles COPY variables AVL tree created

000442: Mar  8 18:59:49.797: //-1/xxxxxxxxxxxx/SIP/Info/info/64/sip_profiles_prefix_slash_in_copy_var_val: ret_dst: 5001

000443: Mar  8 18:59:49.797: //187/D6138E000000/SIP/Info/info/64/sip_profiles_application_peer_copy_pattern: SIP Profiles COPY variable: u1 val: 5001

000444: Mar  8 18:59:49.797: //-1/xxxxxxxxxxxx/SIP/Info/info/64/sip_profiles_application_modify_remove_header: Header before modification : Contact: <sip:5001@10.50.228.61:5060>

000445: Mar  8 18:59:49.797: //187/D6138E000000/SIP/Info/info/64/sip_profiles_check_and_get_variables_in_replace_pattern: Node found: COPY variable: u1 val: 5001

000446: Mar  8 18:59:49.797: //187/D6138E000000/SIP/Info/info/64/sip_profiles_check_and_get_variables_in_replace_pattern: substituted_replace_pattern :  : @168.117.64.94>

000448: Mar  8 18:59:49.797: //187/D6138E000000/SIP/Info/info/64/sip_profiles_check_and_get_variables_in_replace_pattern: Final substituted_replace_pattern : <sip:5001@168.117.64.94>

000449: Mar  8 18:59:49.797: //-1/xxxxxxxxxxxx/SIP/Info/info/64/sip_profiles_app_modify_header: Passing substituted replace pattern

000450: Mar  8 18:59:49.798: //-1/xxxxxxxxxxxx/SIP/Info/info/64/sip_profiles_application_modify_remove_header: Header after modification : Contact: <sip:5001@168.117.64.94>

000451: Mar  8 18:59:49.798: //187/D6138E000000/SIP/Msg/ccsipDisplayMsg:

### Egress from CUBE

Sent:

INVITE sip:1001@14.50.228.63:5060 SIP/2.0

Via: SIP/2.0/UDP 10.50.228.61:5060;branch=z9hG4bK3C7CD

Remote-Party-ID: "5001" <sip:5001@10.50.228.61>;party=calling;screen=yes;privacy=off

From: "5001" <sip:5001@10.50.228.61>;tag=34C458-D6

Contact: <sip:5001@168.117.64.94>

Observações especiais

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

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

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

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

Exemplo de configuração

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

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

!

dial-peer voice 2 voip

description "Incoming call from CUCM"

session protocol sipv2

incoming called-number .

voice-class sip bind control source-interface Loopback1

voice-class sip bind media source-interface Loopback1

!

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

1. De acordo com a instrução bind no peer de discagem de entrada/saída correspondente.

2. De acordo com as associações sob o locatário da classe de voz atribuído ao correspondente de discagem de entrada/saída correspondente.

3. De acordo com a declaração de vinculação global.

4. De acordo com a interface física da camada 3, espera-se que o pacote saia baseado na tabela de roteamento.

Comandos de vinculação SIP

! Per Dial-peer

!

dial-peer voice 1 voip

voice-class sip bind control source-interface <interface>

voice-class sip bind media source-interface <interface>

!

! Global Binding

!

voice service voip

sip

bind control source-interface <interface>

bind media source-interface <interface>

!

Comandos de vinculação MGCP

!

mgcp bind control source-interface <interface>

mgcp bind media source-interface <interface>

!

Comandos de vinculação SCCP

!

sccp local <interface>

!

sccp ccm group <number>

bind interface <interface>

!

Comandos de vinculação H323

!

inteface <interface>

!

! Media Bind Command:

h323-gateway voip interface

!

! Signaling Bind Command:

h323-gateway voip bind srcaddr <a.b.c.d>

!

Peers de discagem DNS e VoIP

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

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

Após essa alteração, os peers de discagem configurados com o destino da sessão dns:FQDN.com obedecem agora ao fato de que o DNS está desabilitado sem nenhuma pesquisa de domínio ip.

Recomendo sempre garantir que o comando "ip domain lookup" esteja configurado ao trabalhar com o DNS para evitar esse problema.

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

1. Pesquisa de consulta SRV

2. Uma Pesquisa de Registro

3. Pesquisa de Registro AAAA

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

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

1. Uma Pesquisa de Registro

2. Pesquisa de Registro AAAA

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

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

Amostras de configuração do IOS DNS

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

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

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

ip host cucm1.lab.local 10.0.0.1

ip host cucm2.lab.local 10.0.0.2

ip host cucm3.lab.local 10.0.0.3

ip domain name lab.local

ip name-server 8.8.8.8

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

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

show host

clear host all *

!

debug ip dns view

debug ip domain

debug ccsip info

debug ccsip error

Teste de DNS 3.15S e posterior

### Domain Name Verification

Gateway# sh run | s lookup

no ip domain lookup

### Checking the host table for no entry

Gateway# show host

Name lookup view: Global

Default domain is cisco.com

Name/address lookup uses static mappings

Codes: UN - unknown, EX - expired, OK - OK, ?? - revalidate

temp - temporary, perm - permanent

NA - Not Applicable None - Not defined

Host                      Port  Flags      Age Type   Address(es)

### Verification of no PING on a FQDN

Gateway# ping cucm.cisco.com

Translating "cucm.cisco.com"

% Unrecognized host or address, or protocol not running.

### Made a test call here

### Checking logs to see if it worked

Gateway# sh log | s INVITE sip:

INVITE sip:9001@14.50.228.70:5060 SIP/2.0

INVITE sip:5001@cucm.cisco.com:5060 SIP/2.0

### Host Table now has an entry

Gateway# sh host

Name lookup view: Global

Default domain is cisco.com

Name/address lookup uses static mappings

Codes: UN - unknown, EX - expired, OK - OK, ?? - revalidate

temp - temporary, perm - permanent

NA - Not Applicable None - Not defined

Host                      Port  Flags      Age Type   Address(es)

cucm.cisco.com            None  (temp, OK)  0   IP    10.50.244.2

### CCSIP All output showing a proper DNS Query for the FQDN on the dial-peer.

001338: Mar  9 15:29:07.437: //-1/xxxxxxxxxxxx/SIP/Info/info/1024/httpish_msg_free: Freed msg=0x7FE9873AE560

001339: Mar  9 15:29:07.437: //-1/xxxxxxxxxxxx/SIP/Info/notify/8192/sip_dns_type_srv_query: TYPE SRV query for _sip._udp.cucm.cisco.com and type:1

001340: Mar  9 15:29:07.438: //-1/xxxxxxxxxxxx/SIP/Info/info/8192/sip_dns_type_a_aaaa_query: DNS query for cucm.cisco.com and type:1

001341: Mar  9 15:29:07.441: //-1/xxxxxxxxxxxx/SIP/Info/notify/8192/sip_dns_type_a_query: TYPE A query successful for cucm.cisco.com

001342: Mar  9 15:29:07.441: //-1/xxxxxxxxxxxx/SIP/Info/info/8192/sip_dns_type_a_query: ttl for A records = 3600 seconds

001343: Mar  9 15:29:07.441: //-1/xxxxxxxxxxxx/SIP/Info/info/8192/sip_dns_type_a_aaaa_query: IP Address of cucm.cisco.com is:

001344: Mar  9 15:29:07.441: //-1/xxxxxxxxxxxx/SIP/Info/info/8192/sip_dns_type_a_aaaa_query: 10.50.244.2

Teste de DNS 3.16S e superior.

### Checking the command is present

Gateway# sh run | s lookup

no ip domain lookup

### Verifying the gateway cannot ping a FQDN

Gateway# ping cucm.cisco.com

% Unrecognized host or address, or protocol not running.

### Checking the Host Table for entries

Gateway# sh host

Default domain is cisco.com

Name servers are 10.50.244.52

NAME  TTL  CLASS   TYPE      DATA/ADDRESS

-----------------------------------------

### Made a test call here

### CCSIP All Outbound showing the failed call

000974: *Mar  9 15:53:01.222: //-1/xxxxxxxxxxxx/SIP/Info/info/1024/httpish_msg_free: Freed msg=0x7FF31DAAA848

000975: *Mar  9 15:53:01.222: //-1/xxxxxxxxxxxx/SIP/Info/notify/8192/sip_dns_type_srv_query: TYPE SRV query for _sip._udp.cucm.cisco.com and type:1

000976: *Mar  9 15:53:01.224: //-1/xxxxxxxxxxxx/SIP/Info/info/8192/sip_dns_type_a_aaaa_query: DNS query for cucm.cisco.com and type:1

000977: *Mar  9 15:53:01.225: //-1/xxxxxxxxxxxx/SIP/Error/sip_dns_type_a_query:

TYPE A query failed for cucm.cisco.com

000978: *Mar  9 15:53:01.225: //-1/xxxxxxxxxxxx/SIP/Error/_send_dns_fail:

DNS Query for cucm.cisco.com failed

000984: *Mar  9 20:53:01.225: %VOICE_IEC-3-GW: SIP: Internal Error (DNS query fail): IEC=10.1.128.7.47.0 on callID 6 GUID=37B668DF044111E7A950D832C82B325C

Máximo de conexões e largura de banda

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

Exemplo de configuração:

Aqui você diz ao gateway para limitar as chamadas do correspondente de discagem de 1 a 30 usando "max-conn 30".

O peer de discagem 2 está limitando a largura de banda desse peer de discagem para que não excedamos o limite alocado.

!

dial-peer voice 1 voip

description ITSP SIP Trunk - 30 Max Calls!

session protocol sipv2

sess target ipv4:10.10.10.10

destination-pattern 8675309$

max-conn 30

!

dial-peer voice 2 voip

description SIP Trunk with Bandwidth Restrictions!

session protocol sipv2

sess target ipv4:10.10.10.10

destination-pattern 123456789$

max-bandwidth 400

!

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

000308: Oct  5 19:01:02.603: %CALL_CONTROL-6-MAX_CONNECTIONS: Maximum number of connections reached for dial-peer 1

000309: Oct  5 19:01:02.603: %VOICE_IEC-3-GW: CCAPI: Internal Error (Dial-peer connections exceeded): IEC=10.1.181.1.21.0 on callID 0

000310: Oct  5 19:01:02.604: %SIP-3-MAXCONNCAC: Call rejected due to CAC based on maximum number of connections on dial-peer 1, sent response 503

000311: Oct  5 19:01:02.604: //17084/86B070800000/SIP/Msg/ccsipDisplayMsg:

Sent:

SIP/2.0 503 Service Unavailable

Via: SIP/2.0/TCP 10.50.244.62:5060;branch=z9hG4bKb78c35aa21b0

From: <sip:9001@10.50.244.62>;tag=72531~2e8ca155-3f0b-4f07-a1b2-b14ef77ceb7f-26250846

To: <sip:1234@10.50.245.70>;tag=3E19564D-1684

Date: Thu, 05 Oct 2017 19:01:02 GMT

Call-ID: 86b07080-9d61816e-b762-3ef4320e@10.50.244.62

CSeq: 101 INVITE

Allow-Events: telephone-event

Warning: 399 10.50.245.70 "Maximum Number of Connections reached for dial-peer 1"

Server: Cisco-SIPGateway/IOS-15.4.3.S4

Content-Length: 0

Discagem interna direta (DID)

Discagem em um estágio

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

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

Exemplo de configuração

!

dial-peer voice 1 pots

incoming called-number 8675309

voice-port 0/0/0

direct-inward-dial

!

Discagem em dois estágios

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

Exemplo de configuração

!

dial-peer voice 1 pots

incoming called-number 8675309

voice-port 0/0/0

no direct-inward-dial

!

Bloqueando chamadas

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

!

voice translation-rule 164

rule 1 reject /8675309/

!

voice translation-profile CALLBLOCK

translate calling 164

!

dial-peer voice 1 pots

desc INCOMING VOICE-PORT with BLOCK

translation-profile incoming ANOTHER

call-block translation-profile incoming CALLBLOCK

call-block disconnect-cause incoming invalid-number

incoming called-number .

port 0/0/0:23

!

Gateway#test voice translation-rule 164 8675309

8675309 blocked on rule 1

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

As duas opções são:

1. Bloqueie a chamada de coleta recebida com base na categoria II-8 recebida do switch telco. Esse é o mecanismo padrão e todos os Cisco Gateways executam isso sem nenhuma configuração. Esse método de bloqueio requer um switch telco mais novo que suporte a marcação baseada em categoria. Para desativar esse método, use o comando collect-call-enable no grupo cas-customer.

2. Utilize o recurso double-answer em um grupo cas-custom de E1 R2 digital R2. A configuração de resposta dupla desativa o bloqueio baseado em categoria e o substitui pelo recurso de resposta dupla. Isso funciona respondendo primeiro a chamada recebida e iniciando um temporizador de 1 segundo. Após 1 segundo, o gateway envia uma versão na forma de um comando CLEAR BWD. A Telco pode enviar um FWD LIMPO para o gateway e a chamada pode ser desconectada. Um temporizador é iniciado depois que o gateway envia o CLEAR BWD e, se esse temporizador expirar, o gateway enviará outro sinal de ATENDIMENTO, assumindo que a chamada não é uma chamada de coleta e, a partir daí, a chamada continua normalmente. Esse temporizador pode ser configurado usando cc-reanswer-to dentro do grupo cas-custom.

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

009228: Nov 21 12:02:00.955 GMT: //-1/BF12BE36BAC8/VTSP:(0/0/0:0):-1:1:2/vtsp_report_cas_digit:

Begin Digit=8, Mode=CC_TONE_R2_MF_BACKWARD_MODE

009229: Nov 21 12:02:00.955 GMT: htsp_digit_ready_up(0/0/0:0(2)): Rx digit='8'

009230: Nov 21 12:02:00.955 GMT: R2 Incoming Voice(0/0): DSX (E1 0/0/0:1): STATE: R2_IN_CATEGORY R2 Got Event 8

009231: Nov 21 12:02:00.955 GMT: Enter r2_comp_category

009232: Nov 21 12:02:00.955 GMT:  R2 Event : 8

009233: Nov 21 12:02:00.955 GMT:  #######R2_II8 TRUE########

009234: Nov 21 12:02:00.955 GMT:  ####### collect_call_enable = 0

009235: Nov 21 12:02:00.955 GMT:  ############sending B7 ##########

009236: Nov 21 12:02:00.955 GMT: r2_reg_generate_digits(0/0/0:0(2)): Tx digit '7'

009237: Nov 21 12:02:01.055 GMT: //-1/BF12BE36BAC8/VTSP:(0/0/0:0):-1:1:2/vtsp_report_cas_digit:

End Digit=8, Mode=CC_TONE_R2_MF_BACKWARD_MODE

009238: Nov 21 12:02:01.055 GMT: htsp_digit_ready(0/0/0:0(2)): Rx digit='#'

009239: Nov 21 12:02:01.055 GMT: R2 Incoming Voice(0/0): DSX (E1 0/0/0:1): STATE: R2_IN_CATEGORY R2 Got Event R2_TONE_OFF

009240: Nov 21 12:02:01.055 GMT: Enter r2_comp_category

009241: Nov 21 12:02:01.055 GMT: r2_reg_generate_digits(0/0/0:0(2)): Tx digit '#'

009242: Nov 21 12:02:01.359 GMT: htsp_dsp_message: SEND_SIG_STATUS: state=0x8 timestamp=22365 systime=225097425

009243: Nov 21 12:02:01.359 GMT: htsp_process_event: [0/0/0:0(2), R2_Q421_IC_WAIT_ANSWER, E_DSP_SIG_1000]

009244: Nov 21 12:02:01.359 GMT: r2_q421_ic_clr_fwd_idle(0/0/0:0(2)) Rx CLEAR FWD

009245: Nov 21 12:02:01.359 GMT: r2_reg_channel_disconnected(0/0/0:0(2))

009246: Nov 21 12:02:01.359 GMT: R2 Incoming Voice(0/0): DSX (E1 0/0/0:1): STATE: R2_IN_CATEGORY R2 Got Event R2_STOP

009247: Nov 21 12:02:01.359 GMT: Enter r2_comp_category

009248: Nov 21 12:02:01.359 GMT: htsp_timer - 2000 msec

009249: Nov 21 12:02:01.359 GMT: htsp_process_event: [0/0/0:0(2), R2_Q421_IC_CLR_FWD, E_HTSP_RELEASE_REQ]

009250: Nov 21 12:02:01.359 GMT: r2_q421_null_release(0/0/0:0(2)) E_HTSP_RELEASE_REQ

009251: Nov 21 12:02:01.359 GMT: r2_reg_process_event: [0/0/0:0(2), R2_REG_COLLECTING, E_R2_REG_DISCONNECT(91)]

009252: Nov 21 12:02:01.359 GMT: r2_reg_disconnect_collect(0/0/0:0(2))

009253: Nov 21 12:02:01.359 GMT: r2_reg_timer_stop(0/0/0:0(2))

009254: Nov 21 12:02:01.711 GMT: htsp_process_event: [0/0/0:0(1), R2_Q421_IC_CLR_FWD, E_HTSP_EVENT_TIMER]

009255: Nov 21 12:02:01.711 GMT: htsp_timer_stop

009256: Nov 21 12:02:01.711 GMT: r2_q421_clr_fwd_idle(0/0/0:0(1)) Tx IDLEvnm_dsp_set_sig_state:[R2 Q.421 0/0/0:0(1)] set signal state = 0x8

009257: Nov 21 12:02:01.711 GMT: r2_reg_channel_disconnected(0/0/0:0(1))

009258: Nov 21 12:02:01.711 GMT: //682206/0C63B263B9C9/VTSP:(0/0/0:0):0:1:1/vtsp_do_call_history:

Coder Rate=5

009259: Nov 21 12:02:01.711 GMT: r2_reg_process_event: [0/0/0:0(1), R2_REG_IDLE, E_R2_REG_DISCONNECT(91)]

Exemplo de Configuração com Resposta Dupla

!

controller e1 0/0/0

ds0-group 0 timeslots 1-15,17-31 type r2-digital r2-compelled ani

cas-custom 0

country brazil

double-answer

cc-reanswer-to 3000

!

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

### Answer the call and start a 1 second timer

May 23 09:52:59.180 BR: r2_q421_ic_answer(0/0/0:0(18)) Tx ANSWER seizure: delay 0 ms,elapsed 12404 msvnm_dsp_set_sig_state:[R2 Q.421 0/0/0:0(18)] set signal state = 0x4

May 23 09:52:59.180 BR: r2_reg_channel_connected(0/0/0:0(18))

May 23 09:52:59.180 BR: htsp_timer - 1000 msec

May 23 09:52:59.180 BR: //23899578/92233E71B421/CCAPI/cc_api_voice_mode_event:

Call Id=23899578

May 23 09:52:59.180 BR: //23899578/92233E71B421/CCAPI/cc_api_voice_mode_event:

Call Entry(Context=0x1E73AD8)

May 23 09:52:59.180 BR: htsp_process_event: [0/0/0:0(18), R2_Q421_IC_DOUBLE_ANS_ANS, E_HTSP_VOICE_CUT_THROUGH] all

May 23 09:52:59.184 BR: //23899578/92233E71B421/CCAPI/cc_process_notify_bridge_done:

Conference Id=0x10AD1, Call Id1=23899578, Call Id2=23899579

May 23 09:52:59.184 BR: r2_reg_process_event: [0/0/0:0(18), R2_REG_WAIT_FOR_CONNECT, E_R2_REG_CONNECT(90)]

May 23 09:52:59.184 BR: r2_reg_connect(0/0/0:0(18))

### One Second Passes and we clear the call and start a 2 second timer

May 23 09:53:00.180 BR: htsp_process_event: [0/0/0:0(18), R2_Q421_IC_DOUBLE_ANS_ANS, E_HTSP_EVENT_TIMER]

May 23 09:53:00.180 BR: r2_q421_ic_d_answ_answ_to(0/0/0:0(18)) E_TIMER_EVENT

May 23 09:53:00.180 BR: htsp_timer - 2000 msec

May 23 09:53:00.180 BR: r2_q421_ic_d_answ_answ_to(0/0/0:0(18)) Tx CLEAR BWDvnm_dsp_set_sig_state:[R2 Q.421 0/0/0:0(18)] set signal state = 0xC

May 23 09:53:00.824 BR: htsp_process_event: [0/0/0:0(18), R2_Q421_IC_DOUBLE_ANS_RLS, E_DSP_SIG_1000]

May 23 09:53:00.824 BR: r2_q421_ic_answer_clr_fwd(0/0/0:0(18)) Rx CLEAR FWD

May 23 09:53:00.824 BR: r2_reg_channel_disconnected(0/0/0:0(18))

May 23 09:53:00.824 BR: htsp_timer - 2000 msec

May 23 09:53:00.824 BR: r2_reg_process_event: [0/0/0:0(18), R2_REG_CONNECTED, E_R2_REG_DISCONNECT(91)]

May 23 09:53:00.824 BR: r2_reg_disconnect_idle(0/0/0:0(18))

May 23 09:53:00.824 BR: R2 Incoming Voice(0/0): DSX (E1 0/0/0:17): STATE: R2_IN_IDLE R2 Got Event R2_STOP

May 23 09:53:00.824 BR: r2_reg_timer_stop(0/0/0:0(18))

### 2 second passes and the gateway release the call

May 23 09:53:02.824 BR: htsp_process_event: [0/0/0:0(18), R2_Q421_IC_CLR_FWD, E_HTSP_EVENT_TIMER]

May 23 09:53:02.824 BR: htsp_timer_stop

May 23 09:53:02.824 BR: r2_reg_channel_disconnected(0/0/0:0(18))

May 23 09:53:02.824 BR: //23899578/92233E71B421/VTSP:(0/0/0:0):17:1:1/vtsp_cc_call_disconnected:

Cause Value=16

May 23 09:53:02.824 BR: //23899578/92233E71B421/CCAPI/cc_api_call_disconnected:

Cause Value=16, Interface=0xB41CEBC, Call Id=23899578

ISDN overlap-receiving

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

Número Chamado Vazio

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

Saída de exemplo

Gateway(config)# dial-peer voice 1 pots

Gateway(config-dial-peer)# incoming called-number T

Warning: Pattern T defines a match with zero or more digits and hence could

match with an empty number. If this is not the desired behaviour please

configure pattern .T instead to match on one or more digits

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

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

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

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

Classe de restrição

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

Duas regras importantes com classe de restrição:

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

2. Se não houver nenhuma lista de COR de entrada, a chamada será sempre roteada.

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

COR

Configurando a Classe de Restrições (COR)

LPCOR com CME

Exemplo de configuração do CME com LPCOR

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.

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