Redes Multimedia 2012 II

Redes Multimedia
Tomado de: Kurose J., ross K. Computer Networking: A Top Down Approach.
7: Multimedia Networking
7-1
Multimedia y calidad de servicio (QoS): Qu es?

Aplicaciones multimedia: audio y video via red (continuous media)
QoS
La red prove a las aplicaciones un nivel de rendimiento necesario para que estas funcionen
7: Multimedia Networking 7-2
Objetivos
Principios Clasificar las aplicaciones multimedia Identificar los servicios de red que necesitan las aplicaciones Hacer el mejor servicio de mejor esfuerzo Mecanismos para proveer QoS Protocolos y Arquitecturas Protocolos especificos para usar en una red de mejor esfuerzo Arquitecturas para QoS
7-3
Aplicaciones multimedia de red
7-4
Aplicaciones multimedia (MM) de red

Clases de aplicaciones MM: 1) Flujo de audio y video almacenado (Streaming stored audio and video) 2) Flujo de audio y video en vivo (Streaming live audio and video) 3) Audio y video interactivo en tiempo real (Real-time interactive audio and video) Jitter es la variabilidad del retardo de paquetes dentro del mismo flujo de paquetes Caractersticas fundamentales: Tpicamente sensibles al retardo

Retardo extremo a extremo jitter de retardo
Pero tolerante a prdidas:
prdidas espordicas causan fallos menores La anttesis de datos, que no son tolerantes a prdidas pero si tolerantes al retardo
7-5
Flujo Multimedia Almacenado
Flujo: Medio almacenado en el origen Se transmite al cliente Flujo: reproduccin en el cliente comienza antes que lleguen todos los datos
Restricciones de tiempo para datos aun por
transmitir: llegar a tiempo para reproduccin

Flujo Multimedia Almacenado: Qu es?
1. video grabado
2. video enviado retardo de red
3. video recibido, Reproducido en el cliente tiempo
flujo: en este momento, el cliente reproduce las primeras partes del video, mientras que el servidor aun envia las partes finales del video
Flujo Multimedia Almacenado: Interactividad
Funcionalidad VCR: el cliente puede pausar,
rebobinar, adelantar, push slider bar Retardo inicial de 10s OK 1-2s hasta que orden se ejecute OK Se suele usar RTSP
Restricciones de tiempo para datos aun por
transmitir: llegar a tiempo para reproducirse

RTSP - Real Time Streaming Protocol
Flujo Multimedia en Vivo

Ejemplos: Talk show de radio por internet (Internet radio talk show) Eventos deportivos en vivo Flujo Buffer de reproduccin La reproduccin puede retrasarse dcimas de segundo despues de su transmisin Aun tiene restricciones de tiempo Interactividad Es imposible adelantar Es posible pausar y rebobinar
Multimedia de tiempo real, Interactivo
Aplicaciones: telefona IP, video
conferencia, mundos interactivos distribuidos Requerimientos de retardo extremo a extremo: audio: < 150 ms delay bueno, < 400 msec OK
Incluye retardos de red y nivel de aplicacin (paquetizacin) Retardos ms grandes notorios, interactividad reducida
Inicializacin de sesin
Cmo anuncia el destinatario su direccin IP, nmero de puerto, algoritmo de codificacin?

Multimedia sobre la Internet de hoy

TCP/UDP/IP*: servicio de mejor esfuerzo
NO brinda garantias de retardo o prdida
Pero Ud. dijo que las plicaciones multimedia ? requieren QoS y niveles de desempeo ? Para ser efectivas! ?
Las aplicaciones multimedia de Internet actual usan tecnicas del nivel de aplicacin para mitigar (lo mejor posible) los efectos del retardo y la prdida
* y RTSP/IP
Cmo debe cambiar Internet para soportar mejor multimedia?

Filsofia de Servicios Integrados (Integrated services): Cambios fundamentales en Internet para que las apps puedan reservar ancho de banda extremo-a-extremo Requiere software nuevo y complejo en hosts y enrutadores Liberalismo (Laissez-faire) Sin grandes cambios Ms ancho de banda cuando se necesita Distribucin de contenidos, multicast de capa de aplicacion
Filosofia de Servicios Diferenciados (DiffServ): Menores cambios a la infraestructura de Internet, proveyendo a la vez servicios de 1ra y 2da clase.
Qu opina?
Capa de aplicacin
Algunas palabras sobre la compresin de audio

Seal analgica Ejemplo: 8,000 muestras/s,
muestreada a tasa constante

telefono: 8,000 muestras/s CD de musica: 44,100 muestras/s
256 valores cuantizados --> 64,000 bps El receptor convierte de vuelta a una seal analgica:
Cada muestra se cuantiza o
Cierta reduccin de calidad
redondea
ejm., 28=256 posibles valores de cuantizacin
Cada valor cuantizado se
representa por bits
Tasas de ejemplo CD: 1.411 Mbps MP3: 96, 128, 160 kbps Telefona Internet: 5.3 - 13 kbps
8 bits para 256 valores
Algunas palabras sobre la compresin de video

