Encaminhamento via SIP de Chamadas E.164 no
fone@RNP: operação e atualização
Paulo Henrique de Aguiar Rodrigues
Abril de 2011
V 4.0
Este relatório apresenta a arquitetura para suporte ao encaminhamento via SIP de chamadas E.164
via SIP, bem como define a operação e cenários de migração para o novo ambiente.
RNP/REF/0204
Sumário
1. Histórico: Motivação para a migração para SIP.................................................................................. 3
2. A nova arquitetura centrada em SIP................................................................................................... 5
3. Princípios do Encaminhamento Nacional ........................................................................................... 8
4. Atualização da arquitetura ................................................................................................................ 10
5. Vantagens da operação com SIP para o serviço fone@RNP........................................................... 10
6. Pacotes para upgrade de versão da arquitetura............................................................................... 11
7. Exemplo de fluxo .............................................................................................................................. 15
Encaminhamento via SIP de Chamadas E.164 em SIP no fone@RNP: operação e atualização.
2
1.
Histórico: Motivação para a migração para SIP
O serviço fone@RNP operou, desde a sua criação até o final de 2007 com o encaminhamento de
chamadas a nível nacional pelo H.323, fazendo uso do DGKRNP. Uma instituição que fizesse parte do
serviço tinha que operar um gatekeeper H.323 (normalmente usando o software livre GnuGK) para
encaminhamento e recebimento de chamadas, ainda que a sua base de usuários fosse SIP.
A arquitetura aberta suportada e recomendada pelo serviço fone@RNP na época é mostrada na
Figura 1.
Figura1 – Ambiente H.323/SIP para o serviço fone@RNP até o final de 2007
As ambientes de software aberto utilizados na arquitetura da Figura 1 eram os seguintes:
o
o
H.323: Gatekeeper GnuGK
SIP: proxy SIP OpenSER, Mediaproxy
o
o
GW de voz e GW H.323/SIP: Asterisk
Banco de dados SQL: PosgreSQL
o
o
Autenticação Radius: FreeRadius
Diretório LDAP: OpenLDAP
Na arquitetura da Figura 1, o gateway de voz que se conectava ao PBX operava com H.323,
recebendo e enviando as chamadas nas quais havia a participação do PBX via H.323. Assim,
chamadas originadas de outras instituições e destinadas ao PBX da instituição local (podendo
eventualmente ser um destino na RTFC do código de área local) eram encaminhadas pelo DGK
Encaminhamento via SIP de Chamadas E.164 em SIP no fone@RNP: operação e atualização.
3
usando a sinalização H.323. Caso o destino fosse um cliente registrado no proxy SIP institucional, a
chamada teria que passar pelo Asterisk local, que funcionava como gateway H.323/SIP.
O Asterisk como gateway H.323/SIP foi avaliado em termos de desempenho e mostrou instabilidade
no canal oh323 quando o número de chamadas excedeu 37. O atraso inserido pelo gateway nas
condições de teste foi da ordem de 61 ms, sem conversão de codecs. Com conversão de codecs, o
atraso tendeu a piorar. O Asterisk local estava sendo utilizado com o canal oh323, por este canal
permitir correlacionar os CDRs do lado SIP com os CDRs do lado H.323. A alternativa ao canal oh323
seria o canal ooh323, mas este último precisaria de ampla modificação no código para possibilitar a
correlação entre os dois ambientes, essencial para a geração de CDRs consolidados.
As versões mais recentes do Asterisk são 1.4.x. Foram testadas as versões 1.4.0 e 1.4.1. Nessas
versões, o canal oh323 não é mais suportado, além de ser um desenvolvimento de terceiros. A
alternativa seria o uso do novo canal h323 nativo, presente nas versões mais atuais. Todavia, este
canal não funcionou corretamente nestas versões testadas.
Pelos fatores expostos, as versões que continuam a ser utilizadas no Asterisk, quando necessário o
suporte a H.323, são as versões 1.2.x com uso do oh323, com os inconvenientes de atraso e
instabilidade já mencionados.
Quando no cenário da Figura 1, dois clientes SIP de diferentes instituições estabelecem uma
chamada, essa chamada passa por dois gateways H.323/SIP, o que acrescenta mais de 120 ms de
atraso adicional, prejudicando a interatividade, e, possivelmente, comprometendo a qualidade da
ligação fim a fim. Quando um cliente SIP de uma instituição tem sua chamada encaminhada para o
PBX de outra instituição, a chamada passa também por dois gateways, um gateway H.323/SIP (do
lado do originador da chamada) e por um gateway H.323/E1 do lado do destinatário da chamada.
Cabe observar que o uso do Asterisk como gateway de voz somente com SIP não apresenta
quaisquer dos problemas relacionados ao H.323. O SIP no Asterisk nas versões mais atuais é estável,
robusto e testado com atrasos extremamente baixos (11 ms) com 60 ligações simultâneas. Testes de
terceiros demonstram que o canal SIP do Asterisk suporta facilmente mais de 120 ligações
simultâneas, sem um limite claro.
Como a maioria das instituições está implantando internamente apenas SIP, a tendência será de que
se tenha a maioria das chamadas sendo originadas em SIP e destinadas também a clientes SIP,
principalmente se os gateways de voz institucionais operarem com SIP.
Encaminhamento via SIP de Chamadas E.164 em SIP no fone@RNP: operação e atualização.
4
2.
A nova arquitetura centrada em SIP
Visando atender ao processo evolutivo do serviço fone@RNP em direção a SIP, o serviço fone@RNP
migrou para a nova estrutura mostrada na Figura 2.
Na Figura 2, observa-se a inclusão do DSER (com uso ENUM e DNS privado) e do gateway
H.323/SIP Asterisk no ambiente nacional, além do já existente DGK. As setas pontilhadas em verde
indicam as interações de sinalização SIP entre os vários equipamentos.
Como pode ser observado na Figura 2, um proxy SIP interage com o DSER e com o Asterisk nacional,
bem como com os outros proxies SIP, que façam parte do serviço. Todos esses elementos são
parceiros (“peers”) ou vizinhos e podem estabelecer sinalização direta entre si.
A FUNÇÃO DO DSER
Na arquitetura da Figura 2, o DSER opera como proxy de sinalização para chamadas originadas dos
proxies SIP e do gateway H.323/SIP Nacional. Sempre que o DSER recebe um INVITE oriundo de um
dispositivo confiável, ele consulta o DNS privado com ENUM para descobrir os proxies ou gateways
que podem receber a chamada.
DSER
DNS
NAPTR
SLONY
vizinhos
prefixos
SLONY
vizinhos
prefixos
CS
I C O IP P H ON E
790 2S ER IE S
1
2
ABC
4
5
Gateway
H.323/SIP
Proxy SIP
“OpenSER”
GHI
7
JK L
6
M NO
7
8
9
PQ RS
T U V
WX Y Z
*
0
#
Gateway
H.323/SIP
Gateway
H.323/SIP
3
DE
F
4
Proxy SIP
“OpenSER”
CS
I C O IP P H ON E
790 2S ER IE S
1
2
ABC
3
DE
F
P
Q
R
S
4
5
6
4
GHI
JK L
M NO
*
7
7
8
9
PQ RS
T U V
W X YZ
*
0
#
P
Q
R
S
*
Cliente A
DNS
SRV
Cliente B
PABX
DNS
SRV
DGK
Gateway
VoIP/RTFC
Gateway
VoIP/RTFC
Gatekeeper
Gatekeeper
PABX
Instituição A
Instituição B
Figura 2 – Ambiente nacional para encaminhamento de chamadas via SIP para o serviço fone@RNP
Na ambiente nacional, existe uma base de dados onde os prefixos e códigos de áreas completados
pelas instituições são anunciados. Estes prefixos e códigos de área se referem aos números VoIP, do
PBX, linhas privadas ou prefixos da telefonia pública. Uma instituição pode anunciar prefixos em mais
de um código de área, sendo uma decisão interna da própria instituição quais prefixos são ou não
Encaminhamento via SIP de Chamadas E.164 em SIP no fone@RNP: operação e atualização.
5
anunciados. Todavia, ao se anunciar um determinado prefixo ou grupo de prefixos, a instituição tem
que se comprometer a completar as chamadas destinadas a estes prefixos.
Todos os anúncios no ambiente nacional são guardados em um banco de dados mestre, que
armazena também todas as características operacionais das instituições. Para maiores informações
sobre as características armazenadas, favor consultar Documentação Técnica fone@RNP:
Homologação de instituições do fone@RNP com encaminhamento nacional via SIP.
PRIORIDADE PARA ENCAMINHAMENTO DE CHAMADAS
Em grandes centros, existe a tendência de a RNP operar seus próprios gateways com a rede de
telefonia pública, garantindo diretamente a qualidade do serviço fone@RNP. Embora nestes centros
possam existir instituições que também completem chamadas para a rede pública de telefonia, estas
instituições normalmente só deveriam receber chamadas do ambiente nacional em segunda
prioridade, sendo os gateways da RNP usados em primeira instância. Em outros centros em que a
RNP não dispõe de gateway de presença, as chamadas para a rede de telefonia pública são
completadas pelas próprias instituições locais que fazem parte do serviço, se assim desejarem.
Mesmo nestes casos, algumas instituições podem ter maior e melhor capacidade para completar as
chamadas, sendo interessante que as chamadas sejam encaminhadas de forma prioritária. Para
atender a priorização, os prefixos anunciados na base de dados nacional são acompanhados de um
valor inteiro positivo, sendo 1 o mais prioritário. Normalmente, a prioridade 1 está associada à RNP.
Quando uma instituição tem que encaminhar uma chamada destinada a outro código de área com
mais de um proxy destino disponível para completamento, uma primitiva INVITE (do SIP) é enviada
pelo proxy de origem ao DSER. Após receber o INVITE, o DSER retorna um REDIRECT para o
originador, indicando os possíveis proxies de destino, com o valor de prioridade associado. As
tentativas de completar a chamada serão feitas de forma seqüencial, seguindo a ordem de prioridade.
Quando dois ou mais destinos estiverem relacionados numa mesma prioridade, eles serão acionados
em paralelo e o primeiro a confirmar receberá a chamada.
Esse papel centralizado do DSER pode facilitar, no futuro, o uso de esquemas de balanceamento de
chamadas mais sofisticados, se necessário. Podem ser utilizadas variações de métrica que levam em
conta outros fatores como prioridade, custo, ocupação dos gateways e duração de chamadas externas
já completadas por uma instituição num determinado período. Essa versatilidade possibilitada pelo
balanceamento centralizado de chamadas depende apenas da manutenção no DSER de informações
atualizadas das instituições. Procedimentos já estão implementados nos gateways Asterisk do
ambiente fone@RNP para que, sempre que uma chamada for estabelecida ou completada, a métrica
que relaciona a capacidade do gateway e os números de chamadas internas e externas em
andamento seja computada em tempo real, através de scripts AGI.
O DSER opera como proxy de sinalização, tanto para as chamadas encaminhadas pelos proxies SIP
como para as chamadas encaminhadas pelo gateway H.323/SIP nacional. Assim, ao receber um
INVITE vindo do gateway H.323/SIP, o DSER retorna o REDIRECT. Importante observar que o canal
SIP do gateway Asterisk não implementa a tentativa de chamar os possíveis destinos
seqüencialmente e/ou paralelamente, efetuando a chamada apenas para a primeira opção.
Chamadas internacionais são realizadas através de um Proxy SIP ou através de Proxy H.323
configurados para receber e encaminhar chamadas SIP ou H.323 externas ao serviço fone@RNP. O
Encaminhamento via SIP de Chamadas E.164 em SIP no fone@RNP: operação e atualização.
6
Proxy SIP externo consulta um banco de dados para identificar qual o tipo de tratamento deve ser
dado para as chamadas oriundas da rede externa. Se a rede externa não possuir um convênio de
serviço com a RNP, então as chamadas somente serão completadas para números internos ao
serviço fone@RNP, bloqueando o completamento das chamadas para a rede pública de telefonia. O
tráfego vindo de redes desconhecidas será aceito no serviço fone@RNP, porém sofrerá a mesma
política de tráfego de rede sem convênio.
No Proxy H.323 externo, todo tráfego recebido de redes conhecidas conveniadas ou não terão
permissão apenas para destinos internos ao serviço fone@RNP, devido a dificuldades em
desenvolver uma programação similar à implementada para SIP.
O PAPEL DO DGK H.323
Na nova arquitetura, o DGK opera como proxy de sinalização H.225 e H.245, sendo configurado como
parceiro do proxy H.323 externo. Somente, excepcionalemnte e em caráter experimental.algum GK
institucional será configurado como parceiro do DGK H.323, visto que o serviço fone@RNP desativou
o encaminhamento nacional via H.323 a patrir de dezembro de 2009.
A TABELA DE VIZINHOS
O banco de dados na RNP está organizado em tabelas mestres que podem ser replicadas e suas
cópias mantidas sincronizadas. A tabela de vizinhos ocupa um papel fundamental na operação do
serviço. Essa tabela é mantida pela RNP e a replicação é feita com uso do software SLONY. Toda
atualização da tabela mestre, como a inserção de uma nova instituição no serviço fone@RNP ou
alteração de instituição já operacional, é repassada para as cópias nas instituições.
Em cada instituição, ao receber uma chamada (primitiva INVITE), o Proxy SIP acessa a tabela de
vizinhos para verificar se a chamada é originada de alguma instituição do serviço fone@RNP. A tabela
de vizinhos contém as associações de um proxy SIP com os prefixos e linhas privadas pelos quais ele
responde. Algumas outras informações pertinentes, como os endereços IPs dos proxies, são também
mantidas nessa tabela.
A tabela de vizinhos é consultada pelo proxy SIP para validar os INVITES que chegam de instituições
do serviço fone@RNP e para descobrir se os destinos de chamadas são co-localizados no mesmo
código de área. Quando o destino é co-localizado, a chamada é enviada diretamente ao proxy de
destino, sem uso do DSER. A tabela de vizinhos é também consultada na consolidação de CDRs,
quando os IPs dos proxies e prefixos alocados permitem identificar a origem e o destino de uma
chamada, possibilitando preencher corretamente os campos do CDR consolidado respectivo.
Para a sinalização SIP, a introdução da tabela de vizinhos torna completamente transparente a
inserção de uma nova instituição no serviço quando já existem outras instituições já operando no
mesmo código de área da nova instituição (chamadas co-localizadas).
A tabela de vizinhos tem também um papel fundamental na atualização de ambiente e na instalação
inicial de uma nova instituição. Para maiores informações, consulte a documentação sobre a
homologação e a reconfiguração de instituições no serviço fone@RNP.
Encaminhamento via SIP de Chamadas E.164 em SIP no fone@RNP: operação e atualização.
7
3.
Princípios do Encaminhamento Nacional
O encaminhamento nacional a partir de dezembro de 2009 está sendo feito exclusivamente por meio
da sinalização SIP, apesar das instituições ligadas ao serviço fone@RNP poderem, internamente,
operar com SIP ou H.323. A operação interna com H.323 é transparente ao serviço fone@RNP e cabe
às instituições a manutenção de gateway interno para conversão para SIP.
Uma instituição participante tem seus prefixos anunciados no DSER e opera com o encaminhamento
nacional via SIP. Assim, se chamadas forem originadas no ambiente H.323 local, elas deverão ser
encaminhadas ao proxy SIP instituciona via gateway H.323/SIP local. O Proxy SIP fará o tratamento
da chamada, decidindo se é destinada ao PBX (sendo repassada ao gateway de voz), se destinada à
cliente IP local, se destinada a uma instituição co-localizada ou se destinada a outro código de área.
Se a chamada for destinada a uma instituição co-localizada, a tabela de vizinhos indicará o proxy SIP
de destino. Nesse caso, a chamada será repassada diretamente ao proxy SIP de destino, sem
necessidade de consulta ao DSER. Procura-se, com esse procedimento, executar rapidamente um
encaminhamento de chamada para destinos em área geográfica próxima.
Caso uma chamada for destinada a um prefixo que somente uma instituição esteja habilitada a
completá-la, a chamada será repassada ao Proxy SIP da instituição diretamente, similar ao
encaminhamento para uma instituição co-localizada.
Se a chamada for destinada a outro código de área e exista mais de uma instituição habilitada a
completá-la, a chamada será encaminhada ao DSER. Caberá ao DSER identificar os possíveis
proxies de destino com consulta via ENUM ao DNS privado. Se a consulta retornar mais de uma
opção de proxy de destino, um REDIRECT será retornado ao proxy remetente, identificando os
proxies de destino e a prioridade de cada um. Os destinos são consultados seqüencialmente em
ordem de prioridade, sendo que destinos de igual prioridade são consultados em paralelo, recebendo
a chamada o destino que enviar a aceitação primeiro ao proxy de origem. Se a consulta à tabela de
vizinhos retornar apenas um proxy de destino, então a chamada será encaminhada diretamente para
esse proxy.
Caso não seja encontrado nenhum destino possível na base local da instituição que realiza a
chamada, a mesma será repassada ao DSER. Caso o destino não seja alcançável pelo serviço
(inexistência de anúncio no banco de dados mestre), a chamada será cancelada.
Na nova arquitetura, somente são repassadas ao gateway H.323/SIP nacional as chamadas
destinadas a redes H.323 externas. Convém aqui salientar que os destinos H.323 externos ao serviço
fone@RNP estão sendo também anunciados no banco mestre.
PROCESSAMENTO DE CHAMADAS ORIGINADAS DO GATEWAY DE VOZ (ORIGEM NO SISTEMA
TELEFÔNICO: PBX OU EM OPERADORA DIRETAMENTE CONECTADA AO GATEWAY DE VOZ)
Se a instituição possuir clientes tanto SIP como H.323, indicando que temos um gateway H.323/SIP e
um GK local, o gateway de voz poderia estar operando tanto com SIP como com H.323. Caso o
gateway de voz estivesse operando com H.323, esta conectividade permitiria que chamadas de
clientes H.323 fossem encaminhadas ao PBX sem passar pelo gateway H.323/SIP local, o que
reduziria o atraso e contribuiria para a qualidade dessas ligações. Todavia, a operação dos canais
Encaminhamento via SIP de Chamadas E.164 em SIP no fone@RNP: operação e atualização.
8
H.323 do Asterisk possui restrições e, por questões de estabilidade, confiabilidade e disponibilidade,
recomenda-se a operação preferencial do gateway de voz Asterisk apenas com SIP.
Supondo o gateway de voz registrado nos dois ambientes, quando uma chamada vinda do PBX for
recebida pelo gateway de voz, este a analisará e recomenda-se que tome as seguintes decisões:
o
Se a chamada for destinada a um número de telefone IP da própria instituição, o número
pode estar registrado, usando um cliente SIP ou H.323. Supondo que o uso preferencial na
instituição seja SIP (afinal a instituição opera apenas com o DSER), o gateway de voz deverá
enviar o pedido de estabelecimento da chamada inicialmente ao SIP. Se o destino não
estiver registrado no SIP, deverá ser retornado um erro e o gateway de voz deverá enviar o
pedido de estabelecimento de chamada ao GK. Se o destino estiver de fato registrado como
um cliente H.323, a chamada será completada, caso contrário, o telefone IP não está
registrado, e a chamada será cancelada.
o
Se o destino da chamada for outra instituição, o gateway de voz deverá encaminhar a
chamada ao proxy SIP, que a processará normalmente, como já indicado acima.
Se o gateway de voz estiver apenas registrado no SIP, como o esperado na arquitetura de referência
do serviço fazendo uso do software Asterisk, o comportamento padrão é encaminhar via gateway
H.323/SIP para o GK caso o destino local não esteja registrado no SIP. Caso também não haja
registro no GK, o comportamento padrão é sempre repassar ao gateway H.323/SIP quando o destino
não for encontrado no H.323. O retorno da chamada ao proxy SIP será detectado como um erro
(destino inexistente) e a chamada será cancelada.
TRÁFEGO SIP DE ORIGEM EXTERNA AO SERVIÇO FONE@RNP
INVITES de origem desconhecida recebidos – a origem não está na tabela de internacional e não faz
parte do serviço fone@RNP – devem ser encaminhados com a inserção de 1 de marcação de
chamada de origem externa se destinados ao PBX local, a números IP ou a linhas privadas da própria
instituição. Se o destino não for local à instituição, então a chamada deve ser cancelada, ainda que
destinada à outra instituição do serviço fone@RNP. A configuração do proxy SIP local na instituição
deverá garantir este comportamento. Embora não haja impedimento técnico para que um INVITE de
origem externa e destinado a outra instituição do serviço fone@RNP seja processado como um
INVITE qualquer, optou-se por não permitir que uma instituição qualquer do serviço possa ser porta de
entrada de tráfego VoIP para outros destinos.
A troca de tráfego SIP com outras redes deve ser realizada preferencialmente através do proxy SIP
externo configurado para recebimento exclusivo de chamadas SIP externas (nacionais ou
internacionais). Este proxy pode dar tratamento diferenciado a cada rede com base em SLA (acordo
de serviço).
Encaminhamento via SIP de Chamadas E.164 em SIP no fone@RNP: operação e atualização.
9
4.
Atualização da arquitetura
A arquitetura do serviço vem sendo constantemente atualizada com novas versões dos pacotes de
instalação, incorporando melhorias e novas facilidades, como é o caso da função de mapeamento de
números, bastante útil para a habilitação de telefones IP com numeração do PBX em substituição a
ramais analógicos convencionais. Normalmente, o processo de migração é semelhante a uma nova
instalação, com a atualização de todo o ambiente. Instituições que tenham configurações especiais
como integração com diretórios corporativos LDAP ou outras, devem procurar analisar bem estas
configurações para sua adaptação ao novo ambiente. O processo de migração de uma instituição não
padrão é único e o quadro técnico da instituição deve sempre estar preparado para operação de
recuperação em caso de falha do novo ambiente e necessidade de retorno ao ambiente original.
5.
Vantagens da operação com SIP para o serviço fone@RNP
Será sintetizado a seguir alguns pontos extremamente favoráveis à adoção preferencial de SIP tanto
pelas instituições como pelo encaminhamento nacional de chamadas E.164.
Do ponto de vista das instituições:
o
O desempenho da arquitetura VoIP institucional com a adoção de gateways de voz Asterisk
com sinalização SIP traz os benefícios de estabilidade do software frente a grandes números
de chamadas ativas simultaneamente e dos atrasos mínimos envolvidos;
o
Para a sinalização SIP, o uso da tabela de vizinhos no proxy SIP torna completamente
transparente a inserção de outras instituições no serviço no mesmo código de área (colocalizadas). Nenhuma reprogramação é necessária. Como algumas instituições possuem
um número muito grande de linhas privadas, a inserção destas instituições como colocalizadas dentro da arquitetura ocorre de maneira trasnparente e imediata.
o
o
O uso de SIP internamente se alinha com as tendências maiores do mercado em suporte a
este protocolo;
Extrema facilidade de programação associada ao mundo SIP, trazendo flexibilidade,
simplicidade para inovação e maior capacidade de integração ao mundo Web, o que
favorece o aparecimento de novos serviços e flexibilidade de gerência e configuração;
o
Os produtos abertos para o mundo SIP, como os softphones, possuem uma interface com o
usuário mais elaborada e com maior apelo. Atualmente, a oferta de produtos SIP é muito
maior que para H.323, favorecendo preços mais baixos;
o
A estabilidade de soluções de PBX IP aliada à queda de preços dos equipamentos VoIP
favorece a migração de soluções de telefonia convencional para a telefonia IP.
Do ponto de vista do serviço fone@RNP:
Encaminhamento via SIP de Chamadas E.164 em SIP no fone@RNP: operação e atualização.
10
o
O uso de SIP no encaminhamento de chamadas E.164, pelas facilidades de programação
que o ambiente SIP apresenta para o estabelecimento e encaminhamento de chamadas,
usufrui de uma implementação simples de mecanismos de balanceamento centralizado.;
o
Com a sinalização SIP, o processo de entrada de co-localizadas é transparente com o uso
da tabela de vizinhos e ocorre de forma automática, sem a necessidade de alteração ou de
inserção manual de regras de reescrita. Alterações de configuração manuais podem deixar
de ser feitas ou podem ser realizadas com erro. O anúncio incorreto de uma co-localizada
pode levar ao completamento de chamadas para o destino co-localizado via rede pública de
telefonia, onerando desnecessariamente os custos de telefonia. O encaminhamento via SIP
com consulta a banco de dados traz uma redução significativa da carga gerencial, técnica e
administrativa gerada pelo serviço fone@RNP;
o
Como a sinalização SIP já foi concebida para uso normal de DNS e alias para os usuários,
além de incorporar facilidades para convivência com NAT/Firewalls, o SIP facilita a gerência
e configuração do serviço;
o
Como a tabela de vizinhos é parte do ambiente SIP e mantida completamente atualizada e
como as informações nesta tabela são essenciais para a geração de CDRs consolidados, o
uso do SIP é uma garantia completa de que o processo de geração de estatísticas será
correto e preciso.
6.
Pacotes para upgrade de versão da arquitetura
Para que haja a atualização para novas versões de pacotes de software foram criados pacotes e
scripts de instalação que facilitam enormemente a atualização/reconfiguração de uma instituição já
operacional ou a ativação de uma nova instituição.
Os pacotes atuais foram desenvolvidos para a distribuição Linux Debian “Etch” 4.0. Um primeiro
objetivo dos pacotes é facilitar a atualização do ambiente, o que é feito de forma extremamente
simples. Um segundo objetivo é o uso de Debian estável em toda a arquitetura recomendada pela
RNP para operação no serviço fone@RNP com software livre. A opção pelo Debian é uma questão de
preferência, mas que pode mudar no futuro em favor de outra distribuição de Linux.
No processo de instalação, é assumido que duas máquinas estão disponíveis somente com o Debian
instalado. A estrutura a ser implantada segue a seguinte estrutura de serviços:
o
Máquina 1 hospedando OpenSER, Asterisk (GW H.323/SIP), GnuGK, MediaProxy e Radius
client.-ng.
o
Máquina 2 hospedando Asterisk (GW PBX), PostgreSQL, Slony, Apache, FreeRadius,
OpenLDAP e Slony.
Os pacotes atuais suportam as seguintes versões de software:
o
Ambiente nacional
openser 1.1.0
pwlib-Mimas_patch2
Encaminhamento via SIP de Chamadas E.164 em SIP no fone@RNP: operação e atualização.
11
openh323-Mimas_patch2
gnugk 2.2.6
postgres 8.1
asterisk-1.2.17
asterisk-oh323-0.7.3
asterisk-ooh323-0.5
slon 1.2.1
bind 9.3.4
o
Ambiente da instituição
Asterisk 1.2.17-labvoip (versão alterada pelo LabVoIP)
Asterisk 1.4.11-labvoip (versão alterada pelo LabVoIP)
Asterisk-oh323 0.7.3-labvoip (versão alterada pelo LabVoIP)
Asterisk-perl 0.10
FreeRADIUS 1.1.6-labvoip (versão alterada pelo LabVoIP)
GnuGK 2.2.6
libmfcr2 0.0.3.1.4
libpri 1.4.7
libsupertone 0.0.2
libunicall 0.0.3.1.4
mediaproxy 1.8.2
OpenLDAP 2.3.32
OpenSER 1.2.0-notls
radiusclient-ng 0.5.2
spandsp 0.0.3
Zaptel 1.4.12
fejeca 0.1.0 (ferramenta de gerência desenvolvida pelo LabVoIP)
Consolida 0.0.4 e Estatística 0.0.3 (softwares utilizados nas estatísticas desenvolvidos
pelo LabVoIP)
O script de consolidação de CDR faz parte do pacote e roda na máquina 2. Para criação inicial de
usuários no LDAP, existe a ferramenta Fejeca, que é disponibilizada como parte do pacote de
instalação.
Foi elaborado um script de instalação que consulta as informações fornecidas previamente pela
instituição e que foram inseridas no banco de dados mestre. São utilizadas as seguintes premissas:
o
Sempre será instalado o ambiente SIP e o encaminhamento nacional via SIP estará
habilitado;
o
O ambiente H.323 local é opcional. Na definição, será especificado se este ambiente será
instalado. A resposta deve ser sim caso a instituição queira suportar clientes H.323. Essa
informação será usada de forma automática na instalação dos pacotes, a partir das
informações da base da RNP.
o
Para o gateway de voz conectado a ramais analógicos, é assumido que será instalada pelo
menos uma placa 4xFXO, sendo que serão definidos, na configuração, quais ramais
operarão como IVR interno (para uso dos ramais do PBX) e quais trabalharão com IVR
externo (podendo receber chamadas externas). Os números de ramais associados a cada
uma das portas FXO e os números de grupo fazem também parte das informações
previamente acordadas com a RNP.
o
Para um gateway de voz conectado a uma placa E1, é suposto que temos apenas uma
placa e um tipo de sinalização (R2 ou ISDN). Parte dos 30 canais disponíveis pode estar
alocada a IVR interno e a outra parte a IVR externo. Esta é uma questão de acerto de
configuração com o PBX. Os números de grupo (ou ramal chave) dos IVRs são também
Encaminhamento via SIP de Chamadas E.164 em SIP no fone@RNP: operação e atualização.
12
configuráveis no PBX. Estas informações precisam constar da base de dados acordada com
a RNP.
Durante a execução do script de instalação, o banco de dados da RNP que contém as informações
previamente acordadas com a instituição antes de sua entrada em serviço é consultado. O banco
contém toda a informação necessária para as configurações de instalação, exceto as informações de
segurança, referentes a senhas locais, que são solicitadas pelo script de instalação em tempo real. A
informação envolvida é referenciada a seguir:
o
Informações constantes do banco da RNP
TABELA INSTITUIÇÕES
• Campo “pk” (integer)
– Identificação única para a instituição
• Campo “nome” (char)
– Sigla da instituição
• Campo “ativo” (boolean)
– Informa se a instituição está ativa
• Campo “responsavel” (char)
– Nome do responsavel da instituição
• Campo “email” (char)
– E-mail do responsável da instituição
• Campo ddd (char)
– Código de área
• Campo “dominio” (char)
– REALM voip da instituição
• Campo “encaminhamento_sip” (boolean)
– Descreve se a instituição faz encaminhamento SIP:
• True -> Faz SIP ; False -> Não faz SIP
• Campo “encaminhamento_h323” (boolean)
– Descreve se a instituição faz encaminhamento H.323:
• True -> Faz H.323 ; False -> Não faz H.323
• Campo “encaminhamento_pstn” (boolean)
– Descreve se a instituição faz encaminhamento H.323:
• True -> Faz encaminhamento para a PSTN ; False -> Não faz
encaminhamento para a PSTN
• Campo “h323_interno” (boolean)
– Descreve se instituição usa H.323 internamente
• True -> H.323 é usado internamente; False -> H.323 não é usado
internamente
• Campo “versão” (integer)
– Descreve versão do sistema:
• 1 -> primeira versão ; 2 -> versão atutal
• Campo “interface_pabx” (char)
– Descreve qual interface utilizada para conexão com o PABX
• R2, ISDN ou FXO
TABELA EQUIPAMENTOS
• Campo “id” (integer)
– Identificação única para o equipamento
• Campo “pk” (integer)
– Identifica a que instituição este equipamento corresponde
• Campo “ip” (inet):
– Endereço IP do equipamento
• Campo “tipo” (integer [ 0 | 1 ] )
– Identifica tipo de equipamento
• 1 para Proxy
• 0 para Gateway
• Campo “descrição” (char)
– Comentário sobre o equipamento
Encaminhamento via SIP de Chamadas E.164 em SIP no fone@RNP: operação e atualização.
13
TABELA PREFIXOS
• Campo “id” (integer):
– Identificação única do prefixo
• Campo “pk” (integer):
– Identifica a que instituição este prefixo corresponde
• Campo “tipo” (integer [ 0 | 1 | 2 ] )
– Identifica tipo de prefixo:
– 2 para Prefixo da linha privada (Podendo ser o número inteiro)
– 1 para Prefixo do PABX (Institucional)
– 0 para Prefixo ip (fone@RNP)
• Campo “ddd” (char)
– DDD desta instituição
• Campo “prefixo” (char)
– Prefixo desta instituição (sem ddd)
TABELA NUMERO_IVR
• Campo “id” (integer):
– Identificação única do prefixo
• Campo “pk” (integer):
– Identifica a que instituição este prefixo corresponde
• Campo “numero” (char)
– Identifica tipo de número IVR:
– 2 para Prefixo da linha privada (Podendo ser o número inteiro)
– 1 para Prefixo do PABX (Institucional)
– 0 para Prefixo ip (fone@RNP)
• Campo “numero” (char)
– Número IVR desta instituição
As informações do banco de dados da RNP são imprescindíveis para a entrada em operação de uma
instituição no serviço fone@RNP. As duas tabelas acima têm que ser preenchidas como parte
preliminar do processo de entrada da nova instituição no serviço fone@RNP. Além disso, as
informações sobre os ramais e números de grupo associados às interfaces analógicas (FXO) e digitais
(E1 R2 ou E1 ISDN) são imprescindíveis para os processos de homologação e auditagem da RNP.
o
Informação de segurança solicitada pelo script de instalação
Senha do LDAP
Segredo do servidor RADIUS
Senha do usuário radius na base de dados
Senha do usuário asterisk na base de dados
Senha do usuário openser na base de dados
Senha do usuário postgres, administrador da base de dados
o
Informação sobre os campos do LDAP existentes na máquina 1 das instituições
uid
cn
userPassword
mail
alias
carLicense
employeeType
callforward
responsável
Nome do usuário
Caminho na árvore LDAP deste usuário
Senha utilizada para um usuário se registrar no OPenSER
E-mail deste usuário
Telefone IP deste usuário
Documento de identificação do usuário
Tipo do usuário na instituição
Número para encaminhamento de chamadas (não implementado ainda)
Nome de um responsável da conta
creditos-periodo
créditos
ipaddress
validade
categoria
H323passwd
Quantidade de créditos utilizados períodicamente no campo créditos
Créditos para ser utilizados em ligações com a PSTN
Limitar o IP que pode se autenticar (Não implementado ainda)
Validade da conta do usuário
Classificação do usuário utilizado para definir quantidade de créditos
Senha para autenticação do usuário no GNUGK
Encaminhamento via SIP de Chamadas E.164 em SIP no fone@RNP: operação e atualização.
14
7.
Exemplo de fluxo
No exemplo a seguir, as linhas pontilhadas representam o caminho da sinalização e as linhas cheias a
rota da mídia de voz, numa comunicação típica entre clientes SIP de duas instituições pertnecentes ao
serviço fone@RNP.
O originador da chamada é o cliente A. O OpenSER originador repassará o INVITE da chamada ao
DSER, que retornará o REDIRECT indicando o proxy destino. Os canais de mídia são então
estabelecidos diretamente entre os clientes SIP, passando pelos proxies de origem e de destino que
operam como proxies de sinalização.
DSER
DNS
NAPTR
mídia
SLONY
pares
prefixos
C ISC O IP PHON E
79 02 SER IE S
1
2
ABC
4
5
GHI
J KL
6
M NO
7
8
9
T UV
WX Y Z
Gateway
H.323/SIP
Gateway
H.323/SIP
3
D E
F
PQ R S
SLONY
pares
prefixos
Gateway
H.323/SIP
Proxy SIP
“OpenSER”
4
7
Proxy SIP
“OpenSER”
C ISC O IP PHON E
79 02 SE RIE S
1
2
ABC
3
DE
F
P
R
Q
S
4
5
6
4
*
0
GH I
#
JK L
M NO
*
7
Q
P
Gateway
VoIP/RTFC
Cliente A
DNS
SRV
8
9
TU V
WX Y Z
*
0
#
DNS
SRV
DGK
Gateway
VoIP/RTFC
7
P QR S
SR
*
Cliente B
C IS C O IP P HON E
7 902 S ER IE S
PABX
1
2
A BC
Gatekeeper
Gatekeeper
4
7
4
5
G HI
J KL
3
DE
F
6
MN O
7
8
9
P Q RS
TU V
W X YZ
*
0
#
Q
SP
R
*
Cliente B
Instituição A
PABX
Instituição B
Figura 3 – Estabelecimento de chamadas entre proxies SIP via DSER
Caso a chamada fosse, na realidade, destinada ao PBX na instituição B, então a mídia seguiria até o
Asterisk operando como gateway de voz, que completaria a chamada para o PBX. Como o Asterisk
opera com atraso bem baixo, a chamada não seria afetada em sua qualidade ao passar por este
elemento adicional.
Por outro lado, o destino da chamada na instituição B pode ser um cliente H.323. Nesse caso, a
chamada passará pelo gateway H.323/SIP local.
Se as duas instituições suportam clientes nos dois tipos de sinalização, então se espera que o
gateway de voz se registre nos dois ambientes.
Encaminhamento via SIP de Chamadas E.164 em SIP no fone@RNP: operação e atualização.
15