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

7

• Protocolos

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)

11

• Cenários de implementação– Cenário tradicional:

– Alternativa pouco interessante:

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:105721@iric.up.pt

Através do DNS, o Servidor SIP A encontra o B

É chamado sip:helpdesk@iric.up.pt

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

33

• Questões?

http://paginas.fe.up.pt/~ee97154/rcarvalho@iric.up.pt