1. Agenda
• Contexto e desafios do Projeto InterVoIP (CPqD)
• Apresentação do Projeto InterVoIP, motivação e etapas
• Conceitos
• ENUM – Convergência de Serviços
• Tecnologias de Interconexão VoIP
• Desafios da Pesquisa do Projeto InterVoIP
• Benchmarking de servidores DNS-ENUM (UFU)
• Pesquisa de uma solução em VoIP Peering (CPqD)
• Padrões de implementação : IETF
• Arquitetura
• Estudo de caso do InterVoIP

2. SBE-I
SIP
SSP-I SSP – SIP Service Provider
SBE – Signaling Path Border Element
SIP
Para qual operadora deve
ser enviado o pacote?
Speermint - elementos

3. SBE-I
LRF
SSP-I
LUF
LUF - Look-Up Function
Determina localização do domínio de um
SF (Signaling Function) de destino
SF
SF - Signaling Function
Envia as requisições SIP para
estabelecimento e manutenção de sessões
LRF - Location Routing Function
Determina SED necessária para
roteamento da requisição
SED (Session Establishment Data)
Dados necessários para rotear uma chamada para
o próximo salto:
. FQDN ou IP
. Porta
. Protocolo de Transmissão
. Segurança
. Outros parâmetros de controle
Speermint - elementos
SIP

4. SSP1
SF
SIP
SBE
SF
SSP2
DBE
RTPRTP
DBE
LUF
Proxy Redirect
ou
ENUM
Q: Numero_ENUM
R: Dominio (AoR)
LRF
DNS
Q: SRV Dominio (AoR)
R: FQDN/IP Porta
Protocolo Transmissão
Speermint - como funciona
SIP
SBE
LUF
- Realiza consulta ENUM
- Retorna o domínio AoR
(sip:bob@example.com)
- Se não resolver, pode enviar para PSTN
DBE
- Data Path border Element
- Elemento de borda por onde passa o tráfego
de mídia.
LRF
- Descobre próximo salto a partir do
domínio de destino
- Resolução DNS: NAPTR (Transporte) /
SRV (Porta) / A (Endereço) – rfc 3263

5. SBE
LUF
LRF
SF
SSP
ENUM
DNS
Como aprovisionamos dados no
DNS e no ENUM?
SIP
Aprovisionamento de dados

6. ENUM
DNS
Database
Sugere modelamento para aprovisionamento de dados de encaminhamento:
Operadora B
Inseridos pelo SSP destino – Registrant
Operadora B
Consumido pela SSP que origina a
chamada ou uma SSP Intermediaria
DRINKS - Aprovisionamento de dados

7. Visão simplificada da arquitetura

8. Base de dados

9. Fatores de decisão
(custo, horário, etc)
Numero
Telefônico
Range de
Numeração
Prefixo
Grupo de
Destino
n
n
n
1
ENUM
Record Domínio
nn 11
SRV Record
NAPTR Record
A Record
n
1
1
1
SED
Grupo de
Rota
n n
n
n
Peering
Organization
1 n
DRINKS - Flexibilização de roteamento

10. Que arquitetura pode atender ao
modelamento DRINKS, permitindo
flexibilização no roteamento da
chamada VoIP ?

11. Requisitos da Arquitetura
• Alta taxa de vazão
• Flexibilidade no encaminhamento de chamada
• Facilidade de implementação
• Escalabilidade de dados
• Escalabilidade Horizontal
• Aderência à infra-estrutura de TI das empresas do setor

12. Opções para a Arquitetura
• Benchmarking realizado pela UFU:
• Bind
• PowerDNS

13. Bind com Zone Files

14. PowerDNS com Mysql

15. Zone Files - Mysql

16. Como conseguir uma maior
independência em relação ao
servidor DNS ?

17. Abstração através de um Adaptador
• Biblioteca linkada ao servidor DNS
em tempo de compilação.
• Trabalha integrada a backend
customizado do servidor DNS.
• Recebe as consultas enviadas ao
servidor DNS e repassa a
resolução ao InterVoIP.
• Faz uso de sockets e trafega
protocolo binário, definido sob
medida, com baixo overhead.

18. Arquitetura adotada
Arquitetura do projeto
PowerDNS com Adaptador

19. • Por que PowerDNS ?
• Concebido com a premissa de ser
extensivel.
• Possui vários backends
implementados
• Lembrando que um dos requisitos...
Facilidade de implementação
• Por outro lado ...
• Para que seja satisteito mais um
requisito da arquitetura:
Aderência à infra-estrutura de TI
• Apenas acoplar Adaptador ao novo
servidor DNS
• Demais módulos são reaproveitados

20. Servidor de Consultas
• Recebe consultas do DNS e encaminha
ao mecanismo de resolução
• Alta disponibilidade
• Escalável horizontalmente.
• Alto desempenho
• Load Balancer via ha-proxy.
• JBOSS Netty
• Abstrai a complexidade da
programação com sockets.

21. Protocolo de transmissão
• Google Protocol Buffers
• Abstrai a complexidade da definição de um protocolo binário
• Protocolo definido sob medida em arquivo texto
• Compilador protoc gera implementações em Java e C++

22. Mecanismo de Resolução
• Traduzir chave DNS para registro correspondente
• Pelo fato da resolução ser interna ao InterVoIP proporciona :
• Flexibilidade e inteligência na tomada de decisão
• Políticas pré-definidas (Custo da ligação, Horário da ligação, Tráfego no link )

23. • Para atender a mais um requisito...
• Alta vazão
• Registros devem estar na memória
• Devido ao grande volume de
registros um outro requisito...
• Escalabilidade de dados
• Como alocar em memória uma
grande quantidade de registros de
forma confiante e escalável ?

24. Cache Distribuído
• MenCached
• Standalone
• JBoss Infinispan
• Standalone
• Embedded
• Opção escolhida:
• JBoss Infinispan Embedded
• Escalabilidade da aplicação em conjunto com dados
• Escalabilidade teórica infinita
• Modo de configuração
• Distribuído parcialmente replicado

25. Modos de Configuração do Cache

26. Modo Replicado
• Capacidade de Armazenamento
• Igual a capacidade do menor nó
• Segurança do dado
• Maximizada
• Cache completo em todos os nós

27. Modo Distribuído
• Capacidade de Armazenamento
• Maximizada
• Igual a soma da capacidade de
todos os nós
• Segurança do dado
• O dado está presente em um único
nó
• Se um nó apresentar falha, parte
dos dados deixarão de estar na
memória.

28. Modo Distribuído parcialmente Replicado
• Capacidade de Armazenamento
• > que cenário Replicado.
• < que cenário Distribuído.
• Depende do nível de replicação.
• Segurança do dado
• > que cenário Distribuído.
• < que cenário Replicado.
• Depende do nível de replicação.
• Cenário Exemplo
• 3 Nós - Nível de replicação = 2
• Se apenas um nó apresentar falha,
o cache ainda contém todos os
dados.

29. Cache Distribuído InterVoIP
• Consulta base de dados relacional, modelada segundo o DRINKS e aloca
os registros em um cache distribuído chave-valor.

30. Validação da Arquitetura
• Nessa arquitetura o desempenho da aplicação passa a depender não
somente do servidor DNS.
• Após a definição da arquitetura e implementação de um mínimo necessário
foram efetuados testes de validação da arquitetura.

31. Validação da arquitetura
• Para formular uma metodologia de teste, devemos considerar
aspectos não funcionais, relativos ao desempenho e a capacidade
de recursos computacionais.
• Desempenho
• Vazão de Requisições por minuto
• Tempo de latência
• Capacidade de recursos computacionais
• Disponibilidade de memória
• Manutenção da base de dados
• Tempo de reload da base de dados
• Desempenho durante o reload da base de dados

32. Testes de desempenho do DNS
• Backend padrão versus backend com adaptador.
• Testes realizados para números existentes e não existente em que
o DNS é autoritativo.
• Utilizamos a ferramenta opensource dnsperf.
• Para os dois cenários foi utilizada uma base com 1 milhão de
números cadastrados.
• Foram considerados várias configurações de cache para o DNS,
fizemos uma analise comparativa com a configuração mais coerente
para o estudo dos dois cenários.

33. Vazão para números existentes

34. Latência para números existentes

35. Vazão para números não existentes

36. Latência para números não existentes

37. Alocação de memória com uso do Adaptador
• Quantidade de memória estimada
para uma carga de 1 milhão de
números telefônicos
• Tempo de carga da base de dados
para RAM
• Tempo aferido para carga em uma
máquina
• Arquitetura Intel i7 2600 64bits - 3.4 Ghz
• 8G RAM
730 MBytes
52 segundos

38. • Vazão
• Para números existentes temos uma vazão maior para o backend padrão
• Para números não existentes os valores para os dois cenários são
parecidos
• Bom desempenho nos dois cenários, considerando o fluxo de chamada
Voip
• Tempo de Latência
• Com adaptador torna-se maior em um cenário com grande número de
requisições simultâneas
• Muito baixo nos dois cenários, comparado ao tempo total para o
estabelecimento da chamada.
• Desempenho medido durante o reload
• Não foi afetado de maneira significativa em relação ao regime normal de
operação.
Análise dos Testes

39. • O cenário “Com Adaptador” é factível devido as seguintes
constatações :
• Desempenho apresentado nos testes
• Ganhos de flexibilização que esta busca proporciona
• Portanto esse cenário deve ser considerado como solução de
arquitetura a ser adotada
Conclusão da validação da arquitetura

40. Portal WEB

41. Portal WEB - Aprovisionamento de dados

42. Portal WEB - Menu
• Cadastro Numérico
• Numero Telefônico
• Prefixo
• Range
• Grupo de Destino
• Cadastro de Grupo de Destino
• Registros
• Domínio-Protocolo
• Domínio-Serviço
• Domínio
• Protocolo
• Serviço
• Servidores
• Grupo de Rota
• Associação Grupo de Rota
• Cadastro de Grupo de Rotas
• Carga Massiva
• Persistir Carga
• Visualizar Log
• Usuário
• Cadastro de Usuários
• Administrar
• Alterar Senha
• Grupo de Recurso
• Organizações
• Perfis
• Recursos

43. Portal WEB - Cadastro Número Telefônico

44. Portal WEB - Assoc. Grupo de Rota - Domínio

45. IETF / Speermint

46. Componentes do Speermint
• Opensips
• Desenvolvido com o fim de ser um SIP Proxy
• Não tem o foco em controlar mídia.
• Modularizado para possibilitar acréscimo de funcionalidades e aderência
a vários protocolos.
• Opensource
• Funções do Speermint
• SF e LRF
• implementadas no core do Opensips
• LUF
• implementadas no modulo ENUM do Opensips, adaptado para enviar o usuário
do RURI e o domínio (hostname ou IP) da operadora de origem.

47. Estudo de caso: InterVoIP

48. Obrigado!
www.cpqd.com.br