TIP-2013-1-Integrado Telefonia IP - Integrado

De MediaWiki do Campus São José
Ir para navegação Ir para pesquisar

Professor

Marcelo Maia Sobral email: msobral@ifsc.edu.br

Plano da da Disciplina

Cronograma

AULA DATA Descriçao
1 2/4/2013 Apresentação da ementa. Revisão histórica. A PSTN. A voz digitalizada. Sinalização e transporte da mídia. Telefonia clássica versus telefonia IP (comutação de circuitos versus comutação de pacotes). Problemas associados a telefonia IP: tabela comparativa com PSTN.
2 9/4/2013 O projeto da disciplina. Cenário de comunicação direta entre terminais. Cenário de comunicação intra-IP PABX. Cenário com múltiplos IP PABX. Cenário de interligação com PSTN. Serviços adicionais almejados.
3 16/4/2013 Protocolos de Sinalização. Sinalização SIP. Cenário de sinalização direta entre terminais. Softfones. Telefones IP.
4 23/4/2013 Cenário de sinalização intracentral. Instalação do Asterisk. Configuração. Análise da sinalização.
5 30/4/2013 Cenário de sinalização intercentral. Configuração do Asterisk. Análise da sinalização.
6 7/5/2013 A transmissão da mídia. Codecs. Negociação usando o SDP/SIP. Análise da negociação.
7 14/5/2013 A transmissão de mídia. Protocolos RTP and RTCP. Análise de jitter, latência, erros.
8 21/5/2013 Entroncamentos SIP entre PBX IP.
9 28/5/2013 A transmissão de mídia: problemas de rede, NAT, STUN, ICE
10 4/6/2013 Avaliação I.
11 11/6/2013 Qualidade de serviço e telefonia IP; Internetworking com PSTNs. MGCP e MEGACO. Uso dos equipamentos da KHOMP.
12 18/6/2013 Definição do projeto final de cada grupo. Serviços adicionais desejados.
13 25/6/2013 Desenvolvimento de Projeto
14 2/7/2013 Desenvolvimento de Projeto
15 9/7/2013 Desenvolvimento de Projeto
16 16/7/2013 Desenvolvimento de Projeto
17 23/7/2013 Apresentação de projetos
18 30/7/2013 Recuperação final

Avaliações

Matrícula Prova 1 Projeto Conceito final Faltas
092608044-0 B A B 5
092608070-9 C B C 0
092608066-0 C B C 2
092608002-4 C A B 2
092608010-5 C B C 4
092608046-6 B A B 2
092608062-8 A 18
092608073-3 B B B 1
092608063-6 B B B 3
092608057-1 B A B 5
092608050-4 A 12
092608017-2 B A B 2
092608029-6 C C C 8
092608023-7 B A B 4

Listas de exercícios

AULA DIA 02/04/2012

  • Apresentação da ementa.
  • Revisão histórica. A PSTN.
  • A voz digitalizada.
  • Sinalização e transporte da mídia.
  • Telefonia clássica versus telefonia IP (comutação de circuitos versus comutação de pacotes).
  • Problemas associados a telefonia IP: tabela comparativa com PSTN.

Revisão histórica. A PSTN

Até 10 anos atrás a base da comunicação de voz através de rede de telecomunicações era a Rede Pública de Telefonia (PSTN). Esta rede ainda é amplamente usada mas está perdendo força para a (Ii)nternet.

São característiscas desta rede:

  • fios ou circuitos dedicados para a comunicação da voz;
  • permite a comunicação duplex;
  • proporciona qualidade para transmissão da voz (até 3400Hz)
  • é baseada em comutação de circuitos
  • hoje é baseada quase que totalmente na transmissão digital mas até pouco tempo usava a transmissão analógica.
  • Existe desde o século XIX

Transformação da voz em sinal elétrico e a transmissão

Através de um transdutor é possível converter o sinal sonoro (onda mecânica) em um sinal elétrico que varia no tempo.

Exemplo1: microfone de carvão

Usando uma fonte dc com este microfone é possível conceber um sistem em que o sinal elétrico gerado pelo microfone é amplificado e transmitido por fios (2 fios). O receptor pod aplicar o sinal em um alto-falante, que faz o reverso do microfone.

Um sistema duplex necessitaria neste caso de 4 fios mas é possível usar um dispositivo para mesclar os dois sinais (híbrida). 

Desta forma, é pssível transmitir e receber voz com dois fios simultaneamente.
Os fios devem partir de um telefone associado a um usuário até o outro telefone.
NOTE que estes fios são dedicados a comunicação entre estes dois usuários!

Chaveamento de circuito - o papel da operadora

No item acima observamos que é possível transmitir e receber voz entre dois usuários. Entretanto, logo após as invenções dests tecnologias, observou-se que, para fins de otimização, todos os telefones deveriam estar ligados a uma central. 

 O uso da central evita uma conexão permanente de todos para todos, o que
 inviabilizaria o sistema.

Então, inventou-se as centrais telefônicas.

Inicialmente que operava a central era um ser humano. Logo a seguir, estes dispositivos foram automatizados.

Necessidade de um protocolo de sinalização

De alguma forma, o chamador do sistema de telefonia, deveria indicar com quem ele deseja se comunicar. O usuário chamado deve receber um sinal audível e proceder o atendimento. É um protocolo conhecido por todos nós. Mas uma série de eventos acontece na prática:

  1. o usuário retira o telefone do gancho e a central detecta este evento e põe-se a escutar a linha do chamador;
  2. o chamador disca o número desejado (interrupções de um sinal dc da linha);
  3. a central observa o número de interrupções e o associa a um circuito a ser chamado.
  4. a central coloca um sinal audível de chamada na linha do usuário chamado (e também uma pequeno sinal para o chamador);
  5. o usuário chamado atende e a central detecta o atendimento;
  6. a central interconecta o circuito do chamador com o circuito chamado.
Pronto, a comunicação pode se dar entre os dois usuários.


Fica evidente a necessidade de duas componentes do sistema: a sinalização e o transporte da informação propriamente dita.

Exercício: Fazer um diagrama de troca de mensagens no tempo, composto pelos três elementos básicos de uma comunicação telefônica: chamador, chamado e a central telefônica.

Digitalização do sinal de voz e da sinalização

Você já deve saber que a tendência é a representação digital binária de qualquer 
informação. Isto facilita o seu processamento, transmissão e armazenamento 
(se necessário).

O sistema telefônico foi quase que completamente digitalizado. No caso particular do sinal da voz, procede-se um processo de amostragem e de quantização para a geração de uma sequência de bits associada ao sinal de voz. Trata-se da técnica chamada PCM.

Nesta técnica amostra-se o sinal analógica a uma frequência específica (sampling rate). No caso da telefonia esta frequência é de 8000 vezes por segundo (8khz). Cada amostra é transformada em um agrupamento de 8 bits (um byte). Por que 8000 khz. É uma limitação teórica descoberta por Nyquist que diz que a a frequência de amostragem deve ser duas vezes maior que a maior frequência que compõe o sinal. Para a transmissão da voz, a frequência limite é 4khz. 

  LEMBRE que um sinal no tempo pode ser descrito pela soma de senóides. Desta forma, um sinal pode
  também ser descrito no domínio da frequência, ou seja pelas frequências e fases das senóides que
  o compõem.

Ver a representação no domínio da frequência aqui. 

 NOTE que amostragem de 8Khz com 8 bits por amostragem leva a uma taxa de transmissão de 64kbps

