Architecture for Voice, Video and Integrated Data

Cisco Unified Communications

Arquivo da categoria ‘Voice Gateways’

« Entradas Anteriores

Entendendo Dial Peers e Call Legs nas plataformas Cisco IOS

Publicado por loliveira em 20/03/2013

Ao iniciar os estudos para o CCIEVestou percebendo o quanto é importante ter os conceitos mais básicos muito bem dominados e na ponta da língua quando lhe perguntarem. No exame teórico, fiquei surpreso com as pegadinhas sobre seleção de dial peers, algo tão básico, no entanto tão importante. Lembro que quando estava começando a aprender sobre isso memorizei o seguinte: IADP, IADP e IADP. Caso você tenha problemas ao memorizar a ordem de seleção das dial-peers, memorize isso: IADP!!!!

Incoming called number

Answer Address

Destination pattern

Port

Sacaram ????

O Cisco IOS utiliza dois tipos de dial-peers:

Plain Old Telephony Systems (POTS) Dial Peers: Estas definem características da rede de telefonia pública tradicional. A Dial Peer POTS mapeia uma sequência de números discados para uma Voice Port do Voice Gateway. Normalmente a Voice Port conecta o Voice Gateway à PSTN, a um PABX ou a um dispositivo analógico (telefone, fax ou modem).

Voip Dial Peers: Estas definem características das conexões de redes de voz (VoIP). VoIP dial peers mapeia uma sequencia de números discados para outro dispositivo de rede, tais como:

Roteador/Voice Gateway remoto
PABX IP ( Cisco Unified Communications Manger )
SIP Server
Gatekeeper H.323
Dentre outros dispositivos.
Relação entre Dial Peers e Call Legs

A Call Leg é a conexão lógica entre dois Voice Gateways ou entre um Voice Gateway e um dispositivo de telefonia IP (CUCM, Sip Server etc). Cada Call Leg é associada a uma Dial Peer. Para ilustrar este conceito veja a figura abaixo:

Figura 1 – Call Legs POTS e VoIP

CallLeg1

 Fonte: cisco.com

Na figura 1, a chamada inclui 4 Call Legs, duas vistas da perspectiva do Gateway de Origem ( 1 e 2 ) e duas vistas da perspectiva do Gateway de Destino (3 e 4).

Fluxo da Chamada (Call Flow)

1 – Uma chamada da POTS chega no Voice Gateway originador. Uma Dial Peer POTS de entrada é selecionada (Inbound match)

2 – Após associar a chamada de entrada a uma Dial Peer POTS de entrada, o Voice Gateway originador cria uma Call Leg de entrada e a associa a um Call ID (Call Leg 1 na figura 1)

3 – O Voice Gateway originador utiliza os números discados para selecionar a Dial Peer VoIP de Saída (Outbound Match).

4- Após associar a chamada a uma Dial Peer VoIP de saída, o Voice Gateway originador cria uma Call Leg de saída e a associa a um Call ID ( Call Leg 2 na figura 1).

5 – A chamada chega no Voice Gateway de destino. Onde uma Dial Peer VoIP é selecionada.

6 – Após o Voice Gateway de destino associar a chamada de entrada a uma Dial Peer VoIP, ele cria uma Call Leg de entrada e associa a um Call ID ( Call Leg 3 na figura 1).

7 – O Voice Gateway de destino utiliza os números discados para selecionar a Dial Peer POTS de Saída.

8 – Após associar esta chamada a uma Dial Peer de saída, o Voice Gateway de destino cria uma Call Leg de saída POTS. Associa um Call ID e estabelece a chamada. ( Call Leg 4 na figura 1).

Em cenários onde o Cisco Unified Communications Manager atua com o Cisco IOS assume-se o seguinte:
Para chamadas de saída do CUCM através um Voice Gateway, o Voice Gateway atua como um dispositivo terminal.
Para chamadas de entrada para o CUCM através de um Voice Gateway, o Voice Gateway atua como um dispositivo originador. Conforme exibido na figura 2.

Figura 2 – CUCM atuando com Cisco IOS Voice Gateway
CallLeg2

 Fonte: cisco.com

Referência: Understanding Dial Peers and Call Legs on Cisco IOS Platforms

Enviado em Voice Gateways, VoIP | Etiquetado: | Deixar um comentário »

Interface E&M – Analógica

Publicado por ligiapeixoto em 28/12/2012

Pessoal,

Fiz um projeto com muitas localidades pelo País e dentre elas localidades com E&M com conexão a PABXs, percebi que quando se trata de E&M a situação fica bem complicada, pois não temos muitos materiais disponíveis e por tratar-se uma interface obsoleta. Essa implantação com E&M durou cerca de duas semanas, onde descobrimos que o problema era o cabeamento entre o PABX e o Gateway de Voz, por isso é muito importante uma comunicação direta com o mantenedor do PABX, para verificar se a placa do PABX é de 2 ou 4 fios e o tipo de discagem (DTMF ou pulse) entre outras configurações.

Muitas vezes o Gateway de Voz Cisco vem em substituição a alguma outra marca que já funcionava com PABX, então o mantenedor do PABX vai informar que já funcionava e que é problema no Gateway Cisco, por isso é necessário muita paciência e explicar ao mantenedor o funcionamento da integração.

