Embed Size (px)
DESCRIPTION
RTP, RTCP.
Citation preview
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.
2. PROTOCOLOS DE COMUNICACIÓN EN TIEMPO REAL.
Los requerimientos de comunicaciones en tiempo real
conllevaron a que investigadores se involucren en el
diseño de familias de protocolos donde se incluyen:
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.
FIGURA 1. FLUJO DE DATOS PARA COMUNICACCIONES EN TIEMPO REAL
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.
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.
Donde:
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.
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.
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.
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,
número de bytes enviados y contador de
paquetes.
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 7. PAQUETE RTCP TIPO SDES
FIGURA 5. PAQUETE RTCP TIPO RR
BYE: este tipo de paquete se usa para indicar el
fin de la participación en la sesión.
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.
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.
Figura 10. RTSP Establece y controla uno o varios flujos sincronizados de medios continuos (audio y video).
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.
Capacidad multi-
servidor:
•Cada flujo de contenido perteneciente a una misma presentación puede residir en diferentes servidores.
Neutral presentacion
es
•No impone ninguna descripción particular o formato concreto de metafile.
Capacidad de negociación
•Si las características básicas están desactivadas, hay un mecanismo para determinar el métodos a ser implementado.
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.
b. Un servidor RTSP necesita para mantener el
estado por defecto en casi todos casos, en
oposición a la naturaleza sin estado de HTTP.
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 8859-
1, 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
solamente la ruta absoluta en la solicitud y
pone el anfitrión nombrar en un campo de la
cabecera separada.
g. 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ñ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 Tabla 1. Tabla de comunicación mediante RTSP.
2.4. PROTOCOLO DE INICIACIÓN DE SESIÓN (SIP) “SESSION INITIATION PROTOCOL”
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:
Establece
Libera
Modifica
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:
Mensajería instantánea
Transferencia de llamadas
Servicios complementarios de telefonía
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.
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
soporte para la movilidad)
Capacidad de usuario (permite la negociación
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 DESCRIPCIÓN
INVITE Solicita el inicio de una sesión
ACK Confirma que se inició una sesión
BYE Solicita la terminación de una sesión
OPTION Consulta a un host sobre sus capacidades
CANCEL Cancela una solicitud pendiente
REGISTER Informa a su servidor de redireccion sobre la ubicación actual del usuario
Tabla 2. Métodos usados para conexión SIP.
Figura 12. Servidor proxy y re direccionamiento SIP.
2.5. PROTOCOLO H.323
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.
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
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.
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.
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
