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

SBE-I

SIP

SSP-I SSP – SIP Service Provider

SBE – Signaling Path Border Element

SIPPara qual operadora deve ser enviado o pacote?

Speermint - elementos

SBE-I

LRF

SSP-I

LUFLUF - Look-Up Function

Determina localização do domínio de um SF (Signaling Function) de destino

SFSF - 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

SSP1

SFSIP

SBE

SF

SSP2

DBE RTPRTPDBE

LUF

Proxy Redirectou

ENUMQ: Numero_ENUM

R: Dominio (AoR)

LRF DNSQ: 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

SBE

LUF

LRF

SF

SSP

ENUM

DNS

Como aprovisionamos dados no DNS e no ENUM?

SIP

Aprovisionamento de dados

ENUM

DNSDatabase

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

Visão simplificada da arquitetura

Base de dados

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

11

SED

Grupo de Rota

n n

n

n

Peering Organization

1 n

DRINKS - Flexibilização de roteamento

Que arquitetura pode atender aomodelamento DRINKS, permitindoflexibilização no roteamento dachamada VoIP ?

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

Opções para a Arquitetura• Benchmarking realizado pela UFU:

• Bind• PowerDNS

Bind com Zone Files

PowerDNS com Mysql

Zone Files - Mysql

Como conseguir uma maiorindependência em relação aoservidor DNS ?

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.

Arquitetura adotada

Arquitetura do projeto

PowerDNS com Adaptador

• 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

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.

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++

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 )

• 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 ?

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

Modos de Configuração do Cache

Modo Replicado• Capacidade de Armazenamento

• Igual a capacidade do menor nó

• Segurança do dado• Maximizada• Cache completo em todos os nós

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.

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.

Cache Distribuído InterVoIP

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

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.

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

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.

Vazão para números existentes

Latência para números existentes

Vazão para números não existentes

Latência para números não existentes

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

• 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

• 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

Portal WEB

Portal WEB - Aprovisionamento de dados

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

Portal WEB - Cadastro Número Telefônico

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

IETF / Speermint

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.

Estudo de caso: InterVoIP

Obrigado!

www.cpqd.com.br