Video es una secuencia de
Ejemplos:
MPEG 1 (CD-ROM) 1.5 Mbps MPEG2 (DVD) 3-6 Mbps MPEG4 (frecuentemente
imgenes mostradas a tasa constante
e.g. 24 imgenes/s
Una imagen digital es un
arreglo de pixels Cada pixel se representa por bits Redundancia
usado en Internet, < 1 Mbps)
espacial temporal
7-14
Flujo de audio y video almacenado
7-15
Flujo de Multimedia Almacenado

Tcnicas de flujo de nivel de aplicacin para obtener lo mejor del servicio de mejor esfuerzo: buffering en el lado del cliente Uso de UDP versus TCP Codificacin mltiple de multimedia
Aplicacin Media Player

Remocin de jitter descompresin Disimulacin de errores Interfaz grfica de usuario con
controles para interactividad
7-16
Multimedia Internet: el enfoque ms simple
audio o video almacenado en un archivo Archivos transferidos como objetos
HTTP Recibido en su totalidad en el cliente luego pasado al reproductor
audio, video no son transmitidos como flujo: retardos largos hasta su reproduccin!
Multimedia Internet : enfoque de flujo
El browser recupera (GET) el metafile 2. El browser lanza el reproductor, pasandole el metafile 3. El reproductor contacta al servidor y el servidor envia el flujo de audio/video al reproductor
1.
Enviando flujo desde un servidor de flujo
Esta arquitectura permite protocolos no-HTTP entre el servidor y el
reproductor de medios Tambien puede usar UDP en vez de TCP.
7-19
Transmisin de flujo Multimedia: Buffering en el cliente

transmisin de video a tasa de bits constante retardo de red variable Recepcin de video en el cliente
buffered video
reproduccin de video en el cliente a tasa de bit constante
Retardo de reproduccin En el cliente
time
Buffering en el cliente, retardo de reproduccin
compensan el retardo de red y de fluctuacin (jitter)

Transmisin de flujo Multimedia: Buffering en el cliente
variable fill rate, x(t)
constant drain rate, d
buffered video
Buffering en el cliente, retardo de reproduccin
compensan el retardo de red y de fluctuacin (jitter)

Transmisin de flujo Multimedia: UDP o TCP?

UDP
El servidor envia a una tasa apropiada para el cliente (ajeno al
congestionamiento de red!) Tasa de envio frecuente = tasa de codificacin = tasa constante Entonces, tasa de llenado = tasa constante prdida de paquetes retardos de reproduccin cortos (2-5 segundos) para compensar el retardo de fluctuacin de red Recuperacin de errores: si el tiempo lo permite
TCP
Enviar a la tasa mxima posible bajo TCP
Tasa de llenado flucta debido a el control de congestionamiento TCP Retardos de reproduccin largos: tasa de entrega TCP suave HTTP/TCP pasa ms fcilmente a travs de firewalls
7-22
Transmisin de flujo Multimedia: tasa(s) de cliente

Codificacin a 1.5 Mbps
Codificacin a 28.8 Kbps
P: Cmo manejar las capacidades diferentes de tasas de recepcin de los clientes? 28.8 Kbps dialup 100Mbps Ethernet R: el servidor almacena mltiples copias de video, codificados a diferentes tasas.
Puede transmitir el mejor para la conexin del cliente.
Control de usuario de medios de flujo: RTSP*

HTTP No fue pensado para contenido multimedia No tiene comandos para adelantar, etc. RTSP: RFC 2326 Protocolo cliente/servidor de capa de aplicacin. Permite al usuario controlar: rebobinado, adelantado, pausa, reiniciar, etc
* Real Time Streaming Protocol
Lo que no hace: No define como se encapsula el audio/video para su envio por la red. No restringe como se transportan los medios de flujo; pueden transportarse sobre UDP o TCP No especifica la forma en que el reproductor de medios almacena en buffer el audio/video
RTSP: control fuera de banda

FTP usa un canal de control fuera de banda: Un archivo se transfiere por una conexin TCP. La informacin de control (cambio de directorio, eliminacin de archivo, etc.) se envia por una conexin TCP separada. Los canales fuera de banda y en banda usan nmeros de puerto diferentes. Los mensajes RTSP tambien se envian fuera de banda: Los mensajes de control RTSP usan un nmero de puerto diferente al del flujo de medios: fuera de banda.
Puerto 554
El flujo de medios se considera
en banda.
Puerto 332
7-25
RTSP Ejemplo
Escenario:
Se envia metafile al navegador web El navegador lanza el reproductor El reproductor establece una conexin de control RTSP y una
conexin de datos al servidor de flujos
Servicio U-verse: el set top box se conecta a la red IP AT&T y es el host, con navegador y reproductor propietario para mltiples canales de musica y TV. Tambien acta como cable modem y gateway para acceder a Internet.
Metafile de ejemplo
<title>Twister</title> <session> <group language=en lipsync> <switch> <track type=audio e="PCMU/8000/1" src = "rtsp://audio.example.com/twister/audio.en/lofi"> <track type=audio e="DVI4/16000/2" pt="90 DVI4/8000/1" src="rtsp://audio.example.com/twister/audio.en/hifi"> </switch> <track type="video/jpeg" src="rtsp://video.example.com/twister/video"> </group> </session>
RTSP Operacin
Los encabezados de flujo de medios RTSP tienen un ID de flujo y una marca de tiempo
RTSP Ejemplo de intercambio

