Redes Unificadas 2008

Redes Corporativas
Redes Unificadas Pgina 1

REDES UNIFICADAS

Ing. Jos Joskowicz
Instituto de Ingeniera Elctrica, Facultad de Ingeniera
Universidad de la Repblica
Montevideo, URUGUAY

Setiembre 2008
Versin 7
Redes Corporativas


1 Temario

1 Temario............................................................................................................ 2
2 Introduccin...................................................................................................... 4
3 Voz sobre redes de datos ................................................................................ 6
3.1 Codificacin de voz................................................................................... 6
3.1.1 G.711................................................................................................. 6
3.1.2 G.729................................................................................................. 6
3.1.3 G.723.1.............................................................................................. 7
3.1.4 RTAudio............................................................................................. 8
3.2 Transmisin de voz sobre redes de datos ................................................ 8
3.3 RTP Real-Time Transport Protocol ........................................................ 9
3.3.1 Versin (V)....................................................................................... 10
3.3.2 CSRC count (CC) ............................................................................ 11
3.3.3 Tipo de informacin (PT=Payload Type).......................................... 11
3.3.4 Nmero de secuencia (Sequence Number)..................................... 11
3.3.5 Marca de tiempo (Time Stamp)........................................................ 11
3.3.6 Identificador del origen (SSRC - Synchronization Source Identifier) 11
3.3.7 Identificador del tributario (CSRC - Contributing Sources Identifier) 12
3.4 RTCP RTP Control Protocol ................................................................ 12
3.5 Ancho de banda en IP para voz.............................................................. 12
4 Video sobre redes de datos ........................................................................... 15
4.1 Aplicaciones de video ............................................................................. 15
4.2 Codificacin de video.............................................................................. 15
4.2.1 JPEG ............................................................................................... 16
4.2.2 MPEG-x ........................................................................................... 17
4.3 Transmisin de video sobre redes de datos ........................................... 21
4.3.1 Paquetizacin del video................................................................... 21
4.3.2 Ancho de banda en IP para video.................................................... 21
5 Calidad de voz en redes IP............................................................................ 24
5.1 Factores que afectan la calidad de la voz sobre redes de paquetes ...... 24
5.1.1 Factor de compresin ...................................................................... 24
5.1.2 Prdida de paquetes........................................................................ 24
5.1.3 Demora............................................................................................ 24
5.1.4 Eco................................................................................................... 26
5.1.5 Variaciones en la demora (Jitter) ..................................................... 26
5.1.6 Tamao de los paquetes ................................................................ 26
5.2 Medida de la calidad de voz.................................................................... 27
5.3 Mtodos Subjetivos de medida de la calidad de voz .............................. 27
5.4 Mtodos Objetivos de medida de la calidad de voz ................................ 28
5.4.1 E-Model ........................................................................................... 28
5.4.2 ITU-T P.862 (PESQ) ........................................................................ 37
5.4.3 ITU-T P.563 ..................................................................................... 39
6 Calidad de video en redes IP......................................................................... 42
6.1 Factores que afectan la calidad del video sobre redes de paquetes ...... 42
6.1.1 Factor de compresin ...................................................................... 42
Redes Corporativas


6.1.2 Prdida de paquetes........................................................................ 43
6.1.3 Demora / Jitter ................................................................................. 45
6.2 Medida de la calidad perceptual de video............................................... 45
6.3 Mtodos Subjetivos de medida de la calidad de video............................ 46
6.4 Mtodos Objetivos de medida de la calidad de video............................. 47
6.4.1 El trabajo del VQEG......................................................................... 51
6.4.2 ITU-R BT.1683................................................................................ 54
7 Protocolos VoIP ............................................................................................. 55
7.1 H.323 ...................................................................................................... 55
7.1.1 Arquitectura H.323........................................................................... 55
7.1.1.1 Terminales................................................................................ 56
7.1.1.2 Gateways (Pasarelas) .............................................................. 61
7.1.1.3 Gatekeeper ............................................................................... 62
7.1.1.4 MCU Multipoint Control Unit (Unidad de control multipunto).. 63
7.2 SIP.......................................................................................................... 64
7.2.1 Mensajera SIP ................................................................................ 64
7.2.2 Arquitectura SIP............................................................................... 68
7.2.2.1 Terminales SIP......................................................................... 69
7.2.2.2 Servidores SIP.......................................................................... 69
7.2.2.3 Gateway SIP............................................................................. 72
8 Unificacin en el Backbone............................................................................ 73
8.1 Multipelxores........................................................................................... 73
8.2 Routers con placas de voz ................................................................... 74
8.3 PBX con Gateways IP .......................................................................... 74
8.4 Gateways IP independientes................................................................ 76
9 Unificacin en el Escritorio............................................................................. 77
9.1 CTI .......................................................................................................... 77
9.1.1 Microsoft TAPI ................................................................................. 78
9.1.2 JAVA JTAPI ..................................................................................... 79
9.1.3 CSTA............................................................................................... 80
9.1.4 ECMA TR/87.................................................................................... 82
9.2 Comunicaciones Unificadas.................................................................... 84
9.2.1 Componentes de las Comunicaciones Unificadas........................... 84
9.2.1.1 Escritorio Convergente ............................................................. 84
9.2.1.2 Presencia.................................................................................. 86
9.2.1.3 Mensajera Instantnea ............................................................ 87
9.2.1.4 Conferencias............................................................................. 87
9.2.1.5 Colaboracin............................................................................. 88
Referencias ........................................................................................................... 89

Redes Corporativas


2 Introduccin

Las redes de voz [1] y las redes de datos [2] presentan tecnologas muy dismiles.
Por un lado, la transmisin de voz, con una historia de ms de 100 aos, se basa
en el establecimiento de vnculos permanentes entre dos puntos, diseados para
transmitir un tipo de seal especfico: la voz humana, tpica seal analgica, de
ancho de banda acotado, que debe llegar a destino inmediatamente y ser lo ms
inteligible posible. Por otro lado, la transmisin de datos, con una relativa reciente
historia, se basa en la transmisin de informacin digital, sin establecer vnculos
permanentes, y donde los retardos no son generalmente importantes.

La integracin de estas dos tecnologas no parece algo sencilla, y cabe
preguntarse si existe alguna ventaja en realizar el intento. Las ventajas aparecen
al analizar por los menos los siguientes tres aspectos:

El primero aspecto es econmico: es posible ahorrar dinero al integrar las
tecnologas. El segundo aspecto es de administracin: es ms sencillo administrar
un nico sistema que dos independientes. Ambos aspectos son importantes, y las
Empresas, tanto desarrolladoras, como consumidoras de tecnologa estn
haciendo una fuerte apuesta a esta integracin. El tercer aspecto, y quizs a nivel
del usuario presente las ventajas ms relevantes, tiene que ver con la mejora en
las aplicaciones. Las nuevas tecnologas de unificacin de redes permitirn a los
usuarios disponer de facilidades que hasta hace un tiempo no eran posibles.

La primera etapa en la integracin se ha dado, no casualmente, en la transmisin
a distancia. La transmisin a distancia est directamente relacionada con gastos
mensuales, ya sean fijos, o por utilizacin. Bajar estos costos, incide directamente
en los costos operativos de las Empresas.

La primera integracin de estas redes, existe desde hace muchos aos: Los
MoDems (Moduladores / Demoduladores) utilizan las redes telefnicas para la
transmisin de datos a distancia. Dado que las redes telefnicas existen desde
mucho antes que las de datos, resulta entendible que las primeras transmisiones
de datos a distancia utilizaran como soporte estas redes. Para ello se disearon
los mdems, encargados de adaptar la informacin de datos al medio telefnico.
Como ste ltimo esta diseado para seales analgicas, de hasta 3.4 kHz de
ancho de banda, los mdems utilizan tonos" dentro de esta banda para enviar los
datos que desean transmitir. De esta manera, se utilizan los enlaces telefnicos,
generalmente disponibles y ya amortizados, para transmitir espordicamente
datos.

Con el incremento de la cantidad computadoras y la baja de sus precios, vino
aparejado la creciente necesidad de intercambio de informacin (datos), y la
comunicacin va mdem est limitada por las propias caractersticas de la red
telefnica: el teorema de Shannon limita la cantidad de informacin por segundo
que se puede transitar por un enlace de este tipo, a menos de 60 kb/s.
Redes Corporativas


Luego de algn tiempo, con el crecimiento de la necesidad de transmitir datos,
surgieron las primeras redes a distancia de transmisin de datos. Estas redes,
inicialmente punto a punto, permitieron aumentar la velocidad en la transmisin
de datos, con un costo fijo mensual para las empresas. En este caso, los enlaces
de datos, no estn limitados por el bajo ancho de banda de los enlaces
telefnicos.

Con la creciente demanda de transmisin de datos, estos enlaces se
incrementaron, ofreciendo mayores capacidades y bajando sus costos. Hasta el
punto en que, en conjunto con las tecnologas de compresin de voz, resulta
actualmente ms econmico utilizar enlaces de datos para transmitir
conversaciones telefnicas.

De esta manera, se invirti la situacin inicial: de utilizar la red telefnica para
cursar datos, se utiliza la red de datos, para cursar trfico de voz.

Comenzaremos por presentar los problemas tecnolgicos que aparecen al cursar
trfico de voz y video sobre redes de datos. Luego se presentarn las tecnologas
utilizadas para la unificacin de las redes en el backbone y en el escritorio.

Redes Corporativas


3 Voz sobre redes de datos

3.1 Codificacin de voz

La voz es codificada digitalmente para su transmisin. Los dispositivos de
codificacin y decodificacin se denominan CoDec (Codificadores /
Decodificadores).

La siguiente tabla resume los algoritmos de compresin de voz ms conocidos.

Algoritmo Descripcin
G.711 Audio encoding at 64 k bit/s (-law and A-law)
G.722 7 kHz speed at 48, 56 and 64K bit/s (hi-fi voice) [3]
G.723.1 Dual Rate Speed at 6.4 and 5.3 k bit/s
G.728 16 k bit/s speech [4]
G.729 Annex A
8 k bit/s speech (Conjugate structure- algebraic code excited
linear prediction or CS-ACELP). Reduce Complexity
G.729 Annex B
linear prediction or CS-ACELP). Silence Compression
G.729 Annex AB
linear prediction or CS-ACELP). Reduce Complexity & Silence
Compression
RTAudio 8.8 kb/s (Linear Prediction Coefficients LPC)

Algunos de estos algoritmos son descritos a continuacin

3.1.1 G.711

El codec bsico en telefnica es el estandarizado en la recomendacin G.711 de
la ITU-T [5], implementando la ley A o ley . Mediante esta codificacin se
obtiene una seal digital de 64 kb/s. La descripcin de este codec puede verse en
[1].

Cuando se dispone de velocidades de red reducidas, es conveniente tratar de
minimizar el ancho de banda requerido por las seales de voz. Para ello, se han
desarrollado varias recomendaciones, que reducen la velocidad de transmisin
requerida, a expensas de degradar la calidad de la voz.

3.1.2 G.729

El codec G.729 [6] es un estndar de codificacin para seales de audio
desarrollado por la ITU, codificando las seales de voz a 8 kbit/s utilizando CS-
ACELP (Conjugate-Structure Algebraic-Code-Excited Linear-Prediction).

Se basa en el modelo CELP [7] operando con ventanas de audio de 10 ms
correspondientes a una cantidad de 80 muestras (ya que la frecuencia de
Redes Corporativas


muestreo es de 8.000 muestras por segundo). CELP no conserva la forma de
onda, sino que codifica el audio en base a caractersticas del odo y de la voz
humana. Dado que el odo no detecta directamente la forma de onda, se genera
una nueva forma de onda que reproduce la voz en base a instrucciones. As se
tiene una tabla de posibles tonos generados por las cuerdas vocales (fonemas) y
otra con filtros que modelan la posicin del tracto vocal (boca, faringe, laringe y
lengua), que filtran los tonos generados por las cuerdas vocales. Las seales
enviadas se llaman descriptores y son una combinacin de fonemas y filtros.

El modelado de la boca y la garganta se hace por medio de filtros lineales y la voz
se genera a partir de una vibracin peridica de aire que los excita. El proceso por
el cual se extraen los parmetros del filtro y de la excitacin se llama Analysis-by-
Synthesis, AbS. El codificador busca los parmetros y realiza una decodificacin
interna (seal sintetizada) para comparar con la seal original. Se eligen los
parmetros que concuerdan mejor y se los enva al decodificador.

Cada 10 ms se extraen los parmetros del modelo CELP (coeficientes del filtro
lineal predictivo, cdigos adaptativos y fijos, ganancias). A partir de estos se
computan los coeficientes LP, se convierten a LSP (Line Spectrum Pairs) y se
cuantizan usando vectores predictivos de dos etapas (VQ).

Dado que a la salida del codificador la tasa de bits es de 8 kbit/s y se toman
cuadros de 10 ms, se usan 80 bits (10 bytes) para representar a cada cuadro o
ventana de audio en G.729.

En el anexo A de la recomendacin G.729 se define una variante de este codec
logrando as un codec de menor complejidad llamado G.729A. Este es
interoperable con G.729, pudindose utilizar un codificador G.729A con un
decodificador G.729 y viceversa. Los cambios respecto a la versin original se
deben a simplificaciones en los algoritmos empleados. La reduccin de la
complejidad incluye la sustitucin de algunos bloques de procesamiento por otros
ms sencillos. Tambin incluye el mantener fijos parmetros que en la versin
completa del codec varan dependiendo del audio a codificar.

El Anexo B de la recomendacin G.729 B provee deteccin de actividad de voz y
silencios y modelado y regeneracin del ruido de fondo, lo que redunda en una
disminucin del ancho de banda total utilizando, ya que no se transmiten muestras
durante los perodos de silencio.

3.1.3 G.723.1

El codec G.723.1 [8] es un estndar de codificacin para seales de audio
desarrollado por la ITU, codificando las seales de voz a 6.4 o 5.3 kbit/s. Utiliza
ventanas de audio de 30 ms.

Redes Corporativas


Para la codificacin a 6.4 kb/s se utiliza un algoritmo MPC-MLQ (Multi-Pulse
Maximum Likelihood Quantization), generando 24 bytes por cada ventana de 30
ms. Para la codificacin a 5.3 kb/s se utiliza ACELP, generando 20 bytes por cada
ventana de 30 ms.

El retardo total (latencia) del algoritmo es de 37.5 ms, ya que, una vez recibida la
ventana de 30 ms, el algoritmo requiere de 7.5 segundos de muestras adicionales.

El Anexo A de la recomendacin G.723.1 provee modelado y regeneracin del
ruido de fondo, lo que redunda en una disminucin del ancho de banda total
utilizando, ya que no se transmiten muestras durante los perodos de silencio.

3.1.4 RTAudio

El codec RTAudio [9], desarrollado por Microsoft, est comenzando a ser utilizado
comercial y corporativamente. Utiliza un ancho de banda de 8.8 k bit/s, con
tcnicas LPC (Linear Prediction Coefficients).

RTAudio utiliza tcnicas de codificacin VBR (Variable Bit Rate), lo que significa
que no todas las ventanas o cuadros de voz se codifiquen con la misma cantidad
de bytes.

El retardo total (latencia) del algoritmo es menor a 40 ms

3.2 Transmisin de voz sobre redes de datos

Para poder transmitir las muestras codificadas de voz sobre redes de datos, es
necesario armar paquetes. Si la voz est codificada con ley A, una conversacin
consiste en un flujo de 64 kb/s. Cada muestra dura 125 s. Si bien se podra
formar un paquete con cada muestra de voz, esto generara un sobrecarga
(overhead) demasiado importante (recordar que cada paquete requiere de
cabezales). Por otro lado, si se espera a juntar demasiadas muestras de voz,
para formar un paquete con mnima sobrecarga porcentual, se pueden introducir
retardos no aceptables. Un paquete IP puede tener hasta 1500 bytes de
informacin. Si con muestras de 64 kb/s se quisiera completar los 1500 bytes del
paquete IP, se introducira un retardo de 125s x 1500 = 187,5 ms. Esta demora
no es aceptable en aplicaciones de voz.

Por esta razn, se toman generalmente ventanas de 10 a 30 ms. Las muestras
de voz de cada una de estas ventanas consecutivas se juntan y con ellas se
arman paquetes. El tamao de estas ventanas es configurable para algunos
algoritmos de codificacin, y est estandarizado para otros.

Redes Corporativas


3.3 RTP Real-Time Transport Protocol

El protocolo RTP, basado en el RFC 3550 [10], establece los principios de un
protocolo de transporte sobre redes que no garantizan calidad de servicio para
datos de tiempo real, como por ejemplo voz y video.

El protocolo establece la manera de generar paquetes que incluyen, adems de
los propios datos de tiempo real a transmitir, nmeros de secuencia, marcas de
tiempo, y monitoreo de entrega. Las aplicaciones tpicamente utilizan RTP sobre
protocolos de red no confiables, como UDP. Los bytes obtenidos de cada
conjunto de muestras de voz o video son encapsulados en paquetes RTP, y cada
paquete RTP es a su vez encapsulado en segmentos UDP.

RTP soporta transferencia de datos a destinos mltiples, usando facilidades de
multicast, si esto es provisto por la red.

Flujo de voz, 64 kb/s
Ventana
Redes Corporativas


Cada paquete RTP consiste en un cabezal y los datos de voz. El cabezal contiene
nmeros de secuencia, marcas de tiempo, y monitoreo de entrega. El formato de
ste cabezal es el mostrado en la figura

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

Los campos ms relevantes son:

3.3.1 Versin (V)
La versin actual del protocolo es la 2.

Flujo de voz, 64 kb/s

RTP
UDP
IP
Ethernet
Sobrecarga
Ventana
V P X CC M PT Sequence number
Timestamp
synchronization source (SSRC) identifier
contributing source (CSRC) identifiers
.
Redes Corporativas


3.3.2 CSRC count (CC)
El campo indica la cantidad de identificadores CSRC incluidos en el cabezal (0 a
15, ver 3.3.7 )

3.3.3 Tipo de informacin (PT=Payload Type)
El campo payload identifica el tipo de informacin que viaja en el paquete. Es un
campo de 7 bits, lo que permite diferenciar hasta 128 tipos de informacin. En
audio, este campo indica el tipo de codificacin. Los valores de este campo se
definen en el RFC 3551 [11]. Algunos valores de ejemplo se muestran en la
siguiente tabla

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

3.3.4 Nmero de secuencia (Sequence Number)
El campo correspondiente al nmero de secuencia es de 16 bits. Con cada
paquete enviado, el emisor incrementa en uno el nmero de secuencia. Esto
permite al receptor detectar paquetes perdidos, o fuera de orden.

3.3.5 Marca de tiempo (Time Stamp)
Este campo es de 32 bits. Indica el momento al que corresponde la primer
muestra de la ventana de informacin que viaja en el paquete. Este campo es
utilizado por el receptor, para reproducir las muestras con la misma cadencia con
las que fueron obtenidas. Es a su vez til para medir el jitter (ver Error! No se
encuentra el origen de la referencia.). En audio, el campo Time Stamp se mide
en unidades de 125 s (o sea, en unidades de muestreo). Si por ejemplo un
paquete de 160 bytes de audio en Ley A contiene el campo TimeStamp con el
valor 1, el siguiente paquete contendr el campo TimeStamp en 160.

