Você está na página 1de 23

RTP

REAL-TIME TRANSPORT PROTOCOL

Comunicao de Dados
Informtica Industrial PL Ano Lectivo 2010/11 2 Ano 1 Semestre Docente: Daniel Silva Alunos: Miguel Cruz n. 5349 Rogrio Meireles n. 5350

Protocolo RTP
Real-Time Transport Protocol

NDICE

Resumo Introduo Funcionamento RTP Emissor/Receptor Transferncia de Pacotes Benefcios nas Comunicaes IP Especificao RTP Sesso RTP Cabealho RTP Segurana Aplicao Concluso Bibliografia

3 4 5 8 9 11 12 13 20 21 22 23

Comunicao de Dados 2010/11 Alunos: Miguel Cruz 5349 e Rogrio Meireles - 5350

Pgina 2

Protocolo RTP
Real-Time Transport Protocol

RESUMO
Este trabalho tem como finalidade mostrar o funcionamento do protocolo RTP e os complementos deste, para que seja possvel a transferncia de contedo multimdia sobre redes IP. Alguns exemplos de servios que fazem uso deste protocolo so: os servios de voz sobre IP (VOIP); as teleconferncias; o vdeo streaming; as aplicaes WebCasting. Como entregar contedo multimdia numa rede IP de forma confivel; Manter a qualidade do servio face a problemas de rede; A segurana do sistema tambm est assegurada. Estes so temas abordados ao longo deste trabalho. Vrios codecs de mdia esto projectados para serem usados em transmisso em tempo real (RTP), tais como, MPEG e GSM. Os sistemas que usam RTP usam protocolos de controlo, como por exemplo o incio de sesso. No entanto focmo-nos no transporte de mdia, deixando de parte a sinalizao. A reserva de recursos no necessria para o correcto funcionamento do RTP, no entanto, mostra-se vantajoso noutras situaes. Um sistema que use o RTP, vai usar diversos codecs de mdia e aplicar protocolos de controlo. A forma como isso se processa depende da aplicao, pois diferentes sistemas requerem mtodos de funcionamento diferentes. Todavia, existe uma camada de transporte de mdia comum a todos os sistemas.

Comunicao de Dados 2010/11 Alunos: Miguel Cruz 5349 e Rogrio Meireles - 5350

Pgina 3

Protocolo RTP
Real-Time Transport Protocol

INTRODUO
O ser humano est em constante evoluo, e prova disso passa um pouco pela internet e pelas alteraes constantes a que esta est sujeita ao longo do tempo. As pginas estticas do lugar s animaes, o texto substitudo por som e cada vez mais a interaco feita atravs de udio e Vdeo. Estas constantes alteraes levam a que seja necessrio criar novas aplicaes que dem suporte a este tipo de contedos. O protocolo RTP (Real Time Transport Protocol), que em portugus significa Protocolo de Transporte em Tempo Real surgiu com a ideia de criar um protocolo especfico para o grande requisito de recursos em tempo real por parte dos utilizadores. Alguns destes recursos so a msica, a videoconferncia, o vdeo, as chamadas telefnicas via internet entre outras aplicaes multimdia. Este protocolo formado conjuntamente com o protocolo RTCP (RTP Control Protocol), ou seja, Protocolo de Controlo RTP, cuja funo principal proporcionar mecanismos de realimentao para informar sobre a qualidade na distribuio dos dados. Apesar da definio do Protocolo RTP ter sido publicada em 1996 na RFC 1889, a ideia de passar udio e vdeo atravs de uma rede informtica no nova, pois o primeiro RFC com este propsito Network Voice Protocol (NVP) data de 1977. Tendo o vdeo surgido mais tarde. Em meados dos anos 90 e devido ao constante aumento da largura de banda e ao desenvolvimento dos computadores pessoais, a comunidade internauta, comeou a demonstrar maior interesse pelo contedo multimdia na rede.

Comunicao de Dados 2010/11 Alunos: Miguel Cruz 5349 e Rogrio Meireles - 5350

Pgina 4

Protocolo RTP
Real-Time Transport Protocol

Funcionamento RTP
Emissor/Receptor
A base de um sistema de transmisso udio/vdeo em tempo real o RTP. Pois, independentemente do protocolo de sinalizao e de aplicao, este fornece a camada de transporte comum a todos. Vejamos ento as responsabilidades de um emissor /receptor num dado sistema.

Emissor
Captura e transforma dados para transmisso udio/vdeo, bem como para gerar pacotes RTP. Pode tambm, atravs de interaco com o receptor fazer o controlo e correco do fluxo de mdia transmitido.

Diagrama do Emissor RTP

Dados multimdia so capturados para um buffer, e da so criadas frames e codificadas (dependendo do algoritmo de compresso utilizado). As frames codificadas podem depender de frames anteriores ou posteriores. Depois de comprimidas, vo ser carregados pacotes RTP, que podem conter fragmentos de frames, caso estas sejam muito grandes, ou vrias frames para o caso de estas serem de tamanhos mais reduzidos. Podem ser usados codificadores de canal para o controlo de pacotes antes da transmisso. Os dados do buffer so libertados aps o envio dos pacotes RTP. Devendo o emissor ter em conta que os dados podem vir a ser necessrios para correco de erros ou processos de codificao. Para

Comunicao de Dados 2010/11 Alunos: Miguel Cruz 5349 e Rogrio Meireles - 5350

Pgina 5

Protocolo RTP
Real-Time Transport Protocol

isso deve armazen-los durante algum tempo, dependendo dos mtodos usados na codificao e esquema de correco de erros. O emissor reporta ainda, de forma peridica, o fluxo de dados multimdia que vai gerando. Incluindo os dados necessrios para sincronizao. O emissor pode adaptar a transmisso atravs do feedback dos restantes participantes.

Receptor
O receptor responsvel pela captura de pacotes RTP, correco de falhas, gesto de tempo, descompresso dos dados e apresentao dos resultados ao utilizador. Tambm interage com o emissor de forma a estabilizar a transmisso. Tem ainda em seu poder uma lista de participantes da sesso.

As operaes podem seguir uma ordem diferente, dependendo das necessidades implementadas.

Diagrama do Receptor RTP

Os pacotes so recebidos e feita uma verificao para possvel correco e de seguida colocados na respectiva lista de espera do emissor. Os pacotes passam de seguida por um controlo de cdigo de rotina para anlise de eventuais perdas. No prximo passo so colocados num buffer de reproduo (playout) especfico. A sada do buffer feita atravs de uma marcao de tempo, e na insero de pacotes para o buffer possvel ser feita a correco do reordenamento ocorrido no transporte. Os pacotes mantm-se no buffer at recepo completa das frames para assim tentar minimizar ao mximo qualquer variao de tempo na rede. Um dos maiores problemas na implementao do RTP o clculo do tempo para corrigir os atrasos. O tempo desejado para a reproduo de determinada frame, est registado no pacote.

Comunicao de Dados 2010/11 Alunos: Miguel Cruz 5349 e Rogrio Meireles - 5350

Pgina 6

Protocolo RTP
Real-Time Transport Protocol

Quando atingido o tempo de reproduo, so formadas frames completas atravs do agrupamento de pacotes, e para o caso de ocorrer perdas ou danos com algumas frames so feitas as reparaes necessrias. Quando as frames so totalmente reparadas, estas so descodificadas (dependendo da codificao, pode ser necessria a frame anterior para se descodificar a seguinte). Nessa altura pode-se verificar desvios temporais entre emissor e receptor, estes desvios verificam-se entre os tempos presentes nos pacotes RTP e os tempos de reproduo. Cabe ao receptor ajustar os tempos para tentar estabilizar a transferncia. Os dados esto prontos para serem entregues ao utilizador. Os fluxos podem ser entregues individualmente, por exemplo, apresentao de vrios fluxos de vdeo, cada um na sua janela. Tambm pode ser feita uma mistura das vrias fontes num nico fluxo de sada, por exemplo, a reproduo de udio, proveniente de vrias fontes, num nico conjunto de colunas. Estas condies dependem do formato de mdia e dos dispositivos de sada.

