Protocolos de Transmisión de Audio y Vídeo
Vicente González Ruiz
December 14, 2014
Contents
1 Real-Time Protocol (RTP) [3]
- RFC 3550.
- Usa UDP.
- Estandariza la información (como son los números de secuencia, estampas de
tiempo, el algoritmo de compresión utilizado, etc.) que utilizan la mayoría de
las aplicaciones de transmisión de audio y vídeo. El formato de la cabecera
RTP es:
7 bits 16 bits 32 bits 32 bits
+---------+----------+-------+-------------------+---------------+
| Payload | Sequence | Time | Synchronization | Miscellaneous |
| type | number | stamp | source identifier | fields |
+---------+----------+-------+-------------------+---------------+
- Donde:
- Payload type: Indica la codificación (PCM, GSM, MPEG-1, MPEG-2,
H.261, etc.). Ejemplos:
- Sequence Number: Enumera los paquetes enviados.
- Time-stamp: indica el instante en que se generó el primer bit de
datos del paquete RTP. Se utiliza para sincronizar el emisor y el
receptor.
- Synchronization source identifier: identifica al emisor del stream (la
dir IP del host no sirve porque en un host pueden generarse varios streams
(audio y vídeo por separado, por ejemplo)).
- RTP defines a standardized packet format for delivering audio and
video over IP networks. RTP is used extensively in communication and
entertainment systems that involve streaming media, such as telephony,
video teleconference applications, television services and Web-based
push-to-talk features.
- Was developed by the Audio-Video Transport Working Group of the
Internet Engineering Task Force (IETF) and first published in 1996 as
RFC 1889, superseded by RFC 3550 in 2003.
struct RTP_header {
uint2 Version = 2;
bit Padding; /* There are extra padding bytes at the end of the RTP packet. */
bit Extension; /* Presence of an Extension header. */
uint4 CSRC_Count; /* Number of CSRC (Contributing SouRCe) identifiers. */
bit Marker; /* The payload is relevant for the application. */
uint7 Payload_Type; /* Payload format (PCM, GSM, MPEG-1 ...). /
uint16 Sequence_Number;/* Packet count. */
uint32 Time_Stamp; /* Instant of the first octet in the payload. */
uint32 SSRC; /* Synchronization SouRCe identifier. */
uint32* CSRC; /* Contributing sources for the payload. */
};
2 Real-Time Control Protocol (RTCP)
- RFC 1889. Se utiliza junto con el RTP, normalmente sobre el siguiente
puerto.
- Sirve para que los miembros de una sesión RTP se intercambien
información (típicamente mediante multicasting).
- Periódicamente, se transmiten informes de estadísticas útiles para la
transmisión de audio y vídeo: número de paquetes enviados, número de
paquetes perdidos, jitter, número de hosts escuchando en una transmisiones
multicast, ....
- Su uso plantea un inconveniente, sobre todo en transmisiones multicast porque
el emisor puede llegar a recibir una gran cantidad de informes (uno por
cada oyente). En estos casos la frecuencia de envío de los informes se
decrementa en función del número de participantes en las sesiones
multicast, de forma que el RTCP consume siempre aproximadamente el
del ancho de banda.
3 Real-Time Streaming Protocol (RTSP)
- RFC 2326. Normalmente usa TCP.
- Se utiliza para controlar la transmisión de streams de audio y vídeo
almacenados (pause, rewind, play, etc.).
- El player sabe que el stream soporta todas estas acciones porque su URL es de
la forma:
- Los mensajes RTSP son muy similares a los utilizados por el protocolo FTP o
HTTP. El cliente (C:) solicita acciones y el servidor (S:) las realiza. Un ejemplo
de transmisión sería:
4 SCTP (Stream Control Transmission Protocol) [1, 2]
- Designed by the IETF Signaling Transport (SIGTRAN) Working Group
in 2000.
- Reliable UDP + congestion control (no data-flow control).
- RFC 4960.
struct SCTP_header {
uint16 Source_Port;
uint16 Destination_Port;
uint32 Verification_Tag; /* To validate the sender of this SCTP packet. */
uint16 Packet_Checksum; /* CRC32 */
};
struct SCTP_chunk {
uint8 Chunk_Type; /* Type of information contained in Chunk_Value. */
uint8 Chunk_Flags; /* Depends on the Chun_Type. */
uint16 Chunk_Length; /* Size of the STCP_chunk, in bytes. */
int32* Chunk_Value; /* Payload. */
};
struct SCTP_packet {
struct SCTP_header Header;
struct SCTP_chunk* Chunk;
};
5 QUIC (Quick UDP Internet Connections) [4]
- Created by Google Inc. in 2012.
- Encrypted/Reliable UDP + congestion control.
- Open-source but not published as a RFC.
6 ReSerVation Protocol (RSVP)
- RFC 2205.
- Permite que los hosts realicen “reservas” de ancho de banda en Internet
para transmisiones multicast.
- Las reservas expiran tras un determinado tiempo y tienen que ser
periódicamente realizadas.
- El host que reserva es el que recibe, no el que envía el stream.
- Los routers tienen que entender el RSVP y permitir las reservas.
- ¿Qué es en realidad una reserva? Para el RSVP una reserva es una
indicación para uno o varios routers de cúanto quiere recibir el receptor,
lo que no significa que se tenga que recibir.
- El RSVP se utiliza fundamentalmente en transmisiones multicast por
capas de calidad. Veamos un ejemplo donde existen 3 capas (20 Kbps, 100
Kbps y 3 Mbps):
|
El router D solicita al router B
recibir las 3 capas. |
|
El router C solicita al router B
recibir las 2 primeras capas. |
|
El router B solicita al router A
recibir las 3 capas. |
|
Hasta
H
llegan las dos primeras capas,
aunque sólo hace uso de la
primera (podría ser incapaz de
usar 2 capas). |
References
