Cap2 3play Parte1 v2

REDES DE BANDA
ANCHA E INTERNET
Capítulo 2 Triple-Play
Andrés Vazquez Rodas
Facultad de Ingeniería - DEET - Universidad de Cuenca
Contenido
1. Introducción
2. Networking Multimedia
3. Servicios de voz
1. VoIP
2. RTP
3. SIP
4. Video sobre IP
1. VoD
2. IPTV
3. Formatos de video digital
Andrés Vazquez-Rodas
1. INTRODUCCIÓN
Introducción
• Emocionantes nuevos
servicios para la época
~2000
• Voz
• Video
• Datos
• Convergencia
• Un solo proveedor
• NGN
• Red Unificada
• Soporte para cualquier
tipo de servicio de
telecomunicaciones
Introducción
• Servicios Triple-Play
Introducción
• Luego de varios intentos fallidos
• Ofrecer múltiples servicios como un solo paquete comercial
• Triple – Play
• Múltiples servicios significa
• 1 red
• Varios terminales
• Muchos tipos de acceso
• NGN
• La convergencia de 2 mundos
Introducción
Introducción
• Evolución del mercado
global
Introducción. Offline
Introducción
Aplicaciones
• Requerimientos
• BW
• Temporales
Introducción. Aplicaciones
Introducción. Aplicaciones
Introducción. Residencial
• Interactividad
• Anuncios personalizados
• Competencias • Canales en Broadcast
• Unicast
• Pay-per-view
• Multicast
• Hi-fi audio
• VoIP corporativo
Introducción. Contenidos
• Telcos como productores de contenidos
• Alianzas con proveedores de contenidos
Introducción
• Nuevos Rx de TV
• Esquemas de codificación
Introducción
Impulsores de 3-Play
• Redefinición del negocio
• Punto de vista de los Telcos
• Punto de vista de los consumidores
• Presión Competitiva
• Negocios diferentes que no competían entre ellos
• Operadores de cable
• ISPs
• Telcos
Introducción
• Cada operador tiene su propia estrategia de migración hacia la convergencia
Introducción
• Las estrategias para 3-Play dependen de una cantidad de parámetros
• Tamaño del negocio
• Posición del mercado
• Competencia
• Infraestructuras existentes
Introducción
Introducción
• Una estrategia bien planeada debe seguir una secuencias de pasos que
allanará el camino para la adopción de 3-play
1. Acceso de banda ancha debe ser actualizado períodicamente
• ADSL
• ADSL2+
• VDSL2
• FTTP/FTTH
2. Agrupación progresiva de llamadas local/nacional/internacional
3. Red convergente para minimizar costos de soporte y mantenimiento
4. Agrupación móvil/fijo
5. Agregar nuevas aplicaciones tales como IPTV, VoIP, video conferencia
6. Servicios multimedia/multiterminal
Introducción https://youtu.be/7aP18Yq3H0M
• 3-Play no solo una cuestión de múltifles flujos de información

• Un amplio rango de terminales que manejan las aplicaciones de audio y video
Introducción
• Proceso de agrupación comercial, una sola cuenta
• Convergencia de red
• Cuádruple-play  móvil
Introducción
• Requisitos para el éxito
• Enfocarse en clientes urbanos
• Objetivo en conexiones de alta velocidad
• El costo es un factor clave
• IPTV es un movimiento defensivo  mantener a los operadores de cable
bajo control
• VoD es un movimiento ofensivo
• Preparar la convergencia
• Mantenerlo simple
Introducción. Infraestructuras
• Red convergente centrada en IP y con QoS
• Independiente de la tecnología de acceso
• DSL
• FTTx
• Cable
• WiMAX, LTE, WiFi
• Y de la arquitectura de la red de core
• VPLS
• MPLS
• Ethernet
• SDH
• WDM
Introducción
• Tecnologías de acceso de banda ancha
Introducción
Proyección de tecnologías de acceso

Introducción
Aplicaciones
Servicios y
Protocolos
Introducción
Alternativas
Ethernet a nivel de
proveedor
Introducción
2. MULTIMEDIA
NETWORKING
Multimedia Networking
• Personas en todo el mundo usando Internet para ver películas y shows de TV
bajo demanda
• No solo consumidores de contenido
• Subir y distribuir sus propios contenidos
• Millones de productores de contenido (youtubers)
• Llamadas de voz y video
• Conferencia multipersona
• Predicción al ~2013
• Al final de la presente década casi toda la distribución de video y las conversaciones de
voz tendrán lugar sobre Internet en ambos extremos (end-to-end)
• Importancia de las comunicaciones inalámbricas (LTE – WiFi)
Clasificación de una Comunicación Multimedia
• Streaming de audio/video almacenado

