Por exemplo, a empresa disponibiliza o número 3123-4444 para os funcionários. A partir de qualquer lugar com um telefone (seja da casa dele, do celular, da rua), ele pode ligar para esse número pagando uma chamada local (claro, caso ele esteja dentro da mesma cidade), digitar uma identificação e senha, e fazer chamadas para qualquer outro lugar: ramais internos da empresa, chamadas locais, DDD, DDI, ... como se ele estivesse no próprio ramal.
No sistema da Cisco, quem atende a chamada é uma gravação, que pede ao usuário o "Remote Destination Number" (opcional) e depois o PIN. Caso seja autenticado, o usuário pode pressionar 1 e depois o número que ele deseja seguido da tecla #.
Vamos ver como é a configuração:
O pré-requisito para isso é que o usuário tenha sido habilitado com a feature de Mobility, que é exatamente o que fizemos no post anterior. Só para recapitular:
1. Configuramos o End User, habilitando o Mobility. Agora vamos ter que habilitar também a opção Enable Mobile Voice Access.
2. Criamos um Remote Destination Profile
3. Criamos um Remote Destination
4. Mudamos uns Service Parameters
Feito isso, vamos começar a configuração do MVA. Existem duas situações diferentes, que afetam a forma de configurar a funcionalidade: MGCP ou H.323? Para o MVA funcionar, obrigatoriamente teremos que ter um gateway H.323! Então para fazer funcionar como MGCP, teremos que fazer uma pequena gambiarra chamada de call hairpinning. Falarei disso mais para frente.
1. Gateway H.323
Se o seu gateway já for H.323, a configuração é um pouco mais simples:
1.1 Service Parameters
Alguns service parameters precisam ser alterados:
- Enable Mobile Voice Access: True
- Mobile Voice Access Number: Pode deixar em branco.
- Matching Caller ID with Remote Destination: Complete Match ou Partial Match. Já falamos disso no post passado... é a forma que vamos enxergar o Remote Destination para que ele dê match com o ANI da chamada quando você ligar a partir do celular. O interessante é que se o sistema conseguir dar o match certinho, a gravação não vai pedir para o usuário digitar um Remote Destination Number. Ela pedirá o PIN diretamente. Por isso, recomendo você rodar um debug isdn q931 e ver como a operadora está mandando o ANI, para assim você conseguir fazer o match. Um detalhe: No post anterior vimos que esse match também serve para quando você ligar do seu celular para um ramal interno, certo? Caso ocorra o match, ao invés de aparecer o número do seu celular no Caller ID, vai aparecer o seu nome e ramal. Só que nessa situação, a chamada pode entrar por qualquer um dos gateways. Tipo, se você ligar do seu celular (11) 9999-8888 para um ramal no Branch 1, a chamada vai entrar pela PSTN do Branch 1. E digamos que essa PSTN esteja enviando como ANI a string 551199998888. Mas quando você ligar do seu celular para o piloto do MVA que estamos criando, a chamada vai entrar pela PSTN do Head Quarters, e digams que a PSTN esteja enviando como ANI 1199998888. E agora, como fazer para o nosso Remote Destination dar match nas duas situações? Temos algumas opções... a primeira é criar outro Remote Destination, pois cada usuário pode ter até 10 Remote Destinations (limite configurável na tela do End User), mas essa solução não é muito escalável. A segunda seria alterarmos o ANI do BR1 através de translation-profiles no gateway, e fazer com que os sites padronizem os seus ANIs para, por exemplo, 1199998888. Não adianta tentarmos mudar os parâmetros para partial match e mudar a quantidade de dígitos para match, porque como eu falei no post anterior, o sistema sempre tentará dar match com o ANI inteiro! Pelo menos foi o que eu observei nos testes, mas não é bem isso que está na documentação da Cisco.
- Number of Digits for Caller ID Partial Match: Se utilizar Partial Match, defina aqui a quantidade de digitos do Remote Destination que será utilizada para o match.
- System Remote Access Blocked Numbers: Caso deseje bloquear algumas patterns no MVA, defina aqui separando por virgulas. Você pode por exemplo querer bloquear chamadas 190 no MVA.
1.2 Mobile Voice Access
Em Media Resource >> Mobile Voice Access, defina um número que o sistema utilizará para rotear as chamadas do MVA. Pode ou não ser o mesmo número que o pilot (4444).
Quando você tentar fazer uma chamada usando o Mobile Voice Access, o que o roteador vai fazer é enviar para o Call Manager a chamada usando o MVA DN como DNIS e o número que você quer ligar como RDNIS, assim:
cisco-ani=1199998888
cisco-anitype=0
cisco-aniplan=1
cisco-anipi=0
cisco-anisi=1
dest=5010
cisco-desttype=0
cisco-destplan=1
cisco-rdie=74
cisco-rdn=1002
cisco-rdntype=0
cisco-rdnplan=1
cisco-rdnpi=0
cisco-rdnsi=0
cisco-redirectreason=10 fwd_final_type =0
final_redirectNumber =
hunt_group_timeout =0
Nesse debug, o meu MVA DN é o 5010. E através do MVA, estava tentando chegar no ramal 1002.
O MVA DN é único no sistema... se você tiver a feature rodando em 5 gateways diferentes, o MVA DID (piloto) pode ser diferente para cada um, mas o MVA DN tem que ser o mesmo. E o gateway tem que ter acesso ao MVA DN.
Para o exemplo, vou deixar o MVA DN diferente do MVA DID. O MVA DN vai ser 5010. Só para vermos como fica a configuração.
1.3 Configuração no Gateway
Agora é necessário criar uma aplicação no gateway. O MVA na verdade é um script VXML que o gateway executa. Para facilitar, pegue a configuração no Help do próprio CUCM, buscando pela string VXML. Para a prova, mais importante do que saber tudo decor, é saber onde buscar as informações que você precisa. A configuração abaixo foi extraída do próprio Help, com algumas modificações para bater com o que temos no nosso ambiente.
application
service mva http://<IP-Publisher>:8080/ccmivr/pages/IVRMainpage.vxml
dial-peer voice 4444 pots
service mva ! -- Chama a aplicação
incoming called-number 4444 ! -- MVA DID
no digit-strip
dial-peer voice 100 voip
destination-pattern 5010 ! -- MVA DN
session-target ipv4:<IP-Publisher>
voice-class codec 1
voice-class h323 1
preference 1
dtmf-relay h245-alphanumeric
no vad
dial-peer voice 101 voip
destination-pattern 5010 ! -- MVA DN
session-target ipv4:<IP-Subscriber>
voice-class codec 1
voice-class h323 1
dtmf-relay h245-alphanumeric
no vadRepare que se o nosso MVA DN estivesse no range DDR, provavelmente eu já teria uma dial-peer criada. Por exemplo, se o meu MVA DN fosse 4444 também, eu já teria uma dial-peer com destination-pattern 4...$ apontando para os CUCMs, e nesse caso não precisaria criar essas duas novas.
1.4 Remote Destination Profile
A Calling Search Space remote destination profile vai definir a permissão de discagem desse usuário via MVA (ou, caso você esteja usando o método Line-Based approach, será a CSS da Line que definirá a permissão). Por isso, se você tentar fazer uma chamada via MVA e ouvir "your call cannot be completed as dialed...", verifique as suas CSSs.
2. Gateway MGCP
Se o seu gateway for MGCP, precisaremos fazer um Call Hairpinning. Isso é, a chamada vai entrar via MGCP para o CUCM, e ele vai mandar de volta para o gateway via H.323. A configuração vai ser parecida, mas precisaremos de umas coisas a mais.
2.1 Service Parameters
Mesma coisa fizemos lá em cima...
2.2 Gateway H.323
Adicione o gateway H.323 no CUCM, e atribua a ele uma nova Calling Search Space que tenha acesso a uma Partition chamada PT_MVA (ou algo do tipo). O importante é que só ele tenha acesso a essa Partition... o gateway MGCP não pode ter.
2.3 Route Pattern
Crie uma Route Pattern para o número 4444 apontando para o gateway H.323. Essa rota tem que ser visível pelo gateway MGCP. A idéia é que as chamadas que entrem para o número 4444 sejam encaminhadas de volta para o roteador, via H.323.
2.4 Mobile Voice Access
Da mesma forma que fizemos lá em cima, vamos criar um MVA DN 5010, na partition PT_MVA, que apenas o Gateway H.323 vai ter acesso.
2.5 Configuração no Gateway
Também vamos pegar a config do Help, procurando pela string VXML, mas agora entrando no capítulo "Configuring an H.323 Gateway for System Remote Access by using hairpinning". Para facilitar, vou criar as duas dial-peers (de entrada e saída) em uma só. Posso fazer isso agora porque ambas são do tipo voip, diferente do caso anterior, onde a 4444 era pots e as outras duas eram voip.
application
service mva http://x.x.x.x:8080/ccmivr/pages/IVRMainpage.vxml
service mva ! -- Chama a aplicação
destination-pattern 5010 ! -- MVA DN (saída para o CUCM)
session target ipv4:<IP Publisher>
incoming called-number 4444 ! -- MVA DID (entrada do CUCM
para a aplicação)
dtmf-relay h245-alphanumeric
codec g711ulaw
no vad
Nesse caso, como faremos a chamada vai entrar por uma dial-peer voip H.323 do CUCM, e sair para o CUCM através de outra dial-peer voip H.323, é necessário habilitar o CUBE:
voice service voip
allow-connection h323 to h323
2. Troncos R2-Digital
Se por acaso você está lendo isso pensando em implantar em alguma localidade no Brasil, note que isso não funciona muito bem com R2-Digital. Se o tronco for R2, você tem que fazer Call Hairpinning! E aí, aquele esquema de ele já reconhecer o número de origem e pedir o PIN diretamente não vai funcionar... O que eu faço nesses casos é configurar o remote destination como sendo o ramal do usuário. Sim, você vai perder a funcionalidade do Mobile Connect, mas caso o cliente queira apenas o MVA, essa é uma boa saída. Aí como remote destination o cara digita o ramal, e depois digita o PIN. Ou troque o seu link para ISDN, que é muito mais rápido, muito mais fácil de configurar e fazer troubleshooting, e até onde eu sei, é o mesmo preço. Vamos acabar com essa merda de R2 no Brasil! ahahuahuah
Nenhum comentário:
Postar um comentário