Vous êtes sur la page 1sur 52

Redes Corporativas

REDES UNIFICADAS

Ing. Jos Joskowicz Instituto de Ingeniera Elctrica, Facultad de Ingeniera Universidad de la Repblica Montevideo, URUGUAY Julio 2006
Versin 5

Redes Unificadas

Pgina 1

Redes Corporativas

1 Temario
1 2 3 Temario..........................................................................................................................2 Introduccin...................................................................................................................4 Voz sobre redes de datos...........................................................................................6 3.1 Paquetizacin de la voz......................................................................................6 3.2 RTP Real-Time Transport Protocol ...............................................................6 3.2.1 Versin (V) ....................................................................................................7 3.2.2 CSRC count (CC).........................................................................................8 3.2.3 Tipo de informacin (PT=Payload Type)..................................................8 3.2.4 Nmero de secuencia (Sequence Number) ............................................8 3.2.5 Marca de tiempo (Time Stamp) .................................................................8 3.2.6 Identificador del origen (SSRC - Synchronization Source Identifier)...8 3.2.7 Identificador del tributario (CSRC - Contributing Sources Identifier) ...9 3.3 RTCP RTP Control Protocol...........................................................................9 3.4 Ancho de banda ...................................................................................................9 3.5 Factores que afectan la calidad de la voz sobre redes de paquetes ........11 3.5.1 Factor de compresin................................................................................11 3.5.2 Prdida de paquetes .................................................................................11 3.5.3 Demora ........................................................................................................12 3.5.4 Eco ...............................................................................................................13 3.5.5 Variaciones en la demora (Jitter).............................................................13 3.5.6 Tamao de los paquetes .........................................................................14 4 Medida de la calidad de voz en redes IP ...............................................................14 4.1 Mtodos Subjetivos ...........................................................................................15 4.2 E-Model ...............................................................................................................15 4.2.1 Clculo de Is ................................................................................................17 4.2.2 Clculo de Id ................................................................................................17 4.2.3 Clculo de Ie-eff ............................................................................................19 4.2.4 Clculo de A ................................................................................................21 4.2.5 Relacin de R y MOS ................................................................................22 4.2.6 Aplicacin del E-model..............................................................................23 4.3 ITU-T P.862 (PESQ)..........................................................................................23 4.4 ITU-T P.563.........................................................................................................25 5 Unificacin en el Backbone ......................................................................................28 5.1 Multipelxores .......................................................................................................28 5.2 Routers con placas de voz.............................................................................29 5.3 PBX con Gateways IP ....................................................................................29 5.4 Gateways IP independientes.........................................................................31 6 Unificacin en el Escritorio .......................................................................................32 6.1 CTI........................................................................................................................32 6.2 H.323....................................................................................................................33 6.2.1 Arquitectura H.323 .....................................................................................34 6.2.1.1 Terminales...........................................................................................34 6.2.1.2 Gateways (Pasarelas) .......................................................................39 6.2.1.3 Gatekeeper .........................................................................................40

Redes Unificadas

Pgina 2

Redes Corporativas 6.2.1.4 MCU Multipoint Control Unit (Unidad de control multipunto)...41 6.3 SIP ........................................................................................................................41 6.3.1 Mensajera SIP ...........................................................................................42 6.3.2 Arquitectura SIP .........................................................................................46 6.3.2.1 Terminales SIP ...................................................................................47 6.3.2.2 Servidores SIP ....................................................................................47 6.3.2.3 Gateway SIP .......................................................................................50 Referencias .........................................................................................................................51

Redes Unificadas

Pgina 3

Redes Corporativas

2 Introduccin
Las redes de voz [1] y las redes de datos [2] presentan tecnologas muy dismiles. Por un lado, la transmisin de voz, con una historia de ms de 100 aos, se basa en el establecimiento de vnculos permanentes entre dos puntos, diseados para transmitir un tipo de seal especfico: la voz humana, tpica seal analgica, de ancho de banda acotado, que debe llegar a destino inmediatamente y ser lo ms inteligible posible. Por otro lado, la transmisin de datos, con una relativa reciente historia, se basa en la transmisin de informacin digital, sin establecer vnculos permanentes, y donde los retardos no son generalmente importantes. La integracin de estas dos tecnologas no parece algo sencilla, y cabe preguntarse si existe alguna ventaja en realizar el intento. Las ventajas aparecen al analizar por los menos los siguientes tres aspectos: El primero aspecto es econmico: es posible ahorrar dinero al integrar las tecnologas. El segundo aspecto es de administracin: es ms sencillo administrar un nico sistema que dos independientes. Ambos aspectos son importantes, y las Empresas, tanto desarrolladoras, como consumidoras de tecnologa estn haciendo una fuerte apuesta a esta integracin. El tercer aspecto, y quizs a nivel del usuario presente las ventajas ms relevantes, tiene que ver con la mejora en las aplicaciones. Las nuevas tecnologas de unificacin de redes permitirn a los usuarios disponer de facilidades que hasta hace un tiempo no eran posibles. La primer etapa en la integracin se ha dado, no casualmente, en la transmisin a distancia. La transmisin a distancia est directamente relacionada con gastos mensuales, ya sean fijos, o por utilizacin. Bajar estos costos, incide directamente en los costos operativos de las Empresas. La primera integracin de estas redes, existe desde hace muchos aos: Los MoDems (Moduladores / Demoduladores) utilizan las redes telefnicas para la transmisin de datos a distancia. Dado que las redes telefnicas existen desde mucho antes que las de datos, resulta entendible que las primeras transmisiones de datos a distancia utilizaran como soporte estas redes. Para ello se disearon los mdems, encargados de adaptar la informacin de datos al medio telefnico. Como ste ltimo esta diseado para seales analgicas, de hasta 3.4 kHz de ancho de banda, los mdems utilizan tonos" dentro de esta banda para enviar los datos que desean transmitir. De esta manera, se utilizan los enlaces telefnicos, generalmente disponibles y ya amortizados, para transmitir espordicamente datos. Con el incremento de la cantidad computadoras y la baja de sus precios, vino aparejado la creciente necesidad de intercambio de informacin (datos), y la comunicacin va mdem est limitada por las propias caractersticas de la red telefnica: el teorema de Shannon limita la cantidad de informacin por segundo que se puede transitar por un enlace de este tipo, a menos de 60 kb/s.

Redes Unificadas

Pgina 4

Redes Corporativas

Luego de algn tiempo, con el crecimiento de la necesidad de transmitir datos, surgieron las primeras redes a distancia de transmisin de datos. Estas redes, inicialmente punto a punto, permitieron aumentar la velocidad en la transmisin de datos, con un costo fijo mensual para las empresas. En este caso, los enlaces de datos, no estn limitados por el bajo ancho de banda de los enlaces telefnicos. Con la creciente demanda de transmisin de datos, estos enlaces se incrementaron, ofreciendo mayores capacidades y bajando sus costos. Hasta el punto en que, en conjunto con las tecnologas de compresin de voz, resulta actualmente ms econmico utilizar enlaces de datos para transmitir conversaciones telefnicas. De esta manera, se invirti la situacin inicial: de utilizar la red telefnica para cursar datos, se utiliza la red de datos, para cursar trfico de voz. Comenzaremos por presentar los problemas tecnolgicos que aparecen al cursar trfico de voz y video sobre redes de datos. Luego se presentarn las tecnologas utilizadas para la unificacin de las redes en el back bone y en el escritorio.

Redes Unificadas

Pgina 5

Redes Corporativas

3 Voz sobre redes de datos


3.1 Paquetizacin de la voz

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

Flujo de voz, 64 kb/s

Ventana

3.2

RTP Real-Time Transport Protocol

El protocolo RTP, basado en el RFC 3550 [3], establece los principios de un protocolo de transporte sobre redes que no garantizan calidad de servicio para datos de tiempo real, como por ejemplo voz y video. El protocolo establece la manera de generar paquetes que incluyen, adems de los propios datos de tiempo real a transmitir, nmeros de secuencia, marcas de tiempo, y monitoreo de entrega. Las aplicaciones tpicamente utilizan RTP sobre protocolos de red no confiables, como UDP. Los bytes obtenidos de cada conjunto de muestras de voz o video son encapsulados en paquetes RTP, y cada paquete RTP es a su vez encapsulado en segmentos UDP.

Redes Unificadas

Pgina 6

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

Flujo de voz, 64 kb/s

Ventana RTP UDP IP Ethernet Sobrecarga


Cada paquete RTP consiste en un cabezal y los datos de voz. El cabezal contiene nmeros de secuencia, marcas de tiempo, y monitoreo de entrega. El formato de ste cabezal es el mostrado en la figura
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
V P X CC M PT Timestamp synchronization source (SSRC) identifier contributing source (CSRC) identifiers Sequence number

. Los campos ms relevantes son: 3.2.1 Versin (V) La versin actual del protocolo es la 2.

Redes Unificadas

Pgina 7

Redes Corporativas

