voz, video y telefonía sobre redes ip -...

Comunicaciones Corporativas Unificadas 2009 Voz, Video y Telefonía sobre IP

1

Voz, Video y Telefonía

Sobre redes IP

Ing. José Joskowicz


2

2Comunicaciones Corporativas Unificadas 2009 © Ing. José Joskowicz

Introducción

Voz, Video y Telefonía sobre IP


3

Comunicaciones Corporativas Unificadas 2009 © Ing. José Joskowicz 3


� Voz sobre redes de datos

� Video sobre redes de datos

� Calidad de voz sobre redes IP

� Calidad de video sobre redes IP

� Calidad de Servicio en redes de datos

� Voz y Video sobre Redes Inalámbricas

� Protocolos de VoIP� H.323

� SIP

� Gestión de proyectos de VoIP


4


Introducción

� ¿Por qué unificar?

� Bajar costos operativos

� Bajar costos de administración

� Mejorar las prestaciones

� Mejorar la productividad


5


Aumento de Tráfico de Voz de Larga Distancia Internacional (ILD)


6


Evolución de Precios de Larga Distancia Internacional (ILD)


7


Voz sobre Redes de Datos



8


Codificación de la voz

8 k bit/s speech (Conjugate structure- algebraic code excited linear prediction or CS-ACELP)

G.729

8.8 kb/s (Linear Prediction Coefficients LPC)RTAudio

Silence CompressionG.729 Annex B

Reduce Complexity G.729 Annex A

16 k bit/s speechG.728

Dual Rate Speed at 6.4 and 5.3 k bit/s G.723.1

7 kHz speed at 48, 56 and 64K bit/s (hi-fi voice)G.722

Audio encoding at 64 k bit/s (µ-law and A-law)G.711

DescripciónAlgoritmo


9


� Para poder transmitir las muestras

codificadas de voz sobre redes de datos, es necesario armar “paquetes”.

� Es necesario “juntar” varias muestras para

armar un paquete.

� Cada paquete tiene una cantidad mínima de

información (bytes) de control

� Cabezal del paquete

� Origen, destino

� Etc.

Paquetización de la voz


10


Transmisión de voz sobre redes de datos

Flujo de voz, 64 kb/s

RTP

UDP

IP

Ethernet

Sobrecarga

Ventana


11


RTP – Real Time Protocol

� Es un protocolo para tranmisión de datos de tiempo real (audio y video) sobre IP

� Está originalmente estandarizado en el RFC 1889, reemplazado por el RFC 3550

� Se basa en UDP


12


RTP - Cabezal

V PX CC M PT Sequence number

Timestamp

synchronization source (SSRC) identifier

contributing source (CSRC) identifiers

…….

32 bits


13


� Payload type (7 bits)

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

14 MPEG Audio Audio 90 kHz

15 G.728 Audio 8 kHz

18 G.729 Audio 8 kHz

26Motion JPEG

Video 90 kHz

31 H.261 Video 90 kHz

34 H.263 Video 90 kHz


14


� 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


15


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).


16


Ancho de banda para Ley A

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

26 bytes

IP (UDP + RTP)

40 bytes

20 ms de voz

160 bytes


17


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


18


Ancho de banda de LAN sin supresión de silencios

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 240 292 233,6

(64 kbps) 20 160 400 452 180,8

30 240 560 612 163,2

G.729 10 10 100 152 121,6

(8 kbps) 20 20 120 172 68,8

30 30 140 192 51,2

G.723.1

(6.3 kbps) 30 24 127 179 47,8

G.723.1

5.3 kbps 30 20 120 172 45,8


19


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 con supresión de silencios


20


Video sobre Redes de Datos



21


� JPEG (Joint Photographic Experts Group)� Diseñado para comprimir imágenes fijas, tanto en color como en blanco y negro

� Divide a la imagen en bloques de 8 x 8 píxeles, los que son procesados en forma independiente

