Tema 4: Comunicaciones Multimedia.

(1)

Dpto. de Ingeniería de Telecomunicación Área de Ingeniería Telemática

Universidad de Jaén E. P. S. de Linares

4.1 La pila de protocolos para comunicaciones multimedia en Internet

Introducción.

4.2 Protocolos y modelos de servicio de Internet

4.3 Protocolos de transporte de tiempo real. RTP y RTCP

4.4 El concepto de sesión multimedia

Contenido

Tema 4

Comunicaciones Multimedia

2

Bibliografía

Ref

Weinstein, Stephen. “The Multimedia Internet", 2005, Springer.

Gibson, Jerry D. “Multimedia Communications”, 2001, Academic Press.

Perkins, Colin. “RTP. Audio and Video for the Internet”. 2003. Pearson Education.

Bibliografía básica

(2)

[RFC 3550] RTP: A Transport Protocol for Real-Time Applications

(Incluye RTCP)

H. Schulzrinne, S. Casner, R. Frederick y V. Jacobson

July 200

[RFC 2776] Multicast-Scope Zone Announcement Protocol (MZAP)

M. Handley, D. Thaler y R. Kermode

February 2000

Bibliografía básica

Tema 4

Comunicaciones Multimedia

4

Bibliografía

Ref

[RFC 4566] SDP: Session Description Protocol.

M. Handley, V. Jacobson, C. Perkins

Obsoletes: 2327, 3266. July 2006

[RFC 2974] Session Announcement Protocol

C. Perkins E. Whelan

October 2000

[RFC 3261] SIP: Session Initiation Protocol

J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M.

Handley y E. Schooler

June 2002

Bibliografía básica

(3)

[Schulzrinne01] Schulzrinne, H. and Rosenberg, J. “Internet Telephony: Architecture

and Protocols”

an IETF Perspective. Computer Networks, 31(3):237–255, 1999.

Bibliografía básica

Tema 4

Comunicaciones Multimedia

6 La pila de protocolos para comunicaciones multimedia en Internet

Auge multimedia.

El interés por la video conferencia y los servicios multimedia dentro de la comunidad de

Internet comenzó a tener su auge a principio de la década de 1.990.

Esto coincidió con el aumento de las capacidades multimedia de los PCs y estaciones de

trabajo, lo que posibilitaba la simultaneidad de captura, compresión y reproducción de

audio y video.

4.1

(4)

Desarrollo de IP Multicast.

En paralelo el desarrollo de IP Multicast posibilitaba la transmisión de datos en tiempo

real a cualquier número de receptores conectados a Internet.

La videoconferencia y el streaming de contenidos multimedia son aplicaciones

multicast típicas.

Los estudios y herramientas desarrolladas dentro del marco de Mbone llevaron a un

profundo estudio de los problemas de la distribución en tiempo real, la necesidad de

escalabilidad y el control de congestión, dando lugar a los protocolos clave, algunos de

ellos usados hoy en día.

Introducción.

Tema 4

Comunicaciones Multimedia

8 La pila de protocolos para comunicaciones multimedia en Internet

Las comunicaciones multimedia en Internet necesitan, además de protocolos de

transmisión de paquetes y mensajes, de:

Protocolos que establezcan y manejen sesiones.

Controles de congestión.

Controles de temporización y entrega de la información multimedia.

Controles de reproducción y acceso a la información multimedia.

Es por eso que en Internet la familia de protocolos involucrados en las comunicaciones

multimedia es amplia y heterogénea.

4.1

(5)

Dpto. de Ingeniería Electrónica, de Telecomunicación y Automática Área de Ingeniería Telemática

IP

TCP

UDP

RTP

RTSP

SIP

SAP

Negociación de Medio

Control de llamada

Sesiones

Ligeras

CODECs

Multimedia

SAP: Session Announcement Protocol SIP: Session Initiation Protocol RTSP: Real Time Streaming Protocol RTP: Real-time Transport Protocol SAP: Session Announcement Protocol SIP: Session Initiation Protocol RTSP: Real Time Streaming Protocol RTP: Real-time Transport Protocol

Tema 4

Comunicaciones Multimedia

10 La pila de protocolos para comunicaciones multimedia en Internet

Paralelamente a los primeros pasos de la voz sobre redes de paquetes, fue el desarrollo

de la RDSI y su familia de estándares para videoconferencia H.320.

Aunque esta norma es para redes de conmutación de circuitos y no tiene mucho interés

para la asignatura, si fue pionera en varios aspectos, como en los algoritmos de

compresión, como por ejemplo el H.261 video, usado hoy en día.

El uso cada vez mayor de Internet y la mejora de los equipos y su implantación

comercial, llevó al ITU a extender la norma H.320 a las redes de área local y redes de

paquetes sin calidad de servicio, como IP, creando la serie de recomendación H.323.

4.1

(6)

IP

UDP

TCP

RTP

H.255.0 Media

CODECs

Registro/

Admisión

Pila de Protocolos de la recomendación H.323 del ITU.

H.245 Negociación de Medio

Control de llamada

H.255.0: Fragmentación y empaquetado de contenido multimedia y configuración de llamadas

H.245: Protocolo de Control

H.255.0: Fragmentación y empaquetado de contenido multimedia y configuración de llamadas

H.245: Protocolo de Control

Tema 4

Comunicaciones Multimedia

12 Protocolos y modelos de servicio de Internet

4.2