C: SETUP rtsp://audio.example.com/twister/audio RTSP/1.0 Transport: rtp/udp; compression; port=3056; mode=PLAY
S: RTSP/1.0 200 1 OK Session 4231

C: PLAY rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 Session: 4231 Range: npt=0C: PAUSE rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 Session: 4231 Range: npt=37 C: TEARDOWN rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 Session: 4231 S: 200 3 OK
MULTIMEDIA DE TIEMPO REAL: CASO DE ESTUDIO DE TELEFONIA IP
7-30
Aplicaciones interactivas de tiempo real

PC-2-PC phone Son proveidos por servicios de mensajeria instantnea
PC-2-phone
Dialpad
Se ver un ejemplo de telefona Internet PC 2 PC en detalle
Net2phone Videoconferencia con Webcams
7-31
Multimedia Interactiva: Telefonia Internet

Explicar la Telefona Internet a traves de un ejemplo
Audio del locutor: rafagas alternadas de conversacin y
periodos de silencio.
64 kbps durante rafagas de conversacin
pkts generados solo durante las rafagas de conversacin
Bloques de 20ms a 8000Bytes/s: datos de 160 bytes.
Se agrega un encabezado de capa de aplicacion a cada
bloque.
Bloque + encabezado se encapsulan en un segmento UDP. Durante las rafagas de conversacin un segmento UDP es
transmitido cada 20 ms.

Telefona Internet: Prdida de paquetes y retardo

Prdida de red: datagrama IP perdido por congestion en la
red (desbordamiento de buffer de enrutador) Prdida por retardo: datagrama IP llega muy tarde para reproducirse en el receptor
retardos: procesamiento y encolamiento en la red; retardos de sistema final (emisor, receptor) Retardo no percibido por un escucha humano : < 150ms Retardo aceptable pero no ideal: 150 a 400 ms Retardo inaceptable : > 400 ms Retardo mximo tolerable tpico: 400 ms
Tolerancia a prdidas: dependiendo de la codificacin de
voz, perdidas escondidas, se puede tolerar tasas de prdida de paquetes entre 1% y 10%.
Fluctuacin de retardo (Delay Jitter)

constant bit rate transmission variable network delay (jitter)
client reception
constant bit rate playout at client
buffered data
client playout delay

Considere los retardos entremo a extremo de dos paquetes
time
consecutivos: la diferencia puede ser mayor o menor a 20ms

Telefono Internet : retardo de reproduccin fijo

El receptor intenta reproducir cada bloque exactamente q
ms despues que el bloque fue generado. El bloque tiene un sello de tiempo t: reproducir bloque en t+q. El bloque llega despues de t+q: los datos llegan muy tarde para reproduccion, datos perdidos Compromiso for q: q grande: menor prdida de paquetes q pequeo: mejor experiencia de interactividad
7-35
Retardo de reproduccin fijo

El emisor genera paquetes cada 20ms durante rafagas de conversacin. Primer paquete recibido en el instante r Primer plan de reproduccin: comienza en p Segundo plan de reproduccin: comienza en p
packets
packets generated packets received
loss
playout schedule p' - r playout schedule p-r
time
r p p'
7-36
Retardo de reproduccin adaptivo, I

Objetivo: minimizar retardo de reproduccin, manteniendo baja la tasa de
prdida tarda. Estrategia : ajuste adaptivo de retardo de reproduccin:
Estimar retardo de red, ajustar retardo de reproduccin al inicio de cada rafaga de conversacin. Periodos de silencio comprimidos y estirados. Los bloques aun se reproducen cada 20ms durante rafagas de conversacin. t i marca de timepo del i - esimo paquete
ri El instatnte en que el paquete i es recibido por el receptor p i El instante en que el paquete i se reproduce en el receptor ri t i retardo de red para el i - esimo paquete d i Estimacin del retardo promedio de red despues de recibir el i - esimo paquete
Estimacin dinmica del retardo promedio en el receptor:
d i (1 u )d i 1 u( ri ti )
donde u es una constante preestablecida (e.g., u = .01).
Retardo de reproduccin adaptivo II

Tambien til para estimar la desviacin promedio del retardo, vi :
vi (1 u )vi 1 u | ri ti d i |
Los estimados di y vi se calculan para cada paquete recibido, aunque solo se usan al inicio de una rafaga de conversacin. Para el primer paquete en una rafaga de conversacin, el tiempo de reproduccin es:
pi ti d i Kvi
donde K es una constante positiva. El instante de reproduccin de los paquetes subsecuentes se calcula como un desplazamiento desde el instante en que el primer paquete se reprodujo. Sea: q p t
i i i
la longitud de tiempo desde que el primer paquete es generado hasta que es reproducido
Si elpaquete jtambien pertenece a la rafaga de conversacin, este se reproduce en el instante
p j t j qi
7-38
Retardo de reproduccin adaptivo III