� Dentro de cada uno de estos bloques, se aplica la transformada discreta de coseno (DCT) bidimensional, generando para cada bloque, una matriz de 8 x 8 coeficientes

Codificación de Video


22


� MPEG-1 � Originalmente diseñado por el “Moving Picture Experts Group” (MPEG) de la ISO

� Pensado para el almacenamiento y reproducción digital de aplicaciones multimedia desde dispositivos CD-ROM

� MPEG-2 � Pensado para proveer calidad de video desde la obtenida con NTSC/PAL y hasta HDTV, con velocidades de hasta 19 Mbps

Codificación de Video


23


Codificación en MPEG


24


Codificación en MPEG


25


MPEG-4 y AVC

� MPEG-4� Es la evolución de MPEG-1 y 2, y provee la tecnología base para la codificación en base a contenidos, y su almacenamiento, transmisión y manipulación

� Puede codificar múltiples “Objetos de video” (MVO –Multiple Video Objects)

� H.264/MPEG-4 Part 10 � JVT/H.26L/AVC (Advanced Video Coding) o H.264/AVC

� Con AVC, para una misma calidad de video, se logran mejoras en el ancho de banda requerido de aproximadamente un 50% respecto estándares anteriores


26


Comparación de codecs de video

NoSiSiSiCompatibilidad con estándares previos

AltaMediaMediaBajaComplejidad del codificador

64 kbps a 150 Mbps64 kbps a 2 Mbps2 a 15 Mbps< 1.5 MbpsAncho de banda

I,P,B,SI,SPI,P,BI,P,BI,P,B,DTipo de cuadros

385NoPerfiles

Si, con hasta 16 MVSiSiSiEstimación y compensación de movimiento

VLC, CAVLC, CABAC

VLCVLCVLCCodificación

4x48x88x88x8Tamaño de la muestra para aplicar la transformada

4x4 Integer transforDCT/DWTDCTDCTTransformada

8x8, 16x8, 8x16, 16x16, 4x8, 8x4,

4x4

16x168x8, 16x8

8x 88x8Tamaño del bloque

16x1616x1616x16, 16x816x16Tamaño del macro-bloque

H.264/MPEG-4 Part 10/AVC

MPEG-4MPEG-2MPEG-1Característica


27


Formatos de video

720 x 576SD

640 x 480VGA

1408 × 115216CIF

704 × 5764CIF

352 × 288CIF

176 × 144QCIF

128 × 96SQCIF

ResoluciónFormato


28


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


29


Calidad vs Ancho de Banda

CIF - MPEG-2

1

1.5

2

2.5

3

3.5

4

4.5

5

0 0.5 1 1.5 2 2.5 3 3.5 4

Bitrate (Mb/s)

MO

S

src2 src3

src4 src5

src7 src9

src10 src13

src14 src16

src17 src18

src19 src20

src21 src22


30


Calidad vs Ancho de Banda


31


“Tempete”


32


Calidad de Voz en Redes IP



33


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


34


Compresión

� El proceso de digitalización utilizado degrada la señal de voz.

� La degradación introducida depende de la técnica utilizada� Generalmente, a mayor “compresión” (menor ancho de banda), mayor degradación


35


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 videoes “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


36


� Se deben a:

� Algoritmos de compresió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

� Procesamiento

� Implementación de los protocolos

� Red (latencia)

� Velocidad de transmisión

� Congestión

� Demoras de los equipos de red (colas en routers,

gateways, etc.)

Demora (Delay)


37


Demora (Delay)

• Tiempo Total =

T algoritmo + T transmisión +

T propagación + T conmutación + T colas

– T algoritmo = función del CODEC

– T transmisión = función de la velocidad y tamaño de trama, paquete o

celda

– T propagación = función del medio de transmisión

– T conmutación = dependiente de la tecnología (store & foreward o cut-

through)

– Tiempo de colas = función de la ocupación, prioridad, tamaño y

