0
Agenda• Contexto e desafios do Projeto InterVoIP (CPqD)• Apresentação do Projeto InterVoIP, motivação e etapas• Conceitos•...
SBE-ISIPSSP-I SSP – SIP Service ProviderSBE – Signaling Path Border ElementSIPPara qual operadora deveser enviado o pacote...
SBE-ILRFSSP-ILUFLUF - Look-Up FunctionDetermina localização do domínio de umSF (Signaling Function) de destinoSFSF - Signa...
SSP1SFSIPSBESFSSP2DBERTPRTPDBELUFProxy RedirectouENUMQ: Numero_ENUMR: Dominio (AoR)LRFDNSQ: SRV Dominio (AoR)R: FQDN/IP Po...
SBELUFLRFSFSSPENUMDNSComo aprovisionamos dados noDNS e no ENUM?SIPAprovisionamento de dados
ENUMDNSDatabaseSugere modelamento para aprovisionamento de dados de encaminhamento:Operadora BInseridos pelo SSP destino –...
Visão simplificada da arquitetura
Base de dados
Fatores de decisão(custo, horário, etc)NumeroTelefônicoRange deNumeraçãoPrefixoGrupo deDestinonnn1ENUMRecord Domínionn 11S...
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• Es...
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 DNSem tempo de compilação.• Trabalha integrada a backend...
Arquitetura adotadaArquitetura do projetoPowerDNS com Adaptador
• Por que PowerDNS ?• Concebido com a premissa de serextensivel.• Possui vários backendsimplementados• Lembrando que um do...
Servidor de Consultas• Recebe consultas do DNS e encaminhaao mecanismo de resolução• Alta disponibilidade• Escalável horiz...
Protocolo de transmissão• Google Protocol Buffers• Abstrai a complexidade da definição de um protocolo binário• Protocolo ...
Mecanismo de Resolução• Traduzir chave DNS para registro correspondente• Pelo fato da resolução ser interna ao InterVoIP p...
• Para atender a mais um requisito...• Alta vazão• Registros devem estar na memória• Devido ao grande volume deregistros u...
Cache Distribuído• MenCached• Standalone• JBoss Infinispan• Standalone• Embedded• Opção escolhida:• JBoss Infinispan Embed...
Modos de Configuração do Cache
Modo Replicado• Capacidade de Armazenamento• Igual a capacidade do menor nó• Segurança do dado• Maximizada• Cache completo...
Modo Distribuído• Capacidade de Armazenamento• Maximizada• Igual a soma da capacidade detodos os nós• Segurança do dado• O...
Modo Distribuído parcialmente Replicado• Capacidade de Armazenamento• > que cenário Replicado.• < que cenário Distribuído....
Cache Distribuído InterVoIP• Consulta base de dados relacional, modelada segundo o DRINKS e alocaos registros em um cache ...
Validação da Arquitetura• Nessa arquitetura o desempenho da aplicação passa a depender nãosomente do servidor DNS.• Após a...
Validação da arquitetura• Para formular uma metodologia de teste, devemos consideraraspectos não funcionais, relativos ao ...
Testes de desempenho do DNS• Backend padrão versus backend com adaptador.• Testes realizados para números existentes e não...
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 estimadapara uma carga de 1 milhão denúmeros telefônicos• ...
• 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 ...
• O cenário “Com Adaptador” é factível devido as seguintesconstatações :• Desempenho apresentado nos testes• Ganhos de fle...
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• R...
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.• Modula...
Estudo de caso: InterVoIP
Obrigado!www.cpqd.com.br
Upcoming SlideShare
Loading in...5
×

Projeto InterVoIP - Arquitetura - I Workshop CPqD de Inovação Tecnológica em VoIP Peering

166

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
166
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "Projeto InterVoIP - Arquitetura - I Workshop CPqD de Inovação Tecnológica em VoIP Peering"

  1. 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. 2. SBE-ISIPSSP-I SSP – SIP Service ProviderSBE – Signaling Path Border ElementSIPPara qual operadora deveser enviado o pacote?Speermint - elementos
  3. 3. SBE-ILRFSSP-ILUFLUF - Look-Up FunctionDetermina localização do domínio de umSF (Signaling Function) de destinoSFSF - Signaling FunctionEnvia as requisições SIP paraestabelecimento e manutenção de sessõesLRF - Location Routing FunctionDetermina SED necessária pararoteamento da requisiçãoSED (Session Establishment Data)Dados necessários para rotear uma chamada parao próximo salto:. FQDN ou IP. Porta. Protocolo de Transmissão. Segurança. Outros parâmetros de controleSpeermint - elementosSIP
  4. 4. SSP1SFSIPSBESFSSP2DBERTPRTPDBELUFProxy RedirectouENUMQ: Numero_ENUMR: Dominio (AoR)LRFDNSQ: SRV Dominio (AoR)R: FQDN/IP PortaProtocolo TransmissãoSpeermint - como funcionaSIPSBELUF- Realiza consulta ENUM- Retorna o domínio AoR(sip:bob@example.com)- Se não resolver, pode enviar para PSTNDBE- Data Path border Element- Elemento de borda por onde passa o tráfegode mídia.LRF- Descobre próximo salto a partir dodomínio de destino- Resolução DNS: NAPTR (Transporte) /SRV (Porta) / A (Endereço) – rfc 3263
  5. 5. SBELUFLRFSFSSPENUMDNSComo aprovisionamos dados noDNS e no ENUM?SIPAprovisionamento de dados
  6. 6. ENUMDNSDatabaseSugere modelamento para aprovisionamento de dados de encaminhamento:Operadora BInseridos pelo SSP destino – RegistrantOperadora BConsumido pela SSP que origina achamada ou uma SSP IntermediariaDRINKS - Aprovisionamento de dados
  7. 7. Visão simplificada da arquitetura
  8. 8. Base de dados
  9. 9. Fatores de decisão(custo, horário, etc)NumeroTelefônicoRange deNumeraçãoPrefixoGrupo deDestinonnn1ENUMRecord Domínionn 11SRV RecordNAPTR RecordA Recordn111SEDGrupo deRotan nnnPeeringOrganization1 nDRINKS - Flexibilização de roteamento
  10. 10. Que arquitetura pode atender aomodelamento DRINKS, permitindoflexibilização no roteamento dachamada VoIP ?
  11. 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. 12. Opções para a Arquitetura• Benchmarking realizado pela UFU:• Bind• PowerDNS
  13. 13. Bind com Zone Files
  14. 14. PowerDNS com Mysql
  15. 15. Zone Files - Mysql
  16. 16. Como conseguir uma maiorindependência em relação aoservidor DNS ?
  17. 17. Abstração através de um Adaptador• Biblioteca linkada ao servidor DNSem tempo de compilação.• Trabalha integrada a backendcustomizado do servidor DNS.• Recebe as consultas enviadas aoservidor DNS e repassa aresolução ao InterVoIP.• Faz uso de sockets e trafegaprotocolo binário, definido sobmedida, com baixo overhead.
  18. 18. Arquitetura adotadaArquitetura do projetoPowerDNS com Adaptador
  19. 19. • Por que PowerDNS ?• Concebido com a premissa de serextensivel.• Possui vários backendsimplementados• Lembrando que um dos requisitos...Facilidade de implementação• Por outro lado ...• Para que seja satisteito mais umrequisito da arquitetura:Aderência à infra-estrutura de TI• Apenas acoplar Adaptador ao novoservidor DNS• Demais módulos são reaproveitados
  20. 20. Servidor de Consultas• Recebe consultas do DNS e encaminhaao mecanismo de resolução• Alta disponibilidade• Escalável horizontalmente.• Alto desempenho• Load Balancer via ha-proxy.• JBOSS Netty• Abstrai a complexidade daprogramação com sockets.
  21. 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. 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. 23. • Para atender a mais um requisito...• Alta vazão• Registros devem estar na memória• Devido ao grande volume deregistros um outro requisito...• Escalabilidade de dados• Como alocar em memória umagrande quantidade de registros deforma confiante e escalável ?
  24. 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. 25. Modos de Configuração do Cache
  26. 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. 27. Modo Distribuído• Capacidade de Armazenamento• Maximizada• Igual a soma da capacidade detodos os nós• Segurança do dado• O dado está presente em um úniconó• Se um nó apresentar falha, partedos dados deixarão de estar namemória.
  28. 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 osdados.
  29. 29. Cache Distribuído InterVoIP• Consulta base de dados relacional, modelada segundo o DRINKS e alocaos registros em um cache distribuído chave-valor.
  30. 30. Validação da Arquitetura• Nessa arquitetura o desempenho da aplicação passa a depender nãosomente do servidor DNS.• Após a definição da arquitetura e implementação de um mínimo necessárioforam efetuados testes de validação da arquitetura.
  31. 31. Validação da arquitetura• Para formular uma metodologia de teste, devemos consideraraspectos não funcionais, relativos ao desempenho e a capacidadede 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. 32. Testes de desempenho do DNS• Backend padrão versus backend com adaptador.• Testes realizados para números existentes e não existente em queo DNS é autoritativo.• Utilizamos a ferramenta opensource dnsperf.• Para os dois cenários foi utilizada uma base com 1 milhão denúmeros cadastrados.• Foram considerados várias configurações de cache para o DNS,fizemos uma analise comparativa com a configuração mais coerentepara o estudo dos dois cenários.
  33. 33. Vazão para números existentes
  34. 34. Latência para números existentes
  35. 35. Vazão para números não existentes
  36. 36. Latência para números não existentes
  37. 37. Alocação de memória com uso do Adaptador• Quantidade de memória estimadapara uma carga de 1 milhão denúmeros telefônicos• Tempo de carga da base de dadospara RAM• Tempo aferido para carga em umamáquina• Arquitetura Intel i7 2600 64bits - 3.4 Ghz• 8G RAM730 MBytes52 segundos
  38. 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ãoparecidos• Bom desempenho nos dois cenários, considerando o fluxo de chamadaVoip• Tempo de Latência• Com adaptador torna-se maior em um cenário com grande número derequisições simultâneas• Muito baixo nos dois cenários, comparado ao tempo total para oestabelecimento da chamada.• Desempenho medido durante o reload• Não foi afetado de maneira significativa em relação ao regime normal deoperação.Análise dos Testes
  39. 39. • O cenário “Com Adaptador” é factível devido as seguintesconstatações :• Desempenho apresentado nos testes• Ganhos de flexibilização que esta busca proporciona• Portanto esse cenário deve ser considerado como solução dearquitetura a ser adotadaConclusão da validação da arquitetura
  40. 40. Portal WEB
  41. 41. Portal WEB - Aprovisionamento de dados
  42. 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. 43. Portal WEB - Cadastro Número Telefônico
  44. 44. Portal WEB - Assoc. Grupo de Rota - Domínio
  45. 45. IETF / Speermint
  46. 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ênciaa 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áriodo RURI e o domínio (hostname ou IP) da operadora de origem.
  47. 47. Estudo de caso: InterVoIP
  48. 48. Obrigado!www.cpqd.com.br
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×