voz video y telefonia sobre ip

© Dr. Ing. José Joskowicz 2013

Voz y Video en Redes IP

Dr. Ing. José Joskowicz

[email protected]


Multimedia sobre Redes de Datos


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.


Flujo multimedia

RTP

UDP

IP

Ethernet

Sobrecarga

Ventana

Transmisión de multimedia sobre redes de datos

Sobrecarga


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


RTP - Cabezal

V P X CC M PT Sequence number

Timestamp

synchronization source (SSRC) identifier

contributing source (CSRC) identifiers

…….

32 bits

Version Padding eXtension CSRC count Payload Type


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


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

� …

� …


� 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


Ejemplo RTP: Paquete de audio


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


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


RTCP – Ejemplo de SR y SDES


Voz sobre Redes de Datos



CODECs de banda angosta

Codec NombreBit rate (kb/s)

Retardo (ms)

Comentarios

G.711PCM: Pulse Code Modulation

64, 56 0.125Codec “base”, utiliza dos posibles leyes de compresión: µ-law y A-law

G.723.1Hybrid MPC-MLQ and ACELP

6.3, 5.3 37.5

Desarrollado originalmente para video conferencias en la PSTN, es actualmente utilizado en sistemas de VoIP

G.728

LD-CELP: Low-Delay code excited linear prediction

40, 16, 12.8, 9.6

1.25Creado para aplicaciones DCME (Digital Circuit Multiplex Encoding)

G.729

CS-ACELP: Conjugate Structure Algebraic Codebook Excited Linear Prediction

11.8, 8, 6.4

15Ampliamente utilizado en aplicaciones de VoIP, a 8 kb/s


CODECs de banda ancha


Retardo (ms)

Comentarios

G.722 Sub-band ADPCM 48,56,64 3Inicialmente diseñado para audio y videconferencias, actualmente utilizado para de telefonía de calidad en VoIP

G.722.1 Transform Coder 24,32 40 Usado en audio y videoconferencias

G.722.2 AMR-WB6.6 a 23.85

25.9375

Estandar en común con 3GPP (3GPP TS 26.171). gran inmunidad a los ruidos de fondo en ambientes adversos (por ejemplo celulares)

G.711.1 Wideband G.71164, 80, 96

11.875Amplía el ancho de banda del codec G.711, optimizando su uso para VoIP

G.729.1 Wideband G.7298 a 32 kb/s

<49 ms

Amplía el ancho de banda del codec G.729, y es “compatible hacia atrás” con este codec. Optimizado su uso para VoIP con audio de alta calidad

RtAudio Real Time Audio 8.8, 18 40Codec propietario de Microsoft, utilizado en aplicaciones de comunicaciones unificadas (OCS)


CODECs de banda superancha


Retardo (ms)

Comentarios

SILK SILK 8 a 24 25 Utilizado por Skype


CODECs de banda completa


Retardo (ms)

Comentarios

G.719Low-complexity, full-band

32 a 128 40Es el primer codec “fullband” estandarizado por ITU


RTP – Paquete de audio


RTP – Ejemplo RFC 2833


RTP – Ejemplo Comfort Noise


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


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


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


Video sobre Redes de Datos



Comparación de codecs de videoCaracterística MPEG-1 MPEG-2 MPEG-4 H.264/MPEG-4

Part 10/AVC

Tamaño del macro-bloque 16x16 16x16, 16x8 16x16 16x16

Tamaño del bloque 8x8 8x 8 16x16

8x8, 16x88x8, 16x8, 8x16,

16x16, 4x8, 8x4, 4x4

Transformada DCT DCT DCT/DWT 4x4 Integer transfor

Tamaño de la muestra para

aplicar la transformada

8x8 8x8 8x8 4x4

Codificación VLC VLC VLC VLC, CAVLC, CABAC

Estimación y

compensación de

movimiento

Si Si Si Si, con hasta 16 MV

Perfiles No 5 8 3

Tipo de cuadros I,P,B,D I,P,B I,P,B I,P,B,SI,SP

Ancho de banda < 1.5 Mbps 2 a 15 Mbps 64 kbps a 2 Mbps 64 kbps a 150 Mbps

