Usando o DUNDi para Formar um Cluster Asterisk

DUNDi é um sistema peer-to-peer para localização de gateways Internet para serviços de telefonia em um Cluster Asterisk. Diferente dos serviços centralizados tradicionais (como o padrão ENUM consideravelmente simples e conciso), o DUNDi é completamente distribuído sem nenhuma hierarquia centralizada.

A implementação de um Cluster Asterisk nos dar a capacidade de distribuir a carga de funções do Soft Switch/PABX ao longo de vários servidores Asterisk em uma infra-estrutura comum ou remota. Isso permite ao Cluster ser visto e ser percebido como um imenso SoftSwitch. Isso também pode nos permitir construir uma estrutura da função softswitch em arquitetura com alta capacidade de execução de failover - é a capacidade do sistema se autorecuperar rapidamente e manter o funcionamento normal quando algum componente do sistema falha, não deixando, assim, que os usuários do sistema percebam que tal falha oconteceu -, e de alta disponibilidade para os Agentes SIP.

Implementando o protocolo DUNDi em um Cluster Asterisk você terá a base de um núcleo de rede que executa a comutação VoIP que é escalável sem a necessidade de se fazer estaticamente endereçamento dos peers SIP para um servidor de registro especifico - esse é o elemento responsável por acatar ou não o pedido de registro de um agente SIP cliente - que então executa script estático no dialplan que roteia para aqueles servidores de registro. A localização dinâmica do peer e o estabelecimento de contato é o objetivo desse material.

Isso serve a uma gama de necessidades fundamentais quando se está projetando e construindo uma rede de Telefonia IP.

1. Projetaremos um ambiente que é por si mesmo tratado através do núcleo do softswitch.

2. Projetaremos a arquitetura tendo em mente a escalabilidade e crescimento orgânico de forma que os custos com equipamento incremental sejam baixos.

Figura* 1: Cluster Asterisk

Temos que tratar de várias necessidades individuais para realizar localização dinâmica do peer e um método de contactá-los diretamente ou indiretamente durante uma falha de PABX. Para completar a localização dinâmica do peer através do Cluster, vamos discutir os passos requeridos. Primeiro, necessitamos implementar um método através do qual um PABX individual possa ficar ciente quando um UA/SIP específico esteja com o seu registro ativo. Quando um UA/SIP se registra com um PABX, é obrigação ao PABX local deixar outros PABX´s saber onde esse UA/SIP estar e como ele pode ser contatado.

Também necessitamos da capacidade para o cluster compartilhar uma série de informação comum sobre dados de registro do UA/SIP. Isso é conseguido através do Asterisk RealTime Architecture usando a informação do Users/Peer SIP puxada de uma Base de Dados MySQL. Essa base de dados pode ser um servidor isolado ou um cluster de servidores em um arranjo de alta disponibilidade e com balanceamento de carga.

Obs.: Embora esse material e o original faça referência ao uso do Realtime com o Mysql, o realtime também pode ser configurado em conjunção com o banco de dados Postegresql. Veja aqui tutorial em português de como fazer isso.

Tendo uma base de dados comum onde todos os servidores puxam a mesma informação, elimina a necessidade de provisão para cada servidor responsável por fazer registro SIP no Cluster.

Para Anúncios de Peer Dinâmico, usamos “regcontext” no arquivo sip.conf: Se regcontext for especificado, o Asterisk criará e destruirá dinamicamente uma extensão de prioridade 1 com o comando NoOp para um dado peer que se registra com o servidor. Se o contexto não for especificado no arquivo extensions.conf, então o Asterisk criará dinamicamente o contexto no dialplan quando um UA/SIP se registrar.

Para o exemplo neste artigo, coloque o fragmento seguinte no arquivo sip.conf:

[general]
regcontext=sipregistration

Uma vez que os telefones, neste exemplo, 1001 e 1006, se registram com REGPBX1, um contexto [sipregistration] aparece e a saída do comando "show dialplan" na CLI do asterisk vai gerar:

REGPBX1*CLI> show dialplan
[ Context 'sipregistration' created by 'SIP' ]
'1001' ⇒ 1. Noop(1001) [SIP]
'1006' ⇒ 1. Noop(1006) [SIP]

Ele gera um contexto dedicado nesse PABX para o qual podemos mapear requisição de consultas DUNDi. Quando um pedido DUNDi chega para a extensão 1001, esse PABX responderá, “Sim, a extensão está ativa aqui e esse é o endereço de contato”. Quando um pedido DUNDi entra para extensão 1002, esse PABX responderá, “Não, essa extensão não está ativa aqui”.

Não existe nenhuma necessidade de inserir um contexto [sipregistration] no arquivo extensions.conf, porque o PABX criará dinamicamente o contexto no dialplan tão logo um agente SIP se registre.

Como inserimos o parâmetro regcontext=sipregistration no arquivo sip.conf de cada um servidor de registro, nós começamos a perceber a maneira como o cluster intuitivamente sabe onde o UA/SIP está registrado quando executa consultas DUNDi.

Com um servidor no cluster dedicado ao processamento de requisições de consultas DUNDi, eliminamos duas dores de cabeça associadas com a escalabilidade e crescimento do núcleo da função Softswitch.

1. Quando do acréscimo de um novo servidor de registro ou de um servidor gateway PSTN ao cluster, precisamos inserir a nova informação do peer ao servidor de consultas DUNDi em vez de acrescentar os novos peers a todos os servidores de registro e os servidores gateway PSTN. Com alguns poucos servidores, convenhamos, isso não é lá um grande problema, mas com 50 ou mais servidores, a manutenção do dialplan pode se arrastar por várias horas ou até mesmo várias tardes.

2. Quando criamos mais tronco de acesso em outras localidades, você diz que está ativando um link E1 Dedicado para Lake Charles, Los Angelis; você tem apenas que fazer uma rota/ translação no servidor de consultas DUNDi em vez de passar por todos os servidores de registro e então cadastrar o peer para o novo servidor em um ou mais NÓS existente no cluster.

Para o DUNDi funcionar através do cluster, primeiro temos de instalar um canal interno de pedido DUNDi e também um canal para passar chamadas entre os PABXs.

Neste exemplo, usaremos um método muito simples e não criptografado com o IAX2. Em um ambiente padrão de produção, os métodos de segurança do IAX2 podem ser implementados para prover criptografia AES. Agora existem muitas formas de configurar ele e justamente alguns poucos parâmetros que podemos especificar para segurança entre todos os servidores de registro e servidor de consultas DUNDi, cada um tendo o seu próprio contexto, relacionamentos peer/users e chaves de segurança ou senha. Como esse exemplo é para um cluster fora da internet e somente usado para rotear ligações e pedido DUNDI internamente, apenas usamos um contexto simples no arquivo iax.conf que é comum a todos os servidores. O IAX2 também pode usar criptografia RSA para prover autenticação assimétrica.

Exemplo no arquivo iax.conf:

[priv]
type=friend
dbsecret=dundi/secret
context=incomingdundi

Adicione esse contexto em cada servidor. Fazendo isso, completa a instalação com IAX2. Agora todos os PABX´s tem um canal para troca de mensagens de pedido/resposta de consultas DUNDi e também um canal para direcionar as chamadas através do cluster.

No arquivo dundi.conf:

Na seção [mappings] é onde especificamos para qual [context] no arquivo extensions.conf queremos permitir acesso aos pedidos DUNDi. Isso é como o cluster enxerga todo e qualquer UA/SIP disponível no contexto [sipregistration] neste PABX.

[mappings]
priv ⇒ sipregistration,0,IAX2,priv:${SECRET}@10.10.10.121/${NUMBER},nopartial

Quando um pedido de consulta DUNDi chega a esse PABX, o DUNDi retornará um report com todo e qualquer UA/SIP que aparece no contexto [sipregistration] do dialplan. Se o pedido é para uma extensão não listada no contexto [sipregistration], esse PABX responderá à consulta DUNDi com um "not found".

