Você está na página 1de 16

PROTOCOLOS PARA APLICAES MULTIMDIA

ABSTRACT The last few years have witnessed an explosive growth in the development and deployment of networks applications that transmit and receive audio and video over the Internet. New multimedia networking applications (continuous media applications) seem to be announced daily. The service requeriments of these applications vary from the elastic applications, being much more sensitive to delays and less to data loss. This work shows a little of some multimedia protocols such as RTP, RTCP, RTSP and the new RSP and some other tools that try to make the internet best effort less perceptible as possible.

RESUMO
Os ltimos anos apresentaram um crescimento explosivo na criao e no desenvolvimento de aplicaes em rede que enviam e recebem udio e vdeo pela internet. Novas aplicaes multimdia distribudas parecem nascer todo dia. Os requerimentos dos servios para essas aplicaes diferem significativamente daqueles para aplicaes elsticas como web, e- mail, login remoto, etc: as aplicaes multimdia so altamente sensveis aos retardos na rede e menos sensveis perda de pacotes. Neste trabalho, veremos como aplicaes multimdias podem ser desenhadas para tirar bom proveito do melhor esforo da internet. Conheceremos alguns protocolos utilizados no streaming multimdia e suas caractersticas.

AUTORES Roberto Schemid Abo-Gamem da Cunha, Rafael Esteves Mansano.

1 APLICAES MULTIMDIA DISTRIBUDAS Existem dois pontos destacados no estudo de requerimento de servios: consideraes sobre o tempo e tolerncia perda de dados. Tempo importante porque veremos que muitas aplicaes so extremamente sensveis ao atraso e um pequeno atraso na chegada de um pacote pode acarretar inutilidade a todo o processo j feito. Por outro lado, este tipo de aplicao mais tolerante perda de dados do que os servios elsticos. Uma perda pode ser facilmente aliviada ou at anulada, por certos mecanismos da aplicao.

1.1 Exemplos de aplicaes multimdia Streaming udio e Vdeos armazenados Nesta classe de aplicaes, um cliente solicita sob demanda udio ou vdeo comprimido que esto armazenados em um servidor. A, h trs pontos distintos: a.) Mdia armazenada. O contedo foi gravado e armazenado. Assim o cliente pode ver, ouvir, pausar, avanar e retroceder a mdia para o ponto que ele quiser. b.) Streaming. O cliente recebe o udio/vdeo em segundos apes ele requisitar. Isto significa que enquanto ele recebe o arquivo, ele j pode ver o contedo, evitando que o arquivo tenha que ser baixado completamente para comear sua execuo. c.) Reproduo contnua. Uma vez que o playout comea, ele deve ocorrer de acordo com o tempo original de gravao. O dado deve chegar ao destino a tempo de ser vista corretamente pelo cliente Streaming udio e Video ao vivo Esta classe similar a transmisso por tv ou rdio, exceto pelo fato de a transmisso ser feita pela internet. Permite ao usurio receber uma transmisso ao vivo de udio ou vdeo. Como o contedo no armazenado, o cliente no pode pausar, retroceder a exibio. Isso s seria possvel com algum tipo de armazenamento da transmisso. Neste tipo de aplicao, h vrios clientes recebendo o mesmo contedo simultaneamente. O distribuidor deve estar bem preparado com estrutura de ip multicasting. Atrasos grandes neste caso, so bem desagradveis e no h como reverter isso, a menos de um armazenamento do streaming. udio e Vdeo em Tempo Real Interativo. Esta classe permite ao usurio se comunicar um com os outros em tempo real. udio interativo sobre internet chamado de Internet Phone. Vdeo conferncia um exemplo para udio e vdeo. Delays de mais de 400 milissegundos resultam em frustrantes e at incompreensveis conversaes.

2 OBSTCULOS PARA MULTIMDIA NA INTERNET DE HOJE

O protocolo IP utilizado na internet hoje prov o servio de melhor esforo para todos os seus datagramas. Em outras palavras, a internet faz o possvel para que tudo corra bem, mas no d nenhuma garantia de que isto vai realmente acontecer, principalmente quanto aos delays dos seus pacotes. Como TCP e UDP rodam sobre o IP, nenhum dos dois pode garantir o tempo que um pacote levar at chegar ao seu destino. Devido falta de um esforo especial para esse aspecto, torna-se um grande desafio resolver este problema para aplicaes multimdia na internet. Principalmente durante os horrios de pico na internet, quando o volume de trfego maior, a importncia de se resolver este caso mostra-se mais urgente. chamado de packet jitter a variao dos delays de um pacote dentro de um mesmo stream de pacotes. Exemplo: num stream packet so mandados 10 pacotes. Pode ocorrer de 8 chegarem no determinado tempo e os outros dois no terem chegado a tempo. As causas podem ser as filas nos roteadores ou congestionamento em algum ponto da rede, por algum motivo. Tenta-se evitar o jitter packet nas aplicaes multimdias. Para tratar o jitter packet, poderiam ser atribudas prioridades a certos pacotes e faz-los ter preferncia nos roteadores. H prs e contras nessa implementao. Mas atualmente na internet, todos os pacotes so tratados iguais.

3 COMO A INTERNET DEVERIA SE DESENVOLVER PARA SUPORTAR MELHOR A MULTIMDIA Os debates sobre a forma de evoluo da Internet para que ela possa suportar aplicaes multimdia so cada vez mais freqentes. Existem duas correntes de pensamentos sobre isso atualmente. Na primeira, alguns pesquisadores acreditam que a melhor maneira fazer mudanas substanciais na rede para que os aplicativos possam alocar explicitamente bandwidth de um extremo ao outro da conexo. Por exemplo: se o ponto A deseja fazer uma chamada telefnica atravs da Internet at o ponto B, ento o aplicativo deveria reservar bandwidth por todo o caminho de A at B. Mas para isso seria necessrio um protocolo que reservasse bandwidth de um ponto ao outro, mudar a poltica de chamadas de espera nos roteadores (quem pagasse mais receberia um tratamento melhor) e descrever o trfego que se pretende utilizar. Com isso, a rede poderia selecionar aquelas reservas que certamente conseguir realizar. RSVP um protocolo que faz tais reservas. A segunda corrente contrria a primeira e acredita que uma poltica de laissez-faire seja a soluo. Com o aumento da demanda, os ISPs fariam um balanceamento de sua rede para melhor atender seus usurios. Seriam utilizados CDNs (redes de distribuio de contedo) nas extremidades da internet, evitando assim um aumento do fluxo no meio dela. Cria r sub-redes para trfego exclusivo de transmisses ao vivo, fazendo rvores de transmisso o trfego ficaria melhor organizado e menos pesado no ponto de partida da transmisso. Existe ainda uma corrente de pesquisadores que apiam as duas anteriores e sugerem a criao de duas classificaes de trfego para que o usurio pague pelo tipo que ele usa.

4 COMPRESSO UDIO E VDEO Antes de um udio ou vdeo ser transmitido por uma rede, ele deve ser comprimido. Essa necessidade bvia: reduzir o nmero de bits transitando a fim de garantir sempre banda suficiente para todas as aplicaes. H vrios tipos de compresso existentes hoje e cada um com sua finalidade e caracterstica. Para udio, PCM, MP3 e GSM so expoentes. Para vdeo, MPEG-1 e 2 e H-261 destacam-se. Est por vir MPEG verso 4, tanto para udio e vdeo.

5 O STREAMING MULTIMDIA Nos ltimos anos, o streaming de udio e vdeo se tornou uma aplicao mais popular e um grande consumidor de banda. Esta tendncia est para continuar devido a diversas razes: custo dos dispositivos de armazenamento tem diminudo, a popularizao da banda larga domstica tem crescido gradativamente, novas tcnicas de distribuio de contedo tm tambm se desenvolvido, etc. Num streaming multimdia, um cliente solicita uma mdia e o servidor atende sua requisio. Este servidor pode ser um servidor normal, como os usados para internet, bem como pode ser servidor especial para streaming. A mdia chega ao cliente por meio de sockets, tanto por UDP quanto por TCP. Antes de ser enviado, a mdia segmentada e cada segmento encapsulado com cabealhos prprios. O RTP um protocolo pblico usado para tal fim. Para desfrutar do contedo da mdia, preciso de programas que interpretam a mdia e expem-na. Tais programas so denominados media players. Estes programas descomprimem a mdia (que em geral vir comprimida), fazem a remoo de jitter e tambm uma correo de erros, a fim de proporcionar um a reproduo boa. Muitos media players j esto acoplados aos browsers.

