REDES INTEGRADAS DE COMUNICAÇÕES. Enunciado do Projecto de. VoIP

Transcrição

1 REDES INTEGRADAS DE COMUNICAÇÕES Enunciado do Projecto de VoIP Paulo Rogério Pereira, SETEMBRO DE 2010

2 1. Objectivo Este trabalho tem como objectivo desenvolver uma aplicação de voz sobre IP (Voice over IP VoIP) para conferências telefónicas. A aplicação deve registar-se num PBX Asterisk [1], aceitar múltiplas chamadas de voz, misturando o som recebido de todas as chamadas e enviando este som para todas as chamadas aceites. Deve ser utilizada uma versão simplificada do protocolo de sinalização SIP [2] para gestão das chamadas de voz. A transmissão de som deve ser feita utilizando PCM 8 KHz µ-law (G.711) [3] sobre RTP/UDP [4], enviando 20 ms de som em cada pacote. 2. Arquitectura A figura 1 ilustra a arquitectura pretendida para este trabalho. Um PBX (Private Branch exchange) Asterisk corre numa máquina Linux, estando acessível na rede interna do laboratório. Este PBX suporta múltiplos protocolos, permitindo o registo de telefones SIP como o X-Lite [5] da X-Ten ou de telefones como o Cisco 7905G. Cada telefone tem uma extensão atribuída, compatível com configuração do PBX. Embora o protocolo SIP suporte extensões alfanuméricas, para permitir a marcação em teclados numéricos de telefones, prefere-se a utilização de extensões apenas numéricas. X-Lite x4000 Cisco 7905G x3001 SCCP SIP Porto SIP: 5060 Porto SCCP: 2000 SCCP Ethernet /16 Cisco ATA 186 x3003 Alice x4002 SIP SIP Figura 1: Arquitectura da Rede. Chat x4001 Porto SIP: 5070 Aplicação VoIP Todo o tráfego de sinalização é trocado através do PBX. Embora o tráfego de voz possa ser trocado directamente entre os telefones intervenientes numa chamada telefónica, é mais fácil de tratar o caso em que também é trocado através do PBX. A aplicação a realizar deve registar-se no PBX utilizando o protocolo SIP, permitindo a aceitação de chamadas telefónicas de outros telefones ligados ao mesmo PBX, utilizando a rede local do laboratório. O PBX funciona como servidor de proxy SIP ( proxy server ) e entidade de registo SIP ( registrar ). 2

3 3. Especificação A aplicação deve ser chamada conf e aceitar três argumentos na linha de comando. O primeiro argumento indica o nome SIP ( display name ) associado à aplicação. O segundo argumento indica o endereço SIP público da aplicação, composto pela extensão, o endereço IP, o caracter : e o porto UDP SIP a utilizar. Este é o endereço do PBX onde a aplicação se regista. O terceiro argumento indica o endereço SIP directo de contacto, sendo composto pelo endereço IP da máquina local, seguido do caracter : e do porto UDP utilizado pelo SIP. Caso algum porto não seja fornecido, a aplicação deve utilizar o porto Um exemplo de invocação da aplicação para o utilizador Chat de acordo com a figura 1, admitindo que se utiliza o porto 5070 para o tráfego de sinalização SIP, é: conf Chat 4001@ : :5070 Uma vez em execução, a aplicação deve registar-se no proxy SIP, avisando o utilizador do sucesso desta operação. Depois deve ficar à escuta de mensagens de sinalização no porto SIP indicado e ainda aceitar a seguinte opção do teclado: T: Terminar a aplicação, desregistando-se primeiro do proxy SIP. As chamadas telefónicas que cheguem devem ser automaticamente aceites sem consultar o utilizador. O som recebido de todas as chamadas deve ser misturado e enviado para todas as chamadas aceites. 4. SIP O protocolo SIP (Session Initiation Protocol) [2] é um protocolo de sinalização que permite gerir sessões entre um conjunto de participantes. As sessões podem ser chamadas telefónicas, distribuição de conteúdos multimédia, ou conferências multimédia. Pretende-se que seja implementada uma versão simplificada, mas funcional, do protocolo SIP, permitindo aceitar chamadas telefónicas de quaisquer telefones do laboratório. Na figura 2 ilustra-se a mensagem que é utilizada para registar um utilizador no PBX, adaptada ao exemplo da aplicação conf dado anteriormente. REGISTER sip: SIP/2.0 Via: SIP/2.0/UDP :5070;branch=z9hG4bK To: Chat <sip:4001@ > From: Chat <sip:4001@ >;tag= Call-ID: a2e3areg@ CSeq: 1 REGISTER Contact: Chat <sip:4001@ :5070> Expires: 3600 Content-Length: 0 Figura 2: Exemplo da mensagem REGISTER. O protocolo SIP utiliza uma sintaxe semelhante ao protocolo HTTP. A mensagem começa com uma linha que identifica o tipo de mensagem (método REGISTER), o domínio SIP e a versão do protocolo. Depois seguem-se linhas de cabeçalho, uma linha em branco e um corpo de mensagem opcional, que deve ter tantos bytes quantos os indicados na linha de cabeçalho Content-Length. A linha de cabeçalho Via contém o endereço onde a Alice está à espera da resposta. O campo branch deve ter um valor que começa obrigatoriamente com os caracteres z9hg4bk. A linha Max-Forwards serve para limitar o número de saltos que um pedido pode fazer no caminho para o seu destino. A linha CSeq contém um número de sequência de pedido associado a um método (REGISTER). Este número de sequência é incrementado por cada novo pedido dentro de um diálogo (mesmo Call-ID). As linhas To: e From: têm o endereço SIP público a registar. A linha Contact contém o endereço de contacto onde o cliente está actualmente, correspondente à sua aplicação. A linha Expires indica o número de segundos de validade do registo. 3