Q: Cmo determina el receptor si un paquete es el primero en una rafaga de conversacin? Si no hay prdida, el receptor verifica los sellos de tiempo sucesivos.
Diferencia de sellos sucesivos > 20ms --> rafaga de conversacin comienza.
Con posible prdida, el receptor debe ver los sellos de
tiempo y los nmeros de secuencia.
Diferencia de sellos sucesivos > 20ms y nmeros de secuencia sin huecos --> rafaga de conversacin comienza.
7-39
Recuperacin de prdida de paquetes

forward error correction (FEC): El retardo de reproduccin esquema simple necesita ser fijados al tiempo Para cada grupo de n bloques que se necesita para recibir crear un bloque redundante todos los n+1 paquetes. calculado como la suma O Compromiso: excluyente de los bloques Incrementar n, menos originales. ancho de banda perdido Enviar n+1 bloques, subiendo Incrementar n, mayor la velocidad de transmisin retardo de reproduccin en un factor de 1/n. Incrementar n, mayor Se puede reconstruir los n probabilidad que 2 o mas bloques originales si hay bloques se pierdan como mucho un bloque perdido de los n+1 bloques
Recuperacin de prdida de paquetes (2)

2 esquema FEC piggyback flujo de menor calidad Enviar flujo de audio de menor resolucin como informacin redundante Por ejemplo, flujo PCM nominal a 64Kbps y flujo GSM redundante a 13Kbps Cuando no hay prdida consecutiva, el receptor puede ocultar la prdida Tambien puede adjuntar los bloques (n-1) y (n-2) de menor calidad
7-41
Recuperacin de prdida de paquetes(3)
Intercalado Los bloques se dividen en unidades ms pequeas Por ejemplo, 4 unidades de 5ms por bloque Un pqeute contiene pequeas unidades de diferentes bloques
Si un paquete se pierde, aun se tiene
la mayor parte de cada bloque No tiene la sobrecarga de redundancia Pero incrementa el retardo de reproducin
Resumen: Multimedia por Internet: bolsa de trucos

Hechos por el servidor y el cliente no por Internet
use UDP para evitar el (retardo) control de
congestionamiento TCP para trfico sensible al retardo

Retardo de reproduccin adaptivo en el cliente: para
compensar el retardo
Emparejar ancho de banda del flujo en el servidor para
ancho de banda cliente-a-servidor disponible

Escoger entre tasas de flujo pre-codificadas Tasa de codificacion dinmica en el servidor
Recuperacion de errores (sobre UDP) FEC, intercalado Retransmisiones, time permitting Ocultar errores: repetir datos cercanos
PROTOCOLOS PARA APLICACIONES INTERACTIVAS DE TIEMPO REAL: RTP,RTCP,SIP
7-44
Real-Time Protocol (RTP)

RTP especifica una RTP se ejecuta en los
estructura de paquete para paquetes que transportan datos de audio y video RFC 1889. Un paquete RTP provee

Identificacion del tipo de payload Numeracin de secuencia de paquetes Sello de tiempo
sistemas finales. Los paquetes RTP se encapsulan en segmentos UDP Interoperabilidad: si dos aplicaciones de telefonia por Internet usan RTP, estos pueden trabajar juntos
7-45
RTP corre sobre UDP

Las librerias RTP proporcionan una interface de capa de transporte que extiende UDP: nmeros de puerto, direcciones IP Identificacin del tipo de payload Numeracin de secuencia de paquetes Sellos de tiempo e.g., RTSP
7-46
RTP Ejemplo
El encabezado RPT indica Considere el envio de voz
a 64Kbps, codificada con PCM sobre RTP. La aplicacion recopila los datos codificados en bloques, e.g., cada 20ms = 160 bytes en un bloque. El bloque de audio junto con el encabezado RTP forman el paquete RTP, que es encapsulado en un segmento UDP.
el tipo de codificacin de audio en cada paquete
El emisor puede cambiar la codificacin durante una conferencia.
El encabezado RTP
tambien contiene los nmeros de secuencia y los sellos de tiempo

IP IP TCP UDP RTSP RTP Control Data Media Data
Sockets TCP y UDP

RTP y QoS
RTP no proporciona ningun mecanismo para asegurar la
entrega oportuna de datos o para proporcionar otras garantias de calidad de servicio. La encapsulacin RTP solo es visible en los sistemas finales: no es visible a los enrutadores intermedios.
Los enrutadores que proveen un servicio de mejor esfuerzo no hacen ningun esfuerzo especial para asegurar que los paquetes RTP arriben a su destino de manera oportuna
7-48
RTP Encabezado
Payload Type (7 bits): Indica el tipo de codificacion actualmente utilizada. Si el emisor cambia la codificacion en medi ode una conferencia, el emisor informa al receptor mediante este campo. Payload tipo 0, PCM mu-law, 64 kbps Payload tipo 3, GSM, 13 kbps Payload tipo 7, LPC, 2.4 kbps Payload tipo 26, Motion JPEG Payload tipo 31, H.261 Payload tipo 33, MPEG2 video
Sequence Number (16 bits): Se incrementa en 1 por cada paquete RTP enviado, y puede usarse para detectar paquetes perdidos y para restaurar la secuencia de paquetes.
Real-Time Control Protocol (RTCP)

Trabaja en conjunto con RTP. Cada participante en una Las estadsticas incluyen el
sesin RTP transmite periodicamente paquetes de control RTCP a todos los demas participantes Cada paquete RTCP contiene reportes del emisor y/o del receptor.
Las estadisticas reportadas son utilies para las aplicaciones
nmero de paquetes enviados, perdidos, la fluctuacin de llegada, etc. Se puede utilizar retroalimentacin para controlar el desempeo El emisor puede modificar sus transmisiones basados en la retroalimentacin. Se usa con IP-TV Multicasting
7-50
RTCP
- Para una sesin RTP tipicamente hay una nica direccion multicast. Todos los paquetes RTP y RTCP pertenecientes a la sesin usan la direccin multicast. - Los paquetes RTP y RTCP se distinguen unas de otras por el uso de numeros de puerto distintos - Para limitar el trfico, cada participante reduce su trfico RTCP a medida que el nmero de participantes en la conferencia aunmenta
7-51
RTCP Paquetes
Paquetes de reporte del receptor: Fraccin de paquetes perdidos, ultimo nmero de secuencia, fluctuacin promedio de arribo. Paquetes de reporte del emisor: SSRC del flujo RTP, el tiempo actual, el nmero de paquetes enviados y el nmero de bytes enviados. Paquetes de descripcion de origen: e-mail del emisor, nombre del emisor, SSRC del flujo RTP asociado. Proporciona mapeo entre el SSRC y el nombre del usuario/host.
7-52
Sincronizacin de flujos
RTCP puede sincronizar
Cada paquete de reporte RTCP del
diferentes flujos de medios dentro de una sesion RTP. Considere una aplicacin de videoconferencia para la cual cada emisor genera un flujo RTP para video y uno para audio. Sellos de tiempo en paquetes RTP ligados a los relojes de muestreo de audio y video
emisor contiene (para el paquete mas recientemente generado en el flujo RTP asociado):

Sello de tiempo del paquete RTP Tiempo de reloj actual cuando el paquete fue creado.
Los receptores pueden utilizar
esta asociacin para sincronizar la reproduccin del audio y video
No ligados al tiempo actual de reloj

RTCP - Escalamiento de ancho de banda

RTCP intenta limitar su
Los 75 Kbps se comparte
trfico al 5% del ancho de banda de la sesin. Eejmplo Suponga un emisor, enviando video a la tasa de 2Mbps. Luego RTCP intenta limitar su trfico a 100Kbps. RTCP da 75% de esta tasa a los receptores; el sobrante 25% al emisor.
equitativamente entre los receptores:
Con R receptores, cada receptor consigue enviar trfico RTCP a 75/R Kbps.
El emisor consigue enviar trfico
RTCP a 25 Kbps. Un participante determina el periodo de transmision de paquetes RTCP calculando el tamao de paquete promedio (durante la sesin entera) y dividiendolo por la tasa asignada.
SIP
Session Initiation Protocol Desarrollado por IETF
SIP visin a largo plazo Todas las llamadas telefnicas y las llamadas de videoconferencia se realizan via Internet La gente se identifica por nombres o emails, no por nmeros telefnicos. Se puede contactar al llamado, sin importar donde yerra, ni el tipo de dispositivo IP que este usando.
SIP Servicios
Establecer una llamada
Determinar la direcin IP
actual del llamado.

Provee mecanismos para que el llamador deje saber al llamado que este quiere establecer una llamada Provee mecanismos para que tanto el llamador como el llamado puedan acordar el tipo de medio y la codificacin Provee mecanismos para terminar la llamada.
Mapea un identificador nemotcnico a una direccin IP actual
Gestion de llamada Agregar nuevos flujos multimedia durante una llamada Cambiar la codificacin durante una llamada Invitar a otros Retener y transferir llamadas.
Estableciendo una llamada a una direccin IP conocida

Alice Bob
167.180.112.24 INVITE bob @193.64.2 10.89 c=IN IP4 16 7.180.112.2 4 m=audio 38 060 RTP/A VP 0
193.64.210.89
El mensaje SIP de invitacin de Alice indica su nmero de puerto y direccin IP. Indica la cadificacin en que prefiere recibir Alice (PCM uLaw)
port 5060
Bob's terminal rings
port 5060
200 OK .210.89 c=IN IP4 193.64 RTP/AVP 3 3 75 m=audio 48
El mensaje 200 OK de Bob indica su nro de puerto, direccin IP y la codificacin preferida (GSM)
Los mensajes SIP pueden enviarse sobre TCP o UDP; en este caso se enviaron sobre RTP/UDP. El puerto SIP por defecto es el 5060
ACK
port 5060
m Law audio
port 38060
GSM
port 48753
time
time
7-57
Estableciendo una llamada (mas)

Negociacin del Codec:
Supongamos que Bob no tiene el codificador PCM uLaw Bob responder con la respuesta 606 Not Acceptable y listar los codificadores que puede usar. Alice puede entonces enviar un nuevo mensaje INIVITE, notificando un codificador apropiado.
Rechazando la llamada
Bob puede rechazar con respuestas busy, gone, payment required, forbidden. El flujo multimedia puede enviarse sobre RTP o algun otro protocolo.
7-58
Traduccin de nombre y ubicacin de usuario

El llamador quiere llamar Los resultados pueden
al llamado, pero solo tiene su nombre o email. Necesita obtener la direccin IP del host actual del llamado:
basarse en:

El usuario es movil Protocolo DHCP El usuario tiene diferentes dispositivos IP (PC, PDA, etc.)
Momento del dia (trabajo, casa) El llamador (no queremos que el jefe nos llame a casa) Estado del llamado (llamadas enviadas al correo de voz cuando el llamado esta ocupado hablando con otro)
Servicio proveido por servidores SIP: Servidor de registros SIP Servidor proxy SIP
Registro SIP
Cuando Bob inicia un cliente SIP, el cliente envia un mensaje
SIP REGISTER al servidor de registro de Bob (funcin similar a la usada en mensajeria instantnea) Mensaje de registro:
REGISTER sip:domain.com SIP/2.0 Via: SIP/2.0/UDP 193.64.210.89 From: sip:bob@domain.com To: sip:bob@domain.com Expires: 3600
7-60
Proxy SIP
Alice envia un mensaje invite a su servidor proxy Contiene la direccin sip:bob@domain.com El proxy es responsible de enrutar los mensajes SIP al
llamado
Posiblemente a travs de mltiples proxies.
El llamado responde a travs del mismo grupo de proxies.
El proxy devuelve el mensaje de respueta SIP a Alice Contiene la direccin IP de Bob

Nota: un proxy es anlogo a un servidor DNS local.
7-61
Ejemplo:
Llamador jim@umass.edu con IP 217.123.56.89 Llama a keith@upenn.edu
(1) Jim envia un mensaje INVITE al proxy SIP unass. (2) El proxy reenvia la peticin al servidor de registro upenn. (3) El servidor upenn devuelve una respuesta de redireccin, indicando que debe intentar keith@eurecom.fr
SIP proxy umass.edu SIP registrar upenn.edu SIP registrar eurecom.fr
3 4 2
1 8
7 6
SIP client 217.123.56.89
SIP client 197.87.54.21
(4) El proxy umass envia INVITE al servidor de registro eurecom. (5) eurecom reenvia INVITE a 197.87.54.21, que ejecuta el cliente SIP de keith. (6-8) la respuesta SIP se envia de vuelta . (9)El flujo multimedia se envia directamente entre clientes. Nota: tambien un mensaje SIP ack, que no se muestra.
Comparacin con H.323

H.323 es otro protocolo de H.323 proviene de ITU (telefona). SIP proviene de IETF: adopta
sealizacin para audio y videoconferencia en tiempo real. H.323 es una suite completa de protocolos verticalmente integrados para conferencias multimedia: sealizacin, registro, control de acceso, transporte y codecs. SIP es un componente nico. Trabaja con RTP, pero no lo controla. Puede combinarse con otros protocolos y servicios
muchos de sus conceptos de HTTP. SIP tiene influencia Web, mientras que H.323 tiene ms influencia del sisetma de telefona convencional. SIP usa el principio KISS: Keep it simple stupid.
7-63
DISTRIBUCION MULTIMEDIA: REDES DE DISTRIBUCION DE CONTENIDOS
7-64
Redes de distribucin de contenidos (CDNs)

Replicacin de contenido
Es complicado transmitir archivos
Servidor de origen en Norteamerica
grandes (e.g. video) de un solo servidor en tiempo real Solucin: replicar contenido en cientos Nodo de distribucin CDN de servidores por toda Internet El contenido se descarga a servidores CDN antes de tiempo Al poner el contenido cerca del usuario se evita impedimentos (prdida, retardo) para el envio de contenidos sobre rutas largas Sevidor CDN Servidor CDN en Sudamerica Los servidores CDN se ubican Servidor CDN en Asia en Europa preferentemente en redes de acceso/borde
Redes de distribucin de contenidos (CDNs)

Replicacin de contenidos
Un cliente CDN (e.g., Akamai) es
Servidor de origen en Norteamerica
proveedor de contenidos (e.g., CNN) CDN replica contenido de clientes en servidores CDN. Cuando el proveedor actualiza contenido, CDN actualiza los servidores
Nodo de distribucin CDN
Sevidor CDN en Sudamerica
Servidor CDN en Europa
Servidor CDN en Asia
7-66
CDN Ejemplo
1 2
HTTP request for www.foo.com/sports/sports.html
Origin server
DNS query for www.cdn.com
CDNs authoritative DNS server

HTTP request for www.cdn.com/www.foo.com/sports/ruth.gif
Nearby CDN server
Servidor origen (www.foo.com) distribuye HTML reemplaza:

http://www.foo.com/sports.ruth.gif
con
http://www.cdn.com/www.foo.com/sports/ruth.gif
Compaia CDN (cdn.com) Distribuye archivos gif Usa su servidor DNS autoritario para enrutar peticiones de redireccin
Mas sobre CDNs

Peticiones de enrutamiento CDN crea un mapa, indicando las distancias desde ISPs hoja y nodos CDN Cuando llega una peticion a un servidor DNS autoritario:

El servidor determina el ISP del cual se origina la peticin Usa el mapa para determinar el mejor servidor CDN
Los nodos CDN crean una red superpuesta de capa de
aplicacion
7-68
MAS ALLA DEL MEJOR ESFUERZO
7-69
Mejorando QoS en redes IP

