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

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.

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

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):

Cisco Unified Presence Server e Personal Communicator

Recentemente fiquei surpreso porque, na mesma semana, 3 pessoas me vieram falando que conheciam o blog, e que haviam encontrado no Google! Puxa, melhor eu começar tomar cuidado com o que escrevo por aqui! hahaha
Bom, depois de uma longa pausa nos posts (por uma boa causa, pois estava estudando), vou escrever hoje sobre o CUPS e CUPC, que é um assunto que eu já estava devendo há muito tempo.

Basicamente o que pode ser testado sobre CUPS e CUPC na prova é integração, IPPM, Deskphone ou Softphone mode, Presence e integração com CUC para visualização dos Voice Mails. São coisas extremamente simples de fazer! Ou seja, pontos garantidos na prova. Só que são muitos detalhes para configurar, então você tem que bolar uma estratégia sua de configuração para que não se esqueça de nada. Particularmente, o meu approach é configurar tudo no CUCM e depois configurar tudo no CUPS, seguindo a sequencia dos menus. Aqui eu vou mostrar tudo o que precisa ser feito nos dois servidores dividido por funcionalidade... A ordem de configuração, cada um define a sua.

1. Integração inicial
Na vida real, quando você incia o CUPS pela primeira vez, ele roda um Wizard para você preencher as informações básicas como Hostname e IP do CUCM, usuário AXL, Security Password... Eu acredito que isso já venha pronto na prova. Mas caso não venha, não tem segredo nenhum... você só vai perder uns minutinhos a mais.
Depois desse Wizard, quando você se logar no CUPS ele já vai entrar na tela inicial... bem parecida com o CUCM, só que ao invés da foto de um Datacenter do lado direito, tem a foto dum Japa mexendo no notebook apoiado em cima de um 6500! hahaha, sempre me pergunto de onde a Cisco tira essas ideias brilhantes...

1.1. Mudar o Hostname para IP
A primeira coisa que você precisa fazer no CUPS é mudar para IP o Hostname dele. Se você não fizer isso, os clients precisarão saber resolver o nome do CUPS. Isso pode ser feito via DNS (que não tem na prova), ou editando o arquivo Hosts (que não sei se é permitido). Então é melhor tirarmos essa dependência com o Hostname. Para isso, faça:
System >> Topology >> Clique em Edit e mude o Hostname para IP.

1.2. Iniciar os serviços do CUPS
Depois (DEPOIS!!!) de mudar o Hostname, vá em Serviceability e ative todos os serviços. Se você ativar antes de mudar o Hostname, vai ter que reiniciar o servidor, e perderá minutos preciosos na prova.

1.3. Verificar a integração
Verifique se a integração está ok em System >> CUCM Publisher. Pode ser que tenha algo errado ali e você precise arrumar.

1.4. Criar ACLs
Crie uma incoming ACL e uma outgoing ACL (System >> Security). O address pattern deve ser ALL (tudo maiúsculo).

1.5. Proxy Domain Service Parameter
Vá em System >> Service Parameters no CUPS, selecione o serviço Cisco UP SIP Proxy e mude o Proxy Domain para alguma coisa diferente de PROXY_DOMAIN_NOT_SET. Pode ser cisco.com.

1.6. Criar End Users no CUCM
Crie novos End Users para a utilização do CUP. Eles devem estar com o campo Primary Extension preenchido, e com o grupo Standard CTI Enabled. Já deixe eles associados ao Deskphone, pois precisaremos disso quando formos fazer o Deskphone Control.

1.7.  Capabilities Assignment
É preciso habilitar o CUP (e o CUPC se necessário) para os usuários que farão parte da solução. Vá em System >> Licensing >> Capabilities Assignment no CUCM e habilite os usuários com CUP e CUPC.


2. IPPM (IP Phone Messenger)
Para habilitar o Phone Messenger nos telefones, os seguintes passos são necessários:

2.1. Phone Service
Adicione o serviço no CUCM, em Device >> Device Settings >> Phone Services. A URL pode ser encontrada no SRND do CUCM (procure por PhoneMessenger1):
http://<IP-CUPS>:8081/ippm/default?name=#DEVICENAME#
E faça o subscribe desse serviço no IP Phone desejado.