En la comunicaciones multimedia en Internet intervienen gran número de protocolos, de los cuales algunos ya se han visto en esta u otras asignaturas. A continuación se enumeran aquellos que serán estudiados en esta asignatura, todos ellos estrechamente relacionados con las comunicaciones y tráfico multimedia sobre Internet.

Protocolos de Transporte (Tema 4):

RTP: Protocolo de Transporte de datos de Tiempo Real (RTCP es su protocolo de control)

Protocolos de Control de Sesiones (Tema 5): SDP: Protocolo de Descripción de Sesión. SAP: Protocolo de Anuncio de Sesión SIP: Protocolo de Inicio de Sesión

Protocolos de Aplicación (Tema 6):

(7)

Universidad de Jaén E. P. S. de Linares RTP (Real-time Transport Protocol)

RTP [RFC 3550] se diseñó con objeto de proporcionar cobertura a los servicios que necesitaban transportar datos en tiempo real, como audio y video (RTCP es su protocolo de control)

RTP, es un protocolo de transporte al igual que TCP o UDP, el cual aporta gran versatilidad a la hora de definir tipos de información transportada (payload), control de tiempos, identificación de flujos y fuentes de información, detección y corrección de pérdidas, realimentación de calidad, sincronización de medios y control de acceso.

RTP se implementó en origen para dar cobertura sobre IP Multicast en sesiones con modelo ligero (“lightweight”)

Normalmente no se implementa por sí sólo, sino que se usa encima de UDP por motivos prácticos y se ha demostrado que es útil tanto para punto a punto como con miles de usuarios en un entorno multicast.

Tema 4

Comunicaciones Multimedia

14 Protocolos y modelos de servicio de Internet

4.2

SDP (Session Description Protocol)

El protocolo SDP [RFC 4566] se utiliza para describir sesiones multicast en tiempo real, siendo útil para invitaciones, anuncios, y cualquier otra forma de inicio de sesiones.

La propuesta original de SDP fue diseñada para anunciar información necesaria para los participantes y para aplicaciones de multicast MBONE. Actualmente, su uso está extendido para el anuncio y la negociación de las capacidades de una sesión multimedia en Internet.

Puesto que SDP es un protocolo de descripción, los mensajes SDP se pueden transportar mediante distintos protocolos con SIP, SAP, RTSP, correo electrónico con aplicaciones MIME o protocolos como HTTP. Como el SIP, el SDP utiliza la codificación del texto. Un mensaje del SDP se compone de una serie de líneas, denominados campos, dónde los nombres son abreviados por una sola letra, y está en una orden requerida para simplificar el análisis. El SDP no fue diseñado para ser fácilmente extensible.

(8)

Universidad de Jaén E. P. S. de Linares SDP (Session Description Protocol)

Ejemplo de descripción de sesión con SDP (Extraído de la RFC 2327)

v=0

o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4 s=SDP Seminar

i=A Seminar on the session description protocol u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps [email protected] (Mark Handley)

c=IN IP4 224.2.17.12/127 t=2873397496 2873404696 a=recvonly m=audio 49170 RTP/AVP 0 m=video 51372 RTP/AVP 31 m=application 32416 udp wb a=orient:portrait

Tema 4

Comunicaciones Multimedia

16 Protocolos y modelos de servicio de Internet

4.2

SAP (v1 y v2) (Session Announcement Protocol)

Session Announcement Protocol (SAP) [RFC 2974] es un protocolo de aviso que se usa para asistir a los anuncios de conferencias multicast, ya sean multimedia o de otro tipo, y para también comunicar información relevante de configuración a cada uno de los respectivos participantes.

Un avisador SAP envía un paquete de anuncio multicast periódicamente a una dirección y puerto bien-conocida. El aviso tiene el mismo ámbito/alcance que la sesión que está anunciando, asegurando que los destinatarios del aviso pueden ser también destinatarios de la sesión que anuncia. Esto es importante para la escalabilidad del protocolo, ya que los avisos de sesiones locales se quedan dentro del ámbito local

Se debe tener en cuenta que aun es un protocolo experimental, y en algunas ocasiones se recomienda el uso de SIP en vez de SAP.

(9)

Universidad de Jaén E. P. S. de Linares SIP (Session Initiation Protocol)

SIP [RFC 3261] es un protocolo de aplicación de señalización muy flexible que permite crear, modificar y terminar sesiones con uno o más participantes. Estas sesiones incluyen llamadas de teléfono a través de Internet, distribución de contenido multimedia y conferencias multimedia.

Las invitaciones SIP usadas para crear sesiones portan descripciones de las mismas que permiten a los participantes acordar una serie de medios compatibles.

SIP hace uso de servidores proxy para ayudar a enrutar las peticiones de localización actual del usuario, autenticación y autorización de usuarios para acceso a servicios, implementar políticas de enrutado de llamadas de los proveedores de servicio y proporcionar un juego de características y capacidades al usuario. SIP también proporciona una función de registro que permite informar al servidor proxy de su localización actual.

SIP funciona sobre diferentes capas de transporte.

Tema 4

Comunicaciones Multimedia

18 Protocolos y modelos de servicio de Internet

4.2

RTSP (Real Time Streaming Protocol)

RTSP es un protocolo de nivel de aplicación para el control de las propiedades de tiempo real durante el envío de información, al estilo de los controles que poseen los VCR tradicionales (play, stop, rebobinar, avance rápido, …)

RTSP proporciona un marco extensible que permite controlar datos de tiempo real bajo demanda, tales como audio y video. Las fuentes pueden incluir tanto contenidos en vivo, como clips almacenados.