Temos 5 servidores de registro que nomeamos de regpbx1, regpbx2, regpbx3, regpbx4 e regpbx5. A informação do UA/SIP chega dinamicamente puxada de uma base de dados MySQL usando o mecanismo do Asterisk RealTime. Quando um Agente SIP tenta se registrar em um servidor de registro, o Asterisk busca a informação do Agente armazenada na base de dados MySQL, se ele estiver presente; será permitido ao agente se registrar.

Temos um PABX Asterisk para processar pedidos de consultas DUNDi e passar as ligações dos Gateways PSTN para os servidores de registro SIP do Cluster, nomeamos esse servidor de dunpbx1. Este PABX forma o núcleo DUNDi com todos os 5 servidores de registro. Sendo todos os 5 servidores de registro somente peer desse servidor de consultas DUNDi, o dunpbx1. Observe que o uso de um servidor DUNDi dedicado não é necessário (e claro, neste exemplo, introduz um SPOF - single point of failure - por si mesmo), mas é usado neste exemplo para tornar a arquitetura bastante fácil de visualizar.

Em um ambiente de produção, todos os servidores seriam conectados a pelo menos outros dois NÓS via DUNDi para eliminar um Ponto Único de Falha (single point of failure – SPOF). Cada servidor de registro é configurado como no arquivo dundi.conf.

No arquivo dundi.conf do Regpbx1:

[general]
department=dept
organization=company
locality=city
stateprov=state
country=US
email=engineer@company.com
phone=contact phone number
;bindaddr=0.0.0.0
;port=4520
entityid=02:03:AF:B7:FF:37 (Isso padroniza ao endereço MAC da primeira NIC, mas é uma boa idéia especificá-lo).


***********************************************************************

cachetime=5

Reduzimos o cachetime a 5 segundos, isso nos permite executar um pedido de busca DUNDi toda vez que discamos. Se um servidor de registro falhar, e esse valor é definido ao valor padrão, ou seja 1 hora, ele gastaria até uma hora antes que as extensões (ramais) que foram registradas nesse servidor de registro sejam conhecidos em algum outro servidor no cluster mesmo que eles se registrem novamente em outro servidor. Escolha um cachetime baseado na sua própria preferência levando em consideração redução do número de consultas versos reconhecimento mais rápido de alterações através da rede.

***********************************************************************

ttl=2
Não desejamos fazer consultas passando além de qualquer um dos servidores de registro local, então limitamos o salto à 2. Novamente, em um ambiente de produção, o valor 1 deixaria o ttl muito mais longo. (veja a figura 2, o diagrama de Contagem de Saltos DUNDi).

***********************************************************************
autokill=yes
;secretpath=dundi
;storehistory=yes


***********************************************************************


[mappings]
priv ⇒ sipregistration,0,IAX2,priv:${SECRET}@10.10.10.121/${NUMBER},nopartial


Quando um pedido de consulta DUNDi chega no canal [priv], esse PABX anunciará toda e qualquer extensões(ramais) que estiverem presentes no contexto [sipregistration] no dialplan e se o extensão(ramal) existir aqui, o PABX enviará de volta a informação de contato IAX2/priv:${SECRET}@o endereço IP desse servidor/o número da extensão pedida.
Essa é a seção no peer, com quem esse PABX tem parceria:

[00:14:22:23:26:2E] ;(esse é o endereço MAC do servidor DUNDi dunpbx1)
model = symmetric
host = 10.10.10.120 ;(esse é o endereço IP do servidor de busca DUNDi dunpbx1)
inkey = dundi
outkey = dundi
include = priv
permit = priv
qualify = yes
order = primary