4 Em resposta às mensagens de REGISTER, é normal receber-se uma resposta 100 Trying, seguida de uma resposta 200 Ok. Respostas 1xx são informativas e podem ser ignoradas. Respostas 2xx devem ser consideradas sucesso. Qualquer outra resposta deve ser considerada insucesso. Após o registo, é possível que o PBX envie mensagens de NOTIFY, que podem ser ignoradas pela aplicação, como simplificação. Para desregistar o utilizador antes de a aplicação terminar, utiliza-se a mesma mensagem REGISTER, mas com um campo Expires: 0 e um campo CSeq: incrementado. Para estabelecer uma chamada de voz entre o PC da Alice, com endereço IP e porto áudio 38060, e a aplicação conf no PC com endereço IP e porto áudio 48753, conforme ilustrado na figura 3, a Alice envia para o PBX uma mensagem INVITE semelhante à ilustrada na figura 4. Os portos áudio devem ser escolhidos automaticamente pela aplicação, durante a execução, de entre os portos livres no momento. Alice Chat áudio µ Law recepção áudio no porto recepção áudio no porto Figura 3: Exemplo de chamada de voz INVITE sip:4001@ SIP/2.0 To: sip:4001@ From: Alice <sip:4002@ >;tag=19283 CSeq: 1 INVITE Contact: Alice <sip:4002@ :5060> Content-Type: application/sdp Content-Length: 123 v=0 o= IN IP s= t=0 0 c=in IP m=audio RTP/AVP 0 a=rtpmap:0 pcmu/8000 Figura 4: Exemplo da mensagem INVITE. A linha To contém o endereço SIP do destinatário da chamada. A linha From contém o endereço SIP público do originador da chamada e uma etiqueta aleatória para identificação da chamada em causa, que terá de ser utilizada em subsequentes linhas From de mensagens desta chamada telefónica. O Call-ID também tem um identificador da chamada e deve ser diferente do Call-ID do REGISTER. O Call-ID em conjunto com as etiquetas de From e To identifica univocamente a chamada. Como simplificação, podem ser utilizados identificadores fixos. A linha Contact contém o endereço SIP directo do chamador. O conteúdo da mensagem INVITE, após o cabeçalho, utiliza o SDP (Session Description Protocol) [6], indicando a informação da conexão de voz que se pretende estabelecer. Na linha c= é indicado o endereço IP de origem, onde a Alice pretende receber a transmissão de voz e na linha m= o tipo de dados (áudio), número do porto, protocolo e lista de formatos de dados suportados, segundo a sintaxe: 4