E&M analógico

E&M análógico: É uma sinalização de tronco utilizada pelos PABXs baseada na ocupação dos fios E e M, utilizando para dígitos e fonia mais 2 ou 4 fiod. Somando com o fio utilizado para enviar o terra, pode-se dizer que se utiliza 7 ou 5 fios para uma conaxão E&M. Abaixo tipo de ocupações utilizadas:

Wink-Start – É aterrado o pino E para ocupação do canal e aguarda-se o receptor enviar um pulso Wink, só então são enviados os dígitos. Recebe durante algum tempo o ring-back até que o recpetor atenda e haja a conversação, quando desligado as duas pontas voltam para livre.

Immediate-start – esta sinalização é muito parecida com a anterior onde a diferença é que não é necessario o envio do pulso Wink. Dessa forma, assim que é feita a ocupação com aterramento do pino E, os dígitos são enviados logo em seguida. Recebe durante algum tempo o ring-back até que o recptor atenda e haja a conversação . Então quando desligado as duas pontas voltam para livre.

Delay-start – esta sinalização, após a ocupação com o aterramento do pino E, aguarda um tempo em milissegundos (Delay), e só após envia os dígitos. Recebe-se durante algum tempo o ringback até que o receptor atenda e haja a conversação. Então quando desligado as duas pontas voltam para livre. É pouco utilizada no Brasil.

Aterramento:
 
Aterramento é fundamental para que se possa ter sucesso numa instalação de E&M analógica, portanto é interessante entender que podem ser utilizados diversos tipos de aterramentos. O mais comum é o que chamamos de tipo V, porém também existem os tipos I, II e III.
Obs.: é necessário que seja feito o aterramento entre carcaças de roteador e PABX. Deve-se medir o aterramento, e podemos também medir os pinos E e M que devem estar entre -48 e -53 volts. O aterramento do Gateway Cisco deve ser feito corretamente onde o fio terra é preso no parafuso de ateramento no chassi.

                           TIPO I                                                                                       TIPO II

clip_image002[4]                          clip_image002[6]

                         TIPO III                                                                        TIPO IV

clip_image002[8]                 clip_image002[10]

 

- Entendendo parâmetros para configuração do E&M 
 
Para uma configuração E&M precisamos saber a sinalização utilizada nas ligações, o aterramento usado e a quantidade de fios Txs e Rxs que pode ser 2 fios (1 Txs e 1 Rxs) ou 4 fios (2 Txs e 2 Rxs), só assim podemos começar a configuração. Os comandos
utilizados são:
 
(a) Dial type – utilizado para selecionar o tipo de discagem, em pulso ou dtmf:
dial-type {dtmf | pulse}
(b) Signal type – determina o tipo de sinalização para ligações, Wink, Immediate ou Delay start: 
signal {wink-start | immediate | delay-dial}
(c) Call progress tone – utilizado para selecionar o tom utilizado:
cptone {country}
(d) Operation – determina a quantidade de fios Txs ou Rxs utilizados 2 ou 4:
operation {2-wire | 4-wire}
(e) Type – determina o tipo de aterramento utilizado, no Brasil o mais utilizado é o tipo V onde o pino E é saída (é aterrado) e o pino M é entrada (recebe o -48volts):
type {1 | 2 | 3 | 5}
(f) Impedance – especifica a impedância da terminação. Este valor deve ser encontrado no sistema de telefonia onde a porta está conectada:
impedance {600c | 600r | 900c | complex1 |complex2}

- Ainda temos os comandos opcionais:
 
(a) PLAR connection mode – modo de conexão, para acrescentar um número que será discado sempre que a porta seja ocupada:
connection plar string
(b) Description – utilizado para identificar a porta de voz:
description string
(c) Comfort noise (se VAD está ativado—VAD é um comando no dial peer) – utilizado para gerar um ruído de fundo para perceber a conexão:
comfort-noise
 
- Temos também os comandos de ajuste fino, onde são os citados acima, mais os seguintes timings:
 
(g) Timing other than timeouts – Determina o tempo de duração dos dígitos e pulsos para envio do roteador para o PABX:
timing clear-wait milliseconds – determina o mínimo de tempo entre um sinal de ocupação inativo e a chamada ser desconectada, de 200 aa 2000
timing delay-duration milliseconds – determina a duração da espera para uma chamada Delay-start, de 100 a 5000
timing delay-start milliseconds – Determina o mínimo de espera de uma ocupação até o envio dos dígitos, de 20 a 2000
timing dial-pulse min-delay milliseconds – determina o tempo entre a geração de um pulso wink. 0 a 5000
timing digit milliseconds – determina a duração do dígito, de 50 a 100
timing inter-digit milliseconds – determina a duração do tempo entre os dígitos, de 50 a 500
timing pulse pulse-per-second – determina a faixa de pulsos por segundos enviados, de 10 a 20
timing pulse-inter-digit milliseconds – determina o tempo entre os dígitos de pulso, 100 a 1000
timing wink-duration milliseconds – determina o máximo de duração de um pulso wink, de 100 a 400
timing wink-wait milliseconds – determina o máximo de espera de um pulso wink para iniciar o sinal, de 100 a 5000 
 