Complejidad del codificador Baja Media Media Alta

Compatibilidad con

estándares previos

Si Si Si No


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


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.


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


MPEG-2 sobre RTP

7 paquetes MTS (MPEG-2 Transport Stream)dentro de un mismo paquete RTP

Payload Type: MTS (MPEG-2 Transport

Stream)


MPEG-2 sobre RTP

Cabezal de MTS (4 bytes)

Payload de MTS (184 bytes)


H.264 sobre RTP

Payload del tipo “dinámico”

Payload de H.264(1430 bytes)


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


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


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


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)


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.


Calidad de Voz y Video



Evolución de la calidad percibida de la voz


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


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


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


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


Demora (Delay)


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.


Demora y Jitter


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


Eco


Cancelación de Eco

� ITU-T G.168: Digital Network Echo Cancellers


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


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


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)


R versus MOS


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


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


Efectos del Codec y la Demora


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


Efectos de la Demora y la Pérdida de paquetes


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


Factor R en paquetes RTCP


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.


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


Pérdida de paquetes


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


ITU-T G.1070 Framework


ITU-T G.1070: Coeficientes para cada Codec


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


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


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


Calidad de Servicioen Redes de Datos



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)


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


LAN

Problemas en enlaces de baja velocidad

WANRouter Router

1 Mb/s100 Mb/s

La diferencia de velocidades hace necesario formar

Colas


ServersLAN

Problemas en enlaces compartidos

Switch Switch

Up-link100 Mb/s

La concurrencia sobre un mismo

“uplink” hace necesario formar

Colas


LAN

Problemas en enlaces compartidos

WAN o Up-link

Cola


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


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.


Tramas 802.1q

Preámbulo S

F

D

Dir

Origen

Dir

Destino

L Datos / Relleno FCS

SFD

7 1 6 6 2 2 2 46 – 1500 4

T

P

I

T

C

I

Preámbulo S

F

D

Dir

Origen

Dir

Destino

L Datos / Relleno FCS

SFD

7 1 6 6 2 46 – 1500 4

Trama normal

Trama 802.1q

Tag Protocol Identifier 81 00

Tag Control Information


Campo TCITag Control Information

PR VLAN ID

CFI

TCI

3 1 12

� PR = Prioridad

� CFI = Canonical Format Indication

� VLAN ID = Identificador de VLAN (LAN Virtual)


Prioridad en 802.1p

� Permite 8 prioridades: 0-7


Prioridad en 802.1p

� Colas

Prioridad = 0

Prioridad = 1

Prioridad = 3

Prioridad = 4

Prioridad = 5

Prioridad = 6

Prioridad = 7

Salida (ordenada por prioridad)


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.


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.


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


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)


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


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


� 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


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.


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.


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.


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


Fragmentación

64 kb/s

WAN

ColasPaquete

de más de 1500 bytes

1.500 bytes / 64 kb/s =187 ms


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


DTE

2 Mb

DTE64 Kb

64 Kb

Ttrans 187.5 / 12.5 ms 6 / 0,4 ms 187.5 / 12.5 msTcola (2 paq) 375 / 25 ms 12 / 0,8 ms 375 / 25 msCodec (G.723) 30 ms

Total paquete 1500 bytes (sin colas): 187.5 + 6 +187.5 =381 msTotal paquete voz 100 bytes G.723 (sin colas): 30 + 12.5 + 0.4 + 12.5 = 30 + 25.24 = 55.4 ms

Paq: 1500/100 bytes

Retardos punta a punta para la voz


VoWLANVoz y Video sobre Redes Inalámbricas

Voz, Video y Telefonía sobre IP


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


Recomendaciones IEEE 802.11

Recomendación Año Descripción

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

802.11a 1999 Amendment 1: High-speed Physical Layer in the 5 GHz band

802.11b 1999 Higher speed Physical Layer (PHY) extension in the 2.4 GHz band

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

802.11d 2001 Specification for Operation in Additional Regulartory Domains

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

802.11g 2003 Further Higher-Speed Physical Layer Extension in the 2.4 GHz Band

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

