Upload
nguyendan
View
225
Download
0
Embed Size (px)
Citation preview
1
VoIP @ IRICUPTelefonia IP na Universidade do Porto
Orientador: Prof. Dr. Mário LeitãoCo-Orientador: Eng.º Mário SerrãoRicardo CarvalhoPSTFC – LEEC – FEUPJunho, 2006
2
• Sumário– Objectivos do estágio– Vantagens– Motivação– Protocolos– SIP vs H323– Análise de uma chamada SIP– Cenários de implementação– Endereçamento– Arquitecturas de testes – Trabalho futuro– Conclusão
3
• Objectivos do estágio– Estudo da tecnologia VoIP e seus protocolos standard Open
Source– Avaliação do impacto técnico e financeiro da migração entre
tecnologias POTS e VoIP nas infra-estruturas da Universidade do Porto
– Desenhar soluções de troca de tráfego de voz entre instituições com ligação à RCTS e avaliar o respectivo impacto no backbone da RCTS
– Estudo e proposta de soluções de endereçamento telefónico– Avaliação da disponibilidade comercial
de serviços de interligação VoIP comas várias redes telefónicas fixa e móveis
– Implementação de um piloto de testes– Realização do relatório do trabalho
4
• Vantagens– Redução de custos das chamadas– Redução de custos das infra-estruturas– Integração de serviços– Mobilidade– Serviços avançados– Melhor qualidade sonora– URIs mais fáceis de memorizar
0
500
1000
1500
2000
2500
3000
3500
4000
2002 2003 2004 2005 2006 2007 2008
PBXIP PBX
Mercado IP PBX vs PBX tradicional
Source: IDC, 2004
5
• Motivação– Integração de voz e dados na mesma infra-estrutura
de rede– Controlo sobre as comunicações
de voz até aqui subcontratado– Uso do backbone IP da UP para
encaminhar tráfego de voz entreUnidades Orgânicas
– Integração com o sistema de informação da UP– Atribuição de um contacto telefónico a cada aluno,
docente, investigador, funcionário da UP– Mobilidade fazendo uso da rede Wi-Fi e-U
6
• Protocolos– SIP
• SIP (Session Intitation Protocol) é o protocolo Standard do IETF (RFC 3261) para VoIP e outras sessões multimédia
• protocolo de sinalização usado para criar, modificar e terminar sessões com um ou mais participantes
– H323• H.323 é um standard do ITU, muito popular• Primeiro conjunto definido de standards multimédia
– SDP• Session Description Protocol, descreve sessões multimédia (conferência ou
distribuição) para efeito de anúncio, convite ou outros formas de início de sessão
– RTP• Real-time Transport Protocol, fornece um serviço de transporte de dados com
características de tempo real, de que são exemplos áudio e vídeo– RTCP
• RTP Control Protocol, fornece informação adicional aos participantes na sessão, tais como feedback sobre a QoS, sincronização entre meios, identificação dos participantes na sessão, controlo da sessão
8
• SIP vs H323
Com recurso ao DNSDefinido recentemente no Anexo G
Encaminhamento entre domínios
RFC3428-Instant Messaging
ASCIIBinárioCodificação das mensagens
TodosTodosCodecs
RTP / RTCPRTP / RTCPComunicação
SDPH.245Negociação
URIs SIPAliasesEndereçamento
Multimédia, MulticastTelefonia PSTNÊnfase
Do tipo HTTPASN.1Codificação
Maioritariamente UDPMaioritariamente TCPTransport
IETFITUOrigem
ElementarPilhaArquitectura
SIPH.323
SIP•Escalabilidade•Extensibilidade•Menor complexidade•Facilidade de implementação•Customização•Forking das chamadas•Controlo de chamadas de terceiros•As mensagens SIP são baseadas em texto•Fácil debugging através de sniffing toolscomo o tcpdump, ethereal, ngrep, netcap
H.323•Desenvolvimento começou mais cedo•Protocolo ultrapassado•Delega complexidade no servidor•Pouco escalável•Mensagens H.323 são binárias•Implementação e debug complicados
Em suma:
9
• Componentes de um sistema SIP– UA (user agent) – terminal de rede SIP
(telefones SIP, ou gateway para outras redes), contém UAC (user agent client) e UAS (useragent server)
– Servidor Proxy – Recebe pedidos de ligação de um UA e transfere-o para outro servidor proxy se o receptor não estiver no seu domínio
– Servidor de Redireccionamento – Recebe pedidos de ligação e envia-os de volta ao emissor incluindo os dados de destino ao invés de enviá-los directamente à parte chamada
– Servidor de localização – recebe pedidos de registro de um UA e actualiza a base de dados de terminais com eles
10
• Análise de uma chamada SIP
Não pudemos deixar fluirassim, dada a necessidade
de controlo e accounting(os proxies têm que incluir ocampo Record-Route nas
mensagens)
12
• Cenários de implementação– Integração do VoIP com o PBX já existente
• PABX entre PSTN e Servidor VoIP
– Pode ser usado um acesso BRI (admitindo no máx. 2 chamadas simultâneas), ou PRI (até 30 chamadas simultâneas). Nos PBX actuais, a carta de interfaceRDIS já existe no sistema.
– Interfaces PRI são economicamente preferíveis em cenários onde mais de 8 canais (4xBRI) são necessários.
LAN da UO
Trunk
PABX
POT
POTPOT
PSTN
Gateway / Servidor VoIP
Trunk IP Telco
Backbone IP da UP
RCTS
Unidade Orgânica
GSM gateway
13
• Cenários de implementação– Integração do VoIP com o PBX já existente
• Servidor VoIP entre PABX e PSTN:
– Grande vantagem: inteligência e configurações de endereçamento é feita no servidor VoIP - nenhuma configuração na central telefónica comutada
– Evita-se assim a necessidade sempre dispendiosa e morosa de contratar serviços a terceiros para reconfigurar o PABX
– Desvantagem em casos de falha da infra-estrutura IP do servidor, o tráfego entre PABX e PSTN ficar cortado – necessário mecanismo de bypass
LAN da UO
PABX
POT
POTPOT
PSTN
Gateway / Servidor VoIP
Trunk
IP Telco
Backbone IP da UP
RCTS
POT
Trunk
Unidade Orgânica
14
• Cenários de implementação– Substituição completa do PBX por VoIP:
• PROS– Sinalização SIP permite inteligência dos terminais – funcionalidades avançadas– Plano de encaminhamento de chamadas com rede pública de móveis– Todos os contactos numa BD integrável com o sistema de informação
• CONS– Por segurança manter um número mínimo de DDIs contratado– Funcionalidades avançadas e displays interactivos dos terminais encarece-os– Terminais requerem alimentação eléctrica, externa ou Power-over-Ethernet
LAN da UO
Trunk
PSTN
Gateway / Servidor VoIP
IP Telco
Backbone IP da UP
RCTS
Unidade Orgânica
GSM gateway
15
• Endereçamento– Um utilizador para comunicar necessita de um
identificador para si e para o receptor da chamada – Encontra-se em avaliação por parte da FCCN a
necessidade de existência de um serviço de directório em cada instituição, ligado a um serviço de directório RCTS, para poder facilitar a pesquisa de contactos telefónicos
– Cada identificador deve ser independente da localização física do utilizador
– Cada utilizador pode ter mais que um endereço IP, ou seja, ser alcançável, por exemplo, em várias localizações físicas
16
• Endereçamento na UP– Dois tipos de identificadores,
URIs e Numeração E.164– O utilizador pode
ser encontradoatravés do DNS
– Desvantagem dos URIs: dificuldade ou até mesmo a impossibilidade de serem digitados em certos terminais
– O plano de numeração tradicional não se coaduna muito bem à Internet tal como a conhecemos baseada em domínios, por essa razão foi criado o sistema ENUM que faz uso dos números telefónicos tradicionais como domínios.
17
• Endereçamento na UP – Sistema ENUM– ENUM como alternativa ao Endereçamento
Estático - limitado pois não é escalável– ENUM - Sistema hierárquico de
endereçamento ao estilo dos URLs, que escala– ENUM faz a transformação de um endereço
E.164, atribuído a um terminal, num endereço URI
– Ponte entre endereçamento PSTN e Internet– Usa o DNS para traduzir números E.164 em
esquemas IP
18
• Endereçamento na UP – Sistema ENUM– Forma de Least Cost Routing dado que um
servidor com ENUM apenas encaminha a chamada para a PSTN se não houver rota em IP
Manter tráfego em IP evita custos de passagem na PSTN e proporciona melhor QoS por evitar codificações sucessivas IP-PSTN
PSTN
Rede VoIPUnidade Orgânica 2
Rede VoIPUnidade Orgânica 1
Sem ENUM
Com ENUM
Mantém-se na rede IP
19
• Endereçamento na UP – Sistema ENUM– Para tal é necessário registar cada número E.164
com rota também por IP num serviço de directório
– Escalabilidade do ENUM• Centenas de milhões de registos• Dezenas de resoluções de endereços por segundo
– Questões de segurança e privacidade dos dados pessoais de contacto dos utilizadores não devem ser descuradas, no entanto é o que hápara já, até que a FCCN crie um serviço de directório RCTS – até láusar p.ex. e164.org ou e164.arpa
20
• Endereçamento na UP – Sistema ENUM– Exemplo:
Núvem de DNS(Internet)
Rede IP
Utilizador marca 223401572
Servidor SIPIRICUP
Servidor SIP pergunta ao DNS se tem rota em IP entregando-lhe
2.7.5.1.0.4.3.2.2.1.5.3.e164.org
Servidor SIPUO A
DNS responde:sip:[email protected]
Através do DNS, o Servidor SIP A encontra o B
É chamado sip:[email protected]
1
2
3
4
5
INVITE 223401572
21
• Arquitecturas de testes - Software– SER (SIP Express Router)
• Implementa o SIP AAA• Opera como Proxy SIP ou apenas como router (Servidor de
Localização ou Servidor de redireccionamento)• Suporta Radius, PgSQL, MySQL• SERweb para administração dos clientes via web• Integrável com RTPproxy• Apenas um ficheiro de configuração
– Asterisk• Suporta SIP, H323, IAX, MGCP, Skinny, etc.• PBX completo com serviços avançados (voicemail, chamada
em conferência, music on hold)• PSTN gateway• Muitos ficheiros de configuração
22
• Arquitecturas de testes – Software– Porque não apenas Asterisk?
• Não é um servidor SIP completamente funcional• Não suporta milhares de clientes como o SER• Não é um Proxy SIP completo, opera melhor como
Servidor de Redireccionamento e Servidor de Localização
• Funciona como UA SIP entre as chamadas– Processamento acrescido pois reescreve as mensagens
• Esta dependência do Servidor SIP não se coaduna à filosofia distribuída do SIP
– Um Proxy SIP nunca deve ser o término da chamada, e nunca deve tratar o stream de dados tal como o Asteriskfaz
23
• Arquitecturas de testes– SER + Asterisk
• Aumenta as capacidades do sistema• SIP Router independente do Asterisk• Retirado do Asterisk a responsabilidade sobre o
registo dos terminais e encaminhamento das chamadas entre terminais SIP
• Asterisk fica apenas responsável pelas tarefas de gateway e serviços avançados (como o Voicemail)
• SER passa a chamada ao Asterisk apenas se constarem permissões para o seu originador na BD
24
• Arquitecturas de testes – Software adicional– RTPproxy
• Usado para obrigar o fluxo RTP a passar pelo servidor• Ajuda o SER a contornar problemas de NAT
– PostgreSQL + PhpPgAdmin– Distro Linux
RTPproxynão
instalado
25
• Arquitecturas de testes– Tabelas da BD para o SER
Mantém registo das chamadas
efectudas
Registo da contabilização dos
custos das chamadas
Registo das chamadas não
atendidas ou não iniciadas pelo facto do
destinatário não possuir nenhum
telefone registado
Registo de usernamesalternativos para cada
contactoPermissões que cada utilizador possui, para ter direito a Voicemail,
PSTN, etc. Quem em tempo-real tem o seu terminal
registado
Tabela principal do registo dos utilizadores
do sistema
O uso de tabelas como estas permite a fácil integração com o sistema de informação da UO, tal como no IRICUP o Sigarra
26
• Arquitecturas de testes– Encaminhamento para uma IP Telco/etc/asterisk/sip.conf
/etc/asterisk/extensions.conf
Utilizador marca número PSTN
SER verifica que utilizador tem permissões na tabela grupo
Chamada atirada para o Asterisk
Asterisk concatena restantes indicativos e envia INVITE SIP
a voipstunt
27
• Arquitecturas de testes– Trixbox (antigo Asterisk@Home)
• PROS– Rápido e fácil de instalar – “up and running in one hour”– Fácil de operar – tudo interface web– Fácil de configurar para ambientes pouco exigentes e pequenos– Muitas funcionalidades avançadas– Bom para tirar ideias para um sistema em produção
• CONS– Imensos ficheiros de configuração e com uma sintaxe demasiado
elaborada, tornam sistema pouco adaptável para cenários mais elaborados de implementação
– Todas as desvantagens do Asterisk aplicam-se aqui também– Demasiados serviços a correr tornam a carga de processamento
desnecessariamente pesado para ambientes mais exigentes
28
• Arquitecturas de testes– Trixbox
• O servidor éproxy de RTP
• O servidor revela uma sinalização estranha, que dever-se-á ao facto de actuar como UA, reescrevendo as mensagens SIP apenas enviando as que entende necessárias ao outro extremo
• Com uma interface Fast Ethernet conseguir-se-áteoricamente 100Mbit/100Kbit=1000 chamadas simultâneas
29
• Arquitecturas de testes - Ferramentas• Ethereal, tcpdump, ngrep• Stress tests:
– SipSak– Sipp
- Mais depressa que o servidor, crashou a firewall com tantos pedidos de início de ligações !
- Não era esse o intuito, mas já agora, deve consciencializar para o perigo de ataques DOS
./sipp -r 2000 -i 192.168.141.121 192.168.141.135:5060 -s 105722
Geradas 2000 ligações UDP por segundo
30
• Arquitecturas de testes– Voicemail
• Na tabela “grupo” cada utilizador que queira possuir voicemail activo tem que lá constar com o atributo “voicemail”
• Um utilizador entra no voicemail quando tenta ligar para alguém que existe no sistema mas que não tem nenhum telefone registado de momento no sistema, ou tem, mas não atende
• É enviado um e-mail ao utilizador chamado com a mensagem como ficheiro wav em anexo
• Cada utilizador pode aceder à sua caixa postal através do número 200 (caso esteja a ligar do seu terminal, ou através do 201 caso esteja a ligar do terminal doutrem
31
• Metas futuras– Integração com Radius e LDAP para Autenticação– Experimentar uma implementação Asterisk Real Time– Implementação de mais serviços avançados tal como a
chamada em conferência iniciada no servidor ou music onhold
– Fazer bypass para a PSTN para situações de quebra do serviço IP
– Testes de carga às diversas implementações com o objectivo de inferir sobre a mais escalável
– Ligação do servidor VoIP a um PBX tradicional para adquirir know how na desagregação de tráfego num cenário de transição
– Estudo e discussão sobre a implementação LAN e WAN– Testes e familiarização com outras soluções proprietárias
32
• Conclusão– VoIP é todo um ponto de viragem da história
das telecomunicações, e tenho orgulho e entusiasmo em estar a participar nesta revolução!
– Apesar de não ser visível, houve muito trabalho por trás de tudo isto, desde estudo dos protocolos, aprofundamento dos conhecimentos em Linux, dificuldade em esclarecer dúvidas de implementação visto que é algo muito emergente