Ou seja, se você digitalizar a voz e transmitir por um par de fios, a taxa de transmissão deverá ser de no mínimo 64kbps. Uma linha telefônica (fixa) que chega a sua casa via fios, possivelmente ainda é analógica (loop local, mas assim que ela chegar em uma central será digitalizada a esta frequência.

As centrais como chaveadoras de circuitos

Entre centrais telefônicas e entre centrais e PABXs normalmente os enlaces são realizados por troncos E1 (ou hierarquias destes troncos). Nestes sistemas os canais digitais são multiplexados no tempo (ver aqui).

Em uma ligação telefônica que passa por várias sinais, toda a sinalização é repassada de forma digitalizada por canais adicionais no E1 (ou uma variante disto). O chaveamento de circuito é espacial e temporal, ou seja um determinado slot de tempo de uma linha física é mapeado em outro slot de tempo em outra linha física. Com todo mapeamento realizado, a conexão entredois telefones interligados por várias centrais é se passa como se fossem dois fios.

Redes com chaveamento por pacotes versus chaveadas por circuitos

Um ponto chave da rede PSTN é que, sendo baseada em chaveamento de circuitos proporciona uma ligação permanente entre dois terminais telefônicos. Mesmo que um usuário não fale nada, os recursos estão alocados para a comunicação. Esta abordagem tem vantagem e desvantagem. A vantagem é a qualidade da comunicação: os recursos estão lá e não são disputados por ninguém. A desvantagem é o desperdício de recursos. Se o usuário não fala desperdiça um recurso valioso.

As redes de pacotes seguem uma abordagem diferente. A informação a ser transportada (qualquer que seja), é organizada na forma de pacotes de bits. Estes pacotes, pelo menos naquelas sem conexão, possuem endereço de destino e de fonte. Todas os enlaces de conexão entre "centrais" são multiplexados em termos de pacotes. Em uma mesma linha, podem seguir pacotes de diferentes origens/destinos. As centrais na realidade são chamadas de roteadores, que chaveiam pacotes para outros enlaces conforme o destino do pacote e a informação de uma tabela de roteamento.

Exemplo 1

Exemplo 2

Uso de redes de pacotes (Internet) para a transmissão de mídias diversas

Originalmente a Internet foi concebida para a transmissão de dados que não tinham requisitos fortes de tempo. Por exemplo, o envio de um email pode demorar alguns minutos até chegar no seu destino. Entretanto, com os avanços em todos os campos das telecomunicações e da computação, conseguiu-se meios de transmissão com altíssima capacidade de transmissão bem como roteadores com grande velocidade de chaveamento. Tudo isto possibilitou que se começasse a usar a Internet para o transporte para outras mídias, tal como a voz e vídeo em tempo real.

Surge uma nova área que é a telefonia IP. Todos os serviços até então construídos sobre as PSTNs começam a ser construídos sobre a Internet.

Um sério problema ainda não resolvido na transmissão de vozo edital para o pes em tempo real (e vídeo també) é a questão da qualidade de serviço. Pacotes podem sofrer atrasos, corrompidos, duplicados ou perdidos. Não é possível ainda garantir qualidade na transmissão. O que se faz é colocar recursos de sobra para não se ter problemas...

Aula Dia 9/04/2013

Objetivos

Ao final da aula o aluno deverá:

  • reconhecer a necessidade de um protocolo para sinalização para uso em aplicações de telefonia na Internet;
  • se familiarizar com protocolo SIP como protocolo de sinalização na Internet;
  • identificar as principais troca de mensagens do protocolo SIP utilizado entre dois terminais (softfones);
  • ter uma visão geral do projeto a ser desenvolvido e estendido.

O que é preciso para voz sobre IP

Pelo menos um ou mais protocolos de sinalização e um ou mais protocolos para transportar a mídia. Em adição, é conveniente comprimir a voz para que ela use menos banda e e, se necessário, forneça algum sigilo na comunicação.

Para sinalização tem-se várias opções. A principal hoje é o protocolo SIP. Para o transporte da voz utiliza-se normalmente o RTP/UDP.

Além disto, é conveniente interconectar a PSTN com o sistema de voz sobre IP.

A sinalização na Internet

A sinalização na telefonia sobre IP é necessária para:

  • chamar um usuário com quem se deseja comunicar;
  • negociar parâmetros de comunicação (para a sessão a ser estabelecida;
  • renegociar parâmetros de comunicação durante uma sessão em andamento;
  • finalizar uma sessão.

Outras funções avançadas são realizadas pelo protocolo de sinalização, mas por enquanto nos concentraremos nas funções acima.

Existem vários protocolos de sinalização, mas o SIP é um dos mais utilizados, sendo inclusive adotado nos sistemas celulares 3G e 4G.

O protocolo SIP

O SIP é um protocolo de sinalização para comunicação multimedia, que se utiliza de mensagens textos (similar ao http) e de endereços similares ao de um email. Como no http ele se utiliza de um modelo de transações do tipo requisição/resposta. Um cliente gera uma requisição a um servidor. O servidor recebe a requisição, invoca um determinado método, e responde ao cliente. A lista de métodos possíveis pode ser encontrada aqui.

Um cliente tipicamente gera uma requisição INVITE para solicitar uma sessão para um servidor. Se aceito, o servidor responde com 200 OK.

No vocabulário SIP, uma requisição é gerada por User Agent Client (UAC) e a resposta é dada por um User Agent Server (UAS). 

 NOTE que um telefone IP ou um softfone SIP funciona tanto como UAS como UAC pois ora 
 gera requisições ora aceita requisições.

O endereço SIP ou SIP URI é utilizado como identificador único de um usuário, funcionando da mesma forma que um número telefônico. Como agora estamos falando de sinalização na Internet, este endereço se utiliza de conceitos associados a esta rede. Note também que a sinalização SIP pode seguir caminhos diferentes do transporte da mídia.

A forma mais simples de usar um SIP URI é simplesmente: 

 usuario@<endereço_ip>

ou 

 usuario@<nome_dns_maquina>

Por exemplo, na figura abaixo joao chama maria que se encontra em PC de endereço IP 200.200.200.1 na rede 200.200.200.0/24. A URI usada é simplesmente maria@200.200.200.1. A mensagem de sinalização é enviada para o IP indicado usando o sistema de roteamento da Internet. Por default, as mensagens são transportadas pelo protocolo UDP e a porta de destino default é 5060. 

joao       INVITE maria@200.200.200.1       maria
     |---------------------------------->|
     |          TRYING                   |
     |<----------------------------------|
     |          RINGING                  |
     |<----------------------------------|  
     |          200 OK                   |
     |<----------------------------------|
     |           ACK                     |
     |---------------------------------->|
     |                                   |
     |<----- conversação --------------->|
     |                                   |
     |          BYE                      |
     |<----------------------------------|
     |          200 OK                   |
     |---------------------------------->|

Experimento 1: Comunicação direta entre dois terminais (softphones)

Neste experimento faremos dois terminais (softphones) estabelecerem uma sessão de comunicação através de uma sinalização direta (sem servidores SIP intermediários). Isto nos permitirá analisar as mensagens báscias de estabelecimento de chamada (INVITE) e de finalização da sessão (BYE).

Recursos utilizados

  • softfone Twinkle instalado no Ubuntu. Ver aqui o manual do twinkle.
  • wireshark/tcpdump. Ver aqui o manual do Wireshark;

Softfone Twinkle

Neste experimento usaremos o softfone Twinkle como terminal de comunicação. O Twinkle é um softfone para VOIP e comunicações de messagens instantâneas usando o SIP. Ele permite a conexão direta fone-fone ou através do uso de uma rede de servidores SIP.

Roteiro PARTE 1 - Comunicação entre usando um hospedeiro e uma máquina virtual

Terminal chamador no hospedeiro

  1. Coloque o twinkle em execução. Abra um terminal e chame: twinkle &</syntaxhighlight>
  2. Quando executado pela primeira vez, o twinkle solicita a criação de um perfilde usuário. Ele suporta múltiplos perfis. Neste experimento vamos criar algo simples. Selecione a criação do perfil através do Wizard</syntaxhighlight>
  3. Entre com o nome do perfil (identificação do perfil)

equipe1p1</syntaxhighlight> OBS: ajuste o nome para sua equipe. O p1 é para identificar o perfil 1. Vários poderão ser criados.

  1. O twinkle abre o wizard que deve ser preenchido conforme o exemplo abaixo (adaptado a sua equipe):
  • TelaPerfilTwinkle.jpg
  • em Sip server provider coloque NONE, pois faremos comunicação direta
  • em nome do usuário, coloque o nome completo
  • em user name coloque um identificador de usuário (sem espaço);
  • em domain coloque o endereço IP do seu computador (verifique com o comando ifconfig).

Terminal chamado na máquina virtual

  1. abra uma máquina virtual (Aplicativos/Sistema/Oracle VM VirtualBox) e execute a máquina XXXX
  2. verifique o IP da MV com ifconfig;
  3. coloque o twinkle em execução e crie um perfil diferente, por exemplo, equipe1p2

Capturando pacotes com wireshark no HOSPEDEIRO

No hospedeiro faça:

  1. execute o wireshark em background wireshark &</syntaxhighlight>
  2. entre na tela de opções de captura:
    TelaConfiguracaoOpcoesCaptura.jpg
  3. configure a captura de pacotes pela eth0 com filtro centrado no IP da máquina virtual e no protocolo UDP porta 5060:
    TelaConfiguracaoInterfaceWireshark.jpg
  4. Tecle start

Fazendo uma chamada a partir do hospedeiro

  1. Coloque o endereço do terminal chamado no twinkle e chame o usuário:
TelaTwinkleChamar.jpg

Atendendo a chamada no Twinkle da Máquina Virtual

  1. atenda a chamada teclando em ANSWER e logo em seguida termine a chamada com BYE;

OBSERVAÇÃO: Nosso foco é a sinalização. O áudio não nos importa no momento.

Parando a captura no wireshark e analisando os pacotes

  1. No wireshark pare a captura de pacotes;
  2. acompanhe a explicação do professor sobre as capturas realizadas.

Roteiro PARTE 2 - Comunicação entre usando hsopedeiros da rede do Laboratório

  1. Comunique o seu sip URL para o grupo ao lado teste a realização de chamadas.

Roteiro PARTE 3 - Desafios

  1. Criar mais um perfil no twinkle da Máquina Virtual.
  2. Teste uma chamada para este novo usuário.

Aula Dia 16/04/2013

Objetivos

Experimento 2 - comunicação direta Telefone IP - Softfone

Recursos usados

  • Telefone IP (ATA+telefone analógico);
  • PC com Linux e MV VirtualBox, ambos com twinkle;
  • acessórios: cabos ethernet, fonte de alimentação.

O Telefone IP

Neste experimento utilizaremos de um telefone IP formado a partir de um dispositivo ATA e um telefone analógico normal.

O dispositivo ATA é dotado de uma porta FXS normal e uma porta LAN (ethernet). Normalmente o dispositivo deve ser alimentado externamente. O ATA implementa pelo menos um protocolo de sinalização e um protocolo de comunicação de mídia. Ao ser conectado a uma LAN o ATA pode aquirir um número IP dinamicamente ou ser configurado estaticamente. A partir deste ponto ele está apto a receber ou realizar chamadas VOIP.

Serão utilizados os dispositivos ATA GKM1000 (manual) ou o GKM2000 (manual). Estes dispositivos implementam o protocolo SIP.

ETAPA 1 - Conexão física

  1. Olhando o manual do dispositivo, faça a conexão física dos dispositivos ATA e Telefone Analógico.
  2. Leia o manual e anote o IP do telefone.
  3. Faça um teste básico de conectividade para este endereço usando o comando ping.

Dados a serem anotados para o relatório:

  • IP do terminal, máscara,gateway default, servidor DNS;
  • IP do hsopedeiro.
  • Qual a razão da configuração do serviço TFTP. Para que serve este protocolo?

ETAPA 2 - Análise da comunicação softphone - Telefone

  • Prepare o twinkle (sobre o hospedeiro) para comunicação IP direta;
  • Prepare o wireshark para captura de pacotes filtrando pacotes de fluxos originários/destinados ao telefone IP;
  • Capture os pacotes de sinalização SIP referentes a uma sessão. Chame a partir do softfone e imediatamente termine a partir do telefone IP.

Dados a serem anotados/incluídos no relatório:

  • Diagrama de troca de mensagens mostrando a primeira linha da mensagem e os campos FROM, TO, CONTACT e CALLID. Ver o link http://www.siptutorial.net/SIP/relation.html e anote diagrama o que é o diálogo, a atransação, o caller e o callee.
  • Discuta o significado dos campos FROM, TO, CONTACT e CALLID.

Aula Dia 23/04/2013

Apresentação do novo professor

  • Marcelo Maia Sobral
  • Email: msobral@ifsc.edu.br
  • Atendimento paralelo: 2a de 8:20 às 9:10 h, 4a de 13:30 a 14:30
  • Grupo no Facebook: TIP (primeiro me adicionem)

Objetivos

  • Realizar chamadas entre telefones IP e softphones por meio de um PBX IP Asterisk
  • Analisar a sinalização dessas chamadas

Chamadas feitas usando PBX IP

Um PBX IP funciona como uma central telefônica, porém intermediando chamadas VoIP. Com isso, as chamadas são feitas de um telefone IP em direção ao PBX IP, que a encaminha ao telefone IP de destino de acordo com suas regras de discagem. A figura abaixo ilustra como funciona uma chamada VoIP típica através de um PBX IP.

Voip-call.png


Nas nossas aulas faremos uso de um PBX IP Asterisk, que é um software desenvolvido pela Digium. O Asterisk roda em computadores do tipo PC que possuem sistema operacional baseado em Linux. Sua licença é livre, o que significa que não há custo de licenciamento para utilizá-lo.

PBX IP Asterisk


Asterisk: uma solução completa de PABX baseado em software, permitindo ligar o mundo IP ao mundo da rede pública de telefonia comutada.

Características Básicas: faz tudo que um PABX pequeno e simples faz e pouco mais

  • ˆ Transferência, música de espera, siga-me, etc.
  • Conferência, correio de voz, URA, fila de chamadas, monitoramento de chamadas, integração com o Jabber (Google talk)


Asterisk-ex1.png
Exemplo de cenário de uso do Asterisk


Plano de discagem

O plano de discagem define como cada chamada deve ser processada. As instruções de processamento residem no arquivo de configuração /etc/asterisk/extensions.conf. O fluxo de processamento de chamadas pode ser visto resumidamente abaixo:

Asterisk-fluxo.png


Um exemplo de plano de discagem simples pode ser visto abaixo: 

[alunos]; o nome deste contexto

# Chamadas para o número 101 são feitas via SIP para o canal "maria"
exten=>101,1,Dial(SIP/maria)
same=>n,Hangup()

# Chamadas para "teste" serão atendidas com um som de beep, seguido 
# da reprodução do arquivo de som "hello-world", em seguida outro beep e
# enfim se encerra a chamada.
exten=>teste,1,Playback(beep)
same=>n,Wait(1)
same=>n,Playback(hello-world)
same=>n,Wait(1)
same=>n,Playback(beep)
same=>n,Hangup

A estrutura do plano de discagem é composta por extensões (um termo específico do Asterisk). Cada extensão identifica um número (ou usuário) que pode ser chamado, e como essa chamada deve ser processada. A sintaxe pode ser vista abaixo: 

exten=>identificador,prioridade,aplicação
  • identificador: o número ou usuário chamado
  • prioridade: a prioridade da extensão. Isso determina a ordem de execução das extensões que tratam do mesmo identificador.
  • aplicação: uma ação a ser realizada quando a extensão for processada. Por exemplo, a aplicação Dial determina que deve ser encaminhada a outro canal.

Como o processamento de uma chamada usualmente envolve uma sequência de extensões, existe uma sintaxe opcional para simplificar a declaração: 

exten=>identificador,prioridade,aplicação
same=>prioridade,aplicação
  • same: declara uma nova extensão com mesmo identificador da extensão imediatamente anterior

Por fim, a prioridade (que define a ordem com que as extensões são processadas) declarada com o valor n equivale à prioridade da extensão imediatamente anterior incrementada em uma unidade: 

exten=>101,1,Dial(SIP/101)
same=>n,Hangup; a prioridade aqui terá o valor 2

Canais SIP

Cada telefone SIP deve ter seu identificador cadastrado no Asterisk. O identificador pode tanto ser um número, análogo a um ramal, ou uma string alfanumérica. No terminologia do Asterisk, cada telefone SIP é chamado de canal SIP, e deve estar declarado em /etc/asterisk/sip.conf: 

; Canal 2000 (um exemplo)
[2000]
username=2000 ; o nome do usuário para fins de autenticação
secret=kabrum
type=friend ; pode efetuar e receber chamadas
host=dynamic ; pode conectar-se a partir de qualquer endereço IP
insecure=port,invite ; a segurança está associada ao registro do canal (primeiro
 passo),
                     ; assim como acontece em sessões Web
context=alunos ; o contexto padrão do João. O arquivo extensions.conf o definirá
disallow=all
allow=gsm ; habilita este codec para o João. Os vários codecs serão vistos em se
guida,
          ; já que cada um deles tem suas particularidades.
allow=alaw ; outro codec
allow=ulaw ; mais um codec
qualify=yes; mostra a qualidade, em ms, da conexão entre UAC e UAS.

; Canal joao (outro exemplo)
[joao]
username=joao ; o nome do usuário para fins de autenticação
secret=blabla
type=friend ; pode efetuar e receber chamadas
host=dynamic ; pode conectar-se a partir de qualquer endereço IP
insecure=port,invite ; a segurança está associada ao registro do canal (primeiro
 passo),
                     ; assim como acontece em sessões Web
context=alunos ; o contexto padrão do João. O arquivo extensions.conf o definirá
disallow=all
allow=gsm ; habilita este codec para o João. Os vários codecs serão vistos em se
guida,
          ; já que cada um deles tem suas particularidades.
allow=alaw ; outro codec
allow=ulaw ; mais um codec
qualify=yes; mostra a qualidade, em ms, da conexão entre UAC e UAS.

Como se pode notar, a declaração de um canal SIP envolve muitos parâmetros que envolvem autenticação, controle de acesso, localização na rede, codecs e possivelmente outras capacidades. Como os valores de alguns parâmetros podem ser iguais para vários canais, o Asterisk possibilita a declaração de perfis (templates): 

; Perfil alunos
[alunos](!);  a sequência "(!)" define isto como um perfil
type=friend ; pode efetuar e receber chamadas
host=dynamic ; pode conectar-se a partir de qualquer endereço IP
insecure=port,invite ; a segurança está associada ao registro do canal (primeiro
 passo),
                     ; assim como acontece em sessões Web
context=alunos ; o contexto padrão do João. O arquivo extensions.conf o definirá
disallow=all
allow=gsm ; habilita este codec para o João. Os vários codecs serão vistos em se
guida,
          ; já que cada um deles tem suas particularidades.
allow=alaw ; outro codec
allow=ulaw ; mais um codec
qualify=yes; mostra a qualidade, em ms, da conexão entre UAC e UAS.

; Canal 2000
[2000](alunos); a sequência "(alunos)" copia as definições do perfil "alunos"
username=2000 ; o nome do usuário para fins de autenticação
secret=kabrum

; Canal joao
[joao](alunos)
username=joao ; o nome do usuário para fins de autenticação
secret=blabla

Experimento 3: comunicação entre telefones IP ou softphones por meio de um PBX IP

Para realizar esses exercícios você deve usar o Asterisk na máquina virtual rmu-asterisk. Para testar as chamadas, use o softphone jitsy ou twinkle na máquina real, e um telefone IP.


1. Criar as seguintes contas SIP:

sip.conf 
[general]

[alunos](!)
type=friend ; pode efetuar e receber chamadas
host=dynamic ; pode conectar-se a partir de qualquer endereço IP
insecure=port,invite ; a segurança está associada ao registro do canal (primeiro passo),
                     ; assim como acontece em sessões Web
disallow=all
allow=gsm ; habilita este codec para o João. Os vários codecs serão vistos em seguida,
          ; já que cada um deles tem suas particularidades.
allow=alaw ; outro codec
allow=ulaw ; mais um codec
qualify=yes; mostra a qualidade, em ms, da conexão entre UAC e UAS.
context=alunos
 
[100](alunos)
username=100
secret=100

[101](alunos)
username=101
secret=101
extensions.conf 
[alunos]; contexto alunos
exten=>_10X,1,Dial(SIP/${EXTEN})
same=>n,Hangup

2. Crie um plano de discagem em que todos podem fazer chamadas para todos (isso é, 100 pode chamar 101, e vice-versa).

3. Execute o Jitsy ou Twinkle, configurando-o para registrar no Asterisk. Isso é feito especificando a conta SIP da seguinte forma (exemplo com o canal SIP 100): 

100@IP_do_PBX_Asterisk

4. Instale um telefone IP, configurando-o apropriadamente para que registre sua conta SIP no PBX Asterisk. Isso vai depender do modelo de telefone IP (Voiper da Intelbras, ou o telefone da Khomp).

5. A partir do softphone faça uma chamada para a conta do telefone IP. Verifique se o telefone IP acusou o recebimento de chamada. Caso isso não tenha ocorrido, verifique seu plano de discagem.

6. Execute o wireshark, e ponha-o em modo de captura em todas as interfaces (pseudo-interface any).

7. Repita a chamada de um softphone ao telefone IP. No telefone IP atenda a chamada, e alguns segundos depois encerre-a.

8. No wireshark interrompa a captura, e em seguida acesse o menu Telephony->VoIP Calls. Selecione uma chamada, e visualize o diagrama de mensagens SIP. Siga cada mensagem SIP (clique no diagrama), e observe a mensagem selecionada no painel de captura do wireshark. Identifique as transações (observe os códigos de resposta) e os diálogos. Você pode usar estes diagramas para se guiar.

Questões:

  1. Que papel desempenhou o Asterisk para os softphones ? UAC, UAC ou algo diferente ?
  2. Entre que agentes ocorreram os diálogos identificados ?
  3. Como o Asterisk conseguiu identificar o telefone chamado (i.e. localizar onde ele estava na rede) ?

Como testar as chamadas

Para testar as chamadas, são necessários um softphone e um telefone IP, além do Asterisk.

  1. Em cada softphone ou telefone IP crie uma conta SIP, que deve ser identificada por ramal@IP_do_PBX (ex: se o PBX tiver IP 192.168.2.110, as contas de alunos podem ser 100@192.168.2.110 e 101@192.168.2.110).
  2. Após definir as contas, verifique se os telefones indicaram que elas estão disponíveis (online). Você pode fazer essa verificação também no próprio Asterisk. Neste caso execute o seguinte comando para acessar o console do Asterisk: 
    sudo rasterisk -vvv
host*CLI> sip show peers
host*CLI> sip show peers
Name/username              Host             Dyn Nat ACL Port     Status     
101/101                    192.168.2.10       D          11270    OK (6 ms)
102/102                    192.168.2.210      D          63169    OK (12 ms)
2 sip peers [Monitored: 2 online, 0 offline Unmonitored: 0 online, 0 offline]
  3. Se algum dos telefones não aparecer como OK no console do Asterisk, verifique se o número de ramal e a senha configuradas no telefone são os mesmos declarados em /etc/asterisk/sip.conf. Outro teste que se pode fazer é acessar o console do Asterisk, e depois tentar ativar as contas SIP nos telefones (i.e. colocá-las para indisponível ou offline, e depois reativá-las). O Asterisk irá mostrar algumas linhas informativas sobre os registros dos telefones (lembre que ao ativar uma conta SIP, ela é registrada no Asterisk usando uma mensagem SIP do tipo REGISTER).
  4. Se as contas SIP estão devidamente registradas no Asterisk, mas ainda assim as chamadas não são realizadas, o problema deve estar no plano de discagem. Isso fica evidente se ao tentar fazer uma chamada obtém-se uma mensagem de erro do tipo 404 not found. Neste caso, acesse o console do Asterisk e tente novamente fazer a chamada. Veja se o Asterisk informa na tela o motivo para a chamada não ser realizada. Em seguida, confira se seu plano de discagem (/etc/asterisk/extensions.conf) possui uma extensão que satisfaça a chamada que se deseja realizar. Isso é, se você estiver tentando chamar o ramal SIP 101@192.168.2.110, deve haver uma extensão assim: 
    exten=>101,1,Dial(SIP/101)
same=>n,Hangup

Aula dia 30/04/2013

Objetivos:

  • Estabelecer chamadas VoIP entre telefones IP através de um PBX IP.
  • Analisar a sinalização SIP quando se usa o PBX IP.


Continuaremos a implantação de chamadas usando um PBX e dois telefones IP.


Como realizar o experimento em casa

Pode-se fazer o experimento em casa, de forma a estudar a sinalização e stream de áudio das chamadas VoIP. Para isso precisa-se do Asterisk (PBX IP) e dois softphones (twinkle, jitsi, linphone, ou outro de sua preferência). O Asterisk roda somente no Linux, portanto deve-se ter esse sistema operacional no seu computador ou em uma máquina virtual Virtualbox. Para facilitar a realização desses experimentos, seguem algumas opções.

Usando uma máquina virtual Virtualbox

Neste cenário, executa-se uma máquina virtual com o Asterisk, e os softphones na máquina real. A máquina real (sistema hospedeiro) pode ser tanto Linux quanto Windows, porém no primeiro caso funciona melhor. Os softphones podem também estar em outros computadores, laptops ou smartphones. Mas para fazer experimentos desta forma é necessário primeiro ter a máquina virtual, que pode ser obtida no link a seguir:

Para instalá-la siga estes passos:

  1. Descompacte o arquivo asterisk-vm.tgz dentro da pasta VirtualBox VMs. No Linux essa pasta fica dentro do diretório pessoal do usuário (o diretório home). No Windows ainda não sei ... na 5a feira verei lá no Ifsc, mas deve estar dentro de Documents and Settings ou algo assim - quem descobrir por favor me avise.
  2. Execute o VirtualBox, e então selecione o menu Máquina->Acrescentar.
  3. Escolha o arquivo Asterisk/Asterisk.vbox, que deve estar na pasta VirtualBox VMs.
  4. Deve ter surgido a máquina virtual Asterisk na lista do VirtualBox.
    • Execute-a para testá-la.
    • Entre com usuário aluno e senha aluno.
    • O Asterisk deve estar em execução. Teste-o usando o comando sudo rasterisk -vvv.
    • Veja os canais SIP (um para cada telefone IP ou softphone) que já estão definidos em /etc/asterisk/sip.conf. São os mesmos que usamos em aula.
    • Observe o plano de discagem em /etc/asterisk/extensions.conf. Ele possibilita chamadas entre os softphones, e também para o número especial 999' (experimente-o).
    • Saia da interface do rasterisk usando o comando quit'.
    • Ao terminar, não esqueça de encerrar a máquina virtual com o comando halt.

Os softphones podem ser o twinkle, que usamos em aula, ou o jitsi, que roda tanto no Linux quanto Windows.

Lembre que se houver dois softphones no mesmo computador, eles deverão usar ports UDP diferentes para o protocolo SIP. Experimente usar port 5060 em um softphone, e 5062 no outro.

Usando o Asterisk diretamente no seu computador (na máquina real)

Você deve ter o Linux instalado no seu computador para rodar diretamente o Asterisk. Assumindo que seja o Ubuntu ou Debian Linux, siga estes passos:

  1. Instale o Asterisk: 
    sudo apt-get istall asterisk
  2. Copie estes arquivos para dentro de /etc/asterisk:
  3. Reinicie o Asterisk: 
    sudo service asterisk restart
  4. Use o rasterisk para acessar o console do Asterisk: 
    sudo rasterisk -vvv
  5. Inicie os softphones (jitsi ou twinkle). Configure-os para usarem as contas SIP 100 e 101, registrando-se no Asterisk que está no IP 127.0.0.1. Lembre de colocar os softphones em ports SIP diferentes (ex: 5062 e 5064).
  6. Tente fazer chamadas, observando as mensagens de aviso na tela do rasterisk.


Aula dia 07/05/2013


Objetivos:

  • Analisar a sinalização SIP quando se usa o PBX IP.
  • Analisar a negociação de midia feita pelo protocolo SDP.
  • Observar e diferenciar a transmissão de midia com diferentes codecs de áudio.


Tip-Pbx-intro.png


Quando um PBX IP intermedia a stream de áudio, então ele funciona também como gateway de media. Isso possibilita que os dois telefones IP usem codecs de áudio diferentes, e nesse caso o PBX IP faz a tradução de uma codificação para a outra ao intermediar o áudio. Além disso, um gateway de media facilita o envia da stream de áudio entre os telefones IP, quando eles estão em redes diferentes (e existem firewalls e tradutores NAT entre eles).

A sinalização SIP apresenta algumas diferenças em relação ao caso em que a chamada ocorre diretamente entre dois telefones IP. Isso se dá porque o PBX IP, apesar de fazer parte da sinalização, não ser a rigor o telefone IP chamado nem o chamador. Os detalhes de como essa troca de mensagens SIP é realizada são introduzidos a seguir.

Chamada entre dois agentes SIP com intermediação de um gateway de media

A chamada é feita inicialmente para o PBX IP, que intermedia tanto as mensagens SIP quanto a stream de áudio (pacotes RTP). Isso possibilita que dois agentes estabeleçam uma chamada mesmo usando codecs diferentes, pois o gateway de media fará a tradução entre codecs. 

Fone 1            PBX IP              Fone 2
              (directmedia=no)        
     |                |                |
     |   INVITE       |                |
     |--------------->|   INVITE       |
     |  100 Trying    |--------------->| 
     |<---------------|  100 Trying    |
     |                |<---------------| 
     |                |   180 Ringing  |
     |   180 Ringing  |<---------------|                
     |<---------------|                |      
     |                |    200 Ok      |
     |     200 Ok     |<---------------|
     |<---------------|                |
     |     ACK        |                |
     |--------------->|    ACK         |
     |                |--------------->|
     |    RTP Media   |   RTP Media    |
     |<==============>|<==============>|
     |     BYE        |                |
     |--------------->|    BYE         |
     |                |--------------->|
     |                |    200 Ok      |
     |     200 Ok     |<---------------|
     |<---------------|                |
     |                |                |

Atividade

  1. Execute a máquina virtual Integrado-Asterisk. Verifique se o Asterisk já está ativado (ele deveria ser iniciado automaticamente ... caso contrário execute sudo service asterisk restart).
  2. Execute o wireshark e inicie a captura de datagramas UDP em todas as interfaces (o nome da interface deve ser any, e o filtro de captura deve ser udp).
  3. Execute dois softhones (twinkle e jitsi). Em um deles crie a conta SIP 100@IP_da_maq_virtual, e no outro cria a conta SIP 101@IP_da_maq_virtual. O IP_da_maq_virtual é 192.168.2.100+número_do_computador (ex: no computador 2 é 192.168.2.102).
  4. Faça uma chamada entre os softphones, atenda-a e em seguida encerre-a.
  5. Procure no wireshark as mensagens SIP trocadas entre os softphones e o Asterisk. Desenhe um diagrama de troca de mensagens usando este modelo.
  6. Observe os cabeçalhos Call-Id, From, To, Via, CSeq das mensagens SIP. Quais mantiveram seus valores ao longo de todas transações, e quais mudaram ?
  7. As mensagens SIP tinham por objetivo estabelecer uma chamada de áudio entre os softphones. Essa informação está no corpo das mensagens INVITE, o qual possui uma mensagem de outro protocolo chamado SDP. Observe as informações contidas na mensagem SDP, e identifique:
    • O tipo de midia a ser transmitida
    • O endereço IP, port e protocolo de transporte de midia a serem usados para essa transmissão.
    • Os codecs que podem ser usados para a transmissão de midia.
  8. A negociação sobre a transmissão de midia se concretiza na mensagem 200 OK em resposta ao INVITE. Observe que ela também contém uma mensagem SDP. Observe as informações ali contidas e compare-as com as que havia no INVITE. Como essa resposta complementa o que foi informado no INVITE ?
  9. Uma vez estabelecida a chamada, ocorre a transmissão da midia. Qual o protocolo utilizado ? Que informações ele contém em seu cabeçalho ? Descubra essas informações observando o que mostra o wireshark.
  10. Experimente estabelecer chamadas com diferentes codecs, e observe a negociação realizada com SDP.

Tarefa para casa

Combine com um colega de realizarem uma chamada VoIP entre softphones a partir de suas residências. Usem como PBX IP o servidor integrado.sj.ifsc.edu.br com contas SIP 100@integrado.sj.ifsc.edu.br a 1099@integrado.sj.ifsc.edu.br (as senhas são as mesmas que as contas, acrescidas do sufixo qwe - ex: 1000@integrado.sj.ifsc.edu.br tem senha 1000qwe). Escreva um breve relatório que descreva como foi realizado o experimento, se a chamada teve sucesso, que problemas apareceram, qual o diagnóstico para esses problemas e que soluções foram encontradas; inclua a troca de mensagens SIP feita pelo seu softphone (descubra isso com o wireshark).

Aula dia 14/05: o transporte do audio nas chamadas VoIP

SDP (Session Description Protocol)

Ao iniciar uma chamada com SIP, a negociação de midia a ser transmitida é especificada no corpo da mensagem INVITE. O formato da especificação é descrito pelo protocolo SDP (Session Description Protocol), contendo as seguintes informações:

  • Endereço IP
  • Perfil RTP (usualmente RTP/AVP)
  • Número de port do protocolo de transporte (usualmente UDP)
  • Tipo de midia (audio, video, e possivelmente outros)
  • Esquema de codificação de midia (o tipo de codec a ser usado)
  • Assunto da sessão (uma descrição)
  • Horários de início e fim
  • Identificação do contato da sessão

Assim como SIP, SDP codifica suas informações em texto simples. Uma mensagem SDP é composta por linhas de texto chamadas de campos, cujos nomes são abreviados por uma única letra. Os campos de uma mensagem SDP são:

Sdp-fields.png
Tabela de campos SDP


Um exemplo de mensagem SDP segue abaixo:

Sdp-msg.png


A descrição completa de cada campo, e os possíveis valores que ele pode assumir, pode ser lida nas referências (em especial, este capítulo de livro).

Protocolo RTP


O protocolo RTP (Real-Time Protocol) foi desenvolvido para possibilitar o transporte de datagramas de tempo-real contendo voz, video, ou outro tipo de dados, sobre IP. Tanto H.323 quanto o modelo SIP usam RTP para o transporte de media, tornando-o o padrão mais comum para comunicações desse tipo na Internet. Apesar desse protocolo não prover qualidade de serviço (i.e. ele não possui mecanismos para atender tais tipos de requisitos), ele torna possível a detecção de alguns dos problemas introduzidos por uma rede IP, tais como:

  • Perda de pacotes
  • Atraso fim-a-fim variável
  • Chegada de pacotes fora de ordem


Esses problemas não são novidade ... nós já os discutimos nas aulas sobre transmissão de dados multimidia. O que há de novo é um protocolo que dá subsídios para as técnicas que buscam atender requisitos de qualidade de serviço. Esses subsídios são informações providas pelo RTP para ajudar a identificar os problemas citados acima, as quais são:

  • Identificação do tipo do conteúdo que está sendo carregado (codec): isso informa ao receptor como ele deve decodificar o conteúdo transportado (ver esta tabela de identificadores de codec usados pelo RTP)
  • Numeração de sequência: essa informação possibilita identificar pacotes perdidos ou fora de ordem.
  • Marcação de tempo (timestamp): com isso é possível efetuar o cálculo de variação de atraso e implementar algum mecanismo de sincronização com a fonte (ex: atraso de reprodução).


Essas informações fazem parte da PDU RTP, como se pode ver a seguir:

Localização do RTP na camada de transporte Cabeçalho RTP
Rtp1.png Tip-Rtp-header.png


Tip-Rtp-avp.png
Perfil RTP/AVP, com codecs e seus códigos numéricos

RTCP

Além do RTP, o protocolo auxiliar RTCP (Real-Time Control Protocol, também definido na RFC 3550) foi definido para o monitoramento da entrega dos pacotes (recepção da stream). Com esse protocolo, os participantes de uma sessão de media podem fazer o intercâmbio de relatórios e estatísticas. Cada tipo de relatório é transportado por um tipo de pacote RTCP. O uso de relatórios possibilita o feedback sobre a qualidade da comunicação, incluindo informações como:

  • Número de pacotes enviados e recebidos
  • Número de pacotes perdidos
  • Jitter (variação de atraso)

Os cinco tipos de relatórios são:

  • Relatório do transmissor (Sender Report - SR)
  • Relatório do receptor (Receiver Report - RR)
  • Descrição da fonte (Source Description - SDES)
  • Bye
  • Específico da aplicação (Application Specific - APP)

Como o tráfego RTCP é puramente overhead, o protocolo foi projetado para que seu consumo da capacidade da rede seja constante, não importa quantos participantes da sessão de media existam. A ideia é que quanto mais participantes houver, menos frequentemente os relatórios RTCP são enviados. Por exemplo, se em uma conferência houver somente dois participantes, os relatórios podem ser enviados a cada 5 segundos. Se houver quatro participantes, os relatórios são enviados a cada 10 segundos. Com isso o consumo de banda para relatórios se mantém constante e previsível.

Atividade

Essa atividade busca ilustrar os fluxos RTP com um exemplo:

  1. Estabeleça uma chamada VoIP entre dois softphones usando o Asterisk como intermediário.
  2. Execute o wireshark no computador onde roda o Asterisk, e ative a captura de datagramas UDP.
  3. Observe os pacotes RTP capturados pelo Wireshark. Selecione alguns deles e investigue as informações contidas em seu cabeçalho. Procure identificar o codec usado e as marcações de tempo. Compare as marcações de tempo do RTP com os instantes de recepção desses pacotes.
  4. Estime o jitter durante a recepção de ao menos 15 segundos de audio.
  5. Observe os relatórios RTCP:
    • Que tipos de relatórios são enviados ?
    • Com que frequência esses relatórios são transmitidos ?
    • Que informações esses relatórios contêm ?
  1. Execute a máquina virtual Integrado-Asterisk. Verifique se o Asterisk já está ativado (ele deveria ser iniciado automaticamente ... caso contrário execute sudo service asterisk restart).
  2. Execute o wireshark e inicie a captura de datagramas UDP em todas as interfaces (o nome da interface deve ser any, e o filtro de captura deve ser udp).
  3. Execute dois softhones (twinkle e jitsi). Em um deles crie a conta SIP 100@IP_da_maq_virtual, e no outro cria a conta SIP 101@IP_da_maq_virtual. O IP_da_maq_virtual é 192.168.2.100+número_do_computador (ex: no computador 2 é 192.168.2.102).
  4. Faça uma chamada entre os softphones, atenda-a e em seguida encerre-a.
  5. Procure no wireshark as mensagens SIP trocadas entre os softphones e o Asterisk. Observe os cabeçalhos Call-Id, From, To, Via, CSeq das mensagens SIP. Quais mantiveram seus valores ao longo de todas transações, e quais mudaram ?
  6. As mensagens SIP tinham por objetivo estabelecer uma chamada de áudio entre os softphones. Essa informação está no corpo das mensagens INVITE, o qual possui uma mensagem de outro protocolo chamado SDP. Observe as informações contidas na mensagem SDP, e identifique:
    • O tipo de midia a ser transmitida
    • O endereço IP, port e protocolo de transporte de midia a serem usados para essa transmissão.
    • Os codecs que podem ser usados para a transmissão de midia.
  7. A negociação sobre a transmissão de midia se concretiza na mensagem 200 OK em resposta ao INVITE. Observe que ela também contém uma mensagem SDP. Observe as informações ali contidas e compare-as com as que havia no INVITE. Como essa resposta complementa o que foi informado no INVITE ?
  8. Uma vez estabelecida a chamada, ocorre a transmissão da midia. Qual o protocolo utilizado ? Que informações ele contém em seu cabeçalho ? Descubra essas informações observando o que mostra o wireshark.
  9. Experimente estabelecer chamadas com diferentes codecs, e observe a negociação realizada com SDP.
  10. Observe os pacotes RTP capturados pelo Wireshark. Selecione alguns deles e investigue as informações contidas em seu cabeçalho. Procure identificar o codec usado e as marcações de tempo. Compare as marcações de tempo do RTP com os instantes de recepção desses pacotes.
  11. Estime o jitter durante a recepção de ao menos 15 segundos de audio.
  12. Observe os relatórios RTCP:
    • Que tipos de relatórios são enviados ?
    • Com que frequência esses relatórios são transmitidos ?
    • Que informações esses relatórios contêm ?

Aula dia 21/05: interligando PBX Asterisk por meio de troncos SIP ou IAX2

A interligação entre PBX Asterisk pode ser feita via rede de dados usando os protocolos SIP ou IAX2. No primeiro caso, o encaminhamento de uma chamada entre dois PBX funciona como uma chamada SIP usual, e isso significa que a sinalização é feita com SIP e o áudio flui em separado com RTP. No segundo caso, o protocolo IAX2 (Inter-Asterisk eXchange) encapsula tanto a sinalização quanto os fluxos de áudio, o que simplifica o estabelecimento do tronco.

Modelo-pbx-asterisk.png


Inicialmente criaremos a infraestrutura para chamadas VoIP, a qual aumentaremos gradualmente para podermos reproduzir o modelo aqui descrito.

Tronco SIP

Em um entroncamento SIP (SIP trunking), um PBX pode encaminhar chamadas através de um tronco SIP. Essas chamadas podem ser originadas de diferentes formas, tais como telefones IP ou convencionais. Entre os PBX do entroncamento, as chamadas são sinalizadas com SIP e transmitidas com RTP e algum codec.

Sip-trunk.png

A ativação de um entroncamento SIP entre dois PBX Asterisk pode ser feita seguindo o exemplo abaixo:

PBX sip.conf extensions.conf
Norte 
[Sul]
type=user
secret=supersercreta
host=IP_PBX_Norte
disallow=all
allow=ulaw
;canreinvite=no
directmedia=no
context=troncoSIP
qualify=yes

[ParaSul]
type=peer
fromuser=Norte
username=Norte
secret=supersecreta
host=IP_PBX_Sul
disallow=all
allow=ulaw
;canreinvite=no
directmedia=no
qualify=yes

 [troncoSIP]
 ; Ligando para a outra central e, na sequência, o "ramal" de destino
 exten => _4XXX.,1,Dial(SIP/ParaSul/${EXTEN})
 same=>n,Hangup
Sul 
[Norte]
type=user
secret=supersercreta
host=IP_PBX_Sul
disallow=all
allow=ulaw
;canreinvite=no
directmedia=no
context=troncoSIP
qualify=yes

[ParaNorte]
type=peer
fromuser=Sul
username=Sul
secret=supersecreta
host=IP_PBX_Norte
disallow=all
allow=ulaw
;canreinvite=no
directmedia=yes
qualify=yes

 [troncoSIP]
 ;
 ; Ligando para a outra central e, na sequência, o "ramal" de destino
 exten => _2XXX.,1,Dial(SIP/ParaNorte/${EXTEN})
 same=>n,Hangup

Atividade: estabelecendo chamadas entre diferentes PBX Asterisk

Nesta atividade, vamos realizar chamadas entre softphones registrados em diferentes PBX Asterisk. Para isso, precisaremos estruturar o laboratório de forma que cada PBX Asterisk possua um tronco SIP com um PBX vizinho. Os usuários SIP serão identificados por MMXX, sendo MM o número do computador de cada aluno (ex: micro 2 tem usuários entre 200 e 299, e micro 11 tem usuários entre 1100 e 1199). Assim, é possível fazer um plano de discagem para encaminhar corretamente as chamadas entre quaisquer desses números.

Aula 28/05: NAT e STUN


A existência de um ou mais tradutores NAT entre telefones dificulta o estabelecimento de chamadas. Isso porque o NAT modifica o endereço IP e port (UDP ou TCP) de origem de pacotes que viajam da rede interna para a externa, o que fica inconsistente com o que foi negociado na chamada com SDP. Há alguma abordagens para contornar esse problema:

  • Informando o endereço IP e port UDP que de fato aparecerão para a rede externa: proposta do STUN e ICE, porém nem sempre funciona (STUN) ou é complicado (ICE).
  • Usando gateway de midia: abordagem mais comum, por ser mais fácil de ser implantada e dar bons resultados.

Usando o Asterisk para contornar NAT

O Asterisk pode ajudar a viabilizar a comunicação com telefones VoIP que estão atrás de gateways NAT. Na definição de cada canal SIP devem-se incluir as opções: 

nat=yes
qualify=yes
directmedia=no

Aqui tem uma boa explicação sobre o que fazem essas opções.

Se for o Asterisk que está atrás de NAT, então deve-se configurar seu IP válido, de forma que o PBX possa informá-lo nas mensagens SDP para as streams de audio. Para isso, deve-se acrescentar em sip.conf: 

[general]
externip=IP_público
; ou:
;externhost=fqdn

; devem-se informar as redes privativas onde está o Asterisk (pode haver mais de uma ... basta repetir o 
; atributo localnet para cada subrede). Isso é importante para que o Asterisk saiba quando usar o IP
; público (para telefones fora de sua rede) ou privativo (telefones dentro de sua rede) nas mensagens
; SDP que especificam o IP e port UDP para as streams RTP.
localnet=prefixo/máscara


OBS: isso só funciona quando o Asterisk está no caminho da stream de áudio. No caso de telefones VoIP que conversam diretamente, só resta STUN ou alguma outra técnica do tipo ...

STUN: Session Traversal Utilities for NAT

Ou: um quebra-galho para resolver os problemas de outro quebra-galho ...


O estabelecimento de uma chamada VoIP implica iniciar e manter duas streams de áudio (uma em cada sentido da comunicação). Cada stream usa o protocolo RTP, cujas PDUs são transportadas dentro de datagramas UDP. Portanto, cada telefone IP precisa alocar um port UDP, por onde serão recebidas as PDUs RTP.

Voip-call.png
Diagrama que mostra uma chamada VoIP típica intermediada por um PBX. A sinalização se faz através do PBX, mas as streams de áudio RTP são estabelecidas diretamente entre os telefones VoIP.


As informações necessárias para transmitir as PDUs da stream RTP são informadas no momento em que se inicia a chamada. Um dos telefones IP usa o protocolo SIP para solicitar uma chamada com outro telefone (mensagem INVITE). Dentro dessa mensagem INVITE é encapsulada uma mensagem SDP, que contém as informações necessárias para criar uma stream de áudio, tais como codecs aceitos, e endereço IP e port UDP onde o telefone iniciador da chamada espera receber as PDUs RTP. Se o telefone chamado aceitar a chamada, sua resposta SIP terá status 200 OK, e encapsulará uma mensagem SDP contendo a identificação dos codecs que aceita utilizar, além de seu endereço IP e port UDP onde espera receber as PDUs RTP. Assim, com base nas informações contidas nas mensagens SDP, os telefones IP podem estabelecer as streams de áudio em ambas direções. A figura abaixo ilustra uma mensagem SDP encapsulada em uma mensagem SIP INVITE.


Sdp.png
O endereço IP e o port UDP para estabelecer a stream RTP são informados dentro da mensagem SDP, quando o telefone VoIP tenta iniciar uma chamada com SIP (mensagem INVITE). A lista de codecs da mensagem SDP foi omitida por simplicidade.


Mas como essas streams de áudio podem ser estabelecidas se existir um ou mais gateways NAT entre os telefones VoIP ? A mensagem SDP com a descrição dos dados de uma stream é preenchida usando o endereço IP e port UDP do telefone VoIP. No entanto, a existência de um gateway NAT faz com que o endereço IP e port UDP desse telefone VoIP sejam diferentes para quem estiver fora de sua rede. O correto seria ter na mensagem SDP o endereço IP e port UDP que serão usados após passar o NAT - quer dizer, os valores que serão visíveis para o outro telefone VoIP. Para isso foi criado o serviço STUN (Session Traversal Utilities for NAT), que possibilita que um telefone VoIP (ou qualquer outro cliente) descubra seu endereço IP e port UDP visíveis para quem estiver do outro lado do gateway NAT. A figura abaixo ilustra como o STUN poderia ser usado para essa finalidade.

STUN.png
Cenário em que se poderia usar STUN


O STUN foi criado para ser usado imediatamente antes de iniciar uma transmissão UDP. Como mostrado na figura abaixo, um cliente envia a um servidor STUN uma mensagem de pedido de vinculação (binding request), que deve usar como port UDP de origem o mesmo port que se pretende usar para a stream de áudio. Esse servidor STUN deve estar fora da rede, de forma que o pedido de vinculação por ele recebido seja modificado pelo NAT. A resposta do servidor STUN (binding response) contém o endereço IP e número de port UDP que apareceram no pedido de vinculação. Com isso o cliente consegue descobrir como esses valores deverão aparecer após passarem pelo NAT. Assim, a mensagem SDP pode ser preenchida com os valores apropriados para a stream de áudio.


Stun-diagram.png
Exemplo de mensagens trocadas com STUN


Deve-se notar que o STUN não faz milagre ! Como apontado no início do texto, STUN é um quebra-galho criado para tentar resolver os problemas de outro quebra-galho (no caso, o NAT). Para que o STUN funcione, o NAT deve permitir que datagramas UDP vindos de outro endereço IP (o telefone VoIP na outra ponta da ligação) acessem o endereço IP e port UDP que foram alocados quando da consulta do cliente para o servidor STUN. Porém isso só é possível se o NAT for do tipo full cone, restricted cone ou port restricted cone. Quer dizer, se o NAT for do tipo simétrico, o STUN não funcionará. E muitos NAT em equipamentos proprietários são do tipo simétrico (ao contrário do Linux, que implementa um NAT port restricted cone) ...

Servidores STUN

Existe uma implementação de um servidor STUN para Linux (disponível no Ubuntu via apt). Assim, basta instalá-lo em um computador e usá-lo como servidor STUN, contanto que ele esteja do outro lado do NAT. No entanto, existem inúmeros servidores STUN públicos, conforme mostrado na listagem abaixo: 

provserver.televolution.net
sip1.lakedestiny.cordiaip.com
stun1.voiceeclipse.net
stun01.sipphone.com
stun.callwithus.com
stun.counterpath.net
stun.endigovoip.com
stun.ekiga.net (alias for stun01.sipphone.com)
stun.ideasip.com (no XOR_MAPPED_ADDRESS support)
stun.internetcalls.com
stun.ipns.com
stun.noc.ams-ix.net
stun.phonepower.com
stun.phoneserve.com
stun.rnktel.com
stun.softjoys.com (no DNS SRV record) (no XOR_MAPPED_ADDRESS support)
stunserver.org see their usage policy
stun.sipgate.net
stun.sipgate.net:10000
stun.voip.aebc.com
stun.voipbuster.com (no DNS SRV record) (no XOR_MAPPED_ADDRESS support)
stun.voxalot.com
stun.voxgratia.org (no DNS SRV record) (no XOR_MAPPED_ADDRESS support)
stun.xten.com
numb.viagenie.ca (http://numb.viagenie.ca) (XOR_MAPPED_ADDRESS only with rfc3489bis magic number in transaction ID)
stun.ipshka.com inside UA-IX zone russsian explanation at http://www.ipshka.com/main/help/hlp_stun.php

Maiores detalhes sobre servidores STUN

Atividade

Vamos implantar a seguinte estrutura de rede:


Pbx-nat.png


Para podermos fazer isso, os seguintes passos devem ser realizados (X é o número do seu computador):

  1. Mude o IP da máquina real para 192.168.1.X/24: 
    sudo ifconfig eth0 192.168.1.X/24
  2. Na máquina real configure o roteador default 192.168.1.254: 
    sudo route add default gw 192.168.1.254
  3. Configure um softphone para usar o seu PBX. Experimente fazer uma chamada para o número 9999. A conta SIP do softphone deve ser número@172.18.25.18.
    • Você precisará configurar as opções de NAT do Asterisk para que isso funcione (em /etc/asterisk/sip.conf).
    • O número 9999 pode ser atendido com as seguintes regras do plano de discagem (/etc/asterisk/extensions.conf): 
      exten=>9999,1,Answer
same=>n,Wait(1)
same=>n,Playback(beep)
same=>n,Wait(1)
same=>n,Playback(hello-world)
same=>n,Wait(1)
same=>n,Playback(beep)
same=>n,Hangup

Agora vamos fazer o contrário:


Pbx-nat2.png


As seguintes alterações precisam ser feitas para esse novo cenário:

  1. Mude o IP da máquina virtual Asterisk para 192.168.1.X/24
  2. Na máquina virtual configure o roteador default 192.168.1.254
  3. Mude o IP da máquina real com DHCP.
  4. Configure um softphone para usar o seu PBX. Experimente fazer uma chamada para o número 9999
    • Você precisará configurar as opções de NAT do Asterisk para que isso funcione.

Aula 04/06: Apresentação do projeto

O projeto visa complementar o aprendizado sobre Telefonia IP, por meio de um problema a ser resolvido em equipe.

Objetivo do projeto: implantar um provedor VoIP

Descrição

Um provedor VoIP possibilita a realização de chamadas entre telefones SIP, e entre esses e telefones da PSTN. Os clientes do provedor possuem URI SIP da forma usuario@dominio_do_provedor, e as chamadas são realizadas por meio dessas URI. É possível que um cliente de um provedor faça uma chamada para um cliente de outro provedor, contanto que esses provedores possuam alguma forma de convênio.


Tip-Proj-1.png
Chamada entre telefones de um mesmo provedor


Tip-Proj-2.png
Chamada entre telefones de provedores diferentes


Os telefones dos clientes podem estar em qualquer rede, como por exemplo em redes residenciais com links ADSL.

Maiores detalhes sobre o projeto serão discutidos à medida que ele progredir.

Equipes

Equipe Domínio IP do servidor antigo IP do novo servidor
Jessica, Taine, Gabriela equipe1.tip.sj.ifsc.edu.br 172.18.80.241 200.135.37.106
Gustavo, Thiago, Karine equipe2.tip.sj.ifsc.edu.br 172.18.80.242 200.135.37.107
Anderson,Igor,Nikolas equipe0.tip.sj.ifsc.edu.br 187.58.224.243 187.58.224.243
Stefanie,Daniela,Mayara kadosh.tip.sj.ifsc.edu.br 172.18.80.244 200.135.37.109
Andreza, Andressa equipe3.tip.sj.ifsc.edu.br 172.18.80.243 200.135.37.108
  • Obs: o servidor DNS do domínio tip.sj.ifsc.edu.br é 172.18.80.251 (ns.tip.sj.ifsc.edu.br). Ele irá delegar seus sudbomínios para seus servidores DNS.
  • Obs. 2: vocês podem entrar em seus respectivos servidores via SSH. Esses servidores já possuem o Asterisk instalado e também o BIND (software do servidor DNS).
  • Obs. 3: os ports UDP usados para as streams RTP (audio) devem estar entre 4000 e 5000. Ver as opções rtpstart e rtpend em /etc/asterisk/rtp.conf.

Etapa 1: implantar o PBX de cada provedor

  1. Implantar o Asterisk e torná-lo capaz de efetuar chamadas entre as contas SIP do provedor.
  2. Fazer com que o Asterisk consiga fazer chamadas para contas SIP de outros provedores. 
zone "tip.sj.ifsc.edu.br" {
        type master;
        file "/etc/bind/db.tip"; // o arquivo que contém as informações da zona
};

Exemplo de definição de uma zona DNS em /etc/bind/named.conf.local. Isso é necessário para que o BIND (software que funciona como servidor DNS) saiba que essa zona existe e que informações ela contém. Só assim ele conseguirá responder a consultas DNS sobre essa zona. 


$TTL    604800
@       IN      SOA     ns.tip.sj.ifsc.edu.br. root.tip.sj.ifsc.edu.br. (
                              4         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
;
        IN      NS      ns
        IN      A       172.18.80.251
ns      IN      A       172.18.80.251
_sip._udp IN SRV 0 5 5060 pbx
pbx     IN      A       172.18.80.251

Exemplo de zona DNS que inclui o registro SRV para apontar quem é o PBX IP de um domínio. Neste exemplo isso está gravado no arquivo /etc/bind/db.tip

Etapa 2: tornar possíveis chamadas entre telefones IP que estejam atrás de NAT

O próximo passo é tornar possível que telefones IP atrás de NAT (ex: em uma rede residencial com ADSL) possam fazer e receber chamadas. Para testá-lo, cada equipe deverá instalar um roteador ADSL e usá-lo para acessar a rede do IFSC (a infraestrutura ADSL será implantada pelo professor).

Etapa 3: fazer e receber chamadas da rede telefônica convencional ou celular

Os soft PBX Asterisk podem fazer e receber chamadas telefônicas se houver interfaces de hardware apropriadas. Como vocês já devem ter estudado em Telefonia, os tipos de canal para comunicação telefônica se dividem em tronco analógico (interface FXO) e tronco digital (E1). Há também canais GSM para acesso à rede celular. Para interligar a infraestrutura VoIP à rede telefônica deve-se, portanto, instalar e usar equipamentos capazes de fazer essa interface.

Nesta etapa iremos usar os módulos EBS da Khomp para interligar nossa infraestrutura VoIP à rede telefônica.

Etapa 4: fazer chamadas com segurança (à prova de grampo)

Uma conversa com VoIP pode ser facilmente interceptada e grampeada. Basta conseguir rodar o wireshark ou tcpdump em um ponto da rede por onde passam os datagramas UDP da stream de audio. Imagine então se VoIP se tornar um serviço de uso disseminado - o que é bem possível com a popularização de tablets e smartphones. Serviços VoIP proprietários, como Skype e Viber, possuem proteções para evitar a invasão de privacidade de seus usuários - mas isso não impediu que o governo americano grampeasse indiscriminadamente seus cidadãos ;-) Nesta etapa do projeto, vamos proteger as chamadas feitas dentro da nossa infraestrutura VoIP.

Aula 11/06: NÃO HOUVE AULA (GREVE DE ÔNIBUS)

Aula 18/06: Avaliação 1

Aula 25/06: Projeto - Etapa 1

Começando pela Etapa 1.

Aula 02/07: Projeto - Etapa 1

Aula 09/07: Projeto - Etapa 2

Ainda a etapa 1: como fazer chamadas para outros provedores explorando DNS:

  1. Deve-se configurar em sip.conf para que o Asterisk aceite chamadas não-autenticadas, e que elas devem ser processadas no contexto externo:
    [general]
srvlookup=yes
domain=tip1.sj.ifsc.edu.br,meu_dominio
context=externo
  2. Deve-se configurar o plano de deiscagem (extensions.conf) para fazer chamadas para outros provedores, se o domínio SIP (contido na variável SIPDOMAIN) for diferente do domínio deste provedor.
    [tip]
exten=>_1XX,1,Dial(SIP/${EXTEN})
same=>n,Hangup

[meu_dominio]
exten=>_1.,1,GotoIf($[${LEN(${SIPDOMAIN})} = 0]?tip,${EXTEN},1)
same=>n,GotoIf($["${SIPDOMAIN}" = "tip.sj.ifsc.edu.br"]?tip,${EXTEN},1)
same=>n,Dial(SIP/${EXTEN}@${SIPDOMAIN})
same=>n,Hangup

[externo]
include=>tip

Aula 16/07: Projeto - Etapa 3

Aula 23/07: Projeto - Etapa 4

Aula 30/07: Conclusão e recuperação

Referências

  • Livros sobre VoIP
    • KUROSE, James F. e ROSS, Keith W. Redes de computadores e a Internet, Uma abordagem Top-Down. 5a edição. Editora Addison Wesley SP, 2010. (ver capítulo 7)
    • Sérgio Colcher, Antônio Tadeu Azevedo Gomes, e Anderson Oliveira da Silva. VoIP: Voz sobre IP. Campus, 1a edição, 2005.

Roteamento de chamadas na Internet com o Asterisk

[1]

[2]

[3]

http://docwiki.cisco.com/wiki/Voice/Data_Integration_Technologies#Voice_Networking

Visualland

Aulas Telefonia IP - Ederson

Aulas Sobral/Emerson RMU

Guia básico de VoIP com Asterisk - Ederson

http://www.voip-info.org/wiki/view/SIP

http://www.cisco.com/en/US/docs/voice_ip_comm/sip/proxies/2.1/administration/guide/fflows.html

http://ftp.iptel.org/pub/ser/0.8.14/doc/html/sip_introduction.html

http://tools.ietf.org/html/rfc3665

http://www.radvision.com/NR/rdonlyres/0AFA30DF-DAD6-461D-943C-ED33F3E7ABD8/0/SIPServerTechnicalOverviewWhitepaper.pdf

Disponível em “https://wiki.sj.ifsc.edu.br/index.php?title=TIP-2013-1-Integrado_Telefonia_IP_-_Integrado&oldid=57191”