- Configuração que realizei para conexão com PABX (Philips/SOPHO 4050):

   Obs: Alguns comandos são implicito e por isso não aparecerão mesmo após aplicados

   Obs II: Após qualquer alteração na voice – port aplique shutdown/no shutdown

!
voice-port 0/1/0
trunk-group EM
dial-type dtmf
type 5
cptone br
signal immediate
operation 2-wire
impedance 600r
!

Referência Bibliográfica: VOFR/VOIP Fast Training, ABC de Voz. 3 Vers. São Paulo, 2003. 74 p (Apostila de Treinamento)
BONATTI;André,COBRA;Dárcio

Enviado em Voice Gateways, VoIP | 1 Comentário »

SRST para telefones SIP

Publicado por Aderno em 10/12/2012

Boa tarde galera!! Estive ausente do blog por um bom tempo mas estou de volta, para colaborar com o que for possivel. Então vamos lá.

Como sabemos, os telefones Cisco, na sua maioria, funcionam com os protocolos SCCP e SIP, o SCCP é o mais utilizado, mas tem alguns modelos de telefones, os das series 39xx, 89xx e 99xx que funcionam apenas com o protocolo SIP, o que requer configurações extra quando vamos habilitar o modo de sobrevivência nos gateways, o conhecido SRST.

Primeiro, precisamos configurar o Communications Manager, para que ele diga aos telefones SIP como permanecer funcionando em modo SRST na eventual falha dos servidores CUCM:

NO CUCM, vá no menu System > SRST e adicione uma referência SRST, se já não existir uma, e configure as informações do roteador que terá a função de SRST. É “obrigatório” configurar o campo “SIP Network/IP Address” para que os telefones SIP possam se registrar no gateway.

Imagem

Depois disso, é preciso configurar o roteador para registrar os telefones SIP na eventual falha dos servidores CUCM:

#voice service voip
     allow-connections sip to sip
     sip
          registrar server
#voice register global
    max-dn 100
    max-pool 42
    system message ##Em modo SRST##

voice register dn  1
    number 2001
voice register pool  1
    id network 10.232.232.0 mask 255.255.255.0    (Deve ser a rede onde os telefones SIP estão localizados)

call-manager-fallback
    max-conferences 8 gain -6
    transfer-system full-consult
    ip source-address 10.232.232.1 port 2000
    max-ephones 42
    max-dn 100

Podemos verificar se o telefone SIP está se registrando corretamente no SRST com o comando:

show sip-ua status registrar

Espero que possa ajudar!!!

Enviado em Callmanager, Voice Gateways | Deixar um comentário »

Rejeitando ou aceitando chamadas a cobrar via E1 R2-DIGITAL

Publicado por gvillarinho em 28/11/2012

Muitas empresas pedem para bloquear as chamadas a cobrar, em roteadores Cisco utilizando E1 R2 Digital é possível pelo comando double-answer dentro do CAS-CUSTOM da controladora E1. Após aplicar este comando, sugiro realizar um “shut / no shut” onde consiste em derrubar via comando a E1 e subir novamente, assim validando a configuração.

Porém, e quando a empresa pede para liberar as chamadas a cobrar?
Pois bem, vamos tentar!!

Primeiro passo, remova a configuração, se houver, de double-answer, utilizando “no double-answer” e em seguida, prossiga com o “shut / no shut” da porta E1.
Caso isso não surta efeito, há um comando oculto dentro do cas custom que pode nos ajudar, o “collect-call-enable”.

O que é um comando oculto ?

A Cisco possui diversos comandos ocultos em seu sistema operacional de roteadores/switchs e etc, o IOS. E estes comando não são completados automaticamente quando você começa a digitar e aperta o TAB, ou seja, é necessário digitar o comando inteiro e apertar ENTER para entrar com o comando. 

Voltando ao “collect-call-enable”, como descrito acima, precisa ser digitado por completo e inserido desta maneira, assim você liberará as chamadas a cobrar. Para este comando não é necessário realizar um “shut / no shut” ou qualquer boot no equipamento.

Ah, não encontrei nenhum documento Cisco oficial mostrando este comando, então não posso garantir se em IOS antigas este comando exista, mas vale a pena testar.

Agradecimentos ao Robson Fialho que me passou este link:
https://supportforums.cisco.com/thread/2127289

Enviado em Voice Gateways | Deixar um comentário »

Desconectar uma chamada especifica no Voice Gateway

Publicado por loliveira em 12/11/2012

Vai ai um “comandinho” bacana pra matar aquela chamada especifica no voice gateway.

Router# clear call voice causecode 1 id [ID da chamada]

Para coletar o ID da chamada digite o comando:  show voice call status conforme exemplo.

Router #show voice call status 
CallID CID ccVdb Port Slot/DSP:Ch Called # Codec MLPP Dial-peers
0x6E1F7 3F83 0x48A6AFBC 0/0/1:15.12 0/3:4 4323 g711ulaw 1/7000
0x6E20A 3F85 0x48A6AFBC 0/0/1:15.14 0/3:2 4322 g711ulaw 1/7000
0x6E212 3F86 0x48A6AFBC 0/0/1:15.15 0/1:4 1231 g729r8 1/7000
0x6E237 3D5B 0x48A6AFBC 0/0/1:15.31 0/1:1 *1123123123 g729r8 7000/1

Reparem que o Calling ID possui 4 caracteres.

