Machine Translated by Google

Grupo de trabajo de red H. Schulzrinne

Solicitud de comentarios: 3550 Universidad de Columbia S.

Obsoletos: 1889 Casner

Categoría: Seguimiento de normas Diseño de paquetes

R. Frederick Blue

Coat Systems Inc.

Diseño de

paquetes de V.
Jacobson, julio de 2003

RTP: un protocolo de transporte para aplicaciones en tiempo real

Estado de este Memo

Este documento especifica un protocolo de seguimiento de estándares de Internet para la comunidad de Internet y solicita discusión y
sugerencias para mejoras. Consulte la edición actual de los “Estándares de protocolos oficiales de Internet” (STD 1) para conocer el
estado de estandarización y el estado de este protocolo. La distribución de este memo es ilimitada.

Aviso de copyright

Copyright (C) Sociedad de Internet (2003). Reservados todos los derechos.

Abstracto

Este memorando describe RTP, el protocolo de transporte en tiempo real. RTP proporciona funciones de transporte de red de extremo a
extremo adecuadas para aplicaciones que transmiten datos en tiempo real, como audio, vídeo o datos de simulación, a través de servicios
de red de multidifusión o unidifusión. RTP no aborda la reserva de recursos y no garantiza la calidad del servicio para los servicios en
tiempo real. El transporte de datos se ve reforzado por un protocolo de control (RTCP) para permitir el monitoreo de la entrega de datos
de una manera escalable a grandes redes de multidifusión y para proporcionar una funcionalidad mínima de control e identificación.

RTP y RTCP están diseñados para ser independientes de las capas de red y transporte subyacentes.
El protocolo admite el uso de traductores y mezcladores de nivel RTP.

La mayor parte del texto de este memorando es idéntico al RFC 1889, que lo deja obsoleto. No hay cambios en los formatos de paquetes

en el cable, sólo cambios en las reglas y algoritmos que rigen cómo se utiliza el protocolo. El mayor cambio es una mejora en el algoritmo
del temporizador escalable para calcular cuándo enviar paquetes RTCP con el fin de minimizar la transmisión por encima de la velocidad
prevista cuando muchos participantes se unen a una sesión simultáneamente.

Schulzrinne, et al. Seguimiento de estándares [Página 1]

Machine Translated by Google

RFC 3550 RTP julio de 2003

Tabla de contenido

1. Introducción 5

1.1 Terminología. . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . ....... . 6

2. Escenarios de uso de RTP 6

2.1 Conferencia de audio multidifusión sencilla. . . . . . . . . . . . . . . ... . ....... . 6

2.2 Conferencia de audio y video. . . . . . . . . . . . . . . . . . . ... . ....... . 7
2.3 Mezcladores y traductores. . . . . . . . . . . . . . . . . . . . . . ... . ....... . 7

2.4 Codificaciones en capas. . . . . . . . . . . . . . . . . . . . . . . . ... . ....... . 8

3. Definiciones 8

4. Orden de bytes, alineación y formato de hora 11

5. Protocolo de transferencia de datos RTP 12

5.1 Campos de encabezado fijo RTP. . . . . . . . . . . . . . . . . . . . . ... . ....... . 12

5.2 Multiplexación de sesiones RTP. . . . . . . . . . . . . . . . . . . . ... . ....... . 15

5.3 Modificaciones específicas del perfil en el encabezado RTP. . . . . . . . . . . ....... . 15

5.3.1 Extensión del encabezado RTP. . . . . . . . . . . . . . . . . . . . . . ....... . dieciséis

6. Protocolo de control RTP: RTCP 17

6.1 Formato de paquete RTCP. . . . . . . . . . . . . . . . . . . . . . . ... . ....... . 18
6.2 Intervalo de transmisión RTCP. . . . . . . . . . . . . . . . . . . ... . ....... . 20

6.2.1 Mantener el número de miembros de la sesión. . . . . ... . ....... . 23

6.3 Reglas de envío y recepción de paquetes RTCP. . . . . . . . . . . . . ... . ....... . 24

6.3.1 Calcular el intervalo de transmisión RTCP. . . . . . ... . ....... . 25

6.3.2 Inicialización. . . . . . . . . . . . . . . . . . . . . . . . ... . ....... . 25

6.3.3 Recibir un paquete RTP o RTCP sin BYE. . . ..... . ....... . 26

6.3.4 Recibir un paquete RTCP BYE. . . . . . . . . . . . ... . ....... . 26

6.3.5 Temporización de un SSRC. . . . . . . . . . . . . . . . . . . . . . . ....... . 27

6.3.6 Vencimiento del temporizador de transmisión. . . . . . . . . . . . . . . . ....... . 27

6.3.7 Transmisión de un paquete BYE. . . . . . . . . . . . . . . ... . ....... . 27

6.3.8 Actualización que enviamos. . . . . . . . . . . . . . . . . . . . . . . . . ....... . 28

Schulzrinne, et al. Seguimiento de estándares [Página 2]

Machine Translated by Google

RFC 3550 RTP julio de 2003

6.3.9 Asignación del ancho de banda de descripción de fuente. . . . . . . . . . ....... . 28

6.4 Informes del remitente y del destinatario. . . . . . . . . . . . . . . . . . . . . . . ....... . 29

6.4.1 SR: Paquete RTCP de informe del remitente. . . . . . . . . . . . . . . . ....... . 30

6.4.2 RR: Paquete RTCP de informe del receptor. . . . . . . . . . . . . . . ....... . 35

6.4.3 Ampliación de los informes de remitente y destinatario. . . . . . . . . . ....... . 35

6.4.4 Análisis de informes de remitente y destinatario. . . . . . . . ... . ....... . 36

6.5 SDES: Paquete RTCP de descripción de origen. . . . . . . . . . . . ... . ....... . 37

6.5.1 CNAME: elemento SDES del identificador de punto final canónico. ... . ....... . 38
6.5.2 NOMBRE: Nombre de usuario Elemento SDES. . . . . . . . . . . . . . . . . ....... . 40
6.5.3 CORREO ELECTRÓNICO: Dirección de Correo Electrónico Artículo SDES. . . . . ... . ....... . 40
6.5.4 TELÉFONO: Número de teléfono Elemento SDES. . . . . . . . . . ... . ....... . 40

6.5.5 LOC: Ubicación geográfica del usuario Elemento SDES. . . . . . . . . . ....... . 41

6.5.6 HERRAMIENTA: Nombre de la aplicación o herramienta Elemento SDES. . . . . ... . ....... . 41

6.5.7 NOTA: Aviso/Estado Elemento SDES. . . . . . . . . . . . ... . ....... . 41

6.5.8 PRIV: Elemento SDES de extensiones privadas. . . . . . . . . . ... . ....... . 42

6.6 ADIÓS: Adiós paquete RTCP. . . . . . . . . . . . . . . . . . ... . ....... . 43

6.7 APLICACIÓN: Paquete RTCP definido por la aplicación. . . . . . . . . . . . . . . . ....... . 44

7. Traductores y mezcladores RTP 45

7.1 Descripción General. . . . . . . . . . . . . . . . . . . . . . . . ... . ....... . 45

7.2 Procesamiento RTCP en traductores. . . . . . . . . . . . . . . . . ... . ....... . 46

7.3 Procesamiento RTCP en mezcladores. . . . . . . . . . . . . . . . . . . . . . . ....... . 48

7.4 Mezcladores en cascada. . . . . . . . . . . . . . . . . . . . . . . . . ... . ....... . 49

8. Asignación y uso del identificador SSRC 49

8.1 Probabilidad de colisión. . . . . . . . . . . . . . . . . . . . . . ... . ....... . 49

8.2 Resolución de colisiones y detección de bucles. . . . . . . . . . . . ... . ....... . 50

8.3 Uso con codificaciones en capas. . . . . . . . . . . . . . . . . . . ... . ....... . 54

9. Seguridad 54

9.1 Confidencialidad. . . . . . . . . . . . . . . . . . . . . . . . . . . ... . ....... . 54

9.2 Autenticación e integridad del mensaje. . . . . . . . . . . . . . ... . ....... . 56

10. Control de congestión 56

Schulzrinne, et al. Seguimiento de estándares [Página 3]

Machine Translated by Google

RFC 3550 RTP julio de 2003

11. RTP sobre protocolos de red y transporte 56

12. Resumen de constantes de protocolo 12.1 58

Tipos de paquetes RTCP. . . . . . . . . . . . . . . . . . . . . . . ... . ....... . 58

12.2 Tipos de SDES. . . . . . . . . . . . . . . . . . . . . . . . . . . . ... . ....... . 58

13. Perfiles RTP y especificaciones de formato de carga útil 59

14. Consideraciones de seguridad 60

15. Consideraciones de la IANA 61

16. Declaración de derechos de propiedad intelectual 61

17. Agradecimientos 61

Apéndice A. Algoritmos 62

A.1 Verificaciones de validez del encabezado de datos RTP. . . . . . . . . . . . . . . . ... . ....... . sesenta y cinco

A.2 Verificaciones de validez del encabezado RTCP. . . . . . . . . . . . . . . . . . ... . ....... . 69

A.3 Determinación del número de paquetes esperados y perdidos. . . . . . . . . . ....... . 69

A.4 Generación de paquetes RTCP SDES. . . . . . . . . . . . . . . . ... . ....... . 70

A.5 Análisis de paquetes RTCP SDES. . . . . . . . . . . . . . . . . . ... . ....... . 71

A.6 Generación de un identificador aleatorio de 32 bits. . . . . . . . . . . . . . . . . ....... . 72

A.7 Calcular el intervalo de transmisión RTCP. . . . . . . . . . ... . ....... . 74

A.8 Estimación de la fluctuación entre llegadas. . . . . . . . . . . . . . . . . . . . ....... . 80

Apéndice B. Cambios desde RFC 1889 81

Referencias 85
Referencias normativas . . . . . . . . . . . . . . . . . . . . . . . . . . ... . ....... . 85
Referencias informativas. . . . . . . . . . . . . . . . . . . . . . . . . ... . ....... . 85

Direcciones de los autores 88

Declaración completa de derechos de autor 89

Schulzrinne, et al. Seguimiento de estándares [Página 4]

Machine Translated by Google

RFC 3550 RTP julio de 2003

1. Introducción

Este memorando especifica el protocolo de transporte en tiempo real (RTP), que proporciona servicios de entrega de extremo a
extremo para datos con características de tiempo real, como audio y vídeo interactivos. Esos servicios incluyen identificación del tipo
de carga útil, numeración secuencial, sellado de tiempo y monitoreo de entrega. Las aplicaciones normalmente ejecutan RTP sobre
UDP para utilizar sus servicios de multiplexación y suma de verificación; Ambos protocolos contribuyen con partes de la funcionalidad
del protocolo de transporte. Sin embargo, RTP se puede utilizar con otros protocolos de transporte o de red subyacentes adecuados
(consulte la Sección 11).
RTP admite la transferencia de datos a múltiples destinos mediante distribución de multidifusión si la proporciona la red subyacente.

Tenga en cuenta que RTP en sí no proporciona ningún mecanismo para garantizar la entrega oportuna ni otras garantías de calidad
de servicio, sino que depende de servicios de capa inferior para hacerlo. No garantiza la entrega ni evita la entrega desordenada, ni
asume que la red subyacente sea confiable y entregue paquetes en secuencia. Los números de secuencia incluidos en RTP permiten
al receptor reconstruir la secuencia de paquetes del remitente, pero los números de secuencia también pueden usarse para
determinar la ubicación adecuada de un paquete, por ejemplo en la decodificación de video, sin necesariamente decodificar paquetes
en secuencia.

Si bien RTP está diseñado principalmente para satisfacer las necesidades de conferencias multimedia con múltiples participantes,
no se limita a esa aplicación en particular. El almacenamiento de datos continuos, la simulación distribuida interactiva, la identificación
activa y las aplicaciones de control y medición también pueden encontrar aplicable el RTP.

Este documento define RTP y consta de dos partes estrechamente vinculadas:

• el protocolo de transporte en tiempo real (RTP), para transportar datos que tienen propiedades de tiempo real.

• el protocolo de control RTP (RTCP), para monitorear la calidad del servicio y transmitir información sobre los participantes en
una sesión en curso. El último aspecto de RTCP puede ser suficiente para sesiones “libremente controladas”, es decir, donde
no existe un control y configuración de membresía explícitos, pero no necesariamente está destinado a soportar todos los
requisitos de comunicación de control de una aplicación. Esta funcionalidad puede estar total o parcialmente incluida en un
protocolo de control de sesión independiente, que está fuera del alcance de este documento.

RTP representa un nuevo estilo de protocolo que sigue los principios de encuadre a nivel de aplicación y procesamiento de capas
integrado propuestos por Clark y Tennenhouse [10]. Es decir, RTP pretende ser maleable para proporcionar la información requerida
por una aplicación particular y, a menudo, se integrará en el procesamiento de la aplicación en lugar de implementarse como una
capa separada.
RTP es un marco de protocolo que deliberadamente no está completo. Este documento especifica aquellas funciones que se espera
que sean comunes en todas las aplicaciones para las cuales RTP sería apropiado.
A diferencia de los protocolos convencionales en los que se pueden incluir funciones adicionales haciendo el protocolo más general
o agregando un mecanismo de opción que requeriría análisis, RTP está diseñado para adaptarse mediante modificaciones y/o
adiciones a los encabezados según sea necesario. Se dan ejemplos en las Secciones 5.3 y 6.4.3.

Por lo tanto, además de este documento, una especificación completa de RTP para una aplicación particular requerirá uno o más
documentos complementarios (consulte la Sección 13):

Schulzrinne, et al. Seguimiento de estándares [Página 5]

Machine Translated by Google

RFC 3550 RTP julio de 2003

• un documento de especificación de perfil, que define un conjunto de códigos de tipo de carga útil y su correspondencia con
formatos de carga útil (por ejemplo, codificaciones de medios). Un perfil también puede definir extensiones o modificaciones
de RTP que son específicas de una clase particular de aplicaciones. Normalmente una aplicación funcionará bajo un solo
perfil. Se puede encontrar un perfil para datos de audio y video en el documento complementario RFC 3551 [1].

• documentos de especificación de formato de carga útil, que definen cómo una carga útil en particular, como un
La codificación de audio o vídeo debe transportarse en RTP.

En [11] se puede encontrar una discusión sobre los servicios y algoritmos en tiempo real para su implementación, así como una
discusión previa sobre algunas de las decisiones de diseño de RTP.

1.1 Terminología

Las palabras clave "debe", "no debe", "obligatorio", "deberá", "no deberá", "debería", "no debería", "recomendado", "puede" y
"opcional" en este documento son debe interpretarse como se describe en BCP 14, RFC 2119 [2] e indicar los niveles de requisitos
para la implementación RTP compatible.
ciones.

2. Escenarios de uso de RTP

Las siguientes secciones describen algunos aspectos del uso de RTP. Los ejemplos se eligieron para ilustrar el funcionamiento
básico de las aplicaciones que utilizan RTP, no para limitar para qué se puede utilizar RTP.
En estos ejemplos, RTP se transfiere sobre IP y UDP, y sigue las convenciones establecidas por el perfil de audio y video especificado
en el RFC 3551 complementario.

2.1 Conferencia de audio multidifusión sencilla

Un grupo de trabajo del IETF se reúne para discutir el último documento de protocolo que utiliza los servicios de multidifusión IP de
Internet para comunicaciones de voz. A través de algún mecanismo de asignación, el presidente del grupo de trabajo obtiene una
dirección de grupo de multidifusión y un par de puertos. Un puerto se utiliza para datos de audio y el otro para paquetes de control
(RTCP). Esta dirección y la información del puerto se distribuyen a los participantes previstos. Si se desea privacidad, los paquetes
de datos y control pueden cifrarse como se especifica en la Sección 9.1, en cuyo caso también se debe generar y distribuir una clave
de cifrado.
Los detalles exactos de estos mecanismos de asignación y distribución están fuera del alcance de RTP.

La aplicación de audioconferencia utilizada por cada participante de la conferencia envía datos de audio en pequeños fragmentos de,
digamos, 20 ms de duración. Cada fragmento de datos de audio está precedido por un encabezado RTP; El encabezado y los datos
RTP, a su vez, están contenidos en un paquete UDP. El encabezado RTP indica qué tipo de codificación de audio (como PCM,
ADPCM o LPC) está contenida en cada paquete para que los remitentes puedan cambiar la codificación durante una conferencia,
por ejemplo, para dar cabida a un nuevo participante que está conectado a través de un ancho de banda bajo. enlazar o reaccionar
ante indicaciones de congestión de la red.

Internet, al igual que otras redes de paquetes, ocasionalmente pierde y reordena paquetes y los retrasa por períodos de tiempo
variables. Para hacer frente a estas deficiencias, el encabezado RTP contiene sincronización

Schulzrinne, et al. Seguimiento de estándares [Página 6]

Machine Translated by Google

RFC 3550 RTP julio de 2003

información y un número de secuencia que permiten a los receptores reconstruir la sincronización producida por la fuente, de modo
que en este ejemplo, fragmentos de audio se reproducen de forma contigua en el altavoz cada 20 ms. Esta reconstrucción de
temporización se realiza por separado para cada fuente de paquetes RTP en la conferencia. El receptor también puede utilizar el
número de secuencia para estimar cuántos paquetes se están perdiendo.

Dado que los miembros del grupo de trabajo entran y salen durante la conferencia, es útil saber quién participa en cada momento y
qué tan bien están recibiendo los datos de audio. Para ello, cada instancia de la aplicación de audio en la conferencia multicast
periódicamente un informe de recepción más el nombre de su usuario en el puerto RTCP (control). El informe de recepción indica
qué tan bien se está recibiendo el hablante actual y puede usarse para controlar codificaciones adaptativas. Además del nombre de
usuario, también se puede incluir otra información de identificación sujeta a límites de control del ancho de banda. Un sitio envía el
paquete RTCP BYE (Sección 6.6) cuando abandona la conferencia.

2.2 Conferencia de audio y video

Si en una conferencia se utilizan medios de audio y vídeo, se transmiten como sesiones RTP separadas. Es decir, se transmiten
paquetes RTP y RTCP separados para cada medio utilizando dos pares de puertos UDP y/o direcciones de multidifusión diferentes.
No existe un acoplamiento directo a nivel RTP entre las sesiones de audio y video, excepto que un usuario que participa en ambas
sesiones debe usar el mismo nombre distinguido (canónico) en los paquetes RTCP para ambas para que las sesiones puedan ser

asociado.

Una motivación para esta separación es permitir que algunos participantes en la conferencia reciban solo un medio si así lo desean.
Se proporciona una explicación más detallada en la Sección 5.2. A pesar de la separación, se puede lograr una reproducción
sincronizada del audio y el vídeo de una fuente utilizando la información de temporización contenida en los paquetes RTCP para
ambas sesiones.

2.3 Mezcladores y traductores

Hasta ahora, hemos asumido que todos los sitios quieren recibir datos multimedia en el mismo formato. Sin embargo, esto puede no
ser siempre apropiado. Considere el caso en el que los participantes de un área están conectados a través de un enlace de baja
velocidad con la mayoría de los participantes de la conferencia que disfrutan de acceso a la red de alta velocidad. En lugar de
obligar a todos a utilizar una codificación de audio de menor ancho de banda y calidad reducida, se puede colocar un relé de nivel
RTP llamado mezclador cerca del área de bajo ancho de banda. Este mezclador resincroniza los paquetes de audio entrantes para
reconstruir el espaciado constante de 20 ms generado por el remitente, mezcla estos flujos de audio reconstruidos en un solo flujo,
traduce la codificación de audio a una de menor ancho de banda y reenvía el flujo de paquetes de menor ancho de banda a través
del enlace de baja velocidad.
Estos paquetes pueden ser de unidifusión a un único destinatario o de multidifusión en una dirección diferente a varios destinatarios.
El encabezado RTP incluye un medio para que los mezcladores identifiquen las fuentes que contribuyeron a un paquete mixto de
modo que se pueda proporcionar una indicación correcta del hablante a los receptores.

Algunos de los participantes previstos en la audioconferencia pueden estar conectados con enlaces de gran ancho de banda, pero
es posible que no sean accesibles directamente a través de multidifusión IP. Por ejemplo, podrían estar detrás de un firewall a nivel
de aplicación que no dejará pasar ningún paquete IP. Para estos sitios, la mezcla puede no ser necesaria, en cuyo caso se puede
utilizar otro tipo de retransmisión de nivel RTP llamado traductor.

Schulzrinne, et al. Seguimiento de estándares [Página 7]

Machine Translated by Google

RFC 3550 RTP julio de 2003

Se instalan dos traductores, uno a cada lado del firewall, y el exterior canaliza todos los paquetes de multidifusión recibidos a través
de una conexión segura al traductor dentro del firewall. El traductor dentro del firewall los envía nuevamente como paquetes de
multidifusión a un grupo de multidifusión restringido a la red interna del sitio.

Los mezcladores y traductores pueden diseñarse para una variedad de propósitos. Un ejemplo es un mezclador de vídeo que escala
las imágenes de personas individuales en secuencias de vídeo separadas y las combina en una sola secuencia de vídeo para simular
una escena grupal. Otros ejemplos de traducción incluyen la conexión de un grupo de hosts que hablan solo IP/UDP a un grupo de
hosts que entienden solo ST­II, o la traducción de codificación paquete por paquete de transmisiones de video de fuentes individuales
sin resincronización ni mezcla. Los detalles del funcionamiento de mezcladores y traductores se dan en la Sección 7.

2.4 Codificaciones en capas

Las aplicaciones multimedia deberían poder ajustar la velocidad de transmisión para que coincida con la capacidad del receptor o
para adaptarse a la congestión de la red. Muchas implementaciones sitúan la responsabilidad de la adaptabilidad de la velocidad en
la fuente. Esto no funciona bien con la transmisión multidifusión debido a los requisitos conflictivos de ancho de banda de receptores
heterogéneos. El resultado suele ser un escenario de mínimo común denominador, donde el conducto más pequeño en la malla de
la red dicta la calidad y fidelidad de la “transmisión” multimedia en vivo en general.

En cambio, la responsabilidad de la adaptación de la velocidad puede recaer en los receptores combinando una codificación en
capas con un sistema de transmisión en capas. En el contexto de la multidifusión RTP sobre IP, la fuente puede dividir las capas
progresivas de una señal representada jerárquicamente en múltiples sesiones RTP, cada una de las cuales se transmite en su propio
grupo de multidifusión. Luego, los receptores pueden adaptarse a la heterogeneidad de la red y controlar su ancho de banda de
recepción uniéndose solo al subconjunto apropiado de los grupos de multidifusión.

Los detalles del uso de RTP con codificaciones en capas se dan en las Secciones 6.3.9, 8.3 y 11.

3. Definiciones

Carga útil RTP: los datos transportados por RTP en un paquete, por ejemplo, muestras de audio o datos de vídeo comprimidos. El
formato y la interpretación de la carga útil están fuera del alcance de este documento.

Paquete RTP: un paquete de datos que consta del encabezado RTP fijo, una lista posiblemente vacía de fuentes contribuyentes
(ver más abajo) y los datos de carga útil. Algunos protocolos subyacentes pueden requerir que se defina una encapsulación
del paquete RTP. Normalmente, un paquete del protocolo subyacente contiene un único paquete RTP, pero se pueden
contener varios paquetes RTP si lo permite el método de encapsulación (consulte la Sección 11).

Paquete RTCP: paquete de control que consta de una parte de encabezado fijo similar a la de los paquetes de datos RTP, seguida
de elementos estructurados que varían según el tipo de paquete RTCP.
Los formatos se definen en la Sección 6. Normalmente, varios paquetes RTCP se envían juntos como un paquete RTCP
compuesto en un único paquete del protocolo subyacente; esto está habilitado por el campo de longitud en el encabezado
fijo de cada paquete RTCP.

Schulzrinne, et al. Seguimiento de estándares [Página 8]

Machine Translated by Google

RFC 3550 RTP julio de 2003

Puerto: La “abstracción que utilizan los protocolos de transporte para distinguir entre múltiples destinos dentro de una computadora
host determinada. Los protocolos TCP/IP identifican puertos utilizando pequeños números enteros positivos”.
[12] Los selectores de transporte (TSEL) utilizados por la capa de transporte OSI son equivalentes a puertos.
RTP depende del protocolo de capa inferior para proporcionar algún mecanismo, como puertos, para multiplexar los paquetes
RTP y RTCP de una sesión.

Dirección de transporte: la combinación de una dirección de red y un puerto que identifica un punto final de nivel de transporte, por
ejemplo, una dirección IP y un puerto UDP. Los paquetes se transmiten desde una dirección de transporte de origen a una
dirección de transporte de destino.

Tipo de medio RTP: un tipo de medio RTP es la colección de tipos de carga útil que se pueden transportar dentro de una única
sesión RTP. El perfil RTP asigna tipos de medios RTP a tipos de carga útil RTP.

Sesión multimedia: un conjunto de sesiones RTP simultáneas entre un grupo común de participantes.
Por ejemplo, una videoconferencia (que es una sesión multimedia) puede contener una sesión RTP de audio y una sesión
RTP de vídeo.

Sesión RTP: una asociación entre un conjunto de participantes que se comunican con RTP. Un participante puede participar en
varias sesiones de RTP al mismo tiempo. En una sesión multimedia, cada medio normalmente se transporta en una sesión
RTP separada con sus propios paquetes RTCP, a menos que la codificación misma multiplexe múltiples medios en un solo
flujo de datos. Un participante distingue múltiples sesiones RTP mediante la recepción de diferentes sesiones utilizando
diferentes pares de direcciones de transporte de destino, donde un par de direcciones de transporte comprende una dirección
de red más un par de puertos para RTP y RTCP. Todos los participantes en una sesión RTP pueden compartir un par de
direcciones de transporte de destino común, como en el caso de multidifusión IP, o los pares pueden ser diferentes para cada
participante, como en el caso de direcciones de red y pares de puertos de unidifusión individuales. En el caso de unidifusión,
un participante puede recibir de todos los demás participantes en la sesión utilizando el mismo par de puertos, o puede utilizar
un par de puertos distintos para cada uno.

La característica distintiva de una sesión RTP es que cada una mantiene un espacio completo e independiente de
identificadores SSRC (que se definen a continuación). El conjunto de participantes incluidos en una sesión RTP consta de
aquellos que pueden recibir un identificador SSRC transmitido por cualquiera de los participantes ya sea en RTP como SSRC
o CSRC (también definido a continuación) o en RTCP. Por ejemplo, considere una conferencia a tres implementada mediante
UDP de unidifusión en la que cada participante recibe de los otros dos en pares de puertos separados. Si cada participante
envía comentarios RTCP sobre los datos recibidos de otro participante solo a ese participante, entonces la conferencia se
compone de tres sesiones RTP punto a punto separadas. Si cada participante proporciona comentarios RTCP sobre la
recepción de otro participante a los otros dos participantes, entonces la conferencia se compone de una sesión RTP de
múltiples partes. El último caso simula el comportamiento que ocurriría con la comunicación IP multicast entre los tres
participantes.

El marco RTP permite las variaciones definidas aquí, pero un protocolo de control particular o un diseño de aplicación
generalmente impondrá restricciones a estas variaciones.

Fuente de sincronización (SSRC): la fuente de un flujo de paquetes RTP, identificada por un identificador SSRC numérico de 32 bits
incluido en el encabezado RTP para no depender de la dirección de red. Todos los paquetes de una fuente de sincronización
forman parte del mismo tiempo y secuencia.

Schulzrinne, et al. Seguimiento de estándares [Página 9]

Machine Translated by Google

RFC 3550 RTP julio de 2003

espacio numérico, por lo que un receptor agrupa paquetes por fuente de sincronización para su reproducción. Ejemplos de
fuentes de sincronización incluyen el remitente de un flujo de paquetes derivados de una fuente de señal como un micrófono
o una cámara, o un mezclador RTP (ver más abajo). Una fuente de sincronización puede cambiar su formato de datos, por
ejemplo, codificación de audio, con el tiempo. El identificador SSRC es un valor elegido aleatoriamente destinado a ser
globalmente único dentro de una sesión RTP particular (consulte la Sección 8). No es necesario que un participante utilice el
mismo identificador SSRC para todas las sesiones RTP en una sesión multimedia; la vinculación de los identificadores SSRC
se proporciona a través de RTCP (consulte la Sección 6.5.1). Si un participante genera múltiples transmisiones en una sesión
RTP, por ejemplo desde cámaras de video separadas, cada una debe identificarse como un SSRC diferente.

Fuente contribuyente (CSRC): una fuente de un flujo de paquetes RTP que ha contribuido al flujo combinado producido por un
mezclador RTP (ver más abajo). El mezclador inserta una lista de los identificadores SSRC de las fuentes que contribuyeron
a la generación de un paquete en particular en el encabezado RTP de ese paquete. Esta lista se llama lista CSRC. Una
aplicación de ejemplo es la audioconferencia en la que un mezclador indica todos los hablantes cuya voz se combinó para
producir el paquete saliente, lo que permite al receptor indicar el hablante actual, aunque todos los paquetes de audio
contengan el mismo identificador SSRC (el del mezclador).

Sistema final: una aplicación que genera el contenido a enviar en paquetes RTP y/o consume el contenido de los paquetes RTP
recibidos. Un sistema final puede actuar como una o más fuentes de sincronización en una sesión RTP particular, pero
normalmente solo una.

Mezclador: un sistema intermedio que recibe paquetes RTP de una o más fuentes, posiblemente cambia el formato de los datos,
combina los paquetes de alguna manera y luego reenvía un nuevo paquete RTP. Dado que la sincronización entre múltiples
fuentes de entrada generalmente no estará sincronizada, el mezclador realizará ajustes de sincronización entre las
transmisiones y generará su propia sincronización para la transmisión combinada. Por lo tanto, se identificará que todos los
paquetes de datos que se originan en un mezclador tienen el mezclador como fuente de sincronización.

Traductor: un sistema intermedio que reenvía paquetes RTP con su identificador de fuente de sincronización intacto. Ejemplos de
traductores incluyen dispositivos que convierten codificaciones sin mezclar, replicadores de multidifusión a unidifusión y filtros
a nivel de aplicación en firewalls.

Monitor: una aplicación que recibe paquetes RTCP enviados por los participantes en una sesión RTP, en particular los informes
de recepción, y estima la calidad actual del servicio para monitoreo de distribución, diagnóstico de fallas y estadísticas a
largo plazo. Es probable que la función de monitor esté integrada en las aplicaciones que participan en la sesión, pero
también puede ser una aplicación separada que de otro modo no participa y no envía ni recibe los paquetes de datos RTP
(ya que están en un puerto separado). . Estos se denominan monitores de terceros. También es aceptable que un monitor
externo reciba los paquetes de datos RTP pero no envíe paquetes RTCP ni se cuente de otro modo en la sesión.

No RTP significa: Protocolos y mecanismos que pueden ser necesarios además de RTP para proporcionar un servicio utilizable. En
particular, para conferencias multimedia, un protocolo de control puede distribuir direcciones y claves de multidifusión para el
cifrado, negociar el algoritmo de cifrado que se utilizará y definir asignaciones dinámicas entre los valores del tipo de carga
útil RTP y los formatos de carga útil que representan para formatos que no tienen un valor predefinido. valor del tipo de carga
útil. Ejemplos de tales