• Voz/Video sobre IP  del tipo conversacional
• Streaming de audio/video en vivo
• Cada una de estos tipos tiene sus requerimientos de servicios propios y únicos
• Servicios que difieren significativamente de las aplicaciones elásticas
Aplicación multimedia de red
• Cualquier aplicación de red que use audio o video

• Varias clases de aplicaciones
• C/aplicación de red tiene su propio conjunto de requisitos y problemas de
diseño
• Antes de centrarse en la aplicaciones es necesario considerar las características
intrínsecas del audio y el video
Propiedades del Video
• Alta tasa de bit  la propiedad más importante
• Baja calidad  100 kbps
• HD  3 Mbps
• Streaming de video consume de lejos el mayor ancho de banda
• Tasa de bit 10 veces más grande que de las otras aplicaciones
• Al diseñar aplicaciones de video el requerimiento más importante es la alta
tasa de bit
• En 2011 Cisco predijo que en el 2015 el 90% del consumo de tráfico global de
Internet será el streaming y el video almacenado
• Otra característica importante del video
• Puede ser comprimido haciendo un compromiso entre calidad y tasa de bit
• Video  secuencia de imágenes
• Mostradas típicamente a tasa constante
• 24 o 30 cuadros por segundo
• Imagen codificada digitalmente sin comprimir
• Arreglo de pixeles
• C/pixel codificado en una cantidad de bits
• Para representar luminancia y color
• 2 tipos de redundancia en el video
• Redundancia Espacial
• Redundancia dentro de una imagen
• Imagen con fondo constante  alto grado de redundancia
• Compresión sin sacrificar significativamente calidad
• Redundancia Temporal
• Repetición de la imagen a la subsecuente
• No hay razón para duplicar la codificación
• Más eficiente indicar en la codificación que la imagen es la misma o enviar solo las diferencias
• Algoritmos de compresión actuales pueden comprimir un video a
esencialmente cualquier tasa de bit deseada
• Mayor tasa  mayor calidad  mejor experiencia de usuario
• Múltiples versiones del mismo video
• c/u con un nivel de calidad diferente
• Usuario 3G  300 kbps
• Usuario WiFi  1 Mbps
• Usuario Eth  3 Mbps
• Usuario escoge en función del BW disponible
• El video en una aplicación de videoconferencia puede comprimirse sobre la
marcha
• Proveer mejor calidad dado el BW disponible extremo-extremo
• Tipos de Video
• CBR  Constnat Bit Rate
• Video codificado a tasa fija
• VBR  Variable Bit Rate

• Tasas de codificación cambian de acuerdo a las variaciones espacio-temporales de la codificación
• Codificaciones más utilizadas Trabajo autónomo

• MPEG-1  CD-ROM  1.5 Mbps Codificación de video MPEG-X y 4K
• MPEG-2  DVD  3 – 6 Mbps

• MPEG-4  (Usado muy a menudo en Internet) < 1 Mbps
Multimedia Net spatial coding example: instead
of sending N values of same

color (all purple), send only two
values: color value (purple) and
number of repeated values (N)
• Codificaciones más utilizadas ……………………...…

……………………...…
• MPEG-1  CD-ROM  1.5 Mbps
• MPEG-2  DVD  3 – 6 Mbps
• MPEG-4  (Usado muy a
menudo en Internet) < 1 Mbps
frame i
temporal coding example:

instead of sending
complete frame at i+1,
send only differences from
frame i
frame i+1
Propiedades del Audio
• Audio digital, música, y voz digitalizada
• Significativamente menor requerimiento de BW que el video
• Propiedades únicas que deben ser consideradas en el diseño
• Cómo se convierte el audio analógico a digital?
• La señal de audio es muestreada a una tasa fija  Ej 8000 muestras/s
• El valor de c/muestra es un No. real arbitrario
• Cuantización  c/u de las muestras es redondeada a un # fijo de valores
• Típicamente una potencia de 2
• C/u de los valores de cuantización es representado por un # fijo de bits
• Si 256 valores de cuantización  c/valor se representa con un Byte
• Cómo se convierte el audio
analógico a digital?
quantization
• La señal de audio es muestreada a
quantized
error value of
una tasa fija  Ej 8000 muestras/s analog value
audio signal amplitude

• El valor de c/muestra es un No. real analog
arbitrario signal
• Cuantización  c/u de las muestras

es redondeada a un # fijo de valores
• Típicamente una potencia de 2 time
• C/u de los valores de cuantización sampling rate

es representado por un # fijo de bits (N sample/sec)
• Si 256 valores de cuantización 