Enviado em Voice Gateways | Deixar um comentário »

Utilizando Call Forward Unregistered para sobrevivência e conceitos de Globalização

Publicado por gvillarinho em 15/08/2012

Estes tempo, obtive uma demanda de configurar em um ambiente multi-site centralizado, com unidades espalhadas em vários estados, além de todas as configurações necessárias, uma delas me chamou mais a atenção que seria para que quando o telefone estiver em sobrevivência local, à chamada “ramal para ramal” continuasse transparente ao usuário final.

Funcionalidades

Com isso, cheguei a um pequeno design interessante onde faremos um mix em diversas features do Cisco Unified Communication Manager e Voice Gateway, para os que já estudaram a grade do CCNP Voice ou já precisou ler a respeito fica mais fácil o entendimento das features descritas abaixo:

- CFUR ( Call Forward Unregistered ) internal e/ou external, quando o telefone não estra registrado, automaticamente ele toma a ação configurada em sua pagina, podendo ser de jogar para o voice-mail ou encaminhar para outro numero.

- Globalization, conceito que é descrito no livro de estudo CIPT2, onde é transformado o que o usuário digitou para o padrão E.164 completo, exemplificando, quando um usuário de são Paulo disca para o numero fictício (11) 1234-5678, o E.164 ficaria +551112345678. Onde o sinal de mais (+) significa que é um numero padrão E.164, 55 significa código do Brasil , 11 significa área de São Paulo e 12345678 o numero discado.

- Localization, conceito que é descrito no livro de estudo CIPT2, onde um numero globalizado (globalized, como descrito acima do conceito de globalization ) ao sair por um determinado voice gateway é “transformado” para um numero legível para sua telefonia publica local. Aproveitando o exemplo acima do numero (11) 1234-5678, imagine que está chamada sairá por um voice gateway localizado no estado do Rio de Janeiro, onde seu código de área é diferente de São Paulo, então a chamada que quando sair pelo voice gateway(denominado call egress) esta como +551112345678 deverá ficar após sua transformação para o numero 0XX1112345678, onde o 0 no Brasil significa acesso a chamadas de Longa Distancia (DDD), o XX seria operadora desejada, 11 como código de área e o numero 1234-5678.

OBS: Ambos os conceitos de Globalization e Localization são mais utilizados com o NANP(North American Numbering Plan, padrão de dial-plan utilizados pelas operadoras PSTN) onde também possível dizer na própria composição dos dígitos se é local(subscriber), ddd(national) ou ddi(internacional). Como nosso dial-plan do Brasil não é NANP, temos que “adaptar”.

- Local Route Group, feature implementada na versão 7.1 do CUCM onde é possível definir um padrão dial-plan mais simplificado, que ao utilizar um route list com a opção do route group “Standard Local Route” ele buscará o route group associado no device pool do device phone e sairá por um determinado gateway.

- Called Party Transformation é uma feature utilizada para traduzir um numero já discado quando chegam a seu destino, podendo ser aplicado no voice gateway ou em device pools.

- SRST (Survivable Remote Site Telephony ) função que utiliza o gateway como PABX limitado quando há perda de conectividade entre o telefone e Cisco Unifed Communication Manager.

- num-exp ( number expansion ) é uma feature configurada no próprio voice gateway via CLI(linha de comando) onde permite adicionar dígitos ao numero discado ou mesmo modificar se necessário, antes mesmo da chamada dar “match” em uma dial-peer.

Ambiente e explicação

Alguns pontos para se importantes do meu ambiente:

- Meu ambiente utiliza Local Route Group para todos os gateways;
- Meus gateways estão em H.323 gateway;
- Os usuários não discam operadora, está inclusão é feita direto na Dial-peer do gateway.
- O Local route group, SRST e conectividades IP Phones via WAN já estão previamente configuradas,
- As traduções de unidade exemplo numero 1111-xxxx para 101-xxxx já estão previamente configuradas.

Caso tenha duvidas, nestes pontos listados, por favor deixe um post que lhe respondo.

Bem, depois desta apresentação das features e pontos do meu ambiente, vamos às configurações, mas antes disso vamos lembrar nossa ideia inicial, agora detalhando um pouco mais:

Os usuários em meu cliente possuem um padrão de sete dígitos em seus ramais, ou seja, três para site code + quatro para seu ramal próprio. Exemplos:

Usuário no site A ( onde o CUCM esta localizado fisicamente ) com o site code 101 ramal 1000, no estado de São Paulo código de área 11, possui o numero externo de (11) 1111-XXXX, onde XXXX representa sua faixa DDR.
Usuário no site B com o site code 102 ramal 1000, no estado de São Paulo código de área 11, possui o numero externo de (11) 2222-XXXX, onde XXXX representa sua faixa DDR.
Usuário no site C com o site code 103 ramal 1000, no estado de Rio de Janeiro código de área 21, possui o numero externo de (21) 3333-XXXX, onde XXXX representa sua faixa DDR.

