quinta-feira, 23 de agosto de 2012

SRST e High Availability

Acredito que SRST seja a sessão na prova onde a galera mais zera. Eu particularmente não conheço ninguém que tenha gabaritado High Availability, porque é um tema cheio de detalhes. Por exemplo, tudo que foi dado de requisito em Call Routing, tem que ser aplicado em HA também... então se lá no começo da prova eles falaram que as chamadas Locais tem que sair com Calling Number de 7 dígitos e type Subscriber, quando você chegar em HA e o enunciado pedir para que as chamadas locais funcionem em SRST, você tem que lembrar de como a PSTN está esperando receber a chamada. Às vezes você pode ter feito a marcação lá no Call Manager, e aí quando chega no SRST, mesmo que tenha já a dial-peer, e que a chamada esteja completando, você esqueceu de manipular o número de origem, e marcações de Plan e Type.
Outra coisa que é chata no SRST é manter o telefone da mesma forma como ele estava quando registrado no CUCM. Isto é, você não pode esquecer de mudar o time-format, date-format, time-zone, e até a mensagem "Your current options" no rodapé. E não é "Your current option" e nem "Your Current Options". É "Your current options"! Sim, detalhes desses são pegos no script de correção, e por uma besteira dessa você pode perder os pontos dessa sessão.

Bom, mas para esse post vou focar nos 4 tipos de SRST que existem. Esse é o básico de td nessa sessão... antes de pensar no Call Routing, você precisa ver qual dos 4 tipos de SRST você vai habilitar:

1. call-manager-fallback
O call-manager-fallback é o que não habilita o CME, não cria ephones e ephone-dns no show run, e por isso, é muito mais limitado com relação às features. Porém, é o único que não da pau! hahaha... Se você ler a questão e ver que não vai precisar alterar ou criar ephones e ephone-dns (ou seja, nada de pickup, alteração de nome de ramal, templates, paging, barge, conference bridges, transcoders, ephone-hunts, etc.), não pense duas vezes. Use o call-manager-fallback, que é muito mais simples, rápido de configurar e estável. Mas ele vai apenas registrar os telefones, receber e efetuar chamadas, fazer desvios para o voice mail e só.
Para a configuração, os únicos parâmetros necessários são ip source-address, max-dn e max-pool. Mas eu recomendo fortemente adicionar os outros também, mesmo que o enunciado não peça...

call-manager-fallback
 ip source-address X.X.X.X
 max-dn X [dual-line] [no-reg]  !-- use o no-reg se tiver Gatekeeper
 max-ephones X
 time-zone YY
 time-format {12 / 24}
 date-format {dd-mm-yy / mm-dd-yy / yy-dd-mm / yy-mm-dd}
 voicemail {Voicemail Pilot}
 call-forward busy {Voicemail Pilot}
 call-forward noan {Voicemail Pilot} timeout X
 transfer-pattern .T
 secondary-dialtone 9
 system message primary Your current options
 moh music-on-hold.au

Obs: No caso de usar call-manager-fallback, não é possível criar ephone-hunts. Porém, é possível criar voice hunt-group. O B-ACD funciona quase perfeitamente com voice hunt-groups. A única desvantagem é que os usuários não conseguirão ver na tela a quantidade de chamadas em fila.

2. CME-SRST com auto-provision none
Resumo: não use, a não ser que o enunciado peça claramente.
Simples assim... ele não leva vantagem nenhuma quase sobre o call-manager-fallback. Ok, você consegue aplicar uns templates para ephones e dns, criar ephones e ephone-dns manualmente, criar ephone-hunts... mas se for usar o auto-provision, utilize logo um dos métodos abaixo. Mas novamente, se o enunciado pedir por exemplo para você não ter nada de ephone/ephone-dn criado automaticamente no show run, mas mesmo assim pedir alguma feature que exija o uso do CME (por exemplo, para criar um ephone-hunt), aí não tem jeito...
Para a configuração:

telephony-service
 srst mode auto-provision none
 srst ephone template X
 srst dn template 1
 srst dn line-mode {dual / single / octo}
 ip source-address X.X.X.X
 max-dn X [preference 9] [no-reg]
 max-ephones X
 time-zone YY
 time-format {12 / 24}
 date-format {dd-mm-yy / mm-dd-yy / yy-dd-mm / yy-mm-dd}
 voicemail {Voicemail Pilot}
 call-forward pattern .T
 transfer-pattern .T
 secondary-dialtone 9
 system message Your current options
 moh music-on-hold.au

ephone-dn-template 1
 call-forward busy {Voicemail Pilot}
 call-forward noan {Voicemail Pilot} timeout X

Para configurar os call-forwards para o voice mail, você deve fazer dentro de um ephone-dn-template. Caso esteja utilizando o CUE como voice mail desse site, eu recomendo adicionar ao template a linha mwi sip, e configurar o modo Solicited Notify:
sip-ua
 mwi-server ipv4:<CUE-IP-Address> ! -- Sem a keyword unsolicited

Dessa forma, se o telefone já estiver com o MWI aceso quando entrar em SRST, ele continuará aceso em contingência. Se você utilizar o modo Unsolicited, terá que dar um refresh nos MWI na CUE.


3. CME-SRST com auto-provision dn
Com esse modo, quando o telefone entrar em SRST, ele copiará os ramais na configuração, e com isso você poderá ver os ephone-dns criados automaticamente no show run. Isso vai permitir que você configure os DNs individualmente, alterando o nome, label, call-forward, etc.
A configuração é igual a de cima, exceto por essas linhas:

telephony-service
 srst mode auto-provision dn

Obs: Quando os ephone-dns forem criados, ele ficará lá para sempre. Ou seja, se o telefone voltar a se registrar no CUCM, o ephone-dn vai continuar lá no show run. Isso quer dizer que mesmo que o telefone não esteja em SRST, a dial-peer dele estará lá, e ativa. Então, em caso de gateways H323, as chamadas entrantes vão falhar caso o telefone volte a se registrar no CUCM, porque o router vai tentar mandar a chamada para a dial-peer do ephone-dn, que tem um match mais específico. Recomendo que configure os ephone-dn com preference 9 (maior que as suas dial-peers para o CUCM), e mude a forma como o router escolhe as dial-peers com o comando dial-peer hunt 2 (que faz a escolha por preferência, e não por longest match).

4. CME-SRST com auto-provision all
Por fim, o auto-provision all. Como é de se imaginar, com o auto-provision all, tudo é criado no seu show run: ephone e ephone-dns, te dando um completo controle dos ramais registrados em SRST. Com esse modo, o seu SRST vira um CME completo, com todos os telefones estaticamente configurados no roteador. Claro que se você mudar algo no CUCM, ele não vai replicar para o SRST, e aí você terá que alterar na mão. Extremamente desaconselhavel para a vida real, e altamente aconselhavel para o Lab.

telephony-service
 srst mode auto-provision all

quarta-feira, 15 de agosto de 2012

Line-Device Approach

Um conceito muito utilizado tanto no Lab quanto em campo é o Line-Device approach para desenho do Call Routing, especialmente para dial plans mais complexos e escaláveis. No caso do Lab eu particularmente não costumo usar muito, salvo algumas exceções, porque a minha estratégia para Call Routing é tentar deixá-lo o mais simples possível. Mas sei de gente que usa o Line-Device e prefere... aí é do gosto de cada um.

O Line-Device Approach não é exatamente uma feature, mas sim um modo de se implantar o Call Routing do CUCM. O conceito é que a CSS de um DN associado a um Device é o resultado da concatenação da CSS da linha com a CSS do Device. Por exemplo, digamos que na Linha você configure a CSS-Line, que tem acesso às Partitions PT_A, PT_B e PT_C. E no Device você configura a CSS-Device, que tem acesso às Partitions PT_1, PT_2 e PT_3. Dessa forma, a CSS dessa linha associada a esse device conterá as partitions PT_A, PT_B, PT_C, PT_1, PT_2 e PT_3, nessa ordem. Esse é o comportamento do CUCM. Não precisa mudar nenhum Service Parameter e nem nada para isso funcionar.

