RTP Real-Time Transport Protocol
Universidad Politécnica de Madrid
ETSI de Telecomunicaciones
Doctorado Ingeniería de Sistemas Telemáticos
Curso: Temas Avanzados de Redes de Ordenadores
junio - 2001
RESUMEN
Durante los últimos años la utilización de Internet como medio
para el transporte de imágenes y audio sobre el protocolo IP ha
generado una serie de esfuerzos en la comunidad académica y
comercial. En tal sentido, el presente documento describe las
funciones de Real-Time Transport Protocol (RTP) haciendo
énfasis en sus cabeceras, Real-Time Control Protocol (RTCP)
como mecanismo de control de calidad y Real-Time Streaming
Protocol (RSTP) como protocolo a nivel de aplicación que
facilita el manejo de la media.
1. INTRODUCCION.
El Protocolo de Transporte en Tiempo-Real (RTP) [1] provee
funciones de transporte para redes end-to-end adecuadas para
transmisión de aplicaciones con datos en tiempo real, tales como
audio, video sobre servicios de redes multicast o unicast.
En la sección 2 exponemos un breve diagnóstico sobre la
problemática de las aplicaciones multimedia en Internet,
asimismo se enuncia las apuestas de la industria respecto a RTP.
En la sección 3 y 4 se sustenta por que RTP sobre UDP para
aplicaciones multimedia y se explica como trabaja RTP.
En la sección 5 explicaremos la estructura de los paquetes RTP.
Se puede percibir que RTP puede incluir servicios de
identificación de tipo payload1 (datos transportados), numeración
de secuencia, fechado de tiempo, y monitoreo de entrega.
Típicamente las aplicaciones RTP corren por encima de UDP de
esa forma hace uso de los servicios de checksum y
multiplexamiento, de tal forma, que entre ambos facilitan la
flexibilidad del protocolo.
Este protocolo en si, no facilita reserva de recurso y no garantiza
la calidad de servicio, de tal forma que no hay garantía de una
entrega fiable o pueda prevenir las entregas fuera de orden de
secuencia (out-of-order). En realidad, el número de secuencia
incluido en RTP permite al receptor reconstruir la secuencia de
datos enviados, pero la secuencia de número podría ser usado
para determinar la apropiada ubicación del paquete, por ejemplo,
en la decodificación de video, sin necesariamente decodificar los
paquetes en secuencia.
En la sección 6 exponemos sobre el Real Time Control Protocol -
(RTCP), el cual permite monitorear la entrega de los datos de una
1
Payload: Es un conjunto de datos, tales como campos, bloques o
agrupamiento de datos, que están siendo transportados o procesados
William Díaz RTP/RTCP/RTSP
Ingº William Díaz
willyd@terra.es
manera escalable a lo largo de redes multicast, y provee
funciones mínimas de control e identificación.
En la sección 7 se detalla el Real Time Streaming Protocol
(RTSP) denominado por analogía el protocolo de control de
mando tan igual que en un Video Control Remote (VCR).
Finalmente, es conocido que el Internet actual no puede soportar
las potencialidades de demanda de los servicios de tiempo real.
Los servicios que consumen gran ancho de banda, tales como el
video, puede potencialmente degradar la calidad de servicio de
otros servicios de la red. A decir, se debería tomar las
precauciones para limitar los accidentes por el uso de ancho de
banda. En conclusión, las aplicaciones deberían documentar
claramente las limitaciones y posibles operaciones sobre el
impacto en las redes de servicios de gran ancho de banda.
2. ANTECEDENTES
Las redes de ordenadores fueron diseñadas para conectarse en
diferentes localidades a fin de compartir datos y comunicaciones.
En tiempos iniciales, el transporte estaba relacionados a datos
textuales. Hoy en día con el crecimiento de las aplicaciones
multimedia y las tecnologías de redes, la multimedia ha
empezado a ser un elemento importante de la Internet.
Animación, voz, video clips, se han convertido en elementos
populares de Internet. Estas redes multimedia producen
productos como telefonía sobre Internet, Internet TV y otros
productos que van apareciendo en el mercado. Estamos viendo
productos multimedia: enseñanza a distancia y grupos de trabajos
distribuidos.
Pero este trabajo no es trivial, para empezar tiene que luchar con
tres dificultades:
Ancho de banda.- Una película de QuickTime de 25 segundos
de 320x240 puede ocupar 2.3 MB, el cual es equivalente a 1,000
pantallas de datos textuales. Esto sería inimaginable si
quisiéramos enviarlo en las épocas iniciales de Internet.
Tráfico en Tiempo Real.- Muchas aplicaciones multimedia
requiere tráfico en tiempo real. El audio y el video deberá
emitirse a la tasa que ellos son muestreados. Si los datos no
arriban a tiempo, el proceso de emisión podría pararse donde el
oído y la visión humana pueden ser perceptibles de la calidad de
la emisión. Por ejemplo, en el caso de la telefonía sobre Internet
el oído humano puede tolerar una latencia de 250 ms. Si la
latencia supera este límite la voz se escuchará con retardo y con
baja calidad. En adición al proceso de demora, la congestión en la
red será más dificultoso para el tráfico en tiempo de real. Si la red
1
esta congestionada, el sólo efecto en el tráfico que no necesita
tiempo real tomará más tiempo para completarse, pero el caso de
los datos en tiempo real, será obsoleto, devueltos y no llegarán a
tiempo.
Interrupciones.- Los stream de datos multimedia es usualmente
interrumpida. Así se incremente el ancho de banda no se
soluciona el problema de interrupciones. Para muchas
aplicaciones multimedia, el receptor tiene un buffer limitado. Si
los datos arriban de forma rápida puede existir un overflow y
algunos datos pueden perderse y si los datos arriban demasiado
lento la aplicación podría terminarse.
Debemos añadir, que estas redes son compartidas por cientos y
millones de usuarios, donde el ancho de banda tiene un límite y
las disponibilidad y las demoras pueden ser impredecibles.
Ahora bien, cuando pensamos en trasmitir datos multimedia
sobre LAN/WAN ( software desarrollado extremadamente
caro),ATM ( soporta gran capacidad de ancho de banda,
orientado a conexión, manejo de calidad de servicio a diferentes
niveles pero pocos usuarios tienen ATM hasta tu desktop) las
soluciones están dadas, pero cuando queremos transmitir sobre
Internet esto se torna extremadamente atractivo.
De otro lado, Internet tiene un crecimiento exponencial, donde
LAN/WAN sobre IP conectadas a Internet hacen crecer más aún
Internet. Sobre esta plataforma esta girando las soluciones
multimedia, es decir, los usuarios pueden integrar datos y
multimedia en una simple red, sin efectuar inversiones en
hardware y construir interfaces para redes diversas.
En tal sentido, IP y Ethernet parecen ser más favorecidos hacia
desktop y LAN, y ATM para redes de área amplia.
Internet como una red que comparte datagramas, no es lo mejor
para tráfico en tiempo real. Es decir, para correr multimedia sobre
Internet, deberán solucionarse algunos problemas:
- Multimedia maneja tráfico denso y pesado. El
hardware no está en capacidad de manejar el suficiente
ancho de banda.
- Las aplicaciones multimedia están relacionada a
multicast (el mismo stream, no múltiples copias es
enviado a un grupo de receptores). Por ejemplo, una
videoconferencia, el video necesita ser enviado a todos
los participantes al mismo tiempo. Vídeo en vivo puede
ser enviado a miles de receptores. En conclusión, los
protocolos diseñados para aplicaciones multimedia
deberán considerar el multicast en orden de reducir el
tráfico.
- Las aplicaciones en tiempo real requieren garantizar el
ancho de banda cuando la transmisión tiene lugar. Así
que deberán existir los mecanismos para hacer una
reserva efectiva de los recursos.
- Internet es una red de datagramas de conmutación de
paquetes, donde los paquetes son ruteados
independientemente de las redes compartidas.
En 1991, una serie de experimentos fueron desarrollados por el
Network Research Group de la Lawrence Berkeley National
Laboratory, lanzando una herramienta para audio conferencia. El
protocolo usado fue referido más tarde como RTP versión 0.
William Díaz RTP/RTCP/RTSP
En diciembre 1992, Henning Schulzrinne, GMD Berlín, publica
RTP versión 1. Este documento fue entregado a la IETF, quienes
lo aprobaron como una propuesta de estándar el 22 de noviembre
de 1995,. Esta versión fue llamada RTP versión 2 y fue publicada
como:
• RFC 1889, RTP: A Transport Protocol for Real-Time
Applications [1]
• RFC 1890, RTP Profile for Audio and Video
Conferences with Minimal Control [2]
El 31 de enero de 1996, , Netscape anunció "Netscape
LiveMedia" un framework que permite entregar audio video en
tiempo real. y otros estándares. Este framework esta basado en
RTP - RFC 1889-, y otros estándares como: MPEG, H.261 y
GSM.
En marzo de 1996, Intel, Microsoft y un consorcio 100 empresas
de tecnologías prometieron construir una plataforma abierta
basada en estándares existentes a fin de "hacer comunicaciones
de video, voz y datos sobre Internet como hacer una llamada
telefónica local".
La International Multimedia Teleconferencing Consortium
(IMTC), mencionaron que esta implementación estaría basada en
los especificaciones de la International Telecommunications
Union (ITU) y la Internet Engineering Task Force (IETF),
incluyendo T.120 (para conferencia de datos), H.323 (para audio
y videoconferencia) y las especificaciones RTP/RTCP y RSVP.
En mayo de 1996, Microsoft anuncia el soporte para RTP.
El grupo de estudio 15 de la ITU, acordó utilizar RTP para
conferencias sobre LAN haciendo iteroperable con H.320.
A la fecha se han publicado RFC relacionado con RTP [3]:
! RTP: A Transport Protocol for Real-Time Applications
(RFC 1889).
! RTP Profile for Audio and Video Conferences with
Minimal Control (RFC 1890) .
! RTP payload format for H.261 video streams (RFC 2032)
! RTP Payload Format of Sun's CellB Video Encoding (RFC
2029)
! RTP Payload Format for H.263 Video Streams (RFC 2190)
RTP Payload for Redundant Audio Data (RFC 2198)
! RTP Payload Format for MPEG1/MPEG2 Video (RFC
2250)
! RTP Payload Format for Bundled MPEG (RFC 2343)
! Options for Repair of Streaming Media (RFC 2354)
! RTP Payload Format for the 1998 Version of ITU-T
Rec.H.263 Video (H.263+) (RFC 2429)
! RTP Payload Format for BT.656 Video Encoding (RFC
2431)
! RTP Payload Format for JPEG-compressed Video (RFC
2435)
! Compressing IP/UDP/RTP Headers for Low-Speed Serial
Links (RFC 2508)
! An RTP Payload Format for Generic Forward Error
Correction (RFC 2733)
! Guidelines for Writers of RTP Payload Format
Specifications (RFC 2736)
! Sampling of the Group Membership in RTP (RFC 2762)
RTP Payload for Text Conversation (RFC 2793)
! RTP Payload for DTMF Digits, Telephony Tones and
Telephony Signals (RFC 2833)
2
! RTP Payload Format for Real-Time Pointers (RFC 2862)
Real-Time Transport Protocol Management Information
Base (RFC 2959)
Registration of parityfec MIME types (RFC 3009)
! RTP payload format for MPEG-4 Audio/Visual streams
(RFC 3016)
! RTP Payload Format for ITU-T Recommendation G.722.1
(RFC 3047)
3. RTP sobre UDP y no TCP
El protocolo de control de transmisión (TCP- Transmisión
Control Procotol) es un protocolo fiable. Se esfuerza por entregar
los datos en su destino, vetifica si se producen errores, repite los
envíos cuando es necesario y sólo informa a las capas superioes
si no consigue realizar una trasnmisión correcta. El precio de la
robustez de TCP es un elevado nivel de tráfico en la red.
El protocolo de datagrama de usuario (UDP - User Datagram
Protocol) - RFC 768-, es un protocolo no fiable que realiza un
solo intento de entrega de los datos. Los datagramas son
mensajes indepedientes que se transmiten individualmente desde
otros datagramas. UDP no se esfuerza en descubrir datagramas
perdidos y los procesos de la capa superior deben encargarse de
la detección y retransmisión de los posibles datos erróneos o
incompletos. UDP genera un nivel menor de tráfico que TCP y lo
utilizan varios protocolos importantes.
TCP es un protocolo formal que requiere que los hosts
establezcan una conexión, la mantengan mientras dure la
conversación y la cierren formalmente. El tráfico adicional
necesario para mantener las conexiones queda justificado, si se
requiere una fiabilidad a toda prueba-
El UDP ofrece un transporte alternativo a aquellos procesos que
no requieren una entrega fiable. UDP es un protocolo de
datagramas que no garantiza la entrega de los datos ni protege
frente a su duplicación. Como protocolo de datagramas, UDP no
se encarga de recibir corrientes de datos ni de segmentar para IP.
Por consiguiente, UDP es un protocolo muy sencillo y mucho
más ligero que TCP.
Es por esta razón, que UDP es adecuado para: Mensajes que no
requieren acuse de recibo, e.g.: SNMP - Simple Network
Management Protocol; Mensajes entre hosts son esporádicos:
SNMP; Fiabilidad se implementa a nivel del proceso: NFS -
Network File System.
El gran interés de TCP radica en su capacidad para aislar los
procesos de la capa superior con respecto a la red. Los procesos
no necesitan conocer el tamaño de los mensajes, ya que TCP se
encarga de su fragmentación y reensamblaje. Además, los
procesos no se preocupan por la fiabilidad de la red, ya que TCP
garantiza por completo la integridad de los mensajes que
transporta.
UDP posee una cabecera de tan solo 8 octetos, mucho más
reducida que TCP que era de 20 como mínimo. Los puertos
origen y destino, de 16 bits al igual que en TCP, identifican la
conexión de ambos extremos. Existe una lista de puertos oficiales
asignada por IANA (Internet Assigned Numbers Authority).
El campo Longitud, de 16 bits, indica el número total de octetos
del mensaje UDP, cabecera y datos incluidos. Por lo tanto el
tamaño máximo es de 64 Kbytes.
William Díaz RTP/RTCP/RTSP
El campo Checksum (suma de verificación), de 16 bits, permite
realizar una suma de verificación de la cabecera y datos, de forma
opcional. En caso de no habilitarse este chequeo, se codificaría
con ceros. [4]
0 16 31
Puerto de origen Puerto destino
Longitud Suma de verificación
Figura 1: Formato de cabecera UDP
Por otra parte, UDP es un protocolo más despreocupado en la
realización de su trabajo. A diferencia de TCP, UDP no necesita
establecer circuitos virtuales entre los hosts, lo que permite una
comunicación más eficiente cuando los mensajes son informales
e independientes. Dado que TCP debe establecer conexiones
entre dos hosts, no es válido para difundir mensajes de uno a
varios hosts. En cambio, UDP admite mensajes de difusión y
multidifusión. [5]
Puerto Puerto Puerto
1 2 3
UDP-
Demultiplexing basado
en Puertops
IP Layer
Figura 2: Ejemplo de demultiplexing
Conceptualmente, todos los multiplexing y demultiplexing entre
UDP y los programas de aplicación ocurren a través de
mecanismos de puertos. En la práctica, cualquier aplicación
deberá negociar con el sistema operativo la obtención de un
puerto de protocolo y un número de puerto asociado antes de
enviar un datagrama UDP. Una vez que el puerto ha sido
asignado cualquier datagrama del programa de aplicación es
enviado a través del puerto asignado en el campo Puerto de
Origen. Mientras se esta procesando, UDP acepta nuevos
datagramas desde IP y va demultiplexando basado en el puerto
destino.
La manera más fácil de pensar de los puertos UDP es como una
cola. En muchas implementaciones, cuando una aplicación
negocia con el sistema operativo usa unos puertos dados, el
sistema operativo crea una cola interna que puede mantenerla al
arribar los mensajes. Frecuentemente, las aplicaciones puede
especificar o cambiar el tamaño de la cola. Cuando UDP recibe
un datagrama, verifica que el puerto destino empareja con el
puerto actualmente en uso. Si no, UDP envía un mensaje ICMP y
3
desecha el mensaje. Si esta emparejado, UDP desencola el nuevo
datagrama al puerto donde el programa de aplicación pueden
acceder. Si el puerto esta lleno, UDP desecha el datagrama que
ha ingresado. [6]
Para algunas aplicaciones de redes multimedia, la posibilidad de
perder paquetes es más aceptable que los costos de TCP. El
streamed de video y audio son los principales ejemplos.
Supongamos, por ejemplo, un exposición esta siendo transmitida
en vivo sobre la red. Si los datos de video estuviera utilizando
TCP, entonces cada frame podría arribar completo y en el orden
correcto, pero la tasa a la cual ellos podría arribar podría ser
imprevisible. Movimientos bruscos y pausas podría ocurrir
cuando los paquetes fueran retransmitidos y los acuses de recibo
estuvieran en espera. Inevitablemente, el display fallaría
retrazando la entrega actual de la exposición. Los pequeños fallos
técnicos causados por las ocasionales pérdidas de frame o
fragmentos de audio podría ser menos indeseado, si ellos podrían
permitir ratios de frames que sean mantenidos. [7]
En conclusión, TCP y UDP son de los más comunes protocolos
de transporte utilizado en Internet. TCP esta orientado a conexión
y fiable entre el flujo entre dos servidores, mientras UDP no es
orientado a conexión pero es poco fiable al servicio de
datagramas sobre la red.
Tabla 1 Comparación de las características de TCP y UDP
TCP UDP
Fiable No Fiable
Orientado a conexiones No orientado a conexiones
Circuito virtual Datagramas
Elevado tráfico de control Tráfico de control reducido
Segmentación de mensajes Sin segmentación ni
reensamblaje de mensajes
Segmentos de mensajes No secuenciale
secuenciales
Finalmente, UDP fue escogido como el protocolo de transporte
para RTP por dos razones:
- RTP es diseñado primariamente para multidifusión , el
TCP orientado a conexión no es escalable y no es
adecuada.
- Para datos en tiempo real, la fiabilidad no es tan
importante como entregar los datos a tiempo. Las
transmisiones provista por las retrasmisiones como en
TCP no es deseable. Por ejemplo, en una congestión de
red, muchos paquetes podrían perderse, el protocolo
insiste en transmitir y los paquetes retransmitidos
podrían incrementar el retardo, atascar la red y
eventualmente cancelar la aplicación receptora.
Tanto los paquetes RTP como RTCP son usualmente
transmitidos usando los servicios de UDP. Sin embargo, hay
esfuerzos que se están realizando para que puedan correr en:
William Díaz RTP/RTCP/RTSP
CLNP(Connectionless Network Protocol), IPX (Internetwork
Packet Exchange), AAL5/ATM.
En la práctica, RTP es usualmente implementado con la
aplicación. La recuperación de paquetes perdidos, el control de
congestión han sido implementados a nivel de aplicación.
En una sesión RTP, la aplicación define un particular par de
dirección de transporte de destino (una dirección de red más una
par de puertos RTP y RTCP). En una sesión multimedia,
cualquier media es transportada en sesiones separada RTP, con
su propio paquete de reporte RTCP se reporta la calidad de la
recepción de la sesión RTP. Por ejemplo, el audio y video podría
viajar en forma separada en sesiones RTP, disponiendo el
receptor seleccionar cualquiera o ninguno de los medios
recibidos.
En un escenario de audio conferencia presentado en el RFC 1889,
supónganse que cada participante envía un dato de audio en
segmentos de 20 ms de duración. Cada segmento de datos de
audio es precedido por una cabecera RTP, y luego el resultado
del mensaje RTP es colocado en una paquete UDP. La cabecera
RTP indica el tipo de codificación de audio que es usado: e.g.
PCM. Los usuarios pueden optar por cambiar la codificación
durante una conferencia en reacción a una congestión o por
ejemplo, acomodar los requerimientos de ancho de banda de
nuevos conferencistas participantes. La información del tiempo y
el número de secuencia en la cabecera RTP son usados por el
receptor para reconstruir el "timing" producido por la fuente, así
que los segmentos son continuamente emitidos en el receptos
cada 20 ms.
4. Cómo trabaja RTP
Como se mencionó UDP esta encima de IP, tan igual que TCP,
pero es mucho más simple, haciendo un poco más seguro que los
datagramas sean pasados a la correcta aplicación cuando ellos
lleguen a destino. Tan igual que IP, UDP sólo trata de hacer el
mejor esfuerzo en entregar los datagramas, no ofrece los
mecanismos de entrega que tiene TCP. Asimismo, los números
de puertos está incluidos en el campo de origen y destino de cada
paquete UDP, de tal forma que aseguren que sean entregados en
el lugar adecuado. UDP desarrolla algunos errores de
verificación que no son provistos por IP, ayudando asegurar que
los datagramas no están corruptos. Estas facilidades hacen que
UDP sea el protocolo en el cual se base otros protocolos (RTP)
para entregar video y audio, donde estas aplicaciones desean
estás facilidades en lugar de asegurar la entrega fiable.
El bajo coste de entrega de UDP no es suficiente, por este
propósito, RTP que típicamente corre sobre UDP, añade extra
facilidades que son necesarias para sincronizar , secuenciar e
identificar los diversos tipos de datos - o payload llamados en
este contexto.
RTP en sí, no garantiza la entrega y no previene que los paquetes
lleguen en orden errado, pero brinda los mecanismos para que las
aplicaciones reconstruyan una secuencia de paquetes y detecten si
hay alguna pérdida [7]
Las aplicaciones multimedia requiere apropiados tiempos en la
trasmisión de los datos. RTP provee mecanismos de tiempo de
fechado, secuencia numérica y otros mecanismos para tomar
cuidado de las emisiones de los tiempos. RTP provee transporte
end-to-end para datos en tiempo real sobre redes de datagramas.
4
Timestamping.- Es la más importante información de las
aplicaciones en tiempo real. El emisor establece el tiempo de
fechado de acuerdo al instante que el primer octeto del paquete
fue muestreado. El timestamps se incrementa de acuerdo al
tiempo cubierto por el paquete. Después de recibir el paquete, el
receptor usa el timestamp para reconstruir el tiempo original en
orden de emitir la data en la tasa correcta. Timestamp es usado
para sincronizar diferentes streams con los apropiados tiempos,
tales como audio y data de vídeo en MPEG. Sin embargo, RTP
no se responsabiliza por la sincronización, esto se deberá efectuar
a nivel de aplicación.
Secuencia Numérica. UDP no entrega paquetes en orden de
tiempo, así que la secuencia numérica es utilizada para colocar la
data en el correcto orden, también es usado para la detección de
paquetes perdidos. Debemos notar que cuando un frame de un
video es particionado en varios paquetes RTP, todos ellos pueden
tener el mismo tiempo de fechado. Pero justo el timestamp no es
suficiente para colocarlo en orden.
Identificador de tipo payload.- Especifica el formato de payload
así como los esquemas de codificación y compresión. Desde este
identificador, la aplicación receptora conoce como interpretar e
imitir la data. Los diversos tipos de payload están definidas en el
RFC 1890 [2]. Ejemplo de especificaciones incluye PCM, audio
y video MPEG1/MPEG2, video JPEG, video Sun CellB, video
streams H.261, y otros más [3]. En algunos tipos de transmisión,
una emisión RTP puede sólo enviar un tipo de payload, o puede
cambiar durante la transmisión para ajustar la congestión en la
red.
Identificador Origen. Permite a la aplicación receptora conocer
de donde proviene la data. Por ejemplo, en una audio
conferencia, este campo podría ser utilizado para decir quien esta
hablando.
Estos mecanismos son implementados a través de cabeceras RTP.
En la figura adjunta muestra un paquete RTP encapsulado en un
paquete UDP/IP [8]
Figura 3: Data RTP en un paquete IP
5. REAL-TIME TRANSPORT
PROTOCOL (RTP)
RTP fue usado por muchas aplicaciones en el Mbone
http://www.lbl.gov/Web/MBONE.html. RTP fue desarrollado
para el soporte de aplicaciones en tiempo real, por ejemplo,
transporte de video y audio.
RTP no es un protocolo de transporte en el sentido convencional.
No provee funciones de control de error, retrasmisión, o control
de flujo de datos. RTP no ofrece garantía sobre la calidad del
servicio o implementa reserva de recursos. En cambio, esta
William Díaz RTP/RTCP/RTSP
limitado a las funciones de protocolo frecuentemente requerida
para el transporte de datos en tiempo real, estas funciones de
protocolo puede ser expandida a las funciones de las
aplicaciones. En muchos casos, RTP esta integrado directamente
dentro de las aplicaciones.
RTP consiste de dos partes:
! Real-Time Transport Protocol (RTP) para la
transmisión de datos en tiempo real.
! Real-Time Control Protocol (RTCP) para la provisión
de retroalimentación acerca de la calidad de
transmisión e información acerca de los miembros de
una sesión.
APLICACION
RTP RTCP
UDP
IP
Figura 4: Pila de Protocolos RTP
RTP es frecuentemente usado arriba de UDP/IP (ver Figura 4).
Pero no es óbice, para que UDP/IP pue ser usado, sobre TCP o
sobre ST2. Tanto RTP como RTCP usan diferentes direcciones
de transporte permitiendo diferenciar fácilmente entre la
información de control transportada por RTCP y la data del
usuario transportada por RTP. Para este propósito, la dirección IP
son las misma para ambos RTP y RTCP, pero el número de
puerto son diferente (RTP puerto +1). Como resultado, RTCP usa
puertos impares. [9] (Ver Numeral 7: RTSP)
5.1 DESCRIPCION DATOS RTP.
Cualquier unidad de datos RTP (ver Figura 6) contiene
los siguiente campos:
! Tipo de datos de usuarios.
! Número de secuencia.
! Fechado
! Identificador de fuente sincronización.
El tipo de datos de usuario (Payload) entrega a la
aplicación una indicación del tipo de dato involucrado. Sin
embargo, el significado de este campo no esta especificado por
RTP, está definido en un profile. Las especificaciones de las
aplicaciones de RTP y los formatos de los datos de usuario está
descritos en un perfil. El perfil AVT (Audio-Video-Transport) es
frecuentemente usado por aplicaciones de videoconferencia. Este
especifica los diversos métodos de codificación para video y
audio y las tasas de muestreo. El formato de los datos en si son
especificados en otros documentos. Por decir, un perfil AVT
contiene los formatos para MPEG y H.261. Si una aplicación
reconoce este perfil utilizado, puede determinar el tipo y formato
de dato de usuario desde el campo Payload.
5