c/valor se representa con un Byte
• Las representaciones de bit de todas las muestras son concatenadas
• Formación de la representación digital de la señal
• Ej  Señal de audio analógico muestreada a 8000 muestras/s
• c/muestra es cuantizada y representada con 8 bits
• La señal digital resultante  tasa 64 000 bps  64 kbps
• En la reproducción en parlantes la señal digital se convierte de vuelta en una señal
analógica
• Señal decodificada es una aproximación de la señal original
• Calidad del sonido puede o no estar degradada
• Ej  Falta de sonidos de alta frecuencia
• A mayor tasa de muestreo y mayor cantidad de valores de cuantización
• Señal decodificada se aproxima mejor a la señal original
• Compromiso entre calidad y tasa de bit y los requisitos de almacenamiento
• Técnica de codificación  Pulse Code Modulation PCM
• Valores comunes PCM para voz
• Tasa de muestreo 8000 muestras/s • Valores comunes PCM de un CD audio
• 44 100 muestras/s
• 8 bits / muestra • 16 bits/muestra
• Tasa de 64 kbps • 705 kbps para mono
• 1.411 kbps para estereo
• Codificación PCM de voz y música rara vez es usada en Internet
• Como en video se usan técnicas de compresión para reducir las tasas de bit
• Voz puede comprimirse a 10 kbps
• Música comúnmente se comprime con MPEG-1 Capa 3  mp3
• Varias tasas son posibles con mp3
• 128 kbps la más común con muy poca degradación del sonido
• 96 kbps
• 160 kbps
• Estándar relacionado Advanced Audio Coding AAC
• Popularizado por Apple
• Aunque las tasas de bit de audio son generalmente mucho menores que las de
video
• Los usuarios son generalmente más sensibles a fallas de audio que a las de
video
• Ej video conferencia por Internet
• Fallas de video
• Fallas de audio
• Cuáles son las molestosas?
Tipos de Aplicaciones Multimedia de Red
• Streaming de audio / video almacenado

• Voz / video conversacional sobre IP
• Streaming de audio / video en vivo
• Medios pregrabados y colocados en servidores
• Servicio bajo demanda de los usuarios
• Estimación  50% del tráfico DL en las redes de acceso a

Internet es video streaming almacenado
• Tres características distintivas
• Streaming
• Inicio de la reproducción pocos segundos después de empezar a Rx el medio
• Reproducción + Rx simultáneas
• Interactividad
• Pausa, adelanto, retroceso, etc  respuesta dentro de < pocos segundos
• Reproducción Continua
• Rx datos a tiempo para que el flujo sea continuo
• De lejos la medida más importante de desempeño  throughput promedio
• Reproducción continua  throughput promedio al menos tan grande como la
tasa de bit del video
• Común el uso de buffering y pre-descarga
• Uso de CDNs  Content Distribution Networks en lugar de centro de datos
• Uso también frecuente de arquitecturas P2P
• Video almacenado en los usuarios
• Torrents
• Voz y Video Conversacional sobre IP
• Servicios de tiempo real
• VoIP > 100 millones de usuarios diarios
• Videoconferencia
• Voz y Video Conversacional sobre IP
• Consideraciones de temporización
• Servicios altamente sensibles al retardo
• Para voz
• Retardo < 150 ms no son percibidos por un escucha humano
• 150 ms < Retardo < 400 ms  pueden considerarse aceptables
• Retardo > 400 ms frustrantes e incluso ilegible
• En cuanto a pérdidas de pkts

