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 PX 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
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
15© Dr. Ing. José Joskowicz 2013
CODECs de banda angosta
Codec NombreBit rate
(kb/s)
Retard
o (ms)Comentarios
G.711PCM: Pulse Code
Modulation64, 56 0.125
Codec “base”, utiliza dos posibles
leyes de compresión: µ-law y A-law
G.723.1Hybrid MPC-MLQ
and ACELP6.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.61.25
Creado para aplicaciones DCME
(Digital Circuit Multiplex Encoding)
G.729
CS-ACELP:
Conjugate
Structure
Algebraic
Codebook
Excited Linear
Prediction
11.8, 8,
6.415
Ampliamente 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 3
Inicialmente 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.8525.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,
9611.875
Amplí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 40
Codec 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-band32 a 128 40
Es el primer codec “fullband”
estandarizado por ITU
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
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, 16x8
8x8, 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.
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.)
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.
48© 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
51© 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
52© 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
53© 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)
55© 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
56© 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
58© 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
61© 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
63© 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.
64© 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
66© 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
69© 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
70© 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
71© 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
73© 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)
74© 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
75© 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
76© 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
78© 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
79© 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.
80© 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 00Tag Control Information
81© Dr. Ing. José Joskowicz 2013
Campo TCI
Tag Control Information
PR VLAN ID
CFI
TCI
3 1 12
PR = Prioridad
CFI = Canonical Format Indication
VLAN ID = Identificador de VLAN (LAN Virtual)
83© 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)
84© 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.
85© 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.
86© 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
87© 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)
88© 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
89© 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
90© 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
92© 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.
93© 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.
94© 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.
95© 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
96© 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
97© 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
98© 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 ms
Tcola (2 paq) 375 / 25 ms 12 / 0,8 ms 375 / 25 ms
Codec (G.723) 30 ms
Total paquete 1500 bytes (sin colas): 187.5 + 6 +187.5 =381 ms
Total 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
VoWLAN
Voz y Video sobre
Redes Inalámbricas
Voz, Video y Telefonía sobre IP
100© 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
101© Dr. Ing. José Joskowicz 2013
Recomendaciones IEEE 802.11
Resumen histórico
Recomendación Año Descripción
802.11 1997 Hasta 2 Mb/s en la banda de 2.4 GHz
802.11a 1999 Hasta 54 Mb/s en la banda de 5 GHz
802.11b 1999 Hasta 11 Mb/s en la banda de 2.4 GHz
802.11g 2003 Hasta 54 Mb/s en la banda de 2.4 GHz
802.11n 2009
Hasta 600 Mb/s en las bandas de 2.4 GHz y 5 GHz con
tecnología MIMO
802.11ac 2013
Hasta 1300 Mb/s en la banda de 5 GHz con tecnología
MultiUser-MIMO
102© Dr. Ing. José Joskowicz 2013
Arquitectura 802.11
AP AP
Distribution
System
Basic Service
Set (Celda)
Access Point
103© 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
104© Dr. Ing. José Joskowicz 2013
Capa Física 802.11
802.11
Especificada para 1 y 2 Mb/s, @ 2.4 GHz. Utiliza las
técnicas FHSS (Frequency Hopping Spread Spectrum) o
DSSS (Direct Sequence Spread Spectrum).
802.11b
Es una extensión de 802.11 y trabaja también a 5.5 y
11 Mb/s. Utiliza CCK (Complementary Code Keying) con
modulación QPSK (Quadrature Phase Shift Keying) y
tecnología DSSS (Direct-Sequence Spread Spectrum).
Soporta cambios de velocidad dinámicos
Se conoció como “Wi-Fi”
105© Dr. Ing. José Joskowicz 2013
Capa Física 802.11
802.11a Es una extensión de 802.11b, y trabaja hasta 54 Mb/s
en la banda de los 5 GHz. Utiliza técnicas demultiplexación ortogonal por división de frecuencia(OFDM), en vez de FHSS o DSSS.
802.11g Es una extensión de 802.11b, y trabaja hasta 54 Mb/s
en la misma banda que 802.11b (2.4 GHz). Utilizatécnicas de multiplexación ortogonal por división defrecuencia (OFDM).
106© Dr. Ing. José Joskowicz 2013
Capa Física 802.11
802.11n Incorpora técnicas de antenas MIMO (Multiple Input –
Multiple Output). Trabaja en las bandas de 2.4 GHz y5 GHz, con técnicas de modulación OFDM, llegandohasta 600 Mb/s
802.11ac Agrega la técnica MU-MIMO (Multi User MIMO),
llegando a velocidades de 1.3 Gb/s en la banda de 5GHz
107© Dr. Ing. José Joskowicz 2013
MIMO y MU-MIMO
108© Dr. Ing. José Joskowicz 2013
Desafíos en VoWLAN
Cobertura
Movilidad
Calidad de Servicio
Capacidad
Seguridad
109© 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
110© 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
111© 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
112© 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
113© 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
114© 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
115© Dr. Ing. José Joskowicz 2013
WMM – Wi-Fi Multi Media
Basado en EDCA, establece 4 categorías de
acceso
117© 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
118© 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
120© 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)
122© Dr. Ing. José Joskowicz 2013
Componentes de H.323
Terminales
Gateways (“pasarelas”)
Gatekeepers
Multipoint Control Units (“Unidades de control
multipunto, para conferencias”)
123© 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.
124© 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
125© 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
126© 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)
127© 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
128© 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
129© 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
130© 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
131© 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
142© 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)
145© 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
146© 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
147© 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”.
148© 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:[email protected] sip:[email protected]
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:[email protected] SIP/2.0From: sip:[email protected]: sip:[email protected]
Medios SDP:G.729MPEG-I Video
INVITE con SDP
ACK sip:[email protected] SIP/2.0:5060ACK
BYE sip:[email protected] 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
149© Dr. Ing. José Joskowicz 2013
Los mensajes de “Request” tiene el formato:
<Método> <URL> <SIP-Version>
Ejemplo: INVITE sip:[email protected] 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
150© 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
151© 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
152© Dr. Ing. José Joskowicz 2013
Ejemplo: INVITE
INVITE sip:[email protected] SIP/2.0
Via:SIP/2.0/UDP pc33.montevideo.com:5060;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Pepe <sip:[email protected]>
From: Alicia <sip:[email protected]>;tag=1928301774
Call-ID: [email protected]
CSeq: 314159 INVITE
Contact: <sip:[email protected]>
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
153© Dr. Ing. José Joskowicz 2013
Ejemplo: INVITE
INVITE sip:[email protected] SIP/2.0
Via:SIP/2.0/UDP pc33.montevideo.com:5060;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Pepe <sip:[email protected]>
From: Alicia <sip:[email protected]>;tag=1928301774
Call-ID: [email protected]
CSeq: 314159 INVITE
Contact: <sip:[email protected]>
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
154© 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>
155© 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:Jose .M. Perez <[email protected]>
sip:[email protected];user=phone
Cabezal
156© 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>
157© 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
158© 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>
159© 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
160© 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
162© Dr. Ing. José Joskowicz 2013
server.fing.com
200 OK
BYE
200 OK
INVITE sip:[email protected]
host.fing.com
200 OK
ACK
INVITE sip:[email protected]
sip.abc.com
SIPUser Agent
Client
SIPProxyServer
SIPUser
AgentServer
Media Stream
Ejemplos con Proxy Server
164© Dr. Ing. José Joskowicz 2013
302 Moved sip:[email protected]
ACK
Media Stream
INVITE sip:[email protected]
SIPUser Agent
Client
SIPRedirectServer
180 Ringing
ACK
INVITE sip:[email protected]
SIPUser Agent
Server
REGISTER [email protected]
host.fing.com.uy sip.ucla.com
200 OK
server.fing.com.uy
200 OK
C
RS
UAS
1
2
3
Media Stream
Ejemplos con Redirect Server
166© 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
168© 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)
169© 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)
170© 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 “Signaling Server”, parte del “core”
de los sistemas Communication Server 1000
171© 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