Ccna Voice - 640-461

Conceitos de Telefonia e Comunicaes Analgicas
O incio da era das telecomunicaes moderna se deu em 1876 com a inveno do telefone
por Alexander Graham Bell. Desde essa poca at os dias atuais a indstria de telefonia passou por
diversas fases, acompanhando a evoluo tecnolgica da humanidade.
Um dos primeiros inventos registrados na histria que possua a capacidade de registrar e reproduzir
a voz humana foi o fongrafo, o qual foi inventado em 21 de Novembro de 1877, por Thomas Edison.
Veja a figura abaixo:
O aparelho consistia em um cilindro com sulcos coberto por uma folha de estanho. Uma ponta aguda
era pressionada contra o cilindro, enquanto conectado ponta oposta ficava um diafragma (uma
membrana circular, cujas vibraes convertiam sons em impulsos mecnicos e vice-versa) acoplado a
um grande bocal em forma de cone. O cilindro era girado manualmente, e conforme o operador ia
falando no bocal (ou chifre), a voz fazia o diafragma vibrar, o que fazia a ponta aguda criar um sulco
anlogo na superfcie do estanho. Quando a gravao estava completa, a ponta era substituda por
uma agulha e a mquina desta vez produzia as palavras quando o cilindro era girado mais uma vez.
J a telefonia nasceu na descoberta da possibilidade da converso da voz humana (energia acstica)
em um sinal eltrico. Assim como em um fongrafo um telefone analgico tem a misso primria de
converter a voz transmitida pelo emissor em outro tipo de formato, mais especificamente em um
sinal eltrico. Esse sinal por sua vez ir registrar as diversas caractersticas da voz do emissor e ser
transmitido ao receptor atravs de ondas eltricas utilizando um meio de transmisso, mais
especificamente utilizando pares de fios metlicos.
Do outro lado da linha, o aparelho receptor recebe essas ondas eltricas e as converte em energia
sonora (ondas sonoras) novamente, permitindo que o receptor entenda a mensagem enviada pelo
emissor mesmo a uma distncia razovel.
Assim nasce a era da telefonia, inicialmente necessitando ser interligado atravs de uma telefonista, o
que foi com o tempo sendo substituda por centrais telefnicas capazes de encaminhar as chamadas
sem interveno humana, sendo no incio centrais analgicas eletromecnicas e

posteriormente centrais telefnicas e PABX digitais.
Temos que lembrar que alm da voz, o telefone analgicorecebe diversos tipos de tons e
sinalizaes, os quais so trocados com as centrais telefnicas para representar o estado de uma
ligao. Por exemplo, quando voc tira o telefone do gancho voc recebe um tom chamado tom de
discar ou dial tone (em ingls), o qual significa que voc pode iniciar a discagem para o nmero
que deseja falar. O tom de discar contnuo. Quando voc disca os nmeros ou dgitos eles so
enviados atravs dos pares metlicos central telefnica para que sua chamada seja encaminhada.
Caso o nmero chamado esteja disponvel o telefone dele vai tocar (ring ou tom da campainha) e seu
telefone receber um tom diferente, intermitente, chamado de ring back ou tom de chamada. Caso o
receptor esteja falando no telefone voc vai receber o tom de ocupado (busy signal), o famoso tu-tutu. Essa sinalizao ser discutida posteriormente em mais detalhes.
Os telefones analgicos, conforme j mencionado, so conectados s centrais telefnicas atravs de
um par metlico, ou seja, dois fios. Um dos fios chamado de terra ou positivo (Tip ou Ground
em ingls) e o outro o negativo ou -48V (Battery ou Ring em ingls). Esses dois fios so
responsveis pela conexo do telefone central e sua energizao, pois uma vez que o telefone
encontra-se no gancho (on-hook em ingls) ele est com o circuito aberto e ao tirar o telefone do
gancho (off-hook em ingls) o circuito entre a central e o telefone fechado e uma corrente eltrica
passa a alimentar esse aparelho, fornecendo a energia para os componentes internos do telefone.
Veja a figura 1 ao lado.
Reparem que o x na figura 1 no fone representa que o circuito est aberto quando o telefone est
no gancho, ou seja, o par de fios que conecta o telefone central est desconectado. Ao retirar o
telefone do gancho esse par conectado e possibilita que uma corrente eltrica flua entre a central e
o telefone. Esse processo chamado de sinalizao loop start, ou seja, o incio da sinalizao se d
atravs do fechamento do loop entre o par de fios. Acompanhe nas figuras 2 e 3 abaixo.
Figura 1
Figura 2
Figura 3
A sinalizao descrita anteriormente, o loop start, a mais comum e muito utilizada para usurios
residenciais. Existem ainda diversos outros tipos de sinalizao, as quais so divididas
como informacional (dial-tone, ring-back, etc), de superviso (no gancho, fora do gancho, ring) e
para endereamento (DTMF, decdico), porm elas sero estudadas com mais detalhes no CCNP de
Voz, mais especificamente na prova do CVOICE.
Entrando um pouco mais a fundo no loop start, importante saber que ele suscetvel a um
problema chamado glare ou ofuscamento. Esse problema ocorre quando voc atende ao telefone
em um momento antes dele tocar, ou seja, algum estava ligando para voc e antes de voc ouvir o
ring (campainha), voc tira o telefone do gancho para fazer uma ligao. Nesse momento voc
esperava escutar um tom de discar e ao invs disso tem uma pessoa na linha.
Voc pode pensar que o problema no to grande assim, pois em um ambiente residencial essa
ligao era realmente para voc ou algum da sua famlia, porm se extrapolarmos para uma
empresa essa situao pode trazer srios problemas. Isso porque na sua casa tem normalmente
apenas um telefone e uma linha telefnica, agora imagine isso em uma empresa com diversos
telefones e diversas linhas telefnicas.
Vamos imaginar que voc agora est em um ambiente empresarial com vrias linhas analgicas
conectadas a um KS (Key System), no qual temos 5 linhas analgicas interconectadas rede pblica
de telefonia (PSTN Public Switched Telephone Network) que esto compartilhadas entre todos os
funcionrios, com um alto volume de ligaes para seus clientes, conforme figura abaixo:
Se uma chamada chegar para o x1001 ao mesmo tempo em que o x1002 tira o telefone do gancho, o
KS vai conectar essa chamada no ramal x1002, fazendo que o x1002 receba a chamada que era para o
x1001. Isso acontece porque o sinal inicial do loop de x1002 ocupa a linha PSTN de sada ao mesmo
tempo em que o KS recebe a chamada que est vindo na mesma linha PSTN. Esse um dos tipos de
glare.
Devido a esse problema, os equipamentos mais modernos, tais como um PABX, utilizam o ground
start como forma de sinalizao. O ground start possui um sistema de reconhecimento de conexes
e desconexes em cada lado do tronco, o que evita que um tronco seja ocupado por mais de um
aparelho telefnico como ilustrado no exemplo do glare quando utilizamos loop start. Para receber o
tom de discagem da Central Pblica (PSTN) o PABX deve enviar um sinal de terra sobre os fios. Isso
intencionalmente sinaliza para a Central PSTN que uma chamada de sada vai acontecer, enquanto
que o mtodo de sinalizao loop start apenas conecta os fios para receber uma chamada ou fazer
uma chamada de sada.
Para concluir, temos que afirmar que PABX uma central telefnica onde chegam as linhas da rede
pblica e saem os ramais para os usurios. Nesta central tambm podem ser conectados o interfone
para tocar direto no telefone e muitas outras funes. Geralmente quem utiliza as funes do PABX
no dia-a-dia so os profissionais de secretariado, que precisam possuir um aparelho de telefone TI
(Terminal Inteligente) para terem acesso a todas as funes da central telefnica.
Um PBX (sigla em ingls de Private Branch Exchange ou ainda PABX para Private Automatic Branch
Exchange, cuja traduo seria troca automtica de ramais privados) um centro de distribuio
telefnica pertencente a uma empresa que no inclua como sua atividade o fornecimento de servios
telefnicos ao pblico em geral. Em um ambiente corporativo normalmente existem muito mais
ramais do que linhas telefnicas, principalmente devido ao custo, havendo a necessidade de um
ponto central para gerenciar e distribuir as chamadas, o que feito pelo PABX. O equipamento tornase tambm um elemento de controle dos usurios de ramais, podendo gerenciar permisses de uso
individuais ou por grupo.
Key system (sistema de chaves, em ingls) era o nome dado s antigas mesas de telefonista, para
comutao privada de ligaes. O KS era uma mesa com uma matriz de chaves, que o operador usava
para comutar os troncos e ramais. Atualmente, a comutao feita eletronicamente, mas algumas
pessoas ainda chamam o terminal de telefonista (mais sofisticado que um telefone comum) de KS.
Problemas do Mundo das Conexes Analgicas
Com o tempo alguns problemas comearam a aparecer devido ao crescimento exponencial da
procura por esse novo meio revolucionrio de se comunicar.
Os dois principais problemas foram:
Distncia entre os aparelhos dificultava a comunicao e

Quantidade de fios para conectar as diversas centrais
Um sinal analgico se propagando atravs de um meio metlico sofre influncia da resistncia desse
fio e interferncias advindas do meio externo. Para resolver o problema da resistncia, que traz uma
perda na potncia do sinal, as companhias telefnicas comearam a utilizarrepetidores e
amplificadores de sinal para aumentar a distncia atingida.
O problema do uso de tal recurso que ao amplificar o sinal o rudo ou interferncia tambm
amplificado, acabando por degradar tanto o sinal que acabava tornando-o quase que impossvel do
receptor reconhecer o que estava sendo falado. E quanto mais repetidores o sinal passava pior ficava.
O segundo problema era a quantidade de pares metlicos necessrios entre as diversas centrais
telefnicas para possibilitar as comunicaes, o que tornava o sistema difcil de administrar e muito
caro. Veja a figura abaixo.
Com o desenvolvimento da eletrnica e da era digital nasce uma necessidade de criar uma maneira
mais eficiente de promover a interligao entre as diversas centrais telefnicas e at das prprias
centrais telefnicas, isso vai ser o que vamos estudar nos prximos captulos, a transio do analgico
para o digital com o nascimento do TDM (time division multiplexing multiplexao no domnio do
tempo) e das comunicaes digitais. O futuro agora no mais analgico e sim binrio (zeros e uns).
Comunicaes Telefnicas Digitais
A parte central das comunicaes digitais a possibilidade de converter a voz em um sinal eltrico e
por sua vez representar esse sinal eltrico em uma sequncia de bits zeros e uns. Essa digitalizao
a converso de nveis eltricos em um conjunto de smbolos digitais, o que dado o nome de
digitalizao da voz. Portanto adigitalizao da voz nada mais que converter esse sinal eltrico em
uma sequncia de nmeros em binrio. Veja a figura abaixo:
Do outro lado da linha essa sequncia de bits pode mais uma vez ser decodificada e gerar o sinal
eltrico, que por sua vez ser convertido na voz de quem estava falando.
Dessa maneira um sinal digital pode ser enviado por quilmetros sem sofrer o problema da
degradao que o sinal analgico sofria, pois podemos, por exemplo, transmitir esse sinal atravs de
uma fibra ptica e cruzar oceanos sem os mesmo problemas descritos de degradao da qualidade
que um sinal analgico poderia sofrer.
Agora uma pergunta fica no ar: como se d esse processo de transformao de analgico para
digital?.
Tudo nasce mais ou menos em 1920 quando a Bell Systems Corporation buscava uma maneira para
reduzir a quantidade de fios entre as centrais de comunicao e iniciou os estudos para criar uma
forma mais eficiente de transmitir o sinal de voz. Foi quando um cientista chamado Dr. Harry
Nyquist (entre outros) criou um teorema que deu incio a era das comunicaes digitais. Esse teorema
conhecido como teorema da amostragem de Nyquist e diz que para transformar um sinal eltrico
em digital voc no precisa de todo o sinal, mas pode tirar amostras dele, ou seja, no precisa
reproduzir a onda eltrica inteira, apenas pedaos dela, com uma frequncia duas vezes maior que a
frequncia do sinal. Acompanhe na figura abaixo:
Aliado a esse fato, temos que a voz humana varia de 200 a 9.000 Hz e nossos ouvidos conseguem
ouvir de 20 a 20.000 Hz. Porm com os estudos realizados chegou-se a concluso que um telefone
analgico transmitia frequncias de 300 a 3.400Hz, portanto ao invs de utilizar o limite da voz
humana poderia ser utilizado o limite de 3.400Hz que o que o telefone analgico consegue
reproduzir, com isso chega-se a uma frequncia limite de 4.000Hz, que acaba pegando os 3.400Hz
que abrange a frequncia do telefone.
Como a frequncia de amostragem tem que ser duas vezes maior que a original ficou padronizada a
amostragem da voz saindo de um telefone de 8.000Hz (2 vezes 4.000Hz), ou seja, vamos ter 8000
amostras por segundo. Acompanhe nas figuras 1 e 2 abaixo:
Figura 1
Figura 2
Portanto, ao invs de termos um sinal completo, o sinal eltrico da voz que transmitido em um
sistema digital composto por vrios pedaos do sinal original e cada um tem 125 micro
segundos entre um e o outro (1/8000Hz). Esses pedaos do sinal analgicos so as amostras, tambm
chamadas de pulsos ou sinal PAM. O PAM (Pulse Amplitude Modulation Modulao por Amplitude
do Pulso) a amostra do sinal analgico que ser transformada em uma palavra digital.
Porm esse processo de digitalizao no feito de uma maneira linear, ou seja, existe uma escala
bem definida para converter esse sinal eltrico em digital onde o espao entre cada amostra no
igual, por isso chamado no linear. Esse processo chamado de quantizao, pois definida uma
escala que tem uma variao maior quanto menor o valor do sinal, pois a onde a variao da voz
pode ser maior. Essa escala composta por valores positivos e negativos.
Portanto, antes de transformar o sinal analgico em digital temos que pegar as amostras e padronizalas utilizando uma escala composta por diversos intervalos. Nessa etapa da codificao, a cada
intervalo de quantizao desses, ser atribuda uma palavra digital diferente. Veja um exemplo de
escala na figura abaixo:
A escala real representada com 8 bits, sendo que o primeiro bit diz se o sinal positivo ou negativo
e os demais 7 bits so utilizados para definir valores na escala de quantizao. Portanto temos na
escala real 128 segmentos positivos e 128 segmentos positivos, de 0 a 127 ou 0 a -127, veja a figura
abaixo:
Na prtica essa escala dividida em oito segmentos com dezesseis posies cada um, isso tanto para
valores positivos como negativos, o que em binrio temos o mostrado na figura abaixo.
Dessa forma, seguindo essas tabelas o codificador consegue gerar as palavras digitais que sero
transmitidas. Esse sinal digitalizado chamado de sinal PCM ou Pulse Code Modulation (modulao
por codificao de pulsos). Acompanhe na figura abaixo:
Se voc for bem criterioso notar que na hora que o sinal analgico convertido para digital haver
uma aproximao em muitas vezes, pois os intervalos tm valores fixos e o sinal analgico ter que
ser aproximado para um valor padro que est definido na curva de quantizao. Essa pequena
diferena chamada de erro de quantizao, porm ele irrelevante na comunicao por telefone.
Do outro lado esses cdigos binrios sero recebidos pela central telefnica, depois convertidos em
um nvel de voltagem e o sinal original remontado.
Ento, resumindo o processo de digitalizao, o sinal amostrado 8000 vezes por segundo e cada
amostra convertida em um valor binrio de 8 bits ou um octeto. Se fizermos uma conta simples,
onde temos 8 bits a cada 125 micro segundo (0,000125 segundos) e quisermos saber quantos bits so
transmitidos em um segundo, basta dividir 8 por ,000125 segundos, onde temos 64.000 bits sendo
enviados por segundo, sendo essa a velocidade ou largura de banda que esse sinal digitalizado
utilizando o PCM necessita para ser transmitido. Esse sinal chamado deG.711 e a melhor
qualidade utilizada em uma transmisso digital.
Outra maneira de chegar na velocidade de 64000 bits por segundo ou 64kbps que temos 8 bits
sendo transmitidos 8 mil vezes por segundo, ou seja, 8x8000 por segundo igual a 64000 bits por
segundo.
Esse mtodo de codificao descrito acima segue um padro internacional chamado Lei-A (a-Law), o
qual utilizado no Brasil e Europa. Nos Estados Unidos o padro utilizado a lei (-law).
Os elementos responsveis pela digitalizao da voz como, por exemplo, o G.711 so chamados
de CODECs (codificador/decodificador). O G.711 no utiliza nenhuma tcnica de compresso. Outros
codificadores ou CODECs mais avanados utilizam tcnicas de compresso para diminuir essa
necessidade de largura de banda e otimizar a transmisso da voz dentro das redes, principalmente em
uma WAN, onde a velocidade dos links mais baixa.
Por exemplo, o G.729 um algoritmo de compresso de udio para voz que compacta o udio de voz
em pedaos de 10 milisegundos. Codecs avanados, tais como G.729, permitem comprimir o nmero
de amostras enviadas e economizar largura de banda na transmisso. Isto possvel porque a
amostragem da voz humana sendo realizada 8.000 vezes por segundo produz muitas amostras que
so semelhantes ou idnticas. Por exemplo, ao falarmos a palavra "Tchau" em voz alta demoramos
cerca de um segundo para finalizar a palavra. Agora, ao ouvirmos os sons emitidos podemos perceber
um "Tch" do som que comea a palavra, ento temos o som do "aaa" no meio, seguido pelo som do
"u" no final. Se voc fosse quebrar isso em 8.000 amostras individuais as chances de que maioria
delas sejam iguais ou muito semelhantes muito grande. Ou seja, ns teramos vrios pedacinhos
de amostras de sinais que teriam quase o mesmo som, por exemplo, vrios pedaos do som tch,
seguido de vrios pedaos do som aaa e mais outros tantos pedaos do som u.
O processo de compresso utilizado pelo G.729, assim como muitos outros CODECs, utilizado enviar
uma amostra de som uma vez e simplesmente dizer para o dispositivo remoto continuar a enviar o
mesmo som por um determinado intervalo de tempo. Isso muitas vezes descrito como "a
construo de um codebook" da voz humana que viaja entre os dois pontos. Usando este processo
o G.729 capaz de reduzir a largura de banda para at 8 kbps por chamada, uma reduo bastante
grande na largura de banda em comparao com o G.711.
Essa amostragem, erros na quantizao, utilizao de codebooks (livros de cdigos) e demais tcnicas
para reduzir a largura de banda acabam por reduzir a qualidade do sinal final que est sendo
escutado pelo outro lado em uma conversa telefnica. A medida dessa qualidade chamada
de MOS ou Mean Opinion Score, realizada atravs de uma pesquisa onde o ouvinte escuta uma
frase pr-definida falada atravs dos diversos tipos de CODECs existentes e d uma nota para clareza
dessa frase. A tabela abixo representa o MOS das principais tecnologias atuais e importante
sabermos essa tabela para o CCNA Voice.
Conexes Digitais
Conforme estudamos no tpico anterior, as diversas comunicaes de voz sero convertidas para
digital resolvendo o problema da degradao da comunicao longa distncia. Porm, e o problema
da quantidade de pares metlicos entre as centrais telefnicas?
Como estamos trabalhando com amostras e no com o sinal inteiro h um espao entre essas
amostras, que de 125 micro segundos, conforme j citamos anteriormente. Portanto, podemos
utilizar este espao entre as amostras para colocar outras amostras intercaladas, processo que
chamado de Multiplexao no Domnio do Tempo ou em ingls Time Division Multiplexing ou
simplesmente TDM.
Acompanhe na figura 1 onde fizemos um exemplo com os pulsos analgicos intercalados, porm na
prtica teremos os bits de cada canal de voz intercalado, conforme figura 2, onde os diversos canais
de voz so convertidos para digital com a tecnologia PCM e depois intercalados (multiplexados)
utilizando a tecnologia TDM.
Figura 1
Figura 2
Cada intervalo de tempo utilizado para transmitir a informao de uma ligao chamado de canal
ou time slot, em portugus espao de tempo. No exemplo acima temos 32 time slots, de 0 a 31.
Essa a tecnologia chamada PCM30, ou seja, voc tem 30 canais de voz PCM em um nico link.
Diminui ou no a quantidade de cabos entre duas centrais?
Lembre que dentro de cada time slot est sendo transmitido um valor em binrio que significa uma
amplitude, a qual ser novamente convertida em analgico do outro lado na recepo.
Alm disso, cada time slot pode ser chamado de DS0 ou digital signal 0, em portugus sinal digital
zero. Nos Estados Unidos, Japo e Canad esses sinais so agregados ou intercalados em um sinal
chamado T1 utilizando 24 DS0, ou seja, 24 canais PCM dentro de um nico link. Esse sinal tambm
chamado de PCM24. J nos outros pases a tecnologia utilizada o PCM30, tambm conhecido como
sinal E1, o qual contm 30 DS0 para comunicao de voz.
Portanto as empresas nos EUA, Canad e Japo podem adquirir em um circuito apenas um total de 24
canais de voz chamado T1, enquanto no restante do mundo 30 canais em um circuito chamado E1. O
canal T1 tem uma largura de banda de 1500kbps (1,5Mbps) e j o E1 tem uma largura de banda de
2.048kbps (2Mbps).
Porm falta algo ainda, e a sinalizao? Falamos em converso da voz, mas e como os circuitos digitais
avisam para o outro lado que um telefone ficou no gancho ou fora do gancho, por exemplo? Isso
realizado por um tipo especial de sinalizao que pode ser dividida em duas categorias:
Sinalizao por Canal Associado ou Channel associated signaling (CAS): A sinalizao ser
transmitida utilizando a mesma banda que os canais de voz.
Sinalizao por Canal Comum ou Common channel signaling (CCS): A sinalizao transmitida
em um canal dedicado.
Portanto, esses links agredados chamados T1 e E1 alm de transmitir a voz tero que enviar a
sinalizao ligada a cada canal de voz!
Conexes Digitais CAS versus CCS
A maneira que a sinalizao por canal associado ou CAS trabalha para um circuito T1 utiliza um bit
que seria utilizado para a voz para representar a sinalizao. Esse processo conhecido por robbed
bit signaling (RBS sinalizao por bit roubado). Como um dos bits que seria utilizado para
converso da voz para digital roubado para sinalizao a qualidade da voz cai um pouco, porm
no significativa essa perda de qualidade considerando o todo, por isso acaba sendo imperceptvel
para quem est ouvindo a voz aps a converso de digital para analgico.
Note que nos cinco primeiros quadros o sinal de voz transmitido por completo e apenas no sexto
quadro que um bit de cada canal emprestado para sinalizao. Cada canal transmite a informao
sobre a sinalizao dele mesmo. Portanto a sinalizao ser transmitida no sexto quadro, depois
dcimo segundo quadro, dcimo oitavo quadro, e assim por diante.
O bit roubado o oitavo bit de cada canal, ou seja, o bit menos significativo fato esse que justifica o
que foi dito acima que a perda na qualidade da voz imperceptvel.
Obs: Lembre que apesar de utilizarmos o E1 no Brasil muito importante entender o T1 para a prova
do CCNA Voice devido a Cisco ser uma empresa Americana!
O quadro T1 formado por 193 bits. Perceba, na figura abaixo, que temos 24 canais com 8 bits, o
que daria 8 x 24 = 192 bits.
No entanto em cada quadro adicionado um bit para fornecer o sincronismo do quadro. Dessa forma
o nmero total de bits de um quadro T1 fica sendo (8x24)+1 = 193 bits. Acompanhe na figura de
exemplo um esquema de um quadro T1, considerando que estamos visualizando um quadro onde o
ltimo bit de cada canal foi roubado para sinalizao do canal (ou seja, estamos vendo um quadro
mltiplo de 6).
Bc = bit de controle ou sinalizao
Bs = bit de sincronismo
O bit 193 de quadro pode, por exemplo, ser alternado em 0 e 1 (010101010) de forma que o
multiplexador na outra ponta da comunicao ser capaz de identificar a informao de sincronismo e
assim conseguir separar um quadro do outro.
J o CAS do E1 transmitido no time slot 16, sem a necessidade de roubar ou emprestar bits dos
canais de voz digitalizados. No sinal E1 o time-slot 0 (zero) utilizado para a palavra de alinhamento
de quadro (PAQ) e para a palavra de servio (PS). A PAQ e a PS so inseridas no quadro de pulsos de
maneira alternada, ou seja, em um quadro colocada a PAQ e no prximo a PS. O time-slot 16
(dezesseis) preenchido com a sinalizao e os time slots de 1 a 15 e 17 a 31 so utilizados para
transmitir a voz.
No E1 so transmitidas as sinalizaes de dois canais por quadro, sendo que a cada 15 quadros toda a
sinalizao transmitida. Essa sinalizao consiste basicamente dos bits ABCD, presentes no timeslot
16 (CAS) do tronco E1, que representam os estados da linha. So similares aos estados de uma linha
analgica. Cada bit tem um significado, mas na prtica os bits C e D raramente so utilizados e por
isso so mantidos constantes, geralmente com os valores 0 e 1.
No Brasil podemos utilizar o CAS ou uma sinalizao chamada R2 Digital, a qual veremos mais sobre
ela quando falarmos das interfaces E1 em captulo posterior nesse curso.
Por padro o quadro E1 possui 256 bits. Veja abaixo um diagrama do quadro E1 abaixo.
Perceba que no quadro E1 o primeiro timeslot (timeslot 0) utilizado para o sincronismo (PAQ
palavra de alinhamento de quadro). J o dcimo stimo timeslot (timeslot 16) utilizado para passar
a sinalizao.
J na sinalizao por canal comum ou CCS um time slot agora inteiramente destinado
sinalizao e ela passa a ser desvinculada da voz, sendo transmitida a 64kpbs. A sinalizao por canal
comum tambm chamada de out-of-band ou fora da banda, pois ela est desvinculada da
banda de voz. J o CAS chamado de in-band, ou seja, transmitido junto com a banda de voz.
Se considerarmos um link T1 com 24 time slots, com o CCS ele perde o ltimo time slot (24) para a
sinalizao podendo transportar apenas 23 canais de voz (do 1 ao 23). Isso no acontece no caso do
E1 que mesmo com o CAS j possui um canal dedicado para sinalizao (o time slot 17 na contagem
americana ou 16 na contagem brasileira). Note que agora o T1 com CCS no precisa mais roubar bits
para a sinalizao dos canais de voz, pois ele tem um circuito dedicado para esse fim.
Alm do que vimos vale lembrar que agora o canal de sinalizao precisar de um protocolo que trate
de todas as questes referentes sinalizao. Um dos protocolos mais comuns para o CCS o Q.931,
o qual utilizado para sinalizao de canais ISDN (Rede Digital de Circuitos Integrados).
A sinalizao por canal comum adotada para comunicao entre as centrais telefnicas ao redor do
mundo, pois possibilita mais flexibilidade, velocidade e segurana por estar em um canal separado e
com um protocolo especfico para trocar as mensagens de sinalizao. Porm existem outros
protocolos alm do ISDN para o CCS, um deles o SS7 ou Signaling System 7 (sistema de sinalizao
7), o qual utilizado para fazer a comunicao entre centrais telefnicas de grande porte.
Entendendo a PSTN Rede Pblica de Telefonia Comutada ou RPTC
A rede pblica de telefonia comutada ou RPTC (do ingls Public Switched Telephone
Network ou PSTN) o termo usado para identificar a rede telefnica mundial comutada por circuitos
destinada ao servio telefnico, sendo administrada pelas operadoras de servio telefnico.
Inicialmente foi projetada como uma rede de linhas fixas e analgicas, porm atualmente digital e
inclui tambm dispositivos mveis como os telefones celulares.
Todos os circuitos digitais discutidos nos tpicos anteriores so utilizados nessa rede pblica para
permitir a comunicao em massa que vivemos desde o incio da era das Telecomunicaes.
A rede pblica de telefonia est para a comutao por circuitos como a Internet est para o IP e
a comutao por pacotes. O uso de comutao por circuitos prov a qualidade de servio necessria
para transmisso de voz, pois o circuito reservado durante toda a ligao, mesmo havendo silncio,
e liberado apenas quando a chamada desligada. Esta rede d suporte restrito para comunicao
de dados.
A rede de telefonia pblica comutada existe desde o comeo do sculo XX. Um sistema de telefonia
fixa constitudo por centrais de comutao telefnica, terminais de servio telefnico, rede de cabos
de interligao entre os assinantes do servio de telefonia pblica e a central pblica de comutao
telefnica e por entroncamentos de transmisso entre as vrias centrais telefnicas.
Os padres da rede pblica de telefonia so ditados em sua maior parte pelo ITU-T seguindo o padro
de endereamento E.163/E.164 conhecidos popularmente como os nmeros dos telefones.
Componentes da Rede Pblica - PSTN
No incio da telefonia analgica se voc desejava ter contato com vrias pessoas seria necessrio ter
vrios telefones, um ligado com cada pessoa que voc desejava manter contato. Tambm seria
necessrio ter uma linha conectada a cada uma dessas casas. O conceito da PSTN que voc precisa
se conectar apenas a um ponto central, os quais so vrios espalhados pelas diversas cidades, e dele
suas chamadas sero encaminhadas.
Essa rede pode ser dividida de uma maneira simples conforme abaixo:
Telefones Analgicos: aparelhos conectados diretamente rede PSTN que transformam o sinal
de udio em um sinal eltrico.
Loop Local: O link entre o cliente (empresa ou pessoa fsica) e a rede pblica, conectado uma
central telefnica.
CO switch: Equipamento que prov os servios aos usurios locais, a central telefnica. Esses
servios incluem sinalizao, coleta dos dgitos discados, roteamento das chamadas, setup
(inicializao da chamada e ocupao de um circuito) e teardown (finalizao da chamada e
liberao do circuito).
Trunk ou Tronco: Fornece conectividade entre as Centrais que podem ser pblicas ou privadas
(PBX ou PABX). Esse entroncamento pode ser feito com circuitos analgicos ou digitais atravs
de links E1 ou T1.
Switch Privativo (PBX ou PABX): Trata-se de uma mini central telefnica que pertence a uma
determinada empresa ou corporao. Ela permite maior flexibilidade s empresas e controle
sobre os diversos telefones, permitindo economizar na hora de contratar linhas telefnicas da
prestadora de servios.
Telefone Digital: Telefone conectado ao PABX que na linha troca zeros e uns ao invs de um
sinal analgico, permitindo uma gama maior de facilidades e servios ao usurio final.
Fala-se muito em que chegar um dia que a PSTN ser absorvida pela Internet, porm primeiro o
problema da qualidade de servios (QoS) na Internet ter que ser resolvido.
Entendendo as Centrais Privativas (PABX e Key System KS)

Um PBX (sigla em ingls de Private Branch Exchange ou ainda PABX para Private Automatic Branch
Exchange, cuja traduo seria troca automtica de ramais privados) uma central telefnica
pertencente a uma empresa que no inclua como sua atividade o fornecimento de servios
telefnicos ao pblico em geral.
Atualmente o termo PBX no Brasil denomina os sistemas manuais obsoletos (necessitam um operador
ou telefonista), tendo sido substitudos por sistemas automticos conhecidos como PABX ou PPCA.
Porm no material oficial da Cisco o termo PBX utilizado para representar uma central telefnica
privada.
Um PABX permite efetuar ligaes entre telefones internos sem interveno manual, ou seja, com
encaminhamento automtico entre os ramais, ou ainda telefonar e receber telefonemas da rede
externa (geralmente pblica - PSTN). So construdas de uma plataforma de hardware e software
atravs de placas de circuito impresso.
Um telefone domstico geralmente est conectado diretamente operadora local de telefonia,
podendo realizar chamadas discando o nmero de destino desejado, porm em um ambiente
corporativo (dentro das empresas) normalmente existem muito mais ramais do que linhas
telefnicas, principalmente devido ao custo, havendo a necessidade de um ponto central para
gerenciar e distribuir as chamadas. Essa a funo realizada pelo PABX. O equipamento torna-se
tambm um ponto de controle dos usurios de ramais, podendo gerenciar permisses de uso
individuais ou por grupo.
Para concluir, temos que afirmar que PABX uma central telefnica onde chegam as linhas da rede
pblica e saem os ramais para os usurios. Nesta central tambm podem ser conectados outros
dispositivos, tais como interfones para tocar direto no telefone e muitas outras funes.
Quando voc analisa de perto um PBX ele parece uma caixa com diversas placas inseridas, as quais
podem ser divididas nas seguintes partes integrantes. Acompanhe nas figuras 1 e 2 abaixo:
Figura 1
Figura 2
Line cards ou Cartes/Interfaces de Linha: Fornece o ponto de conexo entre os telefones dos
usurios finais e o PBX.
Trunk cards ou Cartes/Interfaces de Tronco: So responsveis pela conexo entre outros PBX
ou com a central pblica PSTN. Podem ser tanto analgicos como digitais (E1 ou T1).
Control complex ou Controladora: a parte inteligente do PBX, uma placa que processa as
informaes e fornece o gerenciamento do sistema. Podemos dizer que nela onde est a
CPU do PBX.
J os Key Systems ou simplesmente KS so aplicados em ambientes de pequenas empresas, com

normalmente menos de 50 usurios. Com o avano da tecnologia a diferena entre os KSs e PBXs
comeou a diminuir, porm os KSs normalmente tm menos recursos e voc tem mais uma sensao
de que tem uma "linha compartilhada" do que uma central propriamente dita. Por exemplo, voc
pode ter um KS instalado em um escritrio de pequeno porte onde todos os usurios tm quatro
linhas atribudas ao seu telefone. Se um dos usurios fosse usar a linha 1, essa linha apareceria
ocupada para todos os usurios no escritrio.
Apesar do PABX ser um equipamento nico na rede e voc pensar que ele pode ser um ponto nico
de falha, ou seja, se pifar todo o meu servio de telefonia cai, o Uptime (tempo sem quedas)
desses equipamentos pode chegar a 99.9999% e seu tempo de vida entre 7 e 10 anos, o que garante a
confiana que esses equipamentos conquistaram ao longo dos anos difcil de serem batidas.
Conexes com a Rede Pblica - PSTN

Como escolher o melhor meio para se conectar com a rede pblica de telefonia? Tudo depende do
volume de ligaes que a empresa tem, o qual est ligado com o tipo de negcio e nmero de
funcionrios de cada corporao.
Por exemplo, para um usurio residencial uma linha em sua maioria das vezes o suficiente. J em
um pequeno escritrio pode no ser o bastante, pois tudo depende de quantas pessoas trabalham l
e o nmero de ligaes que so realizadas. Tomando o que foi dito por base, quanto maior a empresa,
mais ligaes sero necessrias e quantas linhas ou que tipo de linha ser necessrio contratar da
operadora vai depender do volume de ligaes.
Em organizaes maiores podem ser contratados circuitos E1 ou T1, os quais transportam diversos
canais de maneira digital, diminuindo a quantidade de fios que o PABX vai receber.
Portanto, podemos ter uma ou vrias linhas analgicas ou ento uma ou vrias linhas digitais com
uma central pblica, tudo depende do porte de cada empresa.
A rede pblica de telefonia ou PSTN como a Internet, so diversas centrais telefnicas se
comunicando entre si atravs de um protocolo de sinalizao chamado SS7, o qual citamos nos
tpicos anteriores.
O sistema de sinalizao nmero 7, o qual um tipo de sinalizao por canal comum (CCS), foi
desenvolvido especialmente para funcionar em centrais digitais de comutao (central telefnica),
com o objetivo de extrair maiores vantagens desse tipo de tecnologia. Pode-se dizer quer o Sistema
de Sinalizao Nmero 7 essencialmente uma rede de pacotes. A informao de sinalizao
carregada em pacotes de dados entre as centrais telefnicas de maneira semelhante quela usada
pelas redes de pacotes X.25 ou uma outra rede de comutao de pacotes. Essa rede de comutao de
pacotes, a rede SS7, agrega-se rede telefnica (Rede de Telecomunicaes) existente, adicionando
novas funcionalidades e servios de comunicao.
Quando um usurio faz uma chamada a central que recebe essa chamada executa uma pesquisa SS7
para localizar o nmero de destino. Uma vez que o destino encontrado, o SS7 responsvel pelo
roteamento da chamada atravs da rede de voz para o destino, fornecendo toda a sinalizao
informativa (como o ring back) para o dispositivo que originou a chamada.
Lembre que o SS7 est entre as centrais das operadoras e no entre os clientes e as operadoras.
Plano de Numerao da PSTN
O Plano de Numerao da PSTN o modo de organizao dos nmeros dos servios de
telecomunicaes de uso pblico, tanto a definio do seu formato como da sua estrutura. Esse plano
consiste em grupos de algarismos os quais contm elementos usados para identificao de servios,
reas geogrficas, redes e clientes.
Podemos comparar ao endereo IP, o qual identifica um host na Internet, a rede pblica mundial de
dados.
O padro utilizado para a numerao pblica de telefones a norma da ITU (International
Telecommunication Union) chamada E.164. Portanto, o E.164 um padro Internacional criado para
enderear telefones de uma maneira que pode ser entendido em qualquer parte do mundo e
composto por:
Cdigo do Pas (Country code)

Cdigo Nacional de Destino (National destination code)
Nmero do Assinante (Subscriber number)
Um detalhe importante que os nmeros E.164 tem um limite de 15 dgitos. Um exemplo de

numerao utilizado nos Estados Unidos o North American Numbering Plan (NANP) que utiliza o
E.164 da seguinte maneira (veja a figura abaixo):
Country code Cdigo do Pas

Area code Cdigo Nacional de Destino ou cdigo de rea
Central office ou exchange code Cdigo da central telefnica
Station code Cdigo do assinante
No Brasil temos uma estrutura parecida para nossos nmeros de telefone, onde nosso pas
identificado internacionalmente com o cdigo 55, nosso Cdigo Nacional de Destino (Area code) o
nosso DDD (veja a figura abaixo), depois temos um cdigo da central telefnica com 4 dgitos e o
nmero do assinante com 4 dgitos tambm.
Transmitindo a Voz Sobre o Protocolo IP VoIP

Nesse ponto j vimos que a tecnologia convencional para transmitir a voz dentro de uma rede pblica
o TDM (multiplexao no domnio do tempo) e que essa informao j transmitida entre as
diversas centrais telefnicas de maneira digital, ou seja, atravs de zeros e uns, ento qual a grande
diferena entre o mundo PSTN/TDM e o mundo VoIP? Os dois no so digitais?
Apesar do TDM j ser digital ele est confinado a uma rede pblica de telefonia e seria muito caro
trazer esse mundo para as empresas, j com o VoIP voc tem a possibilidade de pegar esses pacotes
de voz convertidos em binrio e passar a envi-los atravs da sua rede de dados, ou seja,utilizando a
infraestrutura j existente de dados para passar a voz tambm.
claro que o conceito simples e genial, porm como fazer isso acontecer um pouco mais
complexo, pois a rede de dados deve ser preparada para receber e tratar os pacotes de voz da
maneira correta (QoS qualidade de servio), os pacotes de voz devem ocupar uma banda que no
lote a sua rede, ou seja, utilizando CODECs corretos.
Outro ponto importante que agora a voz est passando pela sua LAN e WAN, possibilitando que os
pacotes sejam capturados, decodificados e sua conversao seja extraida ou ouvida, por isso temos
que garantir a segurana ao passar por ambientes suspeitos utilizando tcnicas de criptografia. Alm
desses fatores citados existem outros diversos que podem influenciar no uso da rede de dados para
passar voz e outros servios multimdia, porm todos esses assuntos esto distribudos entre o CCNA
de Voz e principalmente o CCNP de Voz.
As principais vantagens de implementar a voz sobre o protocolo IP so:
Reduo no custo com ligaes: Agora voc pode utilizar a sua WAN para fazer as ligaes de
longa distncia entre as diversas unidades de sua empresa, reduzindo o custo com
interurbanos e at mesmo ligaes locais.
Reduo no custo do cabeamento: A instalao com VoIP pode cortar at 50% dos custos com
cabeamento, pois o mesmo cabo que liga o computador pode ligar o telefone IP e o
computador. Isso reduz principalmente o custo em escritrios novos.
Rede de Voz Unificada: Agora a rede de voz est integrada a sua rede de dados, possibilitando
que tanto os escritrios remotos como usurios remotos compartilhem a mesma rede e o
mesmo plano de numerao, o que permite um melhor controle e gerenciamento desses
usurios e seus dispositivos.
Sem vnculo com a Central Telefnica (vnculo fsico): agora voc pode levar seu telefone com
voc para onde for, plugar em um cabo de rede que seu ramal ser o mesmo, diferente de uma
central convencional que o ponto dependente de onde est conectado central. Isso trazia
um custo elevado para as mudanas (MACD Moves Adds, Changes and Desinstallation) na
rede convencional, pois para o usurio trocar de lugar a central teria que ser reconfigurada.
Agora isso acabou, ainda mais com as VPNs e telefones via software (softphones) voc pode ter
seu ramal onde estiver. Outra vantagem a possibilidade de se logar em qualquer telefone e
ter seu ramal, o que sim possvel.
IP SoftPhones: SoftPhones so softwares que simulam um telefone em um computador, laptop ou PDA, o limite da integrao dos elementos de rede. Os SoftPhones esto se tornando
cada vez mais sofisticados e mais integrados com outras aplicaes tais como e-mail e suas
listas de contato, instant Messenger e vdeo telefonia.
Unified e-mail, voicemail e fax (Mensagens Unificadas): Todos os tipos de mensagem podem
ser enviadas aos usurios utilizando sua caixa de correio eletrnico, permitindo que os usurios
possam ter suas mensagens em apenas um lugar, podendo responder, encaminhar ou guardar
essas informaes da maneira que desejar.
Aumento na Produtividade: Os ramais VoIP podem enviar uma chamada para mltiplos
dispositivos antes de encaminhar a ligao para a caixa de mensagem, acabando com a perda
de tempo na caada por chamadas perdidas e ouvindo as mensagens de caixa postal (Phone
tag game).
Funcionalidades de Voz Avanadas (Feature-rich Communications): Agora que as redes de
dados, voz e vdeo esto integradas o usurio pode usufruir dessas tecnologias e adicionar
outras aplicaes e benefcios adicionais com esse mundo do VoIP. Por exemplo, baseado no
nmero do cliente um atendente de call center pode ter todos os dados da pessoa, caso ela
seja cadastrada, e at ter informaes sobre negociaes passadas automaticamente pelo
sistema, tudo isso gerado a partir dessa integrao da rede com o mundo VoIP.
Padres Abertos e Compatibilidade entre Diversos Fabricantes: Assim como micros de
diferentes marcas, tais como Apple, Dell e IBM podem trabalhar em uma mesma rede, voc
agora pode escolher padres abertos e fazer equipamentos de fabricantes diferentes
conversarem utilizando protocolos especficos.
Essas so as principais vantagens da implementao do VoIP e da Telefonia IP, porm existem outras
vantagens que sero descritas ao longo do curso.
Processadores Digitais de Sinal (Digital Signal Processors)
Vamos comear lembrando qual a principal funo de um roteador: rotear os pacotes IP. Parece
uma considerao um tanto bvia, porm com isso vamos lembrar que os roteadores no vm
equipados com grandes memrias como nos computadores e o recurso computacional exigido para o
roteamento j bastante alto. O que aconteceria se o roteador tivesse que processar as informaes
de voz utilizando os mesmos recursos que ele tem para fazer todos os outros processos normais?
Comparando com um computador o roteador vem em mdia com 256 Mbytes de memria RAM, o
que para o Windows utilizado somente para o processo de boot.
No mundo VoIP temos uma amostragem de 8000 vezes por segundo, ou seja, a cada 1 segundo o
roteador teria que lidar com 64000 bits, o que tornaria o processo muito complicado contando com
todas as outras tarefas que ele j possui, a onde entra o DSP ou Processador Digital de Sinais. O
DSP alivia o roteador da misso de tratar da digitalizao da voz e demais tarefas tpicas do VoIP,
aliviando o processamento como um todo. Fazendo uma analogia com o nosso computador, podemos
comparar o DSP a uma placa de vdeo com sua prpria memria que daria a capacidade de tratar
imagens mais complexas para os jogos.
Os DSPs fazem toda a amostragem, codificao e compresso do udio para o roteador. O roteador
precisa, portanto, de placas de voz, as VICs (Voice Interface Cards) e os DSPs para tratativa da voz.
Lembre a que as placas de voz conseguem conectar o roteador com a rede PSTN mas no tem a
capacidade de processar a voz.
Os DSPs so chips parecidos com uma memria e vem em diferentes capacidades que so
denominadas PVDMs (Packet Voice Digital Signal Processor Modules) e podem ser do seguinte tipo:
PVDM2-8: tem 0,5 chips DSP

PVDM2-16: tem 1 chip DSP
PVDM2-32: tem 2 chips DSP

Esses DSPs podem ser on-board, ou seja, estar j instalados direto na placa me do roteador, ou em
chips separados que necessitam ser instalados em slots especficos para eles, veja na figura 1 ao
lado exemplos de chips DSP e na figura 2 onde instalar um mdulo DSP em um roteador da srie
1700.
Figura 1
Figura 2
importante antes de instalar uma placa de voz em um roteador planejar quanto de DSP ser
necessrio para as chamadas de voz ativas, por exemplo, um E1 pode receber 30 chamadas
simultneas, quantas conferncias voc precisa ter e quanto de transcoding (transcodificao
transformar de um CODEC para outro diferente) ser necessrio.
A Cisco fornece uma calculadora de DSPs no link abaixo, porm voc precisa ser um usurio
registrado:
http://www.cisco.com/web/applicat/dsprecal/index.html
Alm de tudo isso, um CODEC pode exigir mais DSP que outro devido a sua complexidade ao fazer o
processo de digitalizao da voz, veja a tabela mostrada na figura abaixo.
Quanto mais novo o DSP mais capacidade de lidar com CODECs de alta complexidade do que os
modelos mais antigos. Os roteadores mais antigos tinham as PVDMs, depois saiu a linha PVDM-V2 e
agora estamos com a PVDM verso 3.
Os Protocolos RTP e RTCP
O RTP (do ingls Real-time Transport Protocol) um protocolo de redes utilizado em aplicaes de
tempo real, como por exemplo, pacotes de Voz sobre IP. O RTP define como deve ser feita a
fragmentao do fluxo de dados e udio, adicionando a cada fragmento informao de sequncia e
de tempo de entrega. O controle realizado pelo RTCP - Real Time Control Protocol. Ambos utilizam
o UDP como protocolo de transporte, o qual no oferece qualquer garantia que os pacotes sero
entregues num determinado intervalo. Os protocolos RTP/RTCP so definidos pela RFC 3550 do IETF
(Internet Engineering Task Force).
O RTP trabalha na camada de transporte do modelo OSI, encima do UDP, o que pode parecer
estranho mas exatamente como funciona. O UDP fornece os nmeros de porta e checksums do
cabealho e o RTP adiciona os nmeros de sequncia, time stamps (temporizao) e demais
informaes do cabealho. Isso permite ao outro lado colocar os pacotes em um buffer, acertar a
ordem dos pacotes e equalizar variaes de tempo (jitter) que eventualmente podem ter acontecido
devido transmisso atravs da rede. Veja na figura abaixo o quadro do RTP.
No campo payload type voc tem qual o tipo de RTP est sendo utilizado, se para voz ou vdeo.
Quando uma sesso de voz estabelecia o RTP negocia portas UDP entre 16.384 e 32.767 para cada
fluxo de voz, alm disso, as sesses so unidirecionais, ou seja, cada equipamento deve ter uma
sesso de RTP em direo ao outro. Portanto para ter uma comunicao bidirecional voc ter dois
fluxos RTP. Outro aspecto importante que as portas permanecem a mesma at o final da sesso,
no sendo alteradas dinamicamente entre os dispositivos.
Essa informao importante para a configurao dos firewalls da sua empresa quando implantando
um servio VoIP utilizando equipamentos Cisco.
Uma vez estabelecida a sesso RTP o RTCP tambm ir abrir uma sesso utilizando portas mpares,
um nmero acima da utilizada pelo RTP. Por exemplo, quando o RTP utilizar a porta 16.654, o RTCP
utilizar a porta 16.655. A principal funo do RCTP fornecer estatsticas da conexo para fins de
controle e gerenciamento, tais como:
Contagem de pacotes
Delay ou atraso entre os pacotes
Perda de pacotes (Packet loss)
Jitter (variaes no delay)
Lembre que o RTCP no to crtico como o RTP para a transmisso dos pacotes de voz e isso deve
ser levado em conta na hora de configurar o QoS. Alm disso, durante uma ligao o RTCP enviado
em mdia a cada 5 segundos de conversao.
Utilizando o Cisco Unified Communication Manager Express (CME) voc pode utilizar essas
informaes para ter um registro e reportes sobre problemas que podem afetar sua comunicao,
tais como problemas na qualidade do udio ou ligaes interrompidas, que podem ter sido causadas
pela rede.
Conceito de Comunicaes Unificadas
Comunicaes Unificadas um processo no qual todos os meios e dispositivos de comunicao e
mdia esto integrados permitindo que os usurios se comuniquem em tempo real com qualquer
pessoa em qualquer lugar.
Esta tecnologia mais conhecida pelo seu nome em Ingls Unified Communications (UC) devido ao
pioneirismo no desenvolvimento e uso. As UC surgiram espontaneamente, assim como a evoluo de
qualquer tecnologia, como pode ser identificado no prprio nome, o intuito principal da tecnologia
unificar os meios atuais de comunicao, vdeo conferncia, colaborao, computao em nuvem,
telefonia, etc.
O objetivo das UC aprimorar os procedimentos de negcios e alavancar as comunicaes humanas
com a simplificao do processo.
Apenas olhando atravs da linha de produtos da Cisco para VoIP, parece que ela est tentando dizer
alguma coisa com o tema "unificado" (com "colaborao" chegando em segundo lugar e bem perto),
e se voc se aprofundar vai descobrir que existe muito mais no "unificado" que apenas VoIP. Este
tpico atravessa fronteiras e rene toda a comunicao em um nico cenrio.
A estratgia de UC da Cisco abrange todos os tipos de comunicao eletrnica: voz, vdeo e dados.
No entanto, a maioria dos engenheiros que ouvem a frase "Unified Communications" lembram
imediatamente da linha de produtos VoIP da Cisco, principal motivo de voc estar aqui para aprender.
Os produtos Cisco Unified Communications se dividem em quatro solues principais:
Cisco Unified Communications Manager Express CME

Cisco Unified Communications Manager - CUCM
Cisco Unity Connection
Cisco Unified Presence
Lembre que os produtos acima so a parte central da soluo (core), porm voc pode adicionar
outros produtos e aplicaes para aumentar as facilidades da sua oferta de servios de UC para seus
usurios. Por exemplo, com o Cisco Unified Contact Center voc pode implementar um call-center,
com facilidades como roteamento de chamadas baseado nas habilidades dos atendentes, fila de
espera, monitoramento ao vivo de conversas, e assim por diante. Com o Cisco Unified Meeting
Place voc pode implementar capacidades de conferncias de voz avanadas, com agendamento de
salas de conferncias, colaborao de documentos e plataformas de treinamento.
Lembre que o CCNA de Voz tem o objetivo de dar a base para entender e torn-lo proficiente para
trabalhar no dia a dia de uma empresa que tem o sistema de UC da Cisco implementado, porm
proficiente no expert. Para tornar-se expert o CCNP ser necessrio, mas no sem antes
passar pelo CCNA!
Antigamente o Cisco Unified Communications Manager (CUCM) e o Cisco Unified Communications Manager Express
(CME) costumavam ser chamados de Cisco CallManager (CCM) e Cisco CallManager Express (CME), por esse motivo
voc ainda pode ouvir essa nomenclatura e no se assuste, pois nem todos sabem que essas linhas de solues foram
renomeadas.
Cisco Unified Communications Manager Express

Durante o CCNA estudamos que o roteador tem sua funo principal de rotear os pacotes IP, porm
ele pode tambm ser utilizado como servidor DHCP, fazer tradues de endereo com o NAT e PAT,
fazer filtro de pacotes com as ACLs, rotear pacotes IP verso 6, servir como um firewall e IPS para
aumentar a segurana das redes e muito mais. Alm disso, tudo que foi listado os roteadores da Cisco
tambm podem ser utilizados para fazer telefonia IP utilizando o Cisco Unified Communications
Manager Express ou simplesmente CME.
Os roteadores da famlia Cisco Integrated Service Router (ISR) podem conectar linhas analgicas (FXS,
FXO e E&M) e circuitos digitais (T1, E1 e ISDN), assim como permitem que dispositivos VoIP, tais como
telefones IP, se registrem nele suportando desde de facilidades bsicas at avanadas como
conferncias, vdeo-telefonia e automatic call distribution (ACD distribuio automtica de
chamadas). Dependendo do roteador utilizado ele pode suportar at 450 telefones IP (fsicos ou
softphones), o que uma excelente soluo para mdias empresas.
O Cisco CME est integrado ao software IOS que possui a feature set (lista de facilidades e
tecnologias suportadas pelo IOS) apropriada. Com o IOS verso 15 necessrio uma chave chamada
Product Authorization Key (PAK) para ativar o CME no roteador.
A verso atual do Cisco CME a 8.X e foi projetada para os roteadores ISR de segunda gerao (G2),
porm com o IOS correto voc pode rodar essa verso na linha anterior de ISR (tais como a srie
1800, 2800 e 3800). Na figura abaixo voc tem a lista de equipamentos ISR gerao 2 que suportam o
CME e suas capacidades de ramais por equipamento.
Na figura abaixo mostrada a lista de capacidades da famlia ISR gerao 1.
Lembre que essas informaes foram tiradas no incio de 2012 e podem variar de acordo com as
melhorias e upgrades que o IOS sofre ao longo do tempo. No link abaixo voc encontra as diversas
verses de CME e que equipamentos so suportados.
Um detalhe importante que nessa matriz, clicando na verso de CME voc consegue ver os
endpoints (aparelhos como telefones IP) suportados pela verso, nem todos os aparelhos so
suportados quando novas verses saem, principalmente telefones mais antigos. Por exemplo, o CME
8.x no suporta mais o telefone do modelo 7911 e sim o 7911G.
Principais Facilidades do CME
A principal vantagem do CME que por ele estar dentro do prprio roteador o equipamento acaba
sendo um ponto nico de contato, tanto para os telefones IP como para interao com a PSTN,
podemos dizer que ele um all-in-one equipment ou um faz tudo em portugus.
Abaixo listamos as principais facilidades e recursos que o CME traz.
Vantagens CME
Processamento de Chamadas (Call processing) e Controle de Dispositivos (device control): O

roteador com CME ser capaz de tratar da sinalizao para os telefones IP e demais endpoints,
roteamento das chamadas (call routing) e demais facilidades relativas s chamadas telefnicas.
Configurao por Linha de Comando (CLI) ou Interface Grfica (GUI-based
configuration):Como o CME est integrado ao IOS voc pode configur-lo via CLI ou atravs de
uma interface Web, como por exemplo utilizando o Cisco Configuration Professional (CCP).
Servio de Diretrios Local (Local directory servisse): O roteador CME pode manter um banco
de dados local para autenticar os usurios na rede de telefonia IP.
Suporte a CTI (Computer Telephony Integration):O CTI permite integrar a rede de telefonia IP
(IPT) com aplicaes que esto rodando na rede de dados. Por exemplo, voc pode utilizar o
Cisco Unified CallConnector para fazer chamadas utilizando a lista de contatos do Microsoft
Outlook.
Entroncamento com Outras Redes e Sistemas VoIP: Apesar do CME ser concebido para
trabalhar isoladamente (stand-alone), voc pode conect-lo diretamento rede pblica ou at
com outros sistemas VoIP utilizando as interfaces apropriadas, tais como SIP Trunks (troncos
SIP). Voc poderia conectar um escritrio isolado a um sistema em cluster de servidores Cisco
Unified Communications Manager (CUCM) sem problema algum.
Integrao Direta com o Cisco Unity Express (CUE): A CUE roda em um mdulo que pode ser
instalado nos roteadores para fornecer o servio de correio de voz (voicemail) para os telefones
IP configurados via CME.
Survivable Remote Site Telephony (SRST Backup para o CUCM): Esta facilidade permite que
um roteador CME atue como backup de um CUCM, caso a rede caia os telefones se registram
no roteador CME podendo continuar a realizar ligaes com algumas limitaes, porm a
unidade continua com a telefonia ativa. Lembre-se que o nmero de telefones ativos depende
da verso de CME e do modelo do roteador.
Alm disso, aqui voc tem uma excelente oportunidade de unificao das equipes que tratam das
redes de dados e voz, pois agora tudo est em apenas um elemento que trata dessas duas
tecnologias, maximizando esforos e o trabalho da equipe de suporte como um todo.
Telefones IP e o CME
Vamos analisar nesse tpico qual a funo do CME aps um telefone IP se registrar nele (o que ser
estudado no captulo 4 do curso), assim teremos uma viso de como o CME encaminha as chamadas e
interage com os telefones IP dentro da rede. Para isso considere a figura abaixo.
importante sabermos que os endpoints, tais como os telefones IP, para o CME so como os
terminais burros para um Mainframe, eles no tem inteligncia e capacidade de tomada de deciso
por si s, o CME que dar todas as instrues necessrias para os telefones IP. Portanto ele controla
virtualmente todas as aes que sero executadas pelos telefones IP.
Portanto existir uma comunicao entre o telefone e o CME realizada por um protocolo de
controle que pode ser realizada pelos protocolos Skinny Client Control Protocol (SCCP) ou
the Session Initiation Protocol (SIP), os quais sero discutidos no captulo 4, porm de uma maneira
resumida. Ambos protocolos servem para o CME controlar e se comunicar com os telefones IP. Por
exemplo, levando em conta o cenrio da figura ao lado, quando um usurio tira o telefone do gancho,
esse telefone manda um sinal de off-hook para o CME, quando o CME recebe ele processa essa
informao e manda o telefone enviar o tom de discar para o usurio. Assim que esse usurio comea
a digitar os nmeros do telefone com quem ele quer falar, o telefone IP envia essas informaes ao
CME, o qual quando acaba de receber os nmeros e reconhece o destino, ele envia mensagens para o
telefone de destino tocar (ring). Quando a outra ponta atende o CME completa a chamada entre os
dois telefones IP e um fluxo RTP estabelecido diretamente entre os telefones, no havendo mais a
necessidade de passar pelo CME.
O CME e os telefones IP trocam sinalizao via SCCP ou SIP at o estabelecimento da chamada, aps
isso eles trocam os pacotes de voz via RTP diretamente entre eles.
Como o fluxo de voz atravs do RTP estabelecido diretamente entre os telefones IP, mesmo que o
roteador fique fora do ar eles continuaro a se comunicar, com tanto que o switch onde eles esto
conectados no caia tambm. Isso evita que o roteador acabe se tornando um gargalo para os
pacotes de voz ou interfira na comunicao entre dois telefones depois de estabelecida a chamada.
Porm, as facilidades como conferncia e transferncia dependem ainda do CME, portanto enquanto
o roteador no voltar no ser possvel fazer nenhuma tarefa mais sofisticada. importante lembrar
que se esses dois telefones que esto se comunicando desligarem, enquanto o roteador estiver com
problemas, eles no conseguiro mais fazer outra ligao at o roteador ficar on-line novamente.
O exemplo mostrado anteriormente leva em conta que no existe backup para o CME, o que
comum em pequenas organizaes.
Agora vamos para um segundo cenrio onde o telefone IP vai ligar para um nmero que pertence
PSTN, pegando uma conexo externa analgica ou digital.
Nesse segundo cenrio o roteador passa a ter um papel um pouco diferente, porm a parte inicial
permanece a mesma, ou seja, o usurio tirando o telefone do gancho at finalizar a discagem. Aps
finalizar a discagem, de acordo com o plano de discagem realizado no CME, o roteador vai verificar
que a chamada dever ser encaminhada rede pblica (PSTN) e isso ser realizado via uma conexo
ou tronco digital (E1 ou T1) ou analgico (FXO). Agora, ao invs de utilizar o SIP ou SCCP para
completar a chamada com o destino, o roteador precisar utilizar a sinalizao convencional de
acordo com o tipo de tronco que ele est conectado, por exemplo, utilizando o CAS atravs de um
tronco E1. Portanto agora o roteador CME assume a funo de gateway de voz, ou seja, vai ter que
fazer a interface entre o mundo VoIP, o qual fala via SCCP ou SIP, e o mundo PSTN atravs das
interfaces convencionais analgicas ou digitais.
Lembre o que estudamos no captulo 2 do curso que essa funo de converso do mundo VoIP para o
mundo PSTN consome um processamento extra e os mdulos DSPs atuaro como miniprocessadores para essas chamadas de voz.
Agora o roteador CME ter que tratar com duas conexes chamadas de legs ou pernas da
chamada, uma entre o telefone IP e o CME e outra entre o CME e a rede PSTN. O roteador
permanece no meio dessa comunicao tratando de forma independente cada uma delas de acordo
com a sinalizao e demais caractersticas especficas exigidas pelas diferentes tecnologias. Outra
informao importante que agora o fluxo RTP est criado entre o telefone IP e o roteador, pois o
roteador CME que est conectando o telefone com a rede PSTN, portanto nesse caso se o roteador
cair a comunicao de voz vai parar tambm.
Uma opo bastante utilizada atualmente para o entroncamento com as redes de telefonia o tronco
SIP direto atravs da Internet utilizando uma Internet Telephony Service Provider (ITSP).
Voicemail Integrao entre o CME e CUE

No captulo anterior vimos que o CME tem a capacidade de tratar as chamadas de voz entrantes
quando seus usurios esto presentes, mas e quando eles no esto? Assim como o CUCM o CME no
tem uma soluo de correio de voz (voicemail) integrada e depende de um sistema externo caso haja
necessidade desse tipo de servio aos usurios. Para resolver esse problema podemos utilizar a
CUE (Cisco Unity Express), o qual um sistema para voicemail que pode ser instalado em um
roteador com CME atravs de uma Internal Services Module (ISM mdulo de servio interno) ou
utilizando Service Module (SM mdulo de servio).
A diferena entre os dois dispositivos que o ISM instalado dentro do roteador e utiliza a memria
flash do roteador como dispositivo de armazenamento, compartilhando a flash com os demais
arquivos que o roteador possui. J um SM uma placa externa que possui seu prprio dispositivo de
armazenamento, o qual pode chegar a ser 10 vezes maior que em um ISM.
Para os roteadores ISR G2 existem ISMs e SMs especiais, os quais so uma verso melhorada dos
Advanced Integration Modules (AIM) e Network Modules (NM) das verses anteriores de roteadores.
Em termos de capacidade suportada a tabela abaixo mostra para as linhas ISR e ISR G2 quantas caixas
de correio so suportadas por equipamento, sendo que o nmero mximo de portas representa
quantos usurios podem ler ou utilizar as caixas de voz ao mesmo tempo. Para aumentar o nmero
de portas voc deve adquirir mais licenas.
Apesar de instalada em um roteador com CME a administrao do CUE independente do roteador,

pois ela roda seu prprio sistema operacional. A maioria dos administradores de rede que possuem
esse tipo de mdulo utilizam o CLI apenas para permitir o acesso Web (GUI) ao mdulo, depois disso
acessam somente via web. Os comandos do CLI do CUE so diferentes do IOS, so parecidos, mas com
uma gama de comandos prprios.
O CUE possui mais facilidades (features) que somente voicemail e pode ser um aliado poderoso a uma
empresa, possibilitando tambm os servios mostrados abaixo.
CUE - Features
Voicemail ou Correio de Voz: principal funo do CUE e dependendo da verso do CUE e suas licenas
voc pode ter um nmero de caixas de correio, conforme vimos anteriormente.
Auto-attendant: O atendimento automtico aquela voz automtica e gravada que ouvimos

quando a empresa no tem uma telefonista.
Interactive voice response (IVR): O CUE inclui um IVR bsico que permite os usurios
navegarem por um menu, fornecendo mais recursos que o auto-attendant. A ttulo de
ilustrao, um exemplo desse tipo de aplicao so aquelas opes que temos ao ligar para um
servio de bankphone (disque 1 para ver o saldo, disque 2 para pagamentos e etc).
Processamento de Fax no padro T.37 Nativo: O CME permite o uso do fax via T.37 e os
processa como arquivos TIFF, anexando-os a e-mails. O CUE permite distribuir os faxes
recebidos para as caixas de correio dos usurios.
Survivable Remote Site Voicemail (SRSV Backup para Voicemail): Permite que um mdulo
CUE atue como backup de um voicemail server primrio (porm somente quando estiver com o
Unity Connection verso completa). Esta facilidade atua integrada com o Survivable Remote
Site Telephony (SRST), que permite que um roteador CME atue como backup de um CUCM,
caso a rede caia os telefones se registram no roteador CME podendo continuar com a realizar
ligaes com algumas poucas limitaes.
Standards-based: Toda a sinalizao entre o roteador CME e o mdulo CUE utiliza o protocolo
SIP, que um mtodo aberto de sinalizao de voz.
Portanto, com o CME ativado em um roteador mais o CUE instalado podemos fornecer servio de
telefonia completo para um escritrio remoto ou uma empresa de mdio porte. Alm disso, o CME e
o CUE podem servir como mdulos de sobrevivncia (contingenciamento ou backup) do CUCM e do
Unity quando a comunicao de rede faltar em uma unidade remota.
Cisco Unified Communications Manager
Cisco Unified Communications Manager (CUCM), tambm conhecido no passado como Cisco Unified
CallManager ou Cisco CallManager (CCM), um software gestor de chamadas desenvolvido pela
Cisco Systems. O CUCM controla todos os componentes de uma rede VoIP, tais como telefones IP,
gateways, bridges de conferncia, caixas de voicemail, entre outros.
O CUCM comeou a ser desenvolvido em 1994 pela Selsius Systems sob o nome de Multimedia
Manager 1.0 e foi concebido para para ser um controlador de sinais de vdeo ponto-a-ponto. Foi
inicialmente desenvolvido para um sistema HP-UX utilizando uma linguagem de programao SDL-88,
mas foi mais tarde adaptado plataforma Windows NT 3.51.
No incio, em sua verso 2.4 voc poderia instalar o Callmanager em um lap-top com Microsoft
Windows NT 4.0 rodando o Internet Information Server (IIS) como servidor web e tudo funcionaria
perfeitamente. De l at os dias de hoje muita coisa mudou e outras verses foram lanadas, veja
uma linha do tempo abaixo:
Linha do Tempo CUCM
1994 - Multimedia Manager

1997 - Selsius-CallManager 1.0
1998 - Selsius-CallManager 2.0
2000 - Cisco CallManager 3.0
(aps a Selsius Systems ter sido adquirida em 1998 pela Cisco)

2006 - Cisco Unified CallManager 4.2

2007 - Cisco Unified Communications Manager 6.0
2010 - Cisco Unified Communications Manager 8.X
Atualmente estamos na verso 8.x do CUCM e a Cisco no recomenda a instalao em seu lap-top,
existem servidores fsicos ou virtuais certificados para esse fim.
O CUCM fornece controle dos dispositivos, roteamento de chamadas, controle de permisses,
facilidades e recursos diversos, alm de permitir a conectividade com aplicaes externas. A gama de
recursos e facilidades to grande que foram criadas duas certificaes para tratar do tema dentro
do CCNP de Voz, o CIPT1 e o CIPT2. A escala que um CUCM pode chegar muito grande e tudo isso
administrado via interface grfica (GUI) atravs de um browser.
Principais Recursos e Facilidades do CUCM
Os recursos e facilidades do CUCM so muitos, porm vamos listar abaixo os principais para a prova
do CCNA de Voz e seu dia a dia atuando na rea.
Recursos e Facilidades CUCM
Suporte completo para telefonia de voz e vdeotelefonia: O CUCM pode trabalhar tanto com
chamadas de voz como vdeo atuando em empresas de mdio at grande porte. A soluo
pode abranger projetos em escalas globais.
Appliance-based operation: As solues atuais de CUCM rodam como se fossem um appliance,
ou seja, no mais um programa e sim um sistema fechado e o sistema operacional em que ele
est rodando est enclausurado e inacessvel, dando maior segurana ao sistema como um
todo.
Redundncia atravs de clusters de servidores:Os servidores de CUCM podem ser instalados
em cluster, ou seja, um conjunto de servidores que atuam como se fossem apenas um. Os
recursos da clusterizao permitem que os servidores repliquem suas bases de dados e
informaes em tempo real (como por exemplo, as chamadas ativas). Os clusters de CUCM
podem chegar a 30.000 telefones IP (SCCP ou SIP em unsecure mode modo inseguro) ou
27.000 telefones IP (SCCP ou SIP em secure mode modo seguro).
Controle de gateways de voz e comunicao Intercluster: Apesar de um cluster de CUCM estar
limitado a 30.000 telefones IP, voc pode criar vrios clusters e interliga-los utilizando um
tronco (trunk) intercluster para que eles possam se comunicar. Alm disso, o CUCM pode
conectar gateways de voz que esto conectados a outras redes, como a PSTN, estendendo o
alcance do seu cluster.
Disaster Recovery System (DRS) Integrado: O CUCM possui o servio DRS como uma facilidade
integrada ao sistema, o que permite fazer um backup do banco de dados (e quaisquer outros
arquivos) para um servidor de rede que suporte o protocolo Secure FTP (SFTP).
Suporte a virtualizao com VMWare: O CUCM vesro 8.0 suportado em um ambiente
VMWare ESXi, o que permite a virtualizao do CUCM propiciando escalabilidade e
confiabilidade.
Integrao e/ou suporte a servios de diretrio (Directory service): Com esse recurso voc
pode integrar seus usurios do mundo VoIP com as contas de usurio j existentes na sua rede,
como por exemplo com o Microsoft Active Directory e puxar todas as informaes de contas de
usurios j existentes.
Muitas das facilidades citadas acima dependem de uma verso de CUCM que suporte a clusterizao,
porm existem verses de CUCM chamadas Business Edition (CMBE) que no suportam clusterizao
e so voltadas a empresas de menor porte.
Replicao de Base de Dados do CUCM e Interao com Telefones IP da Cisco
Vamos estudar dois importantes assuntos nesse tpico, um deles voc j estudou no tpico anterior,
pois a maneira que o CME se comunica com os telefones IP praticamente a mesma com o CUCM,
porm em uma escala que pode ser muito maior. O segundo assunto como a comunicao dos
servidores CUCM se d em cluster, assunto pelo qual vamos iniciar.
Muitas vezes quando falamos sobre comunicao de servidores em cluster a primeira imagem que
vem a mente so de vrios servidores espelhados, os quais podem assumir as funes uns dos outros
em caso de falhas. Com o CUCM no bem assim que a clusterizao funciona, pois temos que
considerar que cada servidor tem sua prpria configurao, porm trabalhando em conjunto para
fazer com que os telefones se comuniquem. Existem dois tipos de relacionamento entre os servidores
como voc pode ver no quadro abaixo:
Relacionamento entre os servidores.
Relacionamento das Bases de Dados do CUCM (Database Relationship): A base de dados do

CUCM a IBM Informix e inclui todos os dados estticos do cluster (nmero de diretrios directory numbers, planos de rota - route plan, permisses de chamada, dentre outras). Esses
dados so replicados entre todos os servidores no cluster.
CUCM Runtime Data (Dados em Tempo Real): O runtime data sincroniza tudo o que
acontece em tempo real no cluster de CUCM . Por exemplo, quando um telefone se registra em
um servidor CUCM ele comunica a todos os outros servidores que aquele telefone IP pertence
a ele. O CUCM utiliza um mtodo especialmente desenhado pela Cisco para esse tipo de
comunicao chamado Intracluster Communication Signaling (ICCS), ou seja, um protocolo para
comunicao Intracluster.
Apesar da Runtime Database ser importante as funes que ela exerce so relativamente simples.
Todos os servidores no cluster abrem sesses TCP uns com os outros utilizando o protocolo ICCS nas
portas TCP 8002 at 8004. A partir da cada evento que ocorre, como um registro de telefone ou o
incio de uma chamada ou uma desconexo de chamada, os servidores informam uns aos outros
sobre esses eventos. Para que a comunicao ICCS acontea no necessria nenhuma configurao
especial alm de adicionar os servidores aos clusters.
J o relacionamento das bases de dados do CUCM um pouco mais complexo, porm nada to
complicado assim. O banco de dados IBM Informix que o CUCM utiliza faz a replicao atravs de um
mtodo one-way, onde um servidor chamado Publisher mantm a cpia principal da base de dados
(master copy) e todas as alteraes na base de dados, com algumas pequenas excees, ocorrem no
servidor Publisher. Aps as alteraes realizadas o Publisher replica a base de dados aos demais
servidores chamados de Subscribers, conforme figura abaixo:
Nessa topologia cada cluster pode ter apenas um Publisher e at oito servidores Subscribers. Os
servidores Subscribers so responsveis por fornecer tom de discar, receber os dgitos discados,
roteamento das chamadas e pelo streaming de udio utilizado como music on hold, aquela msica
que escutamos quando estamos em espera. J o Publisher normalmente tem duas funes principais,
que so manter a base de dados e responder s requisies de TFTP. Como o Publisher mantm a
nica cpia da base de dados que pode ser escrita do CUCM, ele poupado da maioria do trabalho
mais pesado de processamento. As requisies TFTP so realizadas pelos Telefones IP durante o
processo de boot, que ser estudado no prximo captulo do curso.
Uma dica prtica que para ambientes menores de 500 telefones voc pode manter todo o
processamento de chamadas e gerenciamento do banco de dados em um nico servidor, ou seja, no
Publisher. A medida que a rede aumenta interessante separar essas funes inserindo servidores
Subscribers na rede. Assim como tambm a Cisco recomenda manter um servidor TFTP dedicado para
redes com mais de 1250 telefones.
Como j estudamos, no CUCM em cluster somente o Publisher tem o direito de escrever na base de
dados e os Subscribers no. Porm, o que ocorre se o Publisher ficar indisponvel? Por exemplo, o
servidor travou ou simplesmente parou de responder. Se o Publisher falhar, o cluster de CUCM entra
em uma espcie de modo de operao travado ou "locked configuration mode. Voc no pode mais
fazer alteraes no banco de dados (como a adio de um telefone IP novo, mudar o plano de rotas,
modificar a msica de espera, e assim por diante).
A nica exceo a isso so os recursos voltados aos usurios (user-facing features), as quais incluem
funes como o redirecionamento do telefone, habilitar a luz de mensagem em espera, pressionar o
boto de No Perturbe e outros comandos que os prprios usurios podem habilitar. Os Subscribers
no cluster de CUCM so capazes de escrever estas mudanas nas suas bases de dados locais, repliclas para os outros Subscribers no cluster e voltar para o Publisher quando a conectividade for
reestabelecida. Dessa maneira os usurios no iro perceber quando uma falha no Publisher ocorreu.
Esta capacidade surgiu no CUCM verso 5 e demais verses superiores, pois antes desta verso uma
falha no Publisher iria impactar na vida do usurio final.
Agora que entendemos como a comunicao entre os servidores do CUCM realizada, vamos estudar
como a interao com os telefones IP e demais dispositivos finais (endpoints). Veja a figura abaixo.
Assim como no CME o CUCM ser responsvel por passar todas as informaes sobre como os
dispositivos finais devem agir frente a um estmulo. A diferena agora que voc pode ter mais de
um gerenciador de chamadas por telefone, os servidores de backup, os quais podem ser primrios,
secundrios ou tercirios, ou seja, na configurao telefone IP voc pode definir um servidor para
registro principal, um secundrio e um tercirio, ou seja, uma lista de trs servidores redundantes. Se
o servidor primrio cair, o telefone utiliza o secundrio e caso ele caia o telefone se registra no
tercirio.
Como um cluster suporta at 8 servidores subscribers voc pode balancear (dividir a carga) os
telefones IP e demais dispositivos entre os servidores, melhorando assim a performance do sistema
como um todo.
Vale a pena ressaltar que o servidor primrio que o telefone IP ir se registrar nem sempre o
Publisher, na realidade em um ambiente de cluster no ser ele e sim um dos subscribers, com
exceo a ambientes de rede muito pequenos.
Cisco Unity Connection
O Cisco Unity Connection fornece mensagens instantneas integradas para ajudar os funcionrios a
controlar as mensagens com comandos de voz e, com isso, sempre atualizados a respeito de todas as
comunicaes atravs do telefone ou PC, ou ambos.
A idia central do termo Unity so mensagens, sejam elas de voz, e-mail, fax ou at mensagens
instantneas (instant Messenger), fazendo com que qualquer mensagem possa ser lida a partir de
qualquer dispositivo de voz ou outra aplicao, ou seja, no importa como voc recebeu a mensagem
voc ser capaz de recuper-la de qualquer dispositivo cliente.
Assim como o software Cisco CallManager, o Cisco Unity original rodava em um sistema operacional
Windows em conjunto com o Microsoft Exchange como servidor de e-mail para soluo de
armazenamento das mensagens. J o Cisco Unity Connection foi lanado como uma alternativa de
menor porte, utilizando o modelo de appliance semelhante ao CUCM anos aps o lanamento do
Cisco Unity original. Como o tempo e o apoio soluo, o Cisco Unity Connection cresceu tanto que
superou a plataforma original do Unity e tornou-se a soluo mais popular e escalvel para tratar das
mensagens. A tabela 1 d uma ideia de escala dos produtos Unity Connection.
Sobre o campo redundncia, veja que a CUE e o CUCM Business Edition no possuem backup. J para
o Unity a soluo de redundncia Ativo/Passivo, o que quer dizer que um servidor de backup vai
ficar parado at o principal falhar. J para o Unity Connection a redundncia ativa, ou seja, os dois
servidores esto trabalhando e quando um parar o outro assume as responsabilidades do primeiro, a
vantagem desse modelo que voc pode fazer o balanceamento de carga das caixas postais.
Alm do Cisco Unity Connection suportar mais caixas postais ele tambm tem recursos mais
avanados que as solues anteriores, tais como reconhecimento de voz e regras para transferncia
de ligaes pessoais.
Principais Recursos e Facilidades do Unity Connection

Acompanhe abaixo os principais recursos e facilidades do Cisco Unity Connection.
Recursos e Facilidades Cisco Unity Connection
Plataforma Appliance-based: O Cisco Unity Connection foi construdo com base na mesma
ideia do CUCM, ou seja, um sistema operacional appliance-based, inclusive o mesmo DVD de
instalao serve para os dois produtos.
Suporta at 20.000 mailboxes por servidor: O nmero de caixas postais pode crescer de
acordo com a necessidade da empresa, podendo ser configuradas com um ou dois servidores
para redundncia.
Acesso s mensagens de voz de qualquer lugar: O Cisco Unity Connection permite que voc
leia (recupere) suas mensagens de voz (voicemail) a partir de um telefone, e-mail, web
browser, aparelhos mveis e plataformas de instant-messenger.
Integrao com LDAP: Assim como para o CUCM voc pode utilizar o Active Directory do
Windows para autenticao dos usurios no Unity Connection, evitando criar mais bases de
dados e unificando tudo em um s local.
Suporte ao Microsoft Exchange: O Cisco Unity Connection pode interagir com um servidor
Microsoft Exchange j existente e fornecer recursos adicionais aos usurios, tais como text-tospeech permitindo voc ouvir seus e-mails pelo telefone, gerenciar o calendrio do Exchange
(aceitar, recursar e outras opes) do telefone, e muito mais.
Voice Profile for Internet Mail (VPIM): O VPIM um padro que permite servidores de
voicemail se integrem para trocar mensagens entre si (mensagens de voz ou outras
mensagens).
Redundncia Ativo/Ativo: O Cisco Unity Connection utiliza uma plataforma
Publisher/Subscriber com banco de dados IBM Informix, assim como no CUCM, entre os pares
de servidores. Ambos os servidores aceitam requisies de clientes, permitindo assim a
redundncia ativo/ativo. Normalmente o sistema permite que 250 pessoas acessem suas caixas
postais simultaneamente (250 portas), j com um par de servidores redundantes esse nmero
dobra, podendo suportar 500 portas de voicemail.
Sobre o ltimo tpico da redundncia, caso um dos servidores caia o sistema continua suportando at 20.000
caixas de correio, porm o nmero de portas (conexes simultneas) cai para 250, o valor de um servidor
somente.
Interao do Unity Connection e CUCM

importante ressaltar nesse incio que tirando o Unified CMBE (CUCM Business Edition), que j tem
o Unity Connection integrado, para todas as demais verses de CUCM o Unity Connection trabalha de
forma independente.
Na realidade o Unity Connection pode trabalhar com outras plataformas de voz que necessitam de
voicemail, inclusive com PABX. Por isso, a comunicao entre o CUCM e o Unity Connection no
automtica e requer um conjunto de configuraes especficas. Como voc j devia prever, o Unity
Connection pode se comunicar com o CUCM atravs dos protocolos de sinalizao SIP ou SCCP. Veja
na figura abaixo a topologia que utilizaremos para apresentar a interao entre o Unity Connection e
o CUCM.
Vamos utilizar ento a figura acima para explicar o funcionamento bsico entre o CUCM e o Unity
Connection, porm existe muito mais detalhes que podem ser adicionados esse cenrio. Aqui
vamos comear pelo bsico:
1. Uma chamada vinda da PSTN chega at o roteador, o qual consulta seu dial-plan (plano de
rotas) e na configurao o nmero discado est dentro da faixa configurada no servidor CUCM.
Essa chamada ento encaminhada ao CUCM.
2. O CUCM recebe a chamada e encaminha para o telefone IP correspondente ao nmero
desejado pela chamador da PSTN (utilizando SCCP ou SIP). Se o usurio do telefone IP no
responder ou desviar a chamada para o correio de voz, o CUCM encaminhar a chamada para
um ramal pr-configurado que tem conexo com o servidor do Unity Connection.
3. Portanto, o CUCM transfere mais uma vez a ligao, utilizando SIP ou SCCP, para o servidor
Unity Connection. O ramal do telefone chamado pela PSTN vem junto com as mensagens de
sinalizao enviadas pelo CUCM, o que permite o Unity Connection encaminhar a chamada
para a caixa postal correta.
Quando a pessoa que ligou via PSTN para o ramal IP finaliza sua mensagem e desliga o telefone o
Unity Connection faz uma ligao para o ramal de Message Waiting Indicator (MWI) configurado
no CUCM (via SCCP ou SIP). Nesse momento o CUCM avisa ao usurio que existe uma mensagem na
caixa postal fazendo acender o led ou luz indicativa de mensagem de voz, conforme figura abaixo.
Todas essas interaes e comunicaes entre o CUCM e o Unity Connection so feitas utilizando
as portas de voicemail, as quais dependem de licenciamento. Quanto mais portas voc tem, mais
comunicaes simultneas so suportadas, por isso importante ter o nmero correto de licenas.
Voc deve considerar os seguintes pontos para levantar o nmero de licenas de portas de voicemail:
chamadas para auto-attendant, checagem de voicemail (ouvir o correio de voz), correios de voz sendo
gravados (mensagens deixadas na caixa) e comunicaes MWI que podem acontecer
simultaneamente.
Por ltimo, o Cisco Unity Connection pode ser integrado ao CME, possibilitando que escritrios
remotos utilizem o mesmo sistema de correio de voz ou a integrao do voicemail quando existem
diversos escritrios espalhados com CME independentes.
Cisco Unified Presence
O objetivo principal do Presence similar ao status que os softwares de mensagens instantneas
fornecem sobre seus usurios (ocupado, livre, no pertube, etc), fazendo com que voc consiga saber
qual o status da pessoa que voc deseja se comunicar antes de fazer a ligao. Alm disso, o Presence
pode fornecer as funcionalidades e recursos listadas abaixo:
Recursos e Funcionalidades Cisco Presence
Mensagens Instantneas Corporativas: O Unified Presence pode incorporar o Jabber

Extensible Communication Platform (XCP), o qual um padro para comunicao entre
diferentes tipos de clientes de IM (Instant Message Mensagens Instantneas).
Message compliance (Conformidade de mensagens): Muitas empresas necessitam de uma
conformidade (seguir certos padres) para comunicao via mensagens instantneas. O Cisco
Presence permite o logging (registro ou gravao) para todos os tipos de comunicao via IM,
mesmo que utilize criptografia via Transport Layer Security (TLS).
Interdomain federation (Federao): Com essa funcionalidade voc pode conectar a soluo
de Unified Presence da Cisco com outros domnios, tais como Google Talk ou WebEx Connect,
dando maior alcance aos usurios corporativos.
Suporte a extenses Jabber XCP: O XCP permite que o Unified Presence seja extendido
virtualmente para quaisquer reas da rede de dados ou voz. Ele pode permitir facilidades como
compartilhamento de arquivos peer-to-peer, compartilhamento de aplicaes,
videoconferncias, dentre outras facilidades. O XCP pode ser integrado com quase todos os
tipos de infraestruturas, tais como directory services (AD), banco de dados e portais web.
Mensagens seguras: As aplicaes que interagem com o Unified Presence podem utilizar IPSec
ou TLS para dar mais segurana nas comunicaes atravs da criptografia.
Cisco Unified Personal Communicator

O Cisco Unified Personal Communicator uma aplicao que integra diversos servios em uma nica
plataforma de software, tais como softphone, presena, instant messaging, voicemail, diretrio de
funcionrios, histrico de conversaes, vdeo e web conferencing (conferncia via Web). A
figura abaixo mostra a tela do Cisco Unified Personal Communicator, a qual parece com um software
cliente de IM qualquer.
Como funo principal o Personal Communicator trabalha como um cliente de IM, podendo suportar
chats peer-to-peer (dois usurios), chats multiusurio (conferncias via chat) e chats permanentes
(persistent chat). Um chat permanente chamado de sala virtual, o que permite aos usurios
entrarem em chats j ocorrendo e ler o histrico de conversao. O Personal Communicator tambm
pode utilizar autenticao de usurios via LDAP para logar os usurios nos clientes de IM, ou para
fazer buscas de usurios e ainda adicionar contatos, mais uma vez permitindo uma base de usurios
nica na empresa. Com a integrao do Personal Communicator e o Cisco Unified Presence voc
pode ir alm de ver o status dos usurios que esto nos clientes de IM e visualizar o status do telefone
desses usurios (no gancho, fora do gancho, etc).
Com o Personal Communicator voc pode tambm fazer chamadas de voz e vdeo com resoluo
High Definition (HD). O Personal Communicator tambm pode agir como um softphone completo,
permitindo realizar chamadas telefnicas dentro e fora da rede VoIP da empresa. Voc pode ainda
integrar o computador com solues de conferncia multiponto da Cisco, tais como o Cisco
Unified MeetingPlace ou o Cisco Unified Video Conferencing.
Nos prximos captulos comearemos a ver como todos esses produtos funcionam na prtica e suas
configuraes bsicas.
Telefones IP Cisco
Existem diversos modelos de telefones IP que vocs podero encontrar na sua prtica do dia a dia.
Atualmente o portflio da Cisco para Telefonia IP cobre as seguintes sries mostradas abaixo:
Cisco Unified SIP Phone 3900 Series:
Oferece servios bsicos de comunicao por voz com um preo atrativo.
Cisco Unified IP Phone 6900 Series:
Possui recursos avanados de comunicao mantendo uma boa relao custo x benefcio.

Comunicao multimdia com uma ampla gama de modelos para desktop, sem fio e telefones de
conferncia.
Telefones com recursos de voz e vdeo expandindo a capacidade de colaborao no ambiente de
trabalho.
Telefones top de linha para gerentes e executivos.
Cabeamento e Alimentao do Telefone IP
Agora que j vimos alguns modelos de telefones IP vamos comear a entender como esse dispositivo
se encaixa na sua rede e tambm alguns processos e tecnologias que esto envolvidos no seu
funcionamento.
Para que voc compreenda o telefone IP como um dispositivo de rede voc deve levar em conta
alguns conceitos/tecnologias muito importantes que discutiremos ao longo desse captulo, como por
exemplo:
Power over Ethernet (PoE)

VLAN de Voz
Dynamic Host Configuration Protocol (DHCP)
No diagrama abaixo mostramos uma topologia bsica onde ilustramos o telefone IP e alguns detalhes
que discutiremos ao longo do curso.
Telefones IP Cabos e Conexes

Como voc pode verificar na topologia anterior, os telefones IP so conectados aos switches assim
como qualquer outro dispositivo que voc j est acostumado a encontrar (desktops, impressoras de
rede e etc.). Alguns modelos de telefones IP tambm possuem um switch interno, o que fornece a
possibilidade para voc conectar seu desktop diretamente no telefone IP e consequentemente
economizar portas de switch, cabeamento e conectores.
Acompanhe no diagrama abaixo, mostrado na figura abaixo, o esquema de ligao de um modelo

Cisco IP Phone 7960.
Porta RS232: utilizada para conectar mdulos de expanso, como por exemplo, 7914,7915 ou
7916.
10/100 SW: essa a porta utilizada para voc conectar o telefone IP no switch.
10/100 PC: essa a porta utilizada para voc conectar o desktop no telefone IP.
Obs: os mdulos de expanso so utilizados para fornecer recursos adicionais, muito utilizados por
telefonistas;
Importante: tome muito cuidado ao realizar a conexo dos cabos para no trocar as portas SW e PC.
Se voc conectar de forma errada o seu telefone e desktop no funcionaro. Esse um erro muito
comum em tcnicos de campo que no esto acostumados com o mundo da telefonia IP. Conferir
esse cabeamento uma boa dica de como iniciar seu troubleshooting em um telefone IP Cisco.
Alimentao em Telefones IP Cisco
Os telefones analgicos que estamos acostumados a utilizar recebem a alimentao de -48V da
Central Telefnica, mas e os telefones IP? Como os telefones IP so alimentados?
Basicamente existem 03 formas de alimentao que podemos encontrar nos telefones IP da Cisco.
Switch PoE da Cisco (padro Cisco ou 802.3af)

Patch Pannel PoE ou Power Patch Pannel (padro Cisco ou 802.3af)
Fonte de alimentao externa (para conexo com a tomada da parede)
Vamos a seguir ver um pouco sobre cada um dos tipos de alimentao, suas vantagens e
desvantagens.
Padro PoE IEEE 802.3af

Um dos principais desafios que a telefonia IP enfrentou foi com relao a alimentao dos telefones
IP. Conforme comentamos anteriormente, na telefonia tradicional os telefones recebem a
alimentao da central (pblica ou privada). Isso torna possvel que os telefones continuem
operacionais mesmo em casos de falha na rede eltrica. As primeiras geraes de telefones IP
necessitavam de uma fonte de alimentao externa, que por sua vez, deveria ser conectada a uma
fonte de energia ininterrupta de forma a garantir o funcionamento do sistema de telefonia IP nos
casos de pane no sistema eltrico.
A Cisco foi a primeira empresa a desenvolver uma alternativa vivel ao implementar uma forma de
enviar a alimentao no mesmo cabo Ethernet no ano de 2000. No incio essa tecnologia foi nomeada
como in-line power e em Junho de 2003 o comit IEEE lanou o padro 802.3af como forma de
generalizar o uso dessa tecnologia.
Atualmente os equipamentos e produtos da Cisco suportam os dois tipos de implementao
do 802.3af(utilizando os pares de dados ou pares separados). Conforme podemos observar na tabela
abaixo o primeiro modelo utiliza os mesmos pares de dados para enviar a alimentao PoE (pares
1,2,3,6) enquanto que o segundo modelo utiliza os pares no utilizados pelo Ethernet para enviar a
alimentao (pares 4,5,7,8).
Outro ponto que no podemos esquecer que recentemente o IEEE criou o padro PoE 802.3at,
chamado de PoE Plus, cujo objetivo foi aumentar a potncia utilizada de 15.4W para 25.5W.
Switch Cisco Catalyst PoE
Via de regras os switches da linha Cisco Catalyst PoE utilizam o primeiro modelo para o envio da
alimentao PoE (pares 1,2,3,6). Ao conectarmos um dispositivo em uma das portas com suporte PoE
um algoritmo de descoberta de telefones entra em cena antes do switch enviar a alimentao. Esse
algoritmo tem como funo garantir que o switch no envie a alimentao para dispositivos que no
suportam a tecnologia PoE.
Agora imagine as vantagens obtidas atravs dessa tecnologia de alimentao. Utilizamos o mesmo
cabo de rede para passar tanto os dados, quanto a alimentao necessria para manter funcionando
o telefone IP. Fica fcil perceber algumas vantagens:
Fonte de alimentao centralizada (no caso o switch PoE)

Possibilidade de alimentar dispositivos que esto distantes da tomada (cmeras de vigilncia ou
access point, por exemplo)
Eliminao do emaranhado de fios na sua mesa de trabalho (realmente isso algo que
incomoda)
Patch Pannel PoE

Suponha agora a seguinte situao: sua empresa j possui um parque instalado de centenas
de switches Cisco que no suportam PoE e deseja implantar a telefonia IP para poder usufruir de
todos os benefcios j discutidos. Talvez a administrao da empresa no esteja disposta a trocar todo
o parque j instalado de switches para modelos que suportem PoE.
Nesse caso uma soluo alternativa seria utilizarmos os chamados Patch Pannel PoE ou Power Patch
Pannel. Veja a figura abaixo:
O patch pannel PoE recebe a alimentao externa e a distribui no padro PoE para os telefones IP.
Tambm conhecidos como In-line Power Patch Panel normalmente suportam at 48 dispositivos e
utilizam os pares 4,5,7,8 para o envio da alimentao PoE.
Possuem 04 fileiras de conectores, onde as duas superiores so utilizadas para conectar dispositivos
finais, tais como telefones IP. As fileiras inferiores so utilizadas para conectar o switch que ir prover
a conectividade Ethernet.
Internamente, o patch panel conecta os pares Ethernet das portas das fileiras inferiores com a porta
correspondente da fileira superior. O patch panel no interfere com os pares 1,2,3,6 sendo um
componente passivo na rede. Um algoritmo de descoberta de telefones IP semelhante ao utilizado
nos switches Catalyst utilizado e quando o telefone IP Cisco detectado o patch panel PoE envia a
alimentao necessria, s que nesse caso atravs dos pares no utilizados pelo Etehernet pares 4,5,7,8.
Com essa soluo voc continua tendo a vantagem de centralizao da alimentao e a possibilidade
de backup da alimentao sem a necessidade de atualizao do hardware dos switches.
Outra opo que pode ser utilizada, geralmente para casos pontuais, so os Inline PoE Injector
(injetor PoE).
Um PoE Injector recebe a alimentao da rede pblica, converte para o padro PoE e envia para o
dispositivo. Geralmente utilizado quando precisamos alimentar poucos dispositivos.
Tenha em mente que os switches na soluo de voz no so responsveis somente em prover a alimentao PoE.
Qualidade de servio (QoS) e VLAN de voz so tambm funcionalidades cruciais para o funcionamento da soluo
VoIP. E para prover esses servios muitas vezes necessiro um upgrade no hardware do switch.
Ento, antes de pensar em utilizar um patch pannel PoE tenha a certeza que seus swtiches atuais esto aptos para
suportar os recursos de QoS e VLAN de voz necessrios.
Fonte de Alimentao Externa (Power Brick)

A maioria dos telefones IP da Cisco no vem com fonte de alimentao, pois a Cisco assume que a
sua soluo VoIP ir utilizar a tecnologia PoE para prover a alimentao.
Dependendo do tamanho da sua rede, se voc tiver que comprar uma fonte de alimentao externa
para cada telefone IP o custo ser equivalente ao de se realizar o upgrade para um switch que
comporte o PoE.
Um ponto importante a considerar que alguns dispositivos podem exceder a capacidade de
alimentao suportada pelo padro PoE 802.3af. Um exemplo muito comum de encontrarmos so
os mdulos extensores 7914/7915 utilizados para fornecer botes de extenso para um telefone IP,
onde nesses casos os mdulos extensores necessitam de fonte de alimentao externa para
funcionar.
Conceitos de VLAN e VLAN de Voz
Depois de devidamente cabeado e alimentado precisamos determinar a parte lgica da conexo dos
aparelhos IP, ou seja, em que VLAN esse telefone IP ser inserido. Tenha em mente que agora
temos voz e dados trafegando na mesma rede e consequentemente os riscos de segurana
envolvidos e a necessidade de QoS aumentam consideravelmente.
Para suprir as necessidades de segurana e QoS a Cisco recomenda separar o trfego de voz e dados
em VLANs distintas, ou seja, isolar os telefones IP (trfego de voz) em VLANs dedicadas para voz as
chamadas VLAN de Voz.
Bem, agora muitos podem estar pensando: vimos no tpico anterior que geralmente o telefone IP
estar cabeado no switch (atravs da porta 10/100 SW do telefone IP) e que o desktop estar
conectado no telefone IP (atravs da porta 10/100 PC do telefone IP).
Tambm estamos acostumados com a afirmao de que uma porta do switch s pode pertencer a
uma nica VLAN. Ento como faremos para colocar o telefone na VLAN de voz e o desktop na VLAN
de dados?
Para atingir esse requerimento a maioria dos telefones IP da Cisco vem com um switch interno que
suporta o padro 802.1q para tagging entre VLANs. O switch interno do telefone IP capaz de
estabelecer uma espcie de trunk com o switch e ento separar o trfego de voz e dados.
Importante: tradicionalmente, uma porta do switch que seja capaz de reconhecer a marcao de VLANs uma
porta trunk (switchport mode trunk). Contudo, quando vamos conectar um telefone IP em uma porta do switch
essa porta deve estar em modo access (switchport mode access). Ento encare essas portas como sendo uma
porta access (porta de acesso) com capacidade de reconhecer a marcao do trfego da VLAN de voz. Veremos a
seguir como fazer essa configurao.
Configurao da VLAN de Voz

O processo de configurao da VLAN de voz similar a qualquer VLAN. Como configurar uma VLAN
um tpico que o aluno do CCNA Voice j deve estar familiarizado, pois isso um conceito muito
estudado no CCNA, que pr-requisito para o CCNA Voice.
A configurao de uma VLAN basicamente composta de duas partes, primeiro criamos a VLAN e em
seguida associamos portas do switch a essa VLAN. Acompanhe abaixo um exemplo.
Agora associamos as portas do switch as quais iremos conectar os telefones IP em ambas as VLANs,
VLAN-voz e VLAN-dados.
Perceba que configuramos as portas em modo access(switchport mode access) e associamos essas
portas nas duas VLANs, VLAN de dados e de voz (switchport access VLAN 20 e switchport voice VLAN
10).
Ao colocarmos as portas em modo access aumentamos os requisitos de segurana. Se no tivssemos
o recurso da VLAN de voz, as portas dos switches conectadas aos telefones IP deveriam ser
configuradas como trunk e isso abriria uma brecha de segurana que poderia ser explorada por um
hacker. Por exemplo, o hacker poderia retirar o telefone IP e conectar seu prprio equipamento
(outro switch ou seu laptop) e executar o que chamamos de ataque VLAN-hopping. Com a porta em
modo access, mesmo que algum conecte um laptop nessa porta conseguir acessar apenas a VLAN
de dados. Somente um telefone IP conseguir reconhecer a VLAN de voz.
Tambm recomendado que voc habilite o port-fast nas interfaces conectadas aos telefones IP
(spanning-tree portfast). Isso porque o processo de boot do telefone IP geralmente mais rpido do
que tempo normal que uma porta com spanning-tree habilitado se torne ativa, geralmente de 50
segundos. Logo, sem o port-fast habilitado o telefone acabar por requisitar um endereo vlido via
DHCP antes dessa porta estar ativa.
Importante:
Os telefones IP da Cisco recebem a informao da VLAN de voz do switch via CDP (Cisco Discovery
Protocol). O CDP um protocolo proprietrio Cisco, logo se voc conectar um telefone IP de outro
fabricante ao switch Cisco, lembre-se que voc dever manualmente fazer a configurao da VLAN de
voz no telefone.
Processo de Boot de um Telefone IP
Agora que j vimos como conectar o telefone IP no switch e como separar o trfego de voz/dados
atravs da VLAN de voz, vamos voltar nossa ateno para o telefone IP propriamente dito. Nesse
tpico iremos entender o processo de boot de um telefone IP Cisco, verificando cada etapa
envolvida. muito importante que voc esteja familiarizado com esse processo, pois em uma situao
de falha e troubleshooting muitos problemas podero ser mais facilmente detectados atravs da
compreenso das etapas envolvidas nesse processo.
O processo de boot de um telefone IP pode ser dividido em 06 etapas, veja a figura abaixo:
Etapa 01: Receber alimentao PoE do switch.

Ao conectarmos um telefone IP Cisco em uma porta do switch com suporte PoE, o switch enviar a
alimentao necessria para por em funcionamento o telefone IP. Assim que receber a alimentao o
telefone IP ir ligar e passar para a etapa 2.
Etapa 02: Carga da imagem do telefone
Os telefones IP da Cisco possuem um memria flash no-voltil onde armazenam sua imagem de
firmware e as preferncias do usurio. Assim que o telefone IP liga ele roda um bootstrap e carrega
esse firmware que est armazenado em sua memria flash. Com essa imagem carregada o telefone IP
pode inicializar seu sofware e hardware.
Firmware, Bootstrap e Software:
O Firmware est normalmente envolvido com operaes muito bsicas de baixo nvel das quais sem
um, dispositivo seria completamente no-funcional.
J o Software, que tambm pode ser denominado "Programa de Computador", uma sequncia de
instrues a serem seguidas e/ou executadas, na manipulao, redirecionamento ou modificao de
um dado/informao ou acontecimento.
A principal diferena entre o Firmware e o Software que o Firmware trabalha manipulando

dispositivos, ou seja, cada firmware s pode ser usado em dispositivos idnticos. J o software
trabalha manipulando dados e faz comunicaes com o firmware, mas pode ser usado em
computadores com dispositivos semelhantes (e no idnticos como o firmware).
O bootstrap ou bootstraping, visto tambm no CCNA 640-802, est ligado ao processo de inicializar
um sistema computacional. Na maioria dos sistemas o bootstrap tem uma sequencia de inicializao
do hardware contida na memria ROM, a qual executada na CPU. Esse cdigo que est gravado na
ROM contm apenas um primeiro passo sobre como carregar o sistema operacional dentro da
memria RAM do computador ou dispositivo.
Etapa 03: Configurar a VLAN de voz
Assim que seu software e hardware so inicializados o switch envia um pacote CDP ao telefone,
informando qual a VLAN que o telefone dever utilizar para trafegar voz a VLAN de voz. Caso o
switch no seja da Cisco ele no ter suporte ao CDP, portanto voc dever configurar manualmente
a VLAN de voz no telefone.
Etapa 04: DHCP Receber um endereo IP e o endereo do TFTP Server
O prximo passo para o telefone IP ser enviar uma requisio em broadcast para o DHCP Server. O
servidor DHCP ir responder com um endereo IP vlido e to logo o telefone IP aceite a oferta do
endereo ele ir receber todas as opes configuradas no DHCP.
As opes no DHCP so utilizadas para passar informaes adicionais aos clientes, como por exemplo,
default-gateway, servidores TFTP, DNS, domnio e demais opes. No caso dos telefones IP da Cisco a
nica opo obrigatria a opo 150, que fornece o endereo do servidor TFTP.
Obs: no tpico a seguir veremos mais detalhes de como configurar o DHCP em roteador Cisco e como
habilitar a opo 150.
Etapa 05: TFTP receber os arquivos de configurao
Assim que o telefone IP toma conhecimento do endereo do servidor TFTP ele ir requisitar a ele os
arquivos de configurao (.cnf ou .xml). No arquivo de configurao estar uma lista dos agentes
processadores de chamadas onde o telefone dever se registrar - um servidor CUCM ou um roteador
com CME.
Importante:
Caso voc tenha habilitado o recurso de auto-registration (registro automtico) no CUCM o telefone
ir acessar o arquivo de configurao default (sepdefault.cnf.xml). Se esse telefone j estiver
configurado na base de dados do CUCM o telefone ir acessar o arquivo de configurao .cnf ou
.xml correspondente ao seu nome de dispositivo (device name SEP mac addres do telefone,
exemplo SEP0923AB23F0DE).
O arquivo .cnf ou .xml tambm contem a informao de qual imagem (firmware) o telefone
dever utilizar. Caso o firmware informado no arquivo de configurao seja diferente do firmware
atual do telefone, o telefone ir fazer o download dessa imagem que tambm deve estar armazenada
no servidor TFTP (arquivo .bin).
Assim que ele fizer o download dessa nova imagem o telefone ir resetar e voltar a etapa 01,
seguindo todo o processo novamente at carregar o seu arquivo de configurao do TFTP. Nesse
ponto a informao da imagem a ser utilizada estar atualizada e o telefone seguir para a prxima
etapa.
Etapa 06: Registro do telefone IP
Nessa etapa o telefone ir se registrar na fonte primria informada no seu arquivo de configurao,
que pode ser um Cisco CallManager (CUCM) ou um Roteador com CME. Se esse processo falhar o
telefone tentar se registrar no prximo servidor informado e assim por diante, at esgotar todas as
fontes.
Obs: no arquivo de configurao possvel armazenar at 03 endereos para registro do telefone.
DHCP Server em Roteadores Cisco
Em redes pequenas possvel utilizar o prprio roteadorCisco para atuar como servidor DHCP. Mais
uma vez frisamos que esse conceito j deve fazer parte do seu entendimento, uma vez que um tema
abordado no CCNA Network. Vamos aqui apenas relembrar de forma rpida como habilitar o DHCP
em um roteador Cisco.
Para configurar o roteador Cisco como servidor DHCP siga os comandos mostrados abaixo.
Lembre-se que a lgica para se configurar o DHCP em roteadores Cisco um pouco diferente da
maioria dos servidores DHCP. Primeiro voc deve informar quais os endereos que voc no quer que
sejam entregues a nenhum cliente (ip dhcp excluded-address). Depois voc cria um pool de endereos
que sero fornecidos aos clientes. O servidor DHCP ir fornecer os endereos IP aos clientes na ordem
crescente de endereos livres. No nosso exemplo, 192.168.1.10 para voz e 192.168.2.10 para dados
(perceba que excluimos os endereos com final de 1 a 9).
Note tambm que ao criarmos o pool de endereos para voz habilitamos a opo 150 do DHCP
informando que o servidor TFTP que dever ser utilizado est no endereo 192.168.1.1.
Informao extra:
Em projetos de telefonia IP para mdias e grandesorganizaes vocs iro se deparar com servidores
de DHCP dedicados. A prpria plataforma Cisco Unified Communications Manager possui recursos de
DHCP Server. Nesses casos, em seu roteador local tudo o que ser necessrio configurar o ip
helper-address (chamado de DHCP Relay) para encaminhar as requisies DHCP dos telefones para o
endereo do servidor DHCP. Como utilizar o ip helper-address tambm abordado no curso para a
certificao CCNA Network, pr-requisito do CCNA Voice. Uma dica que o ip helper-address deve
ser dado dentro da interface de LAN (ou VLAN) onde o switch que liga os telefones IP est conectado.
Curiosidade:
A opo DHCP 150 proprietria da Cisco. O padro IEEE utiliza a opo 66 para informar o endereo
do servidor TFTP. A principal diferena que com a opo 150 podemos definir multiplos endereos
de servidores TFTP, j com a opo 66 somente um endereo pode ser configurado.
Configurando Data/Hora com NTP
Por ltimo, mas no menos importante, devemos assegurar que todos os dispositivos Cisco
(telefones, roteadores e switches) estejam com as informaes de data/hora sincronizadas. Para tal,
utilizamos o protocolo NTP (Network Time Protocol).
Manter seus dispositivos sincronizados traz uma srie de vantagens, dentre elas:
Permite exibir a informao correta de data/hora para todos os usurios diretamente no

telefone IP
Atribui corretamente a data/hora nas mensagens do correio de voz
Fornece informaes precisas nos registros de bilhetagem, utilizados para rastreamento de
chamadas
Sincroniza as mensagens de log nos roteadores e switches
Curiosidade: quando voc reseta um roteador ou switch Cisco a maioria deles ir exibir a
configurao default de data (01 de Maro de 1993). Para configurar a data/hora em roteador/switch
voc tem duas opes:
Manualmente, com o comando clock set em modo EXEC privilegiado

Automaticamente, com o protocolo NTP
Utilizando o protocolo NTP voc ter uma informao de data/hora mais precisa e tambm ir
garantir que todos os dispositivos fiquem sincronizados, ou seja, com a mesma informao de
data/hora.
Os servidores NTP formam uma topologia hierrquica, dividida em camadas ou estratos (em ingls:
strata) numerados de 0 (zero) a 16 (dezesseis). O estrato 0 (stratum 0) na verdade no faz parte da
rede de servidores NTP, mas representa a referncia primria de tempo, que geralmente um
receptor do Sistema de Posicionamento Global (GPS) ou um relgio atmico. O estrato 16 indica que
um determinado servidor est inoperante.
O estrato 0, ou relgio de referncia, fornece o tempo correto para o estrato 1, que por sua vez
fornece o tempo para o estrato 2 e assim por diante. O NTP ento, simultaneamente, servidor
(fornece o tempo) e cliente (consulta o tempo), formando uma topologia em rvore.
Na Internet voc pode encontrar diversos servidores pblicos estratos 2 ou 3 (e at mesmo alguns
estrato 1) para utilizar.
Para habilitar o NTP em um roteador Cisco utilize como referncia o exemplo abaixo.
O primeiro comando ntp server a.st1.ntp.br informa o hostname ou endereo IP do servidor NTP
utilizado. Em nosso exemplo utilizamos um servidor NTP stratum 1 localizado aqui no Brasil. Tambm
poderamos utilizar o comando na forma ntp server 200.160.7.186, onde 200.160.7.186 e o endereo
IP para o host a.st1.ntp.br. O segundo comando ajusta o fuso-horrio do dispositivo, em nosso
exemplo utilizamos o fuso-horrio padro do Brasil, com -3 horas em relao ao UTC (Universal Time
Coordinated).
Para verificar o funcionamento do NTP utilize os comandos mostrados abaixo:
Dica: no comando show ntp associations a coluna st indica o stratum do servidor NTP utilizado,
no nosso exemplo mostra st 1, pois o servidor que utilizamos stratum 1. J no comando "show ntp
status" temos a informaostratum 2, pois esse o stratum do nosso sistema. Como estamos nos
referenciando com um servidor stratum 1, ns seremos stratum 2.
Informao extra:
Se voc desejar que o seu roteador atue como um servidor NTP para outros roteadores ou
dispositivos, voc dever utilizar o comando ntp master x, o x indica o stratum do seu roteador. No
nosso exemplo, utilizaramos ntp master 2.
Obs: em grandes projetos de VoIP, com servidores CUCM, o ideal configurar o NTP diretamente no
servidor CUCM, para que os telefones IP sincronizem a data/hora com o servidor CUCM.
Processo de Registro de um Telefone IP
Nessa etapa iremos verificar o processo de registro do telefone IP no sistema de gerenciamento de
chamada um CME ou um CUCM. Vamos recordar as etapas pelas quais o telefone IP j passou.
1. O telefone IP recebeu a alimentao via PoE do switch
2. O telefone IP recebeu a informao da VLAN de voz via CDP do switch
3. O telefone IP recebeu um endereo IP do servidor DHCP e tambm o endereo do servidor
TFTP (opo 150)
4. O telefone IP fez o download do arquivo de configurao atravs do servidor TFTP
Nesse ponto o telefone IP est verificando a lista deprocessadores de chamadas que ele deve tentar
se registrar. Lembre-se que possvel passar at 03 endereos de processadores de chamadas para o
telefone IP, onde ele vai tentar se registrar na primeira fonte, se no conseguir tentar na segunda e
por ltimo na terceira fonte. Essas fontes podem ser servidores CUCM ou um roteador com CME.
Quando o telefone encontra uma fonte vlida ele inicia o processo de registro via protocolo
SCCP (Skinny Client Control Protocol) ou SIP (Session Initiation Protocol).
Seja qual for o protocolo utilizado entre o telefone (SIP ou SCCP) e o gerenciador de chamadas (CME
ou CUCM), o processo de registro basicamente o mesmo:
O telefone contata o servidor do processador de chamada e se identifica atravs do seu

endereo MAC.
O servidor procura em sua base de dados uma equivalncia do endereo MAC para verificar se
esse telefone est configurado.
Em caso positivo, o servidor envia a configurao de operao para o telefone. Essa
configurao de operao diferente do arquivo XML contido no servidor TFTP. O arquivo XML
que est no servidor TFTP contem apenas as configuraes bsicas, como idioma, verso de
firmware, IP dos servidores e etc. J a configurao de operao contem informaes a
respeito do nmero do telefone, ring tones, layout das teclas do telefone e etc.
importante frisar que esse arquivo com as configuraes de operao enviado para o telefone IP
via protocolo SIP ou SCCP. Alm disso, as vrias outras funcionalidades utilizadas depois do telefone
estar registrado so trocadas via SIP ou SCCP. Por exemplo, quando voc tira o telefone do gancho e
escuta o tom discagem essa informao trocada entre o telefone e o servidor via SCCP ou SIP.
Quando voc digita o nmero que deseja discar, o envio dos dgitos para o servidor CUCM tambm
realizado via SCCP ou SIP.
Com o que estudamos at o momento voc j consegue entender o princpio bsico de
funcionamento e registro de um telefone IP Cisco, agora nos prximos captulos vamos colocar as
mos na massa e aprender como configurar cada um dos elementos VoIP da Cisco.
Informao extra:
O SCCP um protocolo proprietrio Cisco enquanto que o SIP um padro aberto. O SIP est se
tornando cada vez mais popular e a tendncia que o SCCP acabe caindo em desuso.
Gerenciando o CME com Linha de Comando (CLI)

A administrao de roteadores e switches Cisco via CLI (linha de comando) continua sendo a forma
mais completa e flexvel. Todo administrador de redes Cisco deve ter domnio do CLI, caso contrrio
poder enfrentar problemas srios no seu dia-a-dia de trabalho. Afinal, muitas tarefas de
troubleshooting (log/debug) devem ser executadas via linha de comando.
Com relao ao CME vale a mesma regra e via CLI voc poder executar todas as tarefas necessrias,
seja de criao, operao ou manuteno do seu roteador de voz.
importante ressaltar que nem todos os comandosnecessrios para o VoIP estaro dentro
do telephony-services. Alguns comandos como dial-peer, por exemplo, foram mantidos centralizados
fora desse modo.
Como mencionamos anteriormente, os comandos de troubleshooting tambm so encontrados no
modo CLI. Diversos comandos show e debug podem ser utilizados na operao/manuteno de
um roteador com suporte a voz. No decorrer do curso discutiremos esses comandos em maiores
detalhes, por hora, a ttulo de exemplo, mostramos um comando muito comum show ephone
registered que exibe informaes de todos os telefones registrados no CME.
Gerenciando o CME com Interface Grfica

Outra opo para o gerenciamento do CME atravs deaplicativos grficos. Normalmente esses
aplicativos so utilizados para tarefas de configuraes ou monitoramento. Nos dias de hoje,
podemos encontrar basicamente dois tipos de aplicativos grficos para gerenciamento do CME:
Integrated CME GUI

Cisco Configuration Professional (CCP)
Veremos a seguir mais alguns detalhes sobre o assunto. Ao longo do curso, para cada assunto
estudado iremos focar a forma de administrao no modo CLI e no CCP.
CME GUI
O Integrated CME GUI uma aplicativo HTML/JAR que roda direto na memria flash do roteador.
Normalmente os roteadores CME j vm com esse aplicativo pr-instalado, mas caso no seja esse o
caso, voc pode fazer o download de um pacote .TAR do site da Cisco (desde que possua uma conta
ativa CSCO) e decompact-lo na flash do seu roteador.
Para acessar o CME GUI no seu roteador basta configurar um endereo IP e habilitar o HTTP Server.
Em seguida voc poder, via browser, acessar a tela do CME GUI, bastando digitar o endereo IP
configurado no roteador.
Apesar da sua interface grfica no ser muito sofisticada o CME GUI atende os requisitos para o qual
foi criado, permitindo que voc execute diversas configuraes no CME, como por exemplo, adicionar
ou alterar configuraes dos telefones, modificar o dial-plan, configurar hunt groups e outras mais.
Importante:
Tenha em mente que o CME GUI fica instalado na flash do seu roteador. Ento, economizar espao
da flash mais importante do que maquiar a interface grfica com muitos detalhes, por isso a
interface grfica do CME GUI no traz tanta sofisticao.
CCP (Cisco Configuration Professional)
Enquanto que o CME GUI foi projetado para configurao bsica dos telefones IP, o Cisco
Configuration Professional (CCP) j capaz de executar a maior parte das configuraes em um
roteador com suporte a CME. Vamos ao longo desse tpico dar uma breve introduo sobre o CCP e
como utiliz-lo para configurar o roteador CME, na sequncia do curso outros detalhes importantes
para o escopo do CCNA Voice sero apresentados.
O CCP uma ferramenta de gerenciamento da Cisco com interface grfica avanada que simplifica
consideravelmente os aspectos de configurao de roteamento, firewall, IPS, VPN, unified
communications, WAN, LAN e configuraes bsicas de wireless.
O CCP assume que o usurio possui um entendimento genrico dos conceitos, termos e tecnologias
de rede, mas tambm ajuda aqueles que no esto muito acostumados com o CLI da Cisco, pois sua
utilizao baseada em instrues guiadas passo-a-passo, as quais guiam o usurio no caminho

correto atravs de wizards. J para aqueles que so usurios experientes o CCP oferece ferramentas
de configurao avanadas onde voc pode rapidamente visualizar os comandos que sero aplicados
no dispositivo antes de efetuar a configurao.
No site da Cisco possvel fazer o download da ltima verso do CCP e ento instalar em seu
computador (claro que voc precisa de um login vlido na Cisco CSCO). No necessrio instalar
nenhum pacote de software nos dispositivos monitorados (roteadores e switches). A instalao feita
somente no seu computador e tudo o que voc precisar fazer algumas configuraes no
roteador/switch para que habilite o suporte ao CCP, tais como habilitar o servio HTTP e HHTP seguro,
SSH e configurar usurio e senha de acesso.
Informao extra:
Existe uma verso CCP Express, similar ao CME GUI, que pode ser instalada na flash do roteador. Com
a verso express, apenas algumas configuraes bsicas esto disponveis, como por exemplo,
conexes LAN/WAN, firewall, NAT. Os recursos do Unified Communications no esto disponveis na
verso express.
Mais informaes sobre o Cisco Configuration Professional podem ser obtida no site da Cisco no link
abaixo. Fique atento pois nem todos os modelos de roteadores suportam o CCP, no link informado
possvel verificar quais as plataformas/IOS suportam o CCP.
Configurando o Roteador para Suporte ao CCP
Conforme comentamos o CCP um software que deve serinstalado em seu computador, mas para
que o roteador/switch aceite o CCP necessrio executar algumas configuraes. Acompanhe na
sada abaixo um exemplo de configurao.
Endereo IP: o CCP precisa ser capaz de alcanar o endereo IP configurado no roteador.
Usurio nvel 15 (Username e Password de root):conta administrativa para gerenciar o
roteador.
HTTP Service: o servio HTTP para o CCP ser capaz de descobrir o roteador.
Autenticao Telnet/SSH: o CCP ir se logar no roteador via Telnet ou SSH, conforme
configurado.
Por padro, o CCP ir tentar se conectar no roteador utilizando telnet e http. Para aumentar a
segurana possvel habilitar o SSH no roteador e no CCP.
Depois de devidamente configurado basta iniciar o CCP em seu micro.
Inicializando o CCP
Assim que o CCP inicializado ele fornece a opo para que voc configure uma comunidade de
dispositivos, como mostrado na figura ao lado. Entenda a comunidade como sendo um grupo de
dispositivos que voc deseja gerenciar com o CCP.
Para habilitar a conexo via SSH basta marcar o checkbox Connect Securely conforme mostrado na
figura abaixo:
Assim que o CCP abrir a comunidade de dispositivo ser mostrado uma lista com os equipamentos
que fazem parte dessa comunidade. Para que o CCP gerencie os equipamentos deve ser executado
um processo de discovery, onde o CCP ir identificar o hardware, software, interfaces e mdulos
existentes.
Para que o CCP realize o processo de discovery, selecione o equipamento e clique no boto
Discover. Veja as figuras 1, 2 e 3.
Obs: caso o processo de discovery falhe, verifique se a configurao do equipamento est de acordo
com o mostrado no anteriormente e tambm se na tela de criao da comunidade os dados de
endereamento, usurio e senha esto idnticos ao configurado no equipamento.
Figura 1
Figura 2
Figura 3
Conforme comentamos no incio, o CCP capaz de realizar uma srie de configuraes de segurana e
roteamento. Mas como o foco desse curso a parte de voz iremos focar nas facilidades de voz Unified Communications. Para acessar os menus de configurao necessrio clicar no boto
Configure localizado na parte superior.
Assim que abrir a seo de configurao, perceba que na lateral esquerda da tela voc ter uma srie
de pastas e subpastas, cada uma referente a um tipo de configurao. Para acessar a configurao de
voz, clique na pasta Unified Communications.
Caso o seu roteador ainda no tenha sido configurado para suportar o CME, ou seja, se a parte do
telephony-services mostrada anteriormente no tiver sido configurada, a nica opo disponvel ser
Unified Communications Features.
Clicando em Edit ou Reset podemos acessar as opes de modo de configurao para o roteador.
Antes que voc possa realizar alguma configurao de voz o roteador precisa ser configurado em um
dos modos de operao. So possveis os seguintes modos de operao para um roteador no Unified
Communications.
Obs: Em verses diferentes do CCP essa tela pode ser um pouco diferente, mas basicamente teremos
algo bem semelhante. Lembramos que a verso de CCP utilizada nesse curso a v2.6.
Modo Cisco Unified Border Element
Um Cisco Unified Border Element (CUBE) carrega o trfego fim-a-fim e trfego IP atravs de um trunk
SIP atravessando redes de corporaes e provedores de servios diferentes.
Modo Cisco Unified Communications Manager Express
Nesse modo (CME) o roteador age como um agente processador de chamadas e todos os telefones
iro se registrar no roteador CME. Nesse modo, todo o dial plan (plano de discagem) deve ser
realizada nas configuraes do roteador.
Modo Cisco Unified SRST
Nesse modo o roteador ser utilizado para operar no modo Survivable Remote Site Telephony (SRST)
quando perder a conexo com o Cisco Unified Communications Manager. Durante o perodo de falha
do CUCM o roteador utiliza uma aplicao de roteamento de chamada padro via H.323.
Modo Cisco Unified CME as SRST
Nesse modo o roteador fornece suporte ao processamento de chamadas para os telefones IP caso a
conexo com os agentes primrio, secundrio e tercirio falhe. Quando a funcionalidade de SRST
fornecida por um CME o provisionamento dos telefones IP no roteador automtica. Durante o
perodo de falha a maior parte dos recursos e facilidades continuam disponveis para os telefones IP.
Modo TDM Gateway
Nesse modo o roteador configurado um gateway de voz para o roteador que hospeda o CME. O
controle de chamadas e traduo de mdia ficam separados em dois dispositivos, o gateway de voz
trata da converso de mdia e um agente de chamada cuida do controle de chamadas.
Modo Media Resources
Nesse modo possvel configurar transcoding e recursos de conferncia. Media Resource Groups e
Media Resource Group List, no CUCM, fornecem uma forma de gerenciar os recursos de mdia dentro
de um cluster de servidores CUCM. A opo Media Resource ser disponibilizada somente se tivermos
recursos de DSP/PVDM instalados no roteador.
Depois de escolhido o modo desejado basta clicar em Ok. Nesse momento ser exibida uma tela
com a configurao a ser realizada no roteador para que ele atue no modo escolhido.
Se tudo estiver de acordo clique no boto Deliver. Isso far com que essas linhas de comando sejam
enviadas para arunning-config do roteador.
Caso voc deseje salvar a configurao tambm na startup-configuration nessrio clicar na opo
Write to Startup Configuration na guia Utilities.
Logo em seguida clique em Confirm para confirmar sua opo.
Reviso da Teoria
Vimos em captulos anteriores como o processo de boot de um telefone IP Cisco e tambm as
principais configuraes que devemos fazer nos roteadores e switches para suporte a VoIP.
Nesse tpico iremos revisar esses conceitos, pois eles so deextrema importncia para o
prosseguimento do curso. Ento vamos l...abaixo uma lista dos tpicos que abordaremos nos
prximos slides.
VLAN de Voz
Habilitando o Servio DHCP no Roteador
Configurando o TFTP
Configurao CME Bsica
Vimos em captulo anterior que at que o telefone IP Cisco fique operacional para o usurio ele passa
por algumas etapas, conhecidas como processo de boot de um telefone IP. So elas:
Etapa 01: Receber alimentao PoE do switch
alimentao necessria para por em funcionamento o telefone IP.
Assim que o telefone IP liga ele roda um bootstrap e carrega o firmware que est armazenado em sua
memria flash. Com essa imagem carregada o telefone IP pode inicializar seu sofware e hardware.
Nessa etapa o switch envia um pacote CDP ao telefone, informando qual a VLAN que o telefone
dever utilizar para trafegar voz a VLAN de voz. Lembre-se que caso o switch no seja da Cisco ele
no ter suporte ao CDP, portanto voc dever configurar manualmente a VLAN de voz no telefone.
O telefone IP envia uma requisio em broadcast para o DHCP Server. O servidor DHCP responde com
um endereo IP vlido e to logo o telefone IP aceita a oferta do endereo ele recebe todas as opes
configuradas no DHCP, tais como a opo 150 que informa o endereo do servidor TFTP de onde o
telefone IP dever baixar os arquivos de configurao.
Assim que o telefone IP toma conhecimento do endereo do servidor TFTP ele requisita os arquivos
de configurao (.cnf ou .xml), onde consta a lista dos agentes processadores de chamadas onde
o telefone dever se registrar - um servidor CUCM ou um roteador com CME.
fontes.
Atente para o fato de que o servidor TFTP e o DHCP no precisam estar em dispositivos separados, dedicados para esse fim.
Dependendo do tamanho da sua rede, o roteador Cisco poder abrigar todas essas funcionalidades CME, DHCP e TFTP.
VLAN de Voz
Para fazer a separao do trfego de dados e voz necessitamos criar duas VLANs distintas, a vlan
de dados e a vlan de voz. Em cada porta do switch que ser conectada aos telefones IP devemos
habilitar ambas as VLANs, a de voz e a de dados.
Para tal, devemos configurar a porta em modo access e fazer a associao das duas vlans em cada
porta, conforme ilustrado no exemplo abaixo:
Habilitando o Servio DHCP no Roteador

Caso o seu roteador CME esteja funcionando tambm comoservidor DHCP para a VLAN de voz,
gerenciando a demanda de endereos IP para os telefones IP, o servio DHCP deve ser habilitado e a
opo 150 (servidor TFTP) deve estar devidamente configurada. Veja sada abaixo com exemplo de
configurao. A configurao do DHCP para a VLAN de dados no precisa nada de especial como para
a de voz (que precisa da opo 150).
Importante:
Atente para o fato que o seu roteador estar conectado ao switch via porta trunk. Logo, no roteador
deveremos ter criado as sub-interfaces para cada VLAN dentro da interface fsica para conexo com
switch, ou seja, uma sub-interface para a vlan de dados e outra sub-interface para a vlan de voz.
J no switch a porta conectada ao roteador dever estar em modo trunk (switchport mode trunk).
Perceba que na configurao do DHCP para o pool dltec-dados colocamos o default-router apontando
para a sub-interface do roteador que est na vlan de dados, no caso 192.168.10.1. J para pool dltecvoz apontamos para a sub-interface do roteador que est na vlan de voz, ou seja, 192.168.20.1.
Ateno tambm para opo 150 que est apontada para a sub-interface da vlan de voz.
interface FastEthernet0/1
no ip address
duplex auto
speed auto
no shut
!
interface FastEthernet0/1.10
description VLAN-dados
encapsulation dot1Q 10
ip address 192.168.10.1 255.255.255.0
!
interface FastEthernet0/1.20
description VLAN-voz
encapsulation dot1Q 20
ip address 192.168.20.1 255.255.255.0
!
Configurando o TFTP
Vimos que os telefones IP iro contatar o servidor TFTP para baixar os firmwares e arquivos de
configuraes. Encare o servidor TFTP apenas como um repositrio de arquivos que os telefones IP
contatam para baixar os arquivos necessrios. Esse servidor TFTP pode ser configurado em qualquer
dispositivo da sua rede, seja ele cisco ou no-cisco, mas normalmente o que vemos na prtica para
redes VoIP com tecnologia Cisco o servidor TFTP est configurado no roteador CME ou no servidor
publisher CUCM.
Caso nenhuma configurao individual foi realizada em um determinado telefone IP o nico arquivo
de configurao enviado ao telefone IP ser o XMLDefault.cnf.xml que contm o endereo IP e
nmero de porta do servidor processador de chamadas que pode ser um roteador CME ou um
servidor CUCM (em nosso caso ser o endereo do nosso roteador CME). Assim que o telefone recebe
esse arquivo ele baixa o firmware, caso necessrio, e em seguida contata o roteador CME para efetuar
seu registro.
Quando durante a operao de dia-a-dia alteramos a configurao de um determinado telefone IP, o
roteador CME altera o arquivo de configurao especfico desse telefone no servidor de TFTP, esteja
ele na flash ou em um servidor TFTP externo. Dessa forma, no prximo reboot do telefone ele ir
baixar o arquivo atualizado e carregar a configurao correta.
Importante: Atente para o fato de que ao utilizar o roteador como servidor de TFTP todos os arquivos
de configurao e firmwares utilizados ficaro armazenados na flash do seu roteador. O espao na sua
flash deve ser levado em conta, caso contrrio voc poder enfrentar problema de falta de espao.
Tenha em mente tambm que para cada modelo de telefone IP sero necessrios firmwares
especficos e para cada telefone IP configurado um arquivo de configurao ser gerado. Alguns
modelos de telefones podem ter firmwares com tamanho que superam os 40M bytes.
Por isso, utilizar um servidor externo pode ser uma excelente opo.
Reparem na sintaxe do comando alias aps o nome do arquivo. O alias necessrio para que os
telefones IP faam a requisio do arquivo apenas pelo nome. As verses mais novas do CME
organizam os arquivos de firmware em subdiretrios e os telefones IP no conhecem o caminho
completo onde est armazenado o arquivo, e sim, apenas o seu nome.
Reparem tambm que para o modelo 7940-7960 temos 04 arquivos (.bin - .loads - .sb2 - .sbn). Fique
atento em colocar todos os arquivos de firmware para cada modelo de telefone IP no TFTP. Durante o
processo de boot todos esses arquivos podero ser utilizados e caso falte algum o processo ir falhar.
Informao extra:
A partir da verso 4.0 do CME os arquivos de configurao e firmware podem ser armazenados em
um servidor externo de TFTP. Para tal basta configurar a opo cnf-file location tftp://<ip address of
TFTP server> dentro do modo de configurao do telephony-service.
No site da Cisco voc pode encontrar todos os firmwarespara todos os modelos de telefones IP Cisco.
Claro que necessrio uma conta de usurio associada a algum contrato que lhe d o direito de fazer
download desses arquivos.
Esses arquivos vem com a extenso .tar e voc copi-los na flash do roteador e extrair diretamente na
flash via linha de comando.
Abaixo um exemplo de extrair o arquivo .tar para o diretrio desejado na flash.
Configurao CME Bsica

Nesse ponto j temos quase tudo configurado para que o seu roteador atue como CME em sua rede.
A VLAN de voz j est devidamente configurada no switch onde os telefones sero conectados, o
DHCP tambm j foi habilitado com a opo 150 e os arquivos de configurao e firmware j esto
disponveis no servidor TFTP.
O cenrio est quase completo, faltando apenas habilitar o seu roteador para atuar como CME.
Lembre-se que vimos no captulo anterior que isso pode ser feito via CLI (no modo telephony-services
de configurao) ou via CCP (onde tnhamos a opo de colocar o roteador no modo CUCME).
Vamos a seguir mostrar um exemplo via CLI, ou seja, via linha de comandos. Como vimos
anteriormente, muitas configuraes so possveis dentro do modo telephony-services, mas para
comear, basicamente o que precisamos informar ao roteador so os seguintes itens:
IP Source Address
Max DN
Max Ephone
muito importante perceber a diferena entre os parmetros max-ephone e max-dn. O

parmetro max-ephone indica qual o nmero mximo de telefones IP que o roteador ir suportar. J
o max-dn indica quantosnmeros de diretrios so suportados. Entanda o ephone como sendo o
aparelho fsico, o dispositivo conectado no switch. J o DN a linha do telefone, o nmero que esse
telefone ter.
Essa diferenciao se faz necessria porque podemos ter em um mesmo aparelho (ephone) duas ou
mais linhas (DN) configuradas, por exemplo. Isso muito comum de encontrarmos na prtica.
Tenha em mente tambm que essa configurao impacta diretamente na quantidade de recurso
de memriareservada para que o roteador suporte o servio CME. Quanto mais ephones e DNs voc
configurar nos parmetros max-ephone e max-dn, mais recurso ser reservado para o CME e isso
pode impactar nos outros servios que o roteador deve executar.
Outro ponto importante que no devemos esquecer quecada plataforma tem um nmero mximo
permitido de ephones e DNs. O modelo de roteador que voc ir escolher deve estar de acordo com
as suas necessidades reais de projeto. Veja nas tabelas abaixo uma listagem da quantidade mxima
disponvel por modelos de roteadores. Na tabela 2 voc tem a lista de capacidades da famlia ISR
gerao 1.
Tabela 1
Tabela 2
Nesse ponto da configurao o roteador j est pronto para atuar como CME, ou seja, para atuar
como o agente processador de chamadas e de registro para os telefones IP configurados.
Agora iremos seguir um passo a diante e nos prximos slides veremos como podemos criar os
telefones IP no roteador, ou seja, como configuramos os telefones IP no roteador CME.
Configurando Telefones IP via CLI
Conforme j comentamos no item anterior a criao de um telefone IP consiste de dois parmetros
ephone-dn e ephone. Tenha certeza de que compreende bem o conceito envolvido antes de seguir
para a configurao propriamente dita. Por isso vamos falar um pouco mais sobre o tema, s para
garantir que no sobre nenhuma dvida.
Estamos acostumados a ver o telefone convencional como uma entidade nica. O telefone da sua
casa, por exemplo, tem um determinado nmero e tudo o que voc precisa fazer plugar um
aparelho na sua linha. No importa o modelo, nem o fabricante, nem nada desse tipo... se o telefone
no estiver quebrado e a sua linha estiver ativa, ao plugar um telefone na sua tomada ele estar
pronto para o uso.
Com os telefones IP isso pode parecer no to simples assim... na verdade simples tambm, porm
preciso que voc compreenda o conceito do ephone e do ephone-dn.
Entenda o telefone IP como tendo duas entidades, uma fsica e outra lgica. A parte fsica
o ephone e a lgica oephone-dn.
Isso fcil de perceber, por exemplo, se voc pegar um telefone IP em suas mos (se tiver um por
perto, seno d asas a sua imaginao). O que podemos perceber como fsico o ephone, por
exemplo, temos o modelo do telefone (7940, 7911, 7975 e etc), para cada telefone temos um macaddress, um nmero de srie e por a vai... J a parte lgica fica por conta do nmero da linha, esse
o ephone-dn. No podemos pegar fisicamente no nmero da linha, isso uma parte lgica, uma
programao que fizemos, logo o nmero da linha, que aqui chamamos de DN (Directory Number)
est associado ao ephone-dn.
Dito isso, vamos seguir em frente e ver como configuramos, como criamos os ephone-dn, depois
como criamos os ephones e por fim como associamos um ephone-dn (uma linha) a um ephone
(telefone).
Configurando Ephone-dn
Como comentamos os ephones-dn so os nmeros de diretrios que criamos e que podemos
associar aos telefones fisicamente, aos ephones. Esses ephones-dn podem ser criados como singleline ou dual-line.
Single line
Nesse modo, o ephone-dn poder fazer ou receber apenas uma ligao por vez. Ou seja, se voc est
utilizando esse ephone-dn para fazer uma ligao e algum lhe chamar nesse nmero, essa pessoa
escutar um tom de ocupado. Isso porque o seu ephone-dn est configurado como single line, ou
seja, com apenas uma linha.
Dual line
No modo dual line o ephone-dn tem a capacidade de operar com duas chamadas simultneas.
Utilizando o mesmo exemplo anterior, se voc estiver em uma ligao e uma segunda ligao entrar
para esse ephone-dn, voc escutar um alerta informando que tem outra chamada.
O mais comum de encontrarmos na prtica que os ephones-dn de usurios comuns so criados no
modo dual-line. J o single-line utilizado para funes especiais, como intercom por exemplo. No
se preocupe, veremos essas funcionalidades posteriormente em outro captulo desse curso.
As verses mais novas de IOS fornecem suporte a um modo octo-line, ou seja, com oito linhas. Esse
recurso pode ser bem utilizado para telefones de telefonistas ou atendentes, por exemplo. No
entando, tenha em mente que configurar todos os telefones no modo octo-line ir consumir muito
recurso do seu roteador e no recomendado.
Veja exemplo de configurao abaixo.
Perceba que, no nosso caso, o parmetro tag tem um range de 1-150. Esse tag um parmetro lgico
e ser utilizado quando formos associar o ephone-dn ao ephone. Voc pode escolher qualquer
nmero disponvel dentro do range. Lembre-se tambm que no se pode exceder o nmero de
ephone-dn especificado no comando max-dn configurado dentro do telephony-services.
J o parmetro number o nmero que atribuimos ao ephone-dn, ou seja, o nmero do diretrio ou
mais comumente o nmero da linha (esse o nmero que os usurios iro discar para falar com esse
dn).
Informao extra:
Ao criar mais ephone-dn do que o permitido no max-dn o roteador ir lhe mostrar uma mensagem
de erro, conforme abaixo.
dltec(config)# ephone-dn 36
dn tag 36 exceeds legal range 1 to max-dn 35
Para solucionar o problema devemos aumentar o nmero de dn permitido dentro do telephonyservices (max-dn).
Informao extra:
interessante citar que podemos atribuir um nmero secundrio ao ephone-dn. Dessa forma, o
mesmo ephone-dn ter dois nmeros, o primrio e o secundrio. Veja a sintaxe.
dltec(config)#ephone-dn 5 dual-line
dltec(config-ephone-dn)#number 7810 secondary 30457810
Com essa configuraa o dn 5 ir responder a esses dois nmeros, 7810 e 30457810. Isso pode ser
utilizado, por exemplo, para atribuir um nmero interno (7810) para que os usurios internos da sua
rede lhe chamem e um nmero externo (30457810) que ser utilizado quando a chamada vier da rede
pblica (PSTN). Existem outras maneiras de se fazer isso, mas uma das possibilidades com o
parmetro secundary.
Configurando Ephone
Conforme comentamos anteriormente ao configurarmos o ephone estamos configurando os
parmetros do telefone IP Cisco propriamente dito. Assim como no ephone-dn, o nmero
de ephone configurado no pode exceder o mximo especificado dentro do telephony-services (maxephone). Veja abaixo um exemplo.
Perceba que temos inicialmente o parmetro lgico tag, cujo princpio funciona de forma equivalente
ao explicado para o ephone-dn. Ao entrarmos no modo de configurao do ephone 1, por exemplo,
qualquer configurao realizada ir afetar somente o ephone 1. Basicamente precisamos de dois
parmetros para configurar no ephone, o mac-address e o tipo de telefone.
O mac-address do telefone pode ser encontrado de 03 formas:
Na caixa do telefone IP
Verifique a caixa do telefone IP e voc poder encontrar o mac-address, prximo ao cdigo de
barras.
Na traseira do telefone IP
Caso voc no tenha a caixa original do telefone, na traseira do telefone voc encontrar um
etiqueta com o nmero do mac, tambm prximo ao cdigo de barras.
No menu do configurao do telefone
Todos os modelos de telefones IP Cisco possuem um boto de configurao (settings). Ao
pressionar esse boto voc entrar no menu de configurao do telefone. Procure pelo item
Network Configuration e voc conseguir chegar ao mac-address desse telefone.
Claro que as opes citadas acima funcionam somente se estivermos perto do telefone. Caso voc
esteja realizando essa configurao remotamente e o telefone IP j tenha sido conectado na rede,
voc poder conseguir o mac-address do telefone IP acessando o switch no qual o telefone foi
conectado e verificando a tabela mac e/ou vizinhos do CDP. Por exemplo, suponha que precisamos
descobrir o mac-address do telefone que est na conectado na f0/3 do switch, veja ao lado a sada
dos comandos show mac address-table e show cdp neighbors detail.
Para verificar se o telefone foi corretamente configurado no CME utilize o comando show ephone.
Na sada do comando possvel verificar o nmero do ephone (tag) o mac-address e se ele est
registrado ou no. Veja um exemplo.
Perceba que ambos os ephone esto no status Unregistered, ou seja, no-registrado. Caso estivesse
registrado o status mostrado seria Registered. Veremos um exemplo mais a frente da sada desse
comando com os telefones registrados.
Associando Ephone e Ephone-DN
Agora que o ephone j est criado podemos atribuir um nmero (uma linha) para esse telefone, caso
contrrio ele no poder ser utilizado. Isso feito associando um ephone-dn ao ephone e para tal
utilizamos o comando button dentro do modo de configurao do ephone. Veja um exemplo
abaixo.
Nesse caso estamos dizendo que o ephone 1 (telefone IP) ser associado ao ephone-dn 1 no boto 1
desse telefone. Ou seja, primeiro entramos na configurao do ephone 1, depois associamos o seu
boto 1 ao ephone-dn 1 previamente configurado.
aconselhvel reiniciar o telefone para que a configurao tenha efeito, isso feito com o comando
restart ou reset.
Os telefones IP Cisco precisam ser reiniciados aps alteraes de configurao. Voc pode reinicializar
o telefone IP com o uso de dois comandos reset ou restart. Veja no resumo abaixo a diferena entre
os dois comandos.
Comando Reset
Tipo de reinicializao: Similar a ligar e desligar o telefone.
Config do Telefone: Faz o dowload da configurao.
DHCP e TFTP: Contato com servidores DHCP e TFTP para update das informaes de configurao.
Tempo de processamento: Pode demorar, principalmente se estiver fazendo o reset em vrios
telefones simultneamente.
Quando necessrio: Configuraes de data/hora; Network locale, firmware, Source address, TFTP
path, URL parameters, User locale, Voicemail access number.
Tambm pode ser utilizado quando atualizando Directory numbers, Phone buttons, Speed-dial
numbers.
Comando Restart
Tipo de reinicializao: reinicializao rpida
Config do Telefone: Faz o dowload da configurao.
DHCP e TFTP: Contato apenas com o servidor do TFTP para update das informaes de configurao.
O servidor de DHCP no contactado.
Tempo de processamento: Processamento rpido.
Quando necessrio: Directory numbers, Phone buttons, Speed-dial numbers.
possvel realizar o reset/restart de cada telefone individualmente ou de todos os telefones ao
mesmo tempo.
possvel associar um ephone (telefone) a mltiplas linhas(ephone-dn). Veja o exemplo abaixo.
Nesse caso, associamos o boto 1 ao dn 1 e o boto 2 ao dn 2. Ou seja, quando o usurio pressionar o

boto 1 ele ir utilizar a linha configurada no ephone 1. Quando ele desejar utilizar a linha configurada
no ephone 2 ele dever pressionar o boto 2.
Com o comando show ephone mostrado anteriormente podemo verificar a associao realizada.
Reparem na sada do comando a diferena entre o ephone 1 e 2 com relao ao button 1. No ephone
1 temos a informao CH1 IDLE. J no ephone 2 temos somente CH1 IDLE CH2 IDLE. Isso porque o dn
2 associado ao ephone 2 foi configurado como dual-line, j o dn 1 associado ao ephone 1 um singleline.
Gerenciando Arquivos de Firmware

Vamos agora ver um tpico que no tem sido muito cobrado na prova de certificao, mas que
muito importante para o seu dia-a-dia trabalhando com telefonia IP Cisco em CME.
Ns j sabemos que no TFTP devem estar disponveis osarquivos de configurao (.cnf) e
de firmware (.bin) para cada modelo de telefone IP e que esses arquivos sero baixados durante o
processo de boot do telefone.
Cada verso de CME tem as verses de firmware compatveis para cada modelo de telefone IP. No
link a seguir voc pode verificar a matriz de compatibilidade do Cisco CME e IOS.
Passo 01: Servidor TFTP

Passo 02: Forar o telefone a baixar o firmware da verso intermediria
Passo 03: Resetar o telefone IP
Passo 04: Forar o telefone a baixar o firmware da verso atual
Passo 01: Servidor TFTP

Crie no seu servidor TFTP uma pasta para disponibilizar o pacote da verso de firmware intermediria.
Em nosso caso, como estamos utilizando o roteador CME como servidor TFTP para os telefones IP
devemos criar o diretrio na flash e colocar o pacote de firmware intermedirio dentro dessa nova
pasta.
Na pasta 7911_7906 temos os firwmares da verso nova e na pasta 7906-7911-7 os firmwares de uma
verso antiga.
Passo 02: Forar o telefone a baixar o firmware da verso intermediria

Ou seja, nesse passo devemos forar o download do firmware SCCP11.8-3-3S que est na pasta 79067911-7.
Primeiro criamos as entradas tftp-server apontando para o caminho desejado e em seguida, dentro
do telephony-service, foramos a utilizao da verso intermediria.
Passo 03: Resetar o telefone IP

Agora que j temos as entradas para o firmware que o telefone IP deve utilizar, basta resetarmos o
telefone.
Informao extra:
Algumas vezes pode ser necessrio fazer um reset de fbrica no telefone. Esse tipo de reset faz com
que todas as configuraes e firmware sejam apagados, fazendo com que o telefone volte para a sua
condio inicial de fbrica. Para fazer um reset de fbrica proceda da seguinte maneira.
1. Tire o cabo de rede do telefone IP e pressione a tecla #

2. Com a tecla # pressionada conecte o telefone IP no switch
3. Os leds iro comear a piscar. Mantenha pressionada a tecla # at que a luz do monofone
comece a piscar
4. Assim que a luz do monofone comear a piscar solte a tecla # e digite a sequencia
0123456789*0#
Passo 04: Forar o telefone a baixar o firmware da verso atual.
Agora que o telefone j atualizou para o firmware intermedirio basta repetir o passo 2, s que
apontando para a pasta com o firmware da verso atual.
Perceba que no final do processo o telefone SEP001B0C96C5E8 est mostrando que anteriormente
utilizou o firmware SCCP11.8-3-3S e agora est utilizando o firmware correto SCCP11.9-1-1SR1S
Configurando Telefones IP via CCP

Primeiro de tudo vamos considerar que o "telephony services" j foi configurado via CCP, pois sem
isso no conseguiremos criar os ephones ou ephone-dns.
Vamos a um exemplo criando um novo ramal (extension) com o nmero 8006, que ser vinculado a
um IP Communicator (CIPC) e a um usurio chamado Manda Chuva.
Primeiro vamos criar o ramal (extension) que o ephone-dn. Para isso v em Unified
Commmunications > Users, Phones and Extensions > Extensions e clique em "Create".
Obs: A opo Name to be displayed on phone line no o comando name utilizado pelo
Directory, apenas o label do telefone IP.
Agora vamos criar o telefone e o usurio na pasta Phones and Users, logo abaixo de Extensions,
clicando em Create....
Para criar o telefone voc deve escolher um modelo, o qual o nosso um IP Communicator, um
softphone da Cisco. Configuramos o MAC dele e por ltimo vamos vincular esse telefone a um DN, o
qual criamos no passo anterior como 8006.
O 8006 fica listado em Available Extensions, basta clicar nele e clicar na setinha para passar ele para
o outro lado da tela. No clique em OK ainda, agora teremos que configurar a conta de usurio que
ir vincular o comando name ao ephone-dn.
Em seguida passe para a aba user. Primeiro configure umuser ID qualquer (pode ser o nome da
pessoa para facilitar), pois esse parmetro apenas uma identificao.
Depois configure o First e Last name, agora sim esses valores que sero adicionados via o comando
name.
Agora s clicar em OK para enviar a configurao ao roteador.
Na prxima tela vir um resumo dos comandos que sero configurados no roteador, basta dar um
"Deliver" e a configurao est finalizada.
Note que na penltima linha aparece o comando name Manda Chuva.
Portas de Voz x CME

Antes de iniciarmos a configurao dos dial-peers e fazer os roteadores se comunicarem dentro da
rede VoIP precisamos entender e configurar as diversas portas de voz, as quais permitem conexo
com dispositivos analgicos e digitais, possibilitando, por exemplo, que
nossa rede seja interligadacom o mundo exterior atravs da rede tradicional de telefonia (PSTN).
Para isso, vamos analisar como configurar as placas analgicas e digitais que permitem as conexes
com o mundo da telefonia tradicional, sejam com a rede pblica ou com os sistemas privativos, os
PABX.
Configurando Portas de Voz Analgicas

Configurar uma placa de voz analgica uma tarefa relativamente simples, pois se voc plugar um
cabo ela j est operacional, claro que sem encaminhamento de chamadas porque isso deve ser
configurado via dial-peers.
As portas analgicas que so foco do CCNA Voice so as:
Foreign Exchange Station (FXS)

Foreign Exchange Office (FXO)
A topologia mais conhecida sobre a aplicao das portas FXO e FXS est exemplificada
na figura abaixo, a qual mostra que a FXO conectada uma central telefnica convencional e
aFXS a um telefone analgico.
Alm das portas FXO e FXS existe a placa E&M, a qual mais utilizada para fazer conexo entre
centrais telefnicas utilizando 2 ou 4 fios para voz e mais 2 ou 4 fios para a sinalizao. Essas placas
no so cobradas no CCNA Voice.
Configurando uma Porta FXS
Vamos iniciar estudando a placa FXS, a qual responsvel por conectar os dispositivos finais de
telefonia, tais como telefones analgicos, equipamentos de fax ou modems analgicos. Veja a figura
abaixo um exemplo de topologia tpica de um ambiente com placas FXS.
A primeira atividade antes de configurar as portas de voz analgicas de um roteador deve

ser verificar quais portas instaladas com o comando show voice port summary, acompanhe
na figura abaixo.
Perceba que temos 04 portas FXS instaladas, numeraras de 1/0/0 at 1/0/3 (campo PORT), as quais
aparecem como fxs-ls no campo SIG-TYPE.
Obs: Se voc tiver telefones criados via ephone-dn no CME, eles aparecero nesse comando como
EXFS, j as portas FXO aparecero como fxo-ls.
As portas FXS tm trs parmetros para configurarmos:
Sinalizao
Tons de chamada (Call progress tones)
Identificador do ramal (Caller ID)
Sobre a sinalizao de linha que podemos configurar, a qual j estudamos no captulo dois, pode ser
de dois tipos: loop start e ground start. Ela indica como o telefone vai sinalizar para a porta do
roteador que ele est fora do gancho, sendo que o padro configurado nas portas o loop start.
Lembrem que no "loop start", quando tiramos o telefone do gancho fechado um loop que permite
uma corrente eltrica fluir entre o telefone e a central indicando que o usurio ocupou a linha e
deseja realizar uma chamada, porm agora ao invs de uma central teremos uma porta FXS.
Dica: Vale a pena aqui a dica de que a porta FXS simula uma porta de central telefnica, ou seja, ela
deve passar os tons de progresso da chamada e o ring para os telefones.
J com o ground start a porta FXS sabe que o telefone ou dispositivo final est querendo ocupar a
linha (ficar fora do gancho off hook) quando os fios da conexo so aterrados. Como ele no
padro voc deve configurar a porta para ela sinalizar via ground start e normalmente essa
sinalizao utilizada quando temos um PABX na outra ponta.
Para configurar a sinalizao e demais parmetros na porta fsica de voz voc deve estar em modo de
configurao global e entrar na porta com o comando voice port e o nmero da porta a ser
configurado, com isso voc entrar em um modo de configurao da voice port (porta de voz).
Acompanhe no exemplo ao lado, ondeentramos na porta 0/0/0, a primeira porta da VIC2-4FXS, e
configuramos a sinalizao loop start e a seguir entramos na segunda porta (0/0/1) e a configuramos
como ground start.
O segundo parmetro referente aos tons de progresso da chamada ou em ingls Call Progress
Tones. Esses tons so referentes aos diversos tons informativos que o telefone receberia de uma
central telefnica, porm nesse caso sero passados pela placa FXS.
Por exemplo, quando voc tira o telefone do gancho voc recebe um tom de discar, dependendo do
pas onde voc se encontra esse tom pode ser diferente, assim como os demais tons. Para configurar
esses tons conforme o padro de cada pas voc deve utilizar o comando cptone, que est dentro
da configurao da porta de voz.
Veja a sada do comando abaixo e um exemplo de configurao para o Brasil.
Obs: A sequncia de tons padro configurada nas portas FXS dos roteadores Cisco dos Estados
Unidos. Lembrem que esses so os tons que o usurio ir ouvir enquanto a chamada processada.
Outra curiosidade que os pases so identificados com dois dgitos.
A ltima configurao referente ao caller-id, o qual aidentificao de quem est fazendo a
chamada. Esse parmetro ser mostrado na outra ponta, no identificador de chamadas do outro
aparelho, como o nmero que est chamando.
Portanto com essa configurao uma estao remota, como um telefone IP, ir saber o nome e
nmero que est chamando.
Vamos praticar - FXS

Veja outro exemplo de configurao completa ao lado e responda:
Foi configurada a primeira ou segunda porta FXS do roteador? A placa possui duas portas.
De que pas essa porta vai esperar receber a sequncia de tons?
A sinalizao que ela vai utilizar ser a _______
Quando esse telefone ligar para um telefone IP com display ele ver que a chamada est vindo
do nmero _______
Foi configurada a primeira ou segunda porta FXS do roteador? A placa possui duas portas.
Na segunda porta, pois a primeira a 3/0
Do Canad cptone CA
Loop start signal loopstart
Quando esse telefone ligar para um telefone IP com display ele ver que est vindo pelo
nmero _______
Ver em seu display o nmero 5001333
Configurando uma porta FXO

Agora vamos analisar a configurao da FXO, a qual utilizada para conectar uma central telefnica
pblica ou privada a dois fios. Veja na figura abaixo a topologia tpica de uso de uma placa FXO.
Os primeiros comandos para configurar uma porta FXO so os mesmos que utilizamos na FXS para a
sinalizao e definio do caller-id, veja a configurao abaixo:
Porm, lembre que a FXO se conecta a central, portanto ela deve simular como se fosse um
telefone, ou seja, ela recebe um ring e deve atender a ligao vinda da central pblica ou privada.
Portanto temos que definir aps quantos toques a porta FXO deve atender a ligao com o comando
ring number e tambm se ela vai utilizar a troca de dgitos com a central atravs de DTMF
(tom) ou decdico (pulsado) com o comando dial-type. A diferena entre a do envio dos dgitos
atravs de DTMF e o decdico que o primeiro utiliza uma combinao de frequncias para
representar os dgitos, j o decdico a sinalizao antiga utilizada pelos telefones que tinham o disco
ao invs de teclas.
Por padro a placa FXO atende a ligao com um toque, portanto vamos fazer um exemplo ao lado
em que a porta FXO ser configurada como DTMF e para atendimento aps 3 toques.
Vamos praticar - FXO

Veja outro exemplo de configurao completa ao lado e responda:
Foi configurada a primeira ou segunda porta FXO do roteador? A placa possui duas portas.
Se eu conectar a uma central que trabalha sinalizao pulsada (decdico) a placa no vai
funcionar nessa configurao atual. A afirmao verdadeira ou falsa?
A porta FXO vai demorar mais que o padro para atender a chamada. A afirmao verdadeira
ou falsa?
Foi configurada a primeira ou segunda porta FXO do roteador? A placa possui duas portas.
A primeira porta, a numerao como na serial ou fast, ou seja, a primeira a 2/0 e a segunda
a 2/1
No padro brasileiro cptone BR
Loop start signal loopstart
Se eu conectar a uma central que trabalha com decdico a placa no vai funcionar nessa
configurao atual. A afirmao verdadeira ou falsa?
Verdadeira, pois foi configurado o DTMF e no decdico no comando dial-type.
A porta FXO vai demorar mais que o padro para atender a chamada. A afirmao verdadeira
ou falsa?
Verdadeira, o padro atender no primeiro toque e foi configurado para atender no quarto
toque com o comando ring number 4.
Informao adicional para uso no seu dia-a-dia de campo.

Existem diversos comandos adicionais que podem ser utilizados na configurao de uma porta FXO.
Esses comandos devem estar de acordo com o tipo de porta da central telefnica e podem variar de
operadora para operadora, de um modelo de central para outro e por a vai..."Alinhar" uma porta FXO
para perfeito funcionamento nem sempre uma tarefa fcil.
No nvel da prova do ccna voice os comando mostrados anteriormente so suficientes para o sucesso
na prova. Mas como o objetivo do curso no s prepar-lo para a prova, mas tambm para o mundo
real, iremos a seguir colocar alguns templates de configurao de FXO que podem lhe ajudar no seu
dia-a-dia.
Segundo nossa experincia de campo, o template 1 deve funcionar em 95% dos casos. Para os 5%
restante tente um dos outros templates.
Configurando Portas de Voz Digitais

As portas digitais T1 e E1 da Cisco so fornecidas em mdulos WAN chamados VWIC ou Voice Wan
Interface Card com uma ou duas portas. Isso porque as portas E1 e T1 podem ser utilizadas tanto
para passar dados como voz pelas operadoras de telecomunicaes para seus clientes finais. Voc
pode, por exemplo, comprar um circuito E1 com 15 canais (time slots) para voz e 15 canais para dados
(15 canais DS0s de 64kbps -> 15*64= 960kbps).
Diferente das placas analgicas, que so praticamente plug and play, as placas de dados precisam
de umaconfigurao especfica para funcionar, a qual depende da prestadora de servios de
telecomunicaes ou PABX que ser entroncado (conectado via E1/T1) com o roteador.
Conforme vimos no captulo 2, uma interface E1/T1 pode utilizar dois tipos de sinalizao:
sinalizao por canal associado (channel associated signaling - CAS) ou sinalizao por canal
comum (common channel signaling CCS)". Alm disso, a sinalizao CSS conhecida como ISDN
Primary Rate Interface ou PRI. Portanto, o tipo de rede que voc vai conectar o seu roteador
(entroncar com a central) que vai determinar os comandos de configurao que voc precisa inserir
na sua placa VWIC, ou seja, utilizando ds0-group (grupo de ds0 ou time-slots)

para E1/T1 com sinalizao CAS ou conexo via pri-group (o pri relacionado ao ISDN PRI)
parasinalizao CCS.
Informao extra sobre ISDN:

RDIS (acrnimo para Rede Digital Integrada de Servios ou Rede Digital com Integrao de Servios)
ou RDSI (Rede Digital de Servios Integrados), tradues alternativas do ingls ISDN (Integrated
Service Digital Network), uma tecnologia que usa o sistema telefnico passando, tanto a sinalizao
como a voz, em formato digital entre a central telefnica e o aparelho do usurio (telefone RDSI).
O ISDN j existe a algum tempo, sendo consolidado nos anos de 1984 e 1986, sendo umas das
pioneiras na tecnologia xDSL. H dois tipos de acesso baseados em RDSI: BRI (Basic Rate Interface
com uma velocidade de 64 ou 128kbps) e PRI (Primary Rate Interface T1 ou E1).
Configurando uma Interface T1-CAS
Vamos agora mostrar a configurao de um link T1 com a PSTN utilizando os 24 canais para voz e
com sinalizao CAS.
Para iniciar as placas E1/T1 so chamadas no IOS da Cisco de controladoras ou controllers, por isso
para configurar os links E1 e T1 devemos entrar em modo de configurao global com o comando
controller E1 ou controller T1 e o nmero da porta da controladora.
Para facilitar e verificar o nmero que foi dado porta ou s portas, caso a placa tenha mais de uma
porta, entre com o comando show running-config e verifique a numerao, lembrando que a
contagem comear em zero. Por exemplo, se uma controladora T1 com duas portas fosse instalada no
slot zero de um roteador a primeira porta seria a controller T1 0/0/0 e a segunda seria controller
T1 0/0/1. O mesmo vale para uma controladora E1.
Basicamente, para uma controladora T1 temos que definir os seguintes parmetros:
1. Framing ou enquadramento: qual o formato do quadro T1.
2. Linecode ou o cdigo de linha: qual o tipo de cdigo de linha ser utilizado para enviar os
dados na camada fsica da interface.
3. Clock source ou a origem do clock (sincronismo): o sincronismo pode ser interno, externo ou a
placa pode sincronizar utilizando o clock da operadora, atravs da linha.
4. Definir a sinalizao (CAS ou CCS) e os time-slots (ds0) que sero utilizados.
Antes de iniciarmos a configurao vamos verificar o estado atual da placa com o comando show
controllers T1 e o nmero da porta. Acompanhe a sada abaixo:
Note que a porta est utilizando quadro (framing) SF,origem de sincronismo (clock) atravs da linha,
ou seja, sincronizando com a operadora.
Obs: Nos Estados Unidos o padro da maioria das operadoras de telecom utilizando extended
super frame (ESF) para o enquadramento e cdigo de linha B8ZS(linecoding). Alm do mais, em
nosso exemplo devemos utilizar sinalizao CAS utilizando o tipo fxo-loop-start para os ds0. Por isso,
vamos ver como acertar a configurao logo a seguir.
Primeiramente definimos o enquadramento atravs do comando framing, depois passamos para o
comando clock source line, o que faz com que o roteador sincronize com o clock a partir da linha
T1, ou seja, sincronize com o clock da Operadora de Telecom.
Obs: Caso voc entronque o roteador com um PABX, normalmente o roteador fica como internal e
o PABX que ir sincronizar com o roteador, utilizando o comando clock source internal.
Como pretendemos utilizar o CAS configuramos o ds0-group 1, escolhemos os time slots (timeslot)
de 1 a 24para passar os canais de voz.
Note tambm que dentro do comando "ds0-group 1" ns configuramos o tipo de sinalizao utilizado
pelo CAS(type fxo-loop-start), o que possibilita o roteador se conectar com diferentes tipos de
redes e centrais telefnicas. Normalmente a PSTN utiliza a sinalizao FXO loop start quando
utilizamos T1 CAS nos Estados Unidos, porm isso pode variar de operadora para operadora. Em
sistemas privados (PABX) pode haver a necessidade de configurar a sinalizao utilizando Ear and
Mouth (E&M), a qual o roteador suporta diversos tipos diferentes.
Esses parmetros so passados pela operadora de telecomunicaes ou pelo fabricante do PABX, em
caso de entroncamento com uma central privada.
Informao extra:
Em nosso exemplo estamos utilizando todos os 24 time-slots para voz, por isso, configuramos todos
dentro no DS0 group 1 (ds0-group 1 timeslots 1-24 type fxo-loop-start). Perceba que configuramos
como sendo o group 1, sendo que poderamos escolher qualquer valor entre 0-23. Essa tag atua como
um identificador para os timeslots que voc ir configurar dentro desse grupo.
Na verdade, voc pode configurar uma interface T1 para muitos propsitos. Por exemplo, se voc
tivesse um link T1 com 5 time slots para dados (1 at 5) e 19 timeslots para voz (6 at 24), voc teria
que criar dois ds0-group, um para os time slots 1 a 5 e outro para os time slots de 6 a 24.
Depois que a configurao foi finalizada, com o comando show voice port summary voc consegue
ver todas as portas que o sistema provisionou para voc (de 1 a 24). As portas so listadas
como 1/0:1, sendo que o 1/0 representa a interface fsica e o :1 representa o nmero do ds0groupcriado. Cada porta dessas representa um canal dentro do T1 e voc dever lembrar-se disso
para poder configurar os dial-peers. Veja a sada do comando abaixo:
Configurando uma Interface T1-CCS

Quando utilizamos uma interface digital T1/E1 com asinalizao CCS (ISDN PRI) para entroncar o
roteador com a PSTN a configurao parecida com o que utilizamos no CAS. Veja abaixo um
exemplo de configurao dos 24 time slots utilizando uma placa VWIC com sinalizao PRI para
conectar PSTN.
Perceba que a primeira etapa na configurao quando utilizamos o CCS definir o tipo de switch
ISDN que estamos nos conectando (ISDN switch type). Esse parmetro normalmente passado pela
operadora de telecom e no exemplo utilizamos o primary-5ess, padro comumente utilizados nos
Estados Unidos. No Brasil o padro mais comum o primary-net5.
Depois de configurado o tipo de switch ISDN devemos configurar o pri-group e definir os time slots
que vamos utilizar. Nesse comando, porm no tem o tipo de sinalizao, pois o roteador assume a
sinalizao ISDN PRI.
Informao extra:
Nos exemplos mostrados para configurao da interface T1 CAS ou CSS assumimos que nosso
roteador possuia recursos suficientes de Digital Signal Processor (DSP)para tratar todos time-slots
configurados.
Caso no houvesse DSP suficiente o roteador iria exibir uma mensagem de erro na hora de configurar
o pri-group ou o ds0-group, informando exatamente quantos canais o roteador poderia suportar.
Com o comando show voice port summary aps a configurao podemos verificar que o roteador
criou 24 portas de voz ISDN (voice ports) que sero utilizadas tanto para chamadas entrantes como
saintes. As portas sero identificadas como 1/0:23, sendo que o canal 23 (time slot 24) do link T1 ISDN
PRI ser utilizado somente para passar a sinalizao. J os canais numerados de 023 (time slots de 1
24), sero dedicados para voz e totalizando 23 canais. Veja a sada do comando ao lado.
Obs: Lembre que quando utilizamos um link T1 o canal 23 (time slot 24) sempre ser utilizado para
sinalizao CCS, j quando utilizamos interfaces E1 o canal 16 (time slot 17) ser utilizado para
sinalizao.
Exemplo prtico de configurao de uma interface E1 CAS e R2-Digital (padro Brasil)

O Link T1 utilizado no Japo, Estados Unidos e Canad, porm quando falamos de Brasil utilizamos
interfaces E1, normalmente com CAS e sinalizao R2-Digital (uma variante do CAS) ou ento CCS com
a sinalizao ISDN PRI. Vamos mostrar agora um exemplo prtico de configurao de uma
controladora E1 seguindo padres nacionais para que voc possa desempenhar melhor suas funes
como CCNA Voice.
Antes de iniciar as configuraes interessante saber algumas caractersticas do link E1:
Conexo fsica pode ser feita via cabo coaxial(impedncia 75 ohm) ou par
metlico (impedncia 120 ohm). As placas da Cisco vem com um conector RJ-45 e se voc for
utilizar cabo coaxial ele tem uma ponta RJ-45 e uma sada em BNC (conector coaxial).
O cdigo de linha mais utilizado no Brasil o HDB3, porm utilize o padro recomendado pela
Operadora.
O quadro do E1 um s, diferente do T1 que tinha dois tipos. Porm no comando framing
podemos escolher se o E1 vai ou no fazer uma checagem de erros chamada CRC-4. Configure
seu roteador de acordo com o padro da operadora.
O canal utilizado para a sinalizao o 16, no se esquea desse detalhe quando configurar o
ds0-group.
Sobre a sinalizao, normalmente a utilizada o R2-digital.
Vamos iniciar analisando o estado da controladora com o comando show controllers mais o
nmero da interface (voc pode ver com o show running-config).
Agora vamos mostrar a configurao da interface E1, onde utilizamos os seguintes parmetros:
Enquadramento no utilizando CRC-4 (framing no-crc4)

Sincronizao com a linha da operadora (clock source line)
Cdigo de linha HDB3 e utilizando cabo coaxial
Sinalizao padro Brasil com R2-Digital
Informao extra:
O template de configurao mostrado anteriormente deve funcionar na grande maiorias dos casos.
Segundo nossa experincia, alguns links, especialmente da Operadora Telefnica, precisam de um
parmetro adicional para que uma chamada vinda da PSTN para dentro da sua rede seja recebida.
Esse parmetro seizure-ack-time 50.
Ento fica a dica. Se voc estiver entroncando uma porta E1 com um link da telefnica e perceber que
as chamadas de fora (PSTN) do sinal de re-chamada e no entram no roteador, tente esse comando.
controller E1 0/2/0
framing NO-CRC4
line-termination 75-ohm
ds0-group 1 timeslots 1-15 type r2-digital r2-compelled ani
cas-custom 1
country brazil
metering
release-guard-time 100
seizure-ack-time 50
release-ack
answer-signal group-b 1
!
Entendendo e Configurando Dial-Peers
No mdulo anterior vimos como configurar as portas de voz digitais e analgicas que nos permitem
contato com o mundo exterior, seja com a rede pblica de telefonia (PSTN) ou com um PABX
convencional.
Agora, temos que adicionar as rotas para podermos utilizar essas sadas. Essas rotas so similares
a rotas estticas dos roteadores, elas so configuradas pelo administrador de redes de maneira
esttica e definem os destinos que podemos alcanar, porm agora atravs de um nmero telefnico
e no mais um endereo IP.
A entidade que permite essa configurao das rotas ou planos de discagem (dial plan) so os Dial
Peers (em portugus pares de discagem), pois um roteador CME sabe somente como alcanar os
ephone-dn, os quais criamos no captulo anterior, porm no sabe como utilizar as demais
interfaces ou encontrar sozinho as rotas para cada destino. Portanto o dial-peer uma entidade de
configurao (lgica) que define a alcanabilidade da rede de voz sobre o protocolo IP.
Os dial-peers podem ser de dois tipos:
Plain Old Telephone Service (POTS dial-peer voice pots): define a numerao ou plano de
numerao para que possamos sair para a rede de voz utilizando conexes tradicionais
analgicas ou digitais (quaisquer dispositivos conectados a portas analgicas FXS, FXO, E&M ou
portas digitais T1/E1).
Voice over IP (VoIP - dial-peer voice voip): define o alcance a dispositivos da rede VoIP
(qualquer dispositivo que seja alcanvel via endereamento IP).
Resumindo o conceito:
Parte essencial na elaborao de um Plano de Discagem(ou Dial Plan), os dial-peers so utilizadas
para criar o plano de roteamento de chamadas dentro de um ambiente VoIP.
Portanto, podemos dizer que um dial-peer uma rota utilizada para realizar o encaminhamento de
chamadas de voz. Podemos tambm fazer uma analogia de uma dial-peer com a configurao de uma
rota esttica, do qual para se chegar a um determinado destino deve-se encaminhar o pacote IP para
um next-hop (prximo salto), porm ao contrrio das estticas que utilizam apenas endereos IP para
fazer o roteamento, os dial-peers utilizam sequencias de dgitos (nmeros de telefone discados) para
realizar o roteamento dentro da rede VoIP.
Entendendo o conceito das Call legs

Para poder configurar os dial peers voc deve primeiro entender o conceito das call legs (pernas de
uma chamada). Uma call leg uma conexo que pode ser originada ou recebida por um gateway de
voz seja ela a partir da PSTN ou da prpria rede VoIP.
Uma analogia para entendemos os call legs que elas so os saltos que uma chamada tem que dar
para chegar a um destino. Vamos utilizar como exemplo a topologia da figura abaixo:
Nesse cenrio o ramal 1101 quer ligar para o ramal 2101. Veja que o 1101 est conectado a um
roteador e para chegar ao 2101 ter que passar por mais um voice gateway para chegar ao PABX
onde ele est conectado via um link T1. Portanto aqui teremos quatro call legs, conforme abaixo:
Call leg 1: Call leg entrante via POTS do ramal 1101 no DLTEC-A (placa FXS).
Call leg 2: Call leg de VoIP sainte do roteador DLTEC-A para o DLTEC-B.
Call leg 3: Call leg de VoIP entrante no DLTEC-B vinda do roteador DLTEC-A.
Call leg 4: Call leg sainte do tipo POTS do para o ramal 2101 a partir da interface T1 do DLTEC-B.
Se a chamada fosse feita do 2101 para o 1101 o nmero de call legs seria o mesmo, porm em sentido
contrrio. Na realidade, como a comunicao bidirecional ns vamos ter 8 call legs, 4 para o sentido
DLTEC-A -> DLTEC-B e mais quatro no sentido contrrio.
Porque importante aprender o conceito de call leg ento? Porque os dial peers tero que ser
configurados de maneira a permitir essas conexes, um para cada call leg. Para cada call leg que
temos um dial peer que teremos que configurar no roteador.
Alm disso, os peers vo alm de definir o alcance do VoIP (nmeros de telefone), definem tambm o
caminho que o udio (atravs de pacotes RTP) devem seguir. Para o roteador DLTEC-A ele recebe o
audio da porta FXS que tem o ramal 1101 (call leg 1), ento repassa essa informao via RTP atravs
da rede para o IP 11.1.1.2 (call leg 2). No roteador DLTEC-B essa chamada vem do ramal 1101 atravs
de seu IP da interface de rede WAN (call leg 3). Por ltimo, ele precisa repassar essa chamada ao
PABX atravs da sada digital T1, cuja interface a 1/0 (call leg 4).
Voc ter que criar dial peers de retorno para que a comunicao bidirecional ocorra, pois seno
teremos somente o 2101 ouvindo e o 1101 sem ouvir o que o 2101 fala, portanto tem que haver um
dial peer de retorno no DLTEC-B. J para os dial peers POTS, como o da FXS que o ramal 1101 est
configurado, no preciso configurar um dial peer de retorno, pois os dial peers POTS so
bidirecionais. Resumindo, tudo que vai pela rede IP tem que voltar.
A seguir veremos como configurar os dial peers POTS para comunicao com a PSTN ou PABX
convencional e VoIP, para comunicao atravs o mundo IP.
Importante:
Lembre que para todas essas converses de analgico para digital ou converso de padro
(transcoding) o roteador precisar de DSP, caso ele no tenha recurso suficiente ele no processar as
chamadas que excederem sua capacidade.
Configurando Dial Peer POTS
O dial peer do tipo POTS utilizado para configurar rotas para elementos da telefonia convencional,
os quais no possuem um endereo IP, tais como telefones analgicos, aparelhos de fax, um PABX ou
para a PSTN utilizando interfaces de voz FXO, FXS, E&M e conexes digitais BRI, T1 e E1.
Abaixo temos uma topologia tpica onde o roteador DLTEC-A tem duas portas FXS, ligadas aos ramais
1000 e 1001, e mais uma porta FXO conectada PSTN. J o roteador DLTEC-B tem uma placa T1 com
sinalizao CCS (PRI) conectada a uma central privada (PABX) e mais uma linha FXO conectada rede
pblica. Portanto as duas localidades podem se comunicar utilizando a rede WAN atravs da rede IP
11.1.1.0/30 ou atravs da PSTN, porm via PSTN ter o custo de uma chamada telefnica, ao passo
que pela rede IP essa ligao no ter custo adicional, pois utiliza os recursos j implementados para
comunicao IP via rede WAN.
Vamos ver ento como configurar os dial peers POTS para cada um dos roteadores da topologia,
considerando que as interfaces fsicas j foram configuradas com os parmetros passados pela
Operadora e padres do PABX, conforme tpicos anteriores desse captulo.
Para criar os dial peers POTS utilizamos o comando dial-peer voice <identificador> pots em modo
de configurao global. O valor do identificador ou tag pode ser um nmero de 1 at 2.147.483.647
e deve ser nico para cada dial peer criado no roteador.
Esta numerao do tag no tem nada haver com o ramal, mas alguns administradores utilizam o
nmero do ramal ou faixa para identifica-lo, assim facilita a manuteno. Outro ponto importante
que a partir desse nmero que voc pode depois alterar ou verificar a configurao.
Vamos iniciar criando os dial peers pots relativos s portas FXS do roteador DLTEC-A, onde o nmero
do telefone foi configurado com o comando destination-pattern e definimos que porta da FXS ter
aquele ramal configurado, ou seja, vinculamos o dial peer porta fsica, com o comando
port. Nesse ponto, se voc digitar 1001 a partir do telefone que est conectado porta 0/0/0 da
FXS do roteador o telefone que est na porta 0/0/1 ir tocar.
Agora que o dial peer est criado, para alterar a configurao ou deletar no precisa mais digitar o
comando inteiro, voc pode entrar no dial peer digitando apenas dial-peer voice 1000 e para
apagar digite no dial-peer voice 1000.
Com o comando show dial-peer voice (sem a opo summary) voc pode ver detalhes sobre o
dial peer, porm para cada um voc ter mais de uma pgina de informao.
Algumas vezes voc ter que utilizar esse comando para verificar informaes avanadas sobre o
estado do dial peer, porm com o show dial-peer voice summary por enquanto teremos as
informaes necessrias para verificar as configuraes realizadas. Veja a sada do comando abaixo:
Os dois dial peer criados com as tags 1000 e 1001 esto mostradas no final da configurao. Os outros
dial peers listados (com as tags de 20005 a 20014) foram criados pelo CME para identificar os ephonedns, conforme vimos no captulo anterior.
Agora voc pode testar ligando de um ramal para outro, inserindo antes o comando debug voip
dialpeer. Esse comando permite que voc veja o progresso da chamada e os nmeros discados.
As principais mensagens esto marcadas e comentadas na sada do comando debug para mostrar
como o roteadorprocessa a chamada dgito a dgito.
Note que a cada dgito discado o roteador verifica se existe uma correspondncia nos dial peers
configurados. Para os trs primeiros dgitos discados existe um resultado bem claro: more digits
needed ou so necessrios mais dgitos. Quando o quarto dgito discado o roteador encontra
correspondncia (match) com o dial-peer identificado com a tag 1001 e processa a chamada.
Agora que configuramos as interfaces FXS do roteador DLTEC-A vamos configurar o dial peer
POTS referente aoT1 no DLTEC-B. Esse T1 tem uma conexo via sinalizao PRI com o PABX quem tem
os ramais iniciando em 5XXX, ou seja, quatro dgitos iniciando pelo nmero cinco. Lembre que
configuramos anteriormente nesse captulo a interface T1 e uma voice port foi criada como nmero
1/0:23, o que representa o link T1 PRI disponvel para conexo com o PABX. Vamos s configuraes.
Nesse exemplo, ao contrrio do que fizemos para o dial peer da porta FXS, no definimos um nmero
para o tronco E1 e sim uma faixa de ramais que iniciam em 5 e os demais dgitos podem ser quaisquer
um inserindo o ponto (.) como mscara curinga no comando destination-pattern. A porta de
destino (comando port) vinculamos interface T1 1/0:23.
Sobre o comando no digit-strip, ele faz com que o roteador no retire os dgitos explcitos na regra
ao ocupar o canal T1, ou seja, esse comando faz com que o roteador B envie todos os dgitos discados
para o PABX para que ele possa encaminhar a chamada para o ramal correto.
Existe uma regra configurada no roteador que faz com que ele retire os dgitos (digit strip) que esto
explcitos antes de encaminhar a chamada para um dial peer do tipo POTS e o comando no digitstrip anula essa comportamento. Ou seja, com o comando "no digit-strip" o roteador ir enviar todos
os dgitos discados ao PABX, por exemplo, 5001. Sem o comando "no digit-strip" ele enviaria somente
001, pois o dgito 5 est explcito na regra e no seria enviado.
Se no utilizssemos esse comando o PABX no saberia para quem encaminhar a chamada pois ele
no receberia o primeiro dgito 5, o qual est configurado de uma maneira explcita, encaminhando
apenas os trs ltimos dgitos.
Esse comportamento (digit-strip) interessante quando fazemos encaminhamento de chamadas para
a PSTN, onde normalmente digitamos um caractere para representar a linha externa como o 9 ou
0. Por exemplo, se utilizssemos o 9 para utilizar a linha externa e queremos ligar para o nmero
30457810, portanto teremos que digitar 930457810, pois temos um destination-pattern
configurado com a mscara 9........ no roteador para sada para PSTN. Quando fizermos a discagem
o roteador vai retirar o 9, que est explcito na configurao, e passar apenas o 30457810 para a
PSTN, a qual vai encaminhar a chamada corretamente.
Vamos ento agora configurar os roteadores DLTEC-A e o DLTEC-B para que ele utilize a interface
FXO como sada para ligaes externas locais, onde no Brasil utilizamos nmeros de 8 dgitos, e o
dgito para pegarmos a linha externa ser o zero (0).
Obs: O digit-strip atua somente em dial-peer pots. Em um dial-peer voip esse comportamento no
existe e o roteador ir sempre encaminhar todos os dgitos digitados.
Portanto, agora que j resolvemos como encaminhar as chamadas para nossos dispositivos
convencionais, sejam eles digitais ou analgicos, precisamos fazer os roteadores utilizarem a rede IP
para fazer chamadas VoIP, assunto que vamos discutir no prximo logo a seguir.
Configurando Dial Peer VOIP
Vamos voltar ao nosso cenrio do tpico anterior e finalizar a configurao da nossa rede adicionando
a capacidade dos roteadores encaminharem as chamadas utilizando a rede IP atravs de dial peers
voip. So os dial peers voip que iro nos ajudar a cruzar a rede IP para completar uma chamada.
Portanto, nossa misso agora ensinar ao roteadorDLTEC-A alcanar os ramais que iniciam em 5000
atravs da rede WAN e ao DLTEC-B que os ramais 1000 e 1001 esto configurados no roteador DLTECA. Veja a configurao abaixo:
O destination-pattern continua o mesmo, porm veja que voc ensina para o DLTEC-A como chegar
faixa de ramais 5000 a 5999 (5...) e para o DLTEC-B a como chegar nos ramais 1001 e 1002 (100.).
A primeira diferena entre um dial peer POTS e VoIP vem a seguir no comando session target, o
qual substitui o comando port, pois agora no temos mais o dial peer ligado a uma porta fsica e sim
a uma entidade lgica, a qual utilizamos o subcomando ipv4:<ip address> para definir o endereo IP
do roteador remoto que tem aquela numerao telefnica que o roteador deseja alcanar. Esse
comando tambm permite o uso de nomes de DNS (utilizando dns:<name>) ou gerenciadores de
chamada como gatekeepers H.323 ou Session Initiation Protocol (SIP) proxy servers (servidores proxy
SIP). Clique em "Informao adicional" que est localizado lateral superior direita da pgina e veja
importantes informaes sobre os protocolos de sinalizao.
Por ltimo, aps definir o roteador de destino vamos definir o tipo de codificao a ser utilizada com
o comando codec. Ao definir o codec como g711ulaw, cada vez que o roteador for fazer uma
chamada por aquele dial peer utilizar o padro G.711 atravs da lei-A (padro americano). Isso
significa que a chamada ter mais de 64kpbs de ocupao de banda, pois somente o codec utiliza
64kbps e se somarmos mais os cabealhos do IP, TCP e camada 2 teremos uma banda final maior que
64kbps.
Caso os codecs no estejam configurados corretamente entre os roteadores, ou seja, se eles no
baterem voc receber um tom de ocupado e a chamada no ser completada. O codec padro para
VoIP dial peers o G.729.
Quando configuramos o dial peer 1000 no DLTEC-B utilizamos o destination-pattern 100. para
direcionar a chamada para os ramais 1000 e 1001, porm voc poderia criar dois dial peers para
encaminhar essas chamadas, um para cada ramal, que teramos o mesmo efeito.
Outro detalhe que podemos utilizar tags ou identificadores para dial peers iguais nos dois
roteadores, por exemplo, o dial peer voice 1000 pots para as interfaces FXO. Isso no tem problema
algum, pois essa indicao local. O que voc no pode fazer tentarutilizar o mesmo nmero (tag)
no roteador para funes diferentes, pois a ltima configurao que voc inserir vai apagar a
anterior.
Informao Importante:
H.323: Conjunto de protocolos criados pela ITU-T para permitir comunicao multimdia (udio/voz
em tempo real, vdeo e dados) atravs de ambientes de rede de pacotes. O protocolo H.323 muitas
vezes chamado de protocolo guarda-chuva, pois embaixo dele temos diversos outros protocolos
cada um tratando de uma rea especfica da comunicao multimdia. Para mais informaes copie e
cole no seu navegador o endereohttp://pt.wikipedia.org/wiki/H.323
Media Gateway Control Protocol (MGCP): Protocolo de sinalizao de voz criado pela IETF, o qual
permite que gateways de voz sejam controlados por um call agent centralizado em um modelo
cliente/servidor. Normalmente esses agentes chamados call agents controlam dispositivos finais
(edge devices / dispositivos dos usurios) que podem ter um custo menor pela inteligncia do
sistema estar centralizada e no nos dispositivos dos usurios. Para mais informaes copie e cole no
seu navegador o endereo http://pt.wikipedia.org/wiki/Mgcp
Skinny Client Control Protocol (SCCP): Protocolo de sinalizao proprietrio da Cisco utilizado para
controlar os telefones IP Cisco. O SCCP tambm pode controlar portas analgicas (FXS) como um
servio complementar para os gateways de voz (Supplementary Features in Cisco IOS Gateways)
atravs de um servidor Cisco Unified Communications Manager ou Cisco Unified Communications
Manager Express (Cisco Unified CME). Assim como o MGCP a inteligncia do SCCP est centralizada
no CUCM ou CME, tornando os telefones IP Cisco equipamentos burros que passam as informaes
para que o controlador de chamadas tome as decises.
Session Initiation Protocol (SIP): Protocolo de sinalizao de voz criado pelo IETF como uma
alternativa mais leve que o protocolo H.323. Utiliza nas suas trocas de mensagem uma forma
modificada do esquema de URLs utilizado na troca de e-mails pelo SMTP (Simple Mail Transfer
Protocol). Para mais informaes copie e cole no seu navegador o
endereohttp://pt.wikipedia.org/wiki/Session_Initiation_Protocol
Os gateways da Cisco podem suportar todos os protocolos citados acima dependo da verso de IOS e
feature set instalada nele. J os telefones IP da Cisco suportam normalmente o SCCP e/ou SIP, porm
voc deve verificar no datasheet de cada equipamento qual protocolo suportado.
Mscaras Curingas e Dial Peers (wildcards)
J vimos uma wildcard na sesso anterior, a qual a mais comum de utilizarmos, o ponto (.).
A wildcard "." representa quaisquer dgitos. Esses caracteres especiais chamados wildcards nos
ajudam a reduzir o tempo configurando dia peers, pois acabam simplificando a configurao.
Imagine a configurao para apontar um dial peer para a faixa de ramais do PABX do exemplo da
sesso anterior (de 5000 a 5999)? Voc consegue perceber que sem o uso da wildcard "."
precisaramos de mil dial peers? Porm, com o uso do ponto configuramos um s, explicitando o
primeiro dgito "5" e colocando o ponto para representar os demais trs dgitos, os quais podiam ser
quaisquer um de 0 a 9, ficando destination-pattern 5....
Abaixo vamos descrever os caracteres que podem ser utilizados como wildcards.
Ponto (.): Aceita correspondncia (match) com quaisquer dgitos de 09 ou a tecla * do teclado do
telefone.
Sinal de mais (+): Indica que o dgito anterior pode ocorrer uma ou mais vezes, por exemplo, se
utilizarmos 5+23 em um destination pattern ele faz correspondncia com 5523, 55523, 555523 e
assim por diante. Essa sequncia vai no mximo at 32 dgitos, o qual o maior tamanho de um
nmero de destino digitvel.
Colchetes ([]): Corresponde a um range ou faixa de dgitos, por exemplo, [1-4]33 pega os nmeros
133, 233, 333 e 433. Voc pode utilizar o acento circunflexo (^) para indicar nmeros que no
correspondam faixa configurada (does not match range). Por exemplo, [^1-4]33 aceita
correspondncia quando for discado 033, 533, 633, 733, 833, 933 e *33. Ou seja, o primeiro dgito s
no pode ser de 1 a 4.
T: Aceita correspondncia de quaisquer nmeros discados com at 32 dgitos. Nesse caso se voc
digita um nmero com 8 dgitos ter que esperar o temporizador acabar, pois voc pode digitar at 32
dgitos e h uma espera configurada no sistema. Para digitar os 8 dgitos e fazer o roteador parar essa
espera (contador) e realizar a chamada basta digitar a tecla sustenido (#) do telefone, em ingls tecla
pound. Esta espera chamada de timeout interdigit e por padro so 10 segundos.
Vrgula (,): Insere 1 segundo de pausa entre os nmeros discados.

Dica: A Cisco recomenda ao utilizar o T como destination-pattern que seja criado como .T. Isso
exige que pelo menos um dgito seja discado para alcanar o destination-pattern, seno caso o
telefone fique muito tempo deixado fora do gancho sem nenhum dgito discado o roteador acabar
fazendo uma correspondncia com o destination pattern.
Quando um nmero discado e ele corresponde a um destination-pattern configurado, esse processo
chamado de match em ingls, importante entender esse conceito e saber o significado desse
termo em ingls. Em portugus dizemos que o nmero discado bateu ou teve correspondncia
com o destination-pattern configurado.
Normalmente as wildcards com colchetes so as mais difceis, por isso seguem alguns exemplos para
facilitar a compreenso. Acompanhe os exemplos abaixo:
1. 555[1-3]... ?
Essa sequncia faz correspondncia quando os trs primeiros nmeros discados forem 555, tendo
como quarto dgito 1, 2 ou 3, e para os ltimos 3 dgitos podemos ter de 0 a 9 ou *. Totalizando um
nmero discado de 7 dgitos.
2. [14-6]555 ?
Nesse segundo exemplo temos um nmero de 4 dgitos, sendo que o primeiro dgito pode ser os
nmeros 1, 4, 5 ou 6 e os ltimos 3 dgitos obrigatoriamente devem ser 555.
3. 55[59]12 ?
Agora temos um nmero com 5 dgitos que sempre deve iniciar com 55, o terceiro dgito deve ser 5
ou 9, e os dois ltimos dgitos devem ser 12.
4. [^1-7]..[135] ?
Essa ltima mais complexa. Antes de ver a resposta tente achar voc mesmo a que nmeros
discados essa wildcard faz correspondncia (quantos dgitos e que dgitos precisam ser discados para
ter correspondncia?). Primeiro, so 4 dgitos e nessa wildcard teremos uma correspondncia quando
no primeiro nmero discado for diferente de 1 a 7 (^1-7), os outros dois dgitos podem ser quaisquer
um (..), j o quarto dgito pode ser os dgitos 1, 3 ou 5.
Smbolo Circunflexo (^):
Quando utilizado entre colchetes, permite que vocelimine um dgito da correspondncia. Por
exemplo, um destination pattern incluindo [^7] no corresponde a nenhuma string que comea com
7, em outras palavras, ir dar correspondncia apenas nas strings que no iniciam com 7. Voc
tambm pode utilizar mais de um dgito dentro do colchetes, por exemplo, o destination pattern
[^4^5^6] elimina as strings que iniciam com 4,5 ou 6.
Importante: cuidado ao elaborar as wildcards, pois um destination pattern do tipo [^752] permite a
correspondncia apenas com strings que iniciam com 5 ou 2 e que no iniciam com 7. Ora, perceba
que isso o mesmo que utilizar somente [52]. Para eliminar mltiplos dgitos na sua regra voc deve
utilizar cada dgito em um colchete separado, por exemplo, para eliminar as strings que iniciam com o
padro 543 voc deve utilizar a wildcard [^5][^4][^3].
Essas mscaras (wildcards) so na maioria das vezes utilizadas para criar planos de discagem para a
PSTN. Como j foi comentado nesse captulo a forma menos trabalhosa (mas no a melhor) de se
configurar a sada para a PSTN utilizar um destination-pattern 9T (9 para pegar a sada externa e o T
para aguarda os dgitos que sero discados pelo usurio com um nmero de telefone vlido na PSTN).
No Brasil mais comum utilizarmos o zero como sada para a PSTN (destination-pattern 0T).
O problema nesse caso que a Cisco projetou a mscara Tpara dar correspondncia com nmeros de
tamanho varivel de 0 a 32 dgitos. Por isso, quando um usurio digitar, por exemplo,
0214130457810 o roteador configurado com a mscara 0T ficar esperando em silncio o usurio
digitar mais nmeros (pois o roteador est esperando 32 dgitos). Por padro esse tempo de
espera chamado interdigit timeout (tambm conhecido como temporizador ou timer T302) de 10
segundos. Claro que, conforme j falado anteriormente nesse captulo, o usurio pode forar o
roteador a iniciar o processamento da chamada digitando o nmero desejado e em seguida teclando
o sustenido do telefone (pound key -#). Mas isso traz a necessidade de um treinamento ou instruo
extra para os usurios e na maioria das vezes os usurios iro estranhar essa nova maneira de discar e
podem comear a reclamar.
Para evitar esse tempo de silncio por espera da finalizao voc pode mudar os timers ou criar
mscaras diferentes do 0T para acesso PSTN, tarefa que no difcil e muito usual na prtica.
Ao criar mscaras mais especficas voc ir melhorar a experincia do usurio com o sistema VoIP e
tambm ter a oportunidade de otimizar o custo com as ligaes, pois cada operadora tem uma tarifa
diferente e podemos criar vrias mscaras diferentes para criar rotas de melhores custos para
ligaes locais, distncia (DDD), para celular ou chamadas Internacionais, fazendo um dial
plan (plano de discagem) mais elaborado. Abaixo seguem alguns exemplos de rotas para PSTN criadas
para usurios dos Estados Unidos e Brasil.
Exemplo de dial plan para os Estados Unidos:
[2-9]...... - Utilizado para rea com nmeros de sete dgitos
[2-9]..[2-9]...... - Utilizado para reas de 10 dgitos
1[2-9]..[2-9]...... - Utilizado para ligaes de longa distncia com 11 dgitos
[469]11 - utilizados para os nmeros de servio (polcia, bombeiros, etc.), tais como 411, 611 e 911
011T - Utilizados para ligaes internacionais
Exemplo de dial plan para o Brasil:
0[1][^0].$ - Servicos Pblicos
0[1][0]T - Servicos Operadoras
0[2-6].......$ - Local Fixo
0[7-9].......$ - Local Celular
0[0][^0]...[2-6].......$ - DDD Fixo
0[0][^0]...[7-9].......$ - DDD Celular
0[0][0]T - DDI
0[0][389][0][0]T - Servicos Privados
Obs: o wildcard $ desabilita correspondncia com tamanho varivel e deve ser utilizado no final de
uma string.
Agora vamos implementar as configuraes nos dial peers considerando o dial plan estudado para os
Estados Unidos, sendo que para acesso PSTN deve ser discado o 9 e o tronco utilizado um canal T1.
Dois comandos nessa configurao so utilizados para tratar o problema do automatic digitstripping (retirada automtica dos dgitos explcitos) que os dial peers POTS fazem, so o forwarddigits <nmero> e o prefix <nmero>.
O comando forward-digits <nmero> define o nmero de dgitos que devero ser passados para a
linha POTS iniciando de trs para frente, ou seja, a contagem inicia pelo ltimo dgito em direo ao
primeiro. Se analisarmos com mais cuidado o dial peer 100 nele temos configurado o comando
destination-pattern 9[469]11, o que faria o roteador retirar os dgitos 9 e os dois 1s antes de
encaminhar a chamada. Quando foi dado o comando forward-digits 3, o roteador encaminhar os 3
nmeros da direita para a esquerda, ou seja, 411, 611 ou 911, removendo o nmero de acesso PSTN
9.
J o comando prefix <nmero> adiciona frente do nmero discado os dgitos que forem
configurados nele. Veja no dial peer 103 que temos o comando destination-pattern 9011T
configurado para definir o acesso internacional, o que vai fazer com que os dgitos 9011 sejam
retirados antes do envio PSTN e sero passados apenas os dgitos discados aps eles. Utilizando o
comando prefix 011 os dgitos 011 sero colocados novamente em seu devido lugar
permitindo que a PSTN reconhea que uma chamada internacional e seja encaminhado
corretamente.
Private Line Automatic Ringdown - PLAR
Apesar de no estar diretamente ligado aos dial peers e suas configuraes o Private Line Automatic
Ringdown ou PLAR necessita de um dial peer para completar sua chamada, por isso vamos tratar
desse assunto nesse momento.
As portas configuradas com o recurso chamado PLAR discam automaticamente para um determinado
nmero ao ser retirado do gancho, ou seja, quando detectam o sinal de off-hook. o telefone
vermelho do Batman, onde o comissrio Gordon retira o telefone do gancho e ele liga diretamente
para a caverna do heri mascarado sem a necessidade de discagem. Apesar da brincadeira, o PLAR
muito utilizado em telefones de emergncia localizados em elevadores, garagens e estacionamentos,

ou em telefones de ajuda localizados em caixas bancrios automticos (ATMs).
Vamos a um exemplo, suponha que voc possui uma placa FXS e na porta 0/0/0 existe um telefone
configurado como ramal 1001 que ao ser retirado do gancho deve discar para o ramal 1002
automaticamente via PLAR, o qual est na porta 0/0/1. Veja as configuraes abaixo:
Note que para esse tipo de conexo o ramal 1001 no conseguir mais discar, pois ele est vinculado
ao ramal 1002 e ao ser retirado do gancho ir automaticamente fazer a chamada para o ramal 1002.
Outra aplicao dessa funcionalidade quando temos interfaces FXO conectada diretamente PSTN.
Vimos anteriormente como fazer que os telefones internos acessem a FXO para realizarem uma
chamada em direo a rede pblica PSTN. Mas e quando a ligao vem da PSTN com destino a nossa
rede interna?
Quando um roteador recebe uma chamada vinda da PSTN, a informao recebida da operadora no
inclui o nmero discado, o que conhecido como Dialed Number Identification Service - DNIS. O que
enviado para o roteador pela PSTN o nmero de quem est realizando a chamada ou caller ID
(chamado de Automatic Number Identification - ANI), porm esse parmetro no ajuda o roteador a
definir para quem encaminhar a chamada recebida.
O que ocorre ento quando voc recebe uma chamada da PSTN o roteador enviar um segundo tom
de discar para quem est fazendo a chamada via PSTN. como se o roteador falasse para a pessoa
que est ligando Ol, atendi sua ligao...e agora me diga o que fazer???. Para completar a
chamada a pessoa que ligou da PSTN (o chamador) deveria assim que ouvir o segundo tom, discar o
nmero do ramal interno (o DN) de um ramal. No entanto, quase impossvel que a pessoa saiba essa
informao.
nessa situao que o PLAR pode ser utilizado para resolver o problema, pois com o comando PLAR,
o roteador atende a ligao e automaticamente encaminha a chamada para um ramal interno
especfico, por exemplo, para o nmero de uma telefonista. Veja na figura abaixo a topologia
utilizada para o exemplo de configurao.
A configurao voc pode verificar abaixo:
Portanto, entrando com o comando connection plar 5000 nas portas FXO o roteador encaminhar
todas as chamadas entrantes da PSTN para o ramal da telefonista que o 5000 ao invs de gerar um
segundo tom de discagem.
A configurao do PLAR para chamadas de entrada necessrio apenas para os troncos analgicos
FXO. Para troncos digitais com a PSTN (T1 ou E1) o roteador recebe o DNIS nas chamadas entrantes, o
que pode ser utilizado para fazer o Direct Inward Dial (DID) ou encaminhamento direto das chamadas
entrantes, sem a necessidade do PLAR para esse tipo de interface.
Informao extra:
Existe tambm uma variao do comando plar, ocomando plar opx. Com o plar opx a FXO ir
atender a chamada somente se esse ramal estiver disponvel. Utilizando somente o plar (sem o opx)
a FXO ir atender a ligao mesmo que o nmero de destino esteja indisponvel.
VOICE-GW-CME(config)#voice-port 1/0/0
VOICE-GW-CME(config-voiceport)#connection plar opx 5000
VOICE-GW-CME(config-voiceport)#exit
Processamento das Chamadas e Manipulao de Dgitos

O entendimento de como o roteador processa os dgitos que so recebidos de suma importncia
para entender e projetar corretamente os dial peers. Existem duas regras bsicas que regem os dial
peers e devem ser levadas em conta quando voc estiver configurando seu plano de discagem:
1. O destination pattern mais especfico sempre ganha.
2. Quando uma correspondncia (match) feita o roteador imediatamente processa a chamada.
Vamos agora atravs da anlise de alguns exemplos entender melhor o que significam as duas regras
citadas acima. Veja o exemplo abaixo:
Se discarmos o nmero 1001234 os dois dial peers daro correspondncia, porm qual o dial peer que
o roteador utilizar? Vamos analisar qual deles mais especfico.
O dial peer 2 faz correspondncia com nmeros que iniciam em 1001 e os ltimos 3 dgitos podem
ser quaisquer um ..., portanto faz correspondncia com 1000 nmeros.
J o dial peer 1 com destination pattern 100[1-4]... d correspondncia quando os trs primeiros
dgitos forem 100, o quarto dgito pode ir de 1 a 4 ([1-4]), j os ltimos 3 dgitos podem ser
quaisquer nmeros (...), dandocorrespondncia com 4000 nmeros. Portanto o roteador utilizar
o dial peer 2 para encaminhar a chamada, pois ele mais especfico que o dial peer 1.
Agora vamos adicionar mais um dial peer e analisar o que vai acontecer quando discarmos o mesmo
nmero 1001234. Veja o exemplo abaixo:
Se agora digitarmos o mesmo nmero 1001234 o roteador agora vai utilizar o dial peer 3 para
encaminhar a chamada, pois ele mais especfico que os dois anteriores. O roteador vai processar
apenas os dgitos 1001 e descartar os demais dgitos (234). Voc pode utilizar essa configurao para
encaminhar chamadas para nmeros de emergncia, tais como 911 ou 9911 para os Estados Unidos
ou ento 190 ou 0190 para o Brasil (lembre que o nmero de acesso PSTN zero mais utilizado no
Brasil), assim o roteador encaminha a chamada imediatamente depois de digitado o nmero.
Informao extra:
uma prtica muito utilizada criar dial-peers especficospara nmeros de emergncia, como o 190
por exemplo. Ao criarmos um dial-peer cujo destination-pattern seja190, quando o usurio digitar
190 a correspondncia ser feita imediatamente. Mesmo que aps o 190 o usurio digite mais dgitos
a correspondncia j ter sido feita no momento em que ele discou o 190.
Outra boa prtica criar tambm o dial-peer comdestination-pattern 0190, isso para que o usurio
no tenha que decidir ou pensar se coloca o zero para chamada externa ou no. Tendo os dois dialpeer, discando 190 dar certo e discando 0190 dar certo tambm.
Tenha em mente que um nmero de emergncia, como o prprio nome diz, ser utilizado em
situaes de emergncia, onde a pessoa que est tentando fazer a chamada poder estar nervosa ou
em uma situao de risco. nossa funo facilitar o uso desse nmero, afinal uma vida pode estar em
risco.
Voc pode testar seu plano de discagem com o comando show dialplan number <nmero>, sendo
que o nmero o destino que voc deseja testar para verificar por qual dial peer ele ser
encaminhado. O roteador vai mostrar todas as correspondncias colocando a mais especfica por
primeiro. Veja exemplo da sada desse comando abaixo:
Outra dica prtica importante lembrar que o roteador vai encaminhar a chamada assim que houver
um match (correspondncia) com um dial peer mais especfico, portanto evite sobrepor (overlap)
planos de discagem sempre que possvel. Algumas vezes isso no possvel e voc vai precisar fazer
alguma sobreposio, portanto seja criativo na hora de fazer a configurao e alcanar seu objetivo
final. Por exemplo, se voc realmente precisasse discar para o nmero 1001 sem interferir com o dial
peer com destination pattern 1001..., voc poderia criar um terceiro dial peer com destinatio pattern
1001T, conforme configurao abaixo:
Assim o usurio poderia digitar 1001 e pressionar a tecla sustenido (#) que a chamada seria
encaminhada pelo dial peer 3, pois o T espera por nmeros de 0 a 32 dgitos, e caso o usurio no
digite a tecla # aps 10 segundos a chamada vai ser encaminhada, pois quando acaba o tempo do
interdigit timeout. Alm dessa soluo, veremos mais a frente como fazer uma configurao mais
sofisticada com a manipulao de dgitos.
Processo de Correspondncia de Dial Peers de Entrada e Sada
Agora vamos comear a analisar como as chamadas so processadas, pois para que uma chamada
recebida pelo roteador seja encaminhada ela deve sempre tercorrespondncia com um dial peer,
seja de entrada (inbound) ou de sada (outbound). Vamos utilizar como base a topologia da figura
abaixo, a qual traz os equipamentos e suas configuraes de dial peer para que a comunicao entre
os ramais 1001 e 5001 seja possvel.
Vamos iniciar pela correspondncia a partir de um dial peer de sada (outbound dial peer). Nesse caso
o roteador pega os dgitos discados e compara com os destination patterns configurados nos dial
peers para encontrar a correspondncia mais especfica (most specific match).
Por exemplo, quando um usurio que est no ramal 1001 digita os nmeros 5001, o roteador DLTEC-A
verifica os dial peers configurados e encontra uma correspondncia direta que o instrui a realizar uma
chamada para o endereo IP 11.1.1.2 atravs de um dial peer do tipo VoIP. Quando o DLTEC-B recebe
a chamada ele verifica que os dgitos discados tem correspondncia direta com o dial peer POTS 5001,
o qual o instrui a fazer uma chamada pela sada da interface T1 que est conectada ao PABX.
No slide anterior vimos uma explicao de como funciona o processo de match (correspondncia)
para dial peers de sada (representados pelas call legs 2 e 4), porm como ele faz esse processo para
os dial peers de entrada (inbound)? Na realidade o roteador trata inbound dial peers (dial peers de
entrada) atravs de cinco mtodos. Acompanhe abaixo:
Correspondncia para inbound dial peers:
1. Tenta correspondncia com o nmero discado(DNIS) utilizando o incoming called-number
configurado no dial peer.
2. Tenta correspondncia com o caller ID (ANI nmero de quem est realizando a ligao)
utilizando o answer-address na configirao do dial peer.
3. Tenta correspondncia com o caller ID (ANI) utilizando o "destination-pattern" configurado no
dial peer.
4. Tenta correspondncia com o nmero de entrada do dial peer POTS utilizando o port
configurado no dial peer.
5. Se nenhum dos quatro mtodos acima funcionar ele utilizar o dial peer 0.
Portanto, analisando mais uma vez nossa topologia as Call legs 2 e 4 so classificadas como dial peers
de sada(outbound dial peers) que tem correspondncia (matched) utilizando a informao do
nmero discado (dialed number - DNIS) configurado no comando destination-pattern dentro da
configurao dos dial peers.
Agora vamos ver para cada uma das Call legs de entrada(inbound) como as cinco regras so utilizadas
para fazer correspondncia com os dial peers de entrada (inbound dial peers).
Para a call leg 1:
1. (SEM CORRESPONDNCIA - SEM CORRESPONDNCIA - NO MATCH) 5001 (nmero discado DNIS) no corresponde a um incoming called-number na configurao do dial peer do
roteador DLTEC-A router, porque no utilizamos esse comando em sua configurao.
2. (SEM CORRESPONDNCIA - SEM CORRESPONDNCIA - NO MATCH) x1001 como caller ID (ANI
nmero chamado) no tem correspondncia no comando answer-address na configurao
do dial peer no roteador DLTEC-A porque no utilizamos esse comando na configurao.
3. (SEM CORRESPONDNCIA - SEM CORRESPONDNCIA - NO MATCH) x1001 como caller ID (ANI)
no corresponde a nenhum destination- pattern configurado no dial peer do roteador DLTECA, isso porque 1001 no tem nenhuma informao sobre o caller ID configurada. Ele um
telefone analgico e no passa nenhuma informao sobre ele mesmo para o roteador, muito
menos seu caller ID. Um telefone analgico no sabe seu prprio nmero.
4. (COM CORRESPONDNCIA - MATCH) x1001 vem atravs de uma porta FXS 0/0/0, a qual
corresponde com o dial peer de entrada POTS configurado no roteador DLTEC-A atravs do
comando port dentro da configurao do dial peer (port 0/0/0).
Portanto o processo de correspondncia utilizando os cincos passos no roteador DLTEC-A possibilitou
que ele fizesse a correspondncia com o dial peer de entrada utilizando o valor da porta de entrada
na qual o telefone analgico estava conectado.
Aps esse passo o roteador DLTEC-A processa a chamada de sada utilizando o dial peer de sada
gerando a call leg 2, que gera uma chamada at o roteador DLTEC-B. Mais uma vez aqui utilizaremos
os 5 passos para encontra a correspondncia no dial peer de entrada (inbound), mas agora para
a chamada entrante no DLTEC-B.
Cinco passos para determinar a call leg 3:

1. (SEM CORRESPONDNCIA - SEM CORRESPONDNCIA - NO MATCH) 5001 (o nmero discado)
no correspond a nenhum incoming called-number configurado no dial peer do DLTEC-B,
porque no utilizamos esse comando na configurao.
2. (SEM CORRESPONDNCIA - SEM CORRESPONDNCIA - NO MATCH) x1001 caller ID (ANI) no
corresponde a nenhum answer-address configurado no dial peer do DLTEC-B, porque no
utilizamos esse comando na configurao atual.
3. (COM CORRESPONDNCIA - MATCH) x1001 que a informao do caller ID (ANI nmero
discado) tem correspondncia no destination-pattern configurado dentro do dial peer VoIP
com nmero 1001 no DLTEC-B.
Nesse caso, o dial peer do tipo voip de nmero 1001 no DLTEC-B atua tanto como dial peer de
entrada quanto de sada. Ele tem a funo de dial peer de sada para as chamadas feitas com origem
no DLTEC-B para o ramal x1001 e a funo de dial peer de entrada para chamadas vindas do ramal
x1001.
Agora vamos apagar a configurao referente ao dial peer voip com nmero 1001 no
roteador DLTEC-B, mantendo as demais configuraes, conforme abaixo.
DLTEC-B(config)#no dial-peer voice 1001
DLTEC-B(config)#end
DLTEC-B#
Com isso teremos o cenrio ilustrado na figura ao lado. A primeira consequncia do que acabamos de
fazer que no conseguiremos mais fazer chamadas para o nmero 1001 a partir do roteador DLTECB, ou seja, a partir do PABX que est conectado via T1 com o roteador.
Mas o que vai acontecer se o usurio do telefone 1001 ligar para o 5001? Nesse caso, tanto o
roteador DLTEC-A como o DLTEC-B tem informaes suficientes para fazer a correspondncia e
montar as call legs de sada (outbound). Porm est faltando no roteador DLTEC-B a configurao que
permite a correspondncia com o dial peer de entrada relativo call leg 3. Vamos ento montar o
processo de deciso de cinco passos para ver o que vai acontecer:
1. (SEM CORRESPONDNCIA - NO MATCH) 5001 (o nmero discado - DNIS) no corresponde a
nenhum incoming called-number na configurao do dial peer do DLTEC-B, simplesmente
porque no utilizamos esse comando.
2. (SEM CORRESPONDNCIA - NO MATCH) x1101 a informao do caller ID (ANI nmero de
quem est discando) no corresponde a nenhum answer-address configurado no dial peer do
DLTEC-B, tambm porque no utilizamos esse comando em nossa configurao.
3. (SEM CORRESPONDNCIA - NO MATCH) x1101 a informao do caller ID (ANI) no
corresponde a nenhum destination-pattern configurado nos dial peers, isso porque
apagamos essa informao quando removemos o dial peer do tipo voip 1001 da configurao
do DLTEC-B.
4. (SEM CORRESPONDNCIA - NO MATCH) x1101 no veio de nenhuma porta do tipo POTS
(interfaces FXS, FXO, E&M ou interfaces digitais BRI/T1/E1) que poderia fazer correspondncia
com o comando port no dial peer, pois essa ligao veio atravs do VoIP.
(COM CORRESPONDNCIA - MATCH) porque o DLTEC-B no pode utilizar nenhum dos mtodos
enteriores ele utiliza o dial peer 0.
Ento fica a pergunta, o que o dial peer 0? O dial peer 0 como um gateway default quando no h
correspondncia em dial peers de entrada (inbound).
O problema aqui que voc no tem controle sobre ele, ou seja, no pode apagar ou alterar sua
configurao. As caractersticas do dial peer 0 so mostradas abaixo.
Caracterstica do dial-peer 0:
Aceita quaisquer tipos de codec.

No utiliza DTMF relay, o qual possibilita enviar os dgitos discados por fora do fluxo de
udio. Isso til porque dependendo do codec e do nvel de compresso o adio pode ficar
distorcido.
Utiliza o IP Precedence 0, que retira toda e qualquer marcao de QoS do fluxo de voz,
fazendo com que os pacotes de voz sejam tratados como os pacotes de dados.
Voice Activity Detection (VAD deteco de atividade de voz) habilitado, o que possibilita
economizar largura de banda quando h perodos de silncio em uma conversao bidirecional.
No utiliza o protocolo Resource Reservation Protocol (RSVP): Com isso o roteador no reserva
nenhuma banda para chamadas atravs do dial peer 0.
Largura de banda do fax fica limitada banda da voz (Fax-rate voice), o que limita essa banda
ao mximo permitido pelo coded, podendo at impedir a passagem de sinais de fax quando um
codec com nvel de compresso mais alta for utilizado.
Sem suporte aplicaes externas, como por exemplo um Interactive Voice Response (IVR).
Sem suporte ao DID, um recurso que permite chamadas externas vindo da PSTN serem
encaminhadas diretamente a dispositivos internos.
Portanto ao invs de deixar que o dial peer zero tente fazer a correspondncia como um dial peer de
entrada (inbound) melhor garantir que haver um dial peer de entrada configurado corretamente
para que voc possa ter controle da situao.
Utilizando a Manipulao de Dgitos (Digit Manipulation)
A manipulao de dgitos, em ingls digit manipulation, o processo de adicionar ou remover
dgitos ao nmero discado para ajudar que a chamada chegue at ao seu destino corretamente. Ns
j fizemos manipulao de dgitos em exemplos anteriores nesse captulo, tais como no digitstrip, forward-digit e prefix, os quais auxiliaram na retirada automtica de dgitos que o roteador
faz antes de encaminhar os dgitos em chamadas POTS.
Acompanhe abaixo todos os comandos relacionados manipulao de dgitos em roteadores Cisco.
prefix digitos
Pode ser utilizados em dial peers do tipo POTS e permiteadicionar dgitos ao nmero discado.
Exemplo: prefix 041 adiciona o nmero 041 na frente do nmero discado originalmente.
forward-digits numero
Pode ser utilizado em dial peer do tipo POTS e permite encaminhar o nmero de dgitos da direita
para esquerda.
Exemplo: forward-digits 4 encaminhar somente os 4 nmeros mais a direita do nmero discado.

Se tivssemos um destination-pattern 1... e o usurio discasse 1234, sem o forward-digits 4 seria
encaminhado o nmero 234, com o forward-digits 4 ser encaminhado 1234.
[no] digit-strip
O padro para os dial peer POTS ter o comando digit-strip ativado, ou seja, se voc no informar
nada o roteador ir fazer o digit strip nos dial peer pots antes de encaminhar a chamada.
Exemplo: se colocarmos o comando no digit-strip desabilitamos o automatic digit-stripping nesse
dial peer POTS.
num-exp dgitos-discados dgitos-transformados
Funciona para quaisquer tipos de dial peers (pots ou voip) e transforma um nmero discado em uma
outra sequncia especfica de dgitos.
Exemplo 1: se inserirmos o comando num-exp 4... 5... ele pega correspondncia (matches) em
quaisquer nmeros de quatro dgitos que iniciam com 4 e transformam em outro nmero de quatro
dgitos inicando com 5, por exemplo 4123 vira 5123.
Exemplo 2: num-exp 0 5000 toda vez que houver correspondncia com o nmero discado zero e
transforma em 5000.
voice translation-profile
Funciona tanto para dial peers POTS ou VoIP e permite que voc configure uma lista de
tradues que podem terat 15 regras para transformar os nmeros de acordo com a necessidade.
Uma translation profile pode ser aplicada a vrios dial peers como se fossem access-lists.
Exemplo Prtico 1: Redundncia Utilizando a PSTN com o Comando Prefix
Nesse primeiro exemplo prtico analisaremos um cenrio onde temos a comunicao entre duas
localidades de uma empresa via VoIP e caso esse link caia a redundncia ser realizada via PSTN, em
ingls esse cenrio chamado de PSTN Failover.
Essa uma caracterstica desejvel de quaisquer redes VoIP, que elas sejam tolerantes a falha e
possam encaminhar suas chamadas mesmo com a rede IP fora do ar, possibilitando que os usurios
possam se comunicar sem perceber o que est acontecendo com a rede IP.
Veja a topologia base na figura abaixo.
Analisando a topologia vemos que as chamadas entre a Matriz e a Filial so realizadas via rede
WAN atravs do VoIP, sendo que os usurios da filial tem uma faixa de numerao (range) de ramais
utilizando 4 dgitos iniciando em 6XXX (6000 a 6999). J a matriz inicia seu range com 5XXX, tendo
uma faixa de ramais de 5000 a 5999. Isso poderia ser um inconveniente quando a redundncia via
PSTN fosse ativada, pois os usurios teriam que discar o nmero direto de cada ramal configurado na
PSTN (DID direct inward dial) ao invs dos 4 dgitos. Porm com a manipulao de dgitos podemos
tratar esse assunto de maneira que os usurios nem precisaro saber que a rede IP caiu e continuaro
discando os quatro dgitos normalmente.
Vejam que tem um comando novo que apareceu nos dial peers, o comando preference. Esse
comando permite definir que dial peer o roteador ir utilizar quando existem vrios destinos
(destination pattern) configurados iguais. Quanto menor o valor do preference melhor o dial peer
para o roteador, ou seja, os valores menores sero utilizados por primeiro, sendo que podemos
utilizar valores de 0 a 10. O valor padro do preference 0.
Dica: se voc criar diversos dial peers com o mesmo destinatoion pattern e preference o roteador vai
escolher randomicamente (aleatoriamente) que dial peer utilizar por chamada.
Analisando o dial peer 10, o qual a sada via rede VoIP, no precisamos fazer nenhuma manipulao
de dgitos, pois no h a retirada dos dgitos nesse tipo de dial peer. Alm disso, ele ser o dial peer
preferencial em ambos os roteadores, uma vez que sua preferencia est configurada como zero.
Caso a conexo IP entre a Matrzi e a Filial caia ambos os roteadores utilizaro o dial peer 11 para
rotear as chamadas, pois ele tem a segunda preferencia mais alta (preference 1). Porm, como
estamos em interfaces do tipo POTS precisamos resolver o problema da retirada dos dgitos
(automatic digit-stripping) e tambm os usurios estaro discando nmeros de 4 dgitos apenas,
portanto precisaremos colocar o cdigo de rea e o nmero da central local, conforme passado pela
operadora de telecom no servio de DID.
Para resolver o problema da retirada dos dgitos utilizamos o comando no digit-strip, o que faz o
roteador passar para a PSTN os quatro dgitos discados do ramal, porm como estamos na PSTN ela
no vai entender essa numerao, pois precisamos do nmero completo para a central telefnica
rotear a chamada. Por isso colocamos o comando prefix em ambos os roteadores. No roteador
Matriz colocamos o comando prefix 1512555 e no Filialo comando prefix 1480555, permitindo
assim que quando o usurio disque da Matriz o ramal 6001 da Filial, por exemplo, na sada para a
PSTN ele ser transformado em 15125556001, possibilitando que a PSTN roteie a chamada at o T1
localizado no roteador Filial-GW.
Caso a WAN caia durante uma ligao que est acontecendo no h como ter um mecanismo
automtico de redundncia para esse caso, pois a ligao vai cair e o usurio ter que fazer uma nova
chamada.
Note tambm que os exemplos utilizados aqui e que sero cobrados no CCNA de Voz so para os
Estados Unidos, porm cada pas tem sua prpria numerao e regras de discagem. Normalmente
temos que considerar os seguintes tipos de ligao:
Local (podendo ser para telefones fixos ou celulares).

Interurbana ou longa distncia (lembre que no Brasil temos que escolher a prestadora de
servios de longa distncia com dois dgitos).
Internacionais.
Alm desses servios temos tambm os 0800, para chamadas gratuitas para call centers, por exemplo.
Portanto, seu dial plan ter que considerar todas essas situaes.
Exemplo Prtico 2: Direcionando Chamadas para a Recepcionista
Esse um exemplo bastante simples, onde um operador liga para a FXO e deseja redirecionar a
chamada para a recepcionista utilizando o 0, porm o ramal da recepcionista o 5000. Para isso
vamos utilizar uma transformao de dgitos. Segue o cenrio na figura abaixo.
A configurao voc pode ver abaixo:
Como essa uma transformao simples e global, vamos utilizar o comando num-exp em modo de
configurao global do roteador para fazer a transformao. Agora toda vez que o nmero 0 for
discado em qualquer ponto da empresa, seja atravs de um telefone IP, porta FXS e assim por diante,
o roteador ir automaticamente transform-lo em 5000, procurando a seguir pelo dial peer que tem o
destination pattern que tem correspondncia com o ramal 5000.
Portanto, o roteador aplica o comando num-exp no instante que ele recebe os dgitos discados,
antes de tentar correspondncia com um inbound dial peer (dial peer de entrada).
Exemplo Prtico 3: Reservando Linhas POTS para Chamadas de Emergncia
Algumas empresas que esto migrando para o VoIP acabam aproveitando para eliminar conexes
telefnicas tradicionais em escritrios remotos fazendo a centralizao das chamadas PSTN em uma
localidade principal, conforme figura abaixo:
Esse tipo de topologia para encaminhamento de chamadas PSTN em um local centralizado permite
que as empresas negociem valores especiais para tarifas de longa distncia, pois o volume de ligaes
acaba ficando elevado e compensando para ambas as empresas, tanto para o cliente como para a
prestadora de servios telefnicos.
Em alguns pases proibido o encaminhamento de chamadas originadas ou destinadas a partir da
rede PSTN atravs da WAN utilizando o VoIP. Os Estados Unidos e o Brasil no tm leis que limitem
esse tipo de uso.
Apesar da centralizao da sada das chamadas para a PSTN reduzir significativamente os custos com
a telefonia, muitas vezes necessrio manter algumas linhas convencionais nos escritrios remotos
para as chamadas de emergncia e como um backup caso a rede IP falhe.
Muitas vezes os servios de emergncia, como polcia e bombeiro, tem ligao direta e
reconhecimento da sua localidade atravs da conexo local realizada com a PSTN, ou seja, o
reconhecimento e encaminhamento da localidade que voc est ligando dependem da sua conexo
local com a prestadora de servios de telefonia.
Voc pode dedicar linhas FXO para as ligaes de emergncia ou utilizar essas linhas para quaisquer
tipos de ligaes. Nesse exemplo vamos dedicar duas portas da FXO para as ligaes de emergncia,
as portas FXO 1/0/0 e 1/0/1. Tambm vamos utilizar o 911, nmero de emergncia utilizado nos
Estados Unidos (no Brasil seria o 190).
Acompanhe a configurao abaixo:
Note que foram criados 4 dial peers, porm dois deles so idnticos apontando cada um para uma
porta FXO. Como no utilizamos o comando preference para apontar qual o dial-peer preferencial,
o roteador CME ir escolher randomicamente uma das portas da FXO para utilizar cada vez que um
usurio tentar ligar para o destino apontado no destination-pattern.
Perceba tambm que criamos dial-peer para dois destinos 911 e 9911. Com isso se o usurio discar
911 ou 9911, por estar acostumado a digitar o 9 como tecla de acesso PSTN o nmero ser
reconhecido. Os dial peers 10 e 12 so para um nmero discado 911 (destination-pattern 911) e os

dial peers 11 and 13 sero utilizados caso o usurio disque 9911.
Note tambm que para os dial peers 10 e 12 tivemos que adicionar o comando no digit-strip, pois
como o 911 est explcito no destination-pattern ele ser removido antes de ser repassado para a
PSTN, para evitar que isso seja feito e nossa chamada seja roteada pela central pblica precisamos
colocar o comando no digit-strip. J nos dial peers 11 e 13 se utilizssemos o mesmo comando
teramos um problema, pois seria encaminha 9911 ao invs de 911, por isso o comando utilizado
nesses dial peers foi o forward-digits 3, pois assim ser passado para a PSTN apenas o 911, trs
dgitos da direita para a esquerda.
Informao extra:
Informao adicional para uso em campo. No cobrada na prova do ccna voice at o momento do
desenvolvimento do curso.
Perceba na configurao mostrada que tivemos que criar para cada destination-pattern um dial peer
pots para cada porta da FXO. Agora imaginem uma situao onde temos 08 destination-pattern e 08
portas FXO. Teramos nesse caso que criar 64 dial-peers para que o roteador escolhesse
randomicamente cada uma das portas da FXO por vez que um usurio tentar fazer uma ligao para
esses destinos. Felizmente, existe uma maneira mais fcil de fazermos isso com o recurso trunk
group
Entenda o trunk group como sendo um agrupamento lgico de interfaces com as mesmas
caracterstica Para utilizarmos esse recurso devemos seguir as etapas abaixo.
Criar o trunk group em modo de configurao global
dltec(config)#trunk group ?
WORD Trunk group label
! cria o trunk group com o nome PSTN

dltec(config)#trunk group PSTN
! determina que a escolha das portas ser randomicamente
dltec(config-trunk-group)#hunt-scheme random
Associar as voice-port ao tronco PSTN criado
voice-port 0/3/0
! o comando abaixo associa essa porta ao tronco PSTN
trunk-group PSTN
supervisory disconnect dualtone mid-call
cptone BR
timeouts call-disconnect 5
timeouts wait-release 5
connection plar opx 8005
description FXO1 - 30457800
!
voice-port 0/3/1
! o comando abaixo associa essa porta ao tronco PSTN
trunk-group PSTN
supervisory disconnect dualtone mid-call
cptone BR
timeouts call-disconnect 5
timeouts wait-release 5
connection plar opx 8005
description FXO1 - 30457801
!
Associar os dial ao tronco

Perceba que agora nos dial-peer no teremos mais o comando port xxxx. E sim o trunkgroup que esse
dial peer est associado.
dial-peer voice 1000 pots
! o comando abaixo associa essa dial-peer ao tronco PSTN
trunkgroup PSTN
description Servigos Publicos
destination-pattern 0[1][^0].$
!
trunkgroup PSTN
description Servigos Operadoras
destination-pattern 0[1][0]T
!
trunkgroup PSTN
description Local Fixo
destination-pattern 0[2-6].......$
!
trunkgroup PSTN
description Local Celular
destination-pattern 0[7-9].......$
!
trunkgroup PSTN
description DDD Fixo
destination-pattern 0[0][^0]...[2-6].......$
!
trunkgroup PSTN
description DDD Celular
destination-pattern 0[0][^0]...[7-9].......$
!
trunkgroup PSTN
description DDI
destination-pattern 0[0][0]T
!

trunkgroup PSTN
description Servigos Privados
destination-pattern 0[0][389][0][0]T
!
Exemplo Prtico 4: Utilizando Translation Profiles

O que utilizamos at agora para fazer manipulao de dgitos permite apenas mudanas mais simples,
porm quando voc necessitar fazer mudanas mais complexas, por exemplo, alterar um nmero
discado para outro quando a ligao feita somente por determinada porta, nesses casos voc ter
que utilizar uma translation profile.
Para fazer translation profiles voc vai utilizar as tcnicas de manipulao de dgitos aprendidas
anteriormente, porm agora aplicadas em outro formato, similar a uma Access list. O processo
configurado em trs etapas, que voc pode acompanhar abaixo:
Translation Profiles
1. Criar as regras que iro dizer para o roteador como ele ir transformar os nmeros.
2. Associar as regras a um translation profile.
3. Adicionar o translation profile a um determinado dial peer.
Vamos analisar uma configurao na prtica utilizando a topologia da figura abaixo:
Na Matriz a empresa tem um link T1 com um range DID (Direct inward dial) para a PSTN com a
numerao602.555.6XXX. Essa facilidade permite que os ramais internos sejam acessados por
usurios da PSTN ligando diretamente para os ramais dos funcionrios da empresa sem a necessidade
de passar por uma telefonista ou recepcionista. Normalmente a prestadora de servios de
telecomunicaes passa um bloco (range ou faixa) de nmeros DID, o qual para nossa empresa fictcia
foi alocado na faixa 6XXX, de 6000 a 6999. A vantagem desse tipo de servio que permite que voc
utilize internamente somente os 4 ltimos dgitos para encaminhar as chamadas internas e ainda os
nmeros podem ser acessados diretamente pela PSTN discando o nmero completo.
Nesse caso o bloco utilizado na Matriz no sobrepe com a faixa utilizada para a Filial porm a Matriz
utiliza a faixa 5XXX, de 5000 a 5999, e a Filial utiliza a faixa 6XXX, a qual a mesma que a utilizada
pelo DID.
O administrador precisa que todos os nmeros quevenham como 6XXX da
operadora sejam transformadospara a faixa dos seus ramais locais que esto na faixa dos 5XXX, mas
sem interferir no seu esquema de numerao interno que j utiliza a faixa de 6XXX no escritrio
remoto. Essa traduo precisa ser realizada se os nmeros discados vierem pela interface T1 atravs
da PSTN.
Para isso no possvel utilizar o comando num-exp 6... 5... em modo de configurao global, pois
isso ir interferir na discagem dos ramais da faixa 6XXX que esto na Filial, portanto esta uma
situao onde orecomendado utilizar translation profiles.
A sintaxe bsica das translation profiles segue abaixo:
Em nossa configurao o 6 que est entre as barras (/6/) significa que se vier um nmero com incio
6 o roteador deve fazer a traduo que est entre as outras duas barras, que est configurado
como /5/, ou seja, troque pelo dgito 5.
Para verificar o funcionamento das regras de uma translation profile o roteador fornece
uma facilidade de teste muito interessante atravs do comando test voice translation-rule, que
deve ser dado em modo privilegiado. Com esse comando voc pode testar sua regra simulando um
nmero de entrada. Acompanhe o exemplo abaixo:
Portanto, conforme podemos ver na sada do comando nossa regra configurada na translation-rule 1
est funcionando de acordo com o planejado.
Agora, o prximo passo vincular a translation rule a umatranslation profile. A translation profile
define se a translation rule vai alterar o nmero que est chamando (caller ID ou ANI) ou o nmero
chamado (nmero discado/chamado ou DNIS).
Veja abaixo a configurao que vincula a translation rule 1 ao translation profile que vamos
chamar de DID6000.
Portanto a translation rule 1 foi configurada paratraduzir o nmero chamado (called). Isso porque
o cenrio exige que faamos a traduo no nmero discado atravs do DID, o qual o nmero interno
que um usurio da PSTN discou.
Se a translation rule fosse uma traduo criada como calling ela iria alterar o nmero (caller ID) da
pessoa que est ligando via PSTN para dentro do roteador Matriz.
Por ltimo vamos vincular o translation profile a um dial peer. Veja abaixo como ficaria a
configurao, considerando que as chamadas de fora vem pelo dial peer pots 100.
Mais um detalhe importante que a translation profile foi inserida na direo de entrada
(incoming), pois ela deve atuar sobre as chamadas que esto vindas da PSTN em direo Matriz. A
direo de sada (outgoing) teria efeito sobre chamadas de sada, isto , em direo PSTN.
Aqui importante tambm entender que a ordem que colocamos a manipulao de dgitos pode
influenciar no resultado final das operaes desejadas. Essa ordem mostrada abaixo.
Essa ordem pode ser utilizada tanto em dial peers VoIP como para POTS, porm a maioria das vezes
que precisamos fazer manipulao de dgitos ela realizada nos dial peers POTS.
Voice Translation Rules - Info Adicional
Vamos aqui ver mais alguns exemplos sobre as transformaes que podemos fazer com as voice
translations rules. Veja os exemplos abaixo:
Exemplo 1
Este exemplo substitui a primeira ocorrncia do nmero "123" com "456"
voice translation-rule 1
rule 1 /123/ /456/
These are test voice translation-rule examples:
router#test voice translation-rule 1 123
Matched with rule 1
Original number: 123
Translated number: 456
Matched with rule 1
Matched with rule 1
Matched with rule 1
Original number type: none
Translated number type: none
Original number plan: none
Translated number plan: none
Neste exemplo, a regra corresponde a primeira ocorrncia do nmero que contm o padro "123" em
qualquer parte do nmero. Especificamente, voc pode usar os indicadores numricos de incio e fim.
Os prximos exemplos ilustram isso.
Exemplo 2
Este exemplo mostra como substituir qualquer ocorrncia de "123" no incio de um nmero para
"456".
rule 1 /^123/ /456/
These are test voice translation-rule examples.
Matched with rule 1
Matched with rule 1
6123 Didn't match with any of rules
Exemplo 3
Se voc quer apenas a correspondncia de um nmero exato, deve especificar o indicador de incio e
fim.
rule 1 /^123$/ /456/
Matched with rule 1
Utilizando o CCP para Configurar um Dial-Plan no CME

Se voc preferir pode utilizar tambm o Cisco Configuration Professional (CCP) para configurar ou
modificar seu plano de discagem no CME. As configuraes referentes ao dial-plans esto na pasta
chamada Dial Plans, conforme figura abaixo:
Voc pode criar dial plans para dial peers POTS e VOIP, os quais podem ser configurados com as
seguintes opes:
Create Incoming Dial-Plan: Voc cria planos de discagem de entrada (inbound) em dial peers
utilizando troncos PSTN.
Create Outbound Dial-Plan: Nessa opo voc configura dial peers de sada (outbound)
utilizando tambm troncos com a PSTN. Um wizard permite que voc escolha o nmero de
acesso ao tronco (por exemplo, 9 para pegar a linha externa) e as informaes referentes ao
caller ID.
Import Outgoing Dial-Plan Template: Nessa opo voc pode importar um dial-plan a partir de
um arquivo em formato CSV.
Nesse primeiro modelo de configurao voc utilizar uma ferramenta do tipo wizard, ou seja, uma
configurao guiada para facilitar a criao do dial plan. Voc pode ainda criar seus dial peers e dial
plan manualmente, conforme tela mostrada abaixo:
Uma diferena entre a criao dos dial peers pots e voip via CCP que para os dial peers do tipo VoIP
no possuem wizard, apenas configurao manual.
Entendendo e Configurando Class of Restriction (COR) no CME
Nesse ponto j aprendemos a criar um sistema que possibilita nossos ramais internos do CME, os
ephones, e demais dispositivos possam se comunicar atravs da rede IP, atravs do VoIP, comunicarse com a rede PSTN e tambm com um PABX, atravs de interfaces digitais e analgicas de voz,
criando um sistema com diversos recursos e possbilidades.
Mas ainda ficou faltando um ponto a ser tratado, como estamos falando de um sistema de telefonia
que pode utilizar a rede pblica PSTN, algumas restries podem ser necessrias, pois cada tipo de
usurio tem uma necessidade e determinadas permisses.
Por exemplo, porque um atendente de Call Center precisaria fazer ligaes internacionais? Ou ento
como posso bloquear chamadas para celular? Ou ainda bloquear ligaes de longa distncia (DDD)
para funcionrios que no necessitam desse tipo de recurso para seu dia a dia?
Resumindo, algumas vezes restries so necessrias e precisamos tratar cada perfil de
usurio conforme suas necessidades reais, evitando assim o uso indevido dos recursos da empresa,
pois determinadas ligaes podem representar um custo alto para a empresa.
Se voc est implantando a plataforma Cisco Unified Communications Manager (CUCM) voc tem
uma facilidade chamada Partitions and Calling Search Spaces (CSS), a qual permite realizar tais
restries. J no CMEtemos um equivalente chamado Class of Restriction (COR), as quais so listas
de permisso que podem ser colocadas tanto para chamadas entrantes como saintes.
Para realmente aprender a configurar e o funcionamento de uma COR list voc precisa realizar
algumas prticas, porm vamos tentar explicar o conceito de uma maneira mais abrangente.
Acompanhe abaixo:
Translation Profiles
1. Quando um usurio tira o telefone do gancho ele imediatamente associado a uma COR list
de entrada.
2. Quando o usurio incia a discagem, o roteador CME faz a correspondncia em um dial peer de
sada (outgoing dial-peer).
3. Se o dial peer de sada tem uma COR list configurada nele (outgoing dial-peer), o CME verifica
se o usurio est listado na COR list de entrada (incoming).
4. Se ele estiver listado nessa COR list de entrada o CME permite a chamada.
5. Se o ramal no estiver listado nessa COR list de entrada o CME no permite a chamada.
A maneira mais simples de aprendermos o que so COR lists praticando, vamos ento colocar mais
uma vez as mos na massa!
Veja a topologia que ser utilizada nesse primeiro exemplo.
Temos trs ephones configurados na rede interna, com os ramais 1000, 1001 e 1002 que podem
acessar a PSTN para fazer ligaes de emergncia (dial peer 10), fazer chamadas locais (dial peer 11)
ou de longa distncia (dial peer 12).
Algumas caractersticas adicionais sobre a configurao atual e necessidades de restrio por ramal:
Dial-peer 10: Utilizado para chamadas de emergncia (destination-pattern 911).

Dial-peer 11: Utilizado para ligaes locais via PSTN (destination-pattern [2-9]......).
Dial-peer 12: Utilizado para ligaes DDD (destination-pattern 1..........).
A empresa fica situada nos Estados Unidos, por isso seguimos o padro de numerao
Americana.
Restries de chamada para os ephones:
o Ephone-dn 1 (x1000): pode fazer chamadas internas e para telefones de emergncia,
pois est situado na recepo e de acesso ao pblico.
o Ephone-dn 2 (x1001): este um telefone de um funcionrio que pode fazer ligaes
internas, para os nmeros de emergncia e para a PSTN, porm somente chamadas
locais.
o Ephone-dn 3 (x1002): este um ramal de um gerente, por exemplo, o qual no tem
restries de chamadas, pode fazer inclusive chamadas DDD.
Para configurar a COR list em nosso roteador CME precisamos seguir os passos abaixo:
1. Definir as chaves que utilizaremos para fazer as restries via COR list (nomes de
referncia para cada classe de restrio).
2. Criar as COR lists de sada (outbound).
3. Criar as COR lists de entrada (inbound).
4. Vincular as COR lists de sada aos dial peers.
5. Vincular as COR lists de entrada aos ephone-dn.
Vamos iniciar pelo passo 1 definindo os nomes para as classes de restrio. Voc pode e deve utilizar
nomes que lembrem o que desejado fazer com aquela cor list.
At agora foi simples e no fizemos absolutamente nada ainda em termos de restrio, somente
criamos os nomes para as classes de restrio. Agora vamos ao prximo passo que criar as cor lists
de sada que mais tarde faremos o vnculo com os dial peers PSTN.
Note que aqui criamos nomes como 911-CALL, o qual vai indicar um dial peer para chamadas via 911,
LOCAL-CALL ser para as chamadas locais e o DDD-CALL ser para as chamadas DDD.
Prximo passo criar as COR lists de entrada, veja como faremos a configurao.
Note uma diferena nessa configurao, agora estamos definindo que tipo de ligao o ephone
poder fazer, vamos vincular tudo mais tarde.
Vamos criar trs categorias de discagem, a 911-ONLY, ou seja, uma categoria para deixar o telefone
ligar para 911, outra para chamadas locais e 911 chamada 911-LOCAL, e por ltima uma que permite
tudo, 911, LOCAL e DDD.
Agora vamos aos dois ltimos passos que ligar as COR lists de sada nos dial peers que tem vnculo
coma PSTN e as COR list de entrada vamos ligar com nossos ephones.
Como voc pode notar durante a configurao, ambas cor lists foram criadas da mesma maneira,
tanto entrada como sada (inbound e outbound), porm o significado para o roteador muda
dependendo de como voc aplica essas COR lists, pois se voc aplica uma COR list na direo de sada
(outbound) voc est dizendo para o roteador que ele precisa verificar se o ramal (caller quem est
fazendo a chamada) tem a chave que o permite completar a chamada (nome definido no passo 1). Ao
passo que para uma COR list aplicada na direo de entrada (inbound) diz se o roteador vai definir
certas chaves que permitem ou no que o ramal realize uma chamada.
Fica bem claro a explicao acima quando vemos os nomes dados e os vnculos criados. Nos dial peers
de sada, os quais so os POTS que tem a conexo com a PSTN, definimos que servio cada um
destinado (ligaes 911, local ou DDD). J para os COR de entrada (incoming) configurados nos
ephones definimos que tipo de dial peer cada ramal pode acessar, se somente 911, 911 e local ou
911/local/DDD. Bem simples analisando dessa maneira.
Portanto, a COR list de entrada tem a chave e a COR list de sada a trava (lock and key). Para facilitar
o entendimento alguns utilizam do seguinte macete Chave e Fechadura.Para voc abrir a
fechadura de sada (COR list de sada) e ganhar acesso a ligao, seu telefone precisa ter a chave (COR
list de entrada) correta.
Uma observao importante que os dial peers 10, 11 e 12 esto configurados corretamente.
Importante: Se voc no configurar uma COR list de entrada voc ter acesso a quaisquer dial peers,
como ter a chave mestra para todas as sadas. Da mesma maneira, se voc no configurar uma
COR list de sada como no colocar a trava no sistema, permitindo quaisquer ligaes.
Testando a Configurao das Restries do Exemplo Anterior
Vamos fazer duas simulaes de ligao, sendo que a primeira vai ser originada a partir do telefone
que est na rea comum, o ephone-dn 1. Acompanhe abaixo:
Teste de Ligao 01
1. Um usurio tira o telefone do gancho e disca 4805551011.
2. O CME imediatamente vincula esse ramal COR list 911-ONLY, que tem vinculada apenas a
chave 911.
3. O CME faz a correspondncia com o dial peer de sada (outbound) 11, o qual tem a COR list de
sada (outgoing) LOCAL-CALL.
4. Lembre que a COR list de sada LOCAL-CALL precisa da chave LOCAL.
5. Como o telefone da recepo tem apenas a chave 911 a chamada no ser completada e o
usurio receber um reorder tone.
Agora vamos fazer uma chamada para um nmero local da PSTN discado pelo telefone do funcionrio
da empresa, o ephone-dn 2. Acompanhe abaixo:
Teste de Ligao 02
1. O empregado retira o telefone do gancho e disca 4805551011.
2. O CME imediatamente vincula o ramal COR list 911-LOCAL, a qual tem as chaves 911 e LOCAL
configuradas nela.
3. O CME ento faz a correspondncia (matches) o dial peer de sada com o nmero 11, o qual
tem a COR list de sada LOCAL-CALL vinculada.
4. A COR sada LOCAL-CALL precisa que a chave LOCAL esteja presente.
5. Como o empregado tem vinculado ao seu ramal as chaves 911 e LOCAL a chamada ser
completada com sucesso.
Importante: Apesar de termos configurado em nosso exemplo as COR lists de entrada nos ephones e as de sada
nos dial peers, isso no uma regra. Voc pode fazer outras combinaes de acordo com a necessidade de cada
cenrio. Por exemplo, voc pode aplicar uma COR list de entrada em um dial peer da PSTN para restringir acesso a
determinados ramais internos que esto em uma faixa de DID.
Para finalizar o tpico lembrem-se das duas regras j citadas nesse tpico, veja abaixo:
Regra 1: Se nenhuma COR list de sada aplicada a chamada ser encaminhada.
Regra 2: Se nenhuma COR list de entrada aplicada a chamada ser encaminhada.
A regra 1 significa que se voc deseja criar um dial peer PSTN (pots) que pode ser acessado por
todos os telefones basta voc simplesmente no aplicar nenhuma COR list de sada (outgoing). Com
isso esse dial peer no precisa mais de uma chave de COR list para completar a chamada. Mesmo que
uma COR list de entrada esteja aplicada a um ephone-dn a chamada utilizando esse dial peer PSTN
ser realizada com sucesso, pois no h restrio na COR list de sada requisitando uma chave
especfica.
J a segunda regra significa que se um dispositivo, como um ephone-dn, no tem uma COR list de
entrada ele pode fazer chamadas independente de uma COR list de sada estar aplicada ao dial
peer. Aqui podemos ver que para a COR funcionar sempre precisa de uma COR list de entrada
encontrando uma COR list de sada, caso uma delas esteja faltando o CME ir permitir a chamada.
Informao extra:
Com essas duas regras melhor entendidas, como poderamos aperfeioar nosso exemplo prtico
tratado nesse captulo? Ser que poderamos melhorar essa configurao?
Vamos ver duas otimizaes possveis. A primeira leva em conta a regra 1, pois se um determinado
dial peer de sada pode ser utilizado por todos os dispositivos basta no colocarmos uma COR list de
sada, portanto poderamos deixar o dial peer 10, o qual tem a sada para o telefone de emergncia,
sem nenhuma COR list de sada, pois ele permitido para os trs tipos de usurios definidos no
exerccios.
A segunda otimizao seria para o ephone-dn 3, que relativa ao telefone dos gerentes, como ele
no tem restrio alguma simplesmente no colocando uma COR list de entrada ele seria permitido
fazer quaisquer tipo de ligaes, pois a regra 2 diz justamente isso.
Apesar dessas otimizaes serem possveis, recomenda-se utilizar COR lists para todos usurios,
assim voc no corre o risco de deixar buracos para serem utilizados para burlar as polticas de
permisses definidas para a empresa.
Qualidade de Servios (Quality of Service QoS)
Agora que aprendemos a configurar os telefones IP (ephones), interfaces para comunicao com a
telefonia convencional (PABX e PSTN) atravs de interfaces FXS, FXO, E1 e T1, configurar um plano de
discagem para nosso roteador CME e at fazer restrio de chamadas utilizando COR lists, estamos
prontos para efetivamente iniciar as chamadas atravs da rede IP.
Mas, ser que realmente estamos prontos? E nossainfraestrutura de redes, ou seja, nossas redes LAN
e WAN iro suportar as chamadas (tanto sinalizao como o fluxo da voz atravs do protocolo RTP)
assim como suportam os servios de dados tradicionais?
Transportar voz sobre o protocolo IP no uma tarefa to simples, pois cada aplicao tem uma
caracterstica (tamanho do quadro, quantidade de informao enviada, maneira que envia essa
informao, ect), as quais podem prejudicar e muito o fluxo dos pacotes de voz pela rede IP, por isso
preciso uma maneira especial para tratar esses pacotes do VoIP chamada Qualidade de Servios
(QoS).
Para que uma rede VoIP possa operar com qualidade a voz deve receber um tratamento especial, ou
seja, os pacotes de voz precisar ser priorizados quando cruzam a rede de dados at chegar ao seu
destino. Por isso, implantar a tecnologia de voz sobre IP exige uma rede que suporte o QoS fim a fim,
desde o dispositivo que gerou os pacotes de voz at o que vai receber esses pacotes. Veja abaixo a
definio da Cisco sobre QoS.
Qualidade de servios a habilidade da rede fornecer o melhor servio (de uma maneira especial)
para determinados usurios ou aplicaes em detrimento de outros usurios e aplicaes.
O servio de voz um servio de tempo real, ou seja, precisa de um fluxo constante e sem atrasos
(delay), por isso precisa ser tratado como um servio especial. Se voc est acessando a internet ou
utilizando um programa FTP para baixar arquivos, quando a sua rede tem um problema a pgina ou
arquivo iro demorar um pouco mais para carregar, ir aumentar o tempo total do download, mas
voc no final ir receber o arquivo ou a pgina de internet no seu browser. Porm, em uma chamada
de voz via IP se a rede comea a ter atrasos ou delay a conversao pode ficar truncada ou
sobreposta, pois devido ao atraso as pessoas comeam a falar ao mesmo tempo, a conversao
comea a ficar picotada (ter quebras) e pode at cair em casos extremos.
Para evitar esse tipo de problema voc ter que, alm de garantir uma banda para o VoIP, certificarse que essa banda ser alocada em primeiro lugar para a voz sobre IP.
Isto significa que se houver um gargalo de rede onde o roteador precisa enfileirar o trfego antes de
envi-lo atravs da rede, o roteador ter que mover o trfego de voz para frente do trfego de dados
na fila de sada para garantir que a voz seja enviada no primeiro intervalo disponvel.
Na realidade o QoS no uma ferramenta e sim um conjunto de ferramentas utilizadas
para controlar o trfego atravs da rede. Muitas vezes voc consegue garantir o QoS com apenas
uma tcnica ou ferramenta, porm quando os requisitos da aplicao, tais como largura de banda e
delay, forem muito complexos ser necessrio utilizar vrias tcnica simultaneamente para, por
exemplo, controlar o delay, reservar largura de banda (bandwidth) e comprimir o cabealho dos
dados quando eles esto atravessando as redes WAN para melhorar o desempenho da rede e do VoIP
como um todo.
Portanto, j mencionamos que a largura de banda insuficiente e o atraso (delay) so srios inimigos
do trfego VoIP, porm vamos analisar com um pouco mais de detalhe cada um deles e
complementar essa lista. Acompanhe abaixo:
Falta de largura de banda: vrios fluxos de voz e dados competindo por uma largura de banda
limitada para envio das informaes podem causar falta na largura de banda.
Delay ou atraso: o tempo que um pacote leva para ser transmitido do ponto de partida at o
seu destino. Ele pode ser dividido em trs tipos:
o Fixo: esse valor voc no pode alterar, pois so intrnsecos de cada tecnologia, por
exemplo, um pacote levar um tempo fixo para trafegar em longas distncias atravs de
um backbone IP e esse valor fixo, portanto o QoS no pode tratar com esse tipo de
atraso.
o Varivel: valores de delay que voc pode alterar. Por exemplo, o atraso por
enfileiramente (queuing delay quanto tempo um pacote espera em uma fila de uma
determinada interface do roteador) varivel, pois depende de quantos pacotes esto
atualmente na fila da interface esperando para serem enviados. Voc pode alterar esse
delay da fila (queuing delay queue fila em ingls e se pronuncia Kiu) escolhendo os
pacotes que sero enviados primeiro, por exemplo, passando os pacotes de voz na
frente dos pacotes de dados.
o Jitter (variao no delay): so pacotes que chegam com atrasos diferentes no destino,
por exemplo, o primeiro pacote chega com 90 ms (mili segundos ou 1 segundo divididos
por mil 0,001s), enquanto o segundo pacote chega com 110 ms, ou seja, uma diferena
de 20 ms entre o primeiro e o segundo pacote de voz. Portando dizemos que h 20 ms
de variao de delay (jitter) entre os pacotes.
Perda de pacotes (Packet loss): a perda de pacotes pode ocorrer por dois motivos bsicos,
devido a um congestionamento na rede ou pela rede no ser confivel (problemas de
infraestrutura ou dimensionamento).
Os problemas citados ao lado so as principais dificuldades em se utilizar um ambiente de rede de

dados, porm quando adicionamos servios de voz (VoIP) eles seagravam, pois alm do trfego de
dados existentes a rede ter que suportar o novo trfego de voz com requisitos mais complexos de
qualidade.
Alm disso, administradores que trabalham com um ambiente de voz tradicional com PABX esto
acostumados com um sistema que est isolado e com banda garantida para o trfego de voz. A
tolerncia a quebras, eco ou chamadas pedidas em redes de voz tradicionais bastante baixa, pois o
sistema dificilmente tem paradas ou interrupes.
Portanto o objetivo do QoS fornecer uma largura de banda consistente para o trfego de voz de
uma maneira que haja um pequeno, mas constante e previsvel, delay de uma ponta a outra da rede.
Para isso precisamos implementar o QoS de uma forma aevitar congenstionamento em cada ponto
da rede que ele possa existir, implementanto um processo fim a fim, o qual tenha a capacidade de
analisar a rede e determinar os tipos de trfego que existem e que nveis de servios esses trfegos
precisam para serem transmitidos com qualidade e com a devida prioridade.
Requisitos de Rede para Voz, Vdeo e Dados
Conforma j mencionamos anteriormente nesse captulo, diferentes tipos de trfego circulam pela
rede e cada um pode exigir requisitos de QoS diferentes. Alguns protocolos, tais como HTTP, so
menos exigentes e podem funcionar com pouca largura de banda e suportam bem o delay. Outros so
mais so mais exigentes, precisam de largura de banda disponvel com pouco delay, caso dos trfegos
de voz e vdeo.
Diferente do trfego de dados, um fluxo de voz previsvel, ele se mantm constante durante toda a
ligao (lembre que essa largura de banda depende basicamente do tipo de codec escolhido). Isso j
no ocorre com um fluxo de dados, o qual pode saltar repentinamente quando fazemos um download
de grande porte atravs da Internet, podendo at ocupar toda a banda com esse download.
Porm, alm dos requisitos de largura de banda, o qual definido principalmente
pelo codec utilizado para fazer a converso da voz para digital, o trfego de voz depende tambm dos
requisitos citados abaixo:
Delay fim a fim (End-to-end delay): 150 ms ou menor

Jitter: 30 ms ou menor
Perda de pacotes: 1% ou menor
O vdeo tem requisitos idnticos aos de voz, porm precisa de uma largura de banda maior. Alm
disso, essa banda utilizada pode variar dependendo dos movimentos que o vdeo tem, pois quanto
mais movimento mais largura de banda necessria.
J os requerimentos de dados so mais complexos e no podem ser tradados como um s servio, por
isso normalmente ele dividido em quatro categorias macro. Acompanhe abaixo:
Aplicaes de misso crtica (Mission-critical applications): So aplicaes crticas para a

organizao e necessitam de muita largura de banda dedicada.
Aplicaes transacionais (Transactional applications): So aplicaes normalmente interativas
e necessitam de resposta rpida aos usurios, como por exemplo uma consulta a base de dados
de clientes para atendentes de call center.
Aplicaes Best-effort (melhor esforo): So aplicaes menos crticas e no categorizadas, por
exemplo, acesso web, e-mail e transferncias FTP.
Scavenger applications: Esses so aplicativos que consomem um alto valor de largura de banda
e no so de interesse organizacional, tais como Kazaa, BitTorrent e LimeWire, aplicativos de
transferncia de arquivos peer-to-peer.
Voc pode na realidade vincular cada tipo de aplicao a um nvel especfico de QoS, mapeando as
aplicaes atravs de vrios mtodos, tais como interface de entrada ou sada, access lists, e assim
por diante.
Caractersticas dos fluxos de Dados
Smooth or Bursty (Contnuo ou em rajadas): um fluxo de dados pode ser contnuo (smooth) ou
em rajadas (bursty), ou seja, pode ocupar a rede de qualquer maneira.
Drop insensitive (no sensvel a perda de pacotes): no sensvel a perda de pacotes em sua
maioria podemos at dizer que drop insensitive, ou seja, no sensvel a perda de pacotes
devido aos mecanismos de retransmisso e confirmao do TCP.
Delay insensitive (no sensvel a delay): no tem problemas com relao ao delay (atraso) de
rede.
Benign or greedy (benigno ou agressivo na alocao de banda): pode ou no oferecer risco ao
trfego de redes, ou seja, pode ser benigno (benign) ou agressivo (greedy ganancioso). Uma
aplicao P2P como o Kazaa pode ocupar toda a banda de rede em segundos.
TCP retransmit (se utiliza de retransmisses TCP):utiliza a retransmisso do TCP em caso de
problemas de comunicao, pois maioria das aplicaes de dados utilizam TCP.
Caractersticas dos fluxos de Voz
Smooth (contnuo ou suave): fluxo continuo durante a chamada estabelecida, pois os codecs
utilizam uma taxa previsvel.
Delay sensitive (sensvel ao atraso): tem sensibilidade ao atraso (padro 150ms).
Drop sensitive (sensvel perda de pacotes): tem sensibilidade perda de pacotes (padro
menor que 1%).
Benign (benigno): ocupa a rede de forma previsvel e com uma banda fixa por chamada.
UDP priority (precisa de priorizao UDP): precisa de ter prioridade UDP, pois o RTP trabalha
com o servio de UDP para transmitir a voz pela rede.
Caractersticas dos fluxos de Vdeo
Bursty (transmisso em rajadas): trabalha com o envio da diferena nas imagens em

movimento e normalmente acaba enviando uma rajada de dados quando as alteraes no
quadro so grandes, por isso considerado Bursty.
Greedy: agressivo na alocao de banda, normalmente requer muito mais banda que as
chamadas de voz.
Delay sensitive (sensvel ao atraso): tem sensibilidade ao atraso.
Drop sensitive (sensvel perda de pacotes): tem sensibilidade perda de pacotes.
UDP priority (precisa de priorizao UDP): precisa de ter prioridade UDP, pois o RTP trabalha
com o servio de UDP para transmitir a voz pela rede.
Mecanismos de QoS
Para se adequar a diferentes requisitos de diferentes aplicaes vrios mecanismos de QoS surgiram
ao longo do tempo, vamos analisar os principais disponveis atualmente.
Mecanismos de QoS
Best Effort ou Melhor Esforo: o melhor esforo a maneira padro que a rede opera, ou seja, sem
nenhum mecanismo de QoS implementado nela. Sem mecanismos de QoS a rede trata todo trfego
de uma maneira first come, first served (first in, first out), ou seja, quem chega primeiro o que
utiliza o servio. Este tipo de mecanismono atende as exigncias de QoS das redes atuais.
Integrated Services (IntServ): j o IntServ funciona em um modelo baseado em reservas. Por
exemplo, uma chamada que utiliza 100kbps precisa ser realizada pela rede, se essa rede foi projetada
para trabalhar apenas com o modelo IntServ ela reservaria 100Kbps em todo dispositivo de rede
situado entre os telefones que iro se comunicar utilizando o protocolo RSVP (Resource Reservation
Protocol protocolo de reserva de recursos).
Durante toda chamada essa banda de 100Kbps fica disponvel para a ligao. Apesar de ser o nico
modelo que fornece essa garantia de banda o IntServ tem um problema de escalabilidade, porque um
nmero muito grande de reservas poderia consumir toda a banda disponvel na rede.
Differentiated Services (DiffServ): o DiffServ atualmente o modelo mais flexvel e popular entre as
implementaes de QoS na atualidade. Nesse modelo voc pode configurar cada dispositivo de rede
de maneira que ele responda aos variados tipos de trfego com uma variedade de mtodos de QoS,
possibilitando criar diversas classes de trfego, cada uma com um tratamento especfico.
Uma diferena entre o Diffserv e o IntServ que com o primeiro o trfego no pode ser garantido,
uma vez que os dispositivos no trabalham com reserva de banda. Porm, segundo documentao
oficial da Cisco, o DiffServ pode chegar muito prximo a garantia de banda, sendo um modelo que
consegue tratar dos problemas de escalabilidade do IntServ, o que o tornou um padro de QoS
utilizado na maioria das organizaes ao redor do mundo.
Os modelos de QoS podem utilizar vrias estratgias para o projeto e implementao em toda a rede.
Os mecanismos de QoS combinam uma srie de ferramentas para fornecer diversos nveis de servio
para que o trfego de rede possa atravessar a rede, sendo que essas ferramentas se enquadram nas
categorias abaixo:
Ferramentas de QoS
Classificao e Marcao (Classification and Marking): so ferramentas que permitem a
identificao e marcao dos pacotes para que os dispositivos possam identificar e dar o devido
tratamento ao trfego que cruza a rede. Normalmente o primeiro dispositivo que recebe os pacotes
faz a identificao utilizando ferramentas como access-lists, interfaces de entrada ou deep packet
inspection (inspeo da aplicao), ferramentas que podem utilizar o processamente de maneira
intensiva e adicionar delay ao pacote. Depois de identificado, ento o pacote marcado, sendo que
essa marcao pode ser feita no cabealho da camada-2 (enlace/data link permitindo que os
switches possam ler essa marcao) e/ou no cabealho da camada-3 (rede/network) para que os
roteadores possam ler essa marcao. Com isso os pacotes podem atravessar a rede e serem lidos
pelos equipamentos sem que uma anlise mais profunda precise ser realizada a cada salto,
permitindo que os pacotes sejam tradados de acordo com sua marcao.
Controle de Congestionamento (Congestion Management): o controle de congestionamento
basicamente tratado pelas estratgias de QoS para enfileiramento (queuing), as quais so as
ferramentas bsicas de QoS que devem ser implementadas em toda a rede. Essas ferramentas e
estratgias de enfileramente so aplicadas quando ocorre o congestionamento, ou seja, so
ferramentas reativas. Basicamente o roteador ter que decidir quem vai ser liberado primeiro quando
houver disponilibidade de banda durante um congestionamento, enfileirando o restante do trfego
em um buffer (espao de memria RAM reservado para armazenamento temporrio dos pacotes).
Congestion Avoidance: em portugus poderamos traduzir esse mecanisco para Preveno de
Congestionamento. A maioria dos mecanismos de QoS entram em ao quando ocorre o
congestionamento, so reativos, aqui a filosofia diferente, tenta fazer um trabalho preventivo para
evitar que o congestionamento ocorra. Esse mecanismo utiliza tcnicas como excluir (drop) trfego
no interessante ou no essencial antes que um trfego muito pesado cause um congestionamento.
Policing and Shaping: aqui so criadas polticas (policy) de trfego e o modelamento (shaping), onde
a poltica normalmente utilizada para filtrar o trfego excessivo e o modelamento faz o
enfileiramento do trfego excessivo para depois envi-lo na rede. Normalmente so utilizados quando
a largura de banda pode ser maior que a velocidade fsica da rede ou interface, como no caso do
Frame-relay.
Link Efficiency: em portugus eficincia do link ou enlace, so tcnicas utilizadas no estgio final
da transmisso, ou seja, no momento de enviar os pacotes por uma interface (link). Podem ser
utilizadas tcnicas de compresso, por exemplo, para melhorar a performance de um link de baixa
velocidade.
As tcnicas de QoS so to complexas que para entender completamente o QoS a Cisco dedicou uma
prova inteira no currculo do CCNP Voice. Aqui no CCNA Voice a Cisco escolheu utilizar o auto-qos,
que veremos a seguir, e o dividiu em duas categorias chaves: mecanismos de eficincia de link e
algoritmos de enfileiramento.
Eficincia dos Links e Algortmos de Enfileiramento
Com o avano da tecnologia os links utilizados entre asredes WAN das empresas tem se tornado cada
vez mais velozes, em pases como os Estados Unidos conexes abaixo de T1 (1.544Mbps) esto se
tornando cada vez mais raras de serem encontradas, porm em pases como o Brasil ainda temos
muitas regies onde as conexes E1 so raras e em sua maiora as empresas trabalham com mltiplos
de 64kbps (DS0), velocidades como 64, 128, 256, 512 1M a 2Mbps. Nas capitais e cidades maiores os
LAN-to-LAN, conexes WAN de alta velocidade, tem se tornado cada vez mais difundida. O problema
das interfaces com conexes mais lentas que normalmente a falta de largura de banda (bandwidth)
torna difcil o envio dos pacotes na quantidade e velocidade necessria.
Isso acaba impactanto no atraso (delay) fim a fim devido ao processo de serializao, que
o tempo que o roteador leva para retirar os pacotes do buffer e colocar na linha efetivamente. Fica
fcil entender que quanto maior o pacote maior o tempo de serializao, por exemplo, para mandar
um pacote de 1500 bytes em uma linha de 56Kbps o delay devido a serializao chega a 214ms
(lembrem que o atraso recomendado para voz de 150ms ou menos).
Para tratar desses tipos de problemas da eficincia dos links de baixa velocidade
algumas metodologias podem ser utilizadas, conforme abaixo:
Payload Compression (compresso dos dados):utilizando algoritmos de compresso dos dados
enviados o roteador tem menos dados para passar atravs dos links WAN de baixa velocidade.
Header Compression (compresso do cabealho):alguns tipos de trfego, assim como o VoIP,
enviam poucos dados na camada de aplicao (udio RTP) em cada pacote, porm enviam muitos
pacotes na rede. Nesses casos os cabealhos (header) acabam consumindo uma largura de banda
significativa em relao aos dados, portanto a compresso ou compactao do cabealho pode ajudar
a economizar largura de banda eliminando campos redundantes no cabealho dos dados. A
compresso do cabealho do RTP, chamada de Compressed Real-time Transport Protocol (cRTP),
pode reduzir um cabealho de 40 bytes para 2 a 4 bytes. importante lembrar que essa tcnica deve
ser aplicada em ambas as interfaces do link WAN.
Link Fragmentation and Interleaving (LFI Fragmentao e Intercalao): O LFI trata do problema
do delay gerado pela serializao quebrando (fragmentao ou fragmentation) os pacotes maiores em
pedaos menores antes de serem enviados na interface. Isso permite o roteador intercalar os pacotes
do VoIP entre os pedaos fragmentados dos dados no fluxo de sada da interface (chamado
interleaving). O LFI est disponvel para conexes PPP que utilizam o multilink e no Frame Relay,
utilizando o FRF.12 ou FRF.11 Anexo C.
importante aqui ressaltar que essas tcnicas para melhorar a eficincia dos links de baixa
velocidade tm pontos negativos.
Por exemplo, a compresso dos dados causa mais atraso(delay) e aumenta a carga de
processamento do roteador (CPU). Outro exemplo, agora com a fragmentao, ela acaba
aumentando o nmero de pacote enviados na rede, isso acaba ocupando mais banda da rede, pois
cada novo pacote gerado pela fragmentao precisa de um novo cabealho adicionando informaes
de controle que consomem banda.
Por esses motivos, esses mtodos no so recomendadospara interfaces de alta velocidade, tais
como o E1 e T1.
Uma importante informao para o dia a dia que um roteador projetado para processar um
nmero de pacotes por segundo, o pps ou packet per second (pacote por segundo).
Portanto, se a sua rede tiver muitos pacotes o roteador pode no ser capaz de process-los e acaba
aumentando o uso da CPU e memria RAM at ao ponto de travar o roteador.
Diferentemente das tcnicas estudades para eficincia dos links, o enfileiramento ou queuing
definem regras que os roteadores devem utilizar quando ocorre um congestionamento.
As maiorias das interfaces de rede utilizam por padro uma tcnica de enfileiramento bsica
chamada First-in, First-out (FIFO o primeiro que entra o primeiro que sai), ou seja, o pacote que
chega primeiro enviado primeiro, simples assim. O problema desse tipo de fila que o trfego de
rede no igual, os pacotes podem variar em tamanho dependendo da aplicao, por exemplo, como
j vimos o VoIP (RTP) tem pacotes pequenos e em grande nmero, j um pacote enviado entre um
storage e um sistema de backup so os maiores possveis que a rede pode enviar (MTU mximo),
agora imagine esses dois trfegos sendo passados ao mesmo tempo na rede, com certeza utilizando
FIFO a voz iria sofrer muito.
Portanto, o enfileiramento (queuing) tem um objetivo bsico de dar prioridade ao trfego mais
crtico da rede e que tem necessidade de baixo atraso (tempo real), por isso podemos utilizar as
seguintes trs tcnicas no lugar do enfileiramento FIFO. Veja abaixo:
Weighted Fair Queuing (WFQ): WFQ tenta balancear a disponibilidade de largura de banda entre os
fluxos que esto sendo enviados de maneira igual, por isso o nome fair-queuing, em portugus fila
justa ou igualitria. Utilizando esse mtodo um usurio que est utilizando uma largura de banda
para enviar seus dados tem uma menor prioridade que outro usurio de baixa velocidade. Muitas
vezes o WFQ o mtodo padro utilizado pelas interfaces serias nos roteadores Cisco.
Class-Based Weighted Fair Queuing (CBWFQ): Class based quer dizer basado em classes, isso diz
muito sobre esse mtodo de enfileiramento. Com o CWFQ voc pode definir uma largura de banda
para determinados tipos de trfego. Por exemplo, voc pode dedicar 20% da largura de banda
(bandwidth) para o VoIP (RTP) e 40% para um determinado aplicativo da empresa, como o SAP. Assim
os 40% restantes da banda que no foram especificados na CWFQ so tratados pelo roteador
utilizando uma fila WFQ.
Low Latency Queuing (LLQ): O LLQ tambm conhecido como PQ-CBWFQ, pois ele exatamente
igual ao CBWFQ com a adio de uma priority queuing (PQ prioridade da fila) em seu
funcionamento.
Existem outros mtodos alm dos citados anteriormente, porm nas redes atuais esses trs so os
mais utilizados.
Para o VoIP a fila mais indicada a LLQ, pois o trfego prioritrio alm de ter a largura de banda
garantida enviado antes dos demais trfegos. J no CBWFQ puro, um trfego pode ter uma garantia
de 60% de largura de banda e mesmo assim no ter seu trfego enviado antes do roteador garantir
outros trfegos que esto tambm priorizados.
A tabela abaixo mostra quais os mecanismos de QoS voc pode aplicar de acordo com a direo do
trfego.
Lembre que o trfego pode ser de entrada ou sada.

A tratativa de um pacote de voz que est entrando na interface pode ser diferente da que devemos
fazer quando esse pacote sai para a rede, pois ele pode entrar em um tipo de interface (LAN) e sair
por outro (WAN).
Cisco AutoQoS e Trust Boundary
Aplicar o QoS nos dispositivos de rede no uma tarefa simples, tanto que existe uma prova do CCNP
Voice especialmente para tratar desse assunto. Por esse motivo e para acelerar o aprendizado sobre
QoS, a Cisco criou ummecanismo chamado AutoQoS, capaz de habilitar vrios mecanismos de QoS
mesmo para administradores com pouco conhecimento do assunto.
O AutoQoS nada mais que uma srie de templates (padres) de QoS que aplicam as melhores
prticas (best practices) levando em conta o tipo de encapsulamento da interface que o roteador ou
switch possui.
Abaixo voc pode verificar algumas das vantagensque o AutoQoS oferece em relao a uma
configurao manual.
Reduo no tempo de implementao (deployment): muito mais simples e rpido entrar no
roteador com um nico comando do que digitar uma srie de comandos complexos para configurar o
QoS.
Fornece uma configurao consistente e homognea: com um comando de QoS o template em
cada equipamento (padro de configurao) ser o mesmo, evitando problemas como esquecimento
de comandos durante uma configurao manual.
Reduz o custo da implementao de um projeto:mais uma vez, aqui um comando contra vrios,
alm do tempo para treinar e deixar todos cientes das facilidades de QoS que sero implementadas.
Permite ajustes manuais (tuning): aps aplicar o AutoQoS voc pode fazer um ajuste fino para
necessidades especficas ou crticas de QoS para determinados servios de rede.
Porm precisamos ver um conceito antes de aplicar o AutoQoS. O trust boundary para o trfego de
voz, o qual podemos traduzir como limite ou fronteira de confiana. Tudo inicia quando enviamos
um determinado trfego na rede e esse trfego pode estar ou no com marcaes de QoS, tais
marcaes so utilizadas para identificar e dar a devida prioridade para cada tipo de classe de trfego.
Porm, essas marcaes podem ser ou no ser confiveis, ou seja, ser que o equipamento que fez a
marcao tinha realmente autoridade para isso?
Um telefone IP da Cisco, por exemplo, j faz a marcao dos seus pacotes de voz como prioritrios
antes de envi-los na rede e essa marcao realmente confivel, pois o trfego de voz deve ter
prioridade sobre os demais. Agora imagine que um usurio instalou um programa que marca os
quadros dessa aplicao no prioritria como se fossem quadros de voz, ou seja, com alta prioridade,
com certeza no podemos confiar nessa marcao.
Portanto, o limite de confiana ou trust boundary o ponto onde vamos confiar naquela marcao
que est sendo recebida e utiliz-la para dar a devida prioridade aos pacotes, ou seja, o ponto onde
a partir dele a marcao de QoS est correta. Qual esse limiar ou fronteira? Tudo depende das
caractersticas de cada equipamento, se o dispositivo do usurio tiver uma marcao confivel voc
pode utilizar a fronteira mais perto do usurio ou utilizar os equipamentos de rede para fazer a
marcao correta, veja a figura abaixo.
Os telefones IP da Cisco tem capacidade de fazer a marcao dos seus pacotes de voz e tambm
retirar a marcao de alta prioridade feita pelos computadores que esto ligados sua porta de
switch. Utilizando o telefone IP para fazer a marcao utilizamos o ponto 1 como limite de confiana
(trust boundary ou fronteira de confiana). Essa a situao ideal, pois evita que os switches tratem
de um volume muito alto de informaes para realizar a marcao no ponto B.
Se voc tem micros conectados diretamente aos switches de acesso e tem switches de acesso com
capacidade de marcao de QoS, voc pode fazer a marcao nesses equipamentos que esto
no ponto 2. Caso os switches de acesso no tenham capacidade de marcao de QoS voc pode
aplicar no ponto 3, ou seja, nos switches de distribuio, o que tambm funciona bem, porm traz
uma sobrecarga para esses equipamentos. Aplicando a marcao no ponto 3 voc ter os pacotes
trafegando pelos switches de acesso sem nenhum tratamento de QoS, porm como as velocidades na
LAN so maiores isso acaba no afetando a voz. O QoS fundamental onde podem haver gargalos
(bottleneck), porm recomenda-se aplic-lo em toda a rede (QoS fim a fim).
Uma informao importante sobre o AutoQoS que ele utiliza o Cisco Discovery Protocol (CDP)
para identificar que existe um telefone IP da Cisco IP conectados aos switches e ajustar corretamente
as configuraes de QoS. Isso garante que o usurio no possa retirar o telefone IP e conectar um
micro para utilizar o trfego priorizado e ganhar mais banda para si mesmo. Certifique-se tambm
que o CDP esteja habilitado nos telefones IP.
Nos equipamentos Cisco o CDP vem habilitado por padro, mas caso seja necessrio com o comando
em modo de configurao global cdp run voc pode ativar o CDP em todas as interfaces. Em modo
de interface voc pode ativar ou desativar o CDP com o comando cdp enable e no cdp enable.
Para verificar se o seu switch est identificando os telefones entre com o comando show cdp
neighbors, veja um exemplo abaixo:
Cisco AutoQoS - Configurao

Agora o prximo passo aplicar o AutoQoS nas interfacesque precisam ter o tratamento de QoS, ou
seja, que precisam realmente tratar o trfego ou precisam ser priorizadas na rede. Um detalhe
importante que voc precisa configurar a largura de banda correta nas interfaces Seriais antes de
aplicar o AutoQoS, pois ele no consegue detectar sozinho a velocidade dos links seriais, se voc no
configurar nada a velocidade padro de 1,5Mbps (T1).
Sobre as interfaces que voc deve ou no aplicar podem ser somente as que tm telefones IP ou
softphones, os trunks dos switches e as portas seriais e de LAN dos roteadores, ou ento, em todas as
interfaces dos switches e roteadores, garantindo que nada fique fora do esquema de QoS. Isso no vai
impactar a performance dos equipamentos.
Vamos ver na prtica a aplicao dos comandos do AutoQoS, frisando que eles podem variar um
pouco de sintaxe dependendo de onde so aplicados. Veja afigura abaixo que servir de base ao
nosso exemplo.
Vamos analisar a configurao de um switch Cisco Catalyst 2960 antes e depois do AutoQoS para
uma interface de trunk (entre o roteador e o switch fast 0/1) e depois em uma interface de acesso
(entre o switch e o telefone IP fast 0/2).
Notem que existem diferena nos comandos.

Como voc deve ter notado, temos trs opes para o comando auto qos voip:
Os comandos auto qos voip cisco-phone e auto qos voip cisco-softphone so utilizados
quando temos telefones IP ou o softphone chamado Cisco IP Communicator. Com isso o
switch detecta atravs do CDP a presena do dispositivo e d a devida prioridade a ele, alm
disso, confiando em sua marcao. Se o telefone ou o softphone Cisco for retirado o limite de
confiana quebrado evitando que um equipamento utilize a marcao de forma incorreta na
mesma porta.
J o comando auto qos voip trust pode ser utilizado nos trunks ou com telefones IP de outros
fabricantes.
Para apagar a configurao basta entrar na interface e digitar no auto qos voip.
Pode haver diferena ainda nas configuraes aplicadas dependendo do modelo dos
equipamentos utilizados.
Veja abaixo um exemplo do mesmo comando em um switch 3560:
Agora vamos aplicar os comandos em uma interface fast e serial de um roteador modelo 2801 com
IOS verso 15. Primeiro ser mostrado a configurao antes do comando, em seguida realizamos a
configurao e mostramos a interface aps o comando para analisarmos as diferenas.
Vamos iniciar com a configurao da fastethernet (figura abaixo).
Lembre que o roteador est entroncado com o switch e em sua interface fsica (fast 0/1) no temos
IP, os IPs esto nas subinterfaces lgicas criadas para suportar cada VLAN (fast 0/1.10 e fast 0/1.20).
Se voc tiver dvidas sobre VLANs e roteamento entre VLANs revise o material do CCNA.
Na figura abaixo vemos o mesmo procedimento para a interface serial.
Perceba que utilizamos o mesmo comando para as interfaces seriais e fast/giga nos roteadores.
Dependendo da verso de IOS que voc est trabalhando e o modelo do equipamento a sada aps o
autoqos pode variar um pouco.
Alm das configuraes feitas nas interfaces, o autoqosinsere vrios comandos em modo de
configurao global, tais como class maps, policy maps, interfaces multilink e muitos outros. A
explicao completa desses comandos vista no curso de QoS no CCNP Voice.
Vamos abaixo resumir os comandos utilizados e o que eles fazem na prtica nos roteadores e
switches.
auto qos voip: aplicado nos roteadores ou switches Layer 3 e habilita o AutoQoS sem confiar na
marcao recebida na interface, fazendo a remarcao de todos os pacotes baseado em ACLs ou
Network-Based Application Recognition (NBAR). O NBAR utiliza mais processador que a ACL. Para
informaes extras sobre o NBAR clique aqui.
auto qos voip trust: habilitado no roteador ou em um switch ativa o AutoQoS confiando na
marcao recebida atravs de sua interface de entrada confiando na marcao enviada por um
telefone IP Cisco detectado utilizando CDP.
auto qos voip cisco-phone: habilitado em um switch ativa o AutoQoS confiando na marcao
recebida atravs de sua interface de entrada quando um telefone IP Cisco detectado atravs do
CDP.
auto qos voip cisco-softphone: habilitado no roteador ou em um switch ativa o AutoQoS

confiando na marcao recebida atravs de sua interface de entrada quando um SoftPhone (como o
Cisco IP Communicator) Cisco detectado atravs do CDP.
As marcaes utilizadas pelo QoS podem ser feitas utilizando o Class of Service (CoS) e Type of
Service (ToS). O CoS uma marcao de camada-2 feita no cabealho do quadro e pode ser
identificado pelo switch. J o ToS uma marcao de camada-3, ou seja, na camada de rede, a qual
pode ser reconhecida por um roteador. O funcionamento desses tipos de marcao de QoS so
assuntos do CCNP Voice.
Configurando o Diretrio de Usurios (Voice Network Directory)
O diretrio de usurios uma funcionalidade que acaba com a necessidade de gerar listas com os
ramais dos vrios funcionrios das empresas, pois podemos inserir essas informaes de maneira
organizada e simples de ser buscada quando criamos os ramais no Cisco Unified Communication
Manager Express (CME).
Voc pode entrar com os nomes quando estiver configurando um ephone-dn depois que voc
configurar as diversas linhas da organizao. Estes nomes sero utilizados para formar o diretrio
local e tambm sero utilizados como caller ID (nmero de quem est chamando que aparece no
display).
Veja um exemplo abaixo de nomes que so inseridos individualmente aos ephone-dns.
Lembrete:
Um detalhe, aqui os ephones e ephone-dns j estavam criados, com os telefones testados e
registrados e somente inserimos o comando name aps tudo estar funcionando.
Para alterar o nome basta entrar no ephone-dn e digitar o comando "name" com o novo nome, no
precisa apagar o comando para trocar o nome. Para retirar a informao basta digitar no name
nome.
Agora com os nomes configurados no comando name dentro dos ephone-dns, quando voc receber
uma ligao do telefone configurado no ephone-dn 3, no seu ramal ir aparecer uma chamada
entrante do Dona Flor como caller ID no seu display, conforme figura abaixo:
Essas alteraes so imediatas, no precisam de reset no sistema ou no ephone-dn.

Agora vem o mais interessante, pois nos telefones IPs Cisco temos uma opo chamada Directory,
um boto que permite voc acessar o diretrio corporativo. Em alguns modelos voc no ter um
boto dedicado e ter que acessar o diretrio via menu de navegao. Ao pressionar o boto
Directory ou ir ao menu interno voc ver as categorias Missed Calls, Received Calls, e muitas
outras, v para baixo no menu at chegar no diretrio local ou Local Directory, conforme figura
abaixo:
Selecionando a opo Local Directory voc poder buscar o ramal de um usurio pelo nome ou
sobrenome, ou ento deixar o nome e o sobrenome em branco, selecionar o Submit para ver toda a
listagem. Veja figuras 2 e 3.
Figura 2
Figura 3
Por padro o diretrio do Cisco Unified CME organiza os nomes em ordem alfabtica atravs do
primeiro nome (first name) que voc configurou no comando name, para alterar essa opa voc
precisa entrar na configurao do telephony service e utilizar o comando directory. Com o
comando directory voc pode tambm entrar com nmeros que no esto vinculados a um aparelho
IP, criando entradas estticas na lista de diretrio. Veja um exemplo de configurao abaixo:
Com essa configurao fizemos o CME organizar os nomes pelo sobrenome (last name) e inserimos
um nmero no diretrio para a Recepo da DlteC como 30457810. Veja como aparece agora no
telefone na figura abaixo, note que os nomes esto invertidos, pois anteriormente configuramos
dentro do telephony-service para mostrar o ltimo nome primeiro na configurao do diretrio.
Configurando o Diretrio de Usurios via CCP

Alm disso, conforme visto no captulo 6, voc pode utilizar o Cisco Configuration Professional
(CCP) para criar os ramais e, consequentemente, administrar o diretrio local atravs dele.
Com o CCP a configurao do Caller-ID (nmero do ramal) feita quando associamos um
usurio (user) a umramal (Phone/Extension). Lembre que via CCP no associamos ramais (ephonedns) diretamente aos telefones (ephones), o que fazemos criar os ramais e telefones para associar a
uma conta de usurio. Aps configurar o primeiro (First Name) e o ltimo nome (Last Name) conta
do usurio, o nome (name) aplicado ao ramal que est vinculado a essa conta (user account). Para
isso temos que utilizar a pgina de Users, Phones and Extensions.
Vamos a um exemplo criando um novo ramal (extension) com o nmero 8006, que ser vinculado a
um IP Communicator (CIPC) e a um usurio chamado Manda Chuva.
Primeiro vamos criar o ramal (extension) que o ephone-dn. Para isso v em Unified
Commmunications > Users, Phones and Extensions > Extensions e clique em "Create". A opo
Name to be displayed on phone line no o comando name utilizado pelo Directory, apenas o
label do telefone IP.
Agora vamos criar o telefone e o usurio na pasta Phones and Users, logo abaixo de Extensions,
clicando em Create.... Para criar o telefone voc deve escolher um modelo, o qual o nosso um IP
Communicator, um softphone da Cisco.
Configuramos o MAC dele e por ltimo vamos vincular esse telefone a um DN, o qual criamos no
passo anterior como 8006. O 8006 fica listado em Available Extensions, basta clicar nele e clicar na
setinha para passar ele para o outro lado da tela. No clique em OK ainda, agora teremos que
configurar a conta de usurio que ir vincular o comando name ao ephone-dn.
Em seguida passe para a aba user. Primeiro configure umuser ID qualquer (pode ser o nome da
pessoa para facilitar), pois esse parmetro apenas uma identificao. Depois configure o First e Last
name, agora sim esses valores que sero adicionados via o comando name. Agora s clicar em OK
para enviar a configurao ao roteador.
Na prxima tela vir um resumo dos comandos que sero configurados no roteador, basta dar um
"Deliver" e a configurao est finalizada. Note que na penltima linha aparece o comando name
Manda Chuva.
Voc tambm pode configurar a organizao dos nomes no diretrio indo em Unified
Communications > Advanced Telephony Settings > System Config para a verso 2.5 do CCP.
J na verso 2.6 o caminho Configure > Unified Communications > Telephony Settings e clique
em Edit. O parmetro est dentro da aba System Config na opo Directory naming schema,
conforme figura abaixo:
Para criar entradas manuais no diretrio v na opo Unified Communications >

Telephony Features > Directory Services e clique em Create.
Configure o nome e o nmero de telefone e d um OK, depois com o Deliver o CCP ir gravar as
configuraes no roteador.
Lembrete:
Lembre que essas configuraes realizadas via CCP esto indo para a running-config e ainda no
esto salvas nastartup-config, para salvar o backup da configurao utilize o menu esquerdo inferior,
conforme figura abaixo, ou entre no roteador e utilize o copy run start ou wr para salvar sua
configurao.
Configurando o Encaminhamento de Chamadas (Call Forwarding)

O encaminhamento de chamadas no CME pode ser realizado de duas maneiras, a primeira pelo
prprio telefonedo usurio e a segunda atravs do CLI ou CCP realizada pelo administrador.
Para fazer o encaminhamento das chamadas (call forward) pelo telefone IP ou IP Communicator basta
selecionar o boto (softkey) CFwdAll (3), esperar o telefone fazer dois bips e digitar o ramal que
voc far o encaminhamento das suas chamadas. Para finalizar voc pode selecionar o boto End
Call ou teclar #, o que indica o final da discagem para o telefone. Depois de realizado o
encaminhamento aparecer uma seta acima do seu nmero de telefone (1) e uma mensagem
indicando que seu ramal foi encaminhado (2), conforme figura abaixo:
Informao extra:
Voc ainda pode encaminhar suas chamadas direto para o Voice Mail (correio de voz) apertando o
boto CFwdAll e em seguida pressionando o boto referente ao Voice Mail. Para retirar o
encaminhamento basta pressionar o boto CFwdAll novamente que seu telefone volta ao normal.
Para encaminhar chamadas via CLI voc deve entrar em cada ephone-dn e definir um nmero para
encaminhamento em caso de ocupado (busy) ou quando o usurio no atende o ramal (not
answering ou noan) para um outro ramal (extension ou extenso).
O mais comum nesses casos encaminhar para o nmero do voicemail (em nosso exemplo ser o
1999) ou para o nmero da telefonista, porm voc pode encaminhar para qualquer ramal ou hunt
que estiver configurado no sistema ou at mesmo um nmero externo.
Veja o exemplo abaixo onde configuramos que se o telefone estiver ocupado (comando call-forward
busy 1999) ele ser encaminhado para o ramal 1999.
Agora se o usurio no atender o telefone (comando call-forward noan 1999 timeout 25), aps 25
segundos a ligao ser encaminhada para o ramal 1999 tambm.
Lembrete:
Para determinar o tempo que utilizaremos no timeout do comando call-forward temos que saber
que nos Estado Unidos o telefone toca por 2 segundos de tom seguido por 4 segundos de silncio,
com isso voc pode calcular aps quantos toques sem atendimento (noan) o ramal ser desviado,
esse tempo o timeout que iremos configurar no exemplo ao lado.
No Brasil esse tom chamado de tom de controle de chamada e tem uma cadncia de 1 segundo
de tom e 4 segundos de silncio.
Perceba tambm que existe no comando call-forward uma opo chamada max-length, a qual
pode ser utilizada para restringir encaminhamentos para nmeros externos a partir de um telefone IP.
Se voc utilizar o comando call-forward max-length 0, o CME far com que a facilidade de
encaminhamento de chamadas (call forwarding) seja desabilitada no telefone IP Cisco, portanto
fazendo com que o boto CFwdAll fique apagado no telefone IP e se torne inacessvel para o
usurio. Veja o exemplo de configurao abaixo:
E como fica a tela do telefone na figura abaixo:
Note que aps a configurao tivemos que resetar o aparelho para que o boto CFwdAll ficasse
apagado, pois se voc inserir os comandos e no resetar ele no far o encaminhamento mas o boto
continuar aceso para o usurio, parecendo que o telefone est com problemas.
Utilizando o Comando call-forward pattern para Suporte ao H.450.3
O comando call-forward pattern est dentro das configuraes do telephony-service, o qual
habilita o uso do padro H.450.3 para encaminhamento ou desvio de chamadas, veja sada do
comando abaixo:
Sem o uso do H.450.3 voc pode afetar recursos de rede quando ocorre um desvio de chamada, isso
porque normalmente se uma chamada foi desviada para um telefone que est em outro roteador
CME, quando entra uma chamada para aquele usurio que efetuou o desvio, essa chamada passar
por dentro do dispositivo final, ou seja, pelo aparelho IP, fazendo com que ele seja mais um salto na
rede, podendo gerar problemas de qualidade na ligao em casos onde a distncia envolvida seja
muito grande (posies geogrficas distantes) entre o usurio que est chamando e o nmero
desviado, veja a figura abaixo:
J quando utilizamos o padro de desvio de chamadasH.450.3 o roteador CME pode fazer um

redirecionamento da chamada (call redirect) entrante para o destino final quando ele discar para um
telefone com desvio ativo, parando de atuar como mais um salto entre a origem e o destino da
chamada aps o desvio, veja a figura abaixo:
Como podemos perceber nas figuras 1 e 2 o ramal 8002 est desviado para o 8003. Na figura 1,
quando o ramal 8001 liga para o 8002, a ligao desviada para o 8003, mas o roteador DlteC2
utilizado e o fluxo de voz vai passar por ele, podendo causar problemas de QoS tais como picote de
voz (audio clipping), distores e at queda da ligao (call drop). Este sintoma de problema
chamado normalmente de hairpinning, o qual evitado quando utilizamos o H.450.3.
Na figura 2 temos uma chamada com o H.450.3 ativo, mostrando que a mesma chamada (do 8001
para o 8002) desviada para o ramal 8003, porm sem precisar passar pelo roteador DlteC2, pois ela
redirecionada atravs do H.450.3 para o roteador DlteC3 utilizando uma mensagem de redirect.
Voltando a falar do comando call-forward pattern <padro> que est dentro do modo de
configurao do telephony service, o padro que deve ser utilizado pode ser por exemplo 15..,
o que significa que todos os nmeros de quatro dgitos iniciando por 15 iro utilizar o padro de
encaminhamento H.450.3.
Portando, se um desvio for ativado para os ramais de 1500 a 1599 ele ser realizado via o padro
H.450.3. Veja exemplo abaixo onde os ramais de 8000 a 8099 utilizaro o padro H.450.3.
Voc pode utilizar tambm o CCP para configurar a parte de desvio de chamadas indo na aba Unified
Communication > Users, Phones, and Extensions > Extensions", conformefigura ao lado. Uma vez
nesse menu voc pode selecionar um ramal e editar para inserir as configuraes ou selecionar todos
e dar um edit all.
Nessa tela possvel configurar o encaminhamento para todas as chamadas (1), quando o seu
telefone estiver ocupado (2), quando no houver resposta (sem atendimento - 3) e o timeout para
definir o desvio quando o usurio no atende (4).
Configurando Transferncias de Chamadas

Para fazer uma transferncia de chamada voc pode utilizar o boto Trnsfer do seu telefone IP ou
softphone quando uma chamada estiver ativa. Quando voc apertar o boto referido um outro tom
de discagem (dial tone) ser ouvido indicando que voc deve discar o nmero do ramal que a ligao
ser transferida. O que acontece depois depende da configurao do CME, a qual pode ser de dois
tipos:
1. Consult: Nesse modo voc pode falar com a pessoa que voc vai transferir a chamada antes de
finalizar a transferncia. Por exemplo, voc recebeu uma chamada que no para seu ramal, voc faz
uma transferncia apertando o boto Trnsfer, disca o nmero para o qual vai transferir, espera o
destino atender, avisa que vai transferir e depois transfere pressionando novamente o boto Trnsfer.
A partir desse momento voc est fora do circuito. Para que essa funcionalidade seja configura voc
precisa ter uma segunda linha, ou seja, seu ephone-dn como dual-line. Este o padro de
transferncia para o CME (Full Consult).
2. Blind: O modo Blind ou cego transfere a chamada imediatamente aps voc discar o nmero de
destino, no necessitando pressionar mais uma vez o boto Trnsfer para finalizar a transferncia. Esse
modo pode ser configurado para telefones que so single-line (apenas uma linha).
Veja a configurao abaixo:
Portanto temos trs mtodos de transferncia disponveis:full-blind, full-consult e local-consult. No

"full-blind" e "full-consult" utilizado o padro H.450.2 para as transferncias, pois assim o problema
de hairpinning nas chamadas evitado, evitando problemas de QoS cada vez que voc faz uma
transferncia. Quando o H.450.2 utilizado o CME desconecta completamente a chamada do
telefone que est transferindo e inicia uma nova chamada do telefone que vai ser transferido para o
telefone que o destino da transferncia.
O local-consult utiliza um mtodo de transferncia proprietrio da Cisco, o qual ativa a consulta
completa (full-consult) nas transferncias que esto sendo realizadas com telefones de mltiplas
linhas ou duais (dual-line), revertendo a configurao para transferncia cega (blind transfers) se
apenas uma linha estiver disponvel (single line). Esse mtodo proprietrio da Cisco trabalha de
maneira simular ao padro H.450. O problema aqui quando voc tem telefones de outros
fabricantes como destino, nesse caso teremos as chamadas hairpinned na rede, sujeitas a
problemas de QoS.
Para configurar diferentes padres nos telefones IP voc pode entrar com os comandos transfermode <blind/consult> dentro do ephone-dn, assim as configuraes globais do padro H.450 sero
ignoradas.
Por padro os roteadores Cisco bloqueiam transferncias que no podem ser gerenciadas localmente,
isso para evitar fraudes nas ligaes (toll fraud). Por exemplo, um usurio interno poderia transferir
uma chamada para um nmero internacional fazendo com que a chamada seja paga pela empresa e
no pela pessoa que ligou para o usurio da empresa.
Para restringir os nmeros que podem ser utilizados para transferir utilize o comando transferpattern <pattern> no modo de configurao do servio de telefonia (telephony service), onde o
pattern representa os nmeros para os quais voc permite fazer as transferncias, ou seja, os
destinos, veja o exemplo abaixo.
Com essa configurao os ramais 1000 a 1999 e de dez dgitos podem ser utilizados para
transferncia.
Tambm podemos utilizar o Cisco CCP para configurar os padres de transferncia (transfer patterns),
que pode ser encontrado no menu Unified Communications > Advanced Telephony Settings.
Veja um exemplo na figura abaixo.
Dependendo da verso do CCP que voc esteja trabalhando a tela estar em Unified
Communications > Telephony Settings, clicando em "Edit" e indo na aba "Transfer Pattern". Para
adicionar uma transfer pattern clique em Add, conforme figura abaixo:
Configurando o Call Park

De uma maneira bem simples, o Call Park um nmero compartilhado (ou vrios ramais
compartilhados) que voc pode utilizar para estacionar (Park) uma chamada. Normalmente
utilizamos esse recurso com nosso telefone, o qual conhecemos como chamada em espera, porm
somente nosso prprio telefone pode recuperar essa chamada retida na espera, j com o call park
podemos reter uma chamada em um ramal onde qualquer pessoa pode recuper-la.
O sistema de call park funciona com base em ephone-dns livres na configurao do Cisco Unified
CME que voc no vinculou a nenhum telefone fsico ou softfone e configurou em um call park slot
(espao para estacionar as chamadas, ou deix-las em espera). Isso pode ser realizado no CME para
que as chamadas sejam colocadas em espera no primeiro ephone-dn disponvel, ou ento podemos
deixar com que os usurios escolham o ramal que a chamada ser deixada em espera.
Por exemplo, em uma loja de departamentos a telefonista recebe uma ligao para um determinado
vendedor, ela coloca a chamada em espera e depois anuncia no auto-falante Vendedor Pedro,
chamada no ramal 1912, assim o vendedor pode pegar um telefone e puxar a chamada que est em
espera, evitando que a telefonista fique procurando pelo vendedor e espere que ele atenda a
chamada.
Um exemplo para ramais fixos seria uma empresa ou loja com vrios setores e cada um receberia
uma extenso para parking, por exemplo, eletrnicos ramal 1301, eletrodomsticos ramal 1302 e
assim por diante.
Portanto quando a telefonista receber uma ligao para o sertor de eletrnico ela faz o parking da
ligao para o ramal 1301, sendo que podemos ainda ter vrios slots configurados com esse mesmo
ramal e o CME iria alocando as chamadas estacionadas nele. Quando um funcionrio do setor puxar a
chamada estacionada a mais antiga ser repassada para ele, pois essa a regra a primeira ligao
estacionada ser a primeira a ser repassada.
Veja um exemplo de configurao abaixo onde o ephone-dn 10 foi designado com o ramal 5001 para
um park slot com o comando park-slot.
No exemplo de configurao anterior vimos algumas opes extras na configurao do ephone-dn 11.
Essas opes servem para tunar nosso park-slot. Acompanhe as explicaes abaixo:
Opes extras no call park:
reserved-for <ramal>: reserva o park slot para um determinado directory number (DN - ramal) e
no funcionar para outros ramais.
timeout <segundos>: tempo em segundos para o CME aguardar antes de informar ao telefone que
colocou a chamada em espera que ela continua em espera (parked). A notificao feita pelo CME
atravs de um toque (ring) por um segundo e uma mensagem de aviso no display do telefone.
limit <contador>: configura o limite de intervalos de timeout que uma chamada pode ficar
estacionada (parked), sendo que aps esse limite a chamada desconectada. A recomendao geral
configurar um valor alto para esse parmetro, lembrando que quem est em hold (estacionado ou em
espera) tende a ficar entediado at esse contador acabar e ser desconectado.
notify <dn>: notifica um outro ramal (DN), alm do ramal que colocou a chamada em park aps o
tempo configurado no comando timeout.
only: funciona em conjunto com o comando anterior (notify), dando o aviso da chamada
estacionada apenas para o ramal configurado via notify e no avisar o ramal original.
recall: retorna a ligao estacionada (transfer back) para o telefone original aps finalizado o
perodo definido no comando timeout.
transfer <dn>: transfere a chamada para o DN (ramal) especificado no comando quando o timeout
finaliza.
alternate <dn>: define um ramal alternativo se o ramal do comando anterior estiver ocupado.
retry <segundos>: define o tempo para que o CME transfira de novo uma chamada colocada em
espera no caso de no conseguir a primeira vez.
Depois de configurado um ou mais park slots voc precisar fazer um reset no servio de
telefonia (telephony service) para que o softkey (boto) Park aparea nos telefones IP. A partir
desse momento quando houver uma chamada ativa o boto de Park aparecer e voc poder
colocar a chamada em espera pressionando esse boto.
Apertando o boto park durante a chamada o CME ir alocar o primeiro park slot, para voc escolher
o park slot necessrio transferir a ligao para o ramal configurado, pressionando o boto Trnsfer
e depois direcionar a chamada para o ramal configurado com o park slot desejado. Veja um exemplo
de uma chamada em park na figura abaixo:
Para capturar uma chamada (ou atender) voc tem trs opes:
Discar para o ramal configurado como park slot.

Pressionar o boto PickUp do telefone e discar o nmero do call park que voc deseja
atender.
Do telefone que voc fez o park, pressione o boto PickUp e depois um asterisco (*) para
capturar a chamada mais recentemente colocada em espera pelo seu telefone.
Por ltimo, possvel tambm utilizar o CCP para configurar as facilidades de call park, porm
algumas tarefas que so necessrias via CLI sero automatizadas pelo CCP. Para fazer a configurao
entre no menu Unified Communications > Telephony Features > Call Park, depois selecione a
opo Create.
Uma vez nessa janela voc deve digitar um nome (name) que vai criar uma descrio (description
label) na configurao de IOS para essa entrada de call park. Depois o CCP pede para configurar o
nmero de slots (call park numbers) e o ramal inicial para os park slots. Veja o exemplo abaixo:
Nesse exemplo foi criado 1 slot (Number of slots) iniciando no ramal 5010 indo at o 5010, pois foi
criado apenas um slot, com um timeout de 60 segundos. Na janela de Advanced so dadas as
opes discutidas anteriormente para o ajuste fino (tunning) do park.
Configurando Call Pickup
Para tratar de uma maneira bem simples, o Call Pickup(captura de chamadas) nada mais que a
possibilidade de voc atender (usualmente chamado de puxar) a ligao que est tocando em outro
telefone, principalmente quando a pessoa no est na mesa dela e existe uma necessidade de se
atender a todas as ligaes. Para realizar essa tarefa nos telefones IP Cisco existe um boto(softkey)
escrito PickUp.
Imagine uma empresa com um sistema de telefonia sem o PickUp onde quem fica na sala no horrio
de almoo, por exemplo, tem a responsabilidade de atender a todas as chamadas de seus colegas de
trabalho, ele faria um bom exerccio fsico levantando e atendendo a cada chamada no telefone de
seus colegas de trabalho.
Para organizaes maiores o pick up permite a criao de grupos de captura (call pick-up groups)
possibilitando que sejam criados nmeros que representam conjuntos de funcionrios por setor, por
exemplo. Veja a figura abaixo:
Vamos fazer a configurao dos seis ephone-dns conforme a figura anterior e configurar os grupos de
captura. Os ephone-dns 1, 2 e 3 faro parte do grupo de captura Vendas (1000) e os ephone-dns 4, 5
e 6 faro parte do grupo de Marketing (2000), veja a configurao abaixo:
Note que no precisamos criar um grupo de captura, pois quando voc digita o comando pickupgroup dentro de um ephone-dn o CME j cria o grupo automaticamente.
Agora que j criamos nossos grupos de captura temos basicamente trs maneiras de capturar uma
chamada que est tocando em outro telefone:
1. Directed pick-up ou Captura Direta: voc captura a chamada pressionando o boto PickUp e
discando o nmero do telefone que est tocando. Assim o CME transfere automaticamente a
chamada para seu telefone.
2. Local group pick-up (grupo de captura local): agora vamos capturar chamadas do nosso grupo
local pressionando o boto GPickUp e o asterisco (*) em seguida, assim que voc ouvir o
segundo tom de discar (dial tone).
3. Outros Grupos de Captura: voc pode ainda capturar uma chamada de outro grupo de captura
pressionando GPickUp e ao ouvir o segundo tom de discar digitando o nmero do outro grupo
de captura.
Se vrios telefones estiverem tocando e voc fizer uma captura atravs do grupo (segundo e terceiro
mtodo) o CME passar a ligao mais antiga que est tocando.
Veja na figura abaixo onde ficam os softkeys PickUp e GPickUp. O PickUp fica normalmente na
primeira tela e para chegar ao GPickUp voc precisar apertar a tecla "More" em destaque com a seta
amarela.
Importante:
Outro ponto importante que o GPickUp pode funcionar de maneira diferente dependendo da
configurao no CME. Se apenas um grupo de captura foi criado, ao pressionar o GPickUp
automaticamente a chamada do seu grupo ser atendida, sem voc ouvir o segundo tom de discar ou
pressionar o asterisco, pois tem apenas um grupo configurado. Somente aps configurar mais de um
grupo de captura que ao pressionar o GPickUp voc ir ouvir o segundo tom de discar e pode utilizar
o asterisco para capturar chamadas do seu grupo local ou digitar o nmero de outro grupo para
capturar chamadas de outros grupos diferentes.
Outro comando interessante para ser utilizado o no service directed-pickup, dado dentro do
modo de configurao do servio de telefonia (telephony service). Com ele voc desabilita a
possibilidade de uma chamada ser capturada por um telefone em um grupo de captura diferente
quando o usurio pressionar o PickUp e digitar o ramal do telefone que est tocando. A partir desse
momento o boto PickUp funciona para capturar chamadas do seu grupo de captura local e o usurio
no ouvir mais o segundo tom de discar, pois a chamada ser capturada automaticamente.
Para criar pickup groups via CCP v na opo Unified Communications > Telephony Features > Call
Pickup Groups e clique no boto Create.
Via CCP fica mais simples a configurao, pois a janela vai pedir que voc defina um nmero para o
grupo de captura e aloque os ramais (extensions) nesse grupo, veja na figura ao lado. Os ramais j
devem ter sido criados (ephone-dn) para que os DNs apaream na lista.
Configurando Intercom
O Intercom uma facilidade muito comum em sistemas de telefonia tradicionais e permite que
um executivo e sua secretria trabalhem de uma maneira mais simples e prxima, permitindo um
acesso direto entre eles facilitando a discagem e atendimento das ligaes entre ambos.
Tecnicamente falando o intercom uma mistura do speed-dial e do auto-answer speed-dial. Na
prtica, a configurao padro do intercom permite que a secretria ou assistente pressione o boto
de speed-dial configurado com o intercom e automaticamente ser gerada uma chamada para o
telefone do seu chefe, onde a chamada atendida automaticamente e colocada em mudo (mute).
Para que o chefe atenda basta ele pressionar o boto de Mute (ativando o speaker phone) para
iniciar a conversa com sua secretria. Como falado anteriormente, esse o padro, mas tem outras
opes de configurao que veremos na sequncia.
Com a explicao acima voc pode entender melhor aconfigurao do intercom, para o qual voc
precisa terdois novos ephone-dns, um para cada ponta do intercom (um para o chefe e um para a
secretria). Essas novas linhas utilizadas para o intercom devem ter novos nmeros, ou seja, como
novos ephone-dns.
Para prevenir que outros usurios (acidentalmente ou de propsito) acessem o intercom, esse
nmero configurado deve ser inacessvel para outros usurios. Veja a configurao do Intercom
abaixo:
Primeiro note que nos ephone-dn 10 e 11 foram utilizados os nmeros A100 e A101, o que torna
impossvel a discagem para eles atravs de um outro telefone, pois no tem como digitar A para
discar para outra pessoa, tornando o intercom indisponvel para outros usurios.
Agora, tanto o gerente como a secretria conseguem discar porque esse nmero foi vinculado a um
speed-dial que far automaticamente esse discagem, isso foi realizado nos ephones 1 e 2 com o
comando button, por exemplo, o comando button 2:10 coloca no segundo boto de speed-dial
do telefone o intercom que foi criado no ephone-dn 10.
Note tambm que para a configurao ter efeito foi necessrio resetar os ephones.
Portanto, com a configurao que realizamos, no telefone da secretria, que est configurado no
ephone 1,aparecer no boto 2 (segundo speed-dial) o nome Gerente, o qual ao ser pressionado
discar para o nmero A101, o qual o ramal intercom do Gerente. J notelefone do gerente, que
est no ephone 2, aparecer no boto 2 (segundo speed-dial) o nome Secretaria, o qual ao ser
pressionado discar para o nmero A100, o qual o ramal intercom da secretria. Isso foi realizado
logicamente com o comando intercom dado dentro de cada ephone-dn criado para esse propsito.
Importante:
Voc pode ainda fazer um ajuste fino (tunning) nas configuraes do intercom com os comandos
abaixo:
barge-in: faz com que o intercom tenha prioridade sobre as outras chamadas, colocando uma
chamada em curso em hold e faz com que o intercom seja atendido imediatamente.
no-auto-answer: o telefone vai tocar ao invs de fazer o auto-atendimento via speakerphone.
no-mute: atende diretamente o intercom sem estar em mute, podendo causar uma
confuso, pois quem discou vai ouvir o que est acontecendo com o nmero de destino.
Para configurar via CCP v em Unified Communications > Telephony Features > Intercom e clique
no boto Create. Veja na figura abaixo um exemplo de configurao, a tela autoexplicativa.
Na figura abaixo temos como ficar no telefone o Intercom.
Veja que ao receber a ligao via Intercom ela j atendida e fica em Mute, boto com um microfone
cortado em destaque, conforme figura abaixo.
Para atender basta tirar do mute, ou seja, apertar o boto do microfone cortado que est em
vermelho para falar. Note tambm que a ligao vem do ramal A600002, sendo que o A colocado
por motivos de segurana para que o Intercom no possa ser acionado por outros telefones.
Configurando Paging
O Paging bem parecido com o conceito do intercom, porm ele funciona de maneira unidirecional e
automtica, sendo utilizado para fazer o broadcast de mensagens como notificaes de emergncia
ou informar a funcionrios que eles tem chamadas em espera (on hold). O sistema de paging do CME
funciona atravs da configurao de um ephone-dn como um nmero de paging.
Portanto, chamadas para esse DN configurado no ephone-dn para paging sero enviadas via
broadcast para todos os telefones IP que estiverem nesse grupo de paging (paging group).
Veja a figura abaixo com o conceito do paging.
Ao discar para o ramal 1555 voc far um broadcast da sua mensagem para todos os telefones que
estiverem nogrupo de paging 80, j ao discar para o ramal 1556 a mensagem ser ouvida por todos
os telefones do grupo 81.
Note que cada telefone pode pertencer a apenas um grupo de paging, porm vrios grupos podem
ser criados e o CME permite que voc cire nmeros de paging que chamem outros gurpos de paging,
possibilitando um anncio para toda a companhia.
O CME suporta configurao de paging utilizando unicast emulticast. Via Unicast o Paging envia
mensagens individuais para cada telefone configurado no grupo de paging. Com essa configurao o
CME est limitado a criar grupos com no mximo 10 telefones cada.
J com o uso do Multicast o CME envia o fluxo de udio (audio stream) para um nico IP de multicast
que alocado para aquele determinado grupo de paging. Assim teoricamente no h limites para o
grupo de paging, porm a configurao do Multicast em uma rede IP no um assunto simples e
coberta na certificao CCNP. Lembre que o multicast deve estar habilitado e devidamente
configurado para que o paging atravs de multicast seja configurado.
Temos trs tipos de configuraes para o paging: unicast paging, multicast paging e multiplegroup paging. Vamos iniciar com o unicast com apenas um grupo de paging. Veja a configurao
abaixo:
Agora ao discarmos 1555 vamos fazer o paging para os telefones configurados nos ephones 1 e 2.
Note que o vnculo no grupo foi com o comando paging-dn 80 e inserimos o nmero do ephone-dn
que foi habilitado como paging, o qual foi o 80. O comando paging dentro do ephone-dn 80 ativou o
paging.
Para configurarmos o paging via multicast podemos utilizar a configurao abaixo:
Agora o paging ser realizado atravs do IP de multicast 239.1.1.100 atravs da porta 2000. Como
mencionado anteriormente o multicast deve ser configurado corretamente ou ento ser tratado
como um broadcast e enviado para todas as portas dos switches naquela determinada VLAN em que
os telefones IP esto configurados.
Por ltimo, vamos configurar paging multigrupo, criaremos os grupos 80 e 81, depois vamos criar um
outro grupo 82 que vai agregar os dois primeiros grupos em um DN nico, possibilitando que faamos
o paging para todos os telefones ou somente para cada grupo. Veja as configuraes abaixo:
Se discarmos o nmero 1555 vamos fazer o paging para os ephones 1 e 2. Se discarmos 1556 vamos
fazer o paging para os ramais configurados nos ephones 3 e 4. Agora, se discarmos 1557 vamos fazer
o paging para todos os telefones (ephones de 1 a 4), pois ele agrega os dois grupos 80 e 81. Voc
pode adicionar at 10 nmeros de grupos de paging com o comando paging group utilizado no
ephone-dn 82.
Pelo CCP voc pode acessar a configurao do paging indo em Unified Communications >
Telephony Features > Paging Numbers e depois clicando em Create, essa opo configura singlegroup paging (um grupo de paging apenas).
Para configurar via CCP um multiple-group paging (paging de vrios grupos) v em Unified
Communications > Telephony Features > Paging Groups, podendo escolher nmeros de paging
group e associ-los a outros paging groups ao invs de ramais individuais. Veja na figura abaixo um
exemplo da criao de grupos simples de paging (single group).
Na figura abaixo temos um exemplo da configurao de grupos mltiplos.
Foram criados os paging numbers de teste com o nmero 9990 e 9991, assim o grupo com o nmero
9993 ser capaz de fazer o paging para todos os dispositivos em ambos os paging numbers criados.
Configurando o Bloqueio de Chamadas Fora do Horrio (After-Hours Call Blocking)

O bloqueio de chamadas fora do horrio ou after-hours call blocking traz a soluo para
evitar chamadas indevidas realizadas fora do horrio de trabalho, que normalmente nos sistemas de
telefonia tradicional podem ocorrer quando alguns funcionrios ou mesmo empregados terceiros
realizam na empresa sem a superviso de um responsvel.
O bloqueio das chamadas fora do horrio (After-hours call blocking) permite que o administrador crie
faixas de horrios definidas como after-hours intervals (intervalos fora do horrio). Com isso ele
pode definir uma lista de nmeros telefnicos que devem ser bloqueados durante essas faixas de
horrios. As chamadas que forem realizadas para os nmeros dessa faixa recebero do CME um
reorder tone (tom de reordenao) e sero desconectadas.
Caso seja necessrio deixar alguns usurios ou ramais fora das regras de after-hour (fora do horrio)
possvel tiraresses ramais das regras ou criar um PIN (cdigo ou senha) para que os usurios possam
destravar o telefone e fazer as ligaes mesmo fora do horrio. Essa senha permite que o usurio
destrave o telefone por um perodo de tempo configurvel no CME, no quer dizer que ele ficar
destravado indefinidamente.
Outra funcionalidade interessante para o bloqueio de ligaes fora de horrio criar regras para
nmeros que devem sempre ser bloqueados o dia todo. Por exemplo, nos Estados Unidos existem os
nmeros 1-900 que devem ser banidos pelo sistema de telefonia por serem nmeros pagos para
servios no recomendveis em horrio de trabalho.
Veja abaixo os trs passos para configurar o After-hours call blocking.
After-hours call blocking
1. Definir os dias e/ou horas que so considerados fora de horrio de trabalho (off-hours).
2. Especificar os nmeros (patterns) que devem ser bloqueados durante esse horrio definido no
passo 1.
3. Criar excees para a poltica criada nos passos 1 e 2 (se necessrio).
Vamos iniciar as configuraes pelo passo 1, definindo datas e horrios que so considerados fora de
horrio comercial.
Nossa configurao ser fora do horrio comercial entre 18:00 (6:00 p.m.) a 8:00 da manh (a.m.) do
outro dia. Alm disso, os dias 25 de Dezembro (Natal) e primeiro de Janeiro (virada de ano) inteiros
como fora de horrio comercial. Essa configurao feita dentro do telephony-service.
Note que os dias e meses esto todos em ingls e as horas seguem o padro 24:00h.
Agora que as faixas de tempo ou slots que esto configurados temos que definir os nmeros que
sero bloqueados durante esse perodo. Veja a configurao ao lado. A maneira de criar os padres
(pattern) de bloqueio foi estudada nos captulos anteriores.
Voc pode criar no mximo 32 ndices para bloqueio, portanto so no mximo 32 regras de bloqueio.
Em nossa configurao o pattern 1 faz correspondncia (matches) para bloquear ligaes longa
distncia no padro Americano. J a pattern 2 bloqueia ligaes internacionais. Por ltimo o pattern 3
bloqueia os nmeros 1-900 para ligaes pagas (toll calls), porm no final do comando existe o
argumento 7-24, a qual indica ao CME para bloquear sempre (24h por dia 7 dias na semana) esses
nmeros.
Esse parmetro bloqueia quaisquer telefones para esse nmero configurado, mesmo os que iremos
fazer as excees no prximo exemplo de configurao.
O ltimo passo definir as excees s polticas definidas anteriormente. Essas excees podem ser
configuradas por ramal ou utilizando um PIN, permitindo que por qualquer telefone IP voc
desbloqueie as ligaes fora de horrio comercial. Veja abaixo um exemplo de configurao onde o
ephone 10 ser liberado do bloqueio de after-hour e os ephones 20 e 30 podem desbloquear a
configurao com a senha (PIN) 1234 (esse PIN deve ter entre 4 e 8 dgitos)
A ltima linha de configurao, dada dentro do modo de configurao do servio de telefonia, faz o
login funcionar corretamente. Por padro o CME passa aos telefones IP Cisco um softkey de Login em
seu display de LCD. Este softkey fica apagado at o comando login ser configurado dentor do
telephony service. O parmetro timeout define o tempo antes que o telefone seja deslogado (e
consequentemente bloqueado) e seja necessrio digitar mais uma vez o PIN para desbloquear o
telefone. O valor padro do timeout so 60 minutos.
O parmetro clear um valor absoluto de tempo (uma hora determinada) para que o ltimo PIN
digitado se torne invlido, sendo em que nosso exemplo ele ser limpo (clear) s 23h, porm isso no
significa que o usurio no possa desbloquear o telefone com o mesmo PIN aps as 23h. Lembre que
para essas configuraes serem efetivadas voc precisar resetar todos os telefones.
Para configurar o after-hours call blocking via CCP voc deve ir em Unified Communications >
Telephony Features > After-Hour. Voc pode criar agendas e nmeros de PIN atravs de uma
Weekly Schedule (agenda semanal), Holiday Schedule (agenda de feriados) ou Override
(Softkey Login).
Configurando CDRs e Bilhetagem das Chamadas

At agora configuramos caractersticas tcnicas e de uso do sistema, porm para a empresa to
importante como tudo que configuramos at o momento identificar quem fez as chamadas e
qual o tempo dessas ligaes, podendo determinar os custos com telefonia da empresa. Os
registros das chamadas ficam gravados no Call Detail Records ou CDR, porm voc precisa habilitar
essa facilidade no CME.
Os CDRs contm informaes sobre as chamadas entrantes, saintes, realizadas entre os telefones da
empresa ou para telefones externos. Estes registros tem detalhes como quem chamou quem e por
quanto tempo essa chamada foi realizada.
No CME os CDRs podem ser armazenados em um espao da memria RAM (buffered) do roteador,
enviadas a um servidor syslog ou para ambos. Armazenar os CDRs na RAM o mesmo que nada, pois
a RAM voltil e todo contedo ser apagado no caso de um reload ou queda de energia, alm disso,
esse espao de memria reservado aos CDRs limitado. A visualizao dos CDRs no arquivo de log do
CME no uma tarefa simples, so muitas informaes difceis de interpretar sem um software de
apoio. Abaixo segue um exemplo de configurao.
No exemplo mostrado configuramos os seguintes parmetros para os CDRs bufferizados no roteador

CME:
1. 512.000 bytes de memria dedicados aos logs do roteador.
2. CDRs sero mantidos por 7.200 minutos (5 dias).
3. O CME vai manter um mximo de 500 CDRs na memria, acima desse valor o roteador apaga
dos registros mais antigos para os mais novos.
Para visualizar os logs dos CDRs no CME voc deve utilizar o comando show loggingconforme sada
abaixo:
Para garantir que esses registros das ligaes no sejam perdidos e possam ser at exportados para
um software externo interpretar esses dados e gerar relatrios mais elaborados voc pode configurar
o envio dos registros (CDRs) para um servidor de syslog com os comandos abaixo:
O primeiro comando (gw-accounting syslog) define que os CDRs sero enviados ao syslog que teve o
IP configurado no segundo comando (logging).
Vamos utilizar aqui o 3ComDaemon para capturar os CDRs em um computador, porm pode ser
qualquer servidor syslog, como por exemplo o Kiwi Syslog. Veja a sada do syslog server
na figura abaixo:
Informao extra:
Apesar de mais fcil de visualizar ainda difcil de tratar os CDRs, para isso a Cisco disponibiliza em
seu website uma lista de parceiros que possuem sistemas para interpretar seus CDRs e torna-los mais
amigveis (user-friendly).
Uma outra maneira de fazer a contabilidade das chamadas (accounting) utilizando a facilidade do
boto Acct, porm isso vai depender dos usurios digitarem um cdigo definido pela empresa, que
pode ser um centro de custo de cada setor ou rea da empresa. Veja a figura abaixo.
Veja que quando a ligao est em andamento o softkey Acct est j na primeira tela, porm aps a
ligao ser atendida ele passa para a segunda tela e voc precisar apertar o "More" para chegar at
essa opo.
Aps o usurio pressionar o boto Acct um prompt ser oferecido ao usurio e ele pode digitar seu
cdigo ou centro de custo seguido do sustenido (pound key - #). Entrar com esse nmero durante a
chamada estar sendo estabelecida ou aps estabelecida no ir interromper a chamada. Depois de
digitado o CME ir marcar o CDR com esse centro de custo digitado (account number). Quando o
administrador for fazer a filtragem final das chamadas ele pode ter um detalhamento mais fcil por
departamento, evitando a necessidade de ver chamada por chamada e fazer o acumulado por
departamento.
A maior dificuldade desse tipo de implementao otreinamento e conscientizao dos usurios em
marcar cada chamada externa com seu centro de custo. Com um bom software de administrao
das contas telefnicas e CDRs dos seus CMEs isso no ser preciso, pois esses sistemas permitem
configurar o setor que cada ramal pertence e fazer a sumarizao de maneira mais simples, basta
voc adquirir um software com os requisitos da sua empresa.
Configurando Music on Hold (Msica em Espera)
O CME permite que voc configure uma msica de espera (Music on Hold ou MoH) para as ligaes
colocadas em espera a partir de arquivos em WAV ou AU armazenados na memria flash do
roteador.
O CME pode transmitir estes fluxos de udio (stream) pormltiplos fluxos unicast (que consome mais
recursos) ou atravs de um nico fluxo multicast (mais econmico para o roteador e para a rede mas
necessita da configurao do multicast na rede IP). Este fluxo ou stream de MoH pode ser transmitido
pelo CME utilizando os codecs G.711 ou G.729.
Porque o G.729 foi ajustado para a voz humana, um stream de udio do MoH via G.729 fica com uma
qualidade menor que um transmitido via o codec G.711. Alm disso, o CME precisar utilizar recursos
de transcoding DSP para converter o MoH para o padro G.729. Por isso, o recomendado utilizar o
G.711 para transmitir o MoH sempre que possvel.
Vamos a um exemplo de configurao do MOH para ser transmitido via multicast com um arquivo
armazenado na flash chamado moh.wav.
Um ponto de ateno com os direitos autorais das msicas utilizadas no MOH, pois em pases como
os Estados Unidos voc dever comprar a licena de uso caso a msica pertena a uma gravadora ou
um determinado cantor conhecido. O mesmo vale para o Brasil.
Agora ao colocar uma chamada em espera ou quando estivermos transferindo uma chamada, por
exemplo, o usurio escutar a msica gravada no arquivo moh.wav que est gravada na flash do
roteador.
Nesse ponto vale ressaltar a importncia dos requisitos de memria flash para os roteadores CME,
pois j vimos que vamos ter que gravar os arquivos dos telefones e mais uma msica on hold, alm de
j termos o IOS e demais arquivos necessrios para os servios habilitados no roteador.
Configurando Single Number Reach
O Single Number Reach (SNR) permite que voc configure um dispositivo adicional a um nmero pai
(parent number), possibilitando a mobilidade do seu ramal.
Por exemplo, voc poderia ligar seu telefone celular ou at mesmo residencial ao seu ramal
empresarial, fazendo com que quando uma ligao seja feita para o seu nmero
comercial (DN) toque tambm no dispositivo que voc configurou (celular ou telefone
residencial) no SNR aps um perodo de tempo configurado. Em caso do no atendimento dessa
chamada ela pode ser encaminhada ao servidor de voicemail corporativo, por exemplo, ou para
qualquer outro nmero.
Na realidade o Single Number Reach no CME umaverso light do Mobile Connect disponvel para
o CUCM, o qual permite um usurio ter vrios dispositivos configurados para tocar ao mesmo tempo
quando o DN dele chamado.
Alm da facilidade do toque simultneo em vrios dispositivos (simultaneous-ring) o Single Number
Reachtambm permite a transferncia da chamada no meio da conversao (mid-call transfer), o
que possibilita voc pressionar o softkey (boto) Mobility e a chamada do seu telefone corporativo
transferida pelo CME para o nmero que voc pr-configurou no Single Number Reach como
destino. O CME permite que a chamada volte para seu aparelho IP pressionando o boto Resume.
Isso tudo possvel porque o CME mantm as duas chamadas ativas quando voc pressiona o boto
de mobility, utilizando dois troncos para a PSTN, um para a chamada original e outra para a chamada
de sada para o nmero configurado como destino do SNR. Portanto,utilizar o Single Number Reach
pode custar troncos adicionais para a PSTN.
Vamos fazer ao contrrio do que temos feito durante o curso, vamos iniciar as configuraes
diretamente peloCCP indo nas configuraes dos ramais (Extension) em Unified Communications >
Users, Phones, and Extensions > Extensions. Nesse ponto voc pode escolher um ramal ou
extension e habilitar o Single Number Reach clicando duas vezes sobre o ramal ou pressionando o
boto Edit. Aps entrar na tela v na aba de opes avanadas e escolha a opo relativa ao Single
Number Reach, conforme figura abaixo:
Uma vez nessa tela voc pode definir o nmero de destino do SNR (remote number), o tempo antes
do segundo dispositivo comear a tocar (ring remote after), o timeout para considerar a chamada no
atendida e transferir a ligao (Time out) e por ltimo o nmero para o qual ser transferida a
chamada quando o timeout anterior expirar (forward unanswered calls to).
Voc tambm precisar clicar nos checkboxes Enable SNR for this extension e Enable mobility
feature for this extension number para fazer a configurao funcionar.
Via CLI a configurao anterior ficaria da seguinte maneira. Acompanhe abaixo:
O comando mobility permite que as chamadas possam ser transferidas com a ligao em curso, sem
esse comando as ligaes tocaro em ambos dispositivos, mas no poderiam ser transferidas aps a
chamada ter sido atendida.
Habilitando a Interface Grfica (CME GUI) com Arquivos Baseados na Flash
Alm do CCP o CME tem uma verso grfica que pode ser acessada via Web utilizando arquivos que
so instalados na memria flash do roteador. Essa interface grfica simples e no tem recursos
acanados como as configuraes via CCP ou CLI.
Antes de iniciarmos as configuraes que permitiro o acesso ao GUI voc precisa ter certeza que os
arquivos referentes ao CME GUI esto realmente descompactados na memria flash do roteador. Se
voc instalou os arquivos do CME individualmente, ceritifque-se de ter instalado o o pacote chamado
CME GUI.TAR fornecido em Cisco.com. Como instalar e descompactar os arquivos j foi visto
anteriormente, no abordaremos esse assunto nesse tpico.
Uma vez certificado que o CME GUI est devidamente instalado na memria flash, nesse caso dentro
de uma pasta chamada gui, vamos iniciar a configurao que permitir o acesso.
Note que habilitamos o http e o https (http secure-server), alm disso, habilitamos a autenticao
local para os acessos http, com isso voc pode configurar um usurio e senha para acesso com o
comando username. O comando ip http path flash:/gui define para o servidor HTTP utilizar os
arquivos para o GUI no subdiretrio da flash chamado gui quando for requisitada uma solicitao
HTTP. Caso o GUI tenha sido instalado direto na flash, ou seja, no diretrio raiz, voc deve utilizar o
comando ip http path flash:.
Agora vamos configurar um usurio e uma senha para acesso ao CME GUI. Veja um exemplo de
configurao abaixo.
Agora criamos o usurio chamado DlteCAdmin com a senha cisco para acesso ao CME via interface
grfica. Por padro o CME GUI no pode adiciona ephone-dn ou modificar a hora do roteador, porm
com os comandos dn-webedit e time-webedit agora isso possvel.
Cuidado ao destravar a configurao de data e hora com o comando time-webedit, pois se voc
estiver sincronizando o roteador com um servidor NTP essa configurao pode afetar a sincronizao
correta dos telefones, pois o NTP mais confivel que manter a hora manualmente.
Para acessar o CME atravs da interface grfica basta utilizar um web-browser suportado pela
plataforma e digitar a URL http://<CME_IP_Address>/ccme.html para acessar o CME GUI. Uma tela
de autenticao ser mostrada, uma vez que voc digite o usurio e senha correta a tela
da figura abaixo ser exibida.
A nica vantagem do CME GUI que ele roda totalmente a partir da flash do roteador, no
precisando instalar nada no computador, porm o CCP vai muito alm do que o CME GUI oferece de
facilidade.
Voltando um pouco a falar sobre a parte de bilhetagem eCDR, aqui no CME GUI existe a opo de
Reports > Call History com um resumo das chamadas bem simplificado, seja na figura abaixo.
Note que bem simplificado, contendo o nmero de origem (Originating Number), destino
(Terminating Number) e a durao da chamada (Duration), o que pode facilitar na hora de um
troubleshooting de uma determinada chamada.
Descrevendo o GUI e CLI do CUCM
O acesso administrativo do CUCM tem basicamente 6 interfaces de gerenciamento separadas, as
quais podem ser acessadas via HTTPS (acesso Web) ou SSH (acesso CLI).
Abaixo seguem as formas de acesso aos servios do CUCM e suas devidas URLs:
1. Cisco Unified Communications Manager Administration
(https://IP_do_Servidor/ccmadmin)
2. Cisco Unified Serviceability
(https://ip_do_servidor/ccmservice)
3. Disaster Recovery System
(https://ip_do_servidor/drf)
4. Cisco Unified Operating System Administration
(https://ip_do_servidor/cmplatform)
5. Cisco Unified Reporting
(https://ip_do_servidor/cucreports)
6. Command-Line Interface (CLI acesso via SSH)
Um usurio e senha de administrao so definidos nomomento da instalao para acessar as telas

de Disaster Recovery System e administrao do sistema operacional (Operating System
Administration). Veja a figura abaixo.
Alm disso, um usurio e senha de aplicao (application administration account) devem ser criados
para acessar as telas de administrao (CM Administration), Serviceability e telas de relatrios
(Unified Reporting interfaces). Aps a instalao outras contas de administrao e operao do
sistema podem ser criadas com diferentes nveis de privilgio de acordo com a funo de cada
operador de rede, inclusive podendo ser integrado com as contas criadas no Active Directory da
empresa via LDAP. Veja afigura abaixo.
Durante o processo de instalao tambm ser necessrio configurar uma senha adicional chamada
de senha de segurana (security password), o qual utilizado para conectar servidores Subscribers ou
outras aplicaes ao banco de dados do servidor Publisher. Veja a figura abaixo.
Interface de Administrao do Cisco Unified Communications Manager

A interface de administrao do CUCM possui nove menusou opes no total, as quais esto
descritas de maneira breve ao lado.
Acompanhe abaixo:
System: nesse menu voc pode configurar CM groups, Presence groups, Device Mobility Groups
(mobilidade), Device Pools, Regions, Locations, Enterprise and Service Parameters, Survivable Remote
Site Telephony (SRST modo de sobrevivncia local em caso de perda de comunicao com o CUCM)
e outras funcionalidades.
Call Routing: nesse menu voc poder definir os sistemas de encaminhamento de chamadas (call
routing system), Call Hunting, Class of Control, Intercom e outras funcionalidades tais como Call Park,
Call Pickup e muito mais.
Media Resources: com esse menu voc pode configurar recursos como Music On Hold (MOH),
annunciator, media termination points e transcoders, alm disso gerenciar os arquivos do MOH.
Advanced Features: aqui temos as integraes com VoiceMail e configurao do Inter-company
Media Engine Configuration, Extension Mobility Cross-Cluster e facilidades de VPN.
Device: esse menu relativo aos dispositivos tais como as configuraes dos gateways,
gatekeepers, trunks, telefones IP e Remote Destinations, alm disso, muitas opes adicionais sobre
os dispositivos podem ser configuradas, por exemplo, templates para botes e softkeys dos telefones
IP.
Application: aqui nesse menu encontramos o CUCM Assistant Configuration Wizard, para
configurar o CUCM atravs de uma interface passo a passo guiada, e o menu de Plug-ins.
User Management: d acesso ao Application User, End User (usurios finais), Group (grupo de
usurios) e configurao das funes de cada usurio.
Bulk Administration: fornece opes de configuraes em massa, por exemplo, para configurar ou
adicionar um conjunto de usurios ou telefones de uma s vez de maneira automatizada. Aqui temos
vrios recursos poderosos para configurao em BAT.
Help: aqui temos a pgina do Help, pesquisa por palavras chave e o About, que d informaes
gerais do sistema.
Interface de Administrao do Cisco Unified Serviceability

Nessa opo de administrao temos cinco menus com diversos sub-menus sumarizados conforme
abaixo.
Alarm: fornece configuraes e definies de alarme para a parte do sistema de monitoramento da
performance do sistema (system performance and health).
Trace: menu disponibilizado para configuraes e troubleshooting atravs de traces, possibilitando
a monitorao e resoluo de problemas.
Tools: embaixo desse menu voc encontrar as opes relacionada a CDR Analysis and Reporting,
as quais fornecem uma interface para acessar aos registros (logs) e relatrios das chamadas realizadas
atravs do sistema. A tela de Service Activation utilizada para ativar servios instalados pela
primeira vez ou desativar posteriormente esses servios. Temos tambm dois Service Control
Centers: Network Services e Feature Services. Com essa interface o administrador do sistema pode
iniciar (start), parar (stop) ou reiniciar os servios ativados. Na opo Serviceability Reports Archive
voc pode acessar uma interface para exibir relatrios do sistema e utilizar para fazer anlises de
tendncias (system and trend analysis). A interface CDR Management permite ao administrador
configurar e verificar os Call Detail Records (CDRs). J na opo de Audit Log Configuration voc
pode configurar o que ser reportado nos logs de auditoria (audit logs).
SNMP: menu que disponibiliza os submenus V1/V2c, V3 e SystemGroup para configurao do
Simple Network Management Protocol (SNMP).
Help: menu de ajuda.
Vale ressaltar aqui a diferena entre Feature services e Network services. Os Network
services (servios de rede) so ativados automaticamente e so obrigatrios para o bom
funcionamento do sistema. So servios tais como Cisco CallManager Admin Service, DB Replicator
(replicador de base de dados) e CDP. Esses servios no podem ser desativados ou desinstalados,
somente iniciado (started), parado (stopped) e reinicializado (restarted).
J os Feature services (servios de recursos adicionais) so servios opcionais que podem ser
ativados via pgina de Service Activation. Esses servios podem ou no estarem ativados em um
servidor, tudo depende da necessidade de cada projeto e topologia. Por exemplo, um servidor TFTP,
servios de IP Voice Media Streaming (para fornecimento de streaming de voz e vdeo) podem estar
ativos em um determinado servidor dependo da sua funo na rede.
Interface do Cisco Unified Operating System Administration
Dentro da interface Unified Operating System o administrador pode monitorar e interagir com o
sistema operacional baseado em Linux.
As opes e tarefas administrativas possveis nesse menu so as mostradas abaixo.
Monitorao dos recursos de hardware (CPU e espao em disco)
Verificar e fazer upgrade de verso de software
Verificar e alterar as informaes sobre o endereamento IP
Gerenciar o IP do servidor Network Time Protocol (NTP)
Gerenciar a parte de segurana do servidor incluindo IPSec e certificados digitais
Criar uma conta para assistncia remota para o TAC (Cisco Technical Assistance Center)
Fazer Ping para outros dispositivos
Disaster Recovery System Interface

Em Disaster Recovery System (DRS Sistema de Recuperao de Desastres) o administrador
pode gerenciar os backups e tambm as opes de recuperao (restore) do sistema. Para acessar
essa tela de administrao e a de sistema operacional (OS) ser necessrio utilizar a conta configurada
na instalao do sistema, porm podem ser criadas mais contas de acesso posteriormente.
Os backups podem ser gravados em fitas DLT ou em um servidor SFTP (FTP Seguro). Com um
agendador (scheduler) voc pode automatizar os backups ou iniciar um backup manual. Backups
individuais podem ser realizados para termos todo um cluster (Publisher e Subscribers) protegido.
Veja a figura ao lado com a tela da interface de Disaster Recovery System.
Cisco Unified Reporting Interface

A interface de reportes do CUCM ou Cisco Unified Reporting Interface fornece um mtodo
simplificado para acessar os relatrios (reports) do sistema. Veja a figura abaixo:
Os relatrios utilizam as informaes coletadas nos logs existentes e os formata em uma forma
amigvel e simplificada, muitas vezes disponveis em apenas um clique (one-click reports). Os dados
so coletados a partir de todo o cluster (Publisher e Subscribers) e fornece informaes sumarizadas
sobre os principais problemas que podem impactar no funcionamento ou na operao do sistema
como um todo. Alm disso, a interface avisa quando voc solicitar um relatrio que pode demorar
muito ou impactar o servidor devido ao tamanho das consultas que tero que ser realizadas no
sistema para gerar o relatrio.
CLI
O CLI normalmente acessado via SSH, porm se o servidor perdeu acesso rede voc pode se
conectar diretamente ao servidor utilizando um monitor e um teclado. Inicialmente somente a conta
criada na instalao do sistema pode acessar o sistema via CLI, porm outras contas podem ser
criadas posteriormente para tais finalidades.
Os comandos cobertos pela CLI so os mesmos da tela de OS Administration com algumas opes a
mais, tais como:
Desligar e reinicializar (Shut down/restart) o sistema

Fazer upgrades e downgrades de verso de software
Iniciar, parar e reinicializar servios
Modificar parmetros de rede (endereo IP, mscara, gateway, etc)
Utilizar ferramentas de teste de rede (ping, traceroute e captura de pacotes)
Utilizar o DRS (backup e restore)
Adicionar e modificar contas de administrao
Mostrar informaes do carregamento e processos do sistema
Verificar o status do servidor, incluindo verses de software, CPU, memoria e utilizao de
disco (disk utilization), plataforma de hardware e nmeros de srie (serial numbers)
O help no CLI parecido com o dos roteadores Cisco com IOS, utilizando o ? e tambm tem a
funo de auto completar com a tecla tab.
importante lembrar que o CLI uma ferramenta muito poderosa mas os comandos entrados muitas
vezes tem efeito imediato sobre os servidores, sem perguntas de verificao (Voc quer realmente
aplicar esse comando? Sim/No?) podendo parar o servidor ou afetar o seu funcionamento muito
negativamente. Revise sempre o CLI Administration Guide disponibilizado pela Cisco e esteja certo
do que est fazendo antes de entrar com comandos via CLI.
Gerenciamento de Usurios no CUCM

Como o CUCM um sistema muito amplo diversos perfis etipos de usurios podem ter a necessidade
de acessar o sistema. Por exemplo, atendentes de primeiro nvel precisam consultar informaes
sobre os telefones dos usurios, os de segundo nvel precisam fazer troubleshooting mais avanado,
porm sem modificar o sistema e os engenheiros seniores, chamados de terceiro nvel, podem ter
acesso completo ao sistema. Portanto necessrio criar usurios e grupos para podermos definir
qual o nvel de permisso que cada um ter no sistema.
Resumidamente os usurios (Users) so colocados dentro de grupos (Groups), sendo que esses
grupos so ligados a determinadas funes (Roles) e essas Roles definem os privilgios de acesso aos
aplicativos.
As Roles ou funes definem um conjunto de privilgios a recursos na aplicao do CUCM. Um
recurso pode ser a pgina de administrao do CUCM, uma ferramenta de report ou uma
determinada seo ou feature dentro da pgina da web do CUCM. Os privilgios para cada recurso
pode ser configurado como uma das opes abaixo.
No Access: essa opo bloqueia acesso a determinado recurso.
Read: com essa opo o recurso pode ser visualizado e no pode ser editado, ou seja, somente
leitura. Aqui os botes de adicionar, editar ou remover no sero exibidos.
Update: essa opo d acesso completo ao recurso, incluindo edio, modificao e deleo,
quando aplicvel.
Outros aplicativos, tais como o Cisco Unified Serviceabilityou Cisco Extension Mobility, podem ter
configuraes especficas de nveis de acesso (access privileges) para suas aplicaes internas.
Temos no total 39 padres pr-definidos para as Roles no CUCM verso 8.x. Na maioria dos casos
existe uma funo ou role para fornecer acesso administrativo. Caso no exista um padro que tenha
exatamente sua necessidade de funo voc pode configurar uma role customizada para esse caso.
As custom roles ou funes padro podem ser utilizadas para quaisquer uma das aplicaes
mostradas abaixo:
CUCM Administration
CUCM Serviceability
Cisco Computer Telephone Interface (CTI)
CUCM Administrative XML (AXL) database
Cisco Extension Mobility
CUCM End User
Veja na figura abaixo um exemplo da lista de roles que podemos ter no CUCM indo em Cisco Unified
CM Administration > User Management > Role depois clique no boto Find sem escrever nada no
campo find role para vir todas as funes possveis.
Informao Importante:
A role ou funo chamada Standard CCM Admin Users d ao usurio acesso interface de
administrao do CUCM (Cisco Unified Communications Manager Administration User Interface),
sendo a base para todas as demais tarefas administrativas e servindo como uma role de autenticao
(authentication role), pois ela d apenas acesso Interface de Administrao mas no permite que
nada seja alterado, ou seja, o Cisco Unified Communications Manager Administration define essa role
como necessria para efetuar o login no sistema.
Portanto a funo de Standard CCM Admin Users no inclui nenhum privilgio a no ser o de
efetuar o login na pgina de administrao do CUCM, sendo que se o administrador quer dar mais
alguma funo ou privilgio ao usurio ele precisar inserir outra role para definir as partes da
interface de administrao do CUCM que o usurio poder administrar.
J a role Standard CCMADMIN Administration permite que o usurio acesse e faa alteraes em
toda interface de administrao do Cisco Unified Communications Manager.
Uma coisa interessante que se um usurio tiver em um grupo com apenas a role Standard CCM
Admin Users ele pode acessar o CUCM mas no pode alterar nada, ao passo que se ele estiver em
um grupo com apenas a role Standard CCMADMIN Administration ele pode fazer o que quiser no
CUCM, mas no poder se logar no sistema de administrao.
Portanto, um usurio que vai ser administrador do sistema ou de partes do sistema deve ter a role
Standard CCM Admin Users para acessar a pgina de administrao do Cisco Unified
Communications Manager e deve ter pelo menos mais uma role para administrar o sistema.
Por exemplo, suponha que um determinado usurio vai trabalhar no Service Desk de uma empresa e
ter a funo de atendimento de primeiro nvel, a qual no precisa fazer alteraes no sistema, mas
precisar verificar as configuraes para seguir os guias de troubleshooting durante o atendimento de
suporte. Nesse caso, esse usurio precisar ter a role Standard CCM Admin Users para acessar a
pgina de administrao do Cisco Unified Communications Manager e a role Standard CCMADMIN
Read Only, a qual permite acesso de leitura e visualizar as configuraes na pgina de administrao
do CUCM.
J quando falamos dos grupos a aplicao do CUCM tem24 grupos padres (Standard Groups) prdefinidos. Esses grupos por sua vez so vinculados a uma ou mais Standard Roles (funes padro),
fornecendo diversos nveis de privilgio para diferentes aplicativos dentro das pginas de
administrao do CUCM. A maioria dos grupos no tem usurios por padro, portanto quando os
usurios so criados ou importados no CUCM essas contas podem ser adicionadas a um ou mais
grupos. Dessa forma os privilgios que foram dados pelas Roles so herdados pela conta de usurio
quando ele vinculado ou adicionado a um grupo.
Da mesma maneira que vimos anteriormente para as Roles, os grupos tambm permitem a criao
de grupos customizados caso as opes padres no atendam a necessidade do cenrio onde o
ambiente do CUCM est sendo implementado. Veja a figura 2 com a tela da listagem dos grupos
padro do sistema, para acessar essa tela voc deve ir em Cisco Unified CM Administration > User
Management > Groups depois clique no boto Find sem escrever nada no campo find groups
para vir todas as funes possveis.
Um problema que temos que entender como o efeito de um conflito das diferentes roles de cada
grupo que um usurio pode pertencer afetam os privilgios desses usurios. Lembre que um usurio
pode ser membro de diversos grupos e cada grupo pode ter diferentes roles, por sua vez definindo
diferentes nveis de privilgio que podem ser conflitantes quando colocados em conjunto em um
mesmo usurio.
Por exemplo, um usurio Marcelo membro de dois grupos de usurio (User Groups), chamados
grupo_A e grupo_B. O grupo_A est vinculado a uma Role A, que d privilgio de acesso de Update
a um determinado application resource (recurso). J o grupo_B est associado Role B, que d
privilgio de leitura (Read) ao mesmo recurso. Nesse caso qual o privilgio vai valer para esse recurso
no caso do Marcelo?
A resposta determinada pelo Enterprise Parameter Effective Access Privileges for Overlapping
User Groups and Roles. O padro para esse parmetro o Maximum (mximo), ou seja, vale o maior
privilgio e ele ter acesso de Update (acesso completo) para esse recurso que est em conflito nos
grupos A e B. Voc pode trocar esse valor para Minimum (mnimo), ou seja, nesse caso o Marcelo
teria privilgio de leitura (Read) para o exemplo citado acima.
Note que essa configurao citada acima no afeta os privilgios do grupo padro de Super Users do
CUCM.
Descrevendo o GUI e CLI do CUC (Cisco Unity Connection)

O CUC (Cisco Unity Connection) tambm tem seis interfaces de gerenciamento conforme abaixo:
Cisco Unity Connection Administration
(https://ip_do_servidor_CUC/cuadmin)
Cisco Unified Serviceability
(https://ip_do_servidor_CUC/ccmservice)
Cisco Unity Connection Serviceability
(https://ip_do_servidor_CUC/cuservice)
Cisco Unified Operating System Administration
(https://ip_do_servidor_CUC/cmplatform)
Disaster Recovery System
(https://ip_do_servidor_CUC/drf)
Command-Line Interface
Interface de Administrao - Cisco Unity Connection Administration

Diferente do CUCM o CUC tem uma interface de administrao que mostra as opes em rvore,
como se fosse o Windows Explorer, facilitando encontrar e navegar pelas pginas que voc precisa
configurar.
As opes fornecidas seguem abaixo com uma descrio breve de cada uma.
Users: aqui voc tem acesso base de usurios locais para criar ou editar usurios. Os menus de
importao User import e sincronizao synchronization tambm esto listados nesse menu.
Class of Service: define as facilidades e recursos (features) que sero disponibilizadas aos usurios,
incluindo as Licensed and Advanced features (facilidades avanadas e licenciadas) e pode aplicar
outras limitaes das interaes dos usurios. O Class of Service um mtodo flexvel para
controlar a interao dos usurios com o CUC, principalmente as facilidades que necessitam de
licenciamento (licensed features). No existe um limite para o nmero de Classes of Service que
voc pode criar, o que torna possvel construir diversas classes especficas cobrindo diversas
combinaes de requisitos de projeto.
Templates: nessa opo voc pode criar padres ou templates com parmetros comuns para os
usurios (Users), Contacts ou Call Handlers. Com isso podemos criar um dos trs objetos citados
anteriormente de uma maneira rpida, pois os parmetros que definimos em nosso template sero
aplicados individualmente para cada objeto de uma vez s, acelerando o processo e tornando-o
padronizado, ou seja, com maior confiabilidade.
Contacts: um System Contact uma conta que permite interao com o CUC sem ter uma conta
de correios (mailbox) associada a ele.
Distribution Lists: permite que mensagens sejam enviadas a diversos usurios. Voc pode criar
quantas listas forem necessrias e utilizar uma Class of Service (classe de sevio) para bloquear ou
permitir determinados usurios de utilizarem essas listas para as System Distribution Lists.
Call Management: Configura os Call Handlers. Os Call Handlers so a base da estrutura do CUC e
so configurados para atender as chamadas, tocar as mensagens de boas vindas (play greetings),
rotear as chamadas e capturar as mensagens. Existem call handlers mais especializados, tais como os
Directory Handlers que permitem um usurio que est discando (caller) procure dentro do diretrio e
tambm deixe uma mensagem para esse determinado destino escolhido. Existe tambm os
Interview Handlers, os quais interagem com quem discou tocando uma srie de questes gravadas
e coletando as respostas em uma nica mensagem.
Message Storage: permite que seja definido o espao para cada caixa de correio de voz (mailbox
quotas), limitando quanto cada usurio pode ter gravado em seu mailbox evitando que o servidor
fique sem espao em disco.
Networking: permite configurar mltiplos sistemas CUC systems em um ambiente do tipo rede
digital (Digital Networking) ou em um ambiente VPIM (Voice Profile for Internet Mail).
Dial-Plan: permite a criao de parties (Partitions) adicionais e Search Spaces para controlar a
visibilidade e acesso aos componentes de mensagem (messaging componentes). til para esconder
parte do sistema CUC system de certos usurios ou funes.
System Settings: no menu System Settings temos diversos submenus que fornecem configuraes
globais do sistema. Seguem alguns submenus que podemos utilizar:
Licenses: mapeia e mostra as licenas disponveis no sistema, as quais so vinculadas ao MAC
address da placa de rede do servidor.
Holiday Schedules: aqui temos a configurao da agenda de feriados (All Hours, Weekdays e Voice
Recognition Update Schedule), as quais voc pode modificar mas no apagar. Voc ainda pode criar
uma agenda customizada.
External Services: nessa opo voc pode fazer com que o CUC utilize as informaes de
calendrio e contatos a partir do Microsoft Exchange. Essa opo pode ser configurada no Personal
Call Routing Rules. Se existir um Cisco Unified MeetingPlace na rede o CUC pode puxar informaes
das conferncias agendadas desse servidor para que os usurios possam visualizar e at entrar nessas
conferncias (join meetings) a partir de seus Personal Communications Assistant ou do telefone IP.
LDAP: configura as opes de sincronizao do LDAP (Synchronization - User import) e
autenticao (LDAP Authentication redirecionamento da senha para utilizao da base do AD via
LDAP).
SMTP: configurao para que o CUC possa notificar os usurios atravs de e-mail quando eles
receberem novas mensagens de voz.
Advanced: permite configurar uma srie de opes avanadas tais como SMPP, que permite o
CUC enviar mensagens utilizando Short Message Peer to Peer/Short Message Service (SMS) para
avisar nos telefones celulares dos usurios que eles tem mensagem em sua caixa postal de voz.
Telephony Integrations: mostra e configura o sistema de telefonia que o CUC est integrado, tais
como port groups e ports.
Tools: menu que permite a configurao do sistema de administrao em massa (Bulk
Administration Interface) e o agendamento de tarefas (Task Management).
J na figura abaixo voc visualiza um exemplo de tela da interface de administrao do CUC.
Interface Cisco Unity Connection Serviceability

A aplicao de Serviceability do Unified CUC bem parecida com a oferecida pelo CUCM, porm
o CUC fornece uma aplicao a mais chamada Cisco Unity Connection Serviceability, a qual tem
funes muito diferentes da primeira (veja figura abaixo).
O CUC Serviceability uma ferramenta de manuteno(troubleshooting), a qual pode definir alarmes,

traces e logs tool e tambm possui controles de servio (service controls) podendo
ativar/desativar/para/iniciar/reiniciar um servio (Activate/Deactivate e Start/Stop/Restart).
Se uma redundncia Active-Active (ativo-ativo) est configurada e ativada em um par de servidores
em cluster as ferramentas para gerenciamento desse cluster esto dentro dessa interface. Alm disso,
tambm disponibilizada uma interface para relatrios (reports).
Interface GUI e CLI do Cisco Unified Presence Server

Diferente do CUCM e CUC o Cisco Unified Presence Server (CUPS) tem cinco interfaces
administrativas, conforme abaixo:
1. Cisco Unified Presence Administration
(https://ip_do_servidor_CUPS/cupadmin)
2. Cisco Unified Serviceability
(https://ip_do_servidor_CUPS/ccmservice)
3. Cisco Unified Operating System Administration

(https://ip_do_servidor_CUPS/cmplatform)
4. Disaster Recovery System
(https://ip_do_servidor_CUPS/drf)
5. Command-Line Interface (CLI)
Assim como para o CUCM e o CUC, a conta de administrador do CUPS por padro permite login nas
interfaces de OS Administration (administrao do sistema operacional), DRS (recuperao de
desastre) e CLI. O usurio administrativo das aplicaes (Application Administration Account) o
nico por padro que pode entrar na interface de administrao (CUPS Administration) e Unified
Serviceability. Voc pode criar outros usurios para administrao da plataforma se necessrio.
Alm disso, aps a instalao voc precisar configurar alguns parmetros para conexo do CUPS ao
CUCM Publisher, tais como IP do CUCM, habilitar o servio de AXL no CUCM, definir um usurio e
senha para o AXL (no CUCM para utilizar no CUPS como usurio e senha de login) e definir uma senha
de segurana. No captulo que trataremos especificamente do CUPS faremos um passo a passo para
ativar o servio.
Interface de Administrao do Cisco Unified Presence

A interface CUPS Administration (interface administrativa) possui os menus mostrados abaixo:
System: fornece facilidades de integrao com o CUCM, definio de Access Control Lists de entrada
e sada e gerenciamento do licenciamento.
Presence: aqui definimos os gateways fornecendo informaes do Presence a partir do CUCM ou
integrao de calendrio com o Microsoft Outlook. Tambm podemos configurar o Interdomain
federation atravs de diferentes domnios utilizando o protocolo Session Initiation Protocol (SIP)
ou o protocolo Extensible Messaging and Presence Protocol (XMPP), sendo que o mais comum o
SIP utilizado em conjunto com o Microsoft Office Communications Server (OCS), enquanto o XMPP
mais utilizado para integrao com o Google Talk.
Messaging: o CUPS pode utilizar banco de dados externos (PostgreSQL) ou servidores de terceiros
para habilitar o IM retention regulatory compliance (Persistent messaging gravao das
mensagens por questes de regras regulatrias).
Application: aqui temos as aplicaes do CUPS, tais como Desk Phone Control e IP Phone
Messenger.
User Management: segue padro similar de Groups-and-Roles que vimos para o CUCM. Os
usurios podem ser sincronizados e importados com o CUCM.
Bulk Administration: parecido com a ferramenta de Bulk do CUCM, podendo realizar tarefas
repetitivas, como configuraes em massa e agendamento de tarefas.
Diagnostics: utilizado para verificao do status do sistema e troubleshooting. Tambm oferece um
resumo do sistema (System Dashboard) para verificao rpida das configuraes do sistema.
Help: menu de ajuda.
Cisco Unified Presence Serviceability

A interface Cisco Unified Presence Serviceability fornece funo similar a que vimos para o CUC
Serviceability, incluindo as funes mostradas abaixo:
Monitorao de alarmes e eventos para ajudar no troubleshooting
Acessar traces e logs de servio do CUPS
Monitorao em tempo real do comportamento do CUPS via CUCM RTMT
Ativao de facilidades de servio (Feature Service), assim como a desativao e controle. Controle
do servio de rede (Network Service Control)
Arquivamento de relatrios (Reports archive)
Configurao do SNMP
Monitorao do uso do disco rgido e log para parties locais ou servidores em cluster
Implementando Telefones IP no CUCM

Lembre que j configuramos telefones IP no CUCM Expressde uma maneira simples, configurando um
ephone, um ephone-dn e definindo as facilidades que esses telefones e usurios poderiam usufruir,
tais como transferncias e call parking.
No CUCM a tarefa tambm simples, porm existem diversos servios, protocolos e processos
rodando em background, os quais voc normalmente configura somente no incio da operao, que
so necessrios para que essa configurao seja simples e o sistema funcione corretamente. Portanto
aqui vamos revisar os processos e detalhes escondidos atrs de algumas tarefas administrativas
necessrias para facilitar e tornar o processo de criao e funcionamento dos telefones IP possveis
dentro do CUCM. Algumas sero muito semelhantes ao que fizemos no CME.
Na prtica o processo para voc poder utilizar os telefones IP e demais endpoints no CUCM passa
antes por algumas tarefas preliminares, tais como, instalar o servidor, preparar o servidor inserindo as
configuraes iniciais, ativar servios e configurar as integraes com CUC, CUPS e aplicaes
externas, configurar o plano de discagem e demais itens que iremos estudar nesse captulo, para a
sim conseguir configurar os telefones IP e iniciar a fazer ligaes via o CUCM.
Servios Necessrios para o Funcionamento dos Telefones IP
Conforme j estudamos em nosso curso, algumas funes e servios especiais so necessrios para
que os telefones IP funcionem corretamente, fazendo parte desse escopo uma variedade de
protocolos abertos e proprietrios. Os principais servios e protocolos necessrios esto listados
abaixo:
Servios e protocolos necessrios:
Network Time Protocol (NTP)

Cisco Discovery Protocol (CDP)
Trivial File Transfer Protocol (TFTP)

Domain Name System (DNS)
Apesar de j termos comentado ao longo do curso alguns desses protocolos, vamos mais uma vez,
fazer uma breve descrio de cada um deles, pois o perfeito entendimento do conceito envolvido
muito importante para o seu sucesso no mundo da tecnologia Unified Communications da Cisco.
Network Time Protocol (NTP)
De uma maneira resumida, podemos dizer que o NTP um protocolo que fornece sincronizao de
tempo atravs da rede (Network-based Time Synchronization), possibilitando uma fonte nica e
confivel para os relgios dos equipamentos de rede.
A importncia de termos uma fonte segura de sincronismo que em um momento
de troubleshooting temos como rastrear na rede os eventos de uma maneira sequencial, tendo
certeza dos eventos que ocorreram naquela sequncia lgica. Alm disso os Call Detail Records (CDR)
eCall Management Records (CMR) so marcados com uma informao de tempo (data e hora) em
seus arquivos de log, seno como teramos certeza que determinada chamada foi realizada no horrio
relatado no log? Existem tambm recursos e funes que necessitam dessa informao de tempo
(calendrio), por exemplo um sistema de agendamento de reunies integrado com o CUCM, portanto
a sincronizao fundamental para que tenhamos essas funes operando corretamente.
Normalmente, quando utilizamos o NTP em uma rede corporativa um roteador se sincroniza com um
relgio atravs de um servidor de tempo via Internet (Internet time server por exemplo, o relgio
atmico NIST ou com um relgio atravs de GPS via satlite) e os outros dispositivos da rede se
sincronizam com esse roteador. Veja a figura ao abaixo:
No Cisco Unified Communications Manager (CUCM), mais especificamente no Publisher, que

configuramos a informao do NTP (ele faz o papel do roteador citado no pargrafo anterior). Essa
informao solicitada na instalao do servidor (veja figura abaixo), ou seja, voc ter que entrar
com o IP do servidor NTP.
Nos servidores Subscribers o sincronismo realizado atravs da informao enviada pelo Publisher,
e j ostelefones IP pegam sua informao de tempo atravs dosservidores Subscribers via mensagens
trocadas atravs protocolo Skinny Client Control Protocol (SCCP).
No caso do telefone IP trabalhar com o protocolo Session Initiation Protocol (SIP) ele necessitar
de uma referncia de NTP, porm se no estiver configurado eles podem pegar essa informao
atravs da informao de tempo (time stamp) contida na mensagem de SIP OK enviada como
resposta pelo servidor Subscriber. Veja a figura abaixo:
Existe tambm a possibilidade dos servidores Publisher utilizarem um relgio interno para fins de
sincronismo, porm no recomendado pois podem causar problemas de preciso.
Cisco Discovery Protocol (CDP)
J vimos quando estudamos o CME que o CDP muito importante para os telefones IP, pois atravs
dele que asinformaes da VLAN (VLAN ID VLAN de Voz e VLAN de dados) so enviadas aos
telefones IP o que torna possvel a marcao dos quadros 802.1Q enviados ao switch. Veja a figura
abaixo:
O CDP deve ter sido estudado por voc durante o CCNA, lembrando que ele um protocolo
proprietrio da Cisco e vem habilitado por padro em todos os equipamentos Cisco. Lembre-se que
caso voc tenha um telefone IP ou um switch de outro fabricante, a informao da VLAN ID ter que
ser configurada manualmente, uma vez que eles no iro reconhecer o CDP.
O DHCP, como j estudamos para o CME, utilizado parafornecer endereamento IP consistente aos
telefones IP, assim como outras informaes importantes para o funcionamento deles.
Voc at pode configurar o IP manualmente nos telefones IP, porm isso seria muito lento e sem
confiabilidade, pois estaria sujeito a erros de operao (erros humanos).
No caso do CUCM podemos utilizar um servidor existente (pois a maioria das redes j tem seu
servidor DHCP), um roteador local ou at mesmo o prprio CUCM para atuar como servidor DHCP.
Utilizar o CUCM como servidor DHCP no muito recomendado, principalmente em redes com um
nmero muito grande de telefones IP. Mais para frente veremos a configurao do DHCP no CUCM e
vamos revisar a configurao do DHCP nos roteadores.
Os parmetros mnimos que precisamos enviar aos telefones IP via DHCP so:
Endereo IP
Mscara de subrede
Default Gateway
Servidor DNS
Servidor TFTP

Conforme j estudamos no CME o PoE um padro paraenvio de alimentao DC para os telefones
IP e demais dispositivos atravs do cabo de rede. Ele pode ser fornecido pelos Switches ou ento
por injetores (power injector) oupatch pannels (power pannels) PoE.
Lembre que com o PoE podemos economizar com a compra de fontes e utilizao de rede de
alimentao para essas fontes de alimentao externas que seriam necessrias para os telefones IP,
pois agora os aparelhos so ativos e no mais passivos como na telefonia convencional.
Trivial File Transfer Protocol (TFTP)
O servio de TFTP crtico para os telefones IP, isso deve estar claro para voc! Lembre-se que j
estudamos que os telefones IP utilizam esse servio para baixar arquivos de configurao, firmware e
demais dados necessrios para seu funcionamento.
Sem o servio de TFTP os telefones no iro funcionar corretamente pois, por exemplo, quando voc
altera a configurao de um aparelho o CUCM cria ou modifica o arquivo de configurao e grava esse
novo arquivo ou atualizao no servidor TFTP para que o telefone possa mais tarde utilizar essa
informao para se atualizar.
O servio de TFTP deve ser fornecido por um ou mais servidores do cluster de CUCM, pois um
servidor externo (ou genrico) no teria a capacidade de se integrar completamente ao CUCM (assim
como um servidor do cluster consegue) e o servio no funcionaria corretamente.
Portanto, um dos servios que teremos que ativar em um dos servidores do cluster CUCM o
de TFTP.
Domain Name System (DNS)
O DNS fornece traduo de um hostname para um endereo IP. Ele no considerado crtico para o
funcionamento dos telefones IP e em muitos casos recomenda-se eliminar a dependncia do DNS
pelos telefones IP (veremos isso no captulo 11), porm em alguns casos ele torna-se necessrio.
O CUCM no consegue fornecer o servio de DNS e ele deve ser configurado em um servidor a parte e
normalmente dedicado a essa servio.
Normalmente pensamos no DNS atuando na Internet, porm ele tambm pode ser configurado para
resolver nomes dentro da sua Intranet e servir para traduo dos seus servidores Internos.
Processo de Registro dos Telefones IP via SCCP
O processo de registro dos telefones IP no CUCM (com protocolo SCCP) similar ao que estudamos
para o CME, porm no um processo to simples como pensamos. Abaixo segue um resumo do
processo de registro.
1. O telefone energizado (PoE ou fonte externa).
2. Carrega o firmware que est em sua memria local.
3. Aprende o Voice VLAN ID via CDP a partir do switch.
4. Utiliza seu cliente DHCP para aprender seu IP address, subnet mask, default gateway e servidor
TFTP (mais opes podem ser passadas pelo DHCP, esse o mnimo).
5. O telefone solicita ao servidor TFTP seus arquivos de configurao, os quais so criados pelo CUCM
com o nome SEP<mac_address_do_telefone>.cnf.xml quando o administrador cria ou modifica os
telefones.
6. O telefone se registra no CUCM primrio listado nesse arquivo de configurao. Com o telefone
registrado o CUCM passa o template de softkeys utilizando mensagens do protocolo SCCP.
Importante:
No arquivo SEP<mac_address>.cnf.xml temos uma lista de servidores CUCM em ordem de prioridade
para registro dos telefones, as portas TCP que devem ser utilizadas pelo SCCP para sinalizao, o
firmware que os telefones devem utilizar (por modelo de telefone) e as URLs de servio que cada
dispositivo deveria estar utilizando.
As informaes adicionais como o nmero do telefone (DN), teclas (softkeys) e os speed dials
so enviadas pelo CUCM via SCCP para fase final do registro do telefone.
Processo de Registro de Telefones IP SIP
O processo de registro de telefones IP que utilizam oprotocolo SIP para se comunicar com o CUCM
um pouco diferente do que estudamos anteriormente para o SCCP, porm dos passos 1 a 4 so iguais
e os demais seguem abaixo:
1. O telefone entra em contato com o servidor TFTP e solicita o arquivo da lista de certificado de
segurana (Certificate Trust List file quando utilizado segurana no cluster).
2. O telefone entra em contato com o servidor TFTP e solicita o seu arquivo de configurao
SEP<mac_address>.cnf.xml.
3. Faz o download das regras de discagem configuradas para ele (SIP Dial Rules caso existam regras).
4. Faz o registro no CUCM primrio listado em seu arquivo de configurao.
5. Baixa os arquivos de localizao do servidor TFTP (localization files).
6. Baixa as configuraes dos softkeys do servidor TFTP.
7. Baixa os tons de discagem (ringtones se houver algum especial) do servidor TFTP.
Preparando o CUCM para Receber os Telefones IP
O CUCM no vem pronto, ele no plug and play, portanto voc precisar fazer
algumas configuraes antes de iniciar a instalar e configurar seus telefones na rede.
Basicamente teremos que verificar os seguintes itens de configurao prvia no CUCM para termos
uma implantao dos telefones mais concisa. Veja abaixo:
1. Configurar e verificar os servios de rede (Network Services), ajustando se preciso o NTP, ativando
o servio de DHCP (se preciso no prprio CUCM) e habilitando o servio de TFTP.
2. Configurar os parmetros gerais do CUCM (Enterprise Parameters), modificando e verificando as

configuraes padro do cluster para ajustar realidade da empresa onde ele est sendo implantado.
3. Configurar os servios (Service Parameters), fazendo um ajuste fino das aplicaes atravs dos
parmetros (settings) e comportamento (behavior).
Ativando os Servios
Muitos dos servios necessrios so desativados por padro pelo CUCM e teremos que utilizar
a interface de Serviceability para ativ-los. Precisaremos ativar os seguintes servios:
CallManager
TFTP
DHCP Monitor services
Veja nas figuras 1 e 2 abaixo um exemplo da tela com os servios citados que precisamos ativar.
Na figura 1 temos como chegar na ativao de servios, j na figura 2 estamos na parte de ativao
onde voc deve selecionar os servios que sero ativados e depois clicar em save. Vai aparecer uma
mensagem dizendo que a operao pode demorar e voc deve esperar o refresh da tela.
Figura 1
Figura 2
Configurando o Servidor DHCP
Os servidores CUCM j contemplam um servio bsico de DHCP para suportar o endereamento dos
telefones IP, porm a recomendao que no mximo tenhamos 1.000 telefones para no
sobrecarregar o processamento (cpu) do servidor. No h redundncia nativa do servio de DHCP nos
servidores CUCM e apenas um deles suporta essa configurao por cluster, normalmente o Publisher.
H tambm a possibilidade de serem criadas diversas suberedes ou escopos (scopes) nos servidores.
Com o servio de DHCP habilitado, conforme tpico anterior, podemos configurar o servio de DHCP
seguindo os passos abaixo:
1. Na Interface de administrao do CUCM (Cisco Unified CM Administration) entre no menu
System > DHCP > DHCP Server (figura 1).
2. Clique em Add New (figura 2).
3. Selecione o servidor que tem o servio de DHCP rodando no cluster (menu pull-down) (figura
3).
4. Configure o DHCP no mnimo com as informaes abaixo (figura 4):
1. Primary DNS Server IPv4 Address (endereo do servidor DHCP)
2. Primary TFTP Server IPv4 Address (endereo do servidor TFTP)
3. IP Address Lease Time (tempo de aluguel do IP ao telefone IP)
Os demais valores foram colocados como exemplo e voc pode utilizar em sua configurao, mas
lembre que na prtica dependem de cada projeto.
Essas so ento as configuraes gerais que sero utilizadas como base para o prximo slide (DHCP
Subnet) onde vamos especificar as subredes que o CUCM ir trabalhar e sero herdadas por elas,
porm se voc alterar alguma configurao especificada na pgina de Subnet Configuration ela ir
sobrescrever o que foi configurado no menu anterior.
Lembre que tanto a diviso de uma rede em subredes quanto os conceitos da configurao do DHCP
so pr-requisitos que voc deve ter aprendido no CCNA, por isso no entraremos em detalhes aqui
no CCNA Voice.
Figura 1
Figura 2
Figura 3
Figura 4
Agora para configurar as subredes do DHCP v no menu System > DHCP > DHCP Subnet(figura 01).
Clique em Add New para criar as subredes. Voc pode criar quantas subredes forem necessrias
para seu projeto. Abaixo seguem as configuraes necessrias:
Subnet address (endereo de rede ou subrede)

Primary range start IP (incio da faixa de IPs a serem fornecidos)
Primary range end IP (ltimo IP da faixa)
Primary router IP address (default gateway)
Subnet mask (mscara de subrede)

Primary DNS server IP address (endereo do DNS)
TFTP server IP address (servidor TFTP)
Lembre que as configuraes que voc fizer aqui iro sobrescrever as configuraes setadas na tela
anterior do servidor DHCP. Veja um exemplo de configurao onde no vamos alterar o que j foi
configurado no servidor. Veja afigura 2.
Agora se voc voltar na tela de DHCP Subnet e pesquisar ver que a sua subrede foi criada,
conforme figura 3.
Figura 1
Figura 2
Pr-requisitos para Configurar os Telefones IP no CUCM

Existe uma srie de configuraes necessrias para que os telefones IP funcionem no CUCM e vamos
nesse tpico tratar de uma forma resumida cada um desses requisitos, conforme listagem abaixo:
Device Pool: agrupamento de dispositivos que compartilham uma configurao em comum.
Cisco Unified CM Group: utilizado para listar os servidores redundantes para os telefones IP.
Region: identifica o CODEC a ser utilizado.
Location: define a banda a ser utilizada.
Date/Time Group: define os grupos por fuso horrio das diferentes regies.
Phone NTP Reference: define a referncia de tempo dos telefones.
Device Defaults: define um padro para um telefone criado.
Softkey Template: padro que aparecer nos softkeys dos telefones.
Phone Button Template: padro dos botes e teclas do telefone.
SIP Profile: padro para telefones SIP.
Phone Security Profile: padro de segurana para os telefones.
Common Phone Profile: definies para controle do comportamento do telefone.
Na sequncia vamos analisar cada um dos requisitos separadamente.
Device Pool
Os Device Pools, em portugus seria um grupo de dispositivos, fornece configuraes comuns para
grupos de usurios como se fosse um template que podemos aplicar para diferentes dispositivos ao
mesmo tempo, evitando um processo de configurao manual e consequentemente, evitando
possveis erros de configuraes.
Dessa maneira voc pode criar diversos Device Pools, um por localizao ou funo, por exemplo, um
device pool para operadores de call center e outro para o setor administrativo que esto na mesma
localidade. Vamos a partir de agora analisar algumas das principais configuraes disponibilizadas na
tela de Device Pool. Veja as telas nas figuras 1 e 2. Voc ter que clicar em Add New para criar um
novo pool aps selecionar a opo device pool.
Agora vamos na sequncia ver as principais opes disponibilizadas na configurao no device pool.
Voc pode fazer uma configurao baseado somente nos itens obrigatrios marcados com astersco
(*) e deixar que o prprio CUCM utilize suas configuraes internas para completar as outras opes.
Note que no estudaremos em detalhe como subir um CUCM, pois esse assunto detalhado no CCNP
Voice nos cursos CIPT1 e CIPT2. Perceba que so dois cursos para tratar do assunto de to extenso
que ele !
Figura 1
Figura 2
Device Defaults
O menu Device Defaults uma pgina que lista todos osdispositivos (endpoints) que
so suportados (com entradas separadas por tipo SCCP e SIP), mostrando o firmware utilizado, Device
Pool e Phone Button Template que cada um utiliza por padro default.
Estas informaes podem ser teis para o administrator configurar um padro para o sistema quando
um novo tipo de dispositivo se registra. Veja as figuras 1 e 2 abaixo:
Figura 1
Figura 2
Criando Padres Utilizando Softkey Template e Phone Button Template
Os templates de Softkey controlam que botes de softkeyestaro disponveis para os usurios,
normalmente tratam dos acessos s facilidades e recursos, tais como conferncia, transferncia, Park,
Extension Mobility e outras. Temos um total de sete templates de softkey disponveis, mas podemos
criar outros, se necessrio, utilizando os padres como base ou no.
J o Phone Button Template define o comportamento dos botes que esto direita da tela do
telefone, isso para a maioria dos modelos, no entanto podemos encontrar variaes. Por default, so
criados dezoito (ou mais) phone button templates, isso porque existem templates diferentes para
cada tipo de telefone que o sistema suporta e at mesmo, templates distintos dependendo do tipo do
protocolo utilizado pelo telefone (SCCP ou SIP). Normalmente, os templates padro fornecem duas
linhas e o restante dos botes so configurados como speed dials. Voc pode customizar e adicionar
mais templates para definir mais botes com funes diferentes.
Veja as figuras 1, 2,3 e 4 ao lado com as telas relativas aos templates de botes e softkeys. Voc vai
encontrar essas configuraes na interface de administrao do CUCM, em "Device > Device
Settings". A figura 2 mostra um exemplo da tela do Phone Button Template e a figura 3 do Softkey
Template.
Obs: lembrem-se que os Phone Button Templates se referem aos botes que ficam na lateral do
telefone (quando existirem) e servem para configurarmos linhas, speed dial, blf. J os Softkey
Templates se referem as teclas que utilizamos para utilizar alguma funcionalidade do telefone, tais
como, capturar chamada, colocar em espera, transferir e etc. Na figura 4 um exemplo de telefone IP
Cisco 7941 onde mostramos a localizao dos phone buttons e softkeys.
Figura 1
Figura 3
Figura 4
Entendendo os Profiles
Os Profiles tem a funo de permitir a configurao de vrias tarefas repetitivas ao mesmo tempo
(one-time configuration) atravs de uma srie de tipos de profiles diferentes existentes. Com isso
voc pode criar diversas verses de profiles para cada tipo de telefone que voc necessite configurar.
Abaixo seguem dois tipos de profiles que podemos criar:
Phone Security Profile

Common Phone Profile
Existe um Phone Security Profile padro para cada tipo de telefone e protocolo. Por padro esses
profiles tem a segurana desabilitada e voc pode escolher se vai ou no configurar o dispositivo
como seguro, criptografando os arquivos de configurao que esto no servidor TFTP e modificando
as configuraes do certificado (Certificate Authority Proxy). Veja as figuras 1 e 2. Na figura 2 se voc
clicar em Find com o campo de busca em branco sero mostrados os profiles padro, veja que
existem diversos e voc pode adicionar o seu customizado clicando em Add New.
Figura 1
Criando Telefones no CUCM

Agora que vimos alguns itens de preparao do CUCM vamos ver como inserir telefones no sistema.
Os telefones podem ser adicionados de quatro maneiras diferentes no CUCM, conforme abaixo:
Mtodos de Configurao de Telefones no CUCM:
1. Manual Configuration (Configurao Manual):
Com esse mtodo manual podemos criar um novo telefone em tempo real acessando a pgina
Phone Configuration e configurando todos os parmetros necessrios. Normalmente, essa opo

utilizada no dia a dia operacional de uma rede de voz sobre IP quando os operadores necessitam
adicionar/modificar poucos ramais.
2. Autoregistration (Registro Automtico):
Nessa opo os telefones podem ser configurados e adicionados dinamicamente base de dados do
CUCM assim que eles so conectados rede. Com relao segurana essa no uma abordagem
muito segura, pois um usurio mal intencionado poder inserir um telefone qualquer e tentar utilizar a
rede para fazer ligaes indevidas.
3. Bulk Administration Tool (BAT):
Com essa opo o administrador pode criar um arquivo .csv, seguindo um template padro do
CUCM, e inserir vrios telefones de uma s vez na base de dados. Esse um mtodo bastante
eficiente de configurao de implementaes de mdio e grande porte. Tambm traz a vantagem de
se evitar erros de configurao, pois uma vez o template feito, voc tem a garantia que todos os
telefones inseridos seguiro o mesmo padro.
4. Auto Register Phone Tool (TAPS):
Com esse mtodo um servidor Interactive Voice Response (IVR) mescla e melhora as
funcionalidades de Autoregister e BAT possibilitando que voc implemente de maneira segura
milhares de telefones ao mesmo tempo. Com essa opo o operador deve ligar para um nmero
padro e responder no IVR (uma espcie de URA como em um callcenter) os parmetros para
configurar e finalizar a adio do telefone no CUCM.
Vamos a seguir analisar cada um dos mtodos citados acima, lembrando que estamos supondo que o
CUCM foi instalado e configurado para dar suporte instalao dos telefones conforme tpicos
estudados anteriormente.
Configurao Manual de Telefones
Para adicionar telefones manualmente voc deve ir interface de administrao do CUCM, em
Device > Phone. Ao clicar em Phone voc ter uma tela que poder fazer buscas ou clicando em
Add New pode adicionar um novo telefone. Vamos resumir os passos para criao do telefone,
acompanhe abaixo:
1. V em Device > Phone, e clique em Add New (vejafiguras 1 e 2 abaixo).
2. Escolha o modelo do telefone IP a ser criado a partir da lista drop-down (veja a figura abaixo).
3. Escolha o protocolo do telefone entre SCCP ou SIP(lembre que alguns telefones suportam apenas
um tipo de protocolo e no haver mais escolhas ou simplesmente no haver esse passo conforme
figura ao lado). No exemplo mostrado que tipo de telefone estamos configurando? Veja que no
campo Product Type est um Cisco IP Communicator ou CIPC que o softphone da Cisco.
4. Selecione ou entre com as informaes necessrias para o telefone. Nessa tela temos quatro
opes que no tm valores padro (default values) e precisam ser configurados manualmente (trs
delas vimos no captulo anterior):
a) MAC Address: o MAC o identificador nico que faz o vnculo entre o telefone fsico e a
configurao de software no CUCM. Para configurar um telefone de um usurio voc precisar saber
o MAC do seu telefone ou softphone (normalmente o MAC do computador onde ele est instalado)
para configur-lo corretamente. O campo que o MAC configurado chamado Device Name. Lembre
da nomenclatura para os telefones iniciando com SEP mais o MAC, por exemplo, se o MAC do
telefone 0000.0000.6100 o device name dele deve ser SEP000000006100 (veja a figura 1).
b) Device Pool: o Device Pool (como vimos nesse captulo) funciona como um template, aplicando
diversas configuraes comuns aos telefone que estejam em uma mesma localizao ou que devam
apresentar um mesmo tipo de comportamento. Na figura 1 utilizamos o device poll default ou padro
do sistema.
c) Phone Button Template: o Phone Button Template (tambm estudado anteriormente nesse
captulo) define as funes de cada boto no telefone (DNs, Speed Dials, servios e demais
funcionalidades relevantes). Note ainda na figura 1 que utilizamos o padro do sistema para o CIPC.
Caso um usurio solicite configuraes especiais, por exemplo, em seus speed dials ou recursos como
BLF (que estudaremos posteriormente) podemos copiar o phone button template padro, dar outro
nome a ele e fazer as customizaes solicitadas, a nesse campo teramos que escolher esse template
novo que foi criado em um passo anterior.
d) Device Security Profile: aplica as configuraes de segurana, conforme vimos anteriormente. Veja
a figura 2 abaixo onde escolhemos o profile padro do sistema para CICP com SCCP.
5. Clique em Save.
Quando a pgina carregada, aps voc clicar em save, um novo painel de controle chamado
Association Information aparecer na esquerda dessa tela, permitindo que voc configure funes
para os botes do telefone.
As funcionalidades bsicas, tais como Line (linha), Speed Dial, Intercom, Service so definidas no
Phone Button Template especificado anteriormente, porm aqui voc poder especificar qual o
nmero de cada linha (DN), que servios podem ser acessados ou que DN de Intercom pode ser
discado. A figura ao abaixo mostra a pgina de Phone Configuration incluindo as informaes de
Association Information na esquerda.
Em seguida devemos continuar a configurao utilizando a tela do Association Information,

conforme passos a seguir.
6. Clique na informao Line [1] - Add New DN, onde abrir uma pgina chamada de Directory
Number Information, que inclui o nmero do ramal (Directory Number DN) que voc deve digitar
obrigatoriamente e opcionalmente a Partition e outras configuraes opcionais que podem ser
configuradas.
Abaixo seguem algumas das principais opes que voc encontrar na pgina de configurao do
Directory Number (veja a figura abaixo).
Route Partition: vamos estudar no prximo captulo que a Partition ou partio parte do
controle de privilgios de chamadas do CUCM (Calling Privileges System ou Class of Control).
Alerting Name: O Alerting Name o nome que aparece no display de um telefone IP que est
chamando esse usurio. Por exemplo, usurio A tem o alerting name recepcao e o usurio B liga
para o usurio A. No visor do telefone do usurio B ir aparecer a mensagem de que ele est discando
para a recepcao. Lembre-se que alguns tipos de conexes, como a PSTN, podem no suportar essa
funcionalidade. Dependendo do status da chamada e da configurao realizada, o alerting name, DN
ou display podero aparecer no visor do telefone que est chamando, conforme descrito abaixo.
Telefone chamando: durante essa fase, o visor mostra a string configurada no campo Alerting
Name.
Chamada estabelecida: se os campos Display e Alerting Name esto configurados, aps a
ligao ser atendida, o visor do telefone chamador mostra a string configurada no campo
Display.
Chamada estabelecida: se somenteo Alerting Name foi configurado, aps a ligao ser
atendida, o visor do telefone chamador mostra o nmero de diretrio, ou seja, o DN.
Call Forward e Call Pickup: aqui onde podemos configurar o encaminhamento da chamada
quando o DN estiver ocupado (busy), no atende a ligao (no answer) ou um Call Forward All
(transferir todas as ligaes). O usurio tambm pode fazer o Call Forward All atravs do softkey
CallFwdAll ou pela pgina de administrao do telefone, chamada de User Web Page. Outras
funcionalidades como configuraes do Call Forward, tais como Busy e No Answer, estaro
disponveis apenas via User Web Page, ou seja, pela pgina de administrao do telefone que pode
ser disponibilizada ou no aos usurios pelo administrador de redes.
Display: a opo disponvel no campo Display serve como um Caller ID interno, ou seja, quando
um DN disca para outro telefone IP ele substitui o nmero chamado pelo que foi configurado na
opo Display. Por exemplo, suponha que o usurio A, DN 1000, tenha o campo Display em branco,
quando esse usurio ligar para o usurio B, o usurio B ir ver em seu visor que o DN 1000 est
ligando para ele. Agora, se o usurio A tiver o campo Display configurado com Dr. Ananias, quando o
usurio A ligar para B, o usurio B ir ver em seu visor que o Dr. Ananias est ligando.
Line Text Label: este texto define o que vai ser mostrado no telefone para descrever a linha, por
exemplo, seu softphone com o DN 6100 tem o campo Line Text Label configurado como 6100. Isso faz
com que no seu softphone, ao lado do boto em que esta linha est associada mostre o texto 6100.
External Phone Number Mask: se voc estiver fazendo uma chamada para fora da rede (off-net
normalmente para a PSTN), esse campo muda o Calling Line ID (CLID) para uma representao
conforme a numerao completa da PSTN exige ao invs do padro interno do DN.
7. Clique em Save.
8. Nos Related Links (menu drop-down direita da pgina), selecione a opo Configure Device
(<Phone>) e depois clique em Go.
9. Aps o passo 8 voc ser enviado novamente para apgina de configurao do telefone que
acabou de criar (Phone Configuration page). Aqui voc pode continuar fazendo ou alterando as
configuraes do telefone e clicar em Save novamente para salvar as configuraes realizadas at
esse momento.
Ento aparecer uma pgina avisando Click on the Apply Config button to have the changes take
effect, avisando que voc precisa clicar em Apply para que o telefone utilize essas configuraes,
forando um reload no telefone para que as alteraes sejam feitas.
Dependendo da configurao vai ser necessrio um Restart ou um Reset para aplicar as alteraes
feitas no telefone (veja a figura abaixo).
Uma configurao muito comum quando utilizamos recursos avanados, tais como o Extension
Mobility (EM) ou Cisco Unified Personal Communicator (CIPC), a de associar um usurio a um
dispositivo especfico (Device, por exemplo, um telefone IP). Quando voc deseja, por exemplo, que
um usurio tenha acesso sua User Web Page para customizar seu telefone, essa associao entre
usurio e o dispositivo ser necessria. Um usurio (End User) associado a um dispositivo (IP Phone)
e esse dispositivo associado a um ou mais DNs, permitindo que os usurios acessem suas User Web
Pages para configurar seus telefones e demais aplicaes e processos que interagem com o usurio
atravs do sistema de telefonia.
O mais interessante nisso tudo que voc pode deletar um usurio que est vinculado a determinado
DN que nada acontecer, pois, apesar dessas associao existir e ser importante, as bases de dados
so independentes. Existem trs bases distintas: User (usurio), Device (dispositivos) eDNs. Portanto
o Device e o DN no so apagados se um usurio deletado, sendo que o mesmo se aplica quando
um Device ou DN so apagados. No entanto lembre-se que tanto um telefone sem DN quanto um DN
sem telefone no podem fazer chamadas.
Mais na frente, ainda nesse captulo estudaremos com mais detalhes o que um End User no
CUCM, mas vale a pena adiantar que um telefone no CUCM no precisa pertencer a um usurio como
no sistema tradicional de telefonia. Os usurios agora podem se logar no telefone assim como
fazem em seu computador, sendo que o CUCM passa as configuraes do telefone (permisses, DN e
tudo mais) de acordo com o que foi configurado no perfil desse usurio.
Informao extra:
O Reset reinicializa tanto o firmware como asconfiguraes do telefone. Algumas alteraes como
verso de firmware, locale, SRST ou Communications Manager Group necessitam um reset
completo para que o telefone puxe um novo arquivo de configurao do servidor TFTP. Voc pode
fazer o reset a partir da pgina de administrao do telefone ou utilizando o prprio telefone teclando
no boto Settings e digitando **#** no teclado do telefone.
J com um Restart o telefone desregistrado (unregister) e depois ele volta rapidamente e se registra
novamente no CUCM. Com isso, devido ao CUCM ler a base de dados durante o processo de registro
do telefone, as informaes que no precisam ser passadas via arquivo de configuraes do telefone
so atualizadas. Informaes como alteraes de botes (Button changes), nomes, e
encaminhamento (forwarding) podem ser atualizadas apenas com um Restart. Lembre que o Restart
bem mais rpido que o Reset, isso porque no h necessidade de reinicializao de firmware.
No CUCM 7.X a confuso entre o Restart e Reset foi resolvida com a entrada do boto Apply Config.
Essa opo faz, de maneira inteligente, um reset ou restart dependendo das configuraes que foram
realizadas, ou seja, o prprio sistema escolhe o que melhor naquele caso e envia o comando ao
telefone.
Autoregistration
O recurso de Autoregistration permite que os novos telefones que so conectados rede sejam
adicionados base de dados do CUCM, permitindo que eles se registrem no sistema, inclusive eles
recebero um DN e podero fazer e receber chamadas, sendo um recurso suportado por todos os
telefones IP da Cisco.
Note que esse processo traz um risco de segurana ao sistema, pois ele permite que um usurio
qualquer traga um telefone IP qualquer (chamados de rogue phones), conecte rede e consiga
fazer ligaes internas e at para a PSTN, caso no exista nenhuma restrio. Por esse fato muitas
empresas e administradores no utilizam esse mtodo ou utilizam com muita cautela em casos
especficos para no trazer problemas de segurana para o sistema como um todo.
Agora vamos ao passo a passo para habilitar o Autoregistration:
1. Vamos verificar o protocolo de registro automtico dos telefones (Autoregistration Phone
Protocol) acessando na interface de administrao do CUCM o menu System > Enterprise
Parameters e escolher entre os protocolosSCCP (default) ou SIP. Os telefones que no suportam o
protocolo escolhido faro o registro automtico utilizando seu protocolo nativo. Veja a figura abaixo,
na realidade se voc est fazendo a configurao pela primeira vez esse parmetro j vem setado.
2. Certifique-se que pelo menos um CM Group tem oAutoregistration habilitado, selecionando

o checkbox para Auto-registration Cisco Unified Communications Manager Group (menu System >
Unified CM Group).
Veja um exemplo na figura abaixo, porm quando voc ir em System > Unified CM Group voc
cair em uma tela com os links dos grupos criados, clique no que voc vai configurar o
autoregistration e voc vai ver que a opo j est selecionada por padro.
3. Habilte e configure o autoregistration em um ou maisservidores CUCM dentro de System > Cisco

Unified CM, clicando no servidor desejado e seguindo os passos abaixo:
1. Configure a faixa ou range de DNs que sero fornecidos dinamicamente e de maneira
sequencial aos telefones registrados automaticamente. O valor padro configurado no sistema
iniciar com uma faixa de DNs (default Starting Directory Number) com o 1000. Se voc mudar
o valor do Ending Directory Number (nmero final da faixa de registro automtico para
qualquer valor acima de 1000 o Autoregistration automaticamente ativado. Ao passo que se
voc colocar os valores inicial e final iguais ele desabilitado (note que o Autoregistration est
desabilitado por default porque os valores de Starting e Ending Directory Numbers esto
configurados como 1000). Configure essa faixa de ramais (DNs) dentro de uma faixa que esteja
no seu plano de discagem e no sobreponha outras faixas para evitar confuses futuras.
2. Remover a selao do checkbox Auto-registration Disabled no Cisco Unified
Communications Manager para ativar o autoregistration, pois ele vem desabilitado por default
e ao tirar a seleo desse checkbox ele ativado. O CUCM no deixa fazer esse passo se o
range dos ramais do autoregistration no estiver definido.
3. Configure a Partition que ser utilizada pela faixa de DNs registrados automaticamente,
possibilitando que os novos telefones auto registrados possam ser controlados. Esse um
passo opcional, mas aconselhvel. Mais para frente, veremos como restringir permisses de
discagem com Partitions e CSS, sendo possvel atribuir uma Partition com poucos privilgios
para os telefones que esto no Auto-Registration.
4. Verifique mais uma vez se o checkbox Autoregistration Disabled no est selecionado no
Cisco Unified Communications Manager e clique em Save.
Veja na figura abaixo um exemplo da tela de configurao onde deixamos reservada a faixa de 1000 a
1100 para o auto registro dos telefones.
Uma maneira simples de testar plugar um novo telefone e verificar se ele faz o registro
automaticamente sendo configurado com um DN da faixa que voc configurou no sistema.
Bulk Administration Tool (BAT)
O recurso de Bulk Administration Tool (BAT) permite que faamos inseres, modificaes ou
delees em massa diretamente na base de dados. Esse importante recurso permite que um
administrador insira uma grande quantidade de telefones, usurios e outros elementos no sistema de
maneira rpida e muito mais precisa, evitando erros de entradas manuais. Alm disso, essas
inserespodem ser agendadas para serem efetuadas automaticamente em horrios mais
apropriados e sem a necessidade de um operador acompanhando essa execuo, portanto essa
ferramenta til para novas implantaes ou em ambiente operacional quando vrios telefones
precisam ser criados, alterados ou deletados da base de dados.
Conforme j mencionamos, a BAT poder incluir, alterar ou apagar a maioria dos componentes da
base de dados do CUCM, incluindo telefones, usurios, Forced Authorization Codes e Client Matter
Codes, User Device Profiles, matriz de regies (Region Matrix), dispositivos como so Gateways e
muitos outros.
Em um ambiente j implantado, na fase de operao do sistema, um recurso chamado BAT Export
(ferramenta de exportao) permite que o administrador selecione itens da base de dados e faa a
exportao deles, permitindo que esses dados sejam alterados/modificados e depois importados
novamente, j corrigidos ou atualizados, base de dados. Fazendo essas alteraes em massa (bulk
changes) torna a tarefa mais simples, rpida e menos sujeita a erros.
O template em Excel pode ser baixado diretamente do servidor CUCM e pode ser customizado para as
necessidades especficas de cada operao. Esse arquivo baixado deve ser preenchido com os dados
necessrios, de maneira correta, e enviado para o servidor como um arquivo .csv.
Utilizando a interface correta pode ser criada uma BAT apropriada para cada tipo de operao (inserir
telefones, inserir usurios, criar componentes de roteamento de chamadas e muito mais), sendo que
o administrador precisar criar um template de BAT do lado do servidor (server-side BAT Template)
para adicionar mais dispositivos, ou em alguns casos simplesmente fazer um upload do arquivo .csv
no sistema para processamento do arquivo. Se forem necessrios templates, eles definem todas as
configuraes em comum dos telefones, enquanto o arquivo .csv especifica todos os dados nicos de
cada telefone, como o DN, Line Text Label e assim por diante.
Um dos detalhes importantes sobre a ferramenta de BAT que para inserir telefones ser necessrio
o MAC addressde cada telefone a ser inserido. Existem leitores de cdigo de barras que podem ajudar
a coletar os endereos MAC e facilitar a criao das tabelas com os demais detalhes da configurao
do telefone, porm voc precisa assegurar que aquele determinado telefone seja realmente entregue
para o usurio correto conforme planejado, pois seno seu trabalho de implantao pode ser
prejudicado com telefones em mesas trocadas. No uma tarefa fcil fazer o deploy (implantao) de
centenas de telefones simultaneamente.
Podemos utilizar duas estratgias que vimos em conjunto para fazer a implantao via BAT mais
fceis, primeiro utilizando o Autoregistration para fazer com que os telefones se registrem no sistema
e depois utilizar aferramenta de BAT para modificar as configuraes dos telefones aps eles estarem
instalados nas mesas e conectados ao CUCM. Mesmo assim temos um problema a resolver, pois
precisamos ainda saber o MAC que est instalado em cada mesa para fazer a configurao correta dos
telefones via BAT, pois o vnculo do telefone no banco de dados do CUCM fsico o MAC.
Os componentes de uma BAT incluem:
Um template em Excel que fornece os campos necessrios e formatao para os dados;

Templates do servidor (server-side templates) que configuram os dados (common data);
Conjunto de pginas de web (web page interfaces) para preparao e execuo das diversas
operaes suportadas pela BAT.
Auto Register Phone Tool (TAPS)

A ferramenta chamada Auto Register Phone Tool teria uma sigla ARPT, porm era chamada
antigamente de Tool for Auto Registered Phone Support e sua sigla TAPS continuou sendo utilizada
no lugar do ARPT por ser mais simples. Essa a ferramenta mais avanada para configurao e
registro de novos telefones e recomendada para implantaes de mdio e grande porte. O TAPS vai
alm da simples automao de implantaes e sua operao est resumida nos passos ao lado.
Esta uma poderosa ferramenta e a mais aconselhvel na implementao (deploy) de alguns a
milhares de telefones IP. Com um treinamento simples os prprios usurios podem completar a
instalao dos seus telefones, sem a necessidade do envolvimento do administrador de maneira
ostensiva. O lado negativo do TAPS que ele precisa de umservidor ou hardware especfico (assim
como o software) para o IP-IVR e um administrador treinado para realizar as configuraes.
Transferir a responsabilidade para os usurios realizarem tais configuraes nem sempre possvel e
a utilizao de recursos da TI ou dos administradores de rede para tais configuraes podem significar
um uso excessivo do tempo da equipe, que normalmente reduzida. Uma alternativa a de utilizar
equipes terceiras de campo para realizar o deploy dos telefones e fazer as etapas do TAPS para
registro dos mesmos. Isso tudo cabe a uma deciso e anlise por parte da empresa tanto tcnica
como financeira.
TAPS Operao:
1. Um servidor IVR-IP (ou IP-IVR Interactive Voice Response via rede IP) deve ser ativado e
configurado para dar suporte ao TAPS, alm do mais, o servidor CUCM onde os telefones sero
instalados deve ser integrado a esse servidor de IVR. Essa funcionalidade de IP-IVR suportada por
diversas aplicaes Cisco, incluindo o Unified Contact Center Express (UCCX).
2. O administrador prapara uma BAT especificando um Device Template para todos os
componentes e configuraes em um arquivo .csv com todos os parmetros para cada telefone a ser
criado. O MAC utilizado nessa BAT no precisa ser o verdadeiro (chamado dummy MAC address),
pois ainda no sabemos que telefone ser instalado em cada posio, bastando clicar no checkbox na
interface da BAT para que ele seja substitudo pelo MAC real ao final da configurao.
3. Agora plugue os telefones na rede e eles sero auto registrados, recebendo um DN da faixa de
Auto-Registration.
4. O DN que o telefone vai receber no auto-registration no o nmero final, portanto o responsvel
pela instalao dever discar para um ramal piloto do IP- IVR (pilot number).
5. Aps isso, o IP-IVR pode pedir que o usurio se autentique opcionalmente, uma vez autenticado o
IP-IVR pede voc digite o ramal (extension DN) que aquele telefone deveria ter.
6. Quando o usurio digita o ramal planejado para aquela posio o IP-IVR grava a entrada e captura o
MAC address que aquele telefone IP possui, enviandoessas informaes ao CUCM.
7. Agora, com a informao passada pelo IP-IVR, o CUCM procura pelo ramal digitado em sua base de
dados, encontra o registro e troca o MAC falso (dummy) pelo MAC real do telefone IP, finalizando a
configurao daquele ramal em sua base de dados.
8. Para finalizar o CUCM restarta o telefone, sendo que quando ele volta em seu estado operacional
est completamente configurado com todos os detalhes especificados no registro da BAT que foi
configurada para aquele ramal.
Entendendo o Conceito de Usurios (End Users) no CUCM
Em um sistema de telefonia convencional estamos acostumados a trabalhar somente com um
telefone e um ramal, pois no importa o usurio que vai estar naquela extenso, qualquer pessoa
pode realizar uma ligao naquele telefone. Claro que podemos colocar senhas ou mtodos de
bloqueio, porm so cdigos que no podem ser integrados com outros sistemas de TI, por exemplo,
com a base de dados de um Active Directory do Windows.
Portanto, tecnicamente, um sistema de telefonia realmente no precisaria de usurios (End Users),
porm um sistema de comunicaes unificadas (Unified Communications System) consegue ir alm
do convencional e possibilita servios por grupo de usurios ou at a customizao para usurios

individuais. Isso traz uma certa complexidade do ponto de vista da administrao de rede, por outro
lado, os usurios requisitam cada vez mais simplicidades no uso do sistema. Consequentemente, a
configurao de End Users de extrema importncia para podermos prover todos os recursos do
sistema aos usurios.
O CUCM possui dois tipos de usurios que possuem uma diferena importante de ser aprendida: os
End Users e Application Users (usurios de aplicaes). A diferena simples:
Os End Users so tipicamente pessoas que precisam de um usurio e uma senha para digitar
em uma tela de login (login screen normalmente uma pgina de web) para acessar recursos
ou controles.
Um Application User normalmente uma aplicao que envia uma informao de
autenticao em srie (inline) com uma requisio de leitura ou escrita de informaes para
um sistema, por exemplo, um sistema externo de bilhetagem (billing) querendo acessar as
informaes do banco de dados de CDR/CAR.
A tabela abaixo mostra diferenas e limitaes dos End Users versus Application Users.
Poltica de Senhas (Credential Policy)

A poltica de credenciais ou senhas (menu Credential Policy) define as configuraes de
passwords (senhas),PINs dos usurios e senhas para application-user. A Credential Policy padro
para aplicaes definida na instalao do sistema vale para todos os Application Users.
Os administradores podem definir polticas adicionais e especificar detalhes como nmero mximo
de tentativas de login em caso de erro de senha ou usurio, tamanho mnimo de caracteres na senha,
tempo mnimo entre troca de senhas, nmeros de senhas anteriores que podem ser armazenadas e
tempo de vida de uma senha, alm disso, a poltica pode verificar se a senha forte ou no.
As regras bsicas para uma senha forte voc pode verificar abaixo.
As regras bsicas para uma senha forte so:
Conter pelo menos trs das quatro caractersticas a seguir: letra maiscula (uppercase), letra
minscula (lowercase), nmeros e smbolos.
No utilizar o mesmo nmero ou caractere por mais de trs vezes consecutivas.
No incluir coisas de seu dia a dia, tais como apelidos (alias), seu usurio ou o ramal.
No incluir nmeros e caracteres consecutivos.
Temos tambm regras ou diretivas parecidas para os PINs dos telefones IP (segue abaixo).
As regras bsicas para os PINs dos telefones so:
No usar nenhum nmero consecutivo por mais de duas vezes.

No incluir o usurio do correio de voz ou ramal, nem mesmo em ordem reversa.
Conter pelo menos trs nmeros diferentes (por exemplo, 121212 no vlido).
No utilizar a converso do nome para os dgitos do telefone (dial-by-name) como uma verso
do seu nome (por exemplo, Mike = 6453).
No utilizar padres repetitivos de dgitos, por exemplo, nmeros em linha no teclado do
telefone (por exemplo, 2580 ou 357).
Essas recomendaes so uma maneira de reforar a segurana das senhas dos usurios para que no
haja uma quebra de privacidade, alterao de dados indevida ou uso indevido dos recursos de
telefonia por pessoas no autorizadas, elas servem tambm para seu dia a dia.
Recursos e Interaes com as Contas de Usurios
Os recursos citados no quadro ao lado utilizam o processo de login atravs da conta de usurio (EndUser-Account login process), seja com usurio e senha ou autenticao via PIN diretamente pelo
telefone.
Pginas do Unified CM Administration
User web pages (pginas de usurio)
Serviceability
OS Administration (administrao do sistema operacional)
Disaster Recovery System (recuperao de desastre)
Cisco Extension Mobility (EM - mobilidade)
Cisco Unified Communications Manager Assistant
Directories (diretrios)
As informaes sobre as contas de usurio podem ser divididas em trs grandes categorias, com
campos especficos para cada uma delas.
1. Personal and Organizational Settings (configuraes pessoais e organizacionais):
UserID
First, Middle, Last Name (primeiro nome, nome do meio e sobrenome)
Manager UserID (ID de usurio do gerente)
Department (departamento ou setor)
Phone Number, Mail ID (nmero do telefone e identificador do correio)
2. Password Information (informaes de senhas):
Password (senha)
3. CUCM Configuration Settings (configuraes do CUCM):
PIN
SIP Digest Credentials
User Groups and Roles (grupos de usurios e funes)
Associated PCs, controlled devices e DNs (micros associados, dispositivos controlados e ramal)
Application and feature parameters (parametrizao de recursos e aplicativos - Extension
Mobility, Presence Group e CAPF)
Importante:
As contas de Application Users utilizam alguns dos atributos citados anteriormente.
User Locale e Device Association
Uma User locale (localidade do usurio) permite que voc configure diferentes idiomas para serem
exibidos no telefone IP e na pgina de usurio (User Web Page). Basicamente voc precisar:
Instalar localidades (locales) adicionais no CUCM

Os telefones precisaro fazer o download desses arquivos novos de localizao via TFTP.
Fazer a configurao das interfaces primrias dos usurios com as novas locales/idiomas.
Um Device Association (associao do dispositivo) deve ser criada para que os usurios sejam
capazes de controlar seus prprios dispositivos, por exemplo, configurar seus speed dials, servios e
preferncias de ring. Uma conta de usurio (End User account) deve ser associada ao dispositivo
tambm, pois no CUCM os End Users podem ser associados aos telefones IP, Cisco IP Communicator
(CIPC) e profiles do Cisco Extension Mobility.
Devido a conta de usurio (End User Account) precisar ser uma entrada nica (User Attribute Name)
no banco de dados do CUCM, possvel fazer uma discagem pelo nome. O Cisco Unified Presence
Server (CUPS) rastreia a disponibilidade dos usurios e suas capacidades de comunicao, tais como
voz, vdeo e chat.
Implementando End Users no CUCM
Para inserir os usurios no CUCM temos trs mtodos:
1. Manual (um a um)
2. Em massa utilizando a ferramenta de bulk administration
3. Sincronizando com o LDAP, podendo opcionalmente fazer tambm a autenticao
Vamos iniciar com a entrada manual de usurios. O banco de dados do CUCM inclui campos para
administrao das informaes dos usurios, alguns so obrigatrios e marcados com um asterisco,
abaixo seguem alguns deles:
User ID
Last Name (sobrenome)
Presence Group (o padro o Shared Presence Group grupo compartilhado)

Remote Destination Limit (limite de destinos - o padro so 4)
Os dois ltimos campos so preenchidos por padro pelo CUCM, portanto no precisamos muita
informao para criar um usurio, concorda? O User ID deve ser nico, portanto voc precisa
estabelecer um padro para os nomes, garantindo que usurios com nomes parecidos sejam
suportados pelo sistema. Uma opo colocar como User ID dados como a matrcula do funcionrio
na empresa, por exemplo, pois esse nmero deve ser nico.
Alm disso, existem outras opes nos campos de configurao dos End User, tais como senha, PIN,
Last Name, Telephone Number (nmero do telefone) e Device Association. Quanto mais usurio a
empresa possui, mais provvel que voc precisar utilizar essas outras opes para implementar mais
recursos e facilidades, melhorar a busca de informaes e retirar relatrios mais precisos do sistema,
ou ento melhorar questes de segurana.
Veja na figura 1 aobaixo um exemplo da tela de configurao do end user (User Management > End
User).Uma vez criado o usurio voc pode associ-lo a um dispositivo, conforme figuras 2 e 3.
Voc pode tambm adicionar muitos usurios de uma s vez (at milhares) utilizando a interface de
Bulk Administration Tool (BAT). Assim como vimos j nesse captulo, a ferramenta de BAT permite
que faamos o upload de um arquivo em CSV contendo a informao de diversos usurios que sero
inseridos no banco de dados do CUCM automaticamente. O BAT a maneira mais rpida de adicionar,
remover ou modificar itens do banco de dados para quase todas as partes do CUCM.
Figura 1
Figura 2
Integrao do CUCM com LDAP

O CUCM tambm suporta a integrao com o Lightweight Directory Access Protocol (LDAP).
O LDAP um padro aberto (com algumas excees significantes para alguns fabricantes) que
permite a criao de um diretrio nico e centralizado para administrar as informaes de usurios.
Ele guarda informaes como contas de usurio, senhas e privilgios, tudo isso de uma maneira
centralizada, permitindo que outras aplicaes acessem essas informaes fazendo uma centralizao
e evitando a criao de vrios repositrios com informaes de contas. Portando, utilizar o
LDAP simplifica a administrao dos usurios e torna o sistema mais leve, pois voc precisa manter
apenas um lugar para guardar as informaes e senhas dos usurios.
Um detalhe importante que apenas os End Users so replicados via LDAP Sync, os Application
users so sempre mantidos no banco de dados do CUCM.
O CUCM suporta a integrao com diversos sistemas de LDAP, alguns mais importantes citamos
abaixo:
CUCM e LDAP:
Microsoft Active Directory (2000, 2003, 2008)

Microsoft Active Directory Application Mode 2003
Microsoft Lightweight Directory Services 2008
iPlanet Directory Server 5.1
Sun ONE Directory Server (5.2, 6.x)
Open LDAP (2.3.39, 2.4)
A interao do CUCM com o LDAP pode ser de duas maneiras:

1. LDAP Synchronization (sincronizao): replica (ou insere) para a base de dados do CUCM os
usurios do LDAP com seus devidos atributos.
2. LDAP Authentication (autenticao): redireciona a autenticao da senha para o sistema LDAP
que est integrado ao CUCM.
Normalmente a sincronizao e autenticao esto habilitadas em conjunto, porm em ambos os
casos algumas informaes contidas no LDAP podem no ser configurveis no CUCM, pois os campos
ficam read-only (apenas leitura) no CUCM e podem ser editados apenas via LDAP.
Vamos a seguir analisar com um pouco mais de detalhe o processo de sincronizao e autenticao
via LDAP.
Sincronizao e Autenticao com LDAP
Fazer a sincronizao via LDAP (LDAP Sync) significa que alguns usurios (nem todos) sero mantidos
no LDAP ereplicados para a base de dados do CUCM, pois quando o LDAP Sync habilitado as contas
de usurios devero ser mantidas no LDAP e no podero ser criadas ou deletadas no CUCM, porque
conforme j mencionado os atributos do usurio mantidos pelo LDAP ficam como read-only (leitura)
no CUCM.
J os atributos que existem somente no CUCM e no existem no LDAP so configurados diretamente
no CUCM, pois eles existem apenas no banco de dados do CUCM.
Voc deve entender agora um ponto importante: mesmo com o LDAP Sync ativado, as senhas dos
usurios ainda so gerenciadas pelo banco de dados do CUCM. O que significa na prtica que a conta
de usurio replicada pelo LDAP para o banco de dados do CUCM precisa ter sua senha mantida em
ambos sistemas (LDAP Sync e CUCM), o que pode confundir e at irritar o usurio.
O CUCM utiliza o servio chamado DirSync para fazer oLDAP Sync.
Essa sincronizao pode ser configurada para rodar apenas uma vez, sob demanda ou com um
agendamento, a escolha depende do ambiente do sistema e da frequncia que as informaes do
LDAP so alteradas. Fazer a sincronizao constantemente para deixar ambos os sistema atualizados
(up-to-date information) pode gerar trfego na rede e sobrecarga nos servidores em horrios de pico,
por isso deve ser analisado com cuidado a sua necessidade.
J a autenticao via LDAP redireciona a verificao da senha solicitada do CUCM para o sistema
LDAP.
Essas senhas de contas de usurio (End-User Account) so mantidas no sistema de LDAP e no
so configuradas, armazenadas ou replicadas ao CUCM, isso porque um dos benefcios do LDAP,
principalmente para os usurios, justamente a centralizao do sistema de senhas, possibilitando o
single sign-on, ou seja, um usurio nico para entrar em qualquer sistema da empresa, o que o
mais desejado quando implementamos um sistema de autenticao via LDAP com o LDAP Sync.
No caso da autenticao via LDAP estar habilitada e oservio de LDAP falhar ou ficar inacessvel pela
rede o nico usurio capaz de se logar no CUCM ser o administrador com a conta de Application
Administrator definida na instalao do sistema.
Esse tipo de indisponibilidade do LDAP pode causar problemas drsticos para o servio de
comunicaes unificadas dependendo de como os usurios interagem com o sistema, porm, com
certeza no ser somente o sistema de telefonia IP e demais aplicaes de comunicaes unificadas
que sofrero, pois o LDAP com certeza vai parar outros servios e aplicaes de rede que tambm
dependem dele.
Consideraes sobre a Integrao do CUCM com LDAP
Um conceito importante sobre a integrao do CUCM com o LDAP que nem todos os dados dos
usurios esto na base de dados do LDAP, pois com o LDAP Sync alguns atributos so guardados no
diretrio do LDAP e replicados para a base de dados CUCM como atributos read-only. Porm, alguns
atributos ainda sero mantidos e gerenciados na base de dados do CUCM, tais como Associated
Devices, PINs, Extension Mobility Profile e outros.
J sobre o conceito da autenticao via LDAP, lembre que a senha no vai ser replicada para o banco
de dados do CUCM, pois todo o processo de autenticao redirecionado para o sistema de LDAP.
Alm dos conceitos discutidos no slide anterior, a interao do CUCM com o LDAP varia com o tipo de
implementao de LDAP e a principal preocupao dos administradores sobre qual a quantidade de
dados que precisa ser replicado durante um evento de sincronizao, resumindo:
Qual a largura de banda essa sincronizao vai utilizar da minha rede e os servidores sero
sobrecarregados com esse evento?
Por exemplo, com o Microsoft Active Directory 2000/2003/2008 voc tem uma sincronizao
completa de todos os dados de tempos em tempos, o que significa uma grande quantidade de dados
sendo sincronizada e podendo causar congestionamento na rede, alm de afetar a performance dos
servidores. Por isso, escolher um intervalo correto para a sincronizao (ou uma agenda) muito
importante para minimizar o impacto sobre a rede e servidores.
J com os demais sistemas de LDAP suportados pelo CUCM a sincronizao incremental, ou seja,
nem sempre ser necessrio sincronizar tudo novamente, por exemplo, somente os dados alterados
so sincronizados.
Essa uma propriedade que reduz consideravelmente os dados a serem sincronizados e o impacto
sobre a rede e servidores, porm essa uma deciso corporativa e depende da estratgia de cada
empresa na implementao da administrao dos usurios via LDAP.
Mapeamento de Atributos, Requisitos e Comportamento do LDAP
Os nomes dos campos dos atributos dos usurios que o LDAP utiliza so em sua maioria diferentes
dos campos equivalentes que o CUCM utiliza em sua base de dados, mas apesar disso os campos de
atributos do LDAP devem ser mapeados de forma apropriada com os atributos da base de dados do
CUCM.
Portanto, para criar um LDAP Sync agreement (um acordo de sincronismo) primeiro precisamos
identificar qual atributo de usurio do LDAP (nico) ser mapeado com um atributo de User ID no
CUCM. Por exemplo, no Microsoft Active Directory o atributo do LDAP que ser o User ID no CUCM
pode ser qualquer um dos relacionados abaixo:
Microsoft Active Directory - User ID - CUCM
sAMAccountName
uid
mail
TelephoneNumber
No importa realmente qual ser o escolhido, porm para deixar a operao mais consistente e
simples recomendado utilizar um atributo que j utilizado para realizar o login em outras
aplicaes.
Depois desse mapeamento inicial do User ID, voc pode selecionar outros atributos do LDAP e
mape-los de acordo com os campos da base de dados do CUCM. Veja a tabela abaixo com algumas
possibilidades de mapeamento que podem ser realizadas.
Sobre os requisitos e comportamentos necessrios para o LDAP Sync, sempre tenha em mente os
seguintes pontos quando estiver planejando e implementando o servio. Acompanhe abaixo:
1. O dado mapeado como atributo no LDAP de User ID juntamente ao CUCM deve ser nico (tanto no
CUCM como no LDAP). Alguns campos do LDAP permitem entradas duplicadas, porm o campo de
User ID do CUCM deve ser nico, portanto verifique esse item antes de construir seu Sync agreement
no LDAP.
2. O atributo sn (surname/last name ou sobrenome) no LDAP deve ser preenchido ou no haver
replicao desse registro para o CUCM.
3. Se o atributo do LDAP que est mapeado com o atributo User ID do CUCM conter dados iguais aos
j existentes para um Application User do CUCM essa entrada ser descartada e no ser importada
para a base de dados do CUCM.
LDAP Sync Agreements (Acordos de Sincronizao)
Vimos anteriormente o termo LDAP Sync agreement, porm o que ele faz realmente?
Resp: Ele define que parte do diretrio do LDAP ser utilizada pelas contas de usurio.
Muitos sistemas de LDAP tm uma estrutura organizada com diferentes campos e funes,
departamentos, localizaes ou privilgios, e a que o synchronization agreement entra,
especificando em que ponto dessa rvore a busca por contas de usurio deve iniciar.
Portanto o CUCM ter acesso ao conteiner (campos)especificado no acordo, bem como a todos os
nveis inferiores que esto nessa rvore de diretrio, nunca podendo iniciar por nveis superiores ou
atravs das ramificaes dessa rvore, ou seja, pode acessar somente daquele ponto para baixo da
rvore.
O acordo ou agreement pode especificar a raiz do domnio, mas apesar de simples faz com que a
busca seja feita por toda estrutura do LDAP, o que pode trazer como resultado contas no desejadas
ou um nmero muito grande de contas.
Mecanismos de Sincronismo e Filtros Customizados
O LDAP Sync agreement (acordo de sincronizao)especifica quando comear a sincronizao e
quando repetir a sincronizao, atravs de uma agenda (schedule). possvel fazermos uma
sincronizao nica, porm no usual, pois os usurios entram e saem da rede conforme a
movimentao de recursos humanos da empresa.
Quando acontece a primeira sincronizao os seguintes eventos ocorrem. Veja abaixo:
Eventos na primeira sincronizao:
1. Todas as contas de usurio (end-user accounts) no banco de dados do CUCM so desativadas
(no so deletadas!).
2. Contas que esto criadas no CUCM com User ID exatamente igual ao do LDAP so reativadas e
nenhuma configurao do LDAP aplicada ou atualizada na base de dados do CUCM.
3. Contas que existem apenas no LDAP so criadas no CUCM.
4. Quaisquer contas que permaneam desativadas e no existem no LDAP so apagadas da base
de dados do CUCM aps 24 horas.
Alm disso, podemos criar filtros customizados para o LDAP (Custom Filters). O comportamento
padro do LDAP Sync de importar todas as contas de usurios a partir de um ponto inicial para baixo
da rvore do diretrio, o que pode causar a importao de contas que no deveriam ser importadas.
Utilizando um filtro personalizado o administrador podelimitar as contas que sero importadas, por
exemplo, importando somente contas no campo Organizational Unit (OU) um determinado valor
especfico. Se o filtro for alterado uma sincronizao completa do LDAP dever ser realizada para que
essas mudanas tenham efeito.
Configurando o LDAP Sync e Ativando o DirSync
Configurar o LDAP Sync relativamente simples, porm a grande dificuldade normalmente
entender a estrutura do LDAP, saber quais dos containers possuem os usurios que devem ser
importados e onde iniciar a busca pelos usurios dentro do LDAP.
Para configurar o LDAP Sync devemos seguir os seguintes passos:
1.
2.
3.
4.
Ativar o servio Cisco DirSync (na interface de Serviceability).

Configurar o sistema de LDAP.
Configurar o diretrio do LDAP.
Configurar os filtros customizados para refinar busca pelos usurios no LDAP.
Para que o CUCM seja capaz de acessar e buscar os usurios no LDAP necessrio que seja criada
uma conta para o CUCM dentro do LDAP. As configuraes e a conta podem variar dentro de cada
sistema de LDAP, mas normalmente basta criar uma conta de usurio com permisso de leitura na
base de dados de busca.
Para ativar o DirSync voc precisa utilizar a aplicao deServiceability, indo em Tools > Service
Activation, depois ir na lista drop-down de servidores e escolher o Publisher (caso haja mais de um
servidor em cluster). Aps isso, encontre o servio Cisco DirSync, clique no checkbox para selecionar o
servio e clique em Save. Veja um exemplo na figura abaixo:
Configurando o LDAP System

Abaixo seguem os passos para configurar o LDAP Sync no CUCM:
1. V na interface de Unified CM Administration, no menu System > LDAP > LDAP System.
2. Selecione o checkbox para habilitar a sincronizao via LDAP (Enable Synchronizing from LDAP
Server).
3. A partir do item LDAP Server Type (menu drop-down) escolha o tipo de sistema LDAP que o
CUCM ir se sincronizar.
4. Do campo LDAP Attribute for User ID (menu drop-down), selecione qual atributo do LDAP
ser mapeado como User ID no CUCM.
5. Clique em Save.
Veja um exemplo na figura ao lado da pgina de configurao do LDAP System nas figura 1 e 2 abaixo:
Figura 1
Configurando Diretrio (LDAP Directory)

Para configurar o diretrio LDAP voc deve seguir os seguintes passos abaixo:
1. Utilizar a interface Unified CM Administration indo em System > LDAP >LDAP Directory.
Ao clicar nessa tela voc receber dois avisos, basta clicar em OK nos dois.
2. Digite o nome do LDAP Sync agreement no campo LDAP Configuration Name.
3. Digite o usurio e a senha que o CUCM vai utilizar para acessar o LDAP.
4. Defina o User Search Base, o qual deve utilizar a sintaxe completa do caminho no LDAP (por
exemplo, ou=Users,dc=Pod1,dc=com).
5. Ajuste a agenda de sincronizao (synchronization schedule).
6. Especifique os campos de usurio que sero sincronizados com o LDAP (user fields to be
synchronized), mapeando os campos do CUCM com os campos do LDAP.
7. Digite pelo menos um IP de um servidor LDAP, podendo ser no mximo trs endereos para
redundncia. Utilize SSL para dar mais segurana ao processo do LDAP Sync, o qual necessita de
uma configurao similar ao do LDAP system.
Veja a figura abaixo com um exemplo da pgina configurao do LDAP Directory.
Verificando o LDAP Sync:

Para verificar se o LDAP Sync estr funcionando basta fazer uma busca rpida por End Users no
CUCM. Uma vez realizada a busca, na coluna abaixo do LDAP Sync Status os usurios estaro
listados como Active (ativo) ou Inactive (inativo), sendo que pode haver novos usurios vindos do
diretrio LDAP, porm caso eles tenham sido criados previamente no CUCM no iro aparecer (veja o
tpico anterior).
Usurios ativos so os que foram passados via o processo de sincronizao com o LDAP, j
os inativos sero apagados em 24h se no forem criados no LDAP e o sistema seja novamente
sincronizado.
Conforme j estudamos, o que ocorre quando abrimos um a pgina de configurao de um usurio
que foi sincronizado pelo LDAP?
Os campos sincronizados via LDAP no podem ser editados, portanto veremos que os campos User ID,
Last Name, Middle Name, Telephone Number, Mail ID, Manager User ID e Department no podero
ser editados no CUCM, pois eles esto sendo administrados no sistema de LDAP e somente por l
podem ser alterados, seno viraria uma verdadeira baguna.
Configurando a Autenticao (LDAP Authentication)
A configurao do CUCM para redirecionar a autenticaodos usurios para o sistema de LDAP
normalmente realizada quando estamos fazendo a integrao do LDAP. No comum sincronizar
todos os usurios e ainda manter uma senha separada para eles no CUCM.
Para configurar o LDAP authentication siga os seguintes passos:
1.
2.
3.
4.
Ir em System > LDAP > LDAP Authentication.

Clicar na caixa Use LDAP Authentication for End Users.
Especificar uma conta e senha para o CUCM acessar o sistema de LDAP.
Especificar a base de usurios no LDAP (User Search Base).
5. Definir o IP do servidor de LDAP, lembrando que podem ser at trs para redundncia.
6. Clique em Save e est finalizado.
Na figura abaixo temos uma pgina de exemplo da configurao da autenticao via LDAP.
Verificando o LDAP Authentication:

Agora, assim como para o tpico anterior, podemos verificar se a autenticao via LDAP est
funcionando abrindo uma pgina de configurao de usurio (user configuration page) e observando
se o campo Password foi removido, pois agora a senha mantida no LDAP e no mais na base de
dados local do CUCM. O usurio pode testar a autenticao via LDAP trocando sua senha no sistema
de LDAP, com isso o CUCM ir pedir uma nova senha para executar o login.
Lembre que o PIN do usurio mantido localmente na base de dados do CUCM, assim como todos os
atributos especficos dele.
Criando Filtros Customizados (LDAP Custom Filters)
Para criar filtros customizados no LDAP (Custom Filters) voc deve ir em System > LDAP > LDAP
Custom Filter, depois clicar em Add New e na pgina de configurao do filtro especificar um
nome para ele.
No campo do filtro (Filter field) digite o comando de filtragem (filter statement), o qual deve estar
entre parnteses ( ). Vejam alguns exemplos abaixo, lembrando que a sintaxe dos filtros segue a
RFC 4515, LDAP: String Representation of Search Filters (representao de caracteres de busca
atravs de filtros no LDAP).
(cn=Edson Arantes)
(!(cn=Edson Arantes))
(&(objectClass=Person)(|(sn=Arantes)(cn=Edson E*)))
(givenName=John)
Na pgina da Cisco sobre a configurao do LDAP podemos encontrar mais alguns exemplos de filtros
por tipo de LDAP (so filtros aplicados por default) conforme abaixo:
- Microsoft Active Directory (AD):

(&(objectclass=user)(!(objectclass=Computer))(!(UserAccountControl:1.2.840.113556.1.4.803:=2)))
- iPlanet or Sun One LDAP Server:
(objectclass=inetOrgPerson)
- OpenLDAP:
(objectclass=inetOrgPerson)
- Microsoft Active Directory Application Mode (ADAM):
(&(objectclass=user)(!(objectclass=Computer))(!(msDS-UserAccountDisabled=TRUE)))
Veja a pgina de configurao dos filtros customizados na figura abaixo:
Fluxo de Chamadas
Conforme comentamos na introduo o entendimento do fluxo de chamadas em um ambiente de
grande porte tendo o CUCM como agente processador de chamadas pode ser uma tarefa rdua.
Nosso objetivo aqui introduzir esse conceito de forma que ao final desse tpico voc seja capaz de
ter um entendimento bsico sobre o assunto e seja capaz de realizar implementaes ou manuteno
(troubleshooting) que no possuam um alto grau de complexidade.
Vamos analisar alguns cenrios e durante a anlise explicar alguns conceitos importantes.
CUCM x DNS
De maneira geral podemos dizer que o uso do DNS (Domain Name System) no recomendado para
uso com telefones IP Cisco. Caso o DNS esteja sendo utilizado, o telefone IP dever primeiro
completar o processo de resoluo de nomes do DNS para aprender o endereo IP do CUCM antes de
poder realizar qualquer tipo de processo de sinalizao. Na melhor das hipteses isso introduzir
umdelay na rede, na pior das hipteses isso introduz a possibilidade de erros de configurao e/ou
falhas no sistema de DNS que podem acarretar na interrupo do servio de voz em sua rede.
De qualquer forma, to logo o processo de resoluo de nomes do DNS seja completado o fluxo de
chamada consistir em sinalizao (via SCCP ou SIP) entre o telefone IP e o CUCM e voz (via RTP Real
Time Protocol) diretamente entre os telefones. A figura 1 abaixo ilustra esse cenrio.
Atente para o fato de que os telefones IP no trocam sinalizaes entre si (pois a sinalizao
trocada entre o telefone IP e o CUCM) e tambm que nenhum fluxo de voz trfega entre o CUCM e o
telefone IP (pois o fluxo de voz estabelecido diretamente entre os telefones IP via RTP).
Em um cenrio onde no utilizamos o DNS o fluxo das chamadas bem similiar, eliminando apenas o
processo inicial de resoluo de nomes. Observe na figura 2 abaixo um cenrio sem a utilizao do
DNS.
A sinalizao continua sendo trocada entre os telefones IP e o CUCM, via SCCP ou SIP. O fluxo de voz
continua trafegando diretamente entre os telefones IP via RTP.
Informao extra:
Aqui vale ressaltar uma exceo a ltima regra que citamos. Quando o CUCM atua como processador
de conferncia de voz, o fluxo de voz de todos os participantes da conferncia vo at o CUCM, onde
so combinados e retornam para os participantes, de forma que todos os participantes da conferncia
recebem a combinao de todos os fluxos de voz menos o seu prprio.
Para retirarmos o DNS bem simples. Uma instalao padro do CUCM lista o host name na base de
dados utilizada pelo arquivo de configurao do telefone para identificar o CUCM no qual o telefone
dever tentar se registrar. Para alterarmos esse valor devemos seguir os seguintes passos:
1. No CUCM Administration, navegue at "System Server".
2. Selecione o servidor e na sua pgina de configurao altere o campo host Name/Ip Address
para o endereo IP do servidor.
3. Clique em Save
4. Repita o processo para todos os servidores existentes.
Em seguida, navegue at System Enterprise Parameters, procure pela seo Phone URL
Parameters e em cada campo, altere o hostname para o IP do servidor.
Importante: Apesar da eliminao do DNS seja recomendada existem certas circunstncias onde seu
uso til, como por exemplo, na alterao do esquema de endereamento IP (quando o hostname
permanece o mesmo e somente o IP ser alterado). Tambm na integrao do CUCM com o CUPS o
servio DNS necessrio, apesar disso no afetar os hardphones IP. Seja qual for o caso, sempre que
utilizarmos DNS a sua manuteno e operao deve ser feita com muito cuidado, pois uma falha no
servio de DNS pode causar a interrupo dos servios de voz na sua rede VoIP.
Fluxo de Chamada em Ambiente Centralizado

Em uma topologica centralizada os servidores CUCM esto localizados no site principal, com um ou
mais sites remotos conectados via rede IP WAN.
Nesse ponto interessante fazer um pequeno parentses para explicarmos dois conceitos
importantes: chamadas on-net e off-net. Basicamente dizemos que uma chamada on-net quando
ela flui por dentro da rede IP, de um telefone IP para outro telefone IP. J uma chamada off-net so
aquelas que saem da sua rede IP para a rede de telefonia pblica PSTN, ou seja, uma chamada off-net
estabelecida entre um telefone IP da sua rede e um outro telefone qualquer que no esteja na sua
rede.
Dito isso, em nosso ambiente com o CUCM centralizado, do ponto de vista do site remoto, os
telefones IP utilizaro a rede WAN IP para passar tanto a sinalizao quanto ofluxo de voz quando
estiverem realizando uma chamada on-net, ou seja, por dentro da rede. J para o caso de uma ligao
off-net, dependendo do design utilizado, a ligao poder ser roteada atravs do gateway do site
remoto ou atravs do gateway do site principal.
A sinalizao e o fluxo de voz seguem o mesmo princpio visto anteriormente, ou seja, a sinalizao
trocada entre os telefones IP e CUCM (via SCCP e SIP) e o fluxo de voz enviado diretamente entre
os telefones IP via RTP. O nico detalhe que como estamos em um ambiente centralizado, a
sinalizao ou o fluxo de voz dos sites remotos iro utilizar a rede WAN IP para enviar essas
informaes. Veja figura abaixo:
No caso de uma ligao entre dois telefones IP do mesmo site remoto, a sinalizao ser enviada
via rede WAN IP para o CUCM e o fluxo de voz RTP ficar dentro da prpria rede do site remoto.
Backup via PSTN

Acabamos de ver que em um ambiente centralizado a rede WAN IP poder ser utilizada tanto para
troca de sinalizao entre os telefones IP e o CUCM como tambm para o fluxo de voz. Mas e o que
acontece no caso de uma falha na rede WAN? Nesses casos a funcionalidade de voz estaria
comprometida, pois os telefones IP dos sites remotos perderiam a conectividade com o CUCM e
parariam de funcionar.
Para contornar essa situao, nos eventos de falha da WAN existe a funcionalidade
de SRST (Survivable Remote Site Telephony ou modo de sobrevivncia) que fornece a funcionalidade
de registro e controle de chamadas locais para os telefones. O SRST capaz de dar suporte s
chamadas on-net entre os telefones IP dentro do mesmo site, no entanto, chamadas para fora do
site (on-net ou off-net) no so suportadas, uma vez que falta no gateway remoto configuraes para
o roteamento de chamadas.
Por isso, normalmente no gateway remoto tambm habilitado o CUCME para prover acesso rede
de telefonia pblica PSTN. Se o roteador SRST/CUCME tem um route-plan configurado
apropriadamente, os usurios do site remoto podero continuar utilizando o mesmo padro de
discagem utilizado no CUCM para realizarem chamadas on-net que o roteador SRST/CUCME realiza a
manipulao de dgitos para rotear essa chamada para a PSTN de forma transparente para o usurio,
ou seja, ele no ir perceber que a rede WAN falhou.
Para ilustrar essa situao vamos a um exemplo hipottico. Suponha que temos a topologia mostrada
ao lado, onde os usurios do site A possuem os ramais 3045-78XX e os usurios do site B possuem
ramais na faixa 3045-79XX. Vamos supor tambm que o plano de discagem foi desenhado de forma
que todos podem fazer ligaes entre ramais utilizando apenas os ltimos 4 dgitos, ou seja, quando o
usurio do site A quer falar com o usurio do site B basta discar para, por exemplo, 7910 que o
chamada ser encaminhada para o telefone 3045-7910.
Agora vamos imaginar que houve uma falha na rede WANdo site A e os telefones no podero mais
se registrar no CUCM central, pois o site A est sem conectividade com a rede IP, e tambm no ser
mais possvel a realizao de chamadas on-net (por dentro da rede). Para contornar essa situao
podemos habilitar o SRST/CUCME nos gateways remotos para dar suporte aos telefones IP nos casos
de falha da rede IP. Nesse caso, todas as ligaes devero ser roteadas para a rede PSTN (off-net), j
que a rede WAN est fora.
S que os usurios no querem saber se a rede est fora ou no, muitas vezes eles nem mesmo
sabero como identificar esse fato. O que eles querem continuar o usuando o telefone como de
costume, ou seja, os usurios do site A querem discar 79XX para falar com os usurios do site B.
Mas como agora o site A est sem conectividade com a rede WAN e todas as ligaes devero sair via
PSTN ser necessrio implementar uma manipulao de dgitos no gateway do site A para possibilitar
que os usurios continuem discando 79XX e, de forma transparente ao usurio, o gateway acrescenta
o prefixo 3045 aos nmero discado pelo usurio. Dessa forma o usurio disca 7910 e o roteador
manda para a PSTN 30457910. A PSTN cuida de encaminhar essa ligao at o gateway do site B, que
por sua vez, encaminha a ligao para o DN 7910.
Tudo isso feito de forma transparente para o usurio. Imagine que voc tivesse que explicar para
todos os usurios que quando a rede WAN est ok eles devem discar 79XX, quando houver falha na
rede WAN IP a eles devem discar 0 para pegar uma linha externa e depois 304579XX, isso seria um
enorme transtorno, no acha? Por isso extremamente recomendado que nos ambientes com CUCM
centralizado os sites remotos sejam equipados com a funcionalidade SRST/CUCME nos roteadores e
que seja implementada a manipulao de dgitos necessria para que o sistema continue operando de
forma transparente para o usurio nos eventos de falha da rede WAN IP.
Bem, tudo o que comentamos at agora possibilita que o site A, em uma situao de falha da rede
WAN IP do site A, continue fazendo ligaes para os telefones IP dos outros sites. Mas e se algum do
site B tentar ligar para um usurio do site A? Ser que do jeito que est essa ligao ser completada?
A resposta no!!!
Isso porque do ponto de vista do CUCM (e dos outros sites que esto operando via CUCM) o site A
est fora do ar, sem conectividade. No CUCM todos os telefones do site A estaro no registrados e
sero considerados inalcanveis, pois os telefones IP do site A agora esto registrados no gateway
SRST (roteador com o modo de sobrevivncia configurado nele). Ento se algum do site B tentar ligar
para o site A o CUCM vai informar ao site B que o telefone que ele est tentando chamar no est
registrado.
No entanto no bem verdade que os telefones IP do site A esto inalcanveis. Eles esto
inalcanaveis via rede IP, mas continuam sendo alcanveis via PSTN. Ento devemos configurar no
CUCM opes de roteamento para prover um caminho alternativo, via PSTN, aos telefones dos sites
remotos para quando estivermos efrentando situaes de falha na rede WAN dos sites remotos.
O plano de roteamento de chamadas no CUCM (dial plan) deve ter uma segunda opo via
PSTN e tambm a manipulao de dgitos necessrias para que o nmero discado possa ser
corretamente entregue PSTN.
Os telefones IP dos sites remotos devem ter a opoCall Forward UnRegistered
(CUFR) configurada especificando o nmero completo no padro da PSTN que torna possvel
alcanar esse ramal.
Essas duas configuraes no CUCM em conjunto com o SRST/CUCME nos gateways remotos tornam
possvel que os telefones IP dos sites remotos continuem operando, fazendo e recebendo ligaes,
nos eventos de falha da rede WAN. Quando a conectividade com a rede WAN retorna, os telefones IP
se de-registram do gateway SRST e registram novamente no CUCM, voltando a operar de forma
normal.
Consideraes e Limitaes
Topologias com o CUCM centralizado a forma mais de comum de encontrarmos na prtica. Esse
tipo de topologia capaz de prover funcionalidade completa aos telefones localizados tanto no site
central quanto nos sites remotos e tambm traz a vantagem de termos um ponto central de controle,
de forma que podemos concentrar os esforos de operao/manuteno no site central. No entanto
alguns pontos devem ser levandos em conta ao optarmos por uma topologia centralizada.
O CUCM suporta um mximo de 1000 locations, ou seja, 1000 sites remotos. Tambm um nmero
mximo de 1100 gateways (H.323 ou MGCP) suportado por cluster.
Apesar do CUCM no limitar o nmero de telefones IP nos sites remotos, o nmero de telefones IP
suportados emSRST limitado pelo hardware do gateway remoto e pela configurao aplicada. Veja
as tabelas comparativas abaixo (figuras 1 e 2).
O QoS deve ser corretamente aplicado na WAN de forma a prover prioridade para os pacotes de voz
e limitar o delay para o fluxo RTP e sinalizao de voz.
Um esquema de Controle de Admisso de Chamadas (CAC) tambm deve ser implementado, seja
via CUCM Location-Based ou RSVP (Resource Reservation Protocol). Seja qual o for o esquema
utilizado, o objetivo garantir que somente um nmero determinado de chamadas possam ser
estabelecidas via WAN, evitando uma possvel queda na qualidade das chamadas e at mesmo
desconexes de chamadas. Veremos um pouco mais sobre o CAC logo a seguir.
CAC Call Admission Control

O CAC est diretamente ligado a qualidade de servio na sua rede VoIP. O CAC tem como
objetivo prevenir que ligaes IP sejam estabelecidas via WAN se a largura de banda estipulada para
ligaes IP pelo seu esquema de QoS foi ultrapassada.
Por exemplo, suponha que seu esquema de QoS permita um mximo de 15 chamadas IP via WAN
utilizando G.729. Nesse caso sua configurao de QoS ir criar uma fila prioritria (LLQ) dimensionada
para essas 15 ligaes. Caso uma 16 ligao seja estabelecida, a largura de banda reservada ser
ultrapassada e isso ir fazer com que os pacotes dessas 16 chamadas comeem a dropar, causando
perda de pacotes e consequentemente deteriorao da qualidade da voz nessas 16 chamadas.
Com a implementao do CAC via CUCM Location-Based (baseado na localidade), o CUCM monitora
cada ligaode um determinado site (location) subtraindo a largura de banda de cada ligao da
largura de banda total reservada para esse site. Quando a largura de banda restante for menor do
que a largura de banda necessria para mais uma ligao (o que varia de codec para codec), o
comportamento padro do CAC descartar essa ligao, enviando um tom de reordenao (reorder
tone) para o usurio ou uma mensagem informando que a ligao falhou.
Mas simplesmente descartar a ligao por no haver mais banda disponvel pode no ser a melhor
alternativa, pois apesar de no haver banda disponvel para se fazer a ligao on-net ainda podemos
implementar uma maneira de fazer essa ligao via PSTN. Isso feito com o recurso de AAR
(Automated Alternate Routing Roteamento Alternativo Automtico) que tem o objetivo de
redirecionar a chamada via PSTN.
Em outras palavras, o CAC ir impedir que chamadas adicionais sejam feitas via rede WAN IP no caso
de no haver banda disponvel e o AAR ir fornecer um caminho alternativo, via PSTN, para essas
chamadas que foram impedidas pelo CAC de serem estabelecidas via IP WAN. Toda vez que o CAC
impedir uma chamada de ser estabelecida via WAN, o CUCM verifica se existe um AAR Group
configurado para esse site/telefone. Caso exista, o AAR Group ir realizar a manipulao de dgitos
necessria para fazer o encaminhamento dessa chamada via PSTN. Tudo isso feito de forma
transparente ao usurio.
Nesse ponto muito importante que voc perceba a diferena entre o encaminhamento das
chamadas via PSTN no caso de falha na WAN versus o encaminhamento das chamadas via PSTN
devido ao CAC e AAR. No caso de falha da WAN as chamadas sero encaminhadas via PSTN devido ao
plano de discagem e CFUR (Call Forward Unregister desvio de chamada quando o telefone no est
registrado no CUCM) no CUCM e tambm devido ao SRST implementado no site remoto. Agora se a
WAN no tem recurso suficiente para aceitar mais chamadas de voz via IP, o CAC aciona o AAR, que
realiza a chamada via PSTN, fazendo toda a manipulao de dgito necessria para que essa ligao
seja entregue a PSTN de forma apropriada.
Fluxo de Chamada em Ambiente Distribuido
Em uma topologia com o CUCM distribuido, um cluster CUCM sinaliza para outro cluster CUCM
atravs da WAN. Quando um usurio est fazendo uma chamada, asinalizao trocada entre o
telefone IP local (calling quem est fazendo a ligao) e seu CUCM local, ento o CUCM local envia a
sinalizao para o CUCM remoto atravs da WAN, esse por sua vez envia a sinalizao para o telefone
IP (called quem est recebendo a ligao). J ofluxo de voz RTP trocado entre cada um dos
telefones IP (calling e called) atravs da WAN. A figura ao lado exemplifica esse cenrio.
Os protocolos de sinalizao existentes nesse cenrio incluem o Inter-Cluster Trunk (ICT), H.323 e SIP
(Session Initiation Protocol). Os CUCM de cada site controlam seus prprios telefones IP via SIP ou
SCCP. A utilizao de gatekeepers aliado a um bom projeto de plano de discagem permite a
escalabilidade para milhares de sites, podendo ser tanto com CUCM dedicados para sites muito
grandes como tambm soluo de CUCME para sites de menor porte. A contingncia via PSTN em
caso de falha da WAN e CAC-Gatekeeper tambm podem ser utilizada, tudo dependendo de um
projeto adequado para cada situao.
Informao extra:
O CAC Location-Based visto no ambiente centralizado no funciona para ambientes com CUCM
distribuidos. Isso porque um cluster no consegue passar para o outro cluster a sua quantidade de
banda disponvel para ligaes de voz sobre IP. J o gatekeeper CAC fornece uma soluo centralizada
para monitorar a largura de banda entre os clusters e ativar o AAR quando for necessrio.
Um gatekeeper nada mais do que uma feature do IOS que pode ser habilitada em um ou mais
roteadores atuando como gateways na sua rede. Segundo a Wikipedia o gatekeeper um
componente de rede opcional que centraliza os pedidos de chamada e gerencia a banda empregada
pelos participantes para evitar que sobrecarreguem a rede com taxas de transmisso muito elevadas.
Introduo ao Plano de Discagem no CUCM (Dial-Plan)
Os elementos que fazem parte de um plano de discagem no CUCM so simples e consistentes. A
complexidade vem quando implementamos planos de discagem com mltiplos caminhos para
encaminhamento de chamadas, com recursos e capacidades mais avanadas.
Nesse tpico iremos identificar os principais elementos utilizados em um plano de discagem e
entender como um interage com o outro. O objetivo tomarmos conhecimento sobre o seu
funcionamento, sem se preocupar com detalhes mais aprofundados sobre o tema, pois como j
comentamos, isso ser foco de estudo do CCNP Voice.
Primeiro vamos aprender quais os elementos podem agir como "origem" e "destino" para o
roteamento de chamadas.
Origens de Roteamento de Chamadas no CUCM
No CUCM uma requisio de roteamento de chamadas (incluindo, mas no limitado a uma simples
chamada telefnica) pode ser originada a partir de uma das seguintes fontes. Veja abaixo:
Origem de Roteamento de Chamadas
Telefone IP: Realiza uma chamada a partir de uma de suas linhas. Pode ser via discagem manual,
speed dial ou um boto do softkey.
Trunk: Sinaliza chamadas de entrada de outro cluster CUCM, CUCME ou qualquer outro agente de
chamada.
Gateway: Sinaliza chamadas de entrada vindas da PSTN ou outro agente de chamada, como por
exemplo, um PABX.
Translation Pattern: Quando existe a correspondncia do nmero discado com alguma translation
pattern, essa translation pattern imediatamente transforma esse nmero discado em uma nova string
(conjunto de caracteres). Essa nova string ento submetida para anlise de dgitos e roteamento.
Voicemail port: Pode ser a fonte de um pedido de roteamento de chamada se a aplicao tenta uma
chamada, transferncia ou notificao de mensagem em nome da caixa de correio de um usurio.
Uma requisio de roteamento de chamadas nada mais do que uma das entidades citadas
sinalizando o CUCM com uma string de dgitos discada. Esses dgitos podem ter sido discados
manualmente em um telefone IP, automaticamente por alguma aplicao como o Cisco Unity
Connection ou por algum outro sistema via um tronco ou gateway.
Destinos de Roteamento de Chamadas no CUCM
Da mesma forma que temos algumas entidades que podem originar uma requisio de roteamento
de chamadas temos tambm as entidades que podem ser o destino dessas requisies.
Todas essas entidades so representadas atravs de umastring de dgitos discveis. O plano de
discagem deve alocar faixas de nmeros para cada uma dessas entidades e o CUCM deve ser
configurado para rotear as chamadas corretamente para cada um desses destinos (incluindo no
rotear a chamada para um determinado destino quando isso no for permitido).
Destino de Roteamento de Chamadas
Directory Number (DN): Cada boto em um telefone IP pode ser configurado com uma nica linha
(DN).
Translation Pattern: Faz a correspondncia dos dgitos discados e os transforma em uma nova string
de dgitos, que ento submetida para a anlise de dgitos e roteada (encaminhada) para outro alvo.
Route Pattern: Faz a correspondncia com um conjunto de dgitos discados e aciona o processo de
roteamento de chamadas que pode incluir um ou mais caminhos, fornecendo uma topologia
hierrquica de roteamento de chamadas.
Hunt Pilot: Um padro especfico de digtos que quando correspondido aciona uma chamada
customizvel no sistema.
Call Park Number: um nmero ou uma faixa de nmeros que o CUCM utiliza temporariamente para
colocar em espera uma chamada at que o usurio disque o nmero do call park para ento atender a
ligao em um telefone IP.
Meet-me Number: o usurio iniciador da conferncia disca para o nmero meet-me para comear
uma conferncia, ento os demais participantes, discam para esse mesmo nmero para ingressar
nessa conferncia.
Elementos de Configurao de Roteamento de Chamadas no CUCM
Os principais elementos de configurao de roteamenteo de chamadas no CUCM so os mostrados
ao lado.
Vamos a seguir ver um pouco sobre cada um deles...
Elementos de Configurao de Roteamento de Chamadas
Route Patterns
Route Lists
Route Groups
Gateways/Trunks
Route Pattern
O Route Pattern utilizado para enviar chamadas paradestinos externos ao CUCM como Gateways e
outros clusters. Em outras palavras podemos dizer que se no houver nenhum Route Pattern
configurado no seu CUCM, os telefones IP desse CUCM s podero realizar chamadas entre si, no
sendo possvel alcanar nenhum destino exterior ao CUCM.
Um Route Pattern corresponde a uma sequncia de dgitos discados. O Route Pattern pode
ser especfico, correspondendo a um nico nmero discado, ou pode sergenrico, correspondendo a
centenas de milhares de possveis nmeros. O uso de dgitos curinga (wildcards digits) dentro do
Route Pattern possibilita configurar uma faixa de nmeros que podem ser alcanados. Os Route
Patterns permitem que o administrador do sistema especifique o alvo correto para cada padro de
dgito discado no sistema.
Uma das principais utilizaes dos Route Patterns prover acesso rede PSTN. Para que os telefones
IP registrados em um CUCM consigam realizar chamadas para a rede PSTN, ou seja, discar para algum
nmero de fora da rede, necessrio que sejam configurados Route Patterns especficos que
informem ao CUCM que: Quando um determinado usurio discar esse padro de dgitos essa ligao
deve ser encaminhada para a PSTN. Outra aplicao tambm muito comum para integrar o plano
de discagem do CUCM com um sistema j existente de PABX, sendo necessrio que o Route Pattern
pegue a toda a faixa de nmeros controlado pelo PABX.
Acompanhe na figura abaixo um exemplo de um Route Pattern que d acesso aos telefones IP
registrados no CUCM a fazerem ligaes que correspondam com o padro de
dgitos 0.XXXXXXXX tendo como gateway de sada o roteador com o IP 192.168.1.6. Para acessar a
tela de criao de Route Pattern no CUCM Administration "Call Routing > Route/Hunt > Route
Pattern" (figura 1). O padro 0.XXXXXXXX ir permitir ligaes locais, seja para fixo ou celular, sendo
o 0 para pegar linha externa e mais 8 dgitos (XXXXXXXX) - figura 2.
Na verdade, um Route Pattern pode ser customizado para permitir aos usurios discar para qualquer
nmero e alcanar qualquer fonte desejvel. Os Route Patterns so associados a um Route List ou a
um Gateway especfico.
Importante:
Quando um Route Pattern est diretamente associado a um gateway especfico (e no a um Route
List) esse gateway no pode mais ser utilizado em nenhum Route Group (veremos mais para frente).
Ou seja, como se o gateway ficasse preso a esse Route Pattern e no pudesse mais ser utilizado em
nenhum outro Route Group. Para ambientes de pequeno porte isso no acarreta nenhum problema,
mas em ambientes de grande porte isso pode trazer limitaes na flexibilidade do sistema.
Route List
Vimos no tpico anterior um exemplo de um Route Pattern 0.XXXXXXXX apontando para o gateway
192.168.1.6. Esse Route Pattern faz com que toda vez que o usurio digite um nmero nesse padro,
por exemplo, 030457810, essa chamada encaminhada atravs do gateway 192.168.1.6.
Se vocs repararem na tela do exemplo anterior (veja figura abaixo) o campo onde configuramos o IP
192.168.1.6 nos diz que podemos ter ali um Gateway ou um Route List. Reparem tambm que esse
campo marcado com um astersco *, indicando que se trata de um campo obrigatrio.
Isso quer dizer que todo Route Pattern deve apontar ou para um Gateway ou para um Route List.
Quando o Route Pattern aponta para um Gateway fcil perceber que todas as ligaes que
corresponderem a esse padro sairo por esse Gateway, mas e quando configuramos o Route Pattern
com um Route List? Qual seria o comportamento do roteamento para essas chamadas?
Para responder a essa pergunta precisamos entender o que um Route List. Um Route List nada mais
do que umalista ordenada de Route Groups, que por sua vez, uma lista de dispositivos (gateways
ou trunks).
Isso quer dizer que quando apontamos um Route Pattern para um Route List a primeira entrada na
lista ter preferncia para o roteamento das chamadas que se enquadrarem no padro desse Route
Pattern. Caso o caminho apontado na primeira entrada esteja indisponvel ou sobrecarregado o
sistema tentar encaminhar pelasegunda entrada no Route List e assim por diante. possvel
configurar vrios caminhos e cada nova chamada ir tentar ocupar o caminho na ordem configurada,
ou seja, da primeira entrada para a ltima.
A ordem hierrquica do Route List permite que o administrador controle melhor os recursos que
sero utilizados por cada ligao feita atravs do sistema. Por exemplo, suponha que em sua empresa
exista um circuito E1 dedicado de uma operadora qualquer que lhe d um preo especial para
ligaes DDD. Voc poderia configurar um Route Pattern que corresponda ao padro de dgitos
discados em ligaes de longa distncia (DDD) e associar esse Route Pattern um Route List cuja
primeira opo seja um Route Group que aponte para esse gateway onde o circuito E1 est
conectado. A segunda opo do Route List poderia apontar para um outro Route Group que direciona
as ligaes para um outro gateway qualquer.
Dessa forma, todas as ligaes DDD iriam preferencialemente tentar sair via o link com qual voc tem
um custo menor por ligao. Quando esse link estivesse indisponvel ou sobrecarregado, a as ligaes
DDD passariam a ser roteadas via outro gateway onde o custo por ligao DDD seja maior. Assim,
mesmo com o link indisponvel/sobrecarregado no haveria indisponibilidade do servio, pois as
ligaes continuariam sendo aceitas, s que por um caminho onde o custo maior. Assim que o link
principal esteja disponvel novamente para novas ligaes, o sistema passaria automaticamente a
encaminhar as ligaes de longa distncia via caminho com menor custo.
No veremos aqui detalhes de como configurar esses recursos, o escopo do CCNA Voice exige que
voc tenha conhecimento do conceito envolvido. O menu de criao do Route List pode ser acessado
atravs do caminho "Call Routing > Route/Hunt > Route List". Um detalhe importante que voc ter
que clicar no boto "Add Route Group" para fazer a associao do Route Group ao Route List.
Route Group
Conforme j vimos anteriormente um Route Group umalista de dispositivos Gateway ou Trunks,
que so configurados para dar suporte a circuitos para a PSTN ou para outros clusters de CUCM
remotos em topologias distribudas. Geralmente os Route Groups so configurados de forma que
contenham dispositivos com as mesmas caractersticas de sinalizao, por exemplo, um Route Group
contm um conjunto de Gateways com links E1, outro Route Group contm um conjunto de Trunks
WAN IP com conectividade para outro cluster de CUCM.
O algortmo de distribuio de um Route Group pode ser configurado como Top-Down ou Circular.
No modo Top-Down cada nova chamada ser encaminhada para o primeiro dispositivo da lista,
passando para o prximo somente em caso de indisponibilidade ou sobrecarga do primeiro
dispositivo. J no modo Circular cada nova chamada passada para um dispositivo diferente, ou seja,
a primeira chamada vai para o primeiro dispositivo, quando entrar a segunda chamada essa ser
encaminhada para o segundo e assim sucessivamente.
Veja na figura abaixo um exemplo de um Route Group, configurado no modo Top-Down, cuja primeira
opo o gateway 192.168.1.60 e a segunda opo 192.168.1.61.
Gateway
Nossos ltimos elementos de configurao so osGateway e Trunks, que so os dispositivos que
estoconectados aos circuitos com acesso PSTN, PABX digital ou analgicos, circuitos WAN IP para
acesso aos CUCM de clusters remotos ou circuitos IP-TSP (IP Telephony Service Provider ou Provedor
de Servios VoIP) para conexo com operadoras.
O CUCM d suporte a vrios tipos de dispositivos e interfaces, seja via protocolos peer-to-peer (H.323
e SIP) ou via protocolos como MGCP e SCCP.
A figura 1 abaixo ilustra os elementos de roteamento de chamadas j a figura 2 mostra algumas das
opes de tipos de Gateways que podemos configurar no CUCM. Para acessar o menu de criao de
Gateway no CUCM v em "Device > Gateway".
Importante:
A ordem correta de configurao desses elementos :
1.
2.
3.
4.
Devices (gateways ou trunks)

Route Group
Route List
Route Pattern
Voc deve ter percebido que no Route Pattern devemos associar um Route List, logo o Route List j
deve estar previamente configurado. Da mesma forma, no Route List colocamos os Route Groups e no
Route Groups colocamos os dispositivos. Sendo assim, primeiro devemos configurar os devices,
depois os Route Groups, depois os Route List e por ltimo os Route Pattern.
Anlise de Dgitos
A anlise de dgitos o processo pelo qual o CUCM faz acorrespondncia (match) entre os dgitos
discados com os possveis destinos para o roteamento de chamadas. Diferentes protocolos e
dispositivos realizam a anlise de dgitos de forma diferente. Por exemplo, os dgitos podem ser
coletados um a um em telefones SCCP ou SIP com teclado KPML (Keypad Markup Language) ou por
blocos em telefones SIP, trunks ou gateways.
A lgica utilizada pelo CUCM para selecionar o caminho a ser tomado feito via correspondncia
mais prxima, ou seja, aquele padro que tiver a correspondncia mais prxima possvel do nmero
discado pelo usurio o que ser utilizado. Para ilustrar vamos considerar os Route Patterns abaixo:
6666
6766
6[78]XX
681
68[0-4]X
68!
Vamos agora fazer alguns estudos de caso e verificar qual seria a deciso tomada pelo CUCM.
Importante:
importante compreender bem esse conceito de coleta de dgito por dgito. Isso significa que o
CUCM coleta cada dgito enviado, um a um, e os Route Patterns que no correspondem aos dgitos
discados vo sendo descartados.
A lgica de correspondncia mais prxima (closest match) ir escolher um determinado Route

Patterns baseado nos seguintes termos:
Se o padro corresponder exatamente com a string digitada ou

Entre todos os potenciais Route Patterns, ser escolhido aquele que corresponder a menos
destinos possveis.
Exemplo 1:
Vamos supor que um usurio discou para o nmero 6666.
Nesse caso temos uma correspondncia exata entre o nmero discado (6666) e um Route Pattern
(6666). Tambm podemos perceber que no h nenhum outro tipo de correspondncia possvel, logo
a chamada ser encaminhada atravs do Route Pattern 6666.
Exemplo 2:
Um usurio agora disca para o nmero 6766. Nesse ponto o CUCM verifica que existem duas opes
de Route Pattern.
6766 corresponde a 1 nico destino

6[78]XX corresponde a 200 possveis destinos
Nesse caso o CUCM ir buscar pela Route Pattern que contenha a correspondncia mais prxima do
nmero discado, ou seja, aquele que corresponde a menos destinos, logo seria utilizado o Route
Pattern 6766.
Exemplo 3:
Agora um usurio disca para o nmero 681. Vamos analisar quais seriam as opes e ento buscar
aquele que tem a melhor correspondncia.
6[78]XX corresponde a 200 possveis destinos

681 corresponde a 1 nico destino
68[0-4]X corresponde a 50 destinos
68! corresponde a milhares de destinos
Como podemos perceber o Route Pattern 681 faz a correspondncia exata, no entanto
existem outras possibilidades que o CUCM levar em conta. Nesse ponto o CUCM ir esperar para ver
se o usurio ir discar um dgito adicional depois do 681. Caso o usurio parar por a e no discar mais
nenhum dgito a correspondncia ser feita com o Route Pattern 681.
No entanto, caso o usurio continue discando haver outros Route Patterns que podem fazer a
correspondncia, por exemplo, o Route Pattern 68! faz a correspondncia com uma infinidade
dgitos. Sendo assim, o CUCM fica em estado de espera, aguardando se viro mais dgitos ou no, at
que no existam mais possibilidades e uma correspondncia seja estabelecida com o Route Pattern
com o menor nmero de destino (closest match).
Importante:
O tempo que o CUCM aguarda para verificar se viro mais dgitos definido pelo Inter-Digit Timeout
T.302, que por padro tem um tempo de 15 segundos de intervalo entre dgitos.
Se por acaso o usurio discar um quarto dgito o temporizador do Inter-Digit Timeout comea
novamente e ento aguarda mais 15 segundos para ver se no vem o quinto dgito. Se ao final desses
15 segundos o quinto dgito no for discado o CUCM utiliza o Route Pattern 68[0-4]X para
encaminhamento da chamada.
Agora, se o quinto dgito for discado dentro desse perodo de 15 segundos, o CUCM descarta o Route
Pattern 68[0-4]X, pois ele no faz mais a correspondncia com o padro discado pelo usurio. Nesse
caso, o CUCM inicia novamento o Inter-Digit Timeout e fica aguardando os prximos dgitos e quando
a discagem terminar utiliza o Route Pattern 68!.
Hunt Group
Outro elemento que pode atuar como destino de um roteamento de chamadas o Hunt Group. Um
Hunt Group um grupo de telefones IP (na verdade, dos DNs desses telefones IP) que podem ser
alcanados atravs de umnico nmero comum.
Vamos a um exemplo ilustrativo para tornar esse conceito mais claro (figura 1). Imagine que na sua
empresa exista um setor de HelpDesk de TI, onde os funcionrios da empresa quando estiverem
enfrentando algum problema com seu micro ligam para o nmero central do helpdesk, que no nosso
exemplo ser o nmero 6565.
Ento, quando algum usurio quiser ligar para o helpdesk basta discar para 6565. Se o nmero 6565
for configurado no CUCM como sendo um Hunt Group, o CUCM ir distribuir essa ligao para todos
os atendentes do helpdesk, at que algum deles atenda o usurio que est chamando.
Outra aplicao tambm bem comum onde o Hunt Group pode ser utilizado para funcionar
como piloto das ligaes de entrada, para casos onde no h uma telefonista (figura 2). Imagine que
voc tenha uma filial remota com um nmero reduzido de funcionrios e no haja a necessidade de
contratar uma telefonista para esse local para atender todas as ligaes de entrada. Nesse caso, voc
pode configurar no CUCM o nmero de entrada principal das ligaes (comumente chamado aqui no
Brasil de piloto) para ser um Hunt Group e alocar alguns ramais desse site remoto para fazer parte do
Hunt Group. Dessa forma, toda ligao de entrada para esse site ir tocar nos telefones dos usurios
que fazem parte do hunt.
Figura 1
Figura 2
Dependendo da configurao utilizada o Hunt Group poder utilizar diferentes algortmos de
distribuio da chamada, conforme abaixo:
Algortmos de Distribuio:
Top Down: toda chamada para o Hunt Group ser encaminhada primeiro para o primeiro
telefone da lista, se esse no atender vai para o prximo.
Circular: a cada nova chamada para o Hunt Group o sistema encaminha a ligao para o
prximo telefone da lista, ou seja, para o telefone seguinte o ltimo que atendeu a chamada.
Longest Idle time: nesse caso cada nova chamada ser encaminhada para o telefone que est a
mais tempo sem atender ligaes, ou seja, o telefone que est a mais tempo no estado onhook (no gancho).
Broadcast: no modo broadcast toda chamada para o Hunt Group ser encaminhada para todos
os telefones da lista ao mesmo tempo e o primeiro que atender pega a ligao.
Para criarmos um Hunt Group no CUCM devemos configurar os seguintes elementos.
Line Groups: Aqui configuramos os DNs que faro parte do Hunt Group e sero acionados quando
houver uma ligao com destino ao Hunt Group. aqui tambm que definimos o algortmo de
distribuio utilizado (topdown, circular, longest idle time e broadcast) bem como o tempo que a
ligao dever tocar em cada telefone antes de ser passada para o prximo da lista (parmetro RNA
Reversion Timeout).
Hunt Lists: Esse parmetro nada mais do que uma lista de Line Groups que sero utilizadas quando
uma chamada for destinada ao Hunt Group. Aqui a lista de Line Groups sempre no sentido topdown. Ou seja, quando uma ligao for destinada ao Hunt Group o CUCM ir utilizar o primeiro Line
Group configurado na lista. Caso nenhum telefone atenda a ligao o CUCM encaminha para o
segundo Line Group e assim sucessivamente.
Hunt Pilots: Esse elemento como se fosse o nmero do Hunt Group, o Hunt Pilot (Piloto do Hunt)
nmero pelo qual o Hunt Group acionado. No nosso exemplo o Hunt Pilot seria configurado com
6565.
Um exemplo de criao de Hunt Group ser visto no prximo captulo desse curso. Por hora, guarde
bem o conceito para quando formos ver a parte de configurao voc consiga um melhor
aproveitamento.
Informao extra:
Uma dica para a configurao do RNA a seguinte.
Se estiver trabalhando com algortmo do tipotopdow, circular ou longest idle configure

o RNApara um perdo de tempo curto, por exemplo, 10 ou 12 segundos. Isso vai fazer com que
as chamadas toquem 10s em um telefone e caso esse no atenda vai para o prximo, toca mais
10s e vai para o prximo.
Se estiver trabalhando com algortmo do tipobroadcast configure o RNA para um perodo de
tempo mais longo, como por exemplo, 120s. Isso far com que todos os telefones do Hunt
toquem por 120s at que algum atenda. Esse parmetro muito importante, pois caso voc
habilite o Hunt em broadcast e no altere o RNA para um tempo maior no dar tempo de
nenhum usurio atender a ligao.
Controle de Classe (Class of Control)

O termo Class of Control utilizado para definir a habilidade de aplicar restries de chamadas para
os dispositivos da rede.
Para configurar esses tipos de restries de chamadas necessrio o uso de Partitions e Calling
Search Space (CSS). Veremos um pouco mais sobre esse tema nos prximos slides.
Class of Control:
Comumente esse tipo de restrio pode ser aplicada quando voc deseja, por exemplo:
Impedir que determinados usurios realizem chamadas de longa distncia.

Rotear o mesmo nmero de destino para diferentes localizaes dependendo do horrio do
dia.
Rotear o mesmo nmero de destino para diferentes localizaes dependendo de quem est
efetuando a ligao.
Partition
Uma Partition um grupo de elementos com a mesma caracterstica de alcanabilidade. Voc pode
pensar que uma Partition algo que voc associa aos elementos para os quais voc possa discar, tais
como:
DNs
Route Patterns
Translation Patterns
Voicemail Ports
Nmeros Meet-me para conferncia de chamadas
Por padro, uma Partition existe no sistema, chamada de Null Partition e essa Partition aparece
listada em alguns campos do CUCM com o termo <None>. Veja a figura 1.
Para criar Patitions no CUCM basta acessar o menu Call Routing > Class of Control > Partition em
seguida clique em Add New. Na tela que se abrir coloque as Partitions que deseja criar, uma por
linha, utilizando a sintaxe Nome da Partition, Descrio. De uma nica vez podem ser criadas at 75
Partitions. Veja a figura 2.
Calling Search Space (CSS)

As Calling Search Space, comumente chamadas de apenas CSS, so uma lista ordenada de Partitions.
As CSSs podem ser aplicadas aos dispositivos (tais como um telefone IP ou Gateway) ou linha de um
telefone (DN).
Por padro, existe uma CSS no CUCM com o nome de default que contm somente a Null
Partition.
Voc pensar em uma CSS como sendo algo que voc pode aplicar em elementos que realizam
chamadas.
Para criar novas CSSs acesse o menu Call Routing > Class of Control > Calling Search Space em
seguida clique em Add New. Na tela de configurao coloque o nome, uma descrio e as partitions
que faro parte da CSS.
Interao entre Partition e CSS

A regra geral que deve ser entendida : Se o destino de uma ligao no est associado a uma
Partition da CSS do originador da ligao, essa ligao ir falhar. Parece complicado, no ???
Ento vamos l, em outras palavras: Para que uma ligao seja permitida, o nmero chamado deve
estar associado a alguma Partition que faa parte da lista de Partition da CSS de quem est chamando.
Continua complicado? Ento vamos a um exemplo.
Vamos imaginar o seguinte cenrio. Ns temos o usurio A com seu DN associado CSS-Local. Essa
CCS-Local tem configurada a Partition Local. Tambm existe no sistema 02 Route Patterns
configurados, o 0.XXXXXXXX (com a Partition Local) e o 0.XXXXXXXXXXXX (com a Partition DDD). Essa
configurao feita no campo Route Partition dentro do Route Pattern.
Agora suponha que o usurio A tente fazer uma ligao local via PSTN discando os
dgitos 030457810 (figura 1). Nesse caso o CUCM ir fazer a correspondncia com o Route
Pattern 0.XXXXXXXX e ento ir verificar que nesse Route Pattern temos configurado a Partition
Local. Ento o CUCM verifica que o usurio A tem configurado a CSS-Local e que nessa CCS-Local
temos a Partition Local. Como o usurio A contm uma CSS que est associada mesma Partition
necessria para alcanar esse Route Pattern a ligao permitida.
Caso o usurio A tente fazer uma ligao de longa distncia, digitando os
dgitos 0214130457810 (figura 2) o CUCM ir fazer a correspondncia com o Route
Pattern0.XXXXXXXXXXXX e esse Route Pattern est configurado com a Partition DDD. Nesse
momento o CUCM verifica que na CSS-Local configurada no usurio A no est listada a Partition DDD,
logo o CUCM no permite essa ligao.
Figura 1
Figura 2
Informao extra:
Alguns pontos importantes a considerar.
Se for implementar restries de chamadas em seu ambiente CUCM lembre-se de permitir as
chamadas de emergncia (polcia, bombeiros) para todos os usurios.
Toda vez que um Route Pattern retirado da Partition padro <None>, ou seja, toda vez que voc
configurar uma Partition no Route Pattern, esse Route Pattern no ser mais acessvel via CSS
Default. Isso significa que o Route Pattern ficar inacessvel a todos os dispositivos que estejam
associados com a CSS padro Default. Por isso recomendado que voc elabore todo o seu plano
de restrio (Partitions/CSS) antes de criar os telefones, pois assim, quando cri-los voc j os associa
s CSSs desejadas.
Toda CSS inclui, por padro, a Partition None no final da sua lista. Isso significa que qualquer
destino que seja deixado com a Partition None alcanavel por qualquer dispositivo. Por exemplo,
o Route Pattern que d acesso ligaes de emergncia poderia ser deixado com a Partition None,
dessa forma todo mundo poderia fazer esse tipo de ligao. Apesar de ser uma soluo possvel,
alguns acham mais recomendvel projetar um plano de discagem de forma que todo destino esteja
associado a alguma Partition, e ento dar permisso aos dispositivos via CSS, mesmo que sejam para
todos os dispositivos.
Configurao de Dispositivo e Linha

Conforme comentamos no tpico sobre CSS podemos configurar CSS nos devices (telefones
IP) ou nas linhas dos telefones IP (DNs). Na verdade, podemos configurar em ambas, tanto no device
quanto na linha, ao mesmo tempo e em cada lugar com uma CSS diferente, associadas Partitions
diferentes, dando acesso Route Patterns diferentes.
Nesses casos, quando temos CSS configurada no device e na linha (DN), as Partitions de ambas as
CSS so concatenadas em uma ordem sequencial, de cima para baixo (top-down), sendo que as
Partitions da CSS aplicada na linha (DN) viro primeiro e as Partitions da CSS aplicada ao device viro
por segundo.
Quando esse usurio tentar efetuar uma ligao o CUCM ir analizar as Partitions nessa ordem,
primeiros na CSS da linha e depois na CSS do device. Se houver uma correspondncia ento a
chamada ser roteada para o caminho correspondido. Se, por acaso, houver mais de uma
correspondncia o CUCM ir utilizar a primeira Partition que fez a correspondncia, ou seja, a que
estiver mais no topo da lista.
CSS Linha (DN) e Telefone IP (Device):
Em outras palavras, podemos dizer tambm que sempre aCSS da linha sobrescreve a CSS do device.
Por exemplo, se a CSS do device no inclui a Partition que permite uma ligao DDD, mas a CSS da
linha inclui a Partition que permite essa ligao, o CUCM ir permitir a ligao.
Nesse ponto voc pode estar pensando, para que utilizar CSS na linha e no device? De fato, existem
muitos benefcios ao utilizar esse tipo de esquema hierrquico.
A recomendao oficial da Cisco (Best Practice) para se configurar no device uma CSS que
tenha permisso completa de ligaes (full privilege) para todos os Route Patterns, com a chamada
sendo encaminhada para o gateway apropriado de cada localidade. J as restries de ligaes devem
ser aplicadas na linha, ou seja, na linha de cada usurio configurar uma CSS que permita somente os
tipos de ligaes que voc deseja que esse usurio faa.
Exemplo:
Por exemplo, na linha (DN) voc pode configurar uma CSSque corresponda um Route Pattern no
padro dos dgitos discados para uma ligao internacional, mas configurando esse Route Pattern
para bloquear essa ligao e no para permitir.
O resultado final desse tipo de abordagem que um nmero menor de CSS precisar ser configurado,
consequentemente o sistema ser mais fcil de gerenciar e ter um plano de discagem consistente e
escalvel.
Inicialmente a recomendao citada anteriormente pode parecer um tanto quanto confusa. Ento
vamos tentar ilustrar como isso pode ser feito.
Bem, vimos que a recomendao diz para colocarmos nodevice uma CSS com permisso total de
ligao encaminhando as chamadas via gateway local desse site. Ou seja, se deixarmos somente essa
CSS configurada no device de um usurio, o mesmo poder efetuar qualquer tipo de ligao (local,
celular, ddd, ddi) sendo encaminhado via o gateway local ao qual esse usurio est localizado.
A recomendao tambm diz para colocarmos asrestries na linha (DN) do usurio, configurando
uma CSS que ao fazer a correspondncia com um determinado padro de dgitos a CSS bloqueia a
ligao. Ora, como a CSS do device j permite tudo, parece bvio que temos que colocar na linha uma
CSS que bloqueie algum tipo de ligao (lembre-se que a CSS da linha sobrescreve a do device). Em
outras palavras estamos falando que devemos criar CSS de bloqueio e no de permisso. Mas como
fazemos isso?
Para grandes ambientes distribudos, com inmeros sites remotos, uma das formas de se fazer isso
criar um gateway fake (falso) no CUCM, que no esteja entroncado com nada. Ento crie Route
Patterns que aponte para esse gateway e nesses Route Patterns configure uma Partition que voc vai
utilizar para bloqueio de ligaes. Em seguida, crie CSS para bloqueio com essa Partition e atribua essa
CSS a linha (DN) do usurio que no deve ter permisso para fazer esse tipo de ligao.
Para resumir o conceito de CSS e Partition vamos lembrar do recurso que estudamos no CUCME
chamado Cor List, o qual foi citado como um sistema Lock and Key (chave e fechadura), pois no
CUCM as CSS/Partition funcionam de forma semelhante.
Ento vamos tentar ilustrar como uma CCS/Partition e Route Pattern esto conectados, sendo
semelhante a anlise para Translation Pattern, DN ou qualquer outro elemento que atue como
destino de um roteamento de chamada.
Imagine um corredor com diversas portas, todas fechadas. Voc est tentando sair por uma
determinada porta mas percebe que ela est trancada. A voc lembra que possui um chaveiro, com
algumas chaves nesse chaveiro. Ento, voc comea a pegar cada uma das chaves para tentar abrir a
fechadura dessa porta. Se voc tiver a chave correta ir conseguir abrir e sair pela porta.
Bem, nesse exemplo hipottico, o corredor seu dial-plan e as portas so os Route
Patterns, Translations Pattern,DN e etc. Nas portas existem as fechaduras que trancam a porta, que
nada mais do que a Partition que voc configurou no Route Pattern. O seu chaveiro com as chaves
a CSS, onde cada chave uma das Partitions que est configurada na sua CSS (o seu chaveiro).
Ento, se na sua CSS estiver configurada a Partition correta (se no seu chaveiro tiver a chave certa
para a fechadura), voc ir conseguir fazer a ligao (sair pela porta).
Entendendo o Conceito de Extension Mobility no CUCM

O Cisco Extension Mobility (EM) permite que os usurios possam se logar em qualquer
telefone registrado no cluster de CUCM, podendo ir alm na verso 8.x fazendo o cross-cluster (cruzar
um cluster).
Em ambientes onde os colaboradores no tem posio fixa (podendo estar em mesas diferentes que
no so fixas a nenhuma pessoa) o EM possibilita que suas configuraes pessoas, tais como
directory number (DN ramal) e seus speed dials sejam dinamicamente configurados no telefone
que ele est utilizando naquele momento, portanto ele est no ramal dele no importando que
aparelho telefnico esteja utilizando.
O EM um servio de telefonia e aplicado ao Device Profile de telefones para que usurios
especficos possam se logar neles. Uma vez que os telefones so vinculados ao servio de Extension
Mobility, o usurio pode selecionar o servio no telefone (em services) e entrar com seu User
IDe PIN quando solicitado utilizando o teclado do telefone assim como fazemos para digitar
mensagens de texto (SMS) em telefones celulares. Uma vez logado, o CUCM aplica a configurao do
Device Profile do usurio e reseta o telefone. Quando o usurio no precisa mais utilizar o telefone
ele pode fazer um log-off e retirar suas configuraes do telefone.
Alm disso, devem ser criados diferentes Device Profilespara cada tipo de modelo de telefone que
o usurio pode se logar, pois sabemos que cada modelo de telefone possui diferentes nmeros de
botes, por exemplo, se temos um telefone Cisco 7965 com seis botes configurados, sendo dois para
DN e quatro para speed dials, como o mesmo usurio poderia se logar em um 7942 que tem apenas
dois botes com o mesmo Device Profile? Portanto, precisamos definir um Device Profile para o 7942
configurando somente os dois botes, por exemplo, um para DN e outro para speed dial. O usurio
precisar escolher o profile correto quando temos diversos Device Profiles criados.
Se um usurio se logar em diversos telefones ao mesmo tempo o administrador tem trs opes para
determinar o comportamento do sistema. As opes esto descritas no quadro ao lado.
Quando o usurio se desloga do telefone outro Device Profile pode ser aplicado a ele, normalmente
um Logout Device Profile que permite apenas chamadas internas (on-net) e de emergncia, ou as
configuraes da pgina do telefone so aplicadas no dispositivo.
Comportamento CUCM x EM:
1. Permitir mltiplos logins (allow multiple logins), possibilitando que o usurio esteja logado em
diversos telefones ao mesmo tempo, porm quando isso ocorre acontece o compartilhamento da
linha (shared line), ou seja, todos os telefones tocam ao mesmo tempo quando o DN configurado
chamado.
2. Bloquear (Deny) o login, permitindo que o usurio esteja logado em apenas um telefone por vez,
nesse caso quando o usurio tenta se logar em um segundo telefone ele recebe uma mensagem de
erro. Portanto, o usurio primeiro precisar se deslogar do primeiro telefone para a sim se logar em
um aparelho diferente.
3. Fazer o Auto-logout, assim o usurio tambm pode se logar em apenas um telefone, porm no
precisar se deslogar do antigo, pois o sistema vai deslogar o usurio do primeiro aparelho
automaticamente quando ele tiver realizando o segundo login com sucesso.
As configuraes do Device Profile incluem os parmetros mostrados abaixo:
Parmetros de Configurao Device Profile:
Origem do udio do usurio do Music on Hold (MoH)

Phone button template
Softkey template
User locale
Do not disturb (DND no pertube)
Privacy setting (configuraes de privacidade)
Service subscriptions
Dialing name
Obs: Existe um Device Profile padro (default) que permite que os usurios sem um Device Profile
configurado para um tipo especfico de telefone IP possa se logar utilizando o EM.
Habilitando o Extension Mobility

Para habilitar o EM precisamos seguir vrios passos, os quais podemos ter que repetir diversas vezes
dependendo do nmero de telefones e usurios configurados no sistema, mas basicamente temos
que seguir os passos abaixo:
Habilitar o EM:
1.
2.
3.
4.
5.
Ativar o servio do EM.

Configurar os parmetros do EM.
Adicionar um servio de EM.
Configurar um Device Profile padro para cada modelo de telefone que ser utilizado.
Criar Device Profiles e vincul-los ao servio do EM.
6. Criar usurios e associar os usurios aos Device Profiles.

7. Habilitar o EM para os telefones e vincul-los ao servio de EM.
A seguir vamos ver cada passo citado aqui na introduo com mais detalhes.
Ativando o Servio de Extension Mobility
Na pgina de Serviceability v em Tools > Service Activation.
Selecione o Cisco Extension Mobility e clique em salvar (Save), conforme figura abaixo.
Configurao dos Parmetros do EM

Agora vamos para a pgina CM Administration em System > Service Parameters.
Selecione o servidor que voc quer configurar (menu drop-down) e depois selecione o servio de
EM (Cisco Extension Mobility Service - menu drop-down), conforme figura abaixo:
Ao selecionar o servio de EM ser mostrado mais para baixo da tela os parmetros gerais (para
todo o cluster). Note que podemos selecionar para forar que o EM faa logout depois de um tempo
mximo onde o login considerado expirado e quanto tempo. Tambm configuramos aqui o
comportamento quando temos logins em mltiplos devices simultaneamente (Multiple Logins Not
Allowed - padro, Multiple Logins Allowed ou Auto Logout), conforme j estudamos. Tambm
existem parmetros adicionais como User Ids alfanumricos ou apenas numricos, lembrar o ltimo
usurio logado no display do telefone ou no e se para limpar ou no a lista de chamadas do ltimo
logon anterior ao atual.
Veja na figura abaixo um exemplo de configurao.
Adicionando o Servio do EM para os Telefones
Ainda na tela de administrao v em Device > Device Settings > Phone Services. (figura abaixo)
Clique em Add New.

Configure o nome (EM service name) e a descrio (description) se desejar.
Digite ou copie a URL abaixo no campo Service URL, alterando somente o IP address do seu
servidor:
http://IP_ADDRESS_OF_PUBLISHER:8080/emapp/EMAppServlet?device=#DEVICENAME#
Voc pode abaixo digitar a URL para acesso seguro (HTTPS). Se ambos os campos forem digitados
(HTTP e HTTPS) o telefone vai preferir sempre o HTTPS, isso se ele suportar esse servio.
Selecione o checkbox Enable.
Voc pode selecionar o checkbox Enterprise Subscription, com isso todos os telefones que
suportam o servio de EM criaro um vnculo (subscription) automaticamente com o servio evitando
que o administrador tenha que entrar manualmente com esse parmetro.
Veja a figura abaixo com um exemplo de configurao.
Criando um Device Profile Padro

Na interface de administrao CM Administration v em Device > Device Settings > Default
Device Profile.
Clique em Add New.
Selecione o modelo do telefone (Product Type ou Phone Model) e o protocolo do dispositivo
(Device Protocol). (figura abaixo)
Agora selecione o modelo do telefone e depois o protocolo que ele vai utilizar (figura abaixo).
Agora selecione os templates de botes e softkeys (Phone Button e Softkey Templates), porm no
ser possvel aqui definir os DNs ou outras configuraes mais especficas dos botes (figura abaixo).
No final clique em Save.

Criando Device Profiles e Vinculando o Servio de EM (Subscription)
V em Device > Device Settings > Device Profile.
Clique em Add New.
Selecione o modelo do telefone e o protocolo que aquele usurio vai utilizar.
Entre com o nome para o profile.
Configure os parmetros daquele usurio (DN, botes customizados e demais necessrios).

Veja a figura abaixo, lembre que j fizemos essa configurao para fazer a insero manual de
telefones anteriormente.
Agora na pgina do Device Profile escolha Subscribe/Unsubscribe Services nos Related Links
(links relacionados acima da pgina direita em um menu pull-down) e clique em Go, conforme figura
abaixo.
Escolha o servio de EM configurado no passo 2.3 e clique em Next.

Digite o nome no display para o servio de EM e uma verso em ASCII, necessrio para telefones
com baixa resoluo nos displays.
Clique em Subscribe e depois Save. (figura abaixo)
Se o checkbox Enterprise subscription foi selecionado no passo 2.3 no necessrio setar mais uma
vez (na realidade nem vai aparecer essa opo aqui se voc tiver setado o enterprise subscription),
alm disso, uma outra dica importante que voc deve vincular (subscribe) o Device Profile e os
telefones ao servio de EM, se voc no fizer isso o usurio no ter acesso ao servio no telefone e
uma vez aplicado o Device Profile quando ele efetuar o login no conseguir mais se deslogar!
Vinculando os Usurios aos Device Profiles
V at a pgina User Management > End User.
Selecione o usurio que voc quer criar um profile association (associao do profile) ou crie um
novo usurio conforme vimos no captulo 10.
Na configurao do usurio escolha o Device Profile que deve ser vinculado a ele. Se mais de um
profile for vinculado ao usurio, ele precisa escolher qual utilizar aps efetuar o login no EM. O
Default Profile mostrado no topo da lista de opes.
Veja um exemplo da tela de configurao abaixo:
Habilitar e Vincular o EM nos Telefones

V no menu Device > Phone e selecione o telefone que voc quer configurar para no EM.
Na sesso de Extension Mobility selecione a caixa Enable Extension Mobility.
Configure um Device Profile ou utilize as configuraes atuais (mais recomendado) no Log Out
Profile (menu pull-down).
Lembre que o Log Out Profile a configurao aplicada ao telefone quando no temos nenhum
usurio logado no telefone, normalmente feita uma configurao bsica que permite chamadas de
emergncia e ligaes para a rede interna, algumas empresas ainda liberam ligaes locais, porm no
Brasil em sua maioria permitem somente as ligaes internas. Veja um exemplo da configurao
abaixo na figura. Pegamos um ramal j configurado para somente habilitar o EM nele e configurar o
profile de logout.
Agora podemos vincular (Subscribe) mais telefones ao servio de EM indo novamente na pgina de
configurao do telefone, clicando em find para mostrar os telefones criados, clicar no link de cada
telefone e como j fizemos nessa seo ir no Related Links > ubscribe/Unsubscribe Services para
fazer o vnculo ao EM. Agora escolha o servio de EM a partir do menu pull-down e salve para finalizar
o subscription.
Se voc selecionou o checkbox Enterprise Subscription na configurao que fizemos no item 2.3 o
passo anterior no necessrio (muito cuidado com isso, pois simplesmente no aparece nada na tela
de Service Subscription porque o EM j foi vinculado automaticamente!)
Habilite o Extension Mobility no telefone e escolha o logout profile (preferenciamente utilize o
default) conforme j realizamos anteriormente (conforme figura 1).
Entre com o nome que ele vai aparecer no telefone e repita a operao para quantos telefones for
necessrio repetindo os passos 2.5, 2.6 e 2.7.
No telefone o servio de EM estar disponibilizado na teclaServices, conforme figura abaixo.
Ao pressionar o boto Services, deve aparecer o servio Extension Mobility com o nome que voc
configurou e clicando em select voc poder se logar ou deslogar, conforme figura abaixo.
Aps voc digitar o usurio e o PIN corretamente vai aparecer uma mensagem de sucesso e o
telefone vai resetar para pegar o novo profile que voc configurou para o usurio que se logou. Ao se
deslogar o telefone vai ficar com o logout profile configurado anteriormente.
Recursos e Facilidades de Telefonia no CUCM
Voc j deve ter percebido que o CUCM suporta diversos tipos de facilidades de telefonia, sendo
parte fundamental das comunicaes unificadas da Cisco, por isso nesse captulo vamos revisar e
entender as principais facilidades incluindo algumas outras para dar cobertura de chamadas (Call
Coverage Options), Intercom (intercomunicao) e Presena (Presence).
O termo Call Coverage se refere a diversos recursos e mecanismos para que as chamadas sejam
atendidas (para dar cobertura s chamadas) nas mais diversas circunstncias, algumas delas j at
estudamos para o CME e continuam valendo para o CUCM, outras so novidades. Veja a listagem de
facilidades ao lado.
Sobre o Intercom, ele continua sendo o mesmo recurso que estudamos no CME, possibilitando que
tenhamos uma linha direta com outro ramal, j a parte de presena (presence) vamos estudar nesse
captulo a que j vem nativa no CUCM. Essa facilidade de presena possibilita que possamos saber se
um determinado ramal est ocupado sem mesmo discar para ele, por exemplo.
Agora vamos ver cada um dos recursos e facilidades citados aqui e no prximo tpico desse captulo
vamos aprender como configurar cada uma delas.
Facilidades de Telefonia- CUCM:
Call Forward (encaminhamento de chamadas)

Shared Lines (linhas compartilhadas)
Call Pickup (captura de chamada)
Call Hunting (grupo de busca)
Call Park (estacionamento de chamadas)
Call Forward
Existem diversos tipos de encaminhamento de chamadas (Call Forward) que podemos configurar no
CUCM. Esse parmetro, assim como estudamos no CME, define para que ramal ou outro tipo de
entidade do sistema a chamada, em determinada condio, ser encaminhada.
Por exemplo, o usurio est fora da mesa e no atende a ligao, depois de um determinado tempo o
que vai acontecer? Normalmente, se nenhum tipo de encaminhamento estiver configurado, poderiam
acontecer duas situaes: o chamador tem bastante pacincia e aguarda at a ligao cair ou o
chamador no tem pacincia e desliga aps um certo tempo. No entanto, perder essa ligao pode
no ser interessante para empresa e por isso existe a facilidade de encaminhamento da chamada.
Seguindo a linha desse exemplo poderamos configurar o encaminhamento da chamada para o caso
de no atendimento para um outro ramal, ou para um hunt group, ou caixa de correio de voz.
Um dos encaminhamentos mais importantes que temos que entender o Call Forward All (CFA
muitas vezes chamado de Siga-me no Brasil), ou seja, esse parmetro define o encaminhamento
de todas as chamadas para um determinado nmero de destino que o administrador definiu no
sistema, que pode ser um telefone, um usurio do CUCM ou uma pgina administrativa, sem tocar
(ring) o nmero original. Na instalao padro do CUCM, quando o CFA est habilitado o CUCM ignora
as CSSs configurada na linha/device e utiliza apenas a CSS configurada no campo CSS para o Call
Forward. Por isso, se voc est utilizando um plano de discagem com Partitions e CSS para restringir
ligaes importante que voc configure o CSS dos Call Forward, caso contrrio o encaminhamento
ir falhar.
Observe tambm que para o CFA existem o campos para CSS e um outro chamado Secondary Calling
Search Space for Forward All. O CUCM faz uma concatenao entre a Primary CSS e a Secondary CSS
e o CUCM utiliza essa combinao para validar ou no o encaminhamento.
Alm disso, se a opo da caixa de correio de voz (Voice Mail checkbox) estiver selecionada, o CUCM
ignora o destino e a Calling Search Space configuradas e envia a chamada diretamente para o
nmero piloto definido para o correio de voz (Voice Mail Pilot number) configurada no Voice Mail
Profile.
Obs: essa configurao feita no DN do usurio. Voc pode acessar pelos menus
"Device > Phone" - seleciona o device e clica no link do DN desejado

"Call Routing > Directory Number"
Shared Lines
O nome shared lines em portugus j fala por si s: linhas compartilhadas. Portanto se dois ou
maistelefones IP forem configurados com o mesmo DN em uma das suas linhas, quando algum
discar para esse DN os dois (ou mais) telefones iro tocar, sendo que o primeiro que atender fica com
a chamada e o segundo (ou demais) telefone no poder atender mais a chamada sem utilizar o
recurso chamado Barge (entrar sem permisso ou Interveno), isso se este recurso estiver
configurado. Agora, se o primeiro telefone que est com a chamada a coloca em hold, o segundo
telefone pode capturar (pick up) a chamada que est em espera.
Nas linhas compartilhadas podemos ainda ter mais duas configuraes
chamadas Barge e Privacy (privacidade). Se dois telefones tm uma linha compartilhada (shared line)
e um deles est utilizando essa linha, o segundo telefone pode forar uma conferncia a trs (ele, o
primeiro usurio e o usurio remoto) utilizando esta facilidade chamada Barge, sendo que essa
conferncia hospedada na bridge de conferncia interna do primeiro telefone.
Se um dos telefones no suportar a bridge de conferncia interna voc pode configurar uma externa.
Quando o segundo telefone faz o barge na chamada do primeiro, todos os participantes escutam
um beep por padro, porm se o barge falhar, normalmente por falta de recursos de conferncia,
o telefone que est tentando fazer o barge receber uma mensagem de erro.
Barge e Privacy:
Um softkey chamado Privacy pode ser configurado com o objetivo de prevenir que outro telefone
com a mesma linha compartilhada consiga fazer o barge quando uma chamada est ativa, basta
selecionar o softkey.
Ambos recursos de Barge e Privacy podem ser habilitados para o cluster todo ou individualmente nas
pginas de configurao dos telefones.
Call Pickup
Um DN pode ser inserido como membro de um grupo de pick-up (Call Pickup Group) sendo que a
configurao do CUCM semelhante a que fizemos para o CME.
Basicamente trs tipos de captura de chamada (Call Pickup) podem ser configurados nessa atribuio
de grupo de captura (Pickup Group). Veja abaixo:
Call Pickup:
1. Call Pickup: nessa configurao temos diversos DNs com o mesmo nmero de grupo de captura e
quando um telefone desse grupo toca, outro telefone qualquer desse grupo pode capturar a chamada
simplesmente digitando o boto (softkey) de Call Pickup em seu telefone para capturar a chamada
de imediato.
2. Group Call Pickup: agora nesse caso temos dois telefones ou DNs diferentes e que esto em
diferentes grupos de captura (Call Pickup Group) e um deles est tocando. Para que o telefone que
no pertence ao mesmo grupo possa capturar essa chamada ele ter que selecionar o softkey
GPickup (Group Call Pickup), digitar o nmero do grupo do call pickup do DN que est tocando e a
chamada ser capturada para seu telefone imediatamente. Uma variao desse recurso o Directed
Call Pickup (captura direta), a qual permite que o usurio de um grupo diferente capture a chamada
digitando o nmero do DN que est tocando para fazer a captura, assim ele vai capturar aquela
chamada especfica e no a mais antiga que est tocando naquele grupo. Lembre que aqui para o
CUCM como vimos para o CME, quando voc captura uma chamada de um grupo diferente o
sistema encaminha a primeira chamada que entrou (a mais antiga).
3. Other Group Pickup: esse recurso foi introduzino no CUCM verso 7 e permite que o administrador
configure associaes entre Call Pickup Groups, permitindo que um telefone capture a chamada de
um outro grupo de captura sem digitar o nmero do outro grupo. Para que isso seja possvel um
softkey com o nome OGroup aparecer no telefone.
Alm disso, possvel configurar avisos de udio ou visuais(ou ambos) para avisar aos membros do
grupo de captura que um dos telefones nesse grupo est tocando, isso bastante til se houverem
membros distantes uns dos outros que no conseguem ouvir o telefone tocando.
Call Hunting
O Call Hunting, tambm conhecido como Serial ring ou Grupos de busca, em portugus,
permite que um nico DN ou nmero da PSTN distribua as chamadas para diversos telefones em
sequncia, ou seja, permite o roteamento da chamada para um grupo de usurios de forma linear ou
circular a partir de um nmero piloto.
O Call Hunting recomendado para equipes pequenas de helpdesk ou atendimento ao cliente, pois
para grandes implantaes recomenda-se uma aplicao de call-center.
Acompanhe abaixo os componentes que fazem parte da configurao do Call Hunting.
Call Hunting:
DNs e portas de correio de voz (voicemail ports): os ramais e portas de correios de voz so os
destinos finais do sistema de Call Hunting, os quais so vinculados aos Line Groups.
Line groups: so vinculados aos Hunt Lists, sendo que podemos vincular um ou mais Line Groups a
um nico Hunt List. A configurao do Line Group define os diferentes algoritimos de hunt, tais como
Top-Down, Circular, Longest Idle e Broadcast, e demais opes.
Hunt Lists: uma Hunt List uma lista ordenada das Line Groups (top-down). As chamadas iro fluir
atravs do sistema de Call Hunting sendo enviadas para o primeiro Line Group da Hunt List, se
ningum atender a chamada ela devolvida para a Hunt List, a qual tentar um segundo Line Group,
sendo que esse processo ir se repetir at que a chamada seja atendida ou que a lista de line groups
acabe ou que o usurio que est chamando desligue a chamada.
Hunt Pilots: um Hunt Pilot (ou piloto) associado a uma Hunt List, sendo que ele pode ser um nico
DN, uma linha compartilhada ou um nmero PSTN.
Durante o processo de hunting a configurao de Call Forwarding dos membros do Line Group
simplesmente ignorada e se o DN est ocupado (busy), o prximo DN no Line Group ser escolhido,
ao invs de enviar para o DN definido no CFB (call forward busy - encaminhamento em caso de
ocupado) daquele ramal.
Call Park
O estacionamento de chamadas ou Call Park no CUCM permite que o usurio vincule uma
chamada a um Call Park slot, que nada mais do que um DN, sendo que qualquer usurio pode
capturar essa chamada discando o nmero do Call Park. o mesmo princpio que j estudamos para o
CME.
Uma variao desse recurso chamada Directed Call Park, onde nesse caso o sistema vai solicitar
um cdigo (como uma senha) para que a chamada colocada no Park possa ser recuperada.
Call Park:
Por exemplo, se um cliente liga perguntando uma informao sobre um produto e o funconrio que
atendeu a ligao no consegue responder, esse funcionrio pode, por exemplo, colocar o cliente no
Park pressionando osoftkey de Call Park e procurar por uma pessoa na empresa que possa responder
sobre a dvida do cliente.
Uma vez encontrada essa pessoa, o funcionrio que atendeu a ligao passa o nmero do call park
que o cliente est estacionado e essa pessoa responsvel pelo produto, digita o nmero do call park
para recuperar a chamada e esclarecer as dvidas do cliente.
Intercom
O Intercom no CUCM, assim como estudamos para o CME, permite que um boto seja configurado
para que chamadas possam ser realizadas diretamente para outro telefone e vice versa. O telefone
que recebe a chamada intercom responde automaticamente (auto-answer) em viva voz
(speakerphone mode), porm com o microfone em mudo (mute).
Portanto, uma chamada de uma via (one-way audio stream) foi criada de quem discou para quem
recebeu a chamada, ou seja, quem recebeu a chamada pode ouvir o que quem discou est falando,
mas quem discou no pode ouvir o que o nmero chamado est falando, o que conhecido como
Whisper Intercom.
Quando quem recebeu a chamada pressiona o boto de Intercom, uma segunda chamada de mo
nica estabelecida para que o originador da chamada tambm possa ouvir o que o outro est
falando, agora eles podem se comunicar. Para ambos os casos um tom de autoatendimento ouvido
quando a chamada atendida.
Se uma chamada realizada ou recebida enquanto uma chamada intercom em modo
de Whisper est em progresso, esse terceiro usurio no conseguir ouvir o udio proveniente do
Intercom.
As linhas Intercom so diferentes dos DNs normais, pois no podem ser alcanados por outros
usurios. As linhas Intercom tem seu prprio plano de discagem e permisses (Intercom Partition e
CSS). Um boto de Intercom pode ser configurado como um speed dial com uma linha intercom de
destino pr-configurada ou voc pode configurar para que o usurio disque para a linha de intercom
de destino.
Veja na figura abaixo um exemplo do intercom configurado como 6601 no boto 3 do telefone (CIPC).
Ao teclar nesse boto o outro usurio recebe e automaticamente atende a chamada em mute
(Whispering Intercom) e para fechar a comunicao bidirecional basta ele liberar do mute seu
telefone.
CUCM Native Presence

A presena ou Presence a capacidade de um usurio sinalizar sua capacidade ou desejo de se
comunicar. Um exemplo simples, que voc provavelmente utiliza em seu dia a dia, no seu
Messenger (seja ele qual for) colocando seu status (sua vontade de se comunicar) como ocupado,
disponvel, ausente e etc. Portanto os indicadores de presena podem incluir o estado ou status de
Instant Messaging tais como Online (disponvel), Offline (indisponvel), Busy (ocupado), Out to Lunch
(em horrio de almoo), In a Call (no telefone), Away (ausente), Be Right Back (volto logo) e assim por
diante, ou em um sistema de telefonia com o status no gancho e fora do gancho (On Hook e Off
Hook).
O CUCM tem um suporte nativo (built-in) para rastrear se um DN est livre ou ocupado. Esse estado
ou status da presena pode ser monitorado utilizando um Busy Lamp Field (BLF led indicador de
ocupado ou simplesmente indicador de ocupado) atravs de um speed-dial ou utilizando um
diretrio com capacidade de presena habilitado. O boto de BLF um speed-dial que acende quando
o destino est fora do gancho (off hook).
As Presence-Enabled Call Lists (listas de chamadas com presena habilitada) mostram um cone que
indica se o dispositivo na lista est em um dos estados abaixo:
Unknown ou desconhecido: o dispositivo no est sendo monitorado ou voc no tem

permisso para verificar o status da presena desse dispositivo. O cone aqui um teclado de
telefone em branco.
On Hook ou no gancho: aqui o dispositivo est no gancho e o cone que representa este estado
um telefone sobre um teclado em branco.
Off Hook ou fora do gancho: o dispositivo est fora do gancho, ou seja, ocupado. O cone que
representa este estado so dois telefones (handsets) sobre um teclado em branco.
A figura abaixo mostra os cones do presence em uma situao real. Veja que o ramal 6002 est no
gancho, oramal 6001 est fora do gancho e o 6101 no est sendo monitorado.
Em alguns casos no preciso ou no desejado que todos os telefones saibam o status de cada DN
disponvel no sistema, por isso a informao de presena pode sercontrolada das formas listadas
abaixo:
Arquitetura do Presence:
Atravs BLF Speed Dials, os quais podem ser configurados apenas pelo administrador. Os usurios
no podem criar ou editar os BLFs.
A visibilidade para as chamadas com presence habilitadas e listas de diretrio podem ser limitadas
utilizando Partitions e vinculando Calling Search Spaces (CSSs). Uma CSS deve ser vinculada para
monitorao da presena, de forma que para que o DN possa ser monitorado, quem est querendo
ver seu status deve estar na mesma CSS, a as indicaes de presena ficam disponveis. Caso os DNs
no estejam vinculados mesma CSS ele aparecer como no registrado (Unregistered) para quem
est tentando ver seu status.
Grupos de presena (Presence Groups) podem ser utilizados para que usurios em um determinado
grupo possam ser permitidos ou bloqueados de fazer a monitorao do status de usurios em grupos
de presena diferentes dos seus. Esses grupos podem ser compostos de telefones, DNs e usurios,
sendo que todos os usurios so inseridos em um grupo de presena padro, porm grupos
customizados podem se criados conforma a necessidade de cada projeto. A configurao do InterPresence Group Subscribe Policy setting que define o comportamento padro se os grupos de
presena tm ou no permisso para monitorar o status uns dos outros, porm essa configurao
pode ser sobrescrita por configuraes no prprio grupo de presena. Membros de um mesmo grupo
de presena tem permisso de visualizar o status de outros membros do mesmo grupo, a no ser que
voc utilize uma CSS para bloquear esse acesso. A Subscribe CSS e o Presence Group podem ser
configurados de maneira independente ou conjunta, porm se ambas so utilizadas, se voc deseja
que um usurio monitore o status (seja permitido) ambas devem dar essa permisso de monitorao
do status do DN.
As configuraes do Inter-Presence Group so aplicadas apenas nas call lists dos BLFs e diretrios,
porm no afetam os Speed Dials dos BLFs.
Habilitando Recursos de Telefonia no CUCM
Vamos agora explorar cada uma das configuraes sobre os recursos discutidos anteriormente no
CUCM, iniciando pelas linhas compartilhadas ou shared lines e indo at a configurao da presena
nativa do CUCM.
Configurando Shared Lines
Uma linha compartilhada ou shared line criada quando dois dispositivos ou mais tem o mesmo DN
configurado.
Para configurar uma linha compartilhada basta adicionar o mesmo DN em vrios telefones a partir da
pgina de configurao do DN (DN Configuration > Call Routing > Directory Number) ou do telefone
(Phone Configuration > Device > Phone), indo nas configuraes dos botes (Phone Button
configuration). Veja na figura abaixo a pgina de configurao de DN com dois dispositivos associados
ao mesmo DN.
Assim, quando algum discar para o DN 6101 ambos os telefones citados em Associated Devices iro
tocar.
Agora podemos fazer a configurao da parte deprivacidade da shered line, atravs do recurso
chamadoBarge. Lembre que o Barge permite que um usurio com linha compartilhada force uma
conferncia de trs vias (three-way conference) com outro usurio que compartilha a mesma linha.
Para habilitar esse recurso precisamos ativar a bridge de conferncia interna dos telefones
IP (disponvel em maioria dos modelos de telefone IP Cisco, porm consulte a disponibilidade). Alm
disso, podemos configurar a facilidade de Privacy (privacidade), a qual possibilita que um usurio
que tem linha compartilhada bloqueie o barge para suas ligaes. Abaixo seguem os passos para
configurao do Barge e Privacy:
1. Na interface CM Administration procure o menu System > Service Parameters e depois
selecione o servidor que voc deseja configurar na lista drop-down.
2. Selecione depois o servio chamado Cisco CallManager.
3. V para baixo na tela e procure a seo relacionada ao cluster (Clusterwide Parameters) chamada
Device-Phone, nessa seo habilite (coloque em on) a opo Set Built-in Bridge Enable.
4. Mais abaixo verifique se a opo Privacy Setting est como True (o que o default dessa opo).
Lembre que essas opes de Built-in Bridge, Privacy e Single Button Barge (veremos no prximo
passo) podem ser sobrescritas pela configurao do Device Pool ou individualmente nos telefones.
Veja o exemplo das configuraes realizadas at agora na figura abaixo.
5. Agora v mais para baixo dessa pgina e procure uma seo do Clusterwide Parameters chamada
Feature-Join Across Lines And Single Button Barge Feature Set e configure a opo Single Button
Barge/CBarge Policy para Off (default), Barge ou CBarge. O Off desabilita o barge. A opo Barge
habilita a facilidade utilizando a bridge interna atravs do boto da linha compartilhada, sem a
necessidade de utilizar o softkey Barge. Se escolhermos o CBarge (interveno em conferncia) o
telefone vai fazer o barge utilizando recursos de conferncia externo. Veja abaixo na figura um
exemplo de configurao do passo 5.
Um detalhe importante que voc precisar configurar no seu template de softkey para incluir o
softkey Barge para que os telefones consigam fazer a operao, porm se voc utilizou a opo de
Single Button Barge essa configurao no ser necessria. Outro ponto que se voc estiver
utilizando o CBarge voc precisar configurar um recurso de conferncia externo para que os
telefones possam utilizar esse recurso.
Configurando o Call Pickup
Para configurar o Call Pickup precisamos primeiro criar os grupos depois vincular os DNs nos grupos.
Quem far parte de cada grupo uma definio de cada ambiente e podemos selecionar, por
exemplo, funcionrios de um mesmo setor ou grupo de trabalho para participar de um mesmo grupo
de captura (call pickup group). Para fazer a configurao dos grupos de captura siga os passos abaixo:
1. Na interface de administrao CM Administration v em Call Routing > Call Pickup Group e

clique em Add New.
2. Entre com um nome e nmeros nicos (no podem ser repetidos e no podem conter wildcards).
3. Selecione uma Partition (normalmente a mesma dos DNs, porm pode ser outra para que
possibilite que o administrador restrinja o acesso ao pickup group modificando a CSS dos telefones
conforme necessidade).
Veja na figura abaixo um exemplo de configurao de Call Pickup Group, o qual tem o nome
de Grupo-lab-1 e onmero 9000, as demais opes foram deixados os padres do sistema.
possvel fazer a associao de outros Pickup Groups para utilizarmos a facilidade Other Group
Pickup (que veremos a seguir). Esta facilidade configurvel somente durante a configurao inicial
do Pickup Group. Atente para o fato de que essa opo vai aparecer aps voc dar um Save.
Veja a figura com a tela dessas opes abaixo. Voc vai chegar nessas opes indo para baixo da tela
aps dar o save na configurao inicial mostrada na tela da figura.
Agora precisamos configurar um softkey no telefone para que a funcionalidade de captura possa ser
utilizada seguindo os passos abaixo onde vamos modificar um template padro para termos essa nova
funcionalidade:
1. V pgina de administrao do CUCM para configurar o template de softkey indo em Device >
Device Settings > Softkey Template.
2. Nessa pgina voc pode selecionar (Select), adicionar (add) ou copiar (copy) um template de
softkey. Clique em find para mostrar os templates existentes, clique em um deles e depois copie
(copy) para criar seu prprio template.
3. No menu pull-down do lado superior direito Related Tasks, selecione a opo Configure Softkey
Layout.
4. Adicione o softkey Pickup, Group Pickup ou Other Group Pickup de acordo com a necessidade de
projeto ou dos usurios, sendo que esses botes podem ser selecionados para os estados Off Hook
(fora do gancho ou chamada atendida) ou On Hook (no gancho ou telefone no est sendo usado).
5. Clique em Save e depois aplique as modificaes do template de softkey nos telefones ou Device
Profiles conforme necessidade.
Veja nas figuras 1, 2 e 3 um exemplo de configurao, a qual a figura 1 e 2 mostra como chegamos
tela e a figura 3 efetivamente a tela de configurao. Na figura 3voc vai notar que do lado direito
temos os botes possveis e do lado esquerdo os que vo aparecer no telefone. Para mover de uma
tela para outra basta dar dois clique sobre a opo desejada, nesse caso vamos inserir as trs opes
em um novo template criado a partir do template standard user. No final lembre-se de entrar no
telefone e vincular com esse novo template de softkeys criado (veja figura 4).
Figura 1
Figura 2
Figura 3
Figura 4
Agora que finalizamos essas duas primeiras etapas, para utilizarmos a facilidade de Call Pickup
os DNs devem serassociados individualmente a um Call Pickup Groups que j configuramos
anteriormente. Os DNs que esto configurados no mesmo Call Pickup Group podem capturar
chamadas uns dos outros, os que esto em grupos diferentes podem utilizar o Group Pickup ou Other
Group Pickup, isso se eles tiverem Call Pickup Groups pr-associados conforme mencionamos
anteriormente. Veja na figura abaixo um exemplo de associao de um DN a um Call Pickup Group.
Voc pode chegar nessa tela de duas maneiras:
1. Indo em Device > Phone e clicando no telefone a ser configurado e escolhendo a linha (line)
com o DN que voc deseja configurar (veja na figura 4 do slide anterior o link no lado superior
esquerdo chamado Line [1] - 6100 (no partition), ali que devemos clicar).
2. Ou indo diretamente em Call Routing > Directory Number e ento escolhendo o DN que
deseja configurar. A tela que voc vai chegar para os dois caminhos a mesma, ou seja, a tela
de configurao do DN.
Uma vez na tela de configurao do DN, role a pgina para baixo e voc ver a opo Call Pickup
Group, basta agora selecionar o grupo desejado (que j deve ter sido previamente configurado).
Configurando o Call Park e Directed Call Park
O Call Park permite que os usurios utilizem um DN reservado para fazer o estacionamento de uma
chamada, a qual pode ser depois recuperada por qualquer telefone IP. Uma variao dessa facilidade
o Directed Call Park, que funciona de uma maneira similar com a adio de um recurso que pede
ao usurio que est recuperando a chamada para digitar um cdigo (prefix code) antes de capturar a
chamada estacionada, alm da capacidade de especificar um nmero de reverso (reversion number
o nmero que a chamada ser encaminhada caso ningum capture ela do park).
Vamos inciar vendo a configurao do Call Park:
1. V em CM Administration no menu Call Routing > Call Park.
2. Clique em Add New.
3. Especifique um DN ou uma faixa (range) de DNs sero utilizados no Call Park. Os nmeros podem
ser particionados se necessrio utilizando uma Partition customizada. Esse nmero ou range deve
estar vinculado a um servidor CUCM que voc vai escolher em um menu pull-down. Se voc estiver
associando Call Park slots a diversos servidores certifique-se que essa faixa de ramal no sobrepe
faixas de outros servidores.
4. Clique em Save.
A opo de Call Park number/range definida utilizando a mesma wildcard que utilizamos na
criao de Route Patterns, por exemplo o 61XX tem os Call Park slots de 6100 a 6199, conforme tela
de configurao de exemplo na figura abaixo.
Para configurar o Directed Call Park vamos seguir passos bem semelhantes ao anterior, conforme
segue abaixo:
1. Em CM Administration v no menu Call Routing > Directed Call Park.
2. Clique em Add New.
3. Entre com um nmero exclusivo ou um range e especifique uma Partition se necessrio.
4. Especifique um Reversion Number, que o DN para qual a chamada ser transferida caso no
seja puxada do park slot quando o timer de Call Park Reversion expirar, o qual tem por padro 60
segundos.
5. Especifique a Reversion Calling Search Space para permitir que o telefone alcance o nmero de
reverso (reversion number) configurado no passo anterior, isso se ele no estiver na CSS normal do
telefone ou linha.
6. Defina um Retrieval Prefix, que o cdigo que a pessoa vai digitar para capturar a chamada
estacionada.
7. Clique em Save.
A figura abaixo tem um exemplo de configurao do direct call pick-up.
Configurando o Call Hunting

O princpio de configurao do Call Hunting (Grupos de busca) mostrado abaixo:
Call Hunting:
1. Grupos de DNs so associados a Line Groups (grupos de linhas) que especificam o
comportamento do hunt.
2. As Line Groups so associadas a Hunt Lists, as quais selecionam a ordem do hunting atravs dos
Line Groups.
3. Um nmero de Hunt Pilot (piloto) associado a uma Hunt List e servidores como nmeros de
discagem que disparam ou iniciam o sistema de hunting.
Na sequncia veremos como configurar cada um dos passos citados. Clique nas setas de navegao na
parte superior da tela.
Criando os Line Groups
1. Crie DNs e associe-os a telefones (caso j tenha alguns criados ignore esse passo).
2. Em CM Administration v para a tela Call Routing > Route/Hunt > Line Group e clique em Add
New.
3. Entre com um nome para o Line Group.
4. Defina um RNA Reversion Timeout (um valor em segundos que cada DN no Line Group ir tocar
antes do sistema considerar sem respostas - No Answer trigger ou gatilho para considerar sem
atendimento chamada).
5. Selecione o algoritmo de distribuio (Distribution Algorithm):
Top Down (de baixo para cima): cada nova chamada inicia com o DN que est no topo da lista.
Circular: cada nova chamada inicia no DN seguinte ao que atendeu a ltima ligao.
Broadcast: todos os DNS definidos no Line Group tocam simultaneamente.
Longest Idle Time (tempo livre mais longo): o DN que est a mais tempo no estado On Hook
(no gancho) o que toca.
6. Selecione uma opo de Hunt para cada estado da chamada: No Answer (sem
resposta), Busy (ocupado) eNot Available (indisponvel) a partir de um menu pull-down. As opes de
Hunt (busca) determinam se a chamada vai para a Line Group atual ou para uma prxima Line Group
na lista de Hunt.
7. Adicione os DNs Line Group, lembrando que a ordem dos DNs pode ser importante dependendo
do algoritmo de distribuio escolhido anteriormente.
8. Clique em Save.
A figura abaixo mostra um exemplo da tela de configurao do line group.
Criando Hunt Lists

1. V agora em Call Routing > Route/Hunt > Hunt List e clique em Add New. (figura abaixo)
2. Digite um nome para a lista de busca (hunt list).

3. Configure o CUCM Group para redundncia de CUCM para a Hunt List (caso exista servidor
redundante) e clique em Save.
4. Agora as demais configuraes da Hunt List iro aparecer na pgina. (figura abaixo)
5. Adicione as Line Groups nas Hunt List, sendo que o processamento dessa Hunt List sempre topdown, por isso a ordem importante e voc pode fazer os ajustes utilizando as setas se necessrio,
movendo as listas para cima ou para baixo.
6. Clique em Save quando as Line Groups estiverem na ordem correta.

Criando um Hunt Pilot
Agora vamos para ltima etapa de configurao criando um hunt pilot ou nmero piloto da busca.
Veja a sequncia abaixo:
1. Vamos agora at a tela de configurao do piloto em Call Routing > Route/Hunt > Hunt Pilot e
clique em New.
2. Digite um nmero para o Hunt Pilot. O comportamento bem parecido do que vimos para o Route
Pattern, onde voc pode especificar qualquer string que voc quiser, incluindo um nmero PSTN ou
DID (Discagem direta a ramal).
3. Configure uma Partition para controlar o acesso ao Hunt Pilot, se necessrio.
4. No campo Hunt List selecione qual deve ser acessada quando digitar o Hunt Pilot number (nmero
do piloto).
5. Defina um Alerting Name que ser mostrado nos telefones que iro receber as chamadas vindas
do sistema de hunting.
6. Configure as opes do Hunt Forwarding para controlar para onde as chamadas que no podem
ser tratadas pelo sistema de busca devero ser encaminhadas. O checkbox Use Personal
Preferences faz com que as configuraes sejam ignoradas, utilizando as configuraes de Call
Forward definidas no dispositivo que encaminhou aquela chamada para o Hunt Pilot.
7. Clique em Save.
Na figura abaixo voc pode ver a pgina de configurao do Hunt Pilot.
Alm disso, voc pode configurar no Phone Button Template e Softkey Template o boto HLog
para permitir que os usurios se loguem ou desloguem em um Hunt Group. Na tela de CallManager
Service parameter com a opo Hunt Group Logoff Notification voc pode especificar um tom de
toque (ringtone) que ir alertar o usurio que existe uma chamada entrante que poderia tocar no
telefone desse usurio caso ele no estivesse deslogado do hunt. Isto pode servir como um alerta
para usurios que estiveram muito tempo afastados de suas mesas e retornaram, de que eles foram
deslogados do sistema.
Configurando o Intercom
Como vimos anteriormente, o Intercom utiliza recursos especiais para ele: DNs do Intercom,
Partitions e Calling Search Spaces. Vamos agora ver como configurar o Intercom:
1. V em Call Routing > Intercom > Intercom Route Partition e clique em Add New.
2. Na pgina de configurao digite o nome e separado com uma vrgula insira a descrio da nova
partio de Intercom. Voc pode criar at 75 Partitions de uma vez s nessa mesma pgina.
3. Clique em Save (veja a figura abaixo).
4. Agora v em Call Routing > Intercom > Intercom Calling Search Space, clique em Find e veja que
a CSS para o Intercom foi criada automaticamente, isso porque voc criou a partio para o Intercom
no passo anterior (o nome automtico criado foi <nome_da_partio>_GEN). Portanto, a CSS gerada
automaticamente inclui a partio do Intercom que foi recm criada, mas voc pode utilizar essa CSS
e modifica-la ou ento simplesmente criar uma nova se for necessrio. Veja a figura abaixo:
Dica: a customizao da CSS do Intercom s necessria se voc tiver botes para diversos destinos,
tanto discados como speed dials, e o acesso a certos destinos precisam ser limitados. Se voc estiver
utilizando uma linha Intercom ponto a ponto no precisa fazer essa customizao na CSS ou criar uma
nova.
5. Para finalizar v em Navigate to Call Routing > Intercom > Intercom Directory Number e clique
em Add New para criar um DN para o Intercom. Voc vai precisar criar pelo menos dois DNs, isso
devido ao Intercom ser de mo nica (one-way) e no poder fazer ou receber chamadas como um DN
normal.
6. Vincule uma partio e CSS ao DN de Intercom de acordo com seu projeto para controle de
chamadas (veja figura abaixo).
Agora que a configurao geral do Intercom est feita voc precisa configurar o boto no
telefone com o Intercom utilizando o Phone Button Template (forma mais recomendada) ou ento
indo diretamente na pgina de configurao do telefone, porm esse tipo de configurao direta em
um dispositivo (um a um ou one-off) mais complicada de se administrar e no tem uma boa
escalabilidade.
Vamos ver a configurao utilizando o Phone Button Template e a seguir vamos aplicar a um
telefone, veja os passos abaixo:
1. V em Device > Device Settings > Phone Button Template.

2. Escolha o template (Phone Button Template) que mais se adequa ao seu telefone/protocolo para o
qual voc vai configurar o Intercom. Agora vamos alterar o padro (stock profile) copiando e
modificando a cpia ou ento simplesmente criando um novo, porm o mais recomendado copiar e
modificar um dos padres j existentes.
3. Uma vez dentro da pgina de configurao do template de botes, adicione o recurso de
Intercom ao boto desejado ou conforme planejado.
4. Clique em Save para finalizar a configurao.
Veja na figura abaixo um exemplo da tela de configurao do Phone Button Template.
Por ltimo, voc precisa configurar ou associar esse novo template aos telefones que devem ter o
Intercom configurado:
1. V at a pgina de configurao do telefone em Device > Phone, escolha o telefone a ser
configurado e aplique o template selecionando o novo que criamos a partir do menu pull- down
(no campo Phone Button Template) da pgina de configurao do telefone. (figura abaixo)
2. Configure o boto do telefone com o DN, Partition e CSS do Intercom (figura abaixo).
Para chegar na tela da figura 2, voc deve clicar no menu chamado Intercom [1] - Add a new
Intercom na tela da figura 1.
Configurando a Presena Nativa do CUCM
Lembre que estudamos anteriormente que o CUCM tem dois tipos de presena nativa (native
Presence). Veja abaixo:
Presena Nativa:
1. O BLF Speed Dial.
2. As Presence-Enabled Call Lists, o qual um recurso mais elaborado e utiliza Presence
Groups (grupos de presena) e uma Subscribe CSS especial.
Vamos em seguida ver como configurar esses recursos de presena no CUCM.
Configurando BLF Speed Dials
Para adicionar os speed dials do BLF no telefone o mais recomendado modificar um Phone Button
Template. possvel configurar direto nos telefones individualmente, porm o trabalho muito
grande, assim como a probabilidade de erros, alm disso, esse tipo de configurao um a um no tem
escalabilidade. Para fazer a configurao do BLF Speed Dial siga os passos abaixo:
1. V at a pgina Device > Device Settings > Phone Button Template.
2. Selecione, copei ou crie um template para o modelo e protocolo de telefone corretos conforme
necessidade.
3. Adicione a facilidade de Speed Dial BLF em um ou mais botes, de acordo com a sua
necessidade.
4. Aplique esse template nos telefones desejados.

5. Na pgina do telefone, adicione um novo boto de BLF (BLF SD button) e configure o DN e o texto
do display (display Label).
Veja nas figuras 1, 2 e 3 um exemplo da pgina de configurao do boto de Intercom e BLF Speed
Dial.
Na figura 1 alteramos um template padro para que ele tenha o BLF nos botes 4, 5 e 6. J na figura
2 estamos mostrando a pgina de configurao do telefone, o qual tem aquele padro de botes que
alteramos, j com as linhas de BLF aparecendo na configurao. Na figura 3mostramos a configurao
dos ramais que vamos monitorar com os trs BLFs. Note os cones de presena nafigura 4 indicando
que os ramais 6001/6002 esto no gancho e o 6101 tem presena desconhecida, na realidade ele no
est registrado no sistema. O ramal 6602 que est acima dos BLFs o Intercom que configuramos no
tpico anterior.
Figura 1
Figura 2
Figura 3
Figura 4
Configurando Presence-Enabled Call Lists

Conforme descrito anteriormente, o CUCM pode monitorar o status de on/off hook dos telefones
atravs dos speed dials do BLF e Presence-Enabled Call Lists.
As Presence-Enabled Call Lists utilizam as Subscribe CSS e/ou Presence group configuradas nos
dispositivos para determinar se eles podem ou no monitorar o status de presena dos DNs, de
acordo com o mostrado abaixo:
Se a Subscribe CSS aplicada no inclui a Partition do DN que est sendo monitorado o status de
presena fica indisponvel (unavailable).
Se a configurao do Inter-Presence Group Subscription est negada entre dois grupos, as
informaes de presena ficam indisponveis.
Se voc utilizar Subscribe CSS e Presence Groups em conjunto, ambas devem permitir a
monitorao/subscrio (subscription) para que o status de presena possa ser visualizado.
Configurando Presence-Enabled Call Lists

A configurao das listas de presena (Presence-Enabled Call Lists) um pouco mais complexo que o
BLF Speed Dials, mas sua vantagem que possui mais flexibilidade, preciso e escalabilidade
quando o projeto envolve grande nmero de dispositivos e DNs a serem monitorados. Abaixo seguem
os passos de configurao de uma Presence-Enabled Call List:
1. V at a pgina System > Enterprise Parameters e role a pgina para baixo at a seo
Enterprise Parameters Configuration.
2. Habilite a opo BLF for Call Lists (configure como Enabled).

3. Se for preciso crie uma nova Subscribe CSS, nesse caso recomenda-se utilizar essas CSSs com
Partitions j existentes, porm esse controle (Class of Control) deve ser planejado e analisado com
cuidado antes das mudanas serem realizadas.
4. Aplique a CSS apropriada aos telefones e SIP trunks que necessitam dessa configurao.
Veja na figura abaixo um exemplo da tela de configurao do Enterprise BLF for Call Lists.
Configurando Custom Presence Groups

Devido a todos os dispositivos e DNs , por padro, fazerem parte do Standard Presence Group
(grupo padro de presena) e todos os dispositivos poderem ver todos os DNs do mesmo grupo,
a Subscribe CSS e Partitionsexistentes devem fornecer o controle sobre a visibilidadeda presena no
sistema entre os dispositivos e DNs. Em um cenrio ou ambiente mais complexo voc precisar
configurar grupos customizados de presena (Custom Presence Groups) e definir o relacionamento
entre esses grupos (Inter-Presence Group subscriptions) para definir as permisses, conforme passos
abaixo:
1. V at a pgina System > Presence Group, clique em Add New e configure um nome.
2. Defina o relacionamento entre os grupos de presena (Presence Group Relationship) com outros
grupos permitindo ou negando a monitorao (Allow Subscription ou Disallow Subscription) para
controlar se o grupo pode monitorar o status da presena de outros grupos. Cada subscrio
(subscription) de mo nica (one-way), por exemplo, se configurarmos para os gerentes
visualizarem o status de presena de seus empregados, no quer dizer que os empregados podem
visualizar o status do seu gerente. A figura abaixo mostra a configurao da pgina de configurao
do Presence Group.
3. Agora voc precisa ir para a pgina System > Service Parameters, selecionar o servidor a ser
configurado e escolher o servio Cisco CallManager. V mais para baixo na pgina at a sesso
Clusterwide Parameters (System-Presence).
4. Configure o padro do Inter-Presence Group Subscription policy para permitir (Allow) ou
bloquear (Disallow), conforme necessidade.
5. Agora vincule Presence Groups aos DNs e Phones, lembrando que os telefones monitoram DNs.
O grupo de presena (Presence Group) vinculado ao telefone e ao DN, o Inter-Presence Group
Subscription Setting, a Subscribe CSS de quem vai monitorar o status de presena e a Partition do DN
interagem em conjunto para determinar se a informaes de presena esto ou no disponveis para
quem esteja fazendo a monitorao do status.
As figuras 2, 3 e 4 mostram um exemplo da pgina de configurao do Presence Group para um
telefone, DN e SIP trunk respectivamente.
Figura 2
Figura 3
Figura 4
Um detalhe importante que os telefones conseguem monitorar ou observar o status de presena

das entidades de presena (Presence entities), tais como os DNs e SIP trunks. As configuraes do
vnculo com o Presence Group e a inscrio em um Inter-Presence Group controlam se o
observador pode ou no ver o status de presena dessas entidades de presena.
Porm quando falamos de um tronco SIP, ele pode ter o papel de observador e entidade de presena,
mas apenas um grupo de presena pode ser vinculado a um SIP trunk. Este grupo nico de presena
aplicado nas subscries (subscriptions) de presena tanto de envio como de recebimento. Tenha isso
em mente e certifique-se de que o grupo de presena que voc colocou o SIP trunk tem as permisses
corretas para observar e ser observado por outros grupos no sistema.
Entendendo a Mobilidade no CUCM
Atualmente temos diversos tipos de dispositivos de comunicao, tais como nosso telefone de casa,
telefones celulares, smartphones com WiFi-enabled, tablets, laptops, desktops e telefones IP wireless,
portanto encontrar algum online nunca foi to fcil! Agora como administrar as comunicaes com
toda essa diversidade de dispositivos? O CUCM possibilita a criao de um nmero nico para que a
pessoa receba e faa suas ligaes como se estivesse em um mesmo dispositivo.
Por exemplo, uma chamada que foi feita para seu ramal IP (nmero principal para o sistema de
mobilidade) pode tocar em seu telefone celular se voc no estiver na sua mesa, mas para a pessoa
que est discando isso imperceptvel, ou voc est fora da empresa e vai ligar para um cliente e
quer que ele pense que voc est na sua mesa, voc pode fazer uma ligao para o CUCM e o sistema
de mobilidade vai permitir que voc realize essa ligao utilizando o seu DN, ou seja, ao invs de
aparecer o nmero do seu celular no identificador de chamadas do cliente, ir aparecer o nmero do

seu telefone IP.
Vamos ver nesse captulo que o CUCM tem uma gama derecursos de mobilidade que permitem que
os usurios do sistema interajam com seus dispositivos de comunicaes unificadas no importando
onde eles estiverem, pois o objetivo aqui que o usurio possa receber e fazer chamadas atravs do
sistema de uma maneira flexvel.
Agora vamos estudar cada uma das formas de mobilidade que o CUCM permite configurar, para que
na sequncia possamos realizar a configurao bsica desses recursos.
Mobile Connect
O Mobile Connect tambm conhecido como Single Number Reach e possibilita que o nmero do
telefone IP do usurio se torne um nico nmero (single number) para que outros dispositivos que
essa pessoa utilize possam ser alcanveis atravs desse nmero nico, podendo ser seu telefone de
casa, celulares, nmeros VoIP da Internet e muitas outras possibilidades. O maior benefcio que
agora o nmero de telefone do usurio se torna um ponto nico para contato, no importando onde
ou quantos dispositivos esse usurio tenha ele sempre ser alcanado de uma maneira simples e
consistente.
Vamos contextualizar esse recurso com um exemplo. Suponha que um usurio recebeu uma ligao
no seu nmero da empresa (business number) e ele no est na sua mesa. Com o Mobile Connect
configurado todos os dispositivos configurados iro tocar ao mesmo tempo, uma vez um deles
atendido, esse dispositivo vai receber a chamada e os demais param de tocar.
Agora vamos alm, digamos que esse usurio atendeu a ligao em seu aparelho celular enquanto
estava voltando do caf em direo sua mesa, quando ele chega na sua mesa pode pressionar um
softkey em seu telefone IP e puxar essa chamada que est no celular, continuando a conversa a partir
do seu telefone IP sem ter que desligar a chamada. Veja a figura abaixo que ilustra um exemplo do
Mobile Connect.
O caminho inverso tambm possvel, por exemplo, o usurio estava falando no telefone IP e precisa
sair mas deseja continuar falando com a pessoa, nesse caso ele pode pressionar um softkey em seu
telefone IP e transferir a chamada via sistema de mobilidade para seu celular, mas sem que a pessoa
com que ele est conversando note que isso ocorreu. Lembre que via transferncia podemos fazer
isso, mas nesse caso a pessoa do outro lado vai saber que voc est transferindo, porque voc ter
que apertar o softkey de transferncia, discar o nmero do celular e aps isso finalizar a transferncia.
Se o usurio liga para o telefone IP de um colega utilizando o seu Direct Inward Dial (DID discagem
direta a ramal) do seu telefone IP, o CUCM reconhece o Automatic Number Identification (ANI o
Caller ID ou nmero que est discando o celular nesse caso) do usurio devido a correspondncia
(match) com um Remote Destination Profile (profile de destino remoto), o qual tem uma linha
compartilhada com o nmero do usurio (directory number ou DN). Agora ao invs do telefone IP do
colega mostrar o nmero do celular do usurio ele mostrar o DN do telefone IP desse usurio.
Essa mesma funcionalidade possibilita que o usurio ligue para o o sistema de mensagem de voz
(Cisco Unity Connection) e tenha o recurso chamado Easy Message Access e leia suas mensagens de
voz a partir do seu celular que est associado ao DN do seu telefone IP.
A maioria das implantaes de Mobile Connect utilizam cdigos de acesso para destinos remotos,
nesses casos pode ser necessrio fazer manipulao de dgitos com o nmero de entrada (ANI) para
que haja correspondncia com o padro de nmero estabelecido no Remote Destination Profile.
Outra opo ativar o CallManager Service Parameter Matching Call ID com Remote Destination
Partial Match, o que faz com que o CUCM faa a correspondncia mais prxima (closest match) com
o Remote Destination Profile, iniciando com o dgito menos significativo do ANI.
Arquitetura de Mobilidade Unificada
O Mobile Connect utiliza Remote Destination Profiles para configurar telefones virtuais que
compartilham diversas configuraes com o telefone IP principal do usurio, atuando como um
telefone com linhas compartilhadas (shared lines), ou seja, quando o primeiro nmero toca as linhas
compartilhadas tambm tocam, porm a configurao do sistema permite que essas chamadas
tambm sejam redirecionadas para a PSTN possibilitando que outros dispositivos externos toquem.
As Remote Destination Profiles so configuradas de maneira muito semelhantes aos telefones
fsicos com parmetros como Partition, Device Pool, Calling Search Space (CSS), User, Network Music
on Hold (MoH) e o mesmo DN, detalhe bvio mas importante. Uma configurao mais especfica a
Rerouting Calling Search Space usada para permitir que o sistema roteie as chamadas aos
dispositivos, mesmo que essa chamada estivesse bloqueada pela CSS do normal telefone IP.
Obs: Podemos configurar at dez Remote Destination Profiles por usurio.
Para que o Mobile Connect funcione de maneira correta e eficiente teremos ainda que definir alguns
temporizadores para resolver problemas inerentes a esse tipo de soluo, como por exemplo:
Quanto tempo o sistema deve esperar antes de comear a tocar os telefones configurados na
Remote Destination Profile?
Quanto tempo o dispositivo remoto deve tocar antes que a chamada possa ser atendida nele?
Portanto, o ajuste desses temporizadores (timers) pode deixar o sistema muito mais eficiente para o
recurso Mobile Connect, assim como prevenir comportamentos no desejados ou operaes que
deveriam ser evitadas, tais como chamadas indo muito cedo para o sistema de mensagem de voz
(voicemail) ou at serem encaminhadas para caixas de voz erradas em outros dispositivos, por
exemplo, indo para a caixa de correio de voz pessoal do celular do usurio ao invs de ser
encaminhada ao Unity Connection do sistema corporativo.
Esses conceitos so importantes de serem compreendidos para que possamos entender como
configurar o sistema mais para frente nesse captulo.
Access Lists
Aqui no estamos tratando das ACLs disponibilizada pelo IOS dos roteadores da Cisco. As Access Lists
do Mobilie Connectpermitem aos administradores e usurios controlarem quechamadas podem ser
encaminhadas aos dispositivos da Remote Destination Profile e a que hora do dia.
As Access Lists filtram as chamadas com base no Caller ID, os quais precisam ser configurados para
permitir um certo nmero de padres/patterns (chamadas de listas brancas ou white list) ou bloquear
padres/patterns (lista negra ou black list).
Podemos utilizar trs tipos de correspondncias (match) para selecionar os nmeros. Veja abaixo:
Tipos de correspondncias:
Not available ou no disponvel: O Caller ID no foi fornecido.

Privado ou Private: O Caller ID no mostrado.
Directory number: O Caller ID corresponde a um nmero especfico ou uma faixa de nmeros
definidos em uma wildcard (utilizando os dgitos de 0 a 9, *, # e as wildcards X e !).
Agenda de Acesso (Time-of-Day Access)
Cada Remote Destination Profile pode ser configurado com uma agenda (schedule) que controla
quando ela pode ser includa na lista de dispositivos remotos que iro tocar. Por padro todos os
dispositivos tocam (ring).
Um detalhe importante que o time zone real do dispositivo remoto deve ser especificado nas
regras (time-of-day rules) para que a agenda funcione corretamente.
As chamadas entrantes so processadas das formas citadas no quadro ao lado.
importante aqui evitar Access Lists vazias, pois quando elas so selecionadas em uma white list
acabamproibindo as chamadas de serem roteadas. J uma Access List vazia em uma black
list permite que todas as chamadas sejam roteadas aos dispositivos remotos. Ora, se a white list
permite as chamadas e voc configura uma essa access list vazia, ela no vai permitir chamada
nenhuma, concorda??? Da mesma forma, as black list bloqueiam chamada, e se forem configuradas
vazias, no iro bloquear chamada nenhuma.
Processamento chamadas entrantes:
1. As regras de Time-of-Day so processadas primeiro.
2. Se a regra permite que a chamada seja encaminhada Remote Destination Profile as Access
Lists sero processadas na sequencia.
3. Se a Access List permite a chamada ela encaminhada para o dispositivo remoto de destino
(Remote Destination device).
Mobile Voice Access (MVA)
Lembre-se que acabamos de estudar que o Mobile Connect permite que o usurio receba as
chamadas com um nmero nico, j o Mobile Voice Access (MVA) utilizado para que os usurios
possam fazer chamadas de sadautilizando o mesmo nmero (single-number) configurado. Em
sistemas tradicionais o MVA chamado de Direct Inward System Access (DISA).
Como isso funciona? O usurio acessa o sistema do CUCM a partir de seu telefone celular (mobile
device dispositivo mvel) e instrui ao sistema para fazer uma chamada como se estivesse sendo
realizada a partir de seu telefone IP (utilizando seu nmero primrio configurado), assumindo aqui
que estamos utilizando o DID, mas tambm poderia ser um nmero do tronco principal da empresa.
Portanto, como j foi dito no incio a localizao real ou fsica do usurio no importa, pois a chamada
ir aparecer como se ele estivesse na frente de seu telefone IP, dando mais consistncia s
comunicaes de voz, pois todas as ligaes que o usurio realizar utilizando o MVA parecer que ele
est realizando do seu prprio telefone IP com seu nmero corporativo principal.
Na prtica, para utilizar o servio de MVA o usurio ter que (acompanhe na figura ao lado):
1. Discar em um nmero especial reservado para esse servio, normalmente um ou mais ramais
da faixa PSTN DID reservada ao servio.
2. Um gateway VoiceXML configurado para atender e rotear essas chamadas a uma aplicao
de Interactive Voice Response (IVR Resposta interativa de voz) que guia o usurio atravs
da sesso MVA em curso.
3. O IVR ir solicitar que o usurio se autentiquesolicitando um User ID (que opcional) e
um PINpor questes de segurana, seno qualquer um poderia realizar chamadas gratuitas
pelo MVA.
4. Uma vez autenticado o IVR solicita o nmero que o usurio deseja discar.
5. O usurio digita o nmero PSTN e o sistema faz a chamada utilizando o ANI (caller ID) do
telefone IP do usurio.
6. A chamada atendida pelo telefone de destino e a comunicao est estabelecida.
O usurio pode trocar entre o telefone celular e o telefone IP durante a chamada, como vimos para o
recurso anterior de Mobile Connect. Alm disso, a pessoa que recebeu a chamada ver que o Caller ID
o do telefone IP do usurio que discou, fornecendo a consistncia de um nico nmero para o
usurio e reconhecimento desse usurio pelos seus clientes e parceiros, permitindo, por exemplo,
que eles chamem novamente o usurio atravs de uma lista de chamadas recebidas mais facilmente.
Configurando o Mobile Connect

Apesar de no ser difcil de implementar recursos de mobilidade no CUCM, a tarefa repetitiva e
dependendo do nmero de usurios a serem configurados pode ser tornar cansativa e demorada,
porm faz parte dos objetivos do CCNA Voice e vamos ento s configuraes!
Voc vai notar aqui que diferentes componentes interagem para que o Mobile Connect possa
funcionar, mas de uma maneira geral sua configurao envolve os passos citados abaixo:
Configurao do Mobile Connect:
1. Habilitar o boto de Mobility no template de softkey (Softkey Templates).
2. Configurar contas de usurio para o Mobility (user accounts).

3. Configurar os telefones IP para que eles suportem a mobilidade.
4. Criar as Remote Destination Profiles e vincul-las com cada usurio.
5. Adicionar os dispositivos remotos aos Remote Destination Profiles.
6. Configurar a agenda de toque (ring schedules) para cada dispositivo remoto.
7. Configurar as Access Lists.
8. Aplicar as Access Lists aos dispositivos remotos.
9. Configurar os demais parmetros do servio (Service Parameters).
Na sequncia vamos ver cada um dos passos da configurao e suas principais telas.
Configurao dos Templates de Softkey
O Mobile Connect requer que voc ative para os usurios que iro utilizar o recurso um softkey nos
telefones IP deles, abaixo seguem os passos:
1. V em "Device > Device Settings > Softkey Template".
2. Como j vimos anteriormente podemos selecionar, copiar e modificar um template existente ou

ento criar um novo. Em nosso exemplo vamos alterar um j existente clicando em Find com o
campo de busca vazio para mostrar todas as opes e depois clique no link do template chamado
Standard User - Lab DlteC.
3. No menu pull-down (canto superior direito) Related Tasks selecione a opo Configure Softkey
Layout e clique em Go.
4. Adicione o softkey de Mobility para os estados de ligao OnHook e Connected. Veja

as figuras 1 e 2 abaixo.
Figura 1
Figura 2
5. Clique em Save a cada configurao acima. Na figura aBAIXO veja a tela final com o Mobility
inserido no template para o estado de OnHook.
Caso o template j esteja aplicado a alguns telefones voc previsar tambm dar um Apply Config
para que o CUCMreinicialize os telefones que esto utilizando estes templates no final.
Uma vez finalizado, no telefone que tem aquele template deve aparecer o softkey configurado no
template quando ele est no gancho e com uma ligao estabelecida, veja afigura abaixo.
Se voc clicar agora no softkey Mobilityreceber um erro dizendo que seu usurio no vlido para o
Mobility, veja a figura abaixo, pois agora no prximo passo que faremos a configurao da conta do
usurio para esse recurso.
Criando User Accounts para o Mobility

Contas individuais devem ser habilitadas para utilizao do recurso de Mobility e algumas
configuraes devem ser ajustadas (tuned) para funcionarem corretamente. Vamos ver os passos
para criao e ajuste fino desses usurios para o Mobility:
1. V no menu User Management > End User e selecione um usurio (se no existir crie um novo).
Veja a figura abaixo, o processo semelhante ao anterior, muitas vezes no aparecero os usurios e
voc precisar clicar em Find com o campo de busca em branco para poder visualiz-los.
2. Selecione o checkbox Enable Mobility.

3. Configure o temporizador de Maximum Wait Time for Desk Pickup, o qual define quanto tempo
em milissegundos o usurio pode atender a chamada que foi redirecionada do dispositivo remoto
para o telefone IP. O padro so 10.000ms (10 seg) com um mximo de 30.000ms (30 seg).
4. Configure o nmero mximo de dispositivos remotos em Remote Destination Limit, onde o
mximo 10.
Veja as configuraes na tela da figura abaixo, porm quando voc clicar no link do End User voc
precisar rolar a pgina para baixo para visualizar as opes de mobilidade.
Configurando o telefone IP para Utilizar os Recursos de Mobilidade

Agora o usurio do telefone IP deve ser configurado para ser conectado s configuraes de usurio e
template de softkey que fizemos para o Mobility. Para fazer essa configurao siga os passos abaixo:
1. Coloque o Softkey Template que configuramos nos passos anteriores para adicionar no telefone
o boto de Mobility. Se voc escolheu um template que j estava configurado no telefone esse passo
no necessrio. Veja a tela da figura abaixo onde vinculamos o template ao telefone (Device >
Phone selecione o telefone ou crie um novo).
2. Coloque o User ID que criamos para ser o Owner do telefone (dono) - aquele que configuramos
com o recurso de mobility. Tambm aqui se o telefone j tinha um usurio bastava voc reconfigurlo e adicionar o recurso de mobility ao usurio que j era dono do telefone.
Veja a tela da figura abaixo que vamos ligar o telefone ao usurio dltec1 que configuramos
anteriormente.
Se voc tentar pressionar o boto de Mobility ainda no ir funcionar, agora vai aparecer um erro
conforme o telefone da figura abaixo:
Criando Remote Destination Profiles

Agora vamos criar os Remote Destination Profiles, fazer o vnculo deles com as contas de usurio e
garantir que as chamadas consigam alcanar os nmeros remotos:
1. V ao menu Device > Device Settings > Remote Destination Profile e clique em Add New.
2. Configure um nome (name) para o profile.
3. Selecione o User ID que ser associado a esse profile.
4. Selecione a opo de Rerouting Calling Search Space, a qual uma CSS que ir redirecionar as
chamadas aos dispositivos remotos e fornecer acesso aos nmeros desses dispositivos.
Adicionando Dispositivos Remotos aos Remote Destination Profiles

Agora vamos adicionar os Remote Destinations aosRemote Destination Profiles, definindo que
outros telefones sero acionados caso o usurio no esteja em seu telefone IP:
1. V no menu Device > Remote Destination e clique emAdd New.
2. Defina um nome.
3. Configure o nmero de destino (Destination Number), porm deve ser um nmero conforme voc
planejou no seu dial-plan com todos os cdigos de acesso necessrios, ou seja, como se voc fosse
digitar para ele a partir do seu telefone IP. Este nmero deve ser da rede PSTN.
4. Associe o Remote Destination Profile correto para o usurio. Aqui importante ter ateno porque
uma vez configurado no h alteraes, voc ter que deletar o Remote Destination e criar
novamente.
5. Selecione o checkbox Mobile Phone para permitir a troca manual de telefone utilizando o softkey
Mobility (chamado handoff).
6. Selecione o checkbox Enable Mobile Connect para incluir o Remote Destination na lista dos
telefones que iro tocar como linhas compartilhadas do telefone IP principal.
7. Em Association Information selecione uma ou mais linhas compartilhadas no Remote Destination
Profile. Essa tela aparece somente aps darmos um save na configurao incial.
Veja as figuras 1 e 2 com um exemplo dessa configurao at o passo 7. Na tela 1 temos a
configurao inicial onde vamos aplicar o primeiro Save, a na tela 2, aps esse primeiro save,
aparecer a sesso Association Information. Caso no aparea o DN clique no link e adicione o DN,
ele reconhece automaticamente um nmero j existente e preenche para voc, depois d um save e
volte para essa tela de configurao para selecionar o campo line association com a line
configurada.
Figura 1
Figura 2
Com essas configuraes o Mobile Connect j esthabilitado, veja teclando no softkey do telefone
conformefigura abaixo. Nos prximos passos vamos ver como fazer os ajustes finos e definir
permisses de acesso.
Agora com a configurao feita o funcionamento simples, segue abaixo:

1. O ramal com o Mobile Connect recebe uma chamada e voc no atende;
2. Aps o tempo configurado a chamada toca em seu celular ou outro dispositivo configurado;
3. Voc ter um tempo para atender, vamos supor que houve atendimento dentro do tempo:
a. Voc pode continuar falando e desligar, sem mesmo interagir com seu telefone IP ou
b. Voc pode comear a falar do celular e ir at a sua mesa para pegar a chamada com o telefone
IP
4. No caso da alternativa a acima basta falar e quando terminar desligar o celular;
5. Para capturar a chamada para o telefone IP, desligue o celular e com a tecla Resume no telefone
IP capture novamente a chamada para seu telefone IP (porm pode no ser instantneo)
Outra alternativa durante uma chamada em seu telefone IP passar a ligao para o celular utilizando
o Mobility, basta pressionar o softkey Mobility e escolher a transferncia para seu celular. Aps um
tempo o celular ir tocar, a basta voc atender para continuar a chamada.
Veja na figura abaixo um exemplo da tela de um telefone com uma chamada corrente e aps
pressionar o softkey Mobility vemos a opo de transferir a chamada para o telefone celular. Ao lado
temos um exemplo de retorno da chamada para o telefone IP, basta pressionar o softkey Resume.
Configurando as Agendas (Ring Schedules) por Destino Remoto

A configurao dos dias da semana e hora que o Mobile Connect deve chamar o dispositivo
remoto (Remote Destinations) na mesma tela do passo anterior, sendo a opo logo abaixo da
configurao geral. Para configurar devemos seguir os passos abaixo:
1. Definir os dias e horas que o dispositivo remoto deve tocar.
2. Selecionar o time zone correto daquele dispositivo.
Veja um exemplo na figura abaixo onde o Mobile Connect deve funcionar de segunda a sexta em
horrio comercial (das 8:30h s 17:30h).
Configurando as Access Lists

Para configurar as Access Lists (lembre que no tem nada haver com as ACLs do CCNA!) para limitar
que nmeros podem ou no fazer com que os Remote Destinations toquem:
1. V na tela Call Routing > Class of Control > Access List e clique em Add New.
2. Configure o nome da lista.
3. Defina o dono da lista (Owner User ID) a partir do menu pull-down. Isso define sobre que usurio
do Mobile Connect vamos aplicar essa Access List.
4. Escolha se a funo est Allowed (permitida) ou Blocked(bloqueada) nessa lista.
5. Clique em Save.
6. Quando a pgina voltar (der o refresh) na sesso Access List Member clique em Add Member,
conforme tela mostrada na figura abaixo.
7. Na tela de configurao do Access List Member Detail voc deve selecionar a mscara do filtro
(Filter Mask) atravs de uma das seguintes opes:
Directory Number: entre com um nmero de ANI ou uma mscara (wildcard pattern).
Private: para filtrar chamada onde o Caller ID no mostrado (chamadas que vem escrito
como privado no display).
Not Available: para filtrar chamadas que no possuem o Caller ID.
No campo DN Mask voc pode entrar com um nmero de telefone ou utilizar uma mscara com X
(fazendo correspondncia com um nico dgito) e ! (faz correspondncia com qualquer tamanho de
dgitos) para representar vrias entradas ou um nico destino (semelhante aos Route Patterns).
Veja o exemplo na tela da figura abaixo onde configuramos um nmero especfico. Ao clicar em save
voltamos tela anterior e o filtro criado aparece na Access List Member Information que estava
antes em branco, assim como no campo Access List Members.
Aplicando as Access Lists
As Access Lists criadas no passo anterior devem seraplicadas aos Remote Destinations conforme
passos abaixo:
1. V no menu Device > Remote Destination e selecione uma Remote Destination.
2. Selecione uma das opes:
Always ring this destination para no utilizar nenhuma lista de acesso.

Ring this destination if the caller is in para permitir os destinos da lista.
Do not ring this destination if the caller is in para bloquear os destinos da lista.
3. Para as duas ltimas opes do passo 2 escolha no menu pull-down a Access List que tem o filtro
correto configurado.
4. Clique em Save.
Veja um exemplo da tela de configurao na figura abaixo.
Configurando o Servio de Mobilidade (Service Parameters)

Algumas customizaes e ajustes finos nos parmetros do servio podem ser feitas para melhorar o
comportamentodo recurso de Mobility, para isso siga os passos abaixo:
1. V at a pgina System > Service Parameters, selecione o servidor que voc deseja configurar e
escolha o servio Cisco CallManager do menu pull-down.
2. V para baixo na pgina e procure a sesso Clusterwide Parameters (System - Mobility).
3. No campo Inbound Calling Search Space for Remote Destination escolha ou Trunk or Gateway
Inbound Calling Search Space (que o default e utiliza a CSS do trunk ou gateway que est roteando
as chamadas de entrada para aquele Remote Destination) ou Remote Destination Profile + Line
Calling Search Space (que utiliza uma combinao da linha e da Remote Destination Profile CSS).
4. No campo Matching Caller ID with Remote Destination selecione Complete Match (que o
padro e exige que o Caller ID de entrada seja exatamente igual ao nmero configurado como
Remote Destination) ou Partial Match, que permite voc escolher quantos dgitos do Caller ID voc
ter que fazer a correspondncia (match) comeando do dgito menos significativo (campo Number
of Digits for Caller ID Partial Match Required Field).
Veja a figura abaixo onde permitimos o match parcial quando os 8 dgitos menos significativos do
nmero de entrada (Caller ID) forem iguais ao remote destination.
5. V mais para baixo na tela em Clusterwide Parameters(Feature - Reroute Remote Destination

Calls to Enterprise Number).
6. Configure o Reroute Remote Destination Calls to Enterprise Number para True/Verdadeiro (o
default False/Falso) para fazer com que as chamadas possam ser redirecionadas para um Remote
Destination que seja um telefone IP, permitindo que os usurios tirem mais vantagens dos recursos
de mobilidade.
7. Configure tambm o parmetro Ignore Call Forward All on Enterprise DN para True/Verdadeiro,
possibilitando que as chamadas seja direcionadas para os Remote Destinations mesmo que os
telefones IP tenham o CFA (Call Forward all) ativado. Veja um exemplo da tela na figura abaixo com as
configuraes dos itens 5 a 7.
Configurando o MVA
Vamos nos prximos slides ver como configurar o MVA (Mobile Voice Access), tambm chamado de
DISA. Os passos necessrios esto descritos abaixo:
Configurao do MVA:
1. Ative o servio MVA na interface de Serviceability.
2. Configure os parmetros do servio.
3. Habilite o MVA para cada usurio.
4. Configure os recursos de mdia (MVA media resource).
5. Configure o gateway para suportar a aplicao do MVA em VXML.
Na sequncia veremos mais detalhes.
Ativando o Servio de MVA
O recurso de MVA no vem habilitado por padro, por isso voc precisa habilit-lo para que a
facilidade possa ser utilizada. Veja os passos abaixo:
1. V at a tela Unified Serviceability > Tools > Service Activation.
2. Selecione o Cisco Unified Mobile Voice Access Service.
3. Clique em Save.
Configurando o Servio de MVA

Agora que ativamos o servio do MVA vamos habilit-lo para o cluster (ou para o servidor caso tenha
um s). Veja como abaixo:
1. V at a interface Unified CM Administration > System > Service Parameters.
2. Selecione o servidor que voc deseja configurar o MVA e logo abaixo selecione o servio Cisco
CallManager Service.
3. V mais para baixo na tela e procure a sesso Clusterwide Parameters (System - Mobility).
4. Altere o valor do parmetro Enable Mobile Voice Access para True.
5. Modifique os demais parmetros conforme necessidade e clique em Save.
Note que habilitamos o MVA de maneira global, porm precisaremos ativar em cada usurio para que
o servio realmente funcione.
Habilitando o MVA por Usurio

Agora que habilitamos o servio de MVA globalmente, vamos ativar esse recurso para
cada usurio conforme necessidade:
1. V at a pgina do usurio que voc deseja habilitar o MVA em User Management > End User e
selecione o usurio desejado da lista.
2. V para baixo na pgina do usurio e procure a sesso Mobility Information.
3. Marque a caixa Enable Mobile Voice Access, conforme figura abaixo:
4. Verifique se o Remote Destination Profile listado est configurado corretamente para solicitar
autenticao. Voc pode selecionar o profile e clicar em View Details na caixa logo abaixo da
configurao anterior.
Lembre que a autenticao configurada com o PIN dentro do End User, que est vinculado ao
Remote Destination Profile.
As demais configuraes de parmetros, como usurios e os Remote Destination Profile continuam
as mesmas que vimos no captulo anterior para o Mobile Connect.
Configurando o MVA Media Resource
Os recursos de mdia (MVA media resource) so automaticamente criados quando ativamos o
servio, para configurar manualmente ou alterar as configuraes siga os passos abaixo:
1. V at a pgina Media Resources > Mobile Voice Access.
2. Digite o nmero que ser o Mobile Voice Access Directory Number, utilizado internamente para
que o gateway H.323 MVA encaminhe as chamadas recebidas da PSTN que esto querendo acessar
o recurso de MVA. No passo seguinte vamos configurar no gateway um dial peer para esse nmero,
ligando o nmero PSTN do MVA com o MVA do servidor CUCM.
3. Defina uma Partition se necessrio, conforme sua implementao. Essa partition deve estar
na CSS do gateway MVA.
4. Configure as localidades (Locales isso opcional) para que o IVR do MVA suporte mltiplos
idiomas.
5. Clique em Save.
Configurando a aplicao VXML do MVA no Gateway de Voz
O gateway H.323 deve ter as configuraes abaixo em suas linhas de comando.
Agora quando uma ligao vier para o nmero04130453456 ela ser encaminhada ao CUCM e
aaplicao VXML vai acionar os recursos necessrios para que o MVA seja estabelecido com sucesso.
Porm, aligao deve ser realizada do celular configurado como Remote Destination, uma vez
recebida a ligao pelo sistema voc entra em um IVR que perguntar o nmero do Remote
Destination, o PIN configurado na tela de End User que est vinculado a esse profile e depois viro as
opes dos recursos que voc poder utilizar, por exemplo, fazer uma ligao.
Lembre que para fazer uma ligao voc deve utilizar as regras de discagem como se estivesse
fazendo a partir do seu prprio telefone IP, por exemplo, se para alcanar um nmero PSTN local voc
configurou o dgito de acesso 0 ter que discar 030457810 para discar para o destino 30457810.
Note tambm que os exemplos levam em conta que estamos trabalhando com nmeros PSTN DID
(DDR discagem direta a ramais), ou seja, voc consegue acessar diretamente da PSTN os ramais
internos da empresa.
Cisco Unity Connection Recursos, Facilidades e Integrao com CUCM
O Cisco Unity Connection (CUC) um sistema completo de mensagens de voz (voice-messaging) e
reconhecimento de voz (voice-recognition system), capaz de prover acesso irrestrito a chamadas e
mensagens para at 20.000 usurios quando utilizado em apenas um servidor (single hosted) CUC
verso 8.x (contando que est em uma plataforma de hardware compatvel com as necessidades de
memria e processamento para esse nmero de usurios).
O Cisco Unity Connection fornece mensagens instantneas integradas para ajudar os funcionrios a
controlar as mensagens e ficarem atualizados a respeito de todas as comunicaes atravs do
telefone ou PC, ou ambos. Alm disso, o Cisco Unity Connection oferece uma grande variedade de
recursos, tais como os mostrados abaixo:
Recursos CUC:
Comandos de voz (pausar, retomar, repetir, avanar, excluir, salvar, escutar horrio ou dia, passar
para frente ou retroceder) para acessar mensagens ou diretrios.
Controle de volume e velocidade durante a reproduo da mensagem.
Marcar as mensagens como normal, urgente, privada ou segura.
Gravar conversas ao vivo e enviar o arquivo de udio para um correio eletrnico.
Integrao com o Cisco Unified MeetingPlace Express para que os funcionrios verifiquem se h
conferncias e possam ser transferidos diretamente para uma conferncia sem tocar no teclado.
Acesso a mensagens de e-mail via telefone (exige integrao com o Microsoft Exchange).
Rede opcional com outras solues de correio de voz da Cisco para que os usurios de sistemas
diferentes possam se comunicar de forma transparente.
A facilidade do reconhecimento de voz (comandos de voz) pode ser utilizada tanto por usurios
internos como externos (que no fazem parte da empresa e esto ligando para um usurio da
empresa). Alm disso, o CUC possui um servidor IMAP interno que permite acesso s mensagens de
voz atravs de e-mail e uma interface web para que as mensagens possam ser acessadas de qualquer
browser, sem a necessidade da instalao de um software cliente na mquina do usurio.
Viso Geral do Cisco Unity Connection
O CUC um dos cinco produtos da famlia de comunicao unificada da Cisco que oferecido como
um appliance Linux (os outros quatro so: Cisco Unified Communications Manager [CUCM], Cisco
Unified Presence [CUP], Cisco Emergency Responder e Unified Contact Center Express [CCX]).
Clique no cone "Informaes adicionais" ao lado para mais informaes sobre o termo appliance.
Os dados e as mensagens so armazenados em uma base de dados local no servidor CUC, utilizando
uma instncia da aplicao Informix Database Service, assim como nas outras aplicaes dos
produtos da famlia Unified Communications.
O CUC pode ser integrado de diversas maneiras com PABX IP nativo (como o CUCM) ou com PABX
convencional atravs de circuitos digitais TDM conectados diretamente ao PABX utilizando os IP
Media Gateways, que convertem a sinalizao e voz convencional analgica ou digital em um SIP
Trunk, os quais podem ser de dois tipos:
PBX IP Media Gateway (PIMG pode ser conexo analgica ou digital com o PABX) ou
T1 IP Media Gateway (TIMG conecta-se utilizando T1 com o PABX).
Veja a figura abaixo ilustrando essa conexo.
Sobre a administrao de usurios no CUC, ela pode ser feita de maneira manual, em massa (bulk
importao via arquivo Comma-Separated Values CSV), importados do CUCM ou via sincronizao
com um sistema Lightweight Directory Access Protocol (LDAP). Assim como no CUCM, a autenticao
da senha do CUC pode ser redirecionada ao sistema LDAP para manter a funcionalidade de single
sign-on da rede, ou seja, um usurio nico para acessar todos os recursos de rede.
Um recurso muito til do CUC que ele pode se integrar com um servidor Microsoft Exchange
utilizando Web-Based Distributed Authoring and Versioning (WebDAV) para fornecer informaes
integradas sobre calendrios (agendamentos) e jornal, possibilitando a integrao com o Cisco Unified
MeetingPlace e Cisco Unified MeetingPlace Express, Microsoft Exchange 2003 e regras de roteamento
de chamadas dentro do prprio CUC. J a integrao de calendrio com o Microsoft Exchange 2007
deve ser realizada utilizando aplicaes web e interfaces de programao (web services application
programming interface - API).
O CUC fornece a interface tradicional para usurios (Telephone User Interface - TUI) para interao via
Dual-Tone Multi-Frequency (DTMF) com os telefones (apenas pressionando os botes dos telefones),
interface de voz (Voice User Interface - VUI) para interaes via comando de voz (hands-free
interaction comando de voz) e atravs de um servio direto no telefone IP chamado Voice View
Express para visualizar o cabealho das mensagens de voz na tela dos telefones IP ou no Cisco
Unified Personal Communicator (CUPC).
Informao extra:
A traduo mais simples para este tema simplesmente "ferramenta", ou seja, uma caixa preta que
no seu interior tem vrios componentes integrados. No mundo da informtica, os Appliances so
computadores pr-configurados para executar uma tarefa especfica, como servir para compartilhar a
conexo com a Web ou como um firewall para a rede, como um kiosque multimdia, como um
sistema de caixa registradora e leitor de cdigo de barras, um centro de multimdia, um centro de
controle de um sistema de automatizao domstica e assim por diante. As possibilidades so quase
infinitas.
Ao contrrio do que pode parecer, os Appliances nem sempre so dispositivos complicados de
construir. Pelo contrrio, na maioria das vezes temos um PC comum, montado em algum tipo de
gabinete especial, acoplado num leitor de cdigo de barras ou o que mais for necessrio para
executar suas tarefas, rodando uma instalao personalizada do Linux. Muitos mantm um servidor
Apache ativo, para que o usurio possa fazer toda a administrao via rede.
Instalaes Single-Site e Multisite

A maneira mais simples de instalar o CUC utilizando o modelo single-site ou site-nico, com
toda empresa ou campus acessando um nico servidor CUC ou par de servidores redundantes. O que
torna esse modelo mais atrativo a simplicidade do projeto, utilizar apenas um codec para todas as
chamadas e reduo considervel nas tarefas de implementao do sistema. Veja abaixo com um
exemplo de implantao single-site.
Se a empresa tiver diversas localidades a topologia multi-site pode ser uma escolha mais apropriada
para a implementao do Unity Connection, pois isso poderia reduzir o consumo de banda que os
usurios utilizam da WAN para ler ou deixar suas mensagens, assim como economizar recursos de
transcodificao de codec (transcoder resources). Essa preocupao deve ser levada em conta
quando h um acrscimo do nmero de usurios com o recurso de voicemail habilitado, pois em
muitas empresas esse um recurso disponibilizado somente para um nmero restrito de funcionrios
e no para todos, mas cada caso deve ser tratado conforme necessidade de projeto. Portanto,
posicionar servidores adicionais nas localidades remotas pode reduzir o impacto sobre a WAN
produzido pelo fluxo das mensagens de voz e manter as mesmas caractersticas do modelo single-site.
Viso Geral sobre Integrao do CUC
A integrao que nos referimos aqui nada mais que ainterconexo do CUC com um PABX ou com
um sistema de telefonia IP (IP-based telephone system).
Para isso, o CUC consegue trabalhar com diversos protocolos e padres de integrao, tais como
SCCP, SIP ou PIMG/TIMG. Portanto, podemos ter diversos sistemas telefnicos conectados ao CUC
simultaneamente, por exemplo, um CUCM ou CME pode ser conectado via SCCP ou SIP, um PABX com
suporte a SIP pode ser integrado utilizando um SIP trunk e alguns PABX digitais suportam a utilizao
de dispositivos PIMG ou TIMG para converter os circuitos digitais TDM em um SIP trunk, tornando
possvel a comunicao com o CUC.
Integrao CUCM x CUC:
Mais especificamente o CUCM pode ser integrado ao CUCvia SCCP ou SIP. Por ser proprietrio da
Cisco, a integrao via SCCP mais simples que via SIP, mas nada que inviabilize sua utilizao.Vamos
na sequncia analisar mais a fundo a integrao CUC-CUCM.
Integrando o CUC com CUCM via SCCP
Para integrar o CUCM ao CUC voc precisar fazerconfigurao em ambos sistemas, porm
normalmente iniciamos com o CUCM.
A configurao no CUCM pode se realidade utilizando a ferramenta de Voicemail Port Wizard que
est disponvel para as verses 8.x e simplifica bastante o processo de integrao, veja a telas
das figuras 1 e 2.
Figura 1
Figura 2
Na figura 2, quando voc clicar em Next vai aparecer um nome padro CiscoUM1 para as portas,
esse nome o que ir vincular as portas no CUC, guarde esse nome em caso de voc alter-lo. Esse
wizard ir solicitar algumas informaes do usurio que est configurando o sistema para gerar as
portas (voicemail ports) e adicion-las a um Line Group no CUCM. A partir desse passo o
administrador ter que criar manualmente um Hunt List e um Hunt Pilot para suportar esse Line
Group.
Aps a sua criao o Hunt Pilot deve ser referenciado a umVoicemail Pilot, o qual vinculado a um
Voicemail Profile. A figura abaixo ilustra essa arquitetura de integrao do voicemail integration no
lado do CUCM.
Note que a criao das entidades que fazem parte das portas na realidade de baixo para cima, voc
inicia com as portas e termina com o Voicemail Profile.
Existem entradas padro para o voicemail profile e voicemail pilot que so utilizadas para todos os
usurios no CUCM, utilize esses padres somente fazendo a alterao para o nmero do piloto que
voc criou no Hunt Pilot nesse padro existente no sistema, porm voc pode criar outros para
integrar por tipo de usurio, por exemplo, ou com outros sistemas. Esses padres esto nos dois
ltimos menus mostrados na figura abaixo em Advanced Features.
Cuidado com alguns erros comuns cometido na hora da integrao do CUCM-CUC com SCCP. Veja
abaixo:
Integrao - Erros:
Esquecer de vincular ou criar o Voicemail Pilot (ou alterar o default do sistema) e vincular ao Hunt
Pilot criado para as portas de voicemail.
Aps essa etapa criar um Voicemail Profile e vincular ao Voicemail Pilot (ou vincular o padro do
sistema alterado ao profile padro j existente).
Esquecer um desses passos faz com que o boto de mensagens (Messages button) do telefone no
funcione, apesar de voc conseguir discar para o nmero do Hunt Pilot diretamente e chegar at o
CUC.
No lado do servidor CUC o nmero de portas disponveis limitado pelo hardware do servidor (sua
capacidade de processamento e armazenamento) e pelas licenas instaladas. Cada porta no CUC pode
ser configurada para diferentes tipos de comportamento ao receber as chamadas, incluindo que porta
deve atender as chamadas, realizar avisos via Message Waiting Indicator (MWI indicador ou
notificao de mensagem, na prtica um led ou lmpada no telefone) e outras funes. O
roteaemento das chamadas no CUC pode ser controlado tanto pelo sistema de telefonia (phone
system) ou pelo port group.
As mensagens de alerta visual sobre a existncia de uma mensagem em seu correio de voz ou MWI
utilizam nmeros separados (DN), um para MWI On e outro MWI Off. Os DNs devem bater tanto
no CUCM como no CUC, se esses nmeros forem diferentes no ir funcionar. Um teste que voc
pode fazer discar para o nmero do MWI On de um usurio e o led indicativo de mensagem deve
acender no telefone dele (MWI light), ao discar o nmero do MWI off a lmpada vai apagar.
Se voc utilizar a integrao com Skinny Client Control Protocol (SCCP) segura (utilizando certificado
digital) o SCCP ser enviado pela porta 2448, j o inseguro (Nonsecure SCCP) utilizar a porta 2000.
Integrando CUC via SIP
A configurao da integrao via Session Initiation Protocol (SIP) um pouco diferente do que
fizemos para o SCCP no lado do CUCM, pois ao invs do piloto do voicemail apontar para um Hunt
Pilot, ele vai apontar para um Route Pattern, que por sua vez aponta para um SIP trunk, o qual
configurado para conectar ao CUC.
Alm disso, o nmero de portas no mais definido no servidor CUCM como fizemos na integrao
via SCCP, ao invs disso definido apenas no CUC. Cada porta configurada para registrar em um
servidor SIP, o qual um servidor CUCM.
Mais uma diferena na integrao via SIP que no existem DNs para o MWI On/Off (ligar e desligar o
led de aviso de mensagem), pois o SIP trata por si s essa sinalizao do estado da lmpada de MWI.
O SIP pode utilizar segurana atravs da porta 5061 ou se comunicar de maneira insegura (Nonsecure
SIP) pela porta 5060. A figura abaixo representa a integrao do CUCM ao CUC via SIP no lado do
CUCM.
Portanto aqui na integrao com o SIP vamos criar um SIP Trunk, associar ele a um Route Pattern,
depois vincular esse Route Pattern a um piloto do voice mail e para finalizar vinculamos esse piloto a
um profile de voice mail. Lembre que na prtica a criao no caminho inverso do que explicamos no
primeiro pargrafo, porm iniciamos daquela maneira para ficar mais simples a comparao com a
integrao via SCCP.
Outro ponto importante que no existe wizard para criao das portas via SIP para integrao no
lado do CUCM.
Recursos do Cisco Unity Connect
Vamos descrever aqui nesse tpico de maneira sistmica alguns dos recursos e configuraes do
sistema como um todo do CUC.
Lembrem que a implementao completa de um CUCM ou CUC sero estudadas com mais
profundidade no CCNP Voice, no sendo foco esmiuar esses detalhes aqui no CCNA de Voz.
Recursos CUC:
Configuraes do Sistema
Call Handlers
Call Routing Roteamento de Chamadas
Distribution Lists Listas de Distribuio
Authentication Rules Regras de Autenticao de Usurio
Dial-Plan - Plano de Discagem
Configuraes do Sistema
A instalao e configurao do CUC composta por diversas configuraes do sistema. Devido ao
contedo do exame ICOMM ter o escopo relativamente limitado vamos focar no que mais
importante para a prova e o dia a dia de um CCNA de Voz.
Veremos os itens citados abaixo:
Configuraes:
Configuraes Gerais
Roles - Funes
Enterprise Parameters e Service Parameters
LDAP
Configuraes Gerais
As pginas de configuraes gerais (General Configuration) incluem os padres para o sistema de
Time Zone, idioma (Language) e tamanho mximo para as mensagens de boas vindas (Maximum
Greeting Length). Veja a tela na figura abaixo:
Obs: o Time Zone foi configurado na instalao do sistema.
Roles - Funes
A pgina de Roles tem uma lista de nove perfis administrativos (administrative roles) definidos na
aplicao, as quais limitam os poderes e capacidades administrativas para os usurios. Abaixo
seguem as funes definidas para o CUC, conforme tela na figura abaixo:
Audio text administrator

Audit administrator
Greeting administrator
Help desk administrator
Mailbox access delegate account
Remote administrator
System administrator
Technician
User administrator
Obs: dependendo da verso utilizada do CUC o nmero de perfis administrativos pode variar.
Enterprise Parameters e Service Parameters / LDAP
Enterprise Parameters e Service Parameters:
Tem equivalncia s mesmas pginas do CUCM. Elas definem parmetros e permitem ajustes finos
(tune) no sistema e servios, tais como User Web Pages, Quality of Service (QoS) para trfego gerado
pelo CUC e assim por diante.
LDAP:
Essa pgina define a integrao com um sistema de LDAP permitindo a sincronizao dos usurios e
como opcional a autenticao, assim como para o CUCM. Veremos mais detalhes do LDAP
posteriormente.
Call Handlers
Esse um importante componente, pois todas as chamadas de entrada em direo ao CUC so
tratadas por uma srie de call handlers. Existem trs tipos bsicos de call handlers, os quais so
mostrados abaixo:
Call Handlers:
1. System Call Handlers: so utilizados para as mensagens de boas vindas (greetings) e podem ser
customizadas para oferecer opes de entrada para os usurios, por exemplo, como em um nmero
de autoatendimento bancrio (Para verificar seu saldo, tecle 2...), e automaes como, por
exemplo, tocar mensagens de boas vindas (greeting) diferente quando o estabelecimento ou empresa
estiver fora do horrio de funcionamento ou fechada.
2. Directory Handlers: permite que o usurio que est ligando (caller) procure no diretrio do CUC
pelo usurio que ele deseja entrar em contato aps enviar uma mensagem, por exemplo. Voc pode
definir diretrios distintos por localidade, listas de distribuio (distribution list membership), etc.
3. Interview Handlers: fornece uma mensagem gravada ao usurio (caller) perguntando alguma
informao e depois grava o que o usurio respondeu em uma nica mensagem. Os Interview
Handlers podem ser utilizados para qualquer tipo de relatrio baseado em um sistema telefnico,
para quase qualquer propsito, como por exemplo, automatizar candidaturas a vagas de emprego.
Temos trs sistemas de Call Handlers que so definidos por padro:
1. Goodbye Call Handler
2. Opening Greeting
3. Operator Call Handler
Veja a figura abaixo com uma tela das configuraes do System Call Handlers.
O Opening Greeting aquilo que uma pessoa de fora do sistema (de outra empresa que no tem
um voicemail box ou caixa de correio de voz no servidor CUC configurado) ouve.
Essa mensagem pode ser customizada para atender os padres de cada empresa. Veja um exemplo
da tela do openning greeting na figura abaixo:
Call Routing Roteamento de Chamadas

O CUC utiliza normalmente dois critrios primrios nativos para fazer o roteamento de uma
chamada:
1. A aplicao identifica chamadas diretas (direct calls usurio disca para acessar seu correio de
voz) ou
2. Chamadas encaminhadas (forwarded calls nmero externo que ligou para um usurio que
est no telefone, por exemplo, e encaminhado para o correio de voz desse usurio).
Uma Direct Call acontece quando um usurio disca para o sistema do CUC diretamente atravs
do botoMessages no seu telefone IP, discando o piloto do voicemail manualmente ou discando
para o nmero PSTN reservado na faixa do Direct Inward Dial (DID ou DDR Discagem direta a ramal)
para o autoatendimento do CUC, recurso conhecido como Auto-Attendant.
Assim que o sistema recebe essa chamada, ele avalia a informao recebida e roteia a chamada para
uma porta do CUC que responde a essa chamada. A informao disponvel para que o CUC tome uma
deciso sobre o que fazer com a chamada (para onde encaminhar) inclui:
Calling number (quem est chamando)

Called number (nmero de quem est sendo chamado)
Forwarding station (dispositivo de encaminhamento)
Phone system/port (sistema de telefonia e porta)
Schedule (agenda)
Duas regras so definidas abaixo de cada categoria de regra de roteamento de chamadas (call routing
rule), vamos estudar daqui a pouco o que isso significa, agora veja a figura abaixo com
as condies que podemos utilizar nas regras e as aes que podem ser tomadas com a chamada.
Essa figura significa que assim que o CUC receba a chamada ele pode utilizar como condio os
parmetros que esto abaixo das Rule Conditions (regras condicionais) e uma vez essa condio
atendida definida uma Call Action, ou seja, uma ao com a chamada que pode ser enviar para um
Call Handler ou iniciar uma conversao (conversation o CUC utiliza mensagens de voz para pedir
informaes) ou enviar o usurio para seu mailbox (User With Mailbox).
Direct Routing Rules - Regras de Roteamento para Chamadas Direta ao CUC
Para chamadas feitas diretamente ao CUC temos duas regras padres que podem ser aplicadas:
1. Attempt Sign-In: nesse caso se o nmero discado reconhecido como um DN primrio (primary
DN) associado a uma caixa de correio de voz (voicemail box), ento a chamada encaminhada para o
Attempt Sign-In Conversation (um autoatendimento solicitando informaes) e a pessoa que est
discando recebe uma mensagem de voz dizendo para digitar seu PIN para logar em sua caixa de
correio de voz.
2. Opening Greeting: se o nmero que discou diretamente para o sistema de correio de voz no est
associado com uma caixa de correio de voz (voicemail box) no servidor CUC, a chamada enviada
para o Opening Greeting.
Veja a figura abaixo com a tela de configurao das direct call rules, basta clicar na regra para alterar
ou configurar novas condies.
Voc pode utilizar regras adicionais definidas pelo administrador, as quais sero processadas de cima
para baixo (top-down), por isso a ordem das regras fundamental. As regras adicionais podem
definir, por exemplo, o roteamento de chamadas fora do horrio comercial, que forem feitas para o
nmero do atendimento ao cliente, para um call handler especfico que tem uma mensagem gravada
para essa situao, informando ao cliente como ele deve proceder ou avisando qual o horrio de
atendimento.
Forwarded Routing Rules - Regras de Roteamento para Chamadas Encaminhadas ao CUC
Para chamadas encaminhas ao CUC, aquelas que no foram atendidas pelos usurios (ou porque eles
estavam no telefone ou simplesmente no foram atendidas), seguem as duas regras por padro
abaixo:
1. Attempt Forward: se o nmero discado tem uma caixa de correio associada a ele no CUC, essa
chamada encaminhada para essa caixa de correio e quem discou ouve a mensagem pessoal gravada
pelo usurio (users personal greeting).
2. Opening Greeting: se o nmero encaminhado no tem caixa de correio de voz (voicemail box)
associado no CUC quem discou ouve uma mensagem padro definida no Opening Greeting.
Veja na figura abaixo a tela do FORWARDED ROUTING RULES, onde voc pode clicar em uma regra
para configur-la ou adicionar uma nova.
Filtros para "Call Routing Rule"

Quando voc configura uma call routing rules customizada, seja ela para Direct ou Forwarded calls,
podemos utilizar as seguintes opes para esses filtros (pode ser uma nica opo ou uma
combinao delas):
Calling number (nmero de quem est chamando)

Called number (nmero chamado)
Voicemail port (porta do correio de voz)
Phone system
Chamadas encaminhadas (vale apenas para forwarded calls)
Schedule (sistema de agendamento)
Essas regras permitem que os administradores criem roteamento customizado para chamadas, dando
ao sistema muito mais capacidade e flexibilidade. Veja um exemplo na figura abaixo da tela de
configurao de uma regra para chamadas encaminhadas. Para chegar nessa tela voc deve
selecionar abaixo de Call Routing um dos dois menus (direct ou forwarded calls), clicar em uma das
regras existentes e rolando a pgina para baixo voc encontrar as Routing Rule Conditions.
Clicando em Add New chegar nessa tela.
Um ponto importante que essas regras de roteamento que estamos tratando vale somente para as
chamadas atendidas pelo CUC. Por exemplo, um cliente liga para seu ramal IP e voc no atende a
chamada, como voc tem caixa de correio de voz configurada a chamada ser atendida pelo CUC, a
no ser que outra ao foi configurada no Call Forward Busy ou No Answer na pgina de configurao
do seu telefone IP no CUCM.
Lembre que a configurao de encaminhamento de chamadas em caso de no-atendimento (no
answer) ou ocupado (busy) definida no CUCM, mais especificamente no DN do seu telefone. Para
configurar no telefone IP dentro do CUCM o encaminhamento para o Voicemail v at a pgina de
administrao no menu Call Routing > Directory Number e clique no DN que voc deseja configurar
(voc pode chegar a essa tela tambm indo em Device > Phones, clique em um telefone e depois no
DN), conforme tela da figura abaixo:
Distribution Lists Listas de Distribuio

As Distribution Lists (DL ou Listas de Distribuio) podem ser utilizadas para enviar de uma maneira
simples mensagens de voz para um grupo de usurios. Podemos configurar dois tipos de DL:
1. System DLs: so listas do sistema e gerenciadas apenas pelo administrador, o qual pode fazer com
que essa lista seja disponibilizada para todos os usurios ou apenas para alguns usurios, conforme
necessidade.
2. Private DLs: estas listas so gerenciadas e mantidas pelo usurio e podem ser utilizadas apenas por
esse usurio que criou a lista. O administrador pode definir um limite de quantas listas os usurios
podem criar e quantos contatos podem inserir por lista, pois as listas podem acabar virando um SPAM
na mo de usurios mal intecionados.
Veja um exemplo na figura abaixo da tela de configurao das listas de distribuio do sistema, onde
temos uma lista criada pelo administrador chamada Lista_CCNA_Voice_DlteC, as demais so listas
padro do sistema.
Authentication Rules Regras de Autenticao de Usurio

Para configurar os parmetros de segurana para acesso ao sistema do CUC, regras de autenticao
para o Voicemail (acesso de usurio TUI via PIN) e Web Application (para acesso User Web Pages
pgina de usurio) podemos utilizar as Authentication Rules. Podemos configurar parmetros
como:
Quantas falhas no login so aceitas antes de bloquear a conta (account lock-out);

Quanto tempo um usurio fica bloqueado;
Nmero mnimo de caracteres na senha;
Periodicidade para troca de senha;
Verificar a segurana das senhas (trivial passwords), e algumas outras opes.
O sistema j tem regras padres criadas (default AuthenticationRules), as quais so aplicadas a todos
os usurios, essa uma configurao global do sistema. Voc pode alterar os padres do sistema ou
ento criar novas Authentication Rules customizadas para atender necessidades de segurana da
empresa e aplic-las aos User Templates ou para usurios individuais (um a um). Podemos, por
exemplo, ter uma configurao geral com 5 dgitos e configurar uma nova com 4 dgitos, depois
aplic-la a um novo User para ter usurios com regras de senha diferentes.
Se voc for ao menu System Settings > Authentication Rules logo aps instalar o sistema ver que
temos duas regras padres do sistema:
1. Recommended Voice Mail Authentication Rule (regra padro para voicemail)
2. Recommended Web Application Authentication Rule (regra padro para acesso Web User
Page)
Veja na figura abaixo a tela de exemplo quando clicamos na opo Recommended Voice Mail
Authentication Rule.
Dial-Plan - Plano de Discagem

No Cisco Unity Connect tambm temos o conceito dePartitions e Search Spaces implementado de
maneira semelhante ao do CUCM, sendo que:
Objetos que podem receber chamadas tais como uma caixa de correio de um usurio ou um
call handler, podem ser associados a uma Partition.
Objetos que podem realizar ou transferir chamadasso associados a um Search Space.
Um objeto chamado deve estar em uma das Partitions listadas no Search Space do objeto que est
fazendo a chamada. Por padro um Search Space criado pelo sistema contendo uma Partition
padro, permitindo acesso e alcance a todos os objetos at que o administrador faa as
customizaes do sistema conforme necessidade de cada empresa ou projeto. Veja
na figura abaixo um exemplo da tela de configurao das Partitions com o default do sistema.
Utilizando esse recurso possvel limitar acesso de usurios a determinados grupos, por exemplo,
criando um directory handler para o escritrio central e limitando a Search Space desse directory
handler para incluir apenas a partition do prprio escritrio central, fazendo com que a busca nesse
diretrio liste apenas usurios vinculados Partition do escritrio central.
Conceitos sobre Usurrios e Mailboxes no Cisco Unity Connection
Os sistemas e componentes que vimos nos tpicos anteriores desse captulo fazem parte das
configuraes gerais e preparao do sistema para receber as chamadas do correio de voz e
integrao com outros sistemas.
O que vimos at agora a base para que possamos implementar o mais importante do sistema usurios e caixas de correio de voz - pois sem eles o sistema ter a funcionalidade limitada,
concorda?
Vamos nesse tpico estudar os conceitos sobre os usurios e caixas de correio para que em seguida
possamos ver como implementar o bsico, pois lembrem que o CCNA Voice tem o escopo limitado
sendo o foco principal que o aluno entenda os conceitos e consiga navegar pelo sistema.
User Templates
Os User Templates so padres utilizados para criao de novas contas de usurio, assim como no
CUCM utilizamos padres (templates) para criar telefones e outros componentes o CUC tambm
disponibiliza esse recurso para facilitar a criao das contas de usurios. Os templates permitem
definir a maioria das configuraes comuns que devem ser utilizadas em todos os novos usurios e
aps a criao desses usurios voc pode fazer o ajuste fino em algumas configuraes, acelerando e
dando mais preciso ao processo de criao como um todo.
O template aplicado somente na criao do usurio, sendo que se voc mudar o template ele no
afetar as contas j criadas, somente as novas que forem criadas aps a alterao do template.
Temos dois User Templates padres que so criados na instalao do sistema, os quais voc pode ver
abaixo:
User Templates Padro:
1. Template de administradores (administrators)
2. Template de usurio (users)
Voc pode modificar esses templates padres do sistema ou criar outros para atender as
necessidades da sua implementao.
Vamos ver a seguir algumas opes do template, porm como so muitas opes vamos focar
nas mais importantes para o CCNA Voice.
User Template Basics
Os elementos bsicos da configurao de um template de usurio (User Template) so:
Name: define o nome do template. Voc pode configurar tambm o apelido (Alias) e nome
mostrado (Display Name generation) para as contas de usurios. O padro o primeiro nome
(first name) seguido do sobrenome (last name).
Phone: aqui vamos configurar o Dial-Plan (Partition/Search Space), Class of Service (CoS) e
Schedule (agenda).
Location: nessa sesso podemos configurar a localizao geogrfica do usurio, idioma
(language localization) e time zone.
O CoS no CUC um mtodo de associar e limitar os privilgios dos usurios (no confunda com a
marcao de QoS de camada 2 e nem com a Class of Control do CUCM). O CoS permite configurar as
mensagens (greeting) e tamanho delas, recursos que necessitam de licenas (licensed feature access),
recursos avanados de acesso, configurao de um ramal alternativo, Private DL, limites de
membership e capacidade de fazer transferncias de chamadas.
Voc pode criar um nmero ilimitado de CoS para que possa atender todas as combinaes de
habilidades e recursos para todos os tipos de usurios conforme necessrio.
A figura abaixo representa a lista de facilidades que podem ser configuradas no CoS.
Senhas
Nessa pgina em questo voc pode realizar as seguintes tarefas:
bloquear e desbloquear (lock / unlock) uma conta,

controlar se a senha deve ser trocada e com que periodicidade e
definir a regra de autenticao (Authentication Rule).
Obs: Voc pode tambm configurar esses parmetros tanto para a senha do Voicemail como para o
acesso via Web.
Roles - Funes
As Roles j foram estudadas anteriormente nesse captulo no item 1.4.1 (Roles - Funes) e so as
mesmas. Vamos repetir a explicao aqui.
A pgina de Roles tem uma lista de oito perfis administrativos (administrative roles) definidos na
aplicao, as quais limitam os poderes e capacidades administrativas para os usurios. Abaixo
seguem as funes definidas para o CUC, conforme tela na figura abaixo:
Audio text administrator

Greeting administrator
Help desk administrator
Mailbox access delegate account
Remote administrator
System administrator
Technician
User administrator
Transfer Rules e Greetings Regras de Transferncia e Saudaes

Temos trs transfer rules (regras de transferncia) definidas por padro (default) pelo sistema:
Standard rule: essa regra no pode ser modificada, somente podendo ser ativada e desativada.
Alternate rule: essa regra pode ser modificada para ser ativada com diferentes agendas ou
uma data especfica para acabar.
Closed rule: fica ativa somente durante perodos fechados de horas.
Estas regras podem ser aplicadas para determinar o comportamento do mailbox do usurio, incluindo
a saudao (greeting) que a pessoa que est discando para o usurio ir ouvir.
Temos as seguintes saudaes (greetings) possveis de serem configuradas:
Alternate: utilizada para personalizao do voicemail box (caixa de correio) com uma
mensagem do usurio (custom greeting).
Busy: tocada quando a extenso do usurio est ocupada (busy).
Internal: toca para nmeros internos (para chamadas on-net).
Holiday: toca em feriados quando temos uma Holiday schedule (agenda de feriados)
configurada e ativa.
Closed: toca quando uma agenda fechada (Closed schedule) est ativa.
Standard: toca a saudao (greeting) padro <user name> is not available..., ou seja, o
sistema diz o nome do usurio (que est configurado no campo Display Name) e logo aps
toca no est disponvel (para tocar a mensagem em portugus voc ter que instalar o
pacote correto de idioma e localidade).
CALL ACTIONS
Voc pode configurar que ao o sistema vai fazer aps a saudao (greeting) ser tocada para quem
discou (ou foi encaminhado) para o CUC. Normalmente a ao seria Take Message (pegar a
mensagem) mas tambm poderia ser Hang Up (desligar) e Restart Greeting (tocar novamente a
mensagem de saudao).
Outras aes possveis seriam enviar a chamada para um call handler configurado ou para a caixa
postal de um usurio (user mailbox), porm existem outras opes que podem ser configuradas.
CONFIGURAES E AES DE MENSAGENS (MESSAGE SETTINGS/ACTIONS) E CALLER INPUT
Bem, algum ligou para um usurio que no pode atender e essa pessoa deixou uma mensagem para
o usurio. E agora, o que o sistema ir fazer na sequncia? Quando o caller (quem chama) deixa uma
mensagem o sistema pode ser configurado para permitir as seguintes aes:
Editar ou no a mensagem
Marcar a mensagem como urgente (Urgent)
Deixar que o sistema escolha se as mensagens so urgentes ou normais (Urgent / Normal).
Marcar a mensagem como segura, o que pode ser utilizado para limitar onde essa mensagem
pode ser enviada, por exemplo, essa mensagem segura pode ser proibida de ser enviada para
um cliente de IMAP (e-mail).
Depois que a mensagem deixada por quem ligou para um usurio no disponvel, voc pode
configurar que ao o sistema vai tomar, sendo que por default say goodbye and hang up, ou seja,
dizer adeus e desligar a chamada. Porm outras opes podem ser configuradas, tais como enviar a
chamada para um determinado call handler ou para o mailbox de um usurio.
Durante a conversao com o CUC quem discou pode receber a opo de pressionar uma
determinada tecla (key) para tomar uma determinada ao pr-configurada (como por exemplo,
tecle 1 para enviar sua mensagem). As teclas padro so o zero (0) para a telefonista/operador
(operator) e asterisco (*) para entrar no mailbox. O sustenido (# - pound) normalmente utilizado
para indicar que a mensagem acabou e voc quer continuar no sistema para usar outras opes (isso
quando permitido).
CONFIGURAES DO TUI
O experincia do usurio com o TUI (Telephone User Interface) pode ser customizada para aumentar
ou diminuir a velocidade da conversao com o CUC, aumentar ou diminuir o volume, alterar o tempo
que o sistema vai esperar por uma tecla ser pressionada e alterar a ordem que as diferentes
mensagens podem tocar, porm existem mais opes alm dessas.
Todas essas opes esto dentro do usurio criado no CUC e algumas podem ser definidas no
template dos usurios.
Usurios do CUC (End Users)
A criao de usurios no CUC envolve um grande nmero de parmetros de configurao e a
utilizao do User Templates ir facilitar esse processo, pois maioria dos parmetros ser puxada do
template, evitando o trabalho manual e melhorando a preciso no processo. Usando os templates
voc precisar configurar apenas os seguintes parmetros (veja abaixo).
Parmetros de Configurao:
Alias (esse o user ID),

Name (nome do usurio)
Mailbox Store (armazenamento das mensagens)
Extension (ramal)
Alternate Extensions (ramal alternativo)
Porm, no momento da criao os parmetros obrigatrios sero Alias e Extension, pois o que o
CUCM ir passar para o CUC para identificar a caixa postal configurada. Se esses parmetros no
baterem em ambos os lados o usurio no ter voicemail.
Ramais e Opes de Call Forward
O Extension Number (ramal ou extenso) uma opo obrigatria, pois ele o DN primrio
(primary DN nmero principal) do telefone IP do usurio. Quando o usurio pressiona o boto
Messages o CUC utiliza o caller ID para determinar se ele dono de uma caixa postal e permite que
o usurio se logue no sistema, portanto ele compara o caller ID (ramal que est ligando para o CUC)
com o Extension configurado na lista de usurios do CUC.
Da mesma maneira, quando uma ligao encaminhada a partir do telefone do usurio para o CUC,
seja porque o usurio no est em sua mesa ou indisponvel e no atendeu a ligao, o CUC utiliza o
caller ID para determinar que caixa postal ele deve utilizar e tocar o greeting para quem est
chamando esse usurio.
As opes de call forward (encaminhamento de chamadas) disponveis para o DN configurado no
telefpone IP podem alterar o comportamento do CUC, pois podem ser configuradas diferentes
saudaes (greeting) para chamadas realizadas por telefones externos (vindo da PSTN) versus as
chamadas internas, feitas por outros usurios configurados no mesmo sistema.
Correio de Voz com SRST e AAR

Lembrem que existe o SRST (Survivable Remote Site Telephony), que o modo de sobrevivncia em
caso de problemas na rede IP WAN que impossibilita que os telefones IP se registrem no gateway
CME/SRST enquanto a conexo com o CUCM estiver indisponvel. Alm disso, existe a possibilidade
do sistema re-rotear as chamadas que deveriam ser internas (on-net) para sair atravs da PSTN no
caso do link WAN estar muito ocupado atravs do Automated Alternate Routing (AAR). Mas o que vai
acontecer com uma chamada direta ou encaminhada ao CUC quando um dos dois problemas ocorre e
o AAR ou SRST estiver ativo em um escritrio remoto?
Aqui temos duas situaes:
1. O CUC alcanvel pela PSTN assim como pela rede IP WAN pelos telefones IP?
2. O CUC vai reconhecer esse nmero PSTN remoto para vincul-lo a um usurio no correio de
voz?
Em uma situao normal o servidor CUC alcanadopelos telefones IP dos usurios remotos atravs
daWAN e, caso ocorra algum problema na WAN as chamadas so encaminhadas para o CUC via PSTN.
Quando a chamada chega no CUC, ao invs dele receber um nmero de 4 dgitos como em uma
chamada on-net, ele receber um nmero de 8 ou 10 dgitos da PSTN como caller ID, portanto ele no
vai achar correspondncia em sua lista de ramais/usurios. Para resolver esse problema voc pode
inserir um ramal/extenso alternativo (alternate extension) para esse usurio e assim o CUC consegue
vincular esse caller ID da PSTN com o usurio correto.
Parmetros Adicionais
Voicemail Box Caixa de Correio

Quando criamos as caixas de correio de voz podemos escolher se o usurio ser ou no listado no
diretrio, gravar o nome ou voice name, uma verso falada do nome do usurio (o CUC fala o nome
que est na pgina de configurao do usurio se no houver a gravao do nome) e gravar uma
saudao (greeting).
Podemos forar essas configuraes por parte do usurio no seu prximo login.
Private Distribution Lists Listas de Distribuio Privadas

Cara usurio pode criar at 99 DLs privadas com no mximo999 membros na lista.
Para alterar esses limites pode ser utilizado o CoS ou configurado individualmente por usurio. As DLs
privadas so visveis apenas pelo usurio que as criou e pelos administradores do sistema.
Notificao para Outros Dispositivos
Podem ser configurados outros dispositivos alm do MWI do telefone IP. Os usurios podem ser
avisados que chegaram novas mensagens em at trs nmeros PSTN, como por exemplo, seu
telefone celular, o telefone residencial e um pager.
Alm disso, o usurio pode ser avisado por e-mail. O controle de chamadas por motivos de cobrana
pode ser realizado por restriction tables (tabelas de restrio), as quais definem os nmeros que o
CUC pode ligar para enviar as notificaes de mensagem. Quando o CUC liga para o nmero
configurado ele informa o usurio que ele tem uma nova mesagem de voz e fala para o usurio se
autenticar atravs de uma mensagem padro.
Opes para Criao de Usurios no CUC
Temos as opes de criao ou importao de usurios no CUC. Vejam abaixo os mtodos disonveis.
Criao manual: o nome j diz tudo, o usurio criado um de cada vez manualmente e so
mantidos localmente na base de dados do servidor CUC.
Bulk administration (criao em massa): cria diversos usurios de uma vez a partir de um arquivo
em csv e os usurios tambm sero mantidos na base de dados local do CUC.
Migrao a partir do Cisco Unity: importa os usurios utilizando a ferramenta chamada
Consolidated Object Backup and Restore Application Suite (COBRAS). O COBRAS ajuda os
administradores a migrar usurios do Cisco Unity para o Cisco Unity Connection. O interessante que
os usurios podem ser importados com ou sem suas caixas de correios (mailboxes).
Importao a partir do CUCM: essa opo permite sincronizar a base de dados de usurios do CUC
com a do CUCM. Alguns dados so mantidos no CUCM e copiados para o CUC, porm todas as opes
especficas do CUC so mantidas localmente na base de dados do CUC.
Importao via LDAP: o CUC permite tambm a importao de uma base de dados de usurio
existente via LDAP. Assim como para o CUCM, alguns dados sero mantidos no LDAP e copiados para
o CUC, porm todas as opes especficas so mantidas localmente na base de dados do CUC. Assim
como para o CUCM, opcionalmente a autenticao web pode ser redirecionada para o LDAP,
facilitando a administrao dos usurios e senhas em um nico ponto (single point of administration)
e o single sign-on dos usurios (senhas nicas para usurios em todos os sistemas interligados ao
LDAP).
CUC Voicemail Boxes Caixas de Correio de Voz
Uma caixa de correio de voz (voicemail box) normalmente associada a cada usurio, ou seja, na
maioria dos cenrios uma por usurio.
O mailbox armazenado em uma base de dados (database store) que pode ser sincronizada entre
dois servidores CUC em uma arquitetura de par redundante ativo-ativo. A caixa de correio do usurio
pode ser movida para outro ponto de armazenamento se necessrio.
Message Aging Policy e Mailbox Quotas
Para controlar o espao de informaes armazenadas em disco ocupado pelas caixas de correio, os
administradores podem configurar polticas de envelhecimento das mensagens (message aging
policies), utilizadas para mover mensagens lidas para um folder de Deleted Items depois de certo
perodo de tempo especificado em dias (desabilitado por default). As mensagens na pasta de
Deleted Items so automaticamente apagadas aps um perodo de 15 dias por padro, porm esse
perodo pode ser ajustado.
Alm disso, o administrador pode definir um espao de armazenamento ou storage quotas para
avisar aos usurios que suas caixas de correio esto chegando perto do limite de armazenamento
permitido para suas mensagens (por padro avisa com 12MBytes). Ento com 12MB de espao
ocupado em seu mailbox o usurio recebe um aviso, se ele no apagar nada e chegar a 13 MB (pode
ser configurado e alterado) os usurios no podero enviar mensagens, e se deixarem chegar aos
14MB sero impedidos de enviar e receber mensagens (esse valor de 14M pode ser alterado).
Para termos uma idia de espao em disco necessrio para as graes das mensagens de voz, com
12MB de espao em disco conseguimos gravar aproximadamente 200 minutos de gravao com
mensagens gravadas utilizando o CODEC G.729 e 25 minutos com o G.711.
A administrao do espao em disco dos servidores CUC muito importante e deve fazer parte da
rotina operacional de uma empresa que tem esse sistema instalado.
Implementando Usurios e Mailboxes no CUC
At o momento estudamos apenas conceitos e colocamos algumas telas para que vocs pudessem ter
mais contato com o sistema Unity Connect e suas interfaces, porm no configuramos nenhuma
opo efetivamente.
Nesse tpico do captulo vamos realmente colocar em prtica os conhecimentos e conceitos
aprendidos e fazer aimplementao bsica de usurios e (users) e caixas de correio (mailboxes) no
CUC.
Mais uma vez no vamos inserir todas as configuraes, opes e passos possveis para nos
mantermos aderentes ao escopo do exame CCNA Voice.
Outro ponto que para realizar na prtica os passos posteriores e fazer o voicemail funcionar o CUCM
deve estar previamente integrado ao CUC.
Configurando End User Templates
Ns j falamos sobre os templates de usurio e sua capacidade de agilizar e facilitar a criao dos
usurios no CUC. Voc pode utilizar o template padro e alter-lo ou ento criar novos templates para
atender a necessidades especficas.
Conforme j citado, muitas configuraes podem ser feitas dentro do template de usurio, porm o
material oficial do ICOMM 8.0 (Introducing Cisco Voice and Unified Communications Administration)
limitado e seu foco est nos seguintes menus:

Password Settings
Roles
Message Settings and Actions
Phone Menu
Playback Settings
Message Notification
Para iniciar a configurao voc deve entrar na interface de administrao do CUC e ir em Templates
> User Templates. Nessa tela voc poder editar o template padro existente ou criar um novo. Veja
a figura abaixo com a tela citada com os dois templates padres criados, o primeiro para
administradores e o segundo para usurios de voicemail.
Nos prximos passos vamos editar o User Template padro para voicemail, fazendo com que todas as
contas criadas aps finalizarmos as configuraes sejam criadas com esse template. Como alguns
parmetros so nicos e devem ser configurados por usurio, voc pode incluir passos adicionais aps
a criao das contas de usurio para finalizar as configuraes necessrias.
O User Template Basics o menu que vai ser exibido quando voc clicar para alterar um template
existente ou criar um novo. Nele encontramos as configuraes bsicas e normalmente muitas delas
voc nem preisar alterar. Vamos ver os principais campos que podem ser configurados:
1. Alias: este um campo obrigatrio (todos que tem * so obrigatrios) e nesse caso define o nome
do template.
2. Display Name: mais um campo obrigatrio e representa como o nome do template vai aparecer na
lista de busca de templates (Pgina Find/List Templates).
3. Display Name Generation: aqui voc pode escolher como o nome do template vai aparecer
podendo ser First Name depois Last Name ou Last Name depois First Name.
4. Outgoing Fax Server: selecione o servidor de fax para os usurios caso exista.
5. Partition: selecione a Partition correta para os usurios.
6. Search Scope: selecione um Search Scope (Search Space) para os usurios.
7. Phone System: selecione um phone system para os usurios. Na maioria das vezes teremos apenas
um Phone System, porm o CUC suporta integrao com mais de um sistema e este um parmetro
importante para que no haja encaminhamento para o sistema errado.
8. Class of Service: aqui temos como escolher o CoS, o qual controla que recursos e facilidades os
usurios tero acesso.
9. Active Schedule: podemos selecionar uma agenda que ser aplicada aos usurios que forem
criados com esse template. As Schedules podem ser utilizadas para definir quando as saudaes
(greetings) Standard ou Closed devem ser tocadas, assim como a ao aps a saudao que o CUC
deve tomar.
10. Set for Self-enrollment at Next Login: esse checkbox quando selecionado fora o usurio a ir para
o tutorial e gravar seu nome (voice name) e saudao (greeting) na prxima vez que se logar no CUC.
11. List in Directory: selecione esse checkbox para listar os usurios no diretrio do CUC. Fazendo isso
voc permite tambm que usurios externos procurem e achem usurios e liguem para eles (se essa
opo for permitida). Veja na figura abaixo a tela com as opes de 1 a 11.
Continuao dos campos que podem ser configurados ...

12. Time Zone: selecione o Time Zone padro para os usurios. Esse parmetro define a data e hora
que o CUC ir mostrar nas mensagens e notificaes desses usurios.
13. Language: configura a linguagem que o CUC ir utilizar para tocar as instrues aos usurios e na
funcionalidade de text- to-speech (converter texto para voz). Porm no ir afetar no reconhecimento
de voz (voice recognition conversation). Veja na figura abaixo a tela com as configuraes dos itens
12 e 13.
Agora para voc passar para os demais menus que vamos estudar voc deve ir ao menu Edit e clicar
no submenu desejado, conforme tela na figura abaixo:
Password Settings
O Unity Connect tem duas senhas para o usurio:
Senha para acesso s pginas de web (Web Application), utilizada para logar nas pginas de
web do CUC incluindo as pginas de usurio (user web page) e administrativas (administrative
web pages), caso o usurio tenha privilgio administrativo para acess-las.
Senha utilizada para acessar o correio de voz(voicemail password), ou seja, o PIN que
utilizado para login no TUI.
A pgina de configurao tem como primeira opo um menu drop-down onde voc escolhe
configurar as senhas de web ou voicemail (veja a tela na figura abaixo).
Uma vez selecionado voc pode configurar os seguintes itens:

1. Locked by Administrator: se esse checkbox estiver selecionado os usurios no podero logar
no CUC, pois a senha est bloqueada pelo administrador.
2. User Cannot Change: selecionando essa opo o usurio no poder mudar a senha do seu
correio de voz. Essa opo pode ser til quando temos compartilhamento de voicemail e mais
de um usurio acessa a mesma caixa (voicemail box). Nesse caso recomendado colocar para a
senha no expirar com a opo Does Not Expire.
3. User Must Change at Next Login: faz com que o usurio seja obrigado a trocar a senha quando
entrar pela prxima vez no CUC.
4. Authentication Rule: define a Authentication Rule para aquelas contas de usurio. Lembre que
um Authentication Rule so regras que definem os padres de segurana da senha,
normalmente configurando antes dos templates de usurio.
Logo abaixo do menu Password Settings existe um chamado Change Password (veja figura abaixo).
No caso de criar novos usurios voc pode definir uma senha/PIN no menu Change Password e
depois marcar a opo de User Must Change at Next Login no menu de Password Settings, assim voc
garante que todos tem uma senha/PIN inicial igual e sero obrigados a trocar a senha/PIN na primeira
vez que se logarem no CUC.
Roles
As contas de usurio no possuem nenhuma role associada a elas por padro, pois um usurio no
necessita de acesso administrativo para trabalhar com sua caixa de correio de voz ou acessar sua User
Web Page. Caso voc esteja criando um template de usurios para acesso administrativo, escolha
uma role que melhor se adequa a ele com base nos privilgios necessrios.
Veja a tela de exemplo ao lado na figura abaixo.
Para dar acesso administrativo ao seu template basta clicar na role em Available Roles (na caixa de
baixo) e na setinha para cima. Para tirar uma role basta clicar nela em Assigned Roles e na setinha
para baixo, fazendo a role voltar para a caixa Avaliable Roles.
Message Settings
Nessa pgina voc vai poder configurar as caractersticasrelacionadas s mensagens deixadas no
sistema para os usurios. Abaixo seguem os principais campos que temos para configurar:
Maximum Message Length: define quanto tempo uma mensagem pode ter, sendo que o
padro so 300 segundos.
Callers Can Edit Messages: selecionando essa opo o usurio pode escutar de novo, adicionar,
regravar ou apagar a mensagem que ele acabou de deixar.
Language That Callers Hear: escolha um dos idiomas instalados no sistema. Este item afeta a
linguagem do sistema de gravao, em mensagens como Record your message at the tone
vai ser falada no idioma selecionado. Se voc selecionar Inherit Language from Caller o CUC
vai utilizar o idioma do usurio configurado na locale do usurio no CUCM, porm o mesmo
idioma deve estar instalado no CUC.
Unidentified Callers Message Urgency: uma pessoa que no dona de uma caixa de correio de
voz marcada no sistema como Unidentified Caller ou no identificado. A mensagem deixada
por esse tipo de usurio pode ser marcada como Normal, Urgent ou o sistema pode perguntar
ao usurio (Ask Callers), deixando que eles escolham a prioridade. O que isso inlfuencia no dia a
dia da empresa? Por padro as mensagens marcadas como urgentes so enviadas por primeiro
para que o dono da caixa de correio de voz a leia. Com isso, se voc setar essa opo os
usurios do sistema sempre iro ler antes mensagens deixadas por chamadas externas,
priorizando as chamadas de clientes e fornecedores. Essa opo pode ser sobrescrita pela
definio feita no menu do usurio.
Os outros dois menus Message Security e After Message Action no so foco do CCNA de Voz. No
menu deMessage Security voc pode setar para tratar a mensagem de uma maneira diferenciada na
rede (o padro no estar setado), j o menu de After Message Action o que o CUC vai fazer depois
que o usurio deixar sua mensagem.
Message Actions
Voc pode definir aqui por tipo de mensagem (Voicemail, E-mail, Fax e Delivery Receipt) que ao o
CUC deve tomar:
Accept - Aceitar
Reject Recusar
Relay - Encaminhar
Accept and Relay Aceitar e encaminhar
O relay nesse contexto quer dizer para encaminhar a um outro sistema de mensagens, que poderia
ser outro CUC, por exemplo.
Na figura abaixo temos a tela do Message Actions.
Phone Menu
Temos as seguintes opes no menu Phone do CUC:
Touchtone Conversation Menu Style: se voc escolher "Full" o CUC passar instrues
detalhadas para quem est deixando uma mensagem, ou ento escolha "Brief" para instrues
menos detalhadas.
Conversation Volume: ajusta o volume das conversaes do CUC.
Conversation Speed: ajusta a velocidade que o CUC vai tocar as gravaes (playback speed).
Time Format: escolha o formato do relgio para 12-Hour ou 24-Hour, esse ser o padro que o
CUC vai falar o tempo em suas conversaes com os usurios.
Use Voice Recognition Input Style: quando selecionado o CUC utiliza o reconhecimento de voz
(voice recognition) em suas conversaes, a no ser que os recursos de reconhecimento de voz
estajam indisponveis (nesse caso o CUC transforma para touchtone style, ou seja, utilizando
o teclado para obter as respostas).
Touchtone Conversation Style: permite a interao com o usurio via teclado (keypad
emulation). Este o estilo tradicional e preferencialmente utilizado para que os usurios
tenham uma transio mais suave entre um sistema sem reconhecimento de voz para um
sistema com reconhecimento de voz tal qual o CUC permite ter configurado.
Enable Message Locator: habilita para os usurios sistema de busca de mensagens pelo nome,
ramal ou caller ID.
Na figura abaixo temos um exemplo da tela do Phone Menu com as opes vistas acima.
Temos ainda outras opes rolando a tela mais para baixo, porm so itens que no fazem parte do
escopo do CCNA de Voz. Veja a tela na figura abaixo:
Temos ainda trs menus que no so abordados no material oficial do CCNA Voice, mas que vamos
citar para que vocs no tenham surpresas na prtica, os quais seguem abaixo:
When Responding to Menus: aqui temos opes para definir o que fazer quando o usurio no
responde e alguns temporizadores.
After Sign-In, Play: define o que tocar depois que um usurio se loga no sistema para acessar
seu voicemail.
When Exiting the Conversation: definies sobre o que fazer quando finalizar a conversao.
Playback Message Settings

Abaixo seguem as opes do menu Playback Message:
Message Volume: configura o volume da gravao.
Message Speed: seleciona a velocidade que as mensagens so tocadas para o usurio.
For New Messages, Play: essa opo para que o usurio oua um resumo da contagem de
mensagens novas que ele recebeu ao entrar no sistema por Totals (todas as novas mensagens), Emails, Faxes e Receipts.
For Saved Messages, Play: selecionando essa opo o CUC vai falar o nmero de mensagens salvas.
Before Playing Messages, Play: selecionando a opo Message Type Menu voc vai ouvir um
menu baseado em teclas do telefone com opes para ouvir as mensages por tipo. Cada nmero vai
representar um tipo de mensagem que voc pode ouvir.
New Message Play Order and Saved Message Play Order: essas opes servem para definir a
ordem que o CUC ir tocar as mensagens para os usurios. Para que seja possvel ouvir os e-mails e
faxes, necessrio que o usurio tenha vinculado a ele um CoS que tenha acesso ao e-mail em um
servidor externo de armazenamento de mensagens (Third-Party Message Stores) e recursos de Fax
habilitados. No caso do fax, o CUC anuncia apenas quem enviou, data e hora de envio, ele no ir ler o
contedo do fax.
Before Playing Each Message, Play: aqui voc ter algumas caixas para setar para ouvir as seguintes
informaes (podem ser algumas ou todas, voc seleciona):
Senders Information: Para ramais internos toca o nome ou ANI de quem deixou a mensagem,
j o ANI para pessoas externas no falado.
Include Extension: setado em conjunto com a opo acima faz com que o CUC toque o ramal
de um usurio interno que deixou a mensagem e tambm o nome gravado, se disponvel.
Message Number: o CUC anuncia a sequncia do nmero da mensagem que est na caixa de
correio de voz enquanto toca essas mensagens.
Time the Message Was Sent: o CUC toca a data e hora que a mensagem foi gravada.
Senders ANI: o CUC fala o ANI para mensagens gravadas de nmeros externos.
Message Duration: o CUC anuncia o tempo durao de cada mensagem.
Nas figuras 1, 2 e 3 temos as telas de configurao com as opes vistas acima e algumas outras que
no foram citadas por no ser o foco do exame.
Figura 1
Figura 2
Figura 3
Notification Devices
Essa uma opo muito interessante e demonstra o poder das comunicaes unificadas,
possibilitando a configurao de outros dispositivos para avisar que o usurio tem mensagens novas e
at ler essas mensagens. No confunda com o MWI, pois esse menu trata das notificaes que o CUC
pode fazer atravs de uma chamada telefnica ou e-mail para avisar ao usurio que ele tem novas
mensagens. O CUC pode ser configurado para fazer notificaes em um pager, telefone de trabalho,
telefone de casa e celular, alm de poder avisar via SMTP por default. Voc pode adicionar outros
dispositivos de notificao se necessrio.
Para cada dispositivo, faa as configuraes de acordo com sua necessidade:
Enable: selecione esse checkbox para habilitar o envio para o dispositivo.

Display Name: modifica o nome conforme necessidade.
Delay Before First Notification Event: configura o tempo em minutos que o CUC aguarda antes
de enviar a notificao para o dispositivo aps o usurio receber a mensagem.
Notification Repeat Interval: seleciona a frequncia que o CUC vai reenviar a notificao.
Notify Me Of: voc pode selecionar checkboxes para que o CUC envie notificaes sobre All
Messages (todas as mensagens), All Voice Messages (todas as mensagens de voz), Fax
Messages, Calendar Appointments (agendamentos), Calendar Meetings (reunies). E para cada
tipo voc tambm pode determinar que o sistema notifique apenas as mensagens urgentes.
Pager/Phone Settings: aqui selecionamos o nmero de telefone que o CUC deveria ligar,
porm lembre que isso deve ser feito em cada usurio e no no template, pois o do template
valer para todos os usurios. Aqui voc pode definir as configuraes extras para completar a
chamada, como adio de dgitos, tempos de espera e demais configuraes que possibilite
que as chamadas sejam completadas corretamente, conforme cada dial-plan.
Aqui deve ser levado em conta no projeto o custo dessas ligaes extras para os nmeros externos no
caso de escolher opes como telefone residencial ou celular.
Essas configuraes so realizadas em dua telas. Na principal voc tem um resumo dos dispositivos e
para configurar voc deve clicar no link de um dispositivo especfico. Veja no exemplo da figura 1 a
tela geral dos Notification Devices e na tela da figura 2 temos a configurao do telefone celular
(Mobile Phone).
Figura 1
Figura 2
Configurao de End Users no CUC

Conforme j mencionado de maneira geral, podemosadicionar usurios no CUC das formas citadas
abaixo:
CUC x Usurios:
Manual (um de cada vez): Users > Users

Importando do CUCM: Users > Import Users
Importando do LDAP (que opcionalmente pode fazer a autenticao): System Settings > LDAP >
Opes
Utilizando Bulk Administration Tool (BAT criao em massa atravs de um arquivo em csv):
Tools > Bulk Administration Tool
Cada uma das opes ao lado ir fornecer informaes que, em conjunto com o template configurado
no tpico anterior, devero compor a configurao dos usurios.
Assim como em outros tpicos desse captulo e captulos anteriores, vamos omitir algumas
informaes ou passos para mater o material aderente ao contedo do ICOMM.
Processo Manual
O processo de adio de usurios manualmente recomendado para situaes onde precisamos criar
apenas uns poucos usurios. Para criar os usurios v at o menu Users > Users e clique no boto
Add New.
Em seguida voc deve selecionar na sesso New User from Template o tipo de usurio em User
Type, o template que voc vai utilizar (criado no tpico anterior) e inicie a configurao do usurio.
Normalmente o User Type um usurio com caixa de voz (user with mailbox). A opo user without
a mailbox normalmente utilizada para criar usurios para fins administrativos.
Os passos das configuraes seguem abaixo:
1. Nos menus drop-down voc j escolheu o User Type e no menu Based on Template
selecionou o User Template adequado para esse usurio que est sendo criado.
2. Digite o Alias (deve ser nico no sistema), First Name, Last Name e Display Name.
3. Escolha o Mailbox Store correto se utilizar mais de um.
4. Digite o ramal no campo Extension, o qual normalmente o nmero principal (primary DN)
associado ao telefone IP.
5. Clique em Save.
Na figura abaixo segue a tela de configuraes bsicas de um usurio antes do clique no boto Save,
aps o save a tela muda e so mostradas as informaes do menu Users Basic.
ALTERNATE EXTENSIONS E NAMES RAMAIS E NOMES ALTERANTIVOS

Voc pode querer acessar sua caixa postal corporativa mesmo fora da empresa, para isso o CUC
permite a configurao de um ramal alternativo no menu Alternate Extension, sem passar pelo
Openning Greeting. Abaixo seguem os passos para configurao dos Alternate Extensions:
1. Na pgina de configuraes de usurio, clique no usurio a ser configurado, v at o menu Edit
e selecione a opo Alternate Extensions. Clique em Add New.
2. Defina o tipo do telefone em Type of Phone no drop-down que dar as opes de Work,
Home e Mobile.
3. Digite o nome para esse telefone alternativo no campo Display Name.
4. Digite o nmero do telefone no campo Phone Number, lembrando que esse o Caller ID (ANI),
ou seja, o nmero do telefone que vai aparecer para o CUC. Voc deve levar em conta as
tratativas de dgitos que o CUCM faz para configurar o nmero correto que ser enviado ao
CUC, ou seno o nmero pode no ser reconhecido.
5. Volte ao menu Edit e selecione agora a opoAlternate Names e configure um nome
alternativo para o usurio.
Um Alternate Name possibilita que o administrador configure apelidos, nomes mais familiares ou
diferentes tipos de pronncia que podem ser utilizadas para encontrar esses usurios via sistema de
reconhecimento de voz. Por exemplo, o usurio Marcos Mello mais conhecido por seus clientes
como Dr Marcos (Doutor Marcos), portanto voc pode configurar um nome alternativo com essa
maneira de chamar o usurio, facilitando a busca por ele se o sistema de reconhecimento de voz
(voice recognition) estiver em uso.
Veja o exemplo das telas do Alternate Extensions na figura 1 e Alternate Names na figura 2.
Figura 1
Figura 2
Private DLs Listas de Distribuio Privadas

O administrador pode adicionar Private DLs em nome do usurio ou ento o usurio pode utilizar seu
Personal Communications Assistant (PCA) para fazer essa configurao. O PCA um acesso web
disponibilizado pelo CUC aos usurios para que eles possam fazer suas configuraes atravs de seus
web-browsers, para acessar o padro https://IP_do_Servidor_CUC/ciscopca.
A interface de administrao do CUC permite abrir o PCA e logar como se fosse o usurio. Cada lista
precisa de um nome nico e pode ter at 999 membros, podendo ter at 99 listas individuais criadas.
Esses valores podem ser alterados atravs do CoS.
A figura abaixo mostra um exemplo da tela do PCA de um usurio.
Importando Usurios no CUC

A importao facilita muito a criao de usurios, alm de permitir uma melhor administrao dessas
informaes. Com essa ferramenta podemos centralizar as informaes sobre os usurios e at de
autenticao (quando utilizando LDAP).
Agregando a importao com os User Templates que configuramos, a criao de usurios torna-se
rpida e precisa, pois o operador no precisa definir nada sobre os usurios. Alm disso, manter a
base sincronizada com um sistema externo reduz atividades de manuteno e operao relacionadas
aos usurios.
Importao de Usurios:
Importando usurios do CUCM

Importando usurios do LDAP
Importando Usurios do CUCM

Se a base de dados de usurio do servidor CUCM estiver completa, ou seja, com todos os usurios,
voc pode fazer a sincronizao dela com a base de dados do servidor CUC. Nesse caso, os usurios
esto sendo administrados diretamente no CUCM e no no LDAP, caso o CUCM estiver sincronizado
com LDAP recomendado tambm sincronizar o CUC diretamente ao LDAP (veremos essa integrao
a seguir).
O processo de importao dos usurios do CUCM para o CUC feito em duas etapas, primeiro o
servio Cisco AXL Web Service deve ser habilitado no CUCM e ento no CUC deve ser feita uma
integrao com o AXL do CUCM. A depois que essa integrao funcionar podemos fazer a importao
dos usurios.
Para fazer essa sincronizao sero necessrias configuraes tando no CUC quanto no CUCM,
conforme passos abaixo:
1. Entre na interface Cisco Unified Serviceability e procure o menu Tools > Service Activation.
2. Selecione o servio Cisco AXL Web Service e clique em Save.
3. Na interface de administrao do Cisco Unity Connection procure o menu Telephony
Integrations > Phone System.
4. Clique no nome do servidor CUCM que voc deseja importar os usurios.
5. V agora at o menu Edit e clique na opo Cisco Unified Communications Manager AXL
Servers.
6. Uma vez na pgina dos AXL Servers, procure o campo AXL Server Settings e entre com o
usurio e a senha da conta que o CUC utilizar para acessar o servio de AXL no servidor CUCM.
7. Clique em Save.
8. Na sesso AXL Servers, clique em Add New.
9. Digite o IP e a Porta do servidor CUCM (No CUCM verso 8.x utilize a porta 8443 ou 443).
10. Clique no boto Test, esse resultado deve gerar a mensagem Test message successfully sent
to AXL server <ip_address:Port>.
11. Clique em Save para finalizar a integrao.
Veja na figura abaixo a tela com a mensagem de sucesso no teste de comunicao com o servio de
AXL do CUCM.
Dica: Em laboratrio, na instalao dos seus servidores coloque o mesmo usurio e senha para todas
as opes e aqui nesse campo basta utilizar esse usurio e senha criados durante o processo de
instalao. Se voc conseguiu na Internet uma VM pronta com o CUCM e/ou CUC j instalado,
procure uma que tenha todos os usurios e senhas criados na instalao.
Com o AXL funcionando vamos ento fazer a importao dos usurios seguindo os passos abaixo:
1. No servidor CUC, v at a pgina de administrao e procure o menu Users > Import Users.
2. Selecione o servidor CUCM (menu drop-down em Find End Users In) que voc deseja
importar os usurios para o CUC e clique no boto find (voc pode utilizar filtros se desejar).
3. Uma lista de usurios disponveis deve ser mostrada e agora voc deve escolher um User
Template no menu drop-down Based on Template.
4. Selecione os usurios que deseja importar da lista e clique em Import Selected ou clique em
Import All para importar todos os usurios.
Na figura abaixo temos a tela de importao dos usurios a partir do servidor CUCM com AXL
habilitado.
Importando Usurios do LDAP

Todos os conceitos que estudamos para o LDAP com o CUCM continuam valendo aqui, ou seja, o
mesmo padro para administrao de usurios, senhas e privilgios em uma base de dados
centralizada.
O CUC pode importar os usurios de diferentes modelos de implementao de LDAP. Como j vimos
para o CUCM, as contas que o CUC importar ficam mantidas no sistema LDAP, com alguns atributos e
campos copiados para a base de dados do CUC como read-only. Um opcional para essa sincronizao
com LDAP tambm fazer a autenticao, a qual redirecionada para o LDAP tratar.
Para habilitar a sincronizao via LDAP siga os passos abaixo:
1. Habilite o servio DirSync na Interface CUC Cisco Unified Serviceability, indo no menu Tools >
Services, selecione o DirSync e clique em Save.
2. Agora v para a interface de administrao (CUC Administration Interface), no menu System
Settings > LDAP > LDAP Setup.
3. Selecione o checkbox Enable Synchronizing From LDAP Server.
4. Escolha o tipo de servidor LDAP no menu drop-down LDAP Server Type.
5. No atributo do LDAP para o User ID, no menu drop-down, selecione que atributo ser mapeado
no LDAP para ser referente ao Alias no CUC, o qual deve ser nico e conter um dado. As contas
de usurio sem dados nesse atributo no sero importadas.
6. Agora v at o menu LDAP > LDAP Directory Configuration.
7. Digite um nome no campo LDAP Configuration Name. Recomenda-se utilizar um nome que
identifique os usurios que esto sendo importados, principalmente se houver multiplas User
Search Bases.
8. Entre com o usurio e a senha da conta que o CUC vai utilizar para importar a base de dados do
LDAP nos campos LDAP Manager Distinguished Name e LDAP Password.
9. Entre com o LDAP User Search Base, campo que aponta onde o CUC vai comear a ler na
base de dados do LDAP. Lembre que estudamos no CUCM que o LDAP utiliza uma estrutura em
rvore e o mesmo princpio de leitura se aplica para o CUC. O CUC pode sincronizar com apenas
uma base de dados de LDAP. A regra da sintaxe para a User Search Base a mesma que
utilizamos para o CUCM, por exemplo, cn=Users, DC=cisco, DC=com.
10. Na sesso LDAP Directory Synchronization Schedule temos as opes Perform Sync Just
Once, para fazer o sincronismo uma vez apenas, fazendo com que o CUC faa apenas o refresh
dos usurios importados, mas no leia novos usurios. Para importar novos usurios com essa
opo setada voc deve fazer uma nova sincronizao manual.
11. Para ter a sincronizao peridica configure o Perform a Re-sync Every com o intervalo
desejado. Lembre aqui da sobrecarga na rede e servidores, conforme mencionamos no captulo
do CUCM.
12. Para configurar o mapeamento entre os atributos dos usurios do LDAP e do CUC configure os
valores na sesso User Fields to Be Synchronized. Os campos iro variar conforme o tipo de
LDAP voc estiver trabalhando.
Na figura abaixo temos uma tela parcial da configurao do LDAP.
Importando Usurios em Massa - Bulk Administration

A importao de usurios utilizando a ferramenta Bulk Administration Tool uma opo rpida e
fcil de criar diversas contas de usurio formatando as informaes sobre o usurio em um padro
atravs de um arquivo em CSV. A importao em massa de usurios realizada seguindo os seguintes
passos:
1. V at o menu Tools > Bulk Administration Tool.
2. Abaixo da opo Select Operation escolha Create.
3. Abaixo de Select Object Type escolha Users With Mailbox.
4. Abaixo de Override CSV Fields When Creating User Accounts, na opo User Template
selecione Yes e escolha o User Template a ser utilizado na criao dos usurios.
5. No campo Select File selecione o arquivo .csv que contem os usurios que devem ser
importados.
6. Escolha um nome para o arquivo que trar as informaes de falhas em Failed Objects
Filename e clique em Submit.
Na figura abaixo temos um exemplo da tela de importao de uma BAT do Unity Connection.
A formatao do arquivo CSV tudo nesse processo e uma forma de montar seu padro exportando
via BAT apenas um usurio. Com esse modelo voc pode verificar os campos necessrios e criar
arquivos de importao para seus usurios. Aqui diferente da ferramenta de BAT do CUCM, a qual
inclui um modelo em Excel para voc fazer download e j contm macros para facilitar a criao do
arquivo.
Gerenciando o Armazenamento das Mensagens
A capacidade de armazenamento e outros detalhes sobre as caixas de correio de voz (mailbox)
podem ser verificadas e configuradas em Message Storage > Mailbox Stores. Nessa tela voc pode
escolher o armazenamento que voc necessita.
Clicando no Mailbox Store listado na pgina principal voc abre uma tela que contm informaes
sobre o tamanho do store, nmero de mailboxes, quando ele foi criado e permite voc configurar um
valor mximo utilizado para o CUC avisar sobre que a capacidade de armazenamento est chegando
no limite, no campo Maximum Size Before Warning.
Quando a caixa chega a 90% do valor configurado so logados avisos (warnings) e ao chegar em 100%,
so registrados erros (errors). Veja um exemplo na figura abaixo da tela do Message Store.
Mailbox Stores Membership

Voc pode criar pastas de armazenamento (Additional Message Stores) para utilizar quando o
usurio necessita de mais espao. Os usurios podem ser movidos atravs do menu Message
Storage > Mailbox Stores Membership.
Uma vez nessa pgina, basta selecionar o usurio que voc deseja mover, depois selecionar a base de
dados que voc vai utilizar e clicar em Move Selected Mailboxes, conforme tela mostrada
na figura abaixo:
Message Aging Policy

Por padro o Message Aging Policy (que podemos traduzir para poltica de envelhecimento das
mensagens) configurado para deletar as mensagens que esto no arquivo Deleted Items aps 15
dias.
Voc pode modificar esse padro indo em Message Storage > Message Aging Policy e selecionando
o Default System Policy. Voc pode desabilitar essa opo tirando a seleo do checkbox Enabled
que est no incio da pgina, o padro estar habilitado. Alm disso, voc pode criar novas polticas
se precisar.
Podemos ainda modificar os seguintes itens para as polticas:
Abaixo de Message Aging Rules Based on When the Message Was Last Modified voc pode
selecionar se quer mover as mensagens novas da pasta New Messages para a pasta Saved
Messages. Abaixo tem uma opo que setada faz com que as Saved Messages sejam
movidas para a pasta Deleted Items, setando quantos dias depois da mensagem entrar na
pasta ela ser movida em cada uma das opes.
Abaixo de Secure Message Aging Rules Based on When the Message Was Created voc pode
escolher para apagar permanentemente as mensagens seguras que atingiram seu limite de
tempo (aging time) em Permanently Delete Secure Touched Messages That Are Older Than
ou apagar todas as mensagens seguras aps um perodo de tempo especfico em Permanently
Delete All Secure Messages That Are Older Than.
Veja na figura abaixo um exemplo da tela do Messages Aging Policy.
Mailbox Quotas
Definir um limite no incio da implantao para os mailboxes a melhor recomendao.
Para configurar as cotas v at o menu Message Storage > Mailbox Quotas.
Nessa pgina voc pode mudar as cotas das caixas postais para todo o sistema (System-Wide Mailbox
Quotas), incluindo as notificaes de utilizao (limiares/thresholds de Warning, Send e
Send/Receive). Essas cotas podem ser sobrescritas pelo User Template ou individualmente por
usurio.
Na figura abaixo tems uma tela da pgina do Mailbox Quotas.
Cisco Unified Presence e seus Recursos

O Cisco Unified Presence Server (CUPS) expande os recursos de presena nativos do Cisco Unified
Communications Manager (que so on-hook, off-hook ou unknown) possibilitando informar as
capacidades (se ele possui um recurso de mensagens instantneas - Instant Message ou IM, por
exemplo) e disponibilidade dos usurios, indo alm do no gancho e fora do gancho e notificando se
ele est ocupado, ausente, indisponvel, etc. Alm disso, o CUPS traz recursos corporativos
importantes que permitem o cumprimento de questes regulatrias e de legislao (necessrias em
alguns pases) sobre a preservao das comunicaes (retention of communications).
As informaes de disponibilidade (availability) dos colegas de trabalho ou at parceiros de negcios
ficam visveis de imediato e podem ser melhoradas quando utilizado recursos integrados de status do
calendrio dos usurios, notificando uma ausncia devido a reunies ou compromissos, por exemplo.
J a capacidade (capability) Instant Message (IM) corporativo pode ser estendido para alm da
empresa e integrado com contatos externos, tais como Group Chat, Persistent Chat e recursos de
conformidade (compliance features), tais como IM logging e IM history, provendo o registro e
histrico das mensagens trocadas.
Como voc j pode perceber, o objetivo do CUPS diminuir o atraso nas comunicaes atravs da
disponibilizao de informaes teis instantaneamente sobre a disponibilidade e capacidade da
pessoa que voc deseja se comunicar. Voc j deve utilizar parte desses recursos com seu IM (como
msn Messenger, google talk e outros), indicando para seus amigos a sua disponibilidade, mas agora
imagine tudo isso integrado ao seu telefone IP, telefone celular, IM ou aplicativo de conferncia
(conferencing application), ou seja, atravs do indicativo do seu IM corporativo um colega de trabalho
pode ver que voc est ocupado ao telefone, tudo isso feito automaticamente pelo CUPS, que prov
essa integrao entre o status do CUCM e do seu IM.
Alm disso, essa sinalizao sobre a capacidade dos usurios pode ser tambm integrada aos
aplicativos existentes e permitir que o contato entre as pessoas seja realizado de maneira rpida,
pois voc pode com um clique ligar ou iniciar uma conversa via IM com a pessoa que voc deseja
falar. Isso tudo ajuda a resolver problemas de suporte ou problemas de clientes de maneira mais
rpida, evitando a demora em filas para falar ao telefone ou trocas de e-mail. Veja um exemplo dessa
integrao via MOC (Microsoft Office Communicator) na figura abaixo.
Assim como o CUC, o CUPS pode ser integrado ao CUCM, o qual j possui controle de chamadas e
presena nativa (on/off hook), de uma maneira mais completa. O CUPS atua como um ponto central
de coleta de informaes sobre a capacidade e disponibilidade dos usurios utilizando Session
Initiation Protocol (SIP), SIP para Instant Messaging, Presence Leveraging Extensions (SIMPLE) e
Extensible Messaging and Presence Protocol (XMPP).
O CUPS tambm suporta uma variedade de interfaces de clientes incluindo a proprietria da Cisco
chamada Cisco Unified Personal Communicator (CUPC), que por ser da prpria Cisco fornece uma
integrao mais rica e completa com o sistema.
Assim como o CUCM e o CUC, o CUPS pode ser instalado em um servidor fsico ou virtual (VMWare).
Lembre que estudamos no incio do curso as caractersticas de cada produto que em um ambiente
grande os trs sistemas acabam sendo instalados em servidores separados, mas para ambientes
menores existe a verso Business Edition que traz os trs produtos instalados em um nico servidor,
porm sem possibilidade de redundncia.
Cisco Unified Personal Communicator
O CUPC uma interface cliente nica para maioria das ferramentas de Comunicaes Unificadas da
Cisco, pois a partir dele o usurio pode fazer chamadas de voz atravs do seu deskphone control ou
em modo softphone, verificar o status de presena de seus contatos de maneira avanada,
possibilitando funcionalidades do tipo click-to-communicate (clique para se comunicar) atravs de
chamadas de voz e vdeo, grupos de chat, chat e interao colaborativa (collaboration interaction)
com uma interface que possibilita a transio simplificada de um meio para outro.
O Chat habilitado utilizando Jabber Extensible Communications Platform (XCP) utilizando o XMPP
como protocolo para chat. Veja na tela da figura abaixo um exemplo da tela do CUPC verso 8.5.
Modos de Operao do CUPC

O CUPC pode operar em dois modos (mode):
1. Deskphone mode: nesse modo o CUPC pode controlar o telefone IP (desk phone) do usurio para
fazer chamadas. Nesse caso o telefone IP deve estar registrado no CUCM e associado a um usurio
(end user). O CUPC utilizar o protocolo Computer Telephone Integration Quick Buffer Encoding
(CTIQBE) para controlar o telefone IP e ir se comunicar com o CUPS atravs do protocolo XMPP.
Veja essa integrao do CUPC e o telefone IP nafigura abaixo.
2. Softphone mode: quando o telefone IP no est disponvel ou o usurio est longe da sua mesa o
CUPC pode ativar o servio via softphone que est baseado no Cisco Unified Client Services
Framework (CSF), o qual registra o softphone no CUCM como um dispositivo SIP. No CUCM deve ser
criado pelo administrador um dispositivo CSF para habilitar essa funcionalidade. Veja a figura abaixo
com a representao do modo softphone.
Enterprise Instant Messaging IM Corporativo

O CUPC tem capacidade de prover Chat e Grupo de Chatatravs de TLS seguro (TLS-secured). As
sesses de grupo dechat Ad-Hoc so armazenadas no servidor CUPC. Alm disso, o recurso de
Persistent Chat habilita grupos de salas de chat onde as trocas de mensagem so gravadas mesmo
que todos os participantes saiam da sala.
Para que esse recurso de Persistent Chat possa ser habilitado ser necessrio um banco de dados
externo para armazenar as salas de bate papo (chat rooms) e as conversaes. Outro recurso possvel
de ser utilizado o Offline IM (mensagens off-line), o qual permite o envio de mensagens mesmo
que os usurios remotos estejam off-line (deslogados). Essas mensagens so armazenadas em um
banco de dados local (local IDS database) no servidor CUPS.
O sistema de roteamento de mensagens Jabber XCPfoi modificado na implementao do CUPS para
possibilitar o funcionamento quando os usurios esto disponveis em mais de um dispositivo ao
mesmo tempo.
As mensagens nesse caso so enviadas para todos os dispositivos que no esto explicitamente
bloqueados de receber mensagens, chamados de non-negative priority devices ou dispositivos com
prioridade no negativa, ao invs de enviar apenas para o dispositivo com a prioridade mais alta.
Portanto, o CUPS envia as mensagens para todos os dispositivos que o usurio est logado (logged-in
devices) e esse comportamento chamado IM Forking.
Um detalhe importante que quando o usurio responde a uma mensagem (que foi enviada a todos
os dispositivos) de um determinado dispositivo, as mensagens que sero enviadas na sequncia so
enviadas para esse dispositivo especfico que o usurio utilizou para responder, ou seja, se o usurio
respondeu a mensagem pelo seu smartphone as mensagens subsequentes sero enviadas apenas
para o smartphone dele.
Para que haja compatibilidade com outros clientes de presena SIP (SIP-only Presence clientes), tais
como um CUPC verso 7.x, ser necessrio o uso de um gateway de IM ou IM Gateway.
Chamadas de Voz com CUPC
O CUPC suporta tambm chamadas de voz (voice calls) nos modos deskphone ou softphone,
conforme estudamos anteriormente, alm disso, possvel criptografar a voz utilizando o protocolo
Secure Real-Time Protocol (SRTP), melhorando a segurana das comunicaes.
O CUPC pode tambm funcionar quando o sistema estiver em Survivable Remote Site Telephony
(SRST), porm ele deve estar em modo softphone e exige uma configurao especfica no
CUCM/CSF.
O CUPC suporta os seguintes codecs em modo softphone, conforme abaixo:
Codecs no modo softphone:
G.711 a-law e mu-law

G.722 Wideband
G.729A e G.729B
iLBC (Internet Low Bandwidth Codec)
iSAC (Internet Speech Audio Codec)
J no modo deskphone o codec depende do modelo do telefone IP utilizado.

Chamadas de Vdeo com CUPC
As chamadas de vdeo tambm so possveis no CUPC tanto em modo deskphone como em
modo softphone.
Para fazer uma chamada de vdeo em modo deskphone o CUPC utiliza o Cisco Audio Session Tunnel
(CAST) e Cisco Discovery Protocol (CDP) para se comunicar com o telefone IP, ou seja, para fazer a
comunicao entre o telefone IP e o computador que tem o CUPC rodando, porm o telefone IP (desk
phone) deve ter habilitado o suporte a vdeo chamadas no CUCM. Os telefones IP SIP no suportam o
CAST.
Em modo softphone o CUPC utiliza o dispositivo CSF configurado no CUCM para fazer as chamadas de
vdeo. Os dispositivos CSF tm o vdeo habilitado por padro.
Tambm possvel utilizar o CUPC para fazervideoconferncia utilizando uma video-conference
bridge que esteja acessvel via um Media Resource Group List (MRGL), o qual deve estar vinculado ao
telefone IP ou ao dispositivo CSF.
Integrao com outros Sistemas
O CUPC pode ser integrado a muitos produtos da famlia Cisco Unified Communications,
possibilitando uma experincia mais rica aos usurios no uso das ferramentas. Por exemplo, o CUPC
pode prover o voicemail visual quando integrado ao Cisco Unity ou Unity Connection, ou seja, os
usurios podem controlar seus mailboxes escutando, enviando ou apagando mensagens utilizando o
CUPC.
Alm disso, a funcionalidade de Click-to-call (chamada em um clique) possvel atravs da
integrao do CUPC e outras aplicaes, tais como Microsoft Outlook, Word e Excel. Indicadores de
presena (Presence Indicators) para contatos podem ser vistos no Outlook, por exemplo. Veja um
exemplo na figura abaixo do click to call.
Se o Cisco Unified MeetingPlace est tambm integrado ao sistema possvel facilmente atravs do
CUPC transformar uma chamada em uma conferncia de udio.
Outras integraes so possveis, mas isso assunto para o CCNP Voice!
Requisitos de Sistema para o CUPC:
Para saber quais os requisitos do sistema para Windows e Macintosh (OS) v pgina
http://www.cisco.com/en/US/products/ps6844/index.html
e procure as verses atuais e suas necessidades de software (as informaes esto em Ingls).
Cisco Unified Client Services Framework - CSF

O Cisco Unified Client Services Framework (CSF) a base para todos os clientes da famlia Unified
Communications, sendo uma parte do CUPC e permitindo estender as funcionalidades do Microsoft
Outlook e WebEx Connect.
Os principais recursos do CSF so fornecer voz e vdeo,comunicao segura com o CUCM
e comunicao de texto(IM) com servidores como o CUPS. O CSF tambm fornece recursos de udio
e vdeo, tais como controle de chamadas e facilidades avanadas, como, por exemplo, o visual
voicemail.
Importante:
Apenas um cliente CSF pode ser instalado por vez em um PC, por exemplo, um CUPC e um Cisco
Unified Communications Integration for Microsoft Office Communicator (MOC) no podem ser
instalados ao mesmo tempo no mesmo computador cliente.
Cisco Unified Communications Manager IP Phone Service - CCMCIP
O servio CCMCIP era utilizado no incio da implementao do presence para fornecer autenticao,
servios de diretrio e help para os usurios, porm ele foi adaptado para ser utilizado pelo CUPC e
clientes CSF para obter a lista de dispositivos que o usurio pode alcanar quando ele se log.
Veja um esquema de como funciona o CCMCIP nafigura abaixo.
Cisco IP Phone Messenger - IPPM

O servio IPPM permite que o usurio construa uma lista de contatos e veja o status de presena
deles, tudo isso a partir do seu telefone IP (desk phone). Esse servio permite tambm que os
usurios leiam e apaguem mensagens de texto (IM messages) enviadas por outros usurios, responda
aos usurios atravs de uma chamada de voz ou utilize mensagens pr-configuradas pelo
administrador do CUCM para responder s mensagens recebidas. Outra possibilidade que o IPPM
permite que o usurio troque seu status de presena utilizando seu telefone IP.
Os principais componentes que possibilitam o IPPM incluem a sinalizao XML-over-HTTP, trocada
entre o telefone IP e o CUPS, e o XMPP entre o CUPS e CUPC, quando os usurios esto utilizando
suas workstations. Veja na figura 1 ao lado a interao dos dispositivos com o servidor CUPS
utilizando os protocolos XML-over-HTTP e XMPP.
No caso do SIP ser utilizado para a comunicao, ele dever conversar com um SIP proxy ou registrar
servers.
Arquitetura do Cisco Unified Presence

O CUPS uma aplicao baseada em diversos protocolos que juntos fornecem as funcionalidades e
recursos aos usurios. Veja a lista abaixo de protocolos utilizados pelo CUPS:
SIP, SIMPLE e XMPP: fornecem presena genrica e recursos de federation (federao).

Simple Object Access Protocol (SOAP): utilizado para acessar a base de dados do CUCM via
Cisco Unified Communications System XML e configurao dos profiles do CUPC.
Computer Telephone Interface Quick Buffer Encoding (CTIQBE): utilizado para integrao com
CTI para controle remoto de chamadas feitas pelo Microsoft Office Communicator (MOC).
HTTP: para fornecer o IP Phone Messenger (IPPM) nos telefones IP da Cisco.
Os principais componentes do CUPS so:
Jabber XCP: responsvel por fornecer a presena, IM, listagem de contatos, mensagens e
roteamento de chamadas, polticas e federao (federation).
Rich Presence Service: gerencia a coleta do estado da presena e Presence-enabled routing.
Group Chat Storage: os grupos de chat Ad-Hoc geralmente so armazenados na memria do
servidor CUPS, porm o Persistent Chat e arquivamento de mensagens necessitam de uma
base de dados externa.
Integrao com o Microsoft Office Communications Server

O CUPS pode ser integrado ao Microsoft Live Communications Server 2005 ou Microsoft Office
Communications Server 2007 via o protocolo SIP.
Quando o cliente Microsoft Office Communicator (MOC)tem um telefone IP associado ele, os
usurios tm os recursos de click-to-dial, controle de chamadas e capacidade de presena.
Integrao com LDAP

O CUPS tambm pode ser integrado com o Lightweight Directory Access Protocol (LDAP), assim
como o CUC e o CUCM tambm pode. A diferena aqui que o banco de dados de usurio do CUPS
sincronizado com o CUCM, o qual por sua vez pode estar sincronizado com a base de dados de
usurio do LDAP. possvel tambm redirecionar a autenticao do usurio para o LDAP para
proporcionar o single sign-on para os usurios (um login nico na rede). Veja a figura abaixo com a
integrao do CUPS e o LDAP.
Quando o CUPS est integrado ao Microsoft Active Directory, os usurios podem se logar com suas
credenciais LDAP e sincronizar seus status de presena com seus calendrios do Outlook/Exchange.
Alm disso, o diretrio do LDAP pode ser buscado pela interface do CUPC. O CUPS pode tambm se
comunicar com o Exchange atravs da interface Outlook Web Access.
Integrao com o Cisco Unity Connection
A integrao do CUPS com o CUC permite ao usurio a capacidade de organizar, visualizar, ouvir e
apagar suas mensagens de voz, alm disso, fazer uma chamada de voz para os usurios que enviaram
as mensagens, tudo isso utilizando a interface do CUPC.
A informao do status de presena de quem enviou a mensagens tambm mostrada, possibilitando

a comunicao entre os usurios por outros meios, como por exemplo, uma ligao, mensagem ou
at uma conferncia.
A interao entre a caixa de correio do CUC realizada viaInternet Message Access Protocol (IMAP) e
precisa que um profile de voicemail seja configurado no CUPS server. Veja na figura abaixo a
integrao do CUPS com o CUC.
Integrao com Conferencing Resources Recursos de Conferncia

O CUPS pode utilizar o WebEx ou MeetingPlace para ter recursos de conferncia.
Quando utilizando o WebEx o CUPS necessitada de um servidor de conferncia (Meeting
Center Server) local, sendo que a comunicao com o servidor de conferncia feita atravs de
Macromedia Flash utilizando os protocolos HTTP ou HTTPS para transporte das informaes.
Na figura abaixo voc pode ter uma idia da integrao do CUPS com os recursos de conferncia.
Integrao com Recursos de Calendrio

Voc pode tambm integrar o CUPS com o Microsoft Exchange 2003 ou 2007 (utilizando Active
Directory 2003 ou 2008) para possibilitar acesso ao status do calendrio (Livre/Ocupado/Fora do
Escritrio - Free/Busy/Out of Office) e vincular esse status ao da presena
(disponvel/ocupado/ausente Available/Busy/Away).
Para que isso seja possvel necessrio configurar uma conta especial no Microsoft Exchange, uma
conta que tenha permisses no View-Only Administrators Groups no Exchange e permisses
Receive-As em todas as caixas de correios dos usurios. Com essa conta o CUPS poder verificar o
calendrio dos usurios no servidor Exchange, veja uma ilustrao dessa integrao na figura abaixo.
Arquitetura e Fluxo de Chamadas

Modo Softphone:
Se um usurio est fora do escritrio, por exemplo, viajando utilizando um lap-top, ou sem um
telefone IP o CUPC pode operar em modo softphone.
Nesse cenrio o CSF utiliza a sinalizao SIP para se registrar no CUCM como um dispositivo CSF.
Quando isso ocorre o CUPC faz o download do arquivo de configurao do CUCM pegando um DN,
partition, CSS, device pool e os demais itens necessrios para seu funcionamento.
Para suporte ao recurso de chat o protocolo XMPP utilizado para enviar todas as mensagens
instantneas (IM) ao servidor CUPS.
Modo Deskphone:
Quando o CUPC est em modo de controle deskphone ele se registra com o CUCM e faz o download
do seu arquivo de configurao, ento a seguir ele se loga com as credenciais (usurio/senha)
fornecidas pelo usurio. O servio CCMCIP possibilita que o CUPC verifique a lista de dispositivos que
aquele usurio controla.
O telefone IP controlado pelo CUPC atravs doCTIQBE, sendo que se o usurio tem vrios telefones
vinculados a sua conta, ele pode escolher qual deles o CUPC deve controlar.
Assim como para o modo anterior, o CUPC em modo deskphone utiliza o XMPP para o recurso de
chat, enviando todas as mensagens instantneas para o servidor CUPS.
Compliance e Persistent Chat
O termo Persistent Chat tem referncia a mensagens de grupos de chat que precisam ser mantidas
quando todos os participantes do grupo deixaram a sesso de chat, permitindo que essas mensagens
sejam acessadas posteriormente. Os Persistent Chats precisam de umbanco de dados externo para
armazenamento das informaes, ou seja, um banco de dados separado ser necessrio para cada
servidor CUPS configurado para o recurso de Persistent Chat. Essas instncias de banco de dados
podem estar no mesmo servidor ou no, isso depende de cada projeto. Essa interao com o banco
de dados PostgreSQL realizado via Open Database Connectivity (ODBC).
O motivo para gravar os chats realizados via mensagens IM a necessidade de se adequar a regras de
conformidade (Regulatory Compliance) corporativas ou at devido a leis dos pases onde o sistema
est instalado. Para isso, o CUPS pode ser integrado a uma base de dados externa utilizando
PostgreSQL, conforme j citado anteriormente.
Uma opo para adequaes das regras de conformidade citada anteriormente o uso de sistemas
de terceiros (Third-party no Cisco), pois essas aplicaes podem fornecer mais recursos que o
banco de dados PostgreSQL utilizado para armazenamento. Esses recursos extras podem ser
varredura das mensagens para verificao de vrus, medidas contra AntiSpam e outras. Se uma
aplicao de terceiro para conformidade est em uso, todos os chats so enviados atravs desse
servidor (compliance server), o que significa que se esse servidor no estiver disponvel para o CUPS
nenhuma mensagem (IM) pode ser enviada.
Veja na figura abaixo a integrao o CUPS com o servidor de armazenamento de mensagens
externo. Para chats do tipo Ad-Hoc as mensagens so armazenadas na memria do prprio servidor.
Consideraes de QoS
A questo do QoS vital para redes de Comunicaes Unificadas e no poderia ser diferente quando
estamos falando de presena, por isso algumas garantias e medidas devem ser tomadas para que o
trfego do CUPC seja processado de maneira correta pelos mecanismos de QoS.
O CUPC marca o trfego de sada (outbound) na estao do usurio com os valores apropriados para
voz, vdeo e sinalizao. Normalmente todo trfego do micro do usurio marcado como no
confivel (untrusted) e marcado com um valor baixo de QoS pelo primeiro dispositivo que tem QoS
habilitado (QoS-enabled) e est tratando esses quadros/pacotes, porm esse comportamento pode
ser modificado especificando a faixa de portas que o CUPC vai utilizar e se aplicarmos as marcaes de
QoS corretas para esse trfego.
Para isso, os equipamentos de rede tais como switch, roteador, firewall, e demais devem ter a
capacidade declassificar o trfego baseado na porta TCP/UDP, marcar o trfego com o valor correto
para o ambiente de QoS e aplicar uma poltica de QoS que permita o encaminhamento desse trfego
ao seu destino com a garantia de delay e largura de banda apropriada.
Outra possibilidade que o sistema operacional do micro do usurio no suporte marcao de QoS
que o CUPC necessita para o trfego de sada, porm isso atualmente bem raro nos ambientes
modernos de rede LAN.
Na tabela abaixo temos os principais protocolos utilizados pelo CUPC, suas portas utilizadas e uma
breve descrio delas. A lista completa voc encontra no link.
Alm disso, a figura abaixo representa todas as interaes que o CUPS pode ter e os protocolos
utilizados.
Habilitando o CUPS
Nesse tpico vamos ver como habilitar o Cisco Unified Personal Communicator (CUPC) nos modos
desk phone e softphone.
Lembrem que para que isso seja possvel existem passos anteriores de configurao do CUPS que no
fazem parte do escopo do CCNA Voice e sim do CCNP Voice, por isso aqui consideramos que todos os
passos anteriores desde a instalao como a integrao geral foi realizada.
Voc vai ver a seguir que para fazer a configurao do CUPC precisaremos configurar parmetros no
CUCM, no CUPS e no prprio cliente do CUPC.
Habilitando os End Users para o CUPC no CUCM

Os passos para habilitar os usurios utilizarem o CUPC no CUCM esto resumidos no quadro ao lado.
Na sequncia vamos analisar cada passo separadamente.
1.
2.
3.
4.
5.
Liberar as capacidades de licena no CUCM.

Configurar os usurios no CUCM.
Associar DNs com os usurios no CUCM.
Criar um dispositivo Cisco Unified Client Services Framework (CSF).
Associar o dispositivo CSF ao usurio no CUCM.
Liberando as Licenas no CUCM

O controle sobre que usurio pode utilizar o CUPS e o CUPC realizado pelo CUCM. O primeiro passo
da configurao liberar a licenas seguindo os passos ao lado.
Voc pode utilizar o boto de Bulk Assignment para selecionar vrios usurios ao mesmo tempo a
partir de uma lista e selecionar as capacidades que selecionamos acima para todos os usurios
selecionados de uma s vez.
1. V at o CUCM em sua pgina de administrao em System > Licensing > Capabilities
Assignment.
2. Encontre o usurio que voc deseja habilitar a presena e o CUPC e clique no usurio.
3. Na pgina que ir abrir selecione Enable CUP (Cisco Unified Presence) para habilitar o CUP
(somente presena) para aquele usurio.
4. Selecione Enable CUPC (Cisco Unified Personal Communicator) para habilitar o CUPC para o
usurio.
Configurando os Usurios no CUCM
Para configurar o controle do telefone IP (desk phone control) para um usurio voc deve seguir
passos ao lado.
Um ponto chave aqui que se voc no selecionar o checkbox Allow Control of Device from CTI o
usurio no poder controlar seu telefone IP quando ele estiver utilizando o CUPC, ou seja, no
conseguir fazer nenhuma chamada.
Outro ponto importante nessa parte da configurao que devido aos diferentes modelos de
telefone IP suportarem o CTI de maneira diferente, os usurios precisam ser vinculados a um ou mais
grupos para que as funes relacionadas ao CTI funcionem corretamente para os diferentes tipos e
modelos de telefones IP. Isso feito na pgina de usurio (End User configuration page), na sesso
relativa s permisses (Permissions Information) seguindo as seguintes recomendaes:
Para todos os modelos de telefone IP: adicione o usurio ao grupo Standard CTI Enabled.
Para telefones da srie 69XX: adicione o usurio ao grupo Standard CTI Allow Control of
Phones supporting Rollover Mode.
Para telefones IP das sries 89XX e 99XX: adicione o usurio ao grupo Standard CTI Allow
Control of Phones supporting Connected Xfer and conf.
Na pgina de administrao do CUCM v at User Management > End User e selecione o

usurio que voc deseja configurar.
Uma vez n pgina do usurio procure a sesso Device Information e clique no boto
Device Association.
Selecione o telefone IP do usurio para que ele aparea no painel de Controlled Devices.
Agora voc deve verificar se o checkbox Allow Control of Device from CTI est selecionado
na pgina de configurao do usurio, normalmente vem setado por default.
Se o usurio tiver o Extension Mobility habilitado voc deve mover o Device Profile correto
para o painel CTI Controlled Device Profiles.
Associando DNs aos usurios no CUCM

Para associar o DN ao usurio siga os passos ao lado.
1. V at o menu Device > Phone, selecione o telefone IP do usurio e v at a configurao do
DN (Directory Number Configuration).
2. Selecione o checkbox Allow Control of Device from CTI.
3. Se o usurio estiver com o Extension Mobility ativado clique na mesma sesso selecione o
Device Profile adequado para o usurio.
4. Agora v para baixo na mesma pgina em Users Associated with Line e clique no boto
Associate End Users.
5. Selecione o usurio associado ao DN e clique em Add Selected.
6. Para finalizar clique em Apply Config.
Criando um Dispositivo CSF modo Softphone
Agora vamos configurar o modo softphone para o CUPC seguindo os passos abaixo:
1. V at a pgina Device > Phone e clique em Add New.
2. Selecione o Phone Type para a verso correta de CUCP que est sendo utilizada. O mais
importante aqui que voc deve ter os detalhes necessrios para escolher o Phone Type
correto.
3. Agora selecione o checkbox Allow Control of Device from CTI.
4. Escolha um Device Security Profile seguido por um SIP Profile.
5. Na pgina de configurao do Directory Number do usurio associe esse novo dispositivo
CSF com o mesmo DN primrio que est configurado no telefone IP do usurio.
6. Verifique se o usurio est realmente associado ao DN.
7. Aplique a configurao para finalizar.
Ns podemos ter o CUPC na verso 8.x ou 7.x os quais tm recomendaes de nomenclatura e criao
um pouco diferentes. Veja abaixo as principais recomendaes com relao a nomenclatura:
1. Se voc estiver utilizando a verso do CUPC 8.0 ou superior selecione o Cisco Unified Client
Services Framework como Phone Type:
O dispositivo CSF pode ser nomeado como voc definir, ou seja, no h nomenclatura padro
ou conveno de nome a ser seguida, porm existe um limite de 15 caracteres com letras e
nmeros apenas.
2. Se voc estiver utilizando o CUPC verso 7.0, o Cisco Unified Personal Communicator deve ser
selecionado com o Phone Type correto e deve seguir o padro de nomenclatura conforme abaixo:
Para o nome do dispositivo com um CUPC v7.0 voc deve iniciar com as letras UPC seguido
pela derivao do nome do usurio (username).
O nome deve conter apenas letras maisculas e nmeros, podendo ter no mximo 12
caracteres iniciando com o prefixo UPC, conforme citado no passo anterior.
Por exemplo, se temos o usurio (user ID) Mega.Deth o nome do CUPC deveria ser
UPCMEGADETH.
Lembre-se que as recomendaes do item 2 so para a verso mais antiga do CUPC, pois a mais nova
no tem essas limitaes, apenas com nmero de caracteres e tipos.
Associando o Dispositivo CSF com os Usurios no CUCM
Para associar o dispositivo CSF com os usurios no CUCM siga os passos abaixo:
1. Na pgina de configurao usurio (User Management > End User) procure a sesso Device
Information.
2. Adicione o dispositivo CSF criado no passo anterior lista de dispositivos controlados no campo
Controlled Devices clicando no boto Device Association.
3. Clique em Save para finalizar a configurao.
Com esses passos finalizamos a configurao do CUCM e agora precisamos finalizar indo no servidor
CUPS, conforme o prximo tpico.
Habilitando os Usurios do CUPC no Cisco Unified Presence
Agora vamos configurar o CUPC no CUPS, pois eles tm uma forte ligao e devido a isso diversas
configuraes podem ser realizadas para que o CUPC fornea mais recursos aos usurios.
Aqui vamos focar em mensagens de voz (voice mail) para o cliente CUPC, modo de controle do
telefone IP (desk phone control mode), busca no diretrio LDAP (directory lookups) e informaes
sobre os dispositivos do usurio atravs do CCMCIP.
Existem mais facilidades que podem ser configuradas e tambm algumas dessas facilidades podem
no ser necessrias em algumas implantaes, portanto o projeto que vai dizer o que vamos ou no
ter que configurar para os usurios.
Configurando o Acesso ao Voice Mail Utilizando o CUPC
O CUPC pode acessar e processar as mensagens de voz que esto em um servidor de mensagens
como o Unity Connection, porm para que isso seja possvel, vrias configuraes devem ser feitas,
conforme abaixo:
1. Definir o Mailstore: na pgina de administrao do CUPS v at o menu Application > Cisco
Unified Personal Communicator > Mailstore e clique em Add New. Configure um nome
(Name) e endereo IP para o servidor de mensagens (voice messaging server), opcionalmente
voc pode alterar a porta e o protocolo caso seja necessrio para compatibilizar com o
servidor. Esta configurao permite que as mensagens sejam recuperadas do servidor
utilizando o IMAP.
2. Definir o servidor de correio de voz (Voicemail Server): V novamente tela de administrao
do CUPS em Application > Cisco Unified Personal Communicator > Voicemail Server, em
seguida clique em Add New. No parmetro Server Type voc pode escolher entre Unity ou
Unity Connection. Aps isso, configure o endereo IP e clique em Save.
3. Defina o Voicemail Profile: Em Application > Cisco Unified Personal Communicator >
Voicemail Profile selecione o Mailstore e Voicemail Server configurados anteriormente.
Permitir o controle do Telefone IP (Desk Phone Control)
O CUPC pode controlar o telefone IP do usurio atravs do servio CTI. Para habilitar esse recurso
siga os passos abaixo:
Em Application > Cisco Unified Personal Communicator > CTI Gateway Server clique em
Add New e digite o nome (Name) e endereo IP do gateway.
Agora em Application > Cisco Unified Personal Communicator > CTI Gateway Profile
verifique se uma entrada automtica foi criada.
Permitir a busca no diretrio do LDAP - Directory Lookups

A busca no diretrio local do LDAP permite que os usurios que esto utilizando o CUPC possam
utilizar o recurso declick-to-dial (discagem com um clique), siga os passos abaixo para fazer a
configurao.
1. V em Application > Cisco Unified Personal Communicator > LDAP Server e clique em Add
New, depois digite o nome, o endereo IP do servidor LDAP e clique em Save.
2. Agora em Application > Cisco Unified Personal Communicator > LDAP Profile configure o
nome e a conta utilizada para acessar o sistema LDAP.
3. No campo Search Context entre com o LDAP search string (igual ao que utilizamos no
LDAP Sync para o CUCM) que contm os usurios do CUPC.
4. No menu drop-down Primary LDAP Server selecione o servidor LDAP configurado no passo 1
desse tpico.
Configurar o profile do CCMCIP
Como j falamos anteriormente o servio CCMCIP foi adaptado para permitir que o CUPC encontre
todos os dispositivos que o usurio est logado e esto disponveis, informando ao usurio na
interface do CUPC.
Veja os passos para configurao abaixo:
1. V em Application > Cisco Unified Personal Communicator > CCMCIP Profile e clique em Add
New.
2. Digite o endereo IP do host CCMCIP primrio e opcionalmente digite o IP do host CCMCIP
backup.
Consideraes finais sobre a configurao do CUPC
O que acabamos de configurar e criar permite que o CUPC se conecte e se comunique com diversos
recursos e aplicaes na rede de comunicaes unificadas, porm outras aplicaes podem ser
criadas, como profiles para acesso a aplicativos de conferncia e muitos outros.
Cada profile para acesso aplicaes pode ser associado aos usurios para que eles acessem esses
servios. Isso pode ser feito de duas maneiras, conforme quadro abaixo:
Acesso aplicaes:
A maneira mais simples configurar um default <profile_type> para que ele seja utilizado pelos
usurios acessarem o servio. Se isso foi feito antes dos usurios serem sincronizados com o CUCM
todas as contas utilizaro esse default profile sem precisar nenhuma configurao extra.
A outra maneira associar individualmente os usurios aos profiles depois que eles foram criados ou
assim que eles esto sendo criados. Isto feito em cada pgina de profile de usurio (End User
configuration page) no CUPS. O mtodo manual pode ser utilizado a qualquer momento para
modificar um usurio especfico ou criar apenas um usurio.
As ltimas configuraes necessrias so no prprio CUPC, pois cada usurio deve customizar seu
CUPC cliente com suas credenciais de acesso (usurio/senha) no seu profile.
Troubleshooting Bsico para o CUPC
A seguir seguem algumas condies de problema que podem ocorrer quando configuramos o CUPC e
suas possveis causas/resolues.
Ao iniciar o CUPC vem a mensagem: The selected device is not available.
Verifique se o dispositivo est registrado no CUCM.

Verifique se o usurio tem um telefone associado no CUCM.
Verifique se o profile do CCMCIP est associado ao usurio no CUPS.
Verifique se o dispositivo e o DN podem ser controlados pelo CTI no CUCM.
O usurio no consegue fazer chamadas pelo CUPC emmodo softphone.
Verifique se o usurio est associado com um dispositivo CSF no CUCM.

Verifique se o dispositivo CSF est registrado no CUCM.
Verifique se o DN, partition e CSS esto corretamente configurados.
Os usurios no so mostrados como ativos (on) durante uma chamada ativa.
Verifique se o SIP entre o CUCM e o CUPS existe e foi corretamente configurado.

Verifique se o usurio est associado a linha (verifique nas configuraes do telefone IP, Device
Profile ou CSF) no CUCM.
O usurio no consegue se logar no CUPC.
Verifique se a conta no est bloqueada.

Verfique se o IP do servidor est correto no CUPC, pois o usurio pode ter alterado esse
parmetro.
Se ao invs do IP o sistema utilizar o host name como referncia verifique se o DNS est
disponvel e corretamente configurado.
Verifique as licenas (license capabilities assignment) no CUCM.
O usurio no consegue adicionar contatos ou as buscas em diretrios no apresentam resultado.
Verifique se o usurio est associado corretamente com o profile do LDAP no CUPS.

Verifique se o Search Context do LDAP est correto no CUPS.
O usurio no consegue controlar o telefone IP modelo Cisco 9971.
Verifique se o telefone tem um usurio vinculado a ele no CUCM.

Verifique se o checkbox Allow Control of Device from CTI est selecionado na pgina de
configurao do dispositivo (device configuration page) no CUCM.
Verifique se o usuro membro dos grupos Standard CTI Enabled e Standard CTI Allow
Control of Phones supporting Connected Xfer and Conf.
O usurio no consegue controlar o telefone IP modelo Cisco 6961.
Verifique se o telefone tem um usurio vinculado a ele no CUCM.

Verifique se o checkbox Allow Control of Device from CTI est selecionado na pgina de
configurao do dispositivo (device configuration page) no CUCM.
Verifique se o usuro membro dos grupos Standard CTI Enabled e Standard CTI Allow
Control of Phones supporting Rollover Mode.
Conceitos de Troubleshooting
Vamos iniciar repetindo a definio de troubleshooting feita pela Wikipedia:
Troubleshooting uma forma de resolver problemas, muitas vezes aplicada na reparao de
produtos ou processos falhados. uma busca sistemtica e lgica pela raiz de um problema, de modo
que possa ser resolvido e o produto ou processo possa ficar novamente operacional. O troubleshooting
necessrio para desenvolver e manter sistemas complexos onde os sintomas de um problema podem
ter diversas causas. usado em muitos campos, tais como na engenharia, administrao de sistemas,
eletrnica, reparao de automveis e o diagnstico de doenas. Normalmente, um processo de
eliminao usado para isolar as possveis causas dos problemas.
Durante a resoluo de um problema ou troubleshooting, se utilizamos uma metodologia consistente
e sistemtica podemos economizar tempo e evitar erros que podem fazer com que a situao se
agrave mais ainda.
Os passos que vamos utilizar nessa sesso esto baseadas nas melhores prticas da Cisco como um
modelo mais efetivo de troubleshooting. Na figura abaixo temos o fluxograma com a sequncia de
passos para realizar o troubleshooting utilizando esse processo.
Vamos agora ver os principais passos do fluxograma que vamos utilizar como base para nosso
processo de troubleshooting:
1. Definio do problema (Define the problem): O primeiro passo analisar o problema e criar uma
definio clara sobre o que est acontecendo. Tambm temos que definir os sintomas e as possveis
causas, o que pode ser feito comparando as condies atuais com a linha de base (baseline), ou seja,
com o comportamento normal que observado no dia a dia da rede.
2. Coletar os Fatos/Sintomas (Gather facts): Aqui devemos coletar e considerar sadas de comandos e
declaraes dos usurios sobre o problema. Devemos aqui eliminar possveis causas para reduzir o
nmero de problemas em potencial. As perguntas que podem ser feitas nessa fase so: Quando o
problema ocorreu? Algo foi alterado antes do problema iniciar? O problema constante ou
intermitente? Tem algum padro nessa intermitncia? Alguma mensagem de erro est sendo gerada?
Algum outro usurio tem o mesmo problema?
3. Considerar Possibilidades (Consider possibilities): Com base no que foi coletado no passo 2 voc
deve identificar quais as causas so mais provveis e lista-las. Esse processo de deciso pode ser
rpido, quase que um processo intuitivo, ou ento demandar muita pesquisa e discusso para chegar
a uma concluso mais precisa.
4. Criar um plano de ao (Create action plan): iniciando da causa mais provvel da lista montada no
passo 3 defina um plano de ao para corrigir o problema. Esse plano de ao deve conter a
modificao de uma varivel por vez, assim voc pode analisar melhor o efeito dessa mudana nica
encima do problema.
5. Implementar o plano de ao (Implement an action plan): Agora chegou a hora de executar ou
aplicar os comandos e alteraes que foram decididas no passo 4. importante no improvisar e
seguir o plano, porm se novas idias virem a tona voc deve voltar ao passo 3 novamente.
importante aqui fazer uma observao para verificar se a ao tomada no acabou piorando o
problema, nesse caso desfaa a mudana. Por isso, no plano definido no passo 4 importante ter
como mudar e como voltar no caso dessa mudana ter agravado o problema ou ento simplesmente
no ter resolvido o problema. Tambm importante minimizar o impacto dessas alteraes no
ambiente de produo do sistema, especialmente limitando a durao de aes que tragam
vulnerabilidades segurana do sistema, como por exemplo, desabilitar temporariamente access lists
ou regras de firewall para verificar se o problema no est sendo gerado pelos filtros de segurana.
6. Observar os resultados (Observe results): O problema foi resolvido?
6a. No, o problema no foi resolvido: Se o problema no foi resolvido, desfaa as mudanas
implementadas no item 5 e volte ao passo 4.
6b. Sim, problema Resolvido: Se o problema foi resolvido, documente a soluo, a causa raiz (root
cause) desse problema e as alteraes que foram feitas no sistema.
Informao extra:
O processo de troubleshooting muito importante e normalmente envolve o processo da TI da
empresa em que voc trabalha, por exemplo, se sua empresa trabalha seguindo as recomendaes
do ITIL (Information Technology Infrastructure Library) e tem um processo de gerenciamento de
problemas e mudanas, voc ter que seguir os processos e padres estabelecidos. Por exemplo, se
voc tiver que alterar algum parmetro para resolver o problema isso ter que passar pela avaliao
do controle de mudanas (change management), com a documentao e aprovaes necessrias para
que voc possa realizar os testes e alteraes.
Outro ponto importante na hora de resolver um problema na prtica observar qual fase do ciclo de
vida do ambiente implementado, por exemplo, o problema est acontecendo durante a fase de
implantao? Ou ento o ambiente j est implantado e o problema ocorreu durante o dia? Ou ento
aps uma mudana implementada durante a madrugada? Com essas informaes voc pode
determinar mais facilmente muitos dos problemas que podem ocorrer no somente no sistema de
comunicaes unificadas, mas tambm em todo e qualquer sistema que faz parte da empresa.
Problemas Comuns no Registro de Telefones no CME
Vamos iniciar esse captulo contextualizando a resoluo de problemas com um caso que quase todos
j passamos com um colega ou at mesmo com um familiar que nos liga ou pede ajuda para resolver
um problema em seu computador dizendo a famosa frase: Meu computador no est funcionando,
voc poderia dar uma olhadinha para mim?.
Note que essa uma frase muito abrangente e a causa do problema pode ser uma gama enorme de
opes, porm quase que instintivamente comeamos a fazer perguntas de prova (probing questions)
para tentar reduzir as opes do problema e chegar mais perto do que realmente est acontecendo.
Veja abaixo alguns exemplos de perguntas que podemos fazer.
Probing Questions:
Os leds do computador esto acesos?

O monitor est mostrando alguma imagem ou mensagem de erro?
Voc consegue abrir seus programas ou aplicaes?
Baseado nas respostas dessas questes voc pode iniciar o processo de deduo e montar um plano
de ao para solucionar o problema ou simplesmente mande seu amigo trocar o computador que
muito mais simples (claro que essa ltima opo apenas uma brincadeira!).
Agora vamos fazer uma analogia para o troubleshooting em um ambiente de telefonia IP. Quando
um usurio liga dizendo, por exemplo, Meu telefone IP no est funcionando, voc ter que fazer
perguntas para tentar reduzir o escopo do problema, porm com foco no processo de
troubleshooting baseado nos problemas que uma rede de telefonia IP pode estar sujeita.
Voc pode fazer perguntas como as mostradas abaixo:
Meu telefone IP no est funcionando:
Como voc conseguiu me ligar se o seu telefone no est funcionando?

Quando voc notou que seu telefone parou de funcionar?
O seu telefone mostra o seu ramal no display do telefone?
Quando voc tira o telefone do gancho voc ouve um tom de discar ou algum outro tom?
O que acontece quando voc disca para algum?
Que mensagem est aparecendo agora na tela do telefone?
Importante:
Veja que todas essas perguntas esto focando seu troubleshooting para descobrir em que rea pode
estar acontecendo o problema, pois em uma rede de telefonia IP temos as seguintes reas que
podem estar gerando o problema:
Na prpria rede IP ou em sua infraestrutura

Nas configuraes do telefone IP
Nas configuraes do prprio CME
Assim como qualquer outro dispositivo de dados o telefone IP precisa da rede e seus servidores para
funcionar corretamente, pois sem eles o telefone IP no ir funcionar. Portanto, o mais importante
quando fazendo troubleshooting com problemas relacionados rede so os que tem a ver com
o processo de inicializao dos telefones IP (boot process conforme abaixo)
Processo de boot de um telefone IP:
Vimos em captulo anterior que at que o telefone IP Cisco fique operacional para o usurio ele passa
por algumas etapas, conhecidas como processo de boot de um telefone IP. So elas:
Etapa 01: Receber alimentao PoE do switch
alimentao necessria para por em funcionamento o telefone IP.
Assim que o telefone IP liga ele roda um bootstrap e carrega o firmware que est armazenado em sua
memria flash. Com essa imagem carregada o telefone IP pode inicializar seu sofware e hardware.
Nessa etapa o switch envia um pacote CDP ao telefone, informando qual a VLAN que o telefone
dever utilizar para trafegar voz a VLAN de voz. Lembre-se que caso o switch no seja da Cisco ele
no ter suporte ao CDP, portanto voc dever configurar manualmente a VLAN de voz no telefone.
O telefone IP envia uma requisio em broadcast para o DHCP Server. O servidor DHCP responde com
um endereo IP vlido e to logo o telefone IP aceita a oferta do endereo ele recebe todas as opes
configuradas no DHCP, tais como a opo 150 que informa o endereo do servidor TFTP de onde o
telefone IP dever baixar os arquivos de configurao.
Assim que o telefone IP toma conhecimento do endereo do servidor TFTP ele requisita os arquivos
de configurao (.cnf ou .xml), onde consta a lista dos agentes processadores de chamadas onde
o telefone dever se registrar - um servidor CUCM ou um roteador com CME.
fontes.
Vamos recordar o processo que j foi analisado com detalhes em captulos anteriores.
A partir dos conceitos sobre o processo de boot do telefone e seu registro voc pode elaborar seu
prprioesquema de troubleshooting para resolver problemas quando um telefone IP fica travado
nessa etapa de inicializao.
Por exemplo, quando um telefone IP no consegue pegar um endereo IP do servidor DHCP, alcanar
o servidor TFTP ou se registrar no roteador CME, ele fica reinicializando e tentando de novo
indefinidamente. Com isso voc pode verificar em que parte do processo de boot o telefone IP est
parando, observando as mensagens que aparecem na tela do telefone ou analisando os menus de
administrao do telefone IP. Uma vez descobrindo em que etapa o processo de boot est parando
voc pode partir para uma forma de solucionar o problema. Por exemplo, voc percebeu que o
telefone pegou o IP mas no consegue contatar o roteador CME, isso pode ser um problema de
roteamento ou alguma ACL aplicada pode estar impedindo a conexo.
Importante:
Uma dica importante que normalmente na primeira vez que um telefone colocado na rede, ou
seja, recm-instalado, ele pode reinicializar vrias vezes at pegar o arquivo de configurao correto e
fazer as atualizaes de firmware necessrias.
Outro ponto importante (uma dica prtica citada nos captulos iniciais) que se o telefone IP est
com uma verso de firmware muito antiga pode ser que ele no consiga ir direto para uma verso
muito mais nova que a dele, sendo necessria uma atualizao intermediria antes de passar para a
verso mais atual.
Problemas Comuns Relacionados Rede
Vamos agora a algumas situaes de problemas relacionados com a rede e o processo para solucionlos.
Basicamente iremos tratar de problemas relacionados com:
Alimentao (PoE),
VLAN de Voz,
DHCP Server,
TFTP Server e
Roteador CME.
Problemas de Alimentao (PoE)

Problemas relacionados com a energizao do telefone IPso fceis de serem identificados, pois o
telefone vai ficar apagado, sem mostrar nada em seu display.
Portanto se o telefone est apagado voc pode verificar as seguintes possibilidades citadas abaixo.
Conexes fsicas:
Verifique se o conector do cabo de rede do telefone IP est plugado de maneira correta e

segura.
Verifique as conexes no patch panel e o prprio cabo UTP est funcionando corretamente
com todos os pinos, pois o PoE utiliza os quatro pinpos no utilizados para transmisso de
dados.
Um teste bem simples conectar um telefone IP que voc sabe que est funcionando, se ele
ligar com certeza no um problema fsico de cabeamento.
O switch PoE:
Certifique-se que o switch est ligado e operacional.

Certifique-se que o nmero de clientes PoE no excederam a potncia mxima suportada pelo
switch utilizando o comando show power inline.
Com o show run veja se existem portas com o comando power inline never, o qual
desabilita o PoE na porta.
Certifique-se que est conectando o telefone IP nas portas que suportam PoE, pois em alguns
modelos de switch nem todas as portas suportam o PoE.
Verificar o telefone IP:
Verifique se o telefone no tem mdulos de expanso que excedem a potncia mxima

suportada pela porta do switch.
Troque o telefone IP de porta para ver se ele sobe e no um problema na porta original que o
telefone est conactado.
Conecte outro telefone IP na mesma porta do que est com problema para verificar se ele
recebe alimentao, indicando um possvel problema com o telefone original.
Verifique se o telefone IP e o switch PoE so compatveis, lembrando que switches Cisco
suportam Cisco inline power, 802.3af e 802.3at.
Importante:
No caso do telefone ligar e simplesmente no inicializar, antes de iniciar um processo de
troubleshooting mais apurado voc pode tentar fazer um reset de fbrica nesse aparelho, voltando
todas as configuraes ao original de fbrica. Pode ser que a maneira de fazer o reset varie de modelo
para modelo, porm todos eles tm essa opo. Normalmente o que ocorre que uma configurao
antiga pode ficar presa em um dos campos chaves do telefone IP, impedindo sua inicializao.
Quando resetamos o telefone essa configurao "presa" apagada e ento o telefone consegue
finalizar a inicializao.
Na maioria dos modelos de telefone IP da Cisco o reset de fbrica realizado da seguinte maneira:
1. Desconecte o telefone IP da rede e da alimentao.
2. Pressione o boto # e com ele pressionado conecte novamente o telefone IP na rede.
3. Quando o led do monofone comear a piscar, solte o tecla # e digite 123456789*0#
Problemas com a VLAN de Voz
Se um telefone IP no conseguir pegar sua VLAN de Voz ou pegar a VLAN de Voz errada, ele pode ter
problemas de conexo com seus servidores e servios bsicos para inicializao e registro (DHCP,
TFTP, CME e assim por diante).
Normalmente quando isso ocorre o telefone fica reinicializando continuamente e voc pode certificar
o problema com a VLAN de Voz com os passos mostrados abaixo.
Verificando as seguintes configuraes dos switches:
Verifique se as portas onde esto configurados os telefones esto com a configurao correta
utilizando o comando show run.
Verifique se o modo de operao da interface est correto com o comando show interface
<interface_name> switchport.
Verifique se a VLAN de Voz est criada no switch com o comando show vlan.
Certifique-se que a VLAN de Voz est permitida em todos os trunks necessrios com o
comando show interface trunk.
Verifique se o CDP est habilitado na porta que est conectada ao telefone IP com problema,
pois o ID da VLAN de Voz passada pelo CDP. Voc pode ver no comando show run ou show
cdp interface (a interface com o cdp desabilitado no aparece na sada do comando).
Verificando os seguintes itens no telefone IP:
Se voc est em um telefone IP fsico (hardphone) acesse as configuraes de rede em

network settings utilizando o boto Settings do telefone.
Verifique se o telefone recebeu a configurao correta da VLAN de voz.
Verifique se o endereo IP do telefone est na faixa correta da VLAN de Voz.
Acesse o telefone via web browser utilizando seu endereo IP verificado no passo anterior para
verificar os arquivos de log para procurar mais pistas sobre o problema.
Problemas com o DHCP Server

Em um ambiente de switches com VLAN a alocao de endereos IPs via DHCP est intimamente
ligada VLAN que esse dispositivo pertence, portanto para um telefone IP est muito ligado VLAN
de Voz que ele est vinculado. Isso nos leva a uma concluso que um suposto problema de DHCP
pode ser na realidade um problema que tratamos no item anterior, por isso esse um diagnstico
que requer muito cuidado.
Se um telefone IP est vinculado a VLAN errada o IP que ele vai receber do servidor DHCP
provavelmente estar fora da faixa planejada para os telefones e a opo de servidor TFTP pode no
ter sido passada para ele, com isso o telefone no consegue se registrar e assim por diante.
Acompanhe abaixo um processo de troubleshooting paraproblemas relacionados ao DHCP.
Verificar o DHCP helper-address:
Quando o roteador CME no est sendo utilizado como servidor DHCP e voc tem um servidor
centralizado, o roteador ou switch Layer 3 deve permitir que a VLAN de voz encaminhe as
requisies DHCP ao servidor correto.
O comando helper-address deve estar na subinterface do roteador que est conectada
VLAN de voz.
Verificar o servidor DHCP (externo ou o prprio roteador CME):
Verifique se o pool de endereos IP foi criado corretamente para os dispositivos de voz

(inclusive quantidade).
Verifique se os IPs do pool no se esgotaram, pois isso muito comum na prtica devido
troca de dispositivos e do lease time do DHCP (os equipamentos antigos ficam com seus IPs
presos e registrados no servidor DHCP at finalizar o contador).
Verifique se a opo 150 do DHCP (servidor TFTP) est configurada para o pool.
Conecte um micro ou laptop de teste na VLAN de Voz para testar o pool.
Se voc tem acesso ao telefone IP, v at as configuraes de rede dele em network settings
utilizando o boto Settings.
Verifique os dados recebidos pelo servidor DHCP: o IP e mscara, default gateway, servidor
DNS, servidor TFTP e quaisquer outras opes configuradas.
Faa um teste de ping para esse telefone a partir de um dispositivo situado em outra rede IP
para certificar que no existe um problema de roteamento (certifique-se que no tem
nenhuma ACL que possa bloquear esse fluxo).
Importante:
Conforme mencionado no incio, voc deve tomar cuidado antes de assumir que existe um problema
de DHCP, se o que est causando a falha na realidade no um problema de VLAN, TFTP ou do
prprio CME. Um teste bem simplesque pode ser realizado configurar o IP estaticamente no
telefone apenas com IP, Mscara, Gateway e servidor TFTP. Se o telefone registrar normalmente
bem provvel que o problema est realmente ligado ao DHCP ou a VLAN de Voz. Se no funcionar
mesmo com o IP esttico, provavelmente voc tem um problema relacionado a roteamento, servidor
TFTP ou no prprio CME.
Os problemas de roteamento e TFTP podem ser testados com um laptop ou desktop, configurando
um IP na faixa dos telefones e colocando ele na VLAN de Voz. Com ping, trace e telnet voc vai testar
os problemas de roteamento. J sobre o TFTP, voc pode instalar um cliente no seu micro e tentar
buscar um arquivo que est no roteador CME, assim voc se certifica que o caminho e o servio do
TFTP esto OK ou no. Ainda sobre o TFTP, para verificar se a solicitao est chegando ao roteador
voc pode utilizar o comando debug tftp events e procurar pela solicitao a partir do IP
configurado no computador.
Problemas com o TFTP Server
Nesse ponto do curso voc j deve saber que o servio de TFTP crucial para o funcionamento dos
telefones IP, pois com ele que os telefones buscam seu firmware e arquivo de configurao que
contm as informaes para que o telefone possa se registrar no CME ou no CUCM e demais
informaes para sua operao. Portanto, sem o TFTP voc vai ter problemas srios no
funcionamento dos telefones IP!
Apesar do CME poder trabalhar com um servidor TFTP externo, normalmente isso no feito e o
prprio roteador utilizado para armazenamento dos arquivos que os telefones IP necessitam para
operar. Isso feito utilizando a memria flash e a DRAM do roteador para armazenar esses arquivos.
Com essa breve recapitulao sobre o TFTP, vamos agora aos procedimentos que podemos seguir
para realizar o troubleshooting de problemas com o servidor TFTP. Acompanhe abaixo:
Verificar o roteamento at o servidor TFTP:
Se o servidor TFTP est em uma subrede diferente dos telefones IP, voc deve verificar se
existe conectividade entre essas duas redes com ping.
Faa o teste colocando um dispositivo de teste como um micro ou laptop e utilizando um TFTP
cliente tente buscar um arquivo que voc conhece no servidor TFTP.
Verificar o servidor TFTP:
Verifique se o servidor est operacional e ativo (permitindo a transferncia dos arquivos).

Verifique se o firmware para seus telefones IP est realmente disponvel no servidor TFTP.
Verifique se os arquivos de configurao para os telefones tambm esto disponveis no
servidor (o nome deve ser SEP + MAC address do telefone).
Verifique se voc entrou com o comando create cnf-files dentro do telephony-service do
roteador CME para gerar os arquivos de configurao no servidor TFTP.
Se voc tem acesso ao telefone IP, v at as configuraes de rede dele em network settings
utilizando o boto Settings.
Verifique se o telefone tem o IP do servidor TFTP corretamente configurado, seja via DHCP ou
de maneira esttica.
Problemas com o Roteador CME

Quando falamos de problemas no roteador CME o problema mais comum que encontramos a
mensagem de erro Registration Rejected no telefone IP. Esse erro significa que o telefone IP passou
por todo processo de boot (inicializao) e quando vai tentar se registrar no CME que o problema
ocorre.
Sabendo que o problema da rejeio no registro do telefone IP ocorre aps a inicializao ter rodado
com sucesso, ento quase que 100% desse problema provavelmente estar encima da configurao
do ephone, ou seja, quando aparece a mensagem de registration rejected quase sempre ela
gerada por um problema na configurao do telefone no CME. Portanto, se voc pegar essa
mensagem, primeiro verifique se existe a configurao no CME desse telefone IP em questo.
O que vincula o telefone IP na configurao do CME oendereo MAC dele, portanto verifique se o
MAC digitado no ephone bate com o MAC do telefone IP, pois nesse ponto que normalmente o erro
ocorre. E onde eu vejo qual o MAC do telefone IP para configurar no CME? Normalmente podemos
obter o MAC das seguintes maneiras (veja abaixo).
Verificar o MAC do Telefone IP:
Na etiqueta da caixa do telefone;

Temos outra etiqueta no prprio telefone IP (essas duas primeiras no so muito confiveis);
Voc pode conectar o telefone IP em uma porta conhecida do switch e dar um show macaddress-table;
Ou ativando o auto registro dos telefones IP com o comando auto-reg-ephone dentro do
modo de configurao do telephony-service, aps isso verificando se um novo registro
aparece, pois com isso voc pode verificar qual o MAC correto do telefone IP e arrumar a
configurao no CME.
Dica:
Outra meneira de verificar o problema de registro dos telefones IP no CME utilizando o comando
debug ephone detail.
Com esse comando voc vai ter o processo de registro detalhado assim que ele est ocorrendo,
porm esse comando deve ser utilizado com muito cuidado quando um grande nmero de telefones
IP estiver fazendo o registro simultaneamente, pois isso pode sobrecarregar tanto a voc (a anlise
que voc deve fazer das mensagens fica muito complexa) como o roteador CME devido ao nmero de
mensagens que iro aparecer.
Problemas Relacionados ao Plano de Discagem e Qualidade de Servio
Esse tpico que vamos abordar agora est um pouco fora do escopo do CCNA Voice, mas devido a sua
importncia prtica e por constar no material oficial vamos fornecer algumas instrues para o
troubleshooting bsico relacionado a problemas de dial-plan e QoS.
Problemas relacionados ao dial-plan:
Os problemas relacionados ao dial-plan (plano de discagem) ocorrem aps os telefones completarem
o processo de registro no CME, quando o usurio tenta fazer uma ligao e recebe um tom de
ocupado ou reordenao (fast busy/reorder tone), ou seja, no consegue completar a ligao para
determinado destino. Nesses casos importante verificar se no existe um problema com o destino
que o usurio est discando ou com a prpria prestadora de servios de telecom local, no caso de
ligaes externas.
Problemas relacionados ao QoS:
J os problemas relacionados ao QoS vo desde rudos, distores na voz, at o ponto da ligao cair
devido a qualidade na transmisso dos pacotes de voz pela rede IP. Lembrem que no incio do curso,
quando estudamos os conceitos de QoS, que nem sempre um link com largura de banda alta significa
que a voz ir fluir sem problema na rede, pois existem muitos mais fatores que apenas banda para
que no haja problema com um fluxo de voz em uma rede IP.
Problemas Relacionados ao Plano de Discagem - Dial-Plan
Para fazer o troubleshooting em problemas relacionados ao plano de discagem (dial-plan) em um
roteador CME voc ter que analizar os dial peers criados nesse roteador.
Devemos sempre lembrar que o dial-peer gera a configurao do roteadomento das chamadas de voz
atravs da rede IP, portanto se voc configurar incorretamente ou de maneira incompleta seus dial
peers as chamadas no iro ser completadas corretamente.
Vamos aqui focar em dois comandos para esse tipo de resoluo de problemas de plano de discagem,
que so os mostrados abaixo:
show dial-peer voice summary e

debug voip dialpeer
Assim como o show ip interface brief permite que vejamos um resumo das rotas existentes em um
roteador, o comando show dial-peer voice summary permite que voc veja uma tabela com todos
os dial peers configurados no seu gateway de voz. Se as chamadas esto falhando assim que o destino
digitado, esse comando o primeiro passo para o troubleshooting, pois ele permite que vejamos as
rotas das chamadas. Vamos utilizar esse comando para verficar se:
O dial peer existe para aquele destino

O destination pattern para o destino foi configurado corretamente
A porta de voz ou IP alcanvel pelo roteador CME
Veja um exemplo da sada do comando na figura abaixo:
Nesse exemplo, se analisarmos a primeira linha temos que ao discar qualquer ramal de quatro dgitos
que inicie com6XXX ser encaminhado pela rede IP para um CUCM com
endereo 192.168.1.201 pelo dial peer 6000.
J as chamadas locais iniciam com o dgito 0 e sero encaminhas para a porta 0/3/0 no dial peer 1.
Note que vamos ter um problema aqui quando uma segunda ligao for realizada para a PSTN, pois o
dial peer 2, que aponta para a porta 0/3/1 tem um problema, voc conseguiu perceber que a porta
est down? Portanto, dessa maneira iniciamos uma primeira verificao do que nosso roteador CME
pode ou no alcanar em termos de numerao telefnica.
Verificar se existe um dial peer que faa correnpondncia (match) com um determinado nmero
discado e verificar se realmente a ligao consegue ser completar so duas coisas diferentes. Se
mesmo aps voc verificar que est tudo ok com o dial peer a ligao ainda no estiver sendo
completada (recebendo tom de reordenao - reorder tone), voc ter que utilizar o comando debug
voip dialpeer para ajudar a identificar onde est acontecendo o problema. Esse debug permite que
voc veja o que est acontendo a cada dgito discado e j foi estudado no incio do curso. Vamos
relembrar com a sada aabaixo, onde os principais campos esto em destaque.
Note que a cada dgito discado o roteador verifica se existe uma correspondncia nos dial peers
configurados. Para os trs primeiros dgitos discados existe um resultado bem claro: more digits
needed ou so necessrios mais dgitos. Quando o quarto dgito discado o roteador encontra
correspondncia (match) com o dial-peer identificado com a tag 1001 e processa a chamada.
Portanto, esse comando de debug muito til para verificar em tempo real o processo de
correspondncia dos dgitos que o roteador CME est fazendo, ou seja, o processamento dos dgitos
em tempo real. Com isso voc pode pedir ao usurio para discar pausadamente os dgitos e verificar
onde est parando o processo.
Problemas Relacionados ao QoS
Agora vamos tratar de problemas relacionados ao QoS, os quais tem uma metodologia e foco
diferentes dos que utilizamos para resolver problemas de dial-plan, pois aqui estamos lidando com
possveis problemas relacionados ao trfego da voz pela rede IP.
Quando falamos de QoS temos que lembrar dos requisitos para que o trfego de voz recomendados
pela Cisco para termos chamadas de voz com alta qualidade.
Delay fim-a-fim (em um sentido): 150 ms ou menor.

Jitter (variao no delay): 30 ms ou menor.
Perda de pacotes (Packet loss): 1% ou menor.
Lembre que discutimos esses parmetros e os outros que trataremos aqui no captulo 7. Outros
dois fatores importantes que influenciam o trfego de voz pela rede:
O tipo de CODEC que voc est utilizando para fazer as chadamas.

O nmero de chamadas simultneas que sero realizadas atravs da rede.
Os fatores acima esto relacionados ao uso da largura de banda e o que define qual a ocupao de
banda o tipo de CODEC que estamos utilizando, segue uma tabela abaixo com os principais tipos
utilizados.
O clculo desses valores depende de vrias informaes e a tabela mostra valores mdios, pois como
calcular exatamente a largura de banda por chamada estudado em uma das provas do CCNP Voice,
o CVOICE.
Com todos os dados comentados, os quais so as condies que sua rede deve oferecer aos pacotes
de voz que so transmitidos via RTP, voc pode configurar o QoSnos roteadores e switches para que
eles possam garantir, atravs da priorizao e enfileiramento, a largura de banda e a prioridade
necessria para que as chamadas de voz sejam feitas com qualidade.
Aps configurar o QoS minha rede vai funcionar perfeitamente. Ser que essa afirmao est
correta? Teoricamente sim, porm recomenda-se a verificao contnua de maneira pr-ativa se os
parmetros estabelecidos no QoS esto realmente sendo alcanados. Isso pode ser feito de diversas
maneiras e existem sistemas sofisticados (bastante caros) que cumprem essa finalidade, porm
quando voc compra um telefone IP da Cisco ele j possui integrado um sistema bsico de
monitorao de QoS que voc pode utilizar para fins de trobleshooting.
Para visualizar essas informaes pressione o boto de help do telefone (question-mark button - help
menu) duas vezes para buscar as estatsticas quando a chamada est ativa (dica: pressione
rapidamente as duas vezes). Voc poder verificar os seguintes itens:
Codec
Packet size: tamanho dos pacotes
Received and transmitted packets: pacotes transmitidos e recebidos
Average and maximum jitter: jitter mdio e mximo
Lost packets: pacotes perdidos
Veja na figura abaixo uma imagem do telefone com a sada das estatsticas.
Outra maneira de verificar as estatsticas da chamada no telefone IP atravs do acesso web do

telefone. Abra um browser e digite o IP do telefone enquanto a chamada estiver ativa, depois clique
no link referente ao stream de voz que voc deseja verificar (se tiver apenas uma chamada ativa
estar no stream 1). Veja na figura abaixo um exemplo dessa tela.
No roteador tambm podemos verificar as estatsticas de QoS atravs do comando show policy-map
interface x/y. Quando configuramos o QoS em um roteador temos vrias opes para utilizar
(durante o curso vimos a utilizamo do autoqos), porm quando vamos aplicar essas configuraes
no roteador utilizamos comandos nas interfaces chamados de service-policy.
Esses comandos aplicam uma policy-map na interface que vincula uma poltica de QoS a ela, muito
semelhante aplicao de uma ACL em uma interface para tratar de questes de segurana, porm
aqui estamos tratando de QoS. Portanto, esse comando pode ser dado por interface para ver as
estatsticas de QoS dessa interface especfica. Veja a sada do comando abaixo para uma interface
configurada com autoqos.
O comando mostra as caractersticas e possveis problemas da poltica de QoS aplicada na sada

(outbound) dainterface fast 0/1 do roteador. O nome da poltica criada pelo autoqos AutoQoSPolicy-Trust. Ela tem trs classes de priorizao, sendo que a primera chamada de AutoQoS-VoIPRTP-Trust e garante 70% do trfego para os pacotes de voz , uma taxa de 70000 kbps. No h perda
de pacotes nessa sada de comando, se houvesse voc veria no campo drop rate.
O descarte (drop) ou perda de pacotes causado normalmente pelo congenstionamento em um link
WAN ou pelo trfego de voz estar acima do que foi provisionado pelo QoS (acima do limite
configurado).
Um link WAN congestionado significa que voc no temlargura de banda suficiente para passar todas
as chamadas que esto sendo realizadas pela WAN, por isso os pacotes so descartados.
O mesmo ocorre quando temos mais ligaes tentando ser ralizadas que o planejado pois se voc tem
mais chamadas que o link suporta voc acabar congestionando (lotando) o link com as chamadas de
voz, o que ir tambm causar descarte de pacotes. Normalmente quando utilizamos um tipo de
enfileiramento chamado Strict Priority Queuing o roteador garante que uma determinada banda
est garantida para os pacotes de voz, porm se esse trfego tentar ultrapassar essa largura de banda
ele ser descartado. Essa tcnica garante que o administrador de redes saiba exatamente a banda que
est sendo utilizada em seu link WAN com a voz, impedindo que o trfego de dados tente ocupar esse
espao.
Apesar de estarmos tratando do CME, todas essas recomendaes de troubleshooting valem para
telefones que se registram no CUCM.
Troubleshooting em Problemas de Conectividade e Qualidade nas Chamadas com o

CUCM
O conceito de um troubleshooting organizado e sistematizado ser reforado nesse captulo, portanto
no se assuste com a repetio, pois com uma abordagem clara voc ser capaz de solucionar os
problemas de uma maneira mais tranquila, com um ndice de acerto muito maior ao invs de ficar
tentando atirar para todos os lados procurando sem rumo uma soluo. O pior que muitas vezes
conseguimos resolver os problemas dessa maneira desorganizada (com o mtodo metralhadora),
porm ao final do processo no conseguimos identificar a sua causa raiz ou documentar o que foi
realizado.
Como j comentamos anteriormente, os passos que vamos utilizar nessa sesso esto baseadas nas
melhores prticas da Cisco como um modelo mais efetivo de troubleshooting. Veja na figura abaixo o
fluxograma com a sequncia de passos para realizar o troubleshooting utilizando esse processo.
1. Definio do problema (Define the problem): O primeiro passo analisar o problema e criar uma
definio clara sobre o que est acontecendo. Tambm temos que definir os sintomas e as possveis
causas, o que pode ser feito comparando as condies atuais com a linha de base (baseline), ou seja,
com o comportamento normal que observado no dia a dia da rede.
2. Coletar os Fatos/Sintomas (Gather facts): Aqui devemos coletar e considerar sadas de comandos e
declaraes dos usurios sobre o problema. Devemos aqui eliminar possveis causas para reduzir o
nmero de problemas em potencial. As perguntas que podem ser feitas nessa fase so: Quando o
problema ocorreu? Algo foi alterado antes do problema iniciar? O problema constante ou
intermitente? Tem algum padro nessa intermitncia? Alguma mensagem de erro est sendo gerada?
Algum outro usurio tem o mesmo problema?
3. Considerar Possibilidades (Consider possibilities): Com base no que foi coletado no passo 2 voc
deve identificar quais as causas so mais provveis e lista-las. Esse processo de deciso pode ser
rpido, quase que um processo intuitivo, ou ento demandar muita pesquisa e discusso para chegar
a uma concluso mais precisa.
4. Criar um plano de ao (Create action plan): iniciando da causa mais provvel da lista montada no
passo 3 defina um plano de ao para corrigir o problema. Esse plano de ao deve conter a
modificao de uma varivel por vez, assim voc pode analisar melhor o efeito dessa mudana nica
encima do problema.
5. Implementar o plano de ao (Implement an action plan): Agora chegou a hora de executar ou
aplicar os comandos e alteraes que foram decididas no passo 4. importante no improvisar e
seguir o plano, porm se novas idias virem a tona voc deve voltar ao passo 3 novamente.
importante aqui fazer uma observao para verificar se a ao tomada no acabou piorando o
problema, nesse caso desfaa a mudana. Por isso, no plano definido no passo 4 importante ter
como mudar e como voltar no caso dessa mudana ter agravado o problema ou ento simplesmente
no ter resolvido o problema. Tambm importante minimizar o impacto dessas alteraes no
ambiente de produo do sistema, especialmente limitando a durao de aes que tragam
vulnerabilidades segurana do sistema, como por exemplo, desabilitar temporariamente access lists
ou regras de firewall para verificar se o problema no est sendo gerado pelos filtros de segurana.
6. Observar os resultados (Observe results): O problema foi resolvido?
6a. No, o problema no foi resolvido: Se o problema no foi resolvido, desfaa as mudanas
implementadas no item 5 e volte ao passo 4.
6b. Sim, problema Resolvido: Se o problema foi resolvido, documente a soluo, a causa raiz (root
cause) desse problema e as alteraes que foram feitas no sistema.
Informao extra:
A sequncia de passos em ingls : Define > Gather >Consider > Create > Implement > Observe e
um mnemnico para decorar a sequncia que normalmente utilizado a
frase: Dogs Gobble Cookies, Cats IrritateOwners. Veja na figura abaixo a sequncia das atividades
em ingls.
Resolvendo problemas de registro dos telefones IP

O processo de registro de um telefone IP no CUCM no simples, alm disso, tem vrios pontos de
falha e se um passo do registro falha consequentemente o prximo tambm ir falhar.
Por isso temos que utilizar aqui uma abordagem estruturada, como a metodologia chamada Dividir
para Conquistar (Divide and Conquer), a qual podemos rapidamente verficar os passos do registro que
tiveram sucesso e iniciar o troubleshooting a partir do primeiro ponto de falha no passo a passo do
processo de registro.
Podemos categorizar os problemas de registro no CUCM nos seguintes provveis pontos de falha
(note que ser semelhante aos do CME). Acompanhe abaixo:
Problemas locais com o prprio telefone IP

Problemas com VLAN ou de compatibilidade com o switch
Problemas com o servio de DHCP
Problemas com o servidor ou servio TFTP
Problemas de registro com o CUCM
Vamos agora analisar um cenrio onde o telefone IP no est se registrando no CUCM, sendo que ele
est utilizando o endereamento IP via DHCP.
Os passos ao lado descrevem uma sequncia de problemas que podem ocorrer e as melhores prticas
para realizar o troubleshooting em uma ordem estabelecida, porm com o tempo e a experincia
voc pode com um determinado sintoma pular alguns passos e ir direto ao ponto com problema.
Continue navegando nesse slide para mais detalhes.
1.
2.
3.
4.
5.
Problemas locais com o telefone IP

Problemas com VLAN ou de compatibilidade com o switch
Problemas com o DHCP
Problemas com o TFTP
Problemas de registro com o CUCM
1. Problemas locais com o telefone IP: Nesse ponto inicial do troubleshooting voc pode ir ao prprio
telefone e verificar suas configuraes para identificar em que passo do processo de registro o
telefone parou.
Isso pode ser feito pressionando o boto Settings do telefone e selecionando a opo Network
Configuration na lista de opes mostradas no display. Indo para baixo na tela voc vai encontrar a
configurao do protocolo IP em IP Configuration e verificar se o telefone recebeu corretamente
seu endereo IP, mscara de subrede, default gateway e servidor TFTP.
Se esses itens estiverem faltando ou incorretos voc deve verificar se o DHCP cliente est habilitado
indo em Settings > Network Configuration, rolando a tela para baixo verifique se a opo DHCP
Enabled est configurada como Yes.
Se essas verificaes mostraram que o ltimo item do DHCP cliente est habilitado, mas o telefone
continua sem receber as informaes de rede, voc deve seguir para o prximo passo.
2. Problemas com VLAN ou de compatibilidade com o switch: Verifique se as portas do switch foram
configuradas corretamente para suportar os telefones IP. As portas que os telefones IP sero
conectados devem ter uma VLAN de voz (voice vlan) atribuda a ela, alm disso, se houver um micro
conectado ao telefone deve ter uma VLAN de dados separada para o micro (essa configurao foi
realizada no captulo 4).
Verifique se o ID (nmero) das VLANs est correto. Se a configurao do switch estiver correta, passe
para o prximo passo.
Dica: Cuidado ao escolher as portas para conectar os telefones IP ao switch, pois alguns modelos no
tem todas as portas habilitadas com PoE, tendo portas especficas para esse fim e as demais sem o
recurso de PoE disponvel.
3. Problemas com o DHCP: Inicie verificando se servidor DHCP est rodando e no tem a faixa de IPs
alocveis aos clientes esgotada. Depois verifique os escopos do DHCP (subredes ou pools) esto
corretamente configurados com a faixa correta de endereos IP, mscara de subrede, default gateway
e a opo 150 (IP do TFTP).
No telefone IP v novamente em Settings > Network Configuration para verificar se o IP
configurado est correto, de acordo com o que o servidor DHCP deveria ter passado.
Verifique tambm se o IP servidor TFTP est correto em TFTP Server 1. Se o servidor DHCP est em
uma rede remota, ou seja, em uma subrede diferente do telefone IP, o roteador vai bloquear as
solicitaes do DHCP que so enviadas em broadcasts por default. Nesse caso voc deve utilizar o
comando ip helper-address <ip_address> no roteador local para que ele encaminhe a solicitao
DHCP ao servidor correto.
4. Problemas com o TFTP: Quando o telefone inicializa (pegou o IP correto e o endereo do TFTP) ele
busca no servidor TFTP seu arquivo de configurao. O nome do arquivo buscado nomeado como
SEP<mac>.cnf.xml.
Se o telefone achar o arquivo de configurao, significa que ele foi adicionado com sucesso no CUCM
ou Cisco Unified Communication Manager Express (CME) e o arquivo estava presente para ser
copiado pelo telefone. Agora, se o telefone no foi configurado no sistema esse arquivo no ir
existir, nesse caso o telefone busca o arquivo nomeado como XMLDefault.cnf.xml, o qual um
arquivo padro que est sempre disponvel.
Se o telefone no consegue buscar nenhum desses arquivos voc deve verificar se o IP do TFTP est
correto no telefone em Network Configuration, conforme citado anteriormente.
Verifique tambm se o servio do TFTP est rodando no servidor e o IP dele est correto, conforme
planejado e passado pelo DHCP na opo 150. Voc pode verificar o estado do processo do TFTP no
telefone indo em Settings > Status Messages e procurando por uma mensagem de erro, como por
exemplo, File Not Found:SEP<mac address>.cnf.xml, TFTP Timeout: SEP<mac address>.cnf.xml e
SEP<mac address>.cnf.xml. Veja afigura abaixo do menu do telefone com um exemplo de
mensagem de erro.
5. Problemas de registro com o CUCM: O arquivo de configurao que o telefone puxa do TFTP
contm o IP do servidor CUCM que o telefone deveria se registrar. Verifique esse item em Settings >
Device Configuration > Unified CM Configuration, lembrando que podem existir at trs IPs
configurados, o principal, um backup e um servidor tercirio.
Se estiver ok verifique se o servio Cisco CallManager est rodando no servidor listado, alm disso,
se voc utilizar o autoregistration verifique se ele est corretamente configurado. Veja na figura
abaixo um exemplo do menu Device Configuration.
Se todas as alternativas acima foram verificadas e ainda assim o telefone continua com problema,
provavelmente voc tem um problema mais complexo ou com o prprio telefone IP, o que est alm
dos tipos de troubleshooting que fazem parte do escopo do CCNA Voice.
A partir desse passo voc ter que acionar um suporte mais especializado ou at o prprio Technical
Assistance Center (TAC) da Cisco, porm isso precisa de um contrato de servio que d acesso
abertura de chamados diretamente na Cisco ou atravs de um parceiro habilitado.
Na prtica, sempre que voc tiver um telefone reserva(spare) faa a troca pelo que est
apresentando defeito e veja se ele se registra, pois isso pode indicar um problema de hardware e uma
troca a nica alternativa. Antes de voc fazer esse teste tente resetar o telefone para os padres de
fbrica para verificar se no existe algum parmetro travado na configurao antiga do telefone que
o impede de subir (funcionar corretamente).
Outra dica prtica, a qual foi at comentada no captulo anterior quando voc tem a mensagem de
registro rejeitado (conforme figura abaixo), isso normalmente um problema de configurao
relacionado ao endereo MAC utilizado na criao do telefone no CME ou CUCM.
Essa configurao no CUCM est na pgina de administrao, no menu Device > Phone.
Lembre que o nome dos telefones formado pelo SEP mais o MAC do telefone ou da placa de rede de
um computador quando utilizamos um softphone como o CIPC. Veja afigura abaixo com um exemplo
da tela de configurao dos telefones. Nesse caso verifique o MAC correto do telefone e ajuste a
configurao no CUCM.
Clean Up do Banco de Dados Utilizando o Route Plan Report

Agora vamos estudar como apagar Directory Numbersno utilizados com a ferramenta chamada
Route Plan Report.
Quando estamos utilizando o Autoregistration um problema muito comum que ocorre durante o
processo de registro a mensagem Error DB Config (ou similar) quando o telefone tem problemas
para finalizar o processo. Esse problema tem origem no esgotamento da faixa (range) de Directory
Numbers (DNs) alocados para o Autoregistration, ou seja, o Autoregistration est funcionando mas
no tem mais DNs para alocar para os telefones IP.
Porque esse problema ocorre? Por dois motivos, ou voc dimensionou mal a quantidade de DNs para
o autoregistration ou os DNs alocados que j foram migrados para o DN final do usurio ficaram
presos. Na prtica normalmente utilizamos o autoregistration temporariamente no TAPS e depois o
ramal trocado para o nmero real que ser utilizado em produo, porm uma situao anmala
ocorre com esse processo, porque ao invs de liberar um DN recm-utilizado, o autoregistration
marca esse DN como Unassigned e deixa ele inutilizvel em uma espcie de limbo no banco de
dados.
Esses DNs que esto no limbo no ficam visveis e voc ter que procurar por eles no banco de
dados do CUCM, portanto esse no um problema to trivial e simples de resolver. Para resolver o
problema voc pode adicionar mais DNs ao range do Autoregistration ou utilizar os seguintes passos
abaixo para liberar os DNs presos:
1. Entre na pgina de administrao do CUCM e v at Call Routing > Route Plan Report.
2. Configure o filtro para Unassigned DNs e clique em Find (veja a tela da figura ao lado).
3. Apague todos os ramais que estejam como Unassigned selecionando os checkboxes dos DNs
e clicando no boto Delete Selected.
Agora os DNs esto novamente liberados para o range do Autoregistration para alocao dos
telefones. Estes passos so utilizados para fazer o clean up (limpeza) do banco de dados depois de
modificar o design das Partitions.
Informao extra:
Outro comportamento interessante da base de dados do CUCM (nas verses mais antigas do 8.x)
que quando um DN associado a uma Partition diferente, o DN ainda fica na anterior marcado como
unassigned. Esses DNs marcados como unassigned podem gerar muita confuso porque eles
aparecem na lista como selecionvel quando, por exemplo, estamos criando um Line Group, porm
eles no funcionam por no estarem associados a nenhum dispositivo, por isso utilizar o Route Plan
Report para apagar os unassigned DNs deve ser uma rotina de manuteno a ser realizada de
tempos em tempos.
Uma outra dica prtica quando deletamos o telefone (device) sem deletar o DN, esse DN que estava
vinculado ao telefone apagado fica tambm no limbo como unassigned e normalmente precisamos
seguir os passos dessa sesso para fazer o clean-up desses DNs, caso eles no sejam reutilizados em
outros dispositivos.
Outra maneira de apagar os DNs e fazer o clean-up da base de dados indo em Bulk Administratio >
Phones > Delete Phones > Delete unassigned DN. Dando um find ele vai achar todos os unassigned
DNs, porm voc pode utilizar os filtros para encontrar uma faixa especfica de DNs.
Relatrios no CUCM
O CUCM possui vrias ferramentas para gerao de relatrios chamadas reporting tools. O uso
desses relatrios para fazer o troubleshooting pode ajudar muito na resoluo de problemas, alm
disso, os relatrios ou reports podem ser utilizados para manuteno e anlise do sistema. Portanto,
nessa sesso vamos estudar como gerar e analisar alguns dos mais importantes relatrios do CUCM.
As ferramentas de relatrio (reporting tool) do CUCM coleta informaes de diferentes origens e
formata os dados em um formato simples e nico. O report tool alerta ao usurio se quando ele for
gerar um determinado relatrio (report job) poder causar problemas de performance do servidor ou
levar muito tempo para ser finalizado.
Os reports pegam dados do Publisher e subscribers das origens mostradas abaixo:
Contadores do Real-Time Monitoring Tool (RTMT)

Call Detail Records (CDR) e do CDR Administration and Reporting database
Banco de dados do CUCM
Arquivos disponveis no disco rgido (traces e logs)
Prefs settings
CLI
Real-Time Information Server (RIS)
O sistema de relatrios utiliza o servio do Cisco Tomcat e Remote Procedure Calls (RPC) para acessar
outros servidores via HTTPS, por isso certifique-se que o servio do Tomcat est ativo e o trfego
HTTPS pode fluir entre os servidores (em ambos sentidos inbound e outbound).
Gerando Relatrios
Para acessar o Cisco Unified Reporting Tool (ferramentas de relatrio do CUCM) voc pode utilizar
o menu drop-down na parte superior direita da interface de administrao do CUCM ou diretamente
via atravs da URLhttps://ip_address/cucreports.
Por padro somente os usurios membros do CCM Super Users Group podem gerar e ver os
relatrios, sendo que o nico membro que por padro faz parte do grupo de administrao do CUCM
a conta de administrao da aplicao definida na instalao do sistema (application administration
account).
Entre com o usurio e a senha da conta criada na instalao do sistema para administrao ou uma
outra que foi criada posteriormente e que possua os privilgios devidos para acessar os relatrios.
Ao se logar na interface de Report Tools chamada de Cisco Unified Reporting e clicar em System
Reports voc ir visualizar a pgina que est na tela da figura abaixo:
Agora basta voc selecionar o relatrio da lista mostrada no menu do lado esquerdo.
O sistema armazena um relatrio de cada que j foi gerado, para que possa ser consultado
posteriormente. Se o relatrio nunca foi gerado anteriormente o sistema avisa com uma mensagem
inidicando que no existe tal relatrio e um novo deve ser gerado, alm disso, na mensagem j vem o
link de Generate a New Report para gerar um novo relatrio.
Veja uma tela de exemplo que foi gerada ao clicar no primeiro relatrio do menu na figura abaixo que
est sendo gerado pela primeira vez.
Na tela da figura abaixo temos um exemplo do relatrio Device Counts Summary.
Note que a marca em verde (checkmark) com um OK ao lado indica que o report foi gerado com
sucesso. Os outros trs botes ao lado direito da pgina permitem que voc faa um upload de um
relatrio em XML que est armazenado em seu computador para guardar no servidor CUCM, fazer o
download do relatrio para seu computador ou gerar um novo relatrio, descritos aqui conforme
sequncia da esquerda para direita.
Analisando os Relatrios
Os relatrios gerados podem ser utilizados para que voc possa fazer as seguintes tarefas:
Troubleshooting: Para coletar informaes, considerar possibilidades e observar os resultados

(gathering facts > considering possibilities > observing resuls).
Manuteno (Maintenance): Para procurar problemas de configurao, utilizao dos recursos
ou sumarizar informaes do sistema.
Anlise do Sistema (System Analysis): Listar os telefones por tipo, recursos habilitados ou
outros filtros necessrios para encontrar o que voc procura.
Por exemplo, na figura abaixo temos a tela do relatrio de contagem de usurios Unified CM User
Device Count.
Se voc planejou seu projeto para cada telefone ter seu usurio fixo, com esse relatrio voc poderia
ver que tem 4 telefones sem usurio, 4 usurios sem nenhum telefone e mais um usurio com mais
de um telefone, portanto seu planejamento no foi seguido no momento da implantao.
Veja que existem muitos outros relatrios que podem ser utilizados para tirar muitas outras
informaes importantes.
Entendendo e Configurando o Call Detail Record Analysis and Reporting - CAR
Agora vamos estudar o Call Detail Record Analysis and Reporting (CAR) Tool, assim como os
parmetros gerais e do sistema, opes de agendamento e banco de dados. Vamos tambm estudar
como gerar relatrios sobre usurios, sistema e dispositivos.
O CAR no um servio padro do CUCM, por isso voc precisar ativ-lo indo na pgina de Unified
Serviceability, em Tools > Service Activation, selecionando a opo Cisco CAR Web Service e
clicando em Save. Alm disso, se um servidor externo de bilhetagem (billing server) est sendo
utilizado voc precisa tambm ativar o servio Cisco SOAP-CDRonDemand Service. SOAP o
acrnimo para Simple Object Access Protocol, para maiores informaes clique no link ao lado para a
Wikipedia (http://pt.wikipedia.org/wiki/SOAP).
Com o servio CAR ativado todo processo do CUCM pode ser registrado. Esses logs so chamados
Call Detail Records (CDR) e Call Management Records (CMR) e contm informaes sobre as
chamadas e mtricas relativas qualidade da voz para as chamadas.
Os CDRs so armazenados em arquivos (flat files) nos subscribers e depois o publisher puxa esses
arquivos (faz um upload) para o banco de dados de CDR/CAR em um determinado intervalo de tempo,
o qual pode ser configurado pelo administrador. Alm de fornecer informaes internas com
propsitos administrativos, o banco de dados de CDR pode ser acessado por uma aplicao de
terceiros (third-party billing applications), as quais podem forcener relatrios sobre ligaes internas
ou externas para gerar informaes de bilhetagem (uso dos recursos de telefonia, podendo ser
utilizado para propsitos financeiros, como por exemplo, saber quanto um determinado ramal gastou
no ms, seja em minutos ou em valores financeiros).
Voc ainda pode puxar os relatrios manualmente utilizando a interface web atravs da URL
https://<ip_do_CUCM>/car ou programar relatrios (reporting jobs) automticos. A opo de
carregar CMRs em conjunto com CDRs configurada pelo administrador, pois os CMRs no so
carregados por default. Veja na figura abaixo a tela do CAR Reports tool.
Configurando o Servio de CDR

Na interface de administrao do CUCM v at System > Service Parameters, em seguida selecione
o servidor no primeiro menu drop-down e depois selecione o servio Cisco CallManager. Clique no
boto Advanced na parte superior da pgina para mostrar todos os parmetros disponveis e ajuste os
seguintes itens conforme necessidade:
1. CDR Enabled Flag: Este campo determina se os CDRs sero gerados ou no, eles devem estar
configurados em todos os servidores e por padro no vem habilitado (False - os CDRs no so
coletados). Se voc no setar essa opo para true os CDRs no sero coletados e quando voc tentar
gerar um relatrio receber uma mensagem de erro dizendo que no h dados disponveis no banco
de dados (30061 "Data not available in Database").
2. CDR Log Calls with Zero Duration Flag: Configurando essa opo para True o CUCM gera CDRs para
chamadas que no foram completadas ou duraram menos de 1 segundo. Chamadas sem sucesso,
inclusive as que resultaram em um tom de reordenao ou devido a um troco de sada ocupado, so
sempre registradas independente dessa opo. O padro dessa opo False, ou seja, desabilitado.
3. Call Diagnostics Enabled: Este parmetro habilita o registro dos CMRs e por padro vem
desabilitado (Disabled). Voc pode escolher para no gerar CMRs, gerar somente quando os CDRs
esto habilitados ou gerar os CMRs independente dos CDRs estarem ou no sendo gerados.
4. Display FAC in CDR: Esta opo controla se um Forced Authorization Code utilizado para fazer
uma chamada deve ser includo no CDR. O valor padro False (desabilitado).
5. Show Line Group Member DN in finalCalledPartyNumber CDR Field: Esta opo define se
chamadas para Call Hunting systems deve utilizar o Hunt Pilot number (ramal do piloto) ou o DN
que atendeu a chamada deve ser gravado no CDR. O padro nesse caso False, fazendo com que o
Hunt Pilot number seja gravado no CDR ao invs do DN.
6. Add Incoming Number Prefix to CDR: O padro para essa opo False. Esse parmetro determina
se o prefixo de entrada (incoming prefix - muitos deles definidos nos parmetros de servio) deve ser
adicionado ao nmero que est chamando (calling party number) nos CDRs. Os prefixos adicionados a
chamadas de entrada so sempre gravados nos CDRs. Esta configurao controla se os prefixos so
adicionados aos CDRs se eles so colocados em chamadas de sada (outbound calls).
Veja um exemplo da tela de configurao na figura abaixo. Os parmetros esto espalhados pelas
sesses System, Clusterwide Parameters (Device - General) e Clusterwide Parameters (Device Phone).
Tipos de Usurios do CAR e Arquitetura do CDR e CMR

A ferramenta CAR permite que trs tipos de usuriosdiferentes tenham acesso aos relatrios. Veja
no quadro ao lado.
Os CDRs so gerados pelos servidores CUCM que esto fazendo o processamento das chamadas, ou
seja, aqueles que esto rodando o servio CallManager.
Os CDRs contm informaes sobre o nmero que fez a chamada, o nmero chamado, data e hora da
chamada, tanto na conexo como para desconexo, e porque a chamada foi desconectada. J os
CMRs mostram informaes sobre latncia, jitter, perda de pacotes e a quantidade de dados enviados
durante a chamada.
Cada chamada pode gerar diversos CDRs e CMRs, sendo que o processador de chamadas (call
processing nodes - CUCM) coletam os dados do CAR, o qual um termo que representa ambos CDRs
e CMRs, em um registro (log) local e periodicamente faz o upload deles para um dispositivo de
armazenamento (CDR repository node) utilizando o protocolo SFTP (Secure FTP - utiliza SSH para
transferir os arquivos).
O n de armazenamento (repository node) roda o servio CDR Repository Manager Service, o qual
responsvel por manter os arquivos de CDR e CMR, pelo gerenciamento do espao em disco
utilizado pelos dados do CDR e pelo envio dos arquivos para at trs localidades diferentes prconfiguradas, as quais normalmente so servidores de bilhetagem de outros fabricantes (third-party
billing servers).
Tipos de usurios com acesso ao CAR:
Administradores do sistema (Administrators): Os administradores podem utilizar a ferramenta para
ter acesso a todos os recursos para gerar relatrios de anlise de performance do sistema, verificao
de balanceamento de carga (load balancing) e realizar troubleshooting. Quaisquer usurios (end user
ou application user) podem receber acesso administrativo ao CAR, basta coloc-los como membros do
grupo Standard CAR Admin Users Group.
Gerentes (Managers): Os gerentes podem gerar ralatrios por usurio, departamento e Quality of
Service (QoS). Os Managers (gerentes) so definidos pelo campo Manager User ID na interface de
administrao do CUCM. Esse recurso funciona da seguinte maneira, se um usurio com ID A
selecionado com o campo Manager User ID na pgina de configurao de um usurio B, esse
usurio A pode gerenciar os relatrios do usurio B. Os gerentes podem gerar relatrios automticos
que sero enviados para seu mail ID configurado em sua pgina de usurio.
Usurios (Users): Os usurios podem gerar relatrios sobre a bilhetagem (billing report) de suas
prprias chamadas. Os relatrios podem ser gerados para uma faixa especfica de datas e os usurios
podem receb-los atravs de seu e-mail, o qual ser enviado diretamente pelo sistema. Os usurios
devem ser colocados como membros do grupo standard CCM End Users Group para acessar os
relatrios, alm disso os dispositivos que eles querem gerar os relatrios devem estar associados
sua conta.
Parmetros do Sistema do CAR
O sistema do CAR necessita algumas configuraes para que ele funcione mais efetivamente, sendo
necessrio fazer as customizaes mostradas abaixo:
Customizaes do CAR:
1. Configurar os parmetros relativos ao e-mail para envio dos relatrios.
2. Configurar o dial-plan conforme o padro de discagem local, assim os CDRs podero ser
interpretados corretamente, por exemplo, chamadas de 4 dgitos sero classificadas como chamadas
On-Net e chamadas com 8 dgitos como chamadas locais no Brasil (10 dgitos nos EUA). As
configuraes padro so baseadas no NANP (North American Numbering Plan ou plano de discagem
Norte Americano).
3. Configurar os gateways na ferramenta de CAR. Os gateways configurados no CUCM so
automaticamente adicionados ou deletados no sistema, porm os cdigos de rea locais dos gateway
devem ser definidos para que os relatrios possam identificar as chamadas de longa distncia.
4. Configurar o COMPANY_NAME (mximo de 64 caracteres). Esse nome vai aparecer no cabealho

(header) do relatrio de CAR.
5. Configurar o agendador (CAR Scheduler) para configurar os tipos de relatrios que sero
carregados, em que intervalos e por quanto tempo. O objetivo dessa configurao permitir que
sejam carregados relatrios por um tempo suficiente sem impactar a performance do servidor. No
confunda a carga de arquivos (Loading files) de CDR e CMR com a gerao desses arquivos, pois a
carga ou loading se refere ao Repository node (ns de armazenamento) puxando os dados de
CDR/CMR dos call processing nodes (ns de processamento de chamada, que em nosso caso so
servidores CUCM) para dentro do banco de dados de CDR/CAR.
6. Configurar a limpeza do banco de dados do CAR (CDR/CAR database purging). Isso pode ser feito de
maneira automtica (que o default do sistema) ou manual. Voc pode ajustar os valores mximos e
mnimos (High and Low Water Mark) para controlar quando a limpeza automtica deve iniciar e parar,
tudo isso com base no percentual de utilizao do espao disponvel em disco. Qual relatrio gravado
deve ser apagado definido pela idade da entrada, os mais antigos so apagados primeiro.
7. Configurar a gerao automtica de relatrios, escolhendo que relatrios devem ser gerados e se
devem ser enviados por e-mail ou no. O intervalo de gerao de relatrios fixo e pode ser dirio,
semanal ou mensal, porm a hora de incio pode ser customizada utilizando a interface de
agendamento (Scheduler interface).
Essas configuraes so realizadas na pgina do CAR em System, conforme figura abaixo, onde temos
a tela de configurao dos parmetros de e-mail. Abaixo do menu System voc tem uma viso dos
principais menus de configurao do sistema.
Exportando Relatrios de CDR e CMR

Os arquivos de CDR e CMR podem ser puxados via download do servidor como em um formato CSV.
Esse arquivo normalmente importado para uma aplicao de bilhetagem (billing application). Para
configurar aexportao dos arquivos siga os passos abaixo:
1. A partir da interface do CAR v at CDR > Export CDR/CMR.

2. Selecione o intervalo de datas (os valores From Date e To Date).
3. Na opo Select Records selecione CDR Records, CMR Records ou as duas opes ao
mesmo tempo e clique em Export File (veja a tala na figura abaixo).
4. Na nova janela que se abrir escolha entre as opes CDR Dump ou CMR Dump e clique em
Save As para selecionar uma pasta de destino no computador.
5. Selecionando o checkbox Delete File voc far com que o arquivo baixado seja apagado do
banco de dados do CAR, o que recomendado para evitar com que o tamanho do banco de
dados fique excessivamente grande (veja a tela na figura abaixo)
Gerando CDRs User Reports

Agora vamos ver como os usurios (users), gerentes (managers) e administradores (administrators)
podem utilizar o CAR report tool para gerar relatrios. Vamos analisar os relatrios (reports) em
mais detalhes, os quais podem ser do tipo Bills, Top N ou Cisco Unified Communications Manager
Assistant.
Bills:
Individual: Disponvel para usurios, gerentes e administradores. Tem a finalidade de fornecer
informaes de chamadas para um perodo especificado de tempo, podendo ser em formato
resumido (summary) ou detalhado (detail). Alm disso, pode ser visualizado ou enviado por e-mail.
Department: Disponvel apenas para gerentes e administradores. Ele fornece informaes detalhadas
ou resumidas sobre chamadas e QoS. Para o gerente esse relatrio pode ser gerado para todos os
usurios que se reportam a ele ou para usurios selecionados da lista.
Top N:
By Charge: Disponvel apenas para gerentes e administradores. Este relatrio mosta os nmeros de
usurios (DNs) em ordem de chamadas com maior custo (call charges) para um perodo especificado
de tempo (o N o nmero de usurios que iro aparecer na listagem). Alm disso, voc pode gerar
relatrios por cobrana para o destino das chamadas ou para todas as chamadas, listando as top N
calls que geraram mais cobrana (as chamadas mais caras).
By Duration: Disponvel apenas para gerentes e administradores. Esse relatrio lista os usurios que
realizaram chamadas com uma determinada durao de tempo. Os relatrios podem tambm listar as
chamadas que duraram mais (top calls) ordenadas pelo destino ou todas as chamadas por durao.
By Number of Calls: Disponvel apenas para gerentes e administradores. Esse relatrio permite listar
o nmero de chamadas por usurio ou por ramal.
Cisco Unified Communications Manager Assistant:
Manager Call Usage: Disponvel apenas para administradores. Este relatrio pode listar
resumidamente (summary) ou com detalhes (detail) informaes das chamadas completadas pelos
gerentes (Managers) utilizando o Cisco Unified Communications Manager Assistant. Esta listagem
pode ter as chamadas feitas pelo prprio gerente, pelas que as assistentes fizeram para o gerente ou
para ambos os tipos de chamadas.
Assistant Call Usage: Disponvel apenas para administradores. Nesse relatrio podemos ver as
chamadas feitas pelas assistentes ou as que elas realizaram para o gerente, outra opo listar os
dois tipos de chamada.
Cisco IP Phone Services: Disponvel apenas para administradores. Este tipo de relatrio mostra
servios disponveis para os telefones IP que voc pode escolher, o nmero de usurios que esto
inscritos nesses servios e o percentual de utilizao de cada um deles.
Informao extra:
O Cisco Unified Communications Manager Assistant um recurso que otimiza o desempenho do
sistema telefnico para permitir que gerentes e seus assistentes trabalhem em conjunto de modo
mais eficaz. Os usurios incluem gerentes e assistentes.
Gerentes: Um gerente do Cisco Unified Communications Manager Assistant um usurio cujas

chamadas recebidas so interceptadas e redirecionadas para um assistente. O gerente auxiliado
por, pelo menos, um assistente. Os gerentes podem utilizar o Cisco Unified Communications Manager
Assistant diretamente nos telefones IP Cisco Unified. No entanto, os gerentes podero configurar seus
recursos na janela de configurao do gerente ou podero solicitar aos assistentes que configurem
essas preferncias em seu nome.
Assistentes: Um assistente do Cisco Unified Communications Manager Assistant um usurio que
processa chamadas em nome de um gerente. Os assistentes podem acessar a maioria dos recursos do
Cisco Unified Communications Manager Assistant em seus computadores, usando um aplicativo
chamado console Assistant. Os assistentes podem gerenciar diversos gerentes, o limite depende da
verso do CUCM.
Exemplo de Gerao de Relatrio
Agora vamos mostrar um exemplo de como gerar um relatrio utilizando o CAR tool. Nesse
exemplo vamos listar os usurios que mais fizeram chamadas:
1. Abra a interface do CAR Reports tool digitando em seu browser https://ip_do_CUCM/car e se
logue com um usurio e senha que tenha direitos administrativos para gerar os relatrios. Veja figura
abaixo onde o IP do CUCM o 192.168.1.201.
2. Aps o login selecione User Reports > Top N > By Number of Calls, conforme mostrado
na figura abaixo.
3. Na tela da figura abaixo temos a definio dos parmetros do relatrio, tais como tipos de
chamadas (call types), tipos de usurios (user types) e perodo de datas (date range).
4. Clique em View Report para ter o relatrio em PDF (conforme selecionado, poderia ser tambm
em CSV), coforme tela da figura abaixo:
Uma dica prtica que a faixa de datas em From Date/To Date somente estar disponvel para um
range aps a data que voc iniciou a coleta dos CDRs e o sistema avisa com uma mensagem do tipo:
30024 : Data is available only from Apr 2, 2012. Do you want to generate the report?, veja que
nesse exemplo o sistema fala que os relatrios podem ser gerados a partir da data de 2/4/12,
provavelmente antes disso a coleta de CDRs no estava habilitada.
Lembre-se que para ativar a coleta dos CDRs e CMRs voc deve habilitar os servios Cisco CAR Web
Service e Cisco SOAP-CDRonDemand Service e configurar os Service Parameters conforme a
sesso 5.1, principalmente os itens 1 (para CDR) e 3 (para CMR).
Relatrios do Sistema System Reports
Alm dos relatrios de usurios que vimos na sesso anterior (User Reports) a ferramenta de CAR
pode gerar diversos relatrios do sistema (system reports). Temos os seguintes tipos de relatrios de
sistema disponveis:
QoS Qualidade de Servio
Detail: Disponvel para administradores. Forcene estatsticas detalhadas sobre QoS das ligaes
que foram tratadas pelo CUCM durante um perodo especificado de tempo. recomendado
para ter uma idia geral da qualidade da voz do sistema (system-wide voice-quality
monitoring).
Summary: Disponvel para gerentes e administradores. Fornece informaes resumidas em um
grfico no formato pie-chart (tambm conhecido como grfico de pizza) mostrando o QoS
para chamadas por classificao e perodo determinado, inclui uma tabela sumarizada com as
chamadas por nvel de QoS.
By Gateway: Disponvel para gerentes e administradores. Esse relatrio lista o percentual de

chamadas por gateways conforme critrios de QoS definidos previamente. O report pode ser
gerado por hora, diariamente ou semanalmente (hourly/ daily/weekly).
By Call Type: Disponvel para administradores. Lista a porcentagem de chamadas selecionadas
por tipo e que atingiram os determinados critrios de QoS que podem ser escolhidos. O report
pode ser gerado por hora, diariamente ou semanalmente (hourly/ daily/weekly).
Traffic - Trfego
Summary: Disponvel para administradores. Mostra o volume de chamadas por tipo e

categorias de QoS para um perodo de tempo, podendo mostrar o nmero de chamadas
realizadas por hora, dia ou semana (hourly/daily/weekly).
Summary by Extension: Disponvel para administradores. Mostra o volume de chamadas por
ramal especificado e por tipo para um determinado perodo de tempo.
Forced Authorization Code/Client Matter Code (FAC/CMC)
Client Matter Code: Disponvel para administradores. Lista os nmeros de quem discou e o
ramal chamado (called e calling numbers), durao da chamada e a classificao da chamada
em um perodo definido de tempo.
Authorization Code Name: Disponvel para administradores. Esse relatrio traz tambm quem
discou e o nmero chamado, quando ocorreu a ligao (time stamps), durao e a classificao
das chamadas em um perodo especificado de tempo, porm separado por nome de FAC e
incluindo o nvel de autorizao (authorization level).
Authorization Level: Disponvel para administradores. Traz a lista das ligaes com os nmeros
de quem discou e discado, data e hora da ligao, durao e classificao das chamadas por
nvel de autorizao (FAC authorization level - inclui o nome do FAC).
Malicious Call Details: Disponvel para administradores. Mostra as chamadas que foram marcadas
pelo servio Malicious Caller Identification (MCID) em um perodo especificado de tempo.
Precedence Call Summary: Disponvel para administradores. Esse relatrio mostra de forma
sumarizada informaes sobre as chamadas que foram priorizadas pelo seu nvel configurado no
MLPP (Multilevel Precedence and Preemption) em um perodo especificado de tempo. As
informaes so mostradas em um grfico de barras.
System Overview: Disponvel para administradores. Fornece informaes de alto nvel sobre a rede
do CUCM.
CDR Error: Disponvel para administradores. Fornece um relatrio com estatsticas de erros que
ocorrem durante a transferncia de dados do CDR.
Veja a tela das opes macro do menu System Reports nafigura 1 ao lado. Na tela da figura 2 temos
um exemplo do relatrio System Reports > QoS > Detail, mostrando as informaes detalhadas
sobre o QoS das ligaes realizadas utilizando o CUCM.
Figura 1
Figura 2
Relatrio de Dispositivos - Device Reports

Os relatrios fornecidos pelo CAR tambm fornecem informaes relacionadas a performance e
monitoraode carga sobre diversos dispositivos do CUCM, tais como gateways e conference bridges
(bridges de conferncia). Veja abaixo os tipos de relatrios que podemos gerar no Device Reports:
Gateway: Nessa opo podemos gerar relatrios detalhados, sumarizados e de utilizao (Detail /
Summary / Utilization) de acordo com as chamadas e diversos critrios que podemos selecionar sobre
o gateway.
Route Patterns and Hunt Groups: Os relatrios podem ser gerados conforme tipos abaixo.
Route/Line Group Utilization

Route Pattern/Hunt Pilot Utilization
Hunt Pilot Summary
Hunt Pilot Detail
Conference Bridge: As opes Call Detail e Utilization trazem relatrios sobre a monitorao
dos recursos de conferncia.
Voice Messaging: O menu Voice Messaging > Utilization reporta o percentual estimado da
utilizao dos recursos de dispositivos de voice-messaging (mensagem de voz).
Trunk: A opo Utilization no menu Trunk traz um relatrio sobre a utilizao dos trunks
configurados no CUCM em um determinado perodo de tempo.
Veja a tela com o menu geral do Device Reports nafigura abaixo:
Unified RTMT (Real-Time Monitoring Tool)

O Cisco Unified Real-Time Monitoring Tool (RTMT) permite que os administradores coletem,
visualizem interpretem e monitorem diversos contadores, arquivos de trace e logs gerados pelo
CUCM, Cisco Unity Connection (CUC) e Cisco Unified Presence (CUP).
Veja tela de abertura do RTMT na figura abaixo:
O RTMT uma aplicao cliente que pode ser instalada em um micro de administrao ou servidor de
administrao, a qual pode ser baixada a partir dos sevidores do CUCM, CUC, CUP e Cisco Unified
Contact Center Express (CUCCX). importante lembrar que existem uma verso de RTMT especfica
para cada produto, com excesso do CUCM e CUC que podem utilizar a mesma verso de software.
Outro detalhe que apenas uma instncia de RTMT pode ser instalada em uma mesma mquina.
Para baixar o RTMT no CUCM v at o menu Applications > Plugins na interface de gerenciamento
do CUCM e clique em Find, depois basta fazer o download do RTMT para Windows ou Linux,
dependendo do sistema operacional que est rodando em sua workstation, conforme tela
da figura abaixo:
O RTMT utiliza HTTPS para se conectar aos servidores da famlia de Unified Communications da Cisco
e poder monitorar a performance do sistema, estado dos dispositivos (device status), descoberta de
dispositivos (device discovery), aplicaes CTI e portas de voice-messaging.
Os end users ou application users (usurios normais ou de aplicao) precisam ser adicionados no
grupo standard CCM Admin Users and Standard RealtimeAndTraceCollection para utilizar o RTMT,
assim eles podero utilizar seu User ID e senha para acessar o RTMT e monitorar o sistema.
Abaixo segue a lista resumida do que o RTMT oferece de capacidade administrativa:
Monitorar objetos pr-definidos da sade do sistema (system health objects)

Gerar alertas por e-mail para objetos que ultrapassem para baixo ou para cima os limiares
(thresholds) configurados
Coletar e visualizar arquivos de trace para diferentes servios
Visualizar mensagens de syslog
Configurar e monitorar contadores de performance
Interface do RTMT
A interface grfica do RTMT (GUI) tem os seguintes menus e opes (veja a tela
da figura abaixo como referncia):
File: Esse menu tem as opes de save, restore e delete profiles do RTMT, monitorao das
informaes do Java Virtual Machine ( JVM), acesso aos relatrios arquivados (report archive), acesso
ao Unified Reporting Tool (Cisco Unified Reporting), log off ou exit para sair do programa.
System: Permite a monitorao de parmetros relativos sade do sistema, tais como utilizao
da CPU, memria e disco. possvel que o administrador configure e monitore diversos tipos de
contadores de performance, alertas e traces, alm disso, possvel por aqui acessar as ferramentas
Trace & Log Central e um syslog viewer.
As trs opes a seguir dependem da plataforma que o RTMT est monitorando, no caso da tela
da figura mostrada estamos mostrando o RTMT monitorando um CUCM, porm o menu
CallManager pode variar conforme a plataforma para uma das opes abaixo:
CallManager: Esse menu est disponvel quando o RTMT est conectado a um CUCM, permite
que os administradores visualizem informaes resumidas sobre o servidor, faam buscas por
dispositivos e monitorem servios.
Unity Connection: Esse menu est disponvel quando o RTMT est conectado a um CUC,
permite utilizar o Port Monitor Tool e verificar estatsticas e informaes sumarizadas
pertinentes ao CUC.
CUP: Esse menu est disponvel quando o RTMT est conectado a um CUPS, permite verificar
informaes pertinentes ao servidor CUP e suas aplicaes.
As demais opes do menu so:

Analysis Manager: Quando o RTMT est conectado ao CUCM ele permite ao administrador verificar
configuraes e informaes sobre licenas, alm disso permite utilizar o Call Path Analysis Tool.
Edit: Permite configurar categorias para diferentes formatos de tabela de visualizao, configurar o
intervalo de varredura (polling rates) para os contadores de performance e dispositivos, permite
mostrar ou esconder o Quick Launch Channel e editar parmetros do trace para o RTMT.
Window: Utilizado para fechar a janela atual (Close current) ou todas as janelas (all windows)
abertas do RTMT.
Application: Fornece links rpidos para as interfaces de administrao, serviceability, e algumas
outras interfaces para aplicaes especficas, dependendo do RTMT que est e uso (CUCM, CUC ou
CUPS).
Help: Fornece acesso a menus de ajuda e informaes sobre o RTMT que voc instalou (about).
Note que os menus File, Edit, Window, Application e Help so mais referentes ao prprio aplicativo do
RTMT, enquanto os menus System, Callmanager/Unity Connection/CUP e Analysis Manager so os
que vamos utilizar para realmente monitorar a plataforma de comunicaes unificadas e seus
servidores.
Note tambm na tela da figura abaixo que existe um menu de acesso rpido com cones para as
opes mais utilizadas no RTMT (System, CallManager e AnalysisManager).
Basta clicar no cone para visualizar as informaes. Note que para o menu CallManager exitem
grupos de cones sobre o status do sistema, chamadas, dispositivos e assim por diante, se voc clicar
no cone abaixo do CallProcess chamado Call Activity (um telefone azul), por exemplo, sero
mostradas as chamadas ativas, conforme est mostrado na figura. O RTMT mostra as informaes de
maneira grfica e com uma tabela de resumo logo abaixo para maioria das opes, porm para
algumas sero mostrados apenas grficos ou apenas tabelas.
Monitorando o CUCM com o RTMT Menu CallManager
Para monitorar um servidor CUCM via RTMT existem vrias maneiras e opes, porm vamos limitar
o escopo nessa sesso e analisar as seguintes telas.
CallManager Summary
A visualizao da opo CallManager Summary mostra trs grficos, um para os telefones registrados
(registered phones), o segundo para as chamadas que esto ativas (calls in progress) e o ltimo para
portas ou canais de gateways ativos (active MGCP gateway ports and channels). Essa opo pode ser
acessada pelo menu CallManager ou pelo primeiro cone do acesso rpido, conforme figura abaixo.
Gateway Activity
A opo Gateway Activity mostra um resumo das chamadas em um determinado tipo de gateway
(MGCP FXS/FXO/T1/PRI ou H.323) de maneira sumarizada em grficos. Voc tambm pode ver a
informao do nmero de chamadas completadas por tipo de gateway (por servidor ou por cluster)
na tabela do final da pgina. Note que a informao por tipo de gateway e no por gateway.
Voc pode acessar a informao pelo menu de acesso rpido, conforme mostrado na figura abaixo ou
ento pela barra de menus indo em CallManager > Call Process > Gateway Activity.
Device Search
Nessa opo os administradores podem fazer buscas (search) por telefone (phones), gateway devices,
H.323 devices, CTI devices, voice- messaging devices, media resources, hunt lists e Session Initiation
Protocol (SIP) trunks (troncos SIP). Para cada tipo de busca por dispositivos possvel filtrar pelo
status (registered, unregistered, rejected, any status e dispositivos configurados apenas no banco de
dados devices that are only configured in the database). Veja figura abaixo.
possvel tambm limitar a busca por um modelo especfico de dispositivo ou protocolo para os
telefones. O resultado mostrado em uma tabela, onde o dispositivo est na linha e as colunas
trazem as caractersticas, conforme figura abaixo com um exemplo de busca por telefones.
Database Summary
O Database Summary mostra o estado da replicao da base de dados (replication status), o nmero
de replicaes criadas, o nmero de notificaes de requisies de alterao enfileiradas (queued) no
banco de dados e na memria e o total de conexes com clientes. Mostra tambm o estado da
replicao para cada servidor do cluster. As formas de chegar nessa tela esto mostradas na figura
abaixo:
Disaster Recovery System (DRS)

O Disaster Recovery System (DRS Sistema de Recuperao de Desastres) a interface onde voc
(como administrador) pode configurar um agendamento de backups ou realizar um backup manual do
banco de dados do CUCM e CDR/CAR. Alm disso, ele capaz de fazer o backup e restore da sua
prpria configurao, possibilitando que em um evento de restore o DRS no precise ser totalmente
reconfigurado novamente.
O DRS possui interface GUI e CLI (grfica e por linha de comando), uma agenda (backup scheduler),
armazenamento por fita ou storage (tape ou SFTP backup storage) e um sistema de arquitetura
distribuda para funes de backup e restore. Um detalhe importante que os backups devem ser
restaurados na mesma verso de aplicao, o que impossibilita o uso do DRS para mecanismos de
upgrade/downgrade de verso, porm pode ser utilizado para migrar de um servidor fsico para um
ambiente virtualizado (VMware server).
A arquitetura do DRS composta por um agente local (Local Agent) em cada servidor dentro do
cluster (com funo de realizar as operaes de backup e restore) e um agente mestre (Master Agent)
no servidor Publisher. O Master Agent tem as seguintes funes:
Armazenar as informaes sobre os componentes de registro de todo o sistema.

Manter o agendamento das tarefas de backup e enviar essas tarefas(tasks) aos Local Agents.
Armazenar os backups em um drive de fita localmente ou em um servidor SFTP remoto.
Prover a interface com o administrador via DRS web page.
Para acessar a interface do DRS via web voc deve utilizar a seguinte URL
https://<ip_do_CUCM>/drf ou atravs domenu drop-down que existe na parte superior direita da
tela da pgina de administrao do CUCM. Por default somente a conta de administrador do sistema
(Platform Administration account) tem acesso ao DRS, porm voc pode criar outras contas e dar
acesso ao DSR.
O DRS um recurso comum a todos os produtos de comunicao unificadas da Cisco baseados em
Linux, porm os componentes que so protegidos via backup dependem de cada aplicao especfica.
Veja na tabela abaixo as diferenas do backup feito pelo DSR para o CUCM, CUC e CUP.
Como Utilizar o DRS Criando um Backup Device

O uso da interface do DRS muito simples, pois ela permite que voc faa o backup manual ou
agendado e o restore.
O primeiro passo configurar um dispositivo de backup (Backup Device), isso deve ser realizado antes
de realizar o processo de backup. Siga os seguintes passos para criar o dispositivo de backup:
1. Na interface do DRS v at a opo Device > Backup Device e clique em Add New.
2. Configure um nome para o dispositivo.
3. Especifique se o dispositivo de backup ser uma fita local (local tape drive) ou um diretrio de
redeatravs de um servidor SFTP.
4. Selecione o drive da fita (tape drive device) ou o IP,SFTP root path e conta do SFTP onde o DRS
deve fazer o armazenamento remoto.
5. Clique em Save.
Voc pode criar at dez dispositivos de backup. Veja a tela da figura abaixo com a pgina de
configurao do dispositivo de backup.
Informao extra:
O servidor SFTP empresarial normalmente um produto pago, porm existe uma alternativa para
laboratrio que gratuita, o OpenSSH para Windows disponvel para baixar gratuitamente no
SourceForge (http://sshwindows.sourceforge.net/).
Criando uma Agenda de Backup - Scheduled Backup
Uma vez criado o backup device, o prximo passo agendar um backup seguindo os passos abaixo:
1. Ainda na interface do DRS v em Backup > Scheduler e clique em Add New.
2. Digite um nome para o agendamento (schedule).
3. Selecione o backup device criado no item 7.1 que o job deve utilizar.
4. Selecione o que deve ser realizado backup, lembrando que isso depende da aplicao, veja abaixo:
CUCM: CCM e CDR_CAR

CUC: CONNECTION_DATABASE, CONNECTION_GREETINGS_VOICE-NAMES,
CONNECTION_MESSAGES_UNITYMBXDB1 e CUC
CUP: CUPS e CUP
5. Configure o agendamento para o backup.
6. Habilite o job do agendamento.

Veja nas figuras 1 e 2 um exemplo da tela de configurao do agendamento do backup, sendo que a
figura 2 a continuao da tela.
Figura 1
Figura 2
Restaurando a Base de Dados - Restore

Em caso de problemas, onde haja a necessidade derecuperar o servio devido a um problema fsico
ou de software (uma base de dados corrompida, por exemplo) em um dos servidores voc dever
seguir o processo de restaurao dos dados, em ingls chamado de Restore, porm para que isso seja
possvel os backups devem ter sido realizados e armazenados com segurana, ou seja, devem estar
ntegros e disponveis.
Dependendo do nvel de comprometimento do servidor esse pode ser um processo muito complexo,
envolvendo a troca de um servidor, instalao do CUCM/CUC/CUP, instalao de patches ou upgrades
para a sim fazer a restaurao da base de dados, voltando o servio de telefonia. Para se ter uma
idia, a instalao de um CUCM pode levar at quatro horas, imagine isso em um momento de crise!!!
Uma opo que pode acelerar esse processo a instalao das aplicaes de comunicao unificadas
em um servidor virtualizado (VMWare), porm a arquitetura de instalao dos clusters e plataforma a
ser utilizada depende de cada projeto.
Veja abaixo o processo que descreve um restore bsico.
Processo de Restore:
1. Na interface do DRS v at a opo Restore > Restore Wizard.
2. Selecione o dispositivo que tem a guarda dos arquivos de backup que voc deseja utilizar no
restore.
3. Selecione o arquivo de backup correto da lista disponvel no dispositivo do passo anterior.
4. Selecione os recursos (features) a serem restaurados.
5. Se o restore vai ser feito a partir de um servidor SFTP selecione o File Integrity Check para
garantir que o arquivo restaurado no tenha seus dados corrompidos, porm essa cpia
atravs da rede pode causar lentido na rede e a verificao pode tambm aumentar o tempo
do processo de restore.
6. Selecione o servidor que deve ser restaurado. Se for o Publisher (first node) o DRS vai
automaticamente restaurar o banco de dados dos subscribers (subsequent nodes). Porm, em
ambos os casos (seja iniciando por um publisher ou subscriber) todos os dados existentes sero
sobrescritos pelo processo de restore.
7. Monitore o processo de restore e seu progresso atravs da opo Restore > Status.
Todos os alunos que iro atuar como administradores do sistema devem se familiarizar com o manual
chamado Disaster Recovery System Administration Guide para a verso de CUCM/CUC/CUP
instalado em seu ambiente (disponvel no site da Cisco), alm disso praticar o restore em laboratrio.
Essa prtica em laboratrio pode ter uma dupla funo, voc pode colocar em prtica seus
conhecimentos e tambm verificar se o backup realizado est ntegro e disponvel, pois esse um
grande problema do processo de backup/restore da maioria dos sistemas, no momento da
necessidade o backup pode estar corrompido ou ento no ter sido realizado!
Por isso, o backup/restore deve ter um processo bem estabelecido, com um acompanhamento
constante para evitar surpresas nos momentos de crise.
Gerando e Acessando Relatrios CUC Reports
O CUC possui duas interfaces mais relevantes para a gerao e visualizao de relatrios:
1. A primeira est na interface Cisco Unity Connection Serviceability no menu Tools >
Reports. Veja a tela na figura abaixo.
2. A segunda est em Cisco Unified Serviceability no menu Tools > Serviceability Reports
Archive. Veja a tela na figura abaixo.
A seguir vamos estudar as caractersticas e opes que cada uma dessas ferramentas nos oferece para
a tarefa de realizar um troubleshooting atravs de seus relatrios.
Cisco Unity Connection Serviceability: Reports
A aplicao de Serviceability do CUC tem 19 opes de relatrios que permitem ao administrador do
sistema monitorar e entender o estado e comportamento do CUC como um todo. Veja a tela do
Reports na figura abaixo:
Portanto, para acessar esses relatrios temos que abrir a interface CUC Serviceability e clicar na
opo em Tools > Reports. Uma vez na tela basta voc clicar no link do relatrio que voc deseja
tirar, conforme opes abaixo:
Phone Interface Failed Logon Report

Users Report
Message Traffic Report
Port Activity Report
Mailbox Store Report
Dial Plan Report

Dial Search Scope Report
User Phone Login and MWI Report
User Message Activity Report
Distribution Lists Report
User Lockout Report
Unused Voice Mail Accounts Report
Transfer Call Billing Report
Outcall Billing Report
Outcall Billing Summary Report
Call Handler Traffic Report
System Configuration Report
SpeechView Activity Report by User
SpeechView Acitivity Summary Report
Exemplo de Como Gerar um Relatrio a Partir do CUC Serviceability Reports

Vamos ver um exemplo de como gerar um relatrio clicando na opo Users Report. Ao clicar no
link do relatrio voc ter uma tela conforme a figura abaixo:
Em seguida voc pode fazer algumas customizaes para seu relatrio utilizando as sesses:
Run This Report For: aqui voc escolhe para que tipo de informao voc deseja tirar o relatrio, no
nosso caso vamos escolher user que por usurio em Select Class.
Select Class:
o User
o Distribution List
o COS
Em User voc pode tirar um relatrio para todos os usurios (All Users) ou escolhendo por usurio
(Selected Users), vamos em nosso exemplo tirar para todos os usurios.
User:
o
o
All Users
Selected User
File Format: Escolha como voc quer visualizar o relatrio, vamos escolher em Web Page para ver
direto em nosso browser, mas voc poderia escolher em CVS ou PDF para baixar e gravar o arquivo.
Web Page
Comma-Delimited File
PDF File
Sort Order: Aqui voc escolhe como quer ordenar a sada, ns vamos ordenar nesse exemplo pelo
primeiro nome (first name).
Last Name
First Name
Extension
COS
Aps customizar e escolher como voc quer rodar seu relatrio clique no boto Generate Report.
Voc vai notar que o relatrio de usurios (Users Report) traz as seguintes informaes (tambm
mostradas na tela dafigura abaixo):
Cabealho com as informaes gerais do relatrio (como foi gerado, como est a ordenao,
quantidade de usurios e assim por diante) e depois uma tabela com o detalhamento do relatrio de
usurio:
Last Name, First Name, e Alias (sobrenome, nome e apelido o user ID)
Location
Home Mail Server
Billing ID, CoS e Extension (ramal)
Account Lockout Status (se a conta est liberada ou bloqueada pelo administrador)
Personal Call Transfer Rules Enabled/Disabled Status
Os demais relatrios seguem o mesmo princpio para serem gerados a partir do CUC Serviceability
Reports, porm cada um deles traz um detalhamento de outras partes do sistema do CUC, tais como
estado atual, configuraes e utilizao do servidor.
Por exemplo, um outro relatrio que deve ser verificado com frequncia para evitar problemas de
armazenamento o Mailbox Store Report, no qual voc pode analisar como est o estado do seu
mailbox store configurado para os usurios. A tela da figura 1 a que temos ao clicar no link do
relatrio, veja que temos menos opes que no exemplo anterior, e a tela da figura 2 o relatrio
gerado (aps clicarmos no boto generate report). Note que no exemplo da figura 2 apenas 57 Kbytes
esto sendo utilizados, pois trata-se de um servidor de laboratrio. Alm disso, voc pode notar que
existem 4 caixas de correio configuradas.
Figura 1
Figura 2
No seu dia a dia como CCNA de Voz voc poder explorar outras opes, conforme necessidade de
anlise ou troubleshooting. Com a prtica voc ter uma viso de que relatrio preciso para cada
cenrio.
Cisco Unified Serviceability: Serviceability Reports Archive
Agora vamos analisar os relatrios que o CUC possui sobre a monitorao da sade do servidor e
performance, esse relatrios j vem no sistema e no precisa instalao de software a parte, tal como
RTMT. Esses relatrios esto na interface web do Unified Serviceability (no confunda com o CUC
Serviceability!).
importante saber que esses relatrios no vem habilitados e para que voc possa ter acesso a essas
informaes o primeiro passo ativar o servio Cisco Serviceability Reporter. Para ativar o servio
v ate a pgina da interface de Unified Serviceability, em Tools > Service Activation. Uma vez na
pgina de ativao selecione o servio Cisco Serviceability Reporter e clique em Save, mesmo
processo que seguimos em captulos anteriores.
O servio Serviceability Reporter tem a funo de coletar dados dos arquivos de log e popular o
Serviceability Reports Archive, o qual armazena informaes de relatrios e faz que elas fiquem
disponveis diariamente. Outro detalhe inportante que essa operao gera uma sobrecarga no
processamento do servidor (CPU-intensive service), por isso tenha em mente que ao ativar esse
servio seu servidor poder ter sua performance impactada negativamente.
A configurao sobre o tipo e quantidade de dados que deve ser coletado pode ser customizado e
ajustado na interface de administrao do CUC (CUC Administration interface), indo em System
Settings > Advanced > Reports e alterando conforme necessidade os seguintes parmetros:
1. Enable Audit Log: Por padro vem habilitado e se voc desabilitar ir para o registro dos
procedimentos armazenados para o Audit Log.
2. Maximum Events Allowed in Audit Log: Define o limite de entradas do registro de auditoria (Audit
Log). Se o nmero aqui definido exceder o mximo a entrada mais antiga ser apagada, sendo que os
valores podem ir de 1 a 100.000, com o default em 100.000.
3. Enable Security Log: Ativa e desativa o registro de atividades relativas a segurana ou Security
Log. O padro Enabled (habilitado).
4. Maximum Events Allowed in Security Log: Idem ao item 2, porm para limitar as entradas do log
de segurana (mesmos limites e padres).
5. Minutes Between Data Collection Cycles: Este valor controla a frequncia da gerao dos
relatrios, sendo que o default a cada 30 minutos.
6. Days to Keep Data in Reports Database: Define quanto tempo os relatrios devem ser mantidos na
base de dados, ou seja, o histrico (historical data). O default so 90 dias.
7. Reports Database Size (as a Percentage of Capacity) After Which the Reports Harvester Is
Disabled: Define o percentual mximo do disco que o banco de dados de relatrio pode ocupar,
sendo que se esse valor alcanado o servio de coleta (CUC Report Harvester) parado, evitando
que esse banco de dados cresa e possa prejudicar o servidor. O padro 80%.
8. Maximum Records in Report Output: Define o limite de registros (records) que sero apresentadas
na sada do relatrio. A faixa permitida entre 5.000 a 30.000, sendo que o padro 25.000. Porm
alguns relatrios possuem suas prprias limitaes com relao ao tamanho dos relatrios, por
exemplo, para o relatrio User Message Activity existe um limite de 25.000 registros.
9. Minimum Records Needed to Display Progress Indicator: Este valor define que um pop up ser
gerado juntamente com uma barra de progresso enquanto ele roda, pois a idia aqui avisar que o
relatrio selecionado grande e pode impactar a performance do servidor. A configurao permitida
vai de 1 a 10.000 com padro em 2.500.
Veja na figura abaixo a tela com a pgina de configurao de relatrios ou Report Configuration
Page.
Visualizando os Relatrios
Uma vez habilitado o servio de gerao de relatrio e configurado os parmetros de coleta das
informaes, podemos aps um certo perodo de tempo visualizar e analisar esses dados. Para extrair
os relatrios v na interface web Cisco Unified Serviceability na opo Tools > Serviceability
Reports Archive.
Uma vez nessa pgina clique no ms (month) e depois escolha o dia daquele ms que voc deseja
gerar os relatrios, note que voc tem apenas duas opes de relatrios para cada dia do ms.
A figura abaixo voc pode verifivar a tela do Serviceability Reports Archive List Page.
Conforme explicado anteriormente, existem dois tipos de relatrios no Serviceability Archive

Reports, o Alerts Report e o Server Report disponveis para visualizao por dia, porm os dados
estaro disponveis aps o tempo necessrio ter passado para a coleta das informaes, pois a coleta
inicia somente aps a ativao do servio, ou seja, se voc ativar hoje o relatrio estar disponvel a
partir de amanh.
Ao clicar no relatrio Alerts Report voc ter as seguintes informaes (conforme tela
na figura abaixo):
Number of alerts per severity in the cluster: nmero de alertas por severidade no cluster.
Number of alerts per server: nmero de alertas por servidor.
Top ten alerts in the cluster: os 10 alertas que mais aconteceram (os dez mais).
Como voc j deve ter notado, esse relatrio vem sumarizado e em formato de grfico (somente nvel
de severidade e a que servidor esto atribudos os alertas), ou seja, no traz o detalhamento.
Portanto para verificar os alertas com mais detalhes o administrador deve utilizar o RTMT (Real-Time
Monitoring Tool) para o CUC. Atravs da ferramenta Alert Central do RTMT voc pode verificar os
alertas, clicar com o boto direito em quaisquer um deles e selecionar Alert Detail para ver os
detalhes em uma janela pop-up.
J o relatrio do Server Report traz as estatsticas em formato grfico das opes abaixo (conforme
tela dafigura abaixo):
Percentage CPU per Server (percentual de uso da CPU)

Percentage Memory Usage per Server (percentual de uso da memria)
Percentage Hard Disk Usage of the Common Partition per Server (percentual de uso do disco
por servidor)
Percentage Hard Disk Usage of the Spare Partition per Server (percentual de uso do disco da
partio reserva por servidor)
Troubleshooting e Manuteno do CUC Utilizando Ferramentas de Relatrios

Com os relatrios que podem ser gerados via CUC Serviceability Reports podemos ter uma viso do
que est acontecendo com o servidor, como por exemplo:
O administrador pode tirar um relatrio do nmero de logins com falha em um perodo de tempo
(Phone Interface Failed Logon Report) para verificar se est havendo muito erro de usurios
tentando se logar. Se esse nmero for alto tem duas possibilidades, ou os usurios precisam de mais
orientao sobre como usar o sistema ou est havendo uma tentativa de invaso de caixas postais
dos usurios (hacking). Veja a tela da figura abaixo com um exemplo do Phone Interface Failed Logon
Report.
Com os relatrios que podem ser gerados via CUC Serviceability Reports podemos ter uma viso do
que est acontecendo com o servidor, como por exemplo:
Outro exemplo a utilizao do User Lockout Report normalmente em conjunto com o Failed
Login Report para fornecer as contas de usurios que esto bloqueadas (locked out) e porque elas
foram bloqueadas. Com essas informaes o administrador pode entrar em contato com o usurio e
verificar se o bloqueio foi por esquecimento da senha ou talvez por uma tentativa de invaso da sua
caixa de mensagens, alm disso, se necessrio ele pode orientar os usurios em caso deles no
estarem sabendo utilizar o sistema.
Uma vez determinados os usurios que esto bloqueados o administrador pode corrigir o problema
na interface de administrao do CUC indo em Users > Users, selecionando os usurios bloqueados
e indo em Edit > Password Settings, depois clicando em Unlock Password para liberar as contas
de usurios. Veja a figura abaixo com um exemplo da tela do relatrio.
Um outro relatrio que pode ser utilizado no dia a dia o Port Activity Report, o qual mostra
estatsticas sobre cada voicemail port (porta de correio de voz) configurada no servidor, fornecendo
as seguintes informaes:
Port Name
Inbound Calls
Outbound MWI
Outbound AMIS
Outbound Notification
Outbound TRAP
Port Total
Com essas informaes voc pode determinar se as portas esto ativas e utilizveis. Voc pode, por
exemplo, determinar a causa de um problema de MWI por nenhuma porta ter sido habilitada para
trabalhar com o MWI. Veja a tela do Port Activity Report na figura abaixo:
Relatrios que Podem Ajudar na Rotina Operacional de Manuteno do CUC

Uma das rotinas operacionais que devem ser estabelecidas, j citada anteriormente, a monitorao
dos mailbox stores (caixas postais) para evitar que o servidor fique sem espao em disco e acabe
gerando algum outro tipo de indisponibilidade de servio devido a esse problema.
Para isso voc pode utilizar o realtrio Mailbox Store Report e verificar o status sumarizado do
tamanho atual (current size), ltima condio de erro (last error condition) e o estado geral da
mailbox store. Veja na figura abaixo a sada do Mailbox Store Report.
Outra situao comum que pode ocorrer em grandes corporaes que algumas vezes os
funcionrios deixam a empresa e os administradores do sistema de telefonia podem ser informados
ou esquecerem de apagar a caixa postal desse usurio, permanecendo um lixo na base de dados.
Existe um relatrio que pode auxiliar com esse tipo de situao que chamado de Unused Voice
Mail Accounts Report, o qual permite visualizar de maneira simples as contas que no tem sido
utilizadas recentemente, permitindo que os administradores verifiquem o porque e, caso necessrio,
at apaguem as caixas de correio de usurios que j foram desligados da empresa.
Veja na figura abaixo a tela do Unused Voice Mail Accounts Report.
Acompanhando as Chamadas Realizadas pelo CUC - Tarifao

Lembre-se que o CUC pode originar ligaes tambm e muito comum a necessidade de manter o
registro e analisar essas chamadas feitas por ele, seja por motivos de estatstica ou principalmente
para um controle de custo. Lembrem que o CUC pode fazer ligaes por requisio do usurio
(assumindo que est permitido pelo CoS) e consequentemente essas chamadas podem gerar custos
elevados.
Assim como o CUC faz notificaes de mensagens possvel que algumas chamadas podem ter custo.
Por isso ele fornecetrs relatrios de tarifao (billing reports - bilhetagem) que podem ser
facilmente correlacionadas com o nmero, durao e conta de usurio que gerou a requisio da
chamada. Acompanhe abaixo uma descrio dos relatrios.
1. Transfer Call Billing Report: apresenta uma listagem das seguintes opes abaixo.
Nome, ramal (extension) e billing ID (ID de tarifao) do usurio

Data e hora da chamada
Nmero chamado (Called number)
Transfer result (resultado da transferncia - Connected, Ring No Answer, Busy ou Unknown)
2. Outcall Billing Detail Report: pode ser organizado por dia, ramal e mostra as seguintes opes
abaixo.
Nome, ramal (extension) e billing ID (ID de tarifao) do usurio

Data e hora da chamada
Nmero chamado (Called number)
Transfer result (resultado da transferncia - Connected, Ring No Answer, Busy ou Unknown)
Durao da chamada em segundos
3. Outcall Billing Summary Report: gera uma listagem que pode ser organizada por data, nome,
extension e billing ID, mostrando o dial-out time em segundos para cada hora do dia.

Ccna Voice - 640-461

Încărcat de

Informații document

Descriere originală:

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Ccna Voice - 640-461

Încărcat de

Drepturi de autor:

Formate disponibile

Conceitos de Telefonia e Comunicaes Analgicas

sem interveno humana, sendo no incio centrais analgicas eletromecnicas e

Distncia entre os aparelhos dificultava a comunicao e

Entendendo as Centrais Privativas (PABX e Key System KS)

J os Key Systems ou simplesmente KS so aplicados em ambientes de pequenas empresas, com

Conexes com a Rede Pblica - PSTN

Cdigo do Pas (Country code)

Um detalhe importante que os nmeros E.164 tem um limite de 15 dgitos. Um exemplo de

Country code Cdigo do Pas

Transmitindo a Voz Sobre o Protocolo IP VoIP

PVDM2-8: tem 0,5 chips DSP

PVDM2-32: tem 2 chips DSP

Cisco Unified Communications Manager Express CME

Cisco Unified Communications Manager Express

Na figura abaixo mostrada a lista de capacidades da famlia ISR gerao 1.

Processamento de Chamadas (Call processing) e Controle de Dispositivos (device control): O

Voicemail Integrao entre o CME e CUE

Apesar de instalada em um roteador com CME a administrao do CUE independente do roteador,

Auto-attendant: O atendimento automtico aquela voz automtica e gravada que ouvimos

1994 - Multimedia Manager

(aps a Selsius Systems ter sido adquirida em 1998 pela Cisco)

2001 - Cisco CallManager 3.1

2007 - Cisco Unified CallManager 5.0

Relacionamento das Bases de Dados do CUCM (Database Relationship): A base de dados do

Principais Recursos e Facilidades do Unity Connection

Interao do Unity Connection e CUCM

Mensagens Instantneas Corporativas: O Unified Presence pode incorporar o Jabber

Cisco Unified Personal Communicator

Cisco Unified IP Phone 7900 Series:

Power over Ethernet (PoE)

Telefones IP Cabos e Conexes

Acompanhe no diagrama abaixo, mostrado na figura abaixo, o esquema de ligao de um modelo

Switch PoE da Cisco (padro Cisco ou 802.3af)

Padro PoE IEEE 802.3af

Fonte de alimentao centralizada (no caso o switch PoE)

Patch Pannel PoE

Fonte de Alimentao Externa (Power Brick)

Configurao da VLAN de Voz

Etapa 01: Receber alimentao PoE do switch.

A principal diferena entre o Firmware e o Software que o Firmware trabalha manipulando

Permite exibir a informao correta de data/hora para todos os usurios diretamente no

Manualmente, com o comando clock set em modo EXEC privilegiado

O telefone contata o servidor do processador de chamada e se identifica atravs do seu

Gerenciando o CME com Linha de Comando (CLI)

Gerenciando o CME com Interface Grfica

Integrated CME GUI

utilizao baseada em instrues guiadas passo-a-passo, as quais guiam o usurio no caminho

Habilitando o Servio DHCP no Roteador

Configurao CME Bsica

muito importante perceber a diferena entre os parmetros max-ephone e max-dn. O

possvel associar um ephone (telefone) a mltiplas linhas(ephone-dn). Veja o exemplo abaixo.

Nesse caso, associamos o boto 1 ao dn 1 e o boto 2 ao dn 2. Ou seja, quando o usurio pressionar o

Gerenciando Arquivos de Firmware

Passo 01: Servidor TFTP

Passo 01: Servidor TFTP

Passo 02: Forar o telefone a baixar o firmware da verso intermediria

Passo 03: Resetar o telefone IP

1. Tire o cabo de rede do telefone IP e pressione a tecla #

Configurando Telefones IP via CCP

Portas de Voz x CME

Configurando Portas de Voz Analgicas

Foreign Exchange Station (FXS)

A primeira atividade antes de configurar as portas de voz analgicas de um roteador deve