• Tolerables a pérdidas ocasionales
• Servicios Delay-sensitive loss-tolerant  claramente diferentes a un ftp por ej
• Streaming de Audio/Video en Vivo
• Similar a la difusión de radio y TV tradicional
• Tx es sobre Internet
• Tx sobre cualquier esquina del mundo
• Varios usuarios que Rx el mismo contenido al mismo tiempo
• Uso de tecnologías Multicast
• Multicast – IP
• Multicast de capa de aplicación
• Usando P2P
• CDNs
• Streaming de Audio/Video en Vivo
• C/flujo multimedia debe tener un throughput promedio > a la tasa
de consumo del video
• Evento en vivo  Retardo es fundamental
• Restricciones de tiempo mucho menos exigentes que los aplicados a voz
conversacional
• Retardos de hasta 10 s se podrían considerar tolerables
• En discusión
3. SERVICIOS
DE VOZ
Servicios de Voz. VoIP
• Voz conversacional en tiempo real sobre Internet
• Telefonía IP
• Desde la perspectiva del usuario, es similar al servicio tradicional de telefonía
de conmutación de circuitos
VoIP. Limitaciones IP – BE
• IP provee servicio “Best-Effort”
• No hay garantías de temporización ni entrega fiable
• Retos significativos a aplicaciones VoIP que son de tiempo real
• Retardo  debe ser < 150 ms
• Jitter
• Pérdida de Pkts
• Cómo mejorar el rendimiento de aplicaciones VoIP
• Técnicas de capa de aplicación
• No requieren cambios en el core de la red ni en la capa de transporte de los hosts
• El emisor genera bytes a tasa 8000 bytes/s
• c/20ms el emisor acumula estos bytes en “chunks”
• El chunk es encapsulado junto con un encabezado UDP
• El segmento UDP es enviado c/20 ms
• En estas condiciones
• El Rx simplemente puede reproducir c/chunk tan pronto como éste llega
• Pkts pueden perderse
• No todos los Pkts experimentan el mismo retardo extremo-extremo
• Aún en ausencia de congestión
• El Rx debe entonces determinar
• Cuándo reproducir un chunk
• Qué hacer con un chunk perdido
Pérdida de Paquetes
• Los segmentos UDP son encapsulados en paquetes IP
• La red puede perder paquetes IP
• Opción  usar TCP ?
• Problemas asociados a esta solución
• Retardos extremo-extremo inaceptables
• Mecanismo de control de congestión de TCP reduce la tasa de Tx del emisor
• La mayoría de soluciones usan UDP
• Tasas de pérdidas de paquetes entre 1 – 10 % pueden ser tolerables
• Uso de FEC  Forward Error Correction
Retardo de Extremo – Extremo transmission
A propagation
• Acumulación de retardos
• Tx
B
• Procesamiento nodal
processing queueing
• Colas
dnodal = dproc + dqueue + dtrans + dprop
• Propagación en los enlaces
• Retardos de procesamiento en el sistema final
• Conclusión
• Retardo < 150 ms  generalmente no percibido por un escucha humano
• 150 ms < Retardo < 400 ms  tolerables pero no ideales
• Retardo > 400 ms  normalmente los paquetes son descartados y asumidos perdidos
Jitter – Variación del Retardo
• Retardos variables que experimentan los paquetes en los enrutadores de la red
• Variación del tiempo en que un paquete es generado en la fuente hasta que es
Rx en el Rx
• Retardos en cola son altamente variables
• Rx no puede ignorar los efectos del jitter
• La calidad del audio resultante podría llegar a ser inentendible
• Opciones
• Números de secuencia
• Marcas de tiempo
• Retardo de reproducción
VoIP. Removiendo el Jitter
• Paquetes son generados periódicamente
• La reproducción debe ser periódica
• Generalmente se logra con la combinación de 2 mecanismos
• Marca de tiempo antepuesta a c/chunk
• Tx estampa c/chunk con el tiempo en el cual el chunk fue generado
• Retardando la reproducción de los chunks en el Rx
• Asegurar que los paquetes sean Rx antes de su tiempo de reproducción planificado
• Puede ser
• Fijo
• Variar adaptativamente
constant bit
rate client constant bit
transmission reception rate playout
at client
variable
network
buffered
data
delay
(jitter)
client playout time

delay
Retardo de Reproducción Fijo
• El Rx intenta reproducir c/chunk exactamente 𝑞𝑞 ms después de que el chunk
fue generado
• Chunk tiene marca de tiempo 𝑡𝑡  Reproducción en 𝑡𝑡 + 𝑞𝑞
• Si el chunk llega después de 𝑡𝑡 + 𝑞𝑞  llegada muy tardía  se considera como pérdida
• Cuál es una buena elección para 𝑞𝑞?
• Compromiso en escoger 𝑞𝑞
• 𝒒𝒒 muy largo  menos paquetes perdidos
• Útil cuando las variaciones del retardo extremo-extremo son típicamente grandes
• 𝒒𝒒 pequeño  mejor experiencia interactiva
Retardo de Reproducción Fijo
• Emisor genera paquetes c/20 ms packets
• Primer paquete Rx a tiempo 𝑟𝑟

• 2 planificaciones consideradas
• 1era planificación reproducción packets
generated
loss
• Empieza en 𝑝𝑝 packets
received
playout schedule
p' - r
• 2da planificación de reproducción playout schedule

p-r
• Empieza en 𝑝𝑝𝑝
• No hay pérdidas time
r
p p'
Retardo de Reproducción Adaptativo
• Tradeoff importante  retardo-pérdidas
• Objetivo 
• Bajo retardo de reproducción y
• Baja tasa de pérdidas de tardíos
• Propuesta 
• Ajuste adaptativo del retardo de reproducción
• Estimar el retardo de la red
• Ajustar el retardo de reproducción al inicio de cada ráfaga de conversación
• Los periodos de silencio del emisor pueden ser comprimidos o alargados
• Los chunks son aún reproducidos c/20 ms durante la conversación
• Estimación adaptativa del retardo del paquete
• EWMA  Exponentially Weighted Moving Average (Similar a TCP)
di = (1−α)di-1 + α (ri – ti)
delay estimate small constant, time received - time sent

after ith packet e.g. 0.1 (timestamp)
measured delay of ith packet
• Útil también la estimación de la desviación promedio del retardo  𝑣𝑣𝑖𝑖
𝑣𝑣𝑖𝑖 = 1 − 𝛽𝛽 𝑣𝑣𝑖𝑖−1 + 𝛽𝛽 |𝑟𝑟𝑟𝑟 – 𝑡𝑡𝑡𝑡 – 𝑑𝑑𝑑𝑑|