Schulzrinne, et al. Seguimiento de estándares [Página 10]

Machine Translated by Google

RFC 3550 RTP julio de 2003

Los protocolos incluyen el Protocolo de inicio de sesión (SIP) (RFC 3261 [13]), la Recomendación ITU H.323 [14] y
aplicaciones que utilizan SDP (RFC 2327 [15]), como RTSP (RFC 2326 [16]).
Para solicitudes sencillas, también se puede utilizar el correo electrónico o una base de datos de conferencias. La
especificación de dichos protocolos y mecanismos está fuera del alcance de este documento.

4. Orden de bytes, alineación y formato de hora

Todos los campos de números enteros se transportan en el orden de bytes de la red, es decir, el byte más significativo (octeto)
primero. Este orden de bytes se conoce comúnmente como big­endian. El orden de transmisión se describe en detalle en [3,
Apéndice A]. A menos que se indique lo contrario, las constantes numéricas están en decimal (base 10).

Todos los datos del encabezado están alineados a su longitud natural, es decir, los campos de 16 bits están alineados en desplazamientos
pares, los campos de 32 bits están alineados en desplazamientos divisibles por cuatro, etc. Los octetos designados como relleno tienen el valor cero.

La hora del reloj de pared (fecha y hora absolutas) se representa utilizando el formato de marca de tiempo del Protocolo de hora de
red (NTP), que está en segundos en relación con las 0 h UTC del 1 de enero de 1900 [4]. La marca de tiempo NTP de resolución
completa es un número de punto fijo sin signo de 64 bits con la parte entera en los primeros 32 bits y la parte fraccionaria en los
últimos 32 bits. En algunos campos donde es apropiada una representación más compacta, sólo se utilizan los 32 bits del medio; es
decir, los 16 bits inferiores de la parte entera y los 16 bits superiores de la parte fraccionaria. Los 16 bits superiores de la parte entera
deben determinarse de forma independiente.

No se requiere una implementación para ejecutar el protocolo de tiempo de red para poder utilizar RTP. Se pueden utilizar otras
fuentes de tiempo, o ninguna (consulte la descripción del campo de marca de tiempo NTP en la Sección 6.4.1). Sin embargo,
ejecutar NTP puede resultar útil para sincronizar transmisiones transmitidas desde hosts separados.

La marca de tiempo NTP llegará a cero en algún momento del año 2036, pero para fines de RTP, solo se utilizan diferencias entre
pares de marcas de tiempo NTP. Siempre que se pueda suponer que los pares de marcas de tiempo tienen una diferencia de 68
años entre sí, el uso de aritmética modular para restas y comparaciones hace que el ajuste sea irrelevante.

Schulzrinne, et al. Seguimiento de estándares [Página 11]

Machine Translated by Google

RFC 3550 RTP julio de 2003

5. Protocolo de transferencia de datos RTP

5.1 Campos de encabezado fijo RTP

El encabezado RTP tiene el siguiente formato:

0123
01234567890123456789012345678901
+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­ +­+­+­+­+­+­+­+
|V=2|P|X| CC |M| PT | secuencia de números |
+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­ +­+­+­+­+­+­+­+
| marca de tiempo |
+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­ +­+­+­+­+­+­+­+
| identificador de fuente de sincronización (SSRC) |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+= +=+=+=+=+=+=+=+

Identificadores de fuente contribuyente (CSRC) |

|| .... |
+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­ +­+­+­+­+­+­+­+

Los primeros doce octetos están presentes en cada paquete RTP, mientras que la lista de identificadores CSRC está presente
sólo cuando se inserta con una batidora. Los campos tienen el siguiente significado:

versión (V): 2 bits

Este campo identifica la versión de RTP. La versión definida por esta especificación es dos (2).
(El valor 1 es utilizado por la primera versión borrador de RTP y el valor 0 es utilizado por el protocolo
implementado inicialmente en la herramienta de audio “vat”).

relleno (P): 1 bit

Si el bit de relleno está activado, el paquete contiene uno o más octetos de relleno adicionales en el
extremo que no forman parte de la carga útil. El último octeto del relleno contiene un recuento de
cuántos octetos de relleno deben ignorarse, incluido él mismo. Es posible que se necesite relleno
algunos algoritmos de cifrado con tamaños de bloque fijos o para transportar varios paquetes RTP en un
unidad de datos de protocolo de capa inferior.

extensión (X): 1 bit

Si el bit de extensión está activado, el encabezado fijo debe ir seguido exactamente de una extensión de encabezado,
con un formato definido en la Sección 5.3.1.

Recuento CSRC (CC): 4 bits

El recuento de CSRC contiene la cantidad de identificadores de CSRC que siguen al encabezado fijo.

marcador (M): 1 bit

La interpretación del marcador está definida por un perfil. Su objetivo es permitir importantes
eventos tales como límites de trama que se marcarán en el flujo de paquetes. Un perfil puede definir
bits de marcador adicionales o especificar que no hay ningún bit de marcador cambiando el número de bits
en el campo tipo de carga útil (consulte la Sección 5.3).

Schulzrinne, et al. Seguimiento de estándares [Pagina 12]

Machine Translated by Google

RFC 3550 RTP julio de 2003

tipo de carga útil (PT): 7 bits Este

campo identifica el formato de la carga útil RTP y determina su interpretación por parte de la aplicación. Un perfil puede
especificar una asignación estática predeterminada de códigos de tipo de carga útil a formatos de carga útil. Se pueden
definir códigos de tipo de carga útil adicionales dinámicamente a través de medios que no sean RTP (consulte la Sección 3).
En el documento complementario RFC 3551 [1] se especifica un conjunto de asignaciones predeterminadas para audio y
vídeo. Una fuente RTP puede cambiar el tipo de carga útil durante una sesión, pero este campo no debe usarse para
multiplexar flujos de medios separados (consulte la Sección 5.2).

Un receptor debe ignorar los paquetes con tipos de carga útil que no comprende.

número de secuencia: 16 bits El

número de secuencia se incrementa en uno por cada paquete de datos RTP enviado y puede ser utilizado por el receptor
para detectar la pérdida de paquetes y restaurar la secuencia de paquetes. El valor inicial del número de secuencia debe ser
aleatorio (impredecible) para dificultar los ataques de texto plano conocido al cifrado, incluso si la fuente misma no cifra según
el método de la Sección 9.1, porque los paquetes pueden fluir a través de un traductor que sí lo haga. . Las técnicas para
elegir números impredecibles se analizan en [17].

marca de tiempo: 32 bits

La marca de tiempo refleja el instante de muestreo del primer octeto en el paquete de datos RTP. El instante de muestreo
debe derivarse de un reloj que aumenta monótonamente y linealmente en el tiempo para permitir la sincronización y los
cálculos de fluctuación (consulte la Sección 6.4.1). La resolución del reloj debe ser suficiente para la precisión de
sincronización deseada y para medir la fluctuación de llegada de paquetes (un tick por fotograma de vídeo normalmente
no es suficiente). La frecuencia del reloj depende del formato de los datos transportados como carga útil y se especifica
estáticamente en el perfil o la especificación del formato de carga útil que define el formato, o puede especificarse
dinámicamente para formatos de carga útil definidos a través de medios que no son RTP. Si los paquetes RTP se generan
periódicamente, se debe utilizar el instante de muestreo nominal determinado a partir del reloj de muestreo, no una lectura
del reloj del sistema. Por ejemplo, para audio de velocidad fija, el reloj de marca de tiempo probablemente se incrementaría
en uno por cada período de muestreo. Si una aplicación de audio lee bloques que cubren 160 períodos de muestreo desde
el dispositivo de entrada, la marca de tiempo se incrementaría en 160 para cada uno de esos bloques, independientemente
de si el bloque se transmite en un paquete o se descarta como silencioso.

El valor inicial de la marca de tiempo debe ser aleatorio, al igual que el número de secuencia. Varios paquetes RTP
consecutivos tendrán marcas de tiempo iguales si se generan (lógicamente) a la vez, por ejemplo, si pertenecen al mismo
cuadro de vídeo. Los paquetes RTP consecutivos pueden contener marcas de tiempo que no son monótonas si los datos no
se transmiten en el orden en que se muestrearon, como en el caso de los fotogramas de vídeo interpolados MPEG. (Los
números de secuencia de los paquetes transmitidos seguirán siendo monótonos).

Las marcas de tiempo RTP de diferentes flujos de medios pueden avanzar a diferentes velocidades y, por lo general, tienen
compensaciones aleatorias e independientes. Por lo tanto, aunque estas marcas de tiempo son suficientes para reconstruir
la sincronización de una única transmisión, comparar directamente las marcas de tiempo RTP de diferentes medios no es
eficaz para la sincronización. En cambio, para cada medio, la marca de tiempo RTP se relaciona con el instante de muestreo
emparejándolo con una marca de tiempo de un reloj de referencia (reloj de pared) que representa el momento en que se
muestrearon los datos correspondientes a la marca de tiempo RTP. El reloj de referencia es compartido por todos los medios
que se van a sincronizar. la marca de tiempo

Schulzrinne, et al. Seguimiento de estándares [Página 13]

Machine Translated by Google

RFC 3550 RTP julio de 2003

Los pares no se transmiten en todos los paquetes de datos, sino a una velocidad más baja en los paquetes RTCP SR, como
se describe en la Sección 6.4.

El instante de muestreo se elige como punto de referencia para la marca de tiempo RTP porque es conocido por el punto
final de transmisión y tiene una definición común para todos los medios, independientemente de los retrasos de codificación
u otro procesamiento. El objetivo es permitir la presentación sincronizada de todos los medios muestreados al mismo tiempo.

Las aplicaciones que transmiten datos almacenados en lugar de datos muestreados en tiempo real suelen utilizar una línea
de tiempo de presentación virtual derivada del tiempo del reloj de pared para determinar cuándo se debe presentar el
siguiente cuadro u otra unidad de cada medio en los datos almacenados. En este caso, la marca de tiempo RTP reflejaría el
tiempo de presentación de cada unidad. Es decir, la marca de tiempo RTP para cada unidad estaría relacionada con la hora
del reloj de pared en la que la unidad se actualiza en la línea de tiempo de presentación virtual. La presentación real ocurre
algún tiempo después, según lo determine el receptor.

Un ejemplo que describe una narración de audio en vivo de un vídeo pregrabado ilustra la importancia de elegir el instante
de muestreo como punto de referencia. En este escenario, el vídeo se presentaría localmente para que lo vea el narrador y
se transmitiría simultáneamente mediante RTP. El "instante de muestreo" de un fotograma de vídeo transmitido en RTP se
establecería haciendo referencia a su marca de tiempo con la hora del reloj de pared en el que se presentó ese fotograma de
vídeo al narrador. El instante de muestreo para los paquetes RTP de audio que contienen el discurso del narrador se
establecería haciendo referencia al mismo tiempo del reloj de pared cuando se muestreó el audio.

El audio y el vídeo pueden incluso ser transmitidos por diferentes hosts si los relojes de referencia de los dos hosts están
sincronizados por algún medio como NTP. Luego, un receptor puede sincronizar la presentación de los paquetes de audio y
video relacionando sus marcas de tiempo RTP utilizando los pares de marcas de tiempo en los paquetes RTCP SR.

SSRC: 32 bits
El campo SSRC identifica la fuente de sincronización. Este identificador debe elegirse al azar, con la intención de que no
haya dos fuentes de sincronización dentro de la misma sesión RTP que tengan el mismo identificador SSRC. En el Apéndice
A.6 se presenta un algoritmo de ejemplo para generar un identificador aleatorio. Aunque la probabilidad de que varias fuentes
elijan el mismo identificador es baja, todas las implementaciones de RTP deben estar preparadas para detectar y resolver
colisiones.
La Sección 8 describe la probabilidad de colisión junto con un mecanismo para resolver colisiones y detectar bucles de
reenvío a nivel RTP basados en la unicidad del identificador SSRC. Si una fuente cambia su dirección de transporte de origen,
también debe elegir un nuevo identificador SSRC para evitar que se interprete como una fuente en bucle (consulte la Sección
8.2).

Lista CSRC: de 0 a 15 elementos, 32 bits cada uno.

La lista CSRC identifica las fuentes que contribuyen a la carga útil contenida en este paquete.
El número de identificadores viene dado por el campo CC. Si hay más de 15 fuentes contribuyentes, sólo se pueden identificar
15. Los mezcladores insertan los identificadores CSRC (consulte la Sección 7.1), utilizando los identificadores SSRC de las
fuentes contribuyentes. Por ejemplo, para paquetes de audio, se enumeran los identificadores SSRC de todas las fuentes
que se mezclaron para crear un paquete, lo que permite una indicación correcta del hablante en el receptor.

Schulzrinne, et al. Seguimiento de estándares [Página 14]

Machine Translated by Google

RFC 3550 RTP julio de 2003

5.2 Multiplexación de sesiones RTP

Para un procesamiento de protocolo eficiente, se debe minimizar el número de puntos de multiplexación, como se describe en el
principio de diseño de procesamiento de capa integrada [10]. En RTP, la multiplexación la proporciona la dirección de transporte de
destino (dirección de red y número de puerto), que es diferente para cada sesión RTP. Por ejemplo, en una teleconferencia compuesta
de medios de audio y vídeo codificados por separado, cada medio debe transportarse en una sesión RTP separada con su propia
dirección de transporte de destino.

No se deben transportar transmisiones de audio y video separadas en una sola sesión RTP ni demultiplexar según el tipo de carga
útil o los campos SSRC. Intercalar paquetes con diferentes tipos de medios RTP pero usando el mismo SSRC introduciría varios
problemas:

1. Si, digamos, dos transmisiones de audio compartieran la misma sesión RTP y el mismo valor SSRC, y una cambiara las
codificaciones y, por lo tanto, adquiriera un tipo de carga útil RTP diferente, no habría una forma general de identificar qué
transmisión había cambiado las codificaciones.

2. Un SSRC se define para identificar un único espacio de número de secuencia y temporización. Intercalar múltiples tipos de
carga útil requeriría diferentes espacios de tiempo si las velocidades de reloj de los medios difieren y requeriría diferentes
espacios de números de secuencia para indicar qué tipo de carga sufrió la pérdida de paquetes.

3. Los informes del remitente y del receptor RTCP (consulte la Sección 6.4) solo pueden describir un tiempo y
espacio de número de secuencia por SSRC y no lleva un campo de tipo de carga útil.

4. Un mezclador RTP no podría combinar flujos entrelazados de medios incompatibles en

una corriente.

5. Llevar múltiples medios en una sesión RTP excluye: el uso de diferentes rutas de red o asignaciones de recursos de red, si
corresponde; recepción de un subconjunto de medios si se desea, por ejemplo sólo audio si el vídeo excede el ancho de
banda disponible; e implementaciones de receptor que utilizan procesos separados para los diferentes medios, mientras que
el uso de sesiones RTP separadas permite implementaciones de proceso único o múltiple.

Usar un SSRC diferente para cada medio pero enviarlos en la misma sesión RTP evitaría los primeros tres problemas pero no los
dos últimos.

Por otro lado, multiplexar múltiples fuentes relacionadas del mismo medio en una sesión RTP usando diferentes valores SSRC es la
norma para sesiones de multidifusión. Los problemas enumerados anteriormente no se aplican: un mezclador RTP puede combinar
múltiples fuentes de audio, por ejemplo, y se aplica el mismo tratamiento a todas ellas. También puede ser apropiado multiplexar
flujos del mismo medio usando diferentes valores SSRC en otros escenarios donde los dos últimos problemas no se aplican.

5.3 Modificaciones específicas del perfil al encabezado RTP

Se cree que el encabezado del paquete de datos RTP existente está completo para el conjunto de funciones requeridas en común
en todas las clases de aplicaciones que RTP podría admitir. Sin embargo, de acuerdo con el principio de diseño de ALF, el
encabezado puede adaptarse mediante modificaciones o adiciones definidas

Schulzrinne, et al. Seguimiento de estándares [Página 15]

Machine Translated by Google

RFC 3550 RTP julio de 2003

en una especificación de perfil y al mismo tiempo permitir que las herramientas de monitoreo y registro independientes del perfil
función.

• El bit de marcador y el campo de tipo de carga útil transportan información específica del perfil, pero están asignados
en el encabezado fijo, ya que se espera que muchas aplicaciones los necesiten y, de lo contrario, podrían
Tienes que agregar otra palabra de 32 bits solo para contenerlos. El octeto que contiene estos campos puede ser
redefinido por un perfil para adaptarse a diferentes requisitos, por ejemplo con más o menos marcador
bits. Si hay bits marcadores, uno debe ubicarse en el bit más significativo del
octeto, ya que los monitores independientes del perfil pueden observar una correlación entre
patrones de pérdida y el bit marcador.

• Información adicional que se requiere para un formato de carga útil particular, como un video
codificación, debe transportarse en la sección de carga útil del paquete. Esto podría estar en un encabezado.
que siempre está presente al inicio de la sección de carga útil, o puede estar indicado por un reservado
valor en el patrón de datos.

• Si una clase particular de aplicaciones necesita funcionalidad adicional independientemente del

formato de carga útil, el perfil bajo el cual operan esas aplicaciones debe definir campos fijos adicionales.
para seguir inmediatamente después del campo SSRC del encabezado fijo existente. Esas aplicaciones
poder acceder rápida y directamente a los campos adicionales mientras los monitores independientes del perfil
o los registradores aún pueden procesar los paquetes RTP interpretando sólo los primeros doce octetos.

Si resulta que se necesita una funcionalidad adicional en común en todos los perfiles, entonces se creará una nueva
Se debe definir una versión de RTP para realizar un cambio permanente en el encabezado fijo.

5.3.1 Extensión del encabezado RTP

Se proporciona un mecanismo de extensión para permitir que las implementaciones individuales experimenten con nuevas
Funciones independientes del formato de carga útil que requieren que se transporte información adicional en el RTP.
encabezado del paquete de datos. Este mecanismo está diseñado para que la extensión del encabezado pueda ser ignorada por
otras implementaciones interoperativas que no se han ampliado.

Tenga en cuenta que esta extensión de encabezado está destinada únicamente a un uso limitado. La mayoría de los usos potenciales de este
El mecanismo sería mejor hacerlo de otra manera, utilizando los métodos descritos en la sección anterior.
Por ejemplo, una extensión específica del perfil para el encabezado fijo es menos costosa de procesar porque es
no condicional ni en una ubicación variable. Información adicional requerida para una carga útil particular
El formato no debe usar esta extensión de encabezado, pero debe incluirse en la sección de carga útil de
el paquete.

0123
01234567890123456789012345678901
+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­ +­+­+­+­+­+­+­+
| definido por perfil | longitud |
+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­ +­+­+­+­+­+­+­+
extensión del encabezado |
|| .... |

Schulzrinne, et al. Seguimiento de estándares [Página 16]

Machine Translated by Google

RFC 3550 RTP julio de 2003

Si el bit X en el encabezado RTP es uno, se debe agregar una extensión de encabezado de longitud variable al encabezado RTP,
siguiendo la lista CSRC si está presente. La extensión del encabezado contiene un campo de longitud de 16 bits que cuenta el
número de palabras de 32 bits en la extensión, excluyendo el encabezado de extensión de cuatro octetos (por lo tanto, cero es una
longitud válida). Solo se puede agregar una extensión al encabezado de datos RTP. Para permitir múltiples implementaciones
interoperativas para cada experimento de forma independiente con diferentes extensiones de encabezado, o para permitir que una
implementación particular experimente con más de un tipo de extensión de encabezado, los primeros 16 bits de la extensión de
encabezado se dejan abiertos para distinguir identificadores o parámetros. El formato de estos 16 bits debe definirse mediante la
especificación del perfil bajo el cual operan las implementaciones. Esta especificación RTP no define ninguna extensión de
encabezado.

6. Protocolo de control RTP: RTCP

El protocolo de control RTP (RTCP) se basa en la transmisión periódica de paquetes de control a todos los participantes de la sesión,
utilizando el mismo mecanismo de distribución que los paquetes de datos. El protocolo subyacente debe proporcionar multiplexación
de los paquetes de datos y control, por ejemplo utilizando números de puerto separados con UDP. RTCP realiza cuatro funciones:

1. La función principal es proporcionar retroalimentación sobre la calidad de la distribución de datos. Esto es una parte integral
del papel del RTP como protocolo de transporte y está relacionado con las funciones de control de flujo y congestión de otros
protocolos de transporte (consulte la Sección 10 sobre el requisito de control de congestión). La retroalimentación puede ser
directamente útil para el control de codificaciones adaptativas [18, 19], pero los experimentos con multidifusión IP han
demostrado que también es fundamental obtener retroalimentación de los receptores para diagnosticar fallas en la distribución.
Enviar informes de retroalimentación de recepción a todos los participantes permite a quien observa los problemas evaluar si
esos problemas son locales o globales. Con un mecanismo de distribución como la multidifusión IP, también es posible que
una entidad, como un proveedor de servicios de red, que no participa de otro modo en la sesión, reciba la información de
retroalimentación y actúe como un monitor externo para diagnosticar problemas de red. Esta función de retroalimentación la
realizan los informes del remitente y del receptor RTCP, que se describen a continuación en la Sección 6.4.

2. RTCP lleva un identificador de nivel de transporte persistente para una fuente RTP llamado nombre canónico o CNAME,
Sección 6.5.1. Dado que el identificador SSRC puede cambiar si se descubre un conflicto o se reinicia un programa, los
receptores requieren el CNAME para realizar un seguimiento de cada participante. Los receptores también pueden requerir
que CNAME asocie múltiples flujos de datos de un participante determinado en un conjunto de sesiones RTP relacionadas,
por ejemplo, para sincronizar audio y video. La sincronización intermedia también requiere las marcas de tiempo NTP y RTP
incluidas en los paquetes RTCP por los remitentes de datos.

3. Las dos primeras funciones requieren que todos los participantes envíen paquetes RTCP; por lo tanto, se debe controlar la
velocidad para que RTP pueda escalar a una gran cantidad de participantes. Al hacer que cada participante envíe sus
paquetes de control a todos los demás, cada uno puede observar de forma independiente el

Schulzrinne, et al. Seguimiento de estándares [Página 17]

Machine Translated by Google

RFC 3550 RTP julio de 2003

número de participantes. Este número se utiliza para calcular la velocidad a la que se envían los paquetes, como se explica
en la Sección 6.2.

4. Una cuarta función opcional es transmitir información mínima de control de sesión, por ejemplo, la identificación del participante
que se mostrará en la interfaz de usuario. Es más probable que esto sea útil en sesiones “poco controladas” donde los
participantes entran y salen sin control de membresía ni negociación de parámetros. RTCP sirve como un canal conveniente
para llegar a todos los participantes, pero no necesariamente se espera que admita todos los requisitos de comunicación de
control de una aplicación. Es posible que se necesite un protocolo de control de sesión de nivel superior, que está fuera del
alcance de este documento.

Las funciones 1 a 3 deben usarse en todos los entornos, pero particularmente en el entorno de multidifusión IP.
Los diseñadores de aplicaciones RTP deben evitar mecanismos que sólo pueden funcionar en modo unicast y no escalarán a
números mayores. La transmisión de RTCP puede controlarse por separado para emisores y receptores, como se describe en la
Sección 6.2, para casos como enlaces unidireccionales donde la retroalimentación de los receptores no es posible.

Nota no normativa: en el enfoque de enrutamiento de multidifusión llamado multidifusión específica de origen

(SSM), solo hay un remitente por “canal” (una dirección de origen, un par de direcciones de grupo) y los receptores
(excepto el canal de origen) no pueden utilice la multidifusión para comunicarse directamente con otros miembros
del canal. Las recomendaciones aquí se adaptan a SSM solo a través de la opción de la Sección 6.2 de apagar
completamente el RTCP de los receptores. El trabajo futuro especificará la adaptación del RTCP para SSM de
modo que se pueda mantener la retroalimentación de los receptores.

6.1 Formato de paquete RTCP

Esta especificación define varios tipos de paquetes RTCP para transportar una variedad de información de control:

SR: Informe del remitente, para estadísticas de transmisión y recepción de los participantes que están activos
remitentes

RR: Informe del receptor, para estadísticas de recepción de participantes que no son remitentes activos y en combinación con SR
para remitentes activos que informan sobre más de 31 fuentes

SDES: elementos de descripción de la fuente, incluido CNAME

BYE: Indica fin de participación

APP: Funciones específicas de la aplicación

Cada paquete RTCP comienza con una parte fija similar a la de los paquetes de datos RTP, seguida de elementos estructurados que
pueden ser de longitud variable según el tipo de paquete pero que deben terminar en un límite de 32 bits. El requisito de alineación y
un campo de longitud en la parte fija de cada paquete se incluyen para que los paquetes RTCP sean "apilables". Se pueden
concatenar múltiples paquetes RTCP sin ningún separador intermedio para formar un paquete RTCP compuesto que se envía en un
solo paquete del

Schulzrinne, et al. Seguimiento de estándares [Página 18]

Machine Translated by Google

RFC 3550 RTP julio de 2003

protocolo de capa inferior, por ejemplo UDP. No hay un recuento explícito de paquetes RTCP individuales en el paquete compuesto,
ya que se espera que los protocolos de capa inferior proporcionen una longitud total para determinar el final del paquete compuesto.

Cada paquete RTCP individual en el paquete compuesto se puede procesar de forma independiente sin requisitos sobre el orden o
combinación de paquetes. Sin embargo, para realizar las funciones del protocolo, se imponen las siguientes restricciones:

• Las estadísticas de recepción (en SR o RR) deben enviarse con tanta frecuencia como las limitaciones de ancho de banda lo
permitan para maximizar la resolución de las estadísticas; por lo tanto, cada paquete RTCP compuesto transmitido
periódicamente debe incluir un paquete de informe.

• Los nuevos receptores deben recibir el CNAME de una fuente lo antes posible para identificar la fuente y comenzar a asociar
medios para fines tales como sincronización labial, por lo que cada paquete RTCP compuesto también debe incluir el CNAME
SDES, excepto cuando el paquete RTCP compuesto es split para cifrado parcial como se describe en la Sección 9.1.

• La cantidad de tipos de paquetes que pueden aparecer primero en el paquete compuesto debe limitarse para aumentar la
cantidad de bits constantes en la primera palabra y la probabilidad de validar exitosamente los paquetes RTCP contra
paquetes de datos RTP mal direccionados u otros paquetes no relacionados.

Así, todos los paquetes RTCP deben enviarse en un paquete compuesto de al menos dos paquetes individuales, con el siguiente
formato:

Prefijo de cifrado: si y sólo si el paquete compuesto se va a cifrar de acuerdo con el método de la Sección 9.1, debe tener el prefijo
de una cantidad aleatoria de 32 bits redibujada para cada paquete compuesto transmitido. Si se requiere relleno para el
cifrado, se debe agregar al último paquete del paquete compuesto.

SR o RR: El primer paquete RTCP en el paquete compuesto siempre debe ser un paquete de informe para facilitar la validación del
encabezado como se describe en el Apéndice A.2. Esto es cierto incluso si no se han enviado ni recibido datos, en cuyo caso
se debe enviar un RR vacío, e incluso si el único otro paquete RTCP en el paquete compuesto es un BYE.

RR adicionales: si el número de fuentes para las cuales se informan estadísticas de recepción excede 31, el número que cabe en un
paquete SR o RR, entonces los paquetes RR adicionales deben seguir al paquete de informe inicial.

SDES: Se debe incluir un paquete SDES que contenga un elemento CNAME en cada paquete RTCP compuesto, excepto como se
indica en la Sección 9.1. Opcionalmente se pueden incluir otros elementos de descripción de fuente si lo requiere una
aplicación en particular, sujeto a restricciones de ancho de banda (consulte la Sección 6.3.9).

BYE o APP: Otros tipos de paquetes RTCP, incluidos aquellos que aún no se han definido, pueden seguir en cualquier orden, excepto
que BYE debe ser el último paquete enviado con un SSRC/CSRC determinado. Los tipos de paquetes pueden aparecer más
de una vez.

Schulzrinne, et al. Seguimiento de estándares [Página 19]

Machine Translated by Google

RFC 3550 RTP julio de 2003

Un participante RTP individual debe enviar solo un paquete RTCP compuesto por intervalo de informe
para que el ancho de banda RTCP por participante se estime correctamente (ver Sección 6.2), excepto
cuando el paquete RTCP compuesto se divide para cifrado parcial como se describe en la Sección 9.1. Sí hay
Hay demasiadas fuentes para encajar todos los paquetes RR necesarios en un paquete RTCP compuesto sin
excediendo la unidad máxima de transmisión (MTU) de la ruta de red, entonces solo el subconjunto que
cabrá en una MTU debe incluirse en cada intervalo. Los subconjuntos deben seleccionarse.
por turnos en múltiples intervalos para que se informen todas las fuentes.

Se recomienda que los traductores y mezcladores combinen paquetes RTCP individuales del
múltiples fuentes que reenvían en un paquete compuesto siempre que sea posible para
amortizar los gastos generales del paquete (ver Sección 7). Un ejemplo de paquete compuesto RTCP como podría ser
producido por un mezclador se muestra en la Fig. 1. Si la longitud total de un paquete compuesto excede
la MTU de la ruta de red, debe segmentarse en varios paquetes compuestos más cortos
transmitirse en paquetes separados del protocolo subyacente. Esto no perjudica el RTCP
estimación del ancho de banda porque cada paquete compuesto representa al menos un participante distinto.
Tenga en cuenta que cada uno de los paquetes compuestos debe comenzar con un paquete SR o RR.

Una implementación debe ignorar los paquetes RTCP entrantes con tipos desconocidos para ella. Adicional
Los tipos de paquetes RTCP pueden registrarse con la Autoridad de Números Asignados de Internet (IANA) como
descrito en la Sección 15.

si está cifrado: entero aleatorio de 32 bits

paquete paquete paquete

pedazo pedazo
artículo artículo artículo artículo
informes del receptor

SSRC
SSRC
informe NOMBRE DEL TELÉFONO CNOMBRE LOC razón
SR sitio 1 sitio 2 SDES ADIÓS
SSRC

SSRC

SSRC

SSRC

SSRC

del remitente

paquete compuesto
paquete UDP

Figura 1: Ejemplo de un paquete compuesto RTCP

6.2 Intervalo de transmisión RTCP

RTP está diseñado para permitir que una aplicación escale automáticamente en tamaños de sesión que van desde un
de pocos participantes a miles. Por ejemplo, en una audioconferencia el tráfico de datos es inherentemente
autolimitado porque sólo una o dos personas hablarán a la vez, por lo que con la distribución de multidifusión
La velocidad de datos en cualquier enlace determinado permanece relativamente constante independientemente del número de participantes.
Sin embargo, el tráfico de control no es autolimitado. Si los informes de recepción de cada participante fueran
enviado a una velocidad constante, el tráfico de control crecería linealmente con el número de participantes.
Por lo tanto, la tasa debe reducirse calculando dinámicamente el intervalo entre RTCP
transmisiones de paquetes.

Para cada sesión, se supone que el tráfico de datos está sujeto a un límite agregado llamado
“ancho de banda de sesión” que se dividirá entre los participantes. Este ancho de banda puede estar reservado
y el límite impuesto por la red. Si no hay reservas, puede haber otras limitaciones,

Schulzrinne, et al. Seguimiento de estándares [Página 20]