velocidad


38


Demora (Delay)


39


� 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

Eco


40


� 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 grandesdeberán ser los buffers, y por lo tanto, mayor demoratotal tendrá el sistema.

Jitter


41


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


42


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


43


Métodos objetivos: ITU-T P.862

� La recomendación ITU-T P.862 presenta un método objetivo para la evaluación de la calidad vocal de extremo a extremo

� El método objetivo descrito se conoce por "evaluación de la calidad vocal por percepción" (PESQ, perceptual evaluation of speechquality).

� Se compara una señal inicial X(t) con una señal degradada Y(t) que se obtiene como resultado de la transmisión de X(t) a través de un sistema de comunicaciones (por ejemplo, una red IP).

� La salida de PESQ es una predicción de la calidad percibida por los sujetos en una prueba de escucha subjetiva que sería atribuida a Y(t).


44


ITU-T P.862


45


ITU-T P.862

� Lo esencial en este proceso es la

transformación de las dos señales, la inicial y la

degradada, en una representación interna que

intenta reproducir la representación psicoacústica de señales de audio en el sistema

auditivo humano.

� El modelo cognitivo de PESQ termina brindando una distancia entre la señal vocal inicial y la

señal vocal degradada (“nota PESQ”), la que

corresponde a su vez con una predicción de la

MOS subjetiva. La nota PESQ se hace

corresponder a una escala similar a la de MOS


46


Métodos objetivos: ITU-T P.563

� El algoritmo P.563 es aplicable para la

predicción de la calidad vocal sin una señal de

referencia independiente

� En comparación con la ITU-T P.862 que

compara una señal de referencia de elevada

calidad con la señal degradada en base a un

modelo perceptual, P.563 predice la calidad de la voz de una señal degradada sin una señal

vocal de referencia dada

� El enfoque utilizado en P.563 puede

visualizarse como un experto que escucha una

llamada real con un dispositivo de prueba


47


ITU-T P.563 vs ITU-T P.862

Señal de voz

de entrada

Señal de voz

de salida

Experiencia

Expectativa

SemanticaEvaluación

subjetiva

Canal en prueba

Evaluación intrusiva de la

calidad vocal (basada en

dos extremos)

Evaluación no intrusiva

de la calidad vocal

(basada en un extremo)

MOS

MOS

MOS


48


ITU-T P.563

� Trata de detectar tres clases de degradación de la señal de voz:� Desnaturalización de la voz

� Análisis del tracto vocal, tratando de identificar si existe una marcada “robotización”

� Análisis de ruidos adicionales intensos � SNR estática (nivel básico del ruido de fondo)

� SNR por segmentos de voz

� Interrupciones, silenciamientos y recortes temporales


49


ITU-T P.563

� Cada clase de distorsión utiliza una combinación lineal de varios parámetros, con lo que se genera una calidad vocal intermedia.

� La calidad vocal definitiva se calcula combinando los resultados de calidad vocal intermedia con algunas características adicionales de la señal.


50


Métodos objetivos: 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)


51


R versus MOS


52


Definición de “R”

� R = Ro - Is - Id – Ie,eff + 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 causado por las demoras

� Demoras, Jitter, Eco

� Ie,eff = Deterioro causado por el Codec y la pérdidas de paquetes

� A = Factor de Mejoras de Expectativas


53


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


54


Valores de Ie según el Codec

156.3G.723.1MP-MLQ

195.3G.723.1ACELP

118G.729-A + VAD

108G.729CS-ACELP

Speech Compression Codecs

240G.726, G.727ADPCM

064G.711PCM

Waveform Codecs

Ie ValueOperating Ratekbit/s

ReferenceCodec Type


55


Efectos del Codec y la Demora


56


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

dissatisf ied

Many users

dissatisf ied

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


57


Efectos de la Demora y la Pérdida de paquetes


58


