Guia LivSmart
Protocolo

RTP

Quando áudio e vídeo precisam chegar com temporização e identificação de perdas, RTP encapsula amostras em pacotes numerados e marcados por timestamp. A base é a RFC 3550, de 2003, acompanhada por RTCP. Um stream de vídeo pode usar clock de 90 kHz; áudio Opus, 48 kHz. RTP não garante entrega nem reserva banda. O critério de escolha é mídia interativa ou streaming sensível a atraso; para arquivos completos, HTTP/TCP costuma ser mais simples.

📖Definição aprofundada

RTP é um protocolo de transporte de dados em tempo real, especialmente áudio, vídeo e eventos relacionados. Ele foi projetado para fornecer informações que a aplicação precisa para reconstruir a sequência temporal: número de sequência, timestamp, identificação da fonte, tipo de payload e marcadores. Normalmente é transportado sobre UDP, mas pode operar sobre outros serviços. RTP não promete entrega, ordem ou retransmissão. Essa escolha evita que um pacote atrasado bloqueie todos os seguintes. Para voz e vídeo interativos, perder um pacote pode ser menos prejudicial que aguardar centenas de milissegundos. A aplicação usa jitter buffer, ocultação de perda, FEC, retransmissão seletiva ou redução de bitrate conforme o perfil. RTP é definido pela RFC 3550, publicada em julho de 2003, que substituiu a RFC 1889 de 1996. A mesma RFC define RTCP, o protocolo de controle que envia relatórios de recepção, identificação, sincronização e estatísticas. RTP e RTCP formam uma arquitetura. O pacote RTP básico começa com versão 2, flags de padding e extension, contagem de CSRC, marker, payload type, sequence number de 16 bits, timestamp de 32 bits e SSRC de 32 bits. Pode incluir CSRCs e extensões. O número de sequência aumenta por pacote e ajuda detectar perda e reordenamento. Ele volta após 65535. O receptor precisa tratar wrap. O timestamp representa o instante de amostragem numa escala definida pelo payload, não a hora do relógio. H.264 e muitos vídeos usam 90 kHz. Opus usa 48 kHz. G.711 usa 8 kHz. Vários pacotes de um quadro podem compartilhar timestamp. O marker tem significado definido pelo formato de payload. O SSRC identifica uma fonte de sincronização dentro da sessão e deve ser escolhido de forma aleatória com detecção de colisão. Um mixer pode listar CSRCs. O payload type de 7 bits identifica o formato e seus parâmetros por perfil ou negociação. Tipos dinâmicos dependem de SDP ou sinalização. Ver payload 96 não significa H.264 universalmente; o SDP associa. Esse erro é comum. Formatos de payload são definidos em RFCs específicas, como H.264, H.265, Opus, VP8, VP9, AV1 e eventos telefônicos. Eles dizem como fragmentar unidades, agregar e usar marker. A aplicação não deve simplesmente colocar um arquivo inteiro. O tamanho precisa respeitar MTU. Em Ethernet MTU 1500, payload RTP é reduzido por IP, UDP, RTP, SRTP e túneis. Pacotes de vídeo em torno de 1200 bytes são comuns para evitar fragmentação. RTP não possui descoberta nem estabelecimento. SIP, RTSP, WebRTC, H.323 ou outra sinalização negocia endereços, portas, codecs e chaves. SDP descreve. Em RTSP, SETUP define. Em SIP, offer/answer. Em WebRTC, ICE encontra caminho e DTLS-SRTP cria chaves. O RTP em WebRTC usa perfis seguros e extensões. Em câmeras, RTP pode ser enviado por UDP ou intercalado em RTSP/TCP. Em telefonia, pares de portas são comuns. RTCP historicamente usa porta adjacente, mas multiplexação RTP/RTCP pode usar uma só. A sessão pode ter múltiplos SSRCs, simulcast, retransmissão e FEC. O receptor usa RTCP Receiver Reports para informar fração perdida, perda cumulativa, maior sequência, jitter e dados de sincronização. Sender Reports ligam timestamp RTP a NTP, permitindo sincronizar áudio e vídeo. Sem essa associação, relógios podem divergir. CNAME relaciona fontes. Feedback rápido é definido em extensões AVPF e perfis relacionados. NACK solicita retransmissão; PLI pede quadro-chave; FIR solicita refresh; REMB é extensão não padrão universal; transport-wide congestion control usa extensões específicas. RTP não cifra. SRTP, RFC 3711, fornece confidencialidade, autenticação e proteção contra replay. WebRTC exige SRTP. Câmeras RTSP legadas frequentemente enviam RTP aberto. VLAN e VPN ajudam. RTP pode ser multicast para distribuição eficiente. Isso exige rede planejada, IGMP/MLD snooping e bitrate. Wi‑Fi multicast é ineficiente. Unicast é mais simples. A qualidade depende de jitter, perda, atraso e codec. O protocolo fornece sinais, mas não reserva QoS. DiffServ pode marcar. A rede precisa evitar bufferbloat. Para gravação completa, um NVR pode tolerar retransmissão via TCP. Para intercomunicador, baixa latência é prioridade. O critério de escolha é temporalidade, não apenas “vídeo”.

