Real-time Transport Protocol
Enviado por Admin en la categoría networking
el Domingo, 02 Noviembre, 2008
La proliferación de equipos, sumada a la disponibilidad de hardware de audio/video económicos y la posibilidad de contar con velocidades de conexión cada vez más rápidas, ha aumentado el interés en el uso de Internet para enviar audio y video, tipos de datos que tradicionalmente se reservaban para redes especializadas. El objetivo de RTP es brindar un medio uniforme de transmisión sobre IP de datos que estén sujetos a las limitaciones de tiempo real (audio, video, etc.). La función principal de RTP es implementar los números de secuencia de paquetes IP para rearmar la información de voz o de video, incluso cuando la red subyacente cambie el orden de los paquetes.
El primero es utilizado para transportar los datos multimediales (es el que realmente lleva "las imagenes del video") mientras el segundo es utilizado para enviar periódicamente información de control asociada con el flujo de datos.
El flujo de datos RTP y el flujo de control RTCP asociado utilizan números de puertos consecutivos. Los datos RTP utilizan un número de puerto par y la información de control RTCP utiliza el siguiente número (impar).
El protocolo de transporte utilizado por RTP es UDP.
RTP soporta una amplia variedad de aplicaciones multimedia y está diseñado para adicionarle más aplicaciones sin cambiar el protocolo. Para cada clase de aplicación (por ejemplo, audio), RTP define un perfil (profile) y uno o más formatos (formats). El profile proporciona información para asegurar el entendimiento de los campos del header de RTP para dicho tipo de aplicación. El formato especifica cómo los datos que siguen al header deben ser interpretados.
1. Formato del header
La siguiente figura muestra el header utilizado por el protocolo RTP.
Detalle de la cabecera
Los primeros 12 octetos (es decir, los campos V, P, X, CC, M, PT, sequence number, timestamp y SSRC) SIEMPRE están presentes, en tanto que los identificadores de "fuentes contribuyentes" (nodos que generan información al mismo tiempo para, supongamos, una videoconferencia) son utilizados sólo en ciertas circunstancias. Después del header "básico" puede tenerse extensiones opcionales para el header (Extension header).
Finalmente el header es seguido por los datos (payload) que transporta RTP y su formato es definido por la aplicación.
El diseño del header de RTP busca llevar sólo aquellos campos que son necesarios para diversos tipos de aplicaciones.
Detalle del último byte
Con esto se cumple el objetivo de tener un header RTP pequeño. La longitud de los datos se calcula a partir de la información del header del protocolo de la capa inferior (UDP en este caso).
2. Real-time Transport Control Protocol (RTCP)
RTCP proporciona un stream de control que está asociado con un stream de datos para una aplicación multimedia.
Funciones
Este stream de control tiene tres funciones principales:
1. Retroalimenta información sobre el desempeño de la aplicación y de la red
2. Ofrece una forma de correlacionar y sincronizar diferentes media streams que provienen del mismo emisor
3. Proporciona una forma de transferir la identidad de un emisor para ser mostrada en la interface de un usuario
La primera función es muy útil para aplicaciones de velocidad adaptativa y le permitiría, por ejemplo, utilizar un esquema de compresión más agresivo para reducir la congestión o enviar un stream de más alta calidad ya que hay poca congestión. Esta característica puede ser útil también para diagnosticar problemas de la red.
La segunda función parece estar ya cubierta con el identificador de fuente de sincronización de RTP (SSRC), pero en realidad no es así. Como se dijo antes, un nodo con varias cámaras pueden tener un SSRC diferente para cada cámara. Adicionalmente, no se requiere que un stream de audio y otro de video provenientes del mismo nodo utilicen el mismo SSRC. Ya que pueden darse colisiones de identificadores de SSRC es posible que se requiera cambiar el valor SSRC de un stream. Para poder manejar este problema, RTCP utiliza el concepto de nombre canónico (CNAME) que es asignado al emisor, este nombre canónico es luego asociado a varios valores SSRC que pueden ser utilizados por dicho emisor utilizando RTCP.
La correlación simple de dos streams es sólo parte del problema de sincronización intermedia. Como, además, diferentes streams pueden tener también relojes diferentes (con diferentes granuladidades y aún diferentes grados de inexactitud) existe la necesidad de definir una forma de sincronizar streams exactamente entre ellos. RTCP maneja este problema.
Tipos de paquetes RTCP
RTCP define varios tipos de paquetes, que incluyen
RTCP define varios tipos de paquetes, que incluyen
Varios paquetes RTCP pueden ser enviados en un mismo mensaje UDP.
En trasmisiones multicast la información de control puede consumir un ancho de banda considerable (2 o 3 personas en audioconferencia consumen cierta cantidad de ancho de banda para información de control, ¿cuánto se consumirá con 1000 personas?). Para manejar este problema RTCP ha establecido un mecanismo para reducir la trasmisión de información de control a medida que ingresan más nodos a la conferencia. El mecanismo es complejo para contarlo en este documento, pero la meta básica es limitar la cantidad de tráfico de RTCP a un pequeño porcentaje del tráfico de datos en RTP (normalmente el 5%). También es recomendado asignar más ancho de banda RTCP a los emisores activos, bajo el supuesto que la mayoría de los participantes desean ver los reportes enviados por ellos, como por ejemplo saber "quién habla".
Una vez un participante sabe cuánto ancho de banda puede consumir con el tráfico de RTCP, la aplicación comienza a enviar reportes periódicos en la tasa adecuada. Los reportes del emisor (sender reports) y los reportes del receptor (receiver reports) difieren en que sólo los primeros incluyen información extra sobre el emisor. Los dos tipos de reportes contienen información sobre los datos que fueron recibidos de todas las fuentes en el periódo de reportes más reciente.
La información extra en un reporte de emisor consta de:
Observe que las dos primeras cifras pueden ser utilizadas para habilitar la sincornización de diferentes tipos de streams desde la misma fuente, incluso cuando estos streams utilizan diferentes granularidades de reloj en sus streams de datos RTP, ya que da información suficiente para convertir el tiempo (hora) del día en timestamps RTP.
Tanto los reportes de emisor como de receptor contienen un bloque de datos por fuente que ha sido oida desde el último reporte. Cada bloque contiene las siguientes estadísticas para la fuente en cuestión:
Como puede imaginar, los receptores de esta información pueden aprender muchas cosas sobre el estado de la sesión. En particular, ellos pueden ver si otros receptores están obteniendo mejor calidad de otro emisor que la que tienen ellos y puede ser un indicio para hacer una reservación de recursos o el síntoma de un problema en la red que debe ser atentido. Además, si un emisor observa que muchos receptores están esperando un alto porcentaje de perdida de paquetes, él podría decidir reducir su rata de envíos o utilizar un esquema de codificación más resistente a las perdidas.
Descripción de la fuente.
El aspecto final a considerar de RTCP es el paquete de descripción de la fuente. Dicho paquete contiene, como mínimo, el SSRC del emisor y el CNAME del emisor. El nombre canónico es derivado de tal forma que todas las aplicaciones que generen media streams que requieran ser sincronizadas (por ejemplo, generación separada de video y audio por el mismo usuario) escogerán el mismo CNAME aunque pueden escoger diferentes SSRC. Esto permite al receptor identificar el media stream que viene del mismo emisor. El formato común de CNAME es de la forma usuario@host, donde host es el nombre completo del dominio donde se encuentra el emisor.
El nombre largo y con variable número de bytes utilizado en esta representación podría ser una mala selección para el formato de un SSRC ya que el SSRC siempre se envía con cualquier paquete de datos y debe ser procesado en tiempo real. Al ajustar los CNAMEs con los valores SSRC en mensajes periódicos de RTCP (no en todos) permite utilizar un formato eficiente y compacto para los SSRC.
Otros datos pueden ser incluidos en el paquete de descripción de la fuente, tales como el nombre real y el e-mail del usuario. Estos son utilizados en la interface del usuario para permitir identificar las personas, pero esta información es menos esencial para la operación de RTP que el CNAME.
3. Control de sesión y control de llamada (H.323)
Control de sesión
RTP y RTCP ofrecen un amplio rango de funcionalidad para las aplicaciones multimediales, pero hay un aspecto de la videoconferencia que estos protocolos no manejan, normalmente llamado control de sesión.
Para entenderlo consideremos el siguiente problema. Suponga que Usted desea mantener una videoconferencia en cierto momento y hacerla disponible a un amplio número de participantes. Quizá usted decida codificar el video stream utilizando el estándar MPEG-2, utilizar la dirección multicast IP 224.1.1.1 para transmitir los datos y enviarlo a través de RTP, sobre UDP, utilizando el puerto 4000. ¿Cómo se puede dar a conocer toda esta información a los posibles participantes de la videoconferencia?. Una forma es colocar la información en un mensaje de correo electrónico y enviarlo a cada uno de ellos, pero idealmente debería existir un formato estándar y un protocolo para diseminar esta información. La IETF tiene un grupo de trabajo, Multiparty Multimedia Session Control group, que ha definido protocolos para este propósito. Los protocolos que se han definido incluyen:
Se puede pensar a primera vista que son demasiados protocolos para una tarea que parece relativamente simple, pero hay muchos aspectos del problema y diversas situaciones las cuales deben ser manejadas. Por ejemplo, existe diferencia entre anunciar que cierta sesión de conferencia estará disponible sobre MBone (que puede hacerse utilizando SDP y SAP) y tratar de hacer una llamada telefónica a través de Internet a cierto usuario en un instante particular (que podría hacerse con SDP y SIP). En el primer caso, el trabajo se puede considerar hecho en el momento en que toda la información de sesión, puesta en un formato estándar, sea enviada a una dirección multicast conocida. En el segundo, necesita localizar uno o más usuarios, construir y enviar un mensaje anunciando que Usted desea hablarle(s) -equivalente a hacer timbrar el telefono en una llamada convencional- y, quizás, negociar un sistema de codificación de audio disponible entre las partes.
La ITU también ha adelantado mucho en esta área, lo que no es sorprendente ya que el problema que debe manejar esta asociación es el de telefonía. Afortunadamente ha existido considerable coordinación entre la IETF y la ITU en este caso, así que los diferentes protocolos definidos en las dos organizaciones interoperan sin mayores problemas. La recomendación ITU más importante para comunicación multimedial sobre una red de conmutación de paquetes es conocida como H.323 y está asociada a muchas otras recomendaciones de la ITU, incluyendo la H.245 para control de llamadas. El conjunto completo de recomendaciones cubiertas por H.323 tiene bastantes páginas y el protocolo se distingue por su complejidad así que en este documento se revisará de forma muy general. H.323 es popular como protocolo para telefonía Internet y será la aplicación considerada aquí.
H.323 y H.245
Un dispositivo que origina o termina una llamada es conocido como una terminal H.323: podría ser una estación de trabajo ejecutando una aplicación de telefonía Internet, o podría ser un appliance especialmente diseñado -un aparato similar a un teléfono con software de red y un puerto Ethernet-. Las terminales H.323 pueden hablarse entre ellas directamente, pero las llamadas generalemente están mediadas por un dispositivo conocido como gatekeeper. Los gatekeepers realizan un número de funciones como traducir entre diversos formatos de direccionamiento utilizados para hacer llamadas telefónicas y controlan cuántas llamadas pueden ser hechas en un momento dado para delimitar el ancho de banda utilizado por las aplicaciones H.323. H.323 también incluye el concepto de un gateway, un dispositivo que conecta la red H.323 a otros tipos de redes. El uso más común del gateway H.323 es conectar una red H.323 a la red pública de telefonía conmutada. Esto permite a un usuario ejecutar la aplicación H.323 en un computador para hablar con una persona que utiliza un teléfono convencional sobre una red de telefonía pública convencional.
Una función del gatekeeper es ayudar a la terminal H.323 a encontrar un gateway, quizás escogiendo entre varias opciones para encontrar una que sea relativamente cercana al destino final de la llamada. Esto es bastante útil en un mundo donde el número de teléfonos convencionales supera por un alto margen los teléfonos basados en PCs. Cuando una terminal H.323 hace una llamada a un destino que tiene un teléfono convencional, el gateway es el destino efectivo para la llamada H.323 y este último es el responsable de traducir de manera apropiada las señales y el media stream que debe transportarse sobre la red de teléfonos convencional.
Una parte importante de la recomendación H.323 es el protocolo de control de llamadas H.245. Cuando una terminal H.323 desea llamar a otra, esta utiliza H.245 para negociar las propiedades de la llamada. Este podría listar un número de estándares de codificación de audio que la terminal soporta y el destino de la llamada puede responder con una lista de los que ella soporta y las dos terminales pueden seleccionar un estándar de codificación que las dos manejen. H.245 también puede ser utilizado para determinar los números de puerto que RTP y RTCP utilizarán para el media stream (o streams -una llamada podría incluir audio y video-) en determinada llamada. Una vez se logra esto, la llamada puede ser hecha con RTP como protocolo de transporte de los media streams y RTCP llevando la información de control pertinente.
Referencia: rfc1889
1 Comentario
El protocolo RTP, desarrollado por la IETF , define realmente dos protocolos:
- - RTP (Real Time Transport Protocol)
- - RTCP (Real Time Transport Control Protocol)
El primero es utilizado para transportar los datos multimediales (es el que realmente lleva "las imagenes del video") mientras el segundo es utilizado para enviar periódicamente información de control asociada con el flujo de datos.
El flujo de datos RTP y el flujo de control RTCP asociado utilizan números de puertos consecutivos. Los datos RTP utilizan un número de puerto par y la información de control RTCP utiliza el siguiente número (impar).
El protocolo de transporte utilizado por RTP es UDP.
RTP soporta una amplia variedad de aplicaciones multimedia y está diseñado para adicionarle más aplicaciones sin cambiar el protocolo. Para cada clase de aplicación (por ejemplo, audio), RTP define un perfil (profile) y uno o más formatos (formats). El profile proporciona información para asegurar el entendimiento de los campos del header de RTP para dicho tipo de aplicación. El formato especifica cómo los datos que siguen al header deben ser interpretados.
1. Formato del header
La siguiente figura muestra el header utilizado por el protocolo RTP.
Detalle de la cabecera
Los primeros 12 octetos (es decir, los campos V, P, X, CC, M, PT, sequence number, timestamp y SSRC) SIEMPRE están presentes, en tanto que los identificadores de "fuentes contribuyentes" (nodos que generan información al mismo tiempo para, supongamos, una videoconferencia) son utilizados sólo en ciertas circunstancias. Después del header "básico" puede tenerse extensiones opcionales para el header (Extension header).
Finalmente el header es seguido por los datos (payload) que transporta RTP y su formato es definido por la aplicación.
El diseño del header de RTP busca llevar sólo aquellos campos que son necesarios para diversos tipos de aplicaciones.
- - V (versión), 2 bits: Los primeros dos bits identifican la versión del protocolo.
- - P (padding), 1 bit: El siguiente bit identifica el padding. Informa que los datos de RTP llevan un "relleno" para completar un bloque de cierto tamaño. El último byte en el mensaje UDP dice de qué tamaño es el padding
Detalle del último byte
Con esto se cumple el objetivo de tener un header RTP pequeño. La longitud de los datos se calcula a partir de la información del header del protocolo de la capa inferior (UDP en este caso).
- - X (extension), 1 bit: El bit de extensión es utilizado para indicar la presencia de un header de extensión que puede ser definido para una aplicación específica y sigue al header principal. Ese tipo de headers son utilizados en raras ocasiones ya que es posible definir un header dentro de los datos (payload) como parte de la definición del formato de los datos para una aplicación en particular.
- CC (CSRC count), 4 bits: El bit X es seguido por 4 bits (CC) que cuentan el número de "fuentes contribuyentes" incluidas en el header de RTP (en caso de que existan dichas fuentes).
- - M (marker), 1 bit: Este bit es utilizado para indicar el frame. Por ejemplo, puede indicar el inicio de una conversación en RTP: el primer frame.
- - PT (payload type), 7 bits: Los siguientes 7 bits indican qué tipo de dato multimedial se está transportando (payload type). Un posible uso de este campo es permitir a una aplicación pasar de un esquema de codificación a otro basado en la información sobre la disponibilidad de recursos en la red. El uso exacto del bit "marker" (M) y del "payload type" (PT) dependen del perfil (profile) de la aplicación. El payload type NO se usa como llave de demultiplexamiento para dirigir los datos a una aplicación diferente; ese demultiplexamiento lo realiza el protocolo de la capa inferior: UDP. Dos streams de datos multimediales diferentes utilizan números de puerto diferente.
- - Sequence number, 16 bits: El número de secuencia es utilizado para permitir al receptor de un stream RTP detectar paquetes perdidos o que lleguen en desorden. Observe que RTP no indica qué hacer cuando se pierde un paquete (muy diferente a TCP que corrige la perdida -por retransmisión- e interpreta la perdida como un indicador de congestión -que puede llevar a reducir el tamaño de la ventana en TCP-). Por el contrario, RTP deja que la aplicación decida qué es lo mejor que puede hacer cuando el paquete se pierde.
- - Timestamp, 32 bits: El campo de timestamp permite al receptor reproducir (playback) las muestras en los intervalos de tiempo apropiados y permite que diferentes media streams se puedan sincronizar. RTP no especifica en que unidades se debe enviar este timestamp -las aplicaciones y sus formatos requieren diferentes granularidades en tiempo-. El timestamp viene a ser un contador de "ticks" donde el tiempo entre "ticks" depende del formato de codificación de la aplicación (la granularidad del reloj es uno de los detalles que se especifica en el profile de RTP o en los datos -payload- de la aplicación).
- - SSRC, 32 bits: El identificador de fuente de sincronización (SSRC) es un número de 32 bits que identifica de manera única una sola fuente en un stream RTP. En una conferencia multimedial, cada emisor escoge un SSRC aleatorio. El identificador de fuente es diferente de la dirección IP o del número de puerto, que permite, por ejemplo, que un nodo con múltiples fuentes (un equipo con varias cámaras) distinga cada una de las fuentes. Cuando un sólo nodo genera diferentes media streams (por ejemplo, audio y video al mismo tiempo), no es necesario que utilice el mismo SSRC en cada stream ya que RTCP tiene un mecanismo para hacer sincronización intermedia.
- - Lista CSRC, de 0 a 15 elementos, cada uno de 32 bits: El identificador de fuente contribuyente (CSRC) es utilizado sólo cuando varios streams RTP pasan a través de un mezclador (mixer). Un mezclador puede ser utilizado para reducir los requerimientos de ancho de banda para una conferencia recibiendo datos de muchas fuentes y enviando estas como un sólo stream. El número de identificadores incluidos en el header RTP viene colocado en el campo CC (CSRC count). Si hay más de 15 fuentes contribuyentes, sólo 15 pueden ser identificadas.
2. Real-time Transport Control Protocol (RTCP)
RTCP proporciona un stream de control que está asociado con un stream de datos para una aplicación multimedia.
Funciones
Este stream de control tiene tres funciones principales:
1. Retroalimenta información sobre el desempeño de la aplicación y de la red
2. Ofrece una forma de correlacionar y sincronizar diferentes media streams que provienen del mismo emisor
3. Proporciona una forma de transferir la identidad de un emisor para ser mostrada en la interface de un usuario
La primera función es muy útil para aplicaciones de velocidad adaptativa y le permitiría, por ejemplo, utilizar un esquema de compresión más agresivo para reducir la congestión o enviar un stream de más alta calidad ya que hay poca congestión. Esta característica puede ser útil también para diagnosticar problemas de la red.
La segunda función parece estar ya cubierta con el identificador de fuente de sincronización de RTP (SSRC), pero en realidad no es así. Como se dijo antes, un nodo con varias cámaras pueden tener un SSRC diferente para cada cámara. Adicionalmente, no se requiere que un stream de audio y otro de video provenientes del mismo nodo utilicen el mismo SSRC. Ya que pueden darse colisiones de identificadores de SSRC es posible que se requiera cambiar el valor SSRC de un stream. Para poder manejar este problema, RTCP utiliza el concepto de nombre canónico (CNAME) que es asignado al emisor, este nombre canónico es luego asociado a varios valores SSRC que pueden ser utilizados por dicho emisor utilizando RTCP.
La correlación simple de dos streams es sólo parte del problema de sincronización intermedia. Como, además, diferentes streams pueden tener también relojes diferentes (con diferentes granuladidades y aún diferentes grados de inexactitud) existe la necesidad de definir una forma de sincronizar streams exactamente entre ellos. RTCP maneja este problema.
Tipos de paquetes RTCP
RTCP define varios tipos de paquetes, que incluyen
RTCP define varios tipos de paquetes, que incluyen
- - Reportes de emisor, que permite al emisor activo en una sesión reportar estadísticas de recepción y trasmisión.
- - Reportes de receptor, que los receptores que no son emisores, utilizan para enviar estadísticas de recepción.
- - Descripción de fuente, que lleva los CNAMEs y otra información que describe la información de los emisores.
- - Paquetes de control específicos a la aplicación
Varios paquetes RTCP pueden ser enviados en un mismo mensaje UDP.
En trasmisiones multicast la información de control puede consumir un ancho de banda considerable (2 o 3 personas en audioconferencia consumen cierta cantidad de ancho de banda para información de control, ¿cuánto se consumirá con 1000 personas?). Para manejar este problema RTCP ha establecido un mecanismo para reducir la trasmisión de información de control a medida que ingresan más nodos a la conferencia. El mecanismo es complejo para contarlo en este documento, pero la meta básica es limitar la cantidad de tráfico de RTCP a un pequeño porcentaje del tráfico de datos en RTP (normalmente el 5%). También es recomendado asignar más ancho de banda RTCP a los emisores activos, bajo el supuesto que la mayoría de los participantes desean ver los reportes enviados por ellos, como por ejemplo saber "quién habla".
Una vez un participante sabe cuánto ancho de banda puede consumir con el tráfico de RTCP, la aplicación comienza a enviar reportes periódicos en la tasa adecuada. Los reportes del emisor (sender reports) y los reportes del receptor (receiver reports) difieren en que sólo los primeros incluyen información extra sobre el emisor. Los dos tipos de reportes contienen información sobre los datos que fueron recibidos de todas las fuentes en el periódo de reportes más reciente.
La información extra en un reporte de emisor consta de:
- - Un timestamp que contiene el tiempo real del día cuando el reporte fue generado
- - Un timestamp RTP correspondiente al momento en que el reporte fue generado
- - Un acumulado de los paquetes y bytes enviados por ese emisor desde que comenzó la trasmisión.
Observe que las dos primeras cifras pueden ser utilizadas para habilitar la sincornización de diferentes tipos de streams desde la misma fuente, incluso cuando estos streams utilizan diferentes granularidades de reloj en sus streams de datos RTP, ya que da información suficiente para convertir el tiempo (hora) del día en timestamps RTP.
Tanto los reportes de emisor como de receptor contienen un bloque de datos por fuente que ha sido oida desde el último reporte. Cada bloque contiene las siguientes estadísticas para la fuente en cuestión:
- - Su SSRC
- - La fracción de paquetes de datos desde esta fuente que se han perdido desde que el último reporte fue enviado (calculado al comparar el número de paquetes recibidos con el número de paquetes esperados; este último valor puede ser determinado a partir de los números de secuencia RTP).
- - Número total de paquetes perdidos con origen en esta fuente desde la primera vez que fue escuchada.
- - El número de secuencia más alto recibido desde esta fuente
- - Jitter entre entregas estimado para la fuente (calculado por comparar el espacio entre arribos de los paquetes recibidos con el espaciamiento esperado en el tiempo de trasmisión).
- - Último timestamp real recibido a través de RTCP desde dicha fuente
- - Retardo desde el último reporte de emisor recibido a través de RTCP para esta fuente.
Como puede imaginar, los receptores de esta información pueden aprender muchas cosas sobre el estado de la sesión. En particular, ellos pueden ver si otros receptores están obteniendo mejor calidad de otro emisor que la que tienen ellos y puede ser un indicio para hacer una reservación de recursos o el síntoma de un problema en la red que debe ser atentido. Además, si un emisor observa que muchos receptores están esperando un alto porcentaje de perdida de paquetes, él podría decidir reducir su rata de envíos o utilizar un esquema de codificación más resistente a las perdidas.
Descripción de la fuente.
El aspecto final a considerar de RTCP es el paquete de descripción de la fuente. Dicho paquete contiene, como mínimo, el SSRC del emisor y el CNAME del emisor. El nombre canónico es derivado de tal forma que todas las aplicaciones que generen media streams que requieran ser sincronizadas (por ejemplo, generación separada de video y audio por el mismo usuario) escogerán el mismo CNAME aunque pueden escoger diferentes SSRC. Esto permite al receptor identificar el media stream que viene del mismo emisor. El formato común de CNAME es de la forma usuario@host, donde host es el nombre completo del dominio donde se encuentra el emisor.
El nombre largo y con variable número de bytes utilizado en esta representación podría ser una mala selección para el formato de un SSRC ya que el SSRC siempre se envía con cualquier paquete de datos y debe ser procesado en tiempo real. Al ajustar los CNAMEs con los valores SSRC en mensajes periódicos de RTCP (no en todos) permite utilizar un formato eficiente y compacto para los SSRC.
Otros datos pueden ser incluidos en el paquete de descripción de la fuente, tales como el nombre real y el e-mail del usuario. Estos son utilizados en la interface del usuario para permitir identificar las personas, pero esta información es menos esencial para la operación de RTP que el CNAME.
3. Control de sesión y control de llamada (H.323)
Control de sesión
RTP y RTCP ofrecen un amplio rango de funcionalidad para las aplicaciones multimediales, pero hay un aspecto de la videoconferencia que estos protocolos no manejan, normalmente llamado control de sesión.
Para entenderlo consideremos el siguiente problema. Suponga que Usted desea mantener una videoconferencia en cierto momento y hacerla disponible a un amplio número de participantes. Quizá usted decida codificar el video stream utilizando el estándar MPEG-2, utilizar la dirección multicast IP 224.1.1.1 para transmitir los datos y enviarlo a través de RTP, sobre UDP, utilizando el puerto 4000. ¿Cómo se puede dar a conocer toda esta información a los posibles participantes de la videoconferencia?. Una forma es colocar la información en un mensaje de correo electrónico y enviarlo a cada uno de ellos, pero idealmente debería existir un formato estándar y un protocolo para diseminar esta información. La IETF tiene un grupo de trabajo, Multiparty Multimedia Session Control group, que ha definido protocolos para este propósito. Los protocolos que se han definido incluyen:
- SDP (Session Description Protocol)
- SAP (Session Announcement Protocol)
- SIP (Session Initiation Protocol)
- SCCP (Simple Conference Control Protocol)
Se puede pensar a primera vista que son demasiados protocolos para una tarea que parece relativamente simple, pero hay muchos aspectos del problema y diversas situaciones las cuales deben ser manejadas. Por ejemplo, existe diferencia entre anunciar que cierta sesión de conferencia estará disponible sobre MBone (que puede hacerse utilizando SDP y SAP) y tratar de hacer una llamada telefónica a través de Internet a cierto usuario en un instante particular (que podría hacerse con SDP y SIP). En el primer caso, el trabajo se puede considerar hecho en el momento en que toda la información de sesión, puesta en un formato estándar, sea enviada a una dirección multicast conocida. En el segundo, necesita localizar uno o más usuarios, construir y enviar un mensaje anunciando que Usted desea hablarle(s) -equivalente a hacer timbrar el telefono en una llamada convencional- y, quizás, negociar un sistema de codificación de audio disponible entre las partes.
La ITU también ha adelantado mucho en esta área, lo que no es sorprendente ya que el problema que debe manejar esta asociación es el de telefonía. Afortunadamente ha existido considerable coordinación entre la IETF y la ITU en este caso, así que los diferentes protocolos definidos en las dos organizaciones interoperan sin mayores problemas. La recomendación ITU más importante para comunicación multimedial sobre una red de conmutación de paquetes es conocida como H.323 y está asociada a muchas otras recomendaciones de la ITU, incluyendo la H.245 para control de llamadas. El conjunto completo de recomendaciones cubiertas por H.323 tiene bastantes páginas y el protocolo se distingue por su complejidad así que en este documento se revisará de forma muy general. H.323 es popular como protocolo para telefonía Internet y será la aplicación considerada aquí.
H.323 y H.245
Un dispositivo que origina o termina una llamada es conocido como una terminal H.323: podría ser una estación de trabajo ejecutando una aplicación de telefonía Internet, o podría ser un appliance especialmente diseñado -un aparato similar a un teléfono con software de red y un puerto Ethernet-. Las terminales H.323 pueden hablarse entre ellas directamente, pero las llamadas generalemente están mediadas por un dispositivo conocido como gatekeeper. Los gatekeepers realizan un número de funciones como traducir entre diversos formatos de direccionamiento utilizados para hacer llamadas telefónicas y controlan cuántas llamadas pueden ser hechas en un momento dado para delimitar el ancho de banda utilizado por las aplicaciones H.323. H.323 también incluye el concepto de un gateway, un dispositivo que conecta la red H.323 a otros tipos de redes. El uso más común del gateway H.323 es conectar una red H.323 a la red pública de telefonía conmutada. Esto permite a un usuario ejecutar la aplicación H.323 en un computador para hablar con una persona que utiliza un teléfono convencional sobre una red de telefonía pública convencional.
Una función del gatekeeper es ayudar a la terminal H.323 a encontrar un gateway, quizás escogiendo entre varias opciones para encontrar una que sea relativamente cercana al destino final de la llamada. Esto es bastante útil en un mundo donde el número de teléfonos convencionales supera por un alto margen los teléfonos basados en PCs. Cuando una terminal H.323 hace una llamada a un destino que tiene un teléfono convencional, el gateway es el destino efectivo para la llamada H.323 y este último es el responsable de traducir de manera apropiada las señales y el media stream que debe transportarse sobre la red de teléfonos convencional.
Una parte importante de la recomendación H.323 es el protocolo de control de llamadas H.245. Cuando una terminal H.323 desea llamar a otra, esta utiliza H.245 para negociar las propiedades de la llamada. Este podría listar un número de estándares de codificación de audio que la terminal soporta y el destino de la llamada puede responder con una lista de los que ella soporta y las dos terminales pueden seleccionar un estándar de codificación que las dos manejen. H.245 también puede ser utilizado para determinar los números de puerto que RTP y RTCP utilizarán para el media stream (o streams -una llamada podría incluir audio y video-) en determinada llamada. Una vez se logra esto, la llamada puede ser hecha con RTP como protocolo de transporte de los media streams y RTCP llevando la información de control pertinente.
Referencia: rfc1889
Tags: networking, rtp, rtcp, telefonía, ip, protocolo, ietf, itu, h323, h.323, h245, h.245, voz, vídeo, datos
