Guia básico de VoIP com Asterisk

De MediaWiki do Campus São José
(Redirecionado de Guia prático de Asterisk)
Ir para: navegação, pesquisa

As Redes

Hoje, VoIP é considerado um dos pilares para a convergência das tecnologias de informação e comunicação.

Antes de mais nada, é preciso entender que havia dois tipos bem distintos de rede pública até o começo da década de 1990:

  • Rede de telefonia (PSTN);
  • Rede de computadores (Internet).

A rede de telefonia se baseava em serviços dedicados com meios de transmissão determinísticos; ou seja, havia sempre um meio de transmissão apto a transmitir a informação desejada. No caso, a voz até o cliente final. Isso era conseguido graças à capilarização das redes com o mínimo de compartilhamentos desses recursos. Com isso, tem-se um cenário ideal para a rede baseada em circuitos.

Algo inverso ao que acontece nas redes de computadores, onde é natural a disputa pelo recurso: o meio de transmissão. Isso acontece não só nas redes locais - onde é natural a formação da rede em árvore - mas também na Internet. Não bastasse isso, vários serviços distribuídos em rede favorecem um meio altamente competitivo, por isso a rede ser baseada em pacotes.

O que acontece quando se insere um serviço altamente sensível ao tempo em uma rede baseada em pacotes?

VoIP: o que é?

Voz sobre IP pode agrega, portanto, várias áreas de estudo de redes de telefonia e de computadores, uma vez que tem-se um panorama bastante inóspito para a transmissão de voz em tempo real, transmissão esta fragmentada em pacotes.

Dentre as várias áreas, cabe destacar:

  • tecnologias/protocolos de sinalização.
  • tecnologias/protocolos para descrever quais os tipos de mídia suportados em cada ponta da comunicação.
  • tecnologias/protocolos para transmissão das mídias em ambos os sentidos.
  • tecnologias/protocolos para garantir a qualidade do serviço (QoS).

Enquanto que os três primeiros estão mais ligados às pontas da comunicação, geralmente dois usuários finais, é no último item, qualidade de serviço, que reside hoje o grande problema de implementação de VoIP em escala.[1]

Sinalização

A sinalização, termo emprestado das redes de telefonia (e veremos que há muitos outros), é um protocolo utilizado para controlar as ligações entre os elementos da rede - entendendo elemento como um telefone ou uma central telefônica - desde o estabelecimento da chamada até a finalização dessa. No caso de VoIP, o termo sinalização acaba se estendendo um pouco mais, já que abrange também a localização do usuário - pela combinação endereço VoIP + endereço IP. Diferente da telefonia, um usuário pode modificar ser número na rede, o endereço IP, sem modificar a sua identificação na rede VoIP.

O termo portabilidade, portanto, ganha uma matiz diferente nesse meio.

Uma vez que é possível esse tipo de deslocamento, torna-se imprescindível o uso de ferramentas de localização do usuário, bem como a descrição dos tipos de mídia que podem ser suportados, já que o usuário pode estar conectado à rede por meio de um computador ou um telefone com recursos mais limitados.

Exemplos de protocolos de sinalização: H.225.0 e SIP.

SIP

O SIP, Session Initiation Protocol, é um protocolo aberto, tendo como principais características a facilidade de uso e de adequação a vários cenários possíveis (mais detalhes), uma vez que é fortemente inspirado nos protocolos SMTP e HTTP. Em todos estes protocolos, algumas semelhanças que cabem elencar:

  • Baseados em mensagens de texto.
  • Baseados em requisições e respostas entre os agentes, podendo criar sessões.
  • Entidades intermediárias podem atuar como proxy para localizar elementos na rede.
  • Os endereços de localização são construídos segundo um padrão (hoje) muito comum: o URI.

Tais diálogos entre cliente e servidor atuam, portanto, como ações que disparam o estabelecimento ou encerramento de ligações, bem como localizar os nós na rede e verificar a sua qualidade de transmissão de mídias. Ou seja, cuidam do estabelecimento e encerramento de sessões, para transmissão de mídia, com certas garantias de um bom funcionamento - uma vez que a Internet e seus protocolos principais não suprem essa demanda.

Apropriando-se um pouco mais do vocabulário descrito no protocolo, vamos apresentar as entidades possíveis em um cenário SIP:

  • User agent client (UAC): é o cliente que gera as requisições. Um exemplo é o softphone.
  • User agent server (UAS): servidor, que atende às requisições e procura encaminhá-las ao seu destino corretamente. Os servidores são classificados em:
    • Registrar: recebe as requisições de registro (autenticação e localização de um UAC) para, com essa informação, poder localizar os usuários na Internet.
    • Proxy: atua como elemento intermediário nas requisição, atuando portanto como UAC e UAS ao mesmo tempo (em sentidos diferentes). Procura auxiliar na comunicação entre UACs e UASs. Pode participar em todo o diálogo e inclusive como intermediário de toda a transmissão de mídia.
    • Redirect: ao invés do servidor tipo Proxy, ele apenas (re)encaminha para outro servidor que tratará da requisição. Ou seja, participa apenas em uma pequena fração do diálogo.

Os diálogos, ou métodos, elementares são:

  • REGISTER: requisição para informar a um UAS a localização de um usuário. É o registro de um UAC, por exemplo, e que será usado, posteriormente, pelo servidor de localização para poder redirecionar as chamadas para o endereço (IP) de destino correto.
  • INVITE: convite para iniciar uma sessão, como por exemplo de transmissão de mídia de voz.
  • ACK: confirmação a uma requisição ao agente de origem.
  • BYE: uma vez estabelecida a sessão, é com o método BYE que a sessão é encerrada por um dos agentes envolvidos neste sessão (seja UAC ou UAS).
  • CANCEL: o CANCEL, diferente do BYE, server para cancelar o processo de estabelecimento da chamada. Ou seja, é disparado para cancelar alguma requisição INVITE ainda não atendida.
  • OPTIONS: é uma consulta ao agente para listar as suas funcionalidades, como por exemplo codecs suportados, tipos de conteúdo (voz, vídeo, etc.). Pode ser usado, pela sua flexibilidade, para manter uma sessão ativa - e evitar problemas com filtros de pacotes, firewalls, etc.

Uma vez que já sabemos os tipos de agentes, e quais são os métodos disponíveis para a comunicação, podemos entender como as respostas são processadas. Para cada método, deve haver sempre que possível uma resposta remota (UACs e UASs que participam da sessão). E, para facilitar, as respostas foram organizadas em classes, em ordem crescente de gravidade:

  • 1xx: informação provisória. Serve para manter o agente informado do estado da sessão.
  • 2xx: sucesso. A requisição foi bem atendida.
  • 3xx: redirecionamento. (Re)encaminha o pedido para outro destino, que cuidará da requisição.
  • 4xx: falha no cliente. A requisição foi mal formada ou não pôde ser atendida pelo servidor (formato inadequado).
  • 5xx: falha no servidor. A requisição, aparentemente bem construída, não foi atendida pelo servidor.
  • 6xx: falha global. é uma falha grave, onde nenhum servidor pôde atender a requisição.

A seguir, um exemplo de requisição INVITE do de maria para joao, requisição esta realizada com sucesso, conforme pode-se perceber nas respostas de class 2xx (200 OK):

INVITE sip:joao@192.168.2.109 SIP/2.0
Date: Tue, 17 Mar 2009 23:38:32 GMT
CSeq: 1 INVITE
Via: SIP/2.0/UDP 192.168.2.9:5070;branch=z9hG4bK149a4a65-ba11-de11-980e-001ec91e7e37;rport
User-Agent: Ekiga/2.0.12
From: "Aluno do IFSC" <sip:maria@192.168.2.109>;tag=6ce34965-ba11-de11-980e-001ec91e7e37
Call-ID: bae04965-ba11-de11-980e-001ec91e7e37@M9
To: <sip:joao@192.168.2.109>
Contact: <sip:maria@192.168.2.9:5061;transport=udp>
Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE
Content-Type: application/sdp
Content-Length: 385
Max-Forwards: 70
v=0
o=- 1237333112 1237333112 IN IP4 192.168.2.9
s=Opal SIP Session
c=IN IP4 192.168.2.9
t=0 0
m=audio 5034 RTP/AVP 96 3 107 110 0 8 101
a=rtpmap:96 SPEEX/16000
a=rtpmap:3 GSM/8000
a=rtpmap:107 MS-GSM/8000
a=rtpmap:110 SPEEX/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
m=video 5036 RTP/AVP 31
a=rtpmap:31 H261/90000
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.2.9:5070;branch=z9hG4bKee964b65-ba11-de11-980e-001ec91e7e37;received=192.168.2.9;rport=5070
From: "Aluno do IFSC" <sip:maria@192.168.2.109>;tag=6ce34965-ba11-de11-980e-001ec91e7e37
To: <sip:joao@192.168.2.109>
Call-ID: bae04965-ba11-de11-980e-001ec91e7e37@M9
CSeq: 2 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Contact: <sip:joao@192.168.2.109>
Content-Length: 0
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 192.168.2.9:5070;branch=z9hG4bKee964b65-ba11-de11-980e-001ec91e7e37;received=192.168.2.9;rport=5070
From: "Aluno do IFSC" <sip:maria@192.168.2.109>;tag=6ce34965-ba11-de11-980e-001ec91e7e37
To: <sip:joao@192.168.2.109>;tag=as5e2f6338
Call-ID: bae04965-ba11-de11-980e-001ec91e7e37@M9
CSeq: 2 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Contact: <sip:joao@192.168.2.109>
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.2.9:5070;branch=z9hG4bKee964b65-ba11-de11-980e-001ec91e7e37;received=192.168.2.9;rport=5070
From: "Aluno do IFSC" <sip:maria@192.168.2.109>;tag=6ce34965-ba11-de11-980e-001ec91e7e37
To: <sip:joao@192.168.2.109>;tag=as5e2f6338
Call-ID: bae04965-ba11-de11-980e-001ec91e7e37@M9
CSeq: 2 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Contact: <sip:joao@192.168.2.109>
Content-Type: application/sdp
Content-Length: 287
v=0
o=root 3432 3432 IN IP4 192.168.2.109
s=session
c=IN IP4 192.168.2.109
t=0 0
m=audio 13372 RTP/AVP 3 0 8 101
a=rtpmap:3 GSM/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv

E, para finalizar a sessão, ou a ligação, o uso do método BYE:

BYE sip:joao@192.168.2.109 SIP/2.0
CSeq: 4 BYE
Via: SIP/2.0/UDP 192.168.2.9:5070;branch=z9hG4bK8a4c7869-ba11-de11-980e-001ec91e7e37;rport
From: "Aluno do IFSC" <sip:maria@192.168.2.109>;tag=6ce34965-ba11-de11-980e-001ec91e7e37
Call-ID: bae04965-ba11-de11-980e-001ec91e7e37@M9
To: <sip:joao@192.168.2.109>;tag=as5e2f6338
Contact: <sip:maria@192.168.2.9:5061;transport=udp>
Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE
Content-Length: 0
Max-Forwards: 70
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.2.9:5070;branch=z9hG4bK8a4c7869-ba11-de11-980e-001ec91e7e37;received=192.168.2.9;rport=5070
From: "Aluno do IFSC" <sip:maria@192.168.2.109>;tag=6ce34965-ba11-de11-980e-001ec91e7e37
To: <sip:joao@192.168.2.109>;tag=as5e2f6338
Call-ID: bae04965-ba11-de11-980e-001ec91e7e37@M9
CSeq: 4 BYE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Contact: <sip:joao@192.168.2.109>
Content-Length: 0

Os pacotes de mídia, portanto, encontram-se esses dois diálogos. Como o SIP trata apenas da sinalização, o protocolo não trata o transporte da(s) mídia(s).

Descrição de Mídia

Apesar de ser um elemento opcional em VoIP, tem-se tornado cada vez mais clara a sua relevância, dada a portabilidade que o VoIP proporciona. Entretanto, embora isso possa representar um avanço, pois o leque de opções de mídia a serem transmitidas é maior (codecs, compactação de voz, etc.), tem-se aí mais um fator a ponderar no uso de VoIP: cada usuário pode fornecer uma lista de mídia suportadas distinta.

As centrais telefônicas, portanto, devem/podem prover mais esta funcionalidade: alinhar as mídias em cada segmento da comunicação. Quando não for possível compatibilizar diretamente (usando um mesmo codec, por exemplo), a central deverá/poderá converter uma das mídias para permitir o fluxo sem problemas. Entram aí as conversões de codec, que podem cosumir consideravelmente os recursos computacionais.

Significa, portanto, que VoIP acarreta outro problema: como equalizar o uso de recursos de rede com os recursos computacionais? VoIP traz um cenário diferenciado para um problema antigo, que era resolvido com o uso de redes poucos disputadas pelos serviços que ali rodavam.

A solução vem dos dois mundos, de redes e de computadores, em entender como a voz pode ser compactada e fragmentada, transmitida por um meio não adequado e chegar ao destino com qualidade aceitável. No que tange à descrição de mídia, o favorecimento de melhores codecs é um ponto a mais para isso - e melhores codecs são aqueles que, dentro de um cenário específico, mostram-se mais indicados para equilibrar a relação rede (latência, perda de pacotes e outros) X processamento (concorrência do processador, uso de threads, etc.).

Como exemplo de protocolo de descrição de mídia, tem-se o SDP.

Transmissão de Mídia

Uma vez escolhido formato de mídia mais adequado para cada situação - e sentido (uma ligação é uma transmissão bidirecional) - cabe a um terceiro protocolo realizar, de fato, a transmissão da mesma. Este processo envolve, basicamente, a garantia de que tal transmissão respeitará ao máximo a ideia do tempo real, já que os tempos de latência nas redes de computadores são altamente variáveis (dia, hora, segundo).

Isso significa desde estabelecer uma cadência na saída dos pacotes, com o correspondente reajuste na chegada, até descartar pacotes ou mesmo inviabilizar a ligação por causa da má qualidade da transmissão.

O RTP é um exemplo de protocolo de transmissão de mídia, devidamente acompanhado pelo seu protocolo auxiliar de controle, RTCP - descrito na mesma RFC.

Qualidade de Serviço

Sabendo que a transmissão da mídia, em geral, não engloba prover qualidade ao serviço, mas sim garantir um melhor esforço, há um quarto elemento nas redes VoIP dedicado exclusivamente para isso. Um dos motivos mais óbvios é que a qualidade de serviço depende não só das pontas envolvidas na comunicação, mas sobretudo no meio do caminho, entre os diversos roteadores, entre as trocas de operadoras, entre as qualidades de serviço.

Qualidade de serviço, portanto, é extremamente importante e deve, sempre que possível, estar associado ao serviço de VoIP, garantindo a qualidade do serviço de fato em todos os pontos de estrangulamento das redes de computadores (leia-se roteadores e tecnologias de acesso).

VoIP: Como implementar

Os primeiros passos para adentrar neste admirável mundo novo são relativamente simples - se comparado às décadas anteriores. Contudo, deve-se sempre ter em mente que VoIP é um tema em franca expansão de estudos e sistemas, e isso significa melhoria contínua e bastante dedicação para fazer de VoIP um serviço aceitável.

Para fins de estudo, cabe destacar o livro do Sérgio Colcher (disponível na Biblioteca do IF-SC - campus São José), bem como plataformas/sistemas que implementam a maior parte da teoria relacionada ao tema:

  • Asterisk: bastante documentado e com comunidade ativa. Um bom livro introdutório é do Jim Meggelen[2].
  • OpenSIPS: servidor SIP para implementações de grande porte.
  • FreeSWITCH: projeto alternativo ao Asterisk, vem ganhando destaque à sua estabilidade em operação e integração com várias linguagens de programação.

Alguns softphones (clientes VoIP)

Asterisk: um bom começo

O software é um dos mais populares devido à sua facilidade em criar e expandir funções relacionadas a um PBX tradicional. Isso, aliado ao seu baixo custo (inclusive quando comparado àquele equipamento), permitem um cenário favorável a um estudo mais sério. Contudo, como já fora falado, ele requer dedicação e leitura para o seu bom funcionamento com estabilidade e qualidade aceitável. Não há milagres em VoIP, embora os ditos profetas digam o contrário...

O Asterisk foi concebido - e é recomendado - sobre o GNU/Linux, porém hoje ele suporta da grande maioria de variantes UNIX até sistemas Windows. Por uma questão de tradição, manteremos a instalação em sistemas GNU/Linux, e utilizaremos o Ubuntu versão 9.04 como exemplo. Neste sistema, a instalação de programas é bastante simplificada utilizando a ferramenta apt-get.

Como super-usuário do sistema (root), digite:

# apt-get install asterisk

A ferramenta, associada ao instalador de pacotes dpkg, vai instalar os arquivos básicos do soft PBX nos diretórios do sistema operacional. Um deles, /etc/, utilizado para armazenar arquivos de configuração, vai ter um subdiretório, /etc/asterisk, cujo conteúdo serão os vários arquivos de configuração do Asterisk.

Primeiro contato

O Asterisk tem um console de visualização e administração dos recursos. Auxilia principalmente para monitorar chamadas e identificar/corrigir erros.

Para entrar no console (ainda como root):

# asterisk -r

ou seu equivalente:

# rasterisk

Inspirado em alguns consoles de Linux, a composição de teclas <TAB>+<TAB>, dentro do console do Asterisk, mostrará uma lista de comandos disponíveis na instalação corrente. Assim: ao digitar:

> dialp<TAB><TAB>

ele completará com o comando ou mostrará uma lista de opções. Queremos chegar, de fato, ao comando:

> dialplan show

que mostra o plano de numeração completo do PBX. Outro comando bastante útil:

> sip show peers

que mostra os canais SIP. E, também:

> core show channels

que apresenta os canais em uso. Lembrando que uma ligação entre dois UACs envolve dois canais...

Configuração

Alguns arquivos são importantes de serem vistos num primeiro contato com a ferramenta. Por uma questão didática, cabe destacar:

  • sip.conf: arquivo de configuração dos canais SIP. Nele, há configurações globais, que se aplicam a todos os canais, bem como a personalização de cada um deles. O formato da maioria dos arquivos é relativamente simples: uma palavra em colchetes define uma seção do arquivo, como [general]. Abaixo, opções ou atributos referentes à seção, e tudo que se encontra após ponto-e-vírgula é mero comentário - ignorado pelo Asterisk.
  • extensions.conf: arquivo de configuração do plano de numeração, o que o torna um dos arquivos mais importantes do sistema. Assim como sip.conf, também possui uma seção global, que se aplica a todos os contextos. Em seguida, a definição mais específica dos contextos (mencionados anteriormente pelos canais como em sip.conf), através das chamadas extensões, que definem origem e/ou destino e a ação a ser tomada.


Abaixo, um exemplo bastante resumido do arquivos:

sip.conf

; sip.conf: define os canais SIP
;
;
; Seção geral: de aplica a todos os canais
[general]
bindport=5060 ; porta utilizada pelo serviço

; Primeiro canal: João
[joao]
type=friend ; pode efetuar e receber chamadas
username=joao ; o nome do usuário
host=dynamic ; pode conectar-se a partir de qualquer endereço IP
insecure=port,invite ; a segurança está associada ao registro do canal (primeiro passo),
                     ; assim como acontece em sessões Web
context=soLigaParaLocal ; o contexto padrão do João. O arquivo extensions.conf o definirá
allow=gsm ; habilita este codec para o João. Os vários codecs serão vistos em seguida,
          ; já que cada um deles tem suas particularidades.
allow=alaw ; outro codec
allow=ulaw ; mais um codec
qualify=yes; mostra a qualidade, em ms, da conexão entre UAC e UAS.

; Outro canal: maria
[maria]
type=friend
username=maria
secret=ultrasecreta ; maria, ao invés de João, tem uma senha secreta para o registro.
host=dynamic
insecure=port,invite
context=soLigaParaLocal
allow=gsm
allow=alaw
allow=ulaw
qualify=yes

extensions.conf

; extensions.conf: define o plano de numeração
;
;
; Seção global, aplicável a todas as seções deste arquivo
[general]

; Seção de variáveis globais, se houver.
[globals]
E_UM=Zap/0 ; definido o tronco E1 como sendo a interface Zap/0, nome dado a uma das portas de
           ; uma placa Digium.

; Contexto definido para João e Maria: seu plano específico de numeração
[soLigaParaLocal]
exten => _2XXXXXXX,1,Dial(E_UM) ; ligação local saindo pela interface E1
exten => _3XXXXXXX,1,Dial(E_UM) ; idem 
exten => _8XXXXXXX,1,Dial(khomp/bl0) ; as ligações para celular sairão pela placa GSM da Khomp
                                     ; ao invés de Digium
exten => _9XXXXXXX,1,Dial(khomp/bl0) ; idem
exten => 101,1,Dial(SIP/joao) ; ligando para 101, é enviado um INVITE para João (toca o seu telefone)
exten => joao,1,Dial(SIP/joao) ; números ou nomes são possíveis para o endereço de destino em SIP
exten => 102,1,Dial(SIP/maria)
exten => maria,1,Dial(SIP/maria)

Dúvidas no entendimento? O Asterisk insere alguns conceitos próprios ou adaptados em sua configuração, como contexto e extensão. Para este caso, mais uma vez a recomendação do livro do Meggelen.

Relações entre os arquivos

Abaixo, um exemplo de ligação entre dois canais SIP para auxiliar a compreensão.

Cenário: joao, que está definido no contexto soLigaParaLocal, quer ligar para maria:

  • Verifica-se a permissão da operação: o contexto dita as regras. No caso, a última linha do contexto soLigaParaLocal permite a ligação para o destino SIP/maria. Etapas 1 e 2.
  • Verifica-se a possibilidade com os recursos disponíveis: o sistema analisará se há condições propícias para processar a ligação, canais livres, processamento, possíveis custos envolvidos X crédito disponível, entre outros. Etapa 3.

<graphviz> digraph Asterisk {

 splines=true
 subgraph clusterSIP
 {
   label="sip.conf"
   bgcolor="#EEEEEE"
   SIPjoao [shape=Mrecord,label="<0>joao|<1>...|<2>context=soLigaParaLocal|<3>..."]
   SIPmaria [shape=Mrecord,label="<0>maria|<1>...|<2>context=soLigaParaLocal|<3>..."]
 }
 subgraph clusterExtensions
 {
   label="extensions.conf"
   bgcolor="#EEEEEE"
   subgraph clusterContexto
   {
     label=Contextos
     bgcolor="#DDDDDD"
     soLigaParaLocal [shape=Mrecord,label="<0>soLigaParaLocal|<1>Origens|<2>Destinos"]
     subgraph clusterExtensoes
     {
       label=Extensões
       bgcolor="#CCCCCC"
       EXTmaria [shape=Mrecord,label="<0>maria|<1>Ação 1: Discar para o canal SIP/maria"]
     }
   }
 }
 SIPjoao:2 -> soLigaParaLocal:0 [label="1",color=blue,fontcolor=blue]
 soLigaParaLocal:2 -> EXTmaria:0 [label="2",color=blue,fontcolor=blue]
 EXTmaria:1 -> SIPmaria:0 [label="3",color=blue,fontcolor=blue]

} </graphviz>

Aplicando as modificações

Uma vez modificados os conteúdos dos arquivos, podemos, com isso, retornar ao console do Asterisk e aplicar as modificações, com:

> reload

que irá recarregar TODOS os arquivos de configuração. Ou, de forma mais discreta:

> sip reload
> dialplan reload

para canais SIP e plano de numeração, respectivamente - na mesma ordem em que os arquivos foram apresentados acima, a título de exemplo.

Monitoramento do ambiente

Para monitorar o bom funcionamento do sistema, pode-se depurar a sinalização SIP para um canal específico (no exemplo abaixo, o canal SIP/joao):

> sip set debug joao

No caso da ligação entre joao e maria, todas as mensagens SIP serão apresentadas na tela. Além disso, pode-se também acompanhar a sequência de operações realizadas em um bloco do plano de numeração:

> core set verbose 20

Como por exemplo as etapas da extensão maria do contexto soLigaParaLocal.


Referências

  1. COLCHER, S. et. al. VoIP: Voz sobre IP. 1ª ed. Elsevier. 2005. ISBN 85-352-1787-8.
  2. Jim Van Meggelen et. al.; Asterisk: The Future of the Telephony; 2ª edição; O'Reilly; 2007. ISBN 0-596-51048-9.