Machine Translated by Google

RFC 3550 RTP julio de 2003

dependiendo del entorno, que establecen el máximo “razonable” a utilizar por la sesión, y ese sería el ancho de banda de la sesión.
El ancho de banda de la sesión se puede elegir en función de algún costo o conocimiento a priori del ancho de banda de red
disponible para la sesión. Es algo independiente de la codificación del medio, pero la elección de codificación puede estar limitada
por el ancho de banda de la sesión. A menudo, el ancho de banda de la sesión es la suma de los anchos de banda nominales de los
remitentes que se espera que estén activos simultáneamente. Para audio de teleconferencia, este número normalmente sería el
ancho de banda de un remitente. Para codificaciones en capas, cada capa es una sesión RTP separada con su propio parámetro de
ancho de banda de sesión.

Se espera que una aplicación de gestión de sesión proporcione el parámetro de ancho de banda de sesión cuando invoca una
aplicación de medios, pero las aplicaciones de medios pueden establecer un valor predeterminado basado en el ancho de banda de
datos de un solo remitente para la codificación seleccionada para la sesión. La aplicación también puede imponer límites de ancho
de banda basados en reglas de alcance de multidifusión u otros criterios. Todos los participantes deben utilizar el mismo valor para
el ancho de banda de la sesión para que se calcule el mismo intervalo RTCP.

Los cálculos de ancho de banda para el control y el tráfico de datos incluyen protocolos de red y transporte de capa inferior (por
ejemplo, UDP e IP), ya que eso es lo que el sistema de reserva de recursos necesitaría saber.
También se puede esperar que la aplicación sepa cuáles de estos protocolos están en uso. Los encabezados de nivel de enlace no
se incluyen en el cálculo ya que el paquete se encapsulará con diferentes encabezados de nivel de enlace a medida que viaja.

El tráfico de control debe limitarse a una fracción pequeña y conocida del ancho de banda de la sesión: pequeña para que no se vea
afectada la función principal del protocolo de transporte de transportar datos; conocido para que el tráfico de control pueda incluirse
en la especificación de ancho de banda dada a un protocolo de reserva de recursos, y para que cada participante pueda calcular de
forma independiente su participación. El ancho de banda del tráfico de control se suma al ancho de banda de la sesión para el tráfico
de datos. Se recomienda que la fracción del ancho de banda de la sesión agregada para RTCP se fije en 5%. También se recomienda
que 1/4 del ancho de banda RTCP se dedique a los participantes que envían datos para que en sesiones con una gran cantidad de
receptores pero una pequeña cantidad de remitentes, los participantes que se unan recientemente reciban más rápidamente el
CNAME para los sitios de envío. . Cuando la proporción de remitentes es mayor que 1/4 de los participantes, los remitentes obtienen
su proporción del ancho de banda RTCP completo. Si bien los valores de estas y otras constantes en el cálculo del intervalo no son
críticos, todos los participantes en la sesión deben usar los mismos valores para que se calcule el mismo intervalo. Por lo tanto, estas
constantes deben fijarse para un perfil particular.

Un perfil puede especificar que el ancho de banda del tráfico de control puede ser un parámetro separado de la sesión en lugar de
un porcentaje estricto del ancho de banda de la sesión. El uso de un parámetro separado permite que las aplicaciones de velocidad
adaptable establezcan un ancho de banda RTCP consistente con un ancho de banda de datos "típico" que sea menor que el ancho
de banda máximo especificado por el parámetro de ancho de banda de la sesión.

El perfil puede especificar además que el ancho de banda del tráfico de control puede dividirse en dos parámetros de sesión
separados para aquellos participantes que son remitentes de datos activos y aquellos que no lo son; Llamemos a los parámetros S y
R. Siguiendo la recomendación de que 1/4 del ancho de banda RTCP se dedique a los remitentes de datos, los valores
predeterminados recomendados para estos dos parámetros serían 1,25% y 3,75%, respectivamente. Cuando la proporción de
remitentes es mayor que S/(S + R) de los participantes, los remitentes obtienen su proporción de la suma de estos parámetros. El
uso de dos parámetros permite que los informes de recepción RTCP se desactiven por completo para una sesión en particular
estableciendo el ancho de banda RTCP para los remitentes que no son de datos en cero mientras se mantiene el ancho de banda
RTCP para los remitentes de datos distinto de cero para que los informes del remitente aún se puedan enviar para inter
­sincronización de medios. Desactivar RTCP

Schulzrinne, et al. Seguimiento de estándares [Página 21]

Machine Translated by Google

RFC 3550 RTP julio de 2003

No se recomiendan informes de recepción porque son necesarios para las funciones enumeradas al principio de la Sección 6, en
particular información sobre la calidad de la recepción y control de congestión. Sin embargo, hacerlo puede ser apropiado para
sistemas que operan en enlaces unidireccionales o para sesiones que no requieren retroalimentación sobre la calidad de la recepción
o la vivacidad de los receptores y que tienen otros medios para evitar la congestión.

El intervalo calculado entre transmisiones de paquetes RTCP compuestos también debe tener un límite inferior para evitar que las
ráfagas de paquetes superen el ancho de banda permitido cuando el número de participantes es pequeño y el tráfico no se suaviza
según la ley de los grandes números. También evita que el intervalo de informe sea demasiado pequeño durante interrupciones
transitorias como una partición de red, de modo que la adaptación se retrase cuando la partición se recupere. Al iniciar la aplicación,
se debe imponer un retraso antes de que se envíe el primer paquete RTCP compuesto para dar tiempo a que se reciban los paquetes
RTCP de otros participantes, de modo que el intervalo de informe converja al valor correcto más rápidamente. Este retraso puede
establecerse en la mitad del intervalo mínimo para permitir una notificación más rápida de que el nuevo participante está presente. El
valor recomendado para un intervalo mínimo fijo es de 5 segundos.

Una implementación puede escalar el intervalo RTCP mínimo a un valor más pequeño, inversamente proporcional al parámetro de
ancho de banda de la sesión, con las siguientes limitaciones:

• Para sesiones de multidifusión, sólo los remitentes de datos activos pueden usar el valor mínimo reducido para
Calcule el intervalo para la transmisión de paquetes RTCP compuestos.

• Para sesiones de unidifusión, el valor reducido también lo pueden utilizar los participantes que no son remitentes de datos
activos, y el retraso antes de enviar el paquete RTCP compuesto inicial puede ser cero.

• Para todas las sesiones, se debe utilizar el mínimo fijo al calcular el intervalo de tiempo de espera del participante (consulte la
Sección 6.3.5) de modo que otros participantes no agoten el tiempo de espera prematuramente de las implementaciones que
no utilizan el valor reducido para transmitir paquetes RTCP.

• El valor recomendado para el mínimo reducido en segundos es 360 dividido por el ancho de banda de la sesión en kilobits/
segundo. Este mínimo es inferior a 5 segundos para anchos de banda superiores a 72 kb/s.

El algoritmo descrito en la Sección 6.3 y el Apéndice A.7 fue diseñado para cumplir los objetivos descritos en esta sección. Calcula
el intervalo entre el envío de paquetes RTCP compuestos para dividir el ancho de banda del tráfico de control permitido entre los
participantes. Esto permite que una aplicación proporcione una respuesta rápida para sesiones pequeñas en las que, por ejemplo, la
identificación de todos los participantes es importante, pero se adapta automáticamente a sesiones grandes. El algoritmo incorpora
las siguientes características:

• El intervalo calculado entre paquetes RTCP aumenta linealmente con el número de miembros del grupo. Es este factor
lineal el que permite una cantidad constante de tráfico de control cuando se suma entre todos los miembros.

• El intervalo entre paquetes RTCP varía aleatoriamente en el rango [0,5,1,5] veces el intervalo calculado para evitar la
sincronización no deseada de todos los participantes [20]. El primer paquete RTCP enviado después de unirse a una sesión
también se retrasa con una variación aleatoria de la mitad del intervalo RTCP mínimo.

Schulzrinne, et al. Seguimiento de estándares [Página 22]

Machine Translated by Google

RFC 3550 RTP julio de 2003

• Se calcula una estimación dinámica del tamaño promedio de paquete RTCP compuesto, incluidos todos los paquetes recibidos
y enviados, para adaptarse automáticamente a los cambios en la cantidad de información de control transportada.

• Dado que el intervalo calculado depende del número de miembros del grupo observados, puede haber efectos de inicio no
deseados cuando un nuevo usuario se une a una sesión existente, o cuando muchos usuarios se unen simultáneamente a
una nueva sesión. Estos nuevos usuarios inicialmente tendrán estimaciones incorrectas de la membresía del grupo y, por lo
tanto, su intervalo de transmisión RTCP será demasiado corto. Este problema puede ser importante si muchos usuarios se
unen a la sesión simultáneamente. Para solucionar esto, se emplea un algoritmo llamado "reconsideración del temporizador".
Este algoritmo implementa un mecanismo de retroceso simple que hace que los usuarios retengan la transmisión de paquetes
RTCP si el tamaño del grupo aumenta.

• Cuando los usuarios abandonan una sesión, ya sea con un BYE o por tiempo de espera, la membresía del grupo disminuye
y, por lo tanto, el intervalo calculado debería disminuir. Se utiliza un algoritmo de “reconsideración inversa” para permitir a
los miembros reducir más rápidamente sus intervalos en respuesta a la disminución de la membresía del grupo.

• Los paquetes BYE reciben un tratamiento diferente al de otros paquetes RTCP. Cuando un usuario abandona un grupo y
desea enviar un paquete BYE, puede hacerlo antes del próximo paquete RTCP programado. Sin embargo, la transmisión de
BYE sigue un algoritmo de retroceso que evita inundaciones de paquetes BYE en caso de que un gran número de miembros
abandonen la sesión simultáneamente.

Este algoritmo se puede utilizar para sesiones en las que todos los participantes pueden enviar. En ese caso, el parámetro de ancho
de banda de la sesión es el producto del ancho de banda del remitente individual multiplicado por el número de participantes, y el
ancho de banda RTCP es el 5% de eso.

Los detalles del funcionamiento del algoritmo se dan en las secciones siguientes. El Apéndice A.7 ofrece un ejemplo de implementación.

6.2.1 Mantener el número de miembros de la sesión

El cálculo del intervalo de paquetes RTCP depende de una estimación del número de sitios que participan en la sesión. Los sitios
nuevos se agregan al recuento cuando se escuchan, y se debe crear una entrada para cada uno en una tabla indexada por el
identificador SSRC o CSRC (consulte la Sección 8.2) para realizar un seguimiento de ellos. Las nuevas entradas pueden considerarse
no válidas hasta que se hayan recibido varios paquetes que contienen el nuevo SSRC (consulte el Apéndice A.1), o hasta que se
haya recibido un paquete SDES RTCP que contenga un CNAME para ese SSRC. Las entradas se pueden eliminar de la tabla
cuando se recibe un paquete RTCP BYE con el identificador SSRC correspondiente, excepto que algunos paquetes de datos
rezagados puedan llegar después del BYE y provocar que se vuelva a crear la entrada. En su lugar, se debe marcar la entrada como
si hubiera recibido un BYE y luego eliminarla después de un retraso adecuado.

Un participante puede marcar otro sitio como inactivo o eliminarlo si aún no es válido, si no se ha recibido ningún paquete RTP o
RTCP durante un pequeño número de intervalos de informe RTCP (se recomienda 5). Esto proporciona cierta solidez contra la
pérdida de paquetes. Todos los sitios deben tener el mismo valor para este multiplicador y deben calcular aproximadamente el mismo
valor para el intervalo del informe RTCP para que este tiempo de espera funcione correctamente. Por lo tanto, este multiplicador
debe fijarse para un perfil en particular.

Schulzrinne, et al. Seguimiento de estándares [Página 23]

Machine Translated by Google

RFC 3550 RTP julio de 2003

Para sesiones con una gran cantidad de participantes, puede resultar poco práctico mantener una tabla para almacenar el
identificador SSRC y la información de estado de todos ellos. Una implementación puede utilizar muestreo SSRC, como se
describe en [21], para reducir los requisitos de almacenamiento. Una implementación puede utilizar cualquier otro algoritmo
con rendimiento similar. Un requisito clave es que cualquier algoritmo considerado no debe subestimar sustancialmente el
tamaño del grupo, aunque puede sobreestimarlo.

6.3 Reglas de envío y recepción de paquetes RTCP

Las reglas sobre cómo enviar y qué hacer al recibir un paquete RTCP se describen aquí. Una implementación que permita la
operación en un entorno de multidifusión o un entorno de unidifusión multipunto debe cumplir con los requisitos de la Sección 6.2.
Dicha implementación puede usar el algoritmo definido en esta sección para cumplir con esos requisitos, o puede usar algún otro
algoritmo siempre que proporcione un rendimiento equivalente o mejor. Una implementación que está restringida a la operación de
unidifusión bipartita aún debe utilizar la aleatorización del intervalo de transmisión RTCP para evitar la sincronización no deseada
de múltiples instancias que operan en el mismo entorno, pero puede omitir los algoritmos de “reconsideración del temporizador” y
“reconsideración inversa” en Secciones 6.3.3, 6.3.6 y 6.3.7.

Para ejecutar estas reglas, un participante de la sesión debe mantener varios estados:

tp: la última vez que se transmitió un paquete RTCP;

tc: la hora actual;

tn: la próxima hora de transmisión programada de un paquete RTCP;

pmembers: el número estimado de miembros de la sesión en el momento en que se volvió a calcular tn por última vez;

miembros: la estimación más actualizada del número de miembros de la sesión;

remitentes: la estimación más actual del número de remitentes en la sesión;

rtcp bw: el ancho de banda RTCP objetivo, es decir, el ancho de banda total que utilizarán todos los miembros de esta sesión
para los paquetes RTCP, en octetos por segundo. Esta será una fracción específica del parámetro "ancho de banda de
sesión" proporcionado a la aplicación al inicio.

enviamos: Marca que es verdadera si la aplicación ha enviado datos desde el segundo informe RTCP anterior
fue transmitido.

Tamaño promedio de RTCP: el tamaño promedio de paquete RTCP compuesto, en octetos, sobre todos los paquetes RTCP
enviados y recibidos por este participante. El tamaño incluye encabezados de protocolo de red y transporte de capa
inferior (por ejemplo, UDP e IP), como se explica en la Sección 6.2.

inicial: indicador que es verdadero si la aplicación aún no ha enviado un paquete RTCP.

Muchas de estas reglas utilizan el "intervalo calculado" entre transmisiones de paquetes. Este intervalo se describe en la
siguiente sección.

Schulzrinne, et al. Seguimiento de estándares [Página 24]

Machine Translated by Google

RFC 3550 RTP julio de 2003

6.3.1 Calcular el intervalo de transmisión RTCP

Para mantener la escalabilidad, el intervalo promedio entre paquetes de un participante de la sesión debe escalar con el tamaño
del grupo. Este intervalo se llama intervalo calculado. Se obtiene combinando varias de las piezas de estado descritas
anteriormente. El intervalo calculado T se determina entonces de la siguiente manera:

1. Si el número de remitentes es menor o igual al 25% de la membresía (miembros), el intervalo depende de si el participante es
remitente o no (en base al valor de lo que enviamos). Si el participante es un remitente (enviamos verdadero), la constante C
se establece en el tamaño promedio del paquete RTCP (tamaño promedio de rtcp) dividido por el 25% del ancho de banda
RTCP (rtcp bw), y la constante n se establece en el número de remitentes. Si lo que enviamos no es cierto, la constante C se
establece en el tamaño promedio de paquete RTCP dividido por el 75% del ancho de banda RTCP. La constante n se
establece en el número de receptores (miembros ­ remitentes). Si el número de remitentes es superior al 25%, los remitentes
y los destinatarios se tratan juntos. La constante C se establece en el tamaño promedio de paquete RTCP dividido por el
ancho de banda total de RTCP y n se establece en el número total de miembros. Como se indica en la Sección 6.2, un perfil
RTP puede especificar que el ancho de banda RTCP puede definirse explícitamente mediante dos parámetros separados
(llámelos S y R) para aquellos participantes que son remitentes y aquellos que no lo son. En ese caso, la fracción del 25% se
convierte en S/(S + R) y la fracción del 75% se convierte en R/(S + R). Tenga en cuenta que si R es cero, el porcentaje de
remitentes nunca es mayor que S/(S + R) y la implementación debe evitar la división por cero.

2. Si el participante aún no ha enviado un paquete RTCP (la variable inicial es verdadera), la constante
Tmin se establece en 2,5 segundos; en caso contrario, se establece en 5 segundos.

3. El intervalo calculado determinista Td se establece en max(Tmin, n*C).

4. El intervalo calculado T se establece en un número distribuido uniformemente entre 0,5 y 1,5 veces
el intervalo calculado determinista.

5. El valor resultante de T se divide por e − 3/2=1,21828 para compensar el hecho de que el algoritmo de reconsideración del
temporizador converge a un valor del ancho de banda RTCP por debajo del promedio previsto.

Este procedimiento da como resultado un intervalo aleatorio, pero que, en promedio, proporciona al menos el 25% del ancho de
banda RTCP a los emisores y el resto a los receptores. Si los remitentes constituyen más de una cuarta parte de los miembros, este
procedimiento divide el ancho de banda por igual entre todos los participantes, en
promedio.

6.3.2 Inicialización

Al unirse a la sesión, el participante inicializa tp en 0, tc en 0, remitentes en 0, pmembers en 1, miembros en 1, enviamos a false, rtcp
bw a la fracción especificada del ancho de banda de la sesión, inicial a verdadero y promedio tamaño rtcp al tamaño probable del
primer paquete RTCP que la aplicación construirá más adelante. Luego se calcula el intervalo T calculado y se programa el primer
paquete para su envío.

Schulzrinne, et al. Seguimiento de estándares [Página 25]

Machine Translated by Google

RFC 3550 RTP julio de 2003

tiempo tn = T. Esto significa que se establece un temporizador de transmisión que expira en el momento T. Tenga en cuenta que
una aplicación puede utilizar cualquier enfoque deseado para implementar este temporizador.

El participante agrega su propio SSRC a la tabla de miembros.

6.3.3 Recibir un paquete RTP o RTCP sin BYE

Cuando se recibe un paquete RTP o RTCP de un participante cuyo SSRC no está en la tabla de miembros, el SSRC se agrega a
la tabla y el valor de los miembros se actualiza una vez que el participante ha sido validado como se describe en la Sección 6.2.1.
El mismo procesamiento ocurre para cada CSRC en un paquete RTP validado.

Cuando se recibe un paquete RTP de un participante cuyo SSRC no está en la tabla de remitentes, el SSRC se agrega a la tabla
y se actualiza el valor de los remitentes.

Para cada paquete RTCP compuesto recibido, se actualiza el valor del tamaño promedio de rtcp:

tamaño promedio de rtcp = (1/16) * tamaño de paquete + (15/16) * tamaño promedio de rtcp

donde el tamaño del paquete es el tamaño del paquete RTCP que se acaba de recibir.

6.3.4 Recibir un paquete RTCP BYE

Excepto como se describe en la Sección 6.3.7 para el caso en el que se debe transmitir un RTCP BYE, si el paquete recibido es
un paquete RTCP BYE, el SSRC se compara con la tabla de miembros. Si está presente, la entrada se elimina de la tabla y se
actualiza el valor de los miembros. Luego, el SSRC se compara con la tabla de remitentes. Si está presente, la entrada se elimina
de la tabla y se actualiza el valor de los remitentes.

Además, para que la velocidad de transmisión de los paquetes RTCP se adapte mejor a los cambios en la membresía del grupo,
se debe ejecutar el siguiente algoritmo de "reconsideración inversa" cuando se recibe un paquete BYE que reduce los miembros
a un valor menor que pmembers:

• El valor de tn se actualiza según la siguiente fórmula:

tn = tc + (miembros/pmiembros) * (tn ­ tc)

• El valor de tp se actualiza según la siguiente fórmula:

tp = tc ­ (miembros/pmiembros) * (tc ­ tp).

• El siguiente paquete RTCP se reprograma para su transmisión en el momento tn, que ahora es anterior.

• El valor de pmembers se establece igual a member.

Este algoritmo no evita que la estimación del tamaño del grupo caiga incorrectamente a cero durante un breve período debido a
tiempos de espera prematuros cuando la mayoría de los participantes de una sesión grande se van de inmediato pero algunos
permanecen. El algoritmo hace que la estimación vuelva al valor correcto más rápidamente.
Esta situación es bastante inusual y las consecuencias son suficientemente inofensivas como para que este problema se
considere sólo una preocupación secundaria.

Schulzrinne, et al. Seguimiento de estándares [Página 26]

Machine Translated by Google

RFC 3550 RTP julio de 2003

6.3.5 Temporización de un SSRC

A intervalos ocasionales, el participante debe comprobar si alguno de los demás participantes ha agotado el tiempo. Para hacer esto,
el participante calcula el intervalo Td calculado determinista (sin el factor de aleatorización) para un receptor, es decir, con enviamos
falso. Cualquier otro miembro de la sesión que no haya enviado un paquete RTP o RTCP desde el momento tc ­ MTd (M es el
multiplicador de tiempo de espera y el valor predeterminado es 5) se agota. Esto significa que su SSRC se elimina de la lista de
miembros y se actualizan los miembros. Se realiza una verificación similar en la lista de remitentes. Cualquier miembro de la lista de
remitentes que no haya enviado un paquete RTP desde el momento tc ­ 2T (dentro de los dos últimos intervalos de informe RTCP)
se elimina de la lista de remitentes y se actualizan los remitentes.

Si algún miembro se agota, se debe realizar el algoritmo de reconsideración inversa descrito en la Sección 6.3.4.

El participante debe realizar esta verificación al menos una vez por intervalo de transmisión RTCP.

6.3.6 Expiración del temporizador de transmisión

Cuando expira el temporizador de transmisión de paquetes, el participante realiza las siguientes operaciones:

• El intervalo de transmisión T se calcula como se describe en la Sección 6.3.1, incluyendo el

factor de ización.

• Si tp + T es menor o igual que tc, se transmite un paquete RTCP. tp se establece en tc, luego se calcula otro valor para T como
en el paso anterior y tn se establece en tc + T. El temporizador de transmisión se configura para que expire nuevamente en
el momento tn. Si tp + T es mayor que tc, tn se establece en tp + T. No se transmite ningún paquete RTCP. El temporizador
de transmisión está configurado para expirar en el momento tn.

• pmembers se establece en miembros.

Si se transmite un paquete RTCP, el valor de inicial se establece en FALSO. Además, se actualiza el valor del tamaño promedio de
rtcp:

tamaño promedio de rtcp = (1/16) * tamaño de paquete + (15/16) * tamaño promedio de rtcp

donde el tamaño del paquete es el tamaño del paquete RTCP que se acaba de transmitir.

6.3.7 Transmisión de un paquete BYE

Cuando un participante desea abandonar una sesión, se transmite un paquete BYE para informar a los demás participantes del
evento. Para evitar una avalancha de paquetes BYE cuando muchos participantes abandonan el sistema, un participante debe
ejecutar el siguiente algoritmo si el número de miembros es superior a 50 cuando el participante decide irse. Este algoritmo usurpa la
función normal de la variable de miembros para contar los paquetes BYE:

• Cuando el participante decide abandonar el sistema, tp se restablece a tc, la hora actual, los miembros y pmembers se
inicializan en 1, inicial se establece en 1, enviamos se establece en falso, los remitentes se configuran en

Schulzrinne, et al. Seguimiento de estándares [Página 27]

Machine Translated by Google

RFC 3550 RTP julio de 2003

0, y el tamaño promedio de rtcp se establece en el tamaño del paquete BYE compuesto. Se calcula el intervalo T calculado.
El paquete BYE se programa entonces para el tiempo tn = tc + T.

• Cada vez que se recibe un paquete BYE de otro participante, los miembros se incrementan en 1 independientemente de si ese
participante existe o no en la tabla de miembros, y cuando se utiliza el muestreo SSRC, independientemente de si el BYE
SSRC se incluiría o no en la muestra. miembros NO se incrementa cuando se reciben otros paquetes RTCP o paquetes RTP,
sino solo para paquetes BYE. De manera similar, el tamaño promedio de rtcp se actualiza solo para los paquetes BYE
recibidos. los remitentes NO se actualizan cuando llegan los paquetes RTP; sigue siendo 0.

• La transmisión del paquete BYE sigue las reglas para transmitir un RTCP normal.
paquete, como arriba.

Esto permite que los paquetes BYE se envíen de inmediato y, al mismo tiempo, controla su uso total del ancho de banda. En el peor
de los casos, esto podría hacer que los paquetes de control RTCP utilicen el doble de ancho de banda de lo normal (10%): 5% para
paquetes RTCP que no son BYE y 5% para BYE.

Un participante que no quiera esperar a que el mecanismo anterior permita la transmisión de un paquete BYE puede abandonar el
grupo sin enviar ningún BYE. Los demás miembros del grupo eventualmente le quitarán el tiempo de espera a ese participante.

Si el tamaño estimado del grupo es inferior a 50 miembros cuando el participante decide irse, el participante puede enviar un paquete
BYE inmediatamente. Alternativamente, el participante puede optar por ejecutar el algoritmo de retroceso BYE anterior.

En cualquier caso, un participante que nunca envió un paquete RTP o RTCP no debe enviar un paquete BYE cuando abandona el
grupo.

6.3.8 Actualización que enviamos

La variable que enviamos contiene verdadero si el participante envió un paquete RTP recientemente y falso en caso contrario. Esta
determinación se realiza utilizando los mismos mecanismos que para gestionar el conjunto de otros participantes enumerados en la
tabla de remitentes. Si el participante envía un paquete RTP cuando lo enviamos es falso, se agrega a la tabla de remitentes y
establece lo que enviamos como verdadero. El algoritmo de reconsideración inversa descrito en la Sección 6.3.4 debe realizarse
para reducir posiblemente el retraso antes de enviar un paquete SR. Cada vez que se envía otro paquete RTP, la hora de transmisión
de ese paquete se mantiene en la tabla. Luego se aplica al participante el algoritmo de tiempo de espera del remitente normal: si un
paquete RTP no se ha transmitido desde el tiempo tc ­ 2T, el participante se elimina de la tabla de remitentes, disminuye el recuento
de remitentes y establece que enviamos a falso.

6.3.9 Asignación del ancho de banda de descripción de fuente

Esta especificación define varios elementos de descripción de origen (SDES) además del elemento CNAME obligatorio, como
NOMBRE (nombre personal) y EMAIL (dirección de correo electrónico). También proporciona un medio para definir nuevos tipos de
paquetes RTCP específicos de la aplicación. Las aplicaciones deben tener cuidado al asignar ancho de banda de control a esta
información adicional porque ralentizará la velocidad a la que se envían los informes de recepción y CNAME, lo que perjudicará el
rendimiento del protocolo. Él

Schulzrinne, et al. Seguimiento de estándares [Página 28]

Machine Translated by Google

RFC 3550 RTP julio de 2003

Se recomienda que no se utilice más del 20% del ancho de banda RTCP asignado a un solo participante para transportar la
información adicional. Además, no se pretende que todos los elementos SDES se incluyan en cada solicitud. A los que están incluidos
se les debe asignar una fracción del ancho de banda según su utilidad. En lugar de estimar estas fracciones dinámicamente, se
recomienda convertir los porcentajes estáticamente en recuentos de intervalos de informe basados en la longitud típica de un
elemento.

Por ejemplo, una aplicación puede diseñarse para enviar únicamente CNAME, NAME y EMAIL y ningún otro. Es posible que se le dé
mucha mayor prioridad a NOMBRE que a CORREO ELECTRÓNICO porque el NOMBRE se mostraría continuamente en la interfaz
de usuario de la aplicación, mientras que CORREO ELECTRÓNICO se mostraría solo cuando se solicitara. En cada intervalo RTCP,
se enviaría un paquete RR y un paquete SDES con el elemento CNAME. Para una sesión pequeña que funcione en el intervalo
mínimo, sería cada 5 segundos en promedio. Cada tercer intervalo (15 segundos), se incluiría un artículo adicional en el paquete
SDES. Siete de ocho veces este sería el elemento NOMBRE y cada ocho veces (2 minutos) sería el elemento CORREO
ELECTRÓNICO.

Cuando múltiples aplicaciones operan en conjunto usando enlace entre aplicaciones a través de un CNAME común para cada
participante, por ejemplo en una conferencia multimedia compuesta por una sesión RTP para cada medio, la información SDES
adicional puede enviarse en una sola sesión RTP. Las otras sesiones llevarían sólo el elemento CNAME. En particular, este enfoque
debería aplicarse a las múltiples sesiones de un esquema de codificación en capas (ver Sección 2.4).

6.4 Informes del remitente y del destinatario

Los receptores RTP proporcionan información sobre la calidad de la recepción mediante paquetes de informes RTCP que pueden
adoptar una de dos formas dependiendo de si el receptor es también un remitente o no. La única diferencia entre los formularios de
informe del remitente (SR) y de informe del receptor (RR), además del código de tipo de paquete, es que el informe del remitente
incluye una sección de información del remitente de 20 bytes para uso de los remitentes activos. El SR se emite si un sitio ha enviado
algún paquete de datos durante el intervalo desde que se emitió el último informe o el anterior; de lo contrario, se emite el RR.

Tanto el formulario SR como el RR incluyen cero o más bloques de informe de recepción, uno para cada una de las fuentes de
sincronización de las cuales este receptor ha recibido paquetes de datos RTP desde el último informe. No se emiten informes para
las fuentes contribuyentes que figuran en la lista CSRC. Cada bloque de informe de recepción proporciona estadísticas sobre los
datos recibidos de la fuente particular indicada en ese bloque. Dado que en un paquete SR o RR caben un máximo de 31 bloques
de informes de recepción, se deben apilar paquetes RR adicionales después del paquete SR o RR inicial según sea necesario para
contener los informes de recepción de todas las fuentes escuchadas durante el intervalo desde el último informe. Si hay demasiadas
fuentes para colocar todos los paquetes RR necesarios en un paquete RTCP compuesto sin exceder la MTU de la ruta de la red,
entonces solo se debe incluir en cada intervalo el subconjunto que cabe en una MTU. Los subconjuntos deben seleccionarse por
turnos en múltiples intervalos para que se informen todas las fuentes.

Las siguientes secciones definen los formatos de los dos informes, cómo se pueden extender de manera específica al perfil si una
aplicación requiere información de retroalimentación adicional y cómo se pueden utilizar los informes. Los detalles de los informes de
recepción por parte de traductores y mezcladores se dan en la Sección 7.

Schulzrinne, et al. Seguimiento de estándares [Página 29]

Machine Translated by Google

RFC 3550 RTP julio de 2003

6.4.1 SR: Paquete RTCP de informe del remitente

0123
01234567890123456789012345678901
+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­ +­+­+­+­+­+­+­+

encabezado |V=2|P| RC | PT=SR=200 | longitud |

+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­ +­+­+­+­+­+­+­+

| SSRC del remitente |

+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+= +=+=+=+=+=+=+=+
remitente | Marca de tiempo NTP, palabra más significativa |
información +­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+ ­+­+­+­+­+­+­+­+
| Marca de tiempo NTP, palabra menos significativa |
+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­ +­+­+­+­+­+­+­+

| marca de tiempo RTP |

