Nossa, hoje me dei conta que o blog completará 1 ano em alguns dias. Mas certamente dessa vez eu não passarei o fim do ano escrevendo posts! hehehe
Hoje vou falar de call park no CME. Como dificilmente implantamos isso na vida real, esse foi um dos tópicos que me surpreendeu durante os estudos, devido a quantidade de detalhes que se pode configurar. O que eu sabia de Call Park era apenas o comando park-slot dentro de um ephone-dn e pronto, mas tem um monte de coisa que da para configurar.
Nesse post vou focar na versão 7.0 do CME, que é o que tem na prova. Na 7.1 tem algumas coisas mais, dentre elas o suporte a SIP Phones (na prova não vai cair Call Park para SIP, porque não é suportado), reservation-groups, directed call park, ...
Bom, começando do começo. Call Park é a feature de "estacionamento de chamadas", que tinha nos antigos PBX. A recepcionista, por exemplo, atendia uma ligação, fazia o park dela em um ramal XXXX, e anunciava pro chefe: "tem uma chamada no ramal XXXX". Aí o chefe ligava nesse ramal para capturá-la. No CUCM e CME temos essa feature, mas sinceramente, nunca vi ninguém usando na vida real... É mais fácil falar pro cara ligar depois! hehehe
Para configurarmos um ramal XXXX de park, simplesmente criamos um ephone-dn, por exemplo:
ephone-dn 10 dual-line
number 3010
name Call park
park-slot
Agora vamos começar a ajustar esse nosso Call Park. A primeira coisa que podemos fazer, é definir alguns timers. Podemos definir que depois de "x" segundos que um cara estiver em park, um ring de lembrete será tocado no telefone da pessoa que estacionou a chamada. Aí digamos que queremos que esse lembrete ocorra por "y" vezes, e depois disso a chamada volte para quem fez o park. Caso o ramal esteja ocupado, ele vai tentar de novo depois de "s" segundos por "z" vezes. Nesse exemplo, o nosso ephone-dn ficaria assim:
ephone-dn 10 dual-line
number 3010
name Call park
park-slot timeout x limit y recall retry s limit z
Agora, digamos que queremos que o ramal a ser notificado com um ring sobre uma chamada em park não seja o que fez o estacionamento, mas sim um um outro qualquer (por exemplo, o ramal 2001), aí faríamos:
ephone-dn 10 dual-line
number 3010
name Call park
park-slot timeout x limit y notify 2001 recall
O cliente mudou o requisito de novo, e agora ele quer que quando o timeout/limit acabe, ao invés de a chamada voltar para quem fez o park, ela deve tocar no ramal 2050, e depois para o 2051 caso o 2050 esteja ocupado:
ephone-dn 10 dual-line
number 3010
name Call park
park-slot timeout x limit y notify 2001 transfer 2050 alternate 2051
Obs: Podemos usar o alternate também como uma segunda opção do recall, ou seja:
ephone-dn 10 dual-line
number 3010
name Call park park-slot timeout x limit y notify 2001 recall alternate 2050
Bom, agora que estava todo mundo usando o call park a vontade, o cliente percebeu que muitas chamadas estavam se perdendo. Então ele quer que apenas a recepcionista no ramal 2000 consiga utilizar esse call-park. Aí utilizaremos o comando reserved-for:
ephone-dn 10 dual-line
number 3010
name Call park
park-slot reserved-for 2000 timeout x limit y recall
Mas mesmo assim, descobriram que o pessoal continua conseguindo fazer park da chamada. Só que ao invés de eles pressionarem o softkey Park para isso, eles descobriram que se eles dessem um transfer para o ramal 3010, a chamada era estacionada! Olha só que usuários safadinhos! Mas para isso podemos bloquear esse comportamento configurando dentro do ephone:
ephone X
transfer-park blocked
Com isso, abordamos quase tudo de call park no CME, tem mais coisa, mas isso é o que eu me lembro! hahaha... Só tem mais uma coisa importante para se dizer. Por default, se existir por exemplo um ramal 1003 e um park-slot 3303, ele sempre vai tentar usar esse por causa do match dos últimos 2 dígitos. Se existisse um outro park-slot 3302, ele seria usado como segunda opção. Para desligar esse comportamento, faça:
telephony-service
call-park select no-auto-match
Eu recomendo que façam vários testes com Call park, porque são muitos detalhes, como tudo no CME. A melhor coisa para se fazer ao estudar CME é ler o Admin Guide inteiro e ir testando feature por feature. Tenho várias páginas de anotações de CME no meu caderno (como essa), e aos poucos vou postando.
sábado, 22 de dezembro de 2012
sábado, 1 de dezembro de 2012
Dial-Peer Matching
Esse é um tema fácil, mas um tanto confuso. O match de dial-peer é extremamente importante para você definir a sua call leg de entrada e de saída no roteador, e fazer certo o seu dial plan.
Toda chamada que passa pelo gateway (seja ela voip ou pots) deve ter essas duas pernas: uma entrada e uma saída. Para entender melhor o que é isso, se coloque no lugar do roteador. Imagine uma chamada vindo da PSTN e tocando no IP Phone. Para o roteador, a perna que vem da PSTN é a entrada, e a que toca no telefone (ou seja, a que manda para o CUCM) é a saída. Já em uma chamada onde o IP Phone origina e toca na PSTN é ao contrário, temos uma perna de entrada que é a que vem do CUCM, e uma de saída que vai para a PSTN. Toda chamada para completar com sucesso precisa dessas duas dial-peers.
Para configurar uma dial-peer para dar matches de entrada ou saída, usamos os comandos incoming called-number, answer-address, destination-pattern e ports.
Dial-Peer de Entrada
O roteador possui 4 maneiras de verificar se uma chamada específica teve match em alguma dial-peer de entrada, analisando o número de origem (ANI, ou Calling Number) ou destino (DNIS, ou Called Number) dessa chamada, ou a voice port que foi usada para recebê-la. E o roteador analisa nessa ordem:
1. Compara o número Destino com o incoming called-number
2. Compara o número de Origem com o answer-address
3. Compara o número de Origem com o destination-pattern
4. Verifica a Voice Port que recebeu a chamada
O que geralmente fazemos na vida real é logo de cara forçar uma dial-peer de entrada do tipo pots e do tipo voip. Assim:
dial-peer voice 1 pots
incoming called-number .
dial-peer voice 2 voip
incoming called-numer .
Com isso, toda chamada que entrar da PSTN vai bater na dial-peer 1 como entrada (e aqui faria sentido você colocar o comando direct-inward-dial dentro da dial-peer); e toda chamada que entrar do CUCM vai bater na dial-peer 2 como entrada (e aqui faria sentido você definir os codecs).
Mas e se eu quiser forçar uma dial-peer de entrada que tem como destino um ramal específico para, por exemplo, chamar uma aplicação ao invés de mandar para o CUCM (sabe usamos isso, né? No MVA!). Aí eu poderia forçar assim:
Ah, mas e se eu quero dar match na entrada usando o número de origem, e não de destino? Aí podemos usar o answer-address ou destination-pattern (embora esse último seja um pouco complicado, já que usaremos ele também para dial-peer de saída). Mas veja que o roteador só vai partir para essa análise caso a regra 1 não tenha sido atendida.
Caso a chamada entrante não dê match em nenhuma das 3 primeiras regras, o roteador vai analisar a voice port (isso se aplica somente a dial-peers pots). Então se você tem eventualmente uma dial-peer de saída apontando para port 0/0/0:0, e a chamada entrou por essa mesma porta, o roteador pode considerar essa dial-peer como a de entrada. Se houver mais que uma dial-peer apontando para a mesma voice-port, o critério de desempate vai ser a dial-peer adicionada primeiro na configuração.
E por fim, se nenhuma das 4 regras foi atendida, finalmente o roteador vai usar a dial-peer default do sistema que é a 0. Essa dial-peer não é vista na configuração, não é configurável, e portanto queremos evitá-la a todo custo!
A dica que dou é sempre usar o incoming called-number nas suas dial-peers de entrada (a não ser que um requisito maluco da prova te obrigue a usar o answer-address). É importante você ter bastante controle da sua entrada para eventualmente aplicar regras de translations nela (que falarei mais em um outro post), e também para você não cair em caso de codec mismatch e tal, especialmente quando for implementar CUBE, onde o conceito de match de dial-peer de entrada é fundamental.
Dial-Peer de Saída
A saída é bem mais fácil, pois o roteador utiliza um único comando para isso, que é o destination-pattern, velho conhecido de todos nós. E a saída é definida pelo comando port (no caso de dial-peer pots) ou session target (no caso de dial-peer voip).O que tem mais de interessante para falar nas dial-peers de saída é como os critérios de desempate são feitos.
A regra é que por default, quando um número destino da match em vários destination-patterns, de várias dial-peers, o critério de desempate é pelo match mais específico. Porém, temos duas situações aqui:
1. Quando a dial-peer de entrada é do tipo DID (quando colocamos o comando direct-inward-dial, presente apenas em dial-peers pots), a análise dos dígitos na saída é feita com o bloco inteiro dos números. Ou seja, se o roteador recebeu 32324444, ele vai analisar toda essa string de uma só vez. Logo, uma dial-peer com destination-pattern 32324444 vai dar match, enquanto uma dial-peer com destination-pattern 32324, por exemplo, não vai dar match. Esse caso se aplica, portanto, apenas nas chamadas entrantes da PSTN.
2. Quando a dial-peer de entrada não é do tipo DID, o roteador passa a analisar os números dígito a dígito na saída. Então se, por exemplo, o roteador receber os mesmos 32324444, agora na saída a dial-peer com destination-pattern 32324 dará match antes da dial-peer com destination-pattern 32324444, e logo será usada. E se houver uma terceira dial-peer com destination-pattern 32324..., ela também não será usada porque é menos específica que a 32324444 (aí sim entra o critério de desempate da mais específica).
Você pode também alterar a forma como o roteador faz o seu critério de desempate das dial-peers com o comando dial-peer hunt. O valor default é o 0, mas você pode configurar qualquer um dos 7 abaixo:
0 - Longest match in phone number, explicit preference, random selection.
1 - Longest match in phone number, explicit preference, least recent use.
2 - Explicit preference, longest match in phone number, random selection.
3 - Explicit preference, longest match in phone number, least recent use.
4 - Least recent use, longest match in phone number, explicit preference.
5 - Least recent use, explicit preference, longest match in phone number.
6 - Random selection.
7 - Least recent use.
Debugs úteis
Um dos melhores, aliás, o melhor debug para ver matching de dial-peer é o debug voip dialpeer. Mas outros comandos também são úteis:
debug voip dialpeer
show voice call status ! -- mostra a dial-peer de entrada e saída de cada chamada ativa no roteador
debug voice ccapi inout ! -- Mostra o match de entrada, saída, número de origem, destino, debug muito útil em qualquer situação. Só que ele gera muito output.
show dialplan number XXXXX ! -- onde XXXXX é o número de destino. Ele mostra em quais dial-peers a chamada dará match na saída. Ótimo para testar se a sua dial-peer está dando match.
show dial-peer voice summary ! -- mostra o tipo de hunt configurado e o resumo das dial-peers criadas
show run | sec dial-peer !-- Muito útil! Mostra o show run apenas das suas dial-peers
Toda chamada que passa pelo gateway (seja ela voip ou pots) deve ter essas duas pernas: uma entrada e uma saída. Para entender melhor o que é isso, se coloque no lugar do roteador. Imagine uma chamada vindo da PSTN e tocando no IP Phone. Para o roteador, a perna que vem da PSTN é a entrada, e a que toca no telefone (ou seja, a que manda para o CUCM) é a saída. Já em uma chamada onde o IP Phone origina e toca na PSTN é ao contrário, temos uma perna de entrada que é a que vem do CUCM, e uma de saída que vai para a PSTN. Toda chamada para completar com sucesso precisa dessas duas dial-peers.
Para configurar uma dial-peer para dar matches de entrada ou saída, usamos os comandos incoming called-number, answer-address, destination-pattern e ports.
Dial-Peer de Entrada
O roteador possui 4 maneiras de verificar se uma chamada específica teve match em alguma dial-peer de entrada, analisando o número de origem (ANI, ou Calling Number) ou destino (DNIS, ou Called Number) dessa chamada, ou a voice port que foi usada para recebê-la. E o roteador analisa nessa ordem:
1. Compara o número Destino com o incoming called-number
2. Compara o número de Origem com o answer-address
3. Compara o número de Origem com o destination-pattern
4. Verifica a Voice Port que recebeu a chamada
O que geralmente fazemos na vida real é logo de cara forçar uma dial-peer de entrada do tipo pots e do tipo voip. Assim:
dial-peer voice 1 pots
incoming called-number .
dial-peer voice 2 voip
incoming called-numer .
Com isso, toda chamada que entrar da PSTN vai bater na dial-peer 1 como entrada (e aqui faria sentido você colocar o comando direct-inward-dial dentro da dial-peer); e toda chamada que entrar do CUCM vai bater na dial-peer 2 como entrada (e aqui faria sentido você definir os codecs).
Mas e se eu quiser forçar uma dial-peer de entrada que tem como destino um ramal específico para, por exemplo, chamar uma aplicação ao invés de mandar para o CUCM (sabe usamos isso, né? No MVA!). Aí eu poderia forçar assim:
dial-peer voice 4444 pots
service mva
incoming called-number 4444
no digit-strip
Ah, mas e se eu quero dar match na entrada usando o número de origem, e não de destino? Aí podemos usar o answer-address ou destination-pattern (embora esse último seja um pouco complicado, já que usaremos ele também para dial-peer de saída). Mas veja que o roteador só vai partir para essa análise caso a regra 1 não tenha sido atendida.
Caso a chamada entrante não dê match em nenhuma das 3 primeiras regras, o roteador vai analisar a voice port (isso se aplica somente a dial-peers pots). Então se você tem eventualmente uma dial-peer de saída apontando para port 0/0/0:0, e a chamada entrou por essa mesma porta, o roteador pode considerar essa dial-peer como a de entrada. Se houver mais que uma dial-peer apontando para a mesma voice-port, o critério de desempate vai ser a dial-peer adicionada primeiro na configuração.
E por fim, se nenhuma das 4 regras foi atendida, finalmente o roteador vai usar a dial-peer default do sistema que é a 0. Essa dial-peer não é vista na configuração, não é configurável, e portanto queremos evitá-la a todo custo!
A dica que dou é sempre usar o incoming called-number nas suas dial-peers de entrada (a não ser que um requisito maluco da prova te obrigue a usar o answer-address). É importante você ter bastante controle da sua entrada para eventualmente aplicar regras de translations nela (que falarei mais em um outro post), e também para você não cair em caso de codec mismatch e tal, especialmente quando for implementar CUBE, onde o conceito de match de dial-peer de entrada é fundamental.
Dial-Peer de Saída
A saída é bem mais fácil, pois o roteador utiliza um único comando para isso, que é o destination-pattern, velho conhecido de todos nós. E a saída é definida pelo comando port (no caso de dial-peer pots) ou session target (no caso de dial-peer voip).O que tem mais de interessante para falar nas dial-peers de saída é como os critérios de desempate são feitos.
A regra é que por default, quando um número destino da match em vários destination-patterns, de várias dial-peers, o critério de desempate é pelo match mais específico. Porém, temos duas situações aqui:
1. Quando a dial-peer de entrada é do tipo DID (quando colocamos o comando direct-inward-dial, presente apenas em dial-peers pots), a análise dos dígitos na saída é feita com o bloco inteiro dos números. Ou seja, se o roteador recebeu 32324444, ele vai analisar toda essa string de uma só vez. Logo, uma dial-peer com destination-pattern 32324444 vai dar match, enquanto uma dial-peer com destination-pattern 32324, por exemplo, não vai dar match. Esse caso se aplica, portanto, apenas nas chamadas entrantes da PSTN.
2. Quando a dial-peer de entrada não é do tipo DID, o roteador passa a analisar os números dígito a dígito na saída. Então se, por exemplo, o roteador receber os mesmos 32324444, agora na saída a dial-peer com destination-pattern 32324 dará match antes da dial-peer com destination-pattern 32324444, e logo será usada. E se houver uma terceira dial-peer com destination-pattern 32324..., ela também não será usada porque é menos específica que a 32324444 (aí sim entra o critério de desempate da mais específica).
Você pode também alterar a forma como o roteador faz o seu critério de desempate das dial-peers com o comando dial-peer hunt. O valor default é o 0, mas você pode configurar qualquer um dos 7 abaixo:
0 - Longest match in phone number, explicit preference, random selection.
1 - Longest match in phone number, explicit preference, least recent use.
2 - Explicit preference, longest match in phone number, random selection.
3 - Explicit preference, longest match in phone number, least recent use.
4 - Least recent use, longest match in phone number, explicit preference.
5 - Least recent use, explicit preference, longest match in phone number.
6 - Random selection.
7 - Least recent use.
Debugs úteis
Um dos melhores, aliás, o melhor debug para ver matching de dial-peer é o debug voip dialpeer. Mas outros comandos também são úteis:
debug voip dialpeer
show voice call status ! -- mostra a dial-peer de entrada e saída de cada chamada ativa no roteador
debug voice ccapi inout ! -- Mostra o match de entrada, saída, número de origem, destino, debug muito útil em qualquer situação. Só que ele gera muito output.
show dialplan number XXXXX ! -- onde XXXXX é o número de destino. Ele mostra em quais dial-peers a chamada dará match na saída. Ótimo para testar se a sua dial-peer está dando match.
show dial-peer voice summary ! -- mostra o tipo de hunt configurado e o resumo das dial-peers criadas
show run | sec dial-peer !-- Muito útil! Mostra o show run apenas das suas dial-peers
Assinar:
Postagens (Atom)