Este protocolo está diseñado para controlar múltiples sesiones de envío de datos, además de estar preparado para funcionar sobre UDP unicast , UDP multicast, TCP y RTP.

(10)

Universidad de Jaén E. P. S. de Linares Modelos de Servicio de Internet

Los servicios multimedia actuales podrían agruparse en tres grandes grupos:

Conferencias Multimedia (Videoconferencia, Telefonía IP, …)

Intercambio de ficheros de audio y video (Aplicaciones P2P, WWW,…)

Difusión por Internet. (Televisión en directo, radiodifusión, …)

Cada uno de ellos utiliza algunos de los protocolos que se han mencionado antes (SDP, SAP, RTSP, SIP, Conjunto H.323, HTTP, …), aunque la gran variedad de estos a nivel de aplicación hace el estudio de todos estos servicios una tarea compleja.

Sin embargo a nivel de transporte, el conjunto es mucho más reducido, estando UDP, TCP y RTP solamente.

Tema 4

Comunicaciones Multimedia

20 Protocolos y modelos de servicio de Internet

4.2

Modelos de Servicio de Internet

Para dar cobertura a estos tres grandes tipos de servicios multimedia no se dispone de un solo protocolo para su control, sino que son necesarios la cooperación de gran número de ellos, cada uno con unas tareas bien definidas.

Esquema general de protocolos usados por los servicios multimedia .

Unicast Transporte con conexión Transporte en tiempo real Establecimiento y Control de Sesión Descripción de Sesión Calidad de servi cio Nivel de Transporte Multicast Transporte sin conexión Seguridad Nivel de Red Nivel de Aplicación Control de contenidos

(11)

Universidad de Jaén E. P. S. de Linares Modelos de Servicio de Internet

Como ejemplo de un servicio de comunicaciones multimedia de Internet se ha elegido la Telefonía IP (IPTel) o Voice over IP (VoIP) el cual se sirve de todos los protocolos que se verán en temas posteriores.

Tema 4

Comunicaciones Multimedia

22 Protocolos y modelos de servicio de Internet

4.2

Sin duda, la Telefonía IP (IPTel) o Voice over IP (VoIP) es uno de los servicios más conocidos y con un mayor futuro dentro de Internet. Es posiblemente la opción más seria para sustituir a la telefonía convencional, o al menos ser una alternativa solvente.

El principio de la telefonía IP es que la voz es codificada y transmitida sobre redes de conmutación de paquetes y no sobre las redes públicas de conmutación de circuitos.

Las aplicaciones de VoIP abarcan todas las posibilidades: PC a PC

PC a Teléfono Teléfono a PC Teléfono a Teléfono.

Voice over IP (VoIP)

(12)

Dpto. de Ingeniería Electrónica, de Telecomunicación y Automática Área de Ingeniería Telemática

i

Reseña Histórica

La primera solución de VoIP ampliamente extendida fue el Internet Phone de VocalTec en 1.995 que costaba alrededor de 50 $. Era sólo half-dúplex. En la actualidad todos los productos son full-dúplex.

La aplicaciones VoIP para sistemas fuera del PC comenzaron el la última parte de la década de 1.990, como por ejemplo la serie 7900 de Cisco con G.711 y G.729a, señalización SIP, compatible con NetMeetingtm _{de Microsoft y servidor DHCP.}

Actualmente productos como Skype o Microsoft Messenger proporcionan VoIP gratuito PC a PC y precios realmente competitivos para las llamadas a terminales de la Red Telefónica Básica o móviles.

Voice over IP (VoIP)

Cisco 7960 IP phone

Tema 4

Comunicaciones Multimedia

24 Protocolos y modelos de servicio de Internet

4.2

Introducción.

VoIP o IPTel no es un protocolo, ni siquiera una aplicación, es algo mucho más amplio, es un servicio completo, como la Telefonía Básica, la Televisión o yéndonos a otras áreas, la navegación aeronáutica.

Implica a muchos agentes: estándares (protocolos, codificadores, normativas internacionales,…), sistemas (PCs, pasarelas, proxys, routers), tipos de comunicación (unicast, multicast), contenidos (voz, audio, señalización), etc.

Aunque a pesar de todo, la idea es extremadamente simple:

Que cualquier número de usuarios pueda conversar usando Internet como portadora de la información, de manera sencilla, barata y eficaz.

(13)

Ventajas.

Barato.

El servicio de VoIP requiere de una nula inversión en despliegue de redes de comunicaciones, al contrario que la telefonía convencional, lo cual hace que el coste de despliegue del servicio sea mucho menor que el de un operador de telefonía básica. Estos costes dependerán de la cantidad de usuarios a los que se quiera atender simultáneamente, calidad de servicio, variedad de llamadas (nacionales, internacionales, a móviles,…), etc.

Escalabilidad

Al no requerir de despliegue de redes, el sistema puede crecer rápidamente en nuevas zonas, tan sólo instalando pasarelas entre Internet y la operadora u operadoras de TB de la zona.

Voice over IP (VoIP)

Tema 4

Comunicaciones Multimedia

26 Protocolos y modelos de servicio de Internet

4.2

Ventajas.

Calidad ajustable.

A pesar del mito de la voz por Internet tiene un sonido metálico debido al uso de codificadores de bajo bit rate, esto no es siempre así, ya que puede llegar a calidades en las que resultaría agradable escuchar música. Además, esta capacidad de usar diferentes calidades permite que las comunicaciones usando VoIP puedan adaptarse a la situación cambiante del ancho de banda en Internet.

