• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Projeto InterVoIP - Arquitetura - I Workshop CPqD de Inovação Tecnológica em VoIP Peering
 

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

on

  • 398 views

 

Statistics

Views

Total Views
398
Views on SlideShare
398
Embed Views
0

Actions

Likes
0
Downloads
5
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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

    • 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-ISIPSSP-I SSP – SIP Service ProviderSBE – Signaling Path Border ElementSIPPara qual operadora deveser enviado o pacote?Speermint - elementos
    • 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
    • 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
    • SBELUFLRFSFSSPENUMDNSComo aprovisionamos dados noDNS e no ENUM?SIPAprovisionamento de dados
    • 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
    • Visão simplificada da arquitetura
    • Base de dados
    • 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
    • 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 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.
    • Arquitetura adotadaArquitetura do projetoPowerDNS com Adaptador
    • • 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
    • 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.
    • 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 deregistros um outro requisito...• Escalabilidade de dados• Como alocar em memória umagrande quantidade de registros deforma 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 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.
    • 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.
    • Cache Distribuído InterVoIP• Consulta base de dados relacional, modelada segundo o DRINKS e alocaos registros em um cache distribuído chave-valor.
    • 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.
    • 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
    • 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.
    • 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• 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
    • • 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
    • • 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
    • 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ê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.
    • Estudo de caso: InterVoIP
    • Obrigado!www.cpqd.com.br