PROTOCOLOS DE TRANSPORTE EN TIEMPO REAL (UDP) Franklin Iván Gualan Carchi Estudiante de la Ingeniería en Electrónica y Telecomunicaciones de la UNL. Correo-e:
[email protected] Ángel Eduardo Tandazo Gallegos Estudiante de la Ingeniería en Electrónica y Telecomunicaciones de la UNL.
[email protected]
Resume: This document discusses the basic concepts about the protocols most popular for communication in real time, focusing on a simple and straightforward description that serves as an introduction to the architecture of oriented protocols to meet the demands of traffic of applications that require a data stream in real time, refers to protocols that work with UDP at the transport layer, such as: RTP, RTCP, RTSP, SIP, H.323.
1. INTRODUCCIÓN. Con el auge de las tecnologías y técnicas modernas para las comunicaciones tanto fijas como móviles, cada día se fueron incorporando mayores exigencias de los usuarios finales de los diferentes sistemas de telecomunicaciones, en la actualidad estas exigencias van de la mano de términos como convergencia tecnológica, calidad de servicio y transmisiones en tiempo real. Obviamente ante esta situación los diversos sectores involucrados en el área de las telecomunicaciones se han visto en la necesidad innovar nuevas tecnologías capaces de satisfacer estas necesidades. Una parte esencial para la posible implementación de estas nuevas tecnologías son los estándares que regirán la manera en la que se organizara el proceso de comunicaciones. Ahora si nos enfocamos en aplicaciones que demandan el flujo de datos en tiempo real podemos advertir que protocolos de capa de transporte como el TCP no garantiza un adecuado flujo de datos acorde a las exigencias de un proceso de comunicación en tiempo real, y más aún esto involucraría un mayor consumo de recursos por lo cual resulto adecuado y oportuno el desarrollo de protocolos de comunicación orientados exclusivamente a comunicaciones multimedia en tiempo real, donde obviamente se prescinde a de algunas ventajas de los protocolos orientados a la conexión, pero en cambio se logra optimizar de mejor manera los recursos de red.
RTP (Protocolo de transmisión en tiempo real). RTCP (Protocolo de control de transmisión en tiempo real). RTSP (Protocolo de transmisión de flujos en tiempo real). SIP (Protocolo de inicialización de sesión). H-323.
Las aplicaciones multimedia que demandan servicio de tráfico en tiempo real pueden ser divididas en dos categorías:
Aplicaciones interactivas en tiempo real: Voz sobre internet (VoIp), video conferencia. Aplicaciones no interactivas: estas a su vez se pueden subdividir en dos categorías a.) Streaming de audio/video almacenado: música, video clips, películas, etc. Almacenados en servidores, tenemos aplicaciones como Real Player, Apple Quick Time, Microsoft Windows Media, entre otros. b.) Streaming de audio/video en vivo: para aplicaciones de audio y video similares a la señal de televisión tipo broadcast de la televisión o radio convencional.
2. PROTOCOLOS DE COMUNICACIÓN EN TIEMPO REAL. Los requerimientos de comunicaciones en tiempo real conllevaron a que que investigadores se involucren en el diseño de familias de protocolos donde se incluyen:
FIGURA 1. FLUJO DE DATOS PARA COMUNICACCIONES EN TIEMPO REAL
Donde:
2.1. PROTOCOLO RTP. Este protocolo es de uso común en aplicaciones que requieren el transporte de audio o video en tiempo real, especialmente para servicios conocidos como media-on-demand, donde están servicios como la telefonía IP y las aplicaciones para videoconferencia, este estándar se encuentra definido en la RFC 3550, y puede ser usado para trasportar formatos archivos como Mp3 en el caso de audio y H.263 para el caso de video aunque también soporta otro tipo de archivos de audio o video , también tiene importantes aplicaciones para el transporte de archivos con codificación PCM y sistemas GSM.
Versión (2 bits): es un campo de dos bits que indica el número de versión del protocolo, la última versión disponible de RTP es la numero 2. Padding (Relleno) (1 bit): este bit indica si aparecen octetos de relleno en el payload, en el caso de existir octetos de relleno, el último octeto del payload indica el número de octetos de relleno presentes en el payload. Extensión (1 bit): se usa para indicar extensiones del encabezado para versiones experimentales de RTP. Contador CSRC (4 bits): indica el número de fuentes que intervienen en el proceso de comunicación . Marker (Marcador) (1 bit): el uso de este bit depende del tipo de payload que lleve el paquete, pues en un archivo de audio significa el inicio de la comunicación, mientras que en archivos de video significa el fin del bloque de datos. Payload Type (Tipo de carga util) (7 bits): sirve para identificar el formato de la carga útil del paquete RTP.
FIGURA 2. MODELO GENERICO PARA COMUNICACIONES CON PROTOCOLO RTP.
Como era de esperar RTP trabaja con segmentos UDP en la capa de transporte y protocolo IP en la capa de red, por lo cual no cuenta con un mecanismo para asegurarnos de la entrega de paquetes, los datagramas RTP contienen en su encabezado información del tipo de codificación usado en el archivo de audio o video, pero esto varía de acuerdo al tipo de codificación de audio o video que se esté empleando, esto también es determinante para asignar flujos independientes para las diferentes fuentes de información que pueden involucrarse en la comunicación, como en el caso de las video conferencias. RTP puede tener aplicaciones de multidifusión. El encabezado de un paquete RTP tiene los siguientes campos:
FIGURA 3. PAQUETE RTP.
Sequence Number (número de secuencia) (16 bits): ayuda a ordenar la secuencia de paquetes para una adecuada reproducción. Timestamp (marca de tiempo) (32 bits): es un valor que depende del tipo de payload que se transporte, y su valor hace referencia al instante de tiempo en el cual fue generado el primer octeto de datos del payload. SSRC (Identificador de sincronización de Fuente): es un número que identifica a una fuente con una sesión en particular. CSRC (Identificador de fuentes contribuyentes): identifica al tipo de fuente contribuyente del payload.
La RFC 1890 resume el tipo de payload para los paquetes RTP.
FIGURA 4. TIPOS DE FORMATOS SOPORTADOS POR RTP
2.2. PROTOCOLO RTCP.
Este es un protocolo desarrollado para ser usado de forma conjunta con el protocolo RTP, especialmente para transmisiones multicast, su principal función es la entrega de información acerca de los miembros de la sesión, en forma de estadísticas que advierten situaciones como la cantidad de paquetes perdidos y entregados, esta información puede ser de gran ayuda en alguno de los terminales miembros de la comunicación, además del tipo de paquete la principal diferencia entre los paquetes RTP y RTCP radica en que hacen uso de distinto número de puerto, generalmente el número de puerto de RTCP es un número mayor que el del RTP.
número de bytes enviados y contador de paquetes.
La RFC 3550 define 5 clases de paquetes RTCP: RR (Reporte de Receptor): este tipo de reporte es generado por participantes de la sesión que habitualmente no generan paquetes de comunicación, contiene información acerca de paquetes enviados y recibidos, jitter de arribo, marcas de tiempo para calcular tiempos de comunicación entre emisor y receptor.
FIGURA 6. PAQUETE RTCP TIPO SR
SDES (Ítems de Información de la Fuente): contiene información que identifican de manera única a los participantes de una sesión como; número de teléfono dirección de e-mail, nombre de usuario, etc.
FIGURA 5. PAQUETE RTCP TIPO RR
SR (Reporte de Emisor): este tipo de reportes son generados por emisores que intervienen de manera habitual en la sesión, contienen información acerca del emisor, sincronización,
FIGURA 7. PAQUETE RTCP TIPO SDES
BYE: este tipo de paquete se usa para indicar el fin de la participación en la sesión.
Figura 10. RTSP Establece y controla uno o varios flujos sincronizados de medios continuos (audio y video).
FIGURA 8. PAQUETE RTCP TIPO BYE
APP (Funciones de aplicación específica): se usan para aplicaciones experimentales y para el desarrollo de nuevas características.
Para conseguir siempre un envió fiable a través de redes IP con mayor eficiencia el RTSP define diferentes tipo de conexión y diferentes conjuntos de requisitos. También a través de un único identificador se define el uso de sesiones, lo cual permite al cliente abrir o cerrar confiables con el servidor mediante peticiones RTSP Cuando usa el flujo controlado puede usar el RTP, pero en su operación el RTSP es independiente del mecanismo de transporte usado para transmitir el flujo continuo de datos, en la mayoría de casos se usa TCP para control de reproductor y UDP para la transmisión de datos con RTP. Propiedades del protocolo RTSP:
Extensible
•Permite que nuevos métodos y parámetros pueden ser añadidos a RTSP fácilmente.
Seguro
•Usa los mecanismos de seguridad de la web, cualquiera a nivel de transporte. Pudiendo aplicar directamente los mecanismos de autentificación de http.
FIGURA 9. PAQUETE RTCP TIPO APP
2.3. PROTOCOLO DE FLUJO DE DATOS EN TIEMPO REAL (RTSP) REAL TIME STREAMING PROTOCOL Es un protocolo de aplicación para el control de la entrega de datos en tiempo real. Actúa como un “control remoto de red” para servidores multimedia. Este protocolo es no orientado a conexión y se usa en definición de cómo se envía información entre el cliente y el servidor. Su trabajo corresponde al nivel de aplicación y su control se basa en la correcta entrega de datos, ya que el contenido que porta al hacer streaming es sensible a la sincronía temporal o la falta de la misma; actúa así como mando a distancia para servidores multimedia.
Capacidad multiservidor:
Neutral presentacion es
•Cada flujo de contenido perteneciente a una misma presentación puede residir en diferentes servidores.
•No impone ninguna descripción particular o formato concreto de metafile.
•Si las características básicas están desactivadas, hay un mecanismo para Capacidad de determinar el métodos a ser implementado. negociación
El protocolo es muy similar al HTTP/1.1, pero su diferencia radica en lo siguiente: a. RTSP introduce una serie de nuevos métodos y tiene una diferente identificadora de protocolo.
Creado por la IETF (Internet Engineering Task Force), es un protocolo de señalización, ya que realiza tres tareas primordiales en sesiones multimedia como son:
b. Un servidor RTSP necesita para mantener el
Establece
estado por defecto en casi todos casos, en
Libera
oposición a la naturaleza sin estado de HTTP.
Modifica
c.
Tanto un servidor RTSP y el cliente puede emitir solicitudes.
d. Los datos se lleva a cabo de banda por un protocolo diferente e. RTSP se define para utilizar la norma ISO 10646 (UTF-8) en lugar de la norma ISO 88591, en consonancia con los esfuerzos de internacionalización HTML actuales. f.
La Request-URI siempre contiene el URI absoluto. Porque compatibilidad hacia atrás con un error histórico, HTTP / 1.1 lleva
g.
solamente la ruta absoluta en la solicitud y
Mensajería instantánea
pone el anfitrión nombrar en un campo de la
Transferencia de llamadas
cabecera separada.
Servicios complementarios de telefonía
Esto hace que "hosting virtual" más fácil, donde un único host con un solo Dirección IP es sede de varios árboles de documentos.
El RTSP soporta las siguientes operaciones:
Proporcionar contenidos multimedia desde un servidor dedicado
Invitación de un servidor de streaming a una conferencia
A su vez hereda ciertas funciones del HTTP (Hyper Text Tranport Protocol) y del SMTP (Simple Mail Transport Protocol). El SIP usa lo de Cliente servidor, y su direccionamiento usa el URL SIP (Uniform Transaccional Locator SIP) muy similar a un email, por lo tanto cada participantes es alcanzable Un requerimiento SIP contiene el encabezamiento o el “headers” al igual que un mando STMP, lo cual lo hace un protocolo textual. Su extensión llega a soportar numerosos servicios como:
Añadido de contenido multimedia a una presentación existente
Peticiones RTSP Direcciones del trafico DESCRIBE C→S GET_PARAMETER C → S, S → C OPTIONS C → S, S → C PAUSE C→S PING C → S, S → C PLAY C→S REDIRECT S→C SETUP C→S SET_PARAMETER C → S, S → C TEARDOWN C→S
El SIP hace un control de sesión y un control de servicio de la arquitectura “IP Multimedia Subsystem” o IMS en 3GPP, se cree que en el futuro reemplazar al ISUP que es usado en el control de llamadas en Redes Telefónicas Conmutadas y el INAP usado control de servicio de arquitectura inteligente. Como se ha mencionado anteriormente el SIP es un protocolo de señalización, cuando esta está establecida los participantes de la sesión intercambian directamente su tráfico sea este un audio/video usando el protocolo RTP. Ya que el SIP no reserva recursos, el mismo no podría asegurar la calidad del servicio, lo que hace en si es el control de la llamada no del medio.
Tabla 1. Tabla de comunicación mediante RTSP.
2.4. PROTOCOLO DE INICIACIÓN DE SESIÓN (SIP) “SESSION INITIATION PROTOCOL”
Figura 11. Conexión SIP.
SIP
HTTP
Transmite mensajes de señalización cortos para establecer, mantener y liberar la sesión multimedia
Transporta grande volumen de datos
Tabla 2. Diferencias entre SIP y HTTP
Funciones del protocolo SIP
Localización de usuario (Proporcionando
Figura 12. Servidor proxy y re direccionamiento SIP.
soporte para la movilidad)
Capacidad de usuario (permite la negociación
2.5. PROTOCOLO H.323
de parámetros)
Disponibilidad del usuario
Establecimiento y mantenimiento de una sesión.
Aspectos importantes del SIP: Control de llamadas sin estado o “stateless”, que proporciona escalabilidad entre dispositivos telefónicos y los servidores Necesita menos ciclos de una CPU para la generación de los mensajes de señalización, permitiéndole al server manipular más transacciones Una llamada SIP es independiente de la existencia de una conexión en la capa transporte En Autenticación el SIP usa cualquier capara de transporte o cualquier mecanismo de seguridad sea HTTP, SSH o S-HTTP. Un proxy SIP puede controlar la señalización de la llamada y puede bifurcar a cualquier dispositivo simultáneamente
MÉTODO INVITE ACK BYE OPTION CANCEL REGISTER
Este protocolo nació en el ano de 1996 y se denominó “Sistemas y terminales de telefonía visual sobre redes de área local sin garantías de calidad de servicio”. Este estándar aporto al desarrollo de un conjuntos de protocolos de señalización que permitan controlar el establecimiento, mantenimiento y liberación de conexiones multimedia sean estos audio, video o datos en la redes de paquetes. En 1998 reaparece la segunda versión del H.323 v2 con su nombre “Packet based multimedia communications systems”, y es considerado como paraguas de estándares.
DESCRIPCIÓN Solicita el inicio de una sesión Confirma que se inició una sesión Solicita la terminación de una sesión Consulta a un host sobre sus capacidades Cancela una solicitud pendiente Informa a su servidor de redireccion sobre la ubicación actual del usuario
Tabla 2. Métodos usados para conexión SIP.
Figura 13. Arquitectura del modelo H.323
Terminal H.323
Proporciona en tiempo real una comunicación bidireccional con otros terminales H.323. El intercambio de información incluye controles, indicaciones, audio, video y datos. Cada terminal debe soportar a o mínimo: transmisión de voz
voz y datos
voz y video
voz, datos y video
Soporte para multiconferencias.- permite mantener multiconferencias sin el uso de entidades especializadas más MCUs (Multipoint Control Units) proporcionan arquitectura más robusta y flexible.
Gestión de ancho de banda.- el tráfico de audio y video resulta costos en ancho de banda, se limita las conexiones.
Soporte en multicast.- envía un solo paquete hacia un conjunto de destino sin replicación.
Figura 14. Estructura del terminal H.323
En la siguiente figura se muestra la arquitectura del protocolo incluyendo el transporte de medios, transporte de protocolos y de señalización. L mayor parte de los canales usan conexiones TCP y la UDP a partir de la versión 3, mientras el transporte de medios utiliza UDP.
Figura 15.Pila del protocolo H.323
Características Principales
Interoperabilidad entre distintos fabricantes.debido a su complejidad este protocolo intenta acotar todas las posibilidades de la comunicación, de las capacidades de la funcionalidad de cada elemento de la red
Independencia de la red.- hace referencia a redes de paquetes que no provean calidad de servicio, pero no especifica ningún protocolo de red en concreto.
Independencia de la plataforma y de la aplicación.- siempre que se cumplan los requisitos y procedimientos descritos en las especificaciones, podrán hacer uso el H.323 cualquier plataforma, hardware o sistema operativo deseado.
3. CONCLUSIONES. El protocolo UDP de la capa de transporte es la solución más idónea a la hora de establecer un adecuado equilibrio entre el tráfico que demandan diversas aplicaciones en tiempo real y los recursos de la red de comunicaciones. Los protocolos para comunicaciones en tiempo real RTP varían de acuerdo a los formatos de audio o video que se desean transmitir, aunque soporta también varios formatos propietarios es importante tener en cuenta los diversos tipos de codificaciones de audio y video. RTP es importante el desarrollo e implementación de protocolos como el RTCP, SIP y H.323, por lo que resulta necesario conocer la información básica que contienen los paquetes RTP. RTCP es un mecanismo que nos puede ayudar a mejorar los niveles de calidad en una sesión multicast, pero eso depende de la aplicación que implementemos para trabajar con la información contenida en los paquetes RTCP. El protocolo RTSP es en sí un control remoto de red en servicio multimedia no orientado a conexión, su característica es la correcta entrega de datos, lo cual facilita la virtualización de hosting con un solo dominio IP, adema soporta invitaciones a streaming, añadir contenido multimedia, etc. El protocolo SIP es un protocolo de señalización que realiza el proceso de establecer, liberar y modificar en sesiones multimedia, soporta mensajería, transferencia de llamadas y sus servicios complementarios de telefonía, adicional es el protocolo que está reemplazando al H.323
El protocolo H.323 es el protocolo inferior al SIP realiza procesos muy similares al SIP,, pero es un sistema sin garantías de calidad de servicio
BIBLIOGRAFIA: [1] KUROSSE J. Redes de Computadoras Un Enfoque Descendente. Boston –USA, 2012, 7ma edición. [2] STALLINGS W. Data and computers communications. New Jersey-USA, 8va edición. [3] ARJAN D. RAJ J. RTP, RTCP and RTSP Internet protocols for Real Time Multimedia Communication. Louisiana-USA, 2005. [4] ISHANT Raj, KAMALJEET Singh, RAHUL Raj, T. J. Parvat. Real Time Communicaction over Modified UDP Protocol. IOSR Journal of Computer Engineering (IOSR-JCE)
[5] David Mateos Costilla, Samuel Reaño, Streaming de Audio/Video. Protocolo RTSP, Serveis Telematics, Enginy 2012, pdf de uib.es http://enginy.uib.es/index.php/enginy/article/vi ewFile/74/53 [6] Francisco Suarez Alonso, Universidad de Oviedo, área de arquitectura y tecnología de computadoras, 2010-2011, pdf de uniovies, http://www.atc.uniovi.es/teleco/5tm/archives/8 streaming.pdf [7] José Moreno, Ignacio Soto, David Larrabeiti, Universidad Carlos III de Madrid, Ingeniería de Telemática, Protocolos de señalización para el transporte de voz sobre redes IP, pdf de uc3m.es, http://orff.uc3m.es/handle/10016/4295 [8] ITU, Estándar H.323 Diseño y configuración de dos plataformas de interfonia H.323 pdf online: http://bibing.us.es/proyectos/abreproy/11252/fi chero/2-H.323.pdf [9] Andrew S Tanebaum, Redes de computadoras, Cuarta edición, protocolos en tiempo real, pp 529-555