Las unidades de datos RTP son asignadas un número de
secuencia. Este número de secuencia permite al receptor detectar
las pérdida de datos, o rechazar, si mantiene un orden del mismo.
Es oportuno resaltar, que las aplicaciones son responsables de
esta tarea. RTP solo estipula que la data debería ser asignada un
número de secuencia. Sin embargo, el número de secuencia no es
interpretado por RTP.
En relación al fechado (time stamp) es incrementado en
cada muestra. La aplicación puede interpretar el fechado de la
sincronización del stream o entre diferente stream.
El identificador de fuente de sincronización (SSRC)
identifica la fuente de los datos y deberá ser única. El remitente
no deberá usar el mismo SSRC para dos stream multimedia. Por
ejemplo, deberá usar diferente SSRC para audio y video. Para
mantenerlo único es asignado en forma aleatoria. En este caso, la
probabilidad de colisión es baja. Si hubiera alguna colisión, se
deberá escoger otro SSRC y enviar un mensaje RTCP (BYE).
El campo identificador fuente de contribución (CSRC)
es usado si la data del usuario no es entregado directamente desde
el remitente. En este caso, un estación intermedia recibe los
datos, cambiando y reenviando estos datos. Un ejemplo es una
conferencia de audio con múltiples stream de audio que son
enviados por una estación intermedia que crea un simple stream.
En este caso, la fuente de los stream de datos es el sistema
intermedio que hace los cambios, el mezclador (ver Figura 5).
Sin embargo, el mezclador ingresa la lista de los SSRC dentro del
campo CSRC a fin que se conozca quien estaba enviando
originalmente los datos. El CSRC en la cabecera indica la
longitud de la lista.
PCM
Mixer
A Payload type (PT): 7 bits
PCM GSM
Translator
B puede ser usado por el receptor para detectar paquetes perdidos y
Audio Stream from A (PCM-coded)
Audio Stream from B (PCM-coded)
Mixed audio stream from A and B (PCM-coded)
Audio Stream from B (GSM-coded)
Figura 5: Mezclador y Traductor
El traductor (ver Figura 5) tiene una función similar al
mezclador, el cual envía multiples streams. Este sistema cambia
los datos, por ejemplo, para recodificar un datos de diferente
codificación., por ejemplo, desde PCM a GSM, Sin embargo,
solo un simple stream de datos es afectado.
Además, una unidad de datos puede contener extensiones
que son definidas en el perfil utilizado. El campo X en la
cabecera indica donde la cabeceras de los datos contiene esta
extensión.
Los primeros doce octetos están presentes en cada
paquete RTP, mientras que la lista de identificadores CSRC están
William Díaz
presentes sólo cuando es insertado por un mezclador. La cabecera
RTP tiene el siguiente formato [1]
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
V=2 P X CC M PT sequence number
timestamp
synchronization source (SSRC) identifier
contributing source (CSRC) identifiers
…..
Figura 6: Unidad de datos RTP
Versión (V): 2 bits.
Este campo identifica la versión del RTP.
Padding (P): 1 bit
Si el bit de relleno está activado, el paquete contiene uno o mas
octetos de rellenos, al final éstos no forman parte de los payload.
Extensión (X): 1 bit
Si esta activado, la cabecera fija está seguida por una cabecera de
extensión (Ver numeral 5.2)
Contador CSRC (CC): 4 bits
Contiene el número de identificadores CSRC que muestra la
cabecera fija.
Marker (M): 1 bit
La interpretación de un Marker es definida por un perfil. Intenta
mostrar los eventos significativos como límites de los marcos a
ser marcado en el paquete.
Identifica el formato del RTP payload, existe un conjunto de
mapeos para audio y video, el cual es especificado en el perfil.
En realidad un emisor RTP emite un simple tipo de RTP payload
en cualquier tiempo.
Sequence number: 16 bits
Es incrementado en uno para cualquier paquete RTP enviado, y
restablecer la secuencia de los paquetes.
Timestamp: 32 bits
Refleja el muestro instantáneo del primer octeto en el paquete de
datos RTP. El muestreo instantáneo deberá ser derivado desde el
reloj que incrementa monótona y linealmente en el tiempo
mostrando los cálculos de sincronización y jitter2. Es importante
selañar que desde que RTP es derivado desde el reloj de la media,
y cualquier media puede ser transportada en sesiones de RTP
separada, no es posible sincronizar desde la información
contenida en los paquetes de datos [10]
La información contenida en el Sequence number y el Timestamp
es suficiente para identificar únicamente cualquier dato de la
aplicación.
2
Jitter o distorsión FM es una forma de error en el procesamiento de la
señal
RTP/RTCP/RTSP 6