• Las estimaciones de 𝑑𝑑𝑖𝑖 y 𝑣𝑣𝑖𝑖 son calculadas para cada paquete Rx
• Pero solo son usadas en el inicio de una ráfaga de conversación
• Para el primer paquete en la ráfaga de conversación, el tiempo de
reproducción es
playout-timei = 𝑡𝑡𝑖𝑖 + 𝑑𝑑𝑑𝑑 + 𝐾𝐾𝐾𝐾𝑖𝑖
• El resto de paquetes en la ráfaga son reproducidos periódicamente
VoIP. Recuperación Pérdidas
Recuperación desde una Pérdida de Paquetes
• Reto  Recuperarse de pérdidas de paquetes en un tiempo tolerable
• Incluir paquetes que llegan demasiado tarde para se útiles
• Las Re-Tx pueden no ser factibles en tiempo real
• ACK/NACK toma ~𝑅𝑅𝑅𝑅𝑅𝑅
• Alternativas
• FEC  Forward Error Correction
• Entrelazado
• Encubrimiento / ocultación del error
Forward Error Correction FEC
• Agregar información redundante al flujo de paquetes original para
• Incremento en la tasa de Tx pero
• Posibilita recuperación sin Re-Tx
• Reconstruir aproximaciones o versiones exactas de algunos de los paquetes
perdidos
• Dos mecanismos de FEC
• Enviar un chunk codificado redundante después de c/n chunks
• RFC 5109
• Enviar un flujo de audio de menor resolución como información redundante
• Enviar un chunk codificado redundante después de c/𝑛𝑛 chunks
• Por c/grupo de 𝑛𝑛 chunks, crear un chunk redundante
• OR-exclusivo de 𝑛𝑛 chunks originales
• Enviar 𝑛𝑛 + 1 chunks, incrementando el BW por un factor 1/𝑛𝑛
• Es posible reconstruir los 𝑛𝑛 chunks originales
• Si a lo mucho se pierde un chunk de los 𝑛𝑛 + 1
• Piggyback de un flujo de menor calidad
• Flujo de audio nominal y su versión de baja resolución y baja tasa de bit
correspondiente
• Ej
• PCM 64 kbps
• GSM codificado a 13 kbps  Flujo redundante
• Pérdidas no consecutivas
• RX puede ocultar la pérdida
• Generalizacion
• Anexar (𝑛𝑛 − 1)ésimo al 𝑛𝑛-ésimo chunk nominal
Entrelazado
• Alternativa a la Tx
redundante
• Chunks de audio
divididos en pequeñas
unidades
• Ej 5 ms por c/20 ms
• Pkt contiene unidades
pequeñas de diferentes
chunks
• Pkt perdido todavía
contiene la mayoría de
un chunk
• Bajo overhead pero
incrementa retardo
Encubrimiento del Error
• Producir un reemplazo para un paquete perdido
• Explotar la auto-similaridad de corto plazo de las señales de voz
• Útil solo en tasas de pérdidas bajas y paquetes pequeños (4 – 40 ms)
• No útil cuando se pierden fonemas completos
• Forma más simple
• Repetición de paquetes que han llegado inmediatamente antes
• Interpolación
• Usando muestras de audio previas y posteriores a la pérdida
• Mejor
• Más compleja
VoIP. Caso de Estudio - Skype
Skype
Skype clients (SC)
• Trabajo Autónomo
Skype
login server supernode (SN)
supernode
overlay
network
VoIP. Protocolos
• Aplicaciones en tiempo real como VoIP y videoconferencia altamente
populares
• Cuerpos de estandarización como ITU e IETF trabajando en
estándares y protocolos
• Real-Time Transport Protocol RTP
• RFC 3550
• Session Initiation Protocol SIP
• RFCs 3261 - 5411
3.1 RTP
Real-Time Transport Protocol
RFC 3550
RTP
• RTP especifica la estructura de paquetes que transportan datos de audio y
video
• Puede usarse para transportar formatos comunes como
• PCM, ACC, MP3  Audio • Proporciona Interoperabilidad
• MPEG, H.263  Video • Si 2 aplicaciones VoIP corren RTP
• Estas son capaces de trabajar juntas
• Un paquete RTP provee
• Identificación del tipo de payload • Se complementa con otros protocolos
• Número de secuencia del paquete interactivos de tiempo-real
• SIP
• Marca de tiempo
• RTP corre en sistemas finales
• Se encapsula en segmentos UDP y lo extiende
RTP
• Ubicación en la pila de protocolos