Seguridad.

Las comunicaciones de VoIP pueden ser altamente seguras, ya que SIP permite encriptación y autenticación de los mensajes de señalización y RTP soporta el encriptación de los datos transportados.

(14)

Ventajas.

Identificación de usuario.

Las operadores de telefonía fija o móvil suelen proporcionar la identidad del usuario en llamadas entrantes (número o incluso nombre), pero en una conferencia multiparte no hay ninguna indicación. La Telefonía IP, usando RTP proporciona información de cada integrante de una comunicación, ya sea multiparte o desviada, pudiendo aportar información más detallada de los participantes si se desea.

Interfaz de usuario.

Un sistema de VoIP posee un juego más rico de capacidades de señalización, además de la posibilidad de usar interfaces gráficos que pueden ser personalizados.

Voice over IP (VoIP)

Tema 4

Comunicaciones Multimedia

28 Protocolos y modelos de servicio de Internet

4.2

Ventajas.

Mensajería unificada.

Las aplicaciones de VoIP, ya sea sobre PC o teléfono IP, pueden incorporar la muchas funcionalidades que quedan fuera de las posibilidades de la TB o que serían de implantación muy dificultosa o de coste elevado. Estas son por ejemplo la mensajería instantánea o compartir de contenidos multimedia de cualquier tipo.

Movilidad.

Al basarse en un servicio on-line disponible a través de Internet, allá donde se tenga conexión a Internet se podrá disfrutar del servicio, totalmente personalizado, porque no cambiará ni el cliente ni la forma de facturar, ya sea en Europa o en Asia.

(15)

Desventajas.

Inercia del mercado.

Por ahora es difícil el cambio de la mentalidad de los usuarios, sobre todo a fiabilidad y privacidad, además de facilitar equipos terminales sencillos de usar y configurar por usuarios que no conozcan nada de la tecnología subyacente.

Dependencia de acceso por la red de telefonía básica.

Las compañías de TB ofrecen normalmente el servicio de acceso a Internet a través de ADSL o DSL, lo cual obliga a disponer de una línea de TB. Además, el acceso a Internet es difícil en algunas áreas.

Voice over IP (VoIP)

Tema 4

Comunicaciones Multimedia

30 Protocolos y modelos de servicio de Internet

4.2

Requerimientos de la VoIP.

Fundamentalmente los dos aspectos más importantes del servicio de VoIP son la calidad de la voz y el retardo.

Ambos aspectos son cruciales a la hora de competir con la Telefonía Básica, pero si bien pueden ser difíciles de controlar en entornos como el de Internet, dan una mayor versatilidad al servicio, pudiendo ofrecer diferentes calidades de voz, a la vez que facilitan la integración con los datos por la misma naturaleza de Internet, y la posibilidad de llamadas de emergencia masivas (multicast), o la integración con otros servicios como el e-mail.

En VoIP, para asegurar que el servicio se mantendrá dentro de unos márgenes aceptables y no congestionar la red, se utilizan técnicas de control de acceso, en contra de la conmutación de circuitos de la TB (aunque eso implique un control de acceso previo).

(16)

Requerimientos de la VoIP.

Calidad de la voz.

Como se ha visto en el tema pasado, los codificadores de voz consiguen buenas calidades de voz a regímenes binario suficientemente bajos a con costes computacionales asumibles, por lo que actualmente el conseguir una voz inteligible y natural no es el principal problema de VoIP.

Retardos.

Es en este apartado donde VoIP tiene más trabajo pendiente, y es mucho más difícil competir con la Telefonía Básica.

Voice over IP (VoIP)

Tema 4

Comunicaciones Multimedia

32 Protocolos y modelos de servicio de Internet

4.2

Retardos en VoIP.

Los dos retardos que afectan a la VoIP y son cruciales para que el servicio cumpla con las expectativas del usuario son el retardo de empaquetado y el retardo de transmisión.

Retardo de empaquetado: Este retardo es necesario para disponer de la suficiente información codificada para formar paquetes de tamaño apropiado que hagan que la sobrecarga de cabecera no sea un problema. Una solución en las redes troncales es la multiplexación de múltiples paquetes con baja eficiencia en otros mayores contiendo la voz de varios usuarios.

Retardo de red: Este problema se deriva de la existencia de diferentes tipos de tráfico con diferente prioridad y del hecho de que el de baja prioridad pueda bloquear al de alta prioridad. En IP, una de las soluciones más apropiadas es el uso de QoS como Diffserv.

(17)

Resumen.

Sin entrar en detalle en cada uno de los protocolos usados (algunos ya se han visto o se verán en apartado o temas posteriores) se ha visto VoIP o IPTel como un servicio que involucra a gran cantidad de agentes dentro de las comunicaciones multimedia en Internet.

VoIP, ampliamente usado ya en la actualidad, pretende se una alternativa a la telefonía convencional, y las grandes empresas (no necesariamente operadoras de telecomunicaciones) se han dado cuenta de que pueden reducir sus costes de comunicaciones y además aportar servicios de valor añadido muy interesantes.

Si bien es cierto que la profusión de aplicaciones y la misma concepción de Internet dificulta una implantación tan robusta como la Telefonía Básica, es hoy en día una apuesta seria para el futuro de las comunicaciones de voz, imágenes y datos por Internet.

Voice over IP (VoIP)

Tema 4

Comunicaciones Multimedia

34 Protocolos de transporte de tiempo real. RTP y RTCP

