Mobile Voice Access

Ontem eu postei sobre Mobile Connect, e hoje vou falar sobre Mobile Voice Access, para fechar esse assunto de Unified Mobility. O Mobile Voice Access é conhecido no mercado de telefonia como DISA (Direct Inward System Access). É um número piloto que o usuário pode ligar, e a partir dele, fazer chamadas para outros destinos (internos ou externos). 
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 vad

Repare 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

dial-peer voice 5010 voip
 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

Mobile Connect

Para quebrar um pouco essa sequencia de posts sobre Messaging, vou falar hoje sobre o Mobile Connect, ou Single Number Reach. O que essa feature faz é o seguinte:
Digamos que eu tenha um IP Phone com ramal 5001 e um celular de número (11) 9999-8888. Mas eu sou uma pessoa que vive fora do escritório, e além disso o meu celular é pessoal, e não quero ficar divulgando para os clientes. O único número que os clientes possuem é o meu ramal. Mas eu quero que quando alguém ligar nele, a chamada toque ao mesmo tempo no meu celular, de forma que eu possa atendê-la em qualquer um dos dois dispositivos. Além disso, ninguém na empresa sabe o número do meu celular, e eu nem quero que saibam para que não fiquem me ligando direto. Então eu quero que quando eu ligar para algum ramal da empresa, apareça no telefone como Caller ID o meu ramal com o meu nome, e não o número do meu celular.
É para isso que serve o Mobile Connect.

Para configurar é bem fácil:

1. End User
Primeiramente é preciso criar um End User e habilitar para ele a opção Enable Mobility. Cada usuário habilitado com essa feature consumirá 4 DLUs (licenças), a não ser que você associe o usuário a um telefone através do campo Primary User Device. Nesse caso, cada usuário consumirá 2 DLUs.
Outro parâmetro a ser configurado aqui é o Maximum Wait Time for Desk Pickup. Quando você estiver com uma chamada ativa do seu celular para um ramal interno (ou de um ramal interno para o seu celular), e você desligar a chamada no celular, o seu deskphone vai mostrar a ligação em espera por x milissegundos, e te dará a possibilidade de recuperar a chamada. Dessa forma, você pode transferir a chamada do celular para o deskphone. Esse tempo de x milissegundos que a chamada ficará em espera no IP Phone é configurado através desse parâmetro.

2. Remote Destination Profile
Em Device >> Device Settings >> Remote Destination Profile, teremos que criar um novo profile para esse usuário. O importante aqui é associarmos o User ID e atribuirmos a Calling Search Space e a Rerouting Calling Search Space.
A Calling Search Space vai definir a permissão de discagem do seu profile, e será utilizada quando formos falar de Mobile Voice Access (provavelmente no próximo post). Porém, ela pode também ser utilizada para chegar nos ramais quando você ligar a partir do celular. Por padrão, quando você ligar do seu celular para um ramal da empresa, a Calling Search Space utilizada será a do Gateway. Mas se você mudar o Service Parameter Inbound Calling Search Space for Remote Destination para "Remote Destination Profile + Line Calling Search Space", essa CSS em conjunto com a CSS da Line definirão a visibilidade do profile. Assim, você pode por exemplo dar a essa CSS a permissão de chegar apenas a uma Translation Pattern XXXX, e não diretamente aos ramais. E nessa Translation, podemos ter uma regra de transformation no número de origem, por exemplo, "Use Calling Party's External Phone Number Mask". Fazendo isso, podemos manipular a forma que o ANI será apresentado aos telefones quando você ligar a partir do seu celular.
Bom, e quando alguém ligar no seu ramal e o sistema enviar a chamada para o seu celular, é a Rerouting Calling Search Space que vai definir a saída para ele. Ou seja, essa CSS tem que ter acesso a uma Route Pattern para o seu celular. Caso você esteja usando Local Route Groups, é melhor criar uma Route Pattern específica para os celulares, apontando para o Gateway local, e criar uma Calling Search Space específica. Senão a chamada vai sair pelo Voice Gateway do telefone que originou a chamada.

Depois que criar o Remote Destination Profile, adicione um DN com o mesmo número e partition (ou seja, um shared line) com o seu ramal de mesa. No caso do nosso exemplo, 5001.