TCP/IP
RTP
• El RX usa los campos de encabezado RTP para decodificar y reproducir
adecuadamente el chunk de audio
• RTP no brinda ningún mecanismo para asegurar entrega confiable de datos ni
asegura parámetros de temporización
• O ninguna otra garantía de QoS
• La encapsulación RTP es solamente vista por los dispositivos finales
• No por enrutadores intermedios
• Servicio de mejor esfuerzo
• RTP permite que c/fte sea asignada con su propio flujo independiente
• Paquetes RTP pueden ser enviados sobre árboles multicast
• No están limitados a aplicaciones unicast
RTP. Campos de Encabezado
• Versión (2 bits)  actual 2
• P  Si hay bytes de relleno
al final del payload
• X  Si 1, el encabezado
fijo es seguido por un
encabezado de extensión
• CC  cantidad
identificadores de fuentes
contribuyentes
• M  depende del tipo de
carga
• Video  marca el fin de una
trama
• Audio  Marca el inicios de
una ráfaga de conversación
• Tipo de Payload (7 bits)
• # Secuencia (16 bits)
• Inicio aleatorio
• Incrementado en c/pkt RTP
• Detección de pérdidas
• Marca de tiempo (32 bits)
• Instante de generación del
1er byte de dato en el
payload
• Identificador de fuente de
Sincronización SSRC
• # aleatorio que identifica a la
fuente del flujo dentro de una
sesión
• c/flujo en una sesión RTP
tiene un SSRC distinto
• Identificador de fuente
Contribuyente
• Identifica a la fuente
contribuyente para el payload
• Payload
Type
• Tipo de payload para flujos de audio
• Tipo de payload para flujos de video
• El emisor puede cambiar la codificación sobre la marcha
RTP
3.2 RTCP
Real-Time Control Protocol
RTCP
• Trabaja en conjunto con RTP
• C/participante en una sesión RTP envía periódicamente paquetes de
control RTCP a todos los otros participantes
• C/paquete RTCP contiene
• Reportes del emisor y/o Rx
• Estadísticas útiles para la aplicación
• # paquetes enviados
• # paquetes perdidos
• Jitter inter-llegada
• Retroalimentación usada para el control

• El emisor puede modificar sus Tx en base a la realimentación
RTCP sender RTP
Emisores Multicast Múltiples RTCP
RTCP
RTCP
receivers
• Cada sesión RTP  típicamente una sola dirección multicast

• Todos los paquetes RTP/RTCP que pertenecen a una sesión usan direcciones multicast
• Paquetes RTP, RTCP se distinguen entre sí por # de puerto
• Para limitar el tráfico
• C/participante reduce el tráfico RTCP conforme aumenta el # de participantes de la
sesión
RTCP. Tipos de Paquetes
• Paquetes de reporte del Rx • Paquetes de descripción de la fuente
• Fracción de paquetes perdidos • Dirección e-mail del emisor
• Último # de secuencia • Nombre del emisor
• Jitter promedio inter-llegada • SSRC del flujo RTP asociado
• Paquetes de reporte del Emisor • Provee mapeo entre el SSRC y el
nombre del usuario/host
• SSRC del flujo RTP
• Tiempo actual
• # paquetes enviados
• # de bytes enviados
RTCP. Sincronización de Flujo
• RTCP puede sincronizar diferentes flujos dentro de una sesión RTP
• EJ  videoconferencia, cada emisor genera
• Flujo RTP para video
• Flujo RTP para audio
• Marcas de tiempo en paquetes RTP atadas al video

• C/paquete de reporte del emisor contiene
• Marca de tiempo del paquete RTP
• Tiempo en el cual fue creado el paquete
• Rx usan asociación para sincronizar la reproducción de audio y video
RTCP. Escalamiento de BW
• RTCP intenta limitar su tráfico al 5% del BW de la sesión
• Ej  Un emisor, enviando video a 2 Mbps
• RTCP intenta limitar el tráfico RTCP a 100 kbps
• RTCP entrega el 75% de la tasa a los Rx
• El 25% restante al emisor
• 75 kbps son igualmente compartidos entre los Rx
• Con R Rx  c/Rx puede enviar tráfico RTCP a 75/R kbps
• Emisor obtiene 25 kbps para enviar tráfico RTCP
• Participante determina el periodo de Tx del paquete calculando
• El tamaño del paquete RTCP promedio
• Dividido por la tasa asignada
RTCP
3.3 SIP
Session Initiation Protocol
RFC 3261
SIP
• Protocolo abierto y liviano que brinda:
• Mecanismo para el establecimiento de llamadas entre un origen y un
destinatario en una red IP
• Permite que el llamante notifique al destinatario que quiere iniciar una llamada
• Permite que participantes se pongan de acuerdo en las codificaciones del medio
• Permite finalización de llamadas
• Mecanismo para que el que llama determine la IP actual del destino
• Usuarios no tienen una IP fija  generalmente bajo DCHP
• Múltiples dispositivos IP, c/u en direcciones diferentes
SIP
• Mecanismos para Administración de llamadas
• Agregar nuevos flujos de media durante la llamada
• Cambiar la codificación durante las llamadas
• Invitar nuevos participantes durante la llamada
• Transferencia de llamadas
• Llamada en espera
• Entender el establecimiento de una llamada a una IP conocida con un Ej
• Alice quiere llamar a Bob, c/u en sus PCs
• PCs equipados con software basado en SIP para hacer y Rx llamadas telefónicas
• Se asume que Alice conoce la IP de Bob
SIP
• Alice invita a Bob indicando
• # puerto
• Dirección IP
• Codificación preferida (PCM)
• Bob responde 200 ok indicando
• # puerto
• Dirección IP
• Codificación preferida (GSM)
• Mensajes SIP pueden ir sobre
• TCP o UDP
• Puerto SIP por defecto 5060
SIP
• Diferentes esquemas de
codificación
• Si no se dispone del codificador
• Respuesta 606 Not Acceptable
• Lista de codificadores soportados
• Finalmente Alice envía un ACK
SIP
• La conversación puede
entonces fluir sobre RTP o
sobre otro protocolo
• Podría ser simultáneamente
SIP
• Una llamada puede ser
rechazada  respuestas
• Busy
• Gone
• Payment required
• Forbidden
SIP. Características Claves
• SIP es un protocolo fuera de banda
• Los mensajes SIP son Tx y Rx en sockets diferentes a los usados para la Tx y
Rx de mensajes de datos del medio
• Mensajes SIP son ASCII-legibles