5.1 Acessando udio e Vdeo por um Servidor udio e vdeo podem estar armazenados em servidores que os entregam ao cliente tanto por HTTP quanto por no HTTP . Suponha um caso de streaming par udio: se ele est armazenado num servidor web normal, ele enviar para o cliente atravs de uma resposta HTTP, numa conexo TCP. No caso do vdeo, muitas vezes udio e vdeo esto armazenados separadamente e por isso, ser necessrio uma conexo TCP e uma resposta HTTP para cada um. O media player tambm pode interagir com o servidor, analogamente a um browser. Entretanto, HTTP no considerado um protocolo muito bom para tal situao. considerado insuficiente para isso, pois no permite avano, retrocesso, pausa facilmente durante a execuo da mdia. Para ficar livre do uso do protocolo HTTP, possvel fazer o streaming diretamente com o media player, usando uma conexo UDP. Neste caso, o servidor pode ser um especial para assuntos multimdia, diferentemente dos comuns para web.

6 PROTOCOLOS PARA APLICAES MULTIMDIA

6.1 RTP (RFC 1889) Pode ser usado para encapsular inmeros formatos populares (GSM, MPEG, PCM, H263, etc). H vrias implementaes para ele, hoje em dia, pelo mundo em vrias aplicaes. tambm complementar em importantes outros protocolos interativos para aplicaes em tempo real, como SIP e H.323. O servidor web encapsula o arquivo numa resposta HTTP e manda a mensagem para o browser. Quando o browser recebe esta resposta, ele chama o media player, de acordo com o content type no cabealho da mensagem. A, o cliente e o servidor trocam mensagens RTSP, do tipo setup request, mensagens OK, play/pause request, etc. Tambm possvel escolher por exemplo entre uma mdia de maior ou menor qualidade, de acordo com o interesse ou banda disponvel. O RTP roda basicamente em UDP. O lado servidor encapsula um pedao da mdia num pacote RTP, depois esse pacote encapsulado num segmento UDP e ento entregue ao IP. O lado cliente extrai do UDP o pacote RTP, de onde extrai o pedao da mdia passa para o media player. Se uma aplicao usa RTP em vez de outro esquema proprietrio para prover payload time, timestamps ou nmeros seqenciais, a aplicao vai facilmente interoperar com outras aplicaes multimdia. O RTP no prov mecanismos para certificar de que o dado chegar dentro da data prevista ou outra qualidade de servio. Nem garante a ordem da chegada dos dados e nem mesmo a entrega deles. E tambm, o encapsulamento RTP somente visto nos end-systems. Os roteadores no o distinguem: no tm como saber se um datagrama IP contm ou no um encapsulamento RTP. Os pacotes RTP funcionam tanto para unicast como para multicast (um para um, um para muitos e muitos para muitos). 6.1.1 RTP Packet Fields

Figura 1: campos de um pacote RTP.

Os campos apresentados abreviadamente so:


?? ??

V: verso. A verso 2 significa a especificada na RFC, sendo a 1, no draft. P: (padding) preenchimento. Sinaliza a adio de bits no contedo, somente para uso de algoritmos de criptografia ou transmisses de pequenos contedos. O ltimo octeto no campo de contedo (payload) indica quantos octetos de preenchimento foram inseridos.

??

X: extenso. Aumenta o tamanho do cabealho normal para um extendido com maiores informaes. ?? CC: contador CSRC. Apresenta o nmeros de identificadores CSRC apresentados neste campo. ?? M: marcador. Usado geralmente para identificar os limites de um quadro. ?? PT: tipo de contedo. Caso o flag X tenha sido sinalizado, o cabealho inclui uma extenso conforme apresentado na figura abaixo:

Figura 2: parte do cabealho RTP, para o caso de flag X sinalizado

O protocolo RTP, por no ser orientado conexo, no monitora a transmisso e a recepo dos pacotes. Esta tarefa realizada por outro protocolo, RTCP, apresentado a seguir.

6.1.2 Desenvolvendo aplicaes com RTP H duas abordagens: 1.) incorporar o cdigo RTP que encapsula e desencapsula (nos lados cliente e servidor) mo; 2.) usar bibliotecas disponveis, como as para C e Java.

Aplicao RTP Socket UDP IP Enlace Fsico