3.3.6 Identificador del origen (SSRC - Synchronization Source Identifier)
El campo correspondiente al SSRC es de 32 bits. Tpicamente cada flujo en una
sesin RTP tiene un identificador diferente. El origen establece este nmero,
asegurando que no se repita.

Redes Corporativas


3.3.7 Identificador del tributario (CSRC - Contributing Sources Identifier)
Pueden existir hasta 15 campos CSRC, de acuerdo al valor de CC. Esta lista
identifica a cada uno de los interlocutores cuando el audio que se enva es
producido en un mezclador o mixer (por ejemplo, cuando se enva el audio de
varios participantes de una conferencia)

3.4 RTCP RTP Control Protocol

El RFC 3550 establece, adems del protocolo RTP, un protocolo de control,
RTCP, encargado de enviar peridicamente paquetes de control entre los
participantes de una sesin. El protocolo RTCP tiene las siguientes funciones
principales:

Proveer realimentacin acerca de la calidad de los datos distribuidos (por
ejemplo, de la calidad percibida de VoIP). Esta realimentacin permite
adaptar dinmicamente la codificacin, o tomar acciones tendientes a
solucionar problemas cuando se detecta degradacin en la calidad de la
comunicacin
Transporte del CNAME (Canonical Name) de cada originador. Este
identificador permite asociar varios flujos RTP con el mismo origen (por
ejemplo, flujos de audio y video provenientes del mismo emisor)
Adaptar dinmicamente la frecuencia de envo de paquetes de control
RTCP de acuerdo al nmero de participantes en la sesin. Dado que los
paquetes se deben intercambiar todos contra todos, es posible saber
cuantos participantes hay, y de esta manera calcular la frecuencia de
envos de esto paquetes.

3.5 Ancho de banda en IP para voz

Dado que para el envo de voz sobre redes es necesario armar paquetes, el
ancho de banda requerido depender de la sobrecarga (overhead) que generen
estos paquetes.
Como se ha visto, para el envo de voz sobre redes de paquetes se utiliza el
estndar RTP. ste protocolo a su vez se monta sobre UDP, el que a su vez se
monta sobre IP, el que, en la LAN, viaja sobre Ethernet

Ethernet
26 bytes
IP (UDP + RTP)
40 bytes
20 ms de voz
160 bytes
Redes Corporativas


Esta suma de protocolos hace que el ancho de banda requerido para el trfico de
voz sobre Ethernet sea bastante mayor al ancho de banda del audio.
Para una ventana de 20 ms, y con codificacin de audio Ley A, se obtienen 160
bytes de voz por trama

Bytes de voz/trama = 64 kb/s * 20 ms / 8 = 160 bytes

El paquete IP (incluyendo los protocolos RTP y UDP) agregan 40 bytes
adicionales

Bytes de paquete IP = 160 + 40 = 200 bytes

La trama Ethernet agrega otros 26 bytes:

Bytes de Trama Ethernet = 200 + 26 = 226 bytes

En este ejemplo, cada 20ms se generan 226 bytes que se deben enviar por la
LAN. Esto equivale a un ancho de banda de 90,4 kb/s (comprese con los 64 kb/s
del flujo de audio)

Ancho de banda LAN = 226 * 8 / 20 ms = 90.4 kb/s

Es de hacer notar que este clculo fue hecho para el envo de audio en una
direccin. Como las comunicaciones son bidireccionales, el ancho de banda real
requerido en la LAN ser el doble. Pueden utilizarse tcnicas de supresin de
silencio, en las que no se envan paquetes cuando no hay audio. En este caso, el
ancho de banda total es similar al ancho de banda unidireccional.

Por lo visto anteriormente, el ancho de banda de la voz paquetizada en la LAN
depende del tamao de la ventana (tpicamente 10, 20 o 30 ms) y el codec
utilizado.

La siguiente tabla muestra los anchos de banda unidireccionales necesarios
utilizando redes IP sobre Ethernet

Tipo de Codec
Duracin de
Trama (ms)
Bytes de
voz/Trama
Bytes de
paquete IP
Bytes de
trama
Ethernet
Ancho de
Banda en
LAN (kbps)
10 80 120 146 116,8
20 160 200 226 90,4
30 240 280 306 81,6
10 10 50 76 60,8
20 20 60 86 34,4
30 30 70 96 25,6
G.723.1 (6.3 kb/s) 30 24 64 90 23,9
G.723.1 (5.3 kb/s) 30 20 60 86 22,9
G.711 (64 kb/s)
G.729 (8 kb/s)
Redes Corporativas


Como se puede ver en la tabla, el ancho de banda puede variar de 23 kb/s a 117
kb/s, dependiendo del codec y la ventana seleccionada.

Redes Corporativas


4 Video sobre redes de datos

4.1 Aplicaciones de video

El video es utilizado en diversos tipos de aplicaciones, las que a su vez, tienen
diversos requerimientos. La TV es, quizs, la aplicacin de video ms conocida.
Sin embargo, existen en forma cada vez ms difundida un nuevo conjunto de
aplicaciones de video, entre las que se encuentran la video telefona, los servicios
de video conferencia, la distribucin de video a demanda a travs de Internet y la
IP-TV, por mencionar los ms relevantes. Cada una de estas aplicaciones tiene
sus caractersticas propias en lo que respecta a requerimientos de calidad,
velocidades, etc.

En el rea corporativa, se nota una creciente relevancia de la video-telefona y las
video-conferencias.

La video-telefona es una aplicacin tpicamente punto a punto, con imgenes del
tipo cabeza y hombros, y generalmente poco movimiento. Por otra parte, es una
aplicacin altamente interactiva, dnde los retardos punta a punta juegan un rol
fundamental en la calidad conversacional percibida.

Las aplicaciones de video conferencias son tpicamente punto a multi-punto. Al
igual que la video telefona, generalmente tienen poco movimiento. Adems de la
difusin del audio y el video es deseable en estas aplicaciones poder compartir
imgenes y documentos. La interactividad tambin es tpicamente un requisito,
aunque podran admitirse retardos punta a punta un poco mayores que en la video
telefona, ya que los participantes generalmente estn dispuestos a solicitar la
palabra en este tipo de comunicaciones.

4.2 Codificacin de video

Los estudios acerca de la codificacin de imgenes y video comenzaron en la
dcada de 1950. En 1984 fue introducida la estrategia de codificacin utilizando la
transformada discreta de coseno (DCT) [12], tcnica ampliamente utilizada en los
sistemas actuales de codificacin. Las tcnicas de compensacin de movimiento
aparecieron tambin en la dcada de 1980, dando origen a las tecnologas
hbridas MC/DCT (Motion Compensation/Discrete Cosine Transform), utilizadas en
los actuales algoritmos MPEG.

Por otra parte, las transformadas discretas de Wavelets (DWT) comenzaron
tambin a ser utilizadas en codificacin de imgenes en la dcada de 1980, y
fueron adoptadas ms recientemente dentro de las tecnologas MPEG-4 y JPEG
2000, para la codificacin de imgenes fijas.

La complejidad de codificadores y decodificadores ha ido aumentando, logrando
un muy alto nivel de compresin, a expensas de requerir decodificadores y, sobre
todo, codificadores muy complejos, y que requieren gran capacidad de
Redes Corporativas


procesamiento [13]. Es de esperar que en el futuro prximo se requiera an mayor
capacidad de procesamiento, reduciendo los requerimientos de ancho de banda y
mejorando la calidad percibida.

A continuacin se presentan, en forma resumida, las caractersticas ms
destacables de las tecnologas actuales en codificacin de imgenes y video, y la
manera de codificar video para su transmisin sobre redes IP. No es el objetivo
principal de este documento presentar un detalle pormenorizado de estas
tecnologas, por lo que slo se describirn brevemente sus caractersticas ms
relevantes.

4.2.1 JPEG

JPEG (Joint Photographic Experts Group) [14] es un estndar diseado para
comprimir imgenes fijas, tanto en color como en blanco y negro. El objetivo
principal de este estndar fue el de lograr compresiones adecuadas, optimizando
el tamao final de los archivos comprimidos, admitiendo prdida de calidad en la
imagen. El algoritmo utilizado divide a la imagen en bloques de 8 x 8 pxeles, 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. La gran ventaja de
estos coeficientes, es que decrecen rpidamente en valor absoluto, lo que permite
despreciar gran parte de ellos (ya que representan informacin de alta frecuencia
espacial).
Conceptualmente, puede considerarse que cada bloque de 8 x 8 est compuesto
por una suma ponderada de 64 tipos de bloques base, como se muestran en la
Figura 4.1. En esta figura, cada bloque corresponde con un patrn determinado. El
primer bloque (arriba a la izquierda) no tiene textura. El coeficiente asociado a este
bloque se corresponde con la componente de luminancia promedio del bloque. Es
conocido tambin como componente de DC, haciendo analoga con la
componente de continua de una seal elctrica. El resto de los bloques
presentan patrones bien definidos, con frecuencias espaciales crecientes hacia la
parte inferior-derecha de la figura.

Figura 4.1

Redes Corporativas


El estndar JPEG 2000 [15] est tambin basado en la idea de utilizar para la
codificacin los coeficientes de una transformacin, pero en este caso se utilizan
transformadas discretas de Wavelets (DWT). Esta transformada permite comprimir
an ms las imgenes que la DCT. Una de las principales diferencias entre JPEG
y JPEG2000 es que en esta ltima no es necesario dividir la imagen original en
bloques. La transformada DWT se aplica a toda la imagen, lo que elimina el
conocido efecto de bloques.

4.2.2 MPEG-x

MPEG-1 [16] fue originalmente diseado por el Moving Picture Experts Group
(MPEG) de la ISO (International Standards Organization) para el almacenamiento
y reproduccin digital de aplicaciones multimedia desde dispositivos CD-ROM,
hasta velocidades de 1.5 Mb/s. MPEG-2 [17] fue el sucesor de MPEG-1, pensado
para proveer calidad de video desde la obtenida con NTSC/PAL y hasta HDTV,
con velocidades de hasta 19 Mb/s.

La codificacin en MPEG-1 est basada en la transformada DCT para explotar las
redundancias espaciales dentro de cada cuadro, y en tcnicas de estimacin y
compensacin de movimiento para explotar las redundancias temporales (entre
cuadros). Las secuencias de video son primeramente divididas en grupos de
figuras (GOP Group of Pictures). Cada GOP puede incluir tres grupos diferentes
de cuadros: I (Intra), P (Predictivos) y B (predictivos Bidireccionales). Los
cuadros del tipo I son codificados nicamente con tcnicas de compresin
espacial (transformada DCT dentro del propio cuadro, por ejemplo). Son utilizados
como cuadros de referencia para las predicciones (hacia adelante o hacia atrs)
de cuadros P o B. Los cuadros del tipo P son codificados utilizando informacin
previa de cuadros I u otros cuadros P, en base a estimaciones y compensaciones
de movimiento. Los cuadros B se predicen en base a informacin de cuadros
anteriores (pasados) y tambin posteriores (futuros). El tamao de un GOP est
dado por la cantidad de cuadros existentes entre dos cuadros I. Tpicamente se
utilizan de 12 a 15 cuadros para un GOP, y hasta 3 cuadros entre un I y un P o
entre dos P consecutivos (tpicamente una seal PAL se codifica con un GOP de
tamao 12 y una NTSC con 15, ambas con no ms de 2 cuadros B consecutivos).
Un ejemplo tomado de [18] se muestra en la Figura 4.2 (IBBPBBPBBI), donde las
flechas indican los cuadros utilizados para las predicciones. Cuando ms grande
el GOP, mayor compresin se puede obtener, pero a su vez existe menor
inmunidad a la propagacin de errores.

Redes Corporativas


Figura 4.2

Al igual que en JPEG, en MPEG-1 se divide la imagen de cada cuadro en bloques
de 8 x 8 pxeles, 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. A su
vez, cuatro bloques se agrupan en un macro-bloque de 16 x 16 pxeles, el que es
utilizado como base para la estimacin del movimiento. La estimacin de
movimiento de un macro-bloque se realiza en el codificador, comparando el
macro-bloque de una imagen con todos las posibles secciones de tamao igual al
macro-bloque (dentro de un rango espacial de 512 pxeles en cada direccin) de
la(s) imagen(es) siguiente(s). La comparacin se realiza generalmente buscando
la mnima diferencia (el mnimo valor de MSE - ver seccin 6.4) entre el macro-
bloque y la seccin evaluada. Este procedimiento se basa en la hiptesis que
todos los pxeles del macro-bloque tendrn por lo general un mismo
desplazamiento, y por lo tanto, ser ms eficiente codificar un vector de
movimiento del macro-bloque y las diferencias del macro-bloque predicho
respecto del macro-bloque original. Las diferencias entre el macro-bloque predicho
y el real tambin son transformadas mediante la DCT para su codificacin.

Redes Corporativas


Un flujo de video de MPEG-2 se forma de la manera descrita a continuacin. Se
utiliza como unidad bsica un macro-bloque, compuesto tpicamente por 4 bloques
de luminancia y 2 de crominancia (ya que la crominancia es sub-muestreada). Los
coeficientes DCT de cada uno de estos bloques son serializados, y precedidos por
un cabezal de macro-bloque. Varios macrobloques contiguos (en la misma fila, y
de izquierda a derecha) son agrupados formando un slice, el que a su vez es
precedido de un cabezal de slice, el que contiene la ubicacin del slice en la
imagen y el factor de cuantizacin usado. Tpicamente puede haber un slice por
cada fila de macro-bloques, pero puede tambin haber slices con parte de una fila.
Un grupo de slices forma un cuadro, el que es precedido por un cabezal de
cuadro, conteniendo informacin del mismo, como por ejemplo el tipo de cuadro
(I,P,B), y las matrices de cuantizacin utilizadas. Varios cuadros se juntan,
formando el GOP, tambin precedido de un cabezal de GOP. Finalmente, varios
GOPs pueden serializarse en una secuencia (Elementary Stream), con su
correspondiente cabezal, el que contiene informacin general, como el tamao de
los cuadros, y la frecuencia de cuadros. En la Figura 4.3 (tomada de [18]) se
muestra un esquema del sistema de capas descrito.

Figura 4.3

MPGE-4 [19] es la evolucin de MPEG-1 y 2, y provee la tecnologa necesaria
para la codificacin en base a contenidos, y su almacenamiento, transmisin y
Redes Corporativas


manipulacin. Presenta mejoras interesantes respecto a la eficiencia de la
codificacin, robustez de transmisin e interactividad. MPGE-4 puede codificar
mltiples Objetos de video (MVO Multiple Video Objects), ya que sus
contenidos son representados en forma individual. El receptor puede de esta
manera recibir diferentes flujos por cada objeto codificado dentro de un mismo
video, correspondientes por ejemplo a diferentes planos (VOP Video Object
Plane) de la imagen. Cada secuencia de VOPs constituye un objeto de video (VO
Video Object) independiente, los que son multiplexados dentro de una
transmisin, y demultiplexados y decodificados por el receptor.

En 2001, el grupo MPEG de ISO/IEC y el VCEG (Video Coding Expert Group) del
ITU-T decidieron unir esfuerzos en un emprendimiento conjunto para estandarizar
un nuevo codificador de video, mejor que los anteriores, especialmente para
anchos de banda o capacidad de almacenamiento reducidos [20]. El grupo se
llam JVT (Joint Video Team), y culmin con la estandarizacin de la
recomendacin H.264/MPEG-4 Part 10, tambin conocida como JVT/H.26L/AVC
(Advanced Video Coding) o H.264/AVC. Este nuevo estndar utiliza
compensaciones de movimiento ms flexibles, permitiendo dividir los macro-
bloques en diversas reas rectangulares, y utilizar desplazamientos de hasta un
cuarto de pxel. Agrega adems los cuadros del tipo SP (Switching P) y SI
(Switching I), similares a los P e I, pero con la posibilidad de reconstruir algunos
valores especficos de forma exacta. Con AVC, para una misma calidad de video,
se logran mejoras en el ancho de banda requerido de aproximadamente un 50%
respecto estndares anteriores [21] [22].

En la Tabla 4.1 se presenta un resumen comparativo de los diferentes estndares
de codificacin de video. Como se puede observar en dicha tabla, los
codificadores / decodificadores H.264/AVC no son compatibles con los estndares
anteriores, lo que supone un punto de quiebre en la evolucin del video digital.

Caracterstica MPEG-1 MPEG-2 MPEG-4 H.264/MPEG-4
Part 10/AVC
Tamao del macro-bloque
16x16 16x16 (frame
mode)
16x8 (field
mode)
16x16 16x16
Tamao del bloque
8x8 8x 8 16x16
8x8, 16x8
8x8, 16x8, 8x16,
16x16, 4x8, 8x4,
4x4
Transformada
DCT DCT DCT/DWT 4x4 Integer
transfor
Tamao de la muestra para aplicar
la transformada
8x8 8x8 8x8 4x4
Codificacin
VLC VLC VLC VLC, CAVLC,
CABAC
Estimacin y compensacin de
movimiento
Si Si Si Si, con hasta 16
MV
Perfiles
No 5 perfiles, varios
niveles en cada
perfil
8 perfiles, varios
niveles en cada
perfil
3 perfiles, varios
niveles en cada
perfil
Tipo de cuadros
I,P,B,D I,P,B I,P,B I,P,B,SI,SP
Ancho de banda
Hasta 1.5 Mbps 2 a 15 Mbps 64 kbps a 2
Mbps
64 kbps a 150
Mbps
Redes Corporativas


Caracterstica MPEG-1 MPEG-2 MPEG-4 H.264/MPEG-4
Part 10/AVC
Complejidad del codificador
Baja Media Media Alta
Compatibilidad con estndares
previos
Si Si Si No
Tabla 4.1

4.3 Transmisin de video sobre redes de datos

4.3.1 Paquetizacin del video

Las secuencias (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
pequeos 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.

En redes IP, el transporte del video se realiza mediante los protocolos RTP y
RTCP, ya descritos en 3.3. El RFC 2250 [23] 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.
Los RFC 3016 [24] y RFC 3640 [25] establecen los procedimientos para
transportar flujos de audio y video MPEG-4.

4.3.2 Ancho de banda en IP para video

Como se ha visto, la codificacin digital de video utiliza algoritmos de compresin,
los que generan codificacin de largo variable y flujos de ancho de banda tambin
variables. Para una aplicacin determinada, el ancho de banda requerido en una
red IP depender del tipo de codificacin utilizada (MPEG-1, 2, 4, H264, etc.), de
la resolucin (tamao de los cuadros SD, CIF, QCIF, etc), del tipo de cuantizacin
seleccionado y del movimiento y textura de la imagen. Al ancho de banda propio
de la seal de video se le debe sumar la sobrecarga de los paquetes IP, UDP y
RTP y para la LAN, de las tramas Ethernet, todo lo que puede estimarse en
aproximadamente un 25% adicional. A diferencia de la codificacin de audio,
donde los anchos de banda pueden calcularse en forma exacta en base
nicamente al codec utilizado, la codificacin de video es estadstica, y depende
de la imagen transmitida, por lo que los clculos son tambin aproximados y
estadsticos.

A modo de ejemplo, en la figura Figura 4.4 se muestra coma vara la calidad
percibida en funcin del ancho de banda para diferentes secuencias de video,
codificadas en MPEG-2, y en resolucin CIF (352 x 288) a 25 Hz. En esta grfica,
la calidad percibida se mide como DMOS, donde valores de 0 se corresponden a
excelente calidad y valores de 1 se corresponden con muy mala calidad. Cada
Redes Corporativas


lnea se corresponde con una secuencia de video diferente, tomadas de la pgina
del VQEG [26]. En este caso, para formatos CIF, se puede ver que para anchos
de banda superiores a 1.75 Mb/s la calidad es excelente para cualquier
secuencia de video. Sin embargo, para anchos de banda inferiores a 1 Mb/s la
calidad percibida depende fuertemente del contenido del video (movimiento,
textura de la imagen, etc.)

CIF
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0
.
0
0
0
0
.
2
5
0
0
.
5
0
0
0
.
7
5
0
1
.
0
0
0
1
.
2
5
0
1
.
5
0
0
1
.
7
5
0
2
.
0
0
0
2
.
2
5
0
2
.
5
0
0
2
.
7
5
0
3
.
0
0
0
Bitrate (Mb/s)
D
M
O
S
src2
src3
src4
src5
src7
src9
src10
src13
src14
src16
src17
src18
src19
src20
src21
src22

Figura 4.4

Por otra parte, en la Figura 4.5, tomada de [27], se muestra como vara el ancho
de banda requerido usando diversos codificadores, en funcin de la calidad de la
imagen, para una secuencia de video particular (Tempete, src22), en resolucin
CIF a 15 Hz. Puede verse como para una misma calidad (medida en este caso
como PSNR
1
), MPEG-2 requiere de aproximadamente el doble de ancho de
banda que H.264/AVC.

1
La definicin detallada de la mtrica PSNR se presenta ms adelante, en el captulo 6.4
Redes Corporativas


Figura 4.5

Como se puede ver, el ancho de banda de las seales de video puede variar
notoriamente, desde valores cercanos a los 64 kb/s (para baja resolucin de
pantalla, imgenes con poco movimiento, baja cantidad de cuadros por segundo),
hasta varios Mb/s (para resoluciones medias o altas).

Redes Corporativas


5 Calidad de voz en redes IP

La VoIP enfrenta problemticas propias de las redes de datos, que se manifiestan
como degradaciones en la calidad del servicio (QoS) o la calidad de la experiencia
(QoE) percibida por los usuarios. Estas degradaciones pueden deberse por
ejemplo a retardos, jitter (diferencia de retardos) y prdida de paquetes, entre
otros factores. Para que la tecnologa de VoIP pueda ser utilizada a nivel
corporativo, es esencial garantizar una calidad de voz aceptable. Se analizarn a
continuacin los factores que afectan la calidad de voz percibida, y luego los
mtodos aceptados para medirla en forma subjetiva y objetiva.

5.1 Factores que afectan la calidad de la voz sobre redes de paquetes

Realizaremos una pequea discusin acerca de los parmetros que influyen en la
calidad de la voz transmitida a travs de la red de datos:

5.1.1 Factor de compresin
Para poder transmitir la voz a travs de una red de datos, es necesario realizar
previamente un proceso de digitalizacin, el que puede degradar la seal de voz
original, debido a la utilizacin de tcnicas de compresin (Ver 3.1)

5.1.2 Prdida de paquetes
A diferencia de las redes telefnicas, donde para cada conversacin se establece
un vnculo estable y seguro, las redes de datos admiten la prdida de paquetes.
Esto est previsto en los protocolos seguros de alto nivel, y en caso de que
ocurra, los paquetes son reenviados. En los protocolos diseados para trfico de
tiempo real generalmente no se recibe confirmaciones de recepcin de paquetes,
ya que si el canal es suficientemente seguro, estas confirmaciones cargan
intilmente al mismo.
En aplicaciones de voz y video, el audio es encapsulado en paquetes y enviado,
sin confirmacin de recepcin de cada paquete.
Si el porcentaje de perdida es pequeo, la degradacin de la voz tambin lo es.
Los porcentajes de perdida admisibles dependen de otros factores, como por
ejemplo la demora de transmisin y el factor de compresin de la voz.
Existen tcnicas para hacer menos sensible la degradacin de calidad en la voz
frente a la prdida de paquetes. La ms sencilla consiste en simplemente repetir el
ltimo paquete recibido.
Tambin cuentan como perdidos los paquetes que llegan a destiempo o fuera de
orden.

5.1.3 Demora
Un factor importante en la percepcin de la calidad de la voz es la demora. La
demora total est determinada por varios factores, entre los que se encuentran

Demora debida a los algoritmos de compresin
Redes Corporativas


En forma genrica, cuanto mayor es la compresin, ms demora hay en el
proceso (los codecs requieren ms tiempo para codificar cada muestra).

Algoritmo de muestreo/compresin Demora tpica introducida
G711 (64 kb/s) 125 s
G.728 (16 kb/s) 2.5 ms
G.729 (8 kb/s) 10 ms
G.723 (5.3 o 6.4 kb/s) 37.5 ms
RTAudio (8 kb/s) 40 ms

Demoras de procesamiento
Es el tiempo involucrado en el procesamiento de la voz para la
implementacin de los protocolos.

Demoras propias de la red (latencia)
Las demoras propias de la red estn dadas por la velocidad de transmisin
de la misma, la congestin, y las demoras de los equipos de red (routers,
gateways, etc.)

Las demoras no afectan directamente la calidad de la voz, sino la calidad de la
conversacin. Hasta 100 ms son generalmente tolerados, casi sin percepcin de
los interlocutores. Entre 100 y 200 ms las demoras son notadas. Al acercarse a los
300 ms de demora, la conversacin se vuelve poco natural. Pasando los 300 ms la
demora se torna crtica, haciendo dificultosa la conversacin.

Un efecto secundario, generado por las demoras elevadas, es el eco. El eco se
debe a que parte de la energa de audio enviada es devuelta por el receptor. En
los sistemas telefnicos este efecto no tiene mayor importancia, ya que los
retardos o demoras son despreciables, y por lo tanto, el eco no es percibido
como tal.
Redes Corporativas


Cuando la demora de punta a punta comienza a aumentar, el efecto del eco
comienza a percibirse.

5.1.4 Eco

Si el tiempo transcurrido desde que se habla hasta que se percibe el retorno de la
propia voz es menor a 30 ms, el efecto del eco no es percibido. Asimismo, si el
nivel del retorno est por debajo de los 25 dB, el efecto del eco tampoco es
percibido. En las conversaciones telefnicas habituales, el eco existe en niveles
perceptibles (mayores a 25 dB), pero la demora es mnima, por lo que el eco no
es perceptible. Las excepciones son las comunicaciones va satlite, en las que la
demora promedio es del orden de los 150 ms. Para estos casos, las compaas
telefnicas disponen generalmente de sofisticados equipos canceladores de eco.

5.1.5 Variaciones en la demora (Jitter)

El jitter es la variacin 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 receptor debe recibir los paquetes a intervalos constantes, para poder regenerar
de forma adecuada la seal original. Dado que el jitter es inevitable, los
receptores disponen de un buffer de entrada, con el objetivo de suavizar el
efecto de la variacin de las demoras. Este buffer recibe los paquetes a intervalos
variables, y los entrega a intervalos constantes.
Es de hacer notar que este buffer agrega una demora adicional al sistema, ya
que debe retener paquetes para poder entregarlos a intervalos constantes.
Cunto ms variacin de demoras (jitter) exista, ms grande deber ser el buffer,
y por lo tanto, mayor demora ser introducida al sistema.

5.1.6 Tamao de los paquetes

El tamao de los paquetes influye en dos aspectos fundamentales en la
transmisin de la voz sobre redes de datos: La demora y el ancho de banda
requerido.
Para poder transmitir las muestras codificadas de voz sobre una red de datos, es
necesario armar paquetes, segn los protocolos de datos utilizados (por ejemplo,
IP). Un paquete de datos puede contener varias muestras de voz. Por ello, es
necesario esperar a recibir varias muestras para poder armar y enviar el paquete.
Esto introduce un retardo o demora en la transmisin. Desde ste punto de vista,
parece conveniente armar paquetes con la mnima cantidad de muestras de voz
(por ejemplo, un paquete por cada muestra). Sin embargo, hay que tener en
cuenta que cada paquete tiene una cantidad mnima de informacin (bytes) de
control (cabezal del paquete, origen, destino, etc.). Esta informacin (sobrecarga
u overhead), no aporta a la informacin real que se quiere transmitir, pero afecta
al tamao total del paquete, y por tanto al ancho de banda, como se vio en 3.5.
Redes Corporativas


La duracin de las ventanas de voz se encuentran entre 10 a 30 ms, valor que
aporta a la demora total.

5.2 Medida de la calidad de voz

Para evaluar la calidad de voz percibida, se han estandarizado mtodos. Estos
mtodos se dividen en subjetivos y objetivos. Los mtodos subjetivos de medida
de la calidad de voz, se basan en conocer directamente la opinin de los usuarios.
Tpicamente resultan en un promedio de opiniones (por ejemplo, en un valor de
MOS Mean Opinin Store). Los mtodos objetivos a su vez se subdividen en
intrusivos (se inyecta una seal de voz conocida en el canal y se estudia su
degradacin a la salida) y no intrusivos (monitorean ciertos parmetros en un
punto de la red y en base a estos permite establecer en tiempo real la calidad que
percibira un usuario).

Estos mtodos se describen en las siguientes secciones.

5.3 Mtodos Subjetivos de medida de la calidad de voz

La calidad de la voz se establece a travs de la opinin del usuario. La calidad de
audio puede ser evaluada directamente (ACR = Absolute Category Rating), o en
forma comparativa contra un audio de referencia (DCR = Degradation Category
Rating). Con evaluaciones directas (del tipo ACR) se califica el audio con valores
entre 1 y 5, siendo 5 Excelente y 1 Malo. El MOS (Mean Opinin Store) es el
promedio de los ACR medidos entre un gran nmero de usuarios.

Si la evaluacin es comparativa, (del tipo DCR), el audio se califica tambin entre
1 y 5, siendo 5 cuando no hay diferencias apreciables entre el audio de referencia
y el medido y 1 cuando la degradacin es muy molesta. El promedio de los valores
DCR es conocido como DMOS (Degradation MOS).

La metodologa de evaluacin subjetiva ms ampliamente usada es la del MOS
(Mean Opinin Score), estandarizada en la recomendacin ITU-T P.800 [28].
Adicionalmente, se puede evaluar la calidad del audio y la calidad de la
conversacin, las que pueden ser diferentes. La calidad de la conversacin implica
una comunicacin bidireccional, donde, por ejemplo, los retardos juegan un papel
muy importante en la calidad percibida. Los valores obtenidos con las tcnicas
ACR (es decir, el MOS) puede estar sujeto al tipo de experimento realizado. Por
ejemplo, si se utilizan varias muestras de buena calidad, una en particular puede
ser calificada peor que si esa misma muestra se presenta junto a otras de peor
calidad.

Los mtodos subjetivos son en general caros y lentos porque requieren un gran
panel de usuarios. Son dependientes entre otros factores del pas, del idioma, de
las experiencias previas de los usuarios.

Redes Corporativas


5.4 Mtodos Objetivos de medida de la calidad de voz

5.4.1 E-Model

La industria de las telecomunicaciones ha aceptado una representacin numrica
de la calidad de la voz, llamada MOS (Mean Opinion Score), y estandarizada en
la recomendacin ITU-T P.800. La calidad de la voz es calificada con un nmero,
entre 1 y 5. El valor numrico de MOS es proporcional a la calidad de la voz. 1
significa muy mala calidad y 5 significa excelente. Los valores son obtenidos
mediante el promedio de las opiniones de un gran grupo de usuarios.

La ITU-T ha creado un modelo en la recomendacin ITU-T G.107, llamado E-
Model [29], para estimar o predecir la calidad de la voz en redes IP (VoIP)
percibida por un usuario tpico, en base a parmetros medibles de la red. El
resultado del E-Model es un factor escalar, llamado R (Transmission Rating
Factor), que puede tomar valores entre 0 y 100.

El E-model toma en cuenta una gran cantidad de factores que pueden deteriorar
la calidad de la voz percibida, como por ejemplo, el uso de compresin, los
retardos de la red, as como tambin los factores tpicos en telefona como ser
prdida, ruido y eco. Puede ser aplicado para estimar la calidad de la voz en redes
de paquetes, tanto fijas como inalmbricas [30].

El E-Model puede ser utilizado para evaluar como se ver afectada la calidad de la
voz en una red en base a parmetros mensurables. El modelo parte de un puntaje
perfecto (100) y resta diversos factores que degradan la calidad, segn se puede
ver en la ecuacin (5.4.1).

R = R
o
- I
s
- I
d
I
e,eff
+ A (5.4.1)

donde

R
o
Representa la relacin seal/ruido bsica (antes de ingresar en la
red) que incluye fuentes de ruido, tales como ruido ambiente. El valor inicial
puede ser como mximo 100. Las fuentes de ruido independientes del
sistema como ser el ruido ambiental, pueden hacer que este valor inicial
sea menor a 100.

I
s
Es una combinacin de todas las degradaciones que aparecen de
forma ms o menos simultnea con la seal vocal. Por ejemplo, volumen
excesivo y distorsin de cuantizacin.

I
d
Representa las degradaciones producidas por el retardo y el eco

Redes Corporativas


I
e,eff
Effective equipment impairment factor. Representa las
degradaciones producidas por los cdecs y por las prdidas de paquetes de
distribucin aleatoria.

A Factor de Mejoras de Expectativas. Muchas veces, los usuarios
estn dispuestos a aceptar peor calidad de voz si saben que se estn
utilizando tecnologas no clsicas (por ejemplo celulares o VoIP). Permite
compensar los factores de degradacin cuando existen otras ventajas de
acceso para el usuario.

Los valores de R varan entre 0 y 100, correspondiendo los valores ms altos a
mejores calidades de voz.

Los tres tipos de degradaciones (I
s
, I
d
y I
e, eff
) se subdividen, a su vez, en la
combinacin de otros factores, como se detalla a continuacin.

Clculo de Is

I
s
= I
olr
+ I
st
+ I
q
(5.4.2)

donde

I
olr
Representa la disminucin de calidad producida por valores
demasiado bajos de OLR (Overall Loudness Rating). El OLR se calcula, a
su vez, como

OLR = SLR + RLR (5.4.3)

Siendo

SLR (Send Loudness Rating), es la prdida entre la boca del
emisor y el micrfono del aparato telefnico

SLR (Receive Loudness Rating), es la prdida entre el parlante del
aparato telefnico y el odo del receptor

I
st
Representa la degradacin producida por efectos locales no ptimos,
y depende esencialmente del factor STMR (Side Tone Masking Rating).
Parte de la seal recibida por el micrfono es transmitida, dentro del mismo
telfono, al parlante, generando un efecto local que hace que la persona
que habla se escuche por el odo en el que tiene el tubo o microtelfono. La
atenuacin de la seal que pasa del micrfono al parlante del mismo
aparato se conoce como STMR. Si este valor no est dentro de los
parmetros adecuados, genera una sensacin de eco, o de lnea muerta,
segn el caso, bajando la calidad de la comunicacin.

Redes Corporativas


I
q
Representa la degradacin producida por la distorsin de
cuantificacin. Se calcula en base a unidades qdu . 1 qdu se define como
el ruido de cuantizacin que resulta de una codificacin y decodificacin
completas en Ley A o Ley

La frmula de clculo detallada de los parmetros (I
olr
, I
st,
I
q
) puede verse en la
recomendacin G.107 [29].

Clculo de Id

I
d
= I
dte
+ I
dle
+ I
dd
(5.4.4)

Donde

I
dte
Expresa una estimacin para las degradaciones debidas al eco para
el hablante. Se calcula en base al factor TELR (Talker Echo Loudness
Rating) y la demora media T de punta a punta en un sentido. El factor TELR
es la medida de la atenuacin del eco percibido por el hablante.

I
dle
Representa degradaciones debidas al eco para el oyente. Se calcula
en base al factor WEPL (Weighted Echo Path Loss) y la demora media Tr
de ida y vuela. El factor WEPL es la medida de la atenuacin entre la seal
directa recibida por el oyente, la seal retardada recibida como eco.

I
dd
Representa la degradacin producida por retardos absolutos
demasiado largos T
a
, que se producen incluso con compensacin perfecta
del eco. Si T
a
< 100 ms, el factor I
dd
es 0.

La frmula de clculo detallada de los parmetros (I
dte
, I
dle,
I
dd
) puede verse en la
recomendacin G.107.

El efecto de la demora en el valor de R se grafica en la siguiente figura,
asumiendo todos los otros factores ideales [31].

Redes Corporativas


50
60
70
80
90
100
0 100 200 300 400 500
One-way Delay (ms)
R
TELR = 65 dB
Exceptional
limiting case
Very
satisf actory
Satisfactory
Some users
dissatisf ied
Many users
dissatisf ied
User Satisfaction

Puede verse como hasta 175 ms el valore de R es mayor que 90, y se encuentra
en la zona de Muy satisfechos. Sin embargo, luego de los 175 ms, el efecto de
las demoras degrada fuertemente la comunicacin, hacindola poco natural.

Si a la grfica anterior se le suma el efecto del eco, el modelo E predice las
siguientes curvas:

Redes Corporativas


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
satisf actory
Satisfactory
Some users
dissatisf ied
Many users
dissatisf ied
User Satisfaction

Es de hacer notar que el valor TELR es la medida de la atenuacin del eco
percibido por el hablante. Cuanto ms atenuado el eco percibido (mayor valor en
db de TELR), menor efecto tiene el eco sobre la degradacin. En la medida que
aumenta el eco, el valor de R decrece rpidamente con el retardo.

Clculo de Ie-eff

I
e-eff
representa las degradaciones producidas por los cdecs y por las prdidas de
paquetes, segn la siguiente frmula:

Bpl
BurstR
Ppl
Ppl
Ie Ie Ie-eff
+
+ = ) 95 ( (5.4.5)

Donde

I
e
Es un valor que depende del codec utilizado, y representa la
degradacin percibida producida por los diferentes algoritmos de
compresin.

P
pl
Representa la probabilidad de prdida de paquetes

B
pl
Se define como el factor de robustez contra prdida de paquetes, y
es un valor preestablecido para cada codec

Redes Corporativas


BurstR Es la Relacin de rfaga, y se define como

" arbitraria " prdida de s condicione en red la en previstas rfagas las de media Longitud
llegada de secuencia una en observadas rfagas las de media Longitud
= BurstR

Si no existen prdida de paquetes (P
pl
=0), el factor I
e-eff
depende
nicamente del tipo de codec utilizado

Los valores de I
e
para los diferentes codecs se detallan en la siguiente
tabla:

Codec Type Reference Operating Rate
kbit/s
Ie
Value
Waveform Codecs
PCM G.711 64 0
ADPCM G.726, G.727 40 2
G.721, G.726, G.727 32 7
G.726, G.727 24 25
G.726, G.727 16 50
Speech Compression Codecs
LD-CELP G.728 16 7
12.8 20
CS-ACELP G.729 8 10
G.729-A + VAD 8 11
VSELP IS-54 8 20
ACELP IS-641 7.4 10
QCELP IS-96a 8 21
RCELP IS-127 8 6
VSELP Japanese PDC 6.7 24
RPE-LTP GSM 06.10, Full-rate 13 20
VSELP GSM 06.20, Half-rate 5.6 23
ACELP GSM 06.60, EFR 12.2 5
ACELP G.723.1 5.3 19
MP-MLQ G.723.1 6.3 15

En una red sin prdida de paquetes y sin eco, el valor de R depender de la
demora y de los codecs utilizados, segn se muestra en la siguiente grfica, para
G.711, G.729A y G.723.1 (notar que la grfica negra coincide con las grficas
anteriores)

Redes Corporativas


50
60
70
80
90
100
0 100 200 300 400 500
One-way Delay (ms)
R
G.711
G.729A
G.723.1
Exceptional
limiting case
Very
satisf actory
Satisfactory
Some users
dissatisf ied
Many users
dissatisf ied
User Satisfaction

En una red con prdida de paquetes, el valor de R depende de la utilizacin o no
de tcnicas de PLC (Packet Loss Compensation). A modo de ejemplo, para los
codecs G.711 y G.729, las siguientes grficas muestran el efecto conjunto de la
demora y la prdida de paquetes.

Redes Corporativas


Clculo de A

A representa un Factor de Mejoras de Expectativas. Muchas veces, los usuarios
estn dispuestos a aceptar peor calidad de voz si saben que se estn utilizando
tecnologas no clsicas (por ejemplo celulares o VoIP). No existe, por
consiguiente, ninguna relacin entre A y los dems parmetros de transmisin.

El cuadro siguiente presenta los valores tpicos de A para diferentes tecnologas,
segn la recomendacin ITU-T G-113 [32].

Ejemplo de sistema de comunicacin Valor mximo de A
Convencional (almbrico) 0
Movilidad mediante redes celulares en un edificio 5
Movilidad en una zona geogrfica o en un vehculo en
movimiento
10
Conexin con lugares de difcil acceso, por ejemplo,
mediante conexiones de mltiples saltos por satlite
20

Redes Corporativas


Relacin de R y MOS

El modelo relaciona el valor de R con el MOS, con un gran nivel de
aproximacin, segn la siguiente ecuacin:

Para R < 6.5: 1 MOS
CQE
=
Para 0 < R < 100:
6
CQE
10 7 ) 100 )( 60 ( 035 , 0 1 MOS

+ + = R R R R (5.4.6)
Para R > 100: 5 , 4 MOS
CQE
=

La siguiente figuras muestran la relacin entre R y MOS, segn la frmula anterior:

G.107_FB.2
Excelente 5
Buena 4
Mediocre 3
Pobre 2
Mala 1
0 20 40 60 80 100 R
MOS

Redes Corporativas


Aplicacin del E-model

El RFC 3611 [33] define campos de reportes extendidos (XR, Extended Reports)
en el protocolo RTCP que permiten intercambiar informacin acerca de la calidad
de la comunicacin. En este RFC se incluye la posibilidad de intercambiar
informacin del valor de R entre fuentes y destinos, as como los valores
percibidos de MOS-LQ (MOS listening quality) y MOS-CQ (MOS conversational
quality)

5.4.2 ITU-T P.862 (PESQ)

La recomendacin ITU-T P.862 [34] presenta un mtodo objetivo para la
evaluacin de la calidad vocal de extremo a extremo de redes telefnicas de
banda estrecha y codecs vocales.

Esta recomendacin describe un mtodo objetivo para predecir la calidad subjetiva
de la voz telefnica utilizando los codecs ms comunes. Presenta una descripcin
de alto nivel del mtodo, explica la forma de utilizar este mtodo y parte de los
resultados de referencia obtenidos por la Comisin de Estudio 12 de la ITU-T en el
periodo 1999-2000. Proporciona adicionalmente una implementacin de referencia
escrita en el lenguaje de programacin ANSI-C.

Redes Corporativas


El mtodo objetivo descrito se conoce por "evaluacin de la calidad vocal por
percepcin" (PESQ, perceptual evaluation of evaluation of speech quality) y es el
resultado de varios aos de trabajos de desarrollo.

PESQ compara una seal inicial X(t) con una seal degradada Y(t) que se obtiene
como resultado de la transmisin de X(t) a travs de un sistema de
comunicaciones (por ejemplo, una red IP). La salida de PESQ es una prediccin
de la calidad percibida por los sujetos en una prueba de escucha subjetiva que
sera atribuida a Y(t).

El primer paso de PESQ consiste en una alineacin temporal entre las seales
iniciales X(t) y degradada Y(t). Para cada intervalo de seal se calcula un punto de
arranque y un punto de parada correspondientes.

Una vez alineadas, PESQ compara la seal (entrada) inicial con la salida
degradada alineada, utilizando un modelo por percepcin, como el representado
en la siguiente figura

Lo esencial en este proceso es la transformacin de las dos seales, la inicial y la
degradada, en una representacin interna que intenta reproducir la representacin
psicoacstica de seales de audio en el sistema auditivo humano, teniendo en
cuenta la frecuencia por percepcin (Bark) y la sonoridad (Sone).

El modelo cognitivo de PESQ termina brindando una distancia entre la seal vocal
inicial y la seal vocal degradada (nota PESQ), la que corresponde a su vez con
una prediccin de la MOS subjetiva. La nota PESQ se hace corresponder a una
escala similar a la de MOS, un nmero nico en una escala de 0,5 a 4,5, aunque
en la mayora de los casos la gama de las salidas estar entre 1,0 y 4,5, que es la
Redes Corporativas


gama normal de valores de MOS que suelen darse en un experimento sobre la
calidad de voz.

La descripcin detallada del algoritmo es compleja, y puede verse en la
recomendacin referenciada.

El mtodo PESQ es objetivo e intrusivo, ya que requiere del envo de una seal
conocida de referencia para evaluar la calidad percibida de la voz. Algunos
sistemas lo implementan enviando un par de segundos de audio conocido, lo que
basta para poder aplicar el mtodo.

5.4.3 ITU-T P.563

El algoritmo P.563 es aplicable para la prediccin de la calidad vocal sin una seal
de referencia independiente. Por ese motivo, este mtodo se recomienda para la
evaluacin no intrusiva de la calidad vocal y para la supervisin y evaluacin con
la red en funcionamiento, empleando en el extremo lejano de una conexin
telefnica fuentes de seal vocal desconocidas.

En comparacin con la Rec. ITU-T P.862 (que utiliza el mtodo basado en dos
extremos o intrusivo) que compara una seal de referencia de elevada calidad
con la seal degradada en base a un modelo perceptual, P.563 predice la calidad
de la voz de una seal degradada sin una seal vocal de referencia dada. En la
figura siguiente se ilustran las diferencias entre ambos mtodos.

Redes Corporativas


El enfoque utilizado en P.563 puede visualizarse como un experto que escucha
una llamada real con un dispositivo de prueba, tal como un microtelfono
convencional conectado en paralelo a la lnea. Esta visualizacin permite explicar
la principal aplicacin y permite al usuario clasificar las puntuaciones obtenidas
mediante P.563. La puntuacin de calidad que se predice mediante P.563 est
relacionada con la calidad percibida en extremo receptor.

La seal vocal que debe evaluarse se analiza de varias formas, que detectan un
conjunto de parmetros de seal caractersticos. En base a un conjunto
restringido de parmetros clave se establece la asignacin a una clase de
distorsin principal.

Bsicamente, la parametrizacin de la seal del algoritmo P.563 puede dividirse
en tres bloques funcionales independientes que se corresponden con las tres
clases de distorsin principales:

Anlisis del tracto vocal y desnaturalizacin de la voz
o voces masculinas
o voces femeninas
o marcada robotizacin
Anlisis de un ruido adicional intenso
Redes Corporativas


o SNR esttica reducida (nivel bsico del ruido de fondo)
o SNR por segmentos reducida (ruido relacionado con la envolvente
de la seal).
Interrupciones, silenciamientos y recorte temporal

El modelo de calidad vocal de P.563 se compone de tres bloques principales:
1. Decisin sobre la clase de distorsin de que se trata.
2. Evaluacin de la calidad vocal intermedia para la correspondiente clase de
distorsin.
3. Clculo global de la calidad vocal.

Cada clase de distorsin utiliza una combinacin lineal de varios parmetros para
generar la calidad vocal intermedia.
La calidad vocal definitiva se calcula combinando los resultados de calidad vocal
intermedia con algunas caractersticas adicionales de la seal.

La descripcin detallada del algoritmo es compleja, y puede verse en la
Recomendacin referenciada.

Redes Corporativas


6 Calidad de video en redes IP

La transmisin de video y multimedia sobre redes de datos enfrenta problemticas
especficas en lo que respecta a la calidad percibida por los usuarios. Varios tipos
de degradaciones suelen presentarse en las seales de video transmitidas sobre
redes de paquetes. El estudio en esta rea es todava un tema de investigacin.
Se analizarn a continuacin los factores que pueden afectar la calidad de video
percibida, y luego los mtodos aceptados para medirla en forma subjetiva y
objetiva.

6.1 Factores que afectan la calidad del video sobre redes de paquetes

La transmisin de video sobre redes de paquetes, y en particular, sobre la Internet,
presenta caractersticas esencialmente diferentes a la de la difusin de TV por las
vas clsicas (radiofrecuencia, TV-cable). Se utilizan rangos de anchos de banda
variables, hay congestin y prdida de paquetes, y tpicamente, en las
aplicaciones corporativas, la observacin se realiza desde distancias ms cortas, y
generalmente en pantallas ms pequeas.

En esta seccin se describirn conceptualmente los factores especficos de las
redes IP que afectan a la calidad de video.

6.1.1 Factor de compresin

El proceso de digitalizacin de video utiliza tcnicas que transforman una
secuencia de pxeles al dominio de la frecuencia espacial (DCT), cuantificando
valores, descartando eventualmente componentes de alta frecuencia, y haciendo
uso de tcnicas de prediccin y compensacin de movimientos. Esto genera ruido
de cuantificacin, el que puede degradar la imagen original a niveles perceptibles.
Es este ruido de cuantificacin [35], el que genera las clsicas degradaciones
que pueden verse en imgenes y videos con alta compresin, entre ellos, el
conocido efecto de bloques, que hace ver a la imagen como un conjunto de
bloques pequeos.

Los algoritmos de compresin utilizados actualmente en la codificacin digital de
video introducen varios tipos de degradaciones, las que se pueden clasificar segn
sus caractersticas principales [36]. Esta clasificacin es til para poder
comprender las causas de las degradaciones y el impacto que tiene en la calidad
percibida.

Debido al gran ancho de banda requerido en video para enviar la seal sin
comprimir, el uso de codecs con compresin es sumamente habitual en video.
Esto pone un lmite a la calidad de imagen recibida, el que es independiente del
medio de transmisin sobre el que viaje la seal.

Redes Corporativas


Las principales degradaciones introducidas por el uso de codecs con compresin
son las siguientes:

Efecto de bloques (blocking)
Efecto de imagen de base (basis image)
Borrosidad o falta de definicin (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

6.1.2 Prdida de paquetes

La prdida de paquetes en las redes IP afecta a la calidad percibida de video. En
la Figura 6.1, tomada de [37], se muestra como la prdida de un paquete puede
propagarse, afectando no solo a la informacin de video contenida en dicho
paquete, sino a otras partes del mismo o diferentes cuadros. Tpicamente, y dado
que la codificacin se realiza en forma diferencial, la prdida de un paquete
afectar a todos los bloques siguientes en la misma fila (slice). Si el paquete
perdido corresponde adems a un cuadro de referencia (I), tambin se vern
afectados los cuadros predictivos, posteriores o anteriores, propagndose el error
en el tiempo.

Figura 6.1

Redes Corporativas


Existen tcnicas de cancelacin de paquetes perdidos, las que tratan de
reconstruir la informacin perdida en base a informacin disponible. Por ejemplo,
reemplazando los pxeles perdidos por los mismos valores de cuadros anteriores.

Varios trabajos se han realizado, estudiando la manera en que la calidad de video
se ve afectada por la prdida de paquetes. Algunos [38] proponen estimar el MSE
del video, en base a diferentes tcnicas, que tienen en cuenta la prdida de
paquetes. Sin embargo, estos son estimadores no se corresponden con la calidad
perceptual, al basarse en la prediccin del MSE o PSNR, los que no tienen
relacin directa con el MOS.

En [39] se muestra que no basta con conocer el porcentaje de prdida de
paquetes para estimar como se ve afectada la calidad de video percibida.
Dependiendo de diversos factores, la prdida de un paquete determinado de video
puede o no afectar la calidad percibida. Por ejemplo, en imgenes casi estticas,
el video perdido puede ser reconstruido en base a imgenes anteriores, casi sin
prdida de calidad, lo que lleva a que la prdida de un paquete sea prcticamente
imperceptible. Algo similar sucede cuando la prdida solo afecta a un cuadro. De
esta manera, se propone un clasificador de paquetes perdidos, que, en base a
un algoritmo, decide si el paquete perdido afectar o no a la calidad percibida del
video. El algoritmo toma en cuenta cuantos cuadros se vern afectados por la
prdida del paquete, la movilidad de la imagen y su varianza y el error introducido
medido con MSE, entre otros factores. Se define el parmetro VPLR (Visible
Packet Loss Rate), en lugar del clsico PLR (Packet Loss Rate), para ser utilizado
como entrada a los algoritmos de prediccin de calidad en base a la prdida de
paquetes.

La idea de detectar como afecta la posible prdida de cada paquete en la calidad
perceptual es explorada en [40], donde se propone un mtodo que garantice una
calidad perceptual constante en la recepcin de un flujo de video. La idea en este
caso es marcar solo ciertos paquetes especficos con mayor prioridad (asumiendo
una red con soporte para Diff Serv), de manera de garantizar su llegada a
destino, sin inundar a la red con todos los paquetes de video marcados como
prioritarios, sino solo con los paquetes cuya prdida afecten especialmente la
calidad percibida. El algoritmo se basa nicamente en la calidad deseada (PSNR)
y la tasa de prdida de paquetes (PLR).

Una idea similar es presentada en [41], donde se presenta una mtrica para
priorizar ciertos paquetes de video, en base a la estimacin de la distorsin
percibida en caso de la prdida o llegada fuera de tiempo de cada paquete.

Dado que las prdidas de paquetes se dan generalmente en rfagas, la calidad
puede verse fuertemente degradada por la prdida de varios paquetes
consecutivos, correspondientes a cuadros consecutivos. En [42] se propone una
tcnica que consiste en reagrupar los cuadros que se envan, generando un buffer
en el codificador de 3 GOPs, y reagrupando el orden en el que se enva la
informacin. Con esto se logra difundir los paquetes perdidos entre varios cuadros
Redes Corporativas


separados en el tiempo, y de esta manera, segn los autores, mejorar la calidad
percibida.

Si bien varios trabajos se han realizado acerca de la degradacin del video debida
a la prdida de paquetes, el tema est an abierto, y no hay an estndares ni
trabajos sistemticos de comparacin de diferentes modelos.

6.1.3 Demora / Jitter

El receptor debe recibir los paquetes a decodificar a intervalos constantes, para
poder regenerar de forma adecuada la seal original. Dado que el jitter es
inevitable en las redes de paquetes, los receptores disponen de un buffer de
entrada, con el objetivo de suavizar el efecto de la variacin de las demoras.
Este buffer recibe los paquetes a intervalos variables, y los entrega a intervalos
constantes.
Es de hacer notar que este buffer agrega una demora adicional al sistema, ya que
debe retener paquetes para poder entregarlos a intervalos constantes. Cunto
ms variacin de demoras (jitter) exista, ms grande deber ser el buffer, y por lo
tanto, mayor demora ser introducida al sistema. Las demoras son indeseables, y
tienen impacto directo en la experiencia del usuario, sobre todo en contenidos de
tiempo real (por ejemplo, distribucin de eventos deportivos en lnea) y en
aplicaciones conversacionales (por ejemplo video telefona, o video conferencias).
Se hace necesario disponer de mecanismos que minimicen el tamao de los jitter-
buffers, pero que a su vez, no comprometan la calidad debida a la perdida de
paquetes que no han llegado a tiempo.

En [43] se propone un mtodo dinmico al que llaman AMP (Adaptive Media
Playout), en el que se cambia la velocidad de reproduccin del medio (video /
audio) dependiendo de la condicin del canal de transmisin, y logrando de esta
manera reducir el tamao del jitter-buffer. Se indica que aumentar o disminuir la
velocidad de ciertas partes del contenido hasta en un 25% es subjetivamente
mejor que aumentar las demoras totales o tener interrupciones.

En el proyecto Multimedia del VQEG se proponen realizar pruebas con demoras
entre 2 milisegundos y 5 segundos, y prdidas de paquetes impulsivas en el
rango de 0 a 50%.

6.2 Medida de la calidad perceptual de video

La manera ms confiable de medir la calidad de una imagen o un video es la
evaluacin subjetiva, realizada por un conjunto de personas que opinan acerca de
su percepcin. La opinin media, obtenida mediante el MOS (Mean Opinion
Score) es la mtrica generalmente aceptada como medida de la calidad. Para ello,
los experimentos subjetivos controlados continan siendo actualmente los
Redes Corporativas


mtodos de medida reconocidos en la estimacin perceptual de la calidad del
video.

Los mtodos de medida de calidad de video, al igual que los de voz, se clasifican
en mtodos subjetivos y mtodos objetivos. Los mtodos subjetivos se basan en
conocer directamente la opinin de los usuarios. Los mtodos objetivos intentan
predecir la calidad percibida por los usuarios, en base a medidas que puedan
realizarse mediante algoritmos automticos.

6.3 Mtodos Subjetivos de medida de la calidad de video

Diversos mtodos subjetivos de evaluacin de video son reconocidos, y estn
estandarizados en la recomendacin ITU-R BT.500-11 [44], especialmente
desarrollada para aplicaciones de televisin y en la recomendacin ITU-T P.910
[45], para aplicaciones multimedia. En todos los mtodos propuestos, los
evaluadores son individuos que juzgan la calidad en base a su propia percepcin y
experiencia previa. Estos mtodos tienen en comn la dificultad y lo costoso de su
implementacin.

La recomendacin BT.500-11 detalla los siguientes mtodos:

DSIS Double Stimulus Impairment Scale (Escala de degradacin con
doble estmulo)
DSCQS Double Stimulus Continuos Quality Scale (Escala de calidad
continua de doble estmulo)
SSCQE - Single Stimulus Continuous Quality Evaluation (Evaluacin de
calidad continua de estmulo nico)
SDSCE - Simultaneous Double Stimulus for Continuous Evaluation (Mtodo
de doble estmulo simultneo para evaluacin continua)

La recomendacin P.910 detalla los siguientes mtodos:

ACR - Absolute Category Rating (ndices por categoras absolutas)
DCR - Degradation Category Rating (ndices por categoras de
degradacin)
PR - Pair Comparison (Mtodo de comparacin por pares)

En los diferentes mtodos los participantes deben calificar las secuencias de
video, solas o comparadas con la seal de referencia, en escalas que
generalmente van de 1 a 5, en forma discreta o continua, segn el mtodo.

Las recomendaciones establecen los detalles de los procedimientos para realizar
las encuestas.

Redes Corporativas


6.4 Mtodos Objetivos de medida de la calidad de video

Los mtodos subjetivos, presentados en la seccin anterior, son costosos, difciles
de realizar, e impracticables en aplicaciones de tiempo real.
Por esto se hace necesario el uso de mtodos objetivos y automticos, que
puedan predecir con fiabilidad la calidad percibida, en base a medidas objetivas
tomadas en algn punto del sistema.

Las primeras medidas objetivas de la calidad del video estn basadas en obtener
las diferencias, pxel a pxel, entre las imgenes originales (previo a la compresin
y transmisin) y las imgenes presentadas (luego de la recepcin y
reconstruccin). Dado que los sistemas de video utilizan tcnicas de compresin
con prdida de informacin, y que los medios de transmisin a su vez pueden
introducir factores distorsionantes (retardos, prdida de paquetes, etc.), las
imgenes presentadas sern diferentes a las originales.

Las medidas ms simples son las de error cuadrtico medio (MSE - Mean Square
Error) y su raz cuadrada (RMSE = Root Mean Square Error) y la relacin seal a
ruido de pico (PSNR Peak Signal to Noise Ratio), definidas en las ecuaciones
(6.1) a (6.3) ms adelante. Estas mtricas requieren de la referencia completa de
la seal original para poder ser calculadas.

[ ]
= = =
=
N
n
M
m
T
t
t n m y t n m x
TMN
MSE
1
2
1 1
) , , ( ) , , (
1
(6.1)

MSE RMSE= (6.2)

=
MSE
L
PSNR
2
10
log 10 (6.3)

donde la imagen tiene N x M pxeles y T cuadros, x, y son los pxeles de la imagen
original y la distorsionada respectivamente. L es el rango dinmico que pueden
tomar los valores de x o y , y toma el valor 255 para 8 bits por pxel.

Estas mtricas son fciles de calcular, y tienen un claro significado. Por estas
razones, han sido ampliamente usadas como mtricas en la estimacin de la
calidad de video. Hay que poner especial nfasis en la alineacin espacial y
temporal de las imgenes a comparar, ya que la referencia y la imagen degradada
pueden estar desfasadas en el tiempo o en el espacio.

Sin embargo, tambin han sido ampliamente criticadas por no tener correlacin
directa con la calidad percibida. Por ejemplo, en la Figura 6.2, tomada de [46], se
Redes Corporativas


muestran tres ejemplos de imgenes comprimidas, donde se puede ver
claramente que con similares valores de MSE, la calidad percibida puede ser
esencialmente diferente (comparar, por ejemplo, Tiffany con Mandril, sobre el
lado derecho de la figura), lo que pone en duda la utilidad de este tipo de mtrica
como indicador de calidad. En la Figura 6.3, presentada en [47], se puede ver
como la misma imagen, con el mismo valor de PSNR, puede tener diferente
calidad percibida, dependiendo del lugar en el que se presenten las
degradaciones. En la figura (b), se nota claramente la degradacin en el cielo
(parte superior), mientras que en la figura (c), una degradacin similar en la parte
inferior prcticamente no es perceptible. Este fenmeno se conoce como
enmascaramiento. En zonas texturadas o con gran actividad espacial, las
degradaciones quedan enmascaradas y son menos percibidas por el sistema
visual humano. El enmascaramiento tambin puede darse en video, donde
cambios rpidos temporales pueden enmascarar cierta prdida de calidad en cada
cuadro.

Debido a la baja correlacin entre el MSE, RMSE y PSNR con la calidad percibida,
en los ltimos tiempos, se ha realizado un gran esfuerzo para desarrollar nuevos
modelos que tengan en cuenta las caractersticas de percepcin del sistema visual
humano y que permitan calcular mtricas objetivas que lo simulen. Sin embargo,
no se existen, al momento de escribir el presente trabajo, mtodos objetivos de la
medida perceptual de calidad de video estandarizados, que apliquen a todos los
casos y con buenos resultados respecto a las medidas subjetivas. Sin embargo,
existen varias propuestas de mtricas de medida, con diversa complejidad y
precisin de sus resultados. Las mtricas basadas en analizar una imagen
degradada y compararla pxel a pxel con su imagen de referencia (MSE, PSNR),
no son suficientes para estimar la calidad percibida de la misma. El sistema visual
humano es extremadamente complejo, y puede detectar fcilmente algn tipo de
distorsin, mientras que puede pasar por alto otras, dependiendo de diversos
factores. Estos factores pueden incluir el tipo de aplicacin (TV, video conferencia,
etc.), el lugar de la imagen en donde se produce la degradacin (generalmente las
degradaciones son menos visibles en regiones con muchos detalles o actividad
espacial, o con gran movimiento, y son ms visibles en imgenes estacionarias, o
en fondos poco texturados). Incluso la calidad percibida puede depender del tipo
de dispositivo utilizado y del tamao del monitor [48].

En forma genrica, los mtodos objetivos de medida de calidad pueden
clasificarse segn la disponibilidad total, parcial o nula de la seal original, como
se detalla a continuacin.

Mtodos con disponibilidad total de la seal original (FR - Full Reference)
Estos mtodos se basan en la disponibilidad de la seal original, la que puede ser
contrastada con la seal degradada, cuadro a cuadro. Esto presupone una severa
restriccin al uso prctico de este tipo de mtodos, ya que en varias aplicaciones
reales esto no es posible. Los mtodos que utilizan mtricas del tipo FR (Full
Reference) pueden ser utilizados para categorizar en forma objetiva un sistema de
transmisin, un codec, el efecto de un reducido ancho de banda, o de diversos
Redes Corporativas


factores que degraden una seal, en ambientes controlados. Sin embargo, no son
adecuados para aplicaciones de tiempo real (TV, video conferencias, etc.), ya que
no es posible tener las seales originales.

Mtodos con disponibilidad parcial de la seal original (RR - Reduced
Reference)
Se trata de enviar, junto con el video codificado, algunos parmetros que
caractericen a la seal, y que sirvan de referencia en el receptor para poder
estimar la calidad percibida. Puede pensarse en la reserva de un pequeo ancho
de banda (comparado con el del video) para el envo de este tipo de informacin
adicional.

Mtodos sin disponibilidad de la seal original - NR (No Reference)
Las personas no necesitan seales de referencia, ni informacin adicional para
juzgar la calidad de una seal de video. Se basan en sus experiencias previas, y
en las expectativas que tengan respecto al sistema. De igual manera, estos
mtodos intentan estimar la calidad percibida basndose nicamente en el anlisis
de la seal recibida. Son los mtodos ms complejos de implementar, pero no
requieren de otra informacin que la propia seal de video.

La gran mayora de los modelos propuestos hasta el momento son del tipo FR
(Full Reference), ya que requieren de la seal de referencia para el clculo de sus
mtricas.

El Video Quality Experts Group (VQEG) [49] est realizando un interesante y
exhaustivo trabajo en el estudio y comparacin de desempeo de mtricas
objetivas, separando el estudio por reas de aplicacin, de acuerdo al tipo de
servicio: FR-TV (Full Reference TV), RRNR-TV (Reduced Reference / No
Reference TV), HDTV (High Definition TV) y Multimedia.

Redes Corporativas


Figura 6.2
Evaluaciones de imgenes comprimidas con JPEG.
Arriba: Imagen Tiffany original y comprimida, MSE=165; Medio: Imagen Lago original y
comprimida, MSE=167; Abajo: Imagen Mandril original y comprimida, MSE=163
Redes Corporativas


Figura 6.3

6.4.1 El trabajo del VQEG

El VQEG (Video Quality Expert Group) [49] est llevando a cabo un gran trabajo
sistemtico y objetivo de comparacin de modelos. El objetivo del VQEG es
proporcionar evidencia para los organismos internacionales de estandarizacin
acerca del desempeo de diversos modelos propuestos, a los efectos de definir
una mtrica estndar y objetiva de calidad percibida de video digital (VQM Video
Quality Metric).

Los estudios del VQEG se dividen en
FR-TV (Full Reference TV)
RRNR-TV (Reduced Reference, No Reference TV)
Multimedia
HDTV

Cada aplicacin, por sus propias caractersticas, requiere de pruebas y modelos
diferentes. El primer proyecto, ya terminado, es el correspondiente a FRTV. Este
proyecto fue llevado a cabo en dos fases, como se detalla a continuacin.

En la fase I de FR-TV, llevada a cabo entre 1997 y 2000, se evaluaron 9
propuestas, adems de la PSNR. Las evaluaciones fueron realizadas con diversos
tipos de material de video, incluyendo 20 tipos diferentes de contenidos (entre los
que hay deportes, animaciones, escenas de interiores y exteriores, etc.) y con
velocidades de 768 kb/s hasta 50 Mb/s. Se utiliz el mtodo DSCQS y las pruebas
Redes Corporativas


se realizaron sobre una base de ms de 26.000 opiniones subjetivas, en 8
laboratorios independientes en diferentes partes del mundo.

Como se mencion, el objetivo es contrastar el resultado presentado por cada uno
de los modelos propuestos, contra el resultado subjetivo obtenido para el mismo
video, utilizando el mtodo DSCQS. El desempeo de cada una de los modelos
propuestos fue evaluado respecto a tres aspectos de su capacidad de estimar la
calidad subjetiva:
Precisin de la prediccin: La capacidad de predecir la calidad subjetiva con
mnimo error
Monotonicidad: Mide si los incrementos (decrementos) en una variable
estn asociados a incrementos (decrementos) en la otra. Tpicamente se
mide con el coeficiente de correlacin de Spearman
Consistencia: Se corresponde con el grado en que el modelo mantiene la
precisin a lo largo de las secuencias de pruebas. Se puede evaluar
midiendo la cantidad de puntos para los que el error de la prediccin es
mayor a cierto umbral, por ejemplo, el doble de la desviacin estndar.

Como resultado de la fase I de FR-TV, dependiendo de la mtrica de comparacin
utilizada, siete u ocho de los modelos propuestos resultaron estadsticamente
equivalentes entre s, y a su vez, equivalentes a los resultados obtenidos con el
PSNR [50]. Este resultado fue realmente desalentador, ya que indica que no
existen diferencias apreciables entre el sencillo clculo del PSNR y los sofisticados
mtodos preceptuales propuestos. En base a estos resultados, el VQEG ha
realizado una segunda fase de pruebas, llamando nuevamente a interesados en
contrastar sus modelos. La denominada fase II para FR-TV fue realizada entre
los aos 2001 y 2003 y los resultados finales fueron publicados en agosto de 2003
[51]. El objetivo de esta segunda fase era obtener resultados ms discriminatorios
que los obtenidos en la fase I. Al igual que en la fase I, las evaluaciones fueron
realizadas con diversos tipos de material de video, y en formato de 525 y 625
lneas por cuadro. Se evaluaron velocidades entre 768 kb/s y 5 Mb/s. Las pruebas
fueron realizadas en 3 laboratorios independientes, en Canad, Estados Unidos e
Italia.

Se evaluaron 6 proponentes, algunos de los cuales ya haban sido evaluados en la
fase I:

NASA (USA, Proponent A)
British Telecom (UK, Proponent D)
Yonsei University / Radio Research Laboratory (Korea, Proponent E)
CPqD (Brazil, Proponent F)
Chiba University (Japan, Proponent G)
NTIA (USA, Proponent H)

En la Figura 6.4 se muestra la exactitud de las predicciones de cada uno de estos
modelos, medidos con el coeficiente de correlacin de Pearson, segn los datos
presentados en [51]. Puede verse que, en el formato de 525 lneas, los modelos
Redes Corporativas


de British Telecom y de NTIA se destacan del resto, y son estadsticamente
equivalentes, segn las conclusiones del informe del VQEG. Estos modelos
presentan una mejora de un 17% respecto al PSNR. Por otra parte, en el formato
de 625 lneas, los modelos de NASA, Yonsei, CpQD y NTIA son los mejores, y
tambin son estadsticamente equivalentes, segn las conclusiones del informe.
En promedio, presentan una mejora de un 21% respecto al PSNR. Con otras
mtricas de comparacin de los modelos (monotonicidad, consistencia) se
obtienen resultados similares.

0
0,1
0,2
0,3
0,4
0,5
0,6
0,7
0,8
0,9
1
N
A
S
A
B
r
i
t
i
s
h

T
e
l
e
c
o
m
Y
o
n
s
e
i

U
n
i
v
e
r
s
i
t
y
C
P
q
D
C
h
i
b
a

U
n
i
v
e
r
s
i
t
y
N
T
I
A
P
S
N
R
525
625

Figura 6.4

El VQEG est en proceso de evaluar modelos del tipo RR y NR (Reduced y No
Reference), para mbitos diferentes al de TV. En particular, se espera realizar
estudios de modelos especficos para Multimedia, los que seguramente tengan
mayor relacin directa con el mbito corporativo.

En el contexto del VQEG, Multimedia se define como una aplicacin que puede
combinar texto, grficos, video y sonido dentro de un mismo paquete. Estas
aplicaciones incluyen, por ejemplo, sistemas de video conferencias. Las
herramientas a evaluar por el grupo MM del VQEG pueden ser utilizadas tanto en
ambientes de laboratorio (con modelos FR) como en ambientes operacionales,
con modelos RR y NR. El anlisis ser basado en medidas del tipo DMOS para los
modelos FR y RR, y medidas de MOS para el modelo NR.

Se espera que las pruebas subjetivas se realicen en forma separada para los
diferentes tipos de monitores utilizados. Por ejemplo, se prevn pruebas
especficas para dispositivos mviles como PDAs, independientes de las pruebas
realizadas en ordenadores de escritorio, ya que las caractersticas visuales de
estos dispositivos son muy diferentes. Por lo tanto, es posible que del resultado de
las pruebas, surjan modelos ms adecuados a cada tipo de dispositivo.

Redes Corporativas


En el caso de RR, se admitirn las siguientes velocidades para el canal de
referencia, dependiendo del dispositivo utilizado:

PDA/Mobile (QCIF): (1 kb/s, 10 kb/s)
PC1 (CIF): (10 kb/s, 64 kb/s)
PC2 (VGA): (10 kb/s, 64 kb/s, 128 kb/s)

La ltima versin disponible del plan de pruebas del grupo MM, al momento de
publicar estas notas, es la 1.16, del 7 de febrero de 2007 [52]

6.4.2 ITU-R BT.1683

Sobre la base de los resultados anteriores, la ITU ha estandarizado, en la
recomendacin ITU-R BT.1683 [53] de junio de 2004, a los cuatro mejores
algoritmos de prediccin de la calidad percibida, definidos en el marco de esta
recomendacin como:

British Telecom BTFR (Reino Unido)
Yonsei University/Radio Research Laboratory/SK Telecom (Corea)
Centro de Investigacin y Desarrollo en Telecomunicaciones (CPqD)
(Brasil)
National Telecommunications and Information Administration
(NTIA)/Institute for Telecommunication Sciences (ITS) (Estados Unidos)

Es importante destacar que los modelos propuestos en esta Recomendacin
pueden utilizarse para evaluar un codec (combinacin de
codificador/decodificador) o una combinacin de varios mtodos de compresin y
dispositivos de almacenamiento en memoria. Aunque en el clculo de los
estimadores de la calidad objetiva descrito en la Recomendacin se considera la
degradacin provocada por errores (por ejemplo, errores en los bits, paquetes
rechazados), no se dispone an de resultados de pruebas independientes para
validar la utilizacin de estimadores en los sistemas con degradacin por errores.
El material de pruebas utilizado por el VEQG no contena errores de canal.

Redes Corporativas


7 Protocolos VoIP

7.1 H.323

H.323 (AUDIOVISUAL AND MULTIMEDIA SYSTEMS: Infrastructure of
audiovisual services Systems and terminal equipment for audiovisual services
[54] es una recomendacin de la ITU-T que describe los terminales y dems
dispositivos que proveen servicios de comunicaciones multimedia (video, voz y
datos) sobre redes de paquetes que no garantizan calidad de servicio (por ejemplo
Ethernet con protocolos TCP/IP).

La primera versin de H.323 fue aprobada en 1996 por la ITU-T. La versin 2 fue
aprobada en enero de 1998, la versin 3 en 1999, la versin 4 en 2000, la versin
5 en 2003 y la versin 6 en junio de 2006. H.323 es parte de las recomendaciones
H.32x (como por ejemplo H.320 para ISDN y H.324 para la PSTN)

H.323 es aplicable a cualquier red conmutada de paquetes, con independencia de
los protocolos utilizados en la capa fsica. La red debe proveer protocolos de
entrega confiables (como por ejemplo TCP - Transmission Control Protocol) y
protocolos de entrega no confiables (como por ejemplo UDP - User Datagram
Protocol). Los protocolos confiables proveen mecanismos de confirmacin de
recepcin de paquetes, y retransmisiones, de ser necesarias, para asegurar la
correcta recepcin de los paquetes enviados. Los protocolos no confiables son
del tipo mejor esfuerzo en la entrega de paquetes, pero no sobrecargan a la red
con paquetes de confirmacin y eventuales retransmisiones, lo que los hace a su
vez ms rpidos.

7.1.1 Arquitectura H.323

La recomendacin H.323 define una arquitectura en la que se diferencian los
siguientes componentes:

Terminales H.323
Pasarelas (Gateways) para interconectar el mundo H.323 con otros
sistemas de telecomunicaciones (tpicamente la red telefnica pblica
analgica y digital)
Controlador H.323 (Gatekeeper)
Unidades de control multipunto (MCU - Multipoint Control Units)

Redes Corporativas


7.1.1.1 Terminales

Los terminales H.323 son los telfonos multimedia IP. Estos telfonos pueden
ser aplicaciones informticas, que utilizan las capacidades multimedia del PC
(parlantes y micrfono), o terminales fsicos de similar aspecto a cualquier telfono
o videotelfono.
La recomendacin establece que esos terminales deben soportar obligatoriamente
comunicaciones de voz y opcionalmente comunicaciones de datos y video. La
recomendacin tambin establece los protocolos utilizados en la sealizacin de
las llamadas, los mensajes de control, la manera de realizar la multiplexacin de
estos mensajes, los codecs de audio y video y los protocolos utilizados para el
intercambio de datos entre los terminales.
Redes Corporativas


Audio Codec

La recomendacin H.323 admite los siguientes tipos de codificacin de audio (ver
captulo Error! No se encuentra el origen de la referencia.):

G.711 (64 kb/s)
G.722 (7 kHz speed at 48, 56 and 64K bit/s (hi-fi voice)
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
sealizacin
H,225.0
(Q.931)

Canal de
RAS
H.225.0

RTP
RTCP

UDP

TCP

IP

Micrfono
Parlante

Cmara
Display

Equipos
de datos

Control

Interfaces
de usuario
Redes Corporativas


G.728 (16 kb/s)
G.723.1 (Dual Rate Speed at 6.4 and 5.3K bit/s)
G.729 (8 kb/s)

Todo terminal H.323 debe obligatoriamente disponer de un codec de audio. Este
codec de audio debe soportar como mnimo la codificacin G.711 (en Ley A y
Ley ), y opcionalmente las otras admitidas por la recomendacin H.323. El tipo
de codec a utilizar al establecer una comunicacin de audio con otro terminal es
negociado segn la recomendacin H.245, por el canal de control de llamadas.
En una misma comunicacin, el terminal H.323 debe ser capaz de utilizar un
codec en la recepcin y otro diferente en la transmisin.

Si el terminal soporta G.723.1, debe ser capaz de codificar a 5.3 kb/s y a 6.3 kb/s.

El audio generado es formateado segn la recomendacin H.225.0, utilizando los
estndares RTP (Real Time Protocol) y RTCP (Real Time Control Protocol).

Video Codec

La codificacin de video es opcional en H.323, por lo que pueden existir
terminales H.323 que no dispongan de facilidades de video. Sin embargo, si el
terminal H.323 dispone de facilidades de comunicaciones de video, debe
adecuarse a los siguientes codificadores:

H.261 (n x 64 kb/s)
H.263 ( < 64 kb/s)

H.261 QCIF es obligatorio si el terminal dispone de facilidades de video. Otros
modos de H.261 y H.263 son opcionales.

El tipo de codec a utilizar al establecer una comunicacin de video con otro
terminal, la velocidad de transmisin, el formato de la imagen y las opciones de los
algoritmos utilizados, son negociados segn la recomendacin H.245, por el canal
de control de llamadas.

Un mismo terminal puede soportar a la vez varios canales de video, tanto en la
transmisin como en la recepcin. Asimismo, en una misma comunicacin, el
terminal H.323 debe ser capaz de utilizar un codec en la recepcin y otro diferente
en al transmisin.

El video generado es formateado segn la recomendacin H.225.0, utilizando
los estndares RTP (Real Time Protocol) y RTCP (Real Time Control Protocol).

Redes Corporativas


Interfaz de datos

Los terminales H.323 pueden establecer comunicaciones de datos con otros
terminales H.323 (por ejemplo, para compartir documentos). Para ello, pueden
abrir canales de datos, los que pueden ser bidireccionales o unidireccionales.

La recomendacin T.120 provee un estndar de interoperabilidad para el
intercambio de datos entre terminales H.323 y otro tipo de terminales (por ejemplo,
terminales H.324, H.320 y H.310).

RTP (Real-Time Transport Protocol)

El protocolo RTP, basado en el RFC 3550 (ver 3.3), establece los principios de un
protocolo de transporte sobre redes que no garantizan calidad de servicio para
datos de tiempo real, como por ejemplo voz y video.

El protocolo establece la manera de generar paquetes que incluyen, adems de
los propios datos de tiempo real a transmitir, nmeros de secuencia, marcas de
tiempo, y monitoreo de entrega. Las aplicaciones tpicamente utilizan RTP sobre
protocolos de red no confiables, como UDP. Los bytes obtenidos de cada
conjunto de muestras de voz o video son encapsulados en paquetes RTP, y cada
paquete RTP es a su vez encapsulado en segmentos UDP.

RTP soporta transferencia de datos a destinos mltiples, usando facilidades de
multicast, si esto es provisto por la red.

RTCP (RTP Control Protocol)

El RFC 3550 tambin detalla el protocolo de control RTCP. Los paquetes RTCP
son enviados peridicamente y contienen indicadores de la calidad del enlace, y
otros datos acerca de la fuente y destino de la comunicacin. Estos indicadores
incluyen la cantidad de paquetes enviados, la cantidad de paquetes recibidos
perdidos y el jitter en el receptor. El RFC 3550 no establece que deben hacer las
aplicaciones (terminales H.323 en este caso) con los indicadores recibidos, sino
que esto queda librado a cada implementacin. Los usos tpicos estn
relacionados con el cambio de codecs, y el reporte de problemas, locales,
remotos o globales.

Canal de control H.245

Los terminales H.323 utilizan uno o varios canales de control para enviar y recibir
mensajes desde y hacia otros terminales y dispositivos H.323 (gateways,
gatekeepers, etc.). El protocolo utilizado en estos canales de control est
determinado en la recomendacin H.245 (Line transmisin of non-telephone
signals Control protocol for multimedia communication (ver [55])) de la ITU-T.
Redes Corporativas


Los mensajes definidos en H.245 incluyen el intercambio de las capacidades de
cada terminal, la apertura y cierre de canales lgicos, mensajes de control de flujo
y comandos e indicadores generales.

Los terminales deben mantener un canal de control H.245 por cada llamada en la
que el terminal est participando. Dado que un terminal puede estar participando
en forma simultnea en varias llamadas, puede tener tambin varios canales de
control H.245 abiertos.

Canal RAS H.225.0 (Registration, Admission and Status)

El canal de RAS es utilizado entre los terminales y el Gatekeeper (Ver 7.1.1.3). A
travs de ste canal, el terminal realiza las funciones de registro, admisin,
solicitud de ancho de banda, status, etc. Este canal de sealizacin es
independiente del canal de control H.245 y del canal de sealizacin de llamadas.
En ambientes de red dnde no se dispone de Gatekeepers (recordar que los
gatekeepers son opcionales en una red H.323), el canal de RAS no es utilizado
por los terminales. En ambientes de red dnde se dispone de un Gatekeeper, el
canal de RAS debe ser abierto entre el terminal y el gatekeeper, antes de ser
abierto cualquier otro canal entre terminales.

El protocolo utilizado en el canal RAS est descrito en la recomendacin de la
ITU-T H.225.0 Call signalling protocols and media stream packetization for
packet-based multimedia communication systems [56]

Canal de sealizacin H.225.0

El canal de sealizacin del terminal H.323 utiliza funciones de sealizacin del
protocolo H.225.0 para establecer conexiones con otro terminal H.323. Este canal
de sealizacin es independiente del canal de RAS y del canal de control H.245.
El canal de sealizacin es abierto por el terminal antes de establecer el canal de
control H.245.

En ambientes de red en los que no hay Gatekeeper, el canal de sealizacin es
establecido directamente entre dos terminales. En ambientes de red en los que se
dispone de un Gatekeeper, el canal de sealizacin es abierto entre el propio
terminal y el Gatekeeper, o entre el propio terminal y otro terminal, de acuerdo a lo
indicado por el Gatekeeper.

La recomendacin H.225.0 utiliza los mensajes descritos en la recomendacin
Q.931 [57], utilizada en ISDN

Redes Corporativas


7.1.1.2 Gateways (Pasarelas)

Los gateways o pasarelas, realizan la funcin de interconexin entre las redes
H.323 y otras redes de comunicaciones, como la red pblica conmutada (PSTN
Public Switched Telephony Network) analgica y digital, o redes SIP.

Los gateways son responsables de adaptar el audio, video y los datos, as como
tambin la sealizacin, entre los formatos propios de H.323 y otras redes de
telecomunicacin, de manera transparente para los usuarios.

Los terminales H.323 pueden comunicarse con otros terminales H.323 de la
misma red en forma directa, sin utilizar gateways. En redes dnde no es necesario
tener comunicacin con terminales externos a la propia red, no es necesario
disponer de gateways. Por ello, son elementos opcionales en la recomendacin
H.323

Hacia la red H.323, el gateway presenta las caractersticas de un terminal H.323 (o
de un MCU Multipoint Control Unit), y hacia la red PSTN, el de un terminal
telefnico (de acuerdo al tipo de red a la que est conectado, podr presentar las
caractersticas de un telfono analgico, ISDN, etc.)

Los gatekeeprs conocen la existencia de gateways, ya que esto es especificado
en el momento en que el gateway se registra en el gatekeeper.

La recomendacin no detalla la manera en que deben implementarse los
gateways. Pueden ser parte del mismo equipo donde reside el gatekeeper, ser
equipos independientes, etc.

Redes Corporativas


7.1.1.3 Gatekeeper

Las redes H.323 pueden disponer de un elemento centralizador de control y
servicios telefnicos, llamado en la recomendacin Gatekeeper. Este dispositivo,
en caso de existir, debe proveer, como mnimo, los siguientes servicios:

Traduccin de direcciones
Una de las funciones principales del Gatekeeper es traducir un nmero telefnico,
o un alias a la direccin de red apropiada (por ejemplo, la direccin IP). Para ello,
el Gatekeeper debe disponer de una tabla de traduccin de direcciones, que se
actualiza cada vez que un dispositivo (por ejemplo un terminal H.323) se registra o
de-registra en el Gatekeeper.

Control de Admisin
El Gatekeeper puede autorizar o negar el acceso (registro) a la red H.323,
utilizando mensajes descriptos en la recomendacin H.225.0. Las reglas de
decisin para autorizar o negar el acceso no son parte de la recomendacin.

Control de Ancho de Banda
El Gatkeeper debe soportar la mensajera H.225.0 respecto a la asignacin de
ancho de banda. Mediante los protocolos adecuados, puede indicar a cada
terminal el ancho de banda total disponible segn el tipo de llamada, las
categoras de los terminales, etc.

Gerenciamiento de su Zona
Un Gatekeeper define una Zona H.323. Los terminales, gateways y MCUs
registrados en el mismo Gatekeeper pertenecen a la misma zona. El Gatekeeper
debe brindar como mnimo los servicios descritos anteriormente para todos los
dispositivos de su Zona.

En forma adicional a los servicios indicados, el Gatekeeper puede brindar
cualquier otro tipo de servicios adicionales, como por ejemplo:

Sealizacin para el control de llamadas
Cuando una red H.323 dispone de un Gatekeeper, la sealizacin para el
establecimiento y liberacin de llamadas puede realizarse directamente entre dos
terminales, o a travs del Gatekeeper. El Gatekeeper puede asumir la funcin de
centralizador de sealizacin, de manera que los terminales tengan que utilizarlo
para las funciones de sealizacin de llamadas.

Autorizacin de llamadas
Mediante el uso de sealizacin H.225.0, el Gatekeeper puede autorizar o negar
llamadas solicitadas desde los terminales. Las razones para autorizar o negar
llamadas pueden incluir criterios de restricciones de ciertos terminales, horarios
del da, etc. La recomendacin no establece cuales deben ser estos criterios, los
que quedan librados a los fabricantes.
Redes Corporativas


Una red puede tener ms de un Gatekeeper, los que pueden comunicarse entre
s. Los protocolos de comunicacin utilizados entre dos o ms Gatekeeper no
estn especificados en la recomendacin.

7.1.1.4 MCU Multipoint Control Unit (Unidad de control multipunto)

El MCU provee soporte para realizar conferencias, entre 3 o ms terminales. Se
compone de unidades Controladoras Multipunto (MC Multipoint Controller) y
Procesadores Multipunto (MP Multipoint Processor)

Controladoras Multipunto (MC Multipoint Controller)
Los controladores multipunto (MC) proveen las funciones de control necesarias
para la implementacin de conferencias de 3 o ms terminales.
Los MC realizan el intercambio de capacidades entre los terminales de la
conferencia, de manera de establecer un modo comn a todos los participantes.
Como parte del establecimiento de una conferencia, los terminales se conectan a
un MC utilizando el canal de control H.245.

Procesadores Multipunto (MP Multipoint Processor)
A diferencia de los MC, que se encarga exclusivamente del control de las
conferencias, los MP reciben los canales de audio, video y/o datos de los
terminales, los procesan, y los redistribuyen nuevamente a los terminales.
Los MP son los encargados de realizar la conmutacin o mezcla del audio y video
proveniente de los terminales, y redistribuirlo hacia los terminales.
El MP puede decidir conmutar el audio o video, de manera de enviar hacia todos
los terminales de la conferencia el audio o video proveniente de uno de los
terminales, o mezclar el audio y video, de manera de enviar hacia todos los
terminales la suma del audio y video proveniente de todos los otros. En el caso de
video, la mezcla puede consistir en enviar hacia un mismo terminal varios
cuadrantes, cada uno con el video proveniente desde los otros terminales.
El criterio utilizado para realizar las mezclas o la conmutacin es determinado por
el MC.

El MCU mnimo puede consistir de un nico MC y ningn MP. En este caso, las
funciones de mezcla y conmutacin de audio y video debern ser provistas por los
propios terminales. Un MCU tpico, que soporte conferencias centralizadas, se
compone de un MC y un MP. Un MCU tpico que soporte nicamente conferencias
descentralizadas, se compone de un MC y un MP con soporte nicamente la
recomendacin T.120 (datos)

Redes Corporativas


7.2 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 Initiaton Protocol). SIP tiene
sus orgenes a fines de 1996, como un componente del Mbone (Multicast
Backbone), El Mbone, era una red experimental montada sobre la Internet, para la
distribucin 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 sesin multimedia, futura o ya establecida.
Bsicamente un protocolo de inicio de sesin (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
[58][59][60][61][62][63].

Una completa introduccin a SIP puede leerse en [64].

7.2.1 Mensajera SIP

La mensajera SIP est basada en el esquema Request Response de http.
Esto presenta ciertas ventajas, sobre todo para los familiarizados con las
tecnologas HTTP. A diferencia de H.323, todos los mensajes son de texto plano, y
por lo tanto fciles de interpretar (recordar que en H.323, los mensajes eran
binarios).

Para iniciar una sesin se enva un mensaje de Request a una contraparte de
destino. El destino recibe el Request, y lo contesta con el correspondiente
Response. Un ejemplo del establecimiento de una comunicacin se muestra en
la figura

Redes Corporativas


Los mensajes de Request tiene el formato

<Mtodo> <URL> <SIP-Version>

Por ejemplo: INVITE sip:pepe@fing.com SIP/2.0

La siguiente tabla resume los mtodos SIP

Mtodo Descripcin
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.
host.abc.com sip.fing.com
200 OK
ACK
INVITE sip:pepe@fing.com
SIP
User Agent
Client
SIP
User Agent
Server
BYE
200 OK
Media Stream
180 Ringing
Redes Corporativas


Las respuestas (Response) tienen el formato

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

Por ejemplo: SIP/2.0 404 Not Found

La siguiente tabla resume las respuestas SIP

Respuesta Descripcin Ejemplo
1xx
Informational Request received, continuing to process
request.
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.
300 Multiple Choices
302 Moved
Temporarily
4xx
Client Error Request contains bad syntax or cannot be
fulfilled at this server.
401 Unauthorized
408 Request Timeout
5xx
Server Error Server failed to fulfill an apparently valid
request.
503 Service
Unavailable
505 Version Not
Suported
6xx Global Failure Request is invalid at any server.
600 Busy Everywhere
603 Decline

Para comprender mejor el formato de los mensajes SIP, se analizar con ms
detalle el mtodo INVITE.

El mtodo INVITE contiene varios campos que forman un cabezal. Este
cabezal incluye atributos que proporcionan informacin adicional acerca del
mensaje. En el INVITE se incluye un identificador nico de la llamada, la
direccin del destino, la direccin del origen, e informacin acerca del tipo de
sesin que se quiere establecer.

Un ejemplo del cabezal de INVITE es el siguiente:

INVITE sip:pepe@fing.com SIP/2.0
Via: SIP/2.0/UDP pc33.montevideo.com;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Pepe <sip:pepe@fing.com>
From: Alicia <sip:alicia@abc.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.montevideo.com
CSeq: 314159 INVITE
Contact: <sip:alicia@pc33.montevideo.com>
Content-Type: application/sdp
Content-Length: 142
Redes Corporativas


La primer lnea del mensaje contiene el nombre del mtodo (INVITE en el
ejemplo anterior). Las lneas siguientes contienen el resto de los campos del
cabezal.

Los detalles de la sesin, como por ejemplo el tipo de medio, el codec o la
frecuencia de muestreo, no son descriptos en el cabezal SIP. El cuerpo del
mensaje SIP contiene una descripcin de estos parmetros, codificados en un
formato conocido como SDP (Session Description Protocol). Este mensaje SDP
(no mostrado en el ejemplo anterior) es transportado en el mensaje SIP de manera
similar a como se transporta un documento adjunto en un mensaje de e-mail. El
formato SDP se estandariza en el RFC 2327 [65]

Un ejemplo del mensaje anterior, incluyendo el cuerpo SDP, se muestra a
continuacin:

INVITE sip:pepe@fing.com SIP/2.0
Via: SIP/2.0/UDP pc33.montevideo.com;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Pepe <sip:pepe@fing.com>
From: Alicia <sip:alicia@abc.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.montevideo.com
CSeq: 314159 INVITE
Contact: <sip:alicia@pc33.montevideo.com>
Content-Type: application/sdp
Content-Length: 142

v=0
o=AGarcia 2890844526 2890842807 IN IP4 126.16.64.4
s=Phone Call
c=IN IP4 100.101.102.103
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000

El formato de cada rengln de SDP es <tipo>=<valor>. <tipo> es siempre un
nico carcter, y se diferencian maysculas de minsculas. El formato de <valor>
depende del <tipo> al que corresponda. No puede haber espacios al lado del =,
ni antes ni despus.

En este ejemplo, SDP contiene:

Versin del protocolo (v)

Origen (o)
o=<username> <session id> <version> <network type> <address type>
<address>

Nombre de la sesin (s)
Debe haber un nico campo de nombre de sesin.
Redes Corporativas


Datos de la conexin (c)
c=<network type> <address type> <connection address>
<network type> = IN para Internet
<address type> = IP4 para IP version 4
<connection address> Es la direccin IP, que puede ser una
direccin de multicast. Puede incluirse un valor de TTL (Time To
Live), luego de la direccin IP, separada con el smbolo /, por
ejemplo:
c=IN IP4 224.2.1.1/127

Temporaizadores (t)
t=<start time> <stop time>
Indica las horas de comienzo y fin de una sesin.

Medios (m)
m=<media> <port> <transport> <fmt list>
<media> puede ser "audio", "video", "application", "data" and "control"
<port> Puerto para el stream de medios
<transport> Para IP4, tpicamente es RTP/AVP, indicando que se
utiliza el transporte RTP
<fmt list> Es el formato del audio o video transportado (Ver Tipo de
informacin (PT=Payload Type) )

Atributos (a)
a=<attribute>:<value>
a=<attribute>

El campo a permite definir atributos, tanto a nivel de la sesin como a nivel
de cada uno de los medios. Puede haber varios campos de atributos. stos
pueden ser propiedades, del tipo a=<flag>, o atributos, del tipo
a=<attribute>:<value>

7.2.2 Arquitectura SIP

SIP utiliza una arquitectura del tipo Cliente-Servidor, y tiene los siguientes
componentes:

Terminales SIP (SIP User Agents)
Servidores SIP (Registrar, Proxy, Redirect, Location, Presence)
Pasarelas SIP (Gateways)

Redes Corporativas


7.2.2.1 Terminales SIP

Los terminales SIP, al igual que los H.323 son telfonos multimedia IP. Estos
telfonos pueden ser aplicaciones informticas, que utilizan las capacidades
multimedia del PC (parlantes y micrfono), o terminales fsicos de similar aspecto
a cualquier telfono o videotelfono.
Los terminales SIP, llamados SIP User Agents, pueden iniciar y recibir sesiones
SIP. Cada terminal dispone de un User Agent Client (UAC) y un User Agent
Server. Los UAC son los encargados de iniciar requerimientos SIP hacia otros
terminales. Los UAS son quienes escuchan y atienden los requerimientos
remotos.

As como los terminales telefnicos clsicos se identifican mediante su nmero de
telfono, o nmero de abonado, y los terminales H.323 mediante su alias, los
terminales SIP se identifican a travs de su direccin SIP. El direccionamiento en
SIP utiliza el formato de URLs de Internet: sip:nombre@dominio

Los terminales SIP pueden soportar servicios de presencia, incorporando agentes
de presencia (PA= Presence Agent). En estos casos son capaces de recibir
solicitudes de subscripciones y generar notificaciones de cambios de estados. Un
PA soporta un paquete de eventos de presencia, el que incluye los mtodos
SUBSCRIBE y NOTIFY.

7.2.2.2 Servidores SIP

Registrar Server

Es un servidor de registro de usuarios SIP. Los usuarios (agentes SIP) solicitan su
registro en este servidor, mediante el intercambio de mensajes SIP. Un servidor de
registro acepta solamente el mtodo REGISTER, rechazando cualquier otro
mtodo con una respuesta 501 (Not Implemented). La informacin de los usuarios
registrados es puesta a disposicin de otros servidores, como los Proxies o
Redirect.

Proxy Server

Es un servidor que atiendo las solicitudes y las redirige. Para ubicar el destino,
puede consultar un servidor de ubicaciones (Location Server). La siguiente figura
esquematiza el funcionamiento de SIP Proxy
Redes Corporativas


Los servidores Proxy tienen las siguientes caractersticas:
1. Un servidor Proxy no origina requerimientos (request), nicamente
responde a requerimientos provenientes de agentes
2. No tiene capacidad de medios (audio, vide, etc.)
3. No cambia ni interpreta los cuerpos de los mensajes. Se basa
exclusivamente en los campos del cabezal del mensaje.

Un uso tpico de servidores Proxy se ve en la siguiente figura [64]:

server.fing.com
200 OK
BYE
200 OK
INVITE
host.fing.com
200 OK
ACK
INVITE
sip.abc.com
SIP
User Agent
Client
SIP
Proxy
Server
SIP
User Agent
Server
Media
Redes Corporativas


Redirect Server

Es un servidor de redireccionamiento. A diferencia del Proxy, no interviene en el
establecimiento de la comunicacin, sino que informa la manera de ubicar al
destino final. La figura siguiente esquematiza el funcionamiento de SIP Redirect
Redes Corporativas


Location Server

Es un servidor de bsqueda. Puede ser consultado para obtener la direccin final
de un usuario SIP.

Presence Server

Un servidor de presencia es un equipo que en ciertas ocasiones acta como un
agente de presencia y enva informacin de presencia a otros agentes, y en otras
ocasiones acta como proxy, redirigiendo las solicitudes de subscripciones a otros
agentes de presencia.

7.2.2.3 Gateway SIP

Al igual que en H.323, existen pasarelas SIP hacia la PSTN y tambin hacia H.323
Los gateways son responsables de adaptar el audio, video y los datos, as como
tambin la sealizacin, entre los formatos propios de SIP y otras redes de
telecomunicacin, de manera transparente para los usuarios.

En redes dnde no es necesario tener comunicacin con terminales externos a la
propia red, no es necesario disponer de gateways.

302 Moved
ACK
Media Stream
INVITE sip:picard@wcom.com
SIP
User Agent
SIP
Redirect
Server
180 Ringing
ACK
INVITE
SIP
User Agent
REGISTER
host.wcom.com
sip.uunet.com
200 OK
server.wcom.com
200 OK
C C
RS
UAS
1
2
3
Redes Corporativas


MUX

LAN
MUX
LAN
WAN
PBX
Voz
Voz
PBX
8 Unificacin en el Backbone

Como vimos en la Introduccin, la integracin de las redes de voz y datos en el
Backbone (es decir, en los enlaces a distancia entre varios puntos de la misma
empresa) es un concepto que tiene ya varios aos, y el principal mvil es el ahorro
econmico.

En la actualidad la gran mayora de las empresas con varias sucursales disponen
de enlaces dedicados de datos, utilizando diversas tecnologas. Estos enlaces,
generalmente tienen un costo fijo mensual, independientemente de su utilizacin.
Es por tanto razonable tratar de incluir en estos enlaces la mayor cantidad de
informacin posible, incluyendo conversaciones de voz.

Para ello se han desarrollado varias tecnologas.

8.1 Multipelxores

Son equipos capaces de combinar (multiplexar) trfico de voz y de datos y enviarlo
por un mismo enlace digital. Un equipo similar en la punta opuesta del enlace
separa (demultiplexa) los distintos tipos de trficos. Los enlaces digitales pueden
ser de diversas tecnologas, como enlaces punto a punto, Frame Relay, ATM, etc.

Los Multiplexores disponen generalmente de interfaces de datos (pueden ser LAN,
seriales, etc.) y de voz (con sealizacin FXS, FXO, E&M, E1, etc.)

Interfaces de Voz:

FXS
Esta interfaz simula una lnea urbana, a la que se puede conectar un telfono
analgico. Tambin es posible conectar un puerto de lnea urbana de una PBX.

Redes Corporativas


FXO
Esta interfaz simula un telfono, a la que se puede conectar una lnea urbana.
Tambin es posible conectar un puerto de interno de una PBX.

E&M
Esta interfaz se conecta a PBX, con sealizacin E&M

T1 / E1
Esta interfaz provee canales telefnicos a travs enlaces digitales T1 (24 canales)
o E1 (30 canales), tpicamente con sealizacin CAS (Channel Associated
Signaling) o ISDN PRI.

En cualquiera de los casos, la voz es empaquetada y enviada al enlace WAN en
conjunto con los datos. El tipo de enlace WAN puede ser IP, Frame Relay, ATM,
etc. La calidad de la voz depende del protocolo del enlace y de varios factores,
como ser, algoritmos de compresin, tecnologa utilizada, ancho de banda, etc.

8.2 Routers con placas de voz

Los equipos ruteadores (routers) fueron diseados originalmente para
interconectar dos o varias redes de rea local (LAN) a travs de enlaces de datos
a distancia (WAN). Generalmente tienen incorporados algoritmos de ruteo de
varios protocolos (incluido casi siempre el protocolo IP), y soportan una gran
variedad de protocolos de WAN (Frame Relay, enlaces punto a punto, etc.)

Muchos de estos equipos soportan actualmente placas de voz, con las mismas
interfaces que los multiplexores (FXS, FXO, E&M, E1, etc.)

8.3 PBX con Gateways IP

Muchas PBX soportan actualmente la incorporacin de Gateways IP. Estos
Gateways conectan la PBX directamente a la LAN, e implementan la conversin
de la voz a paquetes IP y viceversa.

Los paquetes de voz que salen del Gateway son enviados por el Router, a travs
de la WAN, hasta el Gateway de la otra PBX.
Redes Corporativas


Es de hacer notar que en estas configuraciones se requiere que el Gateway
marque los paquetes de voz como prioritarios y que el router respete sta
priorizacin. Esto es muy importante debido a la diferencia de velocidades de
transmisin que tpicamente existen entre la LAN y la WAN. Mientras que en la
LAN es usual disponer de velocidades de 100 Mb/s, en la WAN, sta velocidad no
sobrepasa generalmente 1 Mb/s y muchas veces se dispone velocidades menores
a 0.1 Mb/s (por ejemplo 64 kb/s). Esto indica una relacin de velocidades de 1 a
100 o a 1000.
Por sta razn, los routers implementan colas de datos: Los paquetes recibidos de
la LAN son encolados para ser enviados a la WAN. Dado que la LAN tiene una
velocidad mucho mayor que la WAN, las rfagas de paquetes recibidos desde la
LAN pueden tener que esperar tiempos largos hasta ser enviados a la WAN.
Esto perjudica especialmente a los paquetes de voz y video, que requieren
demoras de punta a punta muy pequeas.
Para evitar estos problemas, es posible marcar los paquetes, tanto a nivel IP
como a nivel Ethernet, indicando la prioridad del mismo. Los routers preparados
para aplicaciones de voz, soportan varias colas de datos, y los envos a la WAN se
realizan por orden de prioridad.
Los estndares ms comunes son DiffServ (para IP) y 802.1p para Ethernet.

Por otro lado, cuando la velocidad de acceso a la WAN es pequea, los tiempos
que demoran en ser enviados los paquetes no son despreciables. Por ejemplo, un
paquete de 1.500 bytes, transmitido a 32 kbps demora 375 mseg en ser
transmitido (1,5x8/32). Los paquetes de voz, an siendo priorizados, debern
esperar a que pase el paquete de datos, por lo que se introducen demoras muy
apreciables en el sistema. Previniendo esto, algunos protocolos de WAN pueden
fragmentar los paquetes IP grandes, en varios paquetes de WAN ms pequeos,
de manera que entre cada fragmento del paquete original se puedan insertar
paquetes de voz. En el caso de Frame Relay, los mecanismos de fragmentacin
estn normalizados, segn la recomendacin FRF-12 (Frame Relay
Fragmentation Implementation Agreement)

PBX
LAN
LAN
WAN
I
P
Router Router

PBX
IP
Redes Corporativas


8.4 Gateways IP independientes

Estos equipos se utilizan cuando se dispone de PBX y routers que no soportan la
incorporacin de Gateways IP. Son equipos independientes, que disponen de las
interfaces telefnicas clsicas (FXS, FXO, E&M, etc.) y son capaces de paquetizar
la voz sobre IP.

Es muy importante que stos equipos puedan marcar a los paquetes que
generan como prioritarios, ya sea a nivel de IP, Ethernet, o ambos. Es tambin
muy importante que los routers respeten la priorizacin, segn las marcas
realizadas por los gateways

PBX
LAN
LAN
WAN
Gw
Router Router

PBX
Gw
Redes Corporativas


Host
LAN

Pbx
Enlace
9 Unificacin en el Escritorio

La unificacin de las redes de voz y datos a nivel del escritorio comprende varias
tecnologas. La tecnologa llamada CTI (Computer Telephony Integration)
permite vincular la telefona con las aplicaciones informticas. Sobre esta
tecnologa se han desarrollado diversos tipos de aplicaciones. Se destaca su uso
en ambientes de Call Center, y ms recientemente, como plataforma tecnolgica
para las denominadas Comunicaciones Unificadas.

9.1 CTI
La tecnologa de CTI (Computer Telephony Integration) fue concebida
manteniendo las redes de voz y las de datos separadas, pero permitiendo integrar
ambos sistemas. Esto se logra a travs de vnculos de datos entre los servidores
informticos y las centrales telefnicas.

Las tecnologas de CTI permiten mantener los telfonos de escritorio, ya sean
TDM (analgicos o digitales) o IP, pero controlados desde aplicaciones
informticas. Estas aplicaciones informticas pueden integrarse con funciones
telefnicas, permitiendo realizar screen popups cuando llega una llamada, y
controlando las funciones de los telfonos desde el computador.

La tecnologa de CTI permite "sincronizar" la recuperacin de datos en las
aplicaciones de los PCs con el ingreso de cada llamada. Por ejemplo, si se
dispone de la facilidad de identificacin del abonado llamante, es posible,
utilizando funciones de CTI, desplegar en la pantalla del PC los datos del llamante
antes de atender la llamada, de manera que se pueda saludar a quien llama por
su nombre, o se conozca el historial del llamante sin necesidad de preguntar su
identificacin.

Las tecnologas de CTI son ampliamente utilizadas, desde hace ya varios aos, en
ambientes de Call Center, dnde es importante minimizar los tiempos de cada
Redes Corporativas


llamada, y brindarle a las telefonistas la mxima informacin posible referente al
cliente.

Estas tecnologas estn teniendo actualmente creciente difusin en ambientes
corporativos, asociados a la integracin de las aplicaciones de escritorio y
sistemas de presencia. Con este tipo de integraciones, el correo electrnico, las
herramientas de oficina y la mensajera instantnea se integran a la telefona,
permitiendo por un lado actualizar el estado de presencia en funcin de la
actividad telefnica, y por otro, iniciar llamadas desde aplicaciones de escritorio,
en forma automtica y a travs del telfono habitual.

CTI es conocido tambin como RCC, o Remote Call Control, entiendo por ste
concepto a las tecnologas que permiten realizar el control de las llamadas y los
telfonos desde aplicaciones externas.

Las tecnologas de CTI estn basadas en arquitecturas del tipo cliente servidor.
Un Servidor de Telefona se vincula con la PBX mediante un enlace dedicado a
tal fin. Originalmente estos enlaces se implementaban sobre comunicaciones
seriales (RS-232 por ejemplo). Actualmente se realizan a travs de la red IP. En el
Servidor de Telefona se instalan programas que dialogan con las PBX, y
publican servicios para los usuarios de la red de datos. stos servicios permiten
controlar los dispositivos telefnicos (por ejemplo, los telfonos) desde
aplicaciones informticas. Existen varios estndares de CTI entre los que se
destacan:

TAPI (Telephony API): Es utilizada en ambientes Microsoft. Las bibliotecas
necesarias para su uso se distribuyen como parte de los sistemas
operativos Windows
JTAPI (Java Telephony API)
CSTA (Computer Supported Telecommunications Applications)
ECMA TR/87
Protocolos propietarios (como por ejemplo MLink de Nortel, ASAI de
Avaya, etc.)

9.1.1 Microsoft TAPI

Las bibliotecas TAPI de Microsoft contienen un conjunto de funciones de telefona,
que pueden ser utilizadas desde aplicaciones desarrolladas en C, C++, .net o
cualquier otro lenguaje de programacin que pueda llamar a funciones de
Microsoft. La arquitectura es del tipo Cliente-Servidor, como se esquematiza en
la figura siguente. En el Servidor residen los componentes Telephony Service (de
Microsoft) y el denominado Telephony Service Provider (TSP), que es el
responsable de mantener el vnculo con la PBX, implementando el protocolo
adecuado (el que puede ser propietario). Los clientes se comunican con el
servidor a travs de las funciones de TAPI locales.

Redes Corporativas


9.1.2 JAVA JTAPI

La especificacin de JTAPI (Java Telephony API) fue desarrollada en forma
conjunta por diferentes empresas, de computacin y telecomunicaciones (Sun,
Avaya, Nortle, Intel, IBM, entre otras). La primera versin de JTAPI data de 1996,
y la ms reciente, la versin 1.4, de 2001. El modelo de JTAPI se muestra en la
siguiente figura. JTAPI es una capa por encima del motor de tiempo real de Java
(Java Run-Time), y accede remotamente a al servidor de telefona, donde residen
APIs de telefona (como TAPI). JTAPI dispone de un conjunto completo de
funciones y eventos de telefona, que pueden ser utilizadas desde aplicaciones
JAVA.

Redes Corporativas


9.1.3 CSTA

CSTA (Computer Supported Telecommunications Applications) proporciona una
capa de abstraccin para las aplicaciones de telecomunicaciones que requieran
usar tecnologas de CTI. La primera versin fue publicada en 1992, y es conocida
con Fase I. La actual Fase III fue publicada en 1998, y ha tenido varias
actualizaciones posteriores. En 2000 CSTA fue estandarizada por la ISO en las
recomendaciones ISO/IEC 18051, ISO/IEC 18052, ISO/IEC 18053 y ISO/IEC
18056.
El modelo de CSTA es similar a los anteriores, conectando el dominio informtica
con el de la PBX a travs de un Switch Link. CSTA utiliza ASN.1 ("Abstract
Syntax Notation One"), una metodologa para representar estructuras de datos
desarrollada por la ITU. ASN.1 consiste en un lenguaje declarativo, y ciertas reglas
de codificacin para traducir el cdigo ASN.1 en un flujo de bytes que se puedan
ser fcil y eficientemente transmitidos. Al estar normalizado, se garantiza que la
codificacin y la decodificacin de los mensajes es realizada de la misma manera.

Redes Corporativas


CSTA tiene un conjunto completo de funciones, incluyendo:

26 funciones de control de llamadas (Call Control, como Make Call,
Answer call, etc.)
6 funciones asociadas a las llamadas (Call Associated, como Send User
Data, etc.)
19 funciones lgicas (Logical Device features, como do not disturb,
forwarding, etc.)
23 funciones asociadas a los dispositivos fsicos (Physical Device como
escribir en los displays de los telfonos, etc.)
5 funciones de intercambio de capacidades (Capability Exchange, como
feature discovery, etc.)
4 funciones de consultas (Snapshot features como consultar las llamadas
establecidas en un dispostivo, etc.)
3 funciones de monitorizacin (Monitor features, como subscribirse a
notificaciones de eventos, etc.)
17 funciones de voz (Voice Services, como deteccin de DTMF, etc.)
Otras funciones de ruteo, funciones de mantenimiento, administracin, etc.

El modelo de llamada entrante en CSTA es el siguiente:

El modelo de llamada saliente (por ejemplo Make Call) en CSTA es el siguiente:

Offered Delivered Established
Accept
Call
Answer
Call
Connection
Cleared Clear
Connection
Redes Corporativas


Adicionalmente, CSTA soporta el control y notificacin de interacciones no
telefnicas, como por ejemplo mensajera instantnea, correo electrnico y Chat.
Esto permite utilizar un mismo modelo para la atencin de contactos multimedia,
ya sean de voz, texto, etc.

9.1.4 ECMA TR/87

Entre los estndares, ECMA (European Computer Manufacturer's Association)
TR/87 se destaca por estar siendo adoptado por diferentes aplicaciones, entre
ellas Microsoft Office Communicator. Este protocolo fue estandarizado por la
ISO en la recomendacin ISO/IEC TR 22767, en agosto de 2005 [66].
Este estndar utiliza el protocolo SIP (ver la seccin 7.2) y lo adapta para ser
utilizado como transporte para notificar los eventos telefnicos de CSTA. Los
eventos telefnicos son embebidos, extendiendo el protocolo CSTA, dentro de
mensajes con formato SIP. Por ejemplo, un mensaje SIP TR/87 tiene un formato
como el siguiente:

INFO sip:SignalingISBEL@isbel.com.uy:5060;maddr=192.168.1.175
contact: <sip:cavallone@isbel.com.uy:1554;maddr=192.168.1.248;transport=tcp;ms-received-
cid=A400>
via: SIP/2.0/TCP 192.168.1.248:9639;ms-received-port=1554;ms-received-cid=a400
max-forwards: 70
from: "Claudio Avallone" <sip:cavallone@isbel.com.uy>;tag=fe92afa496;epid=df4c4f0f01
to: <sip:SignalingISBEL@isbel.com.uy>;tag=af01a8c0-13c4-46f3f24e-167cfc9b-2f52
call-id: 1d8f7fcfb3d54d6b8d0066edd39ccd27
cseq: 6 INFO
user-agent: LCC/1.3
content-disposition: signal;handling=required
content-type: application/csta+xml
content-length: 279

<?xml version="1.0" ?>
- <MakeCall xmlns="http://www.ecma-international.org/standards/ecma-323/csta/ed3">
<callingDevice>tel:121;phone-context=dialstring</callingDevice>
<calledDirectoryNumber>tel:ESN 330</calledDirectoryNumber>
<autoOriginate>doNotPrompt</autoOriginate>
</MakeCall>

El cabezal es un comando SIP, del tipo INFO El cuerpo del mensaje se
corresponde con un formato XML, donde se detalla el tipo de operacin telefnica
a realizar (Make call en el ejemplo anterior).

Connection
Cleared
Established Delivered Offered Originated
Called
Party
clears
Called
Party
answers
Called
Device
alerted
Call
Offered
To
Called
device
Redes Corporativas


La siguiente figura (tomada de [66]) ilustra el proceso de intercambio de mensajes
para iniciar una llamada desde una aplicacin, utilizando TR/87. Se puede
observar como todos la mensajera CSTA se incluyen dentro de mtodos INFO
de SIP.

Redes Corporativas


9.2 Comunicaciones Unificadas

Las comunicaciones unificadas son un resultado directo de la convergencia de las
telecomunicaciones y las aplicaciones. Diferentes formas de comunicacin han
sido histricamente desarrolladas, promocionadas y distribuidas como
aplicaciones independientes. La convergencia de todas las formas de
comunicacin sobre redes IP y sobre plataformas estandarizadas de software han
permitido el desarrollo de un nuevo paradigma, cambiando la manera en que los
individuos y las organizaciones se comunican.

Las Comunicaciones Unificadas reducen la latencia humana en los procesos de
negocios. Si bien los diferentes mtodos de comunicacin (voz, mensajera
instantnea, etc.) pueden ser utilizados en forma individual e independiente, la
unificacin entre todos ellos ayuda a mejorar la productividad y la eficiencia,
permitiendo disminuir los tiempos necesarios para contactar a otras personas, u
obtener respuestas a las necesidades en forma ms rpida.

Las Comunicaciones Unificadas pueden definirse genricamente como una
plataforma de aplicaciones que mejoran la productividad individual, grupal y
organizacional permitiendo y facilitando la administracin y el control integrado de
diversos canales de comunicacin, redes, sistemas y aplicaciones de negocios
[67].

Los componentes de las Comunicaciones Unificadas incluyen aplicaciones de
presencia, mensajera instantnea, telefona IP, conferencia de audio, conferencia
web o colaboracin de datos, mensajera unificada (un lugar comn de
almacenamiento de correo de voz, correo electrnico y fax), movilidad y/o video
conferencia, todo accesible a travs de una nica interfaz de cliente, o embebida
dentro de una interfaz de aplicacin.

9.2.1 Componentes de las Comunicaciones Unificadas

9.2.1.1 Escritorio Convergente

Utilizando Comunicaciones Unificadas se obtiene un escritorio unificado o
convergente (Converged Desktop). Este concepto apunta a consolidar las
interfaces informticas y telefnicas, manteniendo ambas, pero permitiendo un alto
grado de integracin y unificacin. Mediante la utilizacin de tcnicas de CTI,
integradas o embebidas en las aplicaciones de escritorio, es posible:

Recibir notificaciones de llamadas telefnicas en el escritorio:
Mediante la presentacin de pantallas emergentes (screen popups), la
informacin de las llamadas entrantes se despliegan de manera similar a la
recepcin de un nuevo correo electrnico, o de un mensaje instantneo

Redes Corporativas


Controlar el telfono desde el escritorio: Las llamadas pueden ser
atendidas u originadas desde las aplicaciones de escritorio, integrando la
libreta de direcciones corporativa. Mediante 1 click sobre el nombre de la
persona es posible iniciar una llamada, a su interno, a su celular, a su
trabjo, etc.

Redes Corporativas


Activar desvos inteligentes de llamadas: En forma integrada al
calendario de reuniones, o al estado de presencia, es posible activar
desvos de llamadas, al correo de voz, al celular, etc.

Combinar los sistemas de mensajera instantnea y presencia a las
actividades telefnicas: Automticamente el estado de presencia se
cambia a Al telfono cuando se est en una llamada. Adicionalmente, con
una llamada establecida, se puede iniciar una sesin de mensajera
instantnea para intercambiar archivos, o compartir el escritorio.

9.2.1.2 Presencia

La presencia es una indicacin del estado de disponibilidad de una persona para
comunicarse con otras. Los sistemas de presencia basan su desarrollo en las
recomendaciones del RFC 2778 [68] donde se definen las siguientes entidades:

Presentity: Una entidad descrita por su informacin de presencia.
Generalmente esta entidad es una persona, y su estado se mantiene en
un servidor de presencia.
Watcher: Quienes solicitan informacin de presencia de otras personas al
servidor de presencia
Fetcher: Un watcher que solicita el estado actual de presencia de algn
Presentity a travs del servidor de presencia
Subscriber: Un watcher que solicita notificaciones del servidor de
presencia cuando algn presentity cambia de estado.
Poller: Una clase especial de Fetcher que solicita los estados de
presencia en forma regular.

Redes Corporativas


En el contexto de las Comunicaciones Unificadas, diversos tipos de aplicaciones
pueden conocer y presentar el estado de presencia de las personas. Tpicamente
la presencia es indicada en sistemas de mensajera instantnea. Sin embargo, el
estado de presencia puede ser muy til en otro tipo de aplicaciones. En los
clientes de correo electrnico, conocer el estado de presencia del remitente brinda
la posibilidad de decir en el mismo momento el medio por el cual contestar su
solicitud. Si la persona est presente y disponible, puede ser ms eficiente
llamarlo que responderle en forma escrita. Aplicaciones de procesadores de texto
y planillas electrnicas, as como aplicaciones de gestin (CRM, ERP, etc.)
tambin pueden mostrar el estado de presencia de las personas involucradas en
el documento o proceso, mejorando de esta manera la comunicacin
organizacional cooperativa.

9.2.1.3 Mensajera Instantnea

Originalmente los sistemas de mensajera instantnea fueron definidos para
entregar mensajes de texto cortos y simples en forma inmediata a otros usuarios
que estn contactados en lnea. Con el tiempo los sistemas fueron mejorados para
soportar intercambios de archivos, conversaciones de voz y video, y otras
funciones. La definicin estandarizada de estos sistemas se corresponde con el
RFC 2778.

Los sistemas de mensajera instantnea han tenido un enorme xito para la
comunicacin informal interpersonal. Es por ello que su incorporacin al mbito
corporativo sea un camino casi natural.

9.2.1.4 Conferencias

Las conferencias multipartitas existen desde hace tiempo en el ambiente
corporativo. Sin embargo, los conceptos de Comunicaciones Unificadas aplican a
los sistemas de conferencias, permitiendo la integracin con los sistemas de
presencia, mensajera instantnea, calendarios, PBX, etc.

Redes Corporativas


El RFC 4245 [69] publicado en 2005 describe los lineamientos para construir
aplicaciones que soportan conferencias de manera interoperable, basados en SIP.
Los requerimientos bsicos descritos en sta recomendacin incluyen, entre otros:

Descubrimiento: Soportar el descubrimiento automtico de servidores de
conferencias basados en SIP.
Creacin de Conferencias: Crear y especificar las propiedades de
conferencias, ya sean ad-hoc o programadas. Las conferencias iniciadas
desde el escritorio convergente cumplen con las definicin de conferencias
ad-hoc
Terminacin de Conferencias: Terminar las conexiones establecidas en
una conferencia. Debe incluir la capacidad de pasar la conferencia a una
comunicacin bsica punto a punto cuando queden nicamente dos
participantes.
Manipulacin de Participantes: Invitar o desconectar participantes a una
conferencia. Cuando sea necesario, debe permitir el anonimato de los
participantes.
Informacin de Estado: Mantener una base de datos que registre varios
aspectos referentes a la conferencia. Los aspectos a registrar incluyen la
informacin de los participantes, quien es el moderador actual, informacin
acerca de cada sesin, etc.
Migracin de Roles: Debe ser posible cambiar los roles en la conferencia
dinmicamente
Conferencias Asociadas: Poder crear conferencias asociadas y apartadas
entre participantes de la conferencia principal, y con participantes que no
estn en la conferencia principal.

9.2.1.5 Colaboracin

El concepto de Colaboracin involucra a mltiples personas trabajando en
conjunto para lograr un objetivo comn.

Diversas herramientas de colaboracin forman parte de las Comunicaciones
Unificadas. Entre ellas, se destacan:

Vistas compartidas: Permiten compartir documentos o el escritorio de una
o varias personas entre varias personas. Entre las herramientas de vistas
compartidas se incluye la pizarra electrnica.
Navegacin Web compartida: Permite que los participantes de una
conferencia multimedia puedan navegar en forma conjunta por pginas de
Internet. Esto complementa las vistas compartidas, con aplicaciones que
realizan esta funcin de los navegadores de Internet de cada participante,
no mediante una vista compartida del navegador de uno de los
participantes.
Transferencia de Archivos: Permite que un usuario enve un archivo a
uno o varios colaboradores.
Redes Corporativas


Referencias

[1] Redes de Voz, Versin 07, Jos Joskowicz (Agosto 2008)

[2] Redes de Datos, Versin 05, Jos Joskowicz (Agosto 2008)

[3] Recommendation G.722: 7 kHz audio-coding within 64 kbit/s, CCITT,
(1988).
[4] Recommendation G.728: Coding of speech at 16 kbit/s using Low-delay
code excited linear prediction, CCITT, (1992).

[5] Recommendation G.711: Pulse Code Modulation (PCM) of voice
frequencies, CCITT, (1988).

[6] Recommendation G.729: Coding of speech at 8 kbits using Conjugate-
Structure Algebraic-Code-Excited Linear-Prediction (CS-ACELP), ITU-T,
(1996).

[7] Code-excited linear prediction(CELP): High-quality speech at very low bit
rates
Schroeder, M. Atal, B.
Acoustics, Speech, and Signal Processing, IEEE International Conference
on ICASSP '85.
April 1985, Volume: 10, On page(s): 937- 940

[8] Recommendation G.723.1: Dual Rate speech coder for multimedia
communications transmitting at 5.3 and 6.3 kbit/s, ITU-T, (1996).

[9] Overview of the Microsoft RTAudio Speech Codec
2006, Microsoft Corporation

[10] RFC 3550: RTP: A Transport Protocol for Real-Time Applications, H.
Schulzrinne et al (July 2003)

[11] RFC 3551: RTP Profile for Audio and Video Conferences with Minimal
Control, H. Schulzrinne et al (July 2003)

[12] Discrete Cosine Transform
N Ahmed, T Natrajan, K.R. Rao
IEEE Trans. Comput. Vol C-23, No 1, pp90-93, Dec 1984

[13] Trends and Perspectives in Image and Video Coding
T Sikora
IEEE Proceedings, Vol 93, No 1, January 2005

Redes Corporativas


[14] ISO/IEC IS 10918-1, ITU-T Recommendation T.81 Digital compression and
coding of continuous-tone still images: Requirements and guidelines, 1994

[15] ISO/IEC 15444-1:2004. JPEG2000 Image Coding System: Core coding
system

[16] ISO/IEC 11172-2:1993. Information technology Coding of moving pictures
and associated audio for digital storage media at up to about 1.5 Mbit/s

[17] ISO/IEC 13818-2:2000. Information technology generic coding of moving
pictures and associated audio information: Video.

[18] Digital television fundamentals: design and installation of video and audio
systems
Michel Robin, Michel Poulin
ISBN 0-07-053168-4, 1998, McGraw-Hill

[19] ISO/IEC 14496-2:2001. Information technology Coding of audio-visual
objects Part 2: Visual

[20] The H.264/AVC Advanced Video Coding Standard: Overview and
Introduction to the Fidelity Range Extension
Gary J. Sullivan, Pankaj Topiwala, and Ajay Luthra
SPIE Conference on Applications of Digital Image Processing XXVII
Special Session on Advances in the New Emerging Standard: H.264/AVC,
August, 2004

[21] Overview of the H.264 / AVC Video Coding Standard
Thomas Wiegand, Gary J. Sullivan, Gisle Bjontegaard, and Ajay Luthra
IEEE Transactions on Circuits and Systems For Video Technology, Vol 13,
July 2003

[22] Report of The Formal Verification Tests on AVC (ISO/IEC 14496-10 | ITU-T
Rec. H.264)
ISO/IEC JTC1/SC29/WG11, MPEG2003/N6231
December 2003

[23] RFC 2250 Payload Format for MPEG1/MPEG2 Video
D. Hoffman et al, January 1998

[24] RFC 3016 RTP Payload Format for MPEG-4 Audio/Visual Streams
Y. Kikuchi et al, November 2000

[25] RFC 3640 RTP Payload Format for Transport of MPEG-4 Elementary
Streams
Redes Corporativas


J. van der Meer et al, November 2003

[26] VQEG Phase I Test Sequences. [Online]. Disponibles en:
ftp://vqeg.its.bldrdoc.gov/SDTV/VQEG_PhaseI/TestSequences/Reference/

[27] Video coding with H.264/AVC: Tools, Performance, and Complexity
Jrn Ostermann, Jan Bormans, Peter List, Detlev Marpe, Matthias
Narroschke, Fernando Pereira, Thomas Stockhammer, and Thomas Wedi
IEEE Circuits and Systems Magazine, First Quarter 2004

[28] ITU-T P-801 Mean Opinion Score (MOS) (Mtodos de determinacin
subjetiva de la calidad de transmisin), Aug 1996, http://www.itu.int/rec/T-
REC-P.800/es

[29] ITU-T G.107 The E-model, a computational model for use in transmission
planning, March 2005, http://www.itu.int/rec/T-REC-G.107/e

[30] E-model tutorial
http://www.itu.int/ITU-T/studygroups/com12/emodelv1/introduction.htm

[31] TIA/TSB 116-A Telecommunications - IP Telephony Equipment Voice
Quality Recommendations for IP Telephony, Mar 1, 2006

[32] Degradaciones de la transmisin debido al tratamiento de las seales
vocales, Recomendacin ITU-T G.113 (2001)

[33] RFC 3611: RTP Control Protocol Extended Reports (RTCP XR), T.
Friedman et al (November 2003)

[34] Recommendation ITU-T P.862: Evaluacin de la calidad vocal por
percepcin: Un mtodo objetivo para la evaluacin de la calidad vocal de
extremo a extremo de redes telefnicas de banda estrecha y cdecs
vocales, Febrero 2001

[35] DCT Quantization Noise in Compressed Images
Mark A. Robertson and Robert L. Stevenson
IEEE Transactions on Circuits and Systems For Video Technology, Vol. 15,
No. 1, January 2005

[36] Digital Video Image Quality and Perceptual Coding
H.R. Wu and K.R Rao
2006, CRC Press

[37] User-Oriented QoS Analysis in MPEG-2 Video Delivery
O Verscheure, P Frossard, M Hamdi
Redes Corporativas


Real Time Imaging 5, 1999, pp 305-314

[38] Quality Monitoring of Video Over a Packet Network
Amy R. Reibman, Vinay A. Vaishampayan and Yegnaswamy Sermadevi
IEEE TRANSACTIONS ON MULTIMEDIA, VOL. 6, NO. 2, APRIL 2004

[39] Visibility of individual packet losses in MPEG-2 video
Amy R. Reibman, Sandeep Kanumuri, Vinay Vaishampayan and Pamela C.
Cosman
IEEE International Conference on Image Procecssing) 2004, ICIP04, Vol 1,
pp 171-174

[40] Delivery of MPEG Video Streams with constant perceptual quality of service
Quaglia, D. De Martin, J.C.
IEEE, Proceedings International Conference on Multimedia, 2002

[41] Estimation of packet loss effects on video quality
Bouazizi, I.
IEEE, First International Symposium on Control, Communications and
Signal Processing, 2004, pp 91-94.

[42] Packet Loss Resilience for MPEG-4 Video Stream over the Internet
Jae-Young Pyun, Jae-Han Jung, Jae-Jeong Shim
IEEE Transactions on consumer electronics, Vol 48, issue 3, August 2002

[43] Adaptive Media Playout of Low Delay Video Streaming Over Error Prone
Channels
Mark Kalman, Eckehard Steinbach, Bernd Girod,
IEEE Transactions on Circuits and Systems for Video Technology, Vol 14,
no 6, June 2004

[44] Recommendation ITU-R BT.500-11
Methodology for the subjective assessment of the quality of television
pictures
06/2002

[45] Recommendation ITU-T P.910
Subjective video quality assessment methods for multimedia applications
09/199

[46] The handbook of Video Databases: Dessign and Applications, Chapter 41
B. Furth and O, Marqure
September 2003

[47] Digital Video Quality, Vision Models and Metrics
Stefan Winkler
Redes Corporativas


John Wiley & Sons Ltd, 2005

[48] Effect of Monitor Size on User-Level QoS of Audio-Video Transmission over
IP Networks in Ubiquitous Environments
Y. Ito and S. Tasaka
IEEE 16th International Symposium on Personal, Indoor and Mobile Radio
Communications, PIMRC 2005, September 2005, Vol 3, pp 1806-1812

[49] Video Quality Experts Group
http://www.its.bldrdoc.gov/vqeg/

[50] FINAL REPORT FROM THE VIDEO QUALITY EXPERTS GROUP ON THE
VALIDATION OF OBJECTIVE MODELS OF VIDEO QUALITY
ASSESSMENT
June, 2000

[51] FINAL REPORT FROM THE VIDEO QUALITY EXPERTS GROUP ON THE
VALIDATION OF OBJECTIVE MODELS OF VIDEO QUALITY
ASSESSMENT, PHASE II 2003 VQEG
August 25, 2003

[52] Multimedia Group TEST PLAN, Draft Version 1.16
February 7, 2007

[53] RECOMENDACIN UIT-R BT.1683 - Tcnicas de medicin objetiva de la
calidad de vdeo perceptual para la radiodifusin de televisin digital de
definicin convencional en
presencia de una referencia completa
Junio 2004

[54] Recommendation H.323 Version 6: Packet-based multimedia
communications systems, ITU-T (Junio 2006)

[55] Recommendation H.245 Version 9 Control protocol for multimedia
communication , ITU-T (January 2003)

[56] Recommendation H.225.0 Version 4: Call signalling protocols and media
stream packetization for packet-based multimedia communication systems,
ITU-T (March 2001)

[57] Recommendation Q.931: ISDN user-network interface layer 3 specification
for basic call control, CCITT (May 1998)

[58] RFC 3261: SIP: Session Initiation Protocol. J. Rosenberg et al. June
2002

Redes Corporativas


[59] RFC 3262: Reliability of Provisional Responses in Session Initiation Protocol
(SIP) J. Rosenberg et al., June 2002

[60] RFC 3263: Session Initiation Protocol (SIP): Locating SIP Servers. J.
Rosenberg et al. June 2002

[61] RFC 3264: An Offer/Answer Model with Session Description Protocol (SDP)
J. Rosenberg et al. June 2002

[62] RFC 3265: Session Initiation Protocol (SIP)-Specific Event Notification
AB. Roach, June 2002

[63] RFC 3266: Support for IPv6 in Session Description Protocol (SDP)
S. Olson et al, June 2002

[64] SIP : Understanding the Session Initiation Protocol. 2nd ed. (Artech
House telecommunications library)
ISBN 1-58053-655-7, Alan B. Johnston, 2004

[65] RFC 2327: SDP: Session Description Protocol
M. Handley et al., April 1998

[66] ISO/IEC TR 22767:2005 Technical report - Information technology
Telecommunications and information exchange between systems Using
CSTA for SIP phone user agents (uaCSTA), 15 de agosto de 2005

[67] Unified Communications Solutions A practical Business and Technology
Approach
ISBN 978-0-9801074-1-78, Nortel Press

[68] RFC 2778 A Model for Presence and Instant Messaging
M. Day et al, February 2000

[69] RFC 4245 High-Level Requirements for Tightly Coupled SIP Conferencing
O. Levin et al, November 2005

Redes Unificadas 2008

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Redes Unificadas 2008

Cargado por

Copyright:

Formatos disponibles

Redes Corporativas

Redes Unificadas Pgina 1

También podría gustarte