4.3

¿Qué es RTP?

Real-time Transfer Protocol (RTP) proporciona un envío extremo a extremo de servicios de datos con características de tiempo real, tales como audio y video interactivos.

En origen fue diseñado para soportar conferencias multimedia multipunto. Sin embargo es usado para diversos tipos de aplicaciones más allá de la conferencia multipunto.

RTP es una estándar especificado en la RFC 1889. Las versiones más recientes son la RFC 3550 y la RFC 3551. Además forma parte de las recomendaciones del estándar H.323 del ITU para las sesiones multimedia y para sistemas de streaming multimedia que soportan RTSP.

RTP tiene una parte de control denominada RTP Control Protocol (RTCP).

Introducción

(18)

¿Qué significa Tiempo Real?

Los procesos de tiempo real son aquellos en los que su resultado no sólo dependen de si es el correcto o no, si no también el tiempo que tarda el resultado en ser transmitido.

IMPORTANTE

RTP no garantiza que un envío llegue a tiempo.

Esto es porque RTP no proporciona por él mismo ningún mecanismo que asegure el reparto a tiempo o garantice una determinada calidad de servicio. Todo esto recae en servicios de capas inferiores (UDP, TCP, RSVP, …).

Esto quedará más claro al ver la estructura de paquete.

Introducción

Tema 4

Comunicaciones Multimedia

36 Protocolos de transporte de tiempo real. RTP y RTCP

4.3

Razones de denominar a RTP como protocolo de Tiempo Real.

RTP proporciona un juego apropiado de funcionalidades apropiado para transportar contenido de tiempo real, como por ejemplo marcas de tiempo, mecanismo de control de sincronismo de diferentes flujos multimedia observando aspectos de temporización.

Además RTP no está completo en su especificación, es tan sólo un marco de trabajo a partir del cual se deben diseñar y detallar como son los formatos de la información a transportar (payload format) y como comportarse.

Los tipos de payload más conocidos provienen de estándares y son, por ejemplo, H.261, JPEG o MPEG Video.

(19)

Universidad de Jaén E. P. S. de Linares RTP payload:Son los datos transportados en un paquete RTP, por ejemplo las muestras de audio o video comprimido. El formato de cada payload queda fuera de la RFC del RTP y son especificados en documentos aparte como la RFC 3016 (RTP Payload Format for MPEG-4 Audio/Visual Streams)

RTP media type:Un tipo de medio RTP es una colección de tipos de payload que pueden ser transportados en una sola sesión de RTP. El Perfil RTP asigna los tipos de medios RTP a los tipos de payload RTP.

Multimedia session:Un conjunto de sesiones concurrentes RTP entre un grupo de participantes. Por ejemplo, una videoconferencia (la cual es una sesión multimedia) puede contener una sesión RTP de audio y otra sesión RTP de vídeo.

Definiciones

Tema 4

Comunicaciones Multimedia

38 Protocolos de transporte de tiempo real. RTP y RTCP

4.3

Synchronization source (SSRC):La fuente de un flujo de paquetes RTP, identificada con 32 bits (SSRC identifier) que se envía en la cabecera RTP y que nada depende de la dirección de red. Todos los paquetes de la Fuente de Sincronización forman parte de la misma temporización y espacio de números de secuencia, de tal manera un receptor agrupa los paquetes siguiendo el SSRC para su reproducción. Una Fuente de Sincronización puede cambiar el formato de los datos con el tiempo.

El identificador SSRC es un valor elegido aleatoriamente que pretende ser único dentro de una sesión RTP. Un participante no necesita usar el mismo identificador SSRC para todas la sesiones RTP en una sesión multimedia; es RTCP el que asocia los SSRC.

Si una fuente genera múltiples streams en una sesión RTP cada una debe tener un SSRC diferente (por ejemplo varias videocámaras)

(20)

Universidad de Jaén E. P. S. de Linares Contributing source (CSRC):Es una fuente de un flujo de paquetes RTP que ha contribuido a un flujo combinado producido por un mezclador RTP (mixer). El mezclador inserta una lista de identificadores SSRC de las fuentes que han contribuido a la generación de un paquete en particular en la cabecera de dicho paquete RTP. A esta lista se la denomina lista CSRC.

Monitor:

Una aplicación que recibe los paquetes RTCP enviados por los participantes

de una sesión RTP, y en concreto los informes de recepción. Esta aplicación usando

esta información estima la calidad actual del servicio por monitorización distribuida,

diagnósticos de fallos y estadísticas a largo plazo. Los monitores pueden ser

aplicaciones aparte que no envíen ningún paquete RTP o RTCP.

Definiciones

Tema 4

Comunicaciones Multimedia

40 Protocolos de transporte de tiempo real. RTP y RTCP

4.3

RTP session:Es una asociación entre un conjunto de participantes comunicándose usando RTP. Un participante puede verse involucrado en múltiples sesiones al mimo tiempo.

En una sesión multimedia, cada medio es típicamente transportado por una sesión RTP diferente con sus propios paquetes RTCP a menos que la codificación multiplexe múltiples tipos de medio en un solo stream.

La forma de distinguir las sesiones es usando diferentes pares de direcciones de transporte, lo cual implica una dirección de red y dos puertos de transporte (uno para RTP y otro para RTCP), además cada sesión mantiene un espacio diferente de identificadores SSRC.

El conjunto de participantes en una sesión RTP lo forman aquellos que puede recibir paquetes RTP con un determinado identificador RTP o paquetes RTCP con un CSRC concreto.