2.2. Application User
Crie um Application User chamado PhoneMessenger. Ele deve estar associado ao Device que terá o serviço de IPPM, e deve estar no grupo Standard CTI Enabled.

2.3. Authentication URL
Vá em System >> Enterprise Parameters e verifique se o Authentication URL está correto. Caso esteja o hostname do Publisher, troque para o IP.

2.4. Habilitar o IP Phone Messenger
Agora no CUPS, vá em Application >> IP Phone Messenger >> Settings. Mude o status para On, e preencha os campos de usuário e senha com as informações do Application User criado no passo 2.2


3. Presence
Para que o CUPC possa ver o status de presença dos telefones, faça o seguinte:

3.1. Line Association
Entre nas configurações dos Telefones que farão parte da solução, e depois entre na tela do DN. Lá embaixo, associe esse DN com o End User.

3.2. SIP Trunk Security Profile
Crie um SIP Trunk Security Profile (System >> Security Profile >> SIP Trunk Security Profile) com os 4 Accepts marcados. Utilize o Non Secure SIP Trunk Profile como base.

3.3. SIP Trunk
Crie um SIP Trunk no CUCM apontando para o CUPS, utilizando o Security Profile criado acima.

3.4. SIP Publish Trunk
No CUPS, vá em Presence >> Settings, habilite a opção Enable SIP Publish on CUCM e selecione o SIP Trunk criado acima. Uma outra forma de fazer isso é através do Service Parameter CUP PUBLISH Trunk no CUCM. Se mudar esse service parameter, ele já aplica a alteração no CUPS também.

3.5. Presence Gateway
No CUPS, vá em Presence >> Gateways, e adicione um novo. Coloque o IP do CUCM Publisher.


4. Deskphone Control
Para habilitar o Deskphone Mode no CUPC, os seguintes passos são necessários:

4.1. Application User
Crie um Application User chamado CtiGw. Ele deve estar associado ao Device que será controlado, e deve estar no grupo Standard CTI Enabled.

4.2. End User
No End User criado para o CUPC, associe o telefone de mesa, caso já não tenha feito no passo 1.6.

4.3. Habilitar o Deskphone Control no CUPS
No CUPS, vá em Application >> Deskphone Control >> Settings. Mude o status para On, e preencha os campos de usuário e senha com as informações do Application User criado no passo 4.1. Coloque também os IPs dos CUCMs.

4.4. User Assignment
No CUPS, vá agora em Application >> Deskphone Control >> User Assignment e habilite o usuário desejado.

4.5. CTI GW Profile
No CUPS, vá em Applications >> Cisco Unified Personal Communicator >> User Settings. Selecione o usuário desejado, e configure um CTI Gateway Profile. Esses Profiles são criados automaticamente quando você inicia os serviços do CUPS. Selecione o profile de nome <device_pool>_cti_tcp_profile_synced_000.


5. Softphone Mode
Para que o CUPC possa também funcionar como um softphone, execute os seguintes passos:

5.1. Criar um device no CUCM
No CUCM, crie um novo device do tipo Cisco Unified Personal Communicator. O Device Name deve ser no formato UPCXXXXXXXX, onde XXXXXXXX é o User ID. Utilize letras maiúsculas e até 12 caracteres. Se o User ID for maior que 12 caracteres, por exemplo BRUNONONOGAKI, deixe ele cortado: BRUNONONOGAK
Obs: Para a versão 8, o device type muda para Client Service Framework, e o Device Name deve ser no formato CSFXXXXXXXX.

5.2. Configurar o TFTP no CUPS
No CUPS, vá em Application >> Cisco Unified Personal Communicator >> Settings, e configure como TFTP Server os CUCMs.


6. Voice Mail
Para o usuário conseguir ver os seus Voice Mails no CUPC, faça o seguinte:

6.1. Habilitar o IMAP no CUC
No Unity Connection, vá em Class of Service >> Voice Mail User COS e habilite as opções Allow Users to Access Voice Mail Using an IMAP Client e Allow Users to Use the Cisco Unity Inbox.
Depois, entre nas configurações do usuário, e altere o Web Application Password.


6.2. Voice Mail Server no CUPS
No CUPS, vá em Application >> Cisco Unified Personal Communicator >> Voice Mail Server e crie um novo do tipo Unity Connection. Coloque o IP do servidor e mantenha as portas defaults.


6.3. Voice Mail Profile no CUPS
No CUPS, vá em Application >> Cisco Unified Personal Communicator >> Voice Mail Profile e adicione um novo. Configure um Voice Messaging Pilot (que ele vai puxar do CUCM) e um Primary Voicemail Server (que criamos no passo 6.2)

6.4. Configuração do CUPC
Agora no client, vá em Arquivo >> Preferências, e configure a sua conta de Voice Mail colocando as credenciais que configuramos no CUC.



Parece que é um monte de coisa para fazer, mas utilizando uma boa estratégia e praticando um pouco, verá que é bem simples e rápido. Você não vai perder mais do que 15 minutos fazendo tudo isso.

Um detalhe importante. Na prova não tem AD, até onde eu sei. Sem integração com o AD, não é possível procurar usuários no CUPC! Então existem duas formas de você adicionar um contato no client... uma é entrando na página de usuário do CUPS (https://<CUPS-IP>/ccmuser), e a outra é fazendo com que um outro usuário mande uma mensagem para o CUPC através do IPPM. Quando você receber a mensagem no CUPC, poderá adicioná-lo como contato.

Unity Connection - Integração com o CME (SCCP)

Finalmente hoje consegui um tempo para estudar e fazer uma nova postagem aqui no Blog. Muito trabalho ultimamente, e não tem sobrado muito tempo para os estudos... =(
Bom, para finalizar o assunto de integrações entre CUCM/CME e CUC/CUE, vou falar da última que estava faltando, que é a entre CME e CUC usando SCCP. É bastante incomum no dia-a-dia, mas é possível de ser testada na prova. Felizmente, essa integração também é bem fácil de se fazer.

Primeiramente vamos configurar o CME. Basicamente aqui precisaremos criar as nossas VM Ports, igual fazemos no CUCM quando rodamos aquele Wizard. No caso do CME não tem Wizard, então vai ter que ser tudo na mão. Para simplificar, vou criar apenas 2 portas:

ephone-dn  10
 number 5600 no-reg primary

 description CUC1-VI1
 name CUCM Pilot

ephone-dn  11
 number 5600 no-reg primary

 description CUC1-VI2
 name CUCM Pilot

ephone  10
 device-security-mode none
 vm-device-id CUC1-VI1
 button  1:10

ephone  11

 device-security-mode none
 vm-device-id CUC1-VI2
 button  1:11

E agora vou criar os ramais de MWI:

ephone-dn 15

 number 5601 secondary 5602 no-reg both

 mwi on-off

Assim, o 5601 será o MWI On e o 5602 o MWI Off.

E depois configuro o VM Pilot apontando para o piloto 5600

telephony-services

 voicemail 5600

Agora na Unity Connection, é só configurar a integração da mesma forma como é feita no CUCM:
1. Crie um novo Phone System
2. Associe a um Port Group. Nele configure o MWI (5601 on e 5602 off no nosso caso), e em Edit >> Servers, coloque o IP do CME. Como device prefix, coloque CUC1-VI, ou o que você configurou no CME.
3. Associe as Portas ao Port Group, especificando a quantidade de portas de acordo com a quantidade de ephones que você criou no CME.

Feito isso, você vai ver os seus devices registrados no CME:

ephone-10 Device:CUC1-VI1 TCP socket:[1] activeLine:0 REGISTERED in SCCP ver 17 and Server in ver 8
mediaActive:0 offhook:0 ringing:0 reset:0 reset_sent:0 paging 0 debug:0 caps:0
IP:10.10.210.13 40803 Unity Voice Port  keepalive 3 max_line 1
button 1: dn 10 number 5600 CH1   IDLE

ephone-11 Device:CUC1-VI2 TCP socket:[2] activeLine:0 REGISTERED in SCCP ver 17 and Server in ver 8
mediaActive:0 offhook:0 ringing:0 reset:0 reset_sent:0 paging 0 debug:0 caps:0
IP:10.10.210.13 40804 Unity Voice Port  keepalive 3 max_line 1
button 1: dn 11 number 5600 CH1   IDLE


E pronto, tudo integrado! =)

To: Called Number (Gateways H323)

Um post bem específico hoje. Quando o usuário faz uma chamada para a PSTN roteando via um gateway H.323, o telefone originador pode exibir o número discado de diversas formas uma vez que a chamada é completada.
Por exemplo, digamos que eu tenha um ramal em Boston e faça uma chamada para NY via TEHO. O usuário em Boston discará 9 1 212 394-1111, e a chamada sairá como uma chamada local pelo gateway de NY, enviando para a PSTN os dígitos 3941111.
Quando o usuário faz essa chamada, o phone dele pode exibir o número discado de várias formas, por exemplo:

To: 912123941111

To: 3941111

To: 12123941111

To: *9988776655#3941111 

To: 911
Ou qualquer outro jeito que você quiser!

A regra é sempre fazer a manipulação necessária para o roteamento da chamada dentro da Route List, e usar a Route Pattern para alterar a forma de exibição do número discado no telefone. Mas antes deveremos desabilitar um supplementary-service no gateway (veremos a seguir).
Então por exemplo, eu vou criar no gateway a dial-peer:

dial-peer voice 3 pots
 destination-pattern 9T
 port 0/0/0:23

E no Call Manager a route pattern 91212.394XXXX. Agora vamos às nossas situações:

1. Por padrão, tanto faz se você configurar a regra de Discard-Digits na Route Pattern ou na Route List. O gateway sempre vai atualizar o CID de acordo com a dial-peer. Então no telefone do usuário vai aparecer To: 93941111.

2. Se no gateway eu criar uma voice translation-rule e aplicar na dial-peer, a regra refleirá no CID exibido no telefone. Por exemplo, se eu criar uma regra para tirar o 9:

voice translation-rule 1
 rule 1 /^9\(.*\)/ /\1/

!
voice translation-profile Strip9
 translate called 1

!

dial-peer voice 3 pots
 translation-profile outgoing Strip9
 destination-pattern 9T
 port 0/0/0:23

O número exibido no telefone será: To: 3941111.
Isso porque novamente o gateway está atualizando o número de acordo a dial-peer. Para desativar esse comportamento, faça:

voice service voip

 no supplementary-service h225-notify cid-update

Por isso que no Brasil, quando criamos uma dial-peer de DDD incluindo a operadora (15, 21, 23, ...) via translation, o telefone atualiza o número discado incluindo o número da operadora que foi modificado no gateway. Desativando esse serviço, o gateway não mais atualizará o CID.

3. Agora sim, com o cid-update desabilitado, se eu configurar na Route List um Discard-Digits Pre-Dot, Prefix 9. E na Route Pattern não configurar nada, o telefone não vai alterar a forma como o número é exibido, e mostrará To: 91213941111 (da mesma forma que o usuário discou)

4. Se eu configurar na Route Pattern um Discard-Digits Pre-Dot, Prefix 9. E na Route List não configurar nada, o telefone vai alterar a forma como o número é exibido (de acordo com a regra da Route Pattern), e mostrará: To: 93941111

5. E finalmete, se eu configurar na Route List um DDI Pre-Dot, Prefix 9. E na Route Pattern configurar um DDI Pre-Dot, Prefix *9988776655# o CM vai enviar para o gateway o número de acordo com as regras na Route List (93941111), porém o telefone vai exibir o número formatado de acordo com a regra da Route Pattern, ou seja, To: *9988776655#3941111.

Então se cair na prova alguma questão pedindo para mudar a forma como o número é apresentado, sugiro desativar o cid-update do gateway, e fazer todas as regras utilizando a RL para a formatação do número a ser entregue para o gateway, e a RP para a formatação do número que será exibido no telefone.