Post on 12-Dec-2015
description
© Dr. Ing. José Joskowicz 2013
Voz y Video en Redes IP
Dr. Ing. José Joskowicz
josej@fing.edu.uy
© Dr. Ing. José Joskowicz 2013
Multimedia sobre Redes de Datos
Voz y Video en Redes IP
3© Dr. Ing. José Joskowicz 2013
Paquetización de los flujos multimedia
� Para poder transmitir la información codificada de voz o video sobre redes de datos, es necesario armar “paquetes”.
� Es necesario “juntar” un conjunto apropiado de información para armar un paquete.
� Cada paquete tiene una cantidad mínima de información de control� Cabezal del paquete
� Origen, destino
� Etc.
4© Dr. Ing. José Joskowicz 2013
Flujo multimedia
RTP
UDP
IP
Ethernet
Sobrecarga
Ventana
Transmisión de multimedia sobre redes de datos
Sobrecarga
5© Dr. Ing. José Joskowicz 2013
RTP – Real Time Protocol
� Es un protocolo para transmisión de datos de tiempo real (audio y video) sobre IP
� Está estandarizado en el RFC 3550
� Se basa en UDP
6© Dr. Ing. José Joskowicz 2013
RTP - Cabezal
V P X CC M PT Sequence number
Timestamp
synchronization source (SSRC) identifier
contributing source (CSRC) identifiers
…….
32 bits
Version Padding eXtension CSRC count Payload Type
7© Dr. Ing. José Joskowicz 2013
RTP - Cabezal
Payload Type Formato Medio Clock Rate
0 PCM mu-law Audio 8 kHz
3 GSM Audio 8 kHz 4 G.723 Audio 8 kHz
8 PCM A-law Audio 8 kHz
9 G.722 Audio 8 kHz
13 Confort Noise Audio
14 MPEG Audio Audio 90 kHz 15 G.728 Audio 8 kHz
18 G.729 Audio 8 kHz
26 Motion JPEG Video 90 kHz
31 H.261 Video 90 kHz
32 MPEG-1 o 2 Elementary Stream Video 90 kHz
33 MPEG-1 o 2 Transport Stream Video 90 kHz 34 H.263 Video 90 kHz
96 – 127 Dinámico
� Payload Type
8© Dr. Ing. José Joskowicz 2013
RTP - Cabezal
� Payload type
� Identifica el tipo de información que viaja en el paquete
� Indica el tipo de codificación de audio o video, o el contenido de información “especial”
� CN (Comfort Noise)
� Tipos dinámicos
� RFC 2833 (Tonos DTMF, tonos de Fax, etc.)
� …
� …
9© Dr. Ing. José Joskowicz 2013
� Sequence number ( 16 bits)� Número secuencial, generado en el origen. Es usado
por el receptor para detectar paquetes perdidos
� Time Stamp (32 bits)� Marca horaria, del momento de la generación del
primer byte de la muestra enviada en el paquete
� Synchronization Source Identifier (32 bits)� Identifica el origen
RTP - Cabezal
10© Dr. Ing. José Joskowicz 2013
Ejemplo RTP: Paquete de audio
11© Dr. Ing. José Joskowicz 2013
RTCP –RTP Control Protocol
� El RFC 3550 establece, además del protocolo RTP, un protocolo de control, RTCP
� Encargado de enviar periódicamente paquetes de control entre los participantes de una sesión
� Proveer realimentación acerca de la calidad de los datos distribuidos (por ejemplo, de la calidad percibida de VoIP).
12© Dr. Ing. José Joskowicz 2013
RTCP – tipos de datos
� SR (Sender Report): Envía estadísticas de los participantes “origen” (sender)
� RR (Receiver Report): Envía estadísticas de los participantes “destino” (receivers)
� SDES (Source Description): Envía ítems de descripción del origen
� BYE: Indica el fin de la participación en el intercambio de mensajes RTCP
� APP: Funciones específicas para las aplicaciones participantes
13© Dr. Ing. José Joskowicz 2013
RTCP – Ejemplo de SR y SDES
© Dr. Ing. José Joskowicz 2013
Voz sobre Redes de Datos
Voz y Video en Redes IP
15© Dr. Ing. José Joskowicz 2013
CODECs de banda angosta
Codec NombreBit rate (kb/s)
Retardo (ms)
Comentarios
G.711PCM: Pulse Code Modulation
64, 56 0.125Codec “base”, utiliza dos posibles leyes de compresión: µ-law y A-law
G.723.1Hybrid MPC-MLQ and ACELP
6.3, 5.3 37.5
Desarrollado originalmente para video conferencias en la PSTN, es actualmente utilizado en sistemas de VoIP
G.728
LD-CELP: Low-Delay code excited linear prediction
40, 16, 12.8, 9.6
1.25Creado para aplicaciones DCME (Digital Circuit Multiplex Encoding)
G.729
CS-ACELP: Conjugate Structure Algebraic Codebook Excited Linear Prediction
11.8, 8, 6.4
15Ampliamente utilizado en aplicaciones de VoIP, a 8 kb/s
16© Dr. Ing. José Joskowicz 2013
CODECs de banda ancha
Codec NombreBit rate (kb/s)
Retardo (ms)
Comentarios
G.722 Sub-band ADPCM 48,56,64 3Inicialmente diseñado para audio y videconferencias, actualmente utilizado para de telefonía de calidad en VoIP
G.722.1 Transform Coder 24,32 40 Usado en audio y videoconferencias
G.722.2 AMR-WB6.6 a 23.85
25.9375
Estandar en común con 3GPP (3GPP TS 26.171). gran inmunidad a los ruidos de fondo en ambientes adversos (por ejemplo celulares)
G.711.1 Wideband G.71164, 80, 96
11.875Amplía el ancho de banda del codec G.711, optimizando su uso para VoIP
G.729.1 Wideband G.7298 a 32 kb/s
<49 ms
Amplía el ancho de banda del codec G.729, y es “compatible hacia atrás” con este codec. Optimizado su uso para VoIP con audio de alta calidad
RtAudio Real Time Audio 8.8, 18 40Codec propietario de Microsoft, utilizado en aplicaciones de comunicaciones unificadas (OCS)
17© Dr. Ing. José Joskowicz 2013
CODECs de banda superancha
Codec NombreBit rate (kb/s)
Retardo (ms)
Comentarios
SILK SILK 8 a 24 25 Utilizado por Skype
18© Dr. Ing. José Joskowicz 2013
CODECs de banda completa
Codec NombreBit rate (kb/s)
Retardo (ms)
Comentarios
G.719Low-complexity, full-band
32 a 128 40Es el primer codec “fullband” estandarizado por ITU
19© Dr. Ing. José Joskowicz 2013
RTP – Paquete de audio
20© Dr. Ing. José Joskowicz 2013
RTP – Ejemplo RFC 2833
21© Dr. Ing. José Joskowicz 2013
RTP – Ejemplo Comfort Noise
22© Dr. Ing. José Joskowicz 2013
Ancho de banda para G.711
Ventana = 20 ms
� Bytes de voz/trama = 64 kb/s * 20 ms / 8 = 160 bytes
� Bytes de paquete IP = 160 + 40 = 200 bytes
� Bytes de Trama Ethernet = 200 + 26 = 226 bytes
� Ancho de banda LAN = 226 * 8 / 20 ms = 90.4 kb/s
� Este ancho de banda es para la voz en UN sentido. Se debe duplicar para tener en cuenta ambos sentidos
Ethernet
22 bytes
IP (UDP + RTP)
40 bytes
20 ms de voz
160 bytes
Et
4 bytes
23© Dr. Ing. José Joskowicz 2013
Ancho de banda
� Bytes de voz/trama = Velocidad de muestreo * duración de trama /8
� Bytes de paquete IP = Bytes de voz/trama + 40
� Bytes de Trama Ethernet = Bytes de paquete IP + 26
� Ancho de banda LAN = Bytes de Trama Ethernet * 8 / duración de trama
24© Dr. Ing. José Joskowicz 2013
Tipo de
Codec
Duración
de Trama
(ms)
Bytes de
voz/Trama
Bytes de
paquete IP
Bytes de
trama
Ethernet
Ancho de
Banda en
LAN (kbps)
G.711 10 80 120 146 116,8
(64 kbps) 20 160 200 226 90,4
30 240 280 306 81,6
G.729 10 10 50 76 60,8
(8 kbps) 20 20 60 86 34,4
30 30 70 96 25,6
G.723.1
(6.3 kbps) 30 24 64 90 23,9
G.723.1
5.3 kbps 30 20 60 86 22,9
Ancho de banda de LAN en un sentido
© Dr. Ing. José Joskowicz 2013
Video sobre Redes de Datos
Voz y Video en Redes IP
26© Dr. Ing. José Joskowicz 2013
Comparación de codecs de videoCaracterística MPEG-1 MPEG-2 MPEG-4 H.264/MPEG-4
Part 10/AVC
Tamaño del macro-bloque 16x16 16x16, 16x8 16x16 16x16
Tamaño del bloque 8x8 8x 8 16x16
8x8, 16x88x8, 16x8, 8x16,
16x16, 4x8, 8x4, 4x4
Transformada DCT DCT DCT/DWT 4x4 Integer transfor
Tamaño de la muestra para
aplicar la transformada
8x8 8x8 8x8 4x4
Codificación VLC VLC VLC VLC, CAVLC, CABAC
Estimación y
compensación de
movimiento
Si Si Si Si, con hasta 16 MV
Perfiles No 5 8 3
Tipo de cuadros I,P,B,D I,P,B I,P,B I,P,B,SI,SP
Ancho de banda < 1.5 Mbps 2 a 15 Mbps 64 kbps a 2 Mbps 64 kbps a 150 Mbps
Complejidad del codificador Baja Media Media Alta
Compatibilidad con
estándares previos
Si Si Si No
27© Dr. Ing. José Joskowicz 2013
Formatos de video
Formato Resolución (pixels)
SQCIF 128 × 96
QCIF 176 × 144
CIF 352 × 288
4CIF 704 × 576
16CIF 1408 × 1152
VGA 640 × 480
SD 720 × 576
28© Dr. Ing. José Joskowicz 2013
Transmisión de video sobre redes de datos
� Las secuencias de video (Elementary Streams) son paquetizadas en unidades llamadas PES (Packetized Elementary Streams), consistentes en un cabezal y hasta 8 kbytes de datos de secuencia.
� Estos PES a su vez, son paquetizados en pequeños paquetes, de 184 bytes, los que, junto a un cabezal de 4 bytes (totalizando 188 bytes) conforman el “MPEG Transport Stream” (MTS) y pueden ser transmitidos por diversos medios.
29© Dr. Ing. José Joskowicz 2013
Transmisión de video sobre redes de datos
� RFC 2250:� Establece los procedimientos para transportar video
MPEG-1 y MPEG-2 sobre RTP. Varios paquetes MTS de 188 bytes pueden ser transportados en un único paquete RTP, para mejorar la eficiencia
� RFC 3016 y RFC 3640� Establecen los procedimientos para transportar flujos
de audio y video MPEG-4
� RFC 3984 � Establece los procedimientos para transportar flujos
de video codificados en H.264
30© Dr. Ing. José Joskowicz 2013
MPEG-2 sobre RTP
7 paquetes MTS (MPEG-2 Transport Stream)dentro de un mismo paquete RTP
Payload Type: MTS (MPEG-2 Transport
Stream)
31© Dr. Ing. José Joskowicz 2013
MPEG-2 sobre RTP
Cabezal de MTS (4 bytes)
Payload de MTS (184 bytes)
32© Dr. Ing. José Joskowicz 2013
H.264 sobre RTP
Payload del tipo “dinámico”
Payload de H.264(1430 bytes)
33© Dr. Ing. José Joskowicz 2013
Ancho de Banda de Video
� El ancho de banda requerido depende de
� Tipo de codificación utilizada (MPEG-1, 2, 4, H264, etc.)
� Resolución (tamaño de los cuadros SD, CIF, QCIF, etc.)
� Tipo de cuantización seleccionado
� Movimiento
� Textura
� La codificación de video es estadística, y depende de la imagen transmitida
34© Dr. Ing. José Joskowicz 2013
Calidad vs Ancho de Banda
MOS (SD - MPEG-2)
1
1.5
2
2.5
3
3.5
4
4.5
5
0 1 2 3 4 5 6 7 8 9 10 11 12
Bitrate (Mb/s)
MO
S
Serie1
Serie2
Serie3
Serie4
Serie5
Serie6
Serie7
Serie8
Serie9
Serie10
Serie11
Serie12
Serie13
Serie14
Serie15
Serie16
35© Dr. Ing. José Joskowicz 2013
Ancho de banda en LAN para MPEG-2 con MTS
� 7 x184 = 1288 bytes de contenido MPEG-2
� 40 + 4 x 7 = 68 bytes de cabezales a nivel de capa 3 (IP)
� 26 bytes de cabezales adicionales a nivel de capa 2
184 bytes40 bytes
4 bytes (MTS Header)
22 bytes
Ethernet IP (UDP+RTP) MTS E
36© Dr. Ing. José Joskowicz 2013
Ancho de banda en LAN para MPEG-2 con MTS
� El ancho de banda de MPEG-2 transportado en RTP
� 5.3% (68/1288) mayor que el ancho de banda propio del video en capa 3 (IP)
� 7.3 % (94/1288) mayor que el ancho de banda propio del video en capa 2 (Ethernet)
37© Dr. Ing. José Joskowicz 2013
Ancho de banda en LAN para H.264
� H.264 encapsulado directamente sobre RTP (sin utilizar TS)
� Se pueden enviar hasta 1430 bytes de “payload” en un paquete IP/UDP/RTP
� El ancho de banda en capa 3 es 2.8% (40/1430) mayor que el del propio video codificado
� En capa 2 es 4.6% (66/1430) mayor que el del propio video codificado.
© Dr. Ing. José Joskowicz 2013
Calidad de Voz y Video
Voz y Video en Redes IP
39© Dr. Ing. José Joskowicz 2013
Evolución de la calidad percibida de la voz
40© Dr. Ing. José Joskowicz 2013
Calidad de la voz
� La calidad de la voz sobre redes de paquetes se ve afectada por varios factores
� Compresión utilizada
� Pérdida de paquetes
� Demora
� Eco
� Jitter
41© Dr. Ing. José Joskowicz 2013
Pérdida de paquetes
� A diferencia de las redes telefónicas, donde para cada conversación se establece sobre un vínculo “estable y seguro”, las redes de datos admiten la pérdida de paquetes.
� En aplicaciones de voz y video el audio y video es “encapsulado” en paquetes y enviado, sin confirmación de recepción de cada paquete.
� Puede haber un porcentaje de paquetes que no llegan al destino
� Se escucha como interrupciones en la voz, o cortes de video
42© Dr. Ing. José Joskowicz 2013
ITU-T G.711 Anexo I – PLC
� PLC = Packet Loss Concealment
� Técnica que mitiga la pérdida de paquetes, tratando de “reconstruir” los paquetes perdidos
43© Dr. Ing. José Joskowicz 2013
Demora (Delay)
� Se deben a:
� Codificación
� G.711 (64 kb/s) 0,13 – 0,75 ,ms
� G.728 (16 kb/s) 2.5 ms
� G.729 (8 kb/s) 10 – 15 ms
� G.723.1 (5.3 o 6.4 kb/s) 37.5 ms
� RTAudio < 40 ms
� Red (latencia)
� Cantidad de muestras/bytes por paquete
� Velocidad de transmisión
� Congestión
� Demoras de los equipos de red (colas en routers, gateways, etc.)
44© Dr. Ing. José Joskowicz 2013
Demora (Delay)
45© Dr. Ing. José Joskowicz 2013
Jitter
� Es la variación en las demoras (latencias). � Por ejemplo, si dos puntos comunicados reciben un paquete
cada 20 ms en promedio, pero en determinado momento, un
paquete llega a los 30 ms y luego otro a los 10 ms, el
sistema tiene un “jitter” de 10 ms.
� El jitter afecta la percepción de la voz, y puede evitarse mediante buffers
� Los buffers agregan una demora adicional al sistema, ya que
deben “retener” paquetes para poder entregarlos a intervalos
constantes. Cuánto más variación de demoras (jitter) exista,
más grandes deberán ser los buffers, y por lo tanto, mayor
demora total tendrá el sistema.
46© Dr. Ing. José Joskowicz 2013
Demora y Jitter
47© Dr. Ing. José Joskowicz 2013
Eco
� Tiempo transcurrido desde que se habla hasta que se percibe el retorno de la propia voz
� Si la demora de retorno es menor a 30 ms, o el nivel del retorno está por debajo de los –25 dB, el efecto del eco no es percibido.
� Dado que las demoras de voz sobre redes de datos son altas, puede existir eco
48© Dr. Ing. José Joskowicz 2013
Eco
49© Dr. Ing. José Joskowicz 2013
Cancelación de Eco
� ITU-T G.168: Digital Network Echo Cancellers
50© Dr. Ing. José Joskowicz 2013
Medida de la calidad de voz en redes IP
� Para que la tecnología de VoIP pueda ser utilizada corporativamente, es esencial garantizar una calidad de voz aceptable.
� Para ello se han desarrollado métodos para medirla.
� Subjetivos
� Se basan en conocer directamente la opinión de los usuarios
� Objetivos
� Miden propiedades físicas de una red para prever o estimar la performance percibida por los usuarios
� Intrusivos
� No Intrusivos
51© Dr. Ing. José Joskowicz 2013
Métodos Subjetivos
� La calidad de la voz se establece a través de la opinión del usuario
� ACR: Absolute Category Rating� Se califica el audio con valores entre 1 y 5, siendo 5 “Excelente”
y 1 “Malo”
� MOS (Mean Opinión Score) es el promedio de los ACR medidos entre un gran número de usuarios
� DCR: Degradation Category Rating � Se califica entre 1 y 5, siendo 5 cuando no hay diferencias
apreciables entre el audio de referencia y el medido y 1 cuando la degradación es muy molesta
� DMOS (Degradation MOS) el promedio de los valores DCR medidos entre un gran número de usuarios
52© Dr. Ing. José Joskowicz 2013
Métodos Objetivos: ITU-T G.107 E-Model
� La ITU ha definido un modelo, llamado “E-Model” (ITU-T G.107), para estimar la calidad de la voz sobre redes de paquetes, teniendo en cuenta factores medibles de la red
� El resultado del “E-Model” es un valor escalar llamado R, que puede ser directamente relacionado con el MOS (ITU-T P.800)
53© Dr. Ing. José Joskowicz 2013
R versus MOS
54© Dr. Ing. José Joskowicz 2013
Definición de “R”
� R = Ro - Is - Id – Ie + A� Ro =Fuentes de ruido independientes del sistema
� Ruido ambiental, tanto en el origen como en el destino
� El máximo teórico es 100
� Is = Deterioro simultáneo a la generación de la señal digital
� Volumen excesivo, distorsión de cuantización
� Id = Deterioro casusado por las demoras� Demoras, Jitter, Eco
� Ie = Deterioro causado por equipos especiales� Codec, pérdidas de paquetes
� A = Factor de Mejoras de Expectativas
55© Dr. Ing. José Joskowicz 2013
STD Kbps Algoritmo MOS Observaciones Retardo Uso
de 1 a 5 Encoding CPU
Toll Quality 4 a 5 Telefonía analógica - -
G.711 64 PCM 4,4 Telefonía digital 0,75 ms -
G.726/7 40/32/24/16 ADPCM 4,2 Telefonía digital comprimida 1 bajo
G.728 16 LD-CELP 3,6 Low Delay-Code Excited Linear Prediction bajo muy alto
G.729 8 CS-ACELP 4,2 VoIP/FR/ATM Netmeeting 15 ms alto
G.729A 8 CS-ACELP 3,7 VoIP/FR/ATM Netmeeting 15 ms alto
G.723.1 5,3 ACELP 3,5 VoIP/FR/ATM Netmeeting 37,5 ms moderado
G.723.1 6,4 MP-MLQ 3,98 VoIP/FR/ATM Netmeeting 37,5 ms moderado
MOS según el Codec
56© Dr. Ing. José Joskowicz 2013
Efectos del Codec y la Demora
57© Dr. Ing. José Joskowicz 2013
Efecto del Eco y la demora
50
60
70
80
90
100
0 100 200 300 400 500
One-way Delay (ms)
R
TELR = 65 dB
TELR = 60 dB
TELR = 55 dB
TELR = 50 dB
TELR = 45 dB
Exceptional
limiting case
Very
satisfactory
Satisfactory
Some users
dissatisfied
Many users
dissatisfied
User Satisfaction
TELR = Talker Echo Loudness Rating. Cuanto más atenuado el eco percibido (mayor valor en db de TELR), menor efecto tiene el eco sobre la degradación
58© Dr. Ing. José Joskowicz 2013
Efectos de la Demora y la Pérdida de paquetes
59© Dr. Ing. José Joskowicz 2013
Efectos de la Demora y la Pérdida de paquetes
60© Dr. Ing. José Joskowicz 2013
Estimación de A
Ejemplo de sistema de comunicación Valor máximo de A
Convencional (alámbrico) 0
Movilidad mediante redes celulares en un
edificio
5
Movilidad en una zona geográfica o en un
vehículo en movimiento
10
Conexión con lugares de difícil acceso, por
ejemplo, mediante conexiones de múltiples
saltos por satélite
20
61© Dr. Ing. José Joskowicz 2013
Factor R en paquetes RTCP
62© Dr. Ing. José Joskowicz 2013
Calidad de Video
� Varios tipos de degradaciones suelen presentarse en las señales de video transmitidas sobre redes de paquetes
� A su vez, varios tipos de degradaciones obedecen al método de codificación utilizado
� El estudio en esta área es todavía un tema de investigación.
63© Dr. Ing. José Joskowicz 2013
Degradaciones en video digital
� Efecto de bloques (blocking)� Efecto de imagen de base (basis image)� Borrosidad o falta de definición (Blurring)� Color bleeding (Corrimiento del color)� Efecto escalera y Ringing� Patrones de mosaicos (Mosaic Patterns)� Contornos y bordes falsos� Errores de Compensaciones de Movimiento (MC
mismatch)� Efecto mosquito� Fluctuaciones en áreas estacionarias� Errores de crominancia
64© Dr. Ing. José Joskowicz 2013
Pérdida de paquetes
65© Dr. Ing. José Joskowicz 2013
ITU-T G.1070: Opinion Model for video-telephony applications
� Aprobada por ITU-T en abril 2007, sobre la base de propuestas de NTT
� Propone un algoritmo de estimación de la calidad de video teléfonos en ambientes de redes de datos
� Para ser utilizada como herramienta de diseño o planificación
� Estima tres parámetros de calidad
� Sq Speech Quality
� Vq Video Quality
� MMq Multimedia Quality
66© Dr. Ing. José Joskowicz 2013
ITU-T G.1070 Framework
67© Dr. Ing. José Joskowicz 2013
ITU-T G.1070: Coeficientes para cada Codec
68© Dr. Ing. José Joskowicz 2013
ITU-T G.1070: Sq
� Básicamente se reduce al E-Model, simplificado
Q = Ro - Id – Ie,eff
Sq = f(Q), similar al E-Model
� Los efectos de la demora se incluyen en el MMq, y por lo tanto, se excluyen del Sq
69© Dr. Ing. José Joskowicz 2013
ITU-T G.1070: Vq
� Se propone
Ic = f (codec, bitrate, frame rate)
DPplV = f (codec, bitrate, frame rate)
Pplv
plv
D
P
cq eIV−
+= 1
70© Dr. Ing. José Joskowicz 2013
ITU-T G.1070: MMq
� Se propone
Calidad AudioVisual
MMSV = f (Vq, Sq)
Efectos de las demoras
MMT = f (Speech Delay, Video Delay)
4321 mMMMMmMMmMMmMM TSVTSVq +++=
© Dr. Ing. José Joskowicz 2013
Calidad de Servicioen Redes de Datos
Voz y Video en Redes IP
72© Dr. Ing. José Joskowicz 2013
Impacto de las aplicaciones Multimedia en las Redes IP
� La calidad percibida por los usuarios (Calidad de la Experiencia - QoE) se ve afectada por diversos factores
� Ancho de banda
� Pérdida de paquetes
� Demoras
� Jitter (Variación de la demora)
� Es necesario adecuar las redes de datos para soportar este tipo de aplicaciones, implementado estrategias de manejo de “calidad de servicio” (QoS Quality of Service)
73© Dr. Ing. José Joskowicz 2013
Calidad de Servicio (QoS)
� Técnicas utilizadas
� Priorización
� A nivel de capa 2, capa 3, capa 4, etc.
� Fragmentación
� Necesaria en enlaces de baja velocidad
� Control de los retardos máximos
� Fundamental para la calidad conversacional
74© Dr. Ing. José Joskowicz 2013
LAN
Problemas en enlaces de baja velocidad
WANRouter Router
1 Mb/s100 Mb/s
La diferencia de velocidades hace necesario formar
Colas
75© Dr. Ing. José Joskowicz 2013
ServersLAN
Problemas en enlaces compartidos
Switch Switch
Up-link100 Mb/s
La concurrencia sobre un mismo
“uplink” hace necesario formar
Colas
76© Dr. Ing. José Joskowicz 2013
LAN
Problemas en enlaces compartidos
WAN o Up-link
Cola
77© Dr. Ing. José Joskowicz 2013
Priorización
� Permite “marcar” tramas, paquete o cierto tipo de tráfico con diferentes prioridades
� En los switchs o routers se pueden formar varias “colas”, según las prioridades de los paquetes
78© Dr. Ing. José Joskowicz 2013
QoS en Capa 2
� Las recomendaciones IEEE 802.1q y IEEE 802.1p incorporan 4 bytes adicionales a las tramas Ethernet, donde se puede incluir información acerca de VLANs y etiquetas que identifican la “prioridad” de la trama.
79© Dr. Ing. José Joskowicz 2013
Tramas 802.1q
Preámbulo S
F
D
Dir
Origen
Dir
Destino
L Datos / Relleno FCS
SFD
7 1 6 6 2 2 2 46 – 1500 4
T
P
I
T
C
I
Preámbulo S
F
D
Dir
Origen
Dir
Destino
L Datos / Relleno FCS
SFD
7 1 6 6 2 46 – 1500 4
Trama normal
Trama 802.1q
Tag Protocol Identifier 81 00
Tag Control Information
80© Dr. Ing. José Joskowicz 2013
Campo TCITag Control Information
PR VLAN ID
CFI
TCI
3 1 12
� PR = Prioridad
� CFI = Canonical Format Indication
� VLAN ID = Identificador de VLAN (LAN Virtual)
81© Dr. Ing. José Joskowicz 2013
Prioridad en 802.1p
� Permite 8 prioridades: 0-7
82© Dr. Ing. José Joskowicz 2013
Prioridad en 802.1p
� Colas
Prioridad = 0
Prioridad = 1
Prioridad = 3
Prioridad = 4
Prioridad = 5
Prioridad = 6
Prioridad = 7
Salida (ordenada por prioridad)
83© Dr. Ing. José Joskowicz 2013
Estrategias de encolamiento y priorización
� FIFO (First In, First Out)� El primer paquete que haya ingresado en una cola, es el primero
en salir.
� PQ (Priority Queuing)� La salida de los paquetes se realiza según el orden estricto de
prioridad, y dentro de cada prioridad, según el orden de llegada. Este tipo de encolamiento puede hacer que, si existe siempre tráfico de alta prioridad, el tráfico de baja prioridad nunca sea enviado.
� FQ (Fair Queuing)� Es un esquema en el que cada cola se accede en forma circular,
asegurando una distribución uniforme de ancho de banda entre todas las colas.
84© Dr. Ing. José Joskowicz 2013
Estrategias de encolamiento y priorización
� WRR (Weighted Round Robin)
� Permite asignar diferentes anchos de banda a cada cola.
� WFQ (Weighted Fair Queuing)
� Es una combinación de PQ y FQ, garantizando que aplicaciones
de alto tráfico no monopolicen el enlace.
85© Dr. Ing. José Joskowicz 2013
VLAN
� Muchos switches de datos permiten implementar cierta priorización del tráfico basado en VLANs
� De esta forma, se puede poner a todos los dispositivos de VoIP en la misma VLAN, y darle prioridad frente al tráfico de otras VLANs, dedicadas a aplicaciones de datos
� Adicionalmente, en este caso el tráfico de voz no se ve afectado por el de datos
86© Dr. Ing. José Joskowicz 2013
QoS en Capa 3
� DiffServ (Differentiated Services) es comúnmente utilizado para gestionar prioridad en los paquetes
� La información de priorización se encuentra en el cabezal del paquete IP, en un campo llamado TOS (Type Of Service)
87© Dr. Ing. José Joskowicz 2013
Cabezal IP con TOS
� DSCP = Differentiated Services Code Point
� ECN = Explicit Congestion Notification
Versión TOS Largo total
4 4 8 16
Largo
del
cabezal
Resto del
cabezal IP
DSCP ECN
6 2
88© Dr. Ing. José Joskowicz 2013
DSCP
� Es posible codificar hasta 26 = 64 posibles prioridades.
� De éstas, 32 están reservadas para usos experimentales
� 32 pueden ser utilizadas
� 21 están estandarizadas por el IETF
� Las prioridades estandarizadas se dividen en 3 grupos
89© Dr. Ing. José Joskowicz 2013
� DE (DEfault)� Se asume el comportamiento por defecto, utilizando por tanto
técnicas de encolamiento de “mejor esfuerzo”. El valor típico de DSCP para este tipo de tráfico es 000000.
� AF (Assured Forwarding)� Estandarizado en el RFC 2597, donde se definen 4 clases de
prioridades dentro de este tipo de priorización.
� EF (Expedited Forwarding)� Estandarizado en el RFC 3246, establece las máximas
prioridades para el tráfico marcado con este identificador. El valor típico de DSCP utilizado es 101110 (46 decimal).
DSCP
90© Dr. Ing. José Joskowicz 2013
ECN
� Permite conocer el estado de congestión del destino.
� Es utilizado para que el destino pueda indicarle a la fuente, aún antes de perder paquetes, que existe cierto estado de congestión, de manera que la fuente pueda tomar los recaudos apropiados, por ejemplo, disminuyendo el ancho de banda utilizado.
� ECN = 11 indica que existe congestión
� ECN = 10 o 01 indican que no existe congestión.
� ECN = 00 indica que el extremo distante no soporta la función
de notificación de congestión.
91© Dr. Ing. José Joskowicz 2013
Otros mecanismos de priorización en Capa 3
� RSVP (Resource Reservation Protocol)
� Establece los mecanismos para reservar cierto ancho de banda en la comunicación entre dispositivos que pasen a través de routers.
� El tráfico también puede ser priorizado en base a la dirección IP de origen o destino.
� Esto puede ser implementado cuando se utilizan direcciones IP estáticas.
92© Dr. Ing. José Joskowicz 2013
QoS en Capa 4 y superiores
� Los paquetes de datos pueden ser priorizados en base a los puertos TCP o UDP. � Sin embargo, diferentes aplicaciones podrían utilizar
los mismos puertos, por lo que este tipo de priorizaciones debe ser evaluada en cada caso.
� Es posible también tener prioridades según el protocolo de capas superiores. � Por ejemplo, puede ser priorizado el tráfico RTP
respecto a otros, y asignarlo a las colas de alta prioridad.
93© Dr. Ing. José Joskowicz 2013
Fragmentación
Enlace de baja velocidad
Varias Colas Prioridad = 1
Prioridad = 2
� Las colas y prioridades no resuelven el problema de “paquetes largos sobre enlaces de baja velocidad”
� Es necesario “Fragmentar”
Paquete “largo” de baja prioridad
94© Dr. Ing. José Joskowicz 2013
Fragmentación
64 kb/s
WAN
ColasPaquete
de más de 1500 bytes
1.500 bytes / 64 kb/s =187 ms
95© Dr. Ing. José Joskowicz 2013
Fragmentación
Ethernet MTU Paq. de Voz
1500 32
Velocidad Tiempo Tiempo
[Kbps] [ms] [ms]
64 187,50 4,00
128 93,75 2,00
256 46,88 1,00
512 23,44 0,50
1024 11,72 0,25
2048 5,86 0,13
34000 0,35 0,01
155000 0,08 0,00
622000 0,02 0,00
Trama [Bytes]
Requiere fragmentación en las tramas de datos
96© Dr. Ing. José Joskowicz 2013
DTE
2 Mb
DTE64 Kb
64 Kb
Ttrans 187.5 / 12.5 ms 6 / 0,4 ms 187.5 / 12.5 msTcola (2 paq) 375 / 25 ms 12 / 0,8 ms 375 / 25 msCodec (G.723) 30 ms
Total paquete 1500 bytes (sin colas): 187.5 + 6 +187.5 =381 msTotal paquete voz 100 bytes G.723 (sin colas): 30 + 12.5 + 0.4 + 12.5 = 30 + 25.24 = 55.4 ms
Paq: 1500/100 bytes
Retardos punta a punta para la voz
© Dr. Ing. José Joskowicz 2013
VoWLANVoz y Video sobre Redes Inalámbricas
Voz, Video y Telefonía sobre IP
98© Dr. Ing. José Joskowicz 2013
VoWLAN
� Las tecnologías de voz sobre redes de datos inalámbricas se conocen generalmente como VoWLAN (Voice over Wireless LAN) o VoWi-Fi (Voz sobre Wi-Fi)
� Está comenzando a incrementarse la demanda de esta tecnología en el mercado corporativo
� Sin embargo, este tipo de tecnologías presentan desafíos adicionales para obtener una calidad aceptables
99© Dr. Ing. José Joskowicz 2013
Recomendaciones IEEE 802.11
Recomendación Año Descripción
802.11 1999 Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY)
802.11a 1999 Amendment 1: High-speed Physical Layer in the 5 GHz band
802.11b 1999 Higher speed Physical Layer (PHY) extension in the 2.4 GHz band
802.11b Cor1 2001 Higher-speed Physical Layer (PHY) extension in the 2.4 GHz band—Corrigendum1
802.11d 2001 Specification for Operation in Additional Regulartory Domains
802.11f 2003 Recommended Practice for Multi-Vendor Access Point Interoperability via an Inter-Access Point Protocol Across Distribution Systems…
802.11g 2003 Further Higher-Speed Physical Layer Extension in the 2.4 GHz Band
802.11h 2003 Spectrum and Transmit Power Management Extensions in the 5GHz band in Europe
802.11i 2004 Medium Access Control (MAC) Security Enhancements
802.11j 2004 4.9 GHz–5 GHz Operation in Japan
802.11x 2004 Based Network Access Control
802.11e 2005 Medium Access Control (MAC) Quality of Service Enhancements
802.11r 2008 Fast Basic Service Set (BSS) Transition
802.11n 2009 Amendment 5: Enhancements for Higher Throughput
100© Dr. Ing. José Joskowicz 2013
Arquitectura 802.11
AP AP
Distribution
System
Basic Service
Set (Celda)
Access Point
101© Dr. Ing. José Joskowicz 2013
Modelo de capas 802.11
802.11 PHY
802.11 MAC
802.11 PHY
802.11 MAC
802.3 PHY
802.3 MAC
AP
Ethernet
LANWireless
LLC Relay
102© Dr. Ing. José Joskowicz 2013
Velocidades en 802.11
Recomendación Año Velocidad máxima
802.11 1999 2 Mb/s
802.11a 1999 54 Mb/s
802.11b 1999 11 Mb/s
802.11g 2003 54 Mb/s
802.11n 2009 600 Mb/s
103© Dr. Ing. José Joskowicz 2013
Desafíos en VoWLAN
� Cobertura
� Movilidad
� Calidad de Servicio
� Capacidad
� Seguridad
104© Dr. Ing. José Joskowicz 2013
Cobertura
� La cobertura de las redes WLAN muchas veces se limita a las áreas donde se conectan los usuarios (salas de reuniones compartidas, recepción, etc.)
� Bajas señales de radio frecuencia son soportadas por las aplicaciones típicas de datos (correo electrónico, navegación en Internet, etc.), aún con tasas de errores elevadas
105© Dr. Ing. José Joskowicz 2013
Cobertura
� Las aplicaciones de telefonía móvil requieren una cobertura extendida, en escaleras, pasillos, áreas de descanso, y diversos sectores donde típicamente no eran áreas de trabajo para conexión de laptops
� Los AP deben ser ubicados de tal forma que sus áreas de cobertura se solapen lo suficiente para que no se produzcan cortes o interrupciones en la comunicación
106© Dr. Ing. José Joskowicz 2013
Movilidad
� El proceso de “Roaming” es lento.
� A nivel de cada 2:� búsqueda de un nuevo AP
� re-asociación
� re-autenticación (IEEE 802.11x )
� La re-autenticación es el proceso que mas demora (de cientos de milisegundos a varios segundos)
� La IEEE 802.11r (de 2008) mejora los tiempos de re-autenticación
107© Dr. Ing. José Joskowicz 2013
Movilidad
� A nivel de cada 3:
� búsqueda de un nuevo AP
� re-asociación
� re-autenticación (IEEE 802.11x )
� renovación de dirección IP
� La renovación de dirección IP puede llevar varios segundos (DHCP)
� Existen mecanismos propietarios para bajar estos tiempos
108© Dr. Ing. José Joskowicz 2013
Calidad de Servicio
� Cuando la red inalámbrica se comparte entre aplicaciones de voz y de datos, la calidad de la voz y el video pueden verse fuertemente afectadas, debido a que los paquetes de datos pueden ser excesivamente largos, a velocidades de transmisión relativamente bajas, generando por tanto demoras y jitter mayores a lo que se produce en redes cableadas
109© Dr. Ing. José Joskowicz 2013
Calidad de Servicio
� IEEE 802.11e (2005) establece dos nuevas estrategias de acceso al medio, para asegurar la calidad de servicio
� EDCA (Enhanced Distributed Control Access)
� Establece 4 categorías de acceso: voz, video, mejor
esfuerzo y “background”
� HCCA (Hybrid Controlled Channel Access)
� Sistema centralizado de control que permite a las
aplicaciones reservar recursos de red basados en sus
características de tráfico
110© Dr. Ing. José Joskowicz 2013
WMM – Wi-Fi Multi Media
� Basado en EDCA, establece 4 categorías de acceso
111© Dr. Ing. José Joskowicz 2013
WMM – Wi-Fi Multi Media
112© Dr. Ing. José Joskowicz 2013
Capacidad
� La cantidad máxima de llamadas en determinada área será función de la cantidad de usuarios en dicha área, y de las reglas de tráfico habituales en telefonía
� La capacidad de las redes WLAN está esencialmente determinada por la cantidad de canales de RF no solapados y la densidad de APs instalados
113© Dr. Ing. José Joskowicz 2013
Capacidad
� Agregando APs que utilicen canales de RF que no interfieran (que no se “solapen” en la frecuencia) se incrementa la capacidad en un área determinada � Si los canales se solapan, agregar más APs genera
interferencia de RF, lo que termina disminuyendo la capacidad.
� 802.11b/g tienen únicamente 3 canales de RF que no se solapan
� 802.11a tiene de 8 a 20 canales de RF que no se solapan
© Dr. Ing. José Joskowicz 2013
Protocolos de VoIPH.323
Voz y Video en Redes IP
115© Dr. Ing. José Joskowicz 2013
H.323
� Es un estándar “base” para las comunicaciones de audio, video y datos a través de redes IP que no proveen calidad de servicio garantizada
� La primera versión fue aprobada en 1996 por la ITU.
� La versión 7 fue aprobada en diciembre de 2009
� Es parte de las recomendaciones H.32x (como por ejemplo H.320 para ISDN y H.324 para la PSTN)
116© Dr. Ing. José Joskowicz 2013
Arquitectura de H.323
117© Dr. Ing. José Joskowicz 2013
Componentes de H.323
� Terminales
� Gateways (“pasarelas”)
� Gatekeepers
� Multipoint Control Units (“Unidades de control multipunto, para conferencias”)
118© Dr. Ing. José Joskowicz 2013
Terminales H.323
� Son los “telefonos multimedia IP”
� Deben soportar comununicaciones de voz, y opcionalmente comunicaciones de video y datos.
� Pueden ser equipos “stand alone” conectados directamente a la LAN, o software de PC.
119© Dr. Ing. José Joskowicz 2013
Alcance de H.323
Control
Audio Codec
G.711, G.722, G.723,
G.728, G.729
Video Codec
H.261, H.263
Intrerfaz de datos
T.120
Canal de control
H.245
Canal de
señalización
H,225.0 (Q.931)
Canal de RAS
H.225.0
RTP
RTCP
UDP
TCP
IP
Micrófono
Parlante
Cámara
Display
Equipos de
datos
Control
Interfaces de
usuario
Terminal H.323
120© Dr. Ing. José Joskowicz 2013
Estándares de Control
� H.245� Describe los mensajes y procedimientos para abrir y cerrar
canales lógicos para audio, video y datos, y para realizar el control de las comunicaciones
� Q.931 (H.225.0)� Protocolo de control de conexiones (similar a ISDN)
� RAS� Registration/Admission/Status: Protocolo de comunicacion con
el Gatekeeper
� RTP / RTCP� Real-Time Protocol / Real-Time Control Protocol : Protocolo que
define los procedimientos para manejar datos de tiempo real
121© Dr. Ing. José Joskowicz 2013
Gateways
� Realiza funciones de interconexión entre sistemas H.323 y sistemas de otro tipo (por ejemplo redes ISDN o PSTN)
122© Dr. Ing. José Joskowicz 2013
Gatekeeper
� Actúa como “punto central” de las llamadas de una determinada zona (como “PBX virtual”).
� Funciones de control:
� Traducción de “direcciones”
� Gerenciamiento del ancho de banda
� Ruteo de llamadas H.323
123© Dr. Ing. José Joskowicz 2013
� Traducción de direcciones
� De números de teléfonos o nombres a direcciones de red
� Control de Admisión
� Autorización de uso a los diversos dispositivos (terminales, gateways, MCUs)
� Control de Ancho de banda
� Manejo del ancho de banda permitido para cada servicio y/o terminal
Funciones obligatorias de Gatekeepers
124© Dr. Ing. José Joskowicz 2013
Funciones opcionales de Gatekeepers
� Autorización de llamadas
� Control de llamadas (con fines administrativos -costos)
� Control de la señalización
� Otras funciones, de acuerdo a criterios de los fabricantes
125© Dr. Ing. José Joskowicz 2013
Multipoint Control Units
� Soporta conferencias entre 3 o más puntos
� Consiste de:
� MC: Multipoint Controller
� Encargado de la señalización H.245 entre los terminales
� MP: Multipoint Processors
� Encargado de “mezclar” y procesar audio video y/o datos
126© Dr. Ing. José Joskowicz 2013
Tipos de conferencias
� Centralizadas
� Utiliza MCU para centralizar el control y contenido de la conferencia (dispone de MC y MP centralizado). La comunicación es siempre punto a punto
� Descentralizadas
� Utilizan la tecnología de “Multicast”, donde el audio y video es enviado por cada terminal a todos los otros (utiliza MC y no MP)
� Hibridas
� Conjuga los modos anteriores
127© Dr. Ing. José Joskowicz 2013
Esquema de un MCU en H.323
128© Dr. Ing. José Joskowicz 2013
H.323 en el modelo OSI
129© Dr. Ing. José Joskowicz 2013
Direct Call
130© Dr. Ing. José Joskowicz 2013
Direct Call
131© Dr. Ing. José Joskowicz 2013
Direct Call
132© Dr. Ing. José Joskowicz 2013
Direct Call
133© Dr. Ing. José Joskowicz 2013
Gatekeeper Routed
134© Dr. Ing. José Joskowicz 2013
Gatekeeper Routed
135© Dr. Ing. José Joskowicz 2013
Gatekeeper Routed
136© Dr. Ing. José Joskowicz 2013
Gatekeeper Routed
137© Dr. Ing. José Joskowicz 2013
Fast Connect
� Con este procedimiento el terminal que origina una llamada pude proponer un conjunto de canales de medios para su inmediata apertura en el mensaje de establecimiento (setup) H.225
� Se utiliza el campo “fastStart”, lo que permite encapsular mensajes de apertura de canales de medios H.245 (openLogicalChannel)
138© Dr. Ing. José Joskowicz 2013
Ejemplo de captura H.323
© Dr. Ing. José Joskowicz 2013
Protocolos de VoIPSIP
Voz y Video en Redes IP
140© Dr. Ing. José Joskowicz 2013
SIP
� En marzo de 1999 es aprobado el RFC 2543, por el grupo de estudio MMUSIC (Multiparty Multimedia Session Control ) del IETF, dando origen oficial al protocolo SIP (Session Initiaton Protocol)
� SIP tiene sus orígenes a fines de 1996, como un componente del “Mbone” (Multicast Backbone)� El Mbone, era una red experimental montada sobre la Internet,
para la distribución de contenido multimedia, incluyendo charlas, seminarios y conferencias de la IETF. Uno de sus componentes esenciales era un mecanismo para invitar a usuarios a escuchar una sesión multimedia, futura o ya establecida. Básicamente un “protocolo de inicio de sesión” (SIP).
� En junio de 2002, el RFC 2543 fue reemplazado por un conjunto de nuevas recomendaciones, RFC 3261-3266
141© Dr. Ing. José Joskowicz 2013
“Filosofía” de SIP
� Estándar de Internet
� Promocionado por IETF - http://www.ietf.org
� Reutilizar la tecnología de Internet:
� URLs, DNS, proxies
� Reutilizar el código HTTP
� Textual, sencillo de implementar y depurar
142© Dr. Ing. José Joskowicz 2013
Mensajería SIP
� La mensajería SIP está basada en el esquema “Request” – “Response” de HTTP.
� A diferencia de H.323, todos los mensajes son de texto plano, y por lo tanto fáciles de interpretar
� Para iniciar una sesión se envía un mensaje de “Request” a una contraparte de destino. El destino recibe el “Request”, y lo contesta con el correspondiente “Response”.
143© Dr. Ing. José Joskowicz 2013
RTP Audio G.729
RTP Video MPEG-1
ACK
BYE
180 Ringing
200 OK con SDP
200 OK
100 Tryinig
INVITE con SDP
sip:manuel@192.168.2.2 sip:nancy@192.168.2.4
SIP/2.0 100 Trying100 Tryinig
SIP/2.0 180 Ringing180 Ringing
SIP/2.0 200 OK
Medios SDP:G.729MPEG-I Video
200 OK con SDP
INVITE sip:nancy@192.168.2.4 SIP/2.0From: sip:manuel@192.168.2.2To: sip:nancy@192.168.2.4
Medios SDP:G.729MPEG-I Video
INVITE con SDP
ACK sip:nancy@192.168.2.4 SIP/2.0:5060ACK
BYE sip:nancy@192.168.2.4 SIP/2.0:5060BYE
SIP/2.0 200 OK200 OK
Establecimiento de la llamada
Flujo de datos
Finalización de la llamada
Ejemplo de una llamada SIP
144© Dr. Ing. José Joskowicz 2013
� Los mensajes de “Request” tiene el formato:
� <Método> <URL> <SIP-Version>
� Ejemplo: INVITE sip:nancy@fing.com SIP/2.0
Método Descripción
INVITE A session is being requested to be setup using a specified media
ACK Message from client to indicate that a successful response to an INVITE has been received
OPTIONS A Query to a server about its capabilities
BYE A call is being released by either party
CANCEL Cancels any pending requests. Usually sent to a Proxy Server to cancel searches
REGISTER Used by client to register a particular address with the SIP server
SUBSCRIBE Used to request status or presence updates from the presence server
NOTIFY Used to deliver information to the requestor or presence “watcher.”
SIP Requests
145© Dr. Ing. José Joskowicz 2013
Método Descripción
REFER Used to referring the remote user agent to a web page or another URI
MESSAGE Used to transport instant messages (IM) using SIP
UPDATE Used to modify the state of a session without changing the state of the dialog
INFO Used by a user agent to send call signaling information to another user agent with which it has an established media session
PRACK Provisional ACK. Used to acknowledge receipt of reliably transported
provisional responses (1xx)
SIP Requests
146© Dr. Ing. José Joskowicz 2013
� Las respuestsa SIP son del estilo HTTP:
� <SIP-Version> < Status-Code> <Reason>
� Ejemplo: SIP/2.0 404 Not Found
Respuesta Descripción
1xx Informational – Request received, continuing to process request.
(100 Trying 180 Ringing 181 Call is Being Forwarded …)
2xx Success – Action was successfully received, understood and accepted.
(200 OK )
3xx Redirection – Further action needs to be taken in order to complete the request.
4xx Client Error – Request contains bad syntax or cannot be fulfilled at this server.
5xx Server Error – Server failed to fulfill an apparently valid request.
6xx Global Failure – Request is invalid at any server.
SIP Responses
147© Dr. Ing. José Joskowicz 2013
Ejemplo: INVITE
INVITE sip:pepe@fing.com SIP/2.0
Via:SIP/2.0/UDP pc33.montevideo.com:5060;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Pepe <sip:pepe@fing.com>
From: Alicia <sip:alicia@abc.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.montevideo.com
CSeq: 314159 INVITE
Contact: <sip:alicia@pc33.montevideo.com>
Content-Type: application/sdp
Content-Length: 142
v=0
o=AGarcia 2890844526 2890842807 IN IP4 126.16.64.4
s=Phone Call
c=IN IP4 100.101.102.103
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
Cabezal
148© Dr. Ing. José Joskowicz 2013
Ejemplo: INVITE
INVITE sip:pepe@fing.com SIP/2.0
Via:SIP/2.0/UDP pc33.montevideo.com:5060;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Pepe <sip:pepe@fing.com>
From: Alicia <sip:alicia@abc.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.montevideo.com
CSeq: 314159 INVITE
Contact: <sip:alicia@pc33.montevideo.com>
Content-Type: application/sdp
Content-Length: 142
v=0
o=AGarcia 2890844526 2890842807 IN IP4 126.16.64.4
s=Phone Call
c=IN IP4 100.101.102.103
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
Cuerpo SDP
149© Dr. Ing. José Joskowicz 2013
Cabezal
� Tienen un formato del tipo Campo: Valor
� Via: SIP/<version>/<transporte> hostname:port;branch=<transaction
numer>Via:SIP/2.0/UDP pc33.montevideo.com:5060;branch=z9hG4bK776asdhds
� Max-Forwards: <numero>
� To: <dirección SIP>
� From: <dirección SIP>
150© Dr. Ing. José Joskowicz 2013
Direcciones SIP:
� Utiliza el formato de URLs de Internet
� Uniform Resource Locators
� El formato general es nombre@dominio
� Ejemplos:
� sip:pepe@fing.com.uy
� sip:Jose .M. Perez <pepe@fing.com.uy>
� sip:+598-2-7110978@fing.com.uy;user=phone
� sip:guest@10.64.1.1
Cabezal
151© Dr. Ing. José Joskowicz 2013
Cabezal
� Call-ID: <numero>@<Host>
� CSeq: <numero> <metodo>
� Contact: <dirección SIP>
� Content-Type: <tipo de contenido y formato del cuerpo>
� Content-Length: <largo del cuerpo>
152© Dr. Ing. José Joskowicz 2013
Cuerpo SDP
� El formato de cada renglón de SDP es <tipo>=<valor>
� <tipo> es siempre un único carácter, y se
diferencian mayúsculas de minúsculas
� El formato de <valor> depende del <tipo> al
que corresponda
153© Dr. Ing. José Joskowicz 2013
Cuerpo SDP
� Versión del protocolo (v)
� Origen (o)o=<username> <session id> <version> <network type>
<address type> <address>
� Nombre de la sesión (s)
� Datos de la conexión (c)
c=<network type> <address type> <connection address>
� Medios (m)
m=<media> <port> <transport> <fmt list>
154© Dr. Ing. José Joskowicz 2013
SIP Clients and Servers
� SIP utiliza una arquitectura cliente / servidor
� Elementos:
� SIP User Agents (Teléfonos SIP)
� SIP Servers
� SIP Gateways:
� Hacia la PSTN para interconectar el “mundo” SIP al “mundo” TDM
� Hacia H.323 para realizar interoperabilidad en el “mundo” IP
� Clientes – Origina mensajes
� Servidores – Responden a los mensajes o los redireccionan
155© Dr. Ing. José Joskowicz 2013
SIP Clients and Servers - 2
� Entidades lógicas SIP:
� User Agents
� User Agent Client (UAC): Inician requerimientos SIP
� User Agent Server (UAS): Retornan respuestas SIP
� Network Servers
� Registrar: Acepta registraciones de clientes
� Proxy: Decide el próximo salto y redirecciona el requerimiento
� Redirect: Envía la dirección del próximo salto al cliente
� Location: Servidor de búsqueda
� Presence: Servidor de presencia
156© Dr. Ing. José Joskowicz 2013
Ejemplos con Proxy Server
157© Dr. Ing. José Joskowicz 2013
server.fing.com
200 OK
BYE
200 OK
INVITE sip:pepe@fing.com.uy
host.fing.com
200 OK
ACK
INVITE sip:picard@abc.com
sip.abc.com
SIPUser AgentClient
SIPProxyServer
SIPUser AgentServer
Media Stream
Ejemplos con Proxy Server
158© Dr. Ing. José Joskowicz 2013
Ejemplos con Redirect Server
159© Dr. Ing. José Joskowicz 2013
302 Moved sip:pepe@ucla.com
ACK
Media Stream
INVITE sip:pepe@fing.com.uy
SIPUser AgentClient
SIPRedirectServer
180 Ringing
ACK
INVITE sip:pepe@ucla.com
SIPUser AgentServer
REGISTER pepe@ucla.com
host.fing.com.uy sip.ucla.com
200 OK
server.fing.com.uy
200 OK
CC
RS
UAS
1
2
3
Media Stream
Ejemplos con Redirect Server
160© Dr. Ing. José Joskowicz 2013
161© Dr. Ing. José Joskowicz 2013
Comparación H.323 - SIP
H.323 SIP
Standard de ITU RFC de IETF
Primera versión de 1996 Primer RFC de 1999
Originalmente diseñado para comunicaciones multimedia sobre redes
Originalmente diseñado para establecer sesiones
Mensajes con representación binaria Mensajes con representación textual
Protocolos complejos Protocolos simples
Basado en Q.931 (ISDN) No basado en protocolos telefónicos
Utiliza RTP y RTCP Utiliza RTP y RTCP
Amplia difusión, pero disminuyendo Amplia difusión, en aumento
© Dr. Ing. José Joskowicz 2013
Protocolos Propietarios de VoIP
Voz y Video en Redes IP
163© Dr. Ing. José Joskowicz 2013
� Es un protocolo de señalización propietario de Cisco, utilizado entre su servidor de telefonía (“Call Manager”) y los teléfonos.
SCCP (Skinny Call Control Protocol)
164© Dr. Ing. José Joskowicz 2013
� Es un protocolo de señalización propietario de Asterisk, utilizado para la conexión de varios servidores Asterisk, y también utilizando entre el servidor de telefonía Asterisk y los teléfonos.
� Está publicado en carácter informativo en el RFC 5456 de la IETF.
IAX2 (Inter-Asterisk eXchange protocol)
165© Dr. Ing. José Joskowicz 2013
Unistim
� Es un protocolo propietario de Avaya (antes Nortel).
� Originalmente fue diseñado como protocolo digital, y posteriormente migrada a IP
� Es utilizado entre los teléfonos Avaya y el componente “Session Manager”, parte del “core” de los sistemas Communication Server 1000
166© Dr. Ing. José Joskowicz 2013
NOE
� Es un protocolo Propietario de Alcatel: New Office Environment
� Se utiliza entre los teléfonos Alcatel y el procesador central de la PBX Alcatel
167© Dr. Ing. José Joskowicz 2013
168© Dr. Ing. José Joskowicz 2013
Aspectos de seguridad
� Aparecen nuevas vulnerabilidades y amenazas
� El medio (Audio o Video) utiliza RTP, y puede ser fácilmente capturado y decodificado
� Se puede cifrar el contenido (por ejemplo, usando SRTP – Secure RTP)
� La señalización puede ser fácilmente capturada y decodificada
� Se puede cifrar la señalización (por ejemplo, usando TLS – Transport Level Security)
169© Dr. Ing. José Joskowicz 2013
¿Está la red preparada?
� Es una pregunta que debe realizarse siempre, antes de implementar soluciones de voz, video o multimedia sobre IP
� “Network Assessment”
� Evaluación de la red, detectando la viabilidad o no de implementar determinada aplicación, típicamente de multimedia
� Varios aspectos deben ser considerados, incluyendo el desempeño, la disponibilidad y la seguridad
© Dr. Ing. José Joskowicz 2013
Gestión de Proyectos de VoIP
Voz, Video y Telefonía sobre IP
171© Dr. Ing. José Joskowicz 2013
Gestión de proyectos
172© Dr. Ing. José Joskowicz 2013
Procesos de Iniciación
� Desarrollo del “caso de negocio”
� Determinar el ROI (Retorno de la inversión)
� Establecer el alcance del proyecto, a alto nivel
� Identificar a los grupos de interés (“stakeholders”) y determinar sus necesidades y expectativas
� Identificar las restricciones conocidas
� Crear un “Project charter”, o acta de inicio del proyecto
173© Dr. Ing. José Joskowicz 2013
Procesos de Planificación
� Definición de un alcance detallado
� Estimación detalla del presupuesto y asignación del presupuesto
� Creación de la Estructura de Desglose del Trabajo (WBS)
� Identificación del camino crítico
� Desarrollo de los diversos planes de gestión del proyecto
� Identificación y cuantificación de riesgos
174© Dr. Ing. José Joskowicz 2013
Riesgos en VoIP
� Problemas de calidad de la voz
� Problemas de seguridad
� Infraestructuras de cableado que no soporten apropiadamente la nueva tecnología
� Infraestructura de red de datos que no soporte apropiadamente la nueva tecnología
� Incrementos no detectados en el tráfico
� Problemas técnicos de una tecnología emergente
175© Dr. Ing. José Joskowicz 2013
Network Assessment
� Muchos de estos riesgos se pueden minimizar realizando previamente un análisis del estado de la red, llamado habitualmente “network assessment”
� Permite detectar, de manera temprana, el estado de una infraestructura existente para el soporte de Voz y Video sobre IP
� Es altamente recomendable realizarlo en todo proyecto de VoIP
176© Dr. Ing. José Joskowicz 2013
Procesos de Ejecución
� Determinación y asignación de el o los equipos de trabajo asignados al proyecto
� Realizar y gestionar los contratos de sub contratistas, incluyendo los contratos de hardware, software y servicios.
� Implementación, de acuerdo al alcance detallado realizado en el proceso de planificación
177© Dr. Ing. José Joskowicz 2013
Procesos de Monitoreo y Control
� Monitorear y controlar el avance general del proyecto� Realizar la verificación y control de que se esté
cumpliendo con el alcance definido� Realizar un control de costos� Realizar controles de calidad� Tareas relativas a reportes de avances� Mantener los riesgos monitoreados y controlados. En
casos que corresponda, gestionar la implementación de las medidas correctivas previstas
� Administrar a los sub contratos� Realizar un control integral de cambios
178© Dr. Ing. José Joskowicz 2013
Monitoreo y Control en VoIP
� Los procesos de monitoreo y control en proyectos de VoIP deben tener especial cuidado en lo que respecta a la gestión de riesgos
� Siendo ésta una tecnología emergente, es posible que se
presenten inconvenientes no previstos y se deban tomar
acciones correctivas o de mitigación apropiadas
� Los problemas de integración o de “frontera” entre diversos sectores son frecuentes y muchas veces difíciles de prever en la etapa de planificación.
� Problemas no previstos de seguridad de la información pueden presentarse
179© Dr. Ing. José Joskowicz 2013
Procesos de Cierre
� Obtener la aceptación de los interesados
� Finalizar los sub-contratos
� Des-asignar a los equipos de trabajo y recursos del proyecto
� Documentar las lecciones aprendidas
� Archivar la documentación para referencias futuras
180© Dr. Ing. José Joskowicz 2013
Operación y Mantenimiento
� Una vez cerrado el proyecto, es recomendable realizar un análisis del éxito del mismo, las mejoras de la productividad y de costos obtenidas en la operación, y el grado de satisfacción de los usuarios.
� Hacer visibles estas mejoras ayudará a conseguir presupuesto para nuevas ampliaciones o futuros proyectos de tecnologías relacionadas.
181© Dr. Ing. José Joskowicz 2013
Operación y Mantenimiento
� Es conveniente realizar nuevamente un análisis de la red (network assessment), determinando su desempeño durante la operación
� Idealmente este tipo de estudios debe realizarse periódicamente
� una vez por mes o cada dos meses durante los primeros seis meses de operación y cada vez que se incorporan nuevos servicios o exista incrementos en el tráfico
© Dr. Ing. José Joskowicz 2013
Muchas Gracias!
Dr. Ing. José Joskowicz