Nota: Use o mesmo inkey/outkey para os servidores regpbx1, 2, 3, 4, 5 e dunpbx1. Já que todas as buscas DUNDi estão dentro deste cluster, provisionando 1 conjunto de keys e compartilhamento através do cluster é muito mais fácil do que ficar mantendo rastro de um conjunto de cada um dos servidor. Isso também ajuda quando do acréscimo de novos servidores ao cluster.
Copie o arquivo de configuração acima para os outros servidores de registro e modifique as entradas específicas para cada um dos servidores:
entityid=02:03:AF:B7:FF:37 (isso é específico de servidor, por PABX)
[mappings]
priv ⇒ sipregistration,0,IAX2,priv:${SECRET}@10.10.10.122/${NUMBER},nopartial


(endereço IP é específico do servidor, por PABX) O Servidor de Consultas DUNDi, o dunpbx1, tem uma seção peering com todos os 5 servidores de registro, quais sejam:

[01:31:AF:E7:FF:37] ;(entityid (endereço MAC) do regpbx1)
model = symmetric
host = 10.10.10.121 (endereço IP de regpbx1)
inkey = dundi
outkey = dundi
include = priv
permit = priv
qualify = yes
order = primary


[03:11:AA:02:B3:1D] ;(entityid (endereço MAC) de regpbx2)
model = symmetric
host = 10.10.10.122 ;(endereço IP de regpbx2)
inkey = dundi
outkey = dundi
include = priv
permit = priv
qualify = yes
order = primary


[05:31:AD:18:53:0B] ;(entityid (endereço MAC) do regpbx3)
model = symmetric
host = 10.10.10.123 ;(endereço IP do regpbx3)
inkey = dundi
outkey = dundi
include = priv
permit = priv
qualify = yes
order = primary


[01:19:4A:52:B3:1D] ;(entityid (endereço MAC) do regpbx4)
model = symmetric
host = 10.10.10.124 ;(endereço IP do regpbx4)
inkey = dundi
outkey = dundi
include = priv
permit = priv
qualify = yes
order = primary


[02:7A:AE:43:52:0C] ;(entityid (endereço MAC) do regpbx5)
model = symmetric
host = 10.10.10.125 ;(endereço IP do regpbx5)
inkey = dundi
outkey = dundi
include = priv
permit = priv
qualify = yes
order = primary


Use o comando "dundi show peers" no CLI do Asterisk para ver o estado da conexão com os peers identificados no arquivo dundi.conf:

dunpbx1*CLI> dundi show peers

EID Host Model AvgTime Status
01:31:af:e7:ff:37 10.10.10.121 (S) Symmetric Unavail OK (1 ms)
03:11:aa:02:b3:1d 10.10.10.122 (S) Symmetric Unavail OK (1 ms)
05:31:ad:18:53:0b 10.10.10.123 (S) Symmetric Unavail OK (1 ms)
01:19:4a:52:b3:1d 10.10.10.124 (S) Symmetric Unavail OK (1 ms)
02:7a:ae:43:52:0c 10.10.10.125 (S) Symmetric Unavail OK (1 ms)
5 dundi peers [5 online, 0 offline, 0 unmonitored]
ast1*CLI>


Com esses 5 peers PABX listado como tais, quando um pedido de consulta DUNDi chega de regpbx1, esse PABX vai pedir a informação de localização da extensão(ramal) em regpbx2, 3, 4 e 5. Se um pedido de consulta DUNDi vem de regpbx3, esse PABX vai pedir informação de localização de extensão(ramal) em regpbx1, 2, 4 e 5.
O valor TTL neste arranjo é importante manter baixo. O Servidor de consultas DUNDi está restrito a 1 hop somente, ou seja TTL=1, assim, os pedidos não se propagam para além dos servidores de registro. Os servidores de registro estão restritos a 2 hops, ou seja TTL=2, pela mesma razão, mas se eles fossem definido a 1 hop somente, o pedido de consulta DUNDi não conseguiria passar além do Servidor de Consulta DUNDi. Veja a figura 2, Diagrama de Contagem de Saltos DUNDi.


Figura* 2: Diagrama de Contagem de Salto DUNDi

