A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.
A finalidade deste documento é explicar o roteamento de chamada IO e IOS-XE e os mecanismos atrás do dial peer de entrada e de saída que combina com o serviço de telefonia tradicional (POTS) e a Voz sobre os trechos de chamada da rede IP (VoIP).
Além do que a informação do dial-peer esta assuntos importantes das capas de documento que se referem o roteamento de chamada. Estes incluem a Manipulação de dígitos, uma visão rápida da manipulação da mensagem do Session Initiation Protocol (SIP), alguns métodos para restringir capacidades de chamada, um media rápido e a sinalização de vista geral obrigatória, e ultimamente de um bit do Troubleshooting.
Este documento utiliza exemplos de configuração assim como saídas do comando debug and show como pontos de referência. Muitas características neste documento são identificadas claramente por meio da versão que a característica foi introduzida aos IO e ao IOS-XE. Esta informação pode igualmente ser provida rapidamente verificando a seção do mapa rodoviário do comando e da característica. Se há um defeito muito notável está ligado dentro do texto de modo que os leitores estejam cientes.
Contribuído por Kyzer Davis e editado por Ramiro Amaya, engenheiros de TAC da Cisco
Quando não houver nenhuma condição prévia formal necessária ler este documento; escreveu-se com a expectativa que o leitor já tem algum conhecimento em funcionamento dos protocolos de sinalização de voz subjacentes que são usados para estabelecer e conectar chamadas telefônica. Estes protocolos são providos muitas vezes durante todo o livro.
Protocolos de sinalização: Session Initiation Protocol (SIP), H323 (h225/h245), Media Gateway Control Protocol (MGCP), protocolo skinny client control (SCCP), Q931 DE ISDN, E1 R2.
Protocolos dos media: Real-Time Protocol (RTP), codecs da Voz, codecs video.
Tecnologias análogas: Ear and mouth (E&M), subscritor do câmbio internacional (FXS) e escritório de câmbio internacional (FXO).
A informação neste documento é baseada nestes software e hardware:
Cisco IOS e gateways IOS-XE
2800/3800/2900/3900/4300/4400/CSR1000v/ASR100X
As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a sua rede estiver ativa, certifique-se de que entende o impacto potencial de qualquer comando.
Atributo | Descrição |
---|---|
Corda do dígito |
Igualmente referido como a série numérica, o número de telefone, o número, ou o número E164. Consiste entirerly nos dígitos 0 com 9 com uma condução opcional mais o símbolo (+).
|
Dialed Number Identification Service (DNIS) | Este é o número chamado ou o número de destino para um atendimento. |
Identificação de número automática (ANI) | Este é o número chamado ou o número chamado de origem para um atendimento. Isto pode igualmente ser referido como o identificador da linha de chamada (CLID) que pode igualmente ser intitulado o ID de chamada |
Identificador de recurso uniforme (URI) |
Um URI é qualquer um um o sorvo: ou telefone: corda a mais de uso geral com SORVO e H323 dos protocolos de VoIP.
|
ID de portadora |
Exemplos CID: Nota: O ID de portadora |
Rota-corda |
Um encabeçamento proprietário de Cisco para as Rota-cordas ILS usadas com SORVO.
|
ENUM | O ENUM é um protocolo que use o Domain Name Service (DNS) para traduzir os números de telefone E164 em URI. Esta não deve ser coberta neste documento. |
PSTN | Rede telefônica pública comutada |
ITSP |
Provedor de serviços da telefonia pelo Internet |
SBC |
Controlador de limite de sessões. Este é o dispositivo que está como o ponto de demarcação entre um cliente LAN e uma rede ITSP/PSTN |
Recurso | Versão do IOS | Versão IOS-XE |
Expansão do número (NUM-Exp) Dial peers (POTENCIÔMETROS e VOIP) resposta-endereço destino-teste padrão chamar-número entrante destino de sessão (IPv4 e DNS) Conexões máximas (MAX-CONN) direct-inward-dial dianteiro-dígitos (POTENCIÔMETROS) prefixo (POTENCIÔMETROS) intervalos entre dígitos (porta de voz) |
11.3(1)T | Todos |
terminal do dial-peer |
12.0 | Todos |
huntstop |
12.0(5)T | Todos |
Mapas ISDN | 12.0(6)T | Todos |
Dial-peer que caça esquemas |
12.0(7)XK | Todos |
Regra de tradução e perfil da Voz traduzir-que parte numeração-tipo dígito-tira (POTENCIÔMETROS) |
12.0.(7)XR1 | Todos |
destino de sessão (sorvo-server) | 12.1(1)T | Todos |
Grupo de troncos dos POTENCIÔMETROS | 12.1(3)T | Todos |
DNIS-mapa (de partida) |
12.2(2)XB |
Todos |
tronco-grupo-etiqueta |
12.2(11)T |
Todos |
Dial-peer (dados) |
12.2(13)T |
Todos |
Classe URI da Voz (de partida) | 12.3(4)T |
Todos |
destino de sessão (IPv6) | 12.4(22)T |
Todos |
Perfis do SORVO (de partida) | 15.0(1)M |
Todos |
Classe URI da Voz (de entrada) |
15.1(2)T |
3.8S |
SORVO Copylist destino de sessão (escrivão) |
15.1(3)T |
3.6S |
atendimento-rota (URL) |
15.2(1)T |
3.3S |
MAX-largura de banda |
15.2(2)T |
3.7S |
E164-Pattern-Maps (de partida) | 15.2(4)M | 3.7S |
Rota-corda da classe da Voz atendimento-rota (dest-rota-corda) |
15.3(3)M | 3.10S |
Grupos do dial-peer (VOIP) E164-Pattern-Maps (de entrada) Grupo de servidor de destino requri-passagem destino de sessão (sorvo-URI) |
15.4(1)T |
3.11S |
Política da provisão de dial peer Sorvo-perfis (de entrada) |
15.4(2)T | 3.12S |
Grupo do dial-peer (POTENCIÔMETROS) | 15.5(1)T | 3.14S |
Inquilinos da classe da Voz | 15.6(2)T | 16.3.1 |
VRF que filtra para o dial peers | 15.6(3)M | 16.3.1 |
O Cisco IOS e os gateways IOS-XE utilizam um conceito de um dial-peer para controlar o roteamento de chamada e a negociação de potencialidades para cada pé de um atendimento. Um trecho de chamada é a comunicação bi-direcional entre dois agentes do atendimento. Um agente do atendimento é um dispositivo que inicie, processos, ou para a frente chamadas de telefonia. Isto pode ser e não é limitado ao equipamento do provedor de telefonia, a um Cisco gateway, a um telefone IP, a um gerente unificado Cisco de uma comunicação (CUCM), ao Cisco Unity Connection (CUC), etc. Há distante agentes demais do atendimento a alistar.
Encenação: Um atendimento que chega em um Cisco gateway de um outro agente do atendimento é o trecho de chamada recebida (em-pé). Os processos de gateway o atendimento e baseado no seu processamento enviam o atendimento ao agente seguinte do atendimento. Este é o trecho de chamada de saída (para fora-pé).
A imagem 1 mostra um atendimento do PSTN ao roteamento CUCM com um cisco voice gateway e a informação respectiva do trecho de chamada de entrada e saída.
Imagem 1 - Trechos de chamada de entrada e saída ilustrados
Uma chamada bem sucedida através de um Cisco gateway ALWAYS* combina um de entrada ou um dial peer de saída para distribuir corretamente. Os dial peer de entrada e de saída são similares aos trechos de chamada mencionados mais cedo. Na imagem 1 o atendimento que chega do PSTN no Cisco gateway precisa de combinar um dial peer de entrada. Então o gateway utiliza um dial peer de saída para distribuir o atendimento ao agente seguinte do atendimento. É importante recordar que estes termos estão definidos da perspectiva do Cisco gateway.
Combinando um dial-peer para cada lado do atendimento um administrador tem a potência controlar muitos aspectos do um trecho de chamada específico. Os exemplos destes incluem codecs da Voz, preferências DTMF, Manipulação de dígitos, onde o atendimento deve ser distribuído e muitos muitos outros ajustes. O dial peers pode ser configurado com instruções compatível de entrada e de partida assim que combinar o mesmo dial-peer para o em-pé e o para fora-pé é possível se uma configuração de harmonização de entrada e de partida válida é aplicada a esse dial-peer específico.
*O a exceção a esta regra é com portas de voz MGCP e SCCP. Estes protocolos de sinalização não seguem o mecanismo normal da correspondência de dial peer durante o roteamento de chamada. Veja a seção SCCP e MGCP para uns detalhes mais adicionais
A imagem 2 ilustra os mesmos trechos de chamada de entrada e saída que a imagem 1 mas com o dial peers respectivo para um atendimento do PSTN ao roteamento CUCM através de um cisco voice gateway.
Imagem 2 - Dial peer de entrada e de saída ilustrados
Os ciscos voices gateways podem colaborar muitos tipos diferentes de chamadas de voz e de protocolos que incluem o IP ao IP, POTENCIÔMETROS aos POTENCIÔMETROS e IP aos POTENCIÔMETROS ou vice versa.
A imagem 3 ilustra VoIP à chamada VoIP através do Cisco Unified Border Element (CUBO).
Imagem 3 - Dial peer de entrada e de saída para um Voip à chamada VoIP
A imagem 4 indica POTENCIÔMETROS à chamada de pots através de um Cisco gateway.
Imagem 4 - Dial peer de entrada e de saída para POTENCIÔMETROS à chamada de pots
POTENCIÔMETROS | O dial peers velho liso do serviço de telefonia é combinado para conexões analógicas tais como FXS Analógico, o FXO, o ISDN T1/E1, o E1 R2, e o ear and mouth (conexões E&M). Estes enviam ou recebem um atendimento para/desde uma porta de voz física no gateway. |
VOIP | A Voz sobre o dial peers IP é usada para controlar principalmente H323 e SORVER conexões a e do gateway. Este dial peers envia e recebe a sinalização do IPv4 e do IPv6 IPs assim como os nomes de domínio totalmente qualificados (FQDN) que usam o Domain Name System (DNS). --- Os VoIP dial-peer podem igualmente ser usados para a voz sobre o Frame Relay (VOFR), o Voz sobre ATM (VoATM), a Voz sobre o High-Level Data Link Control (VoHDLC) e o registro, a admissão, e a sinalização e os destinos de sessão do estado (RAS) para este dial peers podem igualmente incluir pagamentos e valores ENUM. Nota: Alguns destes tipos de configurações são umas Tecnologias mais velhas não vistas em umas redes mais novas e com IOS-XE alguns são apoiados já não. Em consequência não devem ser coberta neste documento. |
MMOIP | O dial peers do email multimídia sobre IP é utilizado para enviar email aos serveres de câmbio. Estes são utilizados na maior parte para t37 o on-ramp/off-ramp faxing. Estes tipos do dial-peer não são no âmbito deste documento. |
Nota: O número máximo de dial peers que pode ser configurado em um Cisco gateway depende da memória disponível (DRAM). Cada dial-peer consome aproximadamente 6KB da memória assim que assegure-se de que o gateway tenha pelo menos 20% da memória total reservada para outros processos de CPU. Um grande número dial peer configurados podem adicionar ao atraso para distribuir um atendimento. Isto pode ser significativo como o aplicativo de voz de Cisco olha com o dial peers de cima para baixo, similar a um Access Control List (ACL). Este não é geralmente um problema em Cisco gateway do nwere.
17290095: May 26 12:59:46.406: %DIALPEER_DB-3-ADDPEER_MEM_THRESHOLD: Addition of dial-peers limited by available memory
Quando um Cisco gateway recebe uma requisição de configuração de chamada o gateway começa a procurar por um dial peer entrante aplicável para este atendimento. Esta não é uma análise de dígito por dígito a mensagem completa é utilizada um pouco que para determinar que dial peer de entrada é selecionado. A ordem de artigos na mensagem verificada é pela maior parte dependente do protocolo para o atendimento como indicado pelas lista da preferência definidas nas tabelas 1 a 3. Um dial-peer precisa somente de satisfazer uma das condições para combinar. Não é necessário que todos os atributos seja configurado no dial peer ou que cada fósforo do atributo a informação da configuração de chamada. Todos os dial peer são procurados basearam nos primeiros critérios de verificação de repetição de dados. O gateway move-se sobre para os critérios seguintes somente se nenhum fósforo é encontrado.
Preferência de entrada da seleção do dial-peer do SORVO da tabela 1.
Preferência |
Critérios de verificação de repetição de dados |
Dial-peer Commands* |
1 |
URI |
uri entrante através do <uri-tag> <uri-tag> entrante do pedido do uri uri entrante ao <uri-tag> uri entrante do <uri-tag> |
2 |
Número chamado |
<number-string> entrante do chamar-número <pattern-map-number> chamado entrante e164-pattern-map |
3 | Número chamado |
<pattern-map-number> de chamada entrante e164-pattern-map <number-string> do resposta-endereço |
4 | Destino-teste padrão (ANI) | <number-string> do destino-teste padrão |
5 | ID de portadora | <string> da fonte do ID de portadora |
Preferência de entrada da seleção do dial-peer de H323 da tabela 2.
Preferência | Critérios de verificação de repetição de dados |
Dial-peer Commands* |
1 | URI | o uri entrante chamou o <uri-tag> uri entrante que chama o <uri-tag> |
2 | Número chamado | <number-string> entrante do chamar-número <pattern-map-number> chamado entrante e164-pattern-map |
3 | Número chamado | <pattern-map-number> de chamada entrante e164-pattern-map <number-string> do resposta-endereço |
4 |
Destino-teste padrão (ANI) |
<number-string> do destino-teste padrão |
5 |
ID de portadora |
<string> da fonte do ID de portadora |
Preferência da seleção do dial-peer do POTS de entrada da tabela 3.
Preferência | Critérios de verificação de repetição de dados | Dial-peer Commands* |
1 | Número chamado | <number-string> entrante do chamar-número |
2 | Número chamado | <number-string> do resposta-endereço |
3 | Destino-teste padrão (ANI) | <number-string> do destino-teste padrão |
4 | Porta de voz | <voice-port-number> da porta |
Quando nenhum fósforo existir/dial peer padrão 0 peer_tag=0, pid:0
Quando há nenhum eliglbe combina para um dial peer de entrada para ou POTENCIÔMETROS ou as chamadas VoIP o gateway atribuem o dial-peer 0. Isto não é ideal porque o dial-peer 0 limitou capacidades e pode causar edições com atendimentos. O outlier a este é SCCP e protocolos de MGCP que não usam o dial peers para chamadas de roteamento. Veja a seção MGCP e SCCP para uns detalhes mais adicionais.
dial-peer 0 capacidades
Os dial peer de saída são utilizados para distribuir POTENCIÔMETROS ou chamadas VoIP do gateway ao agente seguinte do atendimento. Como o dial peer de entrada combinar lá é uma lista de artigos que o gateway pode se usar para combinar o dial peers baseou na ordem da preferência para o protocolo específico. Contudo, ao contrário dos dial peer de entrada, se não há nenhum dial peer de saída elegível para distribuir o atendimento o atendimento a seguir falha. Como o dial peer de entrada que combina todos os dial peer são procurados basearam nos primeiros critérios de verificação de repetição de dados. O gateway move-se sobre para os critérios seguintes somente se nenhum fósforo é encontrado.
Preferência de partida da seleção do dial-peer do SORVO da tabela 4.
Preferência | Critérios de verificação de repetição de dados | Dial-peer Commands* |
1 | Dial-peer do grupo do dial-peer |
<dpg-tag> do dpg do destino (configurado no dial peer de entrada) |
2 | Corda da rota ILS | <route-string-tag> da rota-corda do destino |
3 | URI e ID de portadora | <uri-tag> do uri do destino E <string> do alvo do ID de portadora |
4 | Número chamado e ID de portadora | <number-string> do destino-teste padrão E <string> do alvo do ID de portadora |
5 | URI | <uri-tag> do uri do destino |
6 | Número chamado |
<DNIS-number> do destino-teste padrão <pattern-map-number> do destino e164-pattern-map <dnis-map-number> do DNIS-mapa |
7 | Política URI da provisão de dial peer | destino URI-do <uri-tag> destino URI-ao <uri-tag> destino URI-através do <uri-tag> <uri-tag> da URI-diversão do destino destino URI-consultar-pelo <uri-tag> |
8 | Número chamado | destino que chama o <pattern-map-number> e164-pattern-map |
Preferência de partida da seleção do dial-peer de H323 da tabela 5.
Preferência | Critérios de verificação de repetição de dados | Dial-peer Commands* |
1 | Dial-peer do grupo do dial-peer |
<dpg-tag> do dpg do destino (configurado no dial peer de entrada) |
2 | URI e ID de portadora | <uri-tag> do uri do destino E alvo do ID de portadora que <string |
3 | Número chamado e ID de portadora | <number-string> do destino-teste padrão E <string> do alvo do ID de portadora |
4 | URI | <uri-tag> do uri do destino |
5 | Número chamado |
<number-string> do destino-teste padrão <pattern-map-number> do destino e164-pattern-map <dnis-map-number> do DNIS-mapa |
6 | Número chamado | destino que chama o <pattern-map-number> e164-pattern-map |
Preferência da seleção do dial-peer do POTS externo da tabela 6.
Preferência | Critérios de verificação de repetição de dados | Dial-peer Comamnds* |
1 | Dial-peer do grupo do dial-peer |
<dpg-tag> do dpg do destino (configurado no dial peer de entrada) |
2 | URI e ID de portadora |
<uri-tag> do uri do destino E <string> do alvo do ID de portadora |
3 | Número chamado e ID de portadora | <number-string> do destino-teste padrão E <string> do alvo do ID de portadora |
4 | URI |
<uri-tag> do uri do destino |
5 | Número chamado |
<DNIS-número do destino-teste padrão > <map-number> do DNIS-mapa |
Nota: * Os comandos all dentro de cada pilha dos comandos dial-peer são semelhante tratado no peso. O dial-peer da série numérica que caçam e o dial-peer URI que caça a seção entram em como o gateway avalia uma lista de comandos potenciais para o cada critérios de verificação de repetição de dados enfileira antes de se mover para os critérios de verificação de repetição de dados seguintes. isto é avaliando todos os fósforos do potencial URI e comandos de harmonização URI antes de olhar o número chamado.
Preferência da série numérica:
Bem como URI tenha um ordem de operação específico para fósforos do evaluationg lá é igualmente um conjunto de regras usado ao avaliar uma dígito-corda numérica. O esquema da caça do dial peer padrão para é ajustado a 0. Isto significa as buscas do gateway para um teste padrão com o fósforo o mais longo (o mais específico). Se há dois dial peers com o mesmo comprimento do fósforo o olhar do gateway na preferência explicitamente definida do dial-peer. Ultimamente se ambos os aqueles são os mesmos escolhe um em uma ordem aleatória.
Há outros esquemas da caça do dial-peer disponíveis para a configuração contudo que a maioria de deploymens mantêm o padrão de 0. Se o dial peers que está sendo combinado fora da ordem do padrão um administrtor examinar a configuração running para um esquema não-padrão da caça do dial-peer.
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 fósforo o mais longo é definido como o fósforo o mais específico baseado no número possível de números que a corda poderia combinar.
Encenação: O dial peers elegível foi configurado com os seguintes fósforos possíveis e o gateway está avaliando uma dígito-corda de 2001. O dial-peer 1 pode combinar todo o número 2000 a 2999 quando o dial-peer 2 puder combinar 2000 a 2009. o dial-peer 2 seria combinado para este atendimento porque é o fósforo o mais longo (o mais específico) para a corda 2001 do dígito em que os mecanismos da caça do dial peer padrão são empregados (caça 0 do dial-peer).
!
dial-peer voice 1 voip
destination-pattern 2...
!
dial-peer voice 2 voip
destination-pattern 200.
!
A preferência é definida como o peso definido administrador para cada dial-peer. Os administradores podem configurar uma preferência assim que o uso do atendimento sempre um dial-peer específico antes de outro. À revelia todo o dial peers é a preferência 0. Um dial-peer com preferência 0 é combinado antes de um outro dial-peer com o preference 1 com o 10. A maioria de administradores setup dial peer múltiplos para enviar um atendimento a um subscritor específico CUCM com um subscritor alternativo ou um outro agente do atendimento que estão sendo configurados um outro dial-peer com uma preferência inferior.
Encenação: Dois dial peers são configurados com o mesmo comprimento do fósforo para a corda do dígito de 2001. O administrador definiu uma preferência explícita. O gateway avalia ambo o dial peers o mesmos desde que seu comprimento do fósforo é o mesmo. Contudo o administrador ajustou o dial-peer 1 com uma preferência maior de modo que o dial-peer fosse escolhido como o primeiro dial-peer usado em distribuir o atendimento. o dial-peer 2 permaneceria porque uma opção secundária se uma falha ocorrer no primeiro dial-peer.
!
dial-peer voice 1 voip
destination-pattern 2...
preference 1
!
dial-peer voice 2 voip
destination-pattern 2...
preference 2
!
Uma tentativa do Cisco gateway somente de distribuir um atendimento através de um dial peer de saída elegível de cada vez. Se uma condição de falha observada no primeira selecionou o dial-peer o gateway a seguir tenta distribuir chamar o dial-peer elegível seguinte. Isto continua até que o atendimento suceda ou falhe porque não há não mais dial peers elegível deixado para tentar. Os sintomas comuns da caça e da falha do dial-peer são um retardo notável no ringback ao fazer chama. Debugs é precisado geralmente de verificar exatamente porque o atendimento está falhando no dial peers primeiro antes finalmente de trabalhar através de outro. O comando huntstop pode ser empregado em um dial-peer se um administrador não quer um gateway procurar um outro dial-peer quando uma condição de falha está observada.
Encenação: Dois dial peers são configurados com o mesmo comprimento do fósforo para a corda do dígito de 2001. O administrador definiu uma preferência explícita e não a quer combinar o dial-peer 2 para este atendimento particular. Desde que nós temos dois dial peers com o mesmo fósforo-comprimento a preferência é usada para determinar o dial-peer usou-se. O dial-peer 1 tem uma preferência configurada é usado para distribuir o atendimento. Se uma condição de falha ocorre no trecho de chamada de saída usando o dial-peer 1 então o dial-peer da parada do gateway imediatamente que caça desde que o comando huntstop está configurado. Assim em nossa encenação o dial-peer 2 é utilizado nunca para o roteamento de partida.
! dial-peer voice 1 voip destination-pattern 2... preference 1 hunstop ! dial-peer voice 2 voip destination-pattern 2... preference 2 !
Nota: o hunstop e os comandos preference podem igualmente ser usados conjuntamente com indicações de harmonização URI.
O gateway olha cada critérios de verificação de repetição de dados antes e esgota-os antes que se mova para os critérios de verificação de repetição de dados seguintes. Um exemplo deste estaria no atendimento de entrada do SORVO. Nós sabemos que a primeira coisa as verificações do Cisco gateway é o URI e avaliamos todos os comandos do potencial URI encontrar um que cabe. Se não há nenhum fósforo OU nenhuns estão configurados então o gateway se movem para o artigo de harmonização seguinte, execute uma avaliação nos critérios. As repetições deste processo até as rotas do atendimento baseadas em um fósforo ou o gateway são executado fora dos critérios de verificação de repetição de dados para verificar.
Quando um de entrada ou um dial peer de saída são configurados com um comando URI aplicou o gateway examina o URI que foi recebido em encabeçamentos múltiplos para um potencial combina. A preferência do fósforo é baseada no fósforo o mais específico e a preferência exata vai fósforo URI, parcela do host, parcela do usuário, ou o telefone completo URI. Conhecer o ordem de operação para a harmonização URI pode ajudar extremamente na correspondência de dial peer com disposições do SORVO e do CUBO.
Esta ordem da preferência pode ser manipulada usando a preferência do sorvo do uri da classe da Voz do comando para especificar a USER-identificação como a primeira opção em vez do host.
Preferência URI:
Encenação: Um administrador tem a configuração do dial-peer abaixo e envia um atendimento ao gateway. Do encabeçamento no nosso recebido CONVIDE é “de: <sip:testuser@10.10.10.10>” o gateway pode combinar potencialmente o dial peers diferente do fósforo dois baseado neste encabeçamento. dial-peer 1 baseado na parcela do usuário e dial-peer 2 baseado na parcela do host. Contudo desde que um fósforo do host é uma preferência acima de um dial-peer 2 do fósforo do usuário é usada para o dial peer de entrada em nosso atendimento.
! voice class uri URI-1 sip user-id testuser ! voice class uri URI-2 sip host ipv4:10.10.10.10 ! dial-peer voice 1 voip sess protocol sipv2 incoming uri FROM URI-1 ! dial-peer voice 2 voip sess protocol sipv2 incoming uri FROM URI-2 !
O URI que combina para dial peer de entrada e de saída permite a um administrador a capacidade e a flexibilidade para executar fósforos em mais do que uma corda do número de telefone para os protocolos de VoIP que apoiam URI em sua Mensagem. Antes de IO 15.4(1)T e de IOS-XE 3.11S um pedido URI deve conter “user@host alfanumérico” mais que um Cisco gateway rejeitaria o atendimento com uma mensagem 4xx. Agora um URI pode conter apenas a parcela do host e as rotas de gateway que o atendimento baseado apenas no host forneceu. isto é sorvo: cisco.com.
Adicionalmente, antes os USER-ids da Voz-classe URI IO 15.4(1)T e IOS-XE 3.11S poderiam somente ser os valores e.164 numéricos (sip:1234@host.com). Isto foi mudado assim que os administradores podem configurar USER-ids alfanuméricos no CUBO (sorvo: user@host.com)
A parcela do host ou do usuário de um uri da classe da Voz pode conter testes padrões do regex que expanda extremamente os valores possíveis que podem ser combinados.
Gateway(config-voice-uri-class)#user-id .) % unmatched ()user-id pattern should be of format ^([][0-9A-Za-z\|\/()*+^$&?#--.])*$
Gateway(config-voice-uri-class)#host .)
% unmatched ()host pattern should be of format ^([][0-9A-Za-z\|@\/()*+^$&?#--.])*$
KYDAVIS-CME-2951(config-voice-uri-class)#pattern .)
% unmatched ()pattern pattern should be of format ^([][0-9A-Za-z\|@;:=%!~\/()*+^$&?#--.])*$
Classe URI da Voz do exemplo
! voice class uri HOST sip host webex.com host dns:cisco.webex.com host ipv4:14.50.244.2 host ipv6:[2001:4860:4860::8888] ! voice class uri USER sip user-id username ! voice class uri PATTERN sip pattern 8675309 ! voice class uri HostRegex sip host host (.*)cisco.com ! voice class uri PatternRegex sip pattern 555(.*) ! voice class uri UserRegex sip user-id test(.*) !
Nota: Somente os anfitriões 10, 1 teste padrão, ou 1 USER-identificação podem ser configurados pelo uri dos clas da Voz.
Gateway(config)#voice class uri TEST sip Gateway(config-voice-uri-class)#host ipv4:1.1.1.1 Gateway(config-voice-uri-class)#host ipv4:2.2.2.2 Gateway(config-voice-uri-class)#host ipv4:3.3.3.3 Gateway(config-voice-uri-class)#host ipv4:4.4.4.4 Gateway(config-voice-uri-class)#host ipv4:5.5.5.5 Gateway(config-voice-uri-class)#host ipv4:6.6.6.6 Gateway(config-voice-uri-class)#host ipv4:7.7.7.7 Gateway(config-voice-uri-class)#host ipv4:8.8.8.8 Gateway(config-voice-uri-class)#host ipv4:9.9.9.9 Gateway(config-voice-uri-class)#host ipv4:10.10.10.10 Gateway(config-voice-uri-class)#host ipv4:11.11.11.11 Error:Maximum of 10 hosts can only be configured. Gateway(config)#voice class uri TEST2 sip Gateway(config-voice-uri-class)#host dns:1.com Gateway(config-voice-uri-class)#host dns:2.com Gateway(config-voice-uri-class)#host dns:3.com Gateway(config-voice-uri-class)#host dns:4.com Gateway(config-voice-uri-class)#host dns:5.com Gateway(config-voice-uri-class)#host dns:6.com Gateway(config-voice-uri-class)#host dns:7.com Gateway(config-voice-uri-class)#host dns:8.com Gateway(config-voice-uri-class)#host dns:9.com Gateway(config-voice-uri-class)#host dns:10.com Gateway(config-voice-uri-class)#host dns:11.com Error:Maximum of 10 hosts can only be configured. Gateway(config)#voice class uri TEST3 sip Gateway(config-voice-uri-class)#user-id 8675309 Gateway(config-voice-uri-class)#user-id 123456789 Gateway(config-voice-uri-class)#do sh run | s TEST3 voice class uri TEST3 sip user-id 123456789 Gateway(config)#voice class uri TEST4 sip Gateway(config-voice-uri-class)#pattern 8675309 Gateway(config-voice-uri-class)#pattern 123456789 Gateway(config-voice-uri-class)#do sh run | s TEST4 voice class uri TEST4 sip pattern 123456789
Esta característica foi adicionada em IO 15.1(2)T e em IOS-XE 3.8S e utiliza um uri da classe da Voz configurado e aplicado a um dial peer de entrada. O URI entrante foi adotado por muitos clientes sobre a indicação entrante tradicional do chamar-número para atendimentos do SORVO como ele que os primeiros critérios de verificação de repetição de dados verificaram ao selecionar dial peer de entrada. O comando igualmente permite a administradores a capacidade os melhores atendimentos do fósforo que vêm de um agente ou de um usuário particular do atendimento.
Documentação completa: http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-inbnd-dp-match-uri.html
Casos de utilização comum
Exemplo de configuração
O dial-peer abaixo 777 dos fósforos das saídas de exemplo para alguma fonte do pedido do SORVO dois do HOST IPs definido no uri da classe da Voz. O encabeçamento que está sendo olhado foi definido como do encabeçamento no dial-peer contudo que um administrador pode definir muito outro que inclui ATRAVÉS DE, A, e o PEDIDO (pedido URI). Se meu CUCM envia as OPÇÕES sibilam ao CUBO combinam agora o dial-peer 777 e fonte que meus 200 APROVADOS responda às OPÇÕES da interface especificada. Se meu CUCM envia um CONVITE ao CUBO combina o dial-peer 777 como o dial peer de entrada.
! voice class uri CUCM sip
host ipv4:14.50.244.2
host ipv4:14.50.244.20 ! dial-peer voice 777 voip description INCOMING URI session protocol sipv2 incoming uri from CUCM voice-class sip bind control source-interface Loopback777 voice-class sip bind media source-interface Loopback777 !
Os Cisco IOS gateway podem combinar um dial peer de saída que usa um URI aplicando um uri da classe da Voz a um dial peer de saída. Esta característica foi adicionada em IO 12.3(4)T e esta presente em todas as versões IOS-XE. À revelia o SORVO que parte Pedido-URI e ao encabeçamento URI está indo ter o destino de sessão do dial peer de saída. Isto pode ser desabilitado usando a requri-passagem do comando que permite que o gateway passe a parcela do host do em-pé URI ao para fora-pé em vez de substituir a parcela do host URI com o sessão-alvo. A requri-passagem do comando foi adicionada em 15.4(1)T e em IOS-XE 3.11S.
Exemplo de configuração
! voice class uri CUCM sip
host dns:cucm.com ! dial-peer voice 777 voip description OUTGOING URI session protocol sipv2 destination uri CUCM !
Além do que os administradores dos uri da classe da Voz pode usar uma disposição-política do dial-peer para combinar um em-pé URI para uma correspondência de dial peer de saída. Esta característica foi adicionada em IO 15.4(2)T e em IOS-XE 3.12S. Uma disposição-política do dial-peer exige a definição de um atributo preliminar do fósforo com um atributo secundário do fósforo que é opcional. A disposição-política é aplicada a um dial peer de entrada e quando esse dial-peer é selecionado para o uso em um trecho de chamada recebida a política é invocada. O resultado é uma seleção do dial peer de saída baseada no atributo da disposição-política do dial-peer.
Exemplo de configuração:
Este exemplo de configuração distribui a utilização da chamada recebida do encabeçamento na mensagem do SORVO do em-pé. Note por favor que embora nós estejamos distribuindo chamar do encabeçamento o CONVITE que sae do gateway ainda tem a solicitação original URI. Nós escolhemos somente o dial-peer baseado no do encabeçamento. O atendimento está sendo enviado ainda a um destino específico enquanto se recebeu que maneira. Assim no exemplo abaixo nós recebemos um CONVITE com os seguintes dois encabeçamentos:
CONVIDE sip:123456789@10.10.10.10:5060 SIP/2.0
De: sip:8675309@webex.com
O gateway está indo combinar o dial-peer 1234 baseado na indicação entrante do chamar-número porque não há nenhuma indicação entrante URI. Nós temos uma política da disposição no lugar para verificar do encabeçamento. Nós olhamos agora do encabeçamento ao fazer uma escolha sobre o dial peer de saída. Nós vemos um host de webex.com no do encabeçamento. Isto combina com o dial-peer 56789 assim que nós estamos indo distribuir o atendimento usando este dial-peer.
A mensagem do SORVO as folhas o gateway:
CONVIDE sip:123456789@cisco.com:5060 SIP/2.0
De: sip:8675309@webex.com
Note como o número chamado original de 123456789 permanece. A parcela do host muda para ser aquela do destino de sessão no dial-peer. Nós distribuímos o atendimento através do do encabeçamento mas a mensagem da saída é ainda para 123456789.
! voice class dial-peer provision-policy 1 preference 1 from to ! voice class uri FROM sip host dns:webex.com ! dial-peer voice 1234 voip session protocol sipv2 destination provision-policy 1 incoming called-number . ! dial-peer voice 12345 voip session protocol sipv2 destination uri-from FROM
session target dns:cisco.com !
destino de sessão sorvo-URI
Antes de IO 15.4(1)T e de IOS-XE 3.11S se a parcela do host de um URI era diferente mas usuário era o mesmo isto exigiria dois dial peer de saída separados.
Após esta liberação um administrador pode configurar um dial-peer para prestar serviços de manutenção a host múltiplos para o mesmo usuário. isto é testuser@cisco.com e testuser@webex.com sob o mesmo dial-peer. Usando a resolução de DNS dos disparadores do sessiontarget sorvo-URI do domínio de entrante CONVIDE O REQ-URI e determine dinamicamente o IP do destino de sessão.
Exemplo de configuração:
O gateway recebe dois SORVOS convida com os seguintes encabeçamentos CONVIDA sip:testuser@cisco.com:5060 SIP/2.0 CONVIDA sip:testuser@webex.com:5060 SIP/2.0 que o gateway combina o pedido entrante do SORVO de testuser@cisco.com e testuser@webex.com no dial-peer 1 devido o comando entrante do uri e à definição USER-identificação ambos fósforo “usuário de teste”. Estar presente da atendimento-rota URL do sorvo da Voz-classe do comando significa que nós avaliamos os dial peer de saída baseados no pedido URI deste de entrada CONVIDAMOS. Desmama-nos combinam o dial-peer 2 devido às mesmas razões que nós combinamos o dial-peer 1, a USER-identificação do “usuário de teste”. O destino de sessão deste dial-peer é o sorvo-URI original como definido pelo “destino de sessão sorvo-URI” que era um FQDN. Depois que uma resolução de DNS ocorreu e cisco.com e webex.com da mudança em um IP para o roteamento da camada 3 nós enviamos uma mensagem 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
Um administrador pode utilizar convites do dial-peer ao definir os mecanismos de harmonização de entrada e de partida que envolvem uma série numérica. Estes incluem o destino-teste padrão, chamar-número entrante, e164-pattern-maps, e resposta-endereço assim como o comando prefix. Os wilcards do dial-peer são as expressões regulares (regex) disponíveis para a configuração que permitem a maior flexibilidade sobre a harmonização do dial peers.
Tabela do convite
Caractere | Definição | Exemplos |
* | Em um dial-peer este é um valor literal de * (estrela) no teclado numérico. | 12345* |
# | Em um dial-peer este é um valor literal de # (libra) no teclado numérico. | 8675309# |
, |
Introduz uma 1 segundo pausa entre dígitos. Uma vírgula pode igualmente ser usada dentro do [] dos suportes para quebrar acima uma escala contínua. |
9,,,,,555 91[1-3,5-9]8675309 |
. |
O caráter de Regex para combinar alguns avalia 0-9, A-F e *, #, + Acima dos caráteres de ponto do pequeno 15 pode ser definido pelo dial-peer embora o CLI deixe um administrador configurar o tanto como enquanto vê o ajuste. Se mais de 15 pontos são requiree por favor use o T. |
2…. 91[2-9]..[2-9] ...... |
% | Regex para o dígito procedente zero de ocorrência ou mais vezes. | |
+ |
Quando usado no início de uma corda significa que um literal + usado no E164 numera. Quando usado em qualquer outro lugar na corda é um valor do regex para o dígito procedente que ocorre umas ou várias vezes. |
+19191112222 |
? | Regex para o dígito procedente zero ou uns tempos de ocorrência. | (206)?5015111 |
^ |
Caráter de Regex para indicar o começo da corda quando usado fora dos suportes Quando interno usado suporta está tratado como uma exclusão ou a NÃO FAZ NENHUMA instrução compatível Isto está exigido já não em umas versões mais atrasadas enquanto o gateway supõe automaticamente um ^ ao processar uma corda do regex sem um ^. |
^8675309 91[^135]555 |
$ | Caráter de Regex para indicar a extremidade de uma corda. | 8675309$ |
\ |
Caractere de escape para significar um valor literal |
|
[] |
Os suportes definem uma escala dos caráteres para uma única posição. As vírgulas devem ser usadas para quebrar acima cordas contínuas. |
[1-5]0000 [2,5-8]0000 |
() |
O parêntese define um grupo de caráteres em um grupo. |
9(258)7777 |
T |
Um fósforo do comprimento variável de até 32 dígitos. O roteador espera no intervalo entre dígitos para ocorrer antes de distribuir o atendimento. O valor padrão para o interdigit timeout é os segundos 10 e é modificável através dos intervalos entre dígitos em uma porta de voz. T igualmente provê o temporizador T302 |
9011T |
- |
Usado nos suportes para definir a escala. |
[5-9]1234 |
Saída do gateway que indica as entradas possíveis da expressão regular
Gateway(config-dial-peer)#destination-pattern asdfqw4r3~2 Incorrect format for E.164 Number regular expression must be of the form ^[][^0-9,A-F#*.?+%()-]*T?(\$)?$
O dial peers pode estar em um de dois estados operacionais.
Para que um dial-peer esteja em um estado operacional válido e elegível para o uso com roteamento de chamada precisa de estar no estado ASCENDENTE. Para voip dial peer de saída isto significa que deve haver mecanismos de harmonização de partida válidos assim como um alvo da sessão válida para distribuir o atendimento para. Para o dial peers do POTS externo os mecanismos de harmonização de partida válidos válidos assim como uma porta de voz válida devem ser configurados. Com dial peer de entrada somente os mecanismos válidos de uma compatibilidade de entrada devem ser configurados.
O estado ocupado está considerado quando um dial-peer está configurado com mecanismos keepalive e o alvo remoto falhou os parâmetros desse mecanismo keepalive. O gateway move então o dial-peer em um estado ocupado assim que é usado já não para decisões de roteamento de chamada e quando o mecanismo keepalive é cumprido outra vez o gateway põe o dial-peer de novo em um estado ascendente. Se um dial-peer é selecionado enquanto um dial peer de saída e este dial-peer estão em um estado ocupado o gateway falha o atendimento com um código de causa 188.
Junto com estados operacionais há uns estados administrativos.
Um administrador pode desabilitar um dial-peer sem removê-lo da configuração inscrevendo o comando shutdown no dial-peer. Para re-permitir seletor-por não incorpore nenhuma parada programada.
Nota: Um dial-peer com uma porta de voz que esteja para baixo, parada programada, ou as sobras não operacionais no estado operacional de ASCENDENTE contudo o estado da saída mostra como para baixo
Verificação
Gateway#show dial-peer voice summary dial-peer hunt 0 AD PRE PASS OUT TAG TYPE MIN OPER PREFIX DEST-PATTERN FER THRU SESS-TARGET STAT PORT KEEPALIVE 1 voip up up 0 syst 777 voip up up 9... 0 syst ipv4:14.50.244.2 555 voip up down 555 0 syst 888 pots up up 888 0 up 0/2/0
999 pots up up 999 0 down 0/2/0
123 voip up up 123 0 syst ipv4:10.10.10.10 busyout
Ligar com IO Cisco gateway de 15.6(3)M e IOS-XE 16.3.1 pode combinar os dial peer de entrada que usam VRF ID. Para aproveitar-se disto um administrador deve ligar o dial peer de entrada a uma relação que ligue por sua vez o dial-peer ao VRF ID na interface especificada. Depois que o ligamento está completo as chamadas recebidas estão filtradas pelo Cisco gateway a somente incluem somente os dial peer de entrada elegíveis que combinam o VRF ID da relação que o pacote foi recebido sobre. Do dial peer de entrada é combinado aqui com base no ordem de operação regular da correspondência de dial peer.
Antes destes IO/IOS-XE libera o Cisco gateway faria uma seleção de entrada baseada no dial peer de entrada regular que combina somente sem filtrar. Isto significa que um atendimento VRF1 poderia ser combinado por um dial-peer VRF2.
Os Cisco gateway têm a capacidade para construir uma ponte sobre atendimentos através dos VRF sem a necessidade para que os escapes da rota sejam configurados. Isto significa que uma chamada recebida em VRF1 pode ser de partida distribuído em um dial-peer para VRF2 se a seleção de harmonização do dial peer de saída normal é satisfeita. Os grupos do dial-peer podem ser empregados para forçar o Cisco gateway para manter o atendimento dentro do mesmo VRF.
Documentação mais adicional: http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-cube-multi-vrf.html
Exemplo da configuração de grupo VRF e de dial-peer
Este exemplo de configuração tem VRF1 e VRF2 com duas escalas de sobreposição IP e duas escalas de sobreposição do número de telefone.
Nós utilizamos o emperramento VRF para assegurar-se de que o dial peer de entrada correto esteja combinado e os grupos do dial-peer para assegurar ao VRF correto dial peer de saída encadernado esteja combinado. \ Se um pacote do SORVO para um atendimento a 8675309 chega em gig0/0/1.2 então o gateway filtra para fora todos os dial peer de entrada disponíveis baseados no VRF2 ID. Isto significa que nós não podemos combinar o dial-peer 10. agora que nós verificamos a dígito-corda que nós combinamos o dial-peer 20. O dial-peer 20 tem um grupo do dial-peer que diga ao gateway o único dial peer de saída que pode ser combinado é igualmente o dial-peer 20. Este grupo do dial-peer permite que nós evitem combinar o dial-peer 10 e cruzar um atendimento que vem de VRF1 em VRF2. Lá do atendimento deve continuar como o normal.
! 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 -------------------------------------
Ao longo dos anos como as necessidades de negócio crescem, a empresa expande e exige mais mais DIDs ao administradores da empresa pode encontrar que o dial peers básico não encontra a escala bem. Pode haver -fora nas situações que precisam de ser endereçadas, ou talvez há apenas dial peers demais geralmente. Ter milhares de dial peers não faz a administração e a pesquisa de defeitos fáceis. Tendo um dial-peer para os começos do agente de cada CUCM server específico ou de atendimento combinarem o problema de dial peers demais porque agora um administrador precisa de configurar um dial-peer para para cada dígito-corda. Talvez há tem mais de um fornecedor do SORVO que conecta a um gateway ou a alguns clientes diferentes que usam o mesmo CUBO. Isto faz isolando um inquilino específico muito resistente.
Cisco tomou este feedback e criou um grupo de artigos que podem endereçar edições tnese e mais. Os grupos do dial-peer, os inquilinos da classe da Voz, os grupos de servidores do destino, e164-pattern-maps e os grupos de troncos dos POTENCIÔMETROS permitem um administrador resolver todos os problemas acima e muito mais não listados.
Os grupos do dial-peer foram adicionados em IO 15.4(1)T e em IOS-XE 3.11S e POTS dial peer foram adicionados como uma opção em IO 15.5(1)T e em IOS-XE 3.14S. Um grupo do dial-peer permite que os administradores especifiquem um dial-peer exato para o roteamento de partida baseado no dial peer de entrada combinado. Um dial peer de entrada com um grupo do dial-peer configurado é combinado uma vez o atendimento usa o dial-peer definido no grupo do dial-peer mesmo se o destino-teste padrão não combina. A única condição prévia é o dial peer de saída deve estar ACIMA DE assim que um método correspondente de partida deve ser configurado contudo isto não é usado realmente para distribuir o atendimento.
A melhor maneira de descrever grupos do dial-peer é compará-los ao conceito das rotas estáticas em uma tabela de roteamento. Estes são de entrada estático às decisões de roteamento de partida levam embora alguma da adivinhação para o gateway porque são dizendo lhe exatamente como distribuir o atendimento.
Documentação completa: http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/multiple-outbound-dial-peer.html
Exemplo de configuração
Com o exemplo seguinte o número chamado é 8675309. Isto combina o dial-peer 1234 baseado na indicação entrante do chamar-número. Este dial-peer é configurado com um grupo do dial-peer que indique que o atendimento deve agora distribuir para fora o dial peers 2 então 3 e finalmente 1 se o dial-peer 2 falha. Conhecendo isto o gateway tenta agora distribuir o dial-peer 2 chamar porque se disse explicitamente através do grupo do dial-peer que é o que deve fazer.
Note como o destino-teste padrão no dial-peer 1, 2, e 3 não é o número chamado de 8675309. Isto é muito bem e as rotas do atendimento ainda sem uma edição. Recorde como discutido no “dial-peer indica” a seção que nós precisamos algo/qualquer coisa configurados como uma indicação de harmonização de partida. Em nosso padrão de destino do caso é trazer somente o dial-peer em um estado UP operacional e a dígito-corda desse comando é avaliada nunca. Recomenda-se configurar um teste padrão como o “destino-teste padrão AAAA” porque este é um destino-teste padrão válido. Desde que este é technally um dial-peer válido outros atendimentos poderiam combiná-lo. Assim a dígito-corda AAAA significa que nós podemos nunca a usar para qualquer coisa a não ser nossa encenação específica que involing um grupo do dial-peer porque a probabilidade de um atendimento que entra para o AAAA é muito 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 -------------------------------------
Esta característica dá a administradores a capacidade para reduzir o número de dial peers total combinando muitos fósforos possíveis do número (padrõeso de destino, chamar-número entrante, etc.) em um único mapa do teste padrão. O apoio do dial peer de saída e164-pattern-map foi adicionado nos IO 15.2(4)M e IOS-XE 3.7S quando o apoio do dial peer de entrada e164-pattern-map foi adicionado em IO 15.4(1)T e em IOS-XE 3.11S.
Um e164-pattern-map pode ser configurado através o do CLI ou PRE-ser configurado e salvar como um arquivo .cfg. O arquivo .cfg é adicionado então ao flash do gateway e provido então ao configurar o resto do comando. O arquivo .cfg pode utilizar 5000 entradas.
As entradas em ambos os métodos de configuração podem utilizar todos os convites normais do dial-peer para uma agregação mais adicional!
Documentação completa: http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/vd-mdp-dialpeer.html
Exemplo da configuração de CLI - Números chamados
! 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 da configuração de CLI - Número chamado
! voice class e164-pattern-map 2 description E164 Pattern Map for called 800 numbers e164 91800T e164 91855T e164 91888T ! dial-peer voice 2 voip description INBOUND Dial-peer based on CALLED # incoming called e164-pattern-map 2 ! dial-peer voice 22 voip description OUTBOUND Dial-peer based on CALLED # destination e164-pattern-map 2 !
Exemplo de configuração instantâneo
! 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> !
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
Os grupos de servidores dão a administradores a capacidade para configurar destinos múltiplos (destinos de sessão) no mesmo VoIP dial-peer. À revelia a ordem do tipo é a preferência definida nas entradas do grupo de servidores. O caçado round-robin pode ser empregado usando o arredondamento robin do caça-esquema do comando. Os grupos de servidores foram adicionados em IO 15.4(1)T e em IOS-XE 3.11S.
Nota: O número máximo de entradas é 5 pelo grupo de servidores.
Documentação completa: http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/multiple-server-groups.html
Exemplo de configuração
! voice class server-group 1 hunt-scheme round-robin ipv4 14.50.244.2 port 5060 preference 1 ipv4 14.50.244.62
ipv6 2010:AB8:0:2::1 port 2323 preference 3
ipv6 2010:AB8:0:2::2 port 2222 ! dial-peer voice 1 voip session protocol sipv2
destination-pattern 8675309 session server-group 1 !
Verificação
Gateway#show voice class server-group 1 Voice class server-group: 1 AdminStatus: Up OperStatus: Up
Hunt-Scheme: round-robin Last returned server:
Description:
Total server entries: 4
Pref Type IP Address IP Port
---- ---- ---------- -------
1 ipv4 14.50.244.2 5060
0 ipv4 14.50.244.62
3 ipv6 2010:AB8:0:2::1 2323
0 ipv6 2010:AB8:0:2::2 2222
Vale notando que os grupos de servidor não seguem mecanismos keepalive normais das OPÇÕES do Para fora--diálogo. Utilizam uma característica chamada um perfil do opção-keepalive. Isto permite que o gateway monitore cada agente do atendimento definido no grupo de servidores específico.
exemplo do Opção-keepalive com grupo de servidor
! voice class server-group 1 hunt-scheme round-robin ipv4 14.50.244.2 ipv4 14.50.244.62 ! dial-peer voice 1 voip session protocol sipv2 session server-group 1 voice-class sip options-keepalive profile 1 !
Verificação
Gateway# show voice class sip-options-keepalive 1 Voice class sip-options-keepalive: 1 AdminStat: Up Description: Transport: system Sip Profiles: 0 Interval(seconds) Up: 5 Down: 5 Retry: 5 Peer Tag Server Group OOD SessID OOD Stat IfIndex -------- ------------ ---------- -------- ------- 1 1 Active 87 Server Group: 1 OOD Stat: Active OOD SessID OOD Stat ---------- -------- 1 Active 2 Active OOD SessID: 1 OOD Stat: Active Target: ipv4:14.50.244.2 Transport: system Sip Profiles: 0 OOD SessID: 2 OOD Stat: Active Target: ipv4:14.50.244.62 Transport: system Sip Profiles: 0
Os grupos de troncos são uma coleção de portas de voz físicas com potencialidades de sinalização similares. Esta é uma característica que possa ser empregada para reduzir o número total de POTS dial peer que precisam de ser configurados. Os grupos de troncos foram introduzidos em IO em 12.1(3)T e estam presente em todas as versões de IOS-XE.
Documentação completa: http://www.cisco.com/c/en/us/td/docs/ios/12_2/12_2x/12_2xu/feature/guide/ftpg_str.html#wp1034848
Exemplo de configuração:
! trunk group PSTN description PSTN voice-ports !
trunk group FXO
description FXO voice-ports
! voice-port 0/2/0 trunk-group PSTN 1 ! voice-port 0/2/1 trunk-group PSTN 2 !
voice-port 0/2/2
trunk-group FXO 1
!
voice-port 0/2/3
trunk-group FXO 2
! dial-peer voice 1234 pots trunkgroup PSTN 1 trunkgroup FXO 2 !
Inquilinos introduzidos da classe da Voz IO 15.6(2)T e IOS-XE 16.3.1 que permite que cada inquilino tenha suas próprias configurações individuais. Um inquilino pode ser um provedor de telefonia, Cisco unificou o gerente de uma comunicação (CUCM), ou algum outro agente que do atendimento da 3ª parte um administrador gostasse tem configurações globais específicas para. Primeiramente um administrador cria um inquilino da classe da Voz e define os parâmetros. O inquilino da classe da Voz é aplicado então ao dial-peer ou à escolha específica. Esta configuração nova dá a administradores um outro nível de controle sobre atendimentos além do dial peers e da configuração global.
Documentação completa: http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-cube-multi-tenants.html
Ordem normal de comando preference sem inquilinos
Ordem de comando preference com inquilinos
Exemplo de configuração do Multi-inquilino
Nós temos dois inquilinos 777 e 999. Nós configurar-los com configurações levemente diferentes e aplicamo-las a nosso dial peers. Isto significa que os atendimentos que usam o dial peers diferente têm as configurações baseadas dial-peer assim como as configurações do específico do inquilino. As opções abaixo são somente um snippet da potência de inquilinos da classe da Voz. Refira a documentação para ver o que toda pode ser configurado em um inquilino. É recomenda empregar mecanismos de harmonização restritos como números do uri da classe da Voz ou de colocação de etiquetas com determinadas séries numéricas à correspondência de dial peer do inquilino do sperate, ou mesmo configurar VRF de modo que o inquilino A nunca sobreponha com o inquilino B e combine acidentalmente um dial-peer que não devem.
!
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á nenhum comando individual ver configurações do inquilino da classe da Voz. O comando seguinte deve ser suficiente para filtrar a configuração running apenas à informação do inquilino.
show run | sec tenant
As cordas da rota são usadas com serviço da consulta do intercluster CUCM (ILS) e podem ser configuradas para permitir que os Cisco gateway distribuam chamadas VoIP através da rota-corda incluída no SORVO CONVIDAM recebido de um CUCM 9.5+ que executa o serviço ILS. Esta característica foi adicionada nos IO 15.3(3)M e IOS-XE 3.10S. A maioria de conexões ILS são CUCM a CUCM e a administradores não se incomodam envolver um CUBO para o entroncamento do intercluster. Contudo se nós precisamos de executar a função com o CUBO no meio as opções estão lá.
Documentação completa: http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube_interop/configuration/15-mt/cube-interop-15-mt-book/voi-cube-ils-service.html
Exemplo de configuração: CUCM - SORVO - CUBO - SORVO - 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
voice-class sip call-route dest-route-string ! 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
Os artigos cobertos nesta seção são considerados técnicas do legado. Quando a capacidade para configurar estes estiver ainda atual dentro de um Cisco gateway não se recomenda utilizar estes comandos em configurações modernas. Este documento cobre-os somente porque poderiam ser encontrados ao trabalhar com configurações legadas ou ao executar elevações.
os DNIS-mapas poderiam ser considerados o precursor para o que seria agora um E164-pattern-map. Os mapas DNIS foram adicionados aos IO em 12.2(2)XB e existiram sempre em IOS-XE.
Se há DNIS-mapas configurados vale convertendo os à característica mais robusta e164-pattern-map.
Sintaxe de comando: http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr2/vcr2-cr-book/vcr-d2.html#wp3372710070
Exemplo de configuração:
! voice dnis-map 34 dnis 8675309 ! dial-peer voice 88 voip dnis-map 34 !
As etiquetas do grupo de troncos foram adicionadas em IO 12.2(11)T e existem em todas as versões IOS-XE. A finalidade de uma tronco-grupo-etiqueta é similar a um ID de portadora no sentido que pode ser usada para aumentar a harmonização do dial peers. Isto está disponível para a configuração dentro dos grupos de troncos dos POTENCIÔMETROS, o VOIP e os POTS dial peer assim como os grupos da fonte da Voz. O uso das etiquetas do grupo de troncos vistas raramente em configurações de Cisco gateway modernas.
Sintaxe de comando: http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr5/vcr5-cr-book/vcr-t3.html#wp2051313870
Exemplo de configuração:
! dial-peer voice 112 pots trunk-group-label source north3 trunk-group-label target east17 !
Com integrações ISDN Q.931 existe a capacidade para combinar um dial-peer baseado na chamada ou o número chamado assim como o tipo de número específico ITU da Mensagem da INSTALAÇÃO Q.931. Isto é configurável através do comando numbering-type em VOIP ou do POTS dial peer. o Numeração-tipo não pode ser usado apenas e deve ser usado conjuntamente com o destino-teste padrão, o resposta-endereço, ou o chamar-número entrante. Isto significa que a condição indicação de harmonização de entrada/de partida E o tipo de número devem combinar para ser um sucesso para que o dial-peer esteja considerado para o roteamento da chamada de entrada e de saída.
o Numeração-fósforo pode ser pensado como de um mecanismo de filtração do dial-peer um pouco do que um mecanismo de harmonização. Isto é porque um dial-peer com e sem um comando do tipo de numeração aplicado está considerado o mesmo peso da preferência do padrão se nenhuma preferência do administrador é aplicada. Este é ID de portadora desigual que, quando aplicado a um dial-peer ao longo do lado o outro mecanismo de harmonização, adiciona a preferência a esse dial-peer sobre outro se ambas as circunstâncias são verdadeiras.
A harmonização do tipo de numeração foi adicionada em IO 12.0(7)XR1 e esta presente em todas as liberações IOS-XE. Com a diminuição das linhas de ISDN tradicionais dos POTENCIÔMETROS que estão sendo distribuídas em redes de Collboration o uso do numeração-tipo é considerado raramente em disposições modernas.
Sintaxe de comando: http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr3/vcr3-cr-book/vcr-n1.html#wp3304694174
Exemplo de configuração:
Este dial-peer pode combinar 4085150000 a 4085159999 somente se o tipo do número ISDN é nacional
! dial-peer voice 408 voip numbering-type national destination-pattern 408515.... session target ipv4:10.1.1.2 !
Tipos de número possíveis:
Abreviado | Representação abreviada do número completo como apoiada por esta rede |
Internacional | Número chamado para alcançar um subscritor em um outro país |
Nacional | Número chamado para alcançar um subscritor no mesmo país, mas fora da rede local |
Rede | Específico administrativo ou do número do serviço à rede do serviço |
Reservado | Reservado para a extensão |
Assinante | Número chamado para alcançar um subscritor na mesma rede local |
Desconhecido | O tipo de número é desconhecido pela rede |
O dial peers dos dados foi introduzido em IO 12.2(13)T e o útil de tal dial peers era para chamadas de modem dos dados de entrada em um Cisco gateway. Este dial-peer é somente para o uso na direção de entrada e visto raramente em disposições modernas.
Sintaxe de comando: http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr2/vcr2-cr-book/vcr-d1.html#wp1448833490
Exemplo de configuração:
! dial-peer data 100 pots incoming called-number 100 !
A dada altura de um desenvolvimento da Colaboração um administrador pode precisar de manipular dígitos ou um encabeçamento URI/SORVO. Os Cisco gateway têm métodos numerosos para a Manipulação de dígitos que permite um controle completo do administrador sobre como e quando um dígito deve ser manipulado. Contudo, isto pode ser desanimado a algum enquanto estão oprimidos com as opções diferentes OU o administrador não sabe que uma opção existe.
Os POTS dial peer têm algumas técnicas das manipulações do dígito exclusivo originais a elas que os VoIP dial-peer não têm.
O primeiro é o descascamento de dígitos esquerdo-justificados explicitamente definidos em um destino-teste padrão. Isto pode ser desabilitado usando o comando nenhuma dígito-tira no POTS dial peer.
Exemplo:
Neste exemplo nós definimos 9011T como a corda para o destino-teste padrão.
Com isto no lugar nós recebemos um atendimento para 90113227045555. Isto combina nosso dial-peer para o roteamento da chamada externa e os dígitos explicitamente definidos de 9011 estão descascados antes que o atendimento esteja distribuído para fora a porta de voz.
! dial-peer voice 1 pots destination-pattern 9011T port 0/0/0:23 !
O exemplo seguinte mostra uma configuração sem a dígito-tira no lugar.
Se o mesmo número é chamado os 9011 é enviado
! dial-peer voice 1 pots destination-pattern 9011T port 0/0/0:23
no digit-strip !
O segundo é a capacidade para especificar quantos dígitos nós gostaríamos de enviar no POTS dial peer.
Tome o exemplo seguinte onde nós recebemos um atendimento para 918005532447 deCUCM. Nesta situaçãonósqueremosremover o9masenviar oresto donúmero quecomeçacom o1.
Se nós configuramos o comando forward-digits no POTS dial peer nós podemos especificar exatamente quantos dígitos nós enviamos.
! dial-peer voice 1 pots destination-pattern 918005532447 forward-digits 11 port 0/2/0 !
Ultimamente, os POTS dial peer podem utilizar o comando prefix adicionar dígitos a um atendimento antes de distribuir para fora a porta de voz. O exemplo seguinte descasca os 91 explicitamente definidos e prefixa 007 ao número antes de enviar chamar a porta de voz.
! dial-peer voice 1 pots destination-pattern 91T prefix 007 port 0/1/0:15 !
As regras de tradução da Voz são expressões regulares (regex) usadas para transformar dígitos. As regras de tradução e os perfis foram adicionados aos IO em 12.0(7)XR1. Uma tradução-regra nós aplicados para exprimir os perfis de tradução que são aplicados então a um dial-peer ou a uma porta de voz. As regras de tradução contêm uma entrada do fósforo e uma saída da alteração. Junto com a entrada do fósforo no número há um fósforo e altera a entrada para o plano e o tipo ISDN. A combinação de série numérica, de plano e de tipo do fósforo é considerada E fósforo. Isto significa que todas as entradas do fósforo definidas deve ser verdadeiro para que a tradução ocorra.
As regras de tradução têm a capacidade para mudar chamado, chamada, chamada redirecionada, reorientar-alvo, e número de chamada de volta no ISDN, no SORVO, e nos protocolos de sinalização de H323. As regras de tradução combinam baseado em uma busca invertido assim que a ordem das regras é da importância máxima. Se um fósforo é encontrado em uma regra que mais alta o gateway para de imediatamente procurar e processe a tradução. As Regras de tradução não podem mudar encabeçamentos NON-numéricos do sorvo tais como "testuser@10.10.10.10". Para esta manipulação utilize por favor um perfil do SORVO.
as Transição-regras podem ser usadas para obstruir chamam Cisco gateway.
Preferência da seleção do perfil de tradução
Além do que o regex do dial-peer e as regras de tradução dos wilcards tenha seus próprios caráteres do regex.
Caractere |
Definição |
* |
Quando usado nas regras de tradução este é regex para 0 ou mais do caractere anterior. Para combinar um literal * use um caractere de escape: \ * |
\ |
De uso geral para escapar grupos na regra de tradução \ no (\) |
& | O Ampersand é usado para trazer sobre qualquer coisa combinado no fósforo inicial ajustado para o grupo de alteração |
() | Os artigos envolvidos no parêntese são considerados um grupo. |
^ |
Define o começo explícito de uma corda. Ao contrário das regras de tradução do dial peers não defina o começo da corda. Isto significa que definindo uma corda sem um ^ pode o anywehre possível do fósforo na série de entrada que pode conduzir às traduções indesejáveis no meio de um número. |
Grupos de alteração
exemplo da Tradução-regra com dois grupos
Neste exemplo nós examinamos o número 000111000222.
Nós queremos remover o 0s do número e realizar um número final de 111222.
Para fazer isto nós configuramos o grupo 1 e 2 para agarrar os 111 e os 222 respectivamente ao deixar cair o 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 descascar o teste padrão do para fora-seletor 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
Número chamado de truncagem a 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
Descascamento 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 podem igualmente ser aplicadas diretamente a um dial-peer sem primeiro que está sendo aplicado 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 da tradução no grupo de troncos
! trunk group <name> translation-profile incoming <profile-name> translation-profile outgoing <profile-name> !
Debugando Regras de tradução e perfis da Voz
debug voip ccapi inout debug voice translation debug dialpeer test voice translation-rule <number> <string> type <type> plan <plan>
OS MAPAS ISDN são uma técnica mais velha para alterar dígitos. Isto foi adicionado em IO 12.0(6)T e a maioria de configurações novas não utilizam esta característica porque não são tão robustas quanto regras de tradução e perfis da Voz. Os mapas ISDN são definidos sob a 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
Como a expansão do número dos mapas ISDN é uma técnica mais velha adicionada em IO 11.3(1)T e não usada muito em redes novas. Esta característica foi adicionada antes que as regras de tradução e os perfis da Voz existiram. A expansão do número é uma mudança global dos dígitos aplicados a todo o dial peers em um Cisco gateway. A alteração está aplicada ao número chamado DEPOIS QUE o dial-peer foi combinado e right before o atendimento está enviado ao atendimento-agente seguinte.
Exemplo de configuração:
num-exp 4... 18005554...
num-exp 1234 8675309
Os perfis do SORVO são as instruções compatível robustas da expressão regular (regex) que permitem que um administrador mude todo o aspecto de uma mensagem do SORVO que inclui o SDP e SORVA encabeçamentos. Estes podem ser permitidos globalmente, pelo dial-peer ou pelo inquilino. Os perfis do SORVO estão disponíveis para as alterações de entrada que começam com com os IO 15.4(2)T e o IOS-XE 3.12S. Desde que os perfis do SORVO são tão robustos que esta tampa do documento somente alguns exemplos específicos.
Pontos chaves aproximadamente de entrada contra perfis de partida do SORVO
Outras notas sobre a configuração do sorvo-perfil:
Documentação completa: http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-sip-param-mod.html?bookSearch=true
Ferramenta de testes do perfil do SORVO: https://cway.cisco.com/tools/SipProfileTest/
Sintaxe de entrada/de partida do exemplo do perfil do SORVO
! 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 !
Métodos de partida do aplicativo do perfil do SORVO
! Global Application ! voice service voip sip sip-profiles <number> !
! Dial-peer Application ! dial-peer voice <tag> voip voice-class sip profiles <number> !
Métodos de entrada do aplicativo do perfil do SORVO
Note por favor: Exige-se para permitir o “sorvo-perfil de entrada” sob o sorvo do voip do serviço de voz se o aplicativo global ou o aplicativo do dial-peer estão usados.
! Global Application ! voice service voip sip sip-profiles inbound sip-profiles <number> inbound !
! Dial-peer Application !
voice service voip
sip
sip-profiles inbound
! dial-peer voice <tag> voip voice-class sip profiles <number> inbound !
Perfil do SORVO do exemplo para alterar o host, o domínio, ou ambas as parcelas 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>" !
O perfil do SORVO do exemplo a adicionar, altera, ou remove cabeçalhos de desvio
! Add ! voice class sip-profiles 777 request INVITE sip-header Diversion add "Diversion: <sip:1234@abc.com>" ! ! ! Modify ! voice class sip-profiles 888 request INVITE sip-header Diversion modify "sip:" "sip:1234@abc.com" ! ! ! Remove ! voice class sip-profiles 999 request INVITE sip-header Diversion remove !
Perfil do SORVO do exemplo para alterar a parcela do nome do ID de chamada de encabeçamentos do SORVO
! voice class sip-profiles 123 request INVITE sip-header From modify "\".*\"" "\"TEST CLID*\"" !
Perfil do SORVO do exemplo para mudar uma sessão 183 em andamento a uns 180 que soam.
! voice class sip-profiles 789 response 183 sip-header SIP-StatusLine modify "SIP/2.0 183 Session in Progress" "SIP/2.0 180 Ringing" !
Perfil do SORVO do exemplo para a Interoperabilidade audio de sentido único ou no-way com um fornecedor
!
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 do SORVO do exemplo para remover o método da ATUALIZAÇÃO para questões de interoperabilidade.
!
voice class sip-profiles 200
request ANY sip-header Allow-Header modify ", UPDATE" ""
!
Uso AJUSTADO da exibição do perfil do SORVO do exemplo dentro do perfil do SORVO. Este é o mesmo conceito dos grupos descritos dentro da seção da tradução-regra da Voz.
!
voice class sip-profiles 1 request ANY sip-header Contact modify "sip:(.*)@" "sip:\1@"
!
Configurating SE rupturas da lógica e do newline com um perfil do SORVO.
As rupturas do Newline são apoiadas no SORVO perfilam contudo lá são somente um caso muito específico do uso para estes. Desde que os perfis do SORVO não têm alguns SE, a seguir, a lógica outra lá é agora maneira de executar modifcations a um encabeçamento baseado em uma entrada de um outro encabeçamento. Isto é um administrador quer somente alterar um cabeçalho de desvio se do encabeçamento contém 1234@cisco.com. Utilizando a ruptura do newline nós podemos “spoof” SE indicação dentro de um perfil do SORVO. Veja o exemplo de configuração abaixo: Nós combinamos 1234 em todo o domínio no do encabeçamento. Então nós trazemos sobre o primeiro grupo e adicionamos uma ruptura "\x0D\x0AD" da nova linha. Finalmente nós adicionamos o encabeçamento que nós queremos. Veja que este método permite somente que nós ADICIONEM um encabeçamento. Não há nenhuma maneira de alterar um outro encabeçamento. Assim isto somente cumpre parcialmente as exigências que um administrador quis conseguir acima.
!
voice class sip-profiles 1 request INVITE sip-header From modify “(.*sip:1234@.*)” “\1\x0D\x0ADiversion: <sip:5678@example.com>” !
O SORVO Copylist é uma extensão de perfis do SORVO que permita que o gateway COPIE um encabeçamento do em-pé de um atendimento e O COLE então a um outro ponto na mensagem do SORVO da saída no para fora-pé. O apoio de Copylist do SORVO foi adicionado em IO 15.1(3)T e em IOS-XE 3.6S. Esta é maneira eficiente do bery de criar os encabeçamentos dinâmicos baseados em outros encabeçamentos do em-pé do atendimento.
O uso-caso o mais comum está copiando dinamicamente a do encabeçamento a um encabeçamento diferente como a diversão ou a p-afirmar-identificação de modo que o valor da parcela do usuário seja do usuário. Isto é feito na maior parte para finalidades da autenticação assim como do ID de chamada.
Documentação completa: http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/copy_sip_headers.html?bookSearch=true
Exemplo de Copylist do SORVO
! ! Create Copylist to copy the FROM header on the inbound message specified later. ! voice class sip-copylist <number> sip-header From ! ! Apply this to the inbound dial-peer of the call. ! dial-peer voice <tag> voip voice-class sip copy-list <number> ! ! Create SIP Profile to take From (peer-header) stored as variable "u01" and apply to a header of choice. ! This example modifies the user portion of the Contact by copying the user portion of the From header to the user portion of the Contact header. ! voice class sip-profiles <number> request INVITE peer-header sip From copy "<sip:(.*)@" u01 request INVITE sip-header Contact modify "<sip:(.*)>" "<sip:\u01@14.50.244.2>" ! ! Apply the SIP profile to an outbound dial-peer ! dial-peer voice <tag> voip voice-class sip profiles <number>
!
Debugando perfis e Copylist do SORVO
debug voip ccapi inout debug ccsip mess debug ccsip info debug ccsip feature sip-profile
Resultado do debug do SORVO Copylist do exemplo
### Ingress from CUCM Received: INVITE sip:1001@14.50.228.61:5060 SIP/2.0 Via: SIP/2.0/TCP 14.50.244.3:5060;branch=z9hG4bKaad21bc3ae7e From: "5001" <sip:5001@14.50.244.3>;tag=100442~cdffff43-5020-4e79-a10b-99d406971010-36470319 Contact: <sip:5001@14.50.244.3:5060;transport=tcp> ### Copylist Details 00440: Mar 8 18:59:49.796: //-1/xxxxxxxxxxxx/SIP/Info/info/64/sip_profiles_application_peer_copy_pattern: sed_match succeeded 000441: Mar 8 18:59:49.797: //187/D6138E000000/SIP/Info/info/64/sip_profiles_application_peer_copy_pattern: SIP Profiles COPY variables AVL tree created 000442: Mar 8 18:59:49.797: //-1/xxxxxxxxxxxx/SIP/Info/info/64/sip_profiles_prefix_slash_in_copy_var_val: ret_dst: 5001 000443: Mar 8 18:59:49.797: //187/D6138E000000/SIP/Info/info/64/sip_profiles_application_peer_copy_pattern: SIP Profiles COPY variable: u1 val: 5001 000444: Mar 8 18:59:49.797: //-1/xxxxxxxxxxxx/SIP/Info/info/64/sip_profiles_application_modify_remove_header: Header before modification : Contact: <sip:5001@14.50.228.61:5060> 000445: Mar 8 18:59:49.797: //187/D6138E000000/SIP/Info/info/64/sip_profiles_check_and_get_variables_in_replace_pattern: Node found: COPY variable: u1 val: 5001 000446: Mar 8 18:59:49.797: //187/D6138E000000/SIP/Info/info/64/sip_profiles_check_and_get_variables_in_replace_pattern: substituted_replace_pattern : : @165.117.64.94> 000448: Mar 8 18:59:49.797: //187/D6138E000000/SIP/Info/info/64/sip_profiles_check_and_get_variables_in_replace_pattern: Final substituted_replace_pattern : <sip:5001@165.117.64.94> 000449: Mar 8 18:59:49.797: //-1/xxxxxxxxxxxx/SIP/Info/info/64/sip_profiles_app_modify_header: Passing substituted replace pattern 000450: Mar 8 18:59:49.798: //-1/xxxxxxxxxxxx/SIP/Info/info/64/sip_profiles_application_modify_remove_header: Header after modification : Contact: <sip:5001@165.117.64.94> 000451: Mar 8 18:59:49.798: //187/D6138E000000/SIP/Msg/ccsipDisplayMsg: ### Egress from CUBE Sent: INVITE sip:1001@14.50.228.63:5060 SIP/2.0 Via: SIP/2.0/UDP 14.50.228.61:5060;branch=z9hG4bK3C7CD Remote-Party-ID: "5001" <sip:5001@14.50.228.61>;party=calling;screen=yes;privacy=off From: "5001" <sip:5001@14.50.228.61>;tag=34C458-D6 Contact: <sip:5001@165.117.64.94>
Todos os protocolos de sinalização permitem a administradores a capacidade para ligar a sinalização a uma relação específica. À revelia um gateway sem uma estática definida ligando as fontes do gateway a sinalização para um atendimento da interface física que o pacote atravessa. Com ligação em um dial-peer o pacote caracteriza encabeçamentos, Mensagem, e pacotes da fonte da interface especificada mas o pacote real ainda distribui sobre a interface física. O dial-peer que liga substitui sempre o inquilino da classe da Voz e o voip global do serviço de voz que ligam com Session Initiation Protocol (SIP).
Muitos administradores das épocas ligam a sinalização a um laço de retorno. Este ser uma interface lógica significa que nenhum pacote atravessa esta relação. A fim executar capturas de pacote de informação o cpature deve ser executado em uma interface física. O <remote-ip> do comando show ip cef indica a interface física que um pacote utiliza para distribuir ao destino/IP remoto mesmo se é limitado a uma interface virtual.
O emperramento dos media e da sinalização não precisa sempre de ser o mesmo IP. Se nós precisamos de ligar a uma relação específica para sinalizar para/desde um CUCM mas o audio/media entre o telefone e o gateway pode precisar de ligar a uma outra relação.
Exemplo de configuração
Este exemplo mostra que um dial-peer limitado ao laço de retorno 1 e ele recebe um atendimento de CUCM.
Mesmo que os media e a sinalização (controle) sejam limitados ao laço de retorno 1 o comando show ip cef mostra que todos os pacotes enviados a 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 !
Emperramento do SORVO
! 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> !
Emperramento MGCP
!
mgcp bind control source-interface <interface> mgcp bind media source-interface <interface>
!
Emperramento SCCP
!
sccp local <interface> ! sccp ccm group <number> bind interface <interface> !
Ligação de H323
! inteface <interface> ! ! Media Bind Command: h323-gateway voip interface ! ! Signaling Bind Command: h323-gateway voip bind srcaddr <a.b.c.d> !
O DNS com VOIP é empregado apenas toda a outra solução DNS. Uma configuração comum é utilizar o destino de sessão dns: FQDN.com.
Um Cisco gateway executa uma resolução de DNS mesmo quando nenhuma consulta de domínio IP é configurada globalmente no gateway. Isto significa que mesmo que nós estejamos desabilitando o DNS os VoIP dial-peer ainda resolvem a entrada de DNS. De qualquer modo recentemente em IOS-XE 3.16S havia algumas mudanças à funcionalidade total DNS dentro das Plataformas IOS-XE.
Após este dial peers da mudança configurado com destino de sessão dns: FQDN.com obedecem agora o fato de que o DNS está desabilitado com consulta de domínio do noip.
Eu recomendo sempre assegurar-se de que o comando “consulta de domínio IP” esteja configurado ao trabalhar com DNS para evitar esta edição.
3.15S de teste e abaixo
### Domain Name Verification Gateway# sh run | s lookup no ip domain lookup ### Checking the host table for no entry Gateway# show host Name lookup view: Global Default domain is cisco.com Name/address lookup uses static mappings Codes: UN - unknown, EX - expired, OK - OK, ?? - revalidate temp - temporary, perm - permanent NA - Not Applicable None - Not defined Host Port Flags Age Type Address(es) ### Verification of no PING on a FQDN Gateway# ping cucm.cisco.com Translating "cucm.cisco.com" % Unrecognized host or address, or protocol not running. ### Made a test call here ### Checking logs to see if it worked Gateway# sh log | s INVITE sip: INVITE sip:9001@14.50.228.70:5060 SIP/2.0 INVITE sip:5001@cucm.cisco.com:5060 SIP/2.0 ### Host Table now has an entry Gateway# sh host Name lookup view: Global Default domain is cisco.com Name/address lookup uses static mappings Codes: UN - unknown, EX - expired, OK - OK, ?? - revalidate temp - temporary, perm - permanent NA - Not Applicable None - Not defined Host Port Flags Age Type Address(es) cucm.cisco.com None (temp, OK) 0 IP 14.50.244.2 ### CCSIP All output showing a proper DNS Query for the FQDN on the dial-peer. 001338: Mar 9 15:29:07.437: //-1/xxxxxxxxxxxx/SIP/Info/info/1024/httpish_msg_free: Freed msg=0x7FE9873AE560 001339: Mar 9 15:29:07.437: //-1/xxxxxxxxxxxx/SIP/Info/notify/8192/sip_dns_type_srv_query: TYPE SRV query for _sip._udp.cucm.cisco.com and type:1 001340: Mar 9 15:29:07.438: //-1/xxxxxxxxxxxx/SIP/Info/info/8192/sip_dns_type_a_aaaa_query: DNS query for cucm.cisco.com and type:1 001341: Mar 9 15:29:07.441: //-1/xxxxxxxxxxxx/SIP/Info/notify/8192/sip_dns_type_a_query: TYPE A query successful for cucm.cisco.com 001342: Mar 9 15:29:07.441: //-1/xxxxxxxxxxxx/SIP/Info/info/8192/sip_dns_type_a_query: ttl for A records = 3600 seconds 001343: Mar 9 15:29:07.441: //-1/xxxxxxxxxxxx/SIP/Info/info/8192/sip_dns_type_a_aaaa_query: IP Address of cucm.cisco.com is: 001344: Mar 9 15:29:07.441: //-1/xxxxxxxxxxxx/SIP/Info/info/8192/sip_dns_type_a_aaaa_query: 14.50.244.2
3.16S de teste e acima
### Checking the command is present Gateway# sh run | s lookup no ip domain lookup ### Verifying the gateway cannot ping a FQDN Gateway# ping cucm.cisco.com % Unrecognized host or address, or protocol not running. ### Checking the Host Table for entries Gateway# sh host Default domain is cisco.com Name servers are 14.50.244.52 NAME TTL CLASS TYPE DATA/ADDRESS ----------------------------------------- ### Made a test call here ### CCSIP All Outbound showing the failed call 000974: *Mar 9 15:53:01.222: //-1/xxxxxxxxxxxx/SIP/Info/info/1024/httpish_msg_free: Freed msg=0x7FF31DAAA848 000975: *Mar 9 15:53:01.222: //-1/xxxxxxxxxxxx/SIP/Info/notify/8192/sip_dns_type_srv_query: TYPE SRV query for _sip._udp.cucm.cisco.com and type:1 000976: *Mar 9 15:53:01.224: //-1/xxxxxxxxxxxx/SIP/Info/info/8192/sip_dns_type_a_aaaa_query: DNS query for cucm.cisco.com and type:1 000977: *Mar 9 15:53:01.225: //-1/xxxxxxxxxxxx/SIP/Error/sip_dns_type_a_query: TYPE A query failed for cucm.cisco.com 000978: *Mar 9 15:53:01.225: //-1/xxxxxxxxxxxx/SIP/Error/_send_dns_fail: DNS Query for cucm.cisco.com failed 000984: *Mar 9 20:53:01.225: %VOICE_IEC-3-GW: SIP: Internal Error (DNS query fail): IEC=1.1.128.7.47.0 on callID 6 GUID=37B668DF044111E7A950D832C82B325C
À revelia VOIP e os POTS dial peer permitem conexões ilimitadas (atendimentos) e largura de banda (VoIP dial-peer somente). Para os troncos que têm um limite no número de atendimentos ou de largura de banda que podem ser utilizados pode ser útil empregar o MAX-CONN ou os comandos max bandwidth. o MAX-CONN foi adicionado em IO 11.3(1)T e esta presente em toda a versão IOS-XE quando a MAX-largura de banda foi adicionada em 15.2(2)T e em IOS-XE 3.7S
Exemplo de configuração:
Abaixo dos nós estamos dizendo o gateway para limitar atendimentos do dial-peer 1 a 30 usando “MAX-CONN 30".
O dial-peer 2 está limitando a largura de banda para esse dial-peer de modo que nós não vamos sobre o limite atribuído.
! 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
!
Com o Direct Inward Dial permitido em POTS dial peer a Mensagem de entrada deve conter todos os dígitos necessários distribuir o atendimento. O Cisco gateway não deve fazer a coleção do dígito subsequente. Quando o roteador ou o gateway procuram por um dial peer de saída, o dispositivo usa a série de discagem entrante inteira. Este que combina está a um comprimento variável à revelia. Este fósforo não é dígito por dígito feito porque pela definição DID, todos os dígitos foram recebidos. Esta é as configurações padrão para POTS dial peer.
Documentação completa: http://www.cisco.com/c/en/us/support/docs/voice/digital-ccs/14072-direct-inward-dial.html
Exemplo de configuração:
! dial-peer voice 1 pots incoming called-number 8675309 voice-port 0/0/0 direct-inward-dial !
IIf o dial-peer do POTS de entrada é configurado sem o direto-para dentro-seletor o roteador ou o gateway incorpora o modo de coleção por dígito (os dígitos são inband recolhido). A harmonização do dial peer de saída é feita em uma base do dígito por dígito. O roteador ou o gateway verificam para ver se há fósforos de dial peer depois que o dispositivo recebeu cada dígito e distribuem então o atendimento quando uma verificação de repetição de dados direta é feita.
Exemplo de configuração:
!
dial-peer voice 1 pots
incoming called-number 8675309
voice-port 0/0/0
no direct-inward-dial
!
Cada protocolo segura o bloqueio de chamada um bit diferente. A maioria de protocolos podem utilizar o teste padrão da rejeição da tradução-regra que obstrui baseado em uma corda do dígito.
Exemplo de configuração:
! 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 CALLBLOCK
incoming called-number .
port 0/0/0:@3
! Gateway#test voice translation-rule 164 8675309 8675309 blocked on rule 1
Se um administrador quer aplicar um perfil de tradução de entrada para a Manipulação de dígitos normal mas não obstruir ainda dentro nenhuns números há uma opção de executar um atendimento-bloco usando o comando translation-profile do atendimento-bloco.
! 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:@3
! Gateway#test voice translation-rule 164 8675309 8675309 blocked on rule 1
Dentro do E1 R2 existe a capacidade para que um administrador obstrua atendimentos de coleta. Isto principalmente é visto e empregado em disposições de Brasil mas pode ser configurado através de qualquer grupo do CAS-costume.
As duas opções são:
Exemplo de configuração da Dobro-resposta
! 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 !
A Dobro-resposta debuga (debugar o sinal do vpm)
### 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
Há umas implicações para o dial peer de entrada que combina quando o comando isdn overlap-receiving é configurado em interfaces. Depois que cada dígito é recebido na camada de ISDN, os dial peer estão verificados para ver se há fósforos. Se uma verificação de repetição de dados direta é feita, o atendimento está distribuído imediatamente (ao app da sessão neste caso) sem dígitos adicionais de espera. O terminal “T” pode ser usado para suspender esta correspondência dígito por dígito e para forçar o roteador ou o gateway para esperar até que todos os dígitos estejam recebidos. O 'T' refere-se ao temporizador interdígitos T302 no nível do ISDN, configurável na interface serial associada à interface ISDN. O ISDN igualmente fornece outros mecanismos para indicar a extremidade dos dígitos, tais como o ajuste do elemento de informação completa de emissão (IE) nos mensagens de informação Q.931.
O mensagem de advertência mostrado abaixo, indicadores quando o dial-peer for configurado com chamar-número entrante 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
As notas especiais sobre o dial peer entrante combinam com um número chamado vazio:
Um chamar-número “nulo” é considerado “menos” qualificado comparado a uma porta de voz e/ou em alguns casos a um resposta-endereço. Consequentemente, um fósforo baseado em um número chamado “nulo” pode ocorrer SOMENTE se não há nenhum fósforo baseado no resposta-endereço ou no número de porta.
Em caso da sobreposição que disca, um número chamado “nulo” não combina “o chamar-número entrante T” porque o intervalo não ocorreu.
Um chamar-número “nulo” pode combinar “o chamar-número entrante T” somente em caso de ENBLOCK e não há nenhum fósforo um ou outro devido ao resposta-endereço e ao número de porta. O aviso indicado considera quando um administrador configura “o chamar-número entrante T” refere este caso específico.
A classe de limitação é uma maneira de limitar chama um Cisco gateway. O COR é descrito frequentemente como um mecanismo do bloqueio e chave. Os fechamentos são atribuídos aos dial peer com uma lista que parte COR. As chaves são atribuídas aos dial peer com uma lista entrante COR. Quando as lista COR são aplicadas os dial peer de saída disponíveis são aqueles que a chave pode destravar. Isto que filtra ocorre antes que o resto dos métodos correspondentes do dial peer de saída esteja verificado então.
Duas regras importantes com classe de limitação:
A configuração da classe da limitação (COR), da classe de divisão lógica da limitação (LPCOR), e do LPCOR com códigos de autorização forçados (FAC) é além do alcance deste documento mas dos seguintes documentos pode ser provida para a leitura futura.
O CME cria o dial peers do sistema para ephones e associações do registro da Voz. Estes não podem ser vistos na configuração running. Para fazer a mudanças ao dial peers CME as mudanças precisar de ser feito no registro real do ephone ou da Voz associe. Ao ver saídas de sumário da voz do dial peer da mostra o dial-peer que começa com o 2000 é ephones SCCP e o dial peers que começa com 4000 é registro da Voz do SORVO associa-se. Este dial-peer aparece como o dial peer de entrada para atendimentos do CME registrou telefones e o dial peer de saída debuga dentro para o atendimento aos telefones registrados CME.
Saídas de exemplo para o sumário da voz do dial peer da mostra 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ídas de exemplo para o dial peers do registro da Voz da mostra com SORVO 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
O MGCP e o SCCP seguem suas próprias regras para o dial peers. O único conceito que utilizam é que devem ser configurados com a porta de voz desejada para o atendimento. O resto é segurado pelo processo STCAPP e MGCPAPP. Quando nós examinamos a configuração deste dial peers ou têm o comando do “mgcpapp serviço” ou “preste serviços de manutenção ao stcapp”. Estes permitem o dial-peer para o aplicativo da escolha assim como dizem ao aplicativo que dial-peer deve segurar.
Ao debugar estes protocolos a saída nunca indica um fósforo do dial peer de entrada. Isto deve sempre mostrar como o dial-peer 0. Porque não existe. O agente do atendimento que segura o aplicativo tem escolhido já a que mova para enviar o atendimento e harmonização do dial peer de entrada é inútil desde que o gateway não tem nenhum controle sobre esse pé do atendimento. Contudo uma correspondência de dial peer de saída pode ser observada. Isto é meramente para a mostra porque finalmente o agente do atendimento que segura o processo tem o controle sobre esse lado do atendimento também.
Recorde, o dial-peer diz somente o aplicativo da escolha que porta de voz física a controlar. Desde que a maioria desta é controlada por um agente da chamada externa e o gateway é apenas nos faz o que se diz está indo saltar ser a base “como” nesta seção e fornecer algumas configurações para obter começado.
[with CUCM Auto-Configuration*] da configuração de MGCP da amostra:
!
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 MGCP: http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cminterop/configuration/15-mt/dia-15-mt-book/vc-ucm-mgcp-gw.html
Amostra SCCP/configuração STCAPP [with CUCM Auto-Configuration*]
!
stcapp ccm-group 1
stcapp
!
sccp local gig0/0/0
sccp ccm 10.10.10.10 id 1 priority 1 version 7.0+
sccp ccm 10.10.10.20 id 1 priority 2 version 7.0+
sccp
!
sccp ccm group 1
bind interface gig0/0/0
associate ccm 1 priority 1
associate ccm 2 priority 2
!
ccm-manager config server 10.10.10.10
ccm-manager sccp local gig0/0/0
ccm-manager sccp
!
voice-port 0/0/0
description The SCCP port to register
no shut
!
dial-peer voice 1 pots
description Defining the Port for the SCCP application
service stcapp
port 0/0/0
!
ip tftp source-interface gig0/0/0
!
Documentação completa SCCP: http://www.cisco.com/c/en/us/td/docs/routers/access/vg202\_vg204/software/vg2\_vg4\_scg/vg2\_vg4\_voip.html
* Se um administrador não quer CUCM configurar simplesmente o gateway remova os comandos do “CCM-gerente”. Nós incluímos a configuração de dial peer para conduzir em casa o ponto sobre como o conceito trabalha. Com CCM-gerente que as configurações CUCM atual criam este dial peers baseado na configuração de porta em CUCM tão não está nenhuma necessidade de definir realmente o dial-peer. O começo criado CUCM do dial peers geralmente com 999 e é então três mais dígitos.
* Avançado debuga são repleto de recursos e pode impactar o desempenho do CPU e da memória se são permitidos quando houver muitos atendimentos. Mesmo sem chama um gateway pode tornar-se NON-responsivo. recomenda-se executar estes após horas, durante um indicador da mudança, ou quando não houver nenhuma carga no gateway a menos que você for com tac Cisco.