+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­ +­+­+­+­+­+­+­+

| recuento de paquetes del remitente |

+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­ +­+­+­+­+­+­+­+

| recuento de octetos del remitente |

+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+= +=+=+=+=+=+=+=+

informe | SSRC_1 (SSRC de primera fuente) |

bloque +­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+ ­+­+­+­+­+­+­+­+
1 | fracción perdida | número acumulado de paquetes perdidos |
+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­ +­+­+­+­+­+­+­+

| número de secuencia más alto extendido recibido |

+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­ +­+­+­+­+­+­+­+

| fluctuación entre llegadas |

+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­ +­+­+­+­+­+­+­+

| último SR (LSR) |
+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­ +­+­+­+­+­+­+­+

| retraso desde la última SR (DLSR) |

+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+= +=+=+=+=+=+=+=+
informe | SSRC_2 (SSRC de segunda fuente) |
bloque +­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+ ­+­+­+­+­+­+­+­+
2 : ... :
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+= +=+=+=+=+=+=+=+
| extensiones específicas de perfil |
+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­ +­+­+­+­+­+­+­+

El paquete de informe del remitente consta de tres secciones, posiblemente seguidas de una cuarta sección específica del perfil.
sección de extensión si está definida. La primera sección, el encabezado, tiene una longitud de 8 octetos. Los campos tienen la
siguiente significado:

versión (V): 2 bits

Identifica la versión de RTP, que es la misma en los paquetes RTCP que en los paquetes de datos RTP.
La versión definida por esta especificación es dos (2).

relleno (P): 1 bit

Si el bit de relleno está configurado, este paquete RTCP individual contiene algunos octetos de relleno adicionales.
al final que no forman parte de la información de control pero se incluyen en el campo de longitud.
El último octeto del relleno es un recuento de cuántos octetos de relleno deben ignorarse.

Schulzrinne, et al. Seguimiento de estándares [Página 30]

Machine Translated by Google

RFC 3550 RTP julio de 2003

incluyéndose a sí mismo (será múltiplo de cuatro). Algunos algoritmos de cifrado con tamaños de bloque fijos pueden
necesitar relleno. En un paquete RTCP compuesto, solo se requiere relleno en un paquete individual porque el paquete
compuesto se cifra en su totalidad para el método de la Sección 9.1. Por lo tanto, el relleno sólo debe agregarse al último
paquete individual y, si se agrega relleno a ese paquete, el bit de relleno debe establecerse solo en ese paquete. Esta
convención ayuda a las comprobaciones de validez del encabezado descritas en el Apéndice A.2 y permite la detección de
paquetes de algunas implementaciones tempranas que configuran incorrectamente el bit de relleno en el primer paquete
individual y agregan relleno al último paquete individual.

recuento de informe de recepción (RC): 5 bits

El número de bloques de informes de recepción contenidos en este paquete. Un valor de cero es válido.

tipo de paquete (PT): 8 bits Contiene

la constante 200 para identificarlo como un paquete RTCP SR.

longitud: 16 bits
La longitud de este paquete RTCP en palabras de 32 bits menos uno, incluido el encabezado y el relleno. (El desplazamiento
de uno hace que cero sea una longitud válida y evita un posible bucle infinito al escanear un paquete RTCP compuesto,
mientras que contar palabras de 32 bits evita una verificación de validez para un múltiplo de 4).

SSRC: 32 bits
El identificador de origen de sincronización para el creador de este paquete SR.

La segunda sección, la información del remitente, tiene 20 octetos y está presente en cada paquete de informe del remitente. Resume
las transmisiones de datos de este remitente. Los campos tienen el siguiente significado:

Marca de tiempo NTP: 64 bits Indica

la hora del reloj de pared (consulte la Sección 4) cuando se envió este informe para que pueda usarse en combinación con
marcas de tiempo devueltas en informes de recepción de otros receptores para medir la propagación de ida y vuelta a esos
receptores. Los receptores deben esperar que la precisión de la medición de la marca de tiempo se limite a mucho menos
que la resolución de la marca de tiempo NTP.
La incertidumbre de medición de la marca de tiempo no se indica ya que es posible que no se conozca. En un sistema que
no tiene noción de la hora del reloj de pared pero que tiene algún reloj específico del sistema, como "tiempo de actividad del
sistema", un remitente puede usar ese reloj como referencia para calcular las marcas de tiempo NTP relativas. Es importante
elegir un reloj de uso común de modo que si se utilizan implementaciones separadas para producir los flujos individuales de
una sesión multimedia, todas las implementaciones usarán el mismo reloj. Hasta el año 2036, las marcas de tiempo relativas
y absolutas diferirán en el bit superior, por lo que las comparaciones (no válidas) mostrarán una gran diferencia; para entonces
uno espera que ya no sean necesarias las marcas de tiempo relativas. Un remitente que no tenga noción del reloj de pared o
del tiempo transcurrido puede establecer la marca de tiempo NTP en cero.

Marca de tiempo RTP: 32 bits

Corresponde a la misma hora que la marca de tiempo NTP (arriba), pero en las mismas unidades y con el mismo
desplazamiento aleatorio que las marcas de tiempo RTP en los paquetes de datos. Esta correspondencia se puede utilizar
para la sincronización intra e intermedia de fuentes cuyas marcas de tiempo NTP

Schulzrinne, et al. Seguimiento de estándares [Página 31]

Machine Translated by Google

RFC 3550 RTP julio de 2003

están sincronizados y pueden ser utilizados por receptores independientes de los medios para estimar la frecuencia de reloj
RTP nominal. Tenga en cuenta que en la mayoría de los casos esta marca de tiempo no será igual a la marca de tiempo
RTP en ningún paquete de datos adyacente. Más bien, debe calcularse a partir de la marca de tiempo NTP correspondiente
utilizando la relación entre el contador de marca de tiempo RTP y el tiempo real, mantenida verificando periódicamente la
hora del reloj de pared en un instante de muestreo.

recuento de paquetes del remitente: 32 bits

El número total de paquetes de datos RTP transmitidos por el remitente desde que comenzó la transmisión hasta el momento
en que se generó este paquete SR. El recuento debe restablecerse si el remitente cambia su identificador SSRC.

recuento de octetos del remitente: 32 bits

El número total de octetos de carga útil (es decir, sin incluir el encabezado ni el relleno) transmitidos en paquetes de datos
RTP por el remitente desde que comenzó la transmisión hasta el momento en que se generó este paquete SR. El recuento
debe restablecerse si el remitente cambia su identificador SSRC. Este campo se puede utilizar para estimar la velocidad de
datos de carga útil promedio.

La tercera sección contiene cero o más bloques de informes de recepción según la cantidad de otras fuentes escuchadas por este
remitente desde el último informe. Cada bloque de informe de recepción transmite estadísticas sobre la recepción de paquetes RTP
desde una única fuente de sincronización. Los receptores no deben transferir estadísticas cuando una fuente cambia su identificador
SSRC debido a una colisión. Estas estadísticas son:

SSRC n (identificador de fuente): 32 bits El

identificador SSRC de la fuente a la que pertenece la información de este bloque de informe de recepción.

fracción perdida: 8 bits La

fracción de paquetes de datos RTP del origen SSRC n perdidos desde que se envió el paquete SR o RR anterior, expresada
como un número de punto fijo con el punto binario en el borde izquierdo del campo.
(Eso equivale a tomar la parte entera después de multiplicar la fracción de pérdida por 256).
Esta fracción se define como el número de paquetes perdidos dividido por el número de paquetes esperados, como se define
en el siguiente párrafo. En el Apéndice A.3 se muestra una implementación.
Si la pérdida es negativa debido a duplicados, la fracción perdida se fija en cero. Tenga en cuenta que un receptor no puede
saber si se perdió algún paquete después del último recibido, y que no se emitirá ningún bloque de informe de recepción para
una fuente si todos los paquetes de esa fuente enviados durante el último intervalo de informe se han perdido.

número acumulado de paquetes perdidos: 24 bits

El número total de paquetes de datos RTP del origen SSRC n que se han perdido desde el comienzo de la recepción. Este
número se define como el número de paquetes esperados menos el número de paquetes realmente recibidos, donde el
número de paquetes recibidos incluye los que están retrasados o duplicados. Así, los paquetes que llegan tarde no se
cuentan como perdidos, y la pérdida puede ser negativa si hay duplicados. El número de paquetes esperado se define como
el último número de secuencia extendido recibido, como se define a continuación, menos el número de secuencia inicial
recibido. Esto puede calcularse como se muestra en el Apéndice A.3.

Schulzrinne, et al. Seguimiento de estándares [Página 32]

Machine Translated by Google

RFC 3550 RTP julio de 2003

número de secuencia más alto extendido recibido: 32 bits

Los 16 bits inferiores contienen el número de secuencia más alto recibido en un paquete de datos RTP de
fuente SSRC n, y los 16 bits más significativos extienden ese número de secuencia con el correspondiente recuento de
ciclos de número de secuencia, que puede mantenerse de acuerdo con el algoritmo del Apéndice A.1. Tenga en cuenta que
diferentes receptores dentro de la misma sesión generarán
diferentes extensiones del número de secuencia si sus horas de inicio difieren significativamente.

fluctuación entre llegadas: 32 bits

Una estimación de la varianza estadística del tiempo entre llegadas del paquete de datos RTP, medida en
unidades de marca de tiempo y expresadas como un entero sin signo. La fluctuación entre llegadas J se define como
ser la desviación media (valor absoluto suavizado) de la diferencia D en el espaciado de paquetes en el
receptor comparado con el remitente para un par de paquetes. Como se muestra en la siguiente ecuación, esto
es equivalente a la diferencia en el “tiempo de tránsito relativo” de los dos paquetes; el relativo
El tiempo de tránsito es la diferencia entre la marca de tiempo RTP de un paquete y el reloj del receptor en
la hora de llegada, medida en las mismas unidades.

Si Si es la marca de tiempo RTP del paquete i y Ri es la hora de llegada en la marca de tiempo RTP
unidades para el paquete i, entonces para dos paquetes i y j, D puede expresarse como

D(i, j)=(Rj − Ri) − (Sj − Si)=(Rj − Sj ) − (Ri − Si)

La fluctuación entre llegadas debe calcularse continuamente a medida que se recibe cada paquete de datos i.
desde la fuente SSRC n, usando esta diferencia D para ese paquete y el paquete anterior i − 1 en
orden de llegada (no necesariamente en secuencia), según la fórmula

J(i) = J(i − 1) + (|D(i − 1, i)| − J(i − 1))/16

Siempre que se emite un informe de recepción, se toma una muestra del valor actual de J.

El cálculo de la fluctuación debe ajustarse a la fórmula especificada aquí para permitir que los monitores independientes del
perfil hagan interpretaciones válidas de los informes provenientes de diferentes implementaciones. Este algoritmo es el
estimador óptimo de primer orden y el parámetro de ganancia 1/16
proporciona una buena relación de reducción de ruido manteniendo una tasa de convergencia razonable [22,
Sección 11.5­11.12, Fig. 11.6]. En el Apéndice A.8 se muestra una implementación de muestra. Ver
Sección 6.4.4 para una discusión de los efectos de variar la duración del paquete y el retraso antes de la transmisión.

última marca de tiempo SR (LSR): 32 bits

Los 32 bits centrales de los 64 de la marca de tiempo NTP (como se explica en la Sección 4) se recibieron como
parte del paquete de informe del remitente (SR) RTCP más reciente del origen SSRC n. Si ningún SR tiene
aún no se ha recibido, el campo se pone a cero.

retraso desde el último SR (DLSR): 32 bits

El retraso, expresado en unidades de 1/65536 segundos, entre la recepción del último paquete SR de
fuente SSRC n y enviando este bloque de informe de recepción. Si no se ha recibido ningún paquete SR
sin embargo, desde SSRC n, el campo DLSR se establece en cero.

Schulzrinne, et al. Seguimiento de estándares [Página 33]

Machine Translated by Google

RFC 3550 RTP julio de 2003

Sea SSRC r el receptor que emite este informe de receptor. La fuente SSRC n puede calcular el
retardo de propagación de ida y vuelta al SSRC r registrando el tiempo A cuando este informe de recepción
Se recibe el bloque. Calcula el tiempo total de ida y vuelta A­LSR utilizando la última marca de tiempo SR.
(LSR) y luego restar este campo para dejar el retardo de propagación de ida y vuelta como
(A­LSR­DLSR). Esto se ilustra en la Fig. 2. Los tiempos se muestran en formato hexadecimal
representación de los campos de 32 bits y la representación decimal equivalente de punto flotante.
Los dos puntos indican un campo de 32 bits dividido en una parte entera de 16 bits y una parte fraccionaria de 16 bits.

Esto puede usarse como una medida aproximada de la distancia a los receptores del grupo, aunque algunos
Los enlaces tienen retrasos muy asimétricos.

[10 de noviembre de 1995 11:33:25.125 UTC] [10 de noviembre de 1995 11:33:36.5 UTC]
norte
SR(n) A=0xb710:8000 (46864,500 s)

ntp_sec =0xb44db705 dlsr=0x0005:4000 (5,250 s)

ntp_frac=0x20000000 lsr = 0xb705:2000 (46853,125 s)
(3024992005,125 s)

r RR(n)

DLSR
(5,25 segundos)

A 0xb710:8000 (46864,500 s)
DLSR ­0x0005:4000 (5,250 s)
LSR ­0xb705:2000 (46853,125 s)

retraso 0x0006:2000 ( 6,125 s)

Figura 2: Ejemplo de cálculo del tiempo de ida y vuelta

Schulzrinne, et al. Seguimiento de estándares [Página 34]

Machine Translated by Google

RFC 3550 RTP julio de 2003

6.4.2 RR: Paquete RTCP de informe del receptor

0123
01234567890123456789012345678901
+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­ +­+­+­+­+­+­+­+
encabezado |V=2|P| RC | PT=RR=201 | longitud |
+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­ +­+­+­+­+­+­+­+
| SSRC del remitente del paquete |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+= +=+=+=+=+=+=+=+
informe | SSRC_1 (SSRC de primera fuente) |
bloque +­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+ ­+­+­+­+­+­+­+­+
1 | fracción perdida | número acumulado de paquetes perdidos |
+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­ +­+­+­+­+­+­+­+
| número de secuencia más alto extendido recibido |
+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­ +­+­+­+­+­+­+­+
| fluctuación entre llegadas |
+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­ +­+­+­+­+­+­+­+
| último SR (LSR) |
+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­ +­+­+­+­+­+­+­+
| retraso desde la última SR (DLSR) |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+= +=+=+=+=+=+=+=+

informe | SSRC_2 (SSRC de segunda fuente) |

bloque +­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+ ­+­+­+­+­+­+­+­+
2 : ... :
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+= +=+=+=+=+=+=+=+
| extensiones específicas de perfil |
+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­ +­+­+­+­+­+­+­+

El formato del paquete de informe del receptor (RR) es el mismo que el del paquete SR excepto que el
El campo de tipo de paquete contiene la constante 201 y las cinco palabras de información del remitente se omiten.
(Estas son las marcas de tiempo NTP y RTP y los recuentos de paquetes y octetos del remitente). El restante
Los campos tienen el mismo significado que para el paquete SR.

Un paquete RR vacío (RC = 0) debe colocarse al principio de un paquete RTCP compuesto cuando
No hay transmisión ni recepción de datos que informar.

6.4.3 Ampliación de los informes del remitente y del destinatario

Un perfil debe definir extensiones específicas del perfil para el informe del remitente y el informe del receptor si hay
Es información adicional que debe informarse periódicamente sobre el remitente o los destinatarios. Este
método debe usarse con preferencia a definir otro tipo de paquete RTCP porque requiere
menos gastos generales:

• menos octetos en el paquete (sin encabezado RTCP ni campo SSRC);

• análisis más simple y rápido porque las aplicaciones que se ejecutan bajo ese perfil estarían programadas para esperar
siempre los campos de extensión en la ubicación directamente accesible después del

Schulzrinne, et al. Seguimiento de estándares [Página 35]

Machine Translated by Google

RFC 3550 RTP julio de 2003

informes de recepción.

La extensión es una cuarta sección en el paquete de informe del remitente o del receptor que aparece al final después de los bloques
del informe de recepción, si los hay. Si se requiere información adicional del remitente, para los informes del remitente se incluirá
primero en la sección de extensión, pero para los informes del receptor no estará presente. Si se va a incluir información sobre los
receptores, esos datos deben estructurarse como una serie de bloques paralelos a la serie existente de bloques de informes de
recepción; es decir, el número de bloques estaría indicado por el campo RC.

6.4.4 Análisis de informes de remitente y destinatario

Se espera que la información sobre la calidad de la recepción sea útil no sólo para el remitente sino también para otros receptores y
monitores de terceros. El remitente podrá modificar sus transmisiones en función de la retroalimentación; los receptores pueden
determinar si los problemas son locales, regionales o globales; Los administradores de red pueden utilizar monitores independientes
del perfil que reciben solo los paquetes RTCP y no los paquetes de datos RTP correspondientes para evaluar el rendimiento de sus
redes para la distribución de multidifusión.

Los recuentos acumulativos se utilizan tanto en los bloques de información del remitente como en los de informes del receptor para
que se puedan calcular las diferencias entre dos informes cualesquiera para realizar mediciones durante períodos de tiempo cortos y
largos, y para proporcionar resiliencia contra la pérdida de un informe. La diferencia entre los dos últimos informes recibidos se puede
utilizar para estimar la calidad reciente de la distribución. Se incluye la marca de tiempo NTP para que las tarifas puedan calcularse
a partir de estas diferencias durante el intervalo entre dos informes. Dado que esa marca de tiempo es independiente de la velocidad
del reloj para la codificación de datos, es posible implementar monitores de calidad independientes de la codificación y del perfil.

Un ejemplo de cálculo es la tasa de pérdida de paquetes durante el intervalo entre dos informes de recepción. La diferencia en el
número acumulado de paquetes perdidos da el número perdido durante ese intervalo. La diferencia en los últimos números de
secuencia extendidos recibidos proporciona la cantidad de paquetes esperados durante el intervalo. La proporción de estos dos es
la fracción de pérdida de paquetes durante el intervalo. Esta proporción debe ser igual al campo de fracción perdida si los dos
informes son consecutivos, pero en caso contrario puede que no sea así. La tasa de pérdida por segundo se puede obtener dividiendo
la fracción de pérdida por la diferencia en las marcas de tiempo NTP, expresadas en segundos. La cantidad de paquetes recibidos
es la cantidad de paquetes esperados menos la cantidad perdida. El número de paquetes esperados también puede utilizarse para
juzgar la validez estadística de cualquier estimación de pérdida. Por ejemplo, 1 de cada 5 paquetes perdidos tiene un significado
menor que 200 de 1000.

A partir de la información del remitente, un monitor de terceros puede calcular la velocidad promedio de datos de carga útil y la
velocidad promedio de paquetes durante un intervalo sin recibir los datos. Tomando la proporción de los dos se obtiene el tamaño
promedio de la carga útil. Si se puede suponer que la pérdida de paquetes es independiente del tamaño del paquete, entonces el
número de paquetes recibidos por un receptor en particular multiplicado por el tamaño promedio de la carga útil (o el tamaño de
paquete correspondiente) da el rendimiento aparente disponible para ese receptor.

Además de los recuentos acumulativos que permiten mediciones de pérdida de paquetes a largo plazo utilizando diferencias entre
informes, el campo de fracción perdida proporciona una medición a corto plazo a partir de un único informe. Esto se vuelve más
importante a medida que el tamaño de una sesión aumenta lo suficiente como para que la información del estado de recepción no se
mantenga para todos los receptores o el intervalo entre informes se vuelve lo suficientemente largo como para que solo se haya
recibido un informe de un receptor en particular.

Schulzrinne, et al. Seguimiento de estándares [Página 36]

Machine Translated by Google

RFC 3550 RTP julio de 2003

El campo de fluctuación entre llegadas proporciona una segunda medida a corto plazo de la congestión de la red. Paquete
la pérdida rastrea la congestión persistente mientras que la medida de fluctuación rastrea la congestión transitoria. el nerviosismo
Esta medida puede indicar congestión antes de que provoque la pérdida de paquetes. El campo de fluctuación entre llegadas es sólo
una instantánea de la inquietud en el momento de un informe y no debe tomarse cuantitativamente.
Más bien, está destinado a comparar varios informes de un receptor a lo largo del tiempo o
desde múltiples receptores, por ejemplo, dentro de una única red, al mismo tiempo. Para permitir la comparación entre
receptores, es importante que todos los receptores calculen la fluctuación de fase según la misma fórmula.

Debido a que el cálculo de jitter se basa en la marca de tiempo RTP que representa el instante en que
Se muestrearon los primeros datos del paquete, cualquier variación en el retraso entre ese instante de muestreo
y el momento en que se transmite el paquete afectará la fluctuación resultante que se calcula. tal
Se produciría una variación en el retraso para paquetes de audio de duración variable. También ocurrirá para video.
codificaciones porque la marca de tiempo es la misma para todos los paquetes de una trama, pero esos paquetes
No todos se transmiten al mismo tiempo. La variación en el retraso hasta la transmisión se reduce.
la precisión del cálculo del jitter como medida del comportamiento de la red en sí misma, pero
es apropiado incluirlo considerando que el buffer del receptor debe acomodarlo. Cuando el
El cálculo del jitter se utiliza como medida comparativa, el componente (constante) debido a la variación en
retraso hasta que la transmisión se reste para que luego se pueda detectar un cambio en el componente de fluctuación de la red.
observado a menos que sea relativamente pequeño. Si el cambio es pequeño, es probable que no tenga consecuencias.

6.5 SDES: Fuente Descripción Paquete RTCP

0123
01234567890123456789012345678901
+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­ +­+­+­+­+­+­+­+
encabezado |V=2|P| SC | PT=SDES=202 | longitud |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+= +=+=+=+=+=+=+=+
trozo | SSRC/CSRC_1 |
1 +­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­ +­+­+­+­+­+­+­+
Artículos SDES |
|| ... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+= +=+=+=+=+=+=+=+
trozo | 2 SSRC/CSRC_2 |
+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­ +­+­+­+­+­+­+­+
Artículos SDES |
|| ... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+= +=+=+=+=+=+=+=+

El paquete SDES es una estructura de tres niveles compuesta por un encabezado y cero o más fragmentos, cada uno de los cuales
que se compone de elementos que describen la fuente identificada en ese fragmento. Los artículos se describen.
individualmente en secciones posteriores.

versión (V), acolchado (P), longitud:

Como se describe para el paquete SR (consulte la Sección 6.4.1).

tipo de paquete (PT): 8 bits

Contiene la constante 202 para identificarlo como un paquete RTCP SDES.

Schulzrinne, et al. Seguimiento de estándares [Página 37]

Machine Translated by Google

RFC 3550 RTP julio de 2003

recuento de origen (SC): 5 bits El

número de fragmentos SSRC/CSRC contenidos en este paquete SDES. Un valor de cero es válido pero inútil.

Cada fragmento consta de un identificador SSRC/CSRC seguido de una lista de cero o más elementos, que contienen información
sobre el SSRC/CSRC. Cada fragmento comienza en un límite de 32 bits. Cada elemento consta de un campo de tipo 8 bits, un
recuento de octetos de 8 bits que describe la longitud del texto (por lo tanto, sin incluir este encabezado de dos octetos) y el texto
mismo. Tenga en cuenta que el texto no puede tener más de 255 octetos, pero esto es coherente con la necesidad de limitar el
consumo de ancho de banda RTCP.

El texto está codificado según la codificación UTF­8 especificada en RFC 2279 [5]. US­ASCII es un subconjunto de esta codificación
y no requiere codificación adicional. La presencia de codificaciones multioctetos se indica estableciendo el bit más significativo de un
carácter en un valor de uno.

Los elementos son contiguos, es decir, no se rellenan individualmente hasta un límite de 32 bits. El texto no tiene terminación nula
porque algunas codificaciones multioctetos incluyen octetos nulos. La lista de elementos de cada fragmento debe terminar con uno o
más octetos nulos, el primero de los cuales se interpreta como un tipo de elemento cero para indicar el final de la lista. Ningún octeto
de longitud sigue al octeto de tipo de elemento nulo, pero se deben incluir octetos nulos adicionales si es necesario para rellenar
hasta el siguiente límite de 32 bits. Tenga en cuenta que este relleno es independiente del indicado por el bit P en el encabezado
RTCP. Un fragmento con cero elementos (cuatro octetos nulos) es válido pero inútil.

Los sistemas finales envían un paquete SDES que contiene su propio identificador de origen (el mismo que el SSRC en el encabezado
RTP fijo). Un mezclador envía un paquete SDES que contiene un fragmento para cada fuente contribuyente de la cual recibe
información SDES, o múltiples paquetes SDES completos en el formato anterior si hay más de 31 fuentes de este tipo (consulte la
Sección 7).

Los elementos SDES actualmente definidos se describen en las siguientes secciones. Sólo el elemento CNAME es obligatorio.
Algunos elementos que se muestran aquí pueden ser útiles solo para perfiles particulares, pero todos los tipos de elementos se
asignan desde un espacio común para promover el uso compartido y simplificar las aplicaciones independientes del perfil. Se pueden
definir elementos adicionales en un perfil registrando los números de tipo en la IANA como se describe en la Sección 15.

6.5.1 CNAME: elemento SDES del identificador de punto final canónico

0123
01234567890123456789012345678901
+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­ +­+­+­+­+­+­+­+
| CNOMBRE=1 | longitud | nombre de usuario y dominio ...
+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­ +­+­+­+­+­+­+­+

El identificador CNAME tiene las siguientes propiedades:

• Debido a que el identificador SSRC asignado aleatoriamente puede cambiar si se descubre un conflicto o si se reinicia un
programa, se debe incluir el elemento CNAME para proporcionar la vinculación del identificador SSRC a un identificador para
la fuente (remitente o receptor) que permanece constante.

• Al igual que el identificador SSRC, el identificador CNAME también debe ser único entre todos los participantes.
dentro de una sesión RTP.

Schulzrinne, et al. Seguimiento de estándares [Página 38]

Machine Translated by Google

RFC 3550 RTP julio de 2003

• Proporcionar un vínculo entre múltiples herramientas multimedia utilizadas por un participante en un conjunto de actividades relacionadas.
sesiones RTP, el CNAME debe ser fijo para ese participante.

• Para facilitar el seguimiento de terceros, el CNAME debe ser adecuado para un programa
o una persona para localizar la fuente.

Por lo tanto, el CNAME debe derivarse algorítmicamente y no ingresarse manualmente, cuando sea posible. Para cumplir con estos
requisitos, se debe utilizar el siguiente formato a menos que un perfil especifique una sintaxis o semántica alternativa. El elemento
CNAME debe tener el formato "usuario@host" o "host" si un nombre de usuario no está disponible como en los sistemas de usuario
único. Para ambos formatos, "host" es el nombre de dominio completo del host desde el que se originan los datos en tiempo real,
formateado de acuerdo con las reglas especificadas en RFC 1034 [6], RFC 1035 [7] y la Sección 2.1 de RFC 1123. [8]; o la
representación ASCII estándar de la dirección numérica del host en la interfaz utilizada para la comunicación RTP. Por ejemplo, la
representación ASCII estándar de una dirección IP Versión 4 es "decimal con puntos", también conocida como cuádruple de puntos,
y para IP Versión 6, las direcciones se representan textualmente como grupos de dígitos hexadecimales separados por dos puntos
(con variaciones como se detalla en RFC 3513 [23]).

Se espera que otros tipos de direcciones tengan representaciones ASCII que sean mutuamente únicas. El nombre de dominio
completo es más conveniente para un observador humano y puede evitar la necesidad de enviar un elemento NOMBRE adicional,
pero puede ser difícil o imposible obtenerlo de manera confiable en algunos entornos operativos. Las aplicaciones que puedan
ejecutarse en dichos entornos deben utilizar en su lugar la representación ASCII de la dirección.

Algunos ejemplos son “[email protected]”, “[email protected]” o “doe@2201:056D::112E:144A:1E24” para un sistema

multiusuario. En un sistema sin nombre de usuario, los ejemplos serían “sleepy.example.com”, “192.0.2.89” o
“2201:056D::112E:144A:1E24”.

El nombre de usuario debe tener una forma que pueda utilizar un programa como “finger” o “talk”, es decir, normalmente es el nombre
de inicio de sesión en lugar del nombre personal. El nombre del anfitrión no es necesariamente idéntico al que figura en la dirección
de correo electrónico del participante.

Esta sintaxis no proporcionará identificadores únicos para cada fuente si una aplicación permite a un usuario generar múltiples
fuentes desde un host. Una aplicación de este tipo tendría que depender del SSRC para identificar mejor la fuente, o el perfil de esa
aplicación tendría que especificar una sintaxis adicional para el identificador CNAME.

Si cada aplicación crea su CNAME de forma independiente, los CNAME resultantes pueden no ser idénticos como se requeriría para
proporcionar un enlace entre múltiples herramientas multimedia pertenecientes a un participante en un conjunto de sesiones RTP
relacionadas. Si se requiere enlace entre medios, puede ser necesario que una herramienta de coordinación configure externamente
el CNAME de cada herramienta con el mismo valor.

Los redactores de aplicaciones deben tener en cuenta que las asignaciones de direcciones de redes privadas, como la asignación
Net­10 propuesta en RFC 1918 [24], pueden crear direcciones de red que no son globalmente únicas. Esto daría lugar a CNAME no
únicos si los hosts con direcciones privadas y sin conectividad IP directa a la Internet pública reenvían sus paquetes RTP a la Internet
pública a través de un traductor de nivel RTP. (Consulte también RFC 1627 [25].) Para manejar este caso, las aplicaciones pueden
proporcionar un medio para configurar un CNAME único, pero la carga recae en el traductor para traducir los CNAME de direcciones
privadas a direcciones públicas si es necesario para mantener las direcciones privadas fuera del alcance de las personas.

Schulzrinne, et al. Seguimiento de estándares [Página 39]

Machine Translated by Google

RFC 3550 RTP julio de 2003

siendo expuesto.

6.5.2 NOMBRE: Nombre de usuario Elemento SDES

0123
01234567890123456789012345678901
+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­ +­+­+­+­+­+­+­+
| NOMBRE=2 | longitud | nombre común de la fuente ...
+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­ +­+­+­+­+­+­+­+

Este es el nombre real utilizado para describir la fuente, por ejemplo, "John Doe, Bit Recycler". puede ser en
cualquier forma deseada por el usuario. Para aplicaciones como conferencias, esta forma de nombre puede ser la
más deseable para mostrar en las listas de participantes y, por lo tanto, podría enviarse con mayor frecuencia de esos
elementos distintos de CNAME. Los perfiles podrán establecer dichas prioridades. Se espera que el valor NAME
permanecer constante al menos durante la duración de una sesión. NO se debe confiar en que sea único
entre todos los participantes en la sesión.

6.5.3 CORREO ELECTRÓNICO: Dirección de correo electrónico Elemento SDES

0123
01234567890123456789012345678901
+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­ +­+­+­+­+­+­+­+
| CORREO ELECTRÓNICO=3 | longitud | dirección de correo electrónico de la fuente ...
+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­ +­+­+­+­+­+­+­+

La dirección de correo electrónico tiene el formato según RFC 2822 [9], por ejemplo, "[email protected]".
Se espera que el valor de EMAIL permanezca constante durante la duración de una sesión.