Agora, qual a vantagem de se ter isso? Num é mais fácil usar só a CSS da Linha, como costumamos fazer normalmente? Sim, é mais fácil... para ambientes pequenos, poucos sites, realmente é muito mais simples usar apenas a CSS da Line. Porém, quando o seu sistema vai crescendo, e você tem centenas, milhares de escritórios remotos, o conceito do Line-Device começa a fazer mais sentido.

A ideia é que a CSS da Line faça o controle de Classes de Restrição, enquanto a CSS do Device faz o controle do Call Routing (path selection). Então é a CSS do Device que vai ter acesso às Route Patterns, enquanto a CSS da Line vai ter acesso a Translation Patterns do tipo "Block".

Meio confuso, né? Vamos fazer um exemplo para ilustrar melhor.

Digamos que a gente tenha um site apenas, chamado HQ.
Vamos criar as Route Patterns dele e colocar tudo na partition PT-HQ-PSTN. Elas vão apontar para a route list local, que aponta para o Gateway local:
9.[2-9]XXXXXXX (PT-HQ-PSTN)      |
9.0XX[2-9]XXXXXXX (PT-HQ-PSTN)   |--> RL-HQ --> RG-HQ --> HQ GW
9.00! (PT-HQ-PSTN)               |
9.19X (PT-HQ-PSTN)               |

Agora vamos criar uma CSS para os Phones terem acesso a essas rotas:
CSS-HQ-Phones <PT-Ramais, PT-HQ-PSTN>
Essa CSS será configurada nos Devices do site HQ. Assim, todos eles terão acessos aos ramais e a todas as rotas para a PSTN.

Para a classe de restrição, vamos criar as seguintes CSSs:
CSS-Internal <PT-Block-Local, PT-Block-DDD, PT-Block-DDI> 
CSS-Local <PT-Block-DDD, PT-Block-DDI>
CSS-DDD <PT-Block-DDI>
CSS-DDI <None>

E aí criaremos as seguintes translation patterns:
9.[2-9]XXXXXXX (PT-Block-Local)    |
9.0XX[2-9]XXXXXXX (PT-Block-DDD)   |--> Block this Pattern
9.00! (PT-Block-DDI)               |
Todas essas translations serão configuradas com a opção Block This Pattern, ao invés do Default Route This Pattern.

E aplicamos as Calling Search Spaces CSS-Internal, CSS-Local, CSS-DDD e CSS-DDI nos ramais (na Line) que desejamos bloquear para as chamadas externas.
Assim, digamos que temos um ramal 2001 associado a um telefone. Na Line, colocamos a CSS-DDD, enquanto no Device colocamos a CSS-HQ-Phones. A CSS resultante desse ramal associado a esse device será: PT-Block-DDI, PT-Ramais, PT-HQ-PSTN (nessa ordem). Veja que a PT-Block-DDI tem preferência sobre as demais, por estar acima na lista. Então quando esse ramal tentar fazer um DDI (900!), ele vai dar match primeiro na Translation Pattern de Block, e não completará a chamada. Agora, se esse ramal tentar ligar para um número local, como ele não tem acesso a translation pattern de bloquear chamadas locais, a ligação vai completar.

Continuando o exemplo, digamos que colocamos mais um site no sistema, chamado de BR1. Veja que o esforço de configuração para esse site é bem menor. Ao invés de termos que criar várias novas partitions e calling search spaces, criamos apenas uma de cada:
CSS-BR1-Phones <PT-Ramais, PT-BR1-PSTN>

 E depois as rotas:
9.[2-9]XXXXXXX (PT-BR1-PSTN)      |
9.0XX[2-9]XXXXXXX (PT-BR1-PSTN)   |--> RL-BR1 --> RG-BR1 --> BR1 GW
9.00! (PT-BR1-PSTN)               |
9.19X (PT-BR1-PSTN)               |
 
Em todos os devices de BR1 configuramos a CSS-BR1-Phones, e nas Lines utilizamos aquelas mesmas configuradas para o HQ. Pois elas definem apenas classes de restrição, e são genéricas.
Veja como o sistema fica muito mais escalável... para cada site novo no sistema, você precisaria criar apenas 1 partition, 1 calling search space e as rotas.