SSRC: 32 bits
Identifica la fuente de sincronización. Este identificador es
escogido en forma aleatoria, con el entendido que dos fuentes de
sincronización con la misma sesión RTP no tengan el mismo
identificador SSRC. En resumen, cada participante en una sesión
RTP es identificador a través de un identificador SSRC incluido
en cualquier paquete de datos.
CSRC list: de 0 to 15 items, 32 bits
Identifica las contribuciones de las fuentes para el payload
contenido en el paquete. El número de identificadores está
contenida en el campo CC. Si hay más de 15 fuentes
contribuidoras, sólo 15 podrían ser identificadas.
De lo descrito anteriormente podemos concluir que RTP provee
las siguientes funciones [11]
a) Secuencia: Cualquier paquete RTP contiene un número
de secuencia. Este puede ser usado para detectar
pérdidas o compensaciones para el ordenamiento.
b) Sincronización intermedia: Los paquetes con el
mismo stream pueden sufrir diferentes retardos (jitter).
Las aplicaciones usan un buffer de emisión para
compensar estos retardos. La utilización del campo
timestamps provisto por RTP ayudan a la medida de
éstas.
c) Identificación Payload.- En Internet, las condiciones
de la red así como la pérdida de paquetes o retardos
varían durante una simple llamada. Codificaciones de
charlas o video difieren en su capacidad de trabajar
apropiadamente bajo varias condiciones. De cualquier
forma, es deseable disponer las condiciones para
cambiar las codificación de la media (payload de RTP)
dinámicamente cuando las condiciones de la red varían.
Para soportar esto, RTP contiene un identificador
Payload en el cual se describe el tipo de codificación de
la media.
d) Indicador de Frame. - Video y audio son enviados en
unidades lógicas llamada frames. Es necesario indicar
al receptor cuando es el comienzo y fin de estos frames,
en virtud de ayudar a ordenar en la entrega
sincronizada a las capas altas. El campo Marker es
provisto para este propósito.
e) Identificador de Fuente: En sesiones multidifusión,
muchos usuarios están participando. Deberá existir una
forma para que los paquetes contengan un indicador a
quien son enviados. El campo SSRC es provisto para
este propósito.
5.2 EXTENSIONES DE CABECERAS.
Un mecanismo de extensión es proveído para
implementar experimentos con nuevas funciones de formatos
payload independientes que requiere información adicional en ser
transportada en la cabecera de un paquete RTP. Este mecanismo
esta diseñado a fin que la cabecera de extensión puede ser
ignorado por otras implementaciones que no han sido extendidas.
Debemos notar que esta extensión de cabecera sólo se
utilizará para uso limitado. Muchos usos potenciales de este
William Díaz RTP/RTCP/RTSP
mecanismo podría ser mejores a través de otras vías, por ejemplo
a través de un perfil específico.
0 16 31
Definido por un perfil Longitud
Extensión de Cabecera
…. ….
Si el bit X en la cabecera RTP esta activado, una cabecera
de extensión de longitud variables es añadido a la cabecera RTP,
siguiendo la lista CSRC, si esta presente. La cabecera de
extensión contiene un campo de longitud de 16 bits, que cuenta el
número de palabras de 32 bits en la extensión. Sólo una extensión
podría ser añadido a la cabecera RTP. [1]
6 REAL-TIME CONTROL PROTOCOL
(RTCP).
RTCP es el protocolo de control para RTP. Si embargo,
en lugar de controlar el protocolo, es principalmente utilizado
para el intercambio de información entre usuarios. RTCP provee
la siguiente información:
! Información de retroalimentación sobre la calidad
recibida.
! Información acerca de los datos enviados.
! Información acerca de los participantes en una sesión.
Real Time Control Protocol (RTCP)
Receiver Report
Tasa de pérdida, RTP perdidos / RTP enviados SSRC
Total paquetes perdidos desde SSRC inicio tx
Identifica origen donde el RR es generado
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
SSRC of Source
Fraction Lost Cumulative Number of Packets Lost
Extended Higher Sequence Number Received
Intearrival Jitter
…..
Last Sender Report Timestamp
Delay since Last Sender Report
Promedio de demora entre diferentes RTP durante un periodo
Último número de la secuencia recibida desde SSRC
25
La información de retroalimentación es enviada
periódicamente por cualquier receptor en un unidades de datos
denominados: RECEIVER REPORT (RR). Una data RR
contiene la siguiente información para cualquier origen:
! Ratio de pérdida.
! Número de unidades de datos RTP perdidos.
! El más alto número de secuencia recibido
! Jitter.
! NTP fechado para el último reporte recibido.
! Tiempo entre la recepción del último SENDER
REPORT y el transmitido por el RECEIVER
REPORT.
7
 La información de retroalimentación contenida en un