6.5.4 TELÉFONO: Número de teléfono Elemento SDES

0123
01234567890123456789012345678901
+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­ +­+­+­+­+­+­+­+
| TELÉFONO=4 | longitud | número de teléfono de la fuente ...
+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­ +­+­+­+­+­+­+­+

El número de teléfono debe formatearse con el signo más reemplazando el código de acceso internacional.
Por ejemplo, "+1 908 555 1212" para un número de Estados Unidos.

Schulzrinne, et al. Seguimiento de estándares [Página 40]

Machine Translated by Google

RFC 3550 RTP julio de 2003

6.5.5 LOC: Ubicación geográfica del usuario Elemento SDES

0123
01234567890123456789012345678901
+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­ +­+­+­+­+­+­+­+
| LOC=5 | longitud | ubicación geográfica del sitio...
+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­ +­+­+­+­+­+­+­+

Dependiendo de la aplicación, son apropiados diferentes grados de detalle para este artículo. Para aplicaciones de conferencia, una
cadena como “Murray Hill, Nueva Jersey” puede ser suficiente, mientras que, para una activa
sistema de identificación, cadenas como “Habitación 2A244, AT&T BL MH” podrían ser apropiadas. El grado de
Los detalles se dejan a la implementación y/o al usuario, pero el formato y el contenido pueden ser prescritos por un
perfil. Se espera que el valor LOC permanezca constante durante la duración de una sesión, excepto
hosts móviles.

6.5.6 HERRAMIENTA: Nombre de la aplicación o herramienta Elemento SDES

0123
01234567890123456789012345678901
+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­ +­+­+­+­+­+­+­+
| HERRAMIENTA=6 | longitud |nombre/versión de la aplicación fuente. ...
+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­ +­+­+­+­+­+­+­+

Una cadena que proporciona el nombre y posiblemente la versión de la aplicación que genera la transmisión, por ejemplo,
“videoherramienta 1.2”. Esta información puede resultar útil para fines de depuración y es similar a la
Encabezados SMTP de Mailer o Mail­System­Version. Se espera que el valor de la HERRAMIENTA permanezca constante
durante la duración de la sesión.

6.5.7 NOTA: Aviso/Estado Elemento SDES

0123
01234567890123456789012345678901
+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­ +­+­+­+­+­+­+­+
| NOTA=7 | longitud | nota sobre la fuente ...
+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­ +­+­+­+­+­+­+­+

Se sugieren las siguientes semánticas para este ítem, pero éstas u otras semánticas pueden ser explícitamente
definido por un perfil. El elemento NOTA está destinado a mensajes transitorios que describen la situación actual.
estado de la fuente, por ejemplo, “al teléfono, no puedo hablar”. O, durante un seminario, este tema podría ser
Se utiliza para transmitir el título de la charla. Debe utilizarse únicamente para transportar información excepcional y
NO debe ser incluido de forma rutinaria por todos los participantes porque esto ralentizaría el ritmo en
qué informes de recepción y CNAME se envían, perjudicando así el funcionamiento del protocolo. En
En particular, NO debe incluirse como un elemento en el archivo de configuración de un usuario ni automáticamente

Schulzrinne, et al. Seguimiento de estándares [Página 41]

Machine Translated by Google

RFC 3550 RTP julio de 2003

generado como en una cotización del día.

Dado que puede ser importante mostrar el elemento NOTA mientras está activo, la velocidad a la que otros
Los elementos que no son CNAME, como NAME, se transmiten podrían reducirse para que el elemento NOTA pueda
tomar esa parte del ancho de banda RTCP. Cuando el mensaje transitorio se vuelve inactivo, la NOTA
El elemento debe continuar transmitiéndose varias veces con la misma frecuencia de repetición pero con una cadena.
de longitud cero para señalar a los receptores. Sin embargo, los receptores también deben considerar el elemento NOTA
inactivo si no se recibe por un pequeño múltiplo de la tasa de repetición, o quizás 20­30 RTCP
intervalos.

6.5.8 PRIV: Elemento SDES de extensiones privadas

0123
01234567890123456789012345678901
+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­ +­+­+­+­+­+­+­+
| PRIV=8 | longitud | longitud del prefijo |cadena de prefijo...
+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­ +­+­+­+­+­+­+­+
... | cadena de valor ...
+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­ +­+­+­+­+­+­+­+

Este elemento se utiliza para definir extensiones SDES experimentales o específicas de la aplicación. El artículo contiene
un prefijo que consta de un par de cadena de longitud, seguido de la cadena de valor que llena el resto del
artículo y llevar la información deseada. El campo de longitud del prefijo tiene una longitud de 8 bits. La cadena de prefijo
es un nombre elegido por la persona que define el elemento PRIV para que sea único con respecto a otros PRIV
elementos que esta aplicación podría recibir. El creador de la aplicación puede optar por utilizar la aplicación.
nombre más una identificación de subtipo adicional si es necesario. Alternativamente, se recomienda que
otros eligen un nombre basándose en la entidad que representan y luego coordinan el uso del nombre
dentro de esa entidad.

Tenga en cuenta que el prefijo consume algo de espacio dentro de la longitud total del elemento de 255 octetos, por lo que el prefijo
debe ser lo más breve posible. Esta facilidad y el ancho de banda RTCP restringido deberían
NO estar sobrecargado; no pretende satisfacer todos los requisitos de comunicación de control de todos
aplicaciones.

La IANA no registrará los prefijos SDES PRIV. Si alguna forma del elemento PRIV resulta ser
de utilidad general, en su lugar se le debe asignar un tipo de elemento SDES regular registrado en la IANA
de modo que no se requiere ningún prefijo. Esto simplifica el uso y aumenta la eficiencia de la transmisión.

Schulzrinne, et al. Seguimiento de estándares [Página 42]

Machine Translated by Google

RFC 3550 RTP julio de 2003

6.6 ADIÓS: Adiós paquete RTCP

0123
01234567890123456789012345678901
+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­ +­+­+­+­+­+­+­+
|V=2|P| SC | ES=ADIÓS=203 | longitud |
+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­ +­+­+­+­+­+­+­+
| SSRC/CSRC |
+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­ +­+­+­+­+­+­+­+
: ... :
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+= +=+=+=+=+=+=+=+

(optar) | longitud | razón para irse ...

+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­ +­+­+­+­+­+­+­+

El paquete BYE indica que una o más fuentes ya no están activas.

versión (V), acolchado (P), longitud:

Como se describe para el paquete SR (consulte la Sección 6.4.1).

tipo de paquete (PT): 8 bits

Contiene la constante 203 para identificarlo como un paquete RTCP BYE.

recuento de fuente (SC): 5 bits

La cantidad de identificadores SSRC/CSRC incluidos en este paquete BYE. Un valor de conteo de cero
es válido, pero inútil.

Las reglas sobre cuándo se debe enviar un paquete BYE se especifican en las Secciones 6.3.7 y 8.2.

Si un mezclador recibe un paquete BYE, el mezclador debe reenviar el paquete BYE con el
Identificadores SSRC/CSRC sin cambios. Si un mezclador se apaga, debería enviar un listado de paquetes BYE
todas las fuentes contribuyentes que maneja, así como su propio identificador SSRC. Opcionalmente, el paquete BYE
puede incluir un recuento de octetos de 8 bits seguido de esa misma cantidad de octetos de texto que indiquen el motivo de la
dejando, por ejemplo, “mal funcionamiento de la cámara” o “bucle RTP detectado”. La cadena tiene la misma codificación que
lo descrito para SDES. Si la cadena llena el paquete hasta el siguiente límite de 32 bits, la cadena es
no terminado en nulo. De lo contrario, el paquete BYE debe rellenarse con octetos nulos hasta los siguientes 32 bits.
Perímetro. Este relleno es independiente del indicado por el bit P en el encabezado RTCP.

Schulzrinne, et al. Seguimiento de estándares [Página 43]

Machine Translated by Google

RFC 3550 RTP julio de 2003

6.7 APLICACIÓN: Paquete RTCP definido por la aplicación

0123
01234567890123456789012345678901
+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­ +­+­+­+­+­+­+­+

|V=2|P| subtipo | PT=APLICACIÓN=204 | longitud |

+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­ +­+­+­+­+­+­+­+
| SSRC/CSRC |
+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­ +­+­+­+­+­+­+­+
| nombre (ASCII) |
+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­ +­+­+­+­+­+­+­+
| datos dependientes de la aplicación ...
+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­+­ +­+­+­+­+­+­+­+

El paquete APP está destinado a uso experimental a medida que se desarrollan nuevas aplicaciones y nuevas funciones, sin
necesidad de registrar el valor del tipo de paquete. Paquetes de APP con nombres no reconocidos
debe ser ignorado. Después de las pruebas y si se justifica un uso más amplio, se recomienda que cada aplicación
El paquete se redefinirá sin los campos de subtipo y nombre y se registrará en la IANA mediante un RTCP.
tipo de paquete.

versión (V), acolchado (P), longitud:

Como se describe para el paquete SR (consulte la Sección 6.4.1).

subtipo: 5 bits
Puede usarse como subtipo para permitir que un conjunto de paquetes de aplicaciones se definan bajo un nombre único.
o para cualquier dato dependiente de la aplicación.

tipo de paquete (PT): 8 bits

Contiene la constante 204 para identificarlo como un paquete de aplicación RTCP.

nombre: 4 octetos
Un nombre elegido por la persona que define el conjunto de paquetes APP para que sea único con respecto a
otros paquetes de APP que esta aplicación pueda recibir. El creador de la aplicación podría optar por
utilizar el nombre de la aplicación y luego coordinar la asignación de valores de subtipo a otras personas que
desea definir nuevos tipos de paquetes para la aplicación. Alternativamente, se recomienda que
otros eligen un nombre basándose en la entidad que representan y luego coordinan el uso del nombre
dentro de esa entidad. El nombre se interpreta como una secuencia de cuatro caracteres ASCII, con
los caracteres en mayúsculas y minúsculas se tratan como distintos.

datos dependientes de la aplicación: longitud variable

Los datos dependientes de la aplicación pueden aparecer o no en un paquete de APP. Es interpretado por
la aplicación y no el RTP en sí. Debe tener una longitud múltiplo de 32 bits.

Schulzrinne, et al. Seguimiento de estándares [Página 44]

Machine Translated by Google

RFC 3550 RTP julio de 2003

7. Traductores y mezcladores RTP

Además de los sistemas finales, RTP apoya la noción de "traductores" y "mezcladores", que podrían considerarse como "sistemas
intermedios" a nivel de RTP. Aunque este soporte añade cierta complejidad al protocolo, la necesidad de estas funciones ha quedado
claramente establecida mediante experimentos con aplicaciones de multidifusión de audio y vídeo en Internet. Los ejemplos de uso
de traductores y mezcladores que se dan en la Sección 2.3 se derivan de la presencia de firewalls y conexiones de bajo ancho de
banda, los cuales probablemente se mantendrán.

7.1 Descripción general

Un traductor/mezclador RTP conecta dos o más “nubes” a nivel de transporte. Normalmente, cada nube está definida por una red
común y un protocolo de transporte (por ejemplo, IP/UDP) más una dirección de multidifusión y un puerto de destino a nivel de
transporte o un par de direcciones y puertos de unidifusión. (Los traductores de protocolos a nivel de red, como IP versión 4 a IP
versión 6, pueden estar presentes dentro de una nube de manera invisible para RTP).
Un sistema puede servir como traductor o mezclador para varias sesiones RTP, pero cada una se considera una entidad lógicamente
separada.

Para evitar la creación de un bucle cuando se instala un traductor o mezclador, se deben observar las siguientes reglas:

• Cada una de las nubes conectadas por traductores y mezcladores que participan en una sesión RTP debe ser distinta de todas
las demás en al menos uno de estos parámetros (protocolo, dirección, puerto) o debe estar aislada a nivel de red de las
demás.

• Una derivación de la primera regla es que no debe haber múltiples traductores o mezcladores conectados en paralelo a
menos que mediante algún arreglo dividan el conjunto de fuentes que se van a reenviar.

De manera similar, todos los sistemas finales RTP que pueden comunicarse a través de uno o más traductores o mezcladores RTP
comparten el mismo espacio SSRC, es decir, los identificadores SSRC deben ser únicos entre todos estos sistemas finales. La
Sección 8.2 describe el algoritmo de resolución de colisiones mediante el cual los identificadores SSRC se mantienen únicos y se
detectan bucles.

Puede haber muchas variedades de traductores y mezcladores diseñados para diferentes propósitos y aplicaciones. Algunos
ejemplos son agregar o eliminar cifrado, cambiar la codificación de los datos o los protocolos subyacentes, o replicar entre una
dirección de multidifusión y una o más direcciones de unidifusión.
La distinción entre traductores y mezcladores es que un traductor pasa los flujos de datos de diferentes fuentes por separado,
mientras que un mezclador los combina para formar un nuevo flujo:

Traductor: reenvía paquetes RTP con su identificador SSRC intacto; esto hace posible que los receptores identifiquen fuentes
individuales incluso aunque los paquetes de todas las fuentes pasen por el mismo traductor y lleven la dirección de origen de
la red del traductor. Algunos tipos de traductores pasarán los datos intactos, pero otros pueden cambiar la codificación de
los datos y, por lo tanto, el tipo de carga útil y la marca de tiempo de los datos RTP. Si se recodifican varios paquetes de
datos en uno, o viceversa, un traductor debe asignar nuevos números de secuencia a los paquetes salientes. Las pérdidas
en el flujo de paquetes entrantes pueden provocar brechas correspondientes en el flujo de paquetes salientes.

Schulzrinne, et al. Seguimiento de estándares [Página 45]

Machine Translated by Google

RFC 3550 RTP julio de 2003

números de secuencia. Los receptores no pueden detectar la presencia de un traductor a menos que sepan por algún otro
medio qué tipo de carga útil o dirección de transporte utilizó la fuente original.

Mezclador: recibe flujos de paquetes de datos RTP de una o más fuentes, posiblemente cambia el formato de los datos, combina los
flujos de alguna manera y luego reenvía el flujo combinado. Dado que la sincronización entre múltiples fuentes de entrada
generalmente no estará sincronizada, el mezclador realizará ajustes de sincronización entre las transmisiones y generará su
propia sincronización para la transmisión combinada, por lo que es la fuente de sincronización. Por lo tanto, todos los
paquetes de datos reenviados por un mezclador deben estar marcados con el identificador SSRC del propio mezclador. Para
preservar la identidad de las fuentes originales que contribuyen al paquete mixto, el mezclador debe insertar sus identificadores
SSRC en la lista de identificadores CSRC después del encabezado RTP fijo del paquete. Un mezclador que también sea una
fuente contribuyente para algún paquete debe incluir explícitamente su propio identificador SSRC en la lista CSRC para ese
paquete.

Para algunas aplicaciones, puede ser aceptable que un mezclador no identifique fuentes en la lista CSRC. Sin embargo, esto
introduce el peligro de que no se puedan detectar los bucles que involucran esas fuentes.

La ventaja de un mezclador sobre un traductor para aplicaciones como audio es que el ancho de banda de salida está limitado al de
una fuente incluso cuando hay varias fuentes activas en el lado de entrada. Esto puede ser importante para enlaces de bajo ancho
de banda. La desventaja es que los receptores en el lado de salida no tienen ningún control sobre qué fuentes pasan o silenciadas,
a menos que se implemente algún mecanismo para el control remoto del mezclador. La regeneración de la información de
sincronización por parte de los mezcladores también significa que los receptores no pueden realizar la sincronización intermedia de
las transmisiones originales. Un mezclador multimedia podría hacerlo.

En la Fig. 3 se muestra una colección de mezcladores y traductores para ilustrar su efecto en los identificadores SSRC y CSRC. En
la figura, los sistemas finales se muestran como rectángulos (llamados E), los traductores como triángulos (llamados T) y los
mezcladores como óvalos (llamados M). La notación "M1: 48(1,17)" designa un paquete que se origina en un mezclador M1,
identificado por el valor SSRC (aleatorio) de M1 de 48 y dos identificadores CSRC, 1 y 17, copiados de los identificadores SSRC de
los paquetes de E1 y E2. .

7.2 Procesamiento RTCP en traductores

Además de reenviar paquetes de datos, quizás modificados, los traductores y mezcladores también deben procesar paquetes RTCP.
En muchos casos, separarán los paquetes RTCP compuestos recibidos de los sistemas finales para agregar información SDES y
modificar los paquetes SR o RR. La retransmisión de esta información puede ser activada por la llegada del paquete o por el
temporizador de intervalo RTCP del propio traductor o mezclador.

Un traductor que no modifica los paquetes de datos, por ejemplo uno que simplemente replica entre una dirección de multidifusión y
una dirección de unidifusión, también puede simplemente reenviar paquetes RTCP sin modificar. Un traductor que transforma la
carga útil de alguna manera debe realizar las transformaciones correspondientes en la información SR y RR para que aún refleje las
características de los datos y la calidad de recepción. Estos traductores no deben simplemente reenviar paquetes RTCP. En general,
un traductor no debe agregar paquetes SR y RR de diferentes fuentes en un solo paquete, ya que eso reduciría la precisión de las
mediciones del retardo de propagación basadas en los campos LSR y DLSR.

Schulzrinne, et al. Seguimiento de estándares [Página 46]

Machine Translated by Google

RFC 3550 RTP julio de 2003

sistema final

E1 E6

E1:17 E6:15
traductor
E6:15
M1 M1:48(1,17) M1: 48(1,17) M1:48(1,17)
T1 T2 E7
mezclador
E4:47 E4:47
M3:89(64,45)
E2:1 E4:47

E2 E4 M3: 89(64,45)

Leyenda:
E3 M2 M3
E3:64 M2:12(64) fuente: SSRC (CSRC,...)

E5:45

E5

Figura 3: Ejemplo de red RTP con sistemas finales, mezcladores y traductores

Información del remitente SR: un traductor no genera su propia información del remitente, sino que reenvía los paquetes SR recibidos
de una nube a las demás. El SSRC se deja intacto pero la información del remitente debe modificarse si así lo requiere la
traducción. Si un traductor cambia la codificación de datos, debe cambiar el campo "recuento de bytes del remitente". Si
también combina varios paquetes de datos en un paquete de salida, debe cambiar el campo "recuento de paquetes del
remitente". Si cambia la frecuencia de la marca de tiempo, debe cambiar el campo "marca de tiempo RTP" en el paquete SR.

Bloques de informes de recepción SR/RR: un traductor reenvía los informes de recepción recibidos de una nube a las demás. Tenga
en cuenta que estos fluyen en la dirección opuesta a los datos. La SSRC queda intacta. Si un traductor combina varios
paquetes de datos en un paquete de salida y, por lo tanto, cambia los números de secuencia, debe realizar la manipulación
inversa para los campos de pérdida de paquetes y el campo "último número de secuencia extendido". Esto puede resultar
complejo. En el caso extremo, puede que no exista una forma significativa de traducir los informes de recepción, por lo que
el traductor puede no transmitir ningún informe de recepción o emitir un informe sintético basado en su propia recepción. La
regla general es hacer lo que tenga sentido para una traducción particular.

Un traductor no requiere un identificador SSRC propio, pero puede optar por asignar uno con el fin de enviar informes sobre
lo que ha recibido. Estos se enviarían a todas las nubes conectadas, correspondiendo cada una a la traducción del flujo de
datos enviado a esa nube, ya que los informes de recepción normalmente se multidifunden a todos los participantes.

SDES: Los traductores normalmente reenvían sin cambios la información SDES que reciben de uno

Schulzrinne, et al. Seguimiento de estándares [Página 47]

Machine Translated by Google

RFC 3550 RTP julio de 2003

nube a los demás, pero puede, por ejemplo, decidir filtrar información SDES que no sea CNAME si el ancho de banda es
limitado. Los CNAME deben reenviarse para permitir que funcione la detección de colisiones del identificador SSRC. Un
traductor que genera sus propios paquetes RR debe enviar información SDES CNAME sobre sí mismo a las mismas nubes
a las que envía esos paquetes RR.

BYE: Los traductores reenvían los paquetes BYE sin cambios. Un traductor que está a punto de dejar de reenviar paquetes debe
enviar un paquete BYE a cada nube conectada que contenga todos los identificadores SSRC que se estaban reenviando
previamente a esa nube, incluido el propio identificador SSRC del traductor si envió sus propios informes.

APP: Los traductores reenvían los paquetes de APP sin cambios.

7.3 Procesamiento RTCP en mezcladores

Dado que un mezclador genera un nuevo flujo de datos propio, no pasa ningún paquete SR o RR y en su lugar genera nueva
información para ambos lados.

Información del remitente SR: un mezclador no pasa la información del remitente de las fuentes que mezcla porque las características
de los flujos fuente se pierden en la mezcla. Como fuente de sincronización, el mezclador debe generar sus propios paquetes
SR con información del remitente sobre el flujo de datos mixto y enviarlos en la misma dirección que el flujo mixto.

Bloques de informes de recepción SR/RR: un mezclador genera sus propios informes de recepción para las fuentes en cada nube y
los envía solo a la misma nube. No debe enviar estos informes de recepción a las otras nubes y no debe reenviar informes
de recepción de una nube a las demás porque las fuentes no serían SSRC allí (solo CSRC).

SDES: los mezcladores normalmente reenvían sin cambios la información SDES que reciben de una nube a las demás, pero pueden,
por ejemplo, decidir filtrar información SDES que no sea CNAME si el ancho de banda es limitado. Los CNAME deben
reenviarse para permitir que funcione la detección de colisiones del identificador SSRC. (Un identificador en una lista CSRC

generada por un mezclador podría colisionar con un identificador SSRC generado por un sistema final). Un mezclador debe
enviar información SDES CNAME sobre sí mismo a las mismas nubes a las que envía paquetes SR o RR.

Dado que los mezcladores no reenvían paquetes SR o RR, normalmente extraerán paquetes SDES de un paquete RTCP
compuesto. Para minimizar la sobrecarga, los fragmentos de los paquetes SDES se pueden agregar en un único paquete
SDES que luego se apila en un paquete SR o RR que se origina en el mezclador. Un mezclador que agrega paquetes SDES
utilizará más ancho de banda RTCP que una fuente individual porque los paquetes compuestos serán más largos, pero eso
es apropiado ya que el mezclador representa múltiples fuentes. De manera similar, un mezclador que pasa a través de
paquetes SDES a medida que se reciben transmitirá paquetes RTCP a una velocidad superior a la de una sola fuente, pero
nuevamente eso es correcto ya que los paquetes provienen de múltiples fuentes.

La velocidad de los paquetes RTCP puede ser diferente en cada lado del mezclador.

Un mezclador que no inserta identificadores CSRC también puede abstenerse de reenviar SDES CNAME. En este caso, los
espacios del identificador SSRC en las dos nubes son independientes. Como se mencionó anteriormente, este modo de
operación crea el peligro de que no se puedan detectar los bucles.

Schulzrinne, et al. Seguimiento de estándares [Página 48]

Machine Translated by Google

RFC 3550 RTP julio de 2003

BYE: Los mezcladores deben reenviar paquetes de BYE. Un mezclador que está a punto de dejar de reenviar paquetes debe enviar un
paquete BYE a cada nube conectada que contenga todos los identificadores SSRC que se estaban reenviando previamente a esa
nube, incluido el propio identificador SSRC del mezclador si envió sus propios informes.

APP: El tratamiento de los paquetes APP por parte de los mezcladores es específico de la aplicación.

7.4 Mezcladores en cascada

Una sesión RTP puede involucrar una colección de mezcladores y traductores como se muestra en la Fig. 3. Si dos mezcladores están en
cascada, como M2 y M3 en la figura, es posible que los paquetes recibidos por un mezclador ya se hayan mezclado y pueden incluir una
lista CSRC con múltiples identificadores. El segundo mezclador debe crear la lista CSRC para el paquete saliente utilizando los
identificadores CSRC de paquetes de entrada ya mezclados y los identificadores SSRC de paquetes de entrada no mezclados. Esto se
muestra en el arco de salida del mezclador M3 etiquetado como M3:89(64,45) en la figura. Como en el caso de los mezcladores que no
están en cascada, si la lista CSRC resultante tiene más de 15 identificadores, el resto no se puede incluir.

8. Asignación y uso del identificador SSRC

El identificador SSRC incluido en el encabezado RTP y en varios campos de los paquetes RTCP es un número aleatorio de 32 bits que
debe ser globalmente único dentro de una sesión RTP. Es fundamental que el número se elija con cuidado para que no sea probable que
los participantes de la misma red o que comienzan al mismo tiempo elijan el mismo número.

No es suficiente utilizar la dirección de red local (como una dirección IPv4) para el identificador porque la dirección puede no ser única.
Dado que los traductores y mezcladores RTP permiten la interoperación entre múltiples redes con diferentes espacios de direcciones, los
patrones de asignación de direcciones dentro de dos espacios podrían resultar en una tasa de colisión mucho mayor que la que ocurriría
con la asignación aleatoria.
Varias fuentes que se ejecutan en un host también entrarían en conflicto.

Tampoco es suficiente obtener un identificador SSRC simplemente llamando a random() sin inicializar cuidadosamente el estado. En el
Apéndice A.6 se presenta un ejemplo de cómo generar un identificador aleatorio.

8.1 Probabilidad de colisión

Dado que los identificadores se eligen al azar, es posible que dos o más fuentes elijan el mismo número. La colisión ocurre con la mayor
probabilidad cuando todas las fuentes se inician simultáneamente, por ejemplo, cuando se activa automáticamente por algún evento de
gestión de sesión. Si N es el número de fuentes y L la longitud del identificador (aquí, 32 bits), la probabilidad de que dos fuentes elijan
independientemente el mismo valor puede aproximarse para N grande [26, p. 33] como 1 − e−N2/2L+1 .

Para N = 1000, la probabilidad es aproximadamente 10−4.

La probabilidad de colisión típica es mucho menor que la del peor de los casos mencionados anteriormente. Cuando una nueva fuente se
une a una sesión RTP en la que todas las demás fuentes ya tienen identificadores únicos, la probabilidad de colisión es solo la fracción de
los números utilizados fuera del espacio. Nuevamente, si N es el número de

Schulzrinne, et al. Seguimiento de estándares [Página 49]

Machine Translated by Google

RFC 3550 RTP julio de 2003

fuentes y L la longitud del identificador, la probabilidad de colisión es N/2L. Para N = 1000, la probabilidad es aproximadamente 2 ∙
10−7.

La probabilidad de colisión se reduce aún más por la oportunidad que tiene una nueva fuente de recibir paquetes de otros participantes
antes de enviar su primer paquete (ya sea de datos o de control). Si la nueva fuente realiza un seguimiento de los demás participantes
(mediante el identificador SSRC), antes de transmitir su primer paquete, la nueva fuente puede verificar que su identificador no entre
en conflicto con ninguno de los que se hayan recibido, o elegir nuevamente.

8.2 Resolución de colisiones y detección de bucles

Aunque la probabilidad de colisión de identificadores SSRC es baja, todas las implementaciones de RTP deben estar preparadas
para detectar colisiones y tomar las acciones apropiadas para resolverlas. Si una fuente descubre en cualquier momento que otra
fuente está utilizando el mismo identificador SSRC que el suyo, debe enviar un paquete RTCP BYE para el identificador anterior
y elegir otro aleatorio. (Como se explica a continuación, este paso se realiza sólo una vez en caso de un bucle). Si un receptor
descubre que otras dos fuentes están colisionando, puede conservar los paquetes de una y descartar los paquetes de la otra
cuando esto pueda ser detectado por diferentes fuentes. direcciones de transporte de origen o CNAME. Se espera que las dos
fuentes resuelvan el conflicto para que la situación no dure.

Debido a que los identificadores SSRC aleatorios se mantienen globalmente únicos para cada sesión RTP, también se pueden usar
para detectar bucles que pueden introducir mezcladores o traductores. Un bucle provoca la duplicación de datos e información de
control, ya sea sin modificar o posiblemente mezclada, como en los siguientes ejemplos:

• Un traductor puede reenviar incorrectamente un paquete al mismo grupo de multidifusión del que recibió el paquete, ya sea
directamente o a través de una cadena de traductores. En ese caso, el mismo paquete aparece varias veces, procedente de
diferentes fuentes de red.

• Dos traductores configurados incorrectamente en paralelo, es decir, con los mismos grupos de multidifusión en ambos lados,
reenviarían paquetes de un grupo de multidifusión al otro. Los traductores unidireccionales producirían dos copias; Los
traductores bidireccionales formarían un bucle.

• Un mezclador puede cerrar un bucle enviando paquetes al mismo destino de transporte en el que recibe, ya sea directamente
o a través de otro mezclador o traductor. En este caso, una fuente podría aparecer como SSRC en un paquete de datos y
como CSRC en un paquete de datos mixto.

Una fuente puede descubrir que se están repitiendo sus propios paquetes o que se están repitiendo paquetes de otra fuente (un
bucle de terceros).

Tanto los bucles como las colisiones en la selección aleatoria de un identificador de origen dan como resultado paquetes que llegan
con el mismo identificador SSRC pero una dirección de transporte de origen diferente, que puede ser la del sistema final que origina
el paquete o un sistema intermedio. Por lo tanto, si una fuente cambia su dirección de transporte de origen, también puede elegir un
nuevo identificador SSRC para evitar que se interprete como una fuente en bucle. (Esto no es obligatorio porque en algunas
aplicaciones de fuentes RTP se puede esperar que las fuentes cambien de dirección durante una sesión). Tenga en cuenta que si un
traductor se reinicia y, en consecuencia, cambia la dirección de transporte de origen (por ejemplo, cambia el número de puerto de
origen UDP) al que reenvía paquetes, entonces todos esos paquetes aparecerán ante los receptores como en bucle porque los
identificadores SSRC son aplicados por la fuente original y no cambiarán. Este problema se puede evitar manteniendo

Schulzrinne, et al. Seguimiento de estándares [Página 50]

Machine Translated by Google

RFC 3550 RTP julio de 2003

la dirección de transporte de origen se fija durante los reinicios, pero en cualquier caso se resolverá después de un tiempo de espera
en los receptores.

Los bucles o colisiones que ocurren en el lado lejano de un traductor o mezclador no se pueden detectar usando la dirección de
transporte de origen si todas las copias de los paquetes pasan por el traductor o mezclador; sin embargo, aún se pueden detectar
colisiones cuando fragmentos de dos paquetes RTCP SDES contienen el Mismo identificador SSRC pero diferentes CNAME.

Para detectar y resolver estos conflictos, una implementación RTP debe incluir un algoritmo similar al que se describe a continuación,
aunque la implementación puede elegir una política diferente para la cual se conservan los paquetes de fuentes de terceros en
conflicto. El algoritmo que se describe a continuación ignora los paquetes de una nueva fuente o bucle que chocan con una fuente
establecida. Resuelve colisiones con el identificador SSRC del participante enviando un RTCP BYE para el identificador anterior y
eligiendo uno nuevo. Sin embargo, cuando la colisión fue inducida por un bucle de los propios paquetes del participante, el algoritmo
elegirá un nuevo identificador sólo una vez y posteriormente ignorará los paquetes de la dirección de transporte de origen del bucle.
Esto es necesario para evitar una avalancha de paquetes BYE.