Assim, agora temos anunciado a localização dinâmica do Agente SIP dentro do cluster, como rotearemos chamadas dentro do cluster, com que se parece o dialplan?


Vamos examinar alguns poucos exemplos, aqui:

Exemplo 1: Quando acontece de um Agente SIP chamar outro Agente SIP que estar registrado no mesmo servidor de registro.

Neste exemplo, a extensão(ramal) 1001 chama a 1006. Somos levados a olhar internamente pela extensão(ramal) e se estiver presente, seguiremos a função padrão PABX, e conecta a chamada.

Aqui no arquivo extensions.conf, está a lógica do dialplan usado para executar uma busca interna:

[lookuplocal]
exten ⇒ _XXXX,1,ChanIsAvail(SIP/${EXTEN}&IAX2/${EXTEN}|sj)
exten ⇒ _XXXX,2,Goto(incoming|${EXTEN}|2)
exten ⇒ _XXXX,3,Hangup
exten ⇒ _XXXX,102,Goto(lookupdundi|${EXTEN}|1)
exten ⇒ _XXXX,103,Hangup

Verificaremos se é a extensão (ramal) que discamos, 1006, está disponível no PABX local usando o comando "ChanIsAvail". Quando o canal está disponível, enviamos a chamada para o contexto [incoming] para procurar pela extensão(ramal) 1006, na prioridade 2. Se o canal não estiver disponível, enviaremos a chamada para o contexto [lookupdundi] prioridade 1.

Aqui está um pedaço da saída da CLI Asterisk:

regpbx1*CLI>
- - Executing Goto("SIP/1001-6c54", "lookuplocal|1006|1")
- - Goto (lookuplocal,1006,1)
- - Executing ChanIsAvail("SIP/1001-6c54", "SIP/1006&IAX2/1006|sj") in new stack
- - Executing Goto("SIP/1001-6c54", "incoming|1006|2") in new stack
- - Goto (incoming,1006,2)
- - Executing Answer("SIP/1001-6c54", "")
- - Executing Dial("SIP/1001-6c54", "Sip/1006|20|tr")
- - Called 1006
- - SIP/1006-88c4 is ringing
- - SIP/1006-88c4 is ringing
- - SIP/1006-88c4 answered SIP/1001-6c54
= = Spawn extension (incoming, 1006, 3) exited non-zero on 'SIP/1001-6c54'
regpbx1*CLI>



Exemplo 2: Um Agente SIP chama outro Agente SIP que está registrado em outro servidor de registro.

Neste exemplo, a extensão (ramal) 1001 chama a extensão (ramal) 1002. Vamos procurar internamente pela extensão (ramal) e se ela estiver presente, seguiremos a função padrão do PABX, e conecta a chamada. Mas, se a extensão(ramal) não estiver presente, executaremos uma consulta DUNDi dentro do cluster e conecta a chamada ao servidor apropriado que tem a extensão (ramal) 1002 registrada.

No arquivo extensions.conf, está a lógica do dialplan usada para fazer uma consulta DUNDi:

[lookupdundi]
exten ⇒ _X,1,Goto(${ARG1},1)
switch ⇒ DUNDi/priv
exten ⇒ i,1,Goto(lookupmysql,${INVALID_EXTEN},1)



A variável ${ARG1} é a extensão (ramal) do contexto anterior [lookuplocal], neste exemplo ela é 1002. Estamos usando a instrução switch para dizer ao DUNDi para procurar pela extensão(ramal) 1002 no mapeamento "priv" na recepção dos peers (servidores de registro) DUNDi. Lembre-se que todos os servidores de registro tem o contexto [sipregistration] mapeado para "priv" nos seus arquivos dundi.conf. Portanto, quando este pedido atinge o peer local procurando pela extensão 1002, que é o dunpbx1, o pedido atinge o servidor de consulta DUNDi e encaminha o pedido para os servidores registro restantes do cluster.