802.11i 2004 Medium Access Control (MAC) Security Enhancements

802.11j 2004 4.9 GHz–5 GHz Operation in Japan

802.11x 2004 Based Network Access Control

802.11e 2005 Medium Access Control (MAC) Quality of Service Enhancements

802.11r 2008 Fast Basic Service Set (BSS) Transition

802.11n 2009 Amendment 5: Enhancements for Higher Throughput


Arquitectura 802.11

AP AP

Distribution

System

Basic Service

Set (Celda)

Access Point


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


Velocidades en 802.11

Recomendación Año Velocidad máxima

802.11 1999 2 Mb/s

802.11a 1999 54 Mb/s

802.11b 1999 11 Mb/s

802.11g 2003 54 Mb/s

802.11n 2009 600 Mb/s


Desafíos en VoWLAN

� Cobertura

� Movilidad

� Calidad de Servicio

� Capacidad

� Seguridad


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


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


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


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


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


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


WMM – Wi-Fi Multi Media

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


WMM – Wi-Fi Multi Media


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


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


Protocolos de VoIPH.323



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)


Arquitectura de H.323


Componentes de H.323

� Terminales

� Gateways (“pasarelas”)

� Gatekeepers

� Multipoint Control Units (“Unidades de control multipunto, para conferencias”)


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.


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


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


Gateways

� Realiza funciones de interconexión entre sistemas H.323 y sistemas de otro tipo (por ejemplo redes ISDN o PSTN)


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


� 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


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


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


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


Esquema de un MCU en H.323


H.323 en el modelo OSI


Direct Call


Gatekeeper Routed


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)


Ejemplo de captura H.323


Protocolos de VoIPSIP



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


“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


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


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


� 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


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


� 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


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


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


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>


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]

Cabezal


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>


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


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>


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


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


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 AgentClient

SIPProxyServer

SIPUser AgentServer

Media Stream

Ejemplos con Proxy Server


Ejemplos con Redirect Server


302 Moved sip:[email protected]

ACK

Media Stream


SIPUser AgentClient

SIPRedirectServer

180 Ringing

ACK


SIPUser AgentServer

REGISTER [email protected]

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

200 OK

server.fing.com.uy

200 OK

CC

RS

UAS

1

2

3

Media Stream

Ejemplos con Redirect Server


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


Protocolos Propietarios de VoIP



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


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


Unistim

� Es un protocolo propietario de Avaya (antes Nortel).

� Originalmente fue diseñado como protocolo digital, y posteriormente migrada a IP

� Es utilizado entre los teléfonos Avaya y el componente “Session Manager”, parte del “core” de los sistemas Communication Server 1000


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


Aspectos de seguridad

� Aparecen nuevas vulnerabilidades y amenazas

� El medio (Audio o Video) utiliza RTP, y puede ser fácilmente capturado y decodificado

� Se puede cifrar el contenido (por ejemplo, usando SRTP – Secure RTP)

� La señalización puede ser fácilmente capturada y decodificada

� Se puede cifrar la señalización (por ejemplo, usando TLS – Transport Level Security)


¿Está la red preparada?

� Es una pregunta que debe realizarse siempre, antes de implementar soluciones de voz, video o multimedia sobre IP

� “Network Assessment”

� Evaluación de la red, detectando la viabilidad o no de implementar determinada aplicación, típicamente de multimedia

� Varios aspectos deben ser considerados, incluyendo el desempeño, la disponibilidad y la seguridad


Gestión de Proyectos de VoIP

Voz, Video y Telefonía sobre IP


Gestión de proyectos


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


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


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


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


Procesos de Ejecución

� Determinación y asignación de el o los equipos de trabajo asignados al proyecto

� Realizar y gestionar los contratos de sub contratistas, incluyendo los contratos de hardware, software y servicios.

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


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


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


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


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.


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


Muchas Gracias!

Dr. Ing. José Joskowicz

voz video y telefonia sobre ip

Documents

jos joskowicz

mpeg audio audio

law audio

gsm audio

confort noise audio

protocolo rtp

ejemplo rtp

tiempo real audio