Efectos de la Demora y la Pérdida de paquetes


59


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


60


Relación entre R y MOS

G.107_FB.2

Excelente 5

Buena 4

Mediocre 3

Pobre 2

Mala 1

0 20 40 60 80 100 R

MOS


61


Calidad de Video en Redes IP



62


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


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


Pérdida de paquetes


65


Demora / Jitter

� Aun no existe consenso en la influencia de las demoras en la calidad percibida

� Los Jitter-Buffer aportan un componente de demora apreciable en las aplicaciones de video

� Se han propuesto técnicas para bajar las demoras en el comienzo de la reproducción y aún así mantener Buffers“grandes”


66


Demora / Jitter


67


Medida de la calidad de video

� La manera más confiable de medir la calidad de una imagen o un video es la evaluación subjetiva, realizada por un conjunto de personas que opinan acerca de su percepción� El “MOS” (Mean Opinion Score) es la métrica generalmente aceptada como medida de la calidad


68


Medidas Objetivas de Calidad de video

� PSNR (Peak Signal to Noise Ratio)

[ ]∑∑∑= = =

−=N

n

M

m

T

t

tnmytnmxTMN

MSE1

2

1 1

),,(),,(1

MSERMSE=

=

MSE

LPSNR

2

10log10


69


Evaluaciones de imágenes comprimidas con JPEG

“Mandril” original y comprimida

MSE=163

“Tiffany” original y comprimida

MSE=165

“Lago” original y comprimida

MSE=167


70


Evaluación de imágenes comprimidas


71


Calidad de video

� Métodos objetivos� FR - Full Reference

� Se basan en la disponibilidad completa de la señal original

� RR – Reduced Reference� Se trata de enviar, junto con el video codificado, algunos parámetros que caractericen a la señal, y que sirvan de referencia en el receptor para poder estimar la calidad percibida

� NR - No Reference� Intentan estimar la calidad percibida basándose únicamente en el análisis de la señal recibida


72


VQEG

� El VQEG (Video Quality Expert Group) estállevando a cabo un gran trabajo sistemático y objetivo de comparación de modelos

� El objetivo del VQEG es proporcionar evidencia para los organismos internacionales de estandarización acerca del desempeño de diversos modelos propuestos, a los efectos de definir una métrica estándar y objetiva de calidad percibida de video digital (VQM – Video Quality Metric)


73


Areas de estudio de VQEG

� FR-TV (Full Reference TV)

� RRNR-TV (Reduced Reference, No Reference TV)

� Multimedia

� HDTV

� Hybrid Perceptual / Bitstream


74


VQEG FR-TV

� La ITU ha estandarizado en junio de 2004 a los cuatro mejores algoritmos en las recomendaciones ITU-T J.144 y ITU-R BT.1683� British Telecom BTFR (Reino Unido)

� Yonsei University/Radio Research Laboratory/SK Telecom (Corea)

� Centro de Investigación y Desarrollo en Telecomunicaciones (CPqD) (Brasil)

� National Telecommunications and InformationAdministration (NTIA)/Institute for TelecommunicationSciences (ITS) (Estados Unidos)


75


VQEG Multimedia

� Se han evaluado modelos del tipo FR, RR y NR para aplicaciones multimedia, en formatos de pantalla VGA, CIF y QCIF

� En total se presentaron 5 modelos, propuestos por NTT, OPTICOM, Psytechnics, SwissQual y Yonsei University

� Sobre la base de los resultados, se han publicado las recomendaciones ITU-T J.246 (RR) y ITU-T J.247 (FR).

� Los modelos NR no han presentado resultados lo suficientemente satisfactorios


76


VQEG HDTV

� El objetivo es evaluar modelos del tipo FR, RR y NR, para la predicción de la calidad de video percibida en aplicaciones de televisión digital de alta resolución (HDTV).

� Las pruebas se limitan a codecs MPEG-2 y H.264, incluyendo eventuales errores de transmisión.

� La resolución de pantalla a evaluar es 1080i @ 50/60 Hz y 1080p @ 25/30 fps

� Se espera tener los resultados para fines de 2009 o comienzos de 2010


77


Métodos objetivos: ITU-T G.1070

� Opinion Model for video-telephonyapplications� Es una recomendación reciente (Abril 2007)

� 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 planeación

� Estima tres parámetros de calidad� Sq Speech Quality

� Vq Video Quality

� MMq Multimedia Quality


78


ITU-T G.1070 Framework


79


ITU-T G.1070: Coeficientes para cada Codec


80


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


81


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


82


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 +++=


83


Calidad de Servicioen Redes de Datos



84


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)