O Servidor de Registro número 2 responde ao servidor de consulta DUNDi com a informação de conexão, e essa é passada de volta ao servidor de registro número 1 para conectar a chamada. Se a consulta DUNDi retorna "extension not found", isso será considerado uma extensão (ramal) inválida dentro deste contexto [lookupdundi] e a chamada será passada ao manipulador de extensão inválida, então enviaremos a chamada ao contexto [lookupmysql] na extensão (ramal) 1002, na prioridade 1.

Aqui está um pedaço da saída da CLI Asterisk:

regpbx1*CLI>
- - Executing Goto("SIP/1001-2c5d", "lookuplocal|1002|1")
- - Goto (lookuplocal,1002,1)
- - Executing ChanIsAvail("SIP/1001-2c5d", "SIP/1002&IAX2/1002|sj") in new stack
- - Executing Goto("SIP/1001-2c5d", "lookupdundi|1002|1") in new stack
- - Goto (lookupdundi,1002,1)
- - Called priv:wqOGASylTGtBljFtvGjuCw@10.10.10.122/1002
- - Call accepted by 10.10.10.122 (format ulaw)
- - Format for call is ulaw
- - IAX2/10.10.10.122:4569-1 answered SIP/1001-2c5d
- - Hungup 'IAX2/10.10.10.122:4569-1'
= = Spawn extension (lookupdundi, 1002, 1) exited non-zero on 'SIP/1239-2c5d'
regpbx1*CLI>



Exemplo 3: Neste exemplo, a extensão 1001 chama a 1002. Mas vamos supor que o servidor de registro número 2 falhou apenas. Nós somos levados a olhar internamente para a extensão e se estiver presente, nós seguiremos a função padrão do PABX, e conecta a chamada. Mas se a extensão não estiver presente nós executaremos uma consulta DUNDi dentro do cluster e conecta a chamada ao servidor apropriado que tem a extensão 1002 registrada. Se DUNDi retorna "extension not found" então nós consultaremos o servidor MySQL se ele sabe como contatar o Agente SIP diretamente. Isso é possível porque o Asterisk RealTime Architecture puxa a informação de registro do Agente SIP na base de dados e quando um Agente SIP se registra a um PABX, o Asterisk então escreve a informação "fullcontact" de volta na base de dados para este Agente SIP. Nós podemos usar essa informação "fullcontact" para chamar o Agente SIP diretamente se estiver disponível.

Aqui no arquivo extensions.conf, está a lógica do dialplan usado para executar uma consulta ao MySQL:

[lookupmysql]
include ⇒ invalid
exten ⇒ _X.,1,MYSQL(Connect connid 10.10.10.110 asteriskdb password db)
exten ⇒ _X.,2,MYSQL(Query resultid ${connid} SELECT\ fullcontact\ from\ sip\ where\ name=${EXTEN})
exten ⇒ _X.,3,MYSQL(Fetch fetchid ${resultid} var1)
exten ⇒ _X.,4,MYSQL(Clear ${resultid})
exten ⇒ _X.,5,MYSQL(Disconnect ${connid})
exten ⇒ _X.,6,GotoIf($["${var1}" = ""]?invalid,i,1:${EXTEN},8)
exten ⇒ _X.,8,Set(direct=${var1:4})
exten ⇒ _X.,9,Dial(SIP/${direct},15,r)
exten ⇒ _X.,10,Goto(sendtovm,${EXTEN},1)
exten ⇒ _X.,11,Hangup



Aqui, primeiro precisamos nos conectar a base de dados MySQL com a informação correta de autenticação. Então, consultamos a tabela "sip" pelo campo da tabela "fullcontact" onde o nome é 1002. Nós pegamos esta informação, então apagamos o "resultid" e desconectamos do servidor MySQL.

Isso é Importante: Fazer a desconexão é necessário; você não pode deixar as conexões SQL abertas. As conexões não serão fechadas até que você desconecte ou restarte. A não desconexão eventualmente poderia atingir o limite de conexões do MySQL e não permitiria mais nenhuma conexão de consultas ou possivelmente crash.

