Mudanças entre as edições de "PJI4-2017-2"
Linha 1 683: | Linha 1 683: | ||
{{collapse bottom | Aula 16}} | {{collapse bottom | Aula 16}} | ||
+ | |||
+ | == 06/10: VoIP e NAT== | ||
+ | |||
+ | {{collapse top | Aula 17}} | ||
+ | |||
+ | 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. | ||
+ | |||
+ | Para entendermos os problemas causados pelo NAT na telefonia IP, iremos primeiramente fazer uma investigação utilizando como base para isso todo o conhecimento sobre os protocolos SIP, SDP e RTP previamente adquiridos. Assim, iremos implementar os cenários descritos na '''Atividade 1''' e posteriormente '''Atividade 2''', fazer chamadas de teste, capturar os pacotes destas chamadas utilizando o ''Wireshark'' e posterior análise destes. | ||
+ | |||
+ | <br> | ||
+ | |||
+ | ==Atividade 1- Softphone atrás de NAT== | ||
+ | |||
+ | [[Imagem:Cenário1-Aula7.png|400px]] | ||
+ | |||
+ | #A comunicação entre canais SIP internos a cada PABX IP de cada aluno deve estar funcionando corretamente (sinalização e áudio) tanto com REINVITE como SEM REINVITE; | ||
+ | #A comunicação entre canais SIP de diferentes PABX IP deve estar funcionando corretamente tanto com REINVITE como SEM REINVITE; | ||
+ | #Cada aluno deve montar uma estrutura de rede que será apresentada em aula utilizando AP TP-LINK; | ||
+ | #Fazer as devidas configurações para que tenha áudio nas comunicações entre os diferentes PABX IP. | ||
+ | |||
+ | <br> | ||
+ | |||
+ | |||
+ | ==Solução utilizando o Asterisk== | ||
+ | |||
+ | * [http://www.smartvox.co.uk/astfaq_configbehindnat.htm Dicas sobre Asterisk + 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: | ||
+ | |||
+ | <syntaxhighlight lang=text> | ||
+ | nat=yes | ||
+ | qualify=yes | ||
+ | directmedia=no | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | [http://www.voip-info.org/wiki/view/Asterisk+sip+nat Aqui] tem uma boa explicação sobre o que fazem essas opções. | ||
+ | |||
+ | <br> | ||
+ | |||
+ | ==Atividade 2- Asterisk atrás de NAT== | ||
+ | |||
+ | [[Imagem:Cenário1-Aula8.png|400px]] | ||
+ | |||
+ | #Configurar a rede indicada na figura acima. Para isso, utilizar uma VM Servidor como roteador com NAT habilitado; | ||
+ | #Abrir o Wireshark na máquina onde o Asterisk está instalado; | ||
+ | #Tentar registrar um usuário SIP usando o softphone mostrado na figura. Foi possível? A máquina Asterisk recebeu alguma solicitação? | ||
+ | #Fazer as configurações necessárias para que o Asterisk receba as as solicitações vindas do softphone; | ||
+ | #Uma vez o usuário estando registrado, fazer testes de chamadas e verificar se há áudio. | ||
+ | |||
+ | <br> | ||
+ | |||
+ | ==Solução utilizando o Asterisk== | ||
+ | |||
+ | <br> | ||
+ | '''Redirecionamento de portas em Roteador Linux''' | ||
+ | |||
+ | Para fazermos o redirecionamento de um fluxo entrante para outro servidor, devemos executar o seguinte: <code> iptables -t nat -A PREROUTING -d ip_de_destino_do_pacote -p protocolo --dport porta_de_destino -j DNAT --to ip_servidor_interno:porta_servidor_interno </syntaxhighlight> | ||
+ | |||
+ | Para vermos as regras de NAT criadas executamos o seguinte comando: <code> iptables -t nat -L</syntaxhighlight> | ||
+ | |||
+ | <br> | ||
+ | '''Configuração sip.conf''' | ||
+ | |||
+ | 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 na seção [general] [http://www.voip-info.org/wiki/view/Asterisk+config+sip.conf#SIPConfigurationgeneral]: | ||
+ | |||
+ | <syntaxhighlight lang=text> | ||
+ | [general] | ||
+ | externip=IP_público | ||
+ | |||
+ | ; 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 | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | |||
+ | '''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 ... | ||
+ | |||
+ | <br> | ||
+ | |||
+ | '''Dica para testar o áudio''' | ||
+ | |||
+ | Para testar o áudio com apenas um ''softphone'' logado você pode criar uma ''extension'' no arquivo '''extensions.conf''' que toque uma música. Segue abaixo: | ||
+ | |||
+ | <code> exten=>999,1,Answer | ||
+ | exten=>999,n,Playback(tt-monkeys) | ||
+ | exten=>999,n,Hungup()</syntaxhighlight> | ||
+ | |||
+ | '''Ativar NAT em Roteador Linux''' | ||
+ | |||
+ | Configurar as máquinas servidoras para fazer NAT:<code>iptables -t nat -A POSTROUTING -s 10.0.1.0/24 -o eth0 -j MASQUERADE</syntaxhighlight> Lembre-se de adequar a interface (eth0, eth1, ...) para o seu caso e também a rede (10.0.2.0/24, 10.0.3.0/24. ...). | ||
+ | |||
+ | == STUN: Session Traversal Utilities for NAT == | ||
+ | |||
+ | * [http://tools.ietf.org/html/rfc5389 RFC 5389] | ||
+ | |||
+ | |||
+ | '''''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. | ||
+ | |||
+ | [[imagem:Voip-call.png|600px]] | ||
+ | <br>''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. | ||
+ | |||
+ | |||
+ | [[imagem:Sdp.png|800px]] | ||
+ | <br>''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. | ||
+ | |||
+ | [[imagem:STUN.png|600px]] | ||
+ | <br>''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. | ||
+ | |||
+ | |||
+ | [[imagem:Stun-diagram.png|600px]] | ||
+ | <br>''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. Como será visto em uma [[RMU-2012-1#11.2F04:_Firewall|aula futura]], isso só é possível se o NAT for do tipo [http://en.wikipedia.org/wiki/Full_cone_NAT ''full cone''], [http://en.wikipedia.org/wiki/Restricted_cone_NAT ''restricted cone''] ou [http://en.wikipedia.org/wiki/Port_restricted_cone_NAT ''port restricted cone'']. Quer dizer, se o NAT for do tipo [http://en.wikipedia.org/wiki/Symmetric_NAT 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 [http://www.vovida.org/applications/downloads/stun/ servidor STUN para Linux] (disponível no Ubuntu via apt). Basta instalá-lo em um computador e usá-lo como servidor STUN, contanto que ele esteja ''do outro lado'' do NAT. No laboratório de Programação foi ativado um servidor STUN no computador dos professores, e ele atende em '''192.168.1.231'''. Esse servidor atende apenas a necessidade dos experimentos dentro do laboratório. No caso geral, quando o servidor STUN deve possuir endereços IP válidos, existem servidores públicos, conforme mostrado na listagem abaixo: | ||
+ | |||
+ | <syntaxhighlight lang=text> | ||
+ | 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 | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | [http://www.voip-info.org/wiki/view/STUN Maiores detalhes sobre servidores STUN] | ||
+ | |||
+ | {{collapse bottom | Aula 17}} |
Edição das 17h27min de 3 de outubro de 2017
Endereço encurtado: http://bit.ly/pji4-20172
Projeto Integrador IV
Professores: Marcelo Maia Sobral ( Facebook) e Ederson Luiz de Souza Santos (ederson.luiz@ifsc.edu.br)
Encontros: 3a feira/19:00, 6a feira/19:00
Atendimento paralelo: 3a e 6a feira 18:30 h
Coordenadoria pedagógica (Graciane): graciane@ifsc.edu.br (3381-2890, 3381-2842)
Objetivo Geral
- Implantar um PABX IP integrado com serviços de telefonia fixa e móvel convencionais.
- Prover a infraestrutura de rede necessária para o adequado funcionamento deste PABX IP.
- Integrar os serviços de telefonia com outros serviços de rede.
Links interessantes
- VoIP Hacking Techniques
- Asterisk não é um SIP proxy
- FoneRNP
- SwitchVox: PBX virtual
- Net Fone da Embratel é VoIP, mas não usa SIP]
- Estatísticas sobre VoIP no mundo
Provedores VoIP no Brasil
Avaliações
Aluno(a) | Avaliação 1 | Avaliação 2 | Avaliação 3 | Avaliação 4 | Nota final |
---|
Resumo de comandos da CLI para o Asterisk
- O Asterisk pode ser carregado de duas formas:
- foreground: utilizado para depurar problemas na inicialização do Asterisk, quando ele não puder ser inicializado.
- background: modo padrão de inicialização
- Conectar à CLI do Asterisk carregado
asterisk -r rasterisk
- Comandos na CLI
- Saindo da CLI sem interromper o processo
exit
- Carrega canais SIP previamente registrados
sip reload
- Mostra canais SIP registrados
sip show peers
- Carrega plano de discagem
dialplan reload
- Mostra a extensão criada no plano de discagem
dialplan show default
- Finalizando processo no Asterisk
sudo core stop now
- Ver aplicações disponíveis no Asterisk
core show applications
- Saindo da CLI sem interromper o processo
- Iniciando Asterisk em modo Background
sudo service asterisk start
- Carregar o Asterisk em modo ForeGround
sudo asterisk -gc
28/07: Apresentação da disciplina
Aula 1 |
---|
PBX IPUm 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.
PBX IP Asterisk
Características Básicas: faz tudo que um PABX pequeno e simples faz e pouco mais
Plano de discagemO 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:
[default]; o nome deste contexto ... default é o contexto predefinido do Asterisk
# 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
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
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 SIPCada 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]
defaultuser=maria ; 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 ;
disallow=all
allow=gsm ; habilita este codec para o João.
allow=alaw ; outro codec
allow=ulaw ; mais um codec
qualify=yes; monitora o UAC
; Canal 1000 (outro exemplo)
[1000]
defaultuser=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 ;
disallow=all
allow=gsm ; habilita este codec
allow=alaw ; outro codec
allow=ulaw ; mais um codec
qualify=yes; monitora o UAC
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 ;
disallow=all
allow=gsm ; habilita este codec
allow=alaw ; outro codec
allow=ulaw ; mais um codec
qualify=yes; monitora o UAC
; Canal 2000
[2000](alunos); a sequência "(alunos)" copia as definições do perfil "alunos"
defaultuser=maria ; o nome do usuário para fins de autenticação
secret=kabrum
; Canal joao
[joao](alunos)
defaultuser=joao ; o nome do usuário para fins de autenticação
secret=blabla
Experimento: comunicação entre telefones IP ou softphones por meio de um PBX IP
2. Crie um plano de discagem em que todos podem fazer chamadas para todos (isso é, 100 pode chamar 101, e vice-versa). 3. Configure os softphones de forma que se registrem no PBX Asterisk, usando as contas SIP criadas previamente. 5. A partir de um softphone faça uma chamada para a conta do outro softphone. Verifique se o softphone de destino acusou o recebimento de chamada. Caso isso não tenha ocorrido, verifique seu plano de discagem. Em seguida faça uma chamada em sentido contrário. 6. Execute o comando rasterisk -vvv no computador do Asterisk. 7. Usando o comando sip show peers, visualize os estados dos canais SIP conhecidos pelo Asterisk. 8. Refaça uma chamada entre os softphones, e observe o que aparece na tela do rasterisk. 9. Será possível verificar que chamadas estão em andamento no Asterisk usando o rasterisk ? Pesquise como se pode fazer isso. 10. Use o rasterisk para testar chamadas. Use o comando console dial canal_SIP para chamar um canal SIP (substitua canal_SIP pelo número a ser chamado). Ao final, execute console hangup. 11. Acrescente mais um canal SIP, editando o arquivo sip.conf. Configure um dos softphones para usar esse novo canal. 12. Teste chamadas entre os softphones usando esse novo número. Possíveis problemas
DICASComandos válidos no CLI do Asterisk:
|
02/08: Interligação de PBX Asterisk
Aula 2 | ||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Supondo que cada cliente do provedor tenha seu próprio PBX, pode ser necessário interligar suas centrais com o PBX do provedor. A interligação entre PBX Asterisk pode ser feita via rede de dados usando os protocolos SIP ou IAX2 (porém este segundo está em desuso). 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.
Tronco SIPEm 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 (mais detalhes sobre esses protocolos serão vistos em aulas posteriores). A ativação de um entroncamento SIP entre dois PBX Asterisk pode ser feita seguindo o exemplo abaixo:
Atividade: estabelecendo chamadas entre diferentes PBX AsteriskNesta atividade, vamos realizar chamadas entre softphones registrados em diferentes PBX Asterisk. Isso implica definir um plano de numeração para os ramais da empresa. Sendo assim:
Padrões de extensõesExtensões podem ser representadas de forma compacta com padrões de extensões. Com esse recurso, muitas extensões podem ser atendidas com um único conjunto de regras, evitando um plano de discagem repetitivo. Por exemplo, se uma empresa possui ramais entre 100 e 199, o plano de discagem pode ser escrito assim: exten=>_1XX,1,Dial(SIP/${EXTEN})
same=>n,Hangup
A extensão _1XX contida na primeira linha está escrita como um padrão (pattern), pois inicia com o caractere _. Os caracteres que seguem _ indicam cada dígito que deve aparecer para satisfazer essa extensão. Nesse exemplo, deve aparecer 1 seguido de dois dígitos quaisquer entre 0 e 9 (é esse o significado do caractere X). Desta forma, essa extensão atende qualquer número entre 100 e 199. Por fim, o número de fato chamado é armazenado na variável ${EXTEN}, que pode assim ser usada dentro da regra de discagem. Alguns caracteres têm significado especial em padrões, como mostrado no exemplo (caractere X). A tabela abaixo lista esses caracteres:
VariáveisO uso de variáveis no Asterisk possui funcionamento semelhante àquele encontrado nas linguagens de programação, permitindo ao “programador” utilizar variáveis já definidas pelo Asterisk bem como definir suas próprias variáveis. As definições das variáveis devem ser feitas no arquivo extensions.conf. A sintaxe para trabalhar com variáveis no Asterisk é semelhante a do c-shell, porém as variáveis definidas pelo usuário não são sensíveis a caixa, ou seja, VAR e var referem-se à mesma variável.
Existem três tipos de variáveis:
Abaixo se pode ver um exemplo de plano de discagem que usa variáveis: [globals]
; definicao de uma variavel global
VENDAS=SIP/6112
[alunos]
; definicao de uma variavel global atraves do comando Global e aplicacao Set
exten=> 6666,1,Set(GLOBAL(COMPRAS)=SIP/6113)
exten=> 6666,2,NoOp(${GLOBAL(COMPRAS)})
; definicao de uma variavel especifica ao canal
exten=> 7777,1,Set(teste=1)
exten=> 7777,n,NoOp(${teste})
exten=> 7777,n,Set(teste=$[${teste} + 1])
exten=> 7777,n,NoOp(${teste})
exten=> 7777,n,Hangup
Extensões especiaisAlém das extensões criadas pelo usuário, o Asterisk apresenta algumas extensões especiais, tais como:
|
11/08: Projeto 1: continuação sobre entroncamento
Aula 3 |
---|
15/08: Projeto 1: Planejamento da Portaria Eletrônica
Aula 4 |
---|
|
18/08: Projeto 1: Funções de PABX
Aula 5 |
---|
Funções usando o plano de discagemPara implantar funcionalidades conhecidas ou novas no Asterisk usando o plano de discagem, devem-se conhecer alguns recursos avançados. Aqui são apresentados quatro deles: extensões especiais, aplicações, padrões de extensões e variáveis. AplicaçõesAs aplicações são usadas no plano de discagem. Assim, o processamento de uma chamada se faz pela execução sucessiva de aplicações, de forma a se obter o efeito desejado. DialEncaminha a chamada para um destino. Exemplo: exten=>_1XXXX,1,Dial(SIP/${EXTEN})
same=>n,hangup
BackgroundToca um arquivo de som como música de fundo. Esse arquivo deve estar em /usr/share/asterisk/sounds, e ser codificado com codec PCM ou WAV. Exemplo: exten=>666,1,Answer
same=>n,Background(hello-world)
same=>n,Hangup
PlaybackToca um arquivo de som. A diferença em relação a Background é que Playback devolve o controle ao Asterisk (i.e. ao plano de discagem) somente após tocar todo o arquivo. Esse arquivo deve estar em /usr/share/asterisk/sounds, e ser codificado com codec PCM ou WAV. Exemplo: exten=>666,1,Answer
same=>n,Playback(hello-world)
same=>n,Hangup
WaitForça uma espera durante o processamento da chamada. Exemplo: exten=>666,1,Answer
same=>n,Playback(hello-world)
same=>n,Wait(1)
same=>n,Playback(beep)
same=>n,Hangup
Answer e HangupAnswer atende uma chamada. Hangup termina uma chamada. Exemplo: exten=>666,1,Answer
same=>n,Playback(hello-world)
same=>n,Hangup
GoToPula para um contexto (opcional), extensão, prioridade específica. Exemplo: exten=>100,1,GoTo(vendas,s,1)
GoToIfTrata-se do comando GoTo condicional. Sua sintaxe é: GoToIf(condição?[rótulo se verdade]:[rótulo se falso]) Os rótulos podem assumir a forma: [[contexto],extensão,]prioridade Exemplo: [alunos]
exten=>6111,1,GoToIf($["${CALLERID(num)}" != "6112"]?2:4)
same=> n,Dial(SIP/6111,30)
same=> n,Hangup
same=> n,Answer
same=> n,Playback(hello-world)
same=> n,Hangup
SetModifica o valor de uma variável. Exemplo: exten=>666,1,Set(Tentativas=1)
same=>2,Dial(SIP/666,10)
same=>3,Set(Tentativas=${Tentativas}+1)
same=>4,GoToIf($[${Tentativas} < 2]?2:5)
same=>5,Hangup
LogGrava um texto qualquer no log do Asterisk. Exemplo: exten=>666,1,Log(DEBUG,"Chamada para 666")
same=>n,Dial(SIP/666,10)
same=>n,Hangup
NoOpNão faz nada, sendo útil para depurar o plano de discagem. Exemplo: exten=>100,1,NoOp(${CONTEXT})
Atividades
|
22/08: Projeto 1: Funções de PABX (continuação)
Aula 6 |
---|
25/08: Projeto 1: Funções de PABX (continuação)
Aula 7 |
---|
29/08: Projeto 1: Funções de PBX: URA e correio de voz
Aula 8 |
---|
Hoje serão vistas duas funcionalidades de uma central que podem ser aplicadas à portaria eletrônica:
URAO que é uma URA (Unidade de Resposta Audível) ? Clique na imagem abaixo ... Uma URA implementa um menu audível para auto-atendimento. Sua construção é feita toda no plano de discagem, como se pode ver no exemplo abaixo: [default]
exten => s,1,Answer
exten => s,2,NoOp(Ligação entrou na URA)
exten => s,n,Background(/var/lib/asterisk/sounds/benvindo)
exten => s,n,NoOp(Digite a opção/1-suporte/2-comercial/3-financeiro)
exten => s,n,WaitExten(6); caso nada tenha sido digitado durante a mensagem "benvindo", espera mais 6 segundos no máximo
exten => 1,1,NoOp(Chamada foi para Suporte)
same => n,Dial(SIP/2402,60)
same => n, Hangup
exten => 2,1,NoOp(Chamada foi para Comercial)
same => n,Dial(SIP/2801,60)
same => n, Hangup
exten => 3,1,NoOp(Chamada foi para Financeiro)
same => n,Dial(SIP/2000,60)
same => n, Hangup
exten => i,1,NoOp(Extensão inválida)
same => n,Playback(beep)
same => n,GoTo(s,3); volta para o menu
exten => t,1,NoOp(Tempo esgotado)
same => n,Dial(SIP/3401,60)
same => n,Hangup
A URA é composta por mensagens de voz, que instruem o usuário sobre o que ele pode fazer (isto é, apresentam as opções), e músicas, que o entreteem (!?) enquanto aguarda uma operação ser realizada. Assim, para criar uma URA minimamente funcional são necessários esses arquivos de voz. Para gravá-los, pode-se criar uma extensão especial, por exemplo, que atenda por 9005nome_de_um_arquivo. Ao chamar essa extensão, pode-se pronunciar a mensagem de voz assim que o Asterisk atender. Para encerrar a mensagem, deve-se digitar #. O arquivo de voz resultante estará no diretório /var/lib/asterisk/sounds, ou em qualquer outro diretório especificado na aplicação record. exten=>_9005.,1,answer()
same=>n,record(/var/lib/asterisk/sounds/${EXTEN:4}.wav,5,0)
same=>n,playback(/var/lib/asterisk/sounds/${EXTEN:4})
same=>n,hangup()
Para a implantação de uma URA (e de muitas outras funções típicas de PBX) em um PBX Asterisk, é necessário conhecer os recursos que ele oferece. Dentre esses recursos, há aplicações e variáveis, já estudados em aulas anteriores, e características (features). Hoje serão vistos alguns desses recursos, que usaremos para implantar uma URA. Atividade
Correio de voz
|
01/09: Outras funções de PBX
- Revisar o planejamento do projeto: muita coisa foi vista desde a escrita do plano de trabalho. A luz da sua compreensão atual sobre o que se consegue fazer com um PBX Asterisk, revise o seu plano.
Aula 9 |
---|
Após experimentar a implantação de um correio de voz e uma URA, podem-se conhecer outras possíveis funções de PBX existentes no Asterisk, tais como:
Essas funções podem ser úteis na infraestrutura de telefonia a ser implantada na primeira etapa do projeto. Como exemplo, algumas delas são apresentadas a seguir. Música de esperaO Asterisk permite o uso de MP3 como música de espera, porém MP3 são arquivos complicados de se trabalhar pois requerem o uso de aplicações externas para que possam ser reproduzidos, como por exemplo mpg123. Seu funcionamento também pode não agradar muito já que em alguns casos a música pode ser reproduzida em alta rotação além de elevar a carga de processamento da máquina no caso de soluções de grande porte. A partir da versão 1.2 do Asterisk se sugere não mais usar o mpg123. O melhor é converter arquivos MP3 para um formato que o Asterisk trate nativamente, como por exemplo, wav ou pcm (μLaw). A ferramenta ffmpeg pode ser usada para converter arquivos MP3 para WAV ou PCM. # convertendo o arquivo musica.mp3 para musica.wav e musica.pcm
ffmpeg -i musica.mp3 -ar 8000 -ac 1 -ab 64 musica.wav -ar 8000 -ac 1 -ab 64 -f mulaw
musica.pcm -map 0:0 -map 0:0
Os arquivos de música devem ficar em um diretório especificado para cada contexto, conforme definido no arquivo musiconhold.conf: # configuracao no arquivo musiconhold.conf
[alunos]
mode=files
directory=/var/lib/asterisk/moh
sort=random
# deve-se colocar os arquivos wav e/ou pcm no diretorio especificado acima
Para testar a música em espera no plano de discagem, pode-se usar a aplicação MusicOnHold: exten=>667,1,Set(CHANNEL(musicclass)=alunos)
same=>n,Answer
same=>n,MusicOnHold()
same=>n,Dial(SIP/667)
same=>n,Hangup
Filas de atendimentoAmplamente utilizadas nos sistemas de 0800. A configuração é feita no arquivo queues.conf: [fila-suporte]
musicclass=default
strategy=ringall; roundrobin, rrmemory
timeout=10
wrapuptime=30
periodic-announce = em-breve
periodic-announce-frequency=60
member=>SIP/6111
member=>SIP/6112
No plano de discagem a fila de atendimento pode ser usada da seguinte forma: [suporte]
exten=> s,1,Set(CHANNEL(musicclass)=suporte)
exten=> s,2,Playback(bem-vindo)
exten=> s,3,Queue(fila-suporte)
Captura de chamadasA captura possibilita que se puxe uma chamada de um colega no mesmo grupo de chamadas. Isso evita que se tenha que levantar para atender um telefone do seu vizinho que não para de tocar. A captura pode ser feita discando *8 (isso pode ser alterado no arquivo features.conf).
Para habilitar a captura de chamadas é suficiente definir a que grupo de chamadas cada canal pertence (parâmetro callgroup), e de que grupos se pode capturar chamadas (parâmetro pickupgroup). No caso de canais SIP isso fica em sip.conf: [joaozinho]
callgroup=1
pickupgroup=1,2
...
Estacionamento de chamadasO estacionamento de chamadas é feito no arquivo features.conf fazendo uso dos seguintes parâmetros:
Abaixo se pode ver um exemplo de plano de discagem que usa estacionamento de chamadas: [vendas]
include=>parkedcalls
exten=>6200,1,Dial(SIP/6200,30,tT)
exten=>6200,n,Hangup
Atividades
|
05/09: Projeto 1: outras funções de PBX
Aula 10 |
---|
12/09: Projeto 1: Implantação do protótipo do porteiro IP
Aula 11 |
---|
Nesta primeira etapa da disciplina, introduziu-se um PBX IP e suas funções. Esse estudo não foi exaustivo, pelo contrário. Houve a preocupação de realizar um primeiro contato com a tecnologia, principalmente quanto à lógica envolvida em sua utilização. Essa investigação preliminar foi fundamental para se criar uma base de conhecimento necessária à realização do projeto do Porteiro IP. Uma possível estrutura para o sistema do Porteiro IP está ilutsrada a seguir. Nessa figura se podem ver a central que comandas as funções do porteiro, o painel com teclado, microfone e falante, combinado a uma fechadura elétrica para portão, para uso de pessoas que desejam entrar no condomínio, e os interfones e telefones celulares dos moradores.
|
15/09: Projeto 1: Implantação do protótipo
Aula 12 |
---|
19/09: Projeto 1: Implantação e conclusão do protótipo
Aula 13 |
---|
O programa que envia a mensagem contendo o comando de abertura do portão deve ser executado no PBX quando um morador pressionar uma tecla específica em seu interfone. Somente quando uma chamada entre interfone e painel do portão estiver em andamento esse programa pode ser executado. Para que isso funcione, o PBX deve ser capaz de interpretar uma notificação de dígito pressionado vinda do interfone. O Asterisk é capaz desse tipo de ação por meio de features, as quais estão configuradas no arquivo features.conf. Uma feature associa uma sequência de um ou mais dígitos a uma ação a ser executada no PBX. Algumas features são predefinidas, tais como transferência e captura de chamada. Novas features podem ser definidas na seção applicationmap do arquivo features.conf. Uma nova feature associa uma sequência de dígitos a uma aplicação típica de plano de discagem. Para maiores informações, abra esse arquio e leia a explicação contida na seção applicationmap. Dica: a execução de um programa no PBX pode ser feita com a aplicação System. O exemplo a seguir mostra a definição de uma nova feature chamada chaveia. Essa feature associa a tecla 0 (zero) à aplicação Playback(tt-monkeys): chaveia => 0,self,Playback,tt-monkeys A definição de uma feature segue então o formato: nome_da_feature => sequência,canal,aplicação,argumentos da aplicação Sendo que:
Além disso, para que uma feature esteja disponível em uma chamada, a variável de canal DYNAMIC_FEATURES deve estar definida. Por exemplo: [default]
exten=>_[123]XX,1,noop(painel chamando apto ${EXTEN})
same=>n,Set(DYNAMIC_FEATURES=chaveia)
same=>n,Dial(SIP/${EXTEN},30)
same=>n,hangup()
O exemplo acima possibilita que o canal originador da chamada ative a feature chaveia. Porém no caso do porteiro VoIP não é isso que se deve fazer. As chamadas se originam do painel para algum morador, e por isso não pode ser o canal originador quem abre o portão. Se assim fosse, o próprio painel liberaria o portão ! A solução é liberar a execução da feature somente no canal chamado (interfone). O Asterisk não tem um jeito direto de fazer isso, então é necessário o pequeno truque mostrado a seguir: [macaquinhos]
exten=>s,1,noop(ativa feature para tocar macaquinhos)
same=>n,Set(DYNAMIC_FEATURES=chaveia)
same=>n,Return
[default]
exten=>_[123]XX,1,noop(painel chamando apto ${EXTEN})
same=>n,Dial(SIP/${EXTEN},30,U(macaquinhos))
same=>n,hangup()
No exemplo acima, usa-se o conceito de subrotina para ativar a feature no canal chamado. A opção U(macaquinhos) da aplicação Dial faz com que a subrotina macaquinhos seja executada no canal chamado quando atender a chamada. Uma subrotina se assemelha a um contexto que possui somente a extensão s. A chamada é processada nessa extensão até que apareça a aplicação Return, que termina a subrotina. Com isso consegue-se ativar a feature somente no interfone. |
22/09: Projeto 1: O protocolo SIP
Aula 14 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
O protocolo SIPO protocolo SIP segue um modelo P2P (peer-to-peer), em que dois ou mais participantes, chamados de agentes, trocam mensagens com a finalidade de estabelecerem algum tipo de sessão (de voz no nosso caso, mas pode ser de video, mensagem instantânea, ou algum outro tipo de serviço). Assim, cada agente em uma sessão SIP se comporta tanto como cliente (quando envia requisições SIP) quanto servidor (quando responde a requisições SIP). A parte que inicia requisições se chama UAC (User Agent Client), e a que responde requisições é denominada UAS (User Agent Server), estando ambas implementadas nos telefones IP e similares. Uma sessão SIP envolve a interação entre duas entidades lógicas, que no caso de chamadas VoIP são por vezes chamadas simplesmente de usuários. A diferença entre entidade lógica e agente é que a primeira é o usuário (recurso) que inicia ou recebe chamadas, e o segundo é a aplicação que contém os mecanismos para efetuar e receber chamadas - pense que a entidade seria uma pessoa, e o agente o aparelho telefônico em uma chamada telefônica convencional. Cada entidade é identificada por uma URI (Uniform Resource Indicator) SIP, semelhante a um número de telefone. Além de identificar uma entidade lógica, a informação em uma URI SIP indica a forma com que essa entidade deve ser contatada via SIP. Exemplos de URI SIP seguem abaixo: # Uma URI simples, tipicamente usada em mensagens INVITE (que iniciam sessões SIP)
sip:1234@biloxi.example.com
# Uma URI mais elaborada, tipicamente usada em alguns cabeçalhos SIP (ex: Contact ou Refer-to)
sip:joseph.fourier@transform.org:5060;transport=udp;user=ip;method=INVITE;ttl=1;
maddr=240.101.102.103?Subject=FFT
As comunicações SIP seguem uma hierarquia, cujos níveis são:
Mensagens SIPO protocolo SIP tem uma estrutura simplificada com mensagens de pedido e resposta, assemelhando-se ao protocolo HTTP. Essas mensagens possuem a seguinte estrutura: Linha inicial
Cabeçalho1: valor do cabeçalho 1
Cabeçalho2: valor do cabeçalho 2
...
CabeçalhoN: valor do cabeçalho N
<linha em branco>
corpo da mensagem (opcional)
A diferença básica entre pedidos e respostas SIP está na linha inicial: pedidos contém um método SIP e seus parâmetros, e respostas possuem um código de status junto com um curto texto informativo. Abaixo são mostradas duas mensagens SIP: um pedido e sua respectiva resposta. Nesse exemplo, ambas mensagens não possuem um corpo de mensagem (lembre que isso é opcional):
REGISTER sips:ss2.biloxi.example.com SIP/2.0
Via: SIP/2.0/TLS client.biloxi.example.com:5061;branch=z9hG4bKnashds7
Max-Forwards: 70
From: Bob <sips:bob@biloxi.example.com>;tag=a73kszlfl
To: Bob <sips:bob@biloxi.example.com>
Call-ID: 1j9FpLxk3uxtm8tn@biloxi.example.com
CSeq: 1 REGISTER
Contact: <sips:bob@client.biloxi.example.com>
Content-Length: 0
Resposta: SIP/2.0 200 OK
Via: SIP/2.0/TLS client.biloxi.example.com:5061;branch=z9hG4bKnashd92
;received=192.0.2.201
From: Bob <sips:bob@biloxi.example.com>;tag=ja743ks76zlflH
To: Bob <sips:bob@biloxi.example.com>;tag=37GkEhwl6
Call-ID: 1j9FpLxk3uxtm8tn@biloxi.example.com
CSeq: 2 REGISTER
Contact: <sips:bob@client.biloxi.example.com>;expires=3600
Content-Length: 0
O pedido exemplificado foi uma mensagem do tipo REGISTER, que é um tipo de método SIP. Um método pode ser entendido como um comando enviado de um participante a outro. A resposta contém o status 200 OK, que significa que o pedido foi atendido com sucesso. Por fim, ambas mensagens contiveram um conjunto de cabeçalhos necessários para caracterizá-las, dentre eles Via, From, To, Call-Id, CSeq, Contact e Content-Length. As tabelas a seguir descrevem resumidamente os principais métodos e cabeçalhos SIP.
Tabela de métodos SIP (não exaustiva ... apenas os principais métodos)
Tabela de cabeçalhos SIP (não exaustiva ... apenas os principais cabeçalhos)
Tabela com as classes de respostas AtividadesNas análises pedidas a seguir, faça o seguinte:
Usando o wireshark faça o seguinte:
Diagramas de chamadasAlguns tipos de chamadas VoIP com SIP são recorrentes, estando representadas nas subseções a seguir. Registro de agente SIP em um proxy SIPEsta chamada ocorre entre um agente SIP e um servidor de registro SIP (SIP Registar), que está implementado tipicamente em um proxy SIP, um gateway de media, ou um PBX IP (este último incorpora as funções dos dois primeiros com as de um PBX). O registro do agente SIP tem por finalidade fazer com que o servidor de registro SIP conheça a localização do agente (endereço IP e port usado pelo UAS). Fone 1 Proxy SIP ou PBX IP
| |
| REGISTER |
|---------------------------->|
| 401 Unauthorized |
|<----------------------------|
| REGISTER |
|---------------------------->|
| 200 OK |
|<----------------------------|
| |
Chamada direta entre dois agentes SIPUma chamada direta entre dois agentes envolve uma transação INVITE, em que um agente convida o outro a estabelecer uma sessão SIP com um determinado tipo de media (ex: audio). A chamada é finalizada quando um dos agentes inicia uma transação BYE. Fone 1 Fone 2
| |
| INVITE |
|----------------------->|
| 180 Ringing |
|<-----------------------|
| |
| 200 OK |
|<-----------------------|
| ACK |
|----------------------->|
| RTP Media |
|<======================>|
| |
| BYE |
|<-----------------------|
| 200 OK |
|----------------------->|
| |
Chamada entre dois agentes SIP com intermediação de um Proxy SIPA principal diferença entre este tipo de chamada e o anterior é o uso de um (ou mais) proxy SIP entre os dois agentes. O proxy SIP tem por finalidade ajudar na realização das chamadas, uma vez que usualmente incorpora a função de servidor de registro. Um proxy SIP encaminha chamadas para o agente chamado, ou para outro proxy mais próximo do destino, podendo aplicar regras de controle de acesso quanto a quem pode realizar chamadas para quem. Fone 1 Proxy SIP ou PBX IP Fone 2
(directmedia=yes)
| | |
| INVITE | |
|--------------->| INVITE |
| 100 Trying |--------------->|
|<---------------| 100 Trying |
| |<---------------|
| | |
| | 180 Ringing |
| 180 Ringing |<---------------|
|<---------------| |
| | 200 Ok |
| 200 Ok |<---------------|
|<---------------| |
| ACK | |
|--------------->| ACK |
| |--------------->|
| | |
| RTP Media |
|<===============================>|
| | |
| | BYE |
| BYE |<---------------|
|<---------------| |
| 200 Ok | |
|--------------->| 200 Ok |
| |--------------->|
| | |
| | |
Chamada entre dois agentes SIP com intermediação de um gateway de mediaEste caso é parecido com o anterior, que usa um proxy SIP. A diferença está na intermediação do fluxo de media, que é feita pelo gateway de media. 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 |<---------------|
|<---------------| |
| | |
Chamada entre dois agentes SIP com intermediação de um gateway de media e uso de re-INVITEO uso de re-invite possibilita que o fluxo de media seja estabelecido diretamente entre os agentes SIP, caso usem o mesmo codec. Assim, evita-se a carga de processamento envolvida na intermediação pelo gateway de media. Isso é feito com o envio pelo gateway de media (representado abaixo por um PBX IP) de um novo INVITE para cada agente SIP, após a sessão SIP estar estabelecida. Esse novo INVITE contém uma descrição de media (mensagem SDP embutida no corpo da mensagem INVITE) com a localização do outro agente SIP - isso é, seu endereço IP, port UDP para a stream RTP e codec a ser usado. Fone 1 PBX IP Fone 2
(directmedia=yes)
| | |
| INVITE | |
|--------------->| INVITE |
| 100 Trying |--------------->|
|<---------------| 100 Trying |
| |<---------------|
| | 180 Ringing |
| 180 Ringing |<---------------|
|<---------------| |
| | 200 Ok |
| 200 Ok |<---------------|
|<---------------| |
| ACK | |
|--------------->| ACK |
| INVITE |--------------->|
|<---------------| INVITE |
| 200 OK |--------------->|
|--------------->| 200 OK |
| ACK |<---------------|
|--------------->| ACK |
| |<---------------|
| |
| RTP Media |
|<===============================>|
| BYE | |
|--------------->| BYE |
| |--------------->|
| | 200 Ok |
| 200 Ok |<---------------|
|<---------------| |
| | |
AtividadesNas análises pedidas a seguir, faça o seguinte:
|
26/09: O protocolo SDP e o transporte de midia
Aula 15 | ||||
---|---|---|---|---|
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:
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:
Atividade
O transporte de midia com protocolo RTP
RTCPAlé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:
Os cinco tipos de relatórios são:
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. AtividadeEssa atividade busca ilustrar os fluxos RTP com um exemplo:
|
03/10: Investigando os protocolos envolvidos nas chamadas
Aula 16 |
---|
Sinalização com SIPAs chamadas que realizamos por meio do Asterisk foram iniciadas e terminadas usando protocolo SIP. Elas podem ser enquadradas em dois casos:
Os diagramas a seguir servem para melhor entender como ocorrem as comunicações em cada caso. Chamada entre dois agentes SIP com intermediação de um gateway de mediaEste caso é parecido com o anterior, que usa um proxy SIP. A diferença está na intermediação do fluxo de media, que é feita pelo gateway de media. 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 |<---------------|
|<---------------| |
| | |
Chamada entre dois agentes SIP com intermediação de um gateway de media e uso de re-INVITEO uso de re-invite possibilita que o fluxo de media seja estabelecido diretamente entre os agentes SIP, caso usem o mesmo codec. Assim, evita-se a carga de processamento envolvida na intermediação pelo gateway de media. Isso é feito com o envio pelo gateway de media (representado abaixo por um PBX IP) de um novo INVITE para cada agente SIP, após a sessão SIP estar estabelecida. Esse novo INVITE contém uma descrição de media (mensagem SDP embutida no corpo da mensagem INVITE) com a localização do outro agente SIP - isso é, seu endereço IP, port UDP para a stream RTP e codec a ser usado. Fone 1 PBX IP Fone 2
(directmedia=yes)
| | |
| INVITE | |
|--------------->| INVITE |
| 100 Trying |--------------->|
|<---------------| 100 Trying |
| |<---------------|
| | 180 Ringing |
| 180 Ringing |<---------------|
|<---------------| |
| | 200 Ok |
| 200 Ok |<---------------|
|<---------------| |
| ACK | |
|--------------->| ACK |
| INVITE |--------------->|
|<---------------| INVITE |
| 200 OK |--------------->|
|--------------->| 200 OK |
| ACK |<---------------|
|--------------->| ACK |
| |<---------------|
| |
| RTP Media |
|<===============================>|
| BYE | |
|--------------->| BYE |
| |--------------->|
| | 200 Ok |
| 200 Ok |<---------------|
|<---------------| |
| | |
Atividade
|
06/10: VoIP e NAT
Aula 17 |
---|
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:
Para entendermos os problemas causados pelo NAT na telefonia IP, iremos primeiramente fazer uma investigação utilizando como base para isso todo o conhecimento sobre os protocolos SIP, SDP e RTP previamente adquiridos. Assim, iremos implementar os cenários descritos na Atividade 1 e posteriormente Atividade 2, fazer chamadas de teste, capturar os pacotes destas chamadas utilizando o Wireshark e posterior análise destes.
Atividade 1- Softphone atrás de NAT
Solução utilizando o AsteriskO 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.
Atividade 2- Asterisk atrás de NAT
Solução utilizando o Asterisk
Para fazermos o redirecionamento de um fluxo entrante para outro servidor, devemos executar o seguinte:
|