85


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


86


LAN

Problemas en enlaces de baja velocidad

WANRouter Router

1 Mb/s100 Mb/s

La diferencia de

velocidades hace

necesario formar

Colas


87


ServersLAN

Problemas en enlaces compartidos

Switch Switch

Up-link100 Mb/s

La concurrencia sobre un mismo

“uplink” hace

necesario formar

Colas


88


LAN

Problemas en enlaces compartidos

WAN o

Up-link

Cola


89


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


90


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.


91


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


92


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)


93


Prioridad en 802.1p

� Permite 8 prioridades: 0-7


94


Prioridad en 802.1p

� Colas

Prioridad = 0

Prioridad = 1

Prioridad = 3

Prioridad = 4

Prioridad = 5

Prioridad = 6

Prioridad = 7

Salida (ordenada por prioridad)


95


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.


96


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.


97


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


98


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 OfService)


99


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


100


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


101


DSCP

� 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).


102


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.


103


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.


104


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.


105


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


106


Fragmentación

64 kb/s

WAN

ColasPaquete

de más de

1500

bytes1.500 bytes / 64 kb/s =187 ms


107


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


108


DTEDTE

2 Mb

DTEDTE64 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


109


VoWLANVoz y Video sobre Redes Inalámbricas



110


VoWLAN

� Las tecnologías de voz sobre redes de datos inalámbricas se conocen generalmente como VoWLAN (Voice overWireless 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


111


Recomendaciones IEEE 802.11

Fast Basic Service Set (BSS) Transition2008802.11r

Based Network Access Control 2004802.11x

Medium Access Control (MAC) Quality of Service Enhancements2005802.11e

4.9 GHz–5 GHz Operation in Japan2004802.11j

Medium Access Control (MAC) Security Enhancements2004802.11i

Spectrum and Transmit Power Management Extensions in the 5GHz band in Europe

2003802.11h

Further Higher-Speed Physical Layer Extension in the 2.4 GHz Band2003802.11g

Recommended Practice for Multi-Vendor Access Point Interoperability via an Inter-Access Point Protocol Across Distribution Systems…

2003802.11f

Specification for Operation in Additional Regulartory Domains2001802.11d

Higher-speed Physical Layer (PHY) extension in the 2.4 GHz band—Corrigendum1

2001802.11b Cor1

Higher speed Physical Layer (PHY) extension in the 2.4 GHz band1999802.11b

Amendment 1: High-speed Physical Layer in the 5 GHz band1999802.11a

Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY)1999802.11

DescripciónAñoRecomendación


112


Arquitectura 802.11

AP AP

DistributionSystem

Basic Service

Set (Celda)

Access Point


113


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


114


Velocidades en 802.11

600 Mb/s ?2010?802.11n

54 Mb/s2003802.11g

11 Mb/s1999802.11b

54 Mb/s1999802.11a

2 Mb/s1999802.11

Velocidad máximaAñoRecomendación


115


Desafíos en VoWLAN

� Cobertura

� Movilidad

� Calidad de Servicio

� Capacidad

� Seguridad


116


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


117


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


118


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


119


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


120


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 jittermayores a lo que se produce en redes cableadas


121


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


122