Meu cliente pediu que, quando um usuário do site A ou C discasse para o site B o numero 2222-1000 (ou 0 + OPERADORA + 11 2222-1000 no caso para o site C no Rio de Janeiro) a chamada fosse traduzida para 102 1000, assim utilizando seu link WAN, diminuindo seu gasto com chamadas externas PSTN para a mesma empresa. E assim para os demais sites, ou seja, todos que fossem discados para chamadas externas pertencendo a sites diferentes, porém de mesma empresa seriam traduzidos para seus números internos de site code + ramal.
Até ai muito fácil e simples, porém o complicado estava por vir, que quando a chamada já traduzida estiver com o link WAN down e o telefone naquela unidade estiver em sobrevivência pabx limitado com o SRST ? Pois bem, utilizaremos o CFUR, uma feature bem “novinha” no Cisco Unified Communication Manager, eu acredito que entrou na versão 7.1. Até ai, ainda continua fácil, o maior desafio é que o que colocar no campo do CFUR ?
Pois se colocarmos redirecionarmos dos telefones do site B para 0(para pegar linha) + 22221000, os telefones do site A conseguirão fazer perfeitamente pois são do mesmo código de área (São Paulo 11) porém e as chamadas do site C que são de outro código de área (21 do Rio de Janeiro) ? se os usuários do Rio de Janeiro discarem para 0 (linha) + 2222-1000 poderá ser uma empresa ou residência do próprio Rio de Janeiro.

Foi ai que pensei em utilizar o globalization no CFUR, que isso deixaria a chamada em estilo “globalizado” e seria “localizado” em apenas no voice gateway de saída.

OBS: Ok, ok, podem existir outras maneiras de fazer como traduções nos gateways, utilizando AAR e o administrador manualmente altera o location na hora da queda para realizar o rerouting (sim, eu já vi isso!!!) , porém acredito eu que esta seja a melhor maneira, pois mantem as configurações centralizadas e mais fácil para expansão.

Continuando… depois de resolver o problema do CFUR com globalization, está na hora de vermos o lado oposto, que seria quando o site B esta em sobrevivência local, ou seja, sem conectividade ramal para ramal, mesmo assim consiga com transparência, continuar com esta fazendo ramal para ramal só que com utilizando a PSTN local, para isso usamos o num-exp.

Bem, depois de toda essa explicação, vamos as configurações e ao resultado.

 

Configuração

Passo 1 – Crie uma Calling Seach Space e uma partition para sua regra de globalização e associe a partição na CSS. Em meu exemplo, criei com o nome CSS_GLOBAL e PRT_GLOBAL

clip_image001

Passo 2 – Cria uma Route Pattern para a regra globalizada utilizando a partição PRT_GLOBAL

clip_image003

Faz-se necessário utilizar \ (barra) para entender que o sinal de + é padrão E.164.

Passo 3 – Adicionar na linha do usuário seu numero globalizado para que seja possível os outros sites realizarem chamadas via PSTN enquanto o site permanecer fora. Lembrando que é necessário preencher da seguinte forma + 55 CODIGO DE AREA + PREFIXO + XXXX, onde:

- +55 padrão E.164 e código do Brasil

- CODIGO DE AREA é código do estado, em nosso exemplo do site B é São Paulo 11

- PREFIXO da unidade, em nosso exemplo do site B é 2222

- XXXX é a mascará do ramal do usuário de 4 dígitos, caso o usuário tenha 5 ou mais dígitos em seu ramal, neste exemplo usará os 4 últimos dígitos.

Também não se esqueça de adicionar a CSS_GLOBAL que criamos no passo 1

clip_image005

Passo 4 – Criar uma Calling Search Space e partition para cada gateway de saída.

Aqui fica o seu critério como criar, pois pode se basear por código de área da unidade ou mesmo pelo numero de unidades que possuir, fica sua decisão.

Como assim? – Eu criei uma CSS e partição para cada voice gateway, pois assim tenho um controle melhor e restrinjo possíveis erros, mas não acredito que seja necessário, pode criar baseado pelo código de área da localidade, um exemplo, ao invés de criar 3 CSS e PRT no meu cenário de 3 sites, você criaria 2, porque o site A e B pertencem ao mesmo código de área (11 São Paulo).

Não se esqueça de associar a PRT criada no CSS. Em meu exemplo configurei CSS_<UNIDADE>_GATEWAY_SAIDA e PRT_<UNIDADE>_GATEWAY_SAIDA.

clip_image006

Passo 5 – Configurar o Called Party Transformation Pattern localizado na Aba Call Routing > Transformation > Transformation Pattern, para traduzir o numero quando o mesmo chegar no gateway de voz, basicamente aqui criei duas regras, uma para seu código de área (meu exemplo sendo o 11)outra para todas:

clip_image008

clip_image010

Passo 6 – Adicione a CSS_<unidade>_GATEWAY_SAIDA na opção Called Party Transformation CSS do device gateway e desmarque a opção “Use Device Pool Called Party Transformation CSS”.

clip_image011

Não esquece de salvar realizar um reset no device gateway.

Passo 7 – Acesse via CLI seu voice gateway e adicione todas as regras de tradução, exemplo:

- Se você estiver configurando o roteador do site B, deverá incluir as configurações para tradução do site A e C exatamente desta maneira:

#configure terminal
#num-exp 101…. 01111….
#num-exp 103…. 00213333….

Após esta configuração, será possível de um telefone IP em sobrevivência local realizar chamadas para suas unidades via PSTN.