Para quem nunca usou isso, ou nunca ouviu falar, eu recomendo estudar e testar (o SRND é uma ótima fonte). Se não for usar na prova, certamente será útil em campo um dia. Já no lab é difícil dizer... o foco dele não é escalabilidade, são apenas 3 sites... eu não acho muita vantagem. Depois você tem uma zica no Call Routing, e pra fazer o troubleshooting é muito mais coisa para ver... mas aí vai de cada um.


Obs: Para Call Forward All, também é possível usar esse método de Line-Device Approach usando o Activation Policy "With configured CSS". O Forward All CSS será equivalente ao Line, e o Secondary CSS será equivalente ao Device.

segunda-feira, 13 de agosto de 2012

IPMA Proxy Mode

IPMA (IP Manager Assistant), ou chefe-secretária, é uma feature que permite o melhor controle das linhas do chefe pela sua secretária. Na real, eu acho uma porcaria. Acho que o software não é amigável, é chato de configurar, e no final ninguém usa. Dá um trabalhão, e as secretárias só reclamam... hehehe! Aboli definitivamente das minhas implantações em campo. Mas de qualquer forma, é um tópico que faz parte do Blueprint, e devemos saber fazer caso seja cobrado.

Eu tenho um passo-a-passo bem simples que fiz há um tempo, e não toma nem 15 minutos para configurar. Como ultimamente estou mais focado em fazer labs, aprimorar a minha agilidade e estratégias, não estou gerando muito conteúdo novo para postar. Dessa forma, postarei anotações mais antigas que tenho aqui.

A minha dica para o IPMA é NÃO usar o assistente de configuração. Ele vai zoar todo o seu dial plan, criar CSSs e PTs inúteis, e no final não vai funcionar! hahaha... Se você nem sabia que tinha um Wizard, sorte a sua, nem precisa perder o seu tempo pesquisando. Seguindo esse passo-a-passo é muito mais simples e garantido:

1. Partitions
Você precisa ter 2 Partitions. Uma para os ramais dos chefes, e uma para os ramais comuns (que provavelmente já foi criada antes). Caso você esteja usando a partition <None> para os ramais comuns, tudo bem. Nesse caso, seria apenas uma para os chefes, e a <None> para a galera. Para o exemplo, vou criar duas:
PT-Manager
PT-Ramais

2. Calling Search Spaces
Você precisa ter apenas uma CSS especial, que terá acesso a Partition dos chefes. De resto, você vai ter as CSSs normais de chamadas Locais, DDD, DDI, etc. Então vou criar:
CSS-IPMA-Manager {PT-Manager, PT-Ramais}

3. Phones
Teremos 3 tipos de usuários: Os chefes, as secretárias e a galera. No exemplo, vamos considerar que o range de ramal DDR da empresa é 3XXX, e o range de ramais virtuais dos chefes é 1XXX (não DDR).

Phone do Chefe
Ramal: 1000 (PT-Manager), CSS: Qualquer uma, sem acesso a PT-Manager.
Intercom: *1000 >>> *3000
Softkey: Standard Manager

Phone da Secretária
Ramal Principal: 3000 (PT-Ramais), CSS: Qualquer uma, sem acesso a PT-Manager.
Ramal Proxy: 2000 (PT-Ramais), CSS: CSS-IPMA-Manager
Intercom: *3000 >>> *1000
Softkey: Standard Assistant

Phone da Galera
Ramal: 3001 (PT-Ramais). CSS: Qualquer uma, sem acesso a PT-Manager.

4. CTI Route Point
Quando as pessoas tentarem ligar para o chefe, elas não terão acesso direto ao ramal dele, já que está em uma partition PT-Manager que ninguém tem acesso. Então cairão nesse CTI Route Point que vamos criar agora:
Ramal: 1XXX (PT-Ramais), CSS: CSS-IPMA-Manager

5. Phone Services
Crie o phone service:
http://<CUCM-IP>:8080/ma/servlet/MAService?cmd=doPhoneService&Name=#DEVICENAME#.
Para pegar essa URL, você pode ir no Help e procurar por DEVICENAME. Entre em Cisco Unified IP Phone Service Configuration.
Associe o serviço ao telefone do Chefe.