Este algoritmo requiere mantener una tabla indexada por el identificador de origen y que contenga las direcciones de transporte de
origen del primer paquete RTP y el primer paquete RTCP recibido con ese identificador, junto con otro estado de ese origen. Se
requieren dos direcciones de transporte de origen ya que, por ejemplo, los números de puerto de origen UDP pueden ser diferentes
en los paquetes RTP y RTCP. Sin embargo, se puede suponer que la dirección de red es la misma en ambas direcciones de
transporte de origen.

Cada identificador SSRC o CSRC recibido en un paquete RTP o RTCP se busca en la tabla de identificadores de origen para
procesar esos datos o controlar la información. La dirección de transporte de origen del paquete se compara con la dirección de
transporte de origen correspondiente en la tabla para detectar un bucle o una colisión si no coinciden. Para los paquetes de control,
cada elemento con su propio identificador SSRC, por ejemplo un fragmento SDES, requiere una búsqueda por separado. (El
identificador SSRC en un bloque de informe de recepción es una excepción porque identifica una fuente escuchada por el reportero,
y ese identificador SSRC no está relacionado con la dirección de transporte de origen del paquete RTCP enviado por el reportero.)
Si el SSRC o CSRC no está encontrado, se crea una nueva entrada. Estas entradas de la tabla se eliminan cuando se recibe un
paquete RTCP BYE con el identificador SSRC correspondiente y se valida mediante una dirección de transporte de origen coincidente,
o después de que no haya llegado ningún paquete durante un tiempo relativamente largo (consulte la Sección 6.2.1).

Tenga en cuenta que si dos fuentes en el mismo host están transmitiendo con el mismo identificador de fuente en el momento en
que un receptor comienza a funcionar, sería posible que el primer paquete RTP recibido viniera de una de las fuentes mientras que
el primer paquete RTCP recibido viniera de la otra. . Esto provocaría que se asociara información RTCP incorrecta con los datos
RTP, pero esta situación debería ser lo suficientemente rara e inofensiva como para poder ignorarla.

Para rastrear los bucles de los propios paquetes de datos del participante, la implementación también debe mantener una lista
separada de direcciones de transporte de origen (no identificadores) que se hayan encontrado en conflicto.
Al igual que en la tabla de identificadores de origen, se deben mantener dos direcciones de transporte de origen para realizar un
seguimiento por separado de los paquetes RTP y RTCP en conflicto. Tenga en cuenta que la lista de direcciones en conflicto debe
ser breve y normalmente vacía. Cada elemento de esta lista almacena las direcciones de origen más la hora en que se recibió el
paquete conflictivo más reciente. Un elemento puede eliminarse de la lista cuando no ha llegado ningún paquete conflictivo desde
esa fuente durante un tiempo del orden de 10 intervalos de informe RTCP (consulte la Sección 6.2).

Schulzrinne, et al. Seguimiento de estándares [Página 51]

Machine Translated by Google

RFC 3550 RTP julio de 2003

Para el algoritmo que se muestra, se supone que el identificador de origen y el estado del propio participante están
incluidos en la tabla de identificadores de origen. El algoritmo podría reestructurarse para hacer primero una comparación
separada con el identificador de fuente del propio participante.

si (el identificador SSRC o CSRC no se encuentra en la tabla de identificadores

de origen) { cree una nueva
entrada que almacene los datos o controle la fuente
dirección de transporte, la SSRC o CSRC y otro estado;
}

/* El identificador se encuentra en la tabla */

else if (la entrada de la tabla se creó al recibir un paquete de control y este es el primer
paquete de datos o viceversa) {
almacenar la dirección de transporte de origen de este paquete;
}
else if (la dirección de transporte de origen del paquete no coincide con la guardada en la
entrada de la tabla para este identificador) {

/* Se indica una colisión de identificadores o un bucle */

if (el identificador de fuente no es el propio del participante) {

/* Paso del contador de errores OPCIONAL */ si
(el identificador de origen proviene de un fragmento RTCP SDES
que contiene un elemento CNAME que difiere del CNAME en la entrada
de la tabla) { cuenta una
colisión de terceros; } else { cuenta un bucle
de terceros;

}
cancelar el procesamiento del paquete de datos o del elemento de control;
/* PUEDE elegir una política diferente para mantener la nueva fuente */
}

/* Una colisión o bucle de los propios paquetes del participante */

de lo contrario, si (la dirección de transporte de origen se encuentra en la lista de

datos en conflicto o direcciones de transporte de origen de
control) {
/* Paso del contador de errores OPCIONAL */ si
(el identificador de origen no proviene de un fragmento RTCP SDES
que contiene un elemento CNAME o CNAME es propio
del participante) { cuenta la
ocurrencia de tráfico propio en bucle;
}

Schulzrinne, et al. Seguimiento de estándares [Página 52]

Machine Translated by Google

RFC 3550 RTP julio de 2003

marcar la hora actual en una entrada conflictiva de la lista de direcciones;

cancelar el procesamiento de un paquete de datos o un elemento de control;
}

/* Nueva colisión, cambio de identificador SSRC */

else
{ registra la ocurrencia de una colisión; crear
una nueva entrada en los datos o controles en conflicto
lista de direcciones de transporte de origen y marca la hora actual;
enviar un paquete RTCP BYE con el antiguo identificador SSRC; elija un
nuevo identificador SSRC; cree una nueva
entrada en la tabla de identificadores de origen con
el SSRC antiguo más la dirección de transporte de origen del paquete de
datos o de control que se está procesando;
}
}

En este algoritmo, los paquetes de una dirección de origen recientemente conflictiva se ignorarán y los paquetes de la
dirección de origen original se conservarán. Si no llegan paquetes de la fuente original durante un período prolongado,
se expirará el tiempo de espera de la entrada en la tabla y la nueva fuente podrá tomar el control.
Esto puede ocurrir si la fuente original detecta la colisión y pasa a un nuevo identificador de fuente, pero en el caso
habitual se recibirá un paquete RTCP BYE de la fuente original para eliminar el estado sin tener que esperar un tiempo
de espera.

Si la dirección de origen original se recibió a través de un mezclador (es decir, se aprendió como CSRC) y luego se
recibe la misma fuente directamente, se puede recomendar al receptor que cambie a la nueva dirección de origen a
menos que se pierdan otras fuentes en la mezcla. Además, para aplicaciones como la telefonía en las que algunas
fuentes, como entidades móviles, pueden cambiar de dirección durante el transcurso de una sesión RTP, la
implementación de RTP debe modificar el algoritmo de detección de colisiones para aceptar paquetes de la nueva
dirección de transporte de origen. Para protegerse contra cambios entre direcciones si ocurre una colisión genuina, el
algoritmo debe incluir algunos medios para detectar este caso y evitar cambios.

Cuando se elige un nuevo identificador SSRC debido a una colisión, primero se debe buscar el identificador candidato
en la tabla de identificadores de origen para ver si ya estaba en uso por alguna otra fuente. De ser así, se debe generar
otro candidato y repetir el proceso.

Un bucle de paquetes de datos a un destino de multidifusión puede provocar una inundación grave de la red. Todos los
mezcladores y traductores deben implementar un algoritmo de detección de bucles como el que se muestra aquí para
poder romper los bucles. Esto debería limitar el exceso de tráfico a no más de una copia duplicada del tráfico original, lo
que puede permitir que la sesión continúe para que se pueda encontrar y solucionar la causa del bucle. Sin embargo, en
casos extremos en los que un mezclador o traductor no interrumpe adecuadamente el bucle y se producen altos niveles
de tráfico, puede ser necesario que los sistemas finales dejen de transmitir datos o controlar paquetes por completo.
Esta decisión puede depender de la aplicación. Una condición de error debe indicarse según corresponda. La transmisión
se puede volver a intentar periódicamente después de un tiempo prolongado y aleatorio (del orden de minutos).

Schulzrinne, et al. Seguimiento de estándares [Página 53]

Machine Translated by Google

RFC 3550 RTP julio de 2003

8.3 Uso con codificaciones en capas

Para codificaciones en capas transmitidas en sesiones RTP separadas (consulte la Sección 2.4), se debe usar un único espacio de
identificador SSRC en las sesiones de todas las capas y se debe usar la capa central (base) para la asignación de identificadores
SSRC y la resolución de colisiones. Cuando una fuente descubre que ha chocado, transmite un paquete RTCP BYE solo en la capa
base, pero cambia el identificador SSRC al nuevo valor en todas las capas.

9. Seguridad

Los protocolos de capa inferior pueden llegar a proporcionar todos los servicios de seguridad que puedan desearse para las
aplicaciones de RTP, incluidas la autenticación, la integridad y la confidencialidad. Estos servicios se han especificado para IP en
[27]. Dado que las aplicaciones iniciales de audio y video que usaban RTP necesitaban un servicio de confidencialidad antes de que
dichos servicios estuvieran disponibles para la capa IP, el servicio de confidencialidad descrito en la siguiente sección se definió para
su uso con RTP y RTCP. Esa descripción se incluye aquí para codificar la práctica existente. Las nuevas aplicaciones de RTP
pueden implementar este servicio de confidencialidad específico de RTP para compatibilidad con versiones anteriores y/o pueden
implementar servicios de seguridad alternativos. La sobrecarga del protocolo RTP para este servicio de confidencialidad es baja, por
lo que la penalización será mínima si este servicio queda obsoleto por otros servicios en el futuro.

Alternativamente, se pueden definir otros servicios, otras implementaciones de servicios y otros algoritmos para RTP en el futuro. En
particular, se está desarrollando un perfil RTP llamado Protocolo seguro de transporte en tiempo real (SRTP) [28] para proporcionar
confidencialidad de la carga útil RTP y al mismo tiempo dejar el encabezado RTP en claro para que los algoritmos de compresión de
encabezados a nivel de enlace aún puedan funcionar. Se espera que SRTP sea la elección correcta para muchas aplicaciones.
SRTP se basa en el Estándar de cifrado avanzado (AES) y proporciona una seguridad más sólida que el servicio que se describe
aquí. No se afirma que los métodos presentados aquí sean apropiados para una necesidad de seguridad particular. Un perfil puede
especificar qué servicios y algoritmos deben ofrecer las aplicaciones y puede proporcionar orientación sobre su uso apropiado.

La distribución de claves y los certificados están fuera del alcance de este documento.

9.1 Confidencialidad

Confidencialidad significa que sólo el receptor previsto puede decodificar los paquetes recibidos; para otros, el paquete no contiene
información útil. La confidencialidad del contenido se logra mediante cifrado.

Cuando se desea cifrar RTP o RTCP según el método especificado en esta sección, todos los octetos que se encapsularán para su
transmisión en un único paquete de capa inferior se cifran como una unidad. Para RTCP, se debe anteponer a la unidad un número
aleatorio de 32 bits redibujado para cada unidad antes del cifrado. Para RTP, no se antepone ningún prefijo; en cambio, los campos
de número de secuencia y marca de tiempo se inicializan con desplazamientos aleatorios. Este se considera un vector de inicialización
(IV) débil debido a sus malas propiedades de aleatoriedad. Además, si el campo siguiente, el SSRC, puede ser manipulado por un
enemigo, el método de cifrado presenta mayores debilidades.

Para RTCP, una implementación puede segregar los paquetes RTCP individuales en un RTCP compuesto.

Schulzrinne, et al. Seguimiento de estándares [Página 54]

Machine Translated by Google

RFC 3550 RTP julio de 2003

paquete en dos paquetes RTCP compuestos separados, uno para cifrarse y otro para enviarse sin cifrar. Por ejemplo, la información
SDES podría cifrarse mientras que los informes de recepción se enviaban sin cifrar para dar cabida a monitores de terceros que no
tienen acceso a la clave de cifrado. En este ejemplo, representado en la Fig. 4, la información SDES debe agregarse a un paquete
RR sin informes (y el número aleatorio) para satisfacer el requisito de que todos los paquetes RTCP compuestos comiencen con un
paquete SR o RR. El elemento SDES CNAME es necesario en el paquete cifrado o no cifrado, pero no en ambos. No se debe
transportar la misma información SDES en ambos paquetes ya que esto puede comprometer el cifrado.

Int
aleatorio de 32 bits.
paquete UDP paquete UDP

RR informe
SSRC

CNOMBRE

SSRC

SSRC

SSRC
SDES
SR sitio 1 sitio 2
(vacío) del remitente

cifrado no encriptado

encabezado de paquete RTCP fijo

Figura 4: Paquetes RTCP cifrados y no cifrados

El receptor confirma la presencia de cifrado y el uso de la clave correcta mediante comprobaciones de validez del encabezado o de
la carga útil. En los Apéndices A.1 y A.2 se dan ejemplos de tales comprobaciones de validez para encabezamientos RTP y RTCP.

Para ser coherente con las implementaciones existentes de la especificación inicial de RTP en RFC 1889, el algoritmo de cifrado
predeterminado es el algoritmo Estándar de cifrado de datos (DES) en modo de encadenamiento de bloques de cifrado (CBC), como
se describe en la Sección 1.1 de RFC 1423 [29]. excepto que el relleno hasta un múltiplo de 8 octetos se indica como se describe
para el bit P en la Sección 5.1. El vector de inicialización es cero porque los valores aleatorios se proporcionan en el encabezado
RTP o mediante el prefijo aleatorio para paquetes RTCP compuestos. Para obtener detalles sobre el uso de vectores de inicialización
CBC, consulte [30].

Las implementaciones que admiten el método de cifrado especificado aquí siempre deben admitir el algoritmo DES en modo CBC
como cifrado predeterminado para este método para maximizar la interoperabilidad.
Se eligió este método porque se ha demostrado que es fácil y práctico de utilizar en herramientas experimentales de audio y vídeo
que funcionan en Internet. Sin embargo, desde entonces se ha descubierto que DES se rompe con demasiada facilidad. Se
recomienda utilizar algoritmos de cifrado más potentes, como Triple­DES, en lugar del algoritmo predeterminado. Además, el modo
CBC seguro requiere que el primer bloque de cada paquete sea sometido a una operación XOR con un IV independiente y aleatorio
del mismo tamaño que el tamaño del bloque del cifrado. Para RTCP, esto se logra (parcialmente) anteponiendo a cada paquete un
número aleatorio de 32 bits, elegido independientemente para cada paquete. Para RTP, la marca de tiempo y el número de secuencia
comienzan a partir de valores aleatorios, pero los paquetes consecutivos no se aleatorizarán de forma independiente. Cabe señalar
que la aleatoriedad en ambos casos (RTP y RTCP) es limitada.

Las aplicaciones de alta seguridad deberían considerar otros medios de protección más convencionales. Se pueden especificar
dinámicamente otros algoritmos de cifrado para una sesión por medios que no sean RTP. En particular,

Schulzrinne, et al. Seguimiento de estándares [Página 55]

Machine Translated by Google

RFC 3550 RTP julio de 2003

El perfil SRTP [28] basado en AES se está desarrollando para tener en cuenta las preocupaciones conocidas sobre manipulación de
texto plano y CBC, y será la opción correcta en el futuro.

Como alternativa al cifrado a nivel de IP o a nivel de RTP como se describe anteriormente, los perfiles pueden definir tipos de carga
útiles adicionales para codificaciones cifradas. Esas codificaciones deben especificar cómo se deben manejar el relleno y otros
aspectos del cifrado. Este método permite cifrar solo los datos y deja los encabezados claros para las aplicaciones donde así se
desee. Puede resultar particularmente útil para dispositivos de hardware que se encargarán tanto del descifrado como de la
decodificación. También es valioso para aplicaciones donde se desea la compresión a nivel de enlace de RTP y encabezados de
capa inferior y la confidencialidad de la carga útil (pero no de las direcciones) es suficiente ya que el cifrado de los encabezados
excluye la compresión.

9.2 Autenticación e integridad del mensaje

Los servicios de autenticación e integridad de mensajes no están definidos a nivel RTP ya que estos servicios no serían directamente
factibles sin una infraestructura de administración de claves. Se espera que los servicios de autenticación e integridad sean
proporcionados por protocolos de capa inferior.

10. Control de congestión

Todos los protocolos de transporte utilizados en Internet deben abordar el control de la congestión de alguna manera [31].
RTP no es una excepción, pero debido a que los datos transportados a través de RTP suelen ser inelásticos (generados a una
velocidad fija o controlada), los medios para controlar la congestión en RTP pueden ser bastante diferentes de los de otros protocolos
de transporte como TCP. En cierto sentido, la inelasticidad reduce el riesgo de congestión porque el flujo RTP no se expandirá para
consumir todo el ancho de banda disponible como puede hacerlo un flujo TCP. Sin embargo, la inelasticidad también significa que el
flujo RTP no puede reducir arbitrariamente su carga en la red para eliminar la congestión cuando ocurre.

Dado que RTP se puede utilizar para una amplia variedad de aplicaciones en muchos contextos diferentes, no existe un mecanismo
único de control de congestión que funcione para todos. Por lo tanto, el control de la congestión debe definirse en cada perfil RTP
según corresponda. Para algunos perfiles, puede ser suficiente incluir una declaración de aplicabilidad que restrinja el uso de ese
perfil a entornos donde la ingeniería evita la congestión. Para otros perfiles, es posible que se requieran métodos específicos, como
la adaptación de la velocidad de datos basada en la retroalimentación RTCP.

11. RTP sobre protocolos de red y transporte

Esta sección describe cuestiones específicas del transporte de paquetes RTP dentro de una red particular y protocolos de transporte.
Las siguientes reglas se aplican a menos que sean reemplazadas por definiciones específicas del protocolo fuera de esta
especificación.

RTP se basa en los protocolos subyacentes para proporcionar demultiplexación de datos RTP y flujos de control RTCP. Para UDP y
protocolos similares, RTP debe usar un número de puerto de destino par y el flujo RTCP correspondiente debe usar el siguiente
número de puerto de destino superior (impar). Para aplicaciones que toman un único número de puerto como parámetro y derivan el
puerto RTP y RTCP

Schulzrinne, et al. Seguimiento de estándares [Página 56]

Machine Translated by Google

RFC 3550 RTP julio de 2003

par de ese número, si se proporciona un número impar, la aplicación debe reemplazar ese número con el siguiente número inferior
(par) para usarlo como base del par de puertos. Para aplicaciones en las que los números de puerto de destino RTP y RTCP se
especifican mediante parámetros explícitos y separados (usando un protocolo de señalización u otros medios), la aplicación puede
ignorar las restricciones de que los números de puerto sean pares/impares y consecutivos, aunque el uso de un número par Todavía
se recomienda el par de puertos impares. Los números de puerto RTP y RTCP no deben ser los mismos ya que RTP depende de los
números de puerto para demultiplexar los datos RTP y los flujos de control RTCP.

En una sesión de unidifusión, ambos participantes deben identificar un par de puertos para recibir paquetes RTP y RTCP. Ambos
participantes pueden utilizar el mismo par de puertos. Un participante no debe asumir que el puerto de origen del paquete RTP o
RTCP entrante se puede utilizar como puerto de destino para los paquetes RTP o RTCP salientes. Cuando los paquetes de datos
RTP se envían en ambas direcciones, los paquetes RTCP SR de cada participante deben enviarse al puerto que el otro participante
haya especificado para la recepción de RTCP. Los paquetes RTCP SR combinan información del remitente para los datos salientes
más información del informe de recepción para los datos entrantes. Si un lado no envía datos activamente (consulte la Sección 6.4),
en su lugar se envía un paquete RTCP RR.

Se recomienda que las aplicaciones de codificación por capas (consulte la Sección 2.4) utilicen un conjunto de números de puerto
contiguos. Los números de puerto deben ser distintos debido a una deficiencia generalizada en los sistemas operativos existentes
que impide el uso del mismo puerto con múltiples direcciones de multidifusión y, para unidifusión, solo hay una dirección permitida.
Por lo tanto, para la capa n, el puerto de datos es P + 2n y el puerto de control es P + 2n + 1. Cuando se utiliza multidifusión IP, las
direcciones también deben ser distintas porque el enrutamiento de multidifusión y la membresía de grupo se administran en una
granularidad de dirección. Sin embargo, no se puede asumir la asignación de direcciones IP multidifusión contiguas porque algunos
grupos pueden requerir alcances diferentes y, por lo tanto, pueden asignarse desde diferentes rangos de direcciones.

El párrafo anterior entra en conflicto con la especificación SDP, RFC 2327 [15], que dice que es ilegal especificar múltiples direcciones
y múltiples puertos en la misma descripción de sesión porque la asociación de direcciones con puertos podría ser ambigua. Se
pretende que esta restricción se relaje en una revisión de RFC 2327 para permitir que se especifique un número igual de direcciones
y puertos con una asignación uno a uno implícita.

Los paquetes de datos RTP no contienen ningún campo de longitud ni otra delimitación, por lo tanto, RTP se basa en los protocolos
subyacentes para proporcionar una indicación de longitud. La longitud máxima de los paquetes RTP está limitada únicamente por los
protocolos subyacentes.

Si los paquetes RTP se van a transportar en un protocolo subyacente que proporciona la abstracción de un flujo de octetos continuo
en lugar de mensajes (paquetes), se debe definir una encapsulación de los paquetes RTP para proporcionar un mecanismo de
entramado. El encuadre también es necesario si el protocolo subyacente puede contener relleno de modo que no se pueda determinar
el alcance de la carga útil RTP. El mecanismo de encuadre no está definido aquí.

Un perfil puede especificar un método de entramado que se utilizará incluso cuando RTP se transporta en protocolos que sí
proporcionan entramado para permitir transportar varios paquetes RTP en una unidad de datos de protocolo de capa inferior, como
un paquete UDP. Llevar varios paquetes RTP en una red o paquete de transporte reduce la sobrecarga del encabezado y puede
simplificar la sincronización entre diferentes flujos.

Schulzrinne, et al. Seguimiento de estándares [Página 57]

Machine Translated by Google

RFC 3550 RTP julio de 2003

12. Resumen de constantes del protocolo

Esta sección contiene una lista resumida de las constantes definidas en esta especificación.

Las constantes del tipo de carga útil (PT) de RTP se definen en perfiles en lugar de en este documento. Sin embargo,
El octeto del encabezado RTP que contiene los bits marcadores y el tipo de carga útil debe evitar la
valores reservados 200 y 201 (decimal) para distinguir los paquetes RTP de RTCP SR y RR
tipos de paquetes para el procedimiento de validación de encabezado descrito en el Apéndice A.1. Para el estándar
definición de un bit marcador y un campo de tipo de carga útil de 7 bits como se muestra en esta especificación, esto
La restricción significa que los tipos de carga útil 72 y 73 están reservados.

12.1 Tipos de paquetes RTCP

abreviado. nombre valor

SR informe del remitente 200
RR informe del receptor 201
Descripción de la fuente SDES 202
Adios que Te Vaya Bien 203
APP definida por la aplicación 204

Estos valores de tipo se eligieron en el rango 200­204 para mejorar la verificación de la validez del encabezado de RTCP.
paquetes en comparación con paquetes RTP u otros paquetes no relacionados. Cuando el campo de tipo de paquete RTCP
se compara con el octeto correspondiente del encabezado RTP, este rango corresponde al marcador
el bit es 1 (que generalmente no es en los paquetes de datos) y al bit alto de la carga útil estándar
El campo tipo es 1 (ya que los tipos de carga útil estática generalmente se definen en la mitad inferior). Este rango
también se eligió para estar a cierta distancia numéricamente de 0 y 255, ya que todos ceros y todos unos son
patrones de datos comunes.

Dado que todos los paquetes RTCP compuestos deben comenzar con SR o RR, estos códigos se eligieron como
par par/impar para permitir que la verificación de validez RTCP pruebe el número máximo de bits con máscara
y valor.

Se pueden registrar tipos de paquetes RTCP adicionales a través de IANA (consulte la Sección 15).

12.2 Tipos de SDES

abreviado. nombre valor

FIN fin de la lista SDES 0
Nombre canónico CNAME 1
NOMBRE nombre de usuario 2
Dirección de correo electrónico del usuario EMAIL 3
Número de teléfono del usuario de PHONE 4

Ubicación geográfica del usuario de LOC 5

HERRAMIENTA nombre de la aplicación o herramienta 6
NOTA aviso sobre la fuente 7
Extensiones privadas PRIV 8

Schulzrinne, et al. Seguimiento de estándares [Página 58]

Machine Translated by Google

RFC 3550 RTP julio de 2003

Se pueden registrar tipos de SDES adicionales a través de la IANA (consulte la Sección 15).

13. Perfiles RTP y especificaciones de formato de carga útil

Una especificación completa de RTP para una aplicación particular requerirá uno o más documentos complementarios de los dos
tipos que se describen aquí: perfiles y especificaciones de formato de carga útil.

RTP se puede utilizar para una variedad de aplicaciones con requisitos algo diferentes. La flexibilidad para adaptarse a esos
requisitos se proporciona permitiendo múltiples opciones en la especificación del protocolo principal, luego seleccionando las
opciones apropiadas o definiendo extensiones para un entorno particular y una clase de aplicaciones en un documento de perfil
separado. Normalmente, una aplicación funcionará bajo un solo perfil en una sesión RTP particular, por lo que no hay ninguna
indicación explícita dentro del protocolo RTP en cuanto a qué perfil está en uso. Se puede encontrar un perfil para aplicaciones de
audio y video en el RFC 3551 complementario. Los perfiles generalmente se titulan “Perfil RTP para . . . ”.

El segundo tipo de documento complementario es una especificación de formato de carga útil, que define cómo se debe transportar
en RTP un tipo particular de datos de carga útil, como el vídeo codificado H.261. Estos documentos suelen denominarse “Formato
de carga útil RTP para codificación de audio/vídeo XYZ”. Los formatos de carga útil pueden resultar útiles en múltiples perfiles y, por
lo tanto, pueden definirse independientemente de cualquier perfil en particular. Luego, los documentos de perfil son responsables de
asignar una asignación predeterminada de ese formato a un valor de tipo de carga útil, si es necesario.

Dentro de esta especificación, se han identificado los siguientes elementos para su posible definición dentro de un perfil, pero esta
lista no pretende ser exhaustiva:

Encabezado de datos RTP: el octeto en el encabezado de datos RTP que contiene el bit marcador y el campo de tipo de carga útil
puede redefinirse mediante un perfil para adaptarse a diferentes requisitos, por ejemplo, con más o menos bits marcadores
(Sección 5.3, p. 15).

Tipos de carga útil: suponiendo que se incluya un campo de tipo de carga útil, el perfil generalmente definirá un conjunto de formatos
de carga útil (por ejemplo, codificaciones de medios) y una asignación estática predeterminada de esos formatos a los valores
de tipo de carga útil. Algunos de los formatos de carga útil pueden definirse mediante referencia a especificaciones de formato
de carga útil separadas. Para cada tipo de carga útil definido, el perfil debe especificar la velocidad del reloj de marca de
tiempo RTP que se utilizará (Sección 5.1, p. 13).

Adiciones al encabezado de datos RTP: se pueden agregar campos adicionales al encabezado de datos RTP fijo si se requiere
alguna funcionalidad adicional en toda la clase de aplicaciones del perfil, independientemente del tipo de carga útil (Sección
5.3, p. 15).

Extensiones de encabezado de datos RTP: El contenido de los primeros 16 bits de la estructura de extensión del encabezado de
datos RTP debe definirse si se permitirá el uso de ese mecanismo bajo el perfil para extensiones específicas de la
implementación (Sección 5.3.1, p. 16).

Tipos de paquetes RTCP: se pueden definir y registrar en IANA nuevos tipos de paquetes RTCP específicos de la clase de aplicación.

Intervalo de informe RTCP: Un perfil debe especificar que se utilizarán los valores sugeridos en la Sección 6.2 para las constantes
empleadas en el cálculo del intervalo de informe RTCP. Esos son

Schulzrinne, et al. Seguimiento de estándares [Página 59]

Machine Translated by Google

RFC 3550 RTP julio de 2003

la fracción RTCP del ancho de banda de la sesión, el intervalo mínimo de informe y el ancho de banda dividido entre
remitentes y receptores. Un perfil puede especificar valores alternativos si se ha demostrado que funcionan de manera
escalable.

Extensión SR/RR: Se puede definir una sección de extensión para los paquetes RTCP SR y RR si hay información adicional que
debe informarse periódicamente sobre el remitente o los receptores (Sección 6.4.3, p. 35).

Uso de SDES: El perfil puede especificar las prioridades relativas para que los elementos RTCP SDES se transmitan o se excluyan
por completo (Sección 6.3.9); una sintaxis o semántica alternativa para el elemento CNAME (Sección 6.5.1); el formato del
artículo de la LOC (Sección 6.5.5); la semántica y el uso del ítem NOTA (Sección 6.5.7); o nuevos tipos de elementos SDES
que se registrarán en la IANA.

Seguridad: un perfil puede especificar qué servicios y algoritmos de seguridad deben ofrecer las aplicaciones y puede proporcionar
orientación sobre su uso apropiado (Sección 9, p. 54).

Asignación de cadena a clave: un perfil puede especificar cómo se almacena una contraseña o frase de contraseña proporcionada por el usuario.
asignado a una clave de cifrado.

Congestión: un perfil debe especificar el comportamiento de control de congestión apropiado para ese perfil.

Protocolo subyacente: uso de una red subyacente particular o un protocolo de capa de transporte para transportar
Es posible que se requieran paquetes RTP.

Mapeo de transporte: Un mapeo de RTP y RTCP a direcciones de nivel de transporte, por ejemplo, puertos UDP, distinto del mapeo
estándar definido en la Sección 11, p. 56 pueden especificarse.

Encapsulación: Se puede definir una encapsulación de paquetes RTP para permitir que se transporten múltiples paquetes de datos
RTP en un paquete de capa inferior o para proporcionar entramado sobre protocolos subyacentes que aún no lo hacen
(Sección 11, p. 56).

No se espera que sea necesario un nuevo perfil para cada solicitud. Dentro de una clase de aplicación, sería mejor ampliar un perfil
existente en lugar de crear uno nuevo para facilitar la interoperación entre las aplicaciones, ya que cada una normalmente se
ejecutará bajo un solo perfil.
Se pueden lograr extensiones simples, como la definición de valores de tipo de carga útil adicionales o tipos de paquetes RTCP,
registrándolos a través de IANA y publicando sus descripciones en un anexo al perfil o en una especificación de formato de carga útil.

14. Consideraciones de seguridad

RTP sufre las mismas responsabilidades de seguridad que los protocolos subyacentes. Por ejemplo, un impostor puede falsificar
direcciones de red de origen o destino, o cambiar el encabezado o la carga útil. Dentro de RTCP, la información CNAME y NAME se
puede utilizar para hacerse pasar por otro participante. Además, RTP puede enviarse mediante multidifusión IP, lo que no proporciona
ningún medio directo para que un remitente conozca todos los receptores de los datos enviados y, por tanto, ninguna medida de
privacidad. Con razón o no, los usuarios pueden ser más sensibles a las preocupaciones de privacidad con las comunicaciones de
audio y video que con más

Schulzrinne, et al. Seguimiento de estándares [Página 60]

Machine Translated by Google

RFC 3550 RTP julio de 2003

formas tradicionales de comunicación en red [33]. Por tanto, es importante el uso de mecanismos de seguridad con RTP. Estos
mecanismos se analizan en la Sección 9.