Também usamos o comando "GotoIf". Vamos puxar os dados do campo "fullcontact" e colocamos esse dado em uma variável ${direct}, mas primeiro vamos extrair os 4 caracteres da frente do dado porque ele é pre-fixado com a string "sip:", então chamaremos o UA/SIP diretamente. Se não existe nenhum dado no campo "fullcontact", então o UA/SIP nunca se registrou com o cluster, assim enviaremos a chamada ao contexto [invalid] na prioridade 1. Já que estamos conectando o Agente SIP diretamente, não temos qualquer lógica associada no dialplan com a extensão que estamos chamando, assim somente tocaremos o tom de ring por 15 segundos, então enviamos a chamada ao contexto [sendtovm] na prioridade 1.

Aqui está um pedaço da saída da CLI Asterisk:

regpbx1*CLI>
- - Executing Goto("SIP/1001-3a46", "lookuplocal|1002|1")
- - Goto (lookuplocal,1002,1)
- - Executing ChanIsAvail("SIP/1001-3a46", "SIP/1002&IAX2/1002|sj") in new stack
- - Executing Goto("SIP/1001-3a46", "lookupdundi|1002|1") in new stack
- - Goto (lookupdundi,1002,1)
- - Sent into invalid extension '1002' in context 'lookupdundi' on SIP/1001-3a46
- - Executing Goto("SIP/1001-3a46", "lookupmysql|1002|1") in new stack
- - Goto (lookupmysql,1002,1)
- - Executing MYSQL("SIP/1001-3a46", "Connect connid 10.10.10.110 asteriskdb password db") in new stack
- - Executing MYSQL("SIP/1001-3a46", "Query resultid 1 SELECT fullcontact from sip where name=1002") in new stack
- - Executing MYSQL("SIP/1001-3a46", "Fetch fetchid 2 var1") in new stack Mar 29 18:29:47 WARNING[31837]: app_addon_sql_mysql.c:318 aMYSQL_fetch: ast_MYSQL_fetch: numFields=1
- - Executing MYSQL("SIP/1001-3a46", "Clear 2") in new stack
- - Executing MYSQL("SIP/1001-3a46", "Disconnect 1") in new stack
- - Executing GotoIf("SIP/1001-3a46", "0?invalid|i|1:1002|8") in new stack
- - Goto (lookupmysql,1002,8)
- - Executing Set("SIP/1001-3a46", "direct=1002@10.10.10.63:5060") in new stack
- - Executing Dial("SIP/1001-3a46", "SIP/1002@10.10.10.63:5060|15|r") in new stack
- - Called 1002@10.10.10.63:5060
- - SIP/10.10.10.63:5060-32f2 is ringing
- - SIP/10.10.10.63:5060-32f2 answered SIP/1001-3a46
- - Attempting native bridge of SIP/1001-3a46 and SIP/10.10.10.63:5060-32f2
= = Spawn extension (lookupmysql, 1002, 9) exited non-zero on 'SIP/1001-3a46'
regpbx1*CLI>

Por que não executamos um comando "ChanIsAvail" quando temos de discar para o Agente SIP diretamente. Alguns telefones, como os telefones da Cisco e os telefones da Polycom, aceitarão pedido de extensão entrante e ringa o telefone tão longo o telefone ainda pense que ele está registrado a um PABX. Então, quando o tempo de registro do telefone estiver definido em 5 minutos e o servidor de registro de repente torna-se indisponível com 4 min 59 seg do tempo restante do registro, então o telefone reconhecerá um pedido SIP como disponível e aceita uma discagem direta. Durante essa condição, janela máxima de 5 minutos, se você usa o comando "ChanIsAvail', o telefone vai dizer, "sim, Eu estou disponível, e envia a chamada".