5 c=<network type> <address type> <connection address> m=<media> <port>/<number of ports> <transport> <fmt list> RTP/AVP 0 significa que é utilizado o protocolo RTP com o Audio/Video Profile sobre UDP, com codec formato 0, que corresponde a PCM 8 KHz µ-law. A linha v= indica a versão do protocolo SDP. A linha o= indica o utilizador, um identificador da sessão, um número de versão da sessão e o endereço IP de origem. A linha s= indica o nome da sessão. A linha t= indica o tempo de início e fim da sessão. A linha a= explica o significado do codec 0. Após enviar a mensagem INVITE, novamente mensagens com códigos 1xx devem ser ignoradas. A mensagem de sucesso normal é 200 OK. Na figura 5 é apresentado um exemplo. Os cabeçalhos Via, To, From, Call-ID, e CSeq são copiados do pedido INVITE, mas é acrescentada uma etiqueta à linha To, que terá de ser utilizada em subsequentes linhas To de mensagens da mesma chamada telefónica. O conteúdo da mensagem de OK indica onde e como a aplicação de conferência pretende receber a transmissão de voz da Alice, com a mesma sintaxe que no INVITE. SIP/ OK To: sip:4001@ ;tag=a6c85 From: Alice <sip:4002@ >;tag=19283 CSeq: 1 INVITE Contact: Chat <sip:4001@ :5070> Content-Type: application/sdp Content-Length: 123 v=0 o= IN IP s= t=0 0 c=in IP m=audio RTP/AVP 0 a=rtpmap:0 pcmu/8000 Figura 5: Exemplo da mensagem OK. Em resposta à mensagem de OK, o iniciador da chamada envia uma mensagem de ACK. Na figura 6 está ilustrado um exemplo. Note que o número no CSeq deve ser igual ao do INVITE a que diz respeito. ACK sip:4001@ SIP/2.0 To: sip:4001@ ;tag=a6c85 From: Alice <sip:4002@ >;tag=19283 CSeq: 1 ACK Contact: Alice <sip:4002@ :5060> Content-Length: 0 Figura 6: Exemplo da mensagem ACK. Uma vez trocadas estas mensagens, ambos os lados podem enviar e receber pacotes de voz sobre RTP/UDP. Uma chamada acaba quando um dos lados desliga. A terminação da chamada é despoletada pelo envio de uma mensagem BYE (ver figura 7 para o caso de ser a Alice a desligar), ao que a entidade par responde com a mensagem OK (figura 8). Note que o Call-ID é o da chamada a desligar, mas o CSeq foi incrementado por ser um novo comando enviado pela Alice. 5

6 BYE SIP/2.0 From: To: CSeq: 2 BYE Content-Length: 0 Figura 7: Exemplo da mensagem BYE. SIP/ OK From: sip:4002@ ;tag=19283 To: sip:4001@ ;tag=a6c85 CSeq: 2 BYE Content-Length: 0 Figura 8: Exemplo da mensagem OK. 5. RTP O protocolo RTP (Real-time Transport Protocol) [4] é apropriado para a transferência de dados de tempo real, tais como áudio e vídeo, oferecendo mecanismos de associação de numeração de sequência, identificação do formato de codificação e informação temporal. O RTP deixa o processamento desta informação a cargo da aplicação, não oferecendo por si mecanismos de garantia de entrega, sequencialidade ou QoS. Note-se ainda que o RTP pode ser usado sobre qualquer protocolo de transporte, sendo normalmente utilizado sobre o UDP. O cabeçalho RTP encontra-se representado na figura 9. Os bits mais significativos são os da esquerda e são os que se enviam em primeiro lugar. Todos os campos inteiros são transmitidos em formato rede, isto é, com o byte mais significativo primeiro. Assim, a transmissão é feita começando pela esquerda da figura 9, pela ordem dos bits indicada (0, 1, 2, 3...) V=2 P X CC M PT número de sequência marca temporal Identificador de fonte de sincronização (SSRC) Identificador de fonte contribuinte (CSRC)... Figura 9: Campos fixos do cabeçalho RTP. Segue-se uma breve descrição dos campos obrigatórios: Versão [V]: Identifica a versão do RTP em uso. Utilizar o valor 2. Enchimento [P]: Indica a presença de bytes de enchimento no fim do pacote. Colocar a zero. Extensão [X]: Indica a presença da extensão de cabeçalho. Colocar a zero. Número de CSRCs [CC]: contém o comprimento da lista de identificadores de CSRCs. Colocar a zero. 6

7 Marcador [M]: A sua interpretação é definida pelo perfil. Pode servir, por exemplo, para indicar o fim das imagens, no caso de haver segmentação. Em aplicações de transmissão de som [7], deve ser colocado sempre a 0, caso não seja utilizada supressão de silêncio. Tipo de Conteúdo [PT]: Indica qual o tipo de informação e formato de codificação do conteúdo do pacote RTP. Para PCM 8 KHz µ-law, utilizar o valor 0. Número de Sequência: Este campo é incrementado para cada pacote RTP enviado, e pode ser usado pelo receptor para detectar perdas ou recuperar a sequencialidade. Começar a numerar em zero. Marca Temporal: Este campo codifica o momento de amostragem do primeiro byte presente no conteúdo do pacote RTP, aumentando de uma unidade por cada amostra de som tirada. SSRC: Este campo identifica uma fonte dentro de uma sessão RTP. É inicializado com um valor aleatório, podendo mudar ao longo da sessão, em caso de conflito ou reinicialização. 6. Asterisk Para o PBX Asterisk funcionar, é necessário configurá-lo através de um conjunto de ficheiros de configuração disponíveis na directoria /etc/asterisk, dos quais se destacam: extensions.conf sip.conf sccp.conf definição de contextos de números de extensões e sua associação a telefones; definição dos utilizadores SIP e sua associação a uma extensão de um contexto de extensões; definição dos equipamentos SCCP e sua associação a uma extensão de um contexto de extensões. Uma descrição mais detalhada de como configurar o Asterisk pode ser obtida em [10]. Estão pré-configuradas no Asterisk as extensões 1000 para teste de acolhimento e a 600 para teste de eco. O Asterisk pode ser executado com a linha de comando: asterisk vvvvgc onde o número de v s corresponde ao nível de verbosidade da informação apresentada durante o funcionamento do PBX. Se o Asterisk estiver a correr como daemon, pode-se criar uma consola com o comando: asterisk r Alguns comandos interessantes na consola do Asterisk são (consoante a versão do Asterisk): sip show users sip show peers sip show channels sip reload sip debug extensions reload ou sip set debug ou dialplan reload debug level 20 ou core set debug 20 quit stop now 7. Detalhes de Implementação Recomenda-se que implemente o trabalho nas seguintes fases: 7