WMM – Wi-Fi Multi Media

� Basado en EDCA, establece 4 categorías de acceso


123


WMM – Wi-Fi Multi Media


124


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


125


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 APsgenera 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


126


Protocolos de VoIP

H.323



127


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 6 fue aprobada en junio de 2006

� Es parte de las recomendaciones H.32x (como por ejemplo H.320 para ISDN y H.324

para la PSTN)


128


Arquitectura de H.323


129


Componentes de H.323

� Terminales

� Gateways (“pasarelas”)

� Gatekeepers

� Multipoint Control Units (“Unidades de

control multipunto, para conferencias”)


130


Terminales H.323

� Son los “telefonos multimadia 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


131


Terminal H.323

Alcance de H.323

Control

Audio CodecG.711, G.722, G.723,

G.728, G.729

Video CodecH.261, H.263

Intrerfaz de datosT.120

Canal de controlH.245

Canal de señalización

H,225.0 (Q.931)

Canal de RASH.225.0

RTP RTCP

UDP

TCP

IP

MicrófonoParlante

CámaraDisplay

Equipos de datos

Control

Interfaces de usuario


132


Estándares de Audio

� G.711

� Codificación de la voz a 64 kb/s (Ley A o Ley

mu)

� G.729

� Codificación de la voz a 8 kbps utilizando

algoritmos de compresión del tipo

“Conjugate-Structure Algebraic-Code-Excited Linear Prediction (CS-ACELP)”

� G.723.1

� Codificación de la voz a 6.4 kbps y 5.3 kbps


133


Estándares de Video

� H.261� Algoritmos de digitalización y compresión de

video, utilizado para video conferencias. Utiliza multiplos de 64-kbits/s.

� H.263� Algoritmo de digitalización y compresión de

video, optimizado para bajas velocidades de datos y “poco” movimiento. H.263 es unamejora de H.261, diseñado para tenerbuenas calidades de video a velocidadesmenores a 64 kbits/sec.


134


Estándares de Datos

� T.120� Protocolos y servicios para comunicaciones de datos

en tiempo real entre varios puntos. Utilizado paracompartir documentos en video conferencias.


135


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)� 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


136


Gateways

� Realiza funciones de interconexión entre sistemas H.323 y sistemas de otro tipo

(por ejemplo redes ISDN o PSTN)


137


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


138


� 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


139


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


140


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


141


� 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

Tipos de conferencias


142


Esquema de un MCU en H.323


143


H.323 en el modelo OSI


144


Establecimiento de llamadasDirect Call


145




146




147




148


Establecimiento de llamadasGatekeeper Routed


149




150




151




152


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 (openLogicalChannal)


153


Protocolos de VoIP

SIP



154


SIP

� En marzo de 1999 es aprobado el RFC 2543, por el grupo de estudio MMUSIC del IETF, dando origen oficial al protocolo SIP (Session InitiatonProtocol)

� 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, entre las que se encuentran los RFC 3261 al 3266.


155


“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


156


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”.


157


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


158


SIP Requests

� Los mensajes de “Request” tiene el formato:

� <Método> <URL> <SIP-Version>

� Ejemplo: INVITE sip:[email protected] SIP/2.0

Used by client to register a particular address with the SIP serverREGISTER

Cancels any pending requests. Usually sent to a Proxy Server to cancel

searches

CANCEL

A call is being released by either partyBYE

A Query to a server about its capabilitiesOPTIONS

Message from client to indicate that a successful response to an INVITE

has been received

ACK

A session is being requested to be setup using a specified mediaINVITE

DescripciónMétodo


159


SIP Requests

Provisional ACK. Used to acknowledge receipt of reliably transported

provisional responses (1xx)

PRACK

Used by a user agent to send call signaling information to another user

agent with which it has an established media session

INFO

Used to modify the state of a session without changing the state of the

dialog

UPDATE

Used to transport instant messages (IM) using SIPMESSAGE