3.2.2 CSRC count (CC) El campo indica la cantidad de identificadores CSRC incluidos en el cabezal (0 a 15, ver 3.2.7 ) 3.2.3 Tipo de informacin (PT=Payload Type) El campo payload identifica el tipo de informacin que viaja en el paquete. Es un campo de 7 bits, lo que permite diferenciar hasta 128 tipos de informacin. En audio, este campo indica el tipo de codificacin. Los valores de este campo se definen en el RFC 3551 [4]. Algunos valores de ejemplo se muestran en la siguiente tabla Payload Type 0 3 4 8 9 14 15 18 26 31 34 Formato PCM mu-law GSM G.723 PCM A-law G.722 MPEG Audio G.728 G.729 Motion JPEG H.261 H.263 Medio Audio Audio Audio Audio Audio Audio Audio Audio Video Video Video Clock Rate 8 kHz 8 kHz 8 kHz 8 kHz 8 kHz 90 kHz 8 kHz 8 kHz 90 kHz 90 kHz 90 kHz

3.2.4 Nmero de secuencia (Sequence Number) El campo correspondiente al nmero de secuencia es de 16 bits. Con cada paquete enviado, el emisor incrementa en uno el nmero de secuencia. Esto permite al receptor detectar paquetes perdidos, o fuera de orden. 3.2.5 Marca de tiempo (Time Stamp) Este campo es de 32 bits. Indica el momento al que corresponde la primer muestra de la ventana de informacin que viaja en el paquete. Este campo es utilizado por el receptor, para reproducir las muestras con la misma cadencia con las que fueron obtenidas. Es a su vez til para medir el jitter (ver 3.5.5). 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.2.6 Identificador del origen (SSRC - Synchronization Source Identifier) El campo correspondiente al SSRC es de 32 bits. Tpicamente cada flujo en una sesin RTP tiene un identificador diferente. El origen establece este nmero, asegurando que no se repita.

Redes Unificadas

Pgina 8

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

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

3.4

Ancho de banda

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

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

Redes Unificadas

Pgina 9

Redes Corporativas

Esta suma de protocolos hace que el ancho de banda requerido para el trfico de voz sobre Ethernet sea bastante mayor al ancho de banda del audio. Para una ventana de 20 ms, y con codificacin de audio Ley A, se obtienen 160 bytes de voz por trama Bytes de voz/trama = 64 kb/s * 20 ms / 8 = 160 bytes El paquete IP (incluyendo los protocolos RTP y UDP) agregan 40 bytes adicionales Bytes de paquete IP = 160 + 40 = 200 bytes La trama Ethernet agrega otros 26 bytes: Bytes de Trama Ethernet = 200 + 26 = 226 bytes En este ejemplo, cada 20ms se generan 226 bytes que se deben enviar por la LAN. Esto equivale a un ancho de banda de 90,4 kb/s (comprese con los 64 kb/s del flujo de audio) Ancho de banda LAN = 226 * 8 / 20 ms = 90.4 kb/s Es de hacer notar que este clculo fue hecho para el envo de audio en una direccin. Como las comunicaciones son bidireccionales, el ancho de banda real requerido en la LAN ser el doble. Pueden utilizarse tcnicas de supresin de silencio, en las que no se envan paquetes cuando no hay audio. En este caso, el ancho de banda total es similar al ancho de banda unidireccional. Por lo visto anteriormente, el ancho de banda de la voz paquetizada en la LAN depende del tamao de la ventana (tpicamente 10, 20 o 30 ms) y el CODEC utilizado (Ver 3.5.1). La siguiente tabla muestra los anchos de banda unidireccionales necesarios utilizando redes IP sobre Ethernet
Duracin de Bytes de Bytes de Trama (ms) voz/Trama paquete IP 10 80 120 20 160 200 30 240 280 10 10 50 20 20 60 30 30 70 20 16 56 30 24 64 20 13 53 30 20 60 Bytes de Ancho de trama Banda en Ethernet LAN (kbps) 146 116,8 226 90,4 306 81,6 76 60,8 86 34,4 96 25,6 82 32,7 90 23,9 79 31,7 86 22,9

Tipo de Codec G.711 (64 kb/s)

G.729 (8 kb/s) G.723 (6.3 kb/s) G.723 (5.3 kb/s)

Redes Unificadas

Pgina 10

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. 3.5 Factores que afectan la calidad de la voz sobre redes de paquetes

Realizaremos una pequea discusin acerca de los parmetros que influyen en la calidad de la voz transmitida a travs de la red de datos: 3.5.1 Factor de compresin Para poder transmitir la voz a travs de una red de datos, es necesario realizar previamente un proceso de digitalizacin. En telefona clsica, ste proceso se realiza utilizando CODECs que implementan la ley A o ley [1], obteniendo una seal digital de 64 kb/s. Este proceso, se realiza de acuerdo a la recomendacin G.711 de la ITU-T [5]. Sin embargo, cuando se dispone de velocidades de red reducidas, es conveniente tratar de minimizar el ancho de banda requerido por las seales de voz. Para ello, se han desarrollado varias recomendaciones, que reducen la velocidad de transmisin requerida, a expensas de degradar la calidad de la voz. La siguiente tabla resume las recomendaciones de la ITU-T respecto a los algoritmos estandarizados de compresin de voz: Algoritmo G.711 G.722 G.723.1 G.728 G.729 Annex A G.729 Annex B G.729 Annex AB Descripcin Audio encoding at 64 k bit/s (-law and A-law) [5] 7 kHz speed at 48, 56 and 64K bit/s (hi-fi voice) [6] Dual Rate Speed at 6.4 and 5.3 k bit/s [7] 16 k bit/s speech [8] 8 k bit/s speech (Conjugate structure- algebraic code excited linear prediction or CS-ACELP). Reduce Complexity [9] 8 k bit/s speech (Conjugate structure- algebraic code excited linear prediction or CS-ACELP). Silence Compression 8 k bit/s speech (Conjugate structure- algebraic code excited linear prediction or CS-ACELP). Reduce Complexity & Silence Compression

3.5.2 Prdida de paquetes A diferencia de las redes telefnicas, donde para cada conversacin se establece un vnculo estable y seguro, las redes de datos admiten la prdida de paquetes. Esto est previsto en los protocolos seguros de alto nivel, y en caso de que ocurra, los paquetes son reenviados. En los protocolos diseados para trfico de tiempo real generalmente no se recibe confirmaciones de recepcin de paquetes,

Redes Unificadas

Pgina 11

Redes Corporativas ya que si el canal es suficientemente seguro, estas confirmaciones cargan intilmente al mismo. En aplicaciones de voz y video, el audio es encapsulado en paquetes y enviado, sin confirmacin de recepcin de cada paquete. Si el porcentaje de perdida es pequeo, la degradacin de la voz tambin lo es. Los porcentajes de perdida admisibles dependen de otros factores, como por ejemplo la demora de transmisin y el factor de compresin de la voz. Existen tcnicas para hacer menos sensible la degradacin de calidad en la voz frente a la prdida de paquetes. La ms sencilla consiste en simplemente repetir el ltimo paquete recibido. Tambin cuentan como perdidos los paquetes que llegan a destiempo o fuera de orden. 3.5.3 Demora Un factor importante en la percepcin de la calidad de la voz es la demora. La demora total est determinada por varios factores, entre los que se encuentran Demora debida a los algoritmos de compresin En forma genrica, cuanto mayor es la compresin, ms demora hay en el proceso (los CODECS requieren ms tiempo para codificar cada muestra). Algoritmo de muestreo/compresin G711 (64 kb/s) G.728 (16 kb/s) G.729 (8 kb/s) G.723 (5.3 o 6.4 kb/s) Demora tpica introducida 125 s 2.5 ms 10 ms 30 ms

Demoras de procesamiento Es el tiempo involucrado en el procesamiento de la voz para la implementacin de los protocolos. Dependen de los procesadores utilizados Demoras propias de la red (latencia) Las demoras propias de la red estn dadas por la velocidad de transmisin de la misma, la congestin, y las demoras de los equipos de red (routers, gateways, etc.)

Redes Unificadas

Pgina 12

Redes Corporativas

Las demoras no afectan directamente la calidad de la voz, sino la calidad de la conversacin. Hasta 100 ms son generalmente tolerados, casi sin percepcin de los interlocutores. Entre 100 y 200 ms las demoras son notadas. Al acercarse a los 300 ms de demora, la conversacin se vuelve poco natural. Pasando los 300 ms la demora se torna crtica, haciendo muy dificultosa la conversacin. Un efecto secundario, generado por las demoras elevadas, es el eco. El eco se debe a que parte de la energa de audio enviada es devuelta por el receptor. En los sistemas telefnicos este efecto no tiene mayor importancia, ya que los retardos o demoras son despreciables, y por lo tanto, el eco no es percibido como tal. Cuando la demora de punta a punta comienza a aumentar, el efecto del eco comienza a percibirse. 3.5.4 Eco Si el tiempo transcurrido desde que se habla hasta que se percibe el retorno de la propia voz es menor a 30 ms, el efecto del eco no es percibido. Asimismo, si el nivel del retorno est por debajo de los 25 dB, el efecto del eco tampoco es percibido. En las conversaciones telefnicas habituales, el eco existe en niveles perceptibles (mayores a 25 dB), pero la demora es mnima, por lo que el eco no es perceptible. Las excepciones son las comunicaciones va satlite, en las que la demora promedio es del orden de los 150 ms. Para estos casos, las compaas telefnicas disponen generalmente de sofisticados equipos canceladores de eco. 3.5.5 Variaciones en la demora (Jitter) El jitter es la variacin en las demoras (latencias). Por ejemplo, si dos puntos comunicados reciben un paquete cada 20 ms en promedio, pero en determinado