Comunicao de Dados 2010/11 Alunos: Miguel Cruz 5349 e Rogrio Meireles - 5350

Pgina 7

Protocolo RTP
Real-Time Transport Protocol

Transferncia de Pacotes
A divulgao de contedos em tempo real visto como uma emisso para o exterior, por parte do receptor, da informao que este vai recebendo e medida que a recebe. Sabemos que em casos ideais funcionaria assim mas na verdade, a rede impe alguns atrasos. A previsibilidade da variao do tempo de trnsito na rede o factor mais importante na transmisso em tempo real. Se uma fonte transmite pacotes em intervalos de 20 milissegundos, o ideal que o receptor tambm os receba nesses tempos para que a comunicao entre utilizadores seja estvel. Mas a rede impe atrasos e para isso criado um buffer no receptor para melhoria da recepo por parte do utilizador final. A tolerncia a erros comum nesta transmisso. Quanto mais confivel for a ligao, tanto melhor. Mas, por exemplo, numa emisso rdio on-line a perda de um nico pacote no iria ser muito importante para os ouvintes dessa emisso, pois trata-se de um perodo de tempo muito curto e normalmente os pacotes seguintes acabam por colmatar a falha dos anteriores. A quantidade de pacotes perdidos vai influenciar a qualidade da transmisso mas isso depende da finalidade da aplicao e da implementao usada. O Protocolo RTP estabelece-se com o utilizador e executa-se, de modo geral, atravs de UDP, j que este possui menos atraso que TCP. Logo, com UDP conseguimos ganhar maior velocidade perdendo a fiabilidade que o TCP nos oferece. Deste modo, o protocolo RTP no garante a entrega de todos os pacotes, nem mesmo a chegado dos mesmos no tempo previsto, contudo, fornece a deteco e recuperao de perda de tempo.

Comunicao de Dados 2010/11 Alunos: Miguel Cruz 5349 e Rogrio Meireles - 5350

Pgina 8

Protocolo RTP
Real-Time Transport Protocol

Algumas aplicaes preferem a utilizao de TCP/IP para transmisses em tempo real devido ao bloqueio de pacotes UDP por parte de algumas firewalls. Com o elevado nmero de aplicaes a usar este tipo de recursos, esta situao tende a desaparecer.

Benefcios nas Comunicaes IP


Apesar das comunicaes baseadas em IP ainda colocarem vrios desafios, estes apresentam vantagens que so capazes de superar as desvantagens. Cada vez mais os servios de suporte de udio e vdeo convergem para este tipo de redes. Vejamos a quantidade de emisses on-line, quer rdio, quer televisivas que tm surgido nos ltimos tempos, bem como as chamadas telefnicas (unicast), a partilha de ficheiros, os jogos (desde o mais simples ao mais elaborado) e por a adiante. Podemos, com este propsito, obter um avano na economia devido aos baixos custos exigidos para suporte a tantos recursos. O uso de udio e vdeo sobre IP permite ainda a interaco entre aplicaes que at a no faziam uso desse servio. O que permite o desenvolvimento de sistemas que at a no existiam. Outro projecto aprovado pelo RTP O princpio do End to End a forma de se transmitir a informao mas de forma confivel. Onde confirmada a recepo total dos dados. Os dados podem ainda ser armazenados pelo receptor para posterior utilizao. Aqui est presente a interaco entre RTP e TCP/IP. O RTP foi desenvolvido para vrias aplicaes, como um protocolo simples onde no seriam necessrios muitos protocolos adicionais. Ele fornece todas as funes de gesto de sesso necessrias, onde apenas o endereo IP e o mapeamento das definies de mdia presentes so suficientes para participar numa sesso. Podemos verificar essa forma de funcionamento em diversas aplicaes, como por exemplo, as emisses de rdio on-line, onde o feedback dado pelo receptor pode ser usado para dados estatsticos, bem como, a audincia e a qualidade do sinal recebido. Apesar de ainda estar em desenvolvimento, para as chamadas telefnicas (unicast), algumas pessoas alegam que se trata de um

