Protocolo de transporte en tiempo real
| RTP (Protocolo de transporte en tiempo real) | |||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Familia: | Protocolo de red | ||||||||||||||||||||||||
| Área de operación: | Transporte de flujos de medios | ||||||||||||||||||||||||
| Puerto: | cualquier puerto libre, incluso superior a 1024 | ||||||||||||||||||||||||
| |||||||||||||||||||||||||
| Defecto: |
RFC 3550 (RTP: Protocolo de transporte para aplicaciones en tiempo real, 2003 ) |
||||||||||||||||||||||||
El Real-Time Transport Protocol ( RTP ) es un protocolo para la transmisión continua de datos audiovisuales ( streams ) a través de redes basadas en IP . El protocolo se estandarizó por primera vez en RFC 1889 en 1996 . En 2003 fue reemplazado por RFC 3550 .
Sirve multimedia : flujos de datos ( audio , video , texto , etc.) a través de redes para transportar, d. H. para codificar, empaquetar y enviar los datos. RTP es un protocolo basado en paquetes y normalmente se opera sobre UDP . RTP se puede utilizar tanto para conexiones de unidifusión como para comunicaciones de multidifusión en Internet. El RealTime Control Protocol (RTCP) funciona junto con RTP y se utiliza para negociar y mantener los parámetros de calidad de servicio (QoS).
Se usa en muchas áreas, que incluyen: se utiliza con los estándares de telefonía IP H.323 y SIP para transmitir los flujos de audio y video de la llamada.
La función principal de RTP es transmitir flujos de datos que requieren tiempo real , mientras que el Protocolo de transmisión en tiempo real (RTSP) se utiliza para controlar y monitorear la transmisión de datos.
El Protocolo de control de congestión de datagramas (DCCP) es un enfoque actual para permitir el control de la congestión de los flujos de medios basados en RTP / UDP.
arquitectura
- Fuente de sincronización
- La fuente de datos se denomina Fuente de sincronización (SSRC) y se identifica mediante un identificador (32 bits) en el encabezado.
- Traductor
- Un traductor reenvía los paquetes RTP entrantes mientras deja intacto el identificador SSRC. Los traductores pueden dejar los datos sin cambios y se utilizan, por ejemplo, para superar los cortafuegos . Sin embargo, también puede cambiar la codificación de los datos transmitidos; los campos Tipo de carga útil y Marca de tiempo en el encabezado deben adaptarse. La recodificación se realiza de forma transparente para el destinatario.
- mezclador
- Los mezcladores combinan los flujos de datos de varias fuentes en un nuevo flujo de datos y lo reenvían. La codificación también se puede cambiar. Dado que los flujos de datos de las fuentes a combinar no están necesariamente sincronizados, el mezclador debe generar su propia sincronización para el flujo combinado. Por esta razón, el mezclador ingresa su propio SSRC ID en el campo correspondiente para todos los paquetes salientes. Para preservar la identidad de las fuentes originales, sus identificadores SSRC se ingresan en la lista de identificadores CSRC.
- recipiente
- El destinatario de los paquetes RTP los clasifica sobre la base de los números de secuencia y los pone a disposición de la aplicación respectiva.
- Paquete RTP
- Un paquete RTP consta de un encabezado con versión y número de secuencia, formato de datos, ID del remitente y sello de tiempo y la parte de datos del usuario.
Encabezado RTP
| Byte 0 | Byte 1 | Byte 2 | Byte 3 | ||||||||||||||||||||||||||||
| Bit 0 | 1 | 2 | 3 | Cuarto | 5 | Sexto | Séptimo | Bit 0 | 1 | 2 | 3 | Cuarto | 5 | Sexto | Séptimo | Bit 0 | 1 | 2 | 3 | Cuarto | 5 | Sexto | Séptimo | Bit 0 | 1 | 2 | 3 | Cuarto | 5 | Sexto | Séptimo |
| V = 2 | pag. | X | CC | METRO. | PT | Secuencia de números | |||||||||||||||||||||||||
| Marca de tiempo (en unidades de frecuencia de muestreo) | |||||||||||||||||||||||||||||||
| Identificador de fuente de sincronización (SSRC) | |||||||||||||||||||||||||||||||
| Identificadores de fuente contributiva (CSRC) (opcional) | |||||||||||||||||||||||||||||||
| Extensión de encabezado (opcional) | |||||||||||||||||||||||||||||||
- Versión (V), 2 bit
- Estado de la versión del protocolo RTP
- Acolchado (P), 1 bit
- El bit de relleno se establece si se añaden uno o más bytes de relleno al final del paquete que no pertenecen al contenido de datos real (carga útil). El último byte de relleno indica el número de bytes de relleno añadidos. Los bytes de relleno solo son necesarios si los protocolos posteriores requieren un tamaño de bloque específico, p. Ej. B. Algoritmos de cifrado.
- Extensión (X), 1 bit
- El bit de extensión se establece cuando se agrega exactamente un encabezado de extensión al encabezado.
- Recuento de CSRC (CC), 4 bits
- El contador de CSRC indica el número de identificadores de CSRC.
- Marcador (M), 1 bit
- El bit marcador está reservado para usos específicos de la aplicación. Se utiliza para identificar eventos, p. Ej. B. la ocurrencia del final de un cuadro de una secuencia de video.
- Tipo de carga útil (PT), 7 bits
- Este campo describe el formato del contenido RTP que se va a transportar, es decir, los datos del usuario (carga útil).
| Carga útil No. | Códec | Audio Video | tasa de muestreo | Canales de audio | RFC |
| 0 | PCMU | UN. | 8 kHz | 1 | [RFC3551] |
| 3 | GSM | UN. | 8 kHz | 1 | [RFC3551] |
| Cuarto | G723 | UN. | 8 kHz | 1 | [RFC3551] |
| 5 | DVI4 | UN. | 8 kHz | 1 | [RFC3551] |
| Sexto | DVI4 | UN. | 16 kHz | 1 | [RFC3551] |
| Séptimo | LPC | UN. | 8 kHz | 1 | [RFC3551] |
| Octavo | PCMA | UN. | 8 kHz | 1 | [RFC3551] |
| 9 | G.722 | UN. | 8 kHz | 1 | [RFC3551] |
| 10 | L16 | UN. | 44,1 kHz | 2 | [RFC3551] |
| 11 | L16 | UN. | 44,1 kHz | 1 | [RFC3551] |
| 12 | QCELP | UN. | 8 kHz | 1 | [RFC3551] |
| 13 | CN | UN. | 8 kHz | 1 | [RFC3389] |
| 14 | MPA | UN. | 90 kHz | 1 | [RFC3551, RFC2250] |
| 15 | G.728 | UN. | 8 kHz | 1 | [RFC3551] |
| dieciséis | DVI4 | UN. | 11,025 kHz | 1 | |
| 17 | DVI4 | UN. | 22,05 kHz | 1 | |
| 18 | G.729 | UN. | 8 kHz | 1 | [RFC3551] |
| 25 | CelB | V | 90 kHz | [RFC3551, RFC2029] | |
| 26 | JPEG | V | 90 kHz | [RFC3551, RFC2435] | |
| 28 | Nevada | V | 90 kHz | [RFC3551] | |
| 31 | H.261 | V | 90 kHz | [RFC3551, RFC2032] | |
| 32 | Monovolumen | V | 90 kHz | [RFC3551,2250] | |
| 33 | MP2T | AV | 90 kHz | [RFC3551,2250] | |
| 34 | H.263 | V | 90 kHz | [RFC3551,2250] | |
| 96-127 | dinámica | [RFC3551] |
- Número de secuencia, 16 bits
- El número de secuencia aumenta para cada paquete de datos RTP adicional. El número de inicio se elige al azar y no se puede determinar de antemano. El destinatario puede utilizar el número de secuencia para restaurar el orden de los paquetes y reconocer la pérdida de paquetes.
- Marca de tiempo, 32 bits
- La marca de tiempo indica la hora del primer byte del paquete de datos RTP. El punto en el tiempo debe basarse en un reloj que sea continuo y lineal, de modo que se pueda garantizar la sincronicidad del flujo y se puedan determinar las diferencias de tiempo de ejecución en la ruta de transmisión (jitter). Como el número de secuencia, el valor inicial debe ser un valor aleatorio. Los paquetes sucesivos pueden tener la misma marca de tiempo si los datos transportados son, p. Ej. B. pertenecen a la misma imagen única ("fotograma de vídeo"). Los paquetes con números de secuencia consecutivos también pueden contener marcas de tiempo no consecutivas, si tales como B. en el caso de video comprimido, el orden de transmisión y reproducción no coinciden.
- SSRC, 32 bits
- Este campo se utiliza para identificar la fuente de sincronización. El valor se determina aleatoriamente para que dos fuentes dentro de la sesión RTP no tengan el mismo número de identificación.
- Lista CSRC, 0 a 15 campos cada 32 bits
- La lista CSRC se utiliza para identificar las fuentes que están contenidas en los datos de usuario de RTP. El número de campos de la lista se especifica en el campo CC. Si hay más de 15 fuentes, solo se identifican 15. La lista es insertada por mezcladores que utilizan el contenido del campo SSRC de las fuentes involucradas.
literatura
- Ulrich Trick, Frank Weber: SIP, TCP / IP y redes de telecomunicaciones. 2a edición, Oldenbourg, 2005, ISBN 978-3-486-57796-9 .
Normas y estándares
Línea principal:
- RFC 1889 - RTP: Protocolo de transporte para aplicaciones en tiempo real [1996, obsoleto]
-
RFC 3550 - RTP: Protocolo de transporte para aplicaciones en tiempo real [2003, actual]
- Adición RFC 5506 - Compatibilidad con el protocolo de control de transporte en tiempo real de tamaño reducido (RTCP): oportunidades y consecuencias [2009, actual]
- Adición RFC 5761 - Multiplexación de paquetes de control y datos RTP en un solo puerto [2010, actual]
- Adición RFC 6051 - Sincronización rápida de flujos RTP [2010, actual]
- Suplemento de RFC 7022 - Directrices para elegir nombres canónicos (CNAME) del protocolo de control RTP (RTCP) [2013, actual]
- Adición RFC 7160 - Soporte para múltiples frecuencias de reloj en una sesión RTP [2014, actual]
- Adición RFC 7164 - RTP y Leap Seconds [2014, actual]
- Adición RFC 8083 - Control de congestión multimedia: Disyuntores para sesiones de unidifusión RTP [2017, actual]
Ramal:
- RFC 1890 - Perfil RTP para conferencias de audio y video con control mínimo [1996, obsoleto]
-
RFC 3551 - Perfil RTP para conferencias de audio y video con control mínimo [2003, actual]
- Adición RFC 7007 - Actualización para eliminar DVI4 de los códecs recomendados para el perfil RTP para conferencias de audio y video con control mínimo (RTP / AVP) [2013, actual]
enlaces web
- Perfil de RTP Datos de Control (RTP / CDP) para la comunicación de máquina a máquina de aplicaciones
Evidencia individual
- ↑ Finley Breese: Comunicación en serie a través de RTP / CDP . BoD - Books on Demand, 2010, ISBN 9783839184608 , pág. [1] .