RECEIVER REPORT es principalmente previstas para
aplicaciones adaptativas. Los altos ratios de pérdida puede ser Real Time Control Protocol (RTCP)
igual a alta carga de la red. Consecuentemente, el remitente Source Description (SDES)
deberá reducir el ratio de transmisión en virtud de reducir la 0 1 2 3
carga de la red. Por ejemplo, en el caso de una aplicación de 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
video, el ratio de compresión podría ser cambiado a fin de V=2 P RC PT=SDES = 202 LENGTH
alcanzar un ratio de bit muy bajo. Sin embargo, los intervalos de SSRC/ CSRC_1
transmisión depende del tamaño del grupo y la disponibilidad de SDES item
ancho de banda. A mayores grupos o bajo ancho de banda, los …
intervalos de transmisión serán largos. SSRC/ CSRC_2
SDES item
…
En el caso de grupo numerosos o bajo ancho de banda
(causado por congestión), sólo un pocos reportes desde ciertos CNAME = 1 LENGTH USER AND DOMAIN NAME
participantes serán recibidos y podrían ser inútiles. Otro
NAME = 2 LENGTH COMMON NAME OF SOURCE
problema con el mecanismo de retroalimentación es un problema
de implosión ,porque la data enviada de un stream recibe EMAIL = 3 LENGTH EMAIL ADDRESS OF SOURCE
unidades de datos RTCP desde todos los receptores. Es decir, LOC = 5 LENGTH GEOGRAPHIC LOCATION OF SITE
estos reportes son enviados menos frecuentemente por grupo TOOL = 6 LENGTH NAME/VER. OF SOURCE APPL.
numerosos, el número de reportes se incrementa con el tamaño de NOTE = 7 LENGTH NOTE ABOUT THE SOURCE 26
los grupos y el remitente podría estar sobrecargado.
recepción de la calidad. Sin embargo, un participante no puede
Cualquier fuente periódicamente emite una unidad de data enviar un paquete RTCP con un período de tiempo fijo. Desade
SENDER REPORT (SR). Esta incluye un fechado para la RTP es usado por grupos multicast, estás podrían ser sesiones
estimación del tiempo durante todo el trayecto. Este fechado con cientos o miles de participantes. Si un paquete es enviado a la
podría ser utilizado para sincronizar en conjunto con el fechado vez en período fijo de tiempo la rede podría saturarse con
de RTP. El remitente utilizar SR para informar como las unidades paquetes RTCP [11]
de datos RTP y los bytes han sido enviados. Un remitente
también recibe datos RTP de otros remitentes.

