Seção: Banda Larga
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Basicamente, dois tipos de protocolos são utilizados para viabilizar a comunicação VoIP: um protocolo para sinalização (com objetivo de estabelecer e gerenciar a chamada – sessão) e outro para o transporte da voz por uma rede IP (SIÉCOLA, 2010). Diversos protocolos de sinalização foram concebidos por instituições padronizadoras, contudo a maior parte das aplicações utiliza o SIP (Session Initiation Protocol), descrito no RFC 3261, visto que este protocolo apresenta flexibilidade quanto à adição de novas features, além de facilidade de implementação e solução de problemas (DALGIC e FANG, 2011), por isto este trabalho aborda as situações onde este protocolo é utilizado para o estabelecimento de chamadas VoIP.
O SIP é um protocolo textual baseado em requisições e respostas, bastante similar ao HTTP, que possui campos de cabeçalho e um corpo. No corpo de uma mensagem SIP é encapsulado algum protocolo de descrição de sessão responsável pela negociação dos tipos e formatos de mídias que serão trocadas entre as partes comunicantes, chamadas de User Agents (UA). O RFC 3261 não determina qual protocolo de descrição de sessão deve ser usado, portanto implementações SIP podem oferecer suporte a múltiplos protocolos de descrição de sessão. Entretanto, é mandatório o suporte ao SDP (Session Description Protocol), descrito no RFC 2327, o que faz deste o mais utilizado para negociação de mídias numa sessão SIP (JOHNSTON, 2009).
Em se tratando do transporte da voz digitalizada por uma rede IP, o protocolo que ganhou o mercado foi o RTP (Real-time Transport Protocol), definido pelo RFC 3550, que não depende do tipo de protocolo de sinalização e descrição sendo utilizados. Também no mesmo RFC é definido o RTCP, um protocolo associado ao RTP que permite a troca de relatórios estatísticos entre os participantes de uma sessão a respeito da recepção de mídia.
A seguir, é apresentado um tratamento de caráter introdutório sobre os protocolos SIP, SDP, RTP e RTCP.
SIP – Session Initiation Protocol
O SIP é um protocolo da camada de sessão do modelo OSI (camada de aplicação do modelo TCP/IP) que pode estabelecer, modificar e terminar sessões multimídias - onde sessão é considerada uma troca de dados entre uma associação de UAs - como uma chamada telefônica pela Internet (ROSENBERG, SCHULZRINNE e CAMARILLO et al, 2011).
Nesta sessão serão introduzidas as funções básicas do protocolo SIP que tem participação fundamental na viabilização de VoIP: localização de um sistema final, sinalização da intensão de se comunicar, negociação dos parâmetros e estabelecimento de uma sessão e término de uma sessão previamente estabelecida (ROSENBERG, SCHULZRINNE e CAMARILLO et al, 2011). A Figura1 exibe uma típica troca de mensagens SIP entre dois usuários que desejam se comunicar, André e Guilherme. Para referência no texto, cada mensagem foi identificada com uma letra “M” e um número entre parênteses.
O processo começa com o usuário André, no domínio “lima.com” desejando realizar uma chamada ao usuário Guilherme, no domínio “santos.com”. Os usuários são identificados fora de seu domínio pela sua identidade SIP, um tipo de URI (Uniform Resource Identifier) similar a um endereço de email. Para o caso presente, as identidades SIP poderiam ser: sip:andre@lima.com e sip:guilherme@santos.com. Portanto, o usuário André constrói uma solicitação SIP INVITE (a mensagem M1) conforme a seguir:
INVITE sip:guilherme@santos.com SIP/2.0 Via:SIP/2.0/UDP pc145.lima.com:5060;branch=z9hG4bKfw19b Max-Forwards: 70 To: Guilherme Santos <sip:guilherme@santos.com> From: André Lima <sip:andre@lima.com>;tag=76341 Call-ID: jlaks984309k CSeq: 1 INVITE Contact: <sip:andre@pc145.lima.com> Content-Type: application/sdp Content-Length: 158 (Conteúdo SDP não exibido)
Figura 1: Estabelecimento de uma sessão SIP
O cabeçalho da mensagem SIP vai da primeira linha até o campo Content-Length. A primeira linha da mensagem de solicitação exibe o método (INVITE), a identidade SIP do destino (sip:guilherme@santos.com) e a versão do protocolo (SIP/2.0).
A seguir vem o campo Via, que exibe o endereço e a porta para o qual o usuário André espera receber a resposta de sua solicitação. Neste caso, “pc145.lima.com” é um nome que pode ser traduzido por DNS para o endereço IP 100.101.102.103 e a porta 5060 é a porta padrão do SIP.
Ainda no campo Via, há o parâmetro branch que serve como um identificador de transação. Desta forma, respostas referentes a esta transação podem ser identificadas, pois deverão possuir o mesmo valor no parâmetro branch.
O campo Max-Forwards exibe a quantidade máxima de dispositivos SIP que a mensagem pode atravessar. A cada salto o campo é decrementado e quando chega a zero é descartado pelo dispositivo SIP que receber a mensagem.
O campo To carrega um nome de exibição (opcional) e a URI SIP que identifica o destinatário.
O campo From carrega um nome de exibição (opcional) e a URI SIP que identifica o chamador. Observa-se também a presença do parâmetro tag, que é uma sequência de caracteres gerada aleatoriamente pela fonte.
O próximo campo é o Call-ID, outra sequência de caracteres aleatória gerada pela fonte com o objetivo de identificar uma sessão SIP e, portanto, deve ser única no dispositivo SIP de origem. Na verdade, os User Agents de origem e destino, também chamados de User Agent Client (UAC) e User Agent Server (UAS), respectivamente, contribuem com a identificação da chamada cada um com mais uma sequência de caracteres aleatória, que são os parâmetros tag nos campos To e From. Esses três valores (Call-ID, tag do campo To e tag do campo From) identificarão completamente um diálogo aberto entre origem e destino. Na mensagem anterior não há parâmetro tag no campo To porque ele será adicionado quando o destinatário responder a solicitação INVITE.
O campo seguinte é o CSeq (Command Sequence), que traz um valor inteiro e o nome do método. A cada nova solicitação enviada dentro de um diálogo o valor inteiro deve ser incrementado. No exemplo acima, o valor do campo foi iniciado com um (1), mas poderia ser qualquer inteiro maior que zero.
É oportuno dizer que os campos Via, Max-Forwards, To, From, Call-ID e CSeq compõem o menor conjunto de campos obrigatórios no cabeçalho de qualquer solicitação SIP (JOHNSTON, 2009).
O próximo campo na mensagem INVITE é o Contact, que contém o SIP URI do originador da chamada para o qual o User Agent de destino poderá encaminhar as transações seguintes diretamente (sem passar por dispositivos SIP intermediários).
Os dois campos seguintes, Content-Type e Content-Length, informam o tipo de mensagem que está sendo carregada no corpo do protocolo SIP e qual o tamanho desta mensagem, respectivamente.
Importa dizer que a mensagem INVITE aqui exibida não contém todos os campos possíveis para o método em questão. Uma lista completa dos campos possíveis numa mensagem INVITE, bem como em qualquer outra mensagem, está disponível em (JOHNSTON, 2009) e (ROSENBERG, SCHULZRINNE e CAMARILLO et al, 2011).
Apesar de conhecer a identidade SIP do destinatário, o usuário André não conhece o seu endereço IP atual. Portanto, de alguma forma, a mensagem SIP deve ser roteada até o dispositivo onde está o UA de destino.
Para isso, o UAC confia num servidor SIP chamado proxy. Servidores SIP serão abordados posteriormente, por hora importa que um SIP proxy é capaz de receber uma mensagem SIP em seu domínio local, determinar para qual domínio ela está endereçada, encaminhar essa mensagem para o SIP proxy no domínio de destino para que este, finalmente, o entregue ao UAS.
Assim, como pode ser observado na Figura 1, a M1 é encaminhada ao servidor proxy do domínio “lima.com”. Através de uma pesquisa DNS SRV, o servidor proxy do domínio local obterá o endereço do servidor proxy do domínio remoto, “santos.com”. Contudo, antes de encaminhar uma mensagem SIP, um dispositivo SIP adiciona um campo Via com seu próprio endereço, adiciona um parâmetro received (que tem como valor o endereço IP do UAC) ao campo Via original da mensagem e decrementa o valor no campo Max-Forwards. Desta forma, M2 será:
INVITE sip:guilherme@santos.com SIP/2.0 Via: SIP/2.0/UDP proxy.lima.com:5060;branch=z9hG4bK898.78 Via: SIP/2.0/UDP pc145.lima.com:5060;branch=z9hG4bKfw19b;received=100.101.102.103 Max-Forwards: 69 (O resto não se altera)
Adicionalmente, o servidor proxy do domínio “lima.com” também opta por retornar uma mensagem “100 Trying” (M3) para o UAC, informando que recebeu a solicitação INVITE e tomou providências acerca dela. Isto impede que o UAC faça retransmissões da solicitação INVITE (ROSENBERG, SCHULZRINNE e CAMARILLO et al, 2011). Vale destacar que essa não é uma mensagem obrigatória.
Ao receber M2, o servidor proxy do domínio “santos.com” adiciona mais um campo Via com seu endereço, adiciona um parâmetro received ao campo Via inserido pelo servidor proxy anterior, decrementa o valor no campo Max-Forwards e encaminha a mensagem ao UAS, Guilherme. Desta forma, M4 será:
INVITE sip:guilherme@santos.com SIP/2.0 Via: SIP/2.0/UDP pr.santos.com:5060;branch=z9hG4bKhjasu8898ukf Via: SIP/2.0/UDP proxy.lima.com:5060;branch=z9hG4bK898.78;received=100.101.102.104 Via: SIP/2.0/UDP pc145.lima.com:5060;branch=z9hG4bKfw19b;received=100.101.102.103 Max-Forwards: 68 (O resto não se altera)
Como anteriormente, o proxy do domínio “santos.com” envia uma mensagem “100 Trying” para o proxy do domínio “lima.com” informando que está trabalhando na solicitação que lhe foi encaminhada. Contudo, essa mensagem não é repassada pelo proxy do domínio “lima.com” para o UAC, pois mensagens “100 Trying” são do tipo hop-to-hop, isto é: nunca são repassadas.
Ao receber a M4, o UAS opta por gerar uma mensagem “180 Ringing”, M6, para informar que já recebeu a solicitação INVITE e está aguardando ação do usuário (por exemplo, atender ou rejeitar a ligação). Mensagens “180 Ringing” também são opcionais, mas, ao contrário da “100 Trying”, devem ser repassadas até retornar ao UAC.
Como M4 chegou ao destinatário final com três campos Via, o User Agent sabe que a solicitação passou por dois dispositivos SIP intermediários e a rota de retorno para todas as mensagens dentro do contexto da transação INVITE devem passar pelos mesmos dispositivos SIP. Desta forma, M6 é encaminhada ao proxy do domínio “santos.com” conforme mostrado a seguir:
SIP/2.0 180 Ringing Via: SIP/2.0/UDP pr.santos.com:5060;branch=z9hG4bKhjasu8898ukf; received=200.201.202.203.204 Via: SIP/2.0/UDP proxy.lima.com:5060;branch=z9hG4bK898.78;received=100.101.102.104 Via: SIP/2.0/UDP pc145.lima.com:5060;branch=z9hG4bKfw19b;received=100.101.102.103 Max-Forwards: 70 To: Guilherme Santos <sip:guilherme@santos.com>;tag=762920 From: André Lima <sip:andre@lima.com>;tag=76341 Call-ID: jlaks984309k CSeq: 1 INVITE Contact: <sip:guilherme@soft667.santos.com> Content-Length: 0
Essa mensagem simplesmente copia os campos Via, To, From, Call-ID e CSeq da mensagem de requisição INVITE original, mas como agora não há corpo na mensagem, o campo Content-Type não existe e o valor de Content-Length é zero. Além disto, o parâmetro tag foi adicionado ao campo To.
É importante atentar para o fato que, ainda que esta mensagem tenha como origem o usuário Guilherme e destino o usuário André, os campos To e From não se alteram. Isto acontece porque estes campos identificam a direção da requisição e não a direção de uma mensagem específica (ROSENBERG, SCHULZRINNE e CAMARILLO et al, 2011).
Deve-se notar ainda que o campo Contact agora contém o endereço para o qual o usuário André poderá enviar as próximas transações diretamente para o usuário Guilherme sem auxílio dos servidores proxy, a saber: “sip:guilherme@soft667.santos.com”, um nome que pode ser traduzido por DNS para o endereço IP 200.201.202.203.
Ao receber M6, o proxy do domínio “santos.com” checa que o primeiro campo Via contém seu próprio endereço, então ele o remove e encaminha a mensagem para o endereço e porta informados no segundo campo Via (proxy.lima.com, 5060).
Similarmente, o proxy do domínio “lima.com”, ao receber M7 observa que o endereço no primeiro campo Via é o seu próprio endereço. Logo, ele o remove e, finalmente, encaminha a mensagem ao originador, o UAC. Assim, M8 é:
SIP/2.0 180 Ringing Via: SIP/2.0/UDP pc145.lima.com:5060;branch=z9hG4bKfw19b;received=100.101.102.103 Max-Forwards: 68 To: Guilherme Santos <sip:guilherme@santos.com>;tag=762920 From: André Lima <sip:andre@lima.com>;tag=76341 Call-ID: jlaks984309k CSeq: 1 INVITE Contact: <sip:guilherme@soft667.santos.com> Content-Length: 0
No exemplo presente o usuário Guilherme decide atender a ligação, portanto uma mensagem “200 OK” é enviada. Essa resposta é construída da mesma forma que a “180 Ringing”, contendo o mesmo parâmetro tag no campo To e o mesmo endereço de contato direto no campo Contact. Uma resposta “200 OK” também indica que os tipos e formatos de mídias negociadas pelo SDP foram aceitos, por isso no corpo da mensagem SIP é levada uma mensagem SDP carregando essa informação.
Como a mensagem “200 OK” ainda faz parte da transação INVITE, o caminho de retorno deve passar pelos mesmos dispositivos SIP como aconteceu com a mensagem “180 Ringing”. Desta forma, M9 é:
SIP/2.0 200 OK Via: SIP/2.0/UDP pr.santos.com:5060;branch=z9hG4bKhjasu8898ukf; received=200.201.202.203.204 Via: SIP/2.0/UDP proxy.lima.com:5060;branch=z9hG4bK898.78;received=100.101.102.104 Via: SIP/2.0/UDP pc145.lima.com:5060;branch=z9hG4bKfw19b;received=100.101.102.103 Max-Forwards: 70 To: Guilherme Santos <sip:guilherme@santos.com>;tag=762920 From: André Lima <sip:andre@lima.com>;tag=76341 Call-ID: jlaks984309k CSeq: 1 INVITE Contact: <sip:guilherme@soft667.santos.com> Content-Type: application/sdp Content-Length: 158 (Conteúdo SDP não exibido)
Como anteriormente, os servidores proxy no caminho verificam seus endereços no primeiro campo Via da mensagem que recebem, removem este campo, decrementam o valor no campo Max-Forwards e repassam a mensagem para o próximo endereço e porta do campo Via abaixo.
Neste ponto, é interessante destacar que respostas à requisições SIP são sempre compostas por um número de três dígitos seguido por uma frase informativa, como em: “100 Trying”, “180 Ringing”, “200 OK”. Estas respostas são classificadas de acordo com o primeiro dígito de seu número. Os dois dígitos seguintes servem como um subtipo. A Tabela I, extraída de (SIÉCOLA, 2010), mostra as respostas SIP com suas classificações.
Tabela 1: Classes de respostas SIP
O último passo para estabelecer a sessão é o UAC confirmar o recebimento da resposta “200 OK”, permitindo então o início do tráfego de mídia usando outro protocolo (o RTP, por exemplo). Essa confirmação é feita com uma requisição ACK, que é a mensagem M12:
ACK sip:guilherme@soft667.santos.com SIP/2.0 Via: SIP/2.0/UDP pc145.lima.com:5060;branch=z9hG4bKf992uij Max-Forwards: 70 To: Guilherme Santos <sip:guilherme@santos.com>;tag=762920 From: André Lima <sip:andre@lima.com>;tag=76341 Call-ID: jlaks984309k CSeq: 2 ACK Content-Length: 0
Inicialmente deve-se observar que a primeira linha da requisição agora conta com o endereço que o UAS previamente informou como sendo seu endereço de contato direto. Desta forma, o usuário André pode enviar o ACK diretamente para o usuário Guilherme sem intervenção dos servidores proxy. O campo Contact também foi removido, uma vez que o UAS já foi informado do endereço de contato direto do UAC.
Nota-se ainda que o parâmetro branch do campo Via é diferente dos anteriores, uma vez que esta mensagem ACK é considerada uma transação diferente da INVITE. Por outro lado, os parâmetros tag dos campos To e From, bem como o Call-ID não se alteraram porque esta mensagem ainda faz parte do mesmo diálogo que as mensagens anteriores. Agora, a troca de informações da mídia negociada pode então finalmente acontecer.
Após o tráfego de mídia, o usuário Guilherme deseja encerrar a sessão e para isso envia uma Requisição BYE para o usuário André, a mensagem M13:
BYE sip:andre@pc145.lima.com SIP/2.0 Via: SIP/2.0/UDP soft667.santos.com:5060;branch=z9hG4bK098jUkj Max-Forwards: 70 To: André Lima <sip:andre@lima.com>;tag=76341 From: Guilherme Santos <sip:guilherme@santos.com>;tag=762920 Call-ID: jlaks984309k CSeq: 3 BYE Content-Length: 0
Novamente, o parâmetro branch é diferente daquele nas requisições INVITE e ACK porque o BYE é uma transação diferente, contudo os parâmetros tag e o Call-ID permanecem os mesmos já que ainda trata-se do mesmo diálogo. Contudo, como agora esta é uma requisição direcionada ao usuário André, os campos To e From estão trocados em relação às mensagens anteriores. Portanto, neste momento o usuário Guilherme age como um UAC e o usuário André como um UAS.
Isto posto, infere-se que toda implementação SIP deve contar com um módulo cliente e um módulo servidor, visto que estes papéis são dinâmicos dentro de um mesmo diálogo.
Para finalizar a sessão, o UAS (usuário André) agora responde a solicitação BYE com uma mensagem “200 OK”, M14:
SIP/2.0 200 OK Via: SIP/2.0/UDP soft667.santos.com:5060;branch=z9hG4bKfw19b; received=200.201.202.203 Max-Forwards: 70 To: André Lima <sip:andre@lima.com>;tag=76341 From: Guilherme Santos<sip:guilherme@santos.com>;tag=762920 Call-ID: jlaks984309k CSeq: 2893 BYE Content-Length: 0
Com isso, completa-se o ciclo SIP de localização de usuário, sinalização, estabelecimento e encerramento de um diálogo. Contudo, não discutido aqui é como os servidores proxy são capazes de localizar um usuário. Na verdade há diferentes mecanismos para cumprir com esta finalidade, seja usando o protocolo SIP ou outros protocolos.
Servidores SIP
Servidores SIP são aplicações que recebem solicitações SIP, executam alguma operação com ela e devolvem uma resposta ao dispositivo que a solicitou.
Há três tipos de servidores SIP: servidor de proxy, servidor de redirecionamento e servidor de registro. Como são entidades lógicas, mais de um servidor SIP pode estar hospedado num mesmo dispositivo físico (YOSHIOKA, 2003).
Servidor Proxy
A sessão 2.1 introduziu o servidor proxy como um facilitador de troca de mensagens SIP, sendo o elemento responsável pela localização do User Agent alvo da requisição.
É importante esclarecer que um proxy diferencia-se de um User Agent em três pontos chave (ROSENBERG, SCHULZRINNE e CAMARILLO et al, 2011):
Na configuração exibida na Figura 1, conhecida como Trapezoide SIP, cada User Agent é configurado previamente para saber qual é o proxy padrão no seu domínio. Toda mensagem SIP será encaminhada para este servidor quando o UAC não souber qual endereço de contato direto do UAS com quem pretende estabelecer uma sessão.
Quando recebe uma requisição SIP, o proxy analisa para qual domínio a mensagem está destinada e obtém o endereço do servidor de proxy do domínio de destino, tipicamente através de uma pesquisa DNS SRV. Alternativamente, por motivos que estão fora do escopo da presente discussão, um proxy também pode rejeitar uma solicitação. Neste caso é retornada uma mensagem “406 Not Acceptable” ao UA.
Dentro do seu domínio, um servidor proxy tem acesso a uma abstração chamada de serviço de localização, tipicamente um banco de dados populado pelo servidor de registros (Registrar – tratado posteriormente) que armazena a relação entre identidades SIP externas e o endereço atual do dispositivo onde o UA está sendo executado. É desta forma que os servidores proxy resolvem o problema de localização do alvo de uma requisição SIP.
Ademais, um servidor proxy pode operar com estado (stateful)ou sem estado (stateless). No modo stateful, o proxy mantém um contador de tempo e registros para todas as requisições e respostas que recebe e repassa e usa essas informações no processamento futuro de mensagens pertencentes a um mesmo diálogo. No modo stateless não há contadores de tempo nem registros das requisições e respostas repassadas anteriormente, desta forma não há retransmissões de mensagens perdidas e nenhum tipo de processamento para mensagens futuras pertencentes a um mesmo diálogo (YOSHIOKA, 2003).
Servidor de Redirecionamento
Tal como um servidor proxy, um servidor de redirecionamento também auxilia no processo de localização do destinatário de uma requisição SIP, mas não encaminha requisições SIP. Em vez disto, apenas responde ao UA de origem qual é o endereço de contato para atingir o UA de destino, ou um endereço de próximo salto para um servidor proxy ou outro servidor de redirecionamento mais próximo, sem se envolver de fato na comunicação (YOSHIOKA, 2003).
Detalhamentos sobre as mensagens trocadas entre um UA e um servidor de redirecionamento podem ser obtidos em (JOHNSTON, 2009).
Servidor de Registro
Um servidor de registro, também chamado Registrar, aceita requisições SIP REGISTER. Qualquer outra solicitação recebe como resposta um “501 Not Implemented” (ROSENBERG, SCHULZRINNE e CAMARILLO et al, 2011).
A Figura 2 mostra uma situação em que o usuário Guilherme solicita ao servidor de registro em seu domínio que crie um vínculo entre sua identidade SIP externa (também chamada de Address-of-Record, ou simplesmente AOR) e seu endereço atual.
Figura 2: Exemplo de Registro SIP
A solicitação REGISTER é:
REGISTER sip:reg.santos.com SIP/2.0 Via: SIP/2.0/UDP 200.201.202.203:5060;branch=z9hG4bK019jesd Max-Forwards: 70 To: Guilherme Santos <sip:guilherme@santos.com> From: Guilherme Santos <sip:guilherme@santos.com>;tag=456098 Call-ID: 3487654 CSeq: 1 REGISTER Contact: sip:guilherme@200.201.202.203 Content-Length: 0
O campo To traz o AOR que para o qual o UA deseja registrar o seu endereço de contato atual. O campo Contact traz o endereço de contato atual que deve ser associado ao AOR. Os campos To e From usualmente trazem o mesmo endereço, exceto quando há um terceiro dispositivo que faz o registro em nome de outro UA (JOHNSTON, 2009).
Ao receber a requisição REGISTER, o servidor de registro atualiza o banco de dados usado pelos servidores proxy e de redirecionamento para localização de usuário e responde com uma mensagem “200 OK” informando que o registro foi feito com sucesso da seguinte forma:
SIP/2.0 200 OK Via: SIP/2.0/UDP 200.201.202.203:5060;branch=z9hG4bK019jesd Max-Forwards: 70 To: Guilherme Santos <sip:guilherme@santos.com>;tag=374060164 From: Guilherme Santos <sip:guilherme@santos.com>;tag=456098 Call-ID: 3487654 CSeq: 1 REGISTER Contact: sip:guilherme@200.201.202.203;expires=3600 Content-Length: 0
O campo Contact confirma o endereço de contato que foi registrado para o AOR e traz um parâmetro expires que informa a quantidade de tempo em segundos para a qual o registro permanecerá válido. Se o UA desejar que o seu registro continue válido por mais tempo, basta enviar outra requisição REGISTER ao servidor de registro antes que o tempo expire.
Analogamente a um sistema de telefonia celular, o registro tipicamente é feito enquanto o dispositivo SIP está iniciando. A forma como o UA toma conhecimento do endereço do servidor de registro está descrita na seção 10.2.6 de (ROSENBERG, SCHULZRINNE e CAMARILLO et al, 2011).
SDP – Session Description Protocol
Para garantir o processo de negociação das mídias a serem trocadas numa sessão, o SIP encapsula outro protocolo, comumente o SDP.
O SDP, definido inicialmente em no RFC 2327 (HANDLEY e JACOBSON, 2011), teve como propósito original descrever sessões multicast estabelecidas sobre o backbone multicast da Internet, o MBONE e, portanto, vários de seus campos tem uso limitado (ou nenhum uso) para as sessões unicast estabelecidas atualmente com o SIP, mas foram mantidos na nova definição do protocolo, RFC 4566 (HANDLEY, JACOBSON e PERKINS, 2011), para garantir a compatibilidade.
De acordo com (JOHNSTON, 2009), as principais informações carregadas numa mensagem SDP sobre a sessão de mídia são: endereço IP (IPv4 ou IPv6) ou nome de host, perfil RTP (tipicamente “RTP/AVP”), número da porta que será usada para troca de fluxo de mídia, tipo de mídia a ser trocada (vídeo, áudio, texto e etc.) e esquema de codificação de mídia.
Similarmente ao SIP, o SDP é um protocolo textual cujas mensagens são compostas por campos. Cada linha da mensagem é um campo e começa com uma letra minúscula. Nem todos os campos são obrigatórios, mas, se presentes, devem aparecer na ordem especificada na Tabela II, retirada de (SIÉCOLA, 2010).
Tabela 2: Campos SDP
Como detalhado em (ROSENBERG e SCHULZRINE, 2011) e amplamente exemplificado em (JOHNSTON e SPARKS, 2011), o SDP é baseado no modelo de oferta e resposta (Offer/Answer Model). Resumidamente, neste modelo um participante da sessão (o UAC) gera uma mensagem SDP (a oferta) informando quais mídias (e seus respectivos esquemas de codificação) gostaria de trocar, bem como seu endereço IP e porta onde gostaria de receber o fluxo de mídia. O outro participante (UAS) responde com uma mensagem SDP (a resposta) que tem um fluxo de mídia correspondente para cada fluxo de mídia descrito na oferta (isto é, para cada campo “m =” na oferta, deve haver um campo “m =” correspondente na resposta) indicando se o fluxo é aceitável ou não. Na resposta, também são informados o endereço IP e porta onde o UAS gostaria de receber o fluxo de mídia sendo negociado.
Para exemplificar, abaixo segue a oferta SDP carregada em M1 da Figura 1:
v = 0 o = André 2890844526 2890844526 IN IP4 pc145.lima.com s = - c = IN IP4 100.101.102.103 t = 0 0 m = audio 46000 RTP/AVP 0 6 8 a = rtpmap : 0 PCMU/8000 a = rtpmap : 6 DVI4/16000 a = rtpmap : 8 PCMA/8000
A primeira linha traz o campo versão. A versão atual e única do protocolo SDP é a zero (0). Portanto, uma mensagem SDP válida sempre começa com “v = 0”.
O campo seguinte contém informações sobre o originador da mensagem. Esse campo identifica exclusivamente a sessão no contexto do SDP. O primeiro valor depois do “=” é o parâmetro username, que tipicamente contém o nome de login ou host do originador, ou simplesmente “-”. A seguir estão os parâmetros session-id e version. Em (HANDLEY e JACOBSON, 2011) e (HANDLEY, JACOBSON e PERKINS, 2011) recomenda-se que estes parâmetros sejam um timestamp NTP (Network Time Protocol) ou um número aleatório qualquer. Logo após, está o parâmetro network-type que é sempre “IN” para Internet, seguido pelos parâmetros address-type (“IP4” ou “IP6”, para IPv4 e IPv6 respectivamente) e address, que informa o endereço IP do originador ou nome DNS do host.
O campo seguinte é o nome de sessão. Este campo não tem utilidade para o estabelecimento de uma sessão unicast com o SIP, contudo trata-se de um campo obrigatório e como tal não pode deixar de ser incluído. Assim, (ROSENBERG e SCHULZRINE, 2011) recomenda que o campo seja preenchido com um espaço em branco ou com um traço (“-”).
A linha seguinte traz informações sobre a conexão. Os parâmetros neste campo são network-type, address-type e address, que são preenchidos conforme já explicado no campo “o =”, exceto que aqui o parâmetro address deve conter o endereço IP do participante.
A próxima linha indica o tempo para início e término da sessão. Contudo, conforme (ROSENBERG e SCHULZRINE, 2011), sessões unicast devem ser criadas e terminadas através de um protocolo de sinalização, como o SIP. Então os parâmetros start-time e stop-time neste campo devem ser preenchidos com “0”.
A mensagem SDP segue com o campo “m =”, que especifica qual o tipo de mídia deseja-se trocar. O primeiro parâmetro é media que, de acordo com (HANDLEY e JACOBSON, 2011) pode ser “áudio”, “vídeo”, “text”, “application”, “message”, “image”, ou “control”. Seguindo, há os parâmetros port, que identifica em qual porta o participante gostaria de receber o fluxo de mídia, e o transport que exibe o protocolo de camada de transporte ou o perfil RTP que será usado. O último parâmetro é o format-list que traz os esquemas de codificação para a mídia sendo negociada que estão disponíveis.
As três linhas seguintes são atributos, campos opcionais e que podem ser usados para trazer mais informações sobre a mídia listada no campo “m =”. Neste caso, apenas trazem explicitamente informações sobre os esquemas de codificação listados no parâmetro format-list.
Como determina o modelo Offer/Answer, o UAS agora deve construir uma resposta que aceite ou rejeite a oferta. No caso de rejeição, basta que o UAS formule uma mensagem SDP que tenha “0” (zero) no parâmetro port do campo “m =”. Esta é a forma que o SDP usa para comunicar ao outro participante que não tem interesse em trocar uma mídia oferecida (ROSENBERG e SCHULZRINE, 2011).
No exemplo da Figura 1, o usuário Guilherme aceita a oferta. Neste caso, a resposta deve conter uma especificação de mídia coincidente com a oferta. Portanto, a mensagem SDP carregada em M9 pode ser:
v = 0 o = Guilherme 2890844570 2890844570 IN IP4 soft667.santos.com s = - c = IN IP4 200.201.202.203 t = 0 0 m = audio 50000 RTP/AVP 8 a = rtpmap : 8 PCMA/8000
Deve-se notar que o UAS selecionou apenas um dos três esquemas de codificação oferecidos, indicando que este deve ser o codec usado.
Os exemplos de mensagens SDP abordados aqui exploraram apenas os campos obrigatórios. Em (JOHNSTON, 2009) e (HANDLEY, JACOBSON e PERKINS, 2011) são oferecido detalhamentos sobre cada campo da Tabela II. Em (JOHNSTON e SPARKS, 2011) há numerosos exemplos de trocas de mensagens oferta/resposta.
RTP – Real-time Transport Protocol
O RTP (Real-Time Transport Protocol), definido em (SCHULZRINNE, CASNER e FREDERICK, 2011), foi desenvolvido para tornar possível o transporte de pacotes contendo voz, vídeo ou outro tipo de mídia (informação) sobre uma rede IP. O protocolo permite a detecção de pacotes perdidos, variações no atraso (jitter) e chegada fora de ordem, contudonão garante qualidade de serviço para a mídia sendo transportada, isto é: pacotes RTP são tratados da mesma forma como qualquer outro pacote numa rede IP. Assim sendo, o que ocorre é um trabalho em conjunto com o RTCP (Real-time Transport Control Protocol), que é usado para monitorar estatísticas referentes às trocas de pacotes RTP (SCHULZRINNE, 2011). Sendo usado por aplicações cuja natureza é de tempo real, o transporte de pacotes RTP requer uma latência fim-a-fim tão baixa quanto possível através da Internet. Para isto, as aplicações tipicamente utilizam o protocolo UDP na camada de transporte, uma vez que não há tempo para detectar, sinalizar e retransmitir um pacote perdido.
Diferentemente do SIP e do SDP, o RTP é um protocolo orientado a bit e possui um formato predefinido de cabeçalho composto por 12 bytes fixos, podendo ser estendido. O cabeçalho RTP é mostrado na Figura 3.
Figura 3: Cabeçalho RTP
O empacotamento da mídia codificada se dá simplesmente pela adição de um cabeçalho RTP a pequenas amostras do fluxo de bits codificado pelo codec negociado anteriormente com o SDP, formando então um pacote RTP.
Na recepção, os pacotes RTP são tratados de acordo com seu cabeçalho, podendo até ser descartado caso seja um pacote contendo um fragmento de mídia que esteja atrasado demais para ser reproduzido, por exemplo.
O cabeçalho RTP contém, de acordo com (JOHNSTON, 2009):
RTCP – Real-time Transport Control Protocol
Para que os participantes de uma sessão RTP tenham subsídios para medir a qualidade da comunicação, (SCHULZRINNE e CASNER, 2011) também define o RTCP (Real-Time Transport Control Protocol), que se baseia na transmissão periódica de pacotes de controle para todos os participantes da sessão.
O RTCP desempenha, dentre outros, dois papéis que importa destacar. Primeiro, e principalmente, ele deve reunir informações estatísticas sobre aspectos de qualidade a respeito do recebimento da mídia e enviar tais informações à fonte (ou fontes, se na sessão houver vários participantes – sessão multicast). Esses dados podem ser usados para realizar codificação adaptativa da mídia, por exemplo, além de detecção de falhas na transmissão.
Em segundo lugar, o RTCP provê um identificador exclusivo para os sistemas finais da sessão RTP conhecido como CNAME. Essa é também a função do SSRC visto anteriormente, contudo o SSRC de um participante pode ser alterado caso seja detectado um conflito ou caso a aplicação comunicante reinicie. Nestes casos, o CNAME permite correlacionar um participante ao seu novo SSRC, evitando que todo o processo de estabelecimento da sessão seja executado novamente.
A taxa com a qual um participante envia pacotes RTCP para os demais deve ser controlada, caso contrário a comunicação de mídia, que é a principal razão do RTP, ficaria comprometida. Sendo assim, o protocolo também provê mecanismos para que seja calculado um intervalo de envio entre pacotes RTCP, de tal forma que a banda ocupada por eles seja suficientemente baixa. Contudo, a forma como isto é realizado está além do escopo deste trabalho e está detalhada na sessão 6.2 de (SCHULZRINNE e CASNER, 2011).
São definidos cinco tipos de pacotes RTCP no RFC 3551, (SCHULZRINNE e CASNER, 2011):
Para diminuir o overhead de controle na comunicação, múltiplos pacotes RTCP são concatenados e enviados num único datagrama UDP. Cada pacote RTCP neste datagrama poderia ser processado individualmente sem que nenhuma restrição quanto a sua ordem ou combinação fosse imposta, contudo para que as funcionalidades do protocolo sejam garantidas, cada datagrama enviado deve conter no mínimo dois pacotes RTCP diferentes: um pacote de relatório (isto é um SR ou um RR) e um SDES com o CNAME para garantir que participantes recém chegados obtenham o CNAME dos demais participantes tão logo quanto possível.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