Infelizmente, no gateway temos que adicionar todas as regras manualmente, uma a uma com o num-exp e ainda devemos nos atentar á utilização de chamadas locais ou DDD. A vantagem de se utilizar num-exp de outros métodos de tradução é que num-exp podemos utilizar até 255 entradas, enquanto o voice translation podemos utilizar até 15.

 

Duvidas?

Por favor, qualquer duvida, postem abaixo que teremos o prazer em responder.
Abraços.

Enviado em Callmanager, CCNP-V, Voice Gateways | 2 Comentários »

Configurando Media Resource em Voice Gateways

Publicado por leonardotns em 26/07/2012

A configuração de media resource em voice gateways é uma tarefa simples mas um pouco trabalhosa, é necessario verificar varios parâmetros, como dsp no gateway, recursos a serem utilizados.

Segue abaixo um documento do support forum da Cisco para realizar esta configuração passo a passo:

https://supportforums.cisco.com/docs/DOC-25511

Lembrando que no forum da Cisco existem varias documentações de todas as B.Us além de inúmeras discussões sobre problemas do mundo real.

Até a proxima.

Enviado em Voice Gateways | Deixar um comentário »

VC1, VC2 e VC3

Publicado por gvillarinho em 22/05/2012

Algo que sempre pode confundir e é bom saber, quando você vai configurar uma E1 ou interface analógicas para uma conexão com uma operadora que fornece custo reduzidos para ligações de celular o cliente vai mencionar exatamente está frase:

“Quero que a chamadas VC1 saiam pela operadora XXXX e a chamadas VC2 E VC3 pela operadora YYYY”

Agora ficou fácil, siga (ou decore/aprenda) a explicação abaixo:

VC1 – Quando a ligação originada de um celular para destino fixo, ou celular(está podendo ter um nome mais técnico de VC1M)

VC2 – Quando a ligação originada de um celular para destino fixo ou celular da mesma área primária do código de área, ou seja, uma chamada de origem localidade (11) para (19) apenas mudando o segundo digito. Exemplificando sempre será uma chamada VC2 quando um usuário da área 1X ligar para qualquer outra da 1X

VC3 – Quando a ligação originada de um celular para destino fixo ou celular de área primária do código de área diferentes, ou seja, uma chamada de origem localidade (11) para (21) por exemplo.

Fonte: http://www.procon.sp.gov.br/texto.asp?id=624

Enviado em Voice Gateways | Deixar um comentário »

Problemas com ligações de saida para a PSTN

Publicado por loliveira em 07/03/2012

Saudações, recentemente enfrentei problemas relacionado a ligações para a PSTN que não completava e gostaria de compartilhar aqui no AVVID.

A principio, tentei detectar o problema pelo debug isdn q931 ou o debug voice ccapi inout e de fato eu observei umas causas de desconexão muito estranha … como a 101 ( The Message is Not Compatible with the Call State ) sendo que a causa de desconexão era originada pela operadora, achei melhor fazer uma conjunta com a própria operadora para tentar detectar o problema.

Segundo a operadora eles estavam recebendo um padrão de sinalização diferente do que eles determinam como “padrão” e solicitaram que eu verificasse no voice gateway se tinha alguma particularidade relacionado a sinalização ISDN.  Após minha análise detectei que o padrão ISDN estava configurado com o padrão europeu (NET5) e algumas operadora nacionais não trabalham com este protocolo, vejam na configuração da interface os diversos padrões suportados pela IOS:

GATEWAY(config-if)#isdn switch-type primary       ?
primary-4ess Lucent 4ESS switch type for the U.S.
primary-5ess Lucent 5ESS switch type for the U.S.
primary-dms100 Northern Telecom DMS-100 switch type for the U.S.
primary-dpnss DPNSS switch type for Europe
primary-net5 NET5 switch type for UK, Europe, Asia and Australia
primary-ni National ISDN Switch type for the U.S.
primary-ni2c The Cisco NAS-SC switchtype based on NI2C.
primary-ntt NTT switch type for Japan
primary-qsig QSIG switch type
primary-ts014 TS014 switch type for Australia (obsolete)

Para coincidir com o padrão da operadora tive que alterar o switch-type para qsig, deixando assim no padrão genérico. A operadora disse que tinha melhorado o status pois agora eles estavam recebendo quase todos os parametros corretos, exceto o Transfer Capability =   que estava sendo enviado sem restrição. Veja um exemplo:

*Mar 6 13:21:27.152: ISDN Se0/0/0:15 Q921: User TX -> INFO sapi=0 tei=0, ns=32 nr=52
*Mar 6 13:21:27.152: ISDN Se0/0/0:15 Q931: SETUP pd = 8 callref = 0x0D0C
Bearer Capability i = 0×8890
Standard = CCITT
Transfer Capability = Unrestricted Digital
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA9838C
Exclusive, Channel 12
Calling Party Number i = 0×0081, ’5486′
Plan:Unknown, Type:Unknown
Called Party Number i = 0×80, ’0586186544334′

Com esta informação garimpei o site da Cisco e encontrei um documento mencionando este problema e como corrigi-lo:
https://supportforums.cisco.com/docs/DOC-2464

Acesse a voice port

Por Ex: voice-port x/y:z  e insira o comando bearer-cap 3100Hz

Pois as operadoras utilizam esta frequência no canal bearer para estabelecimento das chamadas.
Após esta alteração todas as chamadas passaram a funcionar adequadamente.