Hasta ahora: haciendo lo mejor del mejor esfuerzo Futuro: Internet de siguiente generacin con garantas QoS RSVP: sealizacin para reservacin de recursos Differentiated Services: garantas diferenciales Integrated Services: garantas estrictas Modelo simple para estudios de comparticin y congestin:
7-70
Principios para garantas QoS

Ejemplo: telfono IP de 1Mbps, conexin FTP de 1.5 Mbps. Rfaga FTP puede congestionar el enrutador y causar prdida de audio Es deseable priorizar el audio sobre FTP
Principio 1 Es necesario marcar los paquetes para que el router distinga entre diferentes clases, y nuevas politicas de enrutamiento para tratar los paquetes apropiadamente
Principios para garantas QoS (mas)

Qu pasa si las aplicaciones se comportan mal? (audio envia a
una tasa ms alta que la declarada)
Vigilancia: forzar a la fuente adherirse a la asignacin de ancho de banda
Marcar y vigilar en el borde de la red: Similar a UNI (User Network Interface) de ATM
Principio 2 Proveer proteccin (aislamiento) para una clase respecto de otras


Asignar ancho de banda fijo (no compartible) al flujo: uso
ineficiente de ancho de banda si el flujo no usa la asignacin
Principio 3 Al proveer aislamiento, es deseable usar los recursos de la forma ms eficiente posible

Verdad bsica: no se puede soportar demndas de trfico
mayores a la capacidad del enlace
Principio 4
Admisin de llamada: el flujo declara sus necesidades, la red puede bloquear una llamada (e.g. seal de ocupado) si no puede satisfacer los requerimientos
Resumen de principio QoS
Veamos los mecanismos paa conseguir esto .

MECANISMOS DE PLANIFICACION Y VIGILANCIA
7-76
Mecanismos de planificacin y vigilancia

Planificacin: seleccionar el siguiente paquete para enviar por
el enlace Planificacin FIFO: envio en orden de llegada a la cola
Poltica de descartado: si un paquete llega a una cola llena: a quin descartar? Tail drop: descartar paquete entrante Prioridad: descartar/retirar en base a prioridades Aleatorio: descartar/retirar aleatoriamente
7-77
Polticas de planificacin: mas

Planificacin por prioridades: transmitir el paquete en cola con ms alta prioridad Mltiples clases, con prioridades diferentes
La clase puede depender del marcado u otra informacin del encabezado, e.g. IP origen/destino, nro de puerto, etc.
7-78

Planificacin round robin: Mltiples clases Recorre cclicamente las colas de clases, atendiendo una de cada clase (si existe)
7-79

Encolamiento justo ponderado (Weighted Fair Queuing): Round Robin generalizado Cada clase obtiene una cantidad ponderada de servicio en cada ciclo
7-80
Mecanismos de vigilancia
Objetivo: limitar el trafico para que no exceda los parmetros
declarados Tres criterios comnmente usados: tasa promedio (largo plazo): Cuntos paquetes pueden enviarse por unidad de tiempo (a largo plazo)
Cuestin crucial: cul es la longitud de intervalo: 100 paquetes por segundo o 6000 paquetes por minuto tienen el mismo promedio!
Tasa pico: e.g., promedio de 6000 paquetes por minuto (ppm);
tasas pico de 1500 ppm Tamao de rfaga (Max.) : mximo numero de paquetes enviados consecutivamente (sin pausas)
7-81
Mecanismos de vigilancia
Cubeta de fichas: limitar el ingreso al tamao de rfaga y
tasa promedio especificado.
La cubeta puede retener b fichas Las fichas se generan a una tasa de R fichas/s, a menos que
la cubeta este llena Durante un intervalo de longitud t: el nmero de paquetes admitidos es menor o igual a (r t + b).
Mecanismos de vigilancia (mas)

La cubeta de fichas y WFQ se combinan para proveer un
limite superior garantizado de retardo, i.e., garanta QoS

Trfico
entrante Tamao de cubeta, b Tasa por flujo, R WFQ D = b/R
Tasa de fichas, r
max
7-83
SERVICIOS INTEGRADOS Y SERVICIOS DIFERENCIADOS
7-84
Servicios integrados IETF

Arquitectura para proveer garantas QoS en redes IP para
sesiones de aplicacion individual reservacin de recursos: los enrutadores mantienen informacin de estado de los recursos asignados (a la VC) y de los reqerimientos QoS Admite/rechaza peticiones nuevas de establecimiento de llamadas: Pregunta: Puede el nuevo flujo entrante ser admitido con garantias de desempeo sin violar las garantias QoS hechas a los flujos ya admitidos?
7-85
Intserv: escenario de garanta QoS

