dit Real-time Transport Protocol RTP

Real-time Transport
Protocol
RTP
Joaquín Salvachúa
[email protected]
-1-
© Joaquín Salvachúa 2004
dit
UPM
Problema con nuevos
servicios
u TCP servía para todo excepto:
4Envío de audio
4Envío de vídeo
4Envío de información en tiempo real.
u Enfoque adaptativo no es suficiente
-2-
© Joaquín Salvachúa 2004
dit
UPM
Necesidad de un protocolo
nuevo
u TCP necesita retransmisión
4Necesidad de vencimiento de temporizador
4Puede que la información retransmitida sea
demasiado antigua.
u UDP no tiene confirmación ni datos sobre el
contenido:
u No existe concepto de calidad de servicio
(QOS).
-3-
© Joaquín Salvachúa 2004
dit
UPM
Necesidad de dos
protocolos
u RTP
4Encapsulación de trafico en tiempo real
u RTCP
4Protocolo de reserva y garantía de calidad de
servicio a determinados flujos RTP.
u Necesidad de garantías en todo el recorrido.
u Parte de un esquema mayor a nivel global.
-4-
© Joaquín Salvachúa 2004
dit
UPM
Arquitectura
-5-
© Joaquín Salvachúa 2004
dit
UPM
Objetivos
u El protocolo No garantiza nada, solo ofrece
las facilidades necesarias para hacerlo.
u No esta asociado con ninguna aplicación
concreta.
u Necesidad de una descripción de :
4Perfil de tráfico.
4Formato de codificación.
-6-
© Joaquín Salvachúa 2004
dit
UPM
Objetivos
u Ligero: Implementación simple.
u Flexible: No indica algoritmos
u Neutral frente transporte
u Escalable: Unicast, multicast, broadcast
u Separación de datos y control
u Seguro: posibilidad de encriptación y
autenticación.
-7-
© Joaquín Salvachúa 2004
dit
UPM
Característica
u Datos:
4Temporización
4Detección de perdidas
4Etiquetado de contenidos
u Control
4Realimentación de QOS
4Estimación de miembros y detección de bucles.
-8-
© Joaquín Salvachúa 2004
dit
UPM
Funcionalidad
u Segmentación realizada por UDP ó IP
u Resecuenciación de paquetes.
u Detección de perdidas para estimación
posterior.
u Sincronización entre media
4Sincronización labios y control de retrasos
u Realimentación de QOS y Velocidad
u Identificación de la fuente.
-9-
© Joaquín Salvachúa 2004
dit
UPM
Posibles piezas
u Mezcladores
4Un flujo a partir de múltiples.
4Reduce el ancho de banda.
4Aparece como una nueva fuente.
u Traducciones
4Codificación de un solo media.
4Puede ser translación de protocolo (firewall)
4Cambio de codificación (ancho de banda).
- 10 -
© Joaquín Salvachúa 2004
dit
UPM
Cabecera RTP
u Payload type: Tipo de media contenido
u SSRC: indicación de sincronización
u sequence number: ++ para detectar perdidas.
u P: padding (for encryption)
u M: marker bit; Indica comienzo de frame para delay.
u CC: content source count (for mixers)
u CSRC: lista de identificadores en mezclas.
- 11 -
© Joaquín Salvachúa 2004
dit
UPM
Cabecera RTP
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
|
|
....
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4 version (V)
4 padding (P)
4 extension (X)
- 12 -
CSRC count (CC)
marker (M)
payload type (PT)
© Joaquín Salvachúa 2004
dit
UPM
Temporización en RTP
u Incrementado en 1 por cada muestra
4 (ej., 160 for 20 ms packets @ 8000 Hz)
u Comienzo aleatorio
u Velocidad constante para el audio
4 (e.g., 8000 Hz for PCM-law, 44100 Hz for linear, 16-bit, 90
kHz for video)
u Múltiples imágenes de vídeo pueden tener el mismo
(en silencios).
- 13 -
© Joaquín Salvachúa 2004
dit
UPM
RTP en una red
u Típico : UDP, sin puerto fijo; RTCP port =
RTP port (par) + 1
u Típicamente el paquete de UDP esta
limitado a unos cientos de bytes (OS,
network, fragmentación)
u
u Necesidad de minimizar descarte y
congestón.
- 14 -
© Joaquín Salvachúa 2004
dit
UPM
RTCP ancho de banda
u Cada participante envia un paquete RTCP
para que se sepa quienes estan
escuchando.
u Ancho de banda de la sesión:
4Audio
4N * flujos de video.
- 15 -
© Joaquín Salvachúa 2004
dit
UPM
Sincronización entre flujos
u Necesidad de establecer sincronización
entre múltiples flujos (vídeo, audio,
transparencias).
u Necesidad de correlarlos tics con tiempo real
(depende de envío de temporizaciones
aleatorias).
u Correlarlas con la generación de muestras.
- 16 -
© Joaquín Salvachúa 2004
dit
UPM
RTP control protocol
u Paquetes almacenables (similares a datos).
4sender report (SR): bytes enviados y velocidad.
4 reports (RR): Jitter, Round-trip delay, perdidas.
4source description (SDES): nombre, email,
localización . . .
• CNAME (canonical name = user@host)
4explicit leave (BYE): para conocer quienes estan.
4extensions (APP): definidos por la aplicación (aún
ninguno)
- 17 -
© Joaquín Salvachúa 2004
dit
UPM
Referencias
RTP: A Transport Protocol for Real Time Applications
<http://www.ietf.org.internet-drafts/draft-ietf-avt-rtp-new02.txt>
RTP Profile for Audio and Video Conferences with Minimal
Control <http://www.ietf.org.internet-drafts/draft-ietf-avtprofile-new-04.txt>
The RTP specification is a product of the Audio Video
Transport (AVP) http://www.ietf.org/html.charters/avtcharter.html.
http://www.cs.columbia.edu/~hgs/rtp/faq.html
- 18 -
© Joaquín Salvachúa 2004
dit
UPM