E N D
PROTOCOLOS Sistemas sin control: HTTP: no hay control sobre la transmisión Sistemas con control sobre la transmisión: Control (nivel de aplicación) RTSP (Real Time Streaming Protocol) Otros protocolos propietarios Transporte de datos (nivel de transporte) RTP (Real-Time TransportProtocol) UDP TCP Otros protocolos propietarios
PROTOCOLOS: de sistemas con control sobre la transmisión Existen dos canales de comunicación entre los clientes y el servidor de streaming: Un canal para el control de la sesión (RTSP) Un canal para la transmisión de la información (RTP,
RTSP UDPPROTOCOLO RTSP Es un protocolo de nivel de aplicación Utiliza como protocolo de transporte el TCP Soporta las siguientes operaciones: Recepción de información multimedia desde un servidor multimedia. Un cliente puede solicitar que el servidor le transmita información Solicitar la participación de un servidor multimedia en una conferencia Añadir un flujo multimedia a una presentación ya existente IP TCP RTSP UDP
PROTOCOLO RTSP • Es un protocolo que establece y controla uno o varios flujos sincronizados de información multimedia continua como audio y vídeo # Actúa como un control remoto de los servidores multimedia
PROTOCOLO RTSP Difiere en ciertas cuestiones importantes con HTTP: RTSP es un protocolo con estado a diferencia de HTTP Tanto los servidores como los clientes RTSP pueden realizar peticiones Los datos son transportados mediante un protocolo diferente (datos transportados fuera de banda) La Request-URI siempre contiene una URI absoluta
PROTOCOLO RTSP Similitudes con HTTP: Formato de las peticiones/respuestas: Línea de petición + cabeceras + cuerpo Códigos de estado Mecanismos de seguridad Formato de la URL Negociación de los contenidos Su sintaxis es muy similar
RTSP: Propiedades Extensible: Es posible añadir nuevos métodos y parámetros Independiente del transporte: Los flujos de información van a ser transportados mediante otro protocolo Multiservidor: Cada flujo dentro de una presentación puede residir en un servidor distinto RTSP Flujo de vídeo Flujo de audio
RTSP: Estados RTSP mantiene el estado en el que se encuentra cada una de las conexiones que administra Inicial Listo setupteardown Emitiendo record teardown pause play
RTSP: Transiciones SETUP: hace que el servidor reserve los recursos necesarios para comenzar la transmisión del flujo y da comienzo la sesión RTSP PLAY y RECORD: inicia la transmisión de datos una vez los recursos han sido reservados con SETUP PAUSE: provoca una parada temporal en el envío de datos, pero no libera los recursos asociados a la sesión TEARDOWN: para la transmisión si el servidor está transmitiendo y libera los recursos asociados al flujo
RTSP: Petición Petición = Línea-de-petición *(Cabecera-general | Cabecera-de-la-petición | Cabecera-de-la-entidad) CRLF [Cuerpo-del-mensaje] Línea-de-petición = Método SP URI-solicitada SP Versión-RTSP CRLF URI = ("rtsp:" | "rtspu:") "//" host [":" port] [abs_path] Si no se especifica puerto se asume 554 Versión-RTSP = “RTSP” “/” 1*DIGITO “.” 1*DIGITO Localización dentro del servidor rtsp://media.example.com:554/twister
RTSP: Petición Método = “DESCRIBE” | “ANNOUNCE” | “GET-PARAMETER” | “OPTIONS” | “PAUSE” | “PLAY” | “RECORD” | “REDIRECT” | “SETUP” | “SET-PARAMENTER” | “TEARDOWN” | Otros-métodos-nuevos SP = Separador, espacio-en-blanco CRLF = Retorno-de-carro-y-nueva-línea Otros-métodos-nuevos = token Considerémoslos tipos de peticiones Unos hacen cambiar al servidor de estado y otros no
RTSP: Métodos Método Dirección Objeto Utilización TEARDOWN C → S Presentación / Flujo Obligatorio SET_PARAMETER C → S, S →C Presentación / Flujo Opcional SETUP C → S Flujo Obligatorio REDIRECT S → C Presentación / Flujo Opcional RECORD C → S Presentación / Flujo Opcional PLAY C → S Presentación / Flujo Obligatorio PAUSE C → S Presentación / Flujo Recomendado OPTIONS C → S, S →C Presentación / Flujo Obligatoria (S →C: opcional) GET_PARAMETER C → S, S →C Presentación / Flujo Opcional ANNOUNCE C → S, S →C Presentación / FlujoOpcional DESCRIBE C → S Presentación / Flujo Recomendada
RTSP: Métodos OPTIONS: Para saber las opciones soportadas por el cliente o por el servidor Se puede realizar cuando se quiera No cambia el estado del servidor C->S: OPTIONS * RTSP/1.0 CSeq: 1 Require: implicit-play Proxy-Require: gzipped-messages S->C: RTSP/1.0 200 OK CSeq: 1 Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE
RTSP: Métodos DESCRIBE: Solicita la descripción de la presentación o flujo utilizado la URL Puede considerarse la fase de inicialización Utiliza la cabecera Accept para indicar al servidor que tipos son admisibles El servidor contestará con una descripción sobre el recurso solicitado C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/1.0 CSeq: 312 Accept: application/sdp, application/rtsl, application/mheg
RTSP: Cabecera general general-header = Cache-Control; opcional, SETUP | Connection; obligatorio, todos | Date; opcional, todos | Via; opcional, todos Información sobre la comunicación
RTSP: Cabecera de la petición Cabecera-de-la-petición = Accept; tipos aceptados | Accept-Encoding; codificación aceptada | Accept-Language; lenguaje aceptado | Authorization | From | If-Modified-Since | Range | Referer | User-Agent Describe cuestiones sobre la petición y sobre características del cliente
RTSP: Respuesta Respuesta = Línea-de-estado *(Cabecera-general | Cabecera-de-larespuesta | Cabecera-de-la-entidad) CRLF (Cuerpo-del-mensaje) Línea-de-estado = Versión-de-RTSP SP Código-de-estado SP Explicación CRLF Versión-de-RTSP = “RTSP” “/” DIGITOS “.” DIGITOS Código-de-estado = 3DIGITOS Explicación = “frase explicativa acerca del código de estado” Cabecera-de-la-respuesta = localización | autentificación-en-elproxy | publico | reintentar-después | servidor | variación | autentificación-WWW Igual que el del HTTP
SDP SessionDescriptionProtocol Se utiliza para describir como son las sesiones cuando se están creando Utilizado por otros protocolos como: RTSP y SIP Permite definir cuestiones como: Descripción de la sesión: identificador, creador de la sesión, información variada de la sesión, etc Descripción temporal de la sesión Descripción de los flujos que componen la sesión: nombre del flujo, tipo de encriptación, etc
SDP Tiene campos obligatorios y otros opcionales Utiliza para la descripción una estructura: <elemento>=<valor> •Descripción de la sesión •v= sesión del protocolo •o= identificador del propietario o creador e identificador de la sesión •n= nombre de la sesión •i= información de la sesión (opcional) •u= identificador universal del recurso (opcional) •b= información sobre el ancho de banda (opcional) •K= clave de encriptación (opcional) •Descripción temporal •t= tiempo en que la sesión está activa •r= número de repeticiones
SDP •Descripción de un flujo •m= nombre del flujo y dirección de transporte •i= título del flujo (opcional) •c= información sobre la conexión (opcional) •b= información sobre el ancho de banda (opcional) •k= clave de encriptación (opcional) •a= cero o más líneas de atributos del flujo o= <nombreUsuario> <identificadorSesión> <versión> <tipoDeRed> <tipo de dirección> <dirección> o= - 2890844526 2890842807 IN IP4 192.16.24.202
El PROTOCOLO RTP Real Time Protocol Es un protocolo doble. Formado por: RTP propiamente dicho RTCP (Real Time Control Protocol) Protocolo de control asociado Trabaja sobre UDP Tiene características especiales para el trabajo con sistemas de tiempo real Números de secuencia y marcas de tiempo
¿QUÉ NO HACE RTP? No garantiza el envío ni que los paquetes lleguen fuera de orden No proporciona mecanismos para el envío a tiempo No garantiza la calidad de servicio
DISPOSITIVOS MEZCLADORES RTP permite la utilización de dispositivos denominados mezcladores Es un sistema intermedio que recibe paquetes de una o varias fuentes Combina los paquetes que recibe y genera nuevos paquetes RTP Normalmente necesitará hacer ajustes en los números de secuencia y marcas de tiempo La fuente de los nuevos paquetes será el mezclador (SSRC)
DISPOSITIVOS MEZCLADORES La lista de fuentes contribuyentes serán las fuentes de donde recibe los paquetes (CSRC ContributingSource)
PROCOTOLO DE CONTROL RTCP RTCP implica la transmisión periódica de paquetes de control a todos los participantes en una sesión La función principal es proporcionar mecanismos de realimentación para informar sobre la calidad en la distribución de los datos Esta información se puede utilizar: Para diagnosticar fallos en la distribución Para construir codificadores adaptables (SureStream RealNetworks)
PROTOCOLO DE CONTROL RTCP El RTCP aporta un identificador para la capa de transporte denominado identificador canónico CNAME (Canonical Name) Se utiliza para identificar a cada participante
PAQUETES RTCP Informe del emisor (IE): distribuye las estadísticas de emisión y de recepción de los emisores activos (los emisores también pueden ser receptores) Información del receptor (IR): distribuye las estadísticas de recepción de los participantes que no sean emisores activos Descripción de la fuente (DESF): proporciona información para describir la fuente. Por ejemplo mediante: el CNAME, el nombre, el número de teléfono, la localización y la versión de las herramientas de aplicación PAQUETES RTCP BYE: indica el final de la participación de un emisor APP: esta paquete se utiliza para transportar información específica de las diferentes aplicaciones que pueden utilizar el protocolos RTP
FORMATO DE LOS PAQUETES Los paquetes IE proporcionan un informe del emisor y varios del receptor Informe del Emisor: Referencia de reloj dada la marca de tiempo dada por el protocolo de temporización de red, NTP (Network Time Protocol). Número de segundos desde las 0 horas del 1 de enero de 1990 El mismo instante temporal que la marca NTP pero utilizando el reloj utilizado para generar las marcas de tiempo RTP Esta correspondencia se puede utilizar para realizar la correspondencia intra-media e inter-media Número de paquetes transmitidos Total de bytes de carga útil transmitidos desde que comenzó a transmitir FORMATO DE LOS PAQUETES Informe del receptor: Proporciona para cada una de las fuentes de sincronización los siguientes datos: Fracción de paquetes perdidos desde que se envió el anterior IE o IR Número acumulado de paquetes perdidos desde el comienzo de la recepción Número mayor de secuencia extendida que se haya recibido Dispersión temporal entre las recepciones (jitter) Última marca de tiempo IE Retardo desde el último IE Los paquetes IR son iguales que los IE pero sin el informe del emisor