Segundo o documento da Cisco, isto acontece onde IP Phones que possui a funcionalidade de video envia informações adicionais no estabelecimento das chamadas, mas eu estava enfrentando este problema em modelos 7945, então ficou um pouco vago a explicação do Fabricante. Quando eu tiver uma nova oportunidade irei validar esta informação.

Enviado em Voice Gateways | Deixar um comentário »

Configuração de Criptografia no CME – Easy Mode

Publicado por loliveira em 16/02/2012

Galera, traduzi um documento bacana sobre como implementar criptografia no CUCME utilizando um script TCL que automatiza em torno de 60 linhas de comandos, que por sinal é um negócio chato pra kct para se configurar.

Vejam o procedimento aqui: https://supportforums.cisco.com/docs/DOC-22788

Testado e aprovado !!!

Enviado em Callmanager Express, Voice Gateways | Deixar um comentário »

Entendendo o debug isdn q931

Publicado por loliveira em 13/02/2012

Quando habilitamos o debug isdn q931 vemos diversas informações, mas para agilizar o troubleshooting  duas são as mais importantes, veja o exemplo abaixo:

20:52:14: ISDN BR0: TX -> SETUP pd = 8 callref = 0x2E
20:52:14: Bearer Capability i = 0×8890
20:52:14: Channel ID i = 0×83 20:52:14: Keypad Facility i = ’5551111′
20:52:15: ISDN BR0: RX <- CALL_PROC pd = 8 callref = 0xAE
20:52:15: Channel ID i = 0×89

20:52:16: ISDN BR0: RX <- PROGRESS pd = 8 callref = 0xAE
20:52:16: Progress Ind i = 0x8A81 – Call not end-to-end ISDN,
may have in-band info
20:52:16: Signal i = 0×01 – Ring back tone on
20:52:34: ISDN BR0: RX <- DISCONNECT pd = 8 callref = 0xAE
20:52:34: Cause i =0x829F08 – Normal,unspecified or Special intercept,
call blocked group restriction
20:52:34: ISDN BR0: TX -> RELEASE pd = 8 callref = 0x2E
20:52:34: ISDN BR0: RX <- RELEASE_COMP pd = 8 callref = 0xAE

 

O Keypad Facility é o número discado pelo usuário, e o Cause i= É a informação relacionada a desconexão da chamada.

Com o  Cause i=  já temos quem originou a desconexão, a causa da desconexão e informação de diagnóstico (se configurado).
” Pô, mas é um código com 8 caracteres, como pode ter tais informações ?”

O 0x indica que é um código hexadecimal, restando apenas 6 para o troubleshooting.

O 82 indica quem é o originador da desconexão. [Cause Code Origination Point]

O 9F é a causa da desconexão. [Disconnect Cause Code]

O 08 é o parametro de diagnóstico. [Optional Diagnostic field] (se configurado)

Neste documento da Cisco temos todos os códigos dos 3 campos e suas explicações em detalhe.
http://www.cisco.com/en/US/tech/tk801/tk379/technologies_tech_note09186a008012e95f.shtml

Enviado em Voice Gateways | Deixar um comentário »

Entendendo o Network Time Protocol (NTP)

Publicado por loliveira em 13/02/2012

O NTP é um protocolo para sincronismo de horário entre diversos dispositivos que se comunicam utilizando o TCP/IP, o uso de NTP nos roteadores e em qualquer dispositivo da infraestrutura de UC é extremamente importante para termos dados coerentes de estabelecimento de chamadas, bilhetagem e principalmente de logs.

Segue um documento explicando sobre o NTP e como configurar nos roteadores e voice gateways.
http://packetlife.net/blog/2011/mar/28/cisco-ios-clocks-and-ntp/

PS: É altamente recomendável configurar um NTP server para o CUCM. A configuração do NTP no CUCM é feita na página OS Administration do CUCM Publisher.
Os Subscribers utilizam o Publisher como NTP server.

Mais info: http://htluo.blogspot.com/2009/02/ntp-network-time-protocol.html

Enviado em Callmanager, Voice Gateways | Deixar um comentário »

Configurando um SRST básico

Publicado por loliveira em 11/01/2012

Video tutorial em “indianglish” (indiano falando inglês) ensinando a configurar um Survivable Redundancy Site Telephony (SRST).

https://supportforums.cisco.com/videos/3031

 

Enviado em Voice Gateways | Deixar um comentário »

Nova feature dos IOS 15– Toll-Fraud Prevention

Publicado por gvillarinho em 22/12/2011

Com a chegada da nova versão de IOS da Cisco agora para seus roteadores ISR2 (e ISR1 também) temos novas features, uma delas que conheci foi a Toll-Fraud Prevention. Sua função é, nada mais nada menos, que para prevenir conexões indesejadas de chamadas, a feature bloqueia conexões de call setup signaling que não estejam em sua “white list” (ou como o nome da feature menciona, em sua trusted list), ou seja, há necessidade de adicionar o ip da origem para receber a conexão da chamada.

Esta feature foi adicionada nas IOS a partir da versão 15.1(2)T.

Como descobrir se esta feature está lhe bloqueando alguma conexão?