Redes Unificadas

Pgina 13

Redes Corporativas momento, un paquete llega a los 30 ms y luego otro a los 10 ms, el sistema tiene un jitter de 10 ms. El receptor debe recibir los paquetes a intervalos constantes, para poder regenerar de forma adecuada la seal original. Dado que el jitter es inevitable, los receptores disponen de un buffer de entrada, con el objetivo de suavizar el efecto de la variacin de las demoras. Este buffer recibe los paquetes a intervalos variables, y los entrega a intervalos constantes. Es de hacer notar que este buffer agrega una demora adicional al sistema, ya que debe retener paquetes para poder entregarlos a intervalos constantes. Cunto ms variacin de demoras (jitter) exista, ms grande deber ser el buffer, y por lo tanto, mayor demora ser introducida al sistema. 3.5.6 Tamao de los paquetes El tamao de los paquetes influye en dos aspectos fundamentales en la transmisin de la voz sobre redes de datos: La demora y el ancho de banda requerido. Para poder transmitir las muestras codificadas de voz sobre una red de datos, es necesario armar paquetes, segn los protocolos de datos utilizados (por ejemplo, IP). Un paquete de datos puede contener varias muestras de voz. Por ello, es necesario esperar a recibir varias muestras para poder armar y enviar el paquete. Esto introduce un retardo o demora en la transmisin. Desde ste punto de vista, parece conveniente armar paquetes con la mnima cantidad de muestras de voz (por ejemplo, un paquete por cada muestra). Sin embargo, hay que tener en cuenta que cada paquete tiene una cantidad mnima de informacin (bytes) de control (cabezal del paquete, origen, destino, etc.). Esta informacin (sobrecarga u overhead), no aporta a la informacin real que se quiere transmitir, pero afecta al tamao total del paquete, y por tanto al ancho de banda, como se vio en 3.4. La duracin de las ventanas de voz se encuentran entre 10 a 30 ms, valor que se aporta a la demora total.

4 Medida de la calidad de voz en redes IP


La VoIP enfrenta problemticas propias de las redes de datos, que se manifiestan como degradaciones en la calidad del servicio percibida por los usuarios (QoE). Estas degradaciones pueden deberse por ejemplo a retardos, jitter (diferencia de retardos) y prdida de paquetes, entre otros factores. Para que la tecnologa de VoIP pueda ser utilizada en las Empresas, es esencial garantizar una calidad de voz aceptable. Para ello se han desarrollado mtodos para medirla. Estos mtodos se dividen en subjetivos y objetivos. Los mtodos subjetivos de medida de la calidad de servicio, se basan en conocer directamente la opinin de los usuarios.

Redes Unificadas

Pgina 14

Redes Corporativas Tpicamente resultan en un promedio de opiniones (por ejemplo, en un valor de MOS Mean Opinin Store). Los mtodos objetivos . A su vez se subdividen en intrusivos (se inyecta una seal de voz conocida en el canal y se estudia su degradacin a la salida) y no intrusivos (monitorean ciertos parmetros en un punto de la red y en base a estos permite establecer en tiempo real la calidad que percibira un usuario). 4.1 Mtodos Subjetivos

La calidad de la voz se establece a travs de la opinin del usuario. La calidad de audio puede ser evaluada directamente (ACR = Absolute Category Rating), o en forma comparativa contra un audio de referencia (DCR = Degradation Category Rating). Con evaluaciones directas (del tipo ACR) se califica el audio con valores entre 1 y 5, siendo 5 Excelente y 1 Malo. El MOS (Mean Opinin Store) es el promedio de los ACR medidos entre un gran nmero de usuarios. Si la evaluacin es comparativa, (del tipo DCR), el audio se califica tambin entre 1 y 5, siendo 5 cuando no hay diferencias apreciables entre el audio de referencia y el medido y 1 cuando la degradacin es muy molesta. El promedio de los valores DCR es conocido como DMOS (Degradation MOS). La metodologa de evaluacin subjetiva ms ampliamente usada es la del MOS (Mean Opinin Score), estandarizada en la recomendacin ITU-T P.800 [10]. Adicionalmente, se puede evaluar la calidad del audio y la calidad de la conversacin, las que pueden ser diferentes. La calidad de la conversacin implica una comunicacin bidireccional, donde, por ejemplo, los retardos juegan un papel muy importante en la calidad percibida. Los valores obtenidos con las tcnicas ACR (es decir, el MOS) puede estar sujeto al tipo de experimento realizado. Por ejemplo, si se utilizan varias muestras de buena calidad, una en particular puede ser calificada peor que si esa misma muestra se presenta junto a otras de peor calidad. Los mtodos subjetivos son en general caros y lentos porque requieren un gran panel de usuarios. Son dependientes entre otros factores del pas, del idioma, de las experiencias previas de los usuarios. 4.2 E-Model

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

Redes Unificadas

Pgina 15

Redes Corporativas La ITU-T ha creado un modelo en la recomendacin ITU-T G.107, llamado EModel [11], para estimar o predecir la calidad de la voz en redes IP (VoIP) percibida por un usuario tpico, en base a parmetros medibles de la red. El resultado del E-Model es un factor escalar, llamado R (Transmission Rating Factor), que puede tomar valores entre 0 y 100. El E-model toma en cuenta un gran cantidad de factores que pueden deteriorar la calidad de la voz percibida, como por ejemplo, el uso de compresin, los retardos de la red, as como tambin los factores tpicos en telefona como ser prdida, ruido y eco. Puede ser aplicado para estimar la calidad de la voz en redes de paquetes, tanto fijas como inalmbricas [12]. El E-Model puede ser utilizado para evaluar como se ver afectada la calidad de la voz en una red en base a parmetros mensurables. El modelo parte de un puntaje perfecto (100) y resta diversos factores que degradan la calidad, segn se puede ver en la ecuacin (4.2.1). R = R o - Is - Id Ie,eff + A donde Ro Representa la relacin seal/ruido bsica (antes de ingresar en la red) que incluye fuentes de ruido, tales como ruido ambiente. El valor inicial puede ser como mximo 100. Las fuentes de ruido independientes del sistema como ser el ruido ambiental, pueden hacer que este valor inicial sea menor a 100. Is Es una combinacin de todas las degradaciones que aparecen de forma ms o menos simultnea con la seal vocal. Por ejemplo, volumen excesivo y distorsin de cuantizacin. Id Representa las degradaciones producidas por el retardo y el eco (4.2.1)

Ie,eff Effective equipment impairment factor. Representa las degradaciones producidas por los cdecs y por las prdidas de paquetes de distribucin aleatoria. A Factor de Mejoras de Expectativas. Muchas veces, los usuarios estn dispuestos a aceptar peor calidad de voz si saben que se estn utilizando tecnologas no clsicas (por ejemplo celulares o VoIP). Permite compensar los factores de degradacin cuando existen otras ventajas de acceso para el usuario. Los valores de R varan entre 0 y 100, correspondiendo los valores ms altos a mejores calidades de voz.

Redes Unificadas

Pgina 16

Redes Corporativas Los tres tipos de degradaciones (Is , Id y Ie, eff) se subdividen, a su vez, en la combinacin de otros factores, como se detalla a continuacin. 4.2.1 Clculo de Is Is = Iolr + Ist + Iq donde Iolr Representa la disminucin de calidad producida por valores demasiado bajos de OLR (Overall Loudness Rating). El OLR se calcula, a su vez, como OLR = SLR + RLR Siendo SLR (Send Loudness Rating), es la prdida entre la boca del emisor y el micrfono del aparato telefnico SLR (Receive Loudness Rating), es la prdida entre el parlante del aparato telefnico y el odo del receptor Ist Representa la degradacin producida por efectos locales no ptimos, y depende esencialmente del factor STMR (Side Tone Masking Rating). Parte de la seal recibida por el micrfono es transmitida, dentro del mismo telfono, al parlante, generando un efecto local que hace que la persona que habla se escuche por el odo en el que tiene el tubo o microtelfono. La atenuacin de la seal que pasa del micrfono al parlante del mismo aparato se conoce como STMR. Si este valor no est dentro de los parmetros adecuados, genera una sensacin de eco, o de lnea muerta, segn el caso, bajando la calidad de la comunicacin. (4.2.3) (4.2.2)

Iq Representa la degradacin producida por la distorsin de cuantificacin. Se calcula en base a unidades qdu . 1 qdu se define como el ruido de cuantizacin que resulta de una codificacin y decodificacin completas en Ley A o Ley La frmula de clculo detallada de los parmetros (Iolr , I st, Iq) puede verse en la recomendacin G.107 [11]. 4.2.2 Clculo de Id Id = Idte + Idle + Idd Donde (4.2.3)

Redes Unificadas

Pgina 17

Redes Corporativas

Idte Expresa una estimacin para las degradaciones debidas al eco para el hablante. Se calcula en base al factor TELR (Talker Echo Loudness Rating) y la demora media T de punta a punta en un sentido. El factor TELR es la medida de la atenuacin del eco percibido por el hablante. 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 atenuacin entre la seal directa recibida por el oyente, la seal retardada recibida como eco. Idd Representa la degradacin producida por retardos absolutos demasiado largos Ta, que se producen incluso con compensacin perfecta del eco. Si Ta < 100 ms, el factor Idd es 0. La frmula de clculo detallada de los parmetros (Idte, Idle, Idd) puede verse en la recomendacin G.107. El efecto de la demora en el valor de R se grafica en la siguiente figura, asumiendo todos los otros factores ideales [13].