Figura 3: exemplifica abordagem (1)

Aplicao

transporte

RTP UDP IP Enlace Fsico

Figura 4: exemplifica abordagem (2)

6.2 RTCP (Real Time Control Protocol) (RFC 1889) O RFC 1889 tambm especifica o RTCP, um protocolo que uma aplicao multimdia distribuda pode usar em conjunto como RTP. Os pacotes RTP e RTCP so distinguidos um do outro pelo uso de diferentes nmeros de portas. O nmero da porta do RTCP o nmero de porta do RTP + 1. Os pacotes RTCP no encapsulam nada. Eles so enviados periodicamente por ambos os lados e contm informaes estatsticas que podem ser teis s aplicaes. Estas informaes so: nmero de pacotes enviados, nmeros de pacotes perdidos e jitter, por exemplo. O RTP no especifica o que a aplicao deve fazer com esses dados, ficando isso por conta do programador da aplicao. O transmissor pode usar estas informaes para modificar sua taxa de transmisso enquanto o receptor pode determinar se um determinado problema de ordem local, regional ou global.

6.2.1 Tipos de pacotes do RTCP Para cada stream RTP que o receptor recebe, ele gera um reporte, que agregado a um pacote RTP. Para controlar a transmisso, o RTCP envia os seguintes tipos de pacotes:
?? ?? ?? ?? ??

SR: relatrio do emissor. Para estatsticas de transmisso e recepo sobre os participantes da sesso que so emissores ativos. RR: relatrio do receptor. Para estatsticas de transmisso e recepo sobre os participantes da sesso que no so emissores ativos. SDES: tens de descrio da fonte. Inclui o campo CNAME. BYE: finalizao da participao da sesso. APP: funes especficas de aplicao.

Um exemplo do pacote com relatrio do emissor apresentado abaixo.

Figura 5: um pacote RTCP.

O campo RC refere-se ao "contador de relatrio de recepo", que indica a quantidade de blocos de relatrios contidos no pacote. Abaixo so apresentadas tabelas com os campos do RTCP e seus significados. abreviao nome SR RR SDES BYE APP END CNAME NAME EMAIL PHONE LOC TOOL NOTE PRIV relatrio do emissor relatrio do receptor descrio da fonte adeus definido pela aplicao fim da lista SDES nome cannico nome do usurio endereo eletrnico do usurio telefone do usurio localizao geogrfica do usurio nome da aplicao ou da ferramenta notcias sobre a fonte extenses privadas valor 200 201 202 203 204 0 1 2 3 4 5 6 7 8

Figura 6: alguns campos do cabealho do protocolo RTCP

6.3 RTSP - Real Time Streamming Protocol (RFC 2326) O RTSP, Protocolo de Fluxo (transmisso) em Tempo Real, um protocolo mais robusto para comunicao multimdia e controle de sesses em relao aos apresentados anteriormente. Seu funcionamento baseado em streamming (transmisso) que segmenta os dados em v rios pacotes onde o tamanho depende da banda disponvel entre cliente e servidor, parmetro avaliado atravs do parmetro MTU, unidade mxima de transferncia, da rede. A aplicao recebe estes pacotes e recompe os dados antes de descomprimir e utilizar a informao inicial. Isto permite que fluxo seja ao vivo ou de dados armazenados. O RTSP considerado mais prximo um datagrama devido a esta caracterstica de remontagem. A seleo dos canais de envio (UDP, TCP, IP Multicast) e de mecanismos de transmisso baseado em RTP, tanto para controlar como para garantir a entrega do contedo em tempo real. O RTSP tambm Utilizado com RSVP para solicitar e garantir banda para sesses. Este protocolo permite ao usurio controlar (pausar, avanar, retroceder) a exibio da mdia. Deve estar presente tanto no cliente como no servidor.

Entretanto o RTSP: - no define esquemas de compresso para udio ou vdeo; - no define como a mdia encapsulada nem os cabealhos. Isto tarefa do RTP; - no restringe como o pacote deve ser transmitido (entre UDP ou TCP); - no restringe como o media player armazenar (em buffers) o arquivo; Este um protocolo out of band, ou seja, suas mensagens so transmitidas em banda diferente do contedo (a prpria mdia), usando a porta 544. Suas mensagens podem ser transmitidas por TCP ou UDP. FTP usa tambm este esquema de out of band. O RTSP tambm tem a capacidade de permitir ao cliente operaes de gravao no servidor: stream em direo ao servidor. Este protocolo adotado pela Real Networks.

6.4 SDP - Session Description Protocol (RFC 2327) O SDP, Protocolo de Descrio de Sesso utilizado para descrio de uma sesso multimdia (inicializao, convite, anncio, etc). Ele no tem mecanismo de transporte prprio, mas adaptado para utilizar o de outros protocolos mais apropriados como:
?? ?? ?? ?? ??

SAP (Protocolo de Anncio de Sesso) SIP (Protocolo de Iniciao de Sesso) RTSP SMTP com extenses MIME HTTP, etc

As informaes contidas no SDP incluem:


?? ?? ?? ?? ?? ??

o tipo da mdia (udio, vdeo, etc) o protocolo de transporte (UDP-RTP/IP, H.320, etc) o formato da mdia (H.261 vdeo, MPEG vdeo, etc) endereo de destino porta de recepo no destino URIs (Identificadores Universais de Recursos) com informaes sobre a sesso

A descrio da sesso enviada pelo SDP contm os seguintes campos:


?? ?? ?? ?? ?? ?? ?? ??

v = (verso do protocolo) o = (dono/criador e identificador da sesso) s = (nome da sesso) i = (informao da sesso) u = (URI da descrio) e = (endereo email) p = (nmero do telefone) c = (informao da conexo)

??

b = (informao da largura de banda)

Uma ou mais descries de tempo:


?? ?? ??

z = (ajuste da zona de tempo) k = (chave criptogrfica) a = (linhas de atributo da sesso)

Descrio especfica do tempo:


?? ??

t = (tempo em que a sesso est ativa) r = (tempo de repetio)

Descrio da mdia:
?? ?? ?? ?? ?? ??

m = (noma da mdia e endereo de transporte) i = (ttulo da mdia) c = (informao da conexo) b = (informao da largura de banda) k = (chave criptogrfica) a = (linhas de atributo da mdia)

6.5 ST-II - Internet Stream Protocol, verso 2 O ST-II, Protocolo de Fluxo (transmisso) Internet - verso 2, foi criado para substituir o IP. Devido a esta proposta, foi comumente designado de IPv5 (IP verso 5). O ST-II funciona trocando informaes com os roteadores por onde passa. Entre esta informaes, ele recebe dados importantes sobre as condies da rede como:
?? ??

caractersticas de performance alocao de recursos

O ST-II tem suporte a servios como ftp com TCP (porta 21) para garantir uma maior robustez na entrega dos dados. Alm disto, o ST-II tem suporte a outros protocolos de transporte como:
?? ?? ?? ??

PVP (Protocolo de Vdeo em Pacote) NVP (Protocolo de Voz em Rede) TCP VMTP (Protocolo Verstil de Transao de Mensagem), entre outros

Os pacotes ST-II podem ser encapsulados em IP para dar conectividade e/ou segurana aos dados. Isto permite uma interoperabilidade com o sistemas anteriores baseados em IPv4, principalmente por parte dos roteadores. O ST-II contm uma camada superior destinada ao controle: o SCMP - ST Control Message Protocol, Protocolo de Mensagem de Controle ST - e este parte integrante

do ST-II. O SCMP suporta o re-roteamento do fluxo, em caso de falha de algum roteador, sem a perda da conexo. Abaixo so apresentadas algumas das mensagens do ST-II: Nome Valor Significado AcceptTimeout 2 Um accept no foi reconhecido. AccessDenied 3 AckUnexpected 4 ApplAbort 5 ApplDisconnect 6 AuthentFailed 7 CantGetResrc CantRelResrc CksumBadCtl 8 9 10 Acesso negado Um ACK (reconhecimento) inesperado foi recebido. A aplicao abortou a conexo anormalmente. A aplicao fechou a conexo normalmente. A funo de autenticao falhou. Incapaz de adquirir fontes (adicionais). Incapaz de alocar recursos (em caso de excesso). Um controle de recepo PDU tem uma mensagem com checksum errado.

Figura 7: algumas mensagens do protocolo ST- II e seus significados.

