3. DESARROLLO DE SERVICIOS AVANZADOS DE VOZ
SOBRE REDES DE PAQUETES
1. Introducción
La transmisión de tráfico de voz sobre redes de paquetes ha experimentado grandes avances en los últimos
años tanto por el desarrollo de estándares como por la aparición de productos basados en tecnología IP. A
medio plazo esta tecnología se vislumbra prometedora, motivada por su utilización en redes móviles de
tecnología UMTS. La evolución de la release 99 hacia la release 4 y 5 incluye el salto de tecnología de
transmisión de voz tradicional hacia tecnologías de transmisión de Voz sobre IP (VoIP) basadas en el despliegue
de una única red de paquetes integradora de todos los servicios.
En este ámbito, el presente artículo introduce las distintas tecnologías de transmisión de VoIP actualmente
estandarizadas, así como la experiencia del grupo en el desarrollo de servicios para el caso de utilizar el
protocolo H.323, protocolo que por motivos históricos, la primera versión apareció en el año 1996, presenta
un mayor número de productos en el mercado.
La integración de servicios en una única red de paquetes permite el desarrollo de nuevos servicios que
permiten integrar aspectos que anteriormente estaban segmentados por motivos de la tecnología de red
sobre la que se basaban. Ejemplos de estos servicios son servicios de localización, grupos de salto, transmisión
de vídeo, integración de buzón de voz y correo electrónico, fax, autenticación, control de acceso y seguridad.
Durante los primeros pasos de esta tecnología se fijó como aspecto diferenciador, respecto a la tecnología
clásica de transmisión basada en circuitos, los aspectos relacionados con el coste, especialmente en entornos
corporativos donde existe una red de datos, típicamente propiedad de la propia organización y una red
telefónica, normalmente contratada a uno o varios operadores con facilidades de grupo cerrado de usuarios,
numeración reducida, etc.
Sin embargo la reducción de los precios del mercado motivada por la aparición de la competencia en el
mismo, junto con la falta de soluciones que garanticen, de un modo eficiente, calidad para la transmisión
sobre redes de datos, han provocado que esta tecnología no haya tenido el éxito esperado por las primeras
previsiones. Hasta ahora existen distintos ejemplos tanto de operadores que han apostado por esta tecnología
para ofrecer el servicio de voz como de organizaciones privadas.
Sin embargo, en ambos casos, estas entidades han debido realizar un sobredimensionado de la red para
garantizar aspectos de QoS. Por otro lado, existe una falta de soluciones técnicas para permitir el
encaminamiento de tráfico telefónico a través de la pasarela más adecuada (menor coste) de un modo
dinámico y adaptativo. Las previsiones de despliegue según un estudio de Lucent-Dataquest muestran que
existirá una importante demanda provocada especialmente por entornos corporativos.
3
4. DESARROLLO DE SERVICIOS AVANZADOS DE VOZ
SOBRE REDES DE PAQUETES
Los escenarios de aplicación de VoIP permiten la comunicación de usuarios de tres modos distintos en función
del terminal utilizado:
- PC-PC: en el caso de utilizar terminales tipo
* PC o equivalente interconectados mediante una red de datos
- Teléfono-Teléfono: en el caso de utilizar terminales tradicionales. En este caso, para la interconexión
de los mismos se utiliza un backbone IP y dispositivos que permiten interconectar las centralitas
tradicionales con la red IP (Gateways).
- Teléfono-PC: en el caso de interconectar usuarios conectados a redes de datos y redes telefónicas
tradicionales.
Estos entornos se diferencian en la complejidad, el coste y el equipamiento necesario. La más
fácil y barata es la comunicación PC-PC. Cada PC necesita una tarjeta de sonido, un micrófono
y un altavoz. Si utilizamos teléfonos tradicionales, la complejidad y el coste son mayores porque
se necesita una gateway, además de la harmonización de direcciones IP-E-164. La tercera opción
es la más compleja. Se necesita una gateway y además un software compatible con ella. En
todos los casos, la necesidad de transmisión en tiempo real, obliga a la utilización de protocolos
no fiables (UDP/IP), con lo que es necesario garantizar aspectos de QoS (retardo, ancho de
banda, etc.) bien mediante el sobredimensionado o bien mediante técnicas basadas en los
modelos de DiffServ e IntServ sobre los que se está trabajando actualmente.
En este ámbito, la siguiente sección muestra los distintos protocolos de señalización utilizados en
VoIP centrándose en H.323 por las razones antes mencionadas.
4
5. DESARROLLO DE SERVICIOS AVANZADOS DE VOZ
SOBRE REDES DE PAQUETES
2. Protocolos de señalización en VoIP
Diversos organismos trabajan en la normalización del servicio de VoIP. Los más importantes son el
ITU-T y el IETF. El ITU-T fue pionero en este sentido, produciendo en 1996 la primera versión de la
recomendación H.323, que es considerada un paraguas de normas que aglutinan distintos mecanismos de
señalización para la transmisión de tráfico multimedia sobre redes de paquetes (H.225.0, H.245, T.120,...).
El IETF a través de grupo MMUSIC, estandarizó tres años más tarde otro protocolo de señalización denominado
SIP (Session Initial Protocol) que actualmente está siendo debatida su adopción como estándar para la
transmisión de voz en redes UMTS.
Pensado específicamente para VoIP. La estructura de un escenario SIP es prácticamente la misma, en cuanto
a los elementos funcionales, a la ofrecida por H.323. La principal diferencia es su simplicidad. SIP hace en
una transacción lo que H.323 hacía mediante cuatro o cinco intercambios de mensajes, cada uno de ellos
especificado en un documento distinto del ITU-T. Por esta razón tiene un tiempo de establecimiento menor.
Otra solución es la denominada MGCP, MEGACO o H.248. Esta nueva norma establece el protocolo de
señalización entre una pasarela o Media Gateway en terminología MGCP y un servidor de llamadas o Media
Gateway Controler. La norma originalmente propuesta por el IETF en 1998 (MGCP) y que integraba soluciones
de distintos fabricantes, ha evolucionado hacia el protocolo MEGACO, definida por el IETF en septiembre
de 1999 y adoptada por el ITU-T en la norma H.248.
H.323
Los fabricantes de productos de comunicación se han visto atraídos por esta tecnología desde
1996 cuando se generó la H.323v1. Empresas como Lucent Technologies, Cisco, Teldat, NetSpeak,
y NetPhone, han introducido productos VoIP basados en este estándar. El líder del mercado,
Microsoft, tiene el producto software más utilizado para el soporte de VoIP (NetMeeting), ya que
viene integrado en el paquete de aplicaciones de Windows. Quizás por esta razón sea el estándar
para VoIP más utilizado.
La recomendación H.323 del ITU-T define los componentes, procedimientos y protocolos para ofrecer
comunicaciones multimedia en redes de paquetes sin QoS garantizada. Ofrece servicios de transporte fiable
y no fiable de datos, y no fiable de voz y vídeo. Es independiente de la topología de red y ofrece
interoperabilidad con terminales de la serie H (H.320, H.322,...) a través de pasarelas o gateways.
5
6. DESARROLLO DE SERVICIOS AVANZADOS DE VOZ
SOBRE REDES DE PAQUETES
Un sistema H.323 está formado por los siguientes elementos: terminales, gateways, gatekeepers, y MCUs
(Unidad de control Multipunto). El terminal H.323 proporciona comunicación bidireccional en tiempo real con
otro terminal, gateway o MCU. La información intercambiada consiste en: control, indicaciones, audio, vídeo
y datos. Los terminales H.323 deben al menos soportar la transmisión de audio, si bien existen otras
combinaciones posibles como: audio más datos, audio más vídeo y audio más vídeo más datos.
Todos los terminales deben tener una unidad de control del sistema, una capa H.225.0, una interfaz de red
y un codificador de audio. El codificador de vídeo y las aplicaciones de datos son opcionales.
El gateway permite la comunicación entre terminales H.323 y terminales ITU conectados a otras redes.
Soporta conversión de formatos de transmisión –transcodificación- (por ejemplo H.225.0 a/desde H.221) y
procedimientos de comunicación (a/desde H.245 a H.242) además de establecimiento y liberación de llamada
en ambos lados. El gateway no es necesario para establecer una comunicación entre dos terminales H.323.
El gatekeeper soporta traslación de direcciones, control de acceso, control de ancho de banda y gestión de
zonas. Es opcional en el sistema H.323 pero si existe es obligatorio utilizarlo. Este componente representa
la pieza clave de la arquitectura para el desarrollo de servicios.
La MCU soporta la comunicación multipunto. Se compone de un controlador multipunto (MC) el cual gestiona
el control de las conexiones (obligatorio) y un procesador multipunto (MP) que gestiona la mezcla y
conmutación de audio y vídeo. Este último es opcional ya que esta funcionalidad puede residir en cada uno
de los terminales. Los protocolos de señalización más importantes utilizados en el seno de la H.323 son:
H.225.0: define la señalización entre terminales/gateways y gatekeeper (RAS). También define la señalización
para establecimiento y liberación de la llamada (Setup, Alerting,...) que va por el canal de señalización de
llamada. En este caso se utiliza un subconjunto de las funciones proporcionadas por la Q.931.
H.245: señalización de control extremo a extremo. La función principal es el intercambio de capacidades
entre los terminales H.323 previa a la transmisión de información.
H.235: trata sobre la seguridad en la comunicación incluyendo autentificación, autorización, control de
llamada seguro y privacidad de los canales de voz.
H.450: señalización para el control de todos los servicios suplementarios (desvío de llamada, llamada en
espera,...)
6
7. DESARROLLO DE SERVICIOS AVANZADOS DE VOZ
SOBRE REDES DE PAQUETES
Una llamada H.323 puede dividirse en tres fases en relación con los protocolos de señalización que
intervienen en la misma:
RAS (Registro Autenticación y Estado): cuando un terminal quiere hacer una llamada, pide permiso al
gatekeeper mandando un paquete ARQ (Admission Request). Este mensaje contiene, entre otras cosas, los
alias del destino (nombre o teléfono del usuario con el que quiere comunicarse).
El GKR puede dar permiso para la llamada con un ACF (Admission Confirm) que contiene la dirección de
transporte asociada al alias destino o su propia dirección de transporte si decide encaminar la señalización
H.225.0. El GKR puede también denegar la llamada con un ARJ (Admission Reject) dando la razón por la cual
la llamada no se ha cursado (por ejemplo, no hay suficiente ancho de banda). Durante esta fase el GKR
realiza tres funciones: traducción de direcciones, autorización de llamada y gestión del ancho de banda.
H.225.0: es un subconjunto de mensajes del protocolo de señalización Q.931 de RDSI. Proporciona una
conexión lógica entre los dos terminales. En las primeras versiones de la norma, H.225.0 se implementaba
sobre TCP pero a partir de la versión 3 existe la posibilidad de utiliza UDP por problemas de retardo.
H.245: tan pronto como acaba la fase anterior, los dos terminales intercambian sus capacidades. Se ponen
de acuerdo en el tipo de información que van a mandar.
Después de estas tres fases, se abren los canales lógicos entre los dos terminales de acuerdo con las
capacidades intercambiadas y la comunicación multimedia comienza.
Los paquetes de audio y vídeo se transmiten sobre UDP, por lo que pueden desordenarse, perderse o
retrasarse. Por esta razón se utiliza por encima de UDP el protocolo RTP (Real-Time Transport Protocol). Este
protocolo se utiliza para permitir compensar el jitter y el desorden de los paquetes en recepción. El protocolo
RTCP (RTP Control Protocol) se usa junto con RTP y permite cierta realimentación sobre la calidad recibida.
Para intentar mejorar la calidad de servicio en los streams de audio y vídeo, se puede utilizar el marcado de
paquetes en nodos frontera proporcionado por diffserv. Se elige este mecanismo en lugar de intserv por su
sencillez.
La señalización H.225.0 y H.245 puede encaminarse por el GKR o no en función de que se utilice el
denominado modelo directo o indirecto. Si el GKR intercepta todos los mensajes de señalización puede
realizar la gestión de las llamadas manteniendo una tabla con las llamadas activas, el estado de los
terminales, etc.
7
8. DESARROLLO DE SERVICIOS AVANZADOS DE VOZ
SOBRE REDES DE PAQUETES
Por tanto, para establecer una comunicación H.323 se abren 3 canales de señalización (H.225.0, H.245 y
RAS) más los canales lógicos de audio, vídeo y datos.
Uno de los mayores problemas de H.323 es el elevado retardo de establecimiento de llamadas. Con objeto
de mejorar la eficiencia, a partir de la versión 2 de la norma se reduce el tiempo de establecimiento de
llamada con dos procedimientos: Fast Connect y encapsulado de mensajes H.245 en mensajes Q.931.
EN RESUMEN
La integración de servicios en una única red de paquetes permite el desarrollo de nuevos
servicios que permiten integrar aspectos que anteriormente estaban segmentados por motivos
de la tecnología de red sobre la que se basaban. Ejemplos de estos servicios son servicios de
localización, grupos de salto, transmisión de vídeo, integración de buzón de voz y correo
electrónico, fax, autenticación control de acceso y seguridad. Durante los primeros pasos de
esta tecnología se fijó como aspecto diferenciador, respecto a la tecnología clásica de
transmisión basada en circuitos, los aspectos relacionados con el coste, especialmente en
entornos corporativos donde existe una red de datos, típicamente propiedad de la propia
organización y una red telefónica, normalmente contratada a uno o varios operadores con
facilidades de grupo cerrado de usuarios, numeración reducida, etc.
8
9. DESARROLLO DE SERVICIOS AVANZADOS DE VOZ
SOBRE REDES DE PAQUETES
3. Proyecto PISCIS
A continuación, se describe el proyecto PISCIS, junto con la plataforma piloto del mismo y los servicios
desarrollados en esta plataforma indicando los entornos de desarrollo sobre los que se han trabajado.
El proyecto PISCIS: Plataforma Piloto de Servicios de Comunicaciones sobre Internet de Servicios Integrados
es un proyecto de investigación nacional que trabaja en la problemática de la transmisión de voz sobre redes
de paquetes.
El objetivo del proyecto PISCIS es el desarrollo de una plataforma de experimentación de red que permite
soportar la prestación de servicios avanzados de voz sobre redes IP con soporte de mecanismos de calidad
de servicio (QoS).
El equipo de trabajo está integrado por grupos de investigación de la Universidad Politécnica de Madrid,
Universidad de Sevilla y Universidad Carlos III de Madrid y cuenta con la colaboración de las empresas Teldat
como fabricante de equipos y SuperCable y CyC como operadores de red.
Los objetivos del proyecto sobre los que más se ha trabajado son el despliegue de una red piloto que
interconecte las tres universidades utilizando técnicas de transmisión de VoIP que permitan probar la utilidad
de los servicios de red desarrollados.
En esta línea, se mantiene activa una plataforma entre las tres universidades.
Cada escenario cuenta con PCs con software específico (NetMeeting, OpenPhone,...), una pasarela Teldat
para conectar teléfonos tradicionales y una línea telefónica conectada a la misma pasarela para poder cursar
llamadas desde/hacia la Red Telefónica Conmutada (RTC).
Tras las pruebas de conectividad básicas iniciales se decidió utilizar la funcionalidad de un gatekeeper para
ofrecer servicios de valor añadido como son: la función de directorio, el control de acceso, el soporte de
servicios de Help Desk o grupo de salto, la coordinación con mecanismos de calidad de servicio y el desarrollo
de pasarelas de buzón de voz-email.
9
10. DESARROLLO DE SERVICIOS AVANZADOS DE VOZ
SOBRE REDES DE PAQUETES
4. Desarrollo de Servicios en redes VoIP
El gatekeeper (GKR) es un componente que inicialmente se consideró opcional en el modelo, debido a la
aparición en el mercado de terminales que podían comunicarse entre sí, sin la necesidad de disponer de
dicho elemento, pero que constituye la pieza clave del sistema sin el cual el servicio de VoIP no es más que
un juguete. Las funciones que dicho elemento debe realizar son al menos:
- Función de registro: los terminales al arrancar deben registrase en el GKR (alias, dirección IP puerto).
,
- Traducción de direcciones: el GKR debe traducir los alias a direcciones de transporte (IP+puerto). La
traducción se hace usando una tabla actualizada con los mensajes de registro.
- Control de admisión: el GKR controla el acceso a la red mediante los mensajes H.225.0 ARQ
(Admission Request), ACF (Admisión Confirm) y ARJ (Admission Reject).
- Control de ancho de banda: el GKR es notificado con el ancho de banda necesario para el
establecimiento de la comunicación entre terminales, en función de los codificadores seleccionados.
- Gestión de una zona: el GKR debe proporcionar las funciones anteriores a los terminales, MCUs y
gateways que se han registrado con él.
Opcionalmente, el GKR debe implementar: señalización de llamada y autorización de la llamada.
En la primera versión de la recomendación, las funciones que debía realizar el GKR eran mucho más reducidas
y han ido incluyéndose según las necesidades del sistema H.323. La tarificación es una de las funciones que
no se podrían introducir en un escenario H.323 sin la presencia de un GKR o de otro componente adicional.
El GKR permite que los clientes sean más sencillos a la hora de implementar los servicios suplementarios ya
que toda la complejidad reside en él. Podemos implementar nuevos servicios sin necesidad de obligar a todos
los usuarios a modificar sus clientes.
Otra ventaja es que un usuario puede conectarse en varias máquinas con el mismo alias. De
esta forma no necesitas saber la dirección IP o el teléfono del trabajo, de casa,... del usuario
con el que quieres hablar, basta con conocer el alias.
10
11. DESARROLLO DE SERVICIOS AVANZADOS DE VOZ
SOBRE REDES DE PAQUETES
A la hora de desarrollar servicios sobre VoIP se vio la necesidad de introducir un GKR en la plataforma del
proyecto y se buscaron varios entornos de desarrollo.
Entornos de desarrollo
Intentar programar los componentes desde la primera línea de código no parece una solución muy sencilla,
además de que nos llevaría mucho tiempo. Por esa razón, se buscaron distintos entornos de desarrollo. El
objetivo era encontrar un cliente y un GKR con la funcionalidad básica para luego añadir el código necesario
para desarrollar servicios adicionales.
Varios son los fabricantes que ofrecen estos entornos de desarrollo. En el caso de entornos de desarrollo de
libre distribución, la selección más adecuada en función de la funcionalidad proporcionada, dinamicidad y
disponibilidad de código para plataformas tipo Linux y tipo Windows lo constituyen el proyecto OpenH323 y
Opengatekeeper.
Estas dos organizaciones proporcionan código escrito en C++ para el desarrollo de los componentes de un
escenario H.323. Actualmente, se han desarrollado clientes, gateways y gatekeeper.
El proyecto OpenH323 pretende crear una implementación completa del protocolo para
teleconferencia ITU H.323 que pueda ser utilizada sin cargo tanto por desarrolladores como por
usuarios comerciales.
OpenH323 se coordina por una compañía australiana, Equivalence Pty Ltd, pero está abierto. OpenH323
ofrece las librerías PWLib DLL compuestas por una serie de clases que facilitan la programación. El código
de Openh323 incluye clases que implementan los mensajes definidos en las recomendaciones H.225.0, H.245
y H.235 además de proporcionar el soporte para la transmisión de audio y vídeo (codificadores, rtp,...).
OpenGatekeeper da soporte a todas las características básicas de un gatekeeper H.323 como registro,
admisión, traducción de direcciones y control y monitorización de ancho de banda.
11
12. DESARROLLO DE SERVICIOS AVANZADOS DE VOZ
SOBRE REDES DE PAQUETES
Además, da soporte a otras características avanzadas como:
- Llamadas encaminadas por el GKR (soporte de método indirecto)
- Soporte de los alias definidos en H.323v2 (party_number, URL, transport_id y email_address).
- Creación de ficheros log de registro y llamada.
- Base de datos de GKRs vecinos.
- Registro del tiempo de vida.
En este sentido los desarrollos realizados en el seno del proyecto PISCIS han sido enviados a estas
organizaciones para contribuir como desarrolladores de los componentes H.323.
Servicios de valor añadido
Como puede verse, el código implementa las funciones obligatorias del GKR así como alguna de las
opcionales.
Tras un periodo de tiempo para tomar contacto con el código. Hemos intentado introducir algunas de las
funciones que nos han parecido más interesantes y más útiles en un nuestra plataforma PISCIS.
La funcionalidad introducida ha sido:
- Control de acceso: permite discriminar los terminales que tienen acceso al servicio a través de la
negación de registro en el GKR. De esta forma, podemos controlar que terminal puede o no utilizar
el servicio de VoIP.
- Autorización de llamadas: permite controlar quién puede realizar las llamadas y quién puede
recibirlas. Por ejemplo, si no quieres recibir llamadas de un usuario determinado o no quieres recibir
llamadas durante un cierto tiempo pero sí realizarlas, el GKR permite que sea posible.
- Grupo de salto: asociamos un alias a distintos terminales de forma que si uno de ellos está ocupado
pueda contestar otro terminal libre. Permite implementar, por ejemplo, un servicio de Hot Line o
Help Desk
12
13. DESARROLLO DE SERVICIOS AVANZADOS DE VOZ
SOBRE REDES DE PAQUETES
- Buzón de voz - correo electrónico: permite a los usuarios apuntarse a este servicio de forma que si
no contestan a una llamada, se les mandará un e-mail a la dirección de correo electrónico fijada por
ellos. Este mensaje contendrá un fichero de voz con una grabación del usuario que ha realizado la
llamada. Es un servicio similar al contestador automático.
La principal dificultad encontrada a la hora de introducir nueva funcionalidad al gatekeeper es encontrar el
método exacto que hay que extender y el formato de los datos (por ejemplo, las direcciones y los alias) ya
que son formatos definidos en las librerías PWLib y Openh323. Por esa razón, se empezó implementando
servicios sencillos como los dos primeros que añaden, simplemente, seguridad al escenario.
Una vez implementados los servicios mencionados, se ha instalado el nuevo GKR en la plataforma
PISCIS y se han realizado pruebas locales y de interconexión comprobando la utilidad de las
nuevas funciones en la misma. Actualmente, la plataforma se encuentra activa con el GKR
operativo.
Control de acceso
Permite al propietario de la red controlar el acceso a la misma. Impide el registro con el gatekeeper con lo
que también impide el uso de cualquiera de sus funciones.
La implementación de esta función consiste en leer de un fichero cada cierto tiempo y guardar el contenido
del fichero en una tabla de alias. Esta tabla pasa a formar parte del entorno del GKR. De esa forma, es
accesible desde cualquier clase. Cada vez que un usuario se registra, comprobamos que puede hacerlo
mirando la tabla de alias.
Autorización de llamadas
Se basa en la existencia de listas que contienen el alias de los equipos. Hasta ahora, se han
contemplado las siguientes listas: usuarios a los que no se les permite realizar llamadas, usuarios
a los que no se les permite recibir llamadas y parejas de equipos que no pueden establecer una
comunicación.
13
14. DESARROLLO DE SERVICIOS AVANZADOS DE VOZ
SOBRE REDES DE PAQUETES
Para implementar estas listas, utilizamos un fichero de texto en el que guardamos las parejas que no pueden
establecer conexiones. Igual que para el control de acceso, introducimos los alias en listas que pasan a
formar parte del entorno del GKR.
Cuando se recibe una petición de admisión para realizar una llamada (ARQ) se comprueban las listas
aceptando o rechazando la misma en función de la información allí contenida.
Grupo de salto
Cada servicio tiene asociado un grupo de alias que puede ser un número E.164 o un identificador
H.323. Dado que el escenario incluye pasarelas que permiten realizar llamadas con teléfonos
convencionales, los alias serán números E.164 para que sean accesibles desde todos los
terminales.
La implementación permite que una serie de terminales contesten a la llamada para un mismo alias. Por
ejemplo, tenemos un servicio para dar información sobre el tráfico (200). Cuando el usuario llame a ese
número el GKR internamente le va a redirigir a uno de los terminales pertenecientes a este servicio que esté
libre o le indicará que están todos ocupados. Además de tener asociado un servicio, los terminales son
accesibles desde el exterior independientemente siempre que no estén ocupados.
La implementación actual de este servicio lee periódicamente de un fichero la información sobre las tres
funciones anteriores. Sin embargo, se puede modificar el código para incluir bases de datos, solución más
apropiada.
Los pasos seguidos para implementar esta funcionalidad son:
- Permitir que dos endpoints en la tabla EndpointTable tengan el mismo alias.
- Hacer rotación de terminales con el mismo alias para encontrar uno libre.
- Controlar si un terminal está libre o no.
- Partiendo de una lista de terminales asociados a un servicio, añadir al array de alias de un terminal
el alias del servicio al que está asociado.
- Servicios privados y públicos: no se permite que ningún terminal se registre con el nombre del servicio
privado.
14
15. DESARROLLO DE SERVICIOS AVANZADOS DE VOZ
SOBRE REDES DE PAQUETES
Buzón de voz - correo electrónico
Esta nueva función añadida al GKR es un servicio suplementario no incluido en las
recomendaciones H.450.x. Es un servicio que se ofrece a los usuarios, similar a un contestador
automático o a un buzón de voz.
Para implementar el buzón de voz ha sido necesario modificar los clientes ya que se necesita información
adicional a la proporcionada (dirección de correo electrónico). Sin embargo, no se modifica el protocolo de
señalización con lo que un cliente que no tenga la modificación puede seguir utilizando el GKR.
El objetivo de este servicio es que un usuario que pertenece a él reciba en la dirección de correo electrónico
que decida un e-mail. Este mensaje contiene una grabación con el mensaje dejado por el usuario que realizó
la llamada para él.
Cuando alguien llama a un usuario apuntado en este servicio, el GKR indica en el mensaje de ACF que va a
encaminar también la señalización H.225.0. Si no se contesta la llamada en un tiempo determinado, el GKR
desvía la llamada a un cliente especial (buzón de voz). Para ello, se lanza un timer cuando llega el mensaje
Alerting y se sigue la recomendación H.450.3 de desvío de llamada.
El buzón de voz reproduce una grabación indicando que se puede grabar un mensaje para el usuario que no
contestó a la llamada. Se realiza la grabación, se guarda en un fichero y se manda en un e-mail al usuario
destino.
Los usuarios se dan de alta y baja en el servicio realizando una llamada a un número predeterminado. Si el
usuario se apunta, el GKR manda un mensaje de petición de información (IRR) al cliente para que éste le
conteste con su dirección de correo. El GKR guarda esta información en tablas que vuelca periódicamente a
ficheros para evitar perder esta información en caso de caída del GKR.
Conclusiones
La evolución de la tecnología de transmisión de Voz sobre redes de paquetes presenta a medio
plazo un ámbito en gran crecimiento motivado por la adopción de este modelo en la evolución
de la futura tecnología UMTS, así como la incorporación cada vez mayor en ámbitos corporativos,
como solución competitiva en coste, calidad y complejidad frente a las actuales redes
conmutadas.
15
16. DESARROLLO DE SERVICIOS AVANZADOS DE VOZ
SOBRE REDES DE PAQUETES
En este ámbito el proyecto de investigación PISCIS ha realizado distintos desarrollos de servicios avanzados
que posteriormente han sido probados en la plataforma piloto PISCIS. Para el desarrollo de estos servicios se
ha utilizado el entorno de desarrollo de libre distribución OpenGatekeeper.
Calidad de servicio
QoS o Calidad de Servicio (Quality of Service, en inglés) son las tecnologías que garantizan la transmisión de
cierta cantidad de datos en un tiempo dado (throughput). Calidad de servicio es la capacidad de dar un buen
servicio.
EN RESUMEN
OpenH323 se coordina por una compañía australiana, Equivalence Pty Ltd, pero está abierto.
OpenH323 ofrece las librerías PWLib DLL compuestas por una serie de clases que facilitan la
programación.
El código de Openh323 incluye clases que implementan los mensajes definidos en las
recomendaciones H.225.0, H.245 y H.235 además de proporcionar el soporte para la transmisión
de audio y vídeo (codificadores, rtp,...). OpenGatekeeper da soporte a todas las características
básicas de un gatekeeper H.323 como registro, admisión, traducción de direcciones y control y
monitorización de ancho de banda.
16