Mudanças entre as edições de "TIP-IntTel (2020.1)"
Linha 961: | Linha 961: | ||
Entre centrais telefônicas e entre centrais e PABXs normalmente os enlaces são realizados por troncos [http://en.wikipedia.org/wiki/E-carrier E1] (ou hierarquias destes troncos). Nestes sistemas os canais digitais são multiplexados no tempo ([http://en.wikipedia.org/wiki/Multiplexing#Time-division_multiplexing ver aqui]). | Entre centrais telefônicas e entre centrais e PABXs normalmente os enlaces são realizados por troncos [http://en.wikipedia.org/wiki/E-carrier E1] (ou hierarquias destes troncos). Nestes sistemas os canais digitais são multiplexados no tempo ([http://en.wikipedia.org/wiki/Multiplexing#Time-division_multiplexing ver aqui]). | ||
− | Em uma ligação telefônica que passa por várias etapas, 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 entre dois telefones interligados por várias centrais se passa como se fossem dois fios de uma ponta a outra entre origem e destino da ligação telefônica. | + | Em uma ligação telefônica que passa por várias etapas, toda a sinalização é repassada de forma digitalizada por canais adicionais no E1 (ou uma variante disto). O chaveamento de circuito =Aula Dia 23/04/2013= |
+ | |||
+ | == Apresentação do novo professor == | ||
+ | |||
+ | * [[Marcelo_Maia_Sobral|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 [http://www.facebook.com/Marcelo.Sobral.Ifsc 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. | ||
+ | |||
+ | [[imagem:Voip-call.png|500px]] | ||
+ | |||
+ | |||
+ | Nas nossas aulas faremos uso de um PBX IP [http://www.asterisk.org/ Asterisk], que é um software desenvolvido pela [http://www.digium.com/ 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. | ||
+ | * [http://www.asterisk.org/get-started Uma visão geral sobre Asterisk] | ||
+ | |||
+ | == PBX IP Asterisk == | ||
+ | |||
+ | * [http://tele.sj.ifsc.edu.br/~msobral/rmu/slides/aula-25.pdf Transparências] | ||
+ | * [http://www.asterisk.org Site oficial do Asterisk] | ||
+ | * [http://www.asteriskguru.com/ Asterisk Guru] | ||
+ | * [http://www.voip-info.org/wiki Dicas sobre Asterisk] | ||
+ | * [http://www.asteriskdocs.org/ Livro online gratuito sobre Asterisk] | ||
+ | * [http://www.packetizer.com/ipmc/sip/papers/understanding_sip_voip/ Introdução a VoIP e SIP] | ||
+ | * Livro [http://www.voffice.com.br/index.php/pt/noticiasgrupovoffice/voffice-treinamento/96-voffice-lanca-quinta-geracao-do-guia-de-configuracao-para-o-asterisk- ''Asterisk: Guia de Configuração - 5a geração''], de Flávio Gonçalves. | ||
+ | |||
+ | |||
+ | '''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) | ||
+ | |||
+ | |||
+ | [[imagem:Asterisk-ex1.png|400px]] | ||
+ | <br>''Exemplo de cenário de uso do Asterisk'' | ||
+ | |||
+ | |||
+ | <!-- [[imagem:Asterisk-arch.png|500px]] | ||
+ | <br>''Arquitetura modular 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: | ||
+ | |||
+ | [[imagem:Asterisk-fluxo.png|400px]] | ||
+ | |||
+ | |||
+ | Um exemplo de plano de discagem simples pode ser visto abaixo: | ||
+ | |||
+ | <syntaxhighlight lang=text> | ||
+ | [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 | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | 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: | ||
+ | |||
+ | <syntaxhighlight lang=text> | ||
+ | exten=>identificador,prioridade,aplicação | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | * '''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: | ||
+ | |||
+ | <syntaxhighlight lang=text> | ||
+ | exten=>identificador,prioridade,aplicação | ||
+ | same=>prioridade,aplicação | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | *'''same''': declara uma nova extensão com mesmo identificador da extensão imediatamente anterior | ||
+ | é 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 entre dois telefones interligados por várias centrais se passa como se fossem dois fios de uma ponta a outra entre origem e destino da ligação telefônica. | ||
===Redes com chaveamento por pacotes versus chaveadas por circuitos=== | ===Redes com chaveamento por pacotes versus chaveadas por circuitos=== | ||
Linha 1 430: | Linha 1 524: | ||
#coordenacao Contas: 300 e 3012 | #coordenacao Contas: 300 e 3012 | ||
+ | <\-- | ||
a) Criar um plano de discagem de forma que as contas SIP do contexto alunos so possam atingir outras contas SIP deste contexto.<br> | a) Criar um plano de discagem de forma que as contas SIP do contexto alunos so possam atingir outras contas SIP deste contexto.<br> | ||
b) Faca o mesmo para o contexto professores.,br> | b) Faca o mesmo para o contexto professores.,br> | ||
c) Contas SIP do contexto coordenacao poderao atingir, alem das contas SIP deste contexto, as contas dos contextos alunos e professores. <br> | c) Contas SIP do contexto coordenacao poderao atingir, alem das contas SIP deste contexto, as contas dos contextos alunos e professores. <br> | ||
d) Implementar caixa de correio de voz para cada extensao e criar uma extensao em cada contexto para permitir a consulta ao correio de voz. | d) Implementar caixa de correio de voz para cada extensao e criar uma extensao em cada contexto para permitir a consulta ao correio de voz. | ||
+ | --> | ||
{{collapse bottom}} | {{collapse bottom}} | ||
− | |||
− | |||
=Aula Dia 23/04/2013= | =Aula Dia 23/04/2013= |
Edição das 18h04min de 13 de março de 2020
Professores da Unidade Curricular
- 2020-1 - Jorge Henrique B. Casagrande
- Não há registros de professores de semestres anteriores
Carga horária, Ementas, Bibliografia
Plano de Ensino
Cronograma das Atividades
Semestre 2019-2 | |||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Dados Importantes
Professor: Jorge Henrique B. Casagrande
Email: casagrande@ifsc.edu.br
Atendimento paralelo: 2as das 17:35h às 18:30h e quartas das 11:35h às 12:30h (Sala de Professores de TELE II ou Laboratório de Redes de Computadores)
Link alternativo para Material de Apoio da disciplina: http://www.sj.ifsc.edu.br/~casagrande/TIP
Resultados das Avaliações
- Critérios
- Os alunos serão avaliados da seguinte forma:
- - 2 Avaliações parciais A1 e PI (Projeto Integrador). A avaliação parcial A1 contará com uma PROVA ESCRITA de 2HA de conteúdos preferencialmente associados as teorias e práticas da disciplina os quais representam 60% da NOTA FINAL; Os outros 40% de dessa avaliação parcial é relativa a média das notas atribuídas a aptidão e qualidade das atividades práticas e teóricas correspondentes, atividades extras e avaliação individual. A avaliação parcial PI representa 60% do valor atribuído segundo os critérios do projeto integrador final da turma e os outros 40% representa a média das notas atribuídas a aptidão e qualidade das atividades práticas e avaliação individual correspondentes.
- - Avaliação Individual (AI1, AIPI) é uma nota atribuída pelo professor que representa o mérito de assiduidade, participação em sala e em equipe, cumprimento de tarefas adicionais como atribuições do PI, relatórios e listas de exercícios.
- - Todas as notas parciais serão valoradas de 0 à 10,0 em passos de 0,1 pontos e convertidas em conceitos conforme abaixo:
- Se NOTA FINAL (NF) OU PROVA ESCRITA da avaliação parcial < 6,0 é OBRIGATÓRIO realizar a recuperação dos conteúdos da respectiva avaliação parcial
- Se NOTA FINAL E PROVA ESCRITA da avaliação parcial >= 6,0 a recuperação de conteúdos é opcional
- Para a aprovação na disciplina é necessário atingir no mínimo a nota 6,0 na MÉDIA final ponderada em carga horária de todas as avaliações parciais e 75% de participação em sala de aula;
- Conforme restrições do sistema de registro de notas do SIGAA, a NOTA FINAL sempre tem arredondamento para o valor inteiro mais baixo da unidade (exemplo: Nota 5,9 é considerado NOTA FINAL 5). Arredondamentos para valores inteiros mais altos da NOTA FINAL só serão permitidos mediante tolerância do professor diante da evolução do discente ao longo do semestre.
- Se NOTA FINAL (NF) OU PROVA ESCRITA da avaliação parcial < 6,0 é OBRIGATÓRIO realizar a recuperação dos conteúdos da respectiva avaliação parcial
- - As datas de recuperação das avaliações parciais serão realizadas no último dia letivo da disciplina, mas podem ser decididas em comum acordo com a turma.
- - 2 Avaliações parciais A1 e PI (Projeto Integrador). A avaliação parcial A1 contará com uma PROVA ESCRITA de 2HA de conteúdos preferencialmente associados as teorias e práticas da disciplina os quais representam 60% da NOTA FINAL; Os outros 40% de dessa avaliação parcial é relativa a média das notas atribuídas a aptidão e qualidade das atividades práticas e teóricas correspondentes, atividades extras e avaliação individual. A avaliação parcial PI representa 60% do valor atribuído segundo os critérios do projeto integrador final da turma e os outros 40% representa a média das notas atribuídas a aptidão e qualidade das atividades práticas e avaliação individual correspondentes.
DISCENTE | AE1 | AE2 | AE3 | AE4 | AI1 | Prova A1 | REC A1 | NF A1 | AE5 | AE6 | AI2 | PI | NF PI | NF PI | MÉDIA PONDERADA | NOTA FINAL | Situação | ||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Augusto | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0,0 | 0 | 0 | 0 | 0,0 | 0,0 | 0,0 | 0 | REPROVADO | |||||
Brenda | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0,0 | 0 | 0 | 0 | 0,0 | 0,0 | 0,0 | 0 | REPROVADO | |||||
Bruna | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0,0 | 0 | 0 | 0 | 0,0 | 0,0 | 0,0 | 0 | REPROVADO | |||||
Bruno | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0,0 | 0 | 0 | 0 | 0,0 | 0,0 | 0,0 | 0 | REPROVADO | |||||
Enzo | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0,0 | 0 | 0 | 0 | 0,0 | 0,0 | 0,0 | 0 | REPROVADO | |||||
Fernanda | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0,0 | 0 | 0 | 0 | 0,0 | 0,0 | 0,0 | 0 | REPROVADO | |||||
Guilherme | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0,0 | 0 | 0 | 0 | 0,0 | 0,0 | 0,0 | 0 | REPROVADO | |||||
Isabella | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0,0 | 0 | 0 | 0 | 0,0 | 0,0 | 0,0 | 0 | REPROVADO | |||||
Jennifer | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0,0 | 0 | 0 | 0 | 0 | 0,0 | 0,0 | 0,0 | 0 | REPROVADO | ||||
João Pedro | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0,0 | 0 | 0 | 0 | 0 | 0,0 | 0,0 | 0,0 | 0 | REPROVADO | ||||
Lilia | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0,0 | 0 | 0 | 0 | 0 | 0,0 | 0,0 | 0,0 | 0 | REPROVADO | ||||
Lucas Castro | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0,0 | 0 | 0 | 0 | 0 | 0,0 | 0,0 | 0,0 | 0 | REPROVADO | ||||
Lucas Fontes | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0,0 | 0 | 0 | 0 | 0 | 0,0 | 0,0 | 0,0 | 0 | REPROVADO | ||||
Manuela | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0,0 | 0 | 0 | 0 | 0 | 0,0 | 0,0 | 0,0 | 0 | REPROVADO | ||||
Mateus Seemann | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0,0 | 0 | 0 | 0 | 0 | 0,0 | 0,0 | 0,0 | 0 | REPROVADO | ||||
Matheus Santana | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0,0 | 0 | 0 | 0 | 0 | 0,0 | 0,0 | 0,0 | 0 | REPROVADO | ||||
Nathaly | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0,0 | 0 | 0 | 0 | 0 | 0,0 | 0,0 | 0,0 | 0 | REPROVADO | ||||
Pedro | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0,0 | 0 | 0 | 0 | 0 | 0,0 | 0,0 | 0,0 | 0 | REPROVADO | ||||
Thiago | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0,0 | 0 | 0 | 0 | 0 | 0,0 | 0,0 | 0,0 | 0 | REPROVADO | ||||
Vinícius | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0,0 | 0 | 0 | 0 | 0 | 0,0 | 0,0 | 0,0 | 0 | REPROVADO | ||||
Wesley | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0,0 | 0 | 0 | 0 | 0 | 0,0 | 0,0 | 0,0 | 0 | REPROVADO | ||||
Yasmin | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0,0 | 0 | 0 | 0 | 0 | 0,0 | 0,0 | 0,0 | 0 | REPROVADO |
- ATENÇÃO - MÉDIA PONDERADA = 50% NF A1 +50% NF PI NOTA FINAL – APÓS CONSELHOS DE CLASSE
Recados Importantes
Toda vez que você encontrar a marcação ao lado de alguma atividade, significa que essa atividade estará sendo computada na avaliação como AI. O prazo estabelecido para entrega estará destacado ao lado da atividade. Portanto, não perca o prazo limite para entrega. Atividades entregues fora do prazo terão seu valor máximo de nota debitado de 1,0 pontos ao dia;
Uso da Wiki: Todo o repositório de material de apoio e referências de nossas aulas passam a usar a Wiki de tele;
Whatsapp: Para interação fora da sala de aula, acessem nosso grupo no Whatsapp: está neste link;
SIGAA: Eventualmente alguns materiais, mídias instrucionais, avaliações ou atividades poderão usar o ambiente da turma virtual do SIGAA. O professor fará o devido destaque para isso;
ATENÇÃO: Uma avaliação poderá ser recuperada somente se existir justificativa reconhecida pela coordenação. Desse modo, deve-se protocolar a justificativa no prazo de 48 horas, contando da data e horário da avaliação, e aguardar o parecer da coordenação. O não cumprimento desse procedimento implica a impossibilidade de fazer a recuperação.
Material de Apoio
- Tabela de leitura básica das Bibliografias recomendadas (PARA AVALIAÇÃO A1 e PI)
Referência | Tópicos | Observações |
---|---|---|
Colcher 1ª edição | Todo o Livro | |
Rosenberg | ||
SCHULZRINNE | ||
Madsen |
- Atividades extra sala de aula
- LISTA1 de exercícios para a avaliação A1
- Slides utilizados durante algumas aulas
-
- Manuais e outros
Bibliografia Básica
-
- COLCHER, S. et. al. VoIP: Voz sobre IP. Rio de Janeiro: Elsevier, 2005.
- ROSENBERG, J. et. al. RFC 3261: Session Initiation Protocol. IETF. 2002.
- BOER, M. de. Twinkle - SIP softphone for Linux. 2013.
- HANDLEY, M. et. al. RFC 4566: Session Description Protocol. IETF. 2006.
- Wireshark Foundation. Wireshark · Go Deep.. 2013.
- SCHULZRINNE, H. et. al. RFC 3550: Real-Time Protocol. IETF. 2003.
- MADSEN, L. et. al. Asterisk: The Definite Guide. 2013.
Para pesquisar o acervo das bibliotecas do IFSC:
Softwares e Links úteis
-
- IPKIT: um simulador de encaminhamento IP em java (roda direto no navegador)
- editor de PDF:
- Padrões diversos de protocolos para IoT
-
Diário de aulas TIP60801 - 2020-1 - Prof. Jorge H. B. Casagrande
10/02 - Apresentação da Disciplina e discussão sobre o PI |
---|
10/02 - Apresentação da Disciplina e discussão sobre o PI
|
17/02 - Resgatando bases da Telefonia Analógica e Digital | ||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
17/02 - Resgatando bases da Telefonia AnalógicaVamos dar uma situada sobre a Telefonia IP
O processo de convergência das tecnologias de telecomunicações e processamento de informações, via sistemas computacionais, tem promovido profundas alterações no contexto das Telecomunicações. Exemplo: serviços multimídia, presentes em dispositivos móveis e celulares. Ademais, o acesso à informação tem se tornado cada vez mais rápido e ubíquo (independente de dispositivo ou localização) e a integração dos Sistemas Telefônicos às Redes de Computadores foi um passo natural. Desse modo, a convergência em telecomunicações é uma tendência representada pela fusão dos sistemas de informação e comunicação, resultando numa síntese de serviços, recursos e informações capazes de prover diversas utilidades à sociedade.
Para o caso da Telefonia IP, VoIP é o termo usado para se referir às técnicas de empacotamento e transmissão de amostras de voz sobre redes IP e aos mecanismos de sinalização necessários ao estabelecimento de chamadas telefônicas nessas redes.
A telefonia IP é vista não só como capaz de estabelecer chamadas telefônicas e outras funcionalidades típicas de sistemas telefônicos (redirecionamento e retenção de chamadas), mas também como uma plataforma de integração de serviços típicos da internet (web, correio eletrônico, streaming de áudio e/ou vídeo). TELEFONIA ANALÓGICA
Tarefa para próxima aula 02/03 (AE1). Cada dupla de alunos designada pelo professor, irá escrever um pequeno texto auxiliado com imagens (se for o caso), a explicação de duas funcionalidades (uma simples e outra complexa) presentes em centrais automáticas analógicas e digitais. É obrigatório fazer o registro aqui neste espaço, usando a linguagem da Wiki.
Complexas:
Revisão da PSTN (Public Switched Telephonic Network)A Rede Pública de Telefonia (PSTN) foi a principal infraestrutura de telecomunicações desde o invento de Alexander Bell até o início o século XXI. Embora ainda tenha participação relevante nos dias atuais, ela perde espaço para a Internet. A PSTN se caracteriza pela presença exclusiva dos pares de fios visando a criação de circuitos dedicados para a comunicação da voz e a comutação desses circuitos entre todos os que se conectam nessa rede. Em um único par de fios ela permite a comunicação duplex, mantendo uma qualidade da transmissão da voz em limites de inteligibilidade de palavras e frases (100% de inteligibilidade) e fonemas (87%)determinados pela estreita largura de banda (300 a 3400Hz) do sinal padronizado para cruzar o sistema. Para ampliação do sistema o núcleo da rede telefônica ganha hierarquias na multiplexação e transmissão digital de inúmeros circuitos simultâneos de voz (Telefonia Digital) Os textos adiante são extrações resumidas ou adaptadas dos textos da wiki produzidos pelo Professor Marcelo Sobral, a quem fica aqui o agradecimento e créditos. Transformação da voz em sinal elétrico e a transmissãoAtravé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 sistema em que o sinal elétrico gerado pelo microfone é amplificado e transmitido por fios (2 fios). O receptor pode 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, é possí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 operadoraNo item acima observamos que é possível transmitir e receber voz entre dois usuários. Entretanto, logo após as invenções destas 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çãoDe 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:
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çãoVocê já deve ter percebido que a tendência de qualquer sistema de telecomunicações, é a representação digital binária de qualquer informação. Isto facilita o seu processamento, transmissão, recepçã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 (a banda da telefonia é de 3100Hz). Lembre da disciplina de PRT (princípios de telecomunicações), quem destacou que um sinal no tempo pode ser descrito pela soma de senoides. Desta forma, um sinal pode também ser descrito no domínio da frequência, ou seja pelas frequências e fases das senoides 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 taxa de transmissão. As centrais como chaveadoras de circuitosEntre 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 etapas, toda a sinalização é repassada de forma digitalizada por canais adicionais no E1 (ou uma variante disto). O chaveamento de circuito =Aula Dia 23/04/2013= Apresentação do novo professor
Objetivos
Chamadas feitas usando 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:
[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
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
é 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 entre dois telefones interligados por várias centrais se passa como se fossem dois fios de uma ponta a outra entre origem e destino da ligação telefônica. Redes com chaveamento por pacotes versus chaveadas por circuitosUm ponto chave da rede PSTN é que, sendo baseada em chaveamento de circuitos, a rede proporciona uma ligação permanente entre dois terminais telefônicos até que ela seja encerrada. 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 conversa com seu interlocutor, ele desperdiça um recurso valioso (e caro! $). 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. Todos 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.
Uso de redes de pacotes (Internet) para a transmissão de mídias diversasOriginalmente 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 voz digital em tempo real (e vídeo também) é 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...
|
02/03 - Introdução a VoIP, protocolo SIP e softphones |
---|
02/03 - Introdução a VoIP, protocolo SIP e softphonesObjetivosAo final da aula o aluno deverá:
O que é preciso para efetivar Voz sobre redes IP (VoIP)?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, se necessário, forneça algum sigilo na comunicação. Para sinalização tem-se várias opções. A principal hoje é o Protocolo de Iniciação de Sessão ou protocolo SIP. Para o transporte da voz utiliza-se normalmente o Protocolo de Transporte em Tempo Real sobre o Protocolo de Datagrama de Usuário RTP/UDP. Além disto, para que a transição do antigo para o novo aconteça, é conveniente interconectar a PSTN (sistema legado) com o sistema de voz sobre IP. A sinalização na InternetA sinalização na telefonia sobre IP é necessária para:
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 SIPO 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 softphone 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ásicas de estabelecimento de chamada (INVITE) e de finalização da sessão (BYE). Recursos utilizados
Softphone TwinkleNeste experimento usaremos o softphone Twinkle como terminal de comunicação. O Twinkle é um softphone 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 um hospedeiro e uma máquina virtualTerminal chamador no hospedeiro
Terminal chamado na máquina virtual
Capturando pacotes com wireshark no HOSPEDEIRONo hospedeiro faça:
Fazendo uma chamada a partir do hospedeiro
Atendendo a chamada no Twinkle da Máquina Virtual
Importante! Nosso foco é a sinalização. O áudio não nos importa no momento. Parando a captura no wireshark e analisando os pacotes
Roteiro PARTE 2 - Comunicação entre usando hospedeiros da rede do Laboratório
Roteiro PARTE 3 - Desafios
|
09/03 - O protocolo SIP na comunicação direta entre Telefone IP - Softphone |
---|
09/03 - O protocolo SIP na comunicação direta entre Telefone IP - Softphone
Recursos usados
O Telefone IPNeste 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 GKM2200 (manual). Estes dispositivos implementam o protocolo SIP. ETAPA 1 - Conexão física
Para fins de compreensão da rede que está se formando, anote esses dados:
ETAPA 2 - Análise da comunicação softphone - Telefone
Para fins de compreensão do protocolo SIP em ação, anote esses dados:
|
16/03 - Uso do Asterisk como PBX entre Telefones IP e Softphones | ||||
---|---|---|---|---|
16/03 - Uso do Asterisk como PBX entre Telefones IP e SoftphonesObjetivos
Chamadas feitas usando 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:
[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
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]
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: comunicação entre telefones IP ou softphones por meio de um PBX IPPara 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.
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:
Como testar as chamadasPara testar as chamadas, são necessários um softphone e um telefone IP, além do Asterisk.
Criar as seguintes contas SIP e contextos:
<\--
a) Criar um plano de discagem de forma que as contas SIP do contexto alunos so possam atingir outras contas SIP deste contexto. |
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.
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
- Transparências
- Site oficial do Asterisk
- Asterisk Guru
- Dicas sobre Asterisk
- Livro online gratuito sobre Asterisk
- Introdução a VoIP e SIP
- Livro Asterisk: Guia de Configuração - 5a geração, de Flávio Gonçalves.
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)
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:
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:
- Que papel desempenhou o Asterisk para os softphones ? UAC, UAC ou algo diferente ?
- Entre que agentes ocorreram os diálogos identificados ?
- 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.
- 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).
- 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]
- 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).
- 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:
- 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.
- Execute o VirtualBox, e então selecione o menu Máquina->Acrescentar.
- Escolha o arquivo Asterisk/Asterisk.vbox, que deve estar na pasta VirtualBox VMs.
- 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.
- Jitsi 2.0 para Linux (20 MB)
- Jitsi 2.0 para Windows 32 bits(37 MB)
- Jitsi 2.0 para Windows 64 bits(39 MB)
- Site oficial do Jitsi
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:
- Instale o Asterisk:
sudo apt-get istall asterisk
- Copie estes arquivos para dentro de /etc/asterisk:
- Reinicie o Asterisk:
sudo service asterisk restart
- Use o rasterisk para acessar o console do Asterisk:
sudo rasterisk -vvv
- 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).
- 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.
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
- 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).
- 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).
- 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).
- Faça uma chamada entre os softphones, atenda-a e em seguida encerre-a.
- Procure no wireshark as mensagens SIP trocadas entre os softphones e o Asterisk. Desenhe um diagrama de troca de mensagens usando este modelo.
- 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 ?
- 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.
- 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 ?
- 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.
- 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:
Um exemplo de mensagem SDP segue abaixo:
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
- Transparências
- Uma FAQ sobre RTP (muito boa)
- RFC 3550: RTP: A Transport Protocol for Real-Time Applications
- Capítulo 11 do livro SIP: Understanding the Session Initiation Protocol, 3rd ed
- Cap. 7 do livro Redes de Computadores e a Internet, 5a edição, de James Kurose.
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 |
---|---|
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:
- Estabeleça uma chamada VoIP entre dois softphones usando o Asterisk como intermediário.
- Execute o wireshark no computador onde roda o Asterisk, e ative a captura de datagramas UDP.
- 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.
- Estime o jitter durante a recepção de ao menos 15 segundos de audio.
- 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 ?
- 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).
- 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).
- 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).
- Faça uma chamada entre os softphones, atenda-a e em seguida encerre-a.
- 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 ?
- 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.
- 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 ?
- 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.
- Experimente estabelecer chamadas com diferentes codecs, e observe a negociação realizada com SDP.
- 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.
- Estime o jitter durante a recepção de ao menos 15 segundos de audio.
- 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.
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.
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
- NAT e SIP
- RFC 5389: Session Traversal Utilities for NAT
- RFC 5245: Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols
- RFC 5766: Traversal Using Relays around NAT (TURN)
- ICE Tutorial
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.
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.
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.
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.
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:
Para podermos fazer isso, os seguintes passos devem ser realizados (X é o número do seu computador):
- Mude o IP da máquina real para 192.168.1.X/24:
sudo ifconfig eth0 192.168.1.X/24
- Na máquina real configure o roteador default 192.168.1.254:
sudo route add default gw 192.168.1.254
- 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:
As seguintes alterações precisam ser feitas para esse novo cenário:
- Mude o IP da máquina virtual Asterisk para 192.168.1.X/24
- Na máquina virtual configure o roteador default 192.168.1.254
- Mude o IP da máquina real com DHCP.
- 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.
Chamada entre telefones de um mesmo provedor
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
- Implantar o Asterisk e torná-lo capaz de efetuar chamadas entre as contas SIP do provedor.
- Fazer com que o Asterisk consiga fazer chamadas para contas SIP de outros provedores.
- Ver registros SRV no DNS. E este texto sobre roteamento de chamadas na Internet com Asterisk pode ajudar a entender o problema.
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:
- 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
- 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
http://docwiki.cisco.com/wiki/Voice/Data_Integration_Technologies#Voice_Networking
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
-->