Arquitetura e Funcionamento
Sequência, timestamp e jitter buffer
O sequence number identifica a ordem de pacotes e permite detectar lacunas. O receptor não deve assumir que todo salto é perda permanente; pacotes podem chegar fora de ordem. Uma janela espera por curto período. O timestamp avança conforme o clock da mídia. Para áudio de 20 ms em 48 kHz, avança 960 por pacote. Para vídeo, quadros a 30 FPS podem avançar aproximadamente 3000 num clock de 90 kHz, mas taxa variável é possível. O jitter buffer retém pacotes para compensar variação. Maior buffer reduz cortes e aumenta atraso. Em interfone, 50–150 ms pode ser alvo; em gravação, maior é aceitável. O receptor estima jitter segundo a RFC. Um pacote atrasado além do playout pode ser descartado. O protocolo não decide. Concealment repete ou interpola áudio. Vídeo perde bloco ou quadro. Um PLI solicita keyframe. O ajuste adaptativo deve evitar oscilações. A rede precisa ser medida.
Payload type, SDP e codecs
O payload type não é codec global quando está na faixa dinâmica. A sessão negocia. SDP pode conter `m=video 5004 RTP/AVP 96`, `a=rtpmap:96 H264/90000` e `a=fmtp`. O cliente precisa usar os dados daquela sessão. Reutilizar tabela de outra causa decodificação errada. O formato de payload define fragmentação e agregação. H.264 pode usar FU-A para NAL grande. Opus possui regras. Marker pode indicar fim de unidade de acesso, conforme formato. O receptor precisa validar comprimento e valores antes de alocar, porque pacotes vêm da rede. Codecs possuem perfis. H.264 High pode não ser aceito por navegador. Para interoperabilidade, usar codecs comuns e parâmetros compatíveis. Transcodificação custa CPU e atraso. Remux mantém. Em casa, uma câmera H.265 pode gravar eficientemente, mas exigir stream H.264 para WebRTC. O NVR pode usar dois perfis.
RTCP, sincronização e feedback
RTCP compartilha informações de qualidade e identidade. Sender Report inclui NTP timestamp, RTP timestamp e contadores. Receiver Report inclui perda, maior sequência, jitter, last SR e delay since last SR. Isso permite calcular round-trip e alinhar áudio/vídeo. SDES transmite CNAME. BYE indica saída. APP permite dados específicos. A largura de banda RTCP é controlada para não crescer demais. Em sessões grandes, intervalos aumentam. Perfis de feedback permitem NACK, PLI, FIR e outras mensagens mais rápidas. WebRTC usa intensamente para adaptação. Câmeras simples podem não enviar. Sem RTCP, ainda é possível reproduzir, mas há menos diagnóstico e sincronização. O monitoramento pode medir perda no receptor. Um NVR que só olha “socket aberto” não detecta 20% de perda. Relatórios devem alimentar alertas. Não confundir RTCP com protocolo de controle RTSP; RTCP controla qualidade do RTP, RTSP controla sessão.
SRTP, NAT e transporte de rede
RTP aberto permite ouvir e injetar mídia. SRTP cifra payload, autentica e protege replay, mantendo cabeçalho necessário ao roteamento. Chaves podem vir de SDES, MIKEY, DTLS-SRTP ou outros mecanismos. SDES em SDP aberto é inseguro. WebRTC usa DTLS-SRTP. SIP moderno pode usar DTLS-SRTP ou SDES com TLS, conforme ambiente. NAT muda endereços e portas. ICE, STUN e TURN descobrem e retransmitem. RTP simétrico e rport ajudam em VoIP. RTSP pode indicar server_port/client_port. Firewalls precisam permitir. Em redes locais, portas dinâmicas podem ser bloqueadas. TCP interleaved contorna, mas adiciona comportamento TCP. Multicast usa um emissor e muitos receptores, eficiente em Ethernet. Switch com IGMP snooping evita inundar. Wi‑Fi multicast tem baixa taxa e perdas. Para casa, unicast é padrão. QoS pode marcar DSCP, mas todos os equipamentos precisam respeitar. Não usar prioridade para mascarar upload saturado; controlar filas.
Análise Técnica
✓ Vantagens
  • Fornece sequência, temporização, identificação de fonte e tipo de payload sem impor retransmissão que aumentaria atraso.
  • Suporta ampla variedade de codecs por formatos de payload separados e negociação via SDP.
  • RTCP oferece estatísticas, sincronização entre áudio e vídeo e feedback para adaptação e diagnóstico.
  • Funciona em unicast e multicast, sobre UDP ou outros transportes, e integra RTSP, SIP, WebRTC e sistemas de mídia.
  • Com SRTP, pode oferecer confidencialidade, integridade e proteção contra replay mantendo a estrutura eficiente.
