quarta-feira, 15 de agosto de 2012

Line-Device Approach

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

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

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

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

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

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

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

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

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

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

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

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

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


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

Nenhum comentário:

Postar um comentário