TIP-IntTel (2020.1)
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
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:
|
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
-->