(21)

Universidad de Jaén E. P. S. de Linares La estructura de un paquete RTP es la siguiente.

Estructura de un paquete RTP

Los contenidos en tiempo real a transmitir forma el “RTP payload”. LA cabecera contiene información acerca de payload (fuente, tamaño, tipo de codificación, etc.)

Sin embargo los paquetes RTP no se envían por sí solos sobre la red (sobre IP), sino que se usa UDP como protocolo de transporte auxiliar.

CABECERA IP CABECERA UDP CABECERA RTP PAYLOAD RTP

Tema 4

Comunicaciones Multimedia

42 Protocolos de transporte de tiempo real. RTP y RTCP

4.3

(22)

Universidad de Jaén E. P. S. de Linares Version (V):2 bits

Este campo indentifica la versión de RTP. Actualmente es 2 desde la RFC 1889.

Padding (P):1 bit

Si este bit es uno, el paquete contiene uno o más octetos de relleno al final que no son parte del playload. El último octeto del relleno contiene la cuenta de cuantos octetos de relleno deben ser ignorados. El relleno puede ser necesario para algunos algoritmos de encriptación con tamaño de bloque fijo o para enviar varios paquetes RTP en unidades de datos de protocolos de capas inferiores.

Extension (X):1 bit

Si este bit está activo, la parte de cabecera fija estará seguida de exactamente una cabecera de extensión. Cabecera de extensión: tipo (16 bits) + longitud extensión (16 bits) + datos (max 64 Kbytes).

Estructura de la cabecera de RTP

Tema 4

Comunicaciones Multimedia

44 Protocolos de transporte de tiempo real. RTP y RTCP

4.3

CSRC count (CC):4 bits

Contiene el número de identificadores CSRC que siguen a la cabecera fija.

Marker (M):1 bit

Se usa por aplicaciones específicas para servir a un propósito particular de las mismas.

Payload type (PT):7 bits

Identifica el formato (codificación) del payload RTP y determina su interpretación por la aplicación. Este campo no está concebido para multiplexar diferentes tipos de medios.

Sequence number:16 bits

El número de secuencia se incrementa en uno en cada paquete RTP enviado, y puede ser usado para detectar pérdida o desorden de paquetes por el receptor. El número de secuencia inicial es aleatorio (o mejor dicho impredecible).

(23)

Timestamp:

32 bits

Refleja el instante de muestreo del primer octeto en el paquete de datos RTP. El

momento de muestreo debe ser derivado de un reloj que se incremente

monotónicamente y linealmente para permitir sincronización y calculos del jitter.

SSRC:

32 bits

El campo SSRC identifica a la fuente de sincronización. Este identificador es elegido

aleatoriamente, con el propósito de que dos fuentes de sincronización en la misma

sesión RTP no tengan el mismo identificador SSRC.

Estructura de la cabecera de RTP

Tema 4

Comunicaciones Multimedia

46 Protocolos de transporte de tiempo real. RTP y RTCP

4.3

CSRC list:

0 a 15 identificadores, 32 bits cada uno

La lista de CSRC identifica cada una de las fuentes que han contribuido en el payload

que contiene ese paquete en concreto. El número de identificadores lo dal el campo

CSRC Count. SI hay más de 15 fuentes contribuyentes, sólo 15 pueden ser

identificadas. Los CSRC son insertados por los mezcladores, usando los SSRC de las

fuentes contribuyentes.

(24)

RTP puede ser usado para diferentes tipos de aplicaciones multimedia de tiempo real

con las que se da cobertura a una amplio espectro de posibilidades en Internet.

Conferencia de Audio Simple Multicast

Conferencia de Audio y Video.

Mezcladores y Traductores.

Codificación Escalable

Aplicaciones de RTP

Tema 4

Comunicaciones Multimedia

48 Protocolos de transporte de tiempo real. RTP y RTCP

4.3

Conferencia de Audio Simple Multicast

Inicialmente el propietario de la conferencia a través de algún mecanismo (SDP y SIP), obtiene las dirección del grupo multicast y el par de puertos. Un puerto se usa para los datos de audio y el otro para los paquetes de control (RTCP).

La información de dirección y puerto se distribuye entre los participantes. Si se desea privacidad, la información de audio y los paquetes de control pueden ser encriptados, siendo necesario en tal caso la generación y/o distribución de una clave.

Cada participante envía la información de audio en pequeños fragmentos o paquetes cuyo formato se verá en apartados posteriores. Además cada participante envía periódicamente (multicast) un informe de recepción usando RTCP al puerto de control para ayudar a monitorizar la calidad de la transmisión y detectar la actividad de los participantes.

(25)

Conferencia de Audio y Video.

Si se quiere usar tanto audio como video en la conferencia, ambos deben ser transportados en sesiones RTP diferentes y cada una con sus paquetes RTCP, enviándose para cada sesión a un par diferente de puertos UDP y/o direcciones multicast.

Se usa un nombre canónico, CNAME, por cada participante individual para conjuntar las sesiones de audio y video.

Como ventaja de esta separación, es que es posible conectarse a una conferencia multimedia y no tener que adscribirse obligatoriamente a todo el contenido, si no que se puede recibir sólo el audio y no el video, ya sea por motivos operativos (ancho de banda, capacidad de proceso, audio en varios idiomas) o meramente personales (una persona ciega asistiendo a una conferencia).

Aplicaciones de RTP

Tema 4

Comunicaciones Multimedia

50 Protocolos de transporte de tiempo real. RTP y RTCP