6.6 Protocolo SIP Uma das idias para melhorar os servios de multimdia na Internet o protocolo SIP. Ele foi criado para conectar duas (ou mais) pessoas com transmisso de vdeo e udio de maneira que os aplicativos fossem executados em qualquer aparelho com um endereo IP na Internet (podendo ser um celular, um palm- top, computador, etc...) e o prprio protocolo prov mecanismos para se descobrir qual o IP do aparelho que os usurios esto usando no momento. Para estabelecer uma conexo SIP o aplicativo envia uma mensagem de convite (que se assemelha com uma mensagem de pedido de HTTP) utilizando pacotes UDP ou TCP. Nessa mensagem inicial estar anexado o endereo do outro aplicativo (do usurio a ser contatado), o IP do usurio que est contatando, os codecs de udio e vdeo que ele deseja que o contatado utilize e a porta para qual devem ser enviados os pacotes UDP ou TCP. O segundo usurio ento responde com uma mensagem de 200 OK (que se assemelha com uma mensagem de resposta de HTTP) informando que ele aceitou o convite e de forma anloga indica suas preferncias de quais os codecs de udio e vdeo e a porta para a qual esses devem ser enviados. Aps essas trocas iniciais de informaes, a conexo estabelecida. No entanto, o segundo usurio pode no possuir os codecs que o primeiro requisitou, se isso ocorrer ele enviar uma mensagem de 600 Not Acceptable informando que ele no possui os tais codecs e enviar tambm uma lista de codecs que ele possui para que o primeiro usurio possa escolher qual utilizar e refazer o convite. Vale destacar algumas caractersticas do SIP: suas mensagens no utilizam os sockets utilizados na transferncia de multimdia, as mensagens utilizam ASCII e todas

elas devem ter seu recebimento confirmado (ACK) para que seja possvel utilizar UDP ou TCP.

6.7 H.323 Uma alternativa ao SIP o H.323. Ele um padro popular para conferencia em tempo real entre end-systems na Internet. Este padro tambm cobre como end-systems na Internet se comunicam com telefones conectados a redes de comutao por circuito convencionais. O H.323 inclui as seguintes especificaes: especificao para como os endpoints negociam codificaes para udio/vdeo comuns. Como ele suporta uma variedade de codificaes padro, um protocolo necessrio para um consenso num determinado padro num momento. especificao para como os pedaos de udio/vdeo so encapsulados e mandados rede. Particularmente, H.323 escolhe o RTP para este fim. especificao sobre como os endpoints se comunicam com seus respectivos gatekeepers. especificao sobre como os telefones na Internet se comunicam com os telefones nas redes de comutao por circuito. Cada endpoint H.323 deve suportar G.711, mas o suporte a vdeo opcional. Se suportar o vdeo, o mnimo requerido o QCIF H.261.

H.323 versus SIP H.323 uma sute de protocolos completa e verticalmente integralizada para conferencia multimdia; SIP, por outro lado, controla inicio e gerncia de sesses, sendo um componente simples. H.323 vem do ITU enquanto SIP vem de IETF e pega emprestado muitos conceitos da internet. H.323, sendo um protocolo guarda-chuva, grande e complexo, enquanto SIP bem simples.

6.8 RSVP Um tipo diferente de algoritmo que pode ser utilizado para controlar fatores relacionados a multimdia o Protocolo de Reservas (Reservation Protocol RSVP). Ao invs de tentar identificar certos tipos de fluxos assim que eles entram na fila, RSVP explicitamente aloca bandas para cada fluxo especfico. Aplicaes podem requisitar a quantidade de banda prevista para ser usada por elas. O roteador pode, ento, gerenciar a quantidade de banda disponvel e a que cada aplicao precisa. Para ser implementado, deve haver uma parte RSVP em clientes, servidores e roteadores. Ele prov as reservas de banda em rvores multicast e orientado ao receptor (o receptor quem inicia e mantm a reserva de recursos para um fluxo).

Entretanto, ele no especifica como a rede prover a reserva. Tambm no age como um protocolo que roteador. Este protocolo usado para garantir a QoS (qualidade de servio) em vrias aplicaes numa rede.

6.9 SRP (Selective Retransmission Protocol) SRP, Selective Retransmission Protocol um protocolo desenhado para melhorar a performance de aplicaes multimdia. Ele tenta balancear as altas perdas com o UDP e a latncia do TCP. SRP usa um algoritmo de deciso para determinar se ser pedida ou no a retransmisso de um pacote perdido aplicao. SRP um protocolo no nvel de aplicao que usa UDP para transmitir mensagens. Consiste de um servidor que manda um stream multimdia em uma srie de datagramas numa taxa constante e num cliente que os recebe. Uma aplicao remetente e uma aplicao receptora controlam o SRP cliente e servidor via funes de interface. A remetente passa dados para o servidor SRP e o receptor continuamente chama o RSP cliente pedindo mais dados. A qualquer momento que o cliente detecta que um frame foi perdido, ele toma uma deciso de pedir ou no a retransmisso da mensagem. Esta deciso tomada por um algoritmo que leva em considerao o quanto de perda e latncia pode haver para aquela aplicao e o quanto desses problemas esto ocorrendo. Se a deciso de retransimitir, uma requisio pela retranmisso feita para o servidor e o cliente espera pela resposta. Caso esta resposta no chegue dentro do tempo esperado, o pedido novamente refeito. Se a deciso for no retransmitir, o cliente desiste daquela mensagem particular e retrata o erro para a aplicao. Quaisquer mensagens recebidas pela aplicao enquanto espera pela retransmisso so armazenadas num buffer e utilizadas na hora apropriada. As retransmisses so esperadas para chegarem em um round trip time.

6.9.1 Por que UDP? SRP opera sobre UDP e oferece funcionalidades adicionais ao protocolo. A aceitao do SRP fcil uma vez que suas mensagens so essencialmente as mesmas do UDP. A razo mais importante para UDP ter sido escolhido no lugar do TCP que UDP no implementa retransmisses. J que TCP tem seu sistema de retransmisso, ele teria que ser substitudo, enquanto ao UDP, sem retransmisses, s seriam adicionadas essas funcionalidades.

6.9.2 SRP Packet SRP usa data packet, nack packet e prob packet para transmitir dados na rede. O pacote de dados (data packet) tem um tamanho mximo de 1496. A informao no cabealho padro de 16 bytes e o resto reservado para os dados. Nack packet tem tambm tamanho de 16 bytes e o probe packet possui 8 bytes.

type

time info data

data id

data size

data

Figura 8: data packet do SRP

type

time info

status

data id

no usado em pacotes nack SRP

Figura 9: nack packet do SRP

type

time info

no usado em pacotes probe SRP

Figura 10: probe packet do SRP

7.0 ALM DO MELHOR ESFORO Sabemos que H323, RTP, timestamps, etc no so suficientes para dar s aplicaes multimdias um suporte confivel e robusto. Por ex: telefonia IP tem a mesma qualidade da telefonia convencional? No: na telefonia convencional no h atrasos em pacotes nem jitters. Hoje, a internet trabalha com o melhor esforo para realizar o que deve ser realizado. Uma aplicao ter uma performance de acordo com o que a rede poder oferecer. As aplicaes multimdia so bastante sensveis aos delays e a principio no h distino entre os pacotes que circulam. Veremos aqui novos componentes arquiteturais que podem ser adicionados estrutura da internet a fim de melhorar os servios multimdia: 1) A marcao e a classificao de pacotes permitiriam um roteador distinguir um pacote dentre vrios diferentes. 2) desejvel determinar um grau de isolamento entre os fluxos para que um fluxo no seja adversariamente afetado por um outro mal comportado.

3) Enquanto provendo isolamento entre os fluxos desejvel tambm que se use os recursos (banda do link, buffers, etc...) da maneira mais eficiente possvel. 4) Um fluxo declararia seus requerimentos, a a rede diria se aceita esse fluxo ou no de acordo com seu requerimento. A esse processo chamamos de call admission. Logo, a call admission seria necessria. Estes acima so princpios bsicos para garantir uma qualidade de servio (QoS) para as aplicaes multimdia. Suas implementaes so feitas de acordo com algoritmos de escalonamento (FIFO, fila de prioridades, round robin, etc...).

8 REFERNCIAS
??

Kurose, James F. and Ross, Ketith W. Computer Networking A Top-Down Approach Featuring the Internet, second edition. http://www.lcmi.ufsc.br/redes/redes99/helio/protocolos_multimidia/

??

??

http://www.cs.wpi.edu/~claypool/mqp/srp/report.pdf