8 1. captura de som e transmissão unidireccional por RTP/UDP para outra aplicação com portos fixos. 2. transmissão bidireccional de som por RTP/UDP. 3. registo/desregisto SIP no PBX. 4. implementação da aceitação de uma chamada telefónica utilizando sinalização SIP e menu de gestão de chamadas. Utilização de portos RTP dinâmicos. Com uma só chamada, a aplicação deve ecoar o som recebido. 5. implementação da desconexão de chamadas. 6. implementação da aceitação de chamadas adicionais e mistura do som. O programa será testado com um máximo de três chamadas simultâneas. O programa pode ser feito em qualquer linguagem de programação, podendo ser utilizadas bibliotecas de RTP ou de SIP. Para misturar o som de várias fontes, deve converter a amplitude de cada amostra de som das várias chamadas recebidas para uma escala linear, fazer a média aritmética das amplitudes, converter novamente para µ-law para enviar. Não precisa de ser utilizado o protocolo RTCP. Nunca deve ser feita retransmissão de pacotes enviados, nem ter temporizadores para o caso de não ser recebida resposta. Caso o destinatário não responda à transmissão de um pacote, o utilizador pode terminar a aplicação com control+c, quando se cansar de esperar. Recomenda-se a utilização do programa Ethereal [9] ou Wireshark [10] para análise do tráfego SIP e RTP. Recomenda-se a utilização da chamada sistema select() para ficar à espera dos diversos portos, do teclado e do som. Para ficar à espera do teclado, deve-se ligar o bit correspondente da máscara do select() com FD_SET(fileno(stdin), &mascara). Escreva mensagens de debug no ecrã para se perceber o que está a acontecer. Em Linux, a captura e reprodução de som pode ser feita como explicado em [11], caso se use o Open Sound System (OSS); ou como explicado em [12], caso se use o Advanced Linux Sound Architecture (ALSA). Recomenda-se a configuração adequada do som com o áudio mixer do PC: gravação de som do microfone; volume do microfone 0 (para não se ouvir nos altifalantes o som do microfone); input gain, master volume e PCM volume altos. Se o servidor de partilha de som arts estiver a correr, é aceitável suspendê-lo com artsshell suspend, tal como explicado em [13], para poder utilizar os dispositivos de áudio directamente. 8. Entrega do trabalho O trabalho deve ser entregue através da opção de entrega de projectos do sistema Fénix, num ficheiro ZIP, sem subdirectorias, contendo os seguintes ficheiros: - código fonte do trabalho; - Makefile para compilar o trabalho, produzindo o executável; - quaisquer outros ficheiros que considere indispensáveis para compilar ou correr o programa. O ficheiro ZIP, deve ter o seguinte nome: RIC-VoIP-<nº aluno>-<nº aluno>.zip Onde <nº aluno> deve ser substituído pelos números dos alunos do grupo. O prazo para entrega é: 17/12/2010 Entrega da versão completa do trabalho. 8

9 9. Referências [1] Asterisk, the Open Source PBX. [2] SIP: Session Initiation Protocol. J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, E. Schooler. IETF RFC 3261, Junho de [3] Recomendação G.711 do ITU-T: Pulse Code Modulation (PCM) of Voice Frequencies. [4] RTP: A Transport Protocol for Real-Time Applications. H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson. IETF RFC Julho de [5] X-Ten X-Lite Softphone. [6] SDP: Session Description Protocol. M. Handley, V. Jacobson. IETF RFC 2327, Abril de [7] RTP Profile for Audio and Video Conferences with Minimal Control. H. Schulzrinne, S. Casner. IETF RFC Julho de [8] Asterisk, The Future of Telephony, 2 nd Edition. O Reilly, ISBN: [9] Ethereal: A Network Protocol Analyser. [10] Wireshark Network Protolcol Analyser. [11] OSS Programmer's guide v [12] Advanced Linux Sound Architecture (ALSA). [13] arts Project. Frequently Asked Questions. 9