Comunicao de Dados 2010/11 Alunos: Miguel Cruz 5349 e Rogrio Meireles - 5350

Pgina 9

Protocolo RTP
Real-Time Transport Protocol

protocolo que disponibiliza recursos desnecessrios, prejudicando a transferncia. J a indstria cinematogrfica defende que o RTP no complementa as necessidades e que deviria haver uma maior aposta na melhoria da qualidade do servio bem como na segurana, entre outros. Ainda assim, a maior parte das aplicaes em tempo real tiram partido da unificao do RTP.

Comunicao de Dados 2010/11 Alunos: Miguel Cruz 5349 e Rogrio Meireles - 5350

Pgina 10

Protocolo RTP
Real-Time Transport Protocol

Especificao RTP
Normalmente o RTP usado sobre UDP/IP com vista a aproximar-se o mais possvel do tempo real. Mas no exigncia deste protocolo que a comunicao seja feita sobre UDP, nem sequer IP. Existem aplicaes que o fazem em TCP/IP e tambm usado nas redes sem IP, como o caso das redes Asynchronous Transfer Mode (ATM). O protocolo est dividido em duas partes, transferncia (RTP) e a parte do controlo (RTCP). a parte da

A parte da transferncia responsvel por gerar o fornecimento de dados em tempo real entre clientes. Ele define a carga til a ser enviada e faz uma marcao sequencial para deteco de perdas. Complementa ainda com informaes relativas aos tempos para cada um dos dados. A parte do controlo responsvel pelo feedback acerca da qualidade da recepo de sinal, identificao dos participantes e sincronizao entre fluxos. O RTCP fornece relatrios peridicos, com estas informaes, mas opera numa escala de tempo bastante acima da do RTP.

Comunicao de Dados 2010/11 Alunos: Miguel Cruz 5349 e Rogrio Meireles - 5350

Pgina 11

Protocolo RTP
Real-Time Transport Protocol

Sesso RTP
As comunicaes RTP podem ser compostas por vrios participantes em que cada um deles pode estar activo em mais do que uma sesso, por exemplo, pode estar simultaneamente a efectuar a troca de dados de vdeo numa sesso e a trocar dados udio noutra sesso distinta. Cada participante de uma sesso tem atribudo um endereo de rede e pelo menos dois portos para envio e recepo de dados. Podem ser usados dois ou quatro portos, pois o mesmo porto pode ser usado, tanto para envio como para recepo de dados do mesmo protocolo. Para o caso de utilizarmos apenas dois portos, um dos portos (adjacente) usado para pacotes RTP (porto par) enquanto o outro imediatamente acima (porto impar) usado para pacotes de controlo (RTCP). Os portos usados por defeito so os 5004 e 5005 para RTP e RTCP respectivamente, mas dependendo da aplicao, estes podem variar. As sesses RTP esto desenhadas para que apenas seja transferido um tipo de mdia. Logo, numa transferncia multimdia, cada tipo de mdia deve ser transferida numa sesso diferente. Existem vrios tipos de sesses RTP, unicast, multicast, servidor de difuso, etc. Com a ajuda de tradutores pode ainda ser feita a ponte entre diferentes tipos de redes (IPv4, IPv6, ATM) e entre unicast e multicast.

Comunicao de Dados 2010/11 Alunos: Miguel Cruz 5349 e Rogrio Meireles - 5350

Pgina 12

Protocolo RTP
Real-Time Transport Protocol

Cabealho RTP
Elementos do Cabealho RTP
O cabealho fixo (Mandatory Header) composto normalmente por 12 bytes de comprimento. Embora possa conter uma extenso de 4 a 60 bytes adicionais. O cabealho composto por campos obrigatrios. So eles: tipo de carga til (Payload Type); nmero de sequncia (Sequence Number); marcao de tempo (TimeSpamp); fonte de sincronizao (Synchronization Source). Adicionalmente existe uma indicao das fontes contributivas (Contributing Sources) para aquele pacote, um marcador (Marker) de eventos importantes, suporte para uma possvel extenso (Padding) do cabealho e a indicao da verso (Version) do protocolo.