Used to referring the remote user agent to a web page or another URI REFER

Used to request status or presence updates from the presence serverSUBSCRIBE

Used to deliver information to the requestor or presence “watcher.”NOTIFY

DescripciónMétodo


160


SIP Responses

� Las respuestsa SIP son del estilo HTTP:

� <SIP-Version> < Status-Code> <Reason>

� Ejemplo: SIP/2.0 404 Not Found

Global Failure – Request is invalid at any server.6xx

Server Error – Server failed to fulfill an apparently valid request.5xx

Client Error – Request contains bad syntax or cannot be fulfilled at this

server.

4xx

Redirection – Further action needs to be taken in order to complete the

request.

3xx

Success – Action was successfully received, understood and accepted.

(200 OK )

2xx

Informational – Request received, continuing to process request.

(180 Ringing 181 Call is Being Forwarded )

1xx

DescripciónRespuesta


161


Ejemplo: INVITE

INVITE sip:[email protected] SIP/2.0

Via:SIP/2.0/UDP pc33.montevideo.com;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


162


Ejemplo: INVITE

INVITE sip:[email protected] SIP/2.0

Via:SIP/2.0/UDP pc33.montevideo.com;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


163


Cabezal

� Tienen un formato del tipo Campo: Valor

� Via: SIP/<version>/<transporte> hostnmae;branch=<transaction

numer>Via:SIP/2.0/UDP pc33.montevideo.com;branch=z9hG4bK776asdhds

� Max-Forwards: <numero>

� To: <dirección SIP>

� From: <dirección SIP>


164


Cabezal SIP

Direcciones SIP:

� Utiliza el formato de URLs de Internet

� Uniform Resource Locators

� El formato general es nombre@dominio

� Ejemplos:

� sip:[email protected]

� sip:Jose .M. Perez <[email protected]>

� sip:[email protected];user=phone

� sip:[email protected]


165


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>


166


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


167


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>

� Nombre de la sesión (s)

� Medios (m)

m=<media> <port> <transport> <fmt list>


168


SIP Clients and Servers - 1

� 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


169


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


170


Ejemplos con Proxy Server


171


Ejemplos con Proxy Server

server.fing.com

200 OK

BYE

200 OK

INVITE sip:[email protected]

host.fing.com

200 OK

ACK


sip.abc.com

SIPUser Agent

Client

SIPProxyServer

SIPUser AgentServer

Media Stream


172


Ejemplos con Redirect Server


173


302 Moved sip:[email protected]

ACK

Media Stream


SIPUser Agent

Client

SIPRedirectServer

180 Ringing

ACK


SIPUser Agent

ServerREGISTER [email protected]

host.fing.com.uy sip.ucla.com

200 OK

server.fing.com.uy

200 OK

CC

RS

UAS

1

2

3

Ejemplos con Redirect Server

Media Stream


174


Comparación H.323 - SIP

Utiliza RTP y RTCPUtiliza RTP y RTCP

Amplia difusión, en aumentoAmplia difusión, pero disminuyendo

No basado en protocolos telefónicosBasado en Q.931 (ISDN)

Protocolos simplesProtocolos complejos

Mensajes con representación textualMensajes con representación binaria

Originalmente diseñado para establecer

sesiones

Originalmente diseñado para

comunicaciones multimedia sobre redes

Primer RFC de 1999Primera versión de 1996

RFC de IETFStandard de ITU

SIPH.323


175



176


Gestión de Proyectos de VoIP

SIP



177


Gestión de proyectos


178


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


179


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


180


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


181


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


182


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 subcontratistas, incluyendo los contratos de hardware, software y servicios.

� Implementación, de acuerdo al alcance detallado realizado en el proceso de planificación


183


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


184


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


185


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


186


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.


187


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


188


Muchas Gracias!


Ing. José Joskowicz

voz, video y telefonía sobre redes ip -...

Documents