4.3

Mezcladores y Traductores.

Sería un error asumir que todos los extremos de una conferencia quieren o soportan el mismo formato de contenidos multimedia. Aunque muchos de los formatos usados sean estándares la necesidades de cada participante pueden ser diferentes, además la heterogeneidad de la red, puede hacer inviable ciertos tipos de formatos en determinados momentos o partes de la misma.

Es por esto que RTP proporciona los mezcladores (mixers) y los traductores (translators) para aquellos usuarios que tienen conexiones con diferentes anchos de banda o que trabajan detrás de firewalls y no soportan el paso de paquetes IP.

(26)

Mezcladores en RTP (Mixers)

Es bastante probable que todos los participantes de una conferencia no tengan una conexión a Internet de la misma velocidad, así que surge el problema de como tomar parte en ella simultáneamente.

La solución más fácil a priori es la de trabajar con el ancho de banda menor, pero eso reduciría la calidad de aquellos que pueden soportar y/o desean una calidad alta del audio.

Una solución más apropiada es el uso de una especie de multiplexor a nivel de RTP denominado mezclador. Los mezcladores re-sincronizan los paquetes entrantes para adaptar la salida a régimen del menor ancho de banda, re-codificando si es preciso.

Aplicaciones de RTP

Tema 4

Comunicaciones Multimedia

52 Protocolos de transporte de tiempo real. RTP y RTCP

4.3

Mezcladores en RTP (Mixers)

Los mezcladores ponen su propia identificación SSRC como la fuente de las paquetes y ponen las fuentes contribuyentes en campos CSRC.

Otro uso de los mezcladores es agrupar imágenes de video de diferentes fuentes para generar una única imagen compuesta de todas ellas.

(27)

Traductores RTP (Translators)

Un problema posible es cuando los participantes de una conferencia están detrás de un firewall que no permite el paso de paquetes IP que contengan mensajes RTP. Es en este caso cuando se usan los traductores.

Para resolver esto se instalan dos traductores, uno a cada lado del firewall. El que se encuentra fuera del área restringida recibe todo el tráfico multicast o prohibido y lo pasa a través del firewall hasta el otro traductor usando un túnel seguro. El traductor dentro de la zona protegida extrae del túnel la información RTP protegida y la reenvía a la red interna con las mismas características que tenían a la entrada del mismo (multicast, unicast, ….)

Aplicaciones de RTP

Tema 4

Comunicaciones Multimedia

54 Protocolos de transporte de tiempo real. RTP y RTCP

4.3

Traductores RTP (Translators)

Los traductores no cambian los campos SSRC o CSRC como los mezcladores.

Los traductores pueden ser usados para otros propósitos, como interconectar host IP/UDP con host ST-II

(28)

Codificación Escalable

Las aplicaciones multimedia debería de ser capaces de ajustar la velocidad de transmisión para adaptarse a la capacidad del receptor o al ancho de banda disponible en la red, para evitar la congestión o sobreponerse a ella.

Muchas implementaciones dejan esta responsabilidad de adaptarse a al fuente en el lado de la fuente. Esto no funciona bien en el caso de transmisiones multicast debido a los heterogéneos requisitos de ancho de banda de los receptores y no es una buena solución que por un enlace de baja velocidad todos los demás usuarios vean reducida la calidad, aun teniendo ancho de banda disponible.

Aplicaciones de RTP

Tema 4

Comunicaciones Multimedia

56 Protocolos de transporte de tiempo real. RTP y RTCP

4.3

Codificación Escalable

La solución de la adaptación de ancho de banda es colocarla en los receptores combinándola con un sistema de envío por capas con una codificación escalable.

En el contexto de RTP sobre IP multicast, una fuente puede dividir en varias sesiones RTP una señal estructurada jerárquicamente en capas, y enviadas a su correspondiente grupo multicast.

De esa manera los usuarios pueden adaptarse a la heterogeneidad de ancho de banda de la red uniéndose a unos grupos multicast u otros.

(29)

Universidad de Jaén E. P. S. de Linares Como se ha comentado el aspecto fundamental de RTP es que aporta suficientes información a los receptores para poder mantener la adecuada sincronización de los contenidos multimedia de tiempo real por él transportados. Para esto el receptor necesita tres elementos claves:

La fuente de sincronización. Los paquetes ordenados.

El instante de muestreo de dichos paquetes.

Los tres valores los consigue de los campos de la cabecera.

Synchronization Source (SSRC) Sequence Number

Timestamp

Sincronización con RTP

Tema 4

Comunicaciones Multimedia

58 Protocolos de transporte de tiempo real. RTP y RTCP

4.3

Synchronization Source (SSRC)

Un receptor puede estar recibiendo datos desde varias fuentes. Por lo tanto, para un adecuado funcionamiento necesita identificar la fuente de cada paquete individualmente. Esto es posible leyendo el campo SSRC.

Número de secuencia (Sequence Number)

Pero no es sólo necesario identificar la fuente, el orden es importante también. El número de secuencia se incrementa uno a uno por cada paquete RTP enviado, y puede ser usado por el receptor para detectar pérdida de paquetes y para restaurar la secuencia de los mismos. Estas pérdidas o desordenación en el orden de entrega son debidas fundamentalmente a problemas en la red.

(30)

Universidad de Jaén E. P. S. de Linares Marca de tiempo (Timestamp)

En la distribución de contenidos multimedia no es sólo importante el orden de los paquetes, si no también el instante de muestreo de cada paquete individualmente.