User Satisfaction
100 Very satisfactory 90 Satisfactory

80 Some users

R
70

dissatisfied

TELR = 65 dB

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 comunicacin, hacindola poco natural. Si a la grfica anterior se le suma el efecto del eco, el modelo E predice las siguientes curvas:

Redes Unificadas

Pgina 18

Redes Corporativas

User Satisfaction
100 Very satisfactory 90 Satisfactory

80 Some users

TELR = 65 dB TELR = 60 dB TELR = 55 dB Many users dissatisfied TELR = 45 dB TELR = 50 dB

R
70

dissatisfied

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 atenuacin del eco percibido por el hablante. Cuanto ms atenuado el eco percibido (mayor valor en db de TELR), menor efecto tiene el eco sobre la degradacin. En la medida que aumenta el eco, el valor de R decrece rpidamente con el retardo. 4.2.3 Clculo de Ie-eff Ie-eff representa las degradaciones producidas por los cdecs y por las prdidas de paquetes, segn la siguiente frmula: Ie-eff = Ie + (95 Ie) Ppl Ppl + Bpl BurstR (4.2.4)

Donde Ie Es un valor que depende del Codec utilizado, y representa la degradacin percibida producida por los diferentes algoritmos de compresin.

Redes Unificadas

Pgina 19

Redes Corporativas

Ppl

Representa la probabilidad de prdida de paquetes

Bpl Se define como el factor de robustez contra prdida de paquetes, y es un valor preestablecido para cada Cdec BurstR Es la Relacin de rfaga, y se define como

BurstR =

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

Si no existen prdida 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 kbit/s Waveform Codecs Ie Value 0 2 7 25 50 7 20 10 11 20 10 21 6 24 20 23 5 19 15

PCM ADPCM

G.711 64 G.726, G.727 40 G.721, G.726, G.727 32 G.726, G.727 24 G.726, G.727 16 Speech Compression Codecs G.728 G.729 G.729-A + VAD IS-54 IS-641 IS-96a IS-127 Japanese PDC GSM 06.10, Full-rate GSM 06.20, Half-rate GSM 06.60, EFR G.723.1 G.723.1 16 12.8 8 8 8 7.4 8 8 6.7 13 5.6 12.2 5.3 6.3

LD-CELP CS-ACELP VSELP ACELP QCELP RCELP VSELP RPE-LTP VSELP ACELP ACELP MP-MLQ

Redes Unificadas

Pgina 20

Redes Corporativas

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

User Satisfaction
100 Very satisfactory 90 Satisfactory

80 Some users G.711

R
70

dissatisfied G.729A Many users dissatisfied 60 Exceptional limiting case 50 0 100 200 300 400 500 G.723.1

One-way Delay (ms)

4.2.4 Clculo de A A representa un Factor de Mejoras de Expectativas. Muchas veces, los usuarios estn dispuestos a aceptar peor calidad de voz si saben que se estn utilizando tecnologas no clsicas (por ejemplo celulares o VoIP). No existe, por consiguiente, ninguna relacin entre A y los dems parmetros de transmisin. El cuadro siguiente presenta los valores tpicos de A para diferentes tecnologas, segn la recomendacin ITU-T G-113 [14].
Ejemplo de sistema de comunicacin Convencional (almbrico) Movilidad mediante redes celulares en un edificio Movilidad en una zona geogrfica o en un vehculo en movimiento Conexin con lugares de difcil acceso, por ejemplo, mediante conexiones de mltiples saltos por satlite Valor mximo de A 0 5 10 20

Redes Unificadas

Pgina 21

Redes Corporativas

4.2.5 Relacin de R y MOS El modelo relaciona el valor de R con el MOS, con un gran nivel de aproximacin, segn la siguiente ecuacin: Para R < 6.5: Para 0 < R < 100: Para R > 100: MOSCQE = 1 MOSCQE = 1 + 0,035R + R( R 60)(100 R )7 106 MOSCQE = 4,5 (4.2.5)

Las siguiente figuras muestran la relacin entre R y MOS, segn la frmula anterior:
MOS Excelente 5

Buena 4

Mediocre 3

Pobre 2

Mala 1 0 20 40 60 80

G.107_FB.2

100 R

Redes Unificadas

Pgina 22

Redes Corporativas

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

4.3

ITU-T P.862 (PESQ)

La recomendacin ITU-T P.862 [16] presenta un mtodo objetivo para la evaluacin de la calidad vocal de extremo a extremo de redes telefnicas de banda estrecha y cdecs vocales. Esta Recomendacin describe un mtodo objetivo para predecir la calidad subjetiva de la voz telefnica utilizando los cdecs ms comunes. Presenta una descripcin de alto nivel del mtodo, explica la forma de utilizar este mtodo y parte de los resultados de referencia obtenidos por la Comisin de Estudio 12 de la ITU-T en el periodo 1999-2000. Proporciona adicionalmente una implementacin de referencia escrita en el lenguaje de programacin ANSI-C.

Redes Unificadas

Pgina 23

Redes Corporativas El mtodo objetivo descrito se conoce por "evaluacin de la calidad vocal por percepcin" (PESQ, perceptual evaluation of evaluation of speech quality) y es el resultado de varios aos de trabajos de desarrollo. PESQ compara una seal inicial X(t) con una seal degradada Y(t) que se obtiene como resultado de la transmisin de X(t) a travs de un sistema de comunicaciones (por ejemplo, una red IP). La salida de PESQ es una prediccin de la calidad percibida por los sujetos en una prueba de escucha subjetiva que sera atribuida a Y(t). El primer paso de PESQ consiste en una alineacin temporal entre las seales iniciales X(t) y degradada Y(t). Para cada intervalo de seal se calcula un punto de arranque y un punto de parada correspondientes. Una vez alineadas, PESQ compara la seal (entrada) inicial con la salida degradada alineada, utilizando un modelo por percepcin, como el representado en la siguiente figura

Lo esencial en este proceso es la transformacin de las dos seales, la inicial y la degradada, en una representacin interna que intenta reproducir la representacin psicoacstica de seales de audio en el sistema auditivo humano, teniendo en cuenta la frecuencia por percepcin (Bark) y la sonoridad (Sone). El modelo cognitivo de PESQ termina brindando una distancia entre la seal vocal inicial y la seal vocal degradada (nota PESQ), la que corresponde a su vez con una prediccin de la MOS subjetiva. La nota PESQ se hace corresponder a una escala similar a la de MOS, un nmero nico en una escala de 0,5 a 4,5, aunque en la mayora de los casos la gama de las salidas estar entre 1,0 y 4,5, que es la

Redes Unificadas

Pgina 24

Redes Corporativas gama normal de valores de MOS que suelen darse en un experimento sobre la calidad de voz. La descripcin detallada del algoritmo es compleja, y puede verse en la Recomendacin referenciada. El mtodo PESQ es objetivo e intrusivo, ya que requiere del envo de una seal conocida de referencia para evaluar la calidad percibida de la voz. Algunos sistemas lo implementan enviando un par de segundos de audio conocido, lo que basta para poder aplicar el mtodo.

4.4

ITU-T P.563

El algoritmo P.563 es aplicable para la prediccin de la calidad vocal sin una seal de referencia independiente. Por ese motivo, este mtodo se recomienda para la evaluacin no intrusiva de la calidad vocal y para la supervisin y evaluacin con la red en funcionamiento, empleando en el extremo lejano de una conexin telefnica fuentes de seal vocal desconocidas. En comparacin con la Rec. ITU-T P.862 (que utiliza el mtodo 'basado en dos extremos' o 'intrusivo') que compara una seal de referencia de elevada calidad con la seal degradada en base a un modelo perceptual, P.563 predice la calidad de la voz de una seal degradada sin una seal vocal de referencia dada. En la figura siguiente se ilustran las diferencias entre ambos mtodos.

Redes Unificadas

Pgina 25

Redes Corporativas

El enfoque utilizado en P.563 puede visualizarse como un experto que escucha una llamada real con un dispositivo de prueba, tal como un microtelfono convencional conectado en paralelo a la lnea. Esta visualizacin permite explicar la principal aplicacin y permite al usuario clasificar las puntuaciones obtenidas mediante P.563. La puntuacin de calidad que se predice mediante P.563 est relacionada con la calidad percibida en extremo receptor. La seal vocal que debe evaluarse se analiza de varias formas, que detectan un conjunto de parmetros de seal caractersticos. En base a un conjunto restringido de parmetros clave se establece la asignacin a una clase de distorsin principal. Bsicamente, la parametrizacin de la seal del algoritmo P.563 puede dividirse en tres bloques funcionales independientes que se corresponden con las tres clases de distorsin principales: Anlisis del tracto vocal y desnaturalizacin de la voz o voces masculinas o voces femeninas o marcada robotizacin Anlisis de un ruido adicional intenso o SNR esttica reducida (nivel bsico del ruido de fondo)

Redes Unificadas

Pgina 26

Redes Corporativas o SNR por segmentos reducida (ruido relacionado con la envolvente de la seal). Interrupciones, silenciamientos y recorte temporal

El modelo de calidad vocal de P.564 se compone de tres bloques principales: 1. Decisin sobre la clase de distorsin de que se trata. 2. Evaluacin de la calidad vocal intermedia para la correspondiente clase de distorsin. 3. Clculo global de la calidad vocal. Cada clase de distorsin utiliza una combinacin lineal de varios parmetros para generar la calidad vocal intermedia. La calidad vocal definitiva se calcula combinando los resultados de calidad vocal intermedia con algunas caractersticas adicionales de la seal. La descripcin detallada del algoritmo es compleja, y puede verse en la Recomendacin referenciada.

Redes Unificadas

Pgina 27

Redes Corporativas

5 Unificacin en el Backbone
Como vimos en la Introduccin, la integracin de las redes de voz y datos en el Backbone (es decir, en los enlaces a distancia entre varios puntos de la misma empresa) es un concepto que tiene ya varios aos, y el principal mvil es el ahorro econmico. En la actualidad la gran mayora de las empresas con varias sucursales disponen de enlaces dedicados de datos, utilizando diversas tecnologas. Estos enlaces, generalmente tienen un costo fijo mensual, independientemente de su utilizacin. Es por tanto razonable tratar de incluir en estos enlaces la mayor cantidad de informacin posible, incluyendo conversaciones de voz. Para ello se han desarrollado varias tecnologas. 5.1 Multipelxores

Son equipos capaces de combinar (multiplexar) trfico de voz y de datos y enviarlo por un mismo enlace digital. Un equipo similar en la punta opuesta del enlace separa (demultiplexa) los distintos tipos de trficos. Los enlaces digitales pueden ser de diversas tecnologas, como enlaces punto a punto, Frame Relay, ATM, etc. Los Multiplexores disponen generalmente de interfaces de datos (pueden ser LAN, seriales, etc.) y de voz (con sealizacin FXS, FXO, E&M, E1, etc.)

LAN

MUX
WAN

MUX PBX

LAN

PBX

Voz

Voz

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

Redes Unificadas

Pgina 28

Redes Corporativas FXO Esta interfaz simula un telfono, a la que se puede conectar una lnea urbana. Tambin es posible conectar un puerto de interno de una PBX. E&M Esta interfaz se conecta a PBX, con sealizacin E&M T1 / E1 Esta interfaz provee canales telefnicos a travs enlaces digitales T1 (24 canales) o E1 (30 canales), tpicamente con sealizacin CAS (Channel Associated Signaling) o ISDN PRI. En cualquiera de los casos, la voz es empaquetada y enviada al enlace WAN en conjunto con los datos. El tipo de enlace WAN puede ser IP, Frame Relay, ATM, etc. La calidad de la voz depende del protocolo del enlace y de varios factores, como ser, algoritmos de compresin, tecnologa utilizada, ancho de banda, etc. 5.2 Routers con placas de voz

Los equipos ruteadores (routers) fueron diseados originalmente para interconectar dos o varias redes de rea local (LAN) a travs de enlaces de datos a distancia (WAN). Generalmente tienen incorporados algoritmos de ruteo de varios protocolos (incluido casi siempre el protocolo IP), y soportan una gran variedad de protocolos de WAN (Frame Relay, enlaces punto a punto, etc.) Muchos de estos equipos soportan actualmente placas de voz, con las mismas interfaces que los multiplexores (FXS, FXO, E&M, E1, etc.) 5.3 PBX con Gateways IP

Muchas PBX soportan actualmente la incorporacin de Gateways IP. Estos Gateways conectan la PBX directamente a la LAN, e implementan la conversin de la voz a paquetes IP y viceversa. Los paquetes de voz que salen del Gateway son enviados por el Router, a travs de la WAN, hasta el Gateway de la otra PBX.

Redes Unificadas

Pgina 29

Redes Corporativas

I P PBX LAN
Router

IP

PBX 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 priorizacin. Esto es muy importante debido a la diferencia de velocidades de transmisin que tpicamente existen entre la LAN y la WAN. Mientras que en la LAN es usual disponer de velocidades de 100 Mb/s, en la WAN, sta velocidad no sobrepasa generalmente 1 Mb/s y muchas veces se dispone velocidades menores a 0.1 Mb/s (por ejemplo 64 kb/s). Esto indica una relacin de velocidades de 1 a 100 o a 1000. Por sta razn, los routers implementan colas de datos: Los paquetes recibidos de la LAN son encolados para ser enviados a la WAN. Dado que la LAN tiene una velocidad mucho mayor que la WAN, las rfagas de paquetes recibidos desde la LAN pueden tener que esperar tiempos largos hasta ser enviados a la WAN. Esto perjudica especialmente a los paquetes de voz y video, que requieren demoras de punta a punta muy pequeas. Para evitar estos problemas, es posible marcar los paquetes, tanto a nivel IP como a nivel Ethernet, indicando la prioridad del mismo. Los routers preparados para aplicaciones de voz, soportan varias colas de datos, y los envos a la WAN se realizan por orden de prioridad. Los estndares ms comunes son DiffServ (para IP) y 802.1p para Ethernet. Por otro lado, cuando la velocidad de acceso a la WAN es pequea, los tiempos que demoran en ser enviados los paquetes no son despreciables. Por ejemplo, un paquete de 1.500 bytes, transmitido a 32 kbps demora 375 mseg en ser transmitido (1,5x8/32). Los paquetes de voz, an siendo priorizados, debern esperar a que pase el paquete de datos, por lo que se introducen demoras muy apreciables en el sistema. Previniendo esto, algunos protocolos de WAN pueden fragmentar los paquetes IP grandes, en varios paquetes de WAN ms pequeos, de manera que entre cada fragmento del paquete original se puedan insertar paquetes de voz. En el caso de Frame Relay, los mecanismos de fragmentacin estn normalizados, segn la recomendacin FRF-12 (Frame Relay Fragmentation Implementation Agreement)

Redes Unificadas

Pgina 30

Redes Corporativas 5.4 Gateways IP independientes

Estos equipos se utilizan cuando se dispone de PBX y routers que no soportan la incorporacin de Gateways IP. Son equipos independientes, que disponen de las interfaces telefnicas clsicas (FXS, FXO, E&M, etc.) y son capaces de paquetizar la voz sobre IP. Es muy importante que stos equipos puedan marcar a los paquetes que generan como prioritarios, ya sea a nivel de IP, Ethernet, o ambos. Es tambin muy importante que los routers respeten la priorizacin, segn las marcas realizadas por los gateways
Gw PBX LAN
Router

Gw

PBX WAN
Router

LAN

Redes Unificadas

Pgina 31

Redes Corporativas

6 Unificacin en el Escritorio
La unificacin de las redes de voz y datos a nivel del escritorio comprende varias tecnologas. La primera que analizaremos es la tecnologa llamada CTI (Computer Telephony Integration). sta tecnologa mantiene las redes de voz independientes de las redes de datos, pero permite vincularlas (integrarlas). Luego analizaremos las tecnologas de telefona sobre IP, en particular los estndares H.323 y SIP. 6.1 CTI La tecnologa de CTI (Computer Telephony Integration) fue concebida manteniendo las redes de voz y las de datos separadas, pero permitiendo integrar ambos sistemas. Esto se logra a travs de vnculos de datos entre los servidores informticos y las centrales telefnicas.

LAN

Host

Enlace

Pbx

Las tecnologas de CTI permiten mantener los telfonos clsicos, pero controlados desde aplicaciones informticas, mediante "telfonos virtuales" o "soft phones". Estos "telfonos virtuales" se implementan con aplicaciones informticas que emulan las funciones de los telfonos de escritorio, presentando en una pantalla las teclas de funciones ms habituales. Sin embargo, al utilizar telfonos clsicos, el audio no pasa por la red de datos, sino que se mantiene por la red de voz. Con las tecnologas de CTI, los telfonos virtuales permiten controlar los telfonos clsicos. Asimismo, la tecnologa de CTI permite "sincronizar" la recuperacin de datos en las aplicaciones de los PCs con el ingreso de cada llamada. Por ejemplo, si se dispone de la facilidad de identificacin del abonado llamante, es posible, utilizando funciones de CTI, desplegar en la pantalla del PC los datos del llamante antes de atender la llamada, de manera que se pueda saludar a quien llama por su nombre, o se conozca el historial del llamante sin necesidad de preguntar su identificacin.

Redes Unificadas

Pgina 32

Redes Corporativas

Las tecnologas de CTI son ampliamente utilizadas en ambientes de Call Center, dnde es importante minimizar los tiempos de cada llamada, y brindarle a las telefonistas la mxima informacin posible referente al cliente. Las tecnologas de CTI estn basadas en arquitecturas del tipo cliente servidor. Un Servidor de Telefona se vincula con la PBX mediante un enlace dedicado a tal fin. Este enlace tpicamente se implementa sobre comunicaciones seriales (RS232) o enlaces IP (por ejemplo, sobre Ethernet). En el Servidor de Telefona se instalan programas que dialogan con las PBX, y publican servicios para los usuarios de la red de datos. stos servicios permiten controlar los dispositivos telefnicos (por ejemplo, los telfonos) desde aplicaciones informticas.

6.2

H.323

