Real Time Messaging Protocol

Real Time Messaging Protocol (RTMP) é um protocolo desenvolvido pela Macromedia para streaming de áudio, vídeo e dados para internet totalmente voltada para o Flash player. O protocolo é desenvolvido sobre TCP e por padrão utiliza a porta 1935. É comumente feito o tunelamento do protocolo via RTMPT, que usa pequenos pacotes HTTP para burlar os Firewall, e ainda RTMPS e RTMPTS, que são o mesmo protocolo, mas em conexão segura.

História

A Adobe teve numerosas disputas com projetos que quebraram o protocolo, mas em 15 de junho de 2009 acabou liberando o protocolo (mas não as funcionalidades) da especificação RTMP.

Então, com o código aberto vários projetos surgiram, sendo o mais popular o Red5, gratuito em Java e o Wowza, em Java e pago.

Implementações

Abaixo segue toda a lista de projetos que implementam o RTMP.

Mantidos pela Adobe:
- Flash Media Server http://www.adobe.com/products/flashmediaserver/
- LiveCycle DS http://www.adobe.com/products/livecycle/dataservices/
Não mantidos pela Adobe:
- Red5 http://osflash.org/red5 (Java)
- Wowza http://www.wowzamedia.com/ (Java)
- WebOrb http://www.themidnightcoders.com/products.html (.NET, Java)
- FluorineFX https://web.archive.org/web/20091004180340/http://www.fluorinefx.com/ (.NET)
- ErlyVideo http://code.google.com/p/erlyvideo/ (Erlang)
- RubyIzumi http://code.google.com/p/rubyizumi/ (Ruby)
- RTMPD http://www.rtmpd.com/ (C++)
- Cygnal https://web.archive.org/web/20150905090555/http://wiki.gnashdev.org/Cygnal (C++)
- RTMPy https://web.archive.org/web/20100218145121/http://rtmpy.org/wiki/RTMP (Python)
- RTMPlite http://code.google.com/p/rtmplite/ (Python)
- MammothServer (OpenFMS) http://mammothserver.org/ (C++)

Funcionamento

Basicamente o Flash abre um socket persistente com o servidor através do NetConnection e gerencia o Streaming de áudio/vídeo pelo NetStream e a transferência de dados pelo SharedObject.

Em uma app em Flex você deve usar apenas uma instância do NetConnection, independente de quantos SharedObject e NetStream você tiver.

Para garantir interatividade em tempo Real (Real Time), o sistema mantém uma conexão persistente com o servidor. Para garantir esta interatividade o protocolo divide o vídeo e os dados em fragmentos. O tamanho dos fragmentos utilizados podem ser negociadas de forma dinâmica entre o cliente e o servidor, e até mesmo completamente desativado se desejar, embora os tamanhos padrão são fragmento de 128 bytes para tipos de dados de vídeo e de 64 bytes para dados de áudio.

Fragmentos de diferentes streaming podem então ser intercalados e multiplexados em uma única conexão. Na prática, no entanto, fragmentos individuais geralmente não são intercalados. Em vez disso, a intercalação e multiplexação é feita no nível do pacote, com pacotes RTMP através de vários canais diferentes ativos sendo intercaladas de forma a assegurar que cada canal cumpre a sua largura de banda, latência e outra qualidade do serviço. Pacotes intercalados desta forma são tratados como indivisível, e não são intercalados no nível de fragmentos.

O RTMP define vários canais em que os pacotes podem ser enviados/recebidos, e que operam independentemente um do outro. Por exemplo, existe um canal dedicado para manipulação de solicitações RPC e respostas, um canal para transmitir dados de vídeo, um canal para transmitir dados de áudio, um canal para transmitir as mensagens de controle (banda negociação dos tamanhos dos fragmentos, etc).

Durante uma conexão, vários canais podem estar ativos simultaneamente em um dado momento. Quando os dados são empacotados, um cabeçalho do pacote é gerado. O cabeçalho do pacote especifica, entre outras coisas, a identificação do canal que está a ser enviado em diante, a hora em que foi gerada (se necessário), e do tamanho da carga útil do pacote. Isto é seguido pela carga útil do pacote, que é fragmentado de acordo com o atualmente acordado tamanho dos fragmentos antes que ele seja serializado pela conexão. O cabeçalho do pacote em si nunca é fragmentado, e seu tamanho não conta para os dados no primeiro fragmento do pacote. Em outras palavras, somente os dados da carga real do pacote está sujeito à fragmentação.

Tunelamento

O protocolo RTMP é comumente bloqueado em redes corporativas, redes de acesso gratuito e laboratórios de informática. Então pode se alterar o tipo de protocolo para que trafegue em HTTP:

RTMPT(RTMP Tunneled), neste caso o RTMP é encapsulado e transmitidos em HTTP. Por padrão o server deve escutar a, porta 80.
RTMPS (RTMP Secure), neste caso o RTMP é encapsulado e trocado por HTTPS. Por padrão o server deve escutar a porta 443.