6. Service Parameters
Entre nos Service Parameters do "Cisco IP Manager Assistant" e mude os 4 campos abaixo:
- CTI Manager IP Address
- Route Point Device Name
- Cisco IPMA Server IP Address
- Service Name

7. Configuração dos End users
Crie um end user para o chefe e um para a secretária. Configure primeiro o Chefe.
- Associe o Device
- Em Related Links, vá em Manager Configuration
- Desmarque o Automatic Configuration
- Se for um usuário de EM, selecione Mobile Manager
- Selecione o Device/Profile, que foi associado na tela inicial do End User
- Selecione o ramal de Intercom
- Selecione a secretária
- Selecione o ramal

Agora configure a Secretária:
- Associe o Device
- Em Related Links, vá em Assistant Configuration
- Desmarque o Automatic Configuration
- Selecione o Device
- Selecione o ramal de Intercom
- Selecione o ramal principal dela (não o Proxy!)
- Selecione o chefe
- Em Manager Association, selecione a linha Proxy dela, e o nome/ramal do chefe

8. Restart dos serviços
Reinicie os serviços CTI Manager, IPMA Service e Tomcat (via CLI - utils service restart Cisco Tomcat). Você deve ver o CTI Route Point Registrado, e o telefone do chefe vai aparecer com uma aplicação na tela inicial. Instale o client da Secretária. É por ele que ela vai controlar a linha do chefe.

9. Melhores práticas
- CTI Route Point deve ter um Forward Unregistered para XXXX, na CSS-IPMA-Manager. Assim, se houver uma falha no serviço e o CTI Route Point estiver fora, a chamada vai ser desviada direto para o ramal do chefe
- MWI CSS deve ter acesso direto ao ramal do chefe

sábado, 4 de agosto de 2012

Phone View e Voice View Express

O PhoneView do Unity Connection e o Voice View Express do Unity Express tem o propósito de exibir os voice mails de forma gráfica na tela do telefone. Porém, essas duas features funcionam de maneira bastante diferente.
A grande diferença é que o VoiceView Express é um Phone Service (acessado pelo botão Services do telefone), enquanto o Phone View é acessado através da tecla de mensagens, após acessar a Unity Connection.

O setup do Phone View Express é muito simples. Para o CME, ele já vem ativo por default, então nem precisa fazer nada. Para o CUCM, basta adicionar um Phone Service e fazer o Subscribe do serviço nos telefones. Você pode pegar a URL (http://<cue-ip-address>/voiceview/common/login.do)  na própria GUI do CUE, na telinha onde se habilita a aplicação.
Detalhe que dependendo do seu setup da CUE (CUCM ou CME), essa URL muda. Mas você pode usar só uma ou outra. Em outras palavras, o Phone View Express não é suportado em SRST.

Nesse post vou falar mais sobre o PhoneView. Por incrível que pareça, o mais difícil dessa aplicação não é configurá-la, mas sim descobrir como faz para acessá-la. É aí que um monte de gente fica em dúvida... No CUC 8.6, se não me engano, o Phone View está infinitamente melhor... ele funciona com uma aplicação Java no telefone e tal. Mas enfim, para essa versão da prova, eles vão cobrar o PhoneView véio mesmo...

Para configurar é muito fácil:

1. Crie um Application User no CUCM, e associe os Devices. Coloque o usuário no grupo Standard CTI Enabled.

2. No CUC, habilite o Phone View dentro do Phone System. Coloque lá as credenciais configuradas no passo anterior.

3. Habilite o Phone View para o usuário no CUC, indo em Edit >> Phone Menu. Em Finding Messages with Message Locator, clique em Enable, e embaixo Enable Phone View.

E pronto! hahaha... mas aí você aperta o botão de Messages, entra o seu PIN e não mudou nada... a mulher continua falando quantas mensagens você tem, pressione 1 para ouvir e bla bla bla.
É aí que entra a parte mais obscura do negócio. Como acessa o Phone View? Por padrão, você vai conseguir acessá-lo através da opção 5, "Find New Messages", e depois opção 4 para listar todas as mensagens novas. A tela abaixo será apresentada (imagem "roubada" do blog da IP Expert):