Visão Geral da Configuração :: Admirável Mundo Novo




Muito Bem Vindo

Prezado Leitor, a proposta desse Blog é compartilhar conhecimento com as pessoas que trabalham com Linux, Asterisk, OpenSER, e com tecnologia de voz sobre a rede IP em geral, através de tutoriais, dicas, howto, notícias entre outros assuntos.

Atente para termo de uso do conteúdo do blog no rodapé da página.

quarta-feira, 2 de julho de 2008

Visão Geral da Configuração




Visão Geral da Configuração

A primeira coisa a fazer para que isso funcione é a definição dos mapeamentos entre troncos virtuais e stations virtuais para canais Asterisk. Isso é feito no arquivo sla.conf. Por exemplo, isso define alguns "troncos" para esse sistema de tecla virtual para os canais Asterisk, os quais acontecem de ser 3 linhas FXO aqui:

--sla.conf--

[line1]
type=trunk
device=Zap/1

[line2]
type=trunk
device=Zap/2

[line3]
type=trunk
device=Zap/3

Para criar stations virtuais, nós temos que mapeá-las para um canal Asterisk bem como definir quais os troncos virtuais essa station vai usar. As stations são telefones SIP neste caso:

[station1]
type=station
device=SIP/station1
trunk=line1
trunk=line2

[station2]
type=station
device=SIP/station2
trunk=line1
trunk=line2

[station3]
type=station
device=SIP/station3
trunk=line1
trunk=line2

O próximo passo é configurar os próprios canais Asterisk (Zap/1, SIP/station1, etc.). Isso seria feito nos arquivos zapata.conf e sip.conf. Esses canais seriam configurados como de praxe em suas partes importantes. A única parte que eu desejo notificar aqui, é que nos exemplos, o parâmetro "context" para os canais Zap seria configurado como "line1", "line2" e "line3". O parâmetro "context" no arquivo sip.conf para todas as stations seria "sla_stations". Isso faz com que as chamadas entrantes de cada tronco ir para seu próprio contexto, e chamadas entrantes dos telefones para todos ir para o contexto "sla_stations".

Agora, a interface entre as chamadas entrantes no Asterisk e a camada de emulação SLA no Asterisk é construída no dialplan (extensions.conf). Antes de chegar lá, deixe-me explicar os objetivos das aplicações de dialplan SLA.

O código SLA monitora o que está acontecendo em todos os troncos e stations virtuais. A lógica controla:

o Se um telefone está em uso, determina ao qual tronco estaria conectado.
o Se um telefone não está em uso:
o Ele controla se o telefone estaria ou não tocando.
o Ele controla qual o led para cada tronco virtual estaria mostrando.

A coisa interessante a notar é que o controle do toque dos telefones não está amarrado a fazer brilhar os led´s. O telefone não executa nenhuma dessa mágica que associa as chamadas para cada tronco virtual. Para examinar um pouco mais de perto, vamos iniciar com alguma coisa de dialplan.

[line1]
exten => s,1,SLATrunk(line1)

[line2]
exten => s,1,SLATrunk(line2)

[line3]
exten => s,1,SLATrunk(line3)

O fragmento anterior do dialplan é o que acontece quando alguma chamada chega sobre uma das linhas FXO. Imediatamente executa a aplicação "SLATrunk" com um argumento que indica qual tronco virtual está chamando.

Dentro da aplicação SLA trunk, a camada SLA verifica todas as stations que usam esse tronco para ver se eles já estão tocando ou se está em uso. Se não estiver, ela vai fazer com que o telefone comece a tocar. Além disso, ela define algumas informações especiais de estado que então faz o led dessa linha começar a brilhar no telefone. Uma vez que um dos telefones atenda, eles estão conectados em uma conferência, os outros telefones param de tocar se eles não tiverem nenhuma das suas outras linhas tocando, e todos os leds dos telefones correspondentes a essa linha mostre a linha como estando em uso.

Agora, vamos examinar o que entra no plano de discagem para fazer funcionar a interface para as stations. Nisto, eu estou apenas mostrando a parte para a station1. Contudo, a mesma informação do dialplan seria semelhante para as outras stations, também:

[sla_stations]
exten => station1,1,SLAStation(station1)
exten => station1_line1,1,SLAStation(station1_line1)
exten => station1_line2,1,SLAStation(station1_line2)
exten => station1_line3,1,SLAStation(station1_line3)
exten => station1_line1,hint,SLA:station1_line1
exten => station1_line2,hint,SLA:station1_line2
exten => station1_line3,hint,SLA:station1_line3

Realmente existem dois tipos de entradas diferentes no exemplo mostrado acima, que estão separadas por uma linha em branco.

As primeiras 4 linhas definem o que acontece quando uma chamada chega de uma station. Existem 4 extensões aqui porque o comportamento é diferente baseado no fato de como o telefone iniciou a chamada. Se o telefone estiver apenas fora do gancho, ele chama a aplicação SLAStation com o argumento "station1". No entanto, se a chamada foi iniciada pelo usuário pressionando o botão da line1, então a aplicação SLAStation é chamada com um argumento de "station1_line1". Isso diz ao core SLA que o botão da line1 foi pressionado.

Se o telefone chama "station1", o core SLA vai então buscar o primeiro tronco que não está em uso, tirando-o do gancho, e colocando-o em uma conferência com o telefone. Então, ele vai fazer que todos os led´s ao longo dos telefones que mostram "line1”, mostrarem que a linha está em uso.

Se o telefone chama "station1_line1", o core SLA vai apenas drop a chamada dentro da conferência existente com os outros telefones que já estão na chamada sobre esta linha. (Isso pode ser evitado usando uma opção de configuração, mas isso não vem ao caso, aqui).

O segundo conjunto de entradas no fragmento do dialplan anterior são os "hints". Essa é a entrada mágica no dialplan que permite aos telefones monitorarem o estado de cada “tronco” virtual no sistema. Na configuração do telefone SIP em si, você configuraria um botão (às vezes, chamado BLF) para subscrever o estado das extensões "station1_line1", "staiton1_line2" e "station1_line3". Isso é o que permite ao core SLA controlar quais os led´s refletir sobre o telefone.







Nenhum comentário:




Creative Commons License
Admirável Mundo Novo: Tudo Sobre Asterisk, OpenSER, Linux e Tecnologias de Voz sobre IP
by Cléviton Mendes de Araújo is licensed under a Creative Commons Atribuição 2.5 Brasil License.