3. Remote Destination
Na própria tela de configuração do Remote Destination Profile, vá em Add a New Remote Destination para criar um... Remote Destination. Em Destination Number vamos colocar o número do celular da forma que ele vem da PSTN, por exemplo 1199998888 (depois falarei mais sobre isso). Answer Too Soon Timer é o tempo em ms que tem que passar antes de o celular atender, porque por exemplo, vamos supor que a chamada vai para o seu celular, mas ele está fora de área e cai na caixa postal. Nesse caso, ele nem vai tocar... a mensagem da caixa postal ja atende imediatamente. Aí o sistema não faz a transferência porque o celular atende antes do tempo estipulado nesse parâmetro.  E Answer Too Late Timer é o contrário, ele define em ms quanto tempo o seu celular vai ficar tocando até que o sistema derrube a conexão. Se esse tempo for muito grande, pode ocorrer de o celular desviar para a caixa postal dele, e não é isso que queremos. Depois que esse tempo é expirado, o celular parará de tocar, e o seu deskphone continuará tocando até o tempo de No Answer dele, e dessa forma a chamada é desviada para o seu Voice Mail corporativo, e não para o do seu celular.
Em Ring Schedule é possível definir os dias e horários que o seu celular vai estar ativo para receber as chamadas. Você pode não querer receber chamadas durante o final de semana, por exemplo.
E no quadro When receiving a call during the above ring schedule, podemos definir algumas políticas baseadas em Access Lists (Call Routing >> Class of Control >> Access Lists). Com isso conseguimos definir números que desviam para o celular, e números que não desviam. Por exemplo, se eu quiser que nenhum número de Campinas (DDD 19) toque no meu celular, eu crio uma nova Access List do tipo Blocked, e coloco como Filter Mask "Directory Number" e DN Mask "19!". Depois eu aplico essa Access List dentro do Remote Destination, no campo "Do not ring this destination if caller is in".
Dentro de Remote Destination também, é importante marcar os campos Mobile Phone e Enable Mobile Connect. E marque também a opção Line Association.

4. Application Dial Rules
Agora quando ligarem para o seu ramal 5001, o sistema tentará encaminhar a chamada para o número 1199998888. Mas eventualmente esse número pode não ser "discável" pelo CUCM. Precisamos formatar ele, para que dê match em uma Route Pattern. Fazemos isso em Call Routing >> Dial Rules >> Application Dial Rules. Para o exemplo vamos criar uma com os parâmetros:
Number begins with: 11
Number of Digits: 10
Total Digits to be Removed: 2
Prefix With Pattern: 0
O resultado disso será a string 099998888, que dará match na nossa Route Pattern.

4. Service Parameters
Já está quase pronto. Só precisamos ajustar dois Service Parameters (ou não, dependendo do caso), que são o Matching Caller ID with Remote Destination e o Number of Digits for Caller ID Partial Match. Se o primeiro estiver como Complete Match, o segundo é indiferente.
O que esses parâmetros fazem é definir a quantidade de dígios do Remote Destination que será utilizada para dar match com o número do seu celular. Por exemplo, digamos que a PSTN esteja enviando para nós como ANI o número 1199998888. Como o nosso Remote Destination já está como 1199998888, podemos deixar como Complete Match. Mas se configurássemos o Remote Destination como +551199998888, teriamos que deixar como Partial Match, e dar match em 10 dígitos. Assim, os 10 digitos do ANI dariam match com os 10 últimos do Remote Destination.
Mas aqui está a confusão, pelos testes que eu fiz, esses parâmetros não alteram a quantidades de dígitos do ANI que eu vou ver... se a operadora me mandou 10 dígitos, eu vou ter que dar o match desses 10. Então como a PSTN mandou 1199998888, eu nunca poderia ter um remote destination menor, tipo 99998888. Nunca daria match, por mais que eu mude os meus parâmetros no Service Parameters. A documentação da Cisco é muito confusa sobre esses parâmetros, então eu utilizo essa regra: Sempre considere o ANI completo para o match... se não der, mude o ANI através de uma translation-profile no gateway. Pensando dessa forma, não tive mais problemas.

5. Softkey Template
Por fim, vamos criar uma nova Softkey Template incluindo a tecla Mobility em Idle e Connected. Em idle a tecla servirá para você manualmente ligar ou desligar o Mobile Connect. E em Connected servirá para você transferir uma chamada ativa para o seu celular, sem interromper a chamada.

E isso é tudo o que temos para ver em Mobile Connect. No próximo post falarei sobre Mobile Voice Access, ou DISA.