Se pueden utilizar traductores o mezcladores de nivel RTP para permitir que el tráfico RTP llegue a los hosts detrás de los firewalls.
Se deben seguir principios y prácticas de seguridad de firewall apropiados, que están fuera del alcance de este documento, en el
diseño e instalación de estos dispositivos y en la admisión de aplicaciones RTP para su uso detrás del firewall.

15. Consideraciones de la IANA

Se pueden registrar tipos de paquetes RTCP y tipos de elementos SDES adicionales a través de la Autoridad de Números Asignados
de Internet (IANA). Dado que estos espacios numéricos son pequeños, no sería prudente permitir el registro sin restricciones de
nuevos valores. Para facilitar la revisión de solicitudes y promover el uso compartido de nuevos tipos entre múltiples aplicaciones, las
solicitudes de registro de nuevos valores deben documentarse en un RFC u otra referencia permanente y fácilmente disponible,
como el producto de otro organismo de normalización cooperativo (por ejemplo, UIT­ T). También se podrán aceptar otras solicitudes,
bajo el asesoramiento de un “experto designado”. (Comuníquese con la IANA para obtener la información de contacto del experto
actual).

Las especificaciones del perfil RTP deben registrar en la IANA un nombre para el perfil en el formato "RTP/xxx", donde xxx es una
breve abreviatura del título del perfil. Estos nombres son para uso de protocolos de control de nivel superior, como el Protocolo de
descripción de sesión (SDP), RFC 2327 [15], para referirse a métodos de transporte.

16. Declaración de derechos de propiedad intelectual

El IETF no adopta ninguna posición con respecto a la validez o el alcance de cualquier propiedad intelectual u otros derechos que
puedan reclamarse relacionados con la implementación o el uso de la tecnología descrita en este documento o la medida en que
cualquier licencia bajo dichos derechos podría o no ser disponible; tampoco declara que haya hecho ningún esfuerzo por identificar
dichos derechos. La información sobre los procedimientos del IETF con respecto a los derechos en la documentación relacionada
con los estándares y los estándares se puede encontrar en BCP­11. Copias de reclamaciones de derechos disponibles para
publicación y cualquier garantía de licencias disponibles, o el resultado de un intento de obtener una licencia general o permiso para
el uso de dichos derechos de propiedad por parte de implementadores o usuarios de esta especificación pueden obtenerse de la
Secretaría del IETF.

El IETF invita a cualquier parte interesada a llamar su atención sobre cualquier derecho de autor, patente o solicitud de patente, u
otros derechos de propiedad que puedan cubrir la tecnología que pueda ser necesaria para practicar este estándar. Dirija la
información al Director Ejecutivo del IETF.

17. Agradecimientos

Este memorando se basa en discusiones dentro del grupo de trabajo de Transporte de Audio/Video del IETF presidido por Stephen
Casner y Colin Perkins. El protocolo actual tiene su origen en la Red

Schulzrinne, et al. Seguimiento de estándares [Página 61]

Machine Translated by Google

RFC 3550 RTP julio de 2003

Protocolo de voz y protocolo de vídeo por paquetes (Danny Cohen y Randy Cole) y el protocolo implementado por la aplicación
IVA (Van Jacobson y Steve McCanne). Christian Huitema aportó ideas para el generador de identificadores aleatorios.
Jonathan Rosenberg realizó un análisis y una simulación exhaustivos del algoritmo de reconsideración del temporizador. Las
adiciones para codificaciones en capas fueron especificadas por Michael Speer y Steve McCanne.

Apéndice A. Algoritmos

Proporcionamos ejemplos de código C para aspectos de los algoritmos de remitente y receptor RTP. Puede haber otros métodos
de implementación que sean más rápidos en entornos operativos particulares o que tengan otras ventajas. Estas notas de
implementación tienen fines informativos únicamente y pretenden aclarar la especificación RTP.

Las siguientes definiciones se utilizan para todos los ejemplos; Para mayor claridad y brevedad, las definiciones de estructura
solo son válidas para arquitecturas big­endian (primero el octeto más significativo) de 32 bits. Se supone que los campos de bits
están empaquetados estrechamente en orden de bits big­endian, sin relleno adicional. Se requerirían modificaciones para
construir una implementación portátil.

/*
* rtp.h ­­ Archivo de encabezado RTP */

#incluir <sys/types.h>

/*
* Las definiciones de tipos siguientes son válidas para arquitecturas de 32 bits y * es posible que deban
ajustarse para arquitecturas de 16 o 64 bits. */

typedef char sin firmar u_int8; typedef corto

sin firmar u_int16; typedef unsigned int u_int32;
typedef corto int16;

/*
* Versión actual del protocolo. */

#definir RTP_VERSION 2

#definir RTP_SEQ_MOD (1<<16) #definir

RTP_MAX_SDES 255 /* longitud máxima de texto para SDES */

enumeración typedef {
RTCP_SR = 200,
RTCP_RR = 201,
RTCP_SDES = 202,
RTCP_BYE = 203,

Schulzrinne, et al. Seguimiento de estándares [Página 62]

Machine Translated by Google

RFC 3550 RTP julio de 2003

RTCP_APP = 204
} rtcp_type_t;

enumeración typedef {
RTCP_SDES_END = 0,
RTCP_SDES_CNAME = 1,
RTCP_SDES_NAME = 2,
RTCP_SDES_EMAIL = 3,
RTCP_SDES_PHONE = 4,
RTCP_SDES_LOC = 5,
RTCP_SDES_TOOL = 6,
RTCP_SDES_NOTE = 7,
RTCP_SDES_PRIV = 8
} rtcp_sdes_type_t;

/*
* Encabezado de datos RTP
*/
estructura typedef {
versión int sin firmar: 2; /* versión del protocolo */
int sin signo p:1; /* /* bandera de relleno */
int sin signo x:1; indicador de extensión del encabezado */
sin firmar int cc:4; /* bit /* recuento CSRC */
int sin signo m:1; /* tipo marcador */
de carga útil */
punto entero sin firmar: 7;
secuencia int sin firmar: 16; /* secuencia de números */
u_int32ts; /* marca de tiempo */
u_int32 ssrc; /* fuente de sincronización */
u_int32 csrc[1]; /* lista CSRC opcional */
} rtp_hdr_t;

/*
* Palabra de encabezado común RTCP
*/
estructura typedef {
versión int sin firmar: 2; /* versión del protocolo */
int sin signo p:1; /* bandera de relleno */
recuento de enteros sin firmar: /* varía según el tipo de paquete */
5; punto entero sin firmar: 8; /* tipo de paquete RTCP */
u_int16 longitud; } /* paquete len en palabras, sin esta palabra */
rtcp_common_t;

/*
* Máscara big­endian para versión, bit de relleno y par de tipos de paquete
*/

Schulzrinne, et al. Seguimiento de estándares [Página 63]

Machine Translated by Google

RFC 3550 RTP julio de 2003

#definir RTCP_VALID_MASK (0xc000 | 0x2000 | 0xfe)

#define RTCP_VALID_VALUE ((RTP_VERSION << 14) | RTCP_SR)

/*
* Bloque de informe de recepción
*/
estructura typedef {
u_int32 ssrc; /* fuente de datos que se informa */
fracción int sin signo: 8; /* fracción perdida desde el último SR/RR */
int perdido:24; /* /* cumul. No. paquetes perdidos (¡firmados!) */
u_int32 last_seq; extendida
/* la última secuencia. No. recibió */
u_int32 fluctuación; fluctuación
/ entre llegadas */
u_int32lsr; /* * último paquete SR de esta fuente */
u_int32 dlsr; retraso desde el último paquete SR */
} rtcp_rr_t;

/*
* Artículo SDES
*/
estructura typedef {
tipo u_int8; /* tipo de elemento (rtcp_sdes_type_t) */
longitud u_int8; /* longitud del elemento (en octetos) */
datos de caracteres /* texto, no terminado en nulo */
[1]; } rtcp_sdes_item_t;

/*
* Un paquete RTCP
*/
estructura typedef {
rtcp_common_t común; Unión /* encabezado común */
{
/* informe del remitente (SR) */
estructura {
u_int32 ssrc; /* remitente que genera este informe */
u_int32 ntp_sec; /* Marca de tiempo NTP */
u_int32 ntp_frac;
u_int32 rtp_ts; /* Marca de tiempo RTP */
u_int32 presente; /* paquetes enviados */
u_int32 enviado; /* octetos enviados */
rtcp_rr_trr[1]; /* lista de longitud variable */
} señor;

/* informe de recepción (RR) */

estructura {
u_int32 ssrc; /* receptor generando este informe */

Schulzrinne, et al. Seguimiento de estándares [Página 64]

Machine Translated by Google

RFC 3550 RTP julio de 2003

rtcp_rr_trr[1]; /* lista de longitud variable */

}rr;

/* descripción de la fuente (SDES) */

estructura rtcp_sdes {
u_int32 origen; /* primer SSRC/CSRC */
rtcp_sdes_item_t elemento[1]; /* lista de elementos SDES */
} sdes;

/* ADIÓS */
estructura {
u_int32 origen[1]; /* lista de fuentes */
/* no se puede expresar el texto final por algún motivo */
} adiós;
}r;
} rtcp_t;

typedef estructura rtcp_sdes rtcp_sdes_t;

/*
* Información del estado por fuente
*/
estructura typedef {
u_int16 max_seq; /* se /* secuencia más alta. número visto */
u_int32 ciclos; u_int32 cambió el recuento de secuencias. número de ciclos */
base_seq; /* número de secuencia base */
u_int32 bad_seq; /* último número de secuencia 'incorrecto' + 1 */
u_int32 libertad condicional; /* secuencial. paquetes hasta que la fuente sea válida */
u_int32 recibido; u_int32 /* paquetes recibidos */
esperado_prior; /* paquete esperado en el último intervalo */
u_int32 recibido_prior; /* paquete recibido en el último intervalo */
tránsito u_int32; /* jitter /* tiempo de transferencia relativo para el paquete anterior */
u_int32 fluctuación; / estimado */
* ... */
} fuente;

A.1 Verificaciones de validez del encabezado de datos RTP

Un receptor RTP debe verificar la validez del encabezado RTP en los paquetes entrantes, ya que podrían
estar encriptado o puede ser de una aplicación diferente que no tiene la dirección correcta. Similarmente,
Si el cifrado según el método descrito en la Sección 9 está habilitado, la verificación de validez del encabezado
Es necesario verificar que los paquetes entrantes se hayan descifrado correctamente, aunque un fallo del
La verificación de la validez del encabezado (por ejemplo, tipo de carga útil desconocido) no necesariamente indica un error de descifrado.

Schulzrinne, et al. Seguimiento de estándares [Página 65]

Machine Translated by Google

RFC 3550 RTP julio de 2003

Sólo son posibles comprobaciones de validez débiles en un paquete de datos RTP de una fuente que no se ha escuchado antes:

• El campo de versión RTP debe ser igual a 2.

• Se debe conocer el tipo de carga útil y, en particular, no debe ser igual a SR o RR.

• Si el bit P está establecido, entonces el último octeto del paquete debe contener un recuento de octetos válido, en
En particular, menos que la longitud total del paquete menos el tamaño del encabezado.

• El bit X debe ser cero si el perfil no especifica que se puede utilizar el mecanismo de extensión del encabezado. De lo contrario,
el campo de longitud de extensión debe ser menor que el tamaño total del paquete menos la longitud fija del encabezado y el
relleno.

• La longitud del paquete debe ser coherente con el CC y el tipo de carga (si las cargas tienen un
longitud conocida).

Las últimas tres comprobaciones son algo complejas y no siempre posibles, dejando sólo las dos primeras, que suman sólo unos
pocos bits. Si el identificador SSRC en el paquete es uno que se recibió antes, entonces el paquete probablemente sea válido y
verificar si el número de secuencia está en el rango esperado proporciona una validación adicional. Si el identificador SSRC no se ha
visto antes, entonces los paquetes de datos que contienen ese identificador pueden considerarse inválidos hasta que llegue una
pequeña cantidad de ellos con números de secuencia consecutivos. Esos paquetes no válidos pueden descartarse o pueden
almacenarse y entregarse una vez que se haya logrado la validación si el retraso resultante es aceptable.

La rutina update_seq que se muestra a continuación garantiza que una fuente se declare válida solo después de que se hayan
recibido en secuencia los paquetes MIN_SEQUENTIAL. También valida el número de secuencia de un paquete recién recibido y
actualiza el estado de secuencia para el origen del paquete en la estructura a la que apunta s.

Cuando se escucha una nueva fuente por primera vez, es decir, su identificador SSRC no está en la tabla (consulte la Sección
8.2), y se le asigna el estado por fuente, s­>probation se establece en el número de secuencias secuenciales. Se inicializan los
paquetes necesarios antes de declarar válida una fuente (parámetro MIN_SEQUENTIAL) y otras variables:

init_seq(s, secuencia); s­
>max_seq = secuencia ­ 1; s­
>libertad condicional = MIN_SEQUENTIAL;

Un s­>probation distinto de cero marca la fuente como aún no válida, por lo que el estado puede descartarse después de un tiempo
de espera corto en lugar de uno largo, como se analiza en la Sección 6.2.1.

Después de que una fuente se considera válida, el número de secuencia se considera válido si no está más de MAX_DROPOUT por
delante de s­>max_seq ni más de MAX_MISORDER por detrás. Si el nuevo número de secuencia está por delante del módulo
max_seq, el rango de números de secuencia RTP (16 bits), pero es menor que max_seq, se ha ajustado y se incrementa el recuento
(desplazado) de ciclos de números de secuencia.
Se devuelve un valor de uno para indicar un número de secuencia válido.

De lo contrario, se devuelve el valor cero para indicar que la validación falló y se almacena el número de secuencia incorrecta más 1.
Si el siguiente paquete recibido lleva el siguiente número de secuencia superior,

Schulzrinne, et al. Seguimiento de estándares [Página 66]

Machine Translated by Google

RFC 3550 RTP julio de 2003

se considera el inicio válido de una nueva secuencia de paquetes probablemente causada por una caída prolongada o un
reinicio de la fuente. Dado que es posible que se hayan perdido varios ciclos completos de números de secuencia, se
restablecen las estadísticas de pérdida de paquetes.

Se muestran los valores típicos de los parámetros, basados en un tiempo máximo de orden incorrecto de 2 segundos a 50
paquetes/segundo y una caída máxima de 1 minuto. El parámetro de abandono MAX_DROPOUT debe ser una pequeña
fracción del espacio de números de secuencia de 16 bits para dar una probabilidad razonable de que los nuevos números de
secuencia después de un reinicio no caigan en el rango aceptable para los números de secuencia anteriores al reinicio.