Mas, se o servidor se tornar indisponível e expira o tempo de validade do registro, então o telefone vai entender que ele não está registrado e tira essa extensão fora do status de disponível, assim o comando "ChanIsAvail" vai obter uma negativa falsa e não tentará discar para o telefone, mas o telefone ainda está disponível para discagem direta mesmo que ele não esteja registrado.

É possível ter um Agente SIP registrado em mais de um servidor de registro. O que acontece quando um pedido DUNDi sai nesta situação é a chamada será completada ao primeiro que responder. Assim, se a extensão 1002 for registrada no servidor de registro número 1 e no servidor de registro número 2 e a extensão 1003, registrada no servidor de registro 3 chama a extensão 1002, então a chamada completará no primeiro servidor que responder ao pedido DUNDi.

Isso pode parecer a uma situação ideal, mas isso contém armadilhas, geralmente com funcionalidades de PABX como estacionamento de chamada. Idealmente, você deseja que todos os ramais dentro do mesmo office, pessoas que estariam estacionando chamadas e pedindo a outras para capturar, de estarem registradas ao mesmo PABX, do contrário uma situação poderia surgir onde a extensão 1001 registrada no servidor de registro número 2 estaciona uma chamada para a extensão 1002 que está no servidor de registro número 2. Para evitar isso, tenha cuidado com os servidores de registro de backup. Porque com o telefone Cisco, você pode escolher não ter um servidor de registro de backup, mas um servidor proxy de último recurso. O telefone não se registraria ao proxy de último recurso, mas passaria a chamadas saintes a ele. Se o servidor de registro falhar, o telefone pode ainda completar chamadas saintes e usando o contexto [lookupmysql] conforme observado no exemplo 3 acima, chamadas entrantes podem ainda serem completadas para o Agente SIP.

No diagrama 1, esbocei 2 segmentos Ethernet, 1 para as trocas de mensagens RealTme/ MySQL e outro para o tráfego de Voz/DUNDi. A razão é de escalabilidade e de segmentação do tráfego em ambientes mais controláveis. Muitas máquinas padrão servidor vem com 2 ou mais NIC´s, então o por quê de não usá-las. O MySQL e o RealTime é um ambiente muito conversador para operar e vários componentes no plano de discagem confiam nas respostas rápidas da base de dados MySQL. Quando o tráfego de voz é priorizado quando atravessa a rede de switches, o tráfego entre a base de dados pode ficar retido em buffers e o tempo de resposta ficar excessivamente estendido. No ambiente de realização de testes, buscas de 10ms é um tempo fantástico. Acrescentando 10.000 clientes ao cluster e você vai ficar rezando para essa bondade do tempo de busca, mas você nunca o veria. Você vai conseguir melhores tempos de respostas da base de dados quando implementando a segmentação da função RealTime/MySQL e das outras funções do PABX e de voz.

Se a rede é para abrigar um monte de usuários não constantes, sem associação, como os clientes residenciais, então o método roundrobin ou um método verdadeiramente inteligente de carga de servidor é implementado, então o balanceamento poderia ser arbitrário e corretamente encaminhado direto. Quando você tem 10 usuários na Companhia A, 50 usuários na companhia B, 25 usuários na Companhia C e 5 usuários na Companhia D, então tem mais sentido colocar a Companhia A, C e D em um servidor e a companhia B em outro servidor para ter alguma capacidade de fornecer funcionalidades de PABX complexas. No evento de quebra do Servidor B, os usuários ainda teriam chamadas entrando e saindo até que o outro servidor pudesse ser reconfigurado com o endereço IP do servidor B. Por essa razão e muitas outras, é que vários servidores hotstanby seriam implementados estrategicamente dentro do cluster.

Mais informação sobre configuração de Cluster Asterisk Com DUNDi pode ser visto nos links abaixo: http://www.voip-info.org/wiki/view/DUNDi+Enterprise+Configuration+SIP http://www.voip-info.org/wiki/view/DUNDi+Enterprise+Configuration+IAX http://www.voip-info.org/wiki/view/DUNDi+Enterprise+Configuration+SIP+with+no+passwords.