Para descobrir habilite o debug #debug voice ccapi inout;
Verifique se o disconnect cause da chamada é 21 (Call Rejected) e também irá aparecer um processo no meio do debug chamado _ManagedAppProcess_TOLLFRAUD_APP. Como mostrado no trecho do debug abaixo:

Dec 16 15:15:42.089: //8405/2EAFA232BD7A/CCAPI/cc_process_call_setup_ind:
   Event=0x2B547728
Dec 16 15:15:42.089: //-1/xxxxxxxxxxxx/CCAPI/cc_setupind_match_search:
   Try with the demoted called number 5737
Dec 16 15:15:42.089: //8405/2EAFA232BD7A/CCAPI/ccCallSetContext:
   Context=0x3007694C
Dec 16 15:15:42.089: //8405/2EAFA232BD7A/CCAPI/cc_process_call_setup_ind:
   >>>>CCAPI handed cid 8405 with tag 1200 to app "_ManagedAppProcess_FRAUD_APP"
Dec 16 15:15:42.089: //8405/2EAFA232BD7A/CCAPI/ccCallDisconnect:
   Cause Value=21, Tag=0×0, Call Entry(Previous Disconnect Cause=0, Disconnect Cause=0)
Dec 16 15:15:42.089: //8405/2EAFA232BD7A/CCAPI/ccCallDisconnect:
   Cause Value=21, Call Entry(Responsed=TRUE, Cause Value=21)
Dec 16 15:15:42.089: //8405/2EAFA232BD7A/CCAPI/cc_api_get_transfer_info:
   Transfer Number Is Null
Dec 16 15:15:42.089: //8405/2EAFA232BD7A/CCAPI/cc_api_call_disconnect_done:
   Disposition=0, Interface=0x2B30BBDC, Tag=0×0, Call Id=8405,
   Call Entry(Disconnect Cause=21, Voice Class Cause Code=0, Retry Count=0)
Dec 16 15:15:42.089: //8405/2EAFA232BD7A/CCAPI/cc_api_call_disconnect_done:
   Call Disconnect Event Sent
Dec 16 15:15:42.089: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa:
Dec 16 15:15:42.089: :cc_free_feature_vsa freeing 318C4468
Dec 16 15:15:42.089: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa:

Como manuseiar esta feature para seu funcionamento ?

Há 3 maneiras para realizar a liberação desta feature:

1 – Liberar por IP ou range de IPs para aceitar conexões, na configuração global do roteador, digite:

voice service voip
ip address trusted list
  ipv4 <IP_HOST> 255.255.255.255 ! <—– Caso queira libere apenas um endereço IP 
  ipv4 <IP_REDE> <MASK> !             <—– Caso queira liberar range de endereços IP’s

2 – Liberar tudo, caso queira liberar tudo para qualquer conexão entrar:

voice service voip
ip address trusted list
  ipv4 0.0.0.0 0.0.0.0

3 – Desabilitar a feature, caso queira voltar como era antes dessas novas IOS:

voice service voip
no ip address trusted authenticate

 

OBS: Eu recomendo que use a primeira opção, pois irá dispor de maior segurança em seu ambiente.

 

Comportamentos da feature?

A Cisco pensou em tudo, pelo menos ficou bem redondo esta feature. Uma vez que, você adiciona as dial-peers voice voip no roteador, esta feature automaticamente adiciona o IP de destino que você adicionou da dial-peer como trusted IP na lista dela. Então será necessario você adicionar poucos ips na lista de trusted.

 

Link do documento

http://www.cisco.com/en/US/tech/tk652/tk90/technologies_tech_note09186a0080b3e123.shtml

 

Enviado em Voice Gateways | 1 Comentário »

Configurando um IOS Conference Bridge

Publicado por loliveira em 19/12/2011

Abaixo segue os passos para configurar um Hardware Conference Bridge.

Configure os recursos de DSP no Voice Gateway para habilitar a conferência.

voice-card 0
dspfarm
dsp services dspfarm
sccp local Loopback0
sccp ccm 10.10.1.1 identifier 1 priority 1 version 7
sccp ccm 10.10.1.2 identifier 2 priority 2 version 7
sccp
sccp ccm group
bind interface Loopback0
associate ccm 2 priority 1
associate ccm 1 priority 2
associate profile 1 register Matriz

dspfarm profile 1 conference
codec g729r8
codec g729ar8
codec g711ulaw
codec g711alaw
maximum sessions 4
associate application SCCP
no shutdown

Depois de configurado acess o CUCM Administration > Media Resources > Conference Bridge > Add new

Conference Bridge Type = Cisco IOS Enhanced Conference Bridge
Conference Name = Matriz  (O mesmo nome do associate profile configurado no Voice Gateway)
Selecione o Device Pool, location, e Security Mode se houver.
Salve e pronto o Gateway está configurado como Conference Bridge.
Agora adicione ele no Media Resource Group, Media Resource Group List e Device Pool dos Dispositivos que irão utilizar este recurso de conferência.

Comandos para Troubleshooting no voice gateway:

show sccp connection
show sccp ?
show dspfarm all
show dspfarm ?

Enviado em Voice Gateways | Deixar um comentário »

« Entradas Anteriores
 
Seguir

Obtenha todo post novo entregue na sua caixa de entrada.

Junte-se a 105 outros seguidores

%d bloggers like this: