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.
domingo, 10 de junho de 2012
quarta-feira, 6 de junho de 2012
Unity Connection - Integração com o CME (SIP)
Seguindo a série de postagens sobre a integração dos sistemas de Voice Mail, agora vou falar sobre uma não muito comum no dia a dia: Call Manager Express com Unity Connection via SIP.
Primeiramente, vamos configurar a Unity Connection de uma forma bem parecida com a que fazemos para integrá-la ao CUCM via SIP:
1. Criar um novo Phone System chamado, por exemplo, CUCME
2. Adicionar um Port Group a esse Phone System, escolhendo como Port Group Template a opção SIP. Deixe a autenticação desabilitada, e em Contact Line Name, coloque o número do Piloto, por exemplo, 3600. Em IP Address, coloque o IP do CME
3. Em Edit >> Servers, preencher as informações do CME (IP e portas)
4. Adicionar as Portas, especificando a quantidade baseando no que você tem de licença
5. Crie um novo User Template utilizando esse Phone System. E crie os usuários baseando neste template.
Agora todo o resto do trabalho é no CME. Então primeiro vamos criar a dial-peer para o Voice Mail:
E para o MWI funcionar:
Agora um detalhe importante. Para que o Call Forward e Call Transfer funcionem, precisamos desabilitar do SIP Trunk as mensagens 302 "Moved Temporary" e REFER, que são habilitadas por default. Portanto, os seguintes comandos são necessários:
E caso você tenha registrado no CME telefones SIP utilizando a Unity Connection, tem mais uma coisa pra fazer para que o MWI funcione:
No caso de SIP Phones também, é preciso definir o dtmf como rtp-nte. Se usar o sip-notify (como é com a Unity Express), não funciona!
E é isso aí, bem facinho! :)
Primeiramente, vamos configurar a Unity Connection de uma forma bem parecida com a que fazemos para integrá-la ao CUCM via SIP:
1. Criar um novo Phone System chamado, por exemplo, CUCME
2. Adicionar um Port Group a esse Phone System, escolhendo como Port Group Template a opção SIP. Deixe a autenticação desabilitada, e em Contact Line Name, coloque o número do Piloto, por exemplo, 3600. Em IP Address, coloque o IP do CME
3. Em Edit >> Servers, preencher as informações do CME (IP e portas)
4. Adicionar as Portas, especificando a quantidade baseando no que você tem de licença
5. Crie um novo User Template utilizando esse Phone System. E crie os usuários baseando neste template.
Agora todo o resto do trabalho é no CME. Então primeiro vamos criar a dial-peer para o Voice Mail:
dial-peer voice 3600 voip
destination-pattern 3600
session protocol sipv2
session target ipv4:<IP da Unity Connection>
dtmf-relay rtp-nte
codec g711ulaw
E para o MWI funcionar:
sip-ua
mwi-server ipv4:<IP da Unity Connection> unsolicited
telephony-services
voicemail 3600 ! -- Define o Pilot do Voice Mail
mwi relay
Agora um detalhe importante. Para que o Call Forward e Call Transfer funcionem, precisamos desabilitar do SIP Trunk as mensagens 302 "Moved Temporary" e REFER, que são habilitadas por default. Portanto, os seguintes comandos são necessários:
voice service voip
no supplementary-service sip moved-temporary
no supplementary-service sip refer
E caso você tenha registrado no CME telefones SIP utilizando a Unity Connection, tem mais uma coisa pra fazer para que o MWI funcione:
voice register global
voicemail 3600 ! -- Define o Pilot do Voice Mail
mwi
voice register dn 1
mwi
E é isso aí, bem facinho! :)
terça-feira, 5 de junho de 2012
Unity Express - Integração com o CUCM
No post anterior eu falei sobre as integrações do CUCM com a Unity Connection (SCCP e SIP). Hoje eu vou abordar a integração entre a Unity Express (CUE) e o CUCM, que utiliza o protocolo JTAPI.
Primeiramente, precisamos configurar o módulo da CUE. Recomendo fazer isso no começo da prova, porque vai precisar dar vários reboots. E cada reboot na CUE demooooora... Então já no começo da prova, se você ver que tem CUE na parte de messaging, já seta o IP e inicializa o módulo:
Feito isso, entre na console do módulo (no modo enable):
service-module Service-Engine0/0 session
Obs: Para sair da console do módulo e voltar para o roteador, "Ctrl + Shift + 6" e depois "x". Se tiver sessão presa e você não estiver conseguindo se logar no módulo, service-module Service-Engine0/0 session clear
Logo que entrar, vai ver que ele estará inicializando... pode sentar e esperar (ou melhor, ir fazendo outras coisas do Lab). Quando ele terminar de subir, vai entrar num wizard, onde você vai definir o hostname, domínio, NTP, DNS, Time Zone, e usuário/senha de administrador.
Depois disso, dê o comando show software licenses e veja se na licença instalada, o Application mode é CCM. Se estiver como CME, você vai ter que instalar uma nova licença, que provavelmente estará disponível em um FTP:
software install clean ftp://x.x.x.x/cue-vm-license_12mbx_ccm_7.0.1.pkg username XXX password XXX
Outra coisa boa de se fazer antes de começar a mexer na CUE é:
offline
restore factory defaults
Isso vai apagar toda configuração que por acaso exista na CUE (por exemplo, resquicios do lab de um outro candidato). A CUE é muito chata, qualquer coisa é motivo para ela não funcionar... então esse procedimento é altamente recomendável! Vai te tomar um tempo, porque ela vai ter que reiniciar e tal, por isso é bom já ir fazendo no começo do lab... enquanto ela reinicia, você vai fazendo outras coisas.
Agora, antes de continuarmos na CUE, vamos configurar as coisas necessárias no CUCM. Basicamente precisaremos criar um CTI Route Point, CTI Ports e um Application User.
1. Criar 2 CTI Ports (ou a quantidade que o enunciado pedir). Cada CTI Port vai ter que ter um ramal associado.
2. Criar 1 CTI Route Point, que também terá um ramal associado. Esse ramal será o seu Voice Mail Pilot.
3. Criar um Voice Mail Pilot (Voice Mail >> Voice Mail Pilot) apontando para o número que você configurou no CTI RP
4. Criar um Voice Mail Profile apontando esse Voice Mail Pilot
5. Criar um application user no grupo Standard CTI Enabled, e associar as CTI Ports e CTI Route Points.
6. Criar End Users com Device ou Profile associados e Primary Extension preenchido. Serão os usuários que importaremos para a CUE mais pra frente
7. Alterar o Voice Mail Profile das lines e configurar o forward no answer e forward busy dos ramais para o voice mail.
Pronto, tudo certo no CUCM! Agora vamos voltar para a CUE. Acesse o IP dela a partir de um browser. O primeiro acesso você vai cair num outro Wizard, agora para configurar a integração. No wizard, você passará pelos passos:
1. Informações do CUCM (IP; usuário e senha do ccmadmin; usuário e senha do JTAPI, que é o application user que você criou agora a pouco)
2. Import Users. Escreva o login dos usuários que você criou anteriormente, e importe eles, já criando as respectivas caixas postais.
3. Salve a configuração e reinicie o módulo (denovo!)
Já está tudo pronto, exceto por um detalhe... a Unity Express só fala G.711. E se um telefone tentar falar com ela com G.729? Precisaremos de um transcoder para isso. No roteador onde está a CUE, configure um transcoder, e adicione ao MRGL dos CTI Ports e CTI Route Point.
Mais um detalhe... e se por exemplo a CUE estiver no site BR2, e a prova pedir para que ela continue funcionando quando o site entra em SRST (inclusive o MWI). Aí precisaremos de configurar mais umas coisas no roteador.
E na CUE, garanta que o MWI está configurado como Unsolicited Notify, que é a forma como o CUCM trabalha. O SIP Notify é só com o CME. Por isso que temos que configurar o mwi-server como unsolicited no sip-ua.
Primeiramente, precisamos configurar o módulo da CUE. Recomendo fazer isso no começo da prova, porque vai precisar dar vários reboots. E cada reboot na CUE demooooora... Então já no começo da prova, se você ver que tem CUE na parte de messaging, já seta o IP e inicializa o módulo:
interface Service-Engine 0/0
ip unnumbered interface vlanXXX
! -- interface da vlan de voz ou da subinterface da vlan de voz
service-module ip address 192.168.10.2 255.255.255.0
! -- IP do módulo
service-module ip default-gateway 192.168.10.1
! -- Default Gateway do módulo
no shut
ip route 192.168.10.2 255.255.255.255 Service-Engine0/0
! -- É preciso criar uma rota estática para o módulo com o IP configurado acima e máscara fechada
Feito isso, entre na console do módulo (no modo enable):
service-module Service-Engine0/0 session
Obs: Para sair da console do módulo e voltar para o roteador, "Ctrl + Shift + 6" e depois "x". Se tiver sessão presa e você não estiver conseguindo se logar no módulo, service-module Service-Engine0/0 session clear
Logo que entrar, vai ver que ele estará inicializando... pode sentar e esperar (ou melhor, ir fazendo outras coisas do Lab). Quando ele terminar de subir, vai entrar num wizard, onde você vai definir o hostname, domínio, NTP, DNS, Time Zone, e usuário/senha de administrador.
Depois disso, dê o comando show software licenses e veja se na licença instalada, o Application mode é CCM. Se estiver como CME, você vai ter que instalar uma nova licença, que provavelmente estará disponível em um FTP:
software install clean ftp://x.x.x.x/cue-vm-license_12mbx_ccm_7.0.1.pkg username XXX password XXX
Outra coisa boa de se fazer antes de começar a mexer na CUE é:
offline
restore factory defaults
Isso vai apagar toda configuração que por acaso exista na CUE (por exemplo, resquicios do lab de um outro candidato). A CUE é muito chata, qualquer coisa é motivo para ela não funcionar... então esse procedimento é altamente recomendável! Vai te tomar um tempo, porque ela vai ter que reiniciar e tal, por isso é bom já ir fazendo no começo do lab... enquanto ela reinicia, você vai fazendo outras coisas.
Agora, antes de continuarmos na CUE, vamos configurar as coisas necessárias no CUCM. Basicamente precisaremos criar um CTI Route Point, CTI Ports e um Application User.
1. Criar 2 CTI Ports (ou a quantidade que o enunciado pedir). Cada CTI Port vai ter que ter um ramal associado.
2. Criar 1 CTI Route Point, que também terá um ramal associado. Esse ramal será o seu Voice Mail Pilot.
3. Criar um Voice Mail Pilot (Voice Mail >> Voice Mail Pilot) apontando para o número que você configurou no CTI RP
4. Criar um Voice Mail Profile apontando esse Voice Mail Pilot
5. Criar um application user no grupo Standard CTI Enabled, e associar as CTI Ports e CTI Route Points.
6. Criar End Users com Device ou Profile associados e Primary Extension preenchido. Serão os usuários que importaremos para a CUE mais pra frente
7. Alterar o Voice Mail Profile das lines e configurar o forward no answer e forward busy dos ramais para o voice mail.
Pronto, tudo certo no CUCM! Agora vamos voltar para a CUE. Acesse o IP dela a partir de um browser. O primeiro acesso você vai cair num outro Wizard, agora para configurar a integração. No wizard, você passará pelos passos:
1. Informações do CUCM (IP; usuário e senha do ccmadmin; usuário e senha do JTAPI, que é o application user que você criou agora a pouco)
2. Import Users. Escreva o login dos usuários que você criou anteriormente, e importe eles, já criando as respectivas caixas postais.
3. Salve a configuração e reinicie o módulo (denovo!)
Já está tudo pronto, exceto por um detalhe... a Unity Express só fala G.711. E se um telefone tentar falar com ela com G.729? Precisaremos de um transcoder para isso. No roteador onde está a CUE, configure um transcoder, e adicione ao MRGL dos CTI Ports e CTI Route Point.
Mais um detalhe... e se por exemplo a CUE estiver no site BR2, e a prova pedir para que ela continue funcionando quando o site entra em SRST (inclusive o MWI). Aí precisaremos de configurar mais umas coisas no roteador.
dial-peer voice 3600 voip ! -- Dial peer para o Voice Mail
destination-pattern 3600
session protocol sipv2
session target ipv4:192.168.10.2 ! -- IP da CUE
dtmf-relay sip-notify
codec g711ulaw
call-manager-fallback ! -- Configuração do SRST
max-dn X
max-ephone X
ip source-address 192.168.10.1
voicemail 3600
call-forward busy 3600
call-forward noan 3600 timeout 12
mwi relay
sip-ua
mwi-server ipv4:192.168.10.2 unsolicited
E na CUE, garanta que o MWI está configurado como Unsolicited Notify, que é a forma como o CUCM trabalha. O SIP Notify é só com o CME. Por isso que temos que configurar o mwi-server como unsolicited no sip-ua.
domingo, 20 de maio de 2012
Unity Connection - Integrações com o CUCM
Na parte de Messaging da prova, o blueprint aborda dois produtos: Cisco Unity Connection e Cisco Unity Express. Com eles, existem 6 formas possíveis de integração a serem testadas:
1. Unity Connection + Call Manager usando SCCP
2. Unity Connection + Call Manager usando SIP
3. Unity Connection + Call Manager Express usando SCCP
4. Unity Connection + Call Manager Express usando SIP
5. Unity Express + Call Manager usando JTAPI
6. Unity Express + Call Manager Express usando SIP
Hoje eu vou falar sobre as duas primeiras, que envolvem o Unity Connection com Call Manager.
1. Unity Connection + Call Manager usando SCCP
Essa é a integração que a gente mais faz no dia-a-dia. É bem provável inclusive que ela já venha pronta na prova, e você só tenha que fazer um troubleshooting para descobrir o que tem de errado. De qualquer forma, é bom saber bem como se faz essa integração, porque pode te garantir uns pontinhos de graça na prova.
Vamos começar pela parte do Call Manager. Basicamente aqui a gente vai ter que criar as VM Ports e colocá-las num Line Group. Associamos o Line Group a uma Hunt List e a Hunt List a um Hunt Pilot. Depois criamos os MWI, o Voice Mail Pilot e o Voice Mail Profile! Parece que é um monte de coisa, mas dá para fazermos tudo em menos de 5 minutos.
1.1. Voice Mail Port Wizard
O Wizard (Voice Mail >> Cisco Voice Mail Port Wizard) é guia para a criação das VM Ports. Com ele, podemos criar todas as portas de uma vez e associá-las a um Line Group automaticamente. Os passos desse Wizard são:
a. Escolher se você quer criar uma nova integração, adionar portas a uma integração já existente ou deletar portas. No caso, vamos criar uma nova integração.
b. Escolher um nome para as portas. Esse nome tem que bater com o que você vai configurar depois na Unity Connection, então anote o que você colocar. Recomendo usar o default: CiscoUM1.
c. Informar o número de portas que será criado. Isso vai depender da sua licença, se for na vida real, ou do enunciado da questão, se for na prova. O número de portas define a quantidade de acessos simultâneos que a Unity Connection vai suportar.
d. Configurar a porta. As informações principais que você deve se atentar são: Device Pool, Calling Search Space, AAR CSS e Location.
e. Configurar os DNs. As informações principais que você deve se atentar são: Beginning Directory Number, Partition, Calling Search Space, AAR Group e External Phone Number Mask (em caso de cair AAR na prova, não esqueça de preencher isso aqui!). O Beginning DN vai definir qual será o seu range de ramal para as VM Ports, baseado na quantidade de portas que você definiu lá em cima... ele vai alocar os ramais sequencialmente a partir desse beginning directory number.
f. Configurar o Line Group. Aqui ele vai perguntar se você quer criar um novo line group, adicionar as portas a um line group já existente ou criar o line group manualmente depois. Vamos criar um novo Line Group.
g. Dar um nome para o Line Group. Qualquer nome...
h. Confirmar as informações que serão adicionadas. Se clicar em Next, ele já vai aplicar as alterações.
i. Resumo do que foi criado.
1.2. Line Group, Hunt List e Hunt Pilot
Agora que você já tem um Line Group criado com as suas VM Ports dentro, vamos associá-lo a uma Hunt List, que por sua vez será associada a um Hunt Pilot:
a. Call Routing >> Route/Hunt >> Hunt List: Crie uma nova Hunt List e associe o Line Group criado no Wizard. Marque a opção "For Voice Mail Usage".
b. Call Routing >> Route/Hunt >> Hunt Pilot: Crie um novo Hunt Pilot e associe o Hunt List criado acima. O Hunt Pilot será o número de acesso ao Voice Mail. Denovo, se você for ter que configurar AAR, não esqueça de colocar o AAR Group e External Phone Number Mask!
1.3. MWI, VM Pilot e VM Profile
O resto da integração, teremos que seguir manualmente, sem um Wizard. Mas é pouca coisa:
a. Voice Mail >> Message Waiting Numbers: Aqui definiremos o MWI, que é o alerta no telefone indicando que há uma nova mensagem no correio de voz. Será um ramal para On (ligar o alerta) e um ramal para Off (desligar o alerta) que a Unity Connection utilizará para acender e apagar a luzinha nos telefones.
Adicione os dois ramais e guarde esses números, pois precisaremos deles mais tarde. Atenção: O MWI também tem Partition e CSS. Os ramais devem ter acesso a ele, e ele deve ter acesso aos ramais. Se você tiver configuração de IPMA, a CSS do MWI deve ter acesso ao ramal do chefe!
b. Voice Mail >> Voice Mail Pilot: Colocamos aqui o VM Pilot (que tem que ser o mesmo número do Hunt Pilot criado acima). Basicamente, ele é um "Speed Dial" para o Hunt Pilot para quando você pressionar o botão Messages do telefone.
c. Voice Mail >> Voice Mail Profile: No Voice Mail Profile amarramos o Voice Mail Pilot e colocamos (ou não) uma máscara.
Digamos que você tenha 2 sites pendurados nesse cluster: Site A e Site B. O Site A usa um Unity Connection com o VM Pilot 5000 e o Site B usa um Unity Express com o VM Pilot 2000. Quando um telefone do Site A pressionar a tecla Messages, ele tem que ser mandado para o seu Voice Mail na Unity Connection, enquanto o usuário do Site B, quando pressionar o mesmo botão no seu telefone, tem que ser mandado para o seu Voice Mail na Unity Express. Para essa situação, teríamos que criar dois Profiles diferentes, um para cada site, e cada profile teria associado o VM Pilot correspondente.
Outra finalidade do VM Profile é a seguinte: Imagine que o seu ramal no CUCM é 5001. Mas por algum motivo, o seu ramal na Unity Connection teve que ser criado no formato 5511XXXX (tipo 55115001)... talvez por um problema de ramais duplicados, sei lá. Mas nesse caso, como o seu ramal no CUCM é diferente do seu ramal na Unity, teriamos que colocar uma máscara no Voice Mail Profile: 5511XXXX. Assim, quando você fosse acessar o Voice Mail, o CUCM enviaria para a Unity os digitos 55115001 e não 5001.
1.4. Ramais e Usuários
Só precisamos fazer mais duas coisas no CUCM:
a. Nos ramais que terão Voice Mail, marque o desvio para o Voice Mail nos casos de busy e no answer... e talvez no unregistered também, dependendo do que for pedido na prova.
b. Crie um End User para cada usuário, associe o Device (ou Device Profile em caso de Extension Mobility), e preencha o campo Primary Extension. Sem ele preenchido, a Unity não vai enxergar esse usuário na hora da importação.
1.5. Unity Connection: Phone System
Finalmente vamos para a Unity Connection:
a. Telephony Integration >> Phone System: Utilize o Phone System default já existente.
b. Vá em Edit >> Cisco Unified Communications Manager AXL Servers: Coloque os IPs dos CUCMs, e porta 443 (SSL). Cuidado para não deixar a porta 0, que é a default. Coloque o usuário e senha de admin do Call Manager (ou algum outro que tenha permissão de AXL).
c. Volte na tela inicial do seu Phone System, e clique em Add Port Group, em Related Links, no canto superior direito da tela.
1.6. Unity Connection: Port Group
a. Dê um nome para o seu Port Group (default: PhoneSystem-1)
b. Em Device Name Prefix, você vai colocar o mesmo que definiu lá em cima no Wizard. Mas atenção, o nome tem que ter um "-VI" na frente... maluquisses da Cisco. Então, como o nome que definimos foi CiscoUM1, o Device Name Prefix vai ser CiscoUM1-VI. Isso é clássico de cair na prova para resolver problema de integração...
c. Preencha os MWI Extensions de acordo com o que você configurou antes.
d. Coloque o IP do CUCM.
e. Volte na tela inicial do Port Group, e vá em Edit >> Servers. Preencha os dados do seu CUCM.
f. Volte na tela inicial do Port Group, e clique em Add Ports, no canto superior direito.
1.7. Unity Connection: Ports
Ta acabando... aqui apenas defina a quantidade de portas, de acordo com o que você colocou no Wizard. E pronto! Você deve conseguir já ver as suas Voice Mail Ports registradas no CUCM. Se não tiverem registrando, um bom passo para começar o troubleshooting é ir em Phone System, e depois em Check Telephony Configuration em Related Links, no canto superior direito.
1.8. Unity Connection: Import Users
Agora é só ir em Tools >> Import Users, e importar os usuários criados no CUCM. Talvez antes disso você queira mudar o seu User Template, definir um PIN inicial e tudo mais.
2. Unity Connection + Call Manager usando SIP
Muito mais rápido!!!
a. No CUCM, crie um SIP Trunk Security Profile: System >> Security Profile >> SIP Trunk Security Profile. Esse profile deve ter marcado Accept Replaces Header, Accept Out-of-Dialog REFER, Accept Unsolicited Notification.
b. Crie um SIP Trunk para a Unity Connection, usando esse profile acima. No SIP Trunk, marque a opção Redirecting Diversion Header Delivery - Outbound
c. Crie uma Route Pattern apontando para o SIP Trunk. Essa Route Pattern será o seu Voice Mail Pilot.
d. Em Voice Mail Pilot, coloque o número que você configurou na Route Pattern.
e. Na Unity Connection, vá em Telephony Integrations >> PhoneSystem e configure do mesmo jeito que fizemos antes. Depois clique em Add Port Group.
f. No Port Group, selecione SIP no Port Group Template. E em IP Address or Hostname, coloque o IP do CUCM. Em Edit >> Servers, coloque as informações do seu CUCM também.
g. Clique em Add Ports, e coloque o número de portas que você quer configurar.
h. E só! Não precisa de Wizard nenhum, nem Voice Mail Ports, nem MWI Extensions, nada disso!
3. Configurando o botão Messages do telefone
Pelos labs da IP Expert, vi que eventualmente podem ter apagado o serviço do botão de Messages do seu telefone, e você tem que saber recriá-lo. Sem esse serviço, quando você aperta o botão de Messages não acontece nada. Uma puta falta de sacanagem cair isso na prova...
Bom, para recriar, ou você faz na mão (em Device >> Device Settings >> Phone Services), ou você faz via linha de comando por uma query SQL. Se for fazer na mão, tem que lembrar que a URL é Application:Cisco/Voicemail, o Service Type é Messages, e a categoria é XML. E marque Enterprise Subscriptions também.
Caso não queria lembrar de tudo isso, é só entrar no Release Notes da versão 7.0(1) do CUCM (que você terá acesso na prova) e dar um search por "Voicemail". Lá tem uma query para ser executada via console:
run sql insert into telecasterservice (pkid,Name,NameASCII,Description,URLTemplate,tkPhoneService,EnterpriseSubscription,Priority) values('ca69f2e4-d088-47f8-acb2-ceea6722272e','Voicemail','Voicemail','Voicemail','Application:Cisco/Voicemail',2,'t',1)
Aplique isso, dê um boot nos phones e já era.
1. Unity Connection + Call Manager usando SCCP
2. Unity Connection + Call Manager usando SIP
3. Unity Connection + Call Manager Express usando SCCP
4. Unity Connection + Call Manager Express usando SIP
5. Unity Express + Call Manager usando JTAPI
6. Unity Express + Call Manager Express usando SIP
Hoje eu vou falar sobre as duas primeiras, que envolvem o Unity Connection com Call Manager.
1. Unity Connection + Call Manager usando SCCP
Essa é a integração que a gente mais faz no dia-a-dia. É bem provável inclusive que ela já venha pronta na prova, e você só tenha que fazer um troubleshooting para descobrir o que tem de errado. De qualquer forma, é bom saber bem como se faz essa integração, porque pode te garantir uns pontinhos de graça na prova.
Vamos começar pela parte do Call Manager. Basicamente aqui a gente vai ter que criar as VM Ports e colocá-las num Line Group. Associamos o Line Group a uma Hunt List e a Hunt List a um Hunt Pilot. Depois criamos os MWI, o Voice Mail Pilot e o Voice Mail Profile! Parece que é um monte de coisa, mas dá para fazermos tudo em menos de 5 minutos.
1.1. Voice Mail Port Wizard
O Wizard (Voice Mail >> Cisco Voice Mail Port Wizard) é guia para a criação das VM Ports. Com ele, podemos criar todas as portas de uma vez e associá-las a um Line Group automaticamente. Os passos desse Wizard são:
a. Escolher se você quer criar uma nova integração, adionar portas a uma integração já existente ou deletar portas. No caso, vamos criar uma nova integração.
b. Escolher um nome para as portas. Esse nome tem que bater com o que você vai configurar depois na Unity Connection, então anote o que você colocar. Recomendo usar o default: CiscoUM1.
c. Informar o número de portas que será criado. Isso vai depender da sua licença, se for na vida real, ou do enunciado da questão, se for na prova. O número de portas define a quantidade de acessos simultâneos que a Unity Connection vai suportar.
d. Configurar a porta. As informações principais que você deve se atentar são: Device Pool, Calling Search Space, AAR CSS e Location.
e. Configurar os DNs. As informações principais que você deve se atentar são: Beginning Directory Number, Partition, Calling Search Space, AAR Group e External Phone Number Mask (em caso de cair AAR na prova, não esqueça de preencher isso aqui!). O Beginning DN vai definir qual será o seu range de ramal para as VM Ports, baseado na quantidade de portas que você definiu lá em cima... ele vai alocar os ramais sequencialmente a partir desse beginning directory number.
f. Configurar o Line Group. Aqui ele vai perguntar se você quer criar um novo line group, adicionar as portas a um line group já existente ou criar o line group manualmente depois. Vamos criar um novo Line Group.
g. Dar um nome para o Line Group. Qualquer nome...
h. Confirmar as informações que serão adicionadas. Se clicar em Next, ele já vai aplicar as alterações.
i. Resumo do que foi criado.
1.2. Line Group, Hunt List e Hunt Pilot
Agora que você já tem um Line Group criado com as suas VM Ports dentro, vamos associá-lo a uma Hunt List, que por sua vez será associada a um Hunt Pilot:
a. Call Routing >> Route/Hunt >> Hunt List: Crie uma nova Hunt List e associe o Line Group criado no Wizard. Marque a opção "For Voice Mail Usage".
b. Call Routing >> Route/Hunt >> Hunt Pilot: Crie um novo Hunt Pilot e associe o Hunt List criado acima. O Hunt Pilot será o número de acesso ao Voice Mail. Denovo, se você for ter que configurar AAR, não esqueça de colocar o AAR Group e External Phone Number Mask!
1.3. MWI, VM Pilot e VM Profile
O resto da integração, teremos que seguir manualmente, sem um Wizard. Mas é pouca coisa:
a. Voice Mail >> Message Waiting Numbers: Aqui definiremos o MWI, que é o alerta no telefone indicando que há uma nova mensagem no correio de voz. Será um ramal para On (ligar o alerta) e um ramal para Off (desligar o alerta) que a Unity Connection utilizará para acender e apagar a luzinha nos telefones.
Adicione os dois ramais e guarde esses números, pois precisaremos deles mais tarde. Atenção: O MWI também tem Partition e CSS. Os ramais devem ter acesso a ele, e ele deve ter acesso aos ramais. Se você tiver configuração de IPMA, a CSS do MWI deve ter acesso ao ramal do chefe!
b. Voice Mail >> Voice Mail Pilot: Colocamos aqui o VM Pilot (que tem que ser o mesmo número do Hunt Pilot criado acima). Basicamente, ele é um "Speed Dial" para o Hunt Pilot para quando você pressionar o botão Messages do telefone.
c. Voice Mail >> Voice Mail Profile: No Voice Mail Profile amarramos o Voice Mail Pilot e colocamos (ou não) uma máscara.
Digamos que você tenha 2 sites pendurados nesse cluster: Site A e Site B. O Site A usa um Unity Connection com o VM Pilot 5000 e o Site B usa um Unity Express com o VM Pilot 2000. Quando um telefone do Site A pressionar a tecla Messages, ele tem que ser mandado para o seu Voice Mail na Unity Connection, enquanto o usuário do Site B, quando pressionar o mesmo botão no seu telefone, tem que ser mandado para o seu Voice Mail na Unity Express. Para essa situação, teríamos que criar dois Profiles diferentes, um para cada site, e cada profile teria associado o VM Pilot correspondente.
Outra finalidade do VM Profile é a seguinte: Imagine que o seu ramal no CUCM é 5001. Mas por algum motivo, o seu ramal na Unity Connection teve que ser criado no formato 5511XXXX (tipo 55115001)... talvez por um problema de ramais duplicados, sei lá. Mas nesse caso, como o seu ramal no CUCM é diferente do seu ramal na Unity, teriamos que colocar uma máscara no Voice Mail Profile: 5511XXXX. Assim, quando você fosse acessar o Voice Mail, o CUCM enviaria para a Unity os digitos 55115001 e não 5001.
1.4. Ramais e Usuários
Só precisamos fazer mais duas coisas no CUCM:
a. Nos ramais que terão Voice Mail, marque o desvio para o Voice Mail nos casos de busy e no answer... e talvez no unregistered também, dependendo do que for pedido na prova.
b. Crie um End User para cada usuário, associe o Device (ou Device Profile em caso de Extension Mobility), e preencha o campo Primary Extension. Sem ele preenchido, a Unity não vai enxergar esse usuário na hora da importação.
1.5. Unity Connection: Phone System
Finalmente vamos para a Unity Connection:
a. Telephony Integration >> Phone System: Utilize o Phone System default já existente.
b. Vá em Edit >> Cisco Unified Communications Manager AXL Servers: Coloque os IPs dos CUCMs, e porta 443 (SSL). Cuidado para não deixar a porta 0, que é a default. Coloque o usuário e senha de admin do Call Manager (ou algum outro que tenha permissão de AXL).
c. Volte na tela inicial do seu Phone System, e clique em Add Port Group, em Related Links, no canto superior direito da tela.
1.6. Unity Connection: Port Group
a. Dê um nome para o seu Port Group (default: PhoneSystem-1)
b. Em Device Name Prefix, você vai colocar o mesmo que definiu lá em cima no Wizard. Mas atenção, o nome tem que ter um "-VI" na frente... maluquisses da Cisco. Então, como o nome que definimos foi CiscoUM1, o Device Name Prefix vai ser CiscoUM1-VI. Isso é clássico de cair na prova para resolver problema de integração...
c. Preencha os MWI Extensions de acordo com o que você configurou antes.
d. Coloque o IP do CUCM.
e. Volte na tela inicial do Port Group, e vá em Edit >> Servers. Preencha os dados do seu CUCM.
f. Volte na tela inicial do Port Group, e clique em Add Ports, no canto superior direito.
1.7. Unity Connection: Ports
Ta acabando... aqui apenas defina a quantidade de portas, de acordo com o que você colocou no Wizard. E pronto! Você deve conseguir já ver as suas Voice Mail Ports registradas no CUCM. Se não tiverem registrando, um bom passo para começar o troubleshooting é ir em Phone System, e depois em Check Telephony Configuration em Related Links, no canto superior direito.
1.8. Unity Connection: Import Users
Agora é só ir em Tools >> Import Users, e importar os usuários criados no CUCM. Talvez antes disso você queira mudar o seu User Template, definir um PIN inicial e tudo mais.
2. Unity Connection + Call Manager usando SIP
Muito mais rápido!!!
a. No CUCM, crie um SIP Trunk Security Profile: System >> Security Profile >> SIP Trunk Security Profile. Esse profile deve ter marcado Accept Replaces Header, Accept Out-of-Dialog REFER, Accept Unsolicited Notification.
b. Crie um SIP Trunk para a Unity Connection, usando esse profile acima. No SIP Trunk, marque a opção Redirecting Diversion Header Delivery - Outbound
c. Crie uma Route Pattern apontando para o SIP Trunk. Essa Route Pattern será o seu Voice Mail Pilot.
d. Em Voice Mail Pilot, coloque o número que você configurou na Route Pattern.
e. Na Unity Connection, vá em Telephony Integrations >> PhoneSystem e configure do mesmo jeito que fizemos antes. Depois clique em Add Port Group.
f. No Port Group, selecione SIP no Port Group Template. E em IP Address or Hostname, coloque o IP do CUCM. Em Edit >> Servers, coloque as informações do seu CUCM também.
g. Clique em Add Ports, e coloque o número de portas que você quer configurar.
h. E só! Não precisa de Wizard nenhum, nem Voice Mail Ports, nem MWI Extensions, nada disso!
3. Configurando o botão Messages do telefone
Pelos labs da IP Expert, vi que eventualmente podem ter apagado o serviço do botão de Messages do seu telefone, e você tem que saber recriá-lo. Sem esse serviço, quando você aperta o botão de Messages não acontece nada. Uma puta falta de sacanagem cair isso na prova...
Bom, para recriar, ou você faz na mão (em Device >> Device Settings >> Phone Services), ou você faz via linha de comando por uma query SQL. Se for fazer na mão, tem que lembrar que a URL é Application:Cisco/Voicemail, o Service Type é Messages, e a categoria é XML. E marque Enterprise Subscriptions também.
Caso não queria lembrar de tudo isso, é só entrar no Release Notes da versão 7.0(1) do CUCM (que você terá acesso na prova) e dar um search por "Voicemail". Lá tem uma query para ser executada via console:
run sql insert into telecasterservice (pkid,Name,NameASCII,Description,URLTemplate,tkPhoneService,EnterpriseSubscription,Priority) values('ca69f2e4-d088-47f8-acb2-ceea6722272e','Voicemail','Voicemail','Voicemail','Application:Cisco/Voicemail',2,'t',1)
Aplique isso, dê um boot nos phones e já era.
terça-feira, 15 de maio de 2012
CME Class of Restrictions
Um assunto que sempre me deu um pouco de nó na cabeça é a restrição de chamadas no CME. No CUCM estamos mais acostumados (pelo menos eu). Criamos as partitions e atribuímos às rotas para bloqueá-las; criamos as Calling Search Spaces e atribuimos aos devices para dar permissão.
Agora chega no CME e é "totalmente" diferente... tem as cor customs, cor lists, aplicamos como incoming em alguns lugares, outgoing em outros... uma zona! As explicações nas documentações da Cisco dizem que um ramal vai conseguir acesso a uma dial-peer caso o corlist do ramal seja um superconjunto (lembram disso?) da corlist da dial-peer. Não muito didático, né?
Bom, mas se pararmos para analisar, no CUCM também o ramal só vai conseguir ver uma pattern caso a sua Calling Search Space contenha a partition da rota. Ou seja, a CSS é um superconjunto do conjunto de partitions atribuídos a uma pattern. A diferença é o conjunto de partitions atribuído a uma pattern é formado por uma única partition. O que podemos concluir disso é que uma analogia entre Partitions/CSS do CUCM com Cor Lists do CME é totalmente plausível.
No CME, aplicamos os cor lists nas dial-peers (lembrando que quando criamos um ephone-dn, na realidade estamos criando uma dial-peer virtual para aquele ramal). E as cor lists possuem direção: incoming e outgoing. É só se colocar no lugar do roteador... quando a chamada vem de um ramal, ela é incoming. E quando sai para uma rota, ela é outgoing. Então geralmente aplicamos como incoming no ephone-dn (dial-peer de entrada) e como outgoing na pots dial-peer de saída.
No lado incoming, é o ephone-dn querendo fazer uma chamada. Então podemos considerar a cor list incoming como uma Calling Search Space.
E no lado outgoing, é a rota se bloqueando ou não para um ramal. Então podemos considerar a cor list outgoing como uma Partition.
Pronto, montamos a nossa analogia com o CUCM.
Obs: Essa não é a analogia/explicação que a Cisco usa nas documentações! Essa aqui é um pouco diferente e eu bolei de forma que eu pudesse lembrar melhor... se você nunca viu isso antes, sugiro ler as documentações da Cisco antes para ver como eles tratam oficialmente o assunto.
Bom, vamos ver um exemplo:
Digamos que tenho dois ramais criados no CME: ephone-dn 1 e ephone-dn 2. O 1 vai ter acesso a chamadas locais, e o 2 vai ter acesso a chamadas locais, DDD e DDI. Como podemos fazer isso?
1. Declarando a cor custom
Primeiramente precisamos declarar a nossa lista de cor custom. A Cisco faz uma analogia dessa lista com as Partitions, mas eu prefiro não encarar elas dessa forma. Basicamente aqui vamos definir algumas nomenclaturas para identificar cada tipo de chamada que queremos bloquear ou liberar. No caso, local, DDD e DDI.
2. Criando a cor list de saída
Agora vamos criar as cor lists. Vou separar em duas etapas: as cor list de entrada e as cor list de saída. Mas em termos de comando, é a mesma coisa. Vou separar apenas para ficar mais fácil de entender. As nossas cor lists de saída funcionarão como Partitions, pois elas que vão bloquear ou liberar a rota para um ramal.
Dentro de uma cor list, eu posso colocar vários members, como veremos adiante. Porém, para as cor list de saída, vamos deixar 1 member só. Lembra que eu falei que no CUCM "o conjunto de partitions atribuído uma pattern é formado por uma única partition". Então, é a mesma coisa... o conjunto de members atribuído a uma cor list de saída é formado por um único member.
3. Criando a cor list de entrada
E agora vamos criar as cor list de entrada, que serão as nossas "Calling Search Spaces". No CUCM a CSS só vê a rota quando a partition da rota estiver dentro da CSS, certo? Aqui é a mesma coisa. A cor list de entrada só vai ver a cor list de saída quando o member da cor list de saída estiver dentro da cor list de entrada. Portanto:
Veja que por enquanto apenas criamos as cor lists. Não há nada ainda diferenciando elas entre uma cor list de entrada e uma cor list de saída, exceto pela nomenclatura.
4. Aplicando na dial-peer de saída
Agora que temos tudo criado, vamos aplicar nas dial-peers. Primeiramente nas de saída.
O que faremos a seguir será como se estivéssemos atribuindo uma Partition a uma rota, como no CUCM.
Repare que a dial-peer de chamadas de emergência não possui corlist. Logo, ela não é bloqueada.
4. Aplicando na dial-peer de entrada
Agora vamos aplicar nas dial-peers de entrada. No caso, nos ephones-dn.
O que faremos a seguir será como se estivéssemos atribuindo uma Calling Search Space a um ramal.
ephone-dn 1 dual-line
E agora esse ephone-dn 3 que num tem nenhuma corlist associada? Pois é... isso é diferente do CUCM. Quando não há nenhuma corlist na dial-peer de entrada, ela por padrão tem tudo liberado. Logo, esse phone conseguiria fazer Local, DDD e DDI! Para bloquear esse ramal, poderíamos criar uma cor list de entrada vazia e aplicar ao ephone:
Outro exemplo
E se quisermos fazer o ephone-dn 4 não conseguir ligar internamente para o ephone-dn 5? Aí poderiamos fazer assim:
Ou seja, em algumas situações, a sua dial-peer de saída pode não ser uma pots para a PSTN. Assim como a sua dial-peer de entrada não precisa ser sempre um ephone-dn. Tudo vai depender dos seus requisitos.
Denovo, para saber quando é incoming e quando é outgoing, coloque-se sempre no lugar do roteador. No exemplo acima era uma chamada vinda do ephone-dn 4 para o ephone-dn 5. Logo, o 4 é incoming e o 5 é outgoing.
Agora chega no CME e é "totalmente" diferente... tem as cor customs, cor lists, aplicamos como incoming em alguns lugares, outgoing em outros... uma zona! As explicações nas documentações da Cisco dizem que um ramal vai conseguir acesso a uma dial-peer caso o corlist do ramal seja um superconjunto (lembram disso?) da corlist da dial-peer. Não muito didático, né?
Bom, mas se pararmos para analisar, no CUCM também o ramal só vai conseguir ver uma pattern caso a sua Calling Search Space contenha a partition da rota. Ou seja, a CSS é um superconjunto do conjunto de partitions atribuídos a uma pattern. A diferença é o conjunto de partitions atribuído a uma pattern é formado por uma única partition. O que podemos concluir disso é que uma analogia entre Partitions/CSS do CUCM com Cor Lists do CME é totalmente plausível.
No CME, aplicamos os cor lists nas dial-peers (lembrando que quando criamos um ephone-dn, na realidade estamos criando uma dial-peer virtual para aquele ramal). E as cor lists possuem direção: incoming e outgoing. É só se colocar no lugar do roteador... quando a chamada vem de um ramal, ela é incoming. E quando sai para uma rota, ela é outgoing. Então geralmente aplicamos como incoming no ephone-dn (dial-peer de entrada) e como outgoing na pots dial-peer de saída.
No lado incoming, é o ephone-dn querendo fazer uma chamada. Então podemos considerar a cor list incoming como uma Calling Search Space.
E no lado outgoing, é a rota se bloqueando ou não para um ramal. Então podemos considerar a cor list outgoing como uma Partition.
Pronto, montamos a nossa analogia com o CUCM.
Obs: Essa não é a analogia/explicação que a Cisco usa nas documentações! Essa aqui é um pouco diferente e eu bolei de forma que eu pudesse lembrar melhor... se você nunca viu isso antes, sugiro ler as documentações da Cisco antes para ver como eles tratam oficialmente o assunto.
Bom, vamos ver um exemplo:
Digamos que tenho dois ramais criados no CME: ephone-dn 1 e ephone-dn 2. O 1 vai ter acesso a chamadas locais, e o 2 vai ter acesso a chamadas locais, DDD e DDI. Como podemos fazer isso?
1. Declarando a cor custom
Primeiramente precisamos declarar a nossa lista de cor custom. A Cisco faz uma analogia dessa lista com as Partitions, mas eu prefiro não encarar elas dessa forma. Basicamente aqui vamos definir algumas nomenclaturas para identificar cada tipo de chamada que queremos bloquear ou liberar. No caso, local, DDD e DDI.
dial-peer cor custom
name local
name DDD
name DDI
2. Criando a cor list de saída
Agora vamos criar as cor lists. Vou separar em duas etapas: as cor list de entrada e as cor list de saída. Mas em termos de comando, é a mesma coisa. Vou separar apenas para ficar mais fácil de entender. As nossas cor lists de saída funcionarão como Partitions, pois elas que vão bloquear ou liberar a rota para um ramal.
dial-peer cor list PT-Local
member local
dial-peer cor list PT-DDD
member DDD
dial-peer cor list PT-DDI
member DDI
Dentro de uma cor list, eu posso colocar vários members, como veremos adiante. Porém, para as cor list de saída, vamos deixar 1 member só. Lembra que eu falei que no CUCM "o conjunto de partitions atribuído uma pattern é formado por uma única partition". Então, é a mesma coisa... o conjunto de members atribuído a uma cor list de saída é formado por um único member.
3. Criando a cor list de entrada
E agora vamos criar as cor list de entrada, que serão as nossas "Calling Search Spaces". No CUCM a CSS só vê a rota quando a partition da rota estiver dentro da CSS, certo? Aqui é a mesma coisa. A cor list de entrada só vai ver a cor list de saída quando o member da cor list de saída estiver dentro da cor list de entrada. Portanto:
dial-peer cor list CSS-Local
member local
dial-peer cor list CSS-DDD
member local
member DDD
dial-peer cor list CSS-DDI
member local
member DDD
member DDI
Veja que por enquanto apenas criamos as cor lists. Não há nada ainda diferenciando elas entre uma cor list de entrada e uma cor list de saída, exceto pela nomenclatura.
4. Aplicando na dial-peer de saída
Agora que temos tudo criado, vamos aplicar nas dial-peers. Primeiramente nas de saída.
O que faremos a seguir será como se estivéssemos atribuindo uma Partition a uma rota, como no CUCM.
dial-peer voice 1 pots
description *** Chamadas de Emergencia ***
destination-pattern 019.
port 0/0/0:15
forward-digits 3
dial-peer voice 10 pots
description *** Chamadas Locais ***
destination-pattern 0[2-9].......
port 0/0/0:15
corlist outgoing PT-Local
dial-peer voice 11 pots
description *** Chamadas DDD ***
destination-pattern 0[0][^0][^0][^0][^0][2-9].......
port 0/0/0:15
corlist outgoing PT-DDD
dial-peer voice 12 pots
description *** Chamadas DDI ***
destination-pattern 0[0][0]T
port 0/0/0:15
corlist outgoing PT-DDI
Repare que a dial-peer de chamadas de emergência não possui corlist. Logo, ela não é bloqueada.
4. Aplicando na dial-peer de entrada
Agora vamos aplicar nas dial-peers de entrada. No caso, nos ephones-dn.
O que faremos a seguir será como se estivéssemos atribuindo uma Calling Search Space a um ramal.
ephone-dn 1 dual-line
number 1000
corlist incoming CSS-Local
ephone-dn 2 dual-line
number 1001
corlist incoming CSS-DDI
ephone-dn 3 dual-line
number 1002
E agora esse ephone-dn 3 que num tem nenhuma corlist associada? Pois é... isso é diferente do CUCM. Quando não há nenhuma corlist na dial-peer de entrada, ela por padrão tem tudo liberado. Logo, esse phone conseguiria fazer Local, DDD e DDI! Para bloquear esse ramal, poderíamos criar uma cor list de entrada vazia e aplicar ao ephone:
dial-peer cor list CSS-Block
ephone-dn 3
corlist incoming CSS-Block
E se quisermos fazer o ephone-dn 4 não conseguir ligar internamente para o ephone-dn 5? Aí poderiamos fazer assim:
dial-peer cor custom
name ephone5
dial-peer cor list PT-Ephone5
member ephone5
dial-peer cor list CSS-Ephone4
ephone-dn 4 dual-line
number 1004
corlist incoming CSS-Ephone4
ephone-dn 5 dual-line
number 1005
corlist outgoing PT-Ephone5
Denovo, para saber quando é incoming e quando é outgoing, coloque-se sempre no lugar do roteador. No exemplo acima era uma chamada vinda do ephone-dn 4 para o ephone-dn 5. Logo, o 4 é incoming e o 5 é outgoing.
segunda-feira, 14 de maio de 2012
Primeiro lab remoto
Nesse final de semana fiz os meus primeiros labs remotos da ProctorLabs (Lab1, Volume 2 do IPExpert). E achei interessante compartilhar aqui o resultado. Como toda "primeira vez", estava meio atrapalhado... fui bem mal no sábado, não consegui terminar toda a prova e fiquei meio perdido algumas horas. Despesperante! Eu li o lab, sabia mais ou menos o que tinha que fazer, mas não consegui organizar os meus pensamentos de forma a bolar uma estratégia para atacá-lo.
Todo mundo fala que tem que ser rápido, não pode perder tempo e bla bla bla, então eu tentei fazer tudo o mais rápido que pude. Tipo, vou configurar um telefone no CUCM? Então já buscava na prova todos os requisitos para configurar o telefone de forma que eu tivesse que entrar na tela de config dele apenas uma vez! Então eu ía alternando entre as questões, tentando otimizar o meu tempo, e no final me perdi todo, não sabia direito o que tinha feito, o que faltava... foi um lixo.
Aí pensei... "não é possível... não pode ser assim que as pessoas otimizam o tempo! A não ser que você consiga organizar o seu raciocínio de uma maneira completamente foda".
Resolvi ver alguns comentários na Internet, mais especificamente esse post aqui do Vik Malhi: http://blog.ipexpert.com/2011/01/03/the-big-day-hour-1/
Recomendo fortemente a leitura! Com uma frase ele me entender o meu erro... "Walk before you can run". É isso! Não adianta você começar a prova já pensando como o Phone 1 do HQ vai apresentar o ANI em uma chamada de emergência, se você nem tem ainda o seu Phone 1 registrado! O importante é manter a calma, e se organizar. Se tiver que voltar na config do telefone para mudar uma CSS, tudo bem! Você num vai perder mais do que 15 segundos nisso... Percebi que não adianta economizar tempo com coisas idiotas como essas. Claro, tem coisa que é mais simples, então da pra ganhar uns minutinhos... tipo, configuração dos Softkeys templates, Phone Button templates, Service Parameters... isso só de vc ler a prova uma vez já da pra ter uma idéia do que você vai precisar alterar. Então faça uma vez só. Mas coisas mais complexas, principalmente as que envolvem Dial Plan, eu iria com mais calma.
Bom, o resultado do segundo lab (que eu acabei de acabar) foi bem melhor. Fiz novamente o Lab 1 (que acredito que seja mais facinho que os outros mesmo), e consegui acabar em 5h30. E ainda sobrou umas 2h pra revisar tudo e 15 minutos pra tomar banho! hauhauhau
Isso num lab real estaria ótimo! Claro, fazendo pela segunda vez eu já estava bem mais familiarizado com ele e tudo mais, mas mesmo assim fiquei satisfeito com o progresso.
Ao contrário da minha primeira tentativa, fiz a prova com mais calma e adotando a estratégia "technology-based approach", isto é, resolvendo as questões separando por assuntos (call routing, qos, high availability, ...). Acho que é bem mais fácil de você não se perder com essa estratégia. Tem gente que prefere o método device-based (http://www.youtube.com/watch?v=c1OKIJDDcaE), que é realmente bem interessante, só que acho que é muito fácil para você acabar se perdendo.
Comecei a prova da seguinte forma:
1. Infraestrutura e registro de devices: Faça isso o mais rápido que puder, porque é a parte mais fácil da prova
2. QoS: Acho melhor fazer no começo, porque se você zoar a sua WAN no final da prova, já era!
3. Call Routing: Depois de terminar Call Routing, você tira um peso das costas, e o resto flui mais fácil.
É isso aí, conforme eu for fazendo mais labs, vou colocando aqui o que aprendo com eles com relação a estratégia. Às vezes é a estratégia que define o seu sucesso ou fracasso.
E pra fechar o post, uma fotinha do meu home-lab, agora com telefones coloridos! hehehe
E feliz dia das mães! Graças à minha que estou aqui atrás desse desafio... quem diria, há 10 anos a minha mãe me incentivava a fazer o curso da Net Academy e hoje estou aqui estudando para um CCIE. Mãe sabe o que faz mesmo... hehehe
Ah, ontem lendo outros blogs, vi esse aqui do Matthew Berry (o cara do device-based approach):
http://ciscovoiceguru.com/548/ccie-voice-lab-strategy/
Ele diz: "make a commitment to keep an online blog"! uhu, acho que estou no caminho certo! hauhauhauhua...
Todo mundo fala que tem que ser rápido, não pode perder tempo e bla bla bla, então eu tentei fazer tudo o mais rápido que pude. Tipo, vou configurar um telefone no CUCM? Então já buscava na prova todos os requisitos para configurar o telefone de forma que eu tivesse que entrar na tela de config dele apenas uma vez! Então eu ía alternando entre as questões, tentando otimizar o meu tempo, e no final me perdi todo, não sabia direito o que tinha feito, o que faltava... foi um lixo.
Aí pensei... "não é possível... não pode ser assim que as pessoas otimizam o tempo! A não ser que você consiga organizar o seu raciocínio de uma maneira completamente foda".
Resolvi ver alguns comentários na Internet, mais especificamente esse post aqui do Vik Malhi: http://blog.ipexpert.com/2011/01/03/the-big-day-hour-1/
Recomendo fortemente a leitura! Com uma frase ele me entender o meu erro... "Walk before you can run". É isso! Não adianta você começar a prova já pensando como o Phone 1 do HQ vai apresentar o ANI em uma chamada de emergência, se você nem tem ainda o seu Phone 1 registrado! O importante é manter a calma, e se organizar. Se tiver que voltar na config do telefone para mudar uma CSS, tudo bem! Você num vai perder mais do que 15 segundos nisso... Percebi que não adianta economizar tempo com coisas idiotas como essas. Claro, tem coisa que é mais simples, então da pra ganhar uns minutinhos... tipo, configuração dos Softkeys templates, Phone Button templates, Service Parameters... isso só de vc ler a prova uma vez já da pra ter uma idéia do que você vai precisar alterar. Então faça uma vez só. Mas coisas mais complexas, principalmente as que envolvem Dial Plan, eu iria com mais calma.
Bom, o resultado do segundo lab (que eu acabei de acabar) foi bem melhor. Fiz novamente o Lab 1 (que acredito que seja mais facinho que os outros mesmo), e consegui acabar em 5h30. E ainda sobrou umas 2h pra revisar tudo e 15 minutos pra tomar banho! hauhauhau
Isso num lab real estaria ótimo! Claro, fazendo pela segunda vez eu já estava bem mais familiarizado com ele e tudo mais, mas mesmo assim fiquei satisfeito com o progresso.
Ao contrário da minha primeira tentativa, fiz a prova com mais calma e adotando a estratégia "technology-based approach", isto é, resolvendo as questões separando por assuntos (call routing, qos, high availability, ...). Acho que é bem mais fácil de você não se perder com essa estratégia. Tem gente que prefere o método device-based (http://www.youtube.com/watch?v=c1OKIJDDcaE), que é realmente bem interessante, só que acho que é muito fácil para você acabar se perdendo.
Comecei a prova da seguinte forma:
1. Infraestrutura e registro de devices: Faça isso o mais rápido que puder, porque é a parte mais fácil da prova
2. QoS: Acho melhor fazer no começo, porque se você zoar a sua WAN no final da prova, já era!
3. Call Routing: Depois de terminar Call Routing, você tira um peso das costas, e o resto flui mais fácil.
É isso aí, conforme eu for fazendo mais labs, vou colocando aqui o que aprendo com eles com relação a estratégia. Às vezes é a estratégia que define o seu sucesso ou fracasso.
E pra fechar o post, uma fotinha do meu home-lab, agora com telefones coloridos! hehehe
E feliz dia das mães! Graças à minha que estou aqui atrás desse desafio... quem diria, há 10 anos a minha mãe me incentivava a fazer o curso da Net Academy e hoje estou aqui estudando para um CCIE. Mãe sabe o que faz mesmo... hehehe
Ah, ontem lendo outros blogs, vi esse aqui do Matthew Berry (o cara do device-based approach):
http://ciscovoiceguru.com/548/ccie-voice-lab-strategy/
Ele diz: "make a commitment to keep an online blog"! uhu, acho que estou no caminho certo! hauhauhauhua...
sexta-feira, 11 de maio de 2012
WAN QoS (Frame Relay) - AutoQoS
Estava devendo esse post já há uns meses. No post que fiz em Janeiro sobre WAN QoS, abordei o MQC-Based, onde colocávamos o Traffic Shapping dentro de uma Policy-Map que era chamada pelo map-class frame-relay e etc, etc, etc. Na verdade, você só vai precisar configurar aquela forma de QoS se no enunciado ele for claro quanto a isso, ou se ele disser que você não pode usar o AutoQoS. Caso contrário, o jeito mais fácil e rápido de configurar o QoS na WAN é usando o nosso bom e velho amigo AutoQoS.
Então vamos para a primeira regra. SEMPRE antes de configurar qualquer coisa do seu auto qos, defina a banda do link na sua interface física. É baseado nesse valor que ele vai definir os seus parâmetros do Frame-Relay e do Traffic Shapping. Se você não colocar nada, ele vai considerar que a sua banda é de 1544Kbps, e aí ele não vai configurar o Traffic Shapping, pois ele só configura para links menores que 768Kbps.
Uma vez definida a banda na interface, entre na configuração do seu dlci e aplique um dos comandos abaixo:
Quatro comandos? Sim, quatro tipos de AutoQoS, e temos que saber bem a diferença entre eles... Mas é bem fácil! Os comandos com fr-atm configuram o AutoQoS usando MLPPP e os comandos sem o fr-atm configuram usando o FRF.12. Basicamente são duas formas de se configurar o LFI (Link Fragmentation and Interleaving). Então se o enunciado pedir MLP, coloque o fr-atm. Se pedir FRF.12, não coloque o fr-atm. Simples assim... Eventualmente no mesmo enunciado ele pode pedir para você configurar o link HQ - BR1 com MLP e HQ - BR2 com FRF.12... isso é perfeitamente possível. Em uma interface você configura com o fr-atm e na outra não. Bom, e o trust tá na cara, né? Com o trust ele vai confiar na marcação, e as suas class-maps vão dar match apenas no DSCP. Sem o trust ele não vai confiar na marcação vinda do Switch, e as suas class-maps vão reclassificar os pacotes novamente através de access-lists.
Vamos ver um pouco de configuração... fica mais fácil explicar:
Aplicando o AutoQoS
Com o trust ou sem o trust?
Se você aplicar o trust no seu comando de auto qos, independente de usar ou não o fr-atm, a sua class-map ficará assim:
class-map match-any AutoQoS-VoIP-RTP-Trust
match ip dscp ef
class-map match-any AutoQoS-VoIP-Control-Trust
match ip dscp cs3
match ip dscp af31
Repare que ele apenas deu match no DSCP e boa.
Se você não aplicar o trust, fica assim:
ip access-list extended AutoQoS-VoIP-Control
permit tcp any any eq 1720
permit tcp any any range 11000 11999
permit udp any any eq 2427
permit tcp any any eq 2428
permit tcp any any range 2000 2002
permit udp any any eq 1719
permit udp any any eq 5060
ip access-list extended AutoQoS-VoIP-RTCP
permit udp any any range 16384 32767
Repare que agora ele criou umas access lists para classificar o tráfego de RTP e Sinalização. Eventualmente o enunciado pode pedir para você não usar Access Lists. Nesse caso seria só remover tudo isso e configurar as class-maps com NBAR (match protocol XXX).
MLP
Para os exemplos, vou considerar links menores que 768Kbps. Porque se for maior que isso, tanto faz porque o roteador não vai configurar LFI.
Quando configuramos MLPPP, o roteador cria uma interface virtual chamada Vitual-Template. Se o enunciado pedir para configurar MLP, nem pense em criar isso na mão porque vai dar um trabalhão!!! Deixe que o AutoQoS faça tudo por você. Detalhe que geralmente é necessário um reboot no router depois de aplicar essa config, senão você perde acesso a tudo... um bom motivo para nunca deixar QoS para o final da prova, porque se você quebrar a WAN nos 47 do segundo tempo, meu amigo...
Bom, a configuração usando MLPPP vai ficar assim:
map-class frame-relay AutoQoS-FR-Se0/0-101
frame-relay cir 384000 ! -- Aqui um detalhe. O SRND diz que
frame-relay bc 3840 ! esses valores devem ser 95% do CIR.
frame-relay be 0 ! ou seja, no caso, 36480. Então
frame-relay mincir 384000 ! teriamos que alterá-los na mão.
! Mas se a prova não disser nada, deixe
! assim ou confirme com o Proctor. --
FRF.12
Configuração de FRF.12 é bem mais tranquila. Da até para fazer na mão, se quiser. Tipo, você configura o HQ com auto qos, copia as configurações modificadas e cola na outra ponta da sua WAN. É uma boa tática para economizar um pouco de tempo.
map-class frame-relay AutoQoS-FR-Se0/0-203
frame-relay cir 384000 ! -- Mesma coisa. Confirme com o
frame-relay bc 3840 ! Proctor se tem que seguir o SRND e
frame-relay be 0 ! mudar esses valores para 95% --
frame-relay mincir 384000
frame-relay fragment 480
service-policy output AutoQoS-Policy-Trust
Cálculo da Banda
Pode ser que a prova peça para você permitir na LLQ x chamadas usando G.729 por exemplo. Nesse caso, usar MLPPP ou FRF.12 vai mudar as suas contas. Se você usar MLPPP, o seu overhead de Layer 2 será de 13 bytes. Se usar FRF.12, o overhead é de 6 bytes, de acordo com o SRND. Então atenção com isso na hora de fazer as suas contas.
Se você tiver que configurar FRF.12 e MLPPP no mesmo router, tipo um para a comunicação HQ-BR1 e outra para HQ-BR2, e tiver que configurar bandas diferentes nas suas LLQs, vc vai precisar criar uma segunda Policy-Map e mudar no Virtual-Template.
Para mais informações sobre a continha para fazer o cálculo da banda, veja o meu primeiro post, do dia 30/12.
Então vamos para a primeira regra. SEMPRE antes de configurar qualquer coisa do seu auto qos, defina a banda do link na sua interface física. É baseado nesse valor que ele vai definir os seus parâmetros do Frame-Relay e do Traffic Shapping. Se você não colocar nada, ele vai considerar que a sua banda é de 1544Kbps, e aí ele não vai configurar o Traffic Shapping, pois ele só configura para links menores que 768Kbps.
Uma vez definida a banda na interface, entre na configuração do seu dlci e aplique um dos comandos abaixo:
auto qos voip trust
auto qos voip trust fr-atm
auto qos voip
auto qos voip fr-atm
Vamos ver um pouco de configuração... fica mais fácil explicar:
Aplicando o AutoQoS
interface Serial0/0.1 point-to-point
bandwidth 384 ! -- Primeiro definimos a banda
frame-relay interface-dlci 101 ! -- Depois aplicamos um dos
auto qos voip trust ! -- comandos de AutoQoSCom o trust ou sem o trust?
Se você aplicar o trust no seu comando de auto qos, independente de usar ou não o fr-atm, a sua class-map ficará assim:
class-map match-any AutoQoS-VoIP-RTP-Trust
match ip dscp ef
class-map match-any AutoQoS-VoIP-Control-Trust
match ip dscp cs3
match ip dscp af31
Repare que ele apenas deu match no DSCP e boa.
Se você não aplicar o trust, fica assim:
class-map match-any AutoQoS-VoIP-Remark ! -- Pode ignorar essa
match ip dscp ef
match ip dscp cs3
match ip dscp af31
class-map match-any AutoQoS-VoIP-Control-UnTrust
match access-group name AutoQoS-VoIP-Control
class-map match-any AutoQoS-VoIP-RTP-UnTrust
match protocol rtp audio
match access-group name AutoQoS-VoIP-RTCP
match ip dscp ef
match ip dscp cs3
match ip dscp af31
class-map match-any AutoQoS-VoIP-Control-UnTrust
match access-group name AutoQoS-VoIP-Control
class-map match-any AutoQoS-VoIP-RTP-UnTrust
match protocol rtp audio
match access-group name AutoQoS-VoIP-RTCP
permit tcp any any eq 1720
permit tcp any any range 11000 11999
permit udp any any eq 2427
permit tcp any any eq 2428
permit tcp any any range 2000 2002
permit udp any any eq 1719
permit udp any any eq 5060
ip access-list extended AutoQoS-VoIP-RTCP
permit udp any any range 16384 32767
Repare que agora ele criou umas access lists para classificar o tráfego de RTP e Sinalização. Eventualmente o enunciado pode pedir para você não usar Access Lists. Nesse caso seria só remover tudo isso e configurar as class-maps com NBAR (match protocol XXX).
MLP
Para os exemplos, vou considerar links menores que 768Kbps. Porque se for maior que isso, tanto faz porque o roteador não vai configurar LFI.
Quando configuramos MLPPP, o roteador cria uma interface virtual chamada Vitual-Template. Se o enunciado pedir para configurar MLP, nem pense em criar isso na mão porque vai dar um trabalhão!!! Deixe que o AutoQoS faça tudo por você. Detalhe que geralmente é necessário um reboot no router depois de aplicar essa config, senão você perde acesso a tudo... um bom motivo para nunca deixar QoS para o final da prova, porque se você quebrar a WAN nos 47 do segundo tempo, meu amigo...
Bom, a configuração usando MLPPP vai ficar assim:
policy-map AutoQoS-Policy-Trust
class AutoQoS-VoIP-RTP-Trust
priority percent 70 ! -- Essa é a sua LLQ, que provavel-
class AutoQoS-VoIP-RTP-Trust
priority percent 70 ! -- Essa é a sua LLQ, que provavel-
! mente você tenha que modificar
! depois. --
! depois. --
compression header ip rtp ! cRTP. Eu que adicionei essa linha
! Por padrão o AutoQoS não habilita
! o Class-Based cRTP. Se a prova
! pedir, é assim que faz. --
class AutoQoS-VoIP-Control-Trust
bandwidth percent 5
class class-default
fair-queue
class AutoQoS-VoIP-Control-Trust
bandwidth percent 5
class class-default
fair-queue
interface Serial0/0.1 point-to-point
description Connection to BranchOffice1
bandwidth 384
snmp trap link-status
frame-relay interface-dlci 101 ppp Virtual-Template200
class AutoQoS-FR-Se0/0-101
auto qos voip trust fr-atm
description Connection to BranchOffice1
bandwidth 384
snmp trap link-status
frame-relay interface-dlci 101 ppp Virtual-Template200
class AutoQoS-FR-Se0/0-101
auto qos voip trust fr-atm
interface Virtual-Template200 ! -- O AutoQoS que configurou isso
bandwidth 384
ip address 10.10.10.1 255.255.255.252
ppp multilink
ppp multilink interleave
ppp multilink fragment delay 10
bandwidth 384
ip address 10.10.10.1 255.255.255.252
ppp multilink
ppp multilink interleave
ppp multilink fragment delay 10
service-policy output AutoQoS-Policy-Trust
map-class frame-relay AutoQoS-FR-Se0/0-101
frame-relay cir 384000 ! -- Aqui um detalhe. O SRND diz que
frame-relay bc 3840 ! esses valores devem ser 95% do CIR.
frame-relay be 0 ! ou seja, no caso, 36480. Então
frame-relay mincir 384000 ! teriamos que alterá-los na mão.
! Mas se a prova não disser nada, deixe
! assim ou confirme com o Proctor. --
FRF.12
Configuração de FRF.12 é bem mais tranquila. Da até para fazer na mão, se quiser. Tipo, você configura o HQ com auto qos, copia as configurações modificadas e cola na outra ponta da sua WAN. É uma boa tática para economizar um pouco de tempo.
policy-map AutoQoS-Policy-Trust ! -- Mesma coisa que lá em cima
class AutoQoS-VoIP-RTP-Trust
priority percent 70
class AutoQoS-VoIP-RTP-Trust
priority percent 70
class AutoQoS-VoIP-Control-Trust
bandwidth percent 5
class class-default
fair-queue
bandwidth percent 5
class class-default
fair-queue
interface Serial0/0.1 point-to-point
description Connection to HQ
bandwidth 384
ip address 10.10.10.6 255.255.255.252
snmp trap link-status
frame-relay interface-dlci 203
class AutoQoS-FR-Se0/0-203
auto qos voip trust
frame-relay ip rtp header-compression ! -- Remova isso se for
description Connection to HQ
bandwidth 384
ip address 10.10.10.6 255.255.255.252
snmp trap link-status
frame-relay interface-dlci 203
class AutoQoS-FR-Se0/0-203
auto qos voip trust
frame-relay ip rtp header-compression ! -- Remova isso se for
! usar class-based cRTP --
frame-relay cir 384000 ! -- Mesma coisa. Confirme com o
frame-relay bc 3840 ! Proctor se tem que seguir o SRND e
frame-relay be 0 ! mudar esses valores para 95% --
frame-relay mincir 384000
frame-relay fragment 480
service-policy output AutoQoS-Policy-Trust
Cálculo da Banda
Pode ser que a prova peça para você permitir na LLQ x chamadas usando G.729 por exemplo. Nesse caso, usar MLPPP ou FRF.12 vai mudar as suas contas. Se você usar MLPPP, o seu overhead de Layer 2 será de 13 bytes. Se usar FRF.12, o overhead é de 6 bytes, de acordo com o SRND. Então atenção com isso na hora de fazer as suas contas.
Se você tiver que configurar FRF.12 e MLPPP no mesmo router, tipo um para a comunicação HQ-BR1 e outra para HQ-BR2, e tiver que configurar bandas diferentes nas suas LLQs, vc vai precisar criar uma segunda Policy-Map e mudar no Virtual-Template.
Para mais informações sobre a continha para fazer o cálculo da banda, veja o meu primeiro post, do dia 30/12.
Assinar:
Postagens (Atom)