Real Time Control Protocol (RTCP)

Sender Report (SR)

0 1 2 3
7 REAL-TIME STREAMING PROTOCOL
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 (RTSP).
V=2 P RC PT=SR=200/RR=201 LENGTH
SSRC OF SENDER

NTP TIMESTAMP , MOST SIGNIFICANT WORD

NTP TIMESTAMP, LEAST SIGNIFICANT WORD
RTP TIMESTAMP
SENDER’S PACKET COUNT
SENDER’S OCTECT COUNT
RECEIVER REPORT
Igual NTP pero en unidades y random de RTP
Cuando fue enviado el reporte
# RTP tx
Como se ha podido observar, RTP es adecuado para el
SENDER
INF. transporte del streaming de las medias, y puede ser utilizando
para multidifusión, pero no provee todas las funcionalidades.
Principalmente el usuario desea tener la posibilidad de iniciar,
parar o dar una pausa a la media visualizada o ir a un frame
específico. Un ejemplo podría ser para una presentación en vivo,
donde desearíamos escuchar la hora e instante de un segmento de
nuestro interés. Real-Time Streaming Protocol (RTSP) provee
# Payload Tx estas funciones. RTSP es descrito como el "protocolo de control
24
remoto VCR de Internet"

La descripción de la fuente (SDES) es un dato que contiene
información de los participantes en una sesión. Incluye detalles
tales como el nombre de los participantes, email, teléfono,
localidad y el nombre de la aplicación utilizada. El nombre
canónico (CNAME), el cual identifica al participante, es
importante la información para aplicaciones de conferencia.
Normalmente consiste de nombre de usuario y nombre de
dominio. El CNAME permite la ubicación de los participantes en
los diversos stream, tales como video o audio para una
videoconferencia. [9]
Es importante señalar, que RTCP manda que todos los
participante en una sesión (incluyendo a quien envían y recibe
media) envíen un paquete periódicamente en cual contiene la
información descrita líneas arriba. Estos paquetes son enviados a
una la misma dirección (multicast o unicast) acomo media RTP,
pero en diferente puerto. La información es enviada
periódicamente la cual contiene información sensitiva, tal como
RTSP está definido en abril de 1998 por la RFC- 2326, el
cual está definido como un protocolo de nivel de aplicación que
controla la entrega de datos con propiedades de tiempo real .
RSTP provee un marco extensible para el control de entrega bajo
demanda en tiempo real de audio y video utilizando TCP o UDP.
Antes que se inicie una sesión RTSP, el cliente deberá
obtener una Descripción de la Presentación, el cual contiene
información acerca de la media que será controlada. RTSP no
estipula el formato de la presentación, session description
protocol (SDP) es utilizado comúnmente para ese efecto, en el
caso de aplicaciones como QuickTime y RealPlayer utilizan la
información de la descripción de la presentación para adecuarlo a
sus formatos propietarios.[7]
Un descripción típica incluirá una o más anuncios de
media (media announcements), incluyendo la dirección de
transporte y el protocolo, por ejemplo RTP, así como la