void init_seq(fuente *s, u_int16 seq) {

s­>base_seq = secuencia;
s­>max_seq = secuencia;
s­>bad_seq = RTP_SEQ_MOD + 1; s­>ciclos /* entonces seq == bad_seq es falso */
= 0; s­>recibido = 0;
s­>recibido_prior = 0; s­
>expected_prior = 0; /* otra
inicialización */

int update_seq(fuente *s, u_int16 seq) {

u_int16 udelta = seq ­ s­>max_seq; constanteint

MAX_DROPOUT = 3000; constanteint
MAX_MISORDER = 100; constante int
MIN_SEQUENTIAL = 2;

/*
* La fuente no es válida hasta que se hayan recibido paquetes MIN_SEQUENTIAL
con * números de secuencia secuenciales. */

if (s­>probation) { /* el paquete
está en secuencia */ if (seq == s­>max_seq
+ 1) { s­>probation­­; s­>max_seq =
secuencia; if (s­
>libertad condicional ==
0) { init_seq(s, seq); s­>recibido++;
devolver 1;

} } else { s­
>libertad condicional = MIN_SEQUENTIAL ­ 1; s­
>max_seq = secuencia;

Schulzrinne, et al. Seguimiento de estándares [Página 67]

Machine Translated by Google

RFC 3550 RTP julio de 2003

}
devolver 0; }
si no (udelta < MAX_DROPOUT) {
/* en orden, con espacio permitido */ if (seq < s­
>max_seq) { /* * Número de

secuencia ajustado: cuente otro ciclo de 64 KB. */

s­>ciclos += RTP_SEQ_MOD;
}
s­>max_seq = secuencia; }
si no (udelta <= RTP_SEQ_MOD ­ MAX_MISORDER) {
/* el número de secuencia dio un salto muy grande */ if (seq == s­
>bad_seq) { /* * Dos paquetes

secuenciales ­ supongamos que el otro lado * se reinició sin avisarnos, así que
simplemente vuelva a sincronizar * (es decir, imagine que este fue el
primer paquete). */

init_seq(s, secuencia);
}
else { s­
>bad_seq = (seq + 1) & (RTP_SEQ_MOD­1); devolver 0;

} } else { /*
paquete duplicado o reordenado */
}
s­>recibido++;
devolver 1;
}

La verificación de validez se puede reforzar requiriendo más de dos paquetes en secuencia. Las desventajas son que se
descartará (o se retrasará en una cola) una mayor cantidad de paquetes iniciales y que las altas tasas de pérdida de
paquetes podrían impedir la validación. Sin embargo, debido a que la validación del encabezado RTCP es relativamente
sólida, si se recibe un paquete RTCP de una fuente antes que los paquetes de datos, el recuento podría ajustarse para que
solo se requieran dos paquetes en secuencia. Si se puede tolerar la pérdida de datos inicial durante unos segundos, una
aplicación puede optar por descartar todos los paquetes de datos de una fuente hasta que se haya recibido un paquete
RTCP válido de esa fuente.

Dependiendo de la aplicación y la codificación, los algoritmos pueden aprovechar conocimientos adicionales sobre el formato
de carga útil para una mayor validación. Para los tipos de carga útil donde el incremento de la marca de tiempo es el mismo
para todos los paquetes, los valores de la marca de tiempo se pueden predecir a partir del paquete anterior recibido de la
misma fuente usando la diferencia del número de secuencia (suponiendo que no haya cambios en el tipo de carga útil).

Es posible realizar una verificación sólida de "vía rápida" ya que con alta probabilidad los primeros cuatro octetos del encabezado

Schulzrinne, et al. Seguimiento de estándares [Página 68]

Machine Translated by Google

RFC 3550 RTP julio de 2003

de un paquete de datos RTP recién recibido será el mismo que el del paquete anterior del mismo SSRC excepto que el número de
secuencia habrá aumentado en uno. De manera similar, se puede utilizar una caché de entrada única para búsquedas SSRC más
rápidas en aplicaciones donde los datos normalmente se reciben de una fuente a la vez.

A.2 Verificaciones de validez del encabezado RTCP

Se deben aplicar las siguientes comprobaciones a los paquetes RTCP.

• El campo de versión RTP debe ser igual a 2.

• El campo de tipo de carga útil del primer paquete RTCP en un paquete compuesto debe ser igual a SR
o RR.

• El bit de relleno (P) debe ser cero para el primer paquete de un paquete RTCP compuesto porque
el relleno sólo debe aplicarse, si es necesario, al último paquete.

• Los campos de longitud de los paquetes RTCP individuales deben sumar la longitud total del
paquete RTCP compuesto tal como se recibió. Este es un control bastante fuerte.

El siguiente fragmento de código realiza todas estas comprobaciones. El tipo de paquete no se verifica para paquetes
posteriores, ya que pueden estar presentes tipos de paquetes desconocidos que deben ignorarse.

u_int32 len; rtcp_t /* longitud del paquete RTCP compuesto en palabras */

*r; rtcp_t *fin; /* encabezado RTCP */ /
* fin del paquete RTCP compuesto */

si ((*(u_int16 *)r & RTCP_VALID_MASK) != RTCP_VALID_VALUE) {

/* algo anda mal con el formato del paquete */
}
fin = (rtcp_t *)((u_int32 *)r + len);

hacer r = (rtcp_t *)((u_int32 *)r + r­>common.length + 1); mientras (r < fin && r­
>common.version == 2);

if (r != end) { /* algo
anda mal con el formato del paquete */
}

A.3 Determinación del número de paquetes esperados y perdidos

Para calcular las tasas de pérdida de paquetes, es necesario conocer la cantidad de paquetes RTP esperados y realmente
recibidos de cada fuente, utilizando la información de estado por fuente definida en la estructura fuente a la que se hace
referencia mediante punteros en el código siguiente. La cantidad de paquetes recibidos es simplemente el recuento de
paquetes a medida que llegan, incluidos los paquetes tardíos o duplicados. El número de paquetes esperados.

Schulzrinne, et al. Seguimiento de estándares [Página 69]

Machine Translated by Google

RFC 3550 RTP julio de 2003

El receptor puede calcularlo como la diferencia entre el número de secuencia más alto recibido (s­>max_seq) y el primer
número de secuencia recibido (s­>base_seq). Dado que el número de secuencia tiene solo 16 bits y se ajustará, es
necesario extender el número de secuencia más alto con el recuento (desplazado) de cambios de números de secuencia
(s­>ciclos). Tanto el recuento de paquetes recibidos como el recuento de ciclos se mantienen en la rutina de verificación
de validez del encabezado RTP en el Apéndice A.1.

extendido_max = s­>ciclos + s­>max_seq; esperado =

extendido_max ­ s­>base_seq + 1;

La cantidad de paquetes perdidos se define como la cantidad de paquetes esperados menos la cantidad de paquetes
realmente recibidos:

perdido = esperado ­ s­>recibido;

Dado que este número con signo se transporta en 24 bits, debe fijarse en 0x7fffff para una pérdida positiva o 0x800000
para una pérdida negativa en lugar de ajustarse.

La fracción de paquetes perdidos durante el último intervalo de informe (desde que se envió el paquete SR o RR anterior)
se calcula a partir de las diferencias en los recuentos de paquetes esperados y recibidos a lo largo del intervalo, donde
esperado_prior y recibido_prior son los valores guardados cuando se envió el informe de recepción anterior. generado:

intervalo_esperado = esperado ­ s­>anterior_esperado; s­>expected_prior

= esperado; intervalo_recibido = s­>recibido
­ s­>recibido_prior; s­>recibido_prior = s­>recibido; intervalo_perdido =
intervalo_esperado ­ intervalo_recibido; if
(intervalo_esperado == 0 || intervalo_perdido <= 0) fracción = 0; otra fracción =
(intervalo_perdido << 8) / intervalo_esperado;

La fracción resultante es un número de punto fijo de 8 bits con el punto binario en el borde izquierdo.

A.4 Generación de paquetes RTCP SDES

Esta función crea un fragmento SDES en el búfer b compuesto por elementos argc proporcionados en tipo, valor y longitud
de matriz. Devuelve un puntero a la siguiente ubicación disponible dentro de b.

char *rtp_write_sdes(char *b, u_int32 src, int argc,

rtcp_sdes_type_t tipo[], char *valor[], int longitud[])

{
rtcp_sdes_t *s = (rtcp_sdes_t *)b; rtcp_sdes_item_t
*rsp; ent i; longitud interna;

almohadilla
interna;

Schulzrinne, et al. Seguimiento de estándares [Página 70]

Machine Translated by Google

RFC 3550 RTP julio de 2003

/* encabezado SSRC */ s­
>src = src; rsp = &s­
>elemento[0];

/* Elementos SDES */ for

(i = 0; i < argc; i++) { rsp­>type = type[i]; len
= longitud[i]; si (len >
RTP_MAX_SDES) {

/* longitud no válida, es posible que desee realizar otra acción */ len =

RTP_MAX_SDES;
}
rsp­>longitud = len;
memcpy(rsp­>datos, valor[i], len); rsp =
(rtcp_sdes_item_t *)&rsp­>datos[len];
}

/* termina con el marcador de fin y rellena hasta el siguiente límite de 4 octetos */ len = ((char *) rsp) ­
b; pad = 4 ­ (len y 0x3); b = (char *) rsp;
mientras (pad­­) *b++ =
RTCP_SDES_END;

volver b;
}

A.5 Análisis de paquetes RTCP SDES

Esta función analiza un paquete SDES, llamando a las funciones find_member() para encontrar un puntero a la información de un
miembro de la sesión dado el identificador SSRC y member_sdes() para almacenar la nueva información SDES para ese miembro.
Esta función espera un puntero al encabezado del paquete RTCP.

vacío rtp_read_sdes(rtcp_t *r) {

int recuento = r­>common.count; rtcp_sdes_t

*sd = &r­>r.sdes; rtcp_sdes_item_t *rsp, *rspn;
rtcp_sdes_item_t *end = (rtcp_sdes_item_t *)
((u_int32 *)r + r­>common.length + 1);

fuente *s;

mientras (­­cuenta >= 0) {

Schulzrinne, et al. Seguimiento de estándares [Página 71]

Machine Translated by Google

RFC 3550 RTP julio de 2003

rsp = &sd­>elemento[0]; si
(rsp >= fin) romper; s =
buscar_miembro(sd­>src);

for (; rsp­>tipo; rsp = rspn ) { rspn = (rtcp_sdes_item_t

*)((char*)rsp+rsp­>longitud+2); if (rspn >= fin) { rsp = rspn; romper;

}
member_sdes(s, rsp­>tipo, rsp­>datos, rsp­>longitud);
}
sd = (rtcp_sdes_t *) ((u_int32
*)sd + (((char *)rsp ­ (char *)sd) >> 2)+1);
}
if (count >= 0) { /*
formato de paquete no válido */
}
}

A.6 Generación de un identificador aleatorio de 32 bits

La siguiente subrutina genera un identificador aleatorio de 32 bits utilizando las rutinas MD5 publicadas en RFC 1321
[32]. Es posible que las rutinas del sistema no estén presentes en todos los sistemas operativos, pero deberían servir
como pistas sobre qué tipo de información se puede utilizar. Otras llamadas al sistema que pueden ser apropiadas
incluyen

• obtener nombre de dominio(),

• getwd(), o

• getrusage().

Las muestras de vídeo o audio “en vivo” también son una buena fuente de números aleatorios, pero se debe tener
cuidado de evitar utilizar un micrófono apagado o una cámara ciega como fuente [17].
Se recomienda el uso de esta rutina o una similar para generar la semilla inicial para el generador de números
aleatorios que produce el período RTCP (como se muestra en el Apéndice A.7), para generar los valores iniciales para
el número de secuencia y la marca de tiempo, y para generar valores SSRC. . Dado que es probable que esta rutina
requiera un uso intensivo de la CPU, su uso directo para generar períodos RTCP es inapropiado porque la previsibilidad
no es un problema. Tenga en cuenta que esta rutina produce el mismo resultado en llamadas repetidas hasta que el
valor del reloj del sistema cambia, a menos que se proporcionen valores diferentes para el argumento de tipo.

/*
* Genera una cantidad aleatoria de 32 bits.

Schulzrinne, et al. Seguimiento de estándares [Página 72]

Machine Translated by Google

RFC 3550 RTP julio de 2003

*/
#incluir <sys/types.h> /* u_long */
#incluye <sys/time.h> #incluye /* gettimeofday() */
<unistd.h> /* conseguir..() */
#incluir <stdio.h> /* imprimirf() */
#incluir <hora.h> /* reloj() */
#include <sys/utsname.h> /* uname() */
#incluye "global.h" #incluye /* de RFC 1321 */
"md5.h" /* de RFC 1321 */

#definir MD_CTX MD5_CTX

#definir MDInit MD5Init
#define MDUpdate Actualización MD5
#definir MDFinal MD5Final

estático u_long md_32(char *cadena, longitud int)

{
contexto MD_CTX;
Unión {
carácter c[16];
u_longx[4];
} digerir;
u_long r;
ent i;

MDInit (& contexto);

MDUpdate (& contexto, cadena, longitud);
MDFinal ((carácter sin firmar *)&digest, &context);
r = 0;
para (yo = 0; yo < 3; yo++) {
r ^= resumen.x[i];
}
devolver r;
} /* md_32 */

/*
* Devuelve una cantidad aleatoria de 32 bits sin firmar. Utilice el argumento 'tipo' si
* necesita generar varios valores diferentes en estrecha sucesión.
*/
u_int32 aleatorio32 (tipo int)
{
estructura {
En t tipo;
estructura temporal tv;

Schulzrinne, et al. Seguimiento de estándares [Página 73]

Machine Translated by Google

RFC 3550 RTP julio de 2003

reloj_t CPU; pid_t

pid; u_long se
escondió; uid_t
uid; gid_t gid;
estructura utsname
nombre; } s;

gettimeofday(&s.tv, 0);
uname(&s.nombre);
s.tipo = tipo; s.cpu =
reloj(); s.pid = getpid();
s.hid = gethostid(); s.uid =
getuid(); s.gid = getgid(); /*
también: tiempo de actividad
del sistema */

return md_32((char *)&s, tamaño de(s)); /* aleatorio32 */

}

A.7 Calcular el intervalo de transmisión RTCP

Las siguientes funciones implementan las reglas de transmisión y recepción RTCP descritas en la Sección 6.2. Estas reglas están
codificadas en varias funciones:

• rtcp intervalo() calcula el intervalo calculado determinista, medido en segundos. El

Los parámetros se definen en la Sección 6.3.

• Se llama a OnExpire() cuando expira el temporizador de transmisión RTCP.

• Se llama a OnReceive() cada vez que se recibe un paquete RTCP.

Tanto OnExpire() como OnReceive() tienen el evento e como argumento. Este es el próximo evento programado para ese
participante, ya sea un informe RTCP o un paquete BYE. Se supone que están disponibles las siguientes funciones:

• Horario(hora t, evento e) programa un evento e para que ocurra en el momento t. Cuando llegue el momento,
la función OnExpire se llama con e como argumento.

• Reschedule(hora t, evento e) reprograma un evento e previamente programado para el tiempo t.

• SendRTCPReport(evento e) envía un informe RTCP.

• SendBYEPacket(evento e) envía un paquete BYE.

Schulzrinne, et al. Seguimiento de estándares [Página 74]

Machine Translated by Google

RFC 3550 RTP julio de 2003

• TypeOfEvent(evento e) devuelve EVENTO BYE si el evento que se está procesando es para un BYE
paquete que se enviará; de lo contrario, devuelve INFORME DE EVENTO.

• PacketType(p) devuelve PACKET RTCP REPORT si el paquete p es un informe RTCP (no BYE), PACKET BYE si es un
paquete BYE RTCP y PACKET RTP si es un paquete de datos RTP normal.

• RecibidoPacketSize() y SentPacketSize() devuelven el tamaño del paquete al que se hace referencia en

octetos.

• NewMember(p) devuelve 1 si el participante que envió el paquete p no está actualmente en la lista de miembros; 0 en caso
contrario. Tenga en cuenta que esta función no es suficiente para una implementación completa porque se deben procesar
cada identificador CSRC en un paquete RTP y cada SSRC en un paquete BYE.

• NewSender(p) devuelve un 1 si el participante que envió el paquete p no está actualmente en el remitente

sublista de la lista de miembros, 0 en caso contrario.

• AddMember() y RemoveMember() para agregar y eliminar participantes de la lista de miembros.

• AddSender() y RemoveSender() para agregar y eliminar participantes de la sublista de remitentes

de la lista de miembros.

Estas funciones tendrían que ampliarse para una implementación que permita especificar las fracciones de ancho de banda RTCP
para remitentes y no remitentes como parámetros explícitos en lugar de valores fijos del 25% y el 75%. La implementación extendida
de rtcp intervalo() necesitaría evitar la división por cero si uno de los parámetros fuera cero.

doble rtcp_interval(int miembros, int remitentes,

doble rtcp_bw, int
we_sent, doble
avg_rtcp_size, int
inicial)

{
/*
* Tiempo promedio mínimo entre paquetes RTCP de este sitio (en * segundos). Este tiempo evita
que los informes se "agrupen" cuando * las sesiones son pequeñas y la ley de los grandes números no
ayuda * a suavizar el tráfico. También evita que el intervalo de informe * se vuelva ridículamente
pequeño durante interrupciones transitorias como * una partición de red. */

doble constante RTCP_MIN_TIME = 5.; /* *

Fracción del ancho de banda RTCP que se compartirá entre los * remitentes activos. (Esta
fracción se eligió para que en una sesión * típica con uno o dos remitentes activos, el informe
calculado

Schulzrinne, et al. Seguimiento de estándares [Página 75]

Machine Translated by Google

RFC 3550 RTP julio de 2003

* el tiempo sería aproximadamente igual al tiempo mínimo de informe para que * no ralenticemos
innecesariamente los informes del receptor).
* la fracción del receptor debe ser 1: la fracción del remitente.
*/
doble constante RTCP_SENDER_BW_FRACTION = 0,25; doble
constante RTCP_RCVR_BW_FRACTION = (1­RTCP_SENDER_BW_FRACTION); /* /* Para compensar
la
"reconsideración del temporizador" que converge a un
* valor por debajo del promedio previsto. */

doble const COMPENSACIÓN = 2,71828 ­ 1,5;

doble /* intervalo */ double t;

rtcp_min_time = RTCP_MIN_TIME; /* No. de miembros
para cálculo */ int n;

/*
* La primera llamada al inicio de la aplicación utiliza la mitad del * retraso mínimo para una
notificación más rápida y, al mismo tiempo, permite algo de tiempo * antes de informar para la
aleatorización y para conocer otras * fuentes, de modo que el intervalo del informe converja al
intervalo * correcto más rápidamente . */ if (inicial) { rtcp_min_time /= 2;

/*
* Dedicar una fracción del ancho de banda RTCP a los remitentes a menos que

* el número de remitentes es lo suficientemente grande como para que su participación sea * mayor que
esa fracción.

*/
n = miembros; if
(remitentes <= miembros * RTCP_SENDER_BW_FRACTION) {
si (enviamos) {
rtcp_bw *= RTCP_SENDER_BW_FRACTION; n =
remitentes; } más
{ rtcp_bw *=
RTCP_RCVR_BW_FRACTION; n ­= remitentes;

}
}

/*
* El número efectivo de sitios multiplicado por el tamaño promedio de paquete es

Schulzrinne, et al. Seguimiento de estándares [Página 76]

Machine Translated by Google

RFC 3550 RTP julio de 2003

* el número total de octetos enviados cuando cada sitio envía un informe.

* Dividiendo esto por el ancho de banda efectivo se obtiene el tiempo
* intervalo durante el cual esos paquetes deben enviarse para poder
* Cumplir con el objetivo de ancho de banda, con un mínimo obligatorio. En eso
* intervalo de tiempo enviamos un informe, por lo que este tiempo también es nuestro
* tiempo promedio entre informes.
*/
t = avg_rtcp_size * n / rtcp_bw;
si (t < rtcp_min_time) t = rtcp_min_time;

/*
* Para evitar ráfagas de tráfico debido a sincronizaciones no deseadas con
* otros sitios, luego elegimos nuestro próximo intervalo de informe real como un
* número aleatorio distribuido uniformemente entre 0,5*t y 1,5*t.
*/
t = t * (drand48() + 0,5);
t = t / COMPENSACIÓN;
devolver t;
}

anular OnExpire (evento e,

miembros enteros,
En t remitentes,
doble rtcp_bw,
En t nosotros enviamos,

doble *avg_rtcp_size,
int *inicial,

tiempo_tp tc,
tiempo_tp *tp,
En t *miembros)
{
/* Esta función es responsable de decidir si se envía un
* Informe RTCP o paquete BYE ahora, o para reprogramar la transmisión.
* También se encarga de actualizar los pmembers, inicial, tp,
* y variables de estado avg_rtcp_size. Esta función debe ser
* llamado al vencimiento del temporizador de eventos utilizado por Schedule().
*/

doble t; /* Intervalo */
doble t; /* Próxima hora de transmisión */

/* En el caso de un BYE, utilizamos la "reconsideración del temporizador" para

*reprogramar la transmisión del BYE si es necesario*/

Schulzrinne, et al. Seguimiento de estándares [Página 77]

Machine Translated by Google

RFC 3550 RTP julio de 2003

if (TypeOfEvent(e) == EVENT_BYE) { t =
rtcp_interval(miembros, remitentes,
rtcp_bw,

we_sent,
*avg_rtcp_size, *inicial);

tn = *tp + t; si (tn <=

tc) {
EnviarBYEPacket(e);
salir(1); }
demás {
Horario(tn, e);
}

} else if (TypeOfEvent(e) == EVENT_REPORT) { t =

rtcp_interval(miembros, remitentes,
rtcp_bw,
we_sent,

*avg_rtcp_size, *inicial);

tn = *tp + t;

if (tn <= tc)

{ EnviarRTCPReport(e);
*avg_rtcp_size = (1./16.)*SentPacketSize(e) + (15./16.)*(*avg_rtcp_size);
*tp = tc;

/* Debemos volver a dibujar el intervalo. No reutilice el calculado anteriormente,

ya que en realidad no se distribuye de la misma manera, ya que
estamos condicionados a que sea lo suficientemente pequeño como
para provocar el envío de un paquete */

t = rtcp_interval(miembros, remitentes,
rtcp_bw,
we_sent,

*avg_rtcp_size, *inicial);

Horario(t+tc,e); *inicial = 0;

Schulzrinne, et al. Seguimiento de estándares [Página 78]

Machine Translated by Google

RFC 3550 RTP julio de 2003

} demás {
Horario(tn, e);
}
*pmiembros = miembros;
}
}

anular OnReceive(paquete p,
evento e,
int *members, int
*pmembers, int
*senders, double
*avg_rtcp_size, double *tp,
double tc,
double tn)

{
/* Lo que hacemos depende de si hemos abandonado el grupo y estamos * esperando enviar
un BYE (TypeOfEvent(e) == EVENT_BYE) o un informe RTCP *. p representa el paquete que
se acaba de recibir. */

if (PacketType(p) == PACKET_RTCP_REPORT) { if
(NewMember(p) && (TypeOfEvent(e) == EVENT_REPORT)) {
Agregar
Miembro(p); *miembros += 1;
}
*avg_rtcp_size = (1./16.)*Tamaño del paquete recibido(p) +
(15./16.)*(*avg_rtcp_size); } else if
(PacketType(p) == PACKET_RTP) { if (NewMember(p) &&
(TypeOfEvent(e) == EVENT_REPORT)) { AddMember(p); *miembros += 1;

}
if (NewSender(p) && (TypeOfEvent(e) == EVENT_REPORT)) {
AgregarRemitente(p);
*remitentes += 1;
}
} else if (PacketType(p) == PACKET_BYE) { *avg_rtcp_size
= (1./16.)*ReceivedPacketSize(p) + (15./16.)*(*avg_rtcp_size);

if (TypeOfEvent(e) == EVENT_REPORT) { if
(NewSender(p) == FALSO) {
EliminarRemitente(p);

Schulzrinne, et al. Seguimiento de estándares [Página 79]

Machine Translated by Google

RFC 3550 RTP julio de 2003

*remitentes ­= 1;
}

if (Nuevo Miembro(p) == FALSO) {

Eliminar Miembro(p);
*miembros ­= 1;
}

if (*miembros < *pmiembros) {

tn = tc +
(((doble) *miembros)/(*pmiembros))*(tn ­ tc); *tp = tc ­ (((doble)
*miembros)/
(*pmiembros))*(tc ­ *tp);

/* Reprogramar el próximo informe para el tiempo tn */

Reprogramar(tn, e);
*pmiembros = *miembros;
}

} else if (TypeOfEvent(e) == EVENT_BYE) { *miembros += 1;

}
}
}

A.8 Estimación de la fluctuación entre llegadas

Los fragmentos de código siguientes implementan el algoritmo proporcionado en la Sección 6.4.1 para calcular una
estimación de la varianza estadística del tiempo entre llegadas de datos RTP que se insertará en el campo de fluctuación
entre llegadas de los informes de recepción. Las entradas son r­>ts, la marca de tiempo del paquete entrante y llegada, la
hora actual en las mismas unidades. Aquí hay puntos a indicar para la fuente; s­>transit contiene el tiempo de tránsito relativo
del paquete anterior y s­>jitter contiene la fluctuación estimada.
El campo de fluctuación del informe de recepción se mide en unidades de marca de tiempo y se expresa como un entero sin
signo, pero la estimación de fluctuación se mantiene en un punto flotante. A medida que llega cada paquete de datos, se
actualiza la estimación de fluctuación:

int tránsito = llegada ­ r­>ts; int d = tránsito ­

s­>tránsito; s­>tránsito = tránsito; si (d < 0)
d = ­d; s­>jitter += (1./16.) *
((doble)d ­ s­>jitter);

Schulzrinne, et al. Seguimiento de estándares [Página 80]

Machine Translated by Google

RFC 3550 RTP julio de 2003

Cuando se genera un bloque de informe de recepción (al que apunta rr) para este miembro, la fluctuación actual
Se devuelve la estimación:

rr­>jitter = (u_int32) s­>jitter;

Alternativamente, la estimación de fluctuación se puede mantener como un número entero, pero escalada para reducir el error de redondeo.
El cálculo es el mismo excepto por la última línea:

s­>jitter += d ­ ((s­>jitter + 8) >> 4);

En este caso, la estimación se muestra para el informe de recepción como:

rr­>jitter = s­>jitter >> 4;

Apéndice B. Cambios desde RFC 1889

La mayor parte de este RFC es idéntico al RFC 1889. No hay cambios en los formatos de paquetes en el cable,
sólo cambios en las reglas y algoritmos que rigen cómo se utiliza el protocolo. El mayor cambio
es una mejora del algoritmo del temporizador escalable para calcular cuándo enviar paquetes RTCP:

• El algoritmo para calcular el intervalo de transmisión RTCP especificado en las Secciones 6.2 y 6.3.
e ilustrado en el Apéndice A.7 se amplía para incluir “reconsideración” para minimizar la transmisión en exceso de la
tasa prevista cuando muchos participantes se unen a una sesión simultáneamente,
y “reconsideración inversa” para reducir la incidencia y la duración de los tiempos de espera falsos de los participantes
cuando el número de participantes cae rápidamente. La reconsideración inversa también se utiliza para
posiblemente acorte el retraso antes de enviar RTCP SR al realizar la transición desde un receptor pasivo
al modo de remitente activo.

• La Sección 6.3.7 especifica nuevas reglas que controlan cuándo se debe enviar un paquete RTCP BYE en
para evitar una avalancha de paquetes cuando muchos participantes abandonan una sesión simultáneamente.

• El requisito de conservar el estado de los participantes inactivos durante un período suficiente para abarcar
Las particiones de red típicas se eliminaron de la Sección 6.2.1. En una sesión donde muchos participantes se unen
por un breve tiempo y no envían BYE, este requisito causaría un importante
sobreestimación del número de participantes. El algoritmo de reconsideración agregado en esta revisión compensa la
gran cantidad de nuevos participantes que se unen simultáneamente cuando un
la partición sana.

Cabe señalar que estas mejoras sólo tienen un efecto significativo cuando el número de participantes en la sesión es grande
(miles) y la mayoría de los participantes se unen o salen al mismo tiempo.
Esto dificulta las pruebas en una red en vivo. Sin embargo, el algoritmo fue sometido a una minuciosa
análisis y simulación para verificar su desempeño. Además, el algoritmo mejorado fue diseñado para interoperar con el
algoritmo en RFC 1889 de modo que el grado de reducción en exceso
El ancho de banda RTCP durante una unión por pasos es proporcional a la fracción de participantes que implementan
el algoritmo mejorado. La interoperación de los dos algoritmos se ha verificado experimentalmente en
redes en vivo.

Schulzrinne, et al. Seguimiento de estándares [Página 81]

Machine Translated by Google

RFC 3550 RTP julio de 2003

Otros cambios funcionales fueron:

• La Sección 6.2.1 especifica que las implementaciones pueden almacenar sólo una muestra de los participantes.
Identificadores SSRC para permitir el escalado a sesiones muy grandes. Los algoritmos se especifican en RFC 2762 [21].

• En la Sección 6.2 se especifica que los anchos de banda RTCP del remitente y del no remitente pueden configurarse como
parámetros separados de la sesión en lugar de un porcentaje estricto del ancho de banda de la sesión, y pueden establecerse
en cero. Se flexibilizó el requisito de que RTCP fuera obligatorio para las sesiones RTP que utilizan multidifusión IP. Sin
embargo, también se agregó una aclaración de que desactivar RTCP es
no recomendado.

• En las Secciones 6.2, 6.3.1 y el Apéndice A.7, se especifica que la fracción de participantes por debajo de la cual los
remitentes obtienen ancho de banda RTCP dedicado cambia del 1/4 fijo a una proporción basada en los parámetros de
ancho de banda RTCP del remitente y del no remitente. cuando se dan. Se eliminó la condición de que no se dedica ancho
de banda a los remitentes cuando no hay remitentes, ya que se espera que sea un estado transitorio. También evita que
quienes no son remitentes utilicen el ancho de banda RTCP del remitente cuando no es lo previsto.

• También en la Sección 6.2 se especifica que el intervalo RTCP mínimo se puede escalar a valores más pequeños para sesiones
de gran ancho de banda, y que el retraso RTCP inicial se puede establecer en cero para sesiones de unidifusión.

• El tiempo de espera de un participante se basará en la inactividad durante una cantidad de intervalos de informe RTCP
calculados utilizando la fracción de ancho de banda RTCP del receptor, incluso para los remitentes activos.

• Las secciones 7.2 y 7.3 especifican que los traductores y mezcladores deben enviar paquetes BYE para el
fuentes que ya no reenvían.

• Los cambios de reglas para codificaciones en capas se definen en las Secciones 2.4, 6.3.9, 8.3 y 11. En la última de ellas, se
observa que la regla de asignación de direcciones y puertos entra en conflicto con la especificación SDP, RFC 2327 [15], pero
Se pretende que esta restricción se relaje en una revisión del RFC 2327.

• Se aclaró la convención para el uso de pares de puertos pares/impares para RTP y RTCP en la Sección 11 para hacer referencia
a los puertos de destino. Se eliminó el requisito de utilizar un par de puertos par/impar si los dos puertos se especifican
explícitamente. Para sesiones RTP de unidifusión, se pueden utilizar pares de puertos distintos para los dos extremos
(Secciones 3, 7.1 y 11).

• Se agregó una nueva Sección 10 para explicar el requisito de control de congestión en las aplicaciones.
utilizando RTP.

• En la Sección 8.2, el requisito de que se debe elegir un nuevo identificador SSRC cada vez que se cambia la dirección de
transporte de origen se ha relajado para decir que se puede elegir un nuevo identificador SSRC. En consecuencia, se aclaró
que una implementación puede optar por mantener paquetes de la nueva dirección de origen en lugar de la dirección de origen
existente cuando ocurre una colisión SSRC entre otros dos participantes, y debería hacerlo para aplicaciones como la telefonía
en la que algunas fuentes como la telefonía móvil Las entidades pueden cambiar de dirección durante el transcurso de una
sesión RTP.

Schulzrinne, et al. Seguimiento de estándares [Página 82]

Machine Translated by Google

RFC 3550 RTP julio de 2003

• Se corrigió un error de sangría en la impresión RFC 1889 del pseudocódigo para el algoritmo de detección y resolución de
colisiones en la Sección 8.2 traduciendo la sintaxis al lenguaje pseudo C, y el algoritmo se modificó para eliminar la restricción
de que tanto RTP como RTCP debe enviarse desde el mismo número de puerto de origen.

• Se aclaró la descripción del mecanismo de relleno para paquetes RTCP y se especifica que el relleno sólo debe aplicarse al
último paquete de un paquete RTCP compuesto.

• En la Sección A.1, la inicialización de la secuencia base se corrigió para que fuera secuencia en lugar de secuencia ­ 1, y el
texto se corrigió para que dijera que se almacena el número de secuencia incorrecto más 1. La inicialización de max seq y
otras variables para el algoritmo se separaron del texto para dejar en claro que esta inicialización debe realizarse además de
llamar a la función init seq() (y algunas palabras perdidas en RFC 1889 al procesar el documento desde el código fuente). al
formulario de salida fueron restaurados).

• Se corrigió la fijación del número de paquetes perdidos en la Sección A.3 para utilizar valores positivos y
límites negativos.

• La especificación de marca de tiempo NTP “relativa” en la sección RTCP SR ahora define que estas marcas de tiempo se
basen en el reloj específico del sistema más común, como el tiempo de actividad del sistema, en lugar de en el tiempo
transcurrido de la sesión, que no sería el mismo para múltiples aplicaciones. comenzó en la misma máquina en diferentes
momentos.

Cambios no funcionales:

• Se especifica que un receptor debe ignorar los paquetes con tipos de carga útil que no comprende.

• En la Fig. 2, se corrigió el valor de la marca de tiempo NTP de punto flotante, faltaban algunos ceros a la izquierda.
se agregaron en un número hexadecimal y se especificó la zona horaria UTC.

• Se explica la inconsecuencia de que las marcas de tiempo NTP finalicen en el año 2036.

• La política para el registro de tipos de paquetes RTCP y tipos SDES se aclaró en una nueva Sección 15, Consideraciones de
la IANA. La sugerencia de que los experimentadores registren los números que necesitan y luego cancelen el registro de
aquellos que resulten innecesarios se eliminó en favor del uso de APP y PRIV. También se especificó el registro de nombres
de perfiles.

• La referencia para el juego de caracteres UTF­8 se cambió de una especificación preliminar X/Open.
La certificación será RFC 2279.

• La referencia de RFC 1597 se actualizó a RFC 1918 y la referencia de RFC 2543 se actualizó a RFC 3261.

• El último párrafo de la introducción en RFC 1889, que advertía a los implementadores que limitaran la implementación en
Internet, se eliminó porque se consideró que ya no era relevante.

• Se publicó una nota no normativa sobre el uso de RTP con multidifusión específica de fuente (SSM).
agregado en la Sección 6.

Schulzrinne, et al. Seguimiento de estándares [Página 83]

Machine Translated by Google

RFC 3550 RTP julio de 2003

• La definición de “sesión RTP” en la Sección 3 se amplió para reconocer que una sola sesión puede utilizar múltiples direcciones
de transporte de destino (como siempre fue el caso para un traductor o mezclador) y para explicar que la característica
distintiva de una sesión RTP es que cada uno corresponde a un espacio de identificador SSRC separado. Se añadió una
nueva definición de “sesión multimedia” para reducir la confusión sobre la palabra “sesión”.

• El significado de “instante de muestreo” se explicó con más detalle como parte de la definición de
el campo de marca de tiempo del encabezado RTP en la Sección 5.1.

• Se han realizado pequeñas aclaraciones al texto en varios lugares, algunas en respuesta a preguntas de los lectores. En
particular:

– En RFC 1889, las primeras cinco palabras de la segunda oración de la Sección 2.2 se perdieron al procesar el
documento desde el origen hasta el formulario de salida, pero ahora se restauraron.

– Se agregó una definición de “tipo de medio RTP” en la Sección 3 para permitir que la explicación de la multiplexación de
sesiones RTP en la Sección 5.2 sea más clara con respecto a la multiplexación de múltiples medios. Esa sección
ahora también explica que multiplexar múltiples fuentes del mismo medio basándose en identificadores SSRC puede
ser apropiado y es la norma para sesiones de multidifusión.

– La definición de “medios no RTP” se amplió para incluir ejemplos de otros protocolos.

que constituyen medios no RTP.

– La descripción del parámetro ancho de banda de la sesión se amplía en la Sección 6.2, incluida una aclaración de que
el ancho de banda del tráfico de control se suma al ancho de banda de la sesión para el tráfico de datos.

– El efecto de variar la duración del paquete en el cálculo de la fluctuación se explicó en la sección

ción 6.4.4.

– El método para terminar y rellenar una secuencia de elementos SDES se aclaró en

Sección 6.5.

– Se agregaron ejemplos de direcciones IPv6 en la descripción de SDES CNAME en la Sección 6.5.1.

y se utilizó “ejemplo.com” en lugar de otros nombres de dominio de ejemplo.

– La sección de Seguridad agregó una referencia formal a IPSEC ahora que está disponible y dice que el método de
confidencialidad definido en esta especificación es principalmente para codificar la práctica existente. Se recomienda
utilizar algoritmos de cifrado más potentes, como Triple­DES, en lugar del algoritmo predeterminado, y se tiene en
cuenta que el perfil SRTP basado en AES será la opción correcta en el futuro. Se agregó una advertencia sobre la
debilidad del encabezado RTP como vector de inicialización. También se señaló que el cifrado de sólo la carga útil es
necesario para permitir la compresión del encabezado.

– Se aclaró el método de cifrado parcial de RTCP; en particular, SDES CNAME

se transporta en una sola parte cuando el paquete RTCP compuesto se divide.

– Se aclara que solo se debe enviar un paquete RTCP compuesto por intervalo de informe y que si hay demasiadas
fuentes activas para que los informes quepan en la MTU, entonces se debe seleccionar un subconjunto de fuentes por
turnos en múltiples intervalos.

– Se agregó una nota en el Apéndice A.1 de que los paquetes pueden guardarse durante la validación del encabezado
RTP y entregarse en caso de éxito.

Schulzrinne, et al. Seguimiento de estándares [Página 84]

Machine Translated by Google

RFC 3550 RTP julio de 2003

– La sección 7.3 ahora explica que un mezclador que agrega paquetes SDES utiliza más ancho de banda RTCP debido
a que los paquetes son más largos, y un mezclador que pasa a través de RTCP envía naturalmente paquetes a una
velocidad superior a la de la fuente única, pero ambos comportamientos son válidos.

– La Sección 13 aclara que una aplicación RTP puede utilizar múltiples perfiles, pero normalmente solo
uno en una sesión determinada.

– Los términos debe, debería, puede, etc. se utilizan tal como se define en RFC 2119.

– La bibliografía se dividió en referencias normativas e informativas.

Referencias

Referencias normativas

[1] Schulzrinne, H. y S. Casner, “Perfil RTP para conferencias de audio y video con mínimo
Control”, RFC 3551, julio de 2003.

[2] Bradner, S., “Palabras clave para su uso en RFC para indicar niveles de requisitos”, BCP 14, RFC 2119,
Marzo de 1997.

[3] Postel, J., “Protocolo de Internet”, STD 5, RFC 791, septiembre de 1981.

[4] Mills, D., “Especificación, implementación y análisis del protocolo de tiempo de red (versión 3)”,
RFC 1305, marzo de 1992.

[5] Yergeau, F., “UTF­8, un formato de transformación de ISO 10646”, RFC 2279, enero de 1998.

[6] Mockapetris, P., “Nombres de dominio: conceptos e instalaciones”, STD 13, RFC 1034, noviembre
1987.

[7] Mockapetris, P., “Nombres de dominio: implementación y especificación”, STD 13, RFC 1035,
Noviembre de 1987.

[8] Braden, R., "Requisitos para servidores de Internet: aplicación y soporte", STD 3, RFC 1123,
Octubre de 1989.

[9] Resnick, P., “Formato de mensaje de Internet”, RFC 2822, abril de 2001.

Referencias informativas

[10] Clark, D. y D. Tennenhouse, “Consideraciones arquitectónicas para una nueva generación de protocolos”, en Simposio
SIGCOMM sobre arquitecturas y protocolos de comunicaciones, (Filadelfia, Pensilvania), págs. 200–208, IEEE Computer
Revisión de comunicaciones, vol. 20(4), septiembre de 1990.

[11] Schulzrinne, H., "Problemas en el diseño de un protocolo de transporte para conferencias de audio y video y otras aplicaciones
en tiempo real con múltiples participantes". Borrador de Internet caducado, octubre de 1993.

Schulzrinne, et al. Seguimiento de estándares [Página 85]

Machine Translated by Google

RFC 3550 RTP julio de 2003

[12] Comer, D., Interconexión con TCP/IP, vol. 1. Englewood Cliffs, Nueva Jersey: Prentice Hall,
1991.

[13] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. y E. Schooler, “SIP: Protocolo
de inicio de sesión”, RFC 3261, junio de 2002.

[14] Unión Internacional de Telecomunicaciones, “Sistemas y equipos telefónicos visuales para redes de área local que proporcionan
una calidad de servicio no garantizada”, Recomendación H.323, Sector de Normalización de las Telecomunicaciones de la
UIT, Ginebra, Suiza, julio de 2003.

[15] Handley, M. y V. Jacobson, “SDP: Protocolo de descripción de sesión”, RFC 2327, abril de 1998.

[16] Schulzrinne, H., Rao, A. y R. Lanphier, “Protocolo de transmisión en tiempo real (RTSP)”, RFC 2326,
Abril de 1998.

[17] Eastlake 3rd, D., Crocker, S. y J. Schiller, “Recomendaciones de aleatoriedad para la seguridad”, RFC 1750, diciembre de 1994.

[18] Bolot, J.­C., Turletti, T. e I. Wakeman, “Scalable Feedback Control for Multicast Video Distribution in the Internet”, en SIGCOMM
Symposium on Communications Architectures and Protocols, (Londres, Inglaterra), págs. 58–67, ACM, agosto de 1994.

[19] Busse, I., Deffner, B. y H. Schulzrinne, “Control dinámico de QoS de aplicaciones multimedia basadas en RTP”, Computer
Communications, vol. 19, págs. 49 a 58, enero de 1996.

[20] Floyd, S. y V. Jacobson, “La sincronización de mensajes de enrutamiento periódicos”, en Simposio SIG­COMM sobre
arquitecturas y protocolos de comunicaciones (DP Sidhu, ed.), (San Francisco, California), págs. 44, ACM, septiembre de
1993. También en [34].

[21] Rosenberg, J. y H. Schulzrinne, “Muestreo de la membresía del grupo en RTP”, RFC 2762,
Febrero de 2000.

[22] Cadzow, J., Fundamentos del procesamiento de señales digitales y análisis de datos. Nueva York, Nueva York:
Macmillan, 1987.

[23] Hinden, R. y S. Deering, “Arquitectura de direccionamiento del protocolo de Internet versión 6 (IPv6)”,
RFC 3513, abril de 2003.

[24] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. y E. Lear, “Asignación de direcciones
for Private Internets”, RFC 1918, febrero de 1996.

[25] Lear, E., Fair, E., Crocker, D. y T. Kessler, “Red 10 considerada dañina (algunas prácticas)
tices no deberían codificarse)”, RFC 1627, julio de 1994.

[26] Feller, W., Introducción a la teoría de la probabilidad y sus aplicaciones, vol. 1. Nueva York, Nueva York: John Wiley and Sons,
tercera ed., 1968.

[27] Kent, S. y R. Atkinson, “Arquitectura de seguridad para el Protocolo de Internet”, RFC 2401, noviembre­
Diciembre de 1998.

Schulzrinne, et al. Seguimiento de estándares [Página 86]

Machine Translated by Google

RFC 3550 RTP julio de 2003

[28] Baugher, M., Blom, R., Carrara, E., McGrew, D., Naslund, M., Norrman, K. y D. Oran,
“Protocolo de transporte seguro en tiempo real”, Work in Progress, abril de 2003.

[29] Balenson, D., “Mejora de la privacidad para el correo electrónico de Internet: Parte III”, RFC 1423, febrero­
Año 1993.

[30] Voydock, V. y S. Kent, “Mecanismos de seguridad en protocolos de red de alto nivel”, ACM
Encuestas informáticas, vol. 15, págs. 135­171, junio de 1983.

[31] Floyd, S., “Principios de control de congestión”, BCP 41, RFC 2914, septiembre de 2000.

[32] Rivest, R., “El algoritmo de resumen de mensajes MD5”, RFC 1321, abril de 1992.

[33] Stubblebine, S., “Servicios de seguridad para conferencias multimedia”, en 16th National Computer
Conferencia de seguridad, (Baltimore, Maryland), págs. 391–395, septiembre de 1993.

[34] Floyd, S. y V. Jacobson, “La sincronización de mensajes de enrutamiento periódicos”, IEEE/ACM

Transacciones en redes, vol. 2, págs. 122­136, abril de 1994.

Schulzrinne, et al. Seguimiento de estándares [Página 87]

Machine Translated by Google

RFC 3550 RTP julio de 2003

Direcciones de los autores

Henning Schulzrinne
Departamento de Ciencias de la Computación
Universidad de Colombia
1214 Avenida Ámsterdam

Nueva York, Nueva York 10027

Estados Unidos

Correo electrónico: [email protected]

Stephen L. Casner Packet

Design 3400 Hillview
Avenue, Building 3 Palo Alto, CA 94304
Estados Unidos

Correo electrónico: [email protected]

Ron Frederick Blue

Coat Systems Inc.

650 Almanor Avenue

Sunnyvale, CA 94085 Estados

Unidos

Correo electrónico: [email protected]

van jacobson

Diseño de paquetes
3400 Hillview Avenue, Edificio 3
Palo Alto, CA 94304
Estados Unidos

Correo electrónico: [email protected]

Schulzrinne, et al. Seguimiento de estándares [Página 88]

Machine Translated by Google

RFC 3550 RTP julio de 2003

Declaración completa de derechos de autor

Copyright (C) Sociedad de Internet (2003). Reservados todos los derechos.

Este documento y sus traducciones pueden copiarse y proporcionarse a otros, y los trabajos derivados que lo comenten, lo expliquen
o ayuden en su implementación pueden prepararse, copiarse, publicarse y distribuirse, en su totalidad o en parte, sin restricción de
ningún tipo. , siempre que el aviso de derechos de autor anterior y este párrafo estén incluidos en todas dichas copias y trabajos
derivados.
Sin embargo, este documento en sí no puede modificarse de ninguna manera, como eliminar el aviso de derechos de autor o las
referencias a Internet Society u otras organizaciones de Internet, excepto cuando sea necesario para desarrollar estándares de
Internet, en cuyo caso se aplicarán los procedimientos para derechos de autor definidos en Se debe seguir el proceso de Estándares
de Internet, o según sea necesario, traducirlo a idiomas distintos del inglés.

Los permisos limitados otorgados anteriormente son perpetuos y no serán revocados por Internet Society ni por sus sucesores o
cesionarios.

Este documento y la información aquí contenida se proporcionan "TAL CUAL" y LA SOCIEDAD DE INTERNET Y EL GRUPO DE TRABAJO DE
INGENIERÍA DE INTERNET RENUNCIA A TODA GARANTÍA, EXPRESA O IMPLÍCITA, INCLUYENDO, PERO NO LIMITADO A, CUALQUIER

GARANTÍA DE QUE EL USO DE LA INFORMACIÓN AQUÍ NO INFRINGIR CUALQUIER DERECHO O GARANTÍA IMPLÍCITA DE
COMERCIABILIDAD O IDONEIDAD PARA UN PROPÓSITO PARTICULAR.

Reconocimiento

Actualmente, Internet Society proporciona financiación para la función de editor RFC.

Schulzrinne, et al. Seguimiento de estándares [Página 89]