Tipo de Carga til (Payload Type)


Tambm designada por PT, contm a informao acerca do tipo de mdia transportada por um pacote RTP. Essa informao vai ser analisada na recepo do pacote e enviada para um stio especfico, por exemplo, um descodificador daquele tipo de mdia.
Comunicao de Dados 2010/11 Alunos: Miguel Cruz 5349 e Rogrio Meireles - 5350

Pgina 13

Protocolo RTP
Real-Time Transport Protocol

Para udio/vdeo conferncias normalmente usam-se ligaes com controlo mais reduzido (RTP Profile for Audio and Video Conferences with Minimal Control), presente na RFC 1890 de 1996. Aqui define-se uma tabela que, entre outras coisas, permite saber a ligao entre o n. do tipo de carga, o formato, a RFC associada e a discrio. Vejamos alguns exemplos:

Os termos usados pela MIME (Multipurpose Internet Mail Extensions) so aqui usados para marcar os formatos de carga til. Originalmente concebido para identificar o tipo de anexo num e-mail, tem hoje em dia servido de suporte a muitas aplicaes. Esta interaco relativamente nova mas demonstra ser bastante poderosa na identificao de diferentes tipos de mdia. Dependendo se o tipo de carga esttico ou dinmica, necessrio informar a aplicao para que esta saiba que tipo de sesso est a ser usada. O formato de carga escolhido implica, entre outras coisas, o tempo de clock para execuo das mesmas. Dentro de uma sesso RTP no obrigatrio o uso de apenas um nico formato de carga. Podem ser usados mais do que um tipo de formatos, sendo que, durante a transferncia de um tipo, este pode ser alterado sem qualquer tipo de aviso prvio. Exemplo disso so as chamadas de voz, dentro das quais possvel premir uma tecla para escolher uma de entre vrias opes.

Comunicao de Dados 2010/11 Alunos: Miguel Cruz 5349 e Rogrio Meireles - 5350

Pgina 14

Protocolo RTP
Real-Time Transport Protocol

Embora seja possvel o uso de diferentes formatos de carga na mesma sesso RTP. Os tipos de carga diferentes no se podem misturar. Caso seja necessrio, para uma sesso, o uso de udio e vdeo, estes devero ser enviados em duas sesses RTP diferentes, com diferentes portos de endereo. Deste modo podem ser pedidas melhorias de sinal de um ou de outro tipo de mdia, individualmente. Este processo facilita ainda o processo de controlo (RTCP).

Nmero de Sequncia (Sequence Number)


Os pacotes so identificados com um nmero sequencial, com a inteno de fornecer a informao ao receptor, da eventual perda de algum dos pacotes. A finalidade deste nmero no dizer qual a ordem de reproduo dos pacotes embora ajude o receptor a reconstruir a ordem em que estes foram enviados. Um nmero de 16 bits usado para fazer a sequncia, iniciada num nmero aleatrio (de forma a evitar hackers mal intencionados). Quando atingido o valor mximo, este recomea do zero e assim sucessivamente. Para termos um ideia do tempo necessrio para efectuar um ciclo completo, vejamos a situao em que efectuada uma chamada de voz que envia pacotes a cada 20 milissegundos. O tempo necessrio para a realizao de um ciclo ser de aproximadamente 20 minutos. Da que as aplicaes no devem seguir o nmero de sequncia como identificador para ordenador da reproduo. Devem sim, usar um nmero de 32 bits ou superior, em que os primeiros 16 indicam o nmero de sequncia e os restantes, o nmero de ciclos efectuados. O nmero de sequncias fundamentalmente usado para deteco de perdas de pacotes. Caso esta situao se verifique, o receptor ter de ter autonomia para tentar minimizar as falhas.