William Díaz RTP/RTCP/RTSP 8

codificación utilizada y el tipo de compresión.. Cualquier stream
tendrá un rtsp:// URL, de forma tal, que permite diferenciar los Servidor al Cliente:
stream de los diversos servidores.
RSTP/1.0 200 OK
Cseq:3
Real Time Streaming Protocol (RTSP)
Comunicaciones Cliente / Servidor

Server Port Real Time Streaming Protocol (RTSP)

default (554)
TCP-Control Connection Conexiones de Control (usualmente tcp)
RTSP RTSP
Player Server
RTP Data
Port 2n tcp
RTCP Report DESCRIBE SETUP PLAY
Port 2n+1 request request request
(sincronización & pérdidas)
CLIENTE DESCRIBE SETUP PLAY
RTSP
reply (SDP) reply replay Server
Packets
Reports

37

36

RTSP utiliza una serie de mensajes para el manejo de la

medias a ser presentadas. [12]
Debemos enfatizar que los mensajes RTSP viajan
separadamente de los stream de datos. Usualmente, RTSP
{method name} URL {protocol versión }CRLF
operará por encima de TCP, así se puede asegurar la entrega del
{parameters}
mensaje, aunque podría correr fácilmente encima de UDP, donde
la eficiencia es más importante. Para el stream de datos no hay
En el caso de la petición DESCRIBE el cual informa los
selección, como explicamos anteriormente, TCP no es
mecanismos de presentación a ser visualizados, cuando el cliente
aconsejable para el transporte de la media en sí, el cuál es
obtiene el URL a través de rtsp://URL , envía un DESCRIBE, en
transportado por RTP quién corre sobre UDP. De cualquier
contraposición el servidor envía un mensaje con los
forma, hay una conexión lógica entre los datos y los mensajes
requerimientos de esa presentación.
RTSP. Por ejemplo, RTSP soporta las mismas cabeceras para el
control del caché como HTTP lo hace, pero las cabeceras son
DESCRIBE http://acme.com/expo.ram RTSP/1.0
transmitidas como parte de mensajes RTSP
Cseq:312
Accept:application/sdp, aplication/mheg