• Muy similares a mensajes HTTP
• SIP requiere que todos los mensajes sean reconocidos ACKed

• Puede ir sobre TCP o UDP
SIP. Dirección INVITE sip:bob@domain.com SIP/2.0
• Dirección de Bob Via: SIP/2.0/UDP 167.180.112.24
From: sip:alice@hereway.com
• sip:bob@domain.com To: sip:bob@domain.com
• Direcciones similares a las de e-mail Call-ID: a2e3a@pigeon.hereway.com
Content-Type: application/sdp
• La infraestructura SIP enruta el mensaje al Content-Length: 885
dispositivo IP que Bob usa actualmente
c=IN IP4 167.180.112.24
• Otras posibles direcciones m=audio 38060 RTP/AVP 0
• # telefónico tradicional
• Nombre  First/Middle/Last  asumiendo que
es único
• Las direcciones pueden incluirse en páginas
Web con el URL
• Como las de mail-to
SIP. Mensajes INVITE sip:bob@domain.com SIP/2.0
• Sintaxis de un mensaje HTTP Via: SIP/2.0/UDP 167.180.112.24
From: sip:alice@hereway.com
• Sdp  Session Descrition Protocol To: sip:bob@domain.com
• Call-ID es único para c/llamada Call-ID: a2e3a@pigeon.hereway.com
Content-Type: application/sdp
• Solo se conoce la dirección SIP Content-Length: 885
• No se conoce la IP del dispositivo de Bob c=IN IP4 167.180.112.24

• Son necesario servidores SIP intermedios m=audio 38060 RTP/AVP 0
• En este caso el mensaje va sobre UDP

• Luego del “enter” el mensaje lleva el contenido
• Información a cerca de la IP de Alice
• Cómo se quiere Rx el contenido
SIP. Traducción de Nombre
• Normalmente las IPs son Rx de un servidor DHCP
• Múltiples dispositivos de un usuario
• PC, Smartphone, carro, Tablet, etc
• Objetivo  la IP en la que está el usuario bob@domain.com SIP/2.0
• Alice crea un mensaje INVITE bob@domain.com SIP/2.0 y lo envía a un Proxy
SIP
• El Proxy SIP responderá con un SIP reply
• Puede incluir la IP del dispositivo que Bob usa actualmente
• Como alternativa, la IP del voicemail box de Bob
• URL de una página Web
• Sleeping,
• Esto en función de quién es el que llama  esposa/suegra/amigo
SIP. Ubicación del Usuario
Cómo determina el Proxy server la IP actual para bob@domain.com?
• Introducción de otro dispositivo SIP  SIP Registrar
• c/usuario SIP tiene un registrar asociado
• Siempre que un usuario lanza una aplicación SIP en un dispositivo
• La aplicación envía un mensaje SIP register al registrar informando de su IP actual
REGISTER sip:domain.com SIP/2.0 Hay mensajes de refresco
Via: SIP/2.0/UDP 193.64.210.89
Cuando un usuario cambio de dispositivo,
From: sip:bob@domain.com el nuevo dispositivo enviará un nuevo
To: sip:bob@domain.com mensaje register con la nueva IP
Expires: 3600
El registrar es análogo a un servidor DNS
autorizado
SIP Proxy
Cómo el Proxy SIP de Alice obtiene la IP actual de Bob?
• Otra función del servidor SIP  Proxy
• El servidor proxy re-envía el mensaje INVITE de Alice al proxy/registrar de
Bob
• El proxy/registrar puede entonces re-enviar el mensaje al dispositivo actual
• Bob Rx el INVITE y genera su respuesta SIP
• Ejemplo
• jim@umass.edu trabajando en 217.123.56.89
• Quiere iniciar una sesión VoIP con Keith@poly.edu trabajando en 197.87.54.21
• Proceso
SIP. Ej jim@umass.edu calls keith@poly.edu
Poly SIP
2. UMass proxy forwards request registrar
to Poly registrar server
2 3 3. Poly server returns redirect response,
indicating that it should try keith@eurecom.fr
UMass 4. Umass proxy forwards request Eurecom SIP