✗ Desvantagens
  • Não garante entrega, ordem, banda ou baixa latência; rede, codec, jitter buffer e aplicação determinam a qualidade.
  • Payload types dinâmicos não têm significado sem SDP ou sinalização, causando incompatibilidades em implementações simplificadas.
  • RTP puro não cifra nem autentica; streams legados podem ser capturados ou injetados por atacantes na rede.
  • UDP e portas dinâmicas dificultam NAT e firewall, exigindo ICE, TURN, configuração ou transporte intercalado.
  • Muitos detalhes ficam em perfis e RFCs de payload, tornando uma implementação completa mais complexa que enviar datagramas.
💡 Cenário Prático: RTP em intercomunicadores, câmeras e áudio local
Uma câmera ONVIF fornece URL RTSP. O NVR negocia RTP/RTCP por UDP na VLAN de câmeras e usa pacotes abaixo do MTU. O switch mantém filas e não deixa upload de backup saturar. O NVR mede sequência, jitter e último timestamp. Se a perda fica acima de 2% por minutos, alerta e investiga Wi‑Fi, cabo ou bitrate. Para painel web, um gateway converte a sessão em WebRTC e usa SRTP. O stream H.264 secundário é escolhido para compatibilidade; o principal H.265 grava. Em um interfone SIP, áudio Opus usa clock de 48 kHz, jitter buffer adaptativo e RTCP. ICE/TURN é usado apenas quando atravessa Internet. Na LAN, endereços diretos reduzem latência. As portas RTP não são expostas na WAN. Acesso remoto usa VPN ou WebRTC autenticado. O sistema gera PLI quando entra no vídeo para obter keyframe. Não confunde payload type 96 com um codec fixo. As descrições SDP são registradas para diagnóstico, sem credenciais. O dispositivo tem NTP correto para correlação, embora o timestamp RTP continue relativo. A operação confirma áudio e vídeo, não apenas sessão estabelecida.