Comunicao de Dados 2010/11 Alunos: Miguel Cruz 5349 e Rogrio Meireles - 5350

Pgina 15

Protocolo RTP
Real-Time Transport Protocol

Marcao de Tempo (Time Stamp)


Consiste em indicar a marcao de tempo do primeiro byte de contedo mdia do pacote RTP. Isto, para que seja possvel programar os tempos de reproduo dos contedos mdia. A marcao de tempo consiste num nmero inteiro de 32 bits que vai aumentando, consoante os contedos mdia assim o obriguem. Quando atingido o valor mximo desse nmero, este comea um novo ciclo a partir do zero, semelhante o nmero de sequncia. Vejamos exemplos da durao de um ciclo. Com uma velocidade de clock na ordem dos 90 KHz, tipicamente usada para vdeo, um ciclo pode ter uma durao prxima das 13 horas. J para o udio, com velocidades que rondam os 8 KHz, o intervalo de tempo necessrio para percorrer um ciclo, ronda os 6 dias. Tal como o nmero de sequncia, o marcador de tempo no comea a contagem inicial no zero. Tambm para tentar reduzir os ataques. As aplicaes devem ter em conta esse pormenor, visto que um erro frequente de diversos aplicativos. Estes ciclos so bastante comuns no RTP e as aplicaes devem estar preparadas para isso. Desse modo, o uso de marcadores de tempo muito grandes, na ordem dos 64 bits, no so recomendados tanto que tambm os processadores de hoje em dia no simpatizam muito com esse tipo de arquitectura. Uma arquitectura de 32 bits permite um melhor funcionamento do sistema. O marcador de tempo estabelecido na aplicao, uma vez que o RTP nada tem a ver com timings. Cabe ao emissor e receptor lidar com questes desse tipo.

Sincronizao de Fontes (Synchronization Source SSRC)


Responsvel por identificar os participantes numa sesso, atravs de um inteiro de 32 bits. Cada participante, ao iniciar sesso, escolhe o seu SSRC. Como os SSRC so escolhidos localmente, pode acontecer que dois

Comunicao de Dados 2010/11 Alunos: Miguel Cruz 5349 e Rogrio Meireles - 5350

Pgina 16

Protocolo RTP
Real-Time Transport Protocol

participantes escolham para si o mesmo nmero. Essas situaes so verificadas quando uma aplicao recebe um pacote proveniente de outra com o mesmo nmero. A aplicao que detecta o conflito, abandona o seu SSRC, escolhendo outro para o substituir. Essas colises devem ser evitadas para que no gere confuso na identificao de pacotes por parte do receptor.

Fontes Contributivas (Contributing Sources CSRC)


Os dados RTP so normalmente produzidos por uma nica fonte, mas quando se trata da transmisso de mltiplos fluxos, atravs de misturadores ou tradutores, h a possibilidade de existir mais do que uma fonte para cada pacote RTP. Aqui so identificadas as fontes que contribuem para dado pacote. Estas fontes no so responsveis por tempos nem sincronizao. As fontes so identificadas pelo SSRC do participante que contribuiu para aquele pacote. No campo CC do cabealho RTP indicado o tamanho da lista CSRC.

Marcador (Marker)
Para marcar eventos de interesse usado um marcador. Este marcador tem significados diferentes, dependendo do perfil de RTP e pelo tipo de mdia. usado em videoconferncia para indicar que enviou um pacote aps um perodo de silncio. Nessa altura o seu estado passa a 1, estando a 0 o resto da transferncia. Um marcador a 1 pode indicar que se trata de uma boa altura para fazer um ajuste reproduo. Uma vez que esse ajuste no vai ser perceptvel pelos utilizadores, num perodo de silncio. Para o caso das transmisses vdeo, se o marcador se encontrar a 1 indica que chegou um pacote com a ltima frame de um vdeo. A aplicao deve comear ento o processo de descodificao.

Comunicao de Dados 2010/11 Alunos: Miguel Cruz 5349 e Rogrio Meireles - 5350

Pgina 17

