Redes com Integração de Serviços
5
aParte
Streaming sobre Redes IP
Índice
1 Introdução...2
1.1 Streaming através de um servidor web ...3
1.2 Streaming através de um servidor de media ...4
2 Real-Time Streaming Protocol (RTSP)...6
2.1 Parâmetros RTSP ...7
2.2 Mensagens RTSP ...8
2.2.1 Mensagens RTSP de Pedido ...9
2.2.2 Mensagens RTSP de Resposta ...10
2.3 Sessão RTSP ...11
3 Session Announcement Protocol (SAP)...12
4 Session Description Protocol (SDP) ...13
4.1 Especificações SDP ...14
5 Arquitecturas de distribuição ...17
1 Introdução
Até há pouco tempo, para se ter acesso a dados áudio e vídeo na Internet tinha de se fazer primeiro o download completo do ficheiro de media, para posteriormente o reproduzir localmente, no que é vulgarmente designado download-and-play. Contudo, como que os ficheiros de media são normalmente muito grandes, os únicos conteúdos encontrados na Internet eram clips com poucas dezenas de segundos, que mesmo assim levavam minutos a descarregar.
Por este motivo, surgiu a necessidade de encontrar uma forma de fazer a representação dos dados multimédia à medida que eles iam chegando. O conceito de
streaming resulta desta necessidade, sendo basicamente um método para o envio de
dados numa rede, por forma a que estes possam ser vistos em tempo real.
Os streams podem ser gerados por uma fonte ao vivo como por exemplo uma câmara de vídeo, um Webcast1, uma estação de rádio, ou por um servidor de vídeo. Com acontecimentos ao vivo, os streams funcionam aproximadamente como uma versão
web de uma televisão ou rádio, podendo os utilizadores ligá-lo, desligá- lo ou mudar
de canal. Quando se está a fazer a representação (streaming) de um filme armazenado num disco (tipo video-on-demand, VoD), os utilizadores podem ter acesso ao conteúdo completo, podendo avançar ou retroceder na representação do mesmo.
Devemos distinguir a distribuição dos dados em multicast da distribuição em unicast, pois apresentam diferenças no modo como o utilizador pode controlar a apresentação.
o Em unicast, os streams são enviados entre servidor e cliente, podendo o cliente controlar a representação dos dados. A aplicação cliente pode enviar os comandos do utilizador para o servidor, para que este faça as devidas alterações no stream enviado. Exemplos de comandos são o play, pause, stop, avançar, retroceder ou mesmo gravar.
o Em multicast, os streams são enviados directamente para um endereço de grupo (um endereço IP Multicast), sendo recebidos pelos computadores clientes sem que cada um individualmente tenha a possibilidade de controlar o streaming, mas podendo estabelecer-se alguma forma de controlo.
Para a adequação entre diferentes distribuições existem elementos na rede que são denominados de reflectores. A figura seguinte (Apple) exemplifica uma distribuição ao vivo de um stream, em que são utilizados dois reflectores. O primeiro reflector, denominado de reflector multicast, faz a adequação entre o meio Broadcast de uma
1
Um Webcast é caracterizado como uma distribuição de dados áudio e vídeo em tempo real na Internet, tendo como destinatários simultâneos um ou mais receptores.
LAN e o Mbone2. O segundo reflector (reflector unicast) é um elemento opcional, apenas sendo utilizado quando existirem terminais que não possam aceder directamente ao MBone. Esta situação pode ocorrer sempre que um terminal não estiver coberto por um router multicast, ou quando uma aplicação cliente não estiver preparada para ser um receptor multicast, utilizando o IGMP para fazer a adesão e abandono de um grupo.
Figura 1: Rede de distribuição de streaming
À medida que o streaming de áudio e vídeo se tornou mais popular, sugiram dois métodos de o implementar. Uma das soluções sustenta-se nos convencionais servidores web (web server) para fornecimento dos dados aos clientes. A outra solução utiliza um servidor específico para os dados multimédia (media server) para executar a mesma função.
1.1 Streaming através de um servidor web
A utilização do streaming através de um web server é um pequeno passo evolutivo em relação ao método download-and-play, encontrando-se a maior diferença ao nível do servidor. Os dados áudio e vídeo começam por ser comprimidos e multiplexados formando um único ficheiro de media, em que o nível de compressão depende da
2
MBone é uma rede overlay da Internet que suporta o IP Multicast, permitindo por isso uma comunicação eficiente do tipo many-to-many. Por este motivo a MBone é utilizada para conferências multimédia.
largura de banda da transmissão. Se existirem diferentes clientes que tenham diferentes velocidades de acesso, então existirá um ficheiro para cada uma dessas velocidades. Depois de criado, o ficheiro é colocado num determinado directório de um web server, sendo referenciado através de uma URL de uma página web, em que o cliente é questionado sobre largura de banda da ligação que detém. A página web lança a aplicação cliente de media, que se encarregará de apresentar o ficheiro de media à medida que este vai chegando (através de um download convencional) e depois de um buffering inicial de alguns segundos. Este buffering permite à aplicação cliente continuar a apresentação em períodos de congestionamento da rede.
O streaming através de um servidor web utiliza o protocolo Hyper Text Transport
Protocol (HTTP) em cima do TCP, o que desde logo impossibilita este método de
funcionar em IP Multicast. Este método tem ainda a característica de deixar uma cópia no disco do cliente, o que em termos de direitos de autor pode implicar a necessidade de proteger o ficheiro com mecanismos de protecção, nomeadamente do tipo DRM (Digital Right Management).
1.2 Streaming através de um servidor de media
Com o streaming media server, os passos iniciais são semelhantes, com a excepção de que os dados são copiados para um media server em vez do anterior web server.
O restante processo difere bastante do anterior dado que o servidor de media e o cliente permanecem em contacto um com o outro durante a totalidade do processo de apresentação. Os dados são por isso activa e inteligentemente enviados para o cliente, significando isto que o servidor entrega os dados ao ritmo exacto que o cliente necessita para os representar, consoante o nível de compressão dos streams de áudio e vídeo.
Este processo, apesar de poder ser também baseado no HTTP/TCP, utiliza habitualmente o Real Time Protocol (RTP) para transportar o streaming de dados e o protocolo Real Time Streaming Protocol (RTSP) para a comunicação entre o cliente e o servidor, permitindo a troca de informação sobre os comandos de apresentação. Esta arquitectura de protocolos pode ser vista na figura seguinte.
Dados de Media Monitori-zação de Dados Anúncio de Sessão Descrição e Controlo de Sessão Descrição e Transporte de Sessão SDP Aplicação MPEG-x, H.263, etc SAP RTSP SIP http RTP RTCP UDP TCP Transporte IP Rede
Figure 2: Arquitectura de protocolos IP
Apesar deste método ter sido desenhado especificamente para permitir a entrega de dados de media ao vivo, os servidores de media apresentam várias vantagens sobre os
web servers.
Uma das vantagens tem a ver com uma melhor qualidade na representação do áudio e vídeo, como consequência do permanente contacto entre servidor e cliente, permitindo que o servidor se adapte dinamicamente à largura de banda existente na rede, utilizando para tal o RTCP para diagnosticar a qualidade de recepção. Numa solução web server isto não é possível dado que o servidor não tem informação da parte do cliente sobre a qualidade de recepção.
Outra vantagem, esta agora utilizada fundamentalmente em tráfego unicast, tem a ver com a possibilidade que os utilizadores têm de controlar a apresentação, através dos comandos play, pause, etc. Em contrapartida, numa solução web server apesar de também ser possível comandar a apresentação, isto obriga a constantes rebufferings com os respectivos atrasos indesejáveis.
A solução media server apresenta ainda a vantagem de maior escalabilidade em relação ao número de utilizadores e em relação ao tamanho dos ficheiros de media, que são em geral muito maiores que os tradicionais ficheiros em HTML. O elevado número de utilizadores simultâneos acontece frequentemente em apresentações ao vivo, podendo ser resolvido com a utilização do multicast com a consequente redução drástica da largura de banda necessária. Para além disso, dado que os ficheiros de media têm tamanhos muito maiores que os de HTML torna-se necessária uma aplicação que os saiba gerir de forma correcta optimizando a forma como os ficheiros de media são lidos do disco, guardados na memória e enviados para a rede. Assim, só uma aplicação servidora especializada será capaz de assegurar estas funções.
Uma vantagem adicional tem a ver com os direitos de autor (Copyright) que ficam salvaguardados se o utilizador não puder guardar cópias dos dados, como acontece com o streaming através de um media server.
2 Real-Time Streaming Protocol (RTSP)
O Real-Time Streaming Protocol (RTSP) é um protocolo (ou por vezes referenciado como framework) que fornece às aplicações a possibilidade de controlarem uma ou mais sequências sincronizadas (streams) de um media, como é o caso de áudio ou
vídeo. O RTSP não é no entanto o responsável pela entrega dos dados, actuando mais
como um "controlo remoto" para controlar servidores de media.
O conjunto de sequências (streams) a controlar, é definida por uma descrição da apresentação que contém informação sobre um ou mais streams de media, como por exemplo um conjunto de codificações, endereços de rede, informações sobre os conteúdos, etc. Outros protocolos do IETF como o Session Description Protocol (SDP) utilizam o termo "sessão" para uma apresentação ao vivo. Esta descrição não é no entanto o objectivo deste protocolo, sendo analisada num capítulo posterior.
Em RTSP não existe a noção de conexão RTSP, no entanto, o servidor manterá um identificador por cada sessão, não estando este identificador ligado a qualquer conexão ao nível do protocolo de transporte.
Durante uma sessão RTSP, um cliente pode abrir e fechar várias conexões ao servidor para enviar pedidos RTSP utilizando um protocolo connection-oriented como por exemplo o TCP, ou um protocolo connectionless como por exemplo o UDP.
Os streams controlados pelo RTSP podem utilizar o RTP, mas a operação do RTSP não depende do mecanismo de transporte utilizado.
O protocolo RTSP é intencionalmente semelhante ao HTTP diferindo em alguns aspectos dos quais realçamos os seguintes:
o Um servidor RTSP necessita de manter um registo activo por cada sessão enqua nto decorrer a apresentação ao cliente.
o Em RTSP, tanto o servidor de media como o cliente podem emitir pedidos. o Os dados de media não são transportados pelo RTSP, sendo transportados de
uma forma out-of-band por um outro protocolo.
Utilizando o RTSP o cliente pode requerer uma descrição da apresentação utilizando o HTTP ou outro método. Se a apresentação estiver a ser difundida em multicast, a descrição da apresentação conterá os endereços de multicast e os portos a serem utilizados para os media.
É também possível utilizar o RTSP para convidar um servidor de media a aderir a uma conferência no sentido de fornecer dados para a mesma, ou com o intuito de gravar a apresentação.
É ainda possível ao servidor informar o cliente sobre novos streams de media que passem a estar disponíveis durante uma sessão, o que terá uma clara vantagem para o caso de apresentações ao vivo.
2.1 Parâmetros RTSP
VersãoO RTSP utiliza um sistema de numeração de versão de protocolo do tipo
<maior>.<menor> igual ao que se utiliza para o HTTP. A versão em análise é a
versão 1.0.
Uniform Resource Locator - URL
Existe um conceito muito importante dentro do WWW, que é o conceito de URI (Uniform Resource Identifier). Os Identificadores Uniformes de Recursos têm tido diferentes nomenclaturas ao longo dos tempos. Entre elas existe a de "endereço WWW", "Identificador Universal de Documento", "Identificador Universal de Recursos", sendo que se utiliza actualmente uma combinação de Uniform Resource
Locator (URL) com o de Uniform Resource Name (URN).
No RTSP um URL é uma sequência de texto (com um formato determinado) que identifica de uma forma unívoca um recurso dentro da rede. Para tal contém a seguinte informação:
o Protocolo que se tem que utilizar para o obter (identificado pelo serviço) o Endereço onde se encontra (identificado pelo host)
o Nome do recurso(identificado pelo caminho)
O URL genérico terá o seguinte formato:
serviço://host:porto/caminho
Quando se pretende identificar um recurso RTSP, podem- se utilizar os identificadores "rtsp" ou "rtspu" no campo de serviço. O serviço "rtsp" requer a utilização de um protocolo de transporte fiável (neste caso o TCP), enquanto o serviço "rtspu" se refere à utilização de um protocolo de transporte que não apresente garantias de fiabilidade (neste caso o UDP).
O campo de host refere-se a um host domain name ou a um endereço IP, sendo que este último deverá ser evitado.
Se não aparecer o identificador de porto, assume-se por defeito o porto 554 quer para o UDP, como para o TCP.
Uma stream ou uma agregação de streams (apresentação) é identificada dentro de um
host pelo caminho. No entanto, o caminho não implica uma determinada estrutura de
Vejamos um exemplo em que se admite ter uma apresentação denominada de twister composta de vários streams, um deles de áudio contido num ficheiro de media denominado de audiotrack.
Se numa aplicação cliente pretendermos identificar o recurso correspondente ao ficheiro de áudio poderemos chamar algo como:
rtsp://media.exemplo.com:554/twister/audiotrack
Desta forma passaremos a controlar a stream de áudio através de comandos que serão enviados através de uma conexão do TCP, no porto 554 do host media.exemplo.com.
Mas se pretendermos identificar a apresentação em si, poderemos chamar:
rtsp://media.exemplo.com:554/twister Identificadores de conferência e de sessão
Os identificadores de conferência (conference-id) são utilizados para permitir às sessões RTSP a obtenção de parâmetros de conferências multimédia em que o servidor esteja a participar.
Existe ainda o identificador de sessão (session-id), que é gerado no servidor como consequência de um Pedido de SETUP, sendo mantido até ao final da sessão.
Identificadores temporais
No RTSP há três identificadores temporais.
o O SMPTE relative timestamp identifica o tempo que decorreu desde o início do clip de media, com um formato horas:minutos:segundos:tramas.subtramas. Existem vários formatos que permitem definir o ritmo de tramas por segundo.
o O Normal Play Time (NPT) identifica a posição temporal de cada stream em relação ao começo da apresentação. Este valor é muitas vezes exemplificado com o tempo que visualizamos num VCR e depende dos comandos de avanço ou recuo que o cliente enviar.
o Poderá existir ainda um identificador de tempo absoluto.
2.2 Mensagens RTSP
O RTSP é um protocolo baseado no formato de texto. Cada mensagem é composta por várias linhas separadas por uma sequência de caracteres de final de linha (Carriage Return + Line Feed = CRLF), que por sua vez contêm vários campos, diferenciados através de um caracter de espaço (LWS).
As mensagens RTSP têm o mesmo formato que as do protocolo HTTP, podendo ser mensagens de Pedido ou Resposta. Todas as mensagens são constituídas por:
o uma linha inicial (do tipo Request-Line ou Status-Line). o um ou mais campos de cabeçalho.
o uma linha separadora (apenas contendo os caracteres CRLF) o o corpo da mensagem (opcional)
O corpo da mensagem é utilizado para o transporte de dados adicionais, tais como por exemplo, dados sobre uma descrição de apresentação.
2.2.1 Mensagens RTSP de Pedido
As mensagens de Pedido RTSP podem ser emitidas de um cliente para um servidor ou
vice-versa (ao contrário do HTTP). Na primeira linha (Request-Line) dessa mensagem
é identificado, para além da versão do protocolo, o recurso através do seu URL e um método a ser aplicado a esse recurso. Os métodos RTSP podem ser os seguintes:
??DESCRIBE - Utilizado para requerer a um servidor a descrição de uma apresentação ou de um stream de media. O servidor devolverá entre outros dados, o conteúdo do ficheiro de SDP.(C? S)
??ANNOUNCE - Quando enviado a partir de um cliente, pede a confirmação de uma descrição associada a uma apresentação ou stream. Quando enviado a partir de um servidor, permite actualizar a descrição no cliente em tempo real. (C? S)
??GET_PARAMETER - Permite pedir à entidade par, os valores dos parâmetros indicados, tais como por exemplo o jitter ou o número total de pacotes recebidos. (C? S)
??OPTIONS - Permite consultar a entidade par, em qualquer momento, sobre quais os métodos que estão associados a um recurso (C? S)
??PAUSE - Provoca a interrupção temporária do envio de dados de media, sem a libertação dos recursos correspondentes. Se numa apresentação se enviar um PAUSE indicando a URL de uma das streams, só essa stream parará. Por exemplo para uma stream de áudio corresponde ao comando de mute. (C? S)
??PLAY - Diz ao servidor para começar a enviar os dados através do mecanismo de transporte indicado na mensagem de SETUP. (C? S)
??RECORD - Permite a um cliente pedir a um servidor para que comece a gravar os dados de media, de acordo com a descrição de apresentação.(C? S)
??REDIRECT - Informa um cliente que deverá mudar para uma outra URL. Para tal o cliente deverá enviar um pedido de TEARDOWN para a sessão actual, seguido de um SETUP para a nova sessão. (S? C)
??SETUP - Permite a um cliente pedir a confirmação de um determinado mecanismo de transporte para um stream de media, mesmo que o stream já esteja a ser enviado. Os mecanismos de transporte incluem a descrição do protocolo de transporte de dados (por exemplo o RTP), a indicação se se trata de unicast ou multicast, bem como a indicação dos portos correspondentes. Se o servidor confirmar o pedido, isso fará com que ele faça uma reserva de recursos por cada stream a enviar, iniciando uma sessão RTSP. (C? S)
??SET_PARAMETER - Permite definir determinados parâmetros, sendo preferencialmente emitido parâmetro a parâmetro. (C? S)
??TEARDOWN - Quando emitida do cliente para o servidor, provoca a paragem do envio do stream de dados, libertando os recursos com ele associados. (C? S)
C? S representa um método que só pode ser emitido do cliente para o servidor, S? C representa um método que só pode ser emitido do servidor para o cliente e (C? S) um método que pode ser emitido nos dois sentidos. Todos os métodos se utilizam tanto para apresentações como para streams, à excepção do SETUP que só se utiliza com
streams.
A recepção das mensagens de Pedido são confirmadas (acknowledged) pelos receptores a não ser que sejam enviadas para um grupo multicast, ou utilizem um protocolo que já o faça, como é o caso do TCP.
Cada mensagem de Pedido transporta um número de sequência CSeq num determinado campo do cabeçalho, sendo incrementado de um em cada novo Pedido emitido. No caso de haver uma retransmissão, por falta de confirmação, o valor de
CSeq não é increme ntado.
O cabeçalho de cada mensagem contém, para além do CSeq, vários identificadores que não veremos aqui detalhadamente.
Tal como já referido, o RTSP controla um stream que pode ser enviado utilizando um outro protocolo, independentemente do canal de controlo utilizado. Tal como referido atrás, o fluxo de dados de controlo (RTSP) pode utilizar uma conexão TCP enquanto os dados utilizam o UDP. Para além disso, uma determinada stream de media pode ser controlada através de pedidos sequenciais, enviados através de diferentes conexões TCP. Por este motivo o servidor deverá manter um registo por sessão (estado da sessão) utilizando para tal o identificador de sessão (session_id) em cada Pedido, com o objectivo de ligar um determinado Pedido RTSP a um stream.
Os estados de uma sessão são alterados sempre que sejam emitidos Pedidos que contenham os métodos de SETUP, PLAY ou RECORD, PAUSE e TEARDOWN.
2.2.2 Mensagens RTSP de Resposta
Depois de receber uma mensagem de Pedido, o receptor responde com uma outra mensagem, dita de Resposta. Cada Resposta é identificada com um determinado Pedido anterior, através do valor de CSeq que terá que ser o mesmo.
A mensagem de Resposta, na sua primeira linha (Status-Line) contém um código de resposta (Status-Code) ao Pedido emitido e uma frase contendo o motivo dessa resposta (Reason-Phrase). A Reason-Phrase deverá ser entendida apenas pelo utilizador.
O Status-Code é um valor numérico de três digitos, em que o primeiro digito define a classe da resposta. Estão definidas as seguintes cinco classes de respostas:
- 1xx: Informativo - Pedido recebido, continuando com o processo. - 2xx: Sucesso - A acção foi recebida com sucesso, entendida e aceite.
- 3xx: Redirection - No sentido de se completar a acção, terão que se enviar mais dados.
- 4xx: Erro da parte do cliente - O Pedido contém uma sintaxe errada, ou não pode ser satisfeito.
- 5xx: Erro da parte do servidor - O servidor não pode satisfazer um determinado Pedido.
Por exemplo, durante uma apresentação ao vivo em que um utilizador envie um Pedido com o método de PAUSE, o servidor deverá devolver "501 Not Implemented" e o cliente não deverá voltar a fazer o mesmo pedido.
2.3 Sessão RTSP
A figura seguinte exemplifica uma sessão RTSP, em que são enviados dados áudio e vídeo.
Figure 3: Exemplo de sessão RTSP
No exemplo anterior a descrição da sessão é pedida através de um comando http para ilustrar a interoperabilidade dos dois protocolos, mas poderia ser igualmente feita com o comando RTSP Describe.
O RTSP permite aos clientes de media o controlo de apresentações não contínuas, enviando os streams correspondentes através do RTP. Os identificadores temporais (Timestamps) do RTP, bem como os contadores de número de sequência (SN) do RTP são independentes do RTSP, não sendo afectados pelos saltos do Normal Play Time (NPT) do RTSP.
Por exemplo, se a frequência de relógio for de 8000Hz, o intervalo de empacotamento for de 100ms e os valores iniciais de Timestamp e SN são zero, cada pacote RTP verá o seu Timestamp incrementado de N=800 amostras. Se por exemplo "tocarmos" dois segmentos, o primeiro do NPT=10s ao NPT=14.9s e isso corresponder uma variação do Timestamp de 0 a 39200 e do SN do 0 ao 49 (50 pacotes - 1 em cada 100ms), e o segundo segmento do NPT=18s ao NPT=19.9s, isso corresponderá a uma variação do SN do 50 ao 69, e do Timestamp de 40000 a 55200.
Quando um cliente representa o vídeo, gravado a 30 tramas por segundo, com um factor de escala de velocidade dupla (Fast Forward) e mantendo o ritmo de transmissão, o servidor deverá apenas enviar uma em cada duas tramas. Desta forma, cada pacote RTP terá o incremento habitual do Timestamp de 3000 por cada trama, mas o NPT incrementará 1/15 segundos por cada trama de vídeo (em vez de 1/30).
3 Session Announcement Protocol (SAP)
Como já referimos, o protocolo IGMP é utilizado pelos hosts para aderir a um determinado grupo, permitindo também aos routers a troca de informação sobre membros de grupos. Mas, para que uma aplicação possa aderir a um grupo, é necessário que ela mesma tenha informação sobre as sessões IP Multicast que se estejam a verificar em determinado momento, ou seja é necessário publicitar uma sessão.
Uma das formas de publicitar uma conferência em multicast, baseia-se na utilização de pacotes Session Announcement Protocol (SAP) que transportam dados SDP no respectivo payload, utilizando para tal o próprio multicast como meio de difusão dos anúncios. Para tal, a entidade que quer fazer o anúncio, denominada Directório de Sessão, envia periodicamente um pacote de anúncio para um determinado endereço multicast, indicando também o porto 9875 e um valor de TTL de 255. O endereço multicast do anúncio depende dos endereços IP que se estejam a utilizar para a sessão, que por sua vez dependem do alcance que se quer dar à sessão, podendo-se distinguir sessões locais de sessões globais. Assim, por exemplo, todos os anúncios, que publicitem conferências que utilizem o intervalo de variação de endereços multicast de 224.2.128.0 a 224.2.255.255, que correspondem a um alcance global na Internet, serão enviados para o endereço de multicast 224.2.127.524.
Os Directórios de Sessão são assim responsáveis por guardar a informação SDP de cada sessão, enviando-a periodicamente para os outros Directórios de Sessão. Para que um potencial participante de uma sessão possa conhecer as sessões que se estejam a verificar, basta que se registe como membro do grupo de SAP e esperar que lhe enviem a informação sobre as sessões multicast. Se posteriormente quiser receber informação de um grupo, terá que se registar nesse novo grupo.
O SAP é um protocolo que é baseado no formato de texto. Dado que os anúncios SAP são enviados em multicast, só podem ser encapsulados em pacotes UDP.
O SAP não só permite anunciar uma nova sessão, mas também permite anunciar o fim de uma sessão ou modificar os atributos de uma sessão.
A mensagem de anúncio de sessão, conterá obrigatoriamente uma descrição de sessão utilizando um determinado formato, que aqui consideraremos ser especificado pelo protocolo SDP, mas podendo ser especificado por outro protocolo para além deste.
Uma das aplicações mais conhecidas que utiliza o SAP é o programa sdr (Session
Directory Tool) que tal como o seu próprio autor caracteriza, funciona como um guia
de televisão que faz uma listagem das sessões disponíveis no MBone. Desta forma os utilizadores podem escolher aderir a uma determinada sessão, criar e publicitar uma sessão ou convidar um outro utilizador para participar numa sessão.
4 Session Description Protocol (SDP)
Os Directórios de Sessão são utilizados no MBone para publicitar conferências multimédia fornecendo aos possíveis participantes os endereços e parâmetros da mesma, o que temos designado de descrição de sessão. O Session Description
Protocol (SDP) é utilizado para a troca deste tipo de informação, não sendo um
protocolo de transporte, mas sim uma especificação do formato que deverá ter tal descrição. O SDP utiliza por isso os protocolo de transporte de informação SAP, SIP, RTSP, correio electrónico com extensão MIME e o HTTP.
O SDP utiliza-se por isso, para a troca de informação sobre streams de media de uma sessão multimédia, permitindo que os receptores de uma descrição possam participar nela. Uma sessão multimédia é definidas como um conjunto de streams que existem durante um determinado período de tempo.
Por isso, o SDP inclui:
o O nome da sessão e propósito
o Informação temporal sobre quando a sessão está activa. As sessões podem ser limitadas no tempo ou não. Por isso, o SDP pode fornecer:
- uma lista de intervalos de tempo de início e termino de sessões
- para cada intervalo de tempo é possível especificar as possíveis repetições que se venham a verificar. Por exemplo "todos os Sábados às 10am com a duração de uma hora".
o Os media que compreendem a sessão
o Informação para que se possa receber esses media: - Tipo de media (video, audio, etc)
- Protocolo de transporte (RTP/UDP/IP, H.320, etc) - Formato dos media (H.261 video, MPEG video, etc) - Endereço destino e portos dos media
Dados que os recursos necessários para participar numa sessão podem ser limitados, pode-se acrescentar informação adicional:
o Informação para que se possa contactar a pessoa responsável pela sessão
Em geral, o SDP deve fornecer informação suficiente para que um terminal possa aderir a uma sessão incluindo informação sobre os recursos disponibilizados.
4.1
Especificações SDP
O SDP é um protocolo que é baseado no formato de texto. Uma descrição de sessão em SDP é constituída por várias linhas de texto com um formato:
<tipo>=<valor>
O campo de <valor> pode conter uma série de sub-campos diferenciados por um caracter de espaço, ou uma string com um formato livre.
Uma descrição de sessão é constituída por uma descrição ao nível de sessão, com detalhes que se aplicam à totalidade da sessão e a todas as streams de media, seguida opcionalmente de várias descrições de cada um dos streams de media da mesma sessão. Assim, um anúncio SDP é constituído por uma descrição ao nível de sessão, seguido de zero ou mais descrições ao nível dos media da mesma sessão. A Figure 4 mostra a estrutura de um anúncio SDP.
Descrição ao nível de sessão, iniciada com: "v="
Descrição do 1º media, iniciado com: "m="
…
Descrição do nº media, iniciado com: "m="
Figure 4: Estrutura de um anúncio
Como se pode constatar, a descrição de sessão é iniciada com "v=" e cada uma das seguintes descrições de media começa por "m=". Depois de cada uma destas linhas iniciais aparecerão outras linhas, por uma ordem definida, que completarão a descrição.
Na tabela seguinte apresentamos as possíveis descrições, assinalando com * as que são opcionais: Descrição de Sessão v= o= s= i=* u=*
(Versão do protocolo, neste caso será 0)
(Origem -Identificação de quem criou a sessão e identificação da sessão) (Nome da sessão)
(Informação da sessão) (URI da sessão)
e=* p=* c=* b=*
(Endereço email do responsável pela conferência ) (número de telefone do responsável pela conferência )
(Informação de conexão - não necessária se especificada ao nível de media) (Informação de Largura de Banda)
Uma ou mais descrições temporais com os identificadores t=
r=*
(Intervalo de tempo em que a sessão estará activa) (Zero ou mais repetições temporais)
z=* k=* a=*
(Ajustes temporais dependentes da localização) (Chave de encriptação)
(Zero ou mais linhas de atributos de sessão)
Descrição de Media m= i=* c=* b=* k=* a=*
(nome do media e endereço de transporte) (título do media)
(Informação de conexão - não necessária se especificada ao nível de sessão) (Informação de Largura de Banda)
(Chave de encriptação)
(Zero ou mais linhas de atributos de media)
Em seguida dá-se um exemplo de uma descrição. v=0
o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4 s=SDP Seminar
i=A Seminar on the session description protocol u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps e=mjh@isi.edu (Mark Handley)
c=IN IP4 224.2.17.12/127 t=2873397496 2873404696 a=recvonly
Descrição de Sessão
m=audio 49170 RTP/AVP 0 Descrição de media áudio
m=video 51372 RTP/AVP 31 Descrição de media vídeo
m=application 32416 udp wb a=orient:portrait
Descrição de media aplicação
Para destacar melhor a descrição de sessão das descrições de cada um dos media, colocou-se o separador a tracejado.
Analisamos em seguida mais detalhadamente algumas das descrições.
Origem
O identificador de origem ("o=") contém vários campos separados por espaços, com a seguinte ordem:
o=<nome do utilizador> <id. da sessão> <versão> <tipo de rede> <tipo de endereço> <endereço>
O <nome de utilizador> deverá corresponder à login do mesmo.
A <id. da sessão> deverá identificar esta sessão de forma unívoca, sendo atribuído pela aplicação que a criar. É recomendada a utilização de um identificador temporal NTP para a distinguir de qualquer outra.
A <versão> deverá servir para distinguir e ordenar sucessivas descrições de uma mesma sessão. É recomendada também a utilização de um identificador temporal NTP.
O <tipo de rede> neste caso deverá indicar que se trata de uma rede Internet através do identificador "IN".
O <tipo de endereço> deverá indicar o tipo do endereço que se segue podendo assumir os valores "IP4" ou "IP6".
O <endereço> identificará o endereço IP da máquina de onde a sessão é gerada.
URI da sessão
O identificador de URI ("u=") deverá ser um apontador para o local onde se poderá encontrar informação adicional para a apresentação.
Informação de Conexão
A informação de conexão ("c=") contém vários campos separados por espaços, com a seguinte ordem:
c=<tipo de rede> <tipo de endereço> < endereço da conexão>
O significado destes campos é igual à anterior dada para Origem, mas agora informando quais os endereços destino dos dados. Em IP Multicast, o <endereço da
conexão> será por isso um endereço classe D, ao qual se seguirá o TTL do mesmo,
separado por um caracter "/", como é apresentado no exemplo anterior.
Informação de Media
A informação de media ("m=") contém vários campos separados por espaços, com a seguinte ordem:
c=<media> <porto> <transporte> <formato dos media>
O campo de <media> deverá identificar qual o tipo de media a que se refere: áudio ("audio"), vídeo ("video"), aplicação ("application"), dados ("data") ou controlo
("control"). A diferença entre aplicação e dados é que na primeira trata-se de transferencia de dados de media, como por exemplo um quadro em que dois utilizadores podem escrever, enquanto no segundo são dados que não serão apresentados ao utilizador.
O campo de <porto> identifica o porto do protocolo de transporte que se irá utilizar para este media.
O campo de <transporte> identifica o protocolo de transporte que se irá utilizar. Este campo será dependente do <tipo de endereço> especificado na Informação de
Conexão. Se se tratar de um endereço IP4, será de esperar que a maior parte dos
dados de media sejam transportados através do RTP sobre pacotes UDP. São usados os seguintes identificadores de transporte:
o RTP/AVP (ou RTP/AVP/UDP) - Identifica o protocolo RTP utilizando um perfil áudio ou vídeo sobre pacotes UDP.
o UDP - Identifica o protocolo UDP para transporte directo de dados.
o RTP/AVP/TCP;interleaved - Identifica o protocolo RTP utilizando um perfil áudio ou vídeo sobre pacotes TCP multiplexados na mesma conexão com as mensagens RTSP.
O campo de <formatos dos media> para o caso do áudio e do vídeo refere-se ao identificador de tipo de payload (PT) do protocolo RTP.
A título de exemplo se se utilizar um único canal de áudio com uma codificação PCM lei-? amostrado a 8kHz, o valo de PT deverá ser de 0 (zero). Por isso, e para um porto UDP de 49170, a informação de media enviada será:
m=audio 49170 RTP/AVP 0
No caso de se utilizar um canal de vídeo com uma codificação H.261 amostrado a 90kHz, o valo de PT deverá ser de 31. Por isso, e para um porto UDP de 51372, a informação de media enviada será:
m=video 51372 RTP/AVP 31
5 Arquitecturas de distribuição
O IP multicast é uma possível solução para distribuição multimédia, tendo como principais vantagens a sua escalabilidade, tendo como inconveniente principal o de ainda não ser disponibilizado pela maioria dos operadores e não permitir uma gestão eficiente, nomeadamente para permitir a implementação de mecanismos de controlo de acesso e de pagamento de conteúdos.
O grupo “Content Distribution Internetworking (CDI)” do IETF definiu em [12] modelos de arquitetura de distribuição de streams multimedia em larga escala sobre redes IP.
À medida que crescem o número de fontes de stream e de utilizadores, aumentam igualmente os requisitos de escalabilidade dos servidores de media, o que obriga a definir arquitecturas mais complexas de distribuição. Uma primeira solução consiste em substituir o servidor único por um grupo de servidores interligados (server farm), mas esta solução não resolve o problema da congestão no acesso aos servidores. Uma solução para este problema pode ser baseada numa arquitectura que transfere os conteúdos para servidores intermédios colocados tão próximos quanto possível dos utilizadores, na periferia da rede (rede de acesso).
No projecto Olympic [13] foi adoptada uma arquitectura de distribuição deste tipo, com base em servidores de acesso (SAS – Streaming Access Server), como se mostra na Figure 5. IP Distribution Network SAS Access Network A SASa Client Client Client SASb Client Client Client Access Network B Media Server ISP Web Server
Figure 5: Arquitectura de distribuição multimédia do projecto Olympic
Os streams provenientes dos Media Servers são distribuídos para os clientes que os pedem, através de estruturas em árvore, em que existe um SAS em cada nó da árvore. Na figura 6 apresenta-se um exemplo do estabelecimento de uma sessão RTSP entre um cliente, um Servidor de Media usando um Servidor intermédio. Na referida figura s1 é o ficheiro SDP que contém a descrição da sessão.
Client 1
RTSP Describe rtsp://olympic.isp.pt/s1 RTSP/1.0
Media Server rtsp://main.olympic.gr
Streaming Access Server rtsp://olympic.isp.pt RTSP/1.0 200 OK (SDP Description A’ ) RTSP DESCRIBE rtsp://main.olympic.gr/s1RTSP/1.0 RTSP/1.0 200 OK (SDP Description A) RTSP SETUP rtsp://olympic.isp.pt/s1RTSP/1.0 RTSP SETUP rtsp://main.olympic.gr/s1RTSP/1.0 RTSP/1.0 200 OK RTSP/1.0 200 OK RTSP PLAY rtsp://olympic.isp.pt/s1RTSP/1.0 RTSP PLAY rtsp://main.olympic.pt/s1RTSP/1.0
RTP Payload Type=MPEG Video
RTSP/1.0 200 OK
RTP Payload Type=MPEG Video
RTSP/1.0 200 OK
RTP Payload Type=MPEG Audio RTP Payload Type=MPEG Audio
TCP
UDP
Na Figure 7 apresenta-se um exemplo do estabelecimento de uma segunda sessão do mesmo stream usando igualmente um Servidor intermédio que funciona como servidor multicast ao nível de aplicação.
RTSP Describe rtsp://olympic.isp.pt/s1 Media Server rtsp://main.olympic.gr RTSP/1.0 200 OK (SDP Description A’ ) RTSP SETUP rtsp://olympic.isp.pt/s1 RTSP/1.0 200 OK RTSP PLAY rtsp://olympic.isp.pt/s1
RTP Payload Type=MPEG Video RTP Payload Type=MPEG Video
RTSP/1.0 200 OK
RTP Payload Type=MPEG Audio RTP Payload Type=MPEG Audio RTP Payload Type=MPEG Video1
RTP Payload Type=MPEG Audio
Client 2 Streaming Access Server
rtsp://olympic.isp.pt
Figure 7: Exemplo de sessão RTSP usando um servidor intermédio
Como se verifica na figura, como o servidor intermédio já está a receber o stream do servidor principal, não necessita de estabelecer mais nenhuma sessão com este, o mesmo acontecendo com novos clientes para o mesmo stream. Isto significa que o SAS funciona como servidor multicast de nível aplicação, com as vantagens inerentes em termos de eficiência de largura de banda e de escalabilidade.
6 Bibliografia
[1] H. Schulzrinne et al, "RTP: A Transport Protocol for Real-Time Applications" , RFC1889, Internet Engineering Task Force, January 1996.
[2] H. Schulzrinne, " RTP profile for Audio and Video Conferences with Minimal
Control" , RFC1890, Internet Engineering Task Force, January 1996.
[3] S. Wenger, "RTCP-based feedback: Concepts and Message Timing Rules" , work- in-progress, Internet-Draft "draft-wenger-avt-rtcp- feedback-01.txt", Internet Engineering Task Force, June 2001.
[4] R. Fielding, J. Gettys, J. Mogul, H. Nielsen, T. Berners-Lee, "Hypertext transfer
protocol - HTTP/1.1", RFC2068, Internet Engineering Task Force, January
1997.
[5] Microsoft Media home page, http://www.microsoft.com/windows/
windowsmedia
[6] Realnetworks home page, http://www.realnetworks.com/
[8] H. Schulzrinne, A. Rao, R. Lanphier, "Real Time Streaming Protocol (RTSP)" , RFC2326, Internet Engineering Task Force, April 1998.
[9] M. Handley, C. Perkins, E. Whelan, "Session Announcement Protocol", RFC2974, Internet Engineering Task Force, October 2000.
[10] M. Handley and V. Jacobson, "SDP: Session Description Protocol" , RFC2327, Internet Engineering Task Force, April 1999.
[11] M. Handley, "The session directory tool SDR",
http://www.mice.ed.ac.uk/mice/archive/sdr.html
[12] RFC 3466, “A Model for Content Internetworking (CDI)”, February 2003. [13] Olympics Multimedia Personalized for the Internet Community,
