Architecture for Voice, Video and Integrated Data

Cisco Unified Communications

Archive for the ‘Voice Gateways’ Category

Configurando uma E1 ISDN

Posted by loliveira em 24/09/2015

Procedimento passo-a-passo para se configurar E1 ISDN em Voice Gateways Cisco.

https://supportforums.cisco.com/document/125801/basic-isdn-pri-e1-configuration

Anúncios

Posted in Voice Gateways | Leave a Comment »

Decodificador Online para QSIG Facility IE

Posted by loliveira em 23/01/2014

Vai ai uma dica do Peterson Cristovam para tradução do QSIG Facility IE que é exibido com o debug isdn q931.

http://decoder.telemak.org/

Posted in Voice Gateways | Leave a Comment »

Troubleshooting – Comandos “show”

Posted by loliveira em 19/12/2013

Site interessante com diversos comandos para troubleshooting em voice gateways, o bacana deste site é o exemplo do output que cada comando fornece.

http://www.mackersoft.com/umwisdom/showcommands/showcommands.php

Posted in Voice Gateways | Leave a Comment »

Destination-Pattern com $

Posted by loliveira em 01/08/2013

A lógica do roteamento das chamadas no Voice Gateway sempre irá dar prioridade para a pattern terminando com $.

O uso do $ instrui o Gateway a fazer o seguinte ao analisar os dígitos e começar a procurar a dial-peer: “Para de pensar e roteia logo!!!”

O comando preference não funcionaria pois algoritmo de busca continuaria a procurar pela rota mais especifica primeiro.

Exemplo:

dial-peer voice 1 pots
destination-pattern 1234
port 1/0

dial-peer voice 2 pots
destination-pattern 1234$
port 1/1
preference 10
Para rotear a chamada para o ramal 1234, a dial-peer 2 sempre será eleita, mesmo com preference maior.

 

Nota: O comando prefence é um pouco confuso, mas memorize o seguinte:

Em escala de 0 a 10 onde:
preference 0 (default) = Maior prioridade
preference 10 = Menor prioridade

O preference 0 por ser default, não é exibido na dial-peer.

Posted in Voice Gateways | Leave a Comment »

Debug para DTMF Relay em H.323

Posted by loliveira em 26/07/2013

 

Comando: debug h245 asn1

Configura o exemplo abaixo:

Aug 21 21:07:37.902: h245_decode_one_pdu: more_pdus = 0, bytesLeftToDecode = 7
Aug 21 21:07:37.902: H245 MSC INCOMING ENCODE BUFFER::= 6D810447200063
Aug 21 21:07:37.902:
Aug 21 21:07:37.902: H245 MSC INCOMING PDU ::=

value MultimediaSystemControlMessage ::= indication : userInput : signal :
{
signalType “9″
duration 100
}

 

Posted in Voice Gateways | Leave a Comment »

Voice Translation-Rules e Translation Profiles

Posted by loliveira em 11/07/2013

Post bem interessante sobre Translation Rules e Translation Profiles criado pelo Bruno, do CCIE Voice Brasil. Vale a pena conferir

http://ccievoicebrasil.blogspot.com.br/2013/06/voice-translation-rules-e-voice.html

Posted in Voice Gateways | Leave a Comment »

Voice Gateway – Telnet Reverso

Posted by loliveira em 02/07/2013

Segue abaixo o link para um procedimento genério para quem precisa configurar um Telnet Reverso em um equipamento Cisco.

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

Para quem não sabe: O Telnet Reverso é o método que utiliza a porta auxiliar de um roteador/switch cisco para conectar na porta console de outro roteador/switch.

Em casos críticos o Tshoot só é possível acessando o equipamento pela console.

Posted in Voice Gateways | Leave a Comment »

Entendendo Dial Peers e Call Legs nas plataformas Cisco IOS

Posted by 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

Posted in Voice Gateways, VoIP | Etiquetado: | Leave a Comment »

Interface E&M – Analógica

Posted by ligiavillarinho 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

Posted in Voice Gateways, VoIP | 1 Comment »

SRST para telefones SIP

Posted by 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!!!

Posted in Callmanager, Voice Gateways | 1 Comment »

Rejeitando ou aceitando chamadas a cobrar via E1 R2-DIGITAL

Posted by 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

Posted in Voice Gateways | 5 Comments »

Desconectar uma chamada especifica no Voice Gateway

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

Posted in Voice Gateways | Leave a Comment »

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

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

Posted in Callmanager, CCNP-V, Voice Gateways | 2 Comments »

Configurando Media Resource em Voice Gateways

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

Posted in Voice Gateways | Leave a Comment »

VC1, VC2 e VC3

Posted by 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

Posted in Voice Gateways | Leave a Comment »

 
%d blogueiros gostam disto: