Redes Unificadas 2008

Redes Corporativas
REDES UNIFICADAS
Ing. José Joskowicz

Instituto de Ingeniería Eléctrica, Facultad de Ingeniería
Universidad de la República
Montevideo, URUGUAY
Setiembre 2008
Versión 7
Redes Unificadas Página 1

Redes Corporativas
1 Temario
1 Temario ............................................................................................................ 2
2 Introducción...................................................................................................... 4
3 Voz sobre redes de datos ................................................................................ 6
3.1 Codificación 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 Transmisión de voz sobre redes de datos ................................................ 8
3.3 RTP – Real-Time Transport Protocol ........................................................ 9
3.3.1 Versión (V)....................................................................................... 10
3.3.2 CSRC count (CC) ............................................................................ 11
3.3.3 Tipo de información (PT=Payload Type).......................................... 11
3.3.4 Número 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 Codificación de video .............................................................................. 15
4.2.1 JPEG ............................................................................................... 16
4.2.2 MPEG-x ........................................................................................... 17
4.3 Transmisión de video sobre redes de datos ........................................... 21
4.3.1 Paquetización 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 compresión ...................................................................... 24
5.1.2 Pérdida 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 Tamaño de los paquetes ................................................................ 26
5.2 Medida de la calidad de voz.................................................................... 27
5.3 Métodos Subjetivos de medida de la calidad de voz .............................. 27
5.4 Métodos 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 compresión ...................................................................... 42

Redes Corporativas
6.1.2 Pérdida de paquetes........................................................................ 43

6.1.3 Demora / Jitter ................................................................................. 45
6.2 Medida de la calidad perceptual de video ............................................... 45
6.3 Métodos Subjetivos de medida de la calidad de video............................ 46
6.4 Métodos 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 Mensajería 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 Unificación 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 Unificación 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 Mensajería Instantánea ............................................................ 87
9.2.1.4 Conferencias............................................................................. 87
9.2.1.5 Colaboración............................................................................. 88
Referencias ........................................................................................................... 89

Redes Corporativas
2 Introducción
Las redes de voz [1] y las redes de datos [2] presentan tecnologías muy disímiles.
Por un lado, la transmisión de voz, con una historia de más de 100 años, se basa
en el establecimiento de vínculos permanentes entre dos puntos, diseñados para
transmitir un tipo de señal específico: la voz humana, típica señal analógica, de
ancho de banda acotado, que debe llegar a destino “inmediatamente” y ser lo más
inteligible posible. Por otro lado, la transmisión de datos, con una relativa reciente
historia, se basa en la transmisión de información digital, sin establecer vínculos
permanentes, y donde los retardos no son generalmente importantes.
La integración de estas dos tecnologías 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 económico: es posible ahorrar dinero al integrar las

tecnologías. El segundo aspecto es de administración: es más sencillo administrar
un único sistema que dos independientes. Ambos aspectos son importantes, y las
Empresas, tanto desarrolladoras, como consumidoras de tecnología están
haciendo una fuerte apuesta a esta integración. El tercer aspecto, y quizás a nivel
del usuario presente las ventajas más relevantes, tiene que ver con la mejora en
las aplicaciones. Las nuevas tecnologías de unificación de redes permitirán a los
usuarios disponer de facilidades que hasta hace un tiempo no eran posibles.
La primera etapa en la integración se ha dado, no casualmente, en la transmisión

a distancia. La transmisión a distancia está directamente relacionada con gastos
mensuales, ya sean fijos, o por utilización. Bajar estos costos, incide directamente
en los costos operativos de las Empresas.
La primera “integración” de estas redes, existe desde hace muchos años: Los
MoDems (Moduladores / Demoduladores) utilizan las redes telefónicas para la
transmisión de datos a distancia. Dado que las redes telefónicas 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 diseñaron
los módems, encargados de adaptar la información “de datos” al medio telefónico.
Como éste último esta diseñado para señales analógicas, de hasta 3.4 kHz de
ancho de banda, los módems utilizan “tonos" dentro de esta banda para enviar los
datos que desean transmitir. De esta manera, se utilizan los enlaces telefónicos,
generalmente disponibles y ya amortizados, para transmitir esporádicamente
datos.
Con el incremento de la cantidad computadoras y la baja de sus precios, vino

aparejado la creciente necesidad de intercambio de información (“datos”), y la
comunicación vía módem está limitada por las propias características de la red
telefónica: el teorema de Shannon limita la cantidad de “información por segundo”
que se puede transitar por un enlace de este tipo, a menos de 60 kb/s.

Redes Corporativas
Luego de algún tiempo, con el crecimiento de la necesidad de transmitir datos,

surgieron las primeras redes a distancia de transmisión de datos. Estas redes,
inicialmente “punto a punto”, permitieron aumentar la velocidad en la transmisión
de datos, con un costo fijo mensual para las empresas. En este caso, los “enlaces
de datos”, no están limitados por el bajo ancho de banda de los “enlaces
telefónicos”.
Con la creciente demanda de transmisión de datos, estos enlaces se

incrementaron, ofreciendo mayores capacidades y bajando sus costos. Hasta el
punto en que, en conjunto con las tecnologías de compresión de voz, resulta
actualmente más económico utilizar “enlaces de datos” para transmitir
conversaciones telefónicas.
De esta manera, se invirtió la situación inicial: de utilizar la red telefónica para

cursar datos, se utiliza la red de datos, para cursar tráfico de voz.
Comenzaremos por presentar los problemas tecnológicos que aparecen al cursar

tráfico de voz y video sobre redes de datos. Luego se presentarán las tecnologías
utilizadas para la unificación de las redes en el backbone y en el escritorio.

Redes Corporativas
3 Voz sobre redes de datos
3.1 Codificación de voz
La voz es codificada digitalmente para su transmisión. Los dispositivos de

codificación y decodificación se denominan CoDec (Codificadores /
Decodificadores).
La siguiente tabla resume los algoritmos de compresión de voz más conocidos.
Algoritmo Descripción
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]
8 k bit/s speech (Conjugate structure- algebraic code excited
G.729 Annex A
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 continuación
3.1.1 G.711
El codec básico en telefónica es el estandarizado en la recomendación G.711 de

la ITU-T [5], implementando la “ley A” o “ley µ”. Mediante esta codificación se
obtiene una señal digital de 64 kb/s. La descripción 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 señales de voz. Para ello, se han
desarrollado varias recomendaciones, que reducen la velocidad de transmisión
requerida, a expensas de “degradar” la calidad de la voz.
3.1.2 G.729
El codec G.729 [6] es un estándar de codificación para señales de audio

desarrollado por la ITU, codificando las señales 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 características del oído y de la voz
humana. Dado que el oído 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 posición del tracto vocal (boca, faringe, laringe y
lengua), que filtran los tonos generados por las cuerdas vocales. Las señales
enviadas se llaman descriptores y son una combinación 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 vibración periódica de aire que los excita. El proceso por
el cual se extraen los parámetros del filtro y de la excitación se llama Analysis-by-
Synthesis, AbS. El codificador busca los parámetros y realiza una decodificación
interna (señal sintetizada) para comparar con la señal original. Se eligen los
parámetros que concuerdan mejor y se los envía al decodificador.
Cada 10 ms se extraen los parámetros del modelo CELP (coeficientes del filtro
lineal predictivo, códigos 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 recomendación 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, pudiéndose utilizar un codificador G.729A con un
decodificador G.729 y viceversa. Los cambios respecto a la versión original se
deben a simplificaciones en los algoritmos empleados. La reducción de la
complejidad incluye la sustitución de algunos bloques de procesamiento por otros
más sencillos. También incluye el mantener fijos parámetros que en la versión
completa del codec varían dependiendo del audio a codificar.
El Anexo B de la recomendación G.729 B provee detección de actividad de voz y

silencios y modelado y regeneración del “ruido de fondo”, lo que redunda en una
disminución del ancho de banda total utilizando, ya que no se transmiten muestras
durante los períodos de silencio.
3.1.3 G.723.1
El codec G.723.1 [8] es un estándar de codificación para señales de audio

desarrollado por la ITU, codificando las señales de voz a 6.4 o 5.3 kbit/s. Utiliza
ventanas de audio de 30 ms.

Redes Corporativas
Para la codificación 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 codificación 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 recomendación G.723.1 provee modelado y regeneración del

“ruido de fondo”, lo que redunda en una disminución del ancho de banda total
utilizando, ya que no se transmiten muestras durante los períodos 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
técnicas LPC (Linear Prediction Coefficients).
RTAudio utiliza técnicas de codificación 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 Transmisión 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 conversación
consiste en un “flujo” de 64 kb/s. Cada muestra dura 125 µs. Si bien se podría
formar un paquete con cada muestra de voz, esto generaría 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 mínima sobrecarga porcentual, se pueden introducir
retardos no aceptables. Un paquete IP puede tener hasta 1500 bytes de
información. Si con muestras de 64 kb/s se quisiera completar los 1500 bytes del
paquete IP, se introduciría un retardo de 125µs x 1500 = 187,5 ms. Esta demora
no es aceptable en aplicaciones de voz.
Por esta razón, 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 tamaño de estas ventanas es configurable para algunos
algoritmos de codificación, y está estandarizado para otros.

Redes Corporativas
Flujo de voz, 64 kb/s
Ventana
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, además de

los propios datos de “tiempo real” a transmitir, números de secuencia, marcas de
tiempo, y monitoreo de entrega. Las aplicaciones típicamente 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 múltiples, usando facilidades de

“multicast”, si esto es provisto por la red.

Redes Corporativas
Flujo de voz, 64 kb/s
Ventana
RTP
UDP
IP
Ethernet
Sobrecarga
Cada paquete RTP consiste en un cabezal y los datos de voz. El cabezal contiene
números 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
V P X CC M PT Sequence number
Timestamp
synchronization source (SSRC) identifier
contributing source (CSRC) identifiers

…….
Los campos más relevantes son:
3.3.1 Versión (V)

La versión actual del protocolo es la 2.

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 información (PT=Payload Type)

El campo “payload” identifica el tipo de información que viaja en el paquete. Es un
campo de 7 bits, lo que permite diferenciar hasta 128 tipos de información. En
audio, este campo indica el tipo de codificación. 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 Número de secuencia (Sequence Number)

El campo correspondiente al número de secuencia es de 16 bits. Con cada
paquete enviado, el emisor incrementa en uno el número 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 información 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. Típicamente cada flujo en una
sesión RTP tiene un identificador diferente. El origen establece este número,
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 envía es
producido en un mezclador o “mixer” (por ejemplo, cuando se envía el audio de
varios participantes de una conferencia)
3.4 RTCP – RTP Control Protocol
El RFC 3550 establece, además del protocolo RTP, un protocolo de control,

RTCP, encargado de enviar periódicamente paquetes de control entre los
participantes de una sesión. El protocolo RTCP tiene las siguientes funciones
principales:
• Proveer realimentación acerca de la calidad de los datos distribuidos (por

ejemplo, de la calidad percibida de VoIP). Esta realimentación permite
adaptar dinámicamente la codificación, o tomar acciones tendientes a
solucionar problemas cuando se detecta degradación en la calidad de la
comunicación
• 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 dinámicamente la frecuencia de envío de paquetes de control
RTCP de acuerdo al número de participantes en la sesión. Dado que los
paquetes se deben intercambiar “todos contra todos”, es posible saber
cuantos participantes hay, y de esta manera calcular la frecuencia de
envíos de esto paquetes.
3.5 Ancho de banda en IP para voz
Dado que para el envío 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 envío de voz sobre redes de paquetes se utiliza el
estándar 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
20 ms de voz
Ethernet IP (UDP + RTP)
26 bytes 40 bytes 160 bytes

Redes Corporativas
Esta suma de protocolos hace que el ancho de banda requerido para el tráfico de
voz sobre Ethernet sea bastante mayor al ancho de banda del audio.
Para una ventana de 20 ms, y con codificación 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 (compárese 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 cálculo fue hecho para el envío de audio en una
dirección. Como las comunicaciones son bidireccionales, el ancho de banda real
requerido en la LAN será el doble. Pueden utilizarse técnicas de “supresión de
silencio”, en las que no se envían 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 tamaño de la “ventana” (típicamente 10, 20 o 30 ms) y el codec
utilizado.
La siguiente tabla muestra los anchos de banda unidireccionales necesarios

utilizando redes IP sobre Ethernet
Bytes de Ancho de
Duración de Bytes de Bytes de trama Banda en
Tipo de Codec Trama (ms) voz/Trama paquete IP Ethernet LAN (kbps)
10 80 120 146 116,8
G.711 (64 kb/s) 20 160 200 226 90,4
30 240 280 306 81,6
10 10 50 76 60,8
G.729 (8 kb/s) 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

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, quizás, la aplicación de video más conocida.
Sin embargo, existen en forma cada vez más difundida un nuevo conjunto de
aplicaciones de video, entre las que se encuentran la video telefonía, los servicios
de video conferencia, la distribución de video a demanda a través de Internet y la
IP-TV, por mencionar los más relevantes. Cada una de estas aplicaciones tiene
sus características propias en lo que respecta a requerimientos de calidad,
velocidades, etc.
En el área corporativa, se nota una creciente relevancia de la video-telefonía y las

video-conferencias.
La video-telefonía es una aplicación típicamente punto a punto, con imágenes del

tipo “cabeza y hombros”, y generalmente poco movimiento. Por otra parte, es una
aplicación altamente interactiva, dónde los retardos punta a punta juegan un rol
fundamental en la calidad conversacional percibida.
Las aplicaciones de video conferencias son típicamente punto a multi-punto. Al

igual que la video telefonía, generalmente tienen poco movimiento. Además de la
difusión del audio y el video es deseable en estas aplicaciones poder compartir
imágenes y documentos. La interactividad también es típicamente un requisito,
aunque podrían admitirse retardos punta a punta un poco mayores que en la video
telefonía, ya que los participantes generalmente están dispuestos a “solicitar la
palabra” en este tipo de comunicaciones.
4.2 Codificación de video

Los estudios acerca de la codificación de imágenes y video comenzaron en la
década de 1950. En 1984 fue introducida la estrategia de codificación utilizando la
transformada discreta de coseno (DCT) [12], técnica ampliamente utilizada en los
sistemas actuales de codificación. Las técnicas de compensación de movimiento
aparecieron también en la década de 1980, dando origen a las tecnologías
híbridas MC/DCT (Motion Compensation/Discrete Cosine Transform), utilizadas en
los actuales algoritmos MPEG.
Por otra parte, las transformadas discretas de Wavelets (DWT) comenzaron

también a ser utilizadas en codificación de imágenes en la década de 1980, y
fueron adoptadas más recientemente dentro de las tecnologías MPEG-4 y JPEG
2000, para la codificación de imágenes fijas.
La complejidad de codificadores y decodificadores ha ido aumentando, logrando

un muy alto nivel de compresión, 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 próximo se requiera aún mayor

capacidad de procesamiento, reduciendo los requerimientos de ancho de banda y
mejorando la calidad percibida.
A continuación se presentan, en forma resumida, las características más

destacables de las tecnologías actuales en codificación de imágenes y video, y la
manera de codificar video para su transmisión sobre redes IP. No es el objetivo
principal de este documento presentar un detalle pormenorizado de estas
tecnologías, por lo que sólo se describirán brevemente sus características más
relevantes.
4.2.1 JPEG
JPEG (Joint Photographic Experts Group) [14] es un estándar diseñado para

comprimir imágenes fijas, tanto en color como en blanco y negro. El objetivo
principal de este estándar fue el de lograr compresiones adecuadas, optimizando
el tamaño final de los archivos comprimidos, admitiendo pérdida de calidad en la
imagen. El algoritmo utilizado divide a la imagen en bloques de 8 x 8 píxeles, los
que son procesados en forma independiente. Dentro de cada uno de estos
bloques, se aplica la transformada discreta de coseno (DCT) bidimensional,
generando para cada bloque, una matriz de 8 x 8 coeficientes. La gran ventaja de
estos coeficientes, es que decrecen rápidamente en valor absoluto, lo que permite
despreciar gran parte de ellos (ya que representan información 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 patrón 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 también como componente de DC, haciendo analogía con la
“componente de continua” de una señal eléctrica. 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 estándar JPEG 2000 [15] está también basado en la idea de utilizar para la
codificación los coeficientes de una transformación, pero en este caso se utilizan
transformadas discretas de Wavelets (DWT). Esta transformada permite comprimir
aún más las imágenes 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 diseñado por el “Moving Picture Experts Group”
(MPEG) de la ISO (International Standards Organization) para el almacenamiento
y reproducción 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 codificación en MPEG-1 está basada en la transformada DCT para explotar las

redundancias espaciales dentro de cada cuadro, y en técnicas de estimación y
compensación 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 técnicas de compresión
espacial (transformada DCT dentro del propio cuadro, por ejemplo). Son utilizados
como cuadros de referencia para las predicciones (hacia adelante o hacia atrás)
de cuadros P o B. Los cuadros del tipo P son codificados utilizando información
previa de cuadros I u otros cuadros P, en base a estimaciones y compensaciones
de movimiento. Los cuadros B se predicen en base a información de cuadros
anteriores (pasados) y también posteriores (futuros). El tamaño de un GOP está
dado por la cantidad de cuadros existentes entre dos cuadros I. Típicamente 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 (típicamente una señal PAL se codifica con un GOP de
tamaño 12 y una NTSC con 15, ambas con no más 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 más grande
el GOP, mayor compresión se puede obtener, pero a su vez existe menor
inmunidad a la propagación 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 píxeles, los que son procesados en forma independiente. Dentro de cada
uno de estos bloques, se aplica la transformada discreta de coseno (DCT)
bidimensional, generando para cada bloque, una matriz de 8 x 8 coeficientes. A su
vez, cuatro bloques se agrupan en un “macro-bloque” de 16 x 16 píxeles, el que es
utilizado como base para la estimación del movimiento. La estimación de
movimiento de un macro-bloque se realiza en el codificador, comparando el
macro-bloque de una imagen con todos las posibles secciones de tamaño igual al
macro-bloque (dentro de un rango espacial de 512 píxeles en cada dirección) de
la(s) imagen(es) siguiente(s). La comparación se realiza generalmente buscando
la mínima diferencia (el mínimo valor de MSE - ver sección 6.4) entre el macro-
bloque y la sección evaluada. Este procedimiento se basa en la hipótesis que
todos los píxeles del macro-bloque tendrán por lo general un mismo
desplazamiento, y por lo tanto, será más 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 también son transformadas mediante la DCT para su codificación.

Redes Corporativas
Un flujo de video de MPEG-2 se forma de la manera descrita a continuación. Se

utiliza como unidad básica un macro-bloque, compuesto típicamente 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 ubicación del “slice” en la
imagen y el factor de cuantización usado. Típicamente puede haber un “slice” por
cada fila de macro-bloques, pero puede también haber slices con parte de una fila.
Un grupo de “slices” forma un cuadro, el que es precedido por un cabezal de
cuadro, conteniendo información del mismo, como por ejemplo el tipo de cuadro
(I,P,B), y las matrices de cuantización utilizadas. Varios cuadros se juntan,
formando el GOP, también precedido de un cabezal de GOP. Finalmente, varios
GOPs pueden serializarse en una secuencia (Elementary Stream), con su
correspondiente cabezal, el que contiene información general, como el tamaño 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 evolución de MPEG-1 y 2, y provee la tecnología necesaria

para la codificación en base a contenidos, y su almacenamiento, transmisión y

Redes Corporativas
manipulación. Presenta mejoras interesantes respecto a la eficiencia de la

codificación, robustez de transmisión e interactividad. MPGE-4 puede codificar
múltiples “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
transmisión, 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 estandarización de la
recomendación H.264/MPEG-4 Part 10, también conocida como JVT/H.26L/AVC
(Advanced Video Coding) o H.264/AVC. Este nuevo estándar utiliza
compensaciones de movimiento más flexibles, permitiendo dividir los macro-
bloques en diversas áreas rectangulares, y utilizar desplazamientos de hasta un
cuarto de píxel. Agrega además 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 específicos 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 estándares anteriores [21] [22].
En la Tabla 4.1 se presenta un resumen comparativo de los diferentes estándares

de codificación de video. Como se puede observar en dicha tabla, los
codificadores / decodificadores H.264/AVC no son compatibles con los estándares
anteriores, lo que supone un punto de quiebre en la evolución del video digital.
Característica MPEG-1 MPEG-2 MPEG-4 H.264/MPEG-4
Part 10/AVC
Tamaño del macro-bloque 16x16 16x16 (frame 16x16 16x16
mode)
16x8 (field
mode)
Tamaño del bloque 8x8 8x 8 16x16 8x8, 16x8, 8x16,
8x8, 16x8 16x16, 4x8, 8x4,
4x4
Transformada DCT DCT DCT/DWT 4x4 Integer
transfor
Tamaño de la muestra para aplicar 8x8 8x8 8x8 4x4
la transformada
Codificación VLC VLC VLC VLC, CAVLC,
CABAC
Estimación y compensación de Si Si Si Si, con hasta 16
MV
movimiento
Perfiles No 5 perfiles, varios 8 perfiles, varios 3 perfiles, varios
niveles en cada niveles en cada niveles en cada
perfil perfil 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 64 kbps a 150
Mbps Mbps

Redes Corporativas
Característica MPEG-1 MPEG-2 MPEG-4 H.264/MPEG-4

Part 10/AVC
Complejidad del codificador Baja Media Media Alta
Compatibilidad con estándares Si Si Si No
previos
Tabla 4.1
4.3 Transmisión de video sobre redes de datos
4.3.1 Paquetización 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
pequeños paquetes, de 184 bytes, los que, junto a un cabezal de 4 bytes
(totalizando 188 bytes) conforman el “MPEG Transport Stream” (MTS) y pueden
ser transmitidos por diversos medios.
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 codificación digital de video utiliza algoritmos de compresión,

los que generan codificación de largo variable y flujos de ancho de banda también
variables. Para una aplicación determinada, el ancho de banda requerido en una
red IP dependerá del tipo de codificación utilizada (MPEG-1, 2, 4, H264, etc.), de
la resolución (tamaño de los cuadros SD, CIF, QCIF, etc), del tipo de cuantización
seleccionado y del movimiento y textura de la imagen. Al ancho de banda propio
de la señal 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 codificación de audio,
donde los anchos de banda pueden calcularse en forma exacta en base
únicamente al codec utilizado, la codificación de video es estadística, y depende
de la imagen transmitida, por lo que los cálculos son también aproximados y
estadísticos.
A modo de ejemplo, en la figura Figura 4.4 se muestra coma varía la calidad

percibida en función del ancho de banda para diferentes secuencias de video,
codificadas en MPEG-2, y en resolución CIF (352 x 288) a 25 Hz. En esta gráfica,
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
línea se corresponde con una secuencia de video diferente, tomadas de la página

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
src2
0.8 src3
src4
0.7 src5
src7
0.6 src9
src10
src13
0.5
src14
src16
DMOS
0.4
src17
src18
0.3 src19
src20
0.2 src21
src22
0.1
0
0.000
0.250
0.500
0.750
1.000
1.250
1.500
1.750
2.000
2.250
2.500
2.750
3.000
Bitrate (Mb/s)
Figura 4.4
Por otra parte, en la Figura 4.5, tomada de [27], se muestra como varía el ancho
de banda requerido usando diversos codificadores, en función de la calidad de la
imagen, para una secuencia de video particular (“Tempete”, src22), en resolución
CIF a 15 Hz. Puede verse como para una misma calidad (medida en este caso
como PSNR1), MPEG-2 requiere de aproximadamente el doble de ancho de
banda que H.264/AVC.
1
La definición detallada de la métrica PSNR se presenta más adelante, en el capítulo 6.4

Redes Corporativas
Figura 4.5
Como se puede ver, el ancho de banda de las señales de video puede variar
notoriamente, desde valores cercanos a los 64 kb/s (para baja resolución de
pantalla, imágenes 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 problemáticas 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 pérdida de paquetes, entre
otros factores. Para que la tecnología de VoIP pueda ser utilizada a nivel
corporativo, es esencial garantizar una calidad de voz aceptable. Se analizarán a
continuación los factores que afectan la calidad de voz percibida, y luego los
métodos aceptados para medirla en forma subjetiva y objetiva.
5.1 Factores que afectan la calidad de la voz sobre redes de paquetes
Realizaremos una pequeña discusión acerca de los parámetros que influyen en la

calidad de la voz transmitida a través de la red de datos:
5.1.1 Factor de compresión

Para poder transmitir la voz a través de una red de datos, es necesario realizar
previamente un proceso de digitalización, el que puede degradar la señal de voz
original, debido a la utilización de técnicas de compresión (Ver 3.1)
5.1.2 Pérdida de paquetes

A diferencia de las redes telefónicas, donde para cada conversación se establece
un vínculo “estable y seguro”, las redes de datos admiten la pérdida 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 diseñados para tráfico de
tiempo real generalmente no se recibe confirmaciones de recepción de paquetes,
ya que si el canal es suficientemente seguro, estas confirmaciones cargan
inútilmente al mismo.
En aplicaciones de voz y video, el audio es “encapsulado” en paquetes y enviado,
sin confirmación de recepción de cada paquete.
Si el porcentaje de perdida es pequeño, la degradación de la voz también lo es.
Los porcentajes de perdida admisibles dependen de otros factores, como por
ejemplo la demora de transmisión y el factor de compresión de la voz.
Existen técnicas para hacer menos sensible la degradación de calidad en la voz
frente a la pérdida de paquetes. La más sencilla consiste en simplemente repetir el
último paquete recibido.
También cuentan como “perdidos” los paquetes que llegan a destiempo o fuera de
orden.
5.1.3 Demora
Un factor importante en la percepción 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 compresión

Redes Corporativas
En forma genérica, cuanto mayor es la compresión, más demora hay en el

proceso (los codecs requieren más tiempo para codificar cada muestra).
Algoritmo de muestreo/compresión Demora típica 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
implementación de los protocolos.
• Demoras propias de la red (latencia)

Las demoras propias de la red están dadas por la velocidad de transmisión
de la misma, la congestión, 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

conversación. Hasta 100 ms son generalmente tolerados, casi sin percepción de
los interlocutores. Entre 100 y 200 ms las demoras son notadas. Al acercarse a los
300 ms de demora, la conversación se vuelve poco natural. Pasando los 300 ms la
demora se torna crítica, haciendo dificultosa la conversación.
Un efecto secundario, generado por las demoras elevadas, es el eco. El eco se

debe a que parte de la energía de audio enviada es devuelta por el receptor. En
los sistemas telefónicos 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 telefónicas habituales, el eco existe en niveles
perceptibles (mayores a –25 dB), pero la demora es mínima, por lo que el eco no
es perceptible. Las excepciones son las comunicaciones vía satélite, en las que la
demora promedio es del orden de los 150 ms. Para estos casos, las compañías
telefónicas disponen generalmente de sofisticados equipos canceladores de eco.
5.1.5 Variaciones en la demora (Jitter)
El “jitter” es la variación en las demoras (latencias). Por ejemplo, si dos puntos

comunicados reciben un paquete cada 20 ms en promedio, pero en determinado
momento, un paquete llega a los 30 ms y luego otro a los 10 ms, el sistema tiene
un “jitter” de 10 ms.
El receptor debe recibir los paquetes a intervalos constantes, para poder regenerar
de forma adecuada la señal original. Dado que el “jitter” es inevitable, los
receptores disponen de un “buffer” de entrada, con el objetivo de “suavizar” el
efecto de la variación 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.
Cuánto más variación de demoras (“jitter”) exista, más grande deberá ser el buffer,
y por lo tanto, mayor demora será introducida al sistema.
5.1.6 Tamaño de los paquetes
El “tamaño” de los paquetes influye en dos aspectos fundamentales en la

transmisión 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”, según 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 transmisión. Desde éste punto de vista,
parece conveniente armar paquetes con la mínima 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 mínima de información (bytes) de
control (cabezal del paquete, origen, destino, etc.). Esta información (“sobrecarga”
u “overhead”), no aporta a la información real que se quiere transmitir, pero afecta
al tamaño total del paquete, y por tanto al ancho de banda, como se vio en 3.5.

Redes Corporativas
La duración 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 métodos. Estos

métodos se dividen en subjetivos y objetivos. Los métodos subjetivos de medida
de la calidad de voz, se basan en conocer directamente la opinión de los usuarios.
Típicamente resultan en un promedio de opiniones (por ejemplo, en un valor de
MOS – Mean Opinión Store). Los métodos objetivos a su vez se subdividen en
intrusivos (se inyecta una señal de voz conocida en el canal y se estudia su
degradación a la salida) y no intrusivos (monitorean ciertos parámetros en un
punto de la red y en base a estos permite establecer en tiempo real la calidad que
percibiría un usuario).
Estos métodos se describen en las siguientes secciones.
5.3 Métodos Subjetivos de medida de la calidad de voz
La calidad de la voz se establece a través de la opinión 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 Opinión Store) es el
promedio de los ACR medidos entre un gran número de usuarios.
Si la evaluación es comparativa, (del tipo DCR), el audio se califica también entre

1 y 5, siendo 5 cuando no hay diferencias apreciables entre el audio de referencia
y el medido y 1 cuando la degradación es muy molesta. El promedio de los valores
DCR es conocido como DMOS (Degradation MOS).
La metodología de evaluación subjetiva más ampliamente usada es la del MOS

(Mean Opinión Score), estandarizada en la recomendación ITU-T P.800 [28].
Adicionalmente, se puede evaluar la calidad del audio y la calidad de la
conversación, las que pueden ser diferentes. La calidad de la conversación implica
una comunicación bidireccional, donde, por ejemplo, los retardos juegan un papel
muy importante en la calidad percibida. Los valores obtenidos con las técnicas
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 métodos subjetivos son en general caros y lentos porque requieren un gran
panel de usuarios. Son dependientes entre otros factores del país, del idioma, de
las experiencias previas de los usuarios.

Redes Corporativas
5.4 Métodos Objetivos de medida de la calidad de voz
5.4.1 E-Model
La industria de las telecomunicaciones ha aceptado una representación numérica

de la calidad de la voz, llamada “MOS” (Mean Opinion Score), y estandarizada en
la recomendación ITU-T P.800. La calidad de la voz es calificada con un número,
entre 1 y 5. El valor numérico 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 recomendación 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 típico, en base a parámetros 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 compresión, los
retardos de la red, así como también los factores “típicos” en telefonía como ser
pérdida, ruido y eco. Puede ser aplicado para estimar la calidad de la voz en redes
de paquetes, tanto fijas como inalámbricas [30].
El E-Model puede ser utilizado para evaluar como se verá afectada la calidad de la
voz en una red en base a parámetros mensurables. El modelo parte de un puntaje
“perfecto” (100) y resta diversos factores que degradan la calidad, según se puede
ver en la ecuación (5.4.1).
R = Ro - Is - Id – Ie,eff + A (5.4.1)
donde
Ro Representa la relación señal/ruido básica (antes de ingresar en la

red) que incluye fuentes de ruido, tales como ruido ambiente. El valor inicial
puede ser como máximo 100. Las fuentes de ruido independientes del
sistema como ser el ruido ambiental, pueden hacer que este valor inicial
sea menor a 100.
Is Es una combinación de todas las degradaciones que aparecen de

forma más o menos simultánea con la señal vocal. Por ejemplo, volumen
excesivo y distorsión de cuantización.
Id Representa las degradaciones producidas por el retardo y el eco

Redes Corporativas
Ie,eff “Effective equipment impairment factor”. Representa las

degradaciones producidas por los códecs y por las pérdidas de paquetes de
distribución aleatoria.
A Factor de Mejoras de Expectativas. Muchas veces, los usuarios

están dispuestos a aceptar peor calidad de voz si saben que se están
utilizando tecnologías “no clásicas” (por ejemplo celulares o VoIP). Permite
compensar los factores de degradación cuando existen otras ventajas de
acceso para el usuario.
Los valores de R varían entre 0 y 100, correspondiendo los valores más altos a
mejores calidades de voz.
Los tres tipos de degradaciones (Is, Id y Ie, eff) se subdividen, a su vez, en la

combinación de otros factores, como se detalla a continuación.
Cálculo de Is
Is = Iolr + Ist + Iq (5.4.2)
donde
Iolr Representa la disminución 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 pérdida entre la boca del

emisor y el micrófono del aparato telefónico
SLR (Receive Loudness Rating), es la pérdida entre el parlante del

aparato telefónico y el oído del receptor
Ist Representa la degradación producida por efectos locales no óptimos,

y depende esencialmente del factor STMR (Side Tone Masking Rating).
Parte de la señal recibida por el micrófono es transmitida, dentro del mismo
teléfono, al parlante, generando un “efecto local” que hace que la persona
que habla se escuche por el oído en el que tiene el tubo o microteléfono. La
atenuación de la señal que pasa del micrófono al parlante del mismo
aparato se conoce como STMR. Si este valor no está dentro de los
parámetros adecuados, genera una sensación de “eco”, o de “línea muerta”,
según el caso, bajando la calidad de la comunicación.

Redes Corporativas
Iq Representa la degradación producida por la distorsión de

cuantificación. Se calcula en base a “unidades qdu” . 1 qdu se define como
el “ruido” de cuantización” que resulta de una codificación y decodificación
completas en Ley A o Ley µ
La fórmula de cálculo detallada de los parámetros (Iolr, Ist, Iq) puede verse en la
recomendación G.107 [29].
Cálculo de Id
Id = Idte + Idle + Idd (5.4.4)
Donde
Idte Expresa una estimación 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 atenuación del eco percibido por el hablante.
Idle 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 atenuación entre la señal
“directa” recibida por el oyente, la señal retardada recibida como eco.
Idd Representa la degradación producida por retardos absolutos

demasiado largos Ta, que se producen incluso con compensación perfecta
del eco. Si Ta < 100 ms, el factor Idd es 0.
La fórmula de cálculo detallada de los parámetros (Idte, Idle, Idd) puede verse en la
recomendación 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
User Satisfaction
100
Very
satisfactory
90
Satisfactory
80
Some users
R TELR = 65 dB
dissatisfied
70
Many users
dissatisfied
60
Exceptional
limiting case
50
0 100 200 300 400 500
One-way Delay (ms)
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 comunicación, haciéndola poco natural.
Si a la gráfica anterior se le suma el efecto del eco, el modelo E predice las

siguientes curvas:

Redes Corporativas
User Satisfaction
100
Very
satisfactory
90
Satisfactory
80 TELR = 65 dB
Some users
R TELR = 60 dB
dissatisfied
70 TELR = 55 dB
Many users TELR = 50 dB

dissatisfied
TELR = 45 dB
60
Exceptional
limiting case
50
0 100 200 300 400 500
One-way Delay (ms)
Es de hacer notar que el valor TELR es la medida de la atenuación del eco

percibido por el hablante. Cuanto más atenuado el eco percibido (mayor valor en
db de TELR), menor efecto tiene el eco sobre la degradación. En la medida que
aumenta el eco, el valor de R decrece rápidamente con el retardo.
Cálculo de Ie-eff
Ie-eff representa las degradaciones producidas por los códecs y por las pérdidas de
paquetes, según la siguiente fórmula:
Ppl
Ie-eff = Ie + (95 − Ie) ⋅ (5.4.5)
Ppl
+ Bpl
BurstR
Donde
Ie Es un valor que depende del codec utilizado, y representa la

degradación percibida producida por los diferentes algoritmos de
compresión.
Ppl Representa la probabilidad de pérdida de paquetes
Bpl Se define como el “factor de robustez” contra pérdida de paquetes, y

es un valor preestablecido para cada codec

Redes Corporativas
BurstR Es la “Relación de ráfaga”, y se define como
Longitud media de las ráfagas observadas en una secuencia de llegada

BurstR =
Longitud media de las ráfagas previstas en la red en condiciones de pérdida " arbitraria"
Si no existen pérdida de paquetes (Ppl=0), el factor Ie-eff depende

únicamente del tipo de codec utilizado
Los valores de Ie para los diferentes codecs se detallan en la siguiente

tabla:
Codec Type Reference Operating Rate Ie

kbit/s 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 pérdida de paquetes y sin eco, el valor de R dependerá de la

demora y de los codecs utilizados, según se muestra en la siguiente gráfica, para
G.711, G.729A y G.723.1 (notar que la gráfica “negra” coincide con las gráficas
anteriores)

Redes Corporativas
User Satisfaction
100
Very
satisfactory
90
Satisfactory
80
G.711
Some users
R dissatisfied
70 G.729A
Many users
dissatisfied G.723.1
60
Exceptional
limiting case
50
0 100 200 300 400 500
One-way Delay (ms)
En una red con pérdida de paquetes, el valor de R depende de la utilización o no

de técnicas de PLC (Packet Loss Compensation). A modo de ejemplo, para los
codecs G.711 y G.729, las siguientes gráficas muestran el efecto conjunto de la
demora y la pérdida de paquetes.

Redes Corporativas
Cálculo de A
A representa un “Factor de Mejoras de Expectativas”. Muchas veces, los usuarios

están dispuestos a aceptar peor calidad de voz si saben que se están utilizando
tecnologías “no clásicas” (por ejemplo celulares o VoIP). No existe, por
consiguiente, ninguna relación entre A y los demás parámetros de transmisión.
El cuadro siguiente presenta los valores típicos de A para diferentes tecnologías,

según la recomendación ITU-T G-113 [32].
Ejemplo de sistema de comunicación Valor máximo de A

Convencional (alámbrico) 0
Movilidad mediante redes celulares en un edificio 5
Movilidad en una zona geográfica o en un vehículo en 10
movimiento
Conexión con lugares de difícil acceso, por ejemplo, 20
mediante conexiones de múltiples saltos por satélite

Redes Corporativas
Relación de R y MOS
El modelo relaciona el valor de “R” con el “MOS”, con un gran nivel de

aproximación, según la siguiente ecuación:
Para R < 6.5: MOSCQE = 1
Para 0 < R < 100: MOSCQE = 1 + 0,035 R + R ( R − 60)(100 − R )7 ⋅10 −6 (5.4.6)
Para R > 100: MOSCQE = 4,5
La siguiente figuras muestran la relación entre R y MOS, según la fórmula anterior:
MOS
Excelente 5
Buena 4
Mediocre 3
Pobre 2
G.107_FB.2
Mala 1
0 20 40 60 80 100 R

Redes Corporativas
Aplicación del E-model
El RFC 3611 [33] define campos de “reportes extendidos” (XR, Extended Reports)
en el protocolo RTCP que permiten intercambiar información acerca de la calidad
de la comunicación. En este RFC se incluye la posibilidad de intercambiar
información 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 recomendación ITU-T P.862 [34] presenta un método objetivo para la

evaluación de la calidad vocal de extremo a extremo de redes telefónicas de
banda estrecha y codecs vocales.
Esta recomendación describe un método objetivo para predecir la calidad subjetiva

de la voz telefónica utilizando los codecs más comunes. Presenta una descripción
de alto nivel del método, explica la forma de utilizar este método y parte de los
resultados de referencia obtenidos por la Comisión de Estudio 12 de la ITU-T en el
periodo 1999-2000. Proporciona adicionalmente una implementación de referencia
escrita en el lenguaje de programación ANSI-C.

Redes Corporativas
El método objetivo descrito se conoce por "evaluación de la calidad vocal por

percepción" (PESQ, perceptual evaluation of evaluation of speech quality) y es el
resultado de varios años de trabajos de desarrollo.
PESQ compara una señal inicial X(t) con una señal degradada Y(t) que se obtiene
como resultado de la transmisión de X(t) a través de un sistema de
comunicaciones (por ejemplo, una red IP). La salida de PESQ es una predicción
de la calidad percibida por los sujetos en una prueba de escucha subjetiva que
sería atribuida a Y(t).
El primer paso de PESQ consiste en una alineación temporal entre las señales
iniciales X(t) y degradada Y(t). Para cada intervalo de señal se calcula un punto de
arranque y un punto de parada correspondientes.
Una vez alineadas, PESQ compara la señal (entrada) inicial con la salida
degradada alineada, utilizando un modelo por percepción, como el representado
en la siguiente figura
Lo esencial en este proceso es la transformación de las dos señales, la inicial y la

degradada, en una representación interna que intenta reproducir la representación
psicoacústica de señales de audio en el sistema auditivo humano, teniendo en
cuenta la frecuencia por percepción (Bark) y la sonoridad (Sone).
El modelo cognitivo de PESQ termina brindando una distancia entre la señal vocal
inicial y la señal vocal degradada (“nota PESQ”), la que corresponde a su vez con
una predicción de la MOS subjetiva. La nota PESQ se hace corresponder a una
escala similar a la de MOS, un número único en una escala de –0,5 a 4,5, aunque
en la mayoría 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 descripción detallada del algoritmo es compleja, y puede verse en la

recomendación referenciada.
El método PESQ es objetivo e intrusivo, ya que requiere del envío de una señal
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 método.
5.4.3 ITU-T P.563
El algoritmo P.563 es aplicable para la predicción de la calidad vocal sin una señal
de referencia independiente. Por ese motivo, este método se recomienda para la
evaluación no intrusiva de la calidad vocal y para la supervisión y evaluación con
la red en funcionamiento, empleando en el extremo lejano de una conexión
telefónica fuentes de señal vocal desconocidas.
En comparación con la Rec. ITU-T P.862 (que utiliza el método “basado en dos
extremos” o “intrusivo”) que compara una señal de referencia de elevada calidad
con la señal degradada en base a un modelo perceptual, P.563 predice la calidad
de la voz de una señal degradada sin una señal vocal de referencia dada. En la
figura siguiente se ilustran las diferencias entre ambos métodos.

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 microteléfono
convencional conectado en paralelo a la línea. Esta visualización permite explicar
la principal aplicación y permite al usuario clasificar las puntuaciones obtenidas
mediante P.563. La puntuación de calidad que se predice mediante P.563 está
relacionada con la calidad percibida en extremo receptor.
La señal vocal que debe evaluarse se analiza de varias formas, que detectan un
conjunto de parámetros de señal característicos. En base a un conjunto
restringido de parámetros clave se establece la asignación a una clase de
distorsión principal.
Básicamente, la parametrización de la señal del algoritmo P.563 puede dividirse

en tres bloques funcionales independientes que se corresponden con las tres
clases de distorsión principales:
• Análisis del tracto vocal y desnaturalización de la voz

o voces masculinas
o voces femeninas
o marcada robotización
• Análisis de un ruido adicional intenso

Redes Corporativas
o SNR estática reducida (nivel básico del ruido de fondo)

o SNR por segmentos reducida (ruido relacionado con la envolvente
de la señal).
• Interrupciones, silenciamientos y recorte temporal
El modelo de calidad vocal de P.563 se compone de tres bloques principales:

1. Decisión sobre la clase de distorsión de que se trata.
2. Evaluación de la calidad vocal intermedia para la correspondiente clase de
distorsión.
3. Cálculo global de la calidad vocal.
Cada clase de distorsión utiliza una combinación lineal de varios parámetros para
generar la calidad vocal intermedia.
La calidad vocal definitiva se calcula combinando los resultados de calidad vocal
intermedia con algunas características adicionales de la señal.
La descripción detallada del algoritmo es compleja, y puede verse en la

Recomendación referenciada.

Redes Corporativas
6 Calidad de video en redes IP

La transmisión de video y multimedia sobre redes de datos enfrenta problemáticas
específicas en lo que respecta a la calidad percibida por los usuarios. Varios tipos
de degradaciones suelen presentarse en las señales de video transmitidas sobre
redes de paquetes. El estudio en esta área es todavía un tema de investigación.
Se analizarán a continuación los factores que pueden afectar la calidad de video
percibida, y luego los métodos aceptados para medirla en forma subjetiva y
objetiva.
6.1 Factores que afectan la calidad del video sobre redes de paquetes
La transmisión de video sobre redes de paquetes, y en particular, sobre la Internet,

presenta características esencialmente diferentes a la de la difusión de TV por las
vías clásicas (radiofrecuencia, TV-cable). Se utilizan rangos de anchos de banda
variables, hay congestión y pérdida de paquetes, y típicamente, en las
aplicaciones corporativas, la observación se realiza desde distancias más cortas, y
generalmente en pantallas más pequeñas.
En esta sección se describirán conceptualmente los factores específicos de las

redes IP que afectan a la calidad de video.
6.1.1 Factor de compresión
El proceso de digitalización de video utiliza técnicas que transforman una

secuencia de píxeles al dominio de la frecuencia espacial (DCT), cuantificando
valores, descartando eventualmente componentes de alta frecuencia, y haciendo
uso de técnicas de predicción y compensación de movimientos. Esto genera “ruido
de cuantificación”, el que puede degradar la imagen original a niveles perceptibles.
Es este “ruido de cuantificación” [35], el que genera las clásicas degradaciones
que pueden verse en imágenes y videos con alta compresión, entre ellos, el
conocido “efecto de bloques”, que hace ver a la imagen como un conjunto de
bloques pequeños.
Los algoritmos de compresión utilizados actualmente en la codificación digital de

video introducen varios tipos de degradaciones, las que se pueden clasificar según
sus características principales [36]. Esta clasificación 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 señal sin
comprimir, el uso de codecs con compresión es sumamente habitual en video.
Esto pone un límite a la calidad de imagen recibida, el que es independiente del
medio de transmisión sobre el que viaje la señal.

Redes Corporativas
Las principales degradaciones introducidas por el uso de codecs con compresión

son las siguientes:
• Efecto de bloques (blocking)

• Efecto de imagen de base (basis image)
• Borrosidad o falta de definición (Blurring)
• Color bleeding (Corrimiento del color)
• Efecto escalera y Ringing
• Patrones de mosaicos (Mosaic Patterns)
• Contornos y bordes falsos
• Errores de Compensaciones de Movimiento (MC mismatch)
• Efecto mosquito
• Fluctuaciones en áreas estacionarias
• Errores de crominancia
6.1.2 Pérdida de paquetes
La pérdida 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 pérdida de un paquete puede
propagarse, afectando no solo a la información de video contenida en dicho
paquete, sino a otras partes del mismo o diferentes cuadros. Típicamente, y dado
que la codificación se realiza en forma diferencial, la pérdida de un paquete
afectará a todos los bloques siguientes en la misma fila (“slice”). Si el paquete
perdido corresponde además a un cuadro de referencia (I), también se verán
afectados los cuadros predictivos, posteriores o anteriores, propagándose el error
en el tiempo.
Figura 6.1

Redes Corporativas
Existen técnicas de cancelación de paquetes perdidos, las que tratan de

reconstruir la información perdida en base a información disponible. Por ejemplo,
reemplazando los píxeles 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 pérdida de paquetes. Algunos [38] proponen estimar el MSE
del video, en base a diferentes técnicas, que tienen en cuenta la pérdida de
paquetes. Sin embargo, estos son estimadores no se corresponden con la calidad
“perceptual”, al basarse en la predicción del MSE o PSNR, los que no tienen
relación directa con el MOS.
En [39] se muestra que no basta con conocer el porcentaje de pérdida de

paquetes para estimar como se ve afectada la calidad de video percibida.
Dependiendo de diversos factores, la pérdida de un paquete determinado de video
puede o no afectar la calidad percibida. Por ejemplo, en imágenes casi estáticas,
el video perdido puede ser reconstruido en base a imágenes anteriores, casi sin
pérdida de calidad, lo que lleva a que la pérdida de un paquete sea prácticamente
imperceptible. Algo similar sucede cuando la pérdida 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 verán afectados por la
pérdida del paquete, la movilidad de la imagen y su varianza y el error introducido
medido con MSE, entre otros factores. Se define el parámetro VPLR (Visible
Packet Loss Rate), en lugar del clásico PLR (Packet Loss Rate), para ser utilizado
como entrada a los algoritmos de predicción de calidad en base a la pérdida de
paquetes.
La idea de detectar como afecta la posible pérdida de cada paquete en la calidad

perceptual es explorada en [40], donde se propone un método que garantice una
calidad perceptual constante en la recepción de un flujo de video. La idea en este
caso es marcar solo ciertos paquetes específicos 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 pérdida afecten especialmente la
calidad percibida. El algoritmo se basa únicamente en la calidad deseada (PSNR)
y la tasa de pérdida de paquetes (PLR).
Una idea similar es presentada en [41], donde se presenta una métrica para
priorizar ciertos paquetes de video, en base a la estimación de la distorsión
percibida en caso de la pérdida o llegada fuera de tiempo de cada paquete.
Dado que las pérdidas de paquetes se dan generalmente en ráfagas, la calidad

puede verse fuertemente degradada por la pérdida de varios paquetes
consecutivos, correspondientes a cuadros consecutivos. En [42] se propone una
técnica que consiste en reagrupar los cuadros que se envían, generando un buffer
en el codificador de 3 GOPs, y reagrupando el orden en el que se envía la
información. Con esto se logra difundir los paquetes perdidos entre varios cuadros

Redes Corporativas
separados en el tiempo, y de esta manera, según los autores, mejorar la calidad

percibida.
Si bien varios trabajos se han realizado acerca de la degradación del video debida
a la pérdida de paquetes, el tema está aún abierto, y no hay aún estándares ni
trabajos sistemáticos de comparación 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 señal 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 variación 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. Cuánto
más variación de demoras (jitter) exista, más 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, distribución de eventos deportivos en línea) y en
aplicaciones conversacionales (por ejemplo video telefonía, o video conferencias).
Se hace necesario disponer de mecanismos que minimicen el tamaño 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 método dinámico al que llaman AMP (Adaptive Media

Playout), en el que se cambia la velocidad de reproducción del medio (video /
audio) dependiendo de la condición del canal de transmisión, y logrando de esta
manera reducir el tamaño 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 pérdidas de paquetes impulsivas en el
rango de 0 a 50%.
6.2 Medida de la calidad perceptual de video
La manera más confiable de medir la calidad de una imagen o un video es la

evaluación subjetiva, realizada por un conjunto de personas que opinan acerca de
su percepción. La opinión media, obtenida mediante el “MOS” (Mean Opinion
Score) es la métrica generalmente aceptada como medida de la calidad. Para ello,
los experimentos subjetivos controlados continúan siendo actualmente los

Redes Corporativas
métodos de medida reconocidos en la estimación perceptual de la calidad del

video.
Los métodos de medida de calidad de video, al igual que los de voz, se clasifican
en métodos subjetivos y métodos objetivos. Los métodos subjetivos se basan en
conocer directamente la opinión de los usuarios. Los métodos objetivos intentan
predecir la calidad percibida por los usuarios, en base a medidas que puedan
realizarse mediante algoritmos automáticos.
6.3 Métodos Subjetivos de medida de la calidad de video

Diversos métodos subjetivos de evaluación de video son reconocidos, y están
estandarizados en la recomendación ITU-R BT.500-11 [44], especialmente
desarrollada para aplicaciones de televisión y en la recomendación ITU-T P.910
[45], para aplicaciones multimedia. En todos los métodos propuestos, los
evaluadores son individuos que juzgan la calidad en base a su propia percepción y
experiencia previa. Estos métodos tienen en común la dificultad y lo costoso de su
implementación.
La recomendación BT.500-11 detalla los siguientes métodos:
• DSIS – Double Stimulus Impairment Scale (Escala de degradación con

doble estímulo)
• DSCQS – Double Stimulus Continuos Quality Scale (Escala de calidad
continua de doble estímulo)
• SSCQE - Single Stimulus Continuous Quality Evaluation (Evaluación de
calidad continua de estímulo único)
• SDSCE - Simultaneous Double Stimulus for Continuous Evaluation (Método
de doble estímulo simultáneo para evaluación continua)
La recomendación P.910 detalla los siguientes métodos:
• ACR - Absolute Category Rating (Índices por categorías absolutas)

• DCR - Degradation Category Rating (Índices por categorías de
degradación)
• PR - Pair Comparison (Método de comparación por pares)
En los diferentes métodos los participantes deben calificar las secuencias de

video, solas o comparadas con la señal de referencia, en escalas que
generalmente van de 1 a 5, en forma discreta o continua, según el método.
Las recomendaciones establecen los detalles de los procedimientos para realizar

las encuestas.

Redes Corporativas
6.4 Métodos Objetivos de medida de la calidad de video
Los métodos subjetivos, presentados en la sección anterior, son costosos, difíciles

de realizar, e impracticables en aplicaciones de tiempo real.
Por esto se hace necesario el uso de métodos objetivos y automáticos, que
puedan predecir con fiabilidad la calidad percibida, en base a medidas objetivas
tomadas en algún punto del sistema.
Las primeras medidas objetivas de la calidad del video están basadas en obtener
las diferencias, píxel a píxel, entre las imágenes originales (previo a la compresión
y transmisión) y las imágenes presentadas (luego de la recepción y
reconstrucción). Dado que los sistemas de video utilizan técnicas de compresión
con pérdida de información, y que los medios de transmisión a su vez pueden
introducir factores distorsionantes (retardos, pérdida de paquetes, etc.), las
imágenes presentadas serán diferentes a las originales.
Las medidas más simples son las de error cuadrático medio (MSE - Mean Square
Error) y su raíz cuadrada (RMSE = Root Mean Square Error) y la relación señal a
ruido de pico (PSNR – Peak Signal to Noise Ratio), definidas en las ecuaciones
(6.1) a (6.3) más adelante. Estas métricas requieren de la referencia completa de
la señal original para poder ser calculadas.
2
1 N M T
MSE= ∑∑∑ x(m, n, t ) − y(m, n, t )
TMN n=1 m=1 t =1
[ ] (6.1)
RMSE= MSE (6.2)
 L2 
PSNR=10 log10   (6.3)
 MSE 
donde la imagen tiene N x M píxeles y T cuadros, x, y son los píxeles de la imagen

original y la distorsionada respectivamente. L es el rango dinámico que pueden
tomar los valores de x o y , y toma el valor 255 para 8 bits por píxel.
Estas métricas son fáciles de calcular, y tienen un claro significado. Por estas
razones, han sido ampliamente usadas como métricas en la estimación de la
calidad de video. Hay que poner especial énfasis en la alineación espacial y
temporal de las imágenes a comparar, ya que la referencia y la imagen degradada
pueden estar desfasadas en el tiempo o en el espacio.
Sin embargo, también han sido ampliamente criticadas por no tener correlación
directa con la calidad percibida. Por ejemplo, en la Figura 6.2, tomada de [46], se

Redes Corporativas
muestran tres ejemplos de imágenes 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 métrica
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 degradación en el cielo
(parte superior), mientras que en la figura (c), una degradación similar en la parte
inferior prácticamente no es perceptible. Este fenómeno 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 también puede darse en video, donde
cambios rápidos temporales pueden enmascarar cierta pérdida de calidad en cada
cuadro.
Debido a la baja correlación 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 características de percepción del sistema visual
humano y que permitan calcular métricas objetivas que lo simulen. Sin embargo,
no se existen, al momento de escribir el presente trabajo, métodos 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 métricas de medida, con diversa complejidad y
precisión de sus resultados. Las métricas basadas en analizar una imagen
degradada y compararla píxel a píxel 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 fácilmente algún tipo de
distorsión, mientras que puede pasar por alto otras, dependiendo de diversos
factores. Estos factores pueden incluir el tipo de aplicación (TV, video conferencia,
etc.), el lugar de la imagen en donde se produce la degradación (generalmente las
degradaciones son menos visibles en regiones con muchos detalles o “actividad
espacial”, o con gran movimiento, y son más visibles en imágenes estacionarias, o
en fondos poco texturados). Incluso la calidad percibida puede depender del tipo
de dispositivo utilizado y del tamaño del monitor [48].
En forma genérica, los métodos objetivos de medida de calidad pueden

clasificarse según la disponibilidad total, parcial o nula de la señal original, como
se detalla a continuación.
Métodos con disponibilidad total de la señal original (FR - Full Reference)
Estos métodos se basan en la disponibilidad de la señal original, la que puede ser
contrastada con la señal degradada, cuadro a cuadro. Esto presupone una severa
restricción al uso práctico de este tipo de métodos, ya que en varias aplicaciones
reales esto no es posible. Los métodos que utilizan métricas del tipo FR (Full
Reference) pueden ser utilizados para categorizar en forma objetiva un sistema de
transmisión, un codec, el efecto de un reducido ancho de banda, o de diversos

Redes Corporativas
factores que degraden una señal, en ambientes controlados. Sin embargo, no son
adecuados para aplicaciones de tiempo real (TV, video conferencias, etc.), ya que
no es posible tener las señales originales.
Métodos con disponibilidad parcial de la señal original (RR - Reduced

Reference)
Se trata de enviar, junto con el video codificado, algunos parámetros que
caractericen a la señal, y que sirvan de referencia en el receptor para poder
estimar la calidad percibida. Puede pensarse en la reserva de un pequeño ancho
de banda (comparado con el del video) para el envío de este tipo de información
adicional.
Métodos sin disponibilidad de la señal original - NR (No Reference)

Las personas no necesitan señales de referencia, ni información adicional para
juzgar la calidad de una señal de video. Se basan en sus experiencias previas, y
en las expectativas que tengan respecto al sistema. De igual manera, estos
métodos intentan estimar la calidad percibida basándose únicamente en el análisis
de la señal recibida. Son los métodos más complejos de implementar, pero no
requieren de otra información que la propia señal de video.
La gran mayoría de los modelos propuestos hasta el momento son del tipo FR
(Full Reference), ya que requieren de la señal de referencia para el cálculo de sus
métricas.
El “Video Quality Experts Group” (VQEG) [49] está realizando un interesante y

exhaustivo trabajo en el estudio y comparación de desempeño de métricas
objetivas, separando el estudio por áreas de aplicación, 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 imágenes 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
sistemático y objetivo de comparación de modelos. El objetivo del VQEG es
proporcionar evidencia para los organismos internacionales de estandarización
acerca del desempeño de diversos modelos propuestos, a los efectos de definir
una métrica estándar y objetiva de calidad percibida de video digital (VQM – Video
Quality Metric).
Los estudios del VQEG se dividen en
• FR-TV (Full Reference TV)
• RRNR-TV (Reduced Reference, No Reference TV)
• Multimedia
• HDTV
Cada aplicación, por sus propias características, requiere de pruebas y modelos

diferentes. El primer proyecto, ya terminado, es el correspondiente a FR—TV. Este
proyecto fue llevado a cabo en dos fases, como se detalla a continuación.
En la fase I de FR-TV, llevada a cabo entre 1997 y 2000, se evaluaron 9
propuestas, además 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 método DSCQS y las pruebas

Redes Corporativas
se realizaron sobre una base de más 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 método DSCQS. El desempeño de cada una de los modelos
propuestos fue evaluado respecto a tres aspectos de su capacidad de estimar la
calidad subjetiva:
• Precisión de la predicción: La capacidad de predecir la calidad subjetiva con
mínimo error
• Monotonicidad: Mide si los incrementos (decrementos) en una variable
están asociados a incrementos (decrementos) en la otra. Típicamente se
mide con el coeficiente de correlación de Spearman
• Consistencia: Se corresponde con el grado en que el modelo mantiene la
precisión a lo largo de las secuencias de pruebas. Se puede evaluar
midiendo la cantidad de puntos para los que el error de la predicción es
mayor a cierto umbral, por ejemplo, el doble de la desviación estándar.
Como resultado de la fase I de FR-TV, dependiendo de la métrica de comparación

utilizada, siete u ocho de los modelos propuestos resultaron estadísticamente
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 cálculo del PSNR y los sofisticados
métodos 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 años 2001 y 2003 y los resultados finales fueron publicados en agosto de 2003
[51]. El objetivo de esta segunda fase era obtener resultados más 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
líneas 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 habían 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 correlación de Pearson, según los datos
presentados en [51]. Puede verse que, en el formato de 525 líneas, los modelos

Redes Corporativas
de British Telecom y de NTIA se destacan del resto, y son estadísticamente

equivalentes, según 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 líneas, los modelos de NASA, Yonsei, CpQD y NTIA son los mejores, y
también son estadísticamente equivalentes, según las conclusiones del informe.
En promedio, presentan una mejora de un 21% respecto al PSNR. Con otras
métricas de comparación de los modelos (monotonicidad, consistencia) se
obtienen resultados similares.
1
0,9
0,8
0,7
0,6 525
0,5
0,4 625
0,3
0,2
0,1
0
A
R
ty
D
ity
m
AS
TI
N
Pq
i
co
rs
rs
PS
N
N
ve
ve
C
le
Te
ni
ni
U
U
sh
ba
ei
iti
ns
hi
Br
Yo
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 específicos para Multimedia, los que seguramente tengan
mayor relación directa con el ámbito corporativo.
En el contexto del VQEG, “Multimedia” se define como una aplicación que puede
combinar texto, gráficos, 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 análisis 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 prevén pruebas
específicas para dispositivos móviles como PDAs, independientes de las pruebas
realizadas en ordenadores de escritorio, ya que las características visuales de
estos dispositivos son muy diferentes. Por lo tanto, es posible que del resultado de
las pruebas, surjan modelos más adecuados a cada tipo de dispositivo.

Redes Corporativas
En el caso de RR, se admitirán 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 versión 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

recomendación ITU-R BT.1683 [53] de junio de 2004, a los cuatro mejores
algoritmos de predicción de la calidad percibida, definidos en el marco de esta
recomendación como:
• British Telecom BTFR (Reino Unido)

• Yonsei University/Radio Research Laboratory/SK Telecom (Corea)
• Centro de Investigación y Desarrollo en Telecomunicaciones (CPqD)
(Brasil)
• National Telecommunications and Information Administration
(NTIA)/Institute for Telecommunication Sciences (ITS) (Estados Unidos)
Es importante destacar que los modelos propuestos en esta Recomendación

pueden utilizarse para evaluar un codec (combinación de
codificador/decodificador) o una combinación de varios métodos de compresión y
dispositivos de almacenamiento en memoria. Aunque en el cálculo de los
estimadores de la calidad objetiva descrito en la Recomendación se considera la
degradación provocada por errores (por ejemplo, errores en los bits, paquetes
rechazados), no se dispone aún de resultados de pruebas independientes para
validar la utilización de estimadores en los sistemas con degradación por errores.
El material de pruebas utilizado por el VEQG no contenía 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 recomendación de la ITU-T que describe los terminales y demás
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 versión de H.323 fue aprobada en 1996 por la ITU-T. La versión 2 fue
aprobada en enero de 1998, la versión 3 en 1999, la versión 4 en 2000, la versión
5 en 2003 y la versión 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 física”. 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 confirmación de
recepción de paquetes, y retransmisiones, de ser necesarias, para asegurar la
correcta recepción 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 confirmación y eventuales retransmisiones, lo que los hace a su
vez más “rápidos”.
7.1.1 Arquitectura H.323
La recomendación 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 (típicamente la red telefónica pública
analógica 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 “teléfonos multimedia IP”. Estos “teléfonos” pueden
ser aplicaciones informáticas, que utilizan las capacidades multimedia del PC
(parlantes y micrófono), o terminales físicos de similar aspecto a cualquier teléfono
o videoteléfono.
La recomendación establece que esos terminales deben soportar obligatoriamente
comunicaciones de voz y opcionalmente comunicaciones de datos y video. La
recomendación también establece los protocolos utilizados en la señalización de
las llamadas, los mensajes de control, la manera de realizar la multiplexación de
estos mensajes, los codecs de audio y video y los protocolos utilizados para el
intercambio de datos entre los terminales.

Redes Corporativas
Alcance de H.323
Audio Codec
Micrófono G.711, G.722,
Parlante G.723, G.728,
G.729
RTP UDP
RTCP
Video Codec
Cámara H.261, H.263
Display
Intrerfaz de
Equipos datos
de datos T.120 IP
Control
Canal de
control
H.245 TCP
Control
Canal de
Interfaces señalización
de usuario H,225.0
(Q.931)
Canal de
RAS
H.225.0
Audio Codec
La recomendación H.323 admite los siguientes tipos de codificación de audio (ver

capítulo ¡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)

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 mínimo la codificación G.711 (en “Ley A” y
“Ley µ”), y opcionalmente las otras admitidas por la recomendación H.323. El tipo
de codec a utilizar al establecer una comunicación de audio con otro terminal es
negociado según la recomendación H.245, por el “canal de control de llamadas”.
En una misma comunicación, el terminal H.323 debe ser capaz de utilizar un
codec en la recepción y otro diferente en la transmisión.
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” según la recomendación H.225.0, utilizando los

estándares RTP (Real Time Protocol) y RTCP (Real Time Control Protocol).
Video Codec
La codificación 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 comunicación de video con otro

terminal, la velocidad de transmisión, el formato de la imagen y las opciones de los
algoritmos utilizados, son negociados según la recomendación H.245, por el “canal
de control de llamadas”.
Un mismo terminal puede soportar a la vez varios canales de video, tanto en la

transmisión como en la recepción. Asimismo, en una misma comunicación, el
terminal H.323 debe ser capaz de utilizar un codec en la recepción y otro diferente
en al transmisión.
El video generado es “formateado” según la recomendación H.225.0, utilizando

los estándares 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 recomendación T.120 provee un estándar 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, además de

los propios datos de “tiempo real” a transmitir, números de secuencia, marcas de
tiempo, y monitoreo de entrega. Las aplicaciones típicamente 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 múltiples, usando facilidades de

“multicast”, si esto es provisto por la red.
RTCP (RTP Control Protocol)
El RFC 3550 también detalla el protocolo de control RTCP. Los paquetes RTCP
son enviados periódicamente y contienen indicadores de la calidad del enlace, y
otros datos acerca de la fuente y destino de la comunicación. 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 implementación. Los usos típicos están
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 recomendación H.245 (“Line transmisión 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 lógicos, 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 simultánea en varias llamadas, puede tener también 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

través de éste canal, el terminal realiza las funciones de registro, admisión,
solicitud de ancho de banda, status, etc. Este canal de señalización es
independiente del canal de control H.245 y del canal de señalización de llamadas.
En ambientes de red dónde 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 dónde 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 recomendación de la

ITU-T H.225.0 “Call signalling protocols and media stream packetization for
packet-based multimedia communication systems” [56]
Canal de señalización H.225.0
El canal de señalización del terminal H.323 utiliza funciones de señalización del

protocolo H.225.0 para establecer conexiones con otro terminal H.323. Este canal
de señalización es independiente del canal de RAS y del canal de control H.245.
El canal de señalización 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 señalización es

establecido directamente entre dos terminales. En ambientes de red en los que se
dispone de un Gatekeeper, el canal de señalización 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 recomendación H.225.0 utiliza los mensajes descritos en la recomendación

Q.931 [57], utilizada en ISDN

Redes Corporativas
7.1.1.2 Gateways (Pasarelas)
Los gateways o pasarelas, realizan la función de interconexión entre las redes

H.323 y otras redes de comunicaciones, como la red pública conmutada (PSTN –
Public Switched Telephony Network) analógica y digital, o redes “SIP”.
Los gateways son responsables de adaptar el audio, video y los datos, así como
también la señalización, entre los formatos propios de H.323 y otras redes de
telecomunicación, 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 dónde no es necesario
tener comunicación con terminales externos a la propia red, no es necesario
disponer de gateways. Por ello, son elementos opcionales en la recomendación
H.323
Hacia la red H.323, el gateway presenta las características de un terminal H.323 (o

de un MCU – Multipoint Control Unit), y hacia la red PSTN, el de un terminal
telefónico (de acuerdo al tipo de red a la que esté conectado, podrá presentar las
características de un teléfono analógico, 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 recomendación 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 telefónicos, llamado en la recomendación “Gatekeeper”. Este dispositivo,
en caso de existir, debe proveer, como mínimo, los siguientes servicios:
Traducción de direcciones
Una de las funciones principales del Gatekeeper es traducir un número telefónico,
o un “alias” a la dirección de red apropiada (por ejemplo, la dirección IP). Para ello,
el Gatekeeper debe disponer de una tabla de traducción 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 Admisión
El Gatekeeper puede autorizar o negar el acceso (registro) a la red H.323,
utilizando mensajes descriptos en la recomendación H.225.0. Las reglas de
decisión para autorizar o negar el acceso no son parte de la recomendación.
Control de Ancho de Banda

El Gatkeeper debe soportar la mensajería H.225.0 respecto a la asignación de
ancho de banda. Mediante los protocolos adecuados, puede indicar a cada
terminal el ancho de banda total disponible según el tipo de llamada, las
categorías 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 mínimo 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:
Señalización para el control de llamadas

Cuando una red H.323 dispone de un Gatekeeper, la señalización para el
establecimiento y liberación de llamadas puede realizarse directamente entre dos
terminales, o a través del Gatekeeper. El Gatekeeper puede asumir la función de
centralizador de señalización, de manera que los terminales tengan que utilizarlo
para las funciones de señalización de llamadas.
Autorización de llamadas
Mediante el uso de señalización 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 día, etc. La recomendación no establece cuales deben ser estos criterios, los
que quedan librados a los fabricantes.

Redes Corporativas
Una red puede tener más de un Gatekeeper, los que pueden comunicarse entre
sí. Los protocolos de comunicación utilizados entre dos o más Gatekeeper no
están especificados en la recomendación.
7.1.1.4 MCU – Multipoint Control Unit (Unidad de control multipunto)
El “MCU” provee soporte para realizar conferencias, entre 3 o más 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 implementación de conferencias de 3 o más terminales.
Los MC realizan el intercambio de capacidades entre los terminales de la
conferencia, de manera de establecer un modo común 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 conmutación 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 conmutación es determinado por
el MC.
El MCU mínimo puede consistir de un único MC y ningún MP. En este caso, las
funciones de mezcla y conmutación de audio y video deberán ser provistas por los
propios terminales. Un MCU típico, que soporte conferencias centralizadas, se
compone de un MC y un MP. Un MCU típico que soporte únicamente conferencias
descentralizadas, se compone de un MC y un MP con soporte únicamente la
recomendación 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 orígenes a fines de 1996, como un componente del “Mbone” (Multicast
Backbone), El Mbone, era una red experimental montada sobre la Internet, para la
distribución de contenido multimedia, incluyendo charlas, seminarios y
conferencias de la IETF. Uno de sus componentes esenciales era un mecanismo
para invitar a usuarios a escuchar una sesión multimedia, futura o ya establecida.
Básicamente un “protocolo de inicio de sesión” (SIP).
En junio de 2002, el RFC 2543 fue reemplazado por un conjunto de nuevas
recomendaciones, entre las que se encuentran los RFC 3261 al 3266
[58][59][60][61][62][63].
Una completa introducción a SIP puede leerse en [64].
7.2.1 Mensajería SIP
La mensajería SIP está basada en el esquema “Request” – “Response” de http.

Esto presenta ciertas ventajas, sobre todo para los familiarizados con las
tecnologías HTTP. A diferencia de H.323, todos los mensajes son de texto plano, y
por lo tanto fáciles de interpretar (recordar que en H.323, los mensajes eran
binarios).
Para iniciar una sesión se envía un mensaje de “Request” a una contraparte de

destino. El destino recibe el “Request”, y lo contesta con el correspondiente
“Response”. Un ejemplo del establecimiento de una comunicación se muestra en
la figura

Redes Corporativas
SIP SIP
User Agent User Agent
Client Server
INVITE sip:pepe@fing.com
180 Ringing
200 OK
ACK
Media Stream
BYE
200 OK
host.abc.com sip.fing.com
Los mensajes de “Request” tiene el formato
<Método> <URL> <SIP-Version>
Por ejemplo: INVITE sip:pepe@fing.com SIP/2.0
La siguiente tabla resume los métodos SIP
Método Descripción
INVITE A session is being requested to be setup using a specified media
Message from client to indicate that a successful response to an INVITE
ACK
has been received
OPTIONS A Query to a server about its capabilities
BYE A call is being released by either party
Cancels any pending requests. Usually sent to a Proxy Server to cancel
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.”

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 Descripción Ejemplo

180 Ringing
Informational – Request received, continuing to process
1xx 181 Call is Being
request.
Forwarded
Success – Action was successfully received, understood and
2xx 200 OK
accepted.
300 Multiple Choices
Redirection – Further action needs to be taken in order to
3xx 302 Moved
complete the request.
Temporarily
Client Error – Request contains bad syntax or cannot be 401 Unauthorized
4xx
fulfilled at this server. 408 Request Timeout
503 Service
Server Error – Server failed to fulfill an apparently valid Unavailable
5xx
request. 505 Version Not
Suported
600 Busy Everywhere
6xx Global Failure – Request is invalid at any server.
603 Decline
Para comprender mejor el formato de los mensajes SIP, se analizará con más
detalle el método “INVITE”.
El método “INVITE” contiene varios campos que forman un “cabezal”. Este

cabezal incluye atributos que proporcionan información adicional acerca del
mensaje. En el “INVITE” se incluye un identificador único de la llamada, la
dirección del destino, la dirección del origen, e información acerca del tipo de
sesión 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 línea del mensaje contiene el nombre del método (“INVITE” en el

ejemplo anterior). Las líneas siguientes contienen el resto de los campos del
cabezal.
Los detalles de la sesión, 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 descripción de estos parámetros, 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

continuación:
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 renglón de SDP es <tipo>=<valor>. <tipo> es siempre un

único carácter, y se diferencian mayúsculas de minúsculas. El formato de <valor>
depende del <tipo> al que corresponda. No puede haber espacios al lado del “=”,
ni antes ni después.
En este ejemplo, SDP contiene:
• Versión del protocolo (v)
• Origen (o)
o=<username> <session id> <version> <network type> <address type>
<address>
• Nombre de la sesión (s)

Debe haber un único campo de nombre de sesión.

Redes Corporativas
• Datos de la conexión (c)

c=<network type> <address type> <connection address>
<network type> = IN para Internet
<address type> = IP4 para IP version 4
<connection address> Es la dirección IP, que puede ser una
dirección de multicast. Puede incluirse un valor de TTL (Time To
Live), luego de la dirección IP, separada con el símbolo “/”, 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 sesión.
• 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, típicamente es RTP/AVP, indicando que se
utiliza el transporte RTP
<fmt list> Es el formato del audio o video transportado (Ver Tipo de
información (PT=Payload Type) )
• Atributos (a)
a=<attribute>:<value>
a=<attribute>
El campo “a” permite definir atributos, tanto a nivel de la sesión 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 “teléfonos multimedia IP”. Estos
“teléfonos” pueden ser aplicaciones informáticas, que utilizan las capacidades
multimedia del PC (parlantes y micrófono), o terminales físicos de similar aspecto
a cualquier teléfono o videoteléfono.
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 telefónicos clásicos se identifican mediante su número de

teléfono, o número de abonado, y los terminales H.323 mediante su “alias”, los
terminales SIP se identifican a través de su “dirección 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 métodos
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 método REGISTER, rechazando cualquier otro
método con una respuesta 501 (Not Implemented). La información de los usuarios
registrados es puesta a disposición 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
SIP SIP SIP

User Agent Proxy User Agent
Client Server Server
INVITE
INVITE
200 OK
200 OK
ACK
Media
BYE
200 OK
host.fing.com server.fing.com sip.abc.com
Los servidores Proxy tienen las siguientes características:

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 típico de servidores Proxy se ve en la siguiente figura [64]:

Redes Corporativas
Redirect Server
Es un servidor de redireccionamiento. A diferencia del “Proxy”, no interviene en el

establecimiento de la comunicación, sino que informa la manera de ubicar al
destino final. La figura siguiente esquematiza el funcionamiento de SIP Redirect

Redes Corporativas
SIP SIP SIP

User Agent Redirect User Agent
Server
REGISTER
200 OK
INVITE sip:picard@wcom.com
302 Moved
1 RS
ACK 2
C
INVITE
3
UAS
180 Ringing
200 OK
ACK
Media Stream
host.wcom.com server.wcom.com sip.uunet.com
Location Server
Es un servidor de búsqueda. Puede ser consultado para obtener la dirección final

de un usuario SIP.
Presence Server
Un servidor de presencia es un equipo que en ciertas ocasiones actúa como un

agente de presencia y envía información de presencia a otros agentes, y en otras
ocasiones actúa 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 también hacia H.323
Los gateways son responsables de adaptar el audio, video y los datos, así como
también la señalización, entre los formatos propios de SIP y otras redes de
telecomunicación, de manera transparente para los usuarios.
En redes dónde no es necesario tener comunicación con terminales externos a la

propia red, no es necesario disponer de gateways.

Redes Corporativas
8 Unificación en el Backbone
Como vimos en la Introducción, la integración 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 años, y el principal móvil es el ahorro
económico.
En la actualidad la gran mayoría de las empresas con varias sucursales disponen

de enlaces dedicados de datos, utilizando diversas tecnologías. Estos enlaces,
generalmente tienen un costo fijo mensual, independientemente de su utilización.
Es por tanto razonable tratar de incluir en estos enlaces la mayor cantidad de
información posible, incluyendo conversaciones de voz.
Para ello se han desarrollado varias tecnologías.
8.1 Multipelxores
Son equipos capaces de combinar (multiplexar) tráfico 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 tráficos. Los enlaces digitales pueden
ser de diversas tecnologías, 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 señalización FXS, FXO, E&M, E1, etc.)
LAN MUX LAN

MUX
WAN
PBX PBX
Voz Voz
Interfaces de Voz:
FXS
Esta interfaz “simula” una línea urbana, a la que se puede conectar un teléfono
analógico. También es posible conectar un puerto de línea urbana de una PBX.

Redes Corporativas
FXO
Esta interfaz “simula” un teléfono, a la que se puede conectar una línea urbana.
También es posible conectar un puerto de interno de una PBX.
E&M
Esta interfaz se conecta a PBX, con señalización E&M
T1 / E1
Esta interfaz provee canales telefónicos a través enlaces digitales T1 (24 canales)
o E1 (30 canales), típicamente con señalización 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 compresión, tecnología utilizada, ancho de banda, etc.
8.2 Routers con “placas” de voz
Los equipos ruteadores (“routers”) fueron diseñados originalmente para

interconectar dos o varias redes de área local (LAN) a través 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 incorporación de Gateways IP. Estos

Gateways conectan la PBX directamente a la LAN, e implementan la conversión
de la voz a paquetes IP y viceversa.
Los paquetes de voz que salen del Gateway son enviados por el Router, a través
de la WAN, hasta el Gateway de la otra PBX.

Redes Corporativas
I IP
P
PBX PBX
LAN
Router WAN Router
LAN
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
priorización. Esto es muy importante debido a la diferencia de velocidades de
transmisión que típicamente 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 relación de velocidades de 1 a
100 o a 1000.
Por ésta razón, 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 ráfagas 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 pequeñas.
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 envíos a la WAN se
realizan por orden de prioridad.
Los estándares más comunes son DiffServ (para IP) y 802.1p para Ethernet.
Por otro lado, cuando la velocidad de acceso a la WAN es pequeña, 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, aún siendo priorizados, deberán
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 más pequeños,
de manera que entre cada fragmento del paquete original se puedan insertar
paquetes de voz. En el caso de Frame Relay, los mecanismos de fragmentación
están normalizados, según la recomendación FRF-12 (“Frame Relay
Fragmentation Implementation Agreement”)

Redes Corporativas
8.4 “Gateways” IP independientes
Estos equipos se utilizan cuando se dispone de PBX y routers que no soportan la

incorporación de Gateways IP. Son equipos independientes, que disponen de las
interfaces telefónicas clásicas (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 también
muy importante que los routers respeten la priorización, según las “marcas”
realizadas por los “gateways”
Gw Gw
PBX PBX
LAN
Router WAN Router
LAN

Redes Corporativas
9 Unificación en el Escritorio
La unificación de las redes de voz y datos a nivel del “escritorio” comprende varias
tecnologías. La tecnología llamada “CTI” (Computer Telephony Integration)
permite vincular la telefonía con las aplicaciones informáticas. Sobre esta
tecnología se han desarrollado diversos tipos de aplicaciones. Se destaca su uso
en ambientes de Call Center, y más recientemente, como plataforma tecnológica
para las denominadas “Comunicaciones Unificadas”.
9.1 CTI
La tecnología 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 través de vínculos de datos entre los servidores
informáticos y las centrales telefónicas.
LAN Enlace
Host Pbx
Las tecnologías de CTI permiten mantener los teléfonos de escritorio, ya sean

TDM (analógicos o digitales) o IP, pero “controlados” desde aplicaciones
informáticas. Estas aplicaciones informáticas pueden integrarse con funciones
telefónicas, permitiendo realizar “screen popups” cuando llega una llamada, y
controlando las funciones de los teléfonos desde el computador.
La tecnología de CTI permite "sincronizar" la recuperación de datos en las

aplicaciones de los PCs con el ingreso de cada llamada. Por ejemplo, si se
dispone de la facilidad de identificación 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
identificación.
Las tecnologías de CTI son ampliamente utilizadas, desde hace ya varios años, en
ambientes de Call Center, dónde es importante minimizar los tiempos de cada

Redes Corporativas
llamada, y brindarle a las telefonistas la máxima información posible referente al

cliente.
Estas tecnologías están teniendo actualmente creciente difusión en ambientes

corporativos, asociados a la integración de las aplicaciones de escritorio y
sistemas de presencia. Con este tipo de integraciones, el correo electrónico, las
herramientas de oficina y la mensajería instantánea se “integran” a la telefonía,
permitiendo por un lado actualizar el estado de presencia en función de la
actividad telefónica, y por otro, iniciar llamadas desde aplicaciones de escritorio,
en forma automática y a través del teléfono habitual.
CTI es conocido también como “RCC”, o “Remote Call Control”, entiendo por éste
concepto a las tecnologías que permiten realizar el control de las llamadas y los
teléfonos desde aplicaciones externas.
Las tecnologías de CTI están basadas en arquitecturas del tipo “cliente – servidor”.
Un “Servidor de Telefonía” 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 través de la red IP. En el
“Servidor de Telefonía” 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 telefónicos (por ejemplo, los teléfonos) desde
aplicaciones informáticas. Existen varios “estándares” 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 telefonía,

que pueden ser utilizadas desde aplicaciones desarrolladas en C, C++, .net o
cualquier otro lenguaje de programación 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 vínculo con la PBX, implementando el protocolo
adecuado (el que puede ser propietario). Los clientes se comunican con el
servidor a través de las funciones de TAPI locales.

Redes Corporativas
9.1.2 JAVA JTAPI
La especificación de JTAPI (Java Telephony API) fue desarrollada en forma

conjunta por diferentes empresas, de computación y telecomunicaciones (Sun,
Avaya, Nortle, Intel, IBM, entre otras). La primera versión de JTAPI data de 1996,
y la más reciente, la versión 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 telefonía, donde residen
APIs de telefonía (como TAPI). JTAPI dispone de un conjunto completo de
funciones y eventos de telefonía, que pueden ser utilizadas desde aplicaciones
JAVA.

Redes Corporativas
9.1.3 CSTA
CSTA (Computer Supported Telecommunications Applications) proporciona una

capa de abstracción para las aplicaciones de telecomunicaciones que requieran
usar tecnologías de CTI. La primera versión 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 informática
con el de la PBX a través de un “Switch Link”. CSTA utiliza ASN.1 ("Abstract
Syntax Notation One"), una metodología para representar estructuras de datos
desarrollada por la ITU. ASN.1 consiste en un lenguaje declarativo, y ciertas reglas
de codificación para traducir el código ASN.1 en un flujo de bytes que se puedan
ser fácil y eficientemente transmitidos. Al estar normalizado, se garantiza que la
codificación y la decodificación 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 lógicas (“Logical Device features”, como “do not disturb”,
“forwarding”, etc.)
• 23 funciones asociadas a los dispositivos físicos (“Physical Device” como
escribir en los displays de los teléfonos, 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 monitorización (“Monitor features”, como subscribirse a
notificaciones de eventos, etc.)
• 17 funciones de voz (“Voice Services”, como detección de DTMF, etc.)
• Otras funciones de ruteo, funciones de mantenimiento, administración, etc.
El modelo de llamada entrante en CSTA es el siguiente:
Offered Delivered Established Connection

Accept Answer Clear Cleared
Call Call Connection
El modelo de llamada saliente (por ejemplo “Make Call”) en CSTA es el siguiente:

Redes Corporativas
Originated Offered Delivered Established Connection

Call Called Called Called Cleared
Offered Device Party Party
To alerted answers clears
Called
device
Adicionalmente, CSTA soporta el control y notificación de interacciones no

telefónicas, como por ejemplo mensajería instantánea, correo electrónico y Chat.
Esto permite utilizar un mismo modelo para la atención de contactos multimedia,
ya sean de voz, texto, etc.
9.1.4 ECMA TR/87
Entre los estándares, 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 recomendación ISO/IEC TR 22767, en agosto de 2005 [66].
Este estándar utiliza el protocolo SIP (ver la sección 7.2) y lo adapta para ser
utilizado como transporte para notificar los eventos telefónicos de CSTA. Los
eventos telefónicos 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 operación telefónica
a realizar (“Make call” en el ejemplo anterior).

Redes Corporativas
La siguiente figura (tomada de [66]) ilustra el proceso de intercambio de mensajes

para iniciar una llamada desde una aplicación, utilizando TR/87. Se puede
observar como todos la mensajería CSTA se incluyen dentro de métodos “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 comunicación han
sido históricamente desarrolladas, promocionadas y distribuidas como
aplicaciones independientes. La convergencia de todas las formas de
comunicación 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 métodos de comunicación (voz, mensajería
instantánea, etc.) pueden ser utilizados en forma individual e independiente, la
unificación 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 más rápida.
Las Comunicaciones Unificadas pueden definirse genéricamente como una

plataforma de aplicaciones que mejoran la productividad individual, grupal y
organizacional permitiendo y facilitando la administración y el control integrado de
diversos canales de comunicación, redes, sistemas y aplicaciones de negocios
[67].
Los componentes de las Comunicaciones Unificadas incluyen aplicaciones de

presencia, mensajería instantánea, telefonía IP, conferencia de audio, conferencia
web o colaboración de datos, mensajería unificada (un lugar común de
almacenamiento de correo de voz, correo electrónico y fax), movilidad y/o video
conferencia, todo accesible a través de una única interfaz de cliente, o embebida
dentro de una interfaz de aplicación.
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 informáticas y telefónicas, manteniendo ambas, pero permitiendo un alto
grado de integración y unificación. Mediante la utilización de técnicas de CTI,
integradas o embebidas en las aplicaciones de escritorio, es posible:
• Recibir notificaciones de llamadas telefónicas en el escritorio:

Mediante la presentación de pantallas emergentes (“screen popups”), la
información de las llamadas entrantes se despliegan de manera similar a la
recepción de un nuevo correo electrónico, o de un mensaje instantáneo

Redes Corporativas
• Controlar el teléfono 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 desvíos “inteligentes” de llamadas: En forma integrada al

calendario de reuniones, o al estado de presencia, es posible activar
desvíos de llamadas, al correo de voz, al celular, etc.
• Combinar los sistemas de mensajería instantánea y presencia a las

actividades telefónicas: Automáticamente el estado de presencia se
cambia a “Al teléfono” cuando se está en una llamada. Adicionalmente, con
una llamada establecida, se puede iniciar una sesión de mensajería
instantánea para intercambiar archivos, o compartir el escritorio.
9.2.1.2 Presencia
La “presencia” es una indicación 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 información de presencia.

Generalmente esta “entidad” es una persona, y su estado se mantiene en
un servidor de presencia.
• Watcher: Quienes solicitan información de presencia de otras personas al
servidor de presencia
• Fetcher: Un “watcher” que solicita el estado actual de presencia de algún
“Presentity” a través del servidor de presencia
• Subscriber: Un “watcher” que solicita notificaciones del servidor de
presencia cuando algún “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. Típicamente
la presencia es indicada en sistemas de mensajería instantánea. Sin embargo, el
estado de presencia puede ser muy útil en otro tipo de aplicaciones. En los
clientes de correo electrónico, 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 más eficiente
llamarlo que responderle en forma escrita. Aplicaciones de procesadores de texto
y planillas electrónicas, así como aplicaciones de gestión (CRM, ERP, etc.)
también pueden mostrar el estado de presencia de las personas involucradas en
el documento o proceso, mejorando de esta manera la comunicación
organizacional cooperativa.
9.2.1.3 Mensajería Instantánea
Originalmente los sistemas de mensajería instantánea fueron definidos para

entregar mensajes de texto cortos y simples en forma inmediata a otros usuarios
que estén contactados en línea. Con el tiempo los sistemas fueron mejorados para
soportar intercambios de archivos, conversaciones de voz y video, y otras
funciones. La definición estandarizada de estos sistemas se corresponde con el
RFC 2778.
Los sistemas de mensajería instantánea han tenido un enorme éxito para la

comunicación informal interpersonal. Es por ello que su incorporación 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 integración con los sistemas de
presencia, mensajería instantánea, 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 básicos descritos en ésta recomendación incluyen, entre otros:
• Descubrimiento: Soportar el descubrimiento automático de servidores de

conferencias basados en SIP.
• Creación 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 definición de conferencias
“ad-hoc”
• Terminación de Conferencias: Terminar las conexiones establecidas en
una conferencia. Debe incluir la capacidad de pasar la conferencia a una
comunicación básica punto a punto cuando queden únicamente dos
participantes.
• Manipulación de Participantes: Invitar o desconectar participantes a una
conferencia. Cuando sea necesario, debe permitir el anonimato de los
participantes.
• Información de Estado: Mantener una base de datos que registre varios
aspectos referentes a la conferencia. Los aspectos a registrar incluyen la
información de los participantes, quien es el moderador actual, información
acerca de cada sesión, etc.
• Migración de Roles: Debe ser posible cambiar los roles en la conferencia
dinámicamente
• Conferencias Asociadas: Poder crear conferencias asociadas y apartadas
entre participantes de la conferencia principal, y con participantes que no
estén en la conferencia principal.
9.2.1.5 Colaboración
El concepto de Colaboración involucra a múltiples personas trabajando en

conjunto para lograr un objetivo común.
Diversas herramientas de colaboración 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 electrónica.
• Navegación Web compartida: Permite que los participantes de una
conferencia multimedia puedan navegar en forma conjunta por páginas de
Internet. Esto complementa las vistas compartidas, con aplicaciones que
realizan esta función 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 envíe un archivo a
uno o varios colaboradores.

Redes Corporativas
Referencias
[1] “Redes de Voz”, Versión 07, José Joskowicz (Agosto 2008)
[2] “Redes de Datos”, Versión 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

Jörn 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) (Métodos de determinación

subjetiva de la calidad de transmisión), 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 transmisión debido al tratamiento de las señales

vocales”, Recomendación 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: Evaluación de la calidad vocal por

percepción: Un método objetivo para la evaluación de la calidad vocal de
extremo a extremo de redes telefónicas de banda estrecha y códecs
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, ICIP’04, 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] RECOMENDACIÓN UIT-R BT.1683 - Técnicas de medición objetiva de la

calidad de vídeo perceptual para la radiodifusión de televisión digital de
definición 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

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Redes Unificadas 2008

Uploaded by

Copyright:

Available Formats

Redes Corporativas

Ing. José Joskowicz

Redes Unificadas Página 1

Redes Unificadas Página 2

6.1.2 Pérdida de paquetes........................................................................ 43

Redes Unificadas Página 3

La integración de estas dos tecnologías no parece algo sencilla, y cabe

El primero aspecto es económico: es posible ahorrar dinero al integrar las

La primera etapa en la integración se ha dado, no casualmente, en la transmisión

Con el incremento de la cantidad computadoras y la baja de sus precios, vino

Redes Unificadas Página 4

Luego de algún tiempo, con el crecimiento de la necesidad de transmitir datos,

Con la creciente demanda de transmisión de datos, estos enlaces se

De esta manera, se invirtió la situación inicial: de utilizar la red telefónica para

Comenzaremos por presentar los problemas tecnológicos que aparecen al cursar

Redes Unificadas Página 5

3 Voz sobre redes de datos

3.1 Codificación de voz

La voz es codificada digitalmente para su transmisión. Los dispositivos de

La siguiente tabla resume los algoritmos de compresión de voz más conocidos.

Algunos de estos algoritmos son descritos a continuación

El codec básico en telefónica es el estandarizado en la recomendación G.711 de

Cuando se dispone de velocidades de red reducidas, es conveniente tratar de

El codec G.729 [6] es un estándar de codificación para señales de audio

Se basa en el modelo CELP [7] operando con ventanas de audio de 10 ms

Redes Unificadas Página 6

muestreo es de 8.000 muestras por segundo). CELP no conserva la forma de

El modelado de la boca y la garganta se hace por medio de filtros lineales y la voz

Dado que a la salida del codificador la tasa de bits es de 8 kbit/s y se toman

En el anexo A de la recomendación G.729 se define una variante de este codec

El Anexo B de la recomendación G.729 B provee detección de actividad de voz y

El codec G.723.1 [8] es un estándar de codificación para señales de audio

Redes Unificadas Página 7

Para la codificación a 6.4 kb/s se utiliza un algoritmo MPC-MLQ (Multi-Pulse

El Anexo A de la recomendación G.723.1 provee modelado y regeneración del

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

3.2 Transmisión de voz sobre redes de datos

Por esta razón, se toman generalmente “ventanas” de 10 a 30 ms. Las muestras

Redes Unificadas Página 8

Flujo de voz, 64 kb/s

3.3 RTP – Real-Time Transport Protocol

El protocolo RTP, basado en el RFC 3550 [10], establece los principios de un

El protocolo establece la manera de generar paquetes que incluyen, además de

RTP soporta transferencia de datos a destinos múltiples, usando facilidades de

Redes Unificadas Página 9

Flujo de voz, 64 kb/s

synchronization source (SSRC) identifier

contributing source (CSRC) identifiers

Los campos más relevantes son:

3.3.1 Versión (V)

Redes Unificadas Página 10

3.3.2 CSRC count (CC)

3.3.3 Tipo de información (PT=Payload Type)

Payload Type Formato Medio Clock Rate

3.3.4 Número de secuencia (Sequence Number)

3.3.5 Marca de tiempo (Time Stamp)

3.3.6 Identificador del origen (SSRC - Synchronization Source Identifier)

Redes Unificadas Página 11

3.3.7 Identificador del tributario (CSRC - Contributing Sources Identifier)

3.4 RTCP – RTP Control Protocol

El RFC 3550 establece, además del protocolo RTP, un protocolo de control,

• Proveer realimentación acerca de la calidad de los datos distribuidos (por

3.5 Ancho de banda en IP para voz

26 bytes 40 bytes 160 bytes