SIP proxy to Eurecom registrar server 4 registrar
7
1. Jim sends INVITE 6-8. SIP response returned to Jim 5. eurecom
message to UMass 8 5 registrar
6 forwards INVITE
SIP proxy. 1
to 197.87.54.21,
which is running
keith’s SIP
9 client
128.119.40.186
9. Data flows between clients
197.87.54.21
SIP. Comparación con H.323
• H.323  Otro protocolo de señalización para multimedia interactiva en t-real
• H.323
• Suite de protocolos verticalmente integrado y completo para conferencia multimedia
• Señalización
• Registro
• Control de Admisión
• Transporte
• Codecs
• SIP  un único componente

• Trabaja con RTP aunque no obligatoriamente
• Puede combinarse con otros protocolos y servicios
SIP. Comparación con H.323
• H.323 viene de la ITU
• Telefonía
• Sabor a telefonía convencional
• SIP viene de la IETF
• Mucho de los conceptos de HTTP
• Sabor a Web
• SIP usa el principio KISS
• Keep It Simple Stupid
SIP. Conclusiones
• Protocolo de señalización para inicio y fin de llamadas en general
• Puede usarse
• Llamadas de voz
• Videoconferencia
• Sesiones basadas en texto
• SIP se ha vuelto un componente fundamental en muchas

aplicaciones de mensajería instantánea
• Open SIP
SIP
• Trabajo autónomo
• Práctica. Implementación de un servidor de VoIP de software libre y análisis de los
protocolos asociados mediante Wireshark
SIP
4. VIDEO
SOBRE IP
REFERENCIAS
Referencias
• Kurose J. and Ross K, Computer Networking A Top-Down Approach, 6 Edition,
2013, Pearson
• Janevski Toni, NGN Architectures Protocols and Services, Wiley, 2015
Referencias
Recuperación desde una Pérdida de Paquetes
•S

Cap2 3play Parte1 v2

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Cap2 3play Parte1 v2

Cargado por

Copyright:

Formatos disponibles

REDES DE BANDA

• 3-Play no solo una cuestión de múltifles flujos de información

Proyección de tecnologías de acceso

• Streaming de audio/video almacenado

• Cualquier aplicación de red que use audio o video

• VBR  Variable Bit Rate

• Codificaciones más utilizadas Trabajo autónomo

• MPEG-2  DVD  3 – 6 Mbps

Propiedades del Video

• Codificaciones más utilizadas ……………………...…

temporal coding example:

audio signal amplitude

• Cuantización  c/u de las muestras

• C/u de los valores de cuantización sampling rate

• Si 256 valores de cuantización 

• Streaming de audio / video almacenado

• Estimación  50% del tráfico DL en las redes de acceso a

• En cuanto a pérdidas de pkts

client playout time

• Primer paquete Rx a tiempo 𝑟𝑟

• 2da planificación de reproducción playout schedule

di = (1−α)di-1 + α (ri – ti)

delay estimate small constant, time received - time sent

• Útil también la estimación de la desviación promedio del retardo  𝑣𝑣𝑖𝑖

𝑣𝑣𝑖𝑖 = 1 − 𝛽𝛽 𝑣𝑣𝑖𝑖−1 + 𝛽𝛽 |𝑟𝑟𝑟𝑟 – 𝑡𝑡𝑡𝑡 – 𝑑𝑑𝑑𝑑|

• El resto de paquetes en la ráfaga son reproducidos periódicamente

• Ubicación en la pila de protocolos

• Retroalimentación usada para el control

Emisores Multicast Múltiples RTCP

• Cada sesión RTP  típicamente una sola dirección multicast

• Marcas de tiempo en paquetes RTP atadas al video

• Mensajes SIP son ASCII-legibles

• SIP requiere que todos los mensajes sean reconocidos ACKed

• No se conoce la IP del dispositivo de Bob c=IN IP4 167.180.112.24

• En este caso el mensaje va sobre UDP

UMass 4. Umass proxy forwards request Eurecom SIP

• SIP  un único componente

• SIP se ha vuelto un componente fundamental en muchas

También podría gustarte