El cliente podría responder con un ACCEPT o un

SETUP, frente a esto el servidor envía un identificador de sesión 8 CONCLUSIONES.
(un arbitrario string de datos para identificar la sessión).

Cliente al Servidor:
SETUP rtsp://acme.com/expo.smil RTSP/1.0
Cseq:3
Transport: rtp/avp; unicast;client_port=6970-6971;
mode=play; client_port=6970;mode=play
Servidor al Cliente:
RTSP/1.0 200 OK
Cseq:3
Session:1234567890-2
Trasport:rtp/avp;cliente_port=6970-6971; server_port=
7970-7971
En su más simple operación, un cliente RTSP puede
enviar peticiones de PLAY al servidor de tal forma que se inicie
el envío de los datos o dar PAUSE (parada temporal). Finalmente
el cliente envía un TEARDOWN para terminar la sesión.
! RTP que nació del esfuerzo académico e impulsado por la
IETF se ha convertido en una alternativa para el trasporte de
multimedia en tiempo real sobre Internet. Empresas como
Microsoft, Apple, Real Networks han utilizado este
protocolo como mecanismo de transporte.
! Pero debemos ser cautos en la formulación de soluciones
sobre RTP - a pesar de contar con mecanismos de control de
calidad proveído por RTCP y, a nivel de aplicación con las
facilidades de RTSP -, nos enfrentamos a problemas de
ancho de banda (crítico principalmente en el usuario final) y
empaquetamiento de los IP/RTP/UDP lo cuál implica, en el
caso de transmisión de voz sin hilos, que aproximadamente
el 50% sea información de cabecera lo cual induce a un
consumo de ancho de banda y por consiguiente
subutilización del espectro radioeléctrico.