Protocolo RTP
Real-Time Transport Protocol

O marcador apenas sugere que determinada aco seja feita. No entanto as aplicaes devem estar preparadas para eventuais perdas de pacotes com marcadores activos.

Enchimento (Padding)
Este usado para indicar que a carga til contida excedeu o seu comprimento natural. Caso seja necessrio o suplemento, o bit do padding ir passar a 1 e no ltimo byte de carga til ser indicado o n. de Bytes do suplemento. Este procedimento no muito usual mas existem formas de encriptao bastante extensas que necessitam de mais capacidade de alocao.

Nmero da Verso (Version Number)


Aqui indicada a verso do RTP em uso. O uso deste campo no est generalizado. Apenas usado para verificao e validao do pacote.

Extenses de Cabealho (Header Extensions)


Quando sinalizado, significa que houve uma extenso do cabealho. Encontra-se aps um cabealho de RTP fixo e atrs de qualquer cabealho de carga til. As extenses de cabealho so de tamanho varivel. As extenses de cabealho so teis para casos em que necessrio mais informao no cabealho do que a disponvel no cabealho fixo. Este tipo de cabealho raramente usado. Caso seja mesmo necessrio o seu uso, isso deve ser feito na seco de carga do pacote como um cabealho de reproduo. De qualquer modo as aplicaes devem estar preparadas para eventuais extenses de cabealhos.

Cabealhos de Reproduo (Payload Headers)


Na maior parte dos casos estes cabealhos necessitam de mais informao que os cabealhos fixos. As especificaes do formato de carga fazem parte dessa informao. Este cabealho est includo no

Comunicao de Dados 2010/11 Alunos: Miguel Cruz 5349 e Rogrio Meireles - 5350

Pgina 18

Protocolo RTP
Real-Time Transport Protocol

pacote RTP depois dos cabealhos fixos, de qualquer lista CSRC e de extenses de cabealho. A informao contida num cabealho de carga til pode ser esttica (igual para toda a sesso) ou dinmica. As partes estticas e dinmicas especificaes do formato de carga til. sero indicadas nas

Normalmente se a carga til constante ao longo da sesso, esta informao passada fora da carga til. Isto faz com que a sesso se processe melhor. A principal razo da existncia destes cabealhos a tentativa de evitar, em redes em que frequente, a perda de pacotes.

Dados de Carga til (Payload Data)


Estes esto sempre associados aos cabealhos de reproduo, quer seja uma ou mais frames, compondo a parte final de um cabealho RTP. Os parmetros definidos no incio da sesso vo influenciar o tamanho e o formato dos dados. Num pacote podem ser inseridos mltiplas frames de dados. Existem duas maneiras de saber o nmero de frames de um pacote. Ou elas tm todas o mesmo tamanho e pelo tamanho do pacote determinamos o nmero de frames ou as prprias frames contm encapsulados os respectivos tamanhos. No existe regra para o nmero de frames para cada pacote. As aplicaes tm de ser capazes de identificar quantidades e tamanhos. Para sabermos qual a quantidade de carga a incluir em cada pacote temos que ter em conta duas situaes. A unidade de transferncia mxima do caminho a percorrer e os atrasos inevitveis na espera de mais dados para se completar um longo pacote.

Comunicao de Dados 2010/11 Alunos: Miguel Cruz 5349 e Rogrio Meireles - 5350

Pgina 19

Protocolo RTP
Real-Time Transport Protocol

Segurana
So muitas as reticncias em relao ao uso do nomeadamente na descrio involuntria da fonte de pacotes. RTP,

A transferncia desse tipo de dados pode expor informaes pessoais importantes. Para evitar problemas relacionados com esta questo, as aplicaes deveriam informar os utilizadores que determinada informao est a ser disponibilizada. Outro dos problemas o facto de ser bastante difcil de ocultar os endereos IP, pois estes esto presentes no cabealhos IP e, tambm a passagem pelas NAT (Network Adress Translation) onde explcita a troca de IPs. O uso de nomes de utilizador, sem fazer uso de aplicativos com opes de CNAME (Canonical Name forma de ocultar os nossos dados na rede), pode ser preocupante pois podem ser facilmente interceptados. Para prevenir acessos mal-intencionados podemos fazer uso de encriptao de 32 bits.