Varios paquetes RTP consecutivos pueden tener timestamps iguales si ellos son generados a la vez, por ejemplo, si pertenecen al mismo frame de video.

Paquetes RTP consecutivos pueden contener timestamps que no son monotónicos si los datos no son transmitidos en el orden que fueron muestreados, como en el caso de frames de video MPEG interpolado (sin embargo el número de secuencia de los paquetes transmitidos permanece monotónico) Por lo que el número de secuencia no es necesario para la sincronización.

Además, el audio y el video de una sesión se transmite por canales separados, usándose el timestamp para sincronizarlos.

Sincronización con RTP

Tema 4

Comunicaciones Multimedia

60 Protocolos de transporte de tiempo real. RTP y RTCP

4.3

RTP es un protocolo marco que está deliberadamente incompleto. En determinadas estructuras no es estricto y puede ser modificado para ajustarse a determinadas aplicaciones.

RTP está pensado para ser “maleable” para proporcionar una funcionalidad adecuada. Esta característica se conoce como Marco de Nivel de Aplicación (Application Level Framing) y es un aspecto importante de RTP.

De esta manera se necesitan de nuevos documentos que especifiquen los perfiles de funcionamiento de RTP concretos para aplicaciones concretas. Así, los participantes en una sesión RTP deberían acordar estos formatos comunes. Para llevar esto a cabo, en la cabecera RTP existen diversos campos que pueden ser modificados de acuerdo con una aplicación específica.

Marco de Nivel de Aplicación (Application Level Framing)

(31)

Universidad de Jaén E. P. S. de Linares El bit de extensión puede activarse para indicar que la cabecera fija está seguida por, exactamente, otra cabecera de extensión. Estos nuevos campos pueden llevar nueva y útil información para la aplicación que los use.

Además, la interpretación del bit marker es dependiente del perfil. Está pensado para permitir eventos significativos tales como límites de secuencias en un flujo de paquetes. Un perfil puede definir bit marker adicionales o especificar que no hay bit marker cambiando el número de bits en al campo de tipo de payload.

Un perfil también puede especificar un mapeado estático por defecto de códigos de tipos de payloads con formatos de payload.

Marco de Nivel de Aplicación (Application Level Framing)

Tema 4

Comunicaciones Multimedia

62 Protocolos de transporte de tiempo real. RTP y RTCP

4.3

¿Qué es RTCP?

El protocolo RTCP se basa en la transmisión periódica de paquetes de control a todos los participantes de una sesión, usando el mismo mecanismo que los paquetes de datos.

Funciones de RTCP

Proporcionar una realimentación periódica de información sobre: Calidad de la distribución de datos,

Identificación de participantes, Descripción de fuentes,

Notificaciones en los cambios de adscripción a sesiones Información necesaria para sincronizar los stream multimedia.

RTP Control Protocol (RTCP)

(32)

Universidad de Jaén E. P. S. de Linares RTCP transporta un identificador persistente a nivel de transporte de una fuente RTP denominado nombre canónico o CNAME. El SSRC puede cambiar a lo largo del tiempo pero el CNAME permanece inalterado. Esto se usa para identificar a los participantes durante una sesión.

RTCP puede también contener información extra de cada participante, como por ejemplo el e-mail.

Al tener que enviar cada participante sus mensajes de control a todos los demás, cada uno puede independientemente observar el número de los mismos. Este número es usado para calcular el ratio de paquetes enviados. A más usuarios en una sesión, una fuente individual enviará los paquetes menos frecuentemente.

RTP Control Protocol (RTCP)

Tema 4

Comunicaciones Multimedia

64 Protocolos de transporte de tiempo real. RTP y RTCP

4.3

Tipos de paquetes RTCP

SR (Sender report): Para estadísticas de transmisión y recepción desde los participantes que son transmisores activos.

RR (Receiver report): Para informes de estadísticas de recepción de los participantes que no son transmisores activos.

SDES: Objetos de descripción de fuentes, incluyendo el CNAME.

BYE: Fin de participación.

APP: Funciones específicas de aplicaciones.

RTP Control Protocol (RTCP)

(33)

Universidad de Jaén E. P. S. de Linares En el apartado anterior se ha visto un breve esbozo de lo que es una sesión multimedia, concretamente como la define el protocolo RTP:

Un conjunto de sesiones concurrentes RTP entre un grupo de participantes. Por ejemplo, una videoconferencia (la cual es una sesión multimedia) puede contener una sesión RTP de audio y otra sesión RTP de vídeo.

Pero en general una sesión multimedia involucra más agentes que a un solo protocolo, medio o área. Una definición más completa sería:

Una sesión multimedia es el conjunto de acciones e información necesaria para que cualquier número de participantes puedan intercambiar entre ellos y de la manera acordada, cualquier tipo de contenido multimedia de una o más fuentes de datos.

Concepto

Tema 4

Comunicaciones Multimedia

66 El Concepto de Sesión Multimedia

4.4

Una sesión consta de diferentes fases, funciones y controles, de los cuales se encargan

diferentes protocolos, aunque una norma como la H.323. comprende todo lo que

involucra las conferencias multimedia dentro de la amplia gama de la norma.

Fases de una Sesión Multimedia:

Establecimiento de sesión.

Transferencia de contenidos (uno o varios flujos multimedia).

Liberación.

De estas tres fases, la de establecimiento es la más crucial, puesto que su ejecución es

fundamental para que la transferencia de contenidos sea satisfactoria.

(34)