Cliente al Servidor:

TEADOWN rtsp://acme.com/expo.smil RTSP/1.0

Cseq:3
Session:1234567890-2

William Díaz RTP/RTCP/RTSP 9

9 REFERENCIAS

[1]. H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson,

``RTP: A transport protocol for real-time applications.'' IETF
Network Working Group, January 1996. RFC 1889

[2] H. Schulzrinne. RTP Profile for Audio and Video Conferences

with Minimal Control. RFC 1890.

[3]. Deffner, Bernd, The Real-Time Protocol

http://www.fokus.gmd.de/step/acontrol/node1.html

[4] G. Rubio y otros, Teleinformática (VOL II) Protocolos del

Bloque de Transporte, 1998, Editorial Ciencia 3, pág 519.

[5] D. Heywood, Redes con Microsoft TCP/IP, Prentice Hall,

páginas 145-157

[6] D. Comer, Internetworking with TCP/IP; Vol 1 Principles,

Protocols and Architecture, 1995, Prentice Hall International
Editions, pag. 185-186

[7] N. Chapman, J, Chapman, Digital multimedia, © 2000 John

Wiley & Sons, Ltd, páginas 495-512.

[8] L, Chuenlei, Multimedia over IP: RSVP, RTP, RTCP, RTCSP.

http://www.cis.ohio-state.edu/~cliu/ipmultimedia

[9] R. Wittmann, M. Zitterbart, Multicast Communication, , Morgan

Kaufmann Publishers 1999, © 2001 Academic Press, páginas
272-276

[10] C. Perkins, J. Crowcroft. Notes on the use of RTP for shared

workspace applications. Vol. 30, Nº 2, Apr. 2000.
http://www.acm.org

[11] H. Schuzrinne, The IETF Internet Telephony Architecture and

Protocols, IEEE Network, May/June 1999, pag 18-23

[12] Real Netorks, RSTP Interoperability with RealSystem Server 8,

7 December 2000.

William Díaz RTP/RTCP/RTSP 10