| (12 revisões intermediárias por 3 usuários não estão sendo mostradas) | |||
| Linha 128: | Linha 128: | ||
'''Um arquivo de configuração de zona possui: estruturas de registros de Começo de Autoridade (SOA), responsáveis por delegar o papel do servidor DNS na rede; registros de espaços de nome (NS), responsáveis por listar os nomes de servidores da zona; e registros diversos, área destinada ao registro de dados referente aos hosts da zona.''' | '''Um arquivo de configuração de zona possui: estruturas de registros de Começo de Autoridade (SOA), responsáveis por delegar o papel do servidor DNS na rede; registros de espaços de nome (NS), responsáveis por listar os nomes de servidores da zona; e registros diversos, área destinada ao registro de dados referente aos hosts da zona.''' | ||
'''Os registros de recursos diversos possuem informações de mapeamento entre nomes e endereços IP, denominados “A”; entre endereços IP e nomes, denominados “PTR”; e entre pseudônimos e nomes, denominados “CNAME”.''' | '''Os registros de recursos diversos possuem informações de mapeamento entre nomes e endereços IP, denominados “A”; entre endereços IP e nomes, denominados “PTR”; e entre pseudônimos e nomes, denominados “CNAME”. Veja um arquivo de configuração típico''' | ||
<pre> | |||
TTL 86400 | |||
e164.br. IN SOA ns.e164.br. ( | |||
2011051911 ; Numero serial, baseado na data | |||
21600 ; atualizar em 6 horas | |||
3600 ; tentar novamente após 1 hota | |||
604800 ; expirar depois de 1 semana | |||
86400 ) ; TTL minima de 1 dia | |||
) | |||
e164.br. 43200 IN NS ns.e164.br. | |||
; | |||
ns.e164.br. 43200 IN A 192.168.1.2 | |||
8.7.6.5.4.3.2.1.4.3.5.5.e164.br. NAPTR 10 100 "u" "E2U+sip" "!^.*$!sip:voiptalkers@intervoip.br!". | |||
1.3.3.3.5.5.2.3.4.3.5.5.e164.br. NAPTR 10 101 "u" "E2U+h323" "!^.*$!h323:nonfreevoip@intervoip.br!". | |||
</pre> | |||
'''O padrão DNS especifica um algoritmo abstrato chamado Sistema de Descobrimento Dinâmico de Delegação (DDDS), responsável por fazer associações em tempo real de strings com sistemas delegados. A associação em tempo real permite carregar sistemas delegados que mudam constantemente ao longo do tempo como status de mensagens instantâneas, status de conta VoIP, entre outros. Este algoritmo será o elemento principal da centralizadora peering, permitindo que o servidor DNS seja capaz de resolver nomes de domínio a partir de strings passadas no momento do DNS lookup.''' | '''O padrão DNS especifica um algoritmo abstrato chamado Sistema de Descobrimento Dinâmico de Delegação (DDDS), responsável por fazer associações em tempo real de strings com sistemas delegados. A associação em tempo real permite carregar sistemas delegados que mudam constantemente ao longo do tempo como status de mensagens instantâneas, status de conta VoIP, entre outros. Este algoritmo será o elemento principal da centralizadora peering, permitindo que o servidor DNS seja capaz de resolver nomes de domínio a partir de strings passadas no momento do DNS lookup.''' | ||
| Linha 146: | Linha 163: | ||
'''Após a conversão do número E.164 em um nome de domínio efetua-se uma requisição de busca nos registros de recurso do servidor DNS. O padrão ENUM grava as informações de URI referentes ao pseudônimo em um tipo especial de registro de recurso chamado NAPTR.''' | '''Após a conversão do número E.164 em um nome de domínio efetua-se uma requisição de busca nos registros de recurso do servidor DNS. O padrão ENUM grava as informações de URI referentes ao pseudônimo em um tipo especial de registro de recurso chamado NAPTR.''' | ||
'''O registro NAPTR | '''O NAPTR, tem a função de encontrar caminhos de se contatar determinado assinante através do registro em DNS que este assinante possui. A entrada do protocolo NAPTR é a saída da etapa 2 da conversão de E.164 para URI. Suas tomadas de decisões são baseadas de acordo com 6 campos principais de configuração:''' | ||
#'''Ordem: classifica qual a prioridade que um registro NAPTR referente a certo domínio tem em relação aos outros registros NAPTR do mesmo. Exemplo:caso o usuário possua uma conta SIP, um e-mail, um IM e uma conta H323, o campo classifica a ordem de prioridade com o qual o usuário será contatado quando for efetuada uma requisição de busca pelo pseudônimo referente ao seu número E.164.''' | #'''Ordem: classifica qual a prioridade que um registro NAPTR referente a certo domínio tem em relação aos outros registros NAPTR do mesmo. Exemplo:caso o usuário possua uma conta SIP, um e-mail, um IM e uma conta H323, o campo classifica a ordem de prioridade com o qual o usuário será contatado quando for efetuada uma requisição de busca pelo pseudônimo referente ao seu número E.164.''' | ||
#'''Preferência: configura qual a conta de preferência ao qual o usuário será contatado. Essa propriedade permitirá configurar a ordem de prioridade de uma conta VoIP caso o usuário possua mais de uma. Exemplo: caso dois ou mais registros NAPTR do usuário possua mesma ordem, classifica qual registro será retornado quando uma requisição de busca for efetuada.''' | #'''Preferência: configura qual a conta de preferência ao qual o usuário será contatado. Essa propriedade permitirá configurar a ordem de prioridade de uma conta VoIP caso o usuário possua mais de uma. Exemplo: caso dois ou mais registros NAPTR do usuário possua mesma ordem, classifica qual registro será retornado quando uma requisição de busca for efetuada.''' | ||
| Linha 155: | Linha 173: | ||
'''O resultado é um registro de recurso parecido com o abaixo de acordo com os padrões definidos pela RFC 3403[7]:''' | '''O resultado é um registro de recurso parecido com o abaixo de acordo com os padrões definidos pela RFC 3403[7]:''' | ||
<pre> | |||
$ORIGIN 8.7.6.5.4.3.2.1.4.3.5.5.e164. | |||
IN NAPTR 10 10 "u" "sip+E2U" "!^.*$!sip:voiptalkers@intervoip.br!" . | |||
IN NAPTR 102 10 "u" "mailto+E2U" "!^.*$!mailto:mailtalkers@intervoip.br!" . | |||
IN NAPTR 103 10 "u" "tel+E2U" "!^.*$!tel:+553412345678!" . | |||
</pre> | |||
Nos arquivos de configuração do BIND, o registro seria representado da seguinte forma: | |||
<pre> | |||
8.7.6.5.4.3.2.1.4.3.5.5.e164. NAPTR 10 10 "u" "sip+E2U" "!^.*$!sip:voiptalkers@intervoip.br!" . | |||
8.7.6.5.4.3.2.1.4.3.5.5.e164. NAPTR 102 10 "u" "mailto+E2U" "!^.*$!mailto:mailtalkers@intervoip.br!" . | |||
8.7.6.5.4.3.2.1.4.3.5.5.e164. NAPTR 103 10 "u" "tel+E2U" "!^.*$!tel:+553412345678!" . | |||
</pre> | |||
'''A requisição de busca exemplificada na linha de código acima resultará | '''A requisição de busca exemplificada na linha de código acima resultará preferencialmente pela conta SIP “voiptalkers@intervoip.br”, seguido pelo endereço de email e o número telefônico.''' | ||
==Os Módulos de Software== | ==Os Módulos de Software== | ||
| Linha 178: | Linha 207: | ||
Atualmente (Maio de 2011), sabe-se que a aplicação ENUM do algoritmo DDDS é suportada pelos principais servidores de sip proxy, gateways SIP e SIP ''softphones''. Entre eles as soluções que mais se destacam são: ''SIP express router'' (SER), Kamailio, ''Open Sip Server''(OpenSIPS) como servidores proxy; Asterisk e Swyx como gateways e Ekiga como ''softphone''. | Atualmente (Maio de 2011), sabe-se que a aplicação ENUM do algoritmo DDDS é suportada pelos principais servidores de sip proxy, gateways SIP e SIP ''softphones''. Entre eles as soluções que mais se destacam são: ''SIP express router'' (SER), Kamailio, ''Open Sip Server''(OpenSIPS) como servidores proxy; Asterisk e Swyx como gateways e Ekiga como ''softphone''. | ||
A tabela 1 mostra um comparativo entre as principais soluções de servidores SIP encontradas no mercado. | A tabela 1 mostra um comparativo entre as principais soluções de servidores SIP encontradas no mercado e que poderão ser utilizadas para a validação da arquitetura proposta. | ||
{| style="border-spacing:0;" | {| style="border-spacing:0;" | ||
| | | | style="border-top:0.018cm solid #00000a;border-bottom:0.018cm solid #00000a;border-left:none;border-right:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.191cm;padding-right:0.191cm;"| | ||
| | '''Asterisk''' | | style="border-top:0.018cm solid #00000a;border-bottom:0.018cm solid #00000a;border-left:none;border-right:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.191cm;padding-right:0.191cm;"| <center>'''Asterisk'''</center> | ||
| | '''Kamailio''' | | style="border-top:0.018cm solid #00000a;border-bottom:0.018cm solid #00000a;border-left:none;border-right:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.191cm;padding-right:0.191cm;"| <center>'''Kamailio'''</center> | ||
| | '''OpenSips''' | | style="border-top:0.018cm solid #00000a;border-bottom:0.018cm solid #00000a;border-left:none;border-right:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.191cm;padding-right:0.191cm;"| <center>'''OpenSips'''</center> | ||
| | '''Sip Express Router''' | | style="border-top:0.018cm solid #00000a;border-bottom:0.018cm solid #00000a;border-left:none;border-right:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.191cm;padding-right:0.191cm;"| <center>'''Sip Express Router'''</center> | ||
|- | |- | ||
|| Servidor de registro | | style="border-top:0.018cm solid #00000a;border-bottom:0.018cm solid #00000a;border-left:none;border-right:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.191cm;padding-right:0.191cm;"| Servidor de registro | ||
|| Sim | | style="border-top:0.018cm solid #00000a;border-bottom:0.018cm solid #00000a;border-left:none;border-right:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.191cm;padding-right:0.191cm;"| <center>Sim</center> | ||
|| Sim | | style="border-top:0.018cm solid #00000a;border-bottom:0.018cm solid #00000a;border-left:none;border-right:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.191cm;padding-right:0.191cm;"| <center>Sim</center> | ||
|| Sim | | style="border-top:0.018cm solid #00000a;border-bottom:0.018cm solid #00000a;border-left:none;border-right:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.191cm;padding-right:0.191cm;"| <center>Sim</center> | ||
|| Sim | | style="border-top:0.018cm solid #00000a;border-bottom:0.018cm solid #00000a;border-left:none;border-right:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.191cm;padding-right:0.191cm;"| <center>Sim</center> | ||
|- | |- | ||
|| Servidor de Localização | | style="border-top:0.018cm solid #00000a;border-bottom:0.018cm solid #00000a;border-left:none;border-right:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.191cm;padding-right:0.191cm;"| Servidor de Localização | ||
|| Sim | | style="border-top:0.018cm solid #00000a;border-bottom:0.018cm solid #00000a;border-left:none;border-right:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.191cm;padding-right:0.191cm;"| <center>Sim</center> | ||
|| Sim | | style="border-top:0.018cm solid #00000a;border-bottom:0.018cm solid #00000a;border-left:none;border-right:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.191cm;padding-right:0.191cm;"| <center>Sim</center> | ||
|| Sim | | style="border-top:0.018cm solid #00000a;border-bottom:0.018cm solid #00000a;border-left:none;border-right:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.191cm;padding-right:0.191cm;"| <center>Sim</center> | ||
|| sim | | style="border-top:0.018cm solid #00000a;border-bottom:0.018cm solid #00000a;border-left:none;border-right:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.191cm;padding-right:0.191cm;"| <center>sim</center> | ||
|- | |- | ||
|| Servidor Proxy | | style="border-top:0.018cm solid #00000a;border-bottom:0.018cm solid #00000a;border-left:none;border-right:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.191cm;padding-right:0.191cm;"| Servidor Proxy | ||
|| Não | | style="border-top:0.018cm solid #00000a;border-bottom:0.018cm solid #00000a;border-left:none;border-right:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.191cm;padding-right:0.191cm;"| <center>Não</center> | ||
|| Sim | | style="border-top:0.018cm solid #00000a;border-bottom:0.018cm solid #00000a;border-left:none;border-right:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.191cm;padding-right:0.191cm;"| <center>Sim</center> | ||
|| Sim | | style="border-top:0.018cm solid #00000a;border-bottom:0.018cm solid #00000a;border-left:none;border-right:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.191cm;padding-right:0.191cm;"| <center>Sim</center> | ||
|| Sim | | style="border-top:0.018cm solid #00000a;border-bottom:0.018cm solid #00000a;border-left:none;border-right:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.191cm;padding-right:0.191cm;"| <center>Sim</center> | ||
|- | |- | ||
|| Servidor de Redirecionamento | | style="border-top:0.018cm solid #00000a;border-bottom:0.018cm solid #00000a;border-left:none;border-right:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.191cm;padding-right:0.191cm;"| Servidor de Redirecionamento | ||
|| Sim | | style="border-top:0.018cm solid #00000a;border-bottom:0.018cm solid #00000a;border-left:none;border-right:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.191cm;padding-right:0.191cm;"| <center>Sim</center> | ||
|| Sim | | style="border-top:0.018cm solid #00000a;border-bottom:0.018cm solid #00000a;border-left:none;border-right:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.191cm;padding-right:0.191cm;"| <center>Sim</center> | ||
|| Sim | | style="border-top:0.018cm solid #00000a;border-bottom:0.018cm solid #00000a;border-left:none;border-right:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.191cm;padding-right:0.191cm;"| <center>Sim</center> | ||
|| sim | | style="border-top:0.018cm solid #00000a;border-bottom:0.018cm solid #00000a;border-left:none;border-right:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.191cm;padding-right:0.191cm;"| <center>sim</center> | ||
|- | |- | ||
|| PBX | | style="border-top:0.018cm solid #00000a;border-bottom:0.018cm solid #00000a;border-left:none;border-right:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.191cm;padding-right:0.191cm;"| PBX | ||
|| Sim | | style="border-top:0.018cm solid #00000a;border-bottom:0.018cm solid #00000a;border-left:none;border-right:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.191cm;padding-right:0.191cm;"| <center>Sim</center> | ||
|| sim | | style="border-top:0.018cm solid #00000a;border-bottom:0.018cm solid #00000a;border-left:none;border-right:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.191cm;padding-right:0.191cm;"| <center>sim</center> | ||
|| Não | | style="border-top:0.018cm solid #00000a;border-bottom:0.018cm solid #00000a;border-left:none;border-right:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.191cm;padding-right:0.191cm;"| <center>Não</center> | ||
|| Não | | style="border-top:0.018cm solid #00000a;border-bottom:0.018cm solid #00000a;border-left:none;border-right:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.191cm;padding-right:0.191cm;"| <center>Não</center> | ||
|- | |- | ||
|| Suporta ENUM | | style="border-top:0.018cm solid #00000a;border-bottom:0.035cm solid #00000a;border-left:none;border-right:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.191cm;padding-right:0.191cm;"| Suporta ENUM | ||
|| Sim | | style="border-top:0.018cm solid #00000a;border-bottom:0.035cm solid #00000a;border-left:none;border-right:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.191cm;padding-right:0.191cm;"| <center>Sim</center> | ||
|| sim | | style="border-top:0.018cm solid #00000a;border-bottom:0.035cm solid #00000a;border-left:none;border-right:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.191cm;padding-right:0.191cm;"| <center>sim</center> | ||
|| Sim | | style="border-top:0.018cm solid #00000a;border-bottom:0.035cm solid #00000a;border-left:none;border-right:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.191cm;padding-right:0.191cm;"| <center>Sim</center> | ||
|| Sim | | style="border-top:0.018cm solid #00000a;border-bottom:0.035cm solid #00000a;border-left:none;border-right:none;padding-top:0cm;padding-bottom:0cm;padding-left:0.191cm;padding-right:0.191cm;"| <center>Sim</center> | ||
|} | |} | ||
= Metodologia = | |||
A primeira etapa consistirá na escolha de um servidor DNS compatível e que seja suficientemente robusto para cumprir a função de redirecionamento de chamadas aos respectivos servidores, correspondentes às operadoras envolvidas. Este servidor deve ser capaz de executar uma grande quantidade de execuções simultâneas, garantido a integridade dos pacotes e da comunicação como um todo. | |||
Será implementado um servidor de chamadas voip, com o objetivo de validar o sistema de centralização de chamadas. Este servidor deve estar apto a iniciar e receber chamadas via protocolo de internet, assim como se conectar a outras operadoras VoIP, oferecendo o contexto de avaliação de funcionalidade da entidade centralizadora. Esta fase do desenvolvimento não precisa necessariamente funcionar como um SIP proxy, podendo ser implementada por um servidor asterisk, que funciona como servidor de chamada e como cliente, assim como um servidor openSips, que funciona tanto como servidor de chamada quanto como SIP proxy, sendo capaz de rotear requisições de chamadas. A fase seguinte, consiste em povoar um banco de dados ENUM, contendo números convertidos e possibilitando assim sua localização na internet de forma praticamente universal, respeitando a proposta deste trabalho. | |||
Após cumprida a etapa de implementação do servidor de chamadas, segue-se a etapa de desenvolvimento do sistema de encaminhamento de chamadas em si, que é composto por um módulo de inclusão automática de números, possibilitando que as operadoras informem os novos números a povoar o banco de dados via documentos XML. Implantação de um sistema com interface para acesso pelos administradores, fornecendo informações sobre as transações realizadas, estatísticas de desempenho e possibilidade de realizar configurações e atualizações manualmente. O sistema deve também ser capaz de atualizar automaticamente números que realizaram portabilidade numérica, possibilitando o redirecionamento das respectivas mensagems para a operadora correta em caso de mudança. | |||
Um método empregado será o de integrar a estrutura criada com provedores comerciais por meio de conexões lógicas seguras, VPNs. Para isso, deverão ser discutidos os procedimentos usuais como chaves, portas e acessos adequados para implementar estas comunicações. | |||
Um ponto de alta importância, é a realização de testes extensivos de stress, com alto número de requisições e grande quantidade de informações sendo roteadas, possibilitando garantir que o sistema estará apto a agir em um caso real de funcionamento, com os potenciais milhares de usuários conectados trocando informações simultaneamente. | |||
= Plano de Trabalho = | = Plano de Trabalho = | ||
| Linha 448: | Linha 314: | ||
* http://www.intomobile.com/2010/03/06/in-stat-there-will-be-288-million-mobile-voip-users-by-2013/ | * http://www.intomobile.com/2010/03/06/in-stat-there-will-be-288-million-mobile-voip-users-by-2013/ | ||
*http://hubpages.com/hub/How-to-create-ENUM-Records-Creating-Naptr-Records | |||
Edição atual tal como às 03h29min de 1 de agosto de 2011
Objetivo
Este projeto tem como objetivo desenvolver uma solução que permita a criação de uma entidade centralizadora para interconexões entre operadoras VoIP, denominada VoIP Peering, capaz de gerenciar as interoperações destas conexões através do mapeamento eletrônico de números (ENUM).
A motivação para a criação deste projeto veio da necessidade de reduzir a utilização da rede pública de telefonia comutada (RTPC), do inglês Public Switched Telephone Network (PSTN), evitando assim as suas limitações em escalabilidade, e ao mesmo tempo otimizando a utilização de redes IP e simplificando a topologia entre operadoras VoIP.
Outra finalidade deste projeto é viabilizar a padronização de interconexões VoIP promovendo o surgimento de novas aplicações que só serão possíveis com a visão e atuação de uma estrutura que congregue várias operadoras do serviço de Voz Sobre IP.
Justificativa
Devido à necessidade atual dos sistemas de telecomunicações estarem cada vez mais integrados, baratos e eficientes, constantemente nos deparamos com desafios técnicos, financeiros e até políticos para a implantação de propostas inovadoras. A telefonia IP não é necessariamente um novo paradigma, mas necessita de alternativas interessantes e práticas para se estabelecer como um serviço viável e competitivo de telefonia, atingindo cada vez camadas mais carentes da população. No momento atual, uma entidade centralizadora do tráfego de informações entre as operadoras Voip é eventualmente esperada como uma evolução dos modelos de negócio disponíveis e se mostra iminentemente necessária como forma de congregar empresas e reduzir custos destas para o usuário final.
A tecnologia VoIP é cada vez mais difundida no Brasil, haja visto que existem pesquisas apontando em torno de 14 operadoras de rede fixa e outras 79 operadoras de chamada VoIP existentes no Brasil, sendo a maior parte destas com atuação no ambiente corporativos (teleco http://www.teleco.com.br/opvoip.asp). Entretanto, uma questão que ainda limita a ampliação de negócios VoIP é a falta de integração entre as redes IP em atividade - sejam estas redes corporativas, governamentais ou operadas por empresas prestadoras de serviços de telecomunicações - fato que, segundo a Anatel, é mais crítico que a ausência de um plano de numeração. Esta falta de integração leva a iniciativas individuais que vão complicando cada vez mais o cenário de padronização no Brasil.
Nesse sentido, este projeto propõe um modelo de interconexão VoIP para iniciar a integração dessas redes sem a utilização da rede PSTN, promovendo uma padronização que viabilize essa ampliação de negócios, permita a redução dos custos associados à utilização da rede fixa para essa interconexão, propicie a melhoria na qualidade das chamadas (excluindo as conversões VoIP-PSTN-VoIP) e amplie a possibilidade dos usuários utilizarem ao máximo os benefícios que uma comunicação de Voz sobre IP fim a fim oferece.
Com a eliminação das restrições pelo uso da PSTN, como a queda da qualidade devido à conversão entre as redes e a perda de recursos avançados associados ao ambiente, surge um novo cenário para a oferta de serviços baseados no protocolo IP, o que faz com que este projeto atenda às demandas de serviços de telecomunicações baseados no protocolo IP. De imediato, surge um novo serviço que é a criação de uma entidade centralizadora que poderá organizar o tráfego entre as operadoras envolvidas, e a partir daí, implementar uma série de projetos até então inviáveis pela caráter individualizado das empresas que prestam esse serviço.
O uso da tecnologia VoIP já não é mais novidade no mundo da telefonia, apesar de ter seus benefícios evidenciados na crescente participação nas telecomunicações do mundo IP, prestando serviços de voz, dados e vídeo, ainda tem algumas restrições, tanto no aspecto operacional quando no aspecto mercadológico. Os benefícios advindos do VoIP, principalmente de ordem técnica e econômica são encontrados na sua maioria, apenas quando a chamada começa e termina em uma mesma rede. Nas demais situações que envolvem a interconexão das redes de telefonia IP, há uma série de desafios para a prestação de serviços relacionados à operação com custos e níveis de qualidade adequados. Se levarmos em conta as dificuldades encontradas para a conexão entre as prestadoras deste serviço veremos que existe razão no fato de não ter tido um aumento volumoso no número de usuários.
Observa-se atualmente que a maioria das redes VoIP encontram-se isoladas (as chamadas "ilhas VoIP"), de modo que as chamadas destinadas a um usuário externo a estas redes são encaminhados via PSTN. Esta situação pode ser minimizada através da interconexão bilateral, modalidade na qual as opreadoras das redes, duas a duas, criam relacionamentos técnicos e comerciais entre si, que envolvem configuração dos equipamentos de interconexão, acordos comerciais, etc. Levando em conta o número de empresas que precisam fazer esse serviço par a par, chega-se a conclusão que existem muitos esforços sendo feitos de forma não integrada.
Levando em consideração que cada operadora de rede deveria ter uma interconexão bilateral com várias outras, esta configuração se expande consideravelmente. Fica também prejudicada a escalabilidade da solução, visto que o surgimento de uma nova rede (uma nova operadora ou uma nova rede corporativa, por exemplo) à qual deve se interligar requer a reconfiguração de todas as demais redes.
Além destes fatos citados, as operadoras de redes VoIP tem custos relevantes para utilizar o encaminhamento de chamadas e o meio físico (enlace E1) da operadora TDM (Time Division Multiplexing) à qual estão conectadas. Este custos poderia ser minimizados na medida em que as ligações entre terminais VoIP fossem realizadas somente com tecnologia IP. Entretanto, nessa arquitetura dependente da rede PSTN, as operadoras VoIP estão ilhadas em suas respectivas redes IP, subutilizando o potencial tecnológico que essas redes oferecem em termos de redução de custo operacional e oportunidade de novos negócios.
Neste contexto, faz-se necessária a adoção de um sistema computacional que permita a integração multilateral entre as redes VoIP de maneira a permitir que os usuários destas redes possam estabelecer chamadas entre si sem que estas sejam desviadas para a rede PSTN, incorrendo custos adicionais e perda de qualidade na chamada devido às restrições impostas pela rede TDM em comparação com o universo de possibilidades oferecido pela rede IP.
Assim, propõe-se um mecanismo de interconexão VoIP para interligar as diversas redes IPs sem a utilização da tecnologia TDM, através da utilização de DNS-ENUM, numa nova arquitetura. O protocolo ENUM (Electronic Number Mapping) permite o mapeamento de um número telefônico tradicional (formato E.164) para um Identificador de Recurso Uniforme (URI) em rede IP e é definido pela IETF de acordo com os padrões do ITU-T (International Telecommunication Union - Telecommunication Standardization Sector) para o formato E.164. Portanto, esta proposta é também uma oportunidade de inserção do Brasil no contexto dessa tecnologia emergente. Vale ressaltar que, além da interconexão, a utilização dessa tecnologia viabiliza a convergência de serviços de telecomunicação e serviços disponíveis na Internet (voz, dados, vídeo, SMS, localização de sites, etc), haja visto que na arquitetura IMS (IP Multimedia Subsystem) já se identifica o protocolo ENUM como solução para a localização dos serviços, que é parte integrante do módulo de OSS (Operating Support System) nessa arquitetura.
Com o novo modelo de interconexão, propõe-se centralizar a gestão de peering entre as redes VoIP e, através do servidor DNS-ENUM, permitir armazenar informações que indiquem, com base em informações associadas a um usuário de destino, se uma comunicação estabelecida a partir de um usuário VoIP pode ser resolvida através da rede IP, sem a necessidade de desvio desta comunicação para a rede PSTN.
O modelo de negócios previsto pretende disponibilizar o serviço para as redes que tiverem conectadas à arquitetura através de um servidor VoIP SIP Proxy. Por um lado, as redes participantes reduzem seus custos com a utilização da PSTN, simplificam a topologia para o encaminhamento de chamdas e ficam interligadas às outras redes IP. Por outro lado, além de usufruir os mesmos benefícios das operadoras participantes, a entidade centralizadora tem um aumento de receita com a oferta desse novo serviço e de outros porvir, decorrentes da integração das redes IP.
A solução proposta é inovadora e encontra respaldo em soluções aplicadas em alguns outros poucos países, como por exemplo, o serviço VPF (Voice Peering Fabric) oferecido pela empresa Stealth Communications, com várias empresas já integradas a este serviço e funcionando desde 2004.
Introdução
Desde a sua criação, a internet passou por grandes mudanças e inovações no âmbito de protocolos e comunicações. A comunicação através do protocolo da internet (IP – Internet Protocol) é alvo de transformações tanto nos mecanismos usados para entrega das mensagens quanto nos serviços disponibilizados aos seus usuários.
Na década de 90, foram concebidas as primeiras inovações em serviços de transmissão de Voz sobre IP (VoIP), desde então o tema se tornou objeto de estudo de muitas operadoras de telecomunicações. Atualmente a tecnologia de VoIP está consolidada, com seus padrões e protocolos bem definidos.
A tecnologia VoIP, como um conceito de transmissão de voz através da rede IP, reúne um conjunto de protocolos de codificação de áudio, transmissão em tempo real de pacotes, inicio de sessão, e outros que em conjunto permitem comunicação de voz via IP de ponta a ponta na rede. Tal transporte é feito através da rede sem um caminho fixo, fazendo com que a mensagem não fique retida num congestionamento de tráfego.
O sistema de comunicação VoIP atualmente funciona de maneira bem eficiente, permitindo que esse serviço se torne cada vez mais usado. Para se efetivar uma ligação VoIP é necessário que se estabeleça uma sessão entre o emissor e o receptor. Esta sessão pode ser uma simples chamada de voz entre duas pessoas, uma ligação envolvendo voz, dados e vídeo ou ainda uma conferência multimídia. Para isso, alguns protocolos são usados, por exemplo, H.323, Megaco, MGCP e SIP.
O SIP, um dos protocolos mais utilizados não está limitado a Internet, suas aplicações disponíveis são bem diversificadas, tais como: sistema de realidade virtual, games de rede, vídeo conferência, processamento de chamadas, localização de usuários e mensagens instantâneas (Instant Messaging) são algumas facilidades do protocolo SIP.
O VoIP como tecnologia, aproveita-se destes protocolos para garantir uma comunicação interessante porém ainda com níveis de qualidade inferiores aos que a telefonia fixa e móvel tem provido. Para avaliar o serviço VoIP é necessário levar em conta a qualidade do serviço (QoS), o preço e a confiabilidade do mesmo.
A qualidade do serviço é um aspecto fundamental de garantia de entrega das informações num processo de ponta a ponta (rede local de origem a rede local de destino) e como tal, uma chamada de voz sobre IP entre dois usuários pode ser avaliada neste aspecto. Para se determinar a qualidade do serviço não se deve analisar apenas um componente ou elemento da rede, portanto os principais parâmetros a serem controlados são a vazão, a latência, jitter, as perdas, a disponibilidade e a segurança. Resultados avaliando todos estes parâmetros podem ser dimensionados e tomados como base para definir se uma rede possui ou não um serviço de comunicação de bom desempenho.
Estes parâmetros são de fácil medição e validação. A vazão ou throughput que é determinada pela quantidade de bits destinados a cada atividade da rede é um bom indicador. A latência tida como a soma dos atrasos da rede e equipamentos utilizados para a comunicação estabelecida complementa esta avaliação. O jitter está relacionado com a latência da rede, medindo o tempo de atraso entre a sequencia de entrega dos pacotes, isto permite ampliar o escopo de avaliação de uma rede. Outros itens como perdas, os pacotes que são corrompidos durante a comunicação e a disponibilidade da rede finalizam o processo de medição de uma rede.
O sucesso do serviço VoIP esteve diretamente ligado às possibilidades de redução de custos nas chamadas entre os usuários. Como o meio é a Internet, começou a ser popularizado pelas ligações "sem custo" entre dois usuários na rede e reforçado pela diminuição do preço nas chamadas envolvendo chamadas para fixo e móvel, já que as operadoras VoIP conseguiam comprar minutos em grande volume e logo possuíam condições de negociar o custo dessas ligações.
Existem algumas operadoras de serviço VoIP que oferecem ligações grátis quando feitas para a mesma operadora e cada uma delas oferecem planos variados para ligações locais, nacionais e internacionais. De fato elas proporcionam preços mais baratos em relação aos cobrados pelas operadoras de celulares e de telefonia fixa. Existem também os provedores de serviço VoIP que oferecem o serviço grátis, porém com limitações de qualidade e abrangência do serviço.
Atualmente um cliente VoIP pode se comunicar de forma direta com os clientes de uma mesma empresa. Ao tentar se conectar a um usuário de outro serviço VoIP, telefonia fixa ou móvel, deve ser fechada uma conexão direta com a empresa de destino, um procedimento caro e que demanda grandes investimentos em manutenção. Este modelo depende diretamente do fechamento de acordos bilaterais entre empresas provedoras do serviço VoIP, além da instalação de infra estruturas onerosas no processo de instalação e manutenção. Para criar e suportar tal infra estrutura, além do desafio político, o desafio econômico também se torna latente. Com a perspectiva de crescimento atual dos serviços de telefonia VoIP, cada vez mais utilizados por usuários corporativos e domésticos, a tendência é também o aumento de provedores de serviços dificultando ainda mais a instalação de redes dedicadas entre cada serviço.
Nesta situação, se faz interessante um novo modelo de tráfego, denominado peering onde a interconexão é feita através de uma entidade centralizadora. Esta se responsabilizará pela intermediação das chamadas procurando proporcionar a cada operadora VoIP, benefícios como redução de custo, facilidades na configuração de novas rotas e consequentemente na comunicação entre entidades diferentes, tarifação centralizada e aumento da capilaridade da rede que acarreta em uma maior escalabilidade do sistema.
Entretanto a difusão do VoIP no Brasil se vê bastante limitada devido a crescente demanda de tráfego entre operadoras que não podem expandir seus serviços devido ao isolamento entre suas redes, criando assim ilhas de operação VoIP. A estrutura de rede VoIP em vigor no Brasil requer que toda a comunicação entre duas operadoras VoIP trafegue pela PSTN ou rede pública de telefonia comutada. Esta forma de transmissão também requer que as operadoras possuam ligações diretas entre si, mas em locais onde o número de empresas de telefonia é elevado, a complexidade da topologia de rede se torna onerosa e difícil de administrar.
A necessidade de migrar para a rede mundial de computadores se deve ao fato de que para uma comunicação com alto grau de multimídia (dados, vídeo, voz ou todas juntas) requer uma transmissão via IP de ponta a ponta, característica esta não alcançada devido à existência da rede PSTN entre as operadoras. Quando o sinal da rede IP passa por um gateway para trafegar através da rede PSTN e novamente passa por outro gateway para retornar a rede IP do destinatário, o custo de entrega de tráfego impede que se forneçam serviços de vídeo e áudio com alta confiabilidade e baixo custo. Uma solução possível, que já foi aventada em várias partes do mundo é um sistema que unifique este tráfego, alvo deste projeto.
Para se prover um serviço que centralize estas atividades é necessário o uso de alguns elementos como o DNS ou Domain Name System, um protocolo da camada de aplicação da rede que tem como função atribuir endereços IP a nomes de domínio. Através do uso de servidores distribuídos pela rede, o DNS armazena dados, possibilitando a tradução de nomes de domínio para IP e IP para nomes de domínio. Sua estrutura é organizada de forma hierárquica, possibilitando a divisão de tarefas entre servidores DNS de acordo com a finalidade do site, ou domínio acessado.
Além dos servidores DNS, é necessário também o uso de servidores Proxy, utilizados para intermediar um determinado cliente e suas requisições à rede, possuindo as características de atribuição de segurança, velocidade, restrição e acesso e anonimato ao cliente. Na função de segurança, pode ser utilizado para restringir o acesso de pacotes maliciosos e potencialmente prejudiciais ao usuário, o acesso a determinados tipos de dados e sites e armazenar uma memória cache dos sites acessados por seus usuários, diminuindo assim a largura de banda necessária para o acesso a dados usualmente acessados, e aumentando a agilidade das tarefas. A questão do anonimato, está em se permitir que um determinado cliente acesse um determinado servidor estando protegido pelo servidor de proxy, que realiza a requisição e a repassa para o usuário.
Outro padrão utilizado é o ENUM, ou eletronic numbering, um protocolo que tem como objetivo atribuir um endereço unificado, possibilitando a interconexão entre sistemas VoIP, celular, telefonia fixa, e-mail, ou seja, todos os sistemas de comunicação (texto ou voz). O sistema conta com um servidor DNS, capaz de resolver um determinado número de telefone em um endereço ENUM que poderia ser vinculado a um SIP URI, utilizado para a comunicação entre servidores SIP, ou mesmo um endereço de e-mail. Este projeto tem como objetivo, prover um sistema que centralize o processo de intermediação de chamadas entre operadoras VoIP utilizando todos os recursos como DNS, ENUM e proxy para garantir o máximo de eficiência, escalabilidade, segurança e desempenho.
Arquivo:Conexão dos usuários IP sem utilização da PSTN.jpg
Com este sistema pretende-se obter amplos ganhos como, por exemplo, a diminuição dos custos operacionais na instalação e manutenção da infra estrutura VoIP; grande maleabilidade e escalabilidade da malha VoIP já que novas empresas poderiam ser implantadas de maneira mais fácil, assim como alcançariam mais clientes com um menor investimento em infra estrutura; redução na possibilidade de falhas técnicas em função do menor número de interconexões entre as empresas, diminuindo as instabilidades e intermitências no fornecimento dos serviços VoIP.
Outros benefícios podem ser auferidos por esta proposta já que este serviço abre as portas para uma nova escala de interconexão entre pessoas, possibilitando a criação de novos modelos de serviços, que atingiriam um número maior de pessoas em relação ao e-mail, telefonia VoIP, telefonia fixa e celular. A criação de um modelo padronizado de comunicação entre pessoas e empresas, além de sistemas eficientes de avaliação da eficácia, o que aumenta a credibilidade e a facilidade de adaptação dos usuários à nova realidade.
Desenvolvimento
O desenvolvimento deste projeto envolve uma série de competências e atividades. Inicialmente, será feita uma pesquisa para se identificar Servidores DNS e SIP disponíveis no mercado com requisitos específicos para ser parte da solução. Serão analisados requisitos do ponto de vista de desempenho, funcionalidade, escalabilidade e software livre. Estes servidores deverão ser avaliados por meio de alguns critérios, sendo que um dos principais é a carga que poderá suportar. A centralização implica que o número de usuários do sistema possa crescer bastante e que o tráfego seja capaz de chegar a valores elevados. Outra característica considerada essencial é a possibilidade de se usar soluções de código aberto que podem comprometer o tempo de desenvolvimento pela equipe implementadora mas tem a grande vantagem de levar autonomia no desenvolvimento das soluções contando com o apoio da comunidade mundial.
Na segunda etapa está prevista a definição e implantação da arquitetura da solução, sendo que será desenhada a topologia proposta para criar o ambiente de desenvolvimento da solução contemplando o software e demais recursos envolvidos. Essa etapa será feita em conjunto com a empresa parceira no projeto, pois é necessário definir quem poderá ser a executora comercial da solução gerada a partir deste esforço.
Prevê-se a execução de um projeto piloto, buscando simular situações semelhantes às esperadas durante a operação real do sistema, validando desta maneira os elementos escolhidos. Esta etapa será monitorada para que os resultados obtidos sejam aplicados nas próximas etapas do projeto, dando respaldo às definições que permearão o seu desenvolvimento.
O Servidor DNS
O protocolo DNS é a parte dos padrões da internet e especifica a forma como um computador identifica outro na rede mundial a partir de nomes de domínio. A implementação do protocolo DNS é chamada Servidor DNS e este é o principal elemento de nossa rede. Este servidor será responsável por guardar em seus bancos de dados informações de todos os serviços disponíveis para determinado assinante, assim como traduzir nomes de domínio em endereços IP. A arquitetura de rede proposta terá a finalidade de identificar um subdomínio e associá-lo ao serviço de chamada VoIP.
Para realizar tal tarefa será necessário transformar o numero telefônico E.164 em um subdomínio da rede, a tecnologia responsável por essa conversão é a aplicação ENUM do Sistema de Descoberta Dinâmica de Delegação (DDDS). A nível mundial, o domínio e164.arpa está sendo preenchido para esta finalidade.
O ENUM é uma aplicação DDDS que tem como objetivo converter números telefônicos em um endereço unificado, possibilitando a interconexão entre sistemas de comunicação. O sistema contaria com um servidor DNS capaz de resolver um determinado número de telefone em uma URI, que poderia ser vinculada a um endereço SIP,utilizado para comunicação VoIP, um endereço de e-mail ou um número de telefonia fixa ou celular.
A solicitação de chamada em uma rede compatível com ENUM traduz o número +55 34 8765 4321 em uma URI no formato 1.2.3.4.5.6. 7.8.4.3.5.5.e164.arpa conforme mostrado na imagem a seguir:

- Uma chamada é iniciada através de um usuário requisitando um número específico
- O SIP Proxy A checa que este número não faz parte do seu domínio e envia uma requisição ao Servidor DNS-ENUM, perguntando a qual URI aquele número está asOs Mósociado
- O servidor DNS-ENUM responde a requisição de acordo com a ordem de prioridade dos serviços. No caso da imagem acima, a prioridade era a URI referente a uma conta VoIP, mas poderia ser um email, uma página web, um número móvel ou até mesmo a um número telefônico de uma rede PSTN
- O SIP proxy A encaminha a requisição ao servidor responsável pelo domínio da URI solicitada
- O SIP Proxy B checa se aquela URI está autorizada a receber chamadas
- A chamada é estabelecidade entre o usuário A e B
Para identificar os serviços referentes a um determinado assinante conforme ilustrado no passo 3, é necessário fazer uma busca nos registros do servidor DNS, para tal usamos o protocolo de ponteiro para nome de autoridade (NAPTR).
Colocar uma tabela comparativa com os principais servidores DNS
Para implementar tal capacidade na rede, escolhemos uma distribuição de software livre chamada Berkeley Internet Name Domain (BIND), um servidor DNS desenvolvido pela Internet Systens Consortium que possui uma plataforma robusta e estável, além de ser o mais utilizado nos principais servidores do mundo no gênero e possuir suporte ao protocolo NAPTR.
O pacote de Software BIND possui três elementos principais: a biblioteca de resolução de nome de domínios, as ferramentas de teste de servidor e o mais importante, o servidor de nome de domínio.
A biblioteca de resolução de nome de domínios provê os padrões de conversão entre nomes e endereços IP.
As ferramentas de teste são aplicativos capazes de checar configuração, redundância, zonas e atividade do servidor BIND.
O servidor de nomes de domínio tem a responsabilidade de responder as requisições de buscas, chamadas DNS lookups, utilizando os dados armazenados em suas zonas. Entende-se por zona os arquivos de configurações ou banco de dados que contém informações sobre os domínios. As entradas contidas dentro de uma zona são chamadas de registros de recursos(RR) DNS.
Um arquivo de configuração de zona possui: estruturas de registros de Começo de Autoridade (SOA), responsáveis por delegar o papel do servidor DNS na rede; registros de espaços de nome (NS), responsáveis por listar os nomes de servidores da zona; e registros diversos, área destinada ao registro de dados referente aos hosts da zona.
Os registros de recursos diversos possuem informações de mapeamento entre nomes e endereços IP, denominados “A”; entre endereços IP e nomes, denominados “PTR”; e entre pseudônimos e nomes, denominados “CNAME”. Veja um arquivo de configuração típico
TTL 86400
e164.br. IN SOA ns.e164.br. (
2011051911 ; Numero serial, baseado na data
21600 ; atualizar em 6 horas
3600 ; tentar novamente após 1 hota
604800 ; expirar depois de 1 semana
86400 ) ; TTL minima de 1 dia
)
e164.br. 43200 IN NS ns.e164.br.
;
ns.e164.br. 43200 IN A 192.168.1.2
8.7.6.5.4.3.2.1.4.3.5.5.e164.br. NAPTR 10 100 "u" "E2U+sip" "!^.*$!sip:voiptalkers@intervoip.br!".
1.3.3.3.5.5.2.3.4.3.5.5.e164.br. NAPTR 10 101 "u" "E2U+h323" "!^.*$!h323:nonfreevoip@intervoip.br!".
O padrão DNS especifica um algoritmo abstrato chamado Sistema de Descobrimento Dinâmico de Delegação (DDDS), responsável por fazer associações em tempo real de strings com sistemas delegados. A associação em tempo real permite carregar sistemas delegados que mudam constantemente ao longo do tempo como status de mensagens instantâneas, status de conta VoIP, entre outros. Este algoritmo será o elemento principal da centralizadora peering, permitindo que o servidor DNS seja capaz de resolver nomes de domínio a partir de strings passadas no momento do DNS lookup.
A associação do número E.164 será feita mapeando a string passada na busca com a contida no banco de dados interativamente através de uma aplicação, até que uma condição terminal seja alcançada.
Essa string, chamada String Única da Aplicação (AUS), é a entrada do algoritmo DDDS e sua estrutura léxica deve implicar em um resultado que alcançará um estado terminal dos registros de recursos. A AUS do padrão ENUM é o número de telefone E.164.
A aplicação é um conjunto de protocolos que define a forma como a AUS será lida e convertida. No caso da centralizadora peering, a aplicação a ser utilizada será o ENUM.
ENUM é uma aplicação DDDS capaz de mapear números E.164 em URI. A URI, por sua vez, poderá identificar um usuário de e-mail, um cliente de Mensagem Instantânea (IM), e principalmente uma conta SIP, caracterizando um usuário VoIP. Mapear números telefônicos em URI permitirá que o roteamento de chamadas VoIP seja feita absolutamente na rede IP, não sendo necessário passar pela PSTN como se faz hoje.
Para se mapear um numero E.164 em uma URI utiliza-se os algoritmos definidos pela aplicação ENUM do DDDS. Segue abaixo o processo de conversão:

Após a conversão do número E.164 em um nome de domínio efetua-se uma requisição de busca nos registros de recurso do servidor DNS. O padrão ENUM grava as informações de URI referentes ao pseudônimo em um tipo especial de registro de recurso chamado NAPTR.
O NAPTR, tem a função de encontrar caminhos de se contatar determinado assinante através do registro em DNS que este assinante possui. A entrada do protocolo NAPTR é a saída da etapa 2 da conversão de E.164 para URI. Suas tomadas de decisões são baseadas de acordo com 6 campos principais de configuração:
- Ordem: classifica qual a prioridade que um registro NAPTR referente a certo domínio tem em relação aos outros registros NAPTR do mesmo. Exemplo:caso o usuário possua uma conta SIP, um e-mail, um IM e uma conta H323, o campo classifica a ordem de prioridade com o qual o usuário será contatado quando for efetuada uma requisição de busca pelo pseudônimo referente ao seu número E.164.
- Preferência: configura qual a conta de preferência ao qual o usuário será contatado. Essa propriedade permitirá configurar a ordem de prioridade de uma conta VoIP caso o usuário possua mais de uma. Exemplo: caso dois ou mais registros NAPTR do usuário possua mesma ordem, classifica qual registro será retornado quando uma requisição de busca for efetuada.
- Flags: responsáveis por dizer como será a interpretação dos campos no registro, o padrão ENUM utiliza principalmente a flag "u" e indica que o registro é terminal, ou seja,indica que o mapeamento é feito diretamente entre um número E.164 e uma URI.
- Serviços: indica qual o serviço está sendo disponibilizado ao registro NAPTR. Para o padrão ENUM, o serviço é "e2u" que significa "E.164 to URI". O nome completo do serviço é "e2u+PROTOCOLO" e inclui o protocolo usado pelo URI, sendo que este pode ser SIP, e-mail, IM ou outro. Um exemplo seria "e2u+sip".
- Expressão regular: contém uma expressão regular responsável por modificar o AUS, descrito na etapa dois da conversão E.164 para pseudônimo.
- Substituição: cm um registro não terminal, indica o próximo nome de domínio a efetuar uma requisição de busca. Como o registro NAPTR permite apenas registros terminais, essa propriedade é preenchida com um ponto final ".", indicando que não há servidor de substituição.
O resultado é um registro de recurso parecido com o abaixo de acordo com os padrões definidos pela RFC 3403[7]:
$ORIGIN 8.7.6.5.4.3.2.1.4.3.5.5.e164. IN NAPTR 10 10 "u" "sip+E2U" "!^.*$!sip:voiptalkers@intervoip.br!" . IN NAPTR 102 10 "u" "mailto+E2U" "!^.*$!mailto:mailtalkers@intervoip.br!" . IN NAPTR 103 10 "u" "tel+E2U" "!^.*$!tel:+553412345678!" .
Nos arquivos de configuração do BIND, o registro seria representado da seguinte forma:
8.7.6.5.4.3.2.1.4.3.5.5.e164. NAPTR 10 10 "u" "sip+E2U" "!^.*$!sip:voiptalkers@intervoip.br!" . 8.7.6.5.4.3.2.1.4.3.5.5.e164. NAPTR 102 10 "u" "mailto+E2U" "!^.*$!mailto:mailtalkers@intervoip.br!" . 8.7.6.5.4.3.2.1.4.3.5.5.e164. NAPTR 103 10 "u" "tel+E2U" "!^.*$!tel:+553412345678!" .
A requisição de busca exemplificada na linha de código acima resultará preferencialmente pela conta SIP “voiptalkers@intervoip.br”, seguido pelo endereço de email e o número telefônico.
Os Módulos de Software
Serão desenvolvidos módulos de software que complementarão as funcionalidades necessárias do sistema proposto, a saber:
- Módulo de Inclusão Automática de Números: permitirá que o sistema seja informado automaticamente por uma operadora de rede VoIP da necessidade de inclusão de um novo número em sua base. Dessa forma, deverá haver um procedimento para que cada operadora participante possa repassar essas informações. Isto implica em criar uma Virtual Private Network (VPN) para que as informações fluam com segurança entre cada lado.
- Módulo de Portal Básico de Operação: dará acesso manual aos operadores do sistema para manutenção dos dados presentes em sua base, além de fornecer opções diversas de consulta e relatórios. Esta interface terá vários níveis de operação, entre eles: administrador, supervisor, operacional e consulta.
- Módulo de Interface com Portabilidade Numérica: interface com sistema genérico externo permitindo que o sistema resultante deste projeto seja atualizado de acordo com migrações de números entre operadoras no contexto da portabilidade numérica. Este módulo implica em conexão direta com as bases de dados da portabilidade numérica (BDO).
- Módulo de Gestão Estatística: implementação de supervisão e contabilidade de solicitações efetuadas ao sistema para dar suporte ao modelo de negócios a ser implantado, permitindo o acompanhamento dos acessos feitos ao sistema pelas redes VoIP usuárias do mesmo.
A todos os módulos de software implementados serão aplicadas atividades de testes visando validar sua adequação aos requisitos definidos, e também serão executados testes de integração entre os módulos desenvolvidos e o servidor DNS escolhido. Testes de homologação envolvendo simulação de ambiente real serão executados à medida que os módulos forem sendo desenvolvidos, buscando a validação em ambiente próximo do real.
O Sip proxy
Session Initiation Protocol (SIP) é um protocolo de controle da camada de aplicação usado para criar, modificar e terminar sessões com um ou mais participantes. Essas sessões podem ser de chamadas de telefone via internet, distribuição e conferências multimídia.
Um SIP proxy ou Servidor Proxy SIP é um elemento da rede que roteia uma chamada SIP até o usuário de destino.
O servidor SIP proxy não fará parte da solução, mas será utilizado para a validação da arquitetura proposta. Este proxy SIP será utilizado para simular as solicitações feitas ao servidor DNS-ENUM, além de ser usado para testes de conexão de chamadas de fim a fim.
Atualmente (Maio de 2011), sabe-se que a aplicação ENUM do algoritmo DDDS é suportada pelos principais servidores de sip proxy, gateways SIP e SIP softphones. Entre eles as soluções que mais se destacam são: SIP express router (SER), Kamailio, Open Sip Server(OpenSIPS) como servidores proxy; Asterisk e Swyx como gateways e Ekiga como softphone.
A tabela 1 mostra um comparativo entre as principais soluções de servidores SIP encontradas no mercado e que poderão ser utilizadas para a validação da arquitetura proposta.
| Servidor de registro | ||||
| Servidor de Localização | ||||
| Servidor Proxy | ||||
| Servidor de Redirecionamento | ||||
| PBX | ||||
| Suporta ENUM |
Metodologia
A primeira etapa consistirá na escolha de um servidor DNS compatível e que seja suficientemente robusto para cumprir a função de redirecionamento de chamadas aos respectivos servidores, correspondentes às operadoras envolvidas. Este servidor deve ser capaz de executar uma grande quantidade de execuções simultâneas, garantido a integridade dos pacotes e da comunicação como um todo. Será implementado um servidor de chamadas voip, com o objetivo de validar o sistema de centralização de chamadas. Este servidor deve estar apto a iniciar e receber chamadas via protocolo de internet, assim como se conectar a outras operadoras VoIP, oferecendo o contexto de avaliação de funcionalidade da entidade centralizadora. Esta fase do desenvolvimento não precisa necessariamente funcionar como um SIP proxy, podendo ser implementada por um servidor asterisk, que funciona como servidor de chamada e como cliente, assim como um servidor openSips, que funciona tanto como servidor de chamada quanto como SIP proxy, sendo capaz de rotear requisições de chamadas. A fase seguinte, consiste em povoar um banco de dados ENUM, contendo números convertidos e possibilitando assim sua localização na internet de forma praticamente universal, respeitando a proposta deste trabalho.
Após cumprida a etapa de implementação do servidor de chamadas, segue-se a etapa de desenvolvimento do sistema de encaminhamento de chamadas em si, que é composto por um módulo de inclusão automática de números, possibilitando que as operadoras informem os novos números a povoar o banco de dados via documentos XML. Implantação de um sistema com interface para acesso pelos administradores, fornecendo informações sobre as transações realizadas, estatísticas de desempenho e possibilidade de realizar configurações e atualizações manualmente. O sistema deve também ser capaz de atualizar automaticamente números que realizaram portabilidade numérica, possibilitando o redirecionamento das respectivas mensagems para a operadora correta em caso de mudança.
Um método empregado será o de integrar a estrutura criada com provedores comerciais por meio de conexões lógicas seguras, VPNs. Para isso, deverão ser discutidos os procedimentos usuais como chaves, portas e acessos adequados para implementar estas comunicações.
Um ponto de alta importância, é a realização de testes extensivos de stress, com alto número de requisições e grande quantidade de informações sendo roteadas, possibilitando garantir que o sistema estará apto a agir em um caso real de funcionamento, com os potenciais milhares de usuários conectados trocando informações simultaneamente.
Plano de Trabalho
Resumo
Fontes
[1] BRADNER,S., CONROY, L., FUJIWARA, K. The E.164 to Uniform Resource Identifiers (URI):Dynamic Delegation Discovery System (DDDS) Application (ENUM), RFC 6116, Março de 2011.
[2] MOCKAPETRIS, P. Domain Names — Implementation and Specification, RFC 1035, Novembro de 1987.
[3] MOCKAPETRIS, P. Domain Names — Concepts and Facilities, RFC 1034, Novembro de 1987.
[4] INTERNET SYSTEM CONSORTIUM. BIND 9 Administrator Reference Manual. 2010.
[5] MEALLING, M., Dynamic Delegation Discovery System (DDDS) - Part One: The Comprehensive DDDS, RFC 3401, Outubro de 2002.
[6] MEALLING, M., Dynamic Delegation Discovery System (DDDS) - Part Two: The Algorithm", RFC 3402, Outubro de 2002.
[7] MEALLING, M., Dynamic Delegation Discovery System (DDDS) - Part Three: The Domain Name System (DNS) Database", RFC 3403, Outubro de 2002.
[8] MEALLING, M., Dynamic Delegation Discovery System (DDDS) - Part Four: The Uniform Resource Identifiers (URI) Resolution Application", RFC 3404, Outubro de 2002.
[9] MEALLING, M., Dynamic Delegation Discovery System (DDDS) - Part Five: URI.ARPA Assignment Procedures", RFC 3405, Outubro de 2002.
[10] Electronic Numbering (ENUM). Acedido em 12 de Maio de 2011, em http://www.enum.org.
[11] Centro de Estudos e Pesquisas em Tecnologia de Redes e Operações (2011). VOIPix - O sistema de VoIP Peering do NIC.br. Acedido em 12 de Maio de 2011, em http://www.ceptro.br/CEPTRO/MenuCEPTROSPVoiPPeering.
[12] L. Strand, W. Leiste, “A Survey of SIP Peering”, Norwegian Computing Center, P.O. Box 114 Blindern, NO-0314 Oslo, Norwa, 2010..
[13] H. Lee, T. Kwon, D.H. Cho, “An Enhanced Uplink Scheduling Algorithm Based on Voice Activity for VoIP Services in IEEE 802.16d/e System”, IEEE Communications Letters, vol. 9, no. 8, August 2005.
[14] S. Guha, N. Daswani, R. Jain, “An Experimental Study of the Skype Peer-to-Peer VoIP System”.
- Centro de estudos e pesquisas em tecnologia de redes e operações [1]
- A Survey of SIP Peering [2]
- An Enhanced Uplink Scheduling Algorithm Based on Voice Activity for VoIP Services in IEEE 802.16d/e System [3]
- An Experimental Study of the Skype Peer-to-Peer VoIP System [4]
- Capacity of an IEEE 802.11b Wireless LAN supporting VoIP [5]
- Hersent, Olivier. IP telephony : deploying VoIP protocols and IMS infrastructure / Olivier Hersent. — 2nd ed. ISBN 978-0-470-66584-8
- TRAJETÓRIA TECNOLÓGICA DO SETOR DE TELECOMUNICAÇÕES NO BRASIL: A TECNOLOGIA VoIP [6]
- Análise de desempenho de tráfego VoIP utilizando o Protocolo IP Security [7]
- O PAPEL DA TECNOLOGIA NA ESTRATÉGIA: CASO DE UMA OPERADORA DE TELEFONIA FIXA E A TECNOLOGIA VOIP [8]
- wikipedia: ENUM [9]
- Anatel esclarece uso de VoIP para oferta de serviço de voz