Comunicao de Dados 2010/11 Alunos: Miguel Cruz 5349 e Rogrio Meireles - 5350

Pgina 20

Protocolo RTP
Real-Time Transport Protocol

Aplicaes
Este protocolo hoje em dia muito utilizado no nosso dia-a-dia. Est presente desde os mementos de lazer at aos momentos de maior profissionalismo. Podemos v-lo presente nas transmisses rdio on-line, que nos permitem ouvir emisses rdio de qualquer parte do planeta, em qualquer parte do planeta, quer seja para ouvirmos as ltimas novidades da msica, quer para sabermos as notcias do nosso pas caso nos encontremos no estrangeiro. De igual modo, podemos tirar partido das transmisses televisivas on-line. Outro tipo de aplicabilidade so as videoconferncias, onde podemos realizar uma reunio com diversas pessoas, sem que estas tenham que estar no mesmo espao, nem sequer no mesmo continente. Isto bastante vantajoso para empresas que tm reas de negcio bastante alargadas. As chamadas de voz sobre IP (VOIP), esto em constante crescimento, tendo em conta a velocidade do processamento da informao e o custo destas chamadas em relao s operadoras comuns. Hoje em dia a maioria dos videojogos, desde o mais simples ao mais elaborado graficamente, tem a possibilidade de ser jogado online. Tambm aqui podemos ver o RTP em funcionamento. Cada vez mais o uso deste protocolo mais frequente e continua em larga expanso devido ao elevado nmero de redes IP e aos avanes quanto portabilidade da mesma. Os equipamentos tecnolgicos, como Smartphones, os recentes PADs, as PlayStation, alguns automveis, entre muitos outros, fazem uso de IP, o que revela que este tipo de rede promete avanos e tendo em conta que estes equipamentos permitem mobilidade, normal que faam uso de Real-time Transport Protocol.

Comunicao de Dados 2010/11 Alunos: Miguel Cruz 5349 e Rogrio Meireles - 5350

Pgina 21

Protocolo RTP
Real-Time Transport Protocol

Concluso
Com a realizao deste trabalho podemos aprofundar os nossos conhecimentos na rea das comunicaes em rede. Podemos concluir que a transferncia de dados em tempo real, principalmente atravs de redes IP, utilizando este protocolo, est em constante expanso e permite grandes evolues, como a econmica ou a tecnolgica, entre outras. um protocolo no muito complexo que permite a interaco com outros protocolos para que a transferncia de dados entre utilizadores possa ser mais fivel e mais segura. Tende a ser um dos protocolos mais utilizados num futuro prximo devido expanso e portabilidade das redes IP. Gostaramos de agradecer ao professor Daniel Silva pelos ensinamentos transmitidos e pela disponibilidade no apoio elaborao deste trabalho. Sem esquecer, obviamente, todos os que, de uma forma ou de outra, contriburam na partilha de conhecimentos.

Comunicao de Dados 2010/11 Alunos: Miguel Cruz 5349 e Rogrio Meireles - 5350

Pgina 22

Protocolo RTP
Real-Time Transport Protocol

Bibliografia

http://en.wikipedia.org/wiki/Real-time_Transport_Protocol - 12-2010

http://www.networksorcery.com/enp/protocol/rtp.htm - 12-2010

http://www.monografias.com/trabajos33/telecomunicaciones/telecom unicaciones3.shtml - 12-2010

http://www.chebucto.ns.ca/~rakerman/port-table.html - 01-2011

Sousa, Lindeberg Barros de, Redes de Computadores Dados Voz Imagem, rica

Falbriard, Claude, Protocolos Computadores, rica

Aplicaes

para

Redes

de

Comunicao de Dados 2010/11 Alunos: Miguel Cruz 5349 e Rogrio Meireles - 5350

Pgina 23