H.323 (AUDIOVISUAL AND MULTIMEDIA SYSTEMS: Infrastructure of audiovisual services Systems and terminal equipment for audiovisual services [17] es una recomendacin de la ITU-T que describe los terminales y dems dispositivos que proveen servicios de comunicaciones multimedia (video, voz y datos) sobre redes de paquetes que no garantizan calidad de servicio (por ejemplo Ethernet con protocolos TCP/IP). La primera versin de H.323 fue aprobada en 1996 por la ITU-T. La versin 2 fue aprobada en enero de 1998, la versin 3 en 1999, la versin 4 en 2000, la versin 5 en 2003 y la versin 6 en junio de 2006. H.323 es parte de las recomendaciones H.32x (como por ejemplo H.320 para ISDN y H.324 para la PSTN) H.323 es aplicable a cualquier red conmutada de paquetes, con independencia de los protocolos utilizados en la capa fsica. La red debe proveer protocolos de entrega confiables (como por ejemplo TCP - Transmission Control Protocol) y protocolos de entrega no confiables (como por ejemplo UDP - User Datagram Protocol). Los protocolos confiables proveen mecanismos de confirmacin de recepcin de paquetes, y retransmisiones, de ser necesarias, para asegurar la correcta recepcin de los paquetes enviados. Los protocolos no confiables son del tipo mejor esfuerzo en la entrega de paquetes, pero no sobrecargan a la red con paquetes de confirmacin y eventuales retransmisiones, lo que los hace a su vez ms rpidos.

Redes Unificadas

Pgina 33

Redes Corporativas

6.2.1 Arquitectura H.323

La recomendacin H.323 define una arquitectura en la que se diferencian los siguientes componentes: Terminales H.323 Pasarelas (Gateways) para interconectar el mundo H.323 con otros sistemas de telecomunicaciones (tpicamente la red telefnica pblica analgica y digital) Controlador H.323 (Gatekeeper) Unidades de control multipunto (MCU - Multipoint Control Units)

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

Redes Unificadas

Pgina 34

Redes Corporativas estos mensajes, los codecs de audio y video y los protocolos utilizados para el Alcance de H.323 Micrfono Parlante Audio Codec G.711, G.722, G.723, G.728, G.729 RTP RTCP Cmara Display Video Codec H.261, H.263 UDP

Equipos de datos

Intrerfaz de datos T.120

IP

Control Canal de control H.245 Control Interfaces de usuario


Canal de sealizacin

TCP

H,225.0 (Q.931) Canal de RAS H.225.0

intercambio de datos entre los terminales.

Audio Codec La recomendacin H.323 admite los siguientes tipos de codificacin de audio (ver captulo 3.5.1):

Redes Unificadas

Pgina 35

Redes Corporativas

G.711 (64 kb/s) G.722 (7 kHz speed at 48, 56 and 64K bit/s (hi-fi voice) G.728 (16 kb/s) G.723.1 (Dual Rate Speed at 6.4 and 5.3K bit/s) G.729 (8 kb/s)

Todo terminal H.323 debe obligatoriamente disponer de un codec de audio. Este codec de audio debe soportar como mnimo la codificacin G.711 (en Ley A y Ley ), y opcionalmente las otras admitidas por la recomendacin H.323. El tipo de codec a utilizar al establecer una comunicacin de audio con otro terminal es negociado segn la recomendacin H.245, por el canal de control de llamadas. En una misma comunicacin, el terminal H.323 debe ser capaz de utilizar un codec en la recepcin y otro diferente en la transmisin. Si el terminal soporta G.723.1, debe ser capaz de codificar a 5.3 kb/s y a 6.3 kb/s. El audio generado es formateado segn la recomendacin H.225.0, utilizando los estndares RTP (Real Time Protocol) y RTCP (Real Time Control Protocol). Video Codec La codificacin de video es opcional en H.323, por lo que pueden existir terminales H.323 que no dispongan de facilidades de video. Sin embargo, si el terminal H.323 dispone de facilidades de comunicaciones de video, debe adecuarse a los siguientes codificadores: H.261 (n x 64 kb/s) H.263 ( < 64 kb/s)

H.261 QCIF es obligatorio si el terminal dispone de facilidades de video. Otros modos de H.261 y H.263 son opcionales. El tipo de codec a utilizar al establecer una comunicacin de video con otro terminal, la velocidad de transmisin, el formato de la imagen y las opciones de los algoritmos utilizados, son negociados segn la recomendacin H.245, por el canal de control de llamadas. Un mismo terminal puede soportar a la vez varios canales de video, tanto en la transmisin como en la recepcin. Asimismo, en una misma comunicacin, el terminal H.323 debe ser capaz de utilizar un codec en la recepcin y otro diferente en al transmisin. El video generado es formateado segn la recomendacin H.225.0, utilizando los estndares RTP (Real Time Protocol) y RTCP (Real Time Control Protocol).

Redes Unificadas

Pgina 36

Redes Corporativas

Interfaz de datos Los terminales H.323 pueden establecer comunicaciones de datos con otros terminales H.323 (por ejemplo, para compartir documentos). Para ello, pueden abrir canales de datos, los que pueden ser bidireccionales o unidireccionales. La recomendacin T.120 provee un estndar de interoperabilidad para el intercambio de datos entre terminales H.323 y otro tipo de terminales (por ejemplo, terminales H.324, H.320 y H.310). RTP (Real-Time Transport Protocol) El protocolo RTP, basado en el RFC 3550 (ver 3.2), establece los principios de un protocolo de transporte sobre redes que no garantizan calidad de servicio para datos de tiempo real, como por ejemplo voz y video. El protocolo establece la manera de generar paquetes que incluyen, adems de los propios datos de tiempo real a transmitir, nmeros de secuencia, marcas de tiempo, y monitoreo de entrega. Las aplicaciones tpicamente utilizan RTP sobre protocolos de red no confiables, como UDP. Los bytes obtenidos de cada conjunto de muestras de voz o video son encapsulados en paquetes RTP, y cada paquete RTP es a su vez encapsulado en segmentos UDP. RTP soporta transferencia de datos a destinos mltiples, usando facilidades de multicast, si esto es provisto por la red. RTCP (RTP Control Protocol) El RFC 3550 tambin detalla el protocolo de control RTCP. Los paquetes RTCP son enviados peridicamente y contienen indicadores de la calidad del enlace, y otros datos acerca de la fuente y destino de la comunicacin. Estos indicadores incluyen la cantidad de paquetes enviados, la cantidad de paquetes recibidos perdidos y el jitter en el receptor. El RFC 3550 no establece que deben hacer las aplicaciones (terminales H.323 en este caso) con los indicadores recibidos, sino que esto queda librado a cada implementacin. Los usos tpicos estn relacionados con el cambio de codecs, y el reporte de problemas, locales, remotos o globales. Canal de control H.245 Los terminales H.323 utilizan uno o varios canales de control para enviar y recibir mensajes desde y hacia otros terminales y dispositivos H.323 (gateways, gatekeepers, etc.). El protocolo utilizado en estos canales de control est

Redes Unificadas

Pgina 37

Redes Corporativas determinado en la recomendacin H.245 (Line transmisin of non-telephone signals Control protocol for multimedia communication (ver [18])) de la ITU-T. Los mensajes definidos en H.245 incluyen el intercambio de las capacidades de cada terminal, la apertura y cierre de canales lgicos, mensajes de control de flujo y comandos e indicadores generales. Los terminales deben mantener un canal de control H.245 por cada llamada en la que el terminal est participando. Dado que un terminal puede estar participando en forma simultnea en varias llamadas, puede tener tambin varios canales de control H.245 abiertos. Canal RAS H.225.0 (Registration, Admission and Status) El canal de RAS es utilizado entre los terminales y el Gatekeeper (Ver 6.2.1.3). A travs de ste canal, el terminal realiza las funciones de registro, admisin, solicitud de ancho de banda, status, etc. Este canal de sealizacin es independiente del canal de control H.245 y del canal de sealizacin de llamadas. En ambientes de red dnde no se dispone de Gatekeepers (recordar que los gatekeepers son opcionales en una red H.323), el canal de RAS no es utilizado por los terminales. En ambientes de red dnde se dispone de un Gatekeeper, el canal de RAS debe ser abierto entre el terminal y el gatekeeper, antes de ser abierto cualquier otro canal entre terminales. El protocolo utilizado en el canal RAS est descrito en la recomendacin de la ITU-T H.225.0 Call signalling protocols and media stream packetization for packet-based multimedia communication systems [19]

Canal de sealizacin H.225.0 El canal de sealizacin del terminal H.323 utiliza funciones de sealizacin del protocolo H.225.0 para establecer conexiones con otro terminal H.323. Este canal de sealizacin es independiente del canal de RAS y del canal de control H.245. El canal de sealizacin es abierto por el terminal antes de establecer el canal de control H.245. En ambientes de red en los que no hay Gatekeeper, el canal de sealizacin es establecido directamente entre dos terminales. En ambientes de red en los que se dispone de un Gatekeeper, el canal de sealizacin es abierto entre el propio terminal y el Gatekeeper, o entre el propio terminal y otro terminal, de acuerdo a lo indicado por el Gatekeeper. La recomendacin H.225.0 utiliza los mensajes descritos en la recomendacin Q.931 [20], utilizada en ISDN

Redes Unificadas

Pgina 38

Redes Corporativas

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

Los gateways son responsables de adaptar el audio, video y los datos, as como tambin la sealizacin, entre los formatos propios de H.323 y otras redes de telecomunicacin, de manera transparente para los usuarios. Los terminales H.323 pueden comunicarse con otros terminales H.323 de la misma red en forma directa, sin utilizar gateways. En redes dnde no es necesario tener comunicacin con terminales externos a la propia red, no es necesario disponer de gateways. Por ello, son elementos opcionales en la recomendacin H.323 Hacia la red H.323, el gateway presenta las caractersticas de un terminal H.323 (o de un MCU Multipoint Control Unit), y hacia la red PSTN, el de un terminal telefnico (de acuerdo al tipo de red a la que est conectado, podr presentar las caractersticas de un telfono analgico, ISDN, etc.) Los gatekeeprs conocen la existencia de gateways, ya que esto es especificado en el momento en que el gateway se registra en el gatekeeper. La recomendacin no detalla la manera en que deben implementarse los gateways. Pueden ser parte del mismo equipo donde reside el gatekeeper, ser equipos independientes, etc.

Redes Unificadas

Pgina 39

Redes Corporativas

6.2.1.3 Gatekeeper Las redes H.323 pueden disponer de un elemento centralizador de control y servicios telefnicos, llamado en la recomendacin Gatekeeper. Este dispositivo, en caso de existir, debe proveer, como mnimo, los siguientes servicios: Traduccin de direcciones Una de las funciones principales del Gatekeeper es traducir un nmero telefnico, o un alias a la direccin de red apropiada (por ejemplo, la direccin IP). Para ello, el Gatekeeper debe disponer de una tabla de traduccin de direcciones, que se actualiza cada vez que un dispositivo (por ejemplo un terminal H.323) se registra o de-registra en el Gatekeeper. Control de Admisin El Gatekeeper puede autorizar o negar el acceso (registro) a la red H.323, utilizando mensajes descriptos en la recomendacin H.225.0. Las reglas de decisin para autorizar o negar el acceso no son parte de la recomendacin. Control de Ancho de Banda El Gatkeeper debe soportar la mensajera H.225.0 respecto a la asignacin de ancho de banda. Mediante los protocolos adecuados, puede indicar a cada terminal el ancho de banda total disponible segn el tipo de llamada, las categoras de los terminales, etc. Gerenciamiento de su Zona Un Gatekeeper define una Zona H.323. Los terminales, gateways y MCUs registrados en el mismo Gatekeeper pertenecen a la misma zona. El Gatekeeper debe brindar como mnimo los servicios descritos anteriormente para todos los dispositivos de su Zona. En forma adicional a los servicios indicados, el Gatekeeper puede brindar cualquier otro tipo de servicios adicionales, como por ejemplo: Sealizacin para el control de llamadas Cuando una red H.323 dispone de un Gatekeeper, la sealizacin para el establecimiento y liberacin de llamadas puede realizarse directamente entre dos terminales, o a travs del Gatekeeper. El Gatekeeper puede asumir la funcin de centralizador de sealizacin, de manera que los terminales tengan que utilizarlo para las funciones de sealizacin de llamadas. Autorizacin de llamadas Mediante el uso de sealizacin H.225.0, el Gatekeeper puede autorizar o negar llamadas solicitadas desde los terminales. Las razones para autorizar o negar llamadas pueden incluir criterios de restricciones de ciertos terminales, horarios del da, etc. La recomendacin no establece cuales deben ser estos criterios, los que quedan librados a los fabricantes.

Redes Unificadas

Pgina 40

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

6.2.1.4 MCU Multipoint Control Unit (Unidad de control multipunto) El MCU provee soporte para realizar conferencias, entre 3 o ms terminales. Se compone de unidades Controladoras Multipunto (MC Multipoint Controller) y Procesadores Multipunto (MP Multipoint Processor) Controladoras Multipunto (MC Multipoint Controller) Los controladores multipunto (MC) proveen las funciones de control necesarias para la implementacin de conferencias de 3 o ms terminales. Los MC realizan el intercambio de capacidades entre los terminales de la conferencia, de manera de establecer un modo comn a todos los participantes. Como parte del establecimiento de una conferencia, los terminales se conectan a un MC utilizando el canal de control H.245. Procesadores Multipunto (MP Multipoint Processor) A diferencia de los MC, que se encarga exclusivamente del control de las conferencias, los MP reciben los canales de audio, video y/o datos de los terminales, los procesan, y los redistribuyen nuevamente a los terminales. Los MP son los encargados de realizar la conmutacin o mezcla del audio y video proveniente de los terminales, y redistribuirlo hacia los terminales. El MP puede decidir conmutar el audio o video, de manera de enviar hacia todos los terminales de la conferencia el audio o video proveniente de uno de los terminales, o mezclar el audio y video, de manera de enviar hacia todos los terminales la suma del audio y video proveniente de todos los otros. En el caso de video, la mezcla puede consistir en enviar hacia un mismo terminal varios cuadrantes, cada uno con el video proveniente desde los otros terminales. El criterio utilizado para realizar las mezclas o la conmutacin es determinado por el MC.

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

En marzo de 1999 es aprobado el RFC 2543, por el grupo de estudio MMUSIC del IETF, dando origen oficial al protocolo SIP (Session Initiaton Protocol). SIP tiene sus orgenes a fines de 1996, como un componente del Mbone (Multicast

Redes Unificadas

Pgina 41

Redes Corporativas Backbone), El Mbone, era una red experimental montada sobre la Internet, para la distribucin de contenido multimedia, incluyendo charlas, seminarios y conferencias de la IETF. Uno de sus componentes esenciales era un mecanismo para invitar a usuarios a escuchar una sesin multimedia, futura o ya establecida. Bsicamente un protocolo de inicio de sesin (SIP). En junio de 2002, el RFC 2543 fue reemplazado por un conjunto de nuevas recomendaciones, entre las que se encuentran los RFC 3261 al 3266 [21][22][23][24][25][26]. Una completa introduccin a SIP puede leerse en [27]. 6.3.1 Mensajera SIP La mensajera SIP est basada en el esquema Request Response de http. Esto presenta ciertas ventajas, sobre todo para los familiarizados con las tecnologas HTTP. A diferencia de H.323, todos los mensajes son de texto plano, y por lo tanto fciles de interpretar (recordar que en H.323, los mensajes eran binarios). Para iniciar una sesin se enva un mensaje de Request a una contraparte de destino. El destino recibe el Request, y lo contesta con el correspondiente Response. Un ejemplo del establecimiento de una comunicacin se muestra en la figura

Redes Unificadas

Pgina 42

Redes Corporativas SIP User Agent Client SIP User Agent Server

INVITE sip:pepe@fing.com 180 Ringing 200 OK ACK Media Stream BYE 200 OK host.abc.com
Los mensajes de Request tiene el formato <Mtodo> <URL> <SIP -Version> Por ejemplo: INVITE sip:pepe@fing.com SIP/2.0 La siguiente tabla resume los mtodos SIP Mtodo INVITE Descripcin

sip.fing.com

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 Unificadas

Pgina 43

Redes Corporativas

Las respuestas (Response) tiene el formato <SIP-Version> < Status-Code> <Reason> Por ejemplo: SIP/2.0 404 Not Found La siguiente tabla resume las respuestas SIP Respuesta 1xx 2xx 3xx 4xx Descripcin Informational Request received, continuing to process request. Success Action was successfully received, understood and accepted. Redirection Further action needs to be taken in order to complete the request. Client Error Request contains bad syntax or cannot be fulfilled at this server. Server Error Server failed to fulfill an apparently valid request. Global Failure Request is invalid at any server. Ejemplo 180 Ringing 181 Call is Being Forwarded 200 OK 300 Multiple Choices 302 Moved Temporarily 401 Unauthorized 408 Request Timeout 503 Service Unavailable 505 Version Not Suported 600 Busy Everywhere 603 Decline

5xx

6xx

Para comprender mejor el formato de los mensajes SIP, se analizar con ms detalle el mtodo INVITE. El mtodo INVITE contiene varios campos que forman un cabezal. Este cabezal incluye atributos que proporcionan informacin adicional acerca del mensaje. En el INVITE se incluye un identificador nico de la llamada, la direccin del destino, la direccin del origen, e informacin acerca del tipo de sesin que se quiere establecer. Un ejemplo del cabezal de INVITE es el siguiente:
INVITE sip:pepe@fing.com SIP/2.0 Via: SIP/2.0/UDP pc33.montevideo.com;branch=z9hG4bK776asdhds Max-Forwards: 70 To: Pepe <sip:pepe@fing.com> From: Alicia <sip:alicia@abc.com>;tag=1928301774 Call-ID: a84b4c76e66710@pc33.montevideo.com CSeq: 314159 INVITE Contact: <sip:alicia@pc33.montevideo.com> Content-Type: application/sdp Content-Length: 142

Redes Unificadas

Pgina 44

Redes Corporativas La primer lnea del mensaje contiene el nombre del mtodo (INVITE en el ejemplo anterior). Las lneas siguientes contienen el resto de los campos del cabezal. Los detalles de la sesin, como por ejemplo el tipo de medio, el codec o la frecuencia de muestreo, no son descriptos en el cabezal SIP. El cuerpo del mensaje SIP contiene una descripcin de estos parmetros, codificados en un formato conocido como SDP (Session Description Protocol). Este mensaje SDP (no mostrado en el ejemplo anterior) es transportado en el mensaje SIP de manera similar a como se transporta un documento adjunto en un mensaje de e-mail. El formato SDP se estandariza en el RFC 2327 [28] Un ejemplo del mensaje anterior, incluyendo el cuerpo SDP, se muestra a continuacin:
INVITE sip:pepe@fing.com SIP/2.0 Via: SIP/2.0/UDP pc33.montevideo.com;branch=z9hG4bK776asdhds Max-Forwards: 70 To: Pepe <sip:pepe@fing.com> From: Alicia <sip:alicia@abc.com>;tag=1928301774 Call-ID: a84b4c76e66710@pc33.montevideo.com CSeq: 314159 INVITE Contact: <sip:alicia@pc33.montevideo.com> Content-Type: application/sdp Content-Length: 142 v=0 o=AGarcia 2890844526 2890842807 IN IP4 126.16.64.4 s=Phone Call c=IN IP4 100.101.102.103 t=0 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000

El formato de cada rengln de SDP es <tipo>=<valor>. <tipo> es siempre un nico carcter, y se diferencian maysculas de minsculas. El formato de <valor> depende del <tipo> al que corresponda. No puede haber espacios al lado del =, ni antes ni despus. En este ejemplo, SDP contiene: Versin del protocolo (v) Origen (o)
o=<username> <session id> <version> <network type> <address type> <address>

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

Redes Unificadas

Pgina 45

Redes Corporativas

Datos de la conexin (c)


c=<network type> <address type> <connection address> <network type> = IN para Internet <address type> = IP4 para IP version 4 <connection address> Es la direccin

IP, que puede ser una direccin de multicast. Puede incluirse un valor de TTL (Time To Live), luego de la direccin IP, separada con el smbolo /, por ejemplo: c=IN IP4 224.2.1.1/127 Temporaizadores (t)
t=<start time> <stop time>

Indica las horas de comienzo y fin de una sesin. Medios (m)


m=<media> <port> <transport> <fmt list> <media> puede ser "audio", "video", "application", "data" and "control" <port> Puerto para el stream de medios <transport> Para IP4, tpicamente es RTP/AVP, indicando que se

utiliza el transporte RTP <fmt list> Es el formato del audio o video transportado (Ver Tipo de informacin (PT=Payload Type) ) Atributos (a)
a=<attribute>:<value> a=<attribute>

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

6.3.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 Unificadas

Pgina 46

Redes Corporativas 6.3.2.1 Terminales SIP Los terminales SIP, al igual que los H.323 son telfonos multimedia IP. Estos telfonos pueden ser aplicaciones informticas, que utilizan las capacidades multimedia del PC (parlantes y micrfono), o terminales fsicos de similar aspecto a cualquier telfono o videotelfono. Los terminales SIP, llamados SIP User Agents, pueden iniciar y recibir sesiones SIP. Cada terminal dispone de un User Agent Client (UAC) y un User Agent Server. Los UAC son los encargados de iniciar requerimientos SIP hacia otros terminales. Los UAS son quienes escuchan y atienden los requerimientos remotos. As como los terminales telefnicos clsicos se identifican mediante su nmero de telfono, o nmero de abonado, y los terminales H.323 mediante su alias, los terminales SIP se identifican a travs de su direccin SIP. El direccionamiento en SIP utiliza el formato de URLs de Internet: sip:nombre@dominio Los terminales SIP pueden soportar servicios de presencia, incorporando agentes de presencia (PA= Presence Agent). En estos casos son capaces de recibir solicitudes de subscripciones y generar notificaciones de cambios de estados. Un PA soporta un paquete de eventos de presencia, el que incluye los mtodos SUBSCRIBE y NOTIFY.

6.3.2.2 Servidores SIP Registrar Server Es un servidor de registro de usuarios SIP. Los usuarios (agentes SIP) solicitan su registro en este servidor, mediante el intercambio de mensajes SIP. Un servidor de registro acepta solamente el mtodo REGISTER, rechazando cualquier otro mtodo con una respuesta 501 (Not Implemented). La informacin de los usuarios registrados es puesta a disposicin de otros servidores, como los Proxies o Redirect. Proxy Server Es un servidor que atiendo las solicitudes y las redirige. Para ubicar el destino, puede consultar un servidor de ubicaciones (Location Server). La siguiente figura esquematiza el funcionamiento de SIP Proxy

Redes Unificadas

Pgina 47

Redes Corporativas

SIP User Agent Client

SIP Proxy Server

SIP User Agent Server

INVITE 200 OK ACK Media BYE

INVITE 200 OK

200 OK host.fing.com server.fing.com sip.abc.com

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

Redes Unificadas

Pgina 48

Redes Corporativas

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

Redes Unificadas

Pgina 49

Redes Corporativas
SIP User Agent SIP Redirect Server REGISTER INVITE sip:picard@wcom.com 302 Moved ACK 200 OK SIP User Agent

RS
2

C
INVITE 180 Ringing 200 OK ACK Media Stream

UAS

host.wcom.com

server.wcom.com

sip.uunet.com

Location Server Es un servidor de bsqueda. Puede ser consultado para obtener la direccin final de un usuario SIP. Presence Server Un servidor de presencia es un equipo que en ciertas ocasiones acta como un agente de presencia y enva informacin de presencia a otros agentes, y en otras ocasiones acta como proxy, redirigiendo las solicitudes de subscripciones a otros agentes de presencia.

6.3.2.3 Gateway SIP Al igual que en H.323, existen pasarelas SIP hacia la PSTN y tambin hacia H.323 Los gateways son responsables de adaptar el audio, video y los datos, as como tambin la sealizacin, entre los formatos propios de SIP y otras redes de telecomunicacin, de manera transparente para los usuarios. En redes dnde no es necesario tener comunicacin con terminales externos a la propia red, no es necesario disponer de gateways.

Redes Unificadas

Pgina 50

Redes Corporativas

Referencias
[1] Redes de Voz , Versin 05, Jos Joskowicz (Agosto 2006) [2] Redes de Datos, Versin 03, Jos Joskowicz (Agosto 2006) [3] RFC 3550: RTP: A Transport Protocol for Real-Time Applications, H. Schulzrinne et al (July 2003) [4] RFC 3551: RTP Profile for Audio and Video Conferences with Minimal Control, H. Schulzrinne et al (July 2003) [5] Recommendation G.711: Pulse Code Modulation (PCM) of voice frequencies, CCITT, (1988). [6] Recommendation G.722: 7 kHz audio-coding within 64 kbit/s, CCITT, (1988). [7] Recommendation G.723.1: Dual Rate speech coder for multimedia communications transmitting at 5.3 and 6.3 kbit/s, ITU-T, (1996). [8] Recommendation G.728: Coding of speech at 16 kbit/s using Low-delay code excited linear prediction, CCITT, (1992). [9] Recommendation G.729: Coding of speech at 8 kbits using ConjugateStructure Algebraic-Code-Excited Linear-Prediction (CS-ACELP), ITU-T, (1996). [10] ITU-T P-801 Mean Opinion Score (MOS) (Mtodos de determinacin subjetiva de la calidad de transmisin), Aug 1996, http://www.itu.int/rec/T-REC-P.800/es [11] 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 [12] E-model tutorial http://www.itu.int/ITU-T/studygroups/com12/emodelv1/introduction.htm [13] TIA/TSB 116-A Telecommunications - IP Telephony Equipment Voice Quality Recommendations for IP Telephony, Mar 1, 2006 [14] Degradaciones de la transmisin debido al tratamiento de las seales vocales, Recomendacin ITU-T G.113 (2001), [15] RFC 3611: RTP Control Protocol Extended Reports (RTCP XR), T. Friedman et al (November 2003) [16] Recommendation ITU-T P.862: Evaluacin de la calidad vocal por percepcin: Un mtodo objetivo para la evaluacin de la calidad vocal de extremo a extremo de redes telefnicas de banda estrecha y cdecs vocales Febrero 2001 [17] Recommendation H.323 Version communications systems, ITU-T (Junio 2006) 6: Packet-based multimedia

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

Redes Unificadas

Pgina 51

Redes Corporativas

[19] Recommendation H.225.0 Version 4: Call signalling protocols and media stream packetization for packet-based multimedia communication systems, ITU-T (March 2001) [20] Recommendation Q.931: ISDN user-network interface layer 3 specification for basic call control, CCITT (May 1998) [21] RFC 3261: SIP: Session Initiation Protocol J. Rosenberg et al. June 2002 [22] RFC 3262: Reliability of Provisional Responses in Session Initiation Protocol (SIP) J. Rosenberg et al. June 2002 [23] RFC 3263: Session Initiation Protocol (SIP): Locating SIP Servers J. Rosenberg et al. June 2002 [24] RFC 3264: An Offer/Answer Model with Session Description Protocol (SDP) J. Rosenberg et al. June 2002 [25] RFC 3265: Session Initiation Protocol (SIP)-Specific Event Notification AB. Roach June 2002 [26] RFC 3266: Support for IPv6 in Session Description Protocol (SDP) S. Olson et al June 2002 [27] SIP : Understanding the Session Initiation Protocol. 2nd ed. (Artech House telecommunications library) ISBN 1-58053-655-7 Alan B. Johnston, 2004 [28] RFC 2327: SDP: Session Description Protocol M. Handley et al. April 1998

Redes Unificadas

Pgina 52

Vous aimerez peut-être aussi