Reservacin de recursos Establecimiento de llamada, sealizacin (RSVP) Trfico, declaracin QoS Control de admisin por elemento
peticin/
respuesta
Planificacin sensible a QoS (e.g., WFQ)
7-86
Admisin de llamada
La sesin entrante debe :
Declarar sus requerimientos QoS
la QoS que se solicita Caracterizar el trfico que enviar a la red T-spec: define las caractersticas del trfico Protocolo de sealizacin: necesario para transportar Rspec y T-spec a los enrutadores (donde se requiere la reservacin) RSVP
R-spec: define
7-87
RSVP
7-88
Sealizacin en Internet
Reenvio sin conexin (sin estado) por los enrutadores IP Sin protocolo de sealizacin de red en el diseo IP inicial
Servicio de mejor esfuerzo
Nuevo requerimiento: reservar recursos en toda la ruta de
extremo a extremo (sistemas finales, enrutadores) para QoS para aplicaciones multimedia RSVP: Resource Reservation Protocol [RFC 2205]
permite a los usuarios comunicar sus requerimientos a la red de forma robusta y eficiente i.e., sealizacin !
Protocolo de sealizacin Internet anterior: ST-II [RFC 1819]

RSVP Objetivos de diseo

1.
2. 3. 4.
5.
6.
Acomodar receptores heterogneos (ancho de banda diferente en el trayecto) Acomodar aplicaciones diferentes con requerimientos de recursos diferentes Hacer del multicast un servicio de primera clase, con adaptacin a la membresa de grupos multicast Potenciar el enrutamiento multicast/unicast existente, con adaptacin a cambios en las rutas unicast y multicast subyascentes Controlar la sobrecarga de protocolo para crecer (en el peor caso) linealmente en # de receptores Diseo modular para tecnologias heterogneas subyascentes
RSVP: no
Especifica como se reservan los recursos
Mas bien: un mecanismo para comunicar necesidades Ese es trabajo de los protocolos de enrutamiento La sealizacin esta desacoplada del enrutamiento Separacin de los planos de control (signaling) y datos (forwarding)
Determina la ruta que tomarn los paquetes

Interacta con el reenvio de paquetes
7-91
RSVP: vision general de operacin

Emisores, receptor se unen a un grupo multicast Se hace fuera de RSVP Los emisores no necesitan unirse a grupo Sealizacin emisor-a-red Mensaje de ruta: hacer conocer la presencia del emisor a los enrutadores Remocin de trayecto: borrar el estado del rayecto de los enrutadores Sealizacin receptor-a-red Mensaje de reservacin: reservar recursos desde el emisor(es) al receptor Remocin de reservacin: remover las reservaciones del receptor Sealizacin red-a-sistema-final Error de trayecto Error de reservacin
7-92

Redes Multimedia 2012 II

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Redes Multimedia 2012 II

Caricato da

Copyright:

Formati disponibili

Redes Multimedia

Multimedia y calidad de servicio (QoS): Qu es?

Aplicaciones multimedia de red

Aplicaciones multimedia (MM) de red

Retardo extremo a extremo jitter de retardo

Pero tolerante a prdidas:

Flujo Multimedia Almacenado

transmitir: llegar a tiempo para reproduccin

Flujo Multimedia Almacenado: Qu es?

2. video enviado retardo de red

3. video recibido, Reproducido en el cliente tiempo

Flujo Multimedia Almacenado: Interactividad

Funcionalidad VCR: el cliente puede pausar,

transmitir: llegar a tiempo para reproducirse

Flujo Multimedia en Vivo

Multimedia de tiempo real, Interactivo

Aplicaciones: telefona IP, video

Cmo anuncia el destinatario su direccin IP, nmero de puerto, algoritmo de codificacin?

Multimedia sobre la Internet de hoy

Cmo debe cambiar Internet para soportar mejor multimedia?

Algunas palabras sobre la compresin de audio

muestreada a tasa constante

telefono: 8,000 muestras/s CD de musica: 44,100 muestras/s

Cada muestra se cuantiza o

Cierta reduccin de calidad

ejm., 28=256 posibles valores de cuantizacin

Cada valor cuantizado se

representa por bits

8 bits para 256 valores

Algunas palabras sobre la compresin de video

imgenes mostradas a tasa constante

Una imagen digital es un

arreglo de pixels Cada pixel se representa por bits Redundancia

usado en Internet, < 1 Mbps)

Flujo de audio y video almacenado

Flujo de Multimedia Almacenado

Aplicacin Media Player

controles para interactividad

Multimedia Internet: el enfoque ms simple

audio o video almacenado en un archivo Archivos transferidos como objetos

HTTP Recibido en su totalidad en el cliente luego pasado al reproductor

Multimedia Internet : enfoque de flujo

Enviando flujo desde un servidor de flujo

Esta arquitectura permite protocolos no-HTTP entre el servidor y el

reproductor de medios Tambien puede usar UDP en vez de TCP.

Transmisin de flujo Multimedia: Buffering en el cliente

reproduccin de video en el cliente a tasa de bit constante

Retardo de reproduccin En el cliente

Buffering en el cliente, retardo de reproduccin

compensan el retardo de red y de fluctuacin (jitter)

Transmisin de flujo Multimedia: Buffering en el cliente

variable fill rate, x(t)

constant drain rate, d

Buffering en el cliente, retardo de reproduccin

compensan el retardo de red y de fluctuacin (jitter)

Transmisin de flujo Multimedia: UDP o TCP?

Transmisin de flujo Multimedia: tasa(s) de cliente

Codificacin a 28.8 Kbps

Control de usuario de medios de flujo: RTSP*

RTSP: control fuera de banda

El flujo de medios se considera

conexin de datos al servidor de flujos

RTSP Ejemplo de intercambio