Desarrollo de Servicios Avanzados de Voz sobre redes de Paquetes

M Carmen Bartolom 1, Raquel Panadero1, Carlos Garca1, Jos Ignacio Moreno1, David Fernndez2
1

Departamento de Ingeniera Telemtica

Universidad Carlos III de Madrid
Avda. de la Universidad 30
28911 Legans (MADRID)

Departamento de Ingeniera Telemtica

ETSI Telecomunicacin
Universidad Politcnica de Madrid
Ciudad universitaria sn
28040 Madrid

E-mail: {cbc, rpa, cgarcia, jmoreno}@it.uc3m.es

e-mail: david@dit.upm.es

Abstract. During last years, voice transport over packet-switched networks has experimented great
growth due to the development of standards as well as to the appearance of products based on IP
technology. In this scope, this article will introduce the different technologies of Voice over IP (VoIP)
transport emphasizing the H.323 protocol because of its popularity. Later, PISCIS project is
described and we will present our group experience implementing new services based on a key
component of the H.323 protocol, the gatekeeper, based on free licence software OpenH323 which
have been fully tested in a pilot H.323 network provided by PISCIS.

1 Introduccin
La transmisin de trfico de voz sobre redes de
paquetes ha experimentado grandes avances en los
ltimos aos tanto por el desarrollo de estndares
como por la aparicin de productos basados en
tecnologa IP. A medio plazo esta tecnologa se
vislumbra prometedora motivada por su utilizacin
en redes mviles de tecnologa UMTS. La
evolucin de la release 99 [1] hacia la release 4 y 5
[2] incluye el salto de tecnologa de transmisin de
voz tradicional hacia tecnologas de transmisin 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 artculo introduce las
distintas tecnologas de transmisin de VoIP
actualmente estandarizadas, as como la experiencia
del grupo en el desarrollo de servicios para el caso
de utilizar el protocolo H.323 [3], protocolo que por
motivos histricos, la primera versin apareci en
el ao 1996, presenta un mayor numero de
productos en el mercado. Este trabajo ha sido
desarrollado dentro del proyecto de investigacin
PISCIS:Plataforma Piloto de Servicios de
Comunicaciones sobre Internet de Servicios
Integrados. [4]
La integracin 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 tecnologa
de red sobre la que se basaban. Ejemplos de estos
servicios son servicios de localizacin, grupos de
salto, transmisin de vdeo, integracin de buzn de
voz y correo electrnico, fax, autenticacin control
de acceso y seguridad

Durante los primeros pasos de esta tecnologa se

fij como aspecto diferenciador, respecto a la
tecnologa clsica de transmisin basada en
circuitos, los aspectos relacionados con el coste,
especialmente en entornos corporativos donde
existe una red de datos, tpicamente propiedad de la
propia organizacin y una red telefnica,
normalmente contratada a uno o varios operadores
con facilidades de grupo cerrado de usuarios,
numeracin reducida, etc. Sin embargo la reduccin
de los precios del mercado motivada por la
aparicin de la competencia en el mismo, junto con
la falta de soluciones que garanticen de un modo
eficiente calidad para la transmisin sobre redes de
datos, han provocado que esta tecnologa no haya
tenido el xito esperado por las primeras
previsiones. Hasta ahora existen distintos ejemplos
tanto de operadores que han apostado por esta
tecnologa 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
tcnicas
para
permitir
el
encaminamiento de trfico telefnico a travs de la
pasarela ms adecuada (menor coste) de un modo
dinmico y adaptativo. Las previsiones de
despliegue segn un estudio de Lucent-Dataquest
muestran que existir una importante demanda
provocada especialmente por entornos corporativos
(figura 1).
Los escenarios de aplicacin de VoIP permiten la
comunicacin de usuarios de tres modos distintos
en funcin del terminal utilizado:

PC-PC: en el caso de utilizar terminales tipo

PC o equivalente interconectados mediante una
red de datos

ECU M
3500
3000
2500
VoInternet

2000

VoPrivate IP
1500

VoFR
VToA

1000
500

Source: Lucent, Dataquest

0
1997

1998

1999

2000

2001

2002

2003

Figura 1: Previsiones de evolucin de VoPKT

en Europa

Telfono-Telfono: en el caso de utilizar

terminales tradicionales. En este caso, para la
interconexin de los mismos se utiliza un
backbone IP y dispositivos que permiten
interconectar las centralitas tradicionales con la
red IP (Gateways).
Telfono-PC: en el caso de interconectar
usuarios conectados a redes de datos y redes
telefnicas tradicionales.

Estos entornos se diferencian en la complejidad, el

coste y el equipamiento necesario. La ms fcil y
barata es la comunicacin PC-PC. Cada PC necesita
una tarjeta de sonido, un micrfono y un altavoz. Si
utilizamos telfonos tradicionales, la complejidad y
el coste son mayores porque se necesita una
gateway, adems de la harmonizacin de
direcciones IP-E-164. La tercera opcin es la ms
compleja. Se necesita una gateway y adems un
software compatible con ella.
En todos los casos, la necesidad de transmisin en
tiempo real, obliga a la utilizacin 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 tcnicas basadas en los modelos de
DiffServ [5] e IntServ [6] sobre los que se est
trabajando actualmente.
En este mbito, la siguiente seccin muestra los
distintos protocolos de sealizacin utilizados en
VoIP centrndose en H.323 por las razones antes
mencionadas. A continuacin, 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.

2 Protocolos
VoIP

de sealizacin en

Diversos organismos trabajan en la normalizacin

del servicio de VoIP. Los ms importantes son el
ITU-T y el IETF. El ITU-T fue pionero en este
sentido, produciendo en 1996 la primera versin de
la recomendacin H.323, que es considerada un

paraguas de normas que aglutinan distintos

mecanismos de sealizacin para la transmisin de
trfico multimedia sobre redes de paquetes
(H.225.0, H.245, T.120, ...). El IETF a travs de
grupo MMUSIC, estandariz tres aos ms tarde
otro protocolo de sealizacin denominado SIP
(Session Initial Protocol) [7] que actualmente est
siendo debatida su adopcin como estndar para la
transmisin de voz en redes UMTS (release 5).
pensado especficamente para VoIP. La estructura
de un escenario SIP es prcticamente la misma en
cuanto a los elementos funcionales a la ofrecida por
H.323. La principal diferencia con es su
simplicidad. SIP hace en una transaccin lo que
H.323 haca mediante cuatro o cinco intercambios
de mensajes, cada uno de ellos especificado en un
documento distinto del ITU-T. Por esta razn tiene
un tiempo de establecimiento menor.
Junto a estas dos soluciones, existe una tercera
denominada MGCP, MEGACO o H.248. Esta
nueva norma establece el protocolo de sealizacin
entre una pasarela o Media Gateway en
terminologa MGCP y un servidor de llamadas o
Media Gateway Controler. La norma originalmente
propuesta por el IETF en 1998 (MGCP) [8] y que
integraba soluciones de distintos fabricantes, ha
evolucionado hacia el protocolo MEGACO [9],
definida por el IETF en septiembre de 1999 y
adoptada por el ITU-T en la norma H.248 en
Febrero de 2000 [10].

2.1 H.323
Los fabricantes de productos de comunicacin se
han visto atrados por esta tecnologa desde 1996
cuando se gener la H.323v1. Empresas como
Lucent Technologies, Cisco, Teldat, NetSpeak, y
NetPhone, han introducido productos VoIP basados
en este estndar. El lder del mercado, Microsoft,
tiene el producto software ms utilizado para el
soporte de VoIP (NetMeeting), ya que viene
integrado en el paquete de aplicaciones de
Windows. Quizs por esta razn sea el estndar
para VoIP ms utilizado.
La recomendacin 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 vdeo, es independiente de la topologa de red
y ofrece interoperabilidad con terminales de la serie
H (H.320, H.322, ...) a travs de pasarelas o
gateways.
Un sistema H.323 est formado por los siguientes
elementos: terminales, gateways, gatekeepers, y
MCUs (Unidad de control Multipunto). En los
prrafos siguientes procedemos a explicar cada uno
de estos componentes con detalle.

Video I/O equip.

Audio I/O equip.

User Data Appl.

T.120, etc.

Video Codec
H.261, H.263
Audio Codec

(Setup, Alerting,...) que va por el canal de

sealizacin de llamada. En este caso se utiliza
un
subconjunto
de
las
funciones
proporcionadas por la Q.931.

Receive
Path
delay

G.711, G.722, G.723,

G,728, G.729

H.225.0
System Control

Local
Area
Network
Interface

H.245 [12]: Sealizacin de control extremo a

extremo. La funcin principal es el intercambio
de capacidades entre los terminales H.323
previa a la transmisin de informacin.

H.235 [13]: trata sobre la seguridad en la

comunicacin incluyendo autentificacin,
autorizacin, control de llamada seguro y
privacidad de los canales de voz

H.450 [14]: sealizacin para el control de

todos los servicios suplementarios (desvo de
llamada, llamada en espera,...)

H.245 Control
System Control
User Interface

Call Control
H.225.0 (Q.931)

RAS Control
H.225.0

Figura 2: Estructura de un Terminal H.323

El terminal H.323 proporciona comunicacin
bidireccional en tiempo real con otro terminal,
gateway o MCU. La informacin intercambiada
consiste en: control, indicaciones, audio, vdeo y
datos. Los terminales H.323 deben al menos
soportar la transmisin de audio, si bien existen
otras combinaciones posibles como: audio ms
datos, audio ms video y audio ms video ms
datos. La estructura de un terminal H.323 se
muestra en la figura 2.
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
vdeo y las aplicaciones de datos son opcionales.

La arquitectura de protocolos utilizada por H.323 es

la mostrada en la figura 3.
Una llamada H.323 puede dividirse en tres fases en
relacin con los protocolos de sealizacin que
intervienen en la misma:
-

RAS (Registro Autenticacin 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 telfono del usuario con
el que quiere comunicarse). El GKR puede dar
permiso para la llamada con un ACF
(Admission Confirm) que contiene la direccin
de transporte asociada al alias destino o su
propia direccin de transporte si decide
encaminar la sealizacin H.225.0. El GKR
puede tambin denegar la llamada con un ARJ
(Admission Reject) dando la razn 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: traduccin
de direcciones, autorizacin de llamada y
gestin del ancho de banda.

H.225.0: Es un subconjunto de mensajes del

protocolo de sealizacin Q.931 de RDSI.

El gateway permite la comunicacin entre

terminales H.323 y terminales ITU conectados a
otras redes. Soporta conversin de formatos de
transmisin transcodificacin- (por ejemplo
H.225.0 a/desde H.221) y procedimientos de
comunicacin (a/desde H.245 a H.242) adems de
establecimiento y liberacin de llamada en ambos
lados. El gateway no es necesario para establecer
una comunicacin entre dos terminales H.323.
El gatekeeper soporta traslacin de direcciones,
control de acceso, control de ancho de banda y
gestin 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 y se
tratar en detalle en el apartado 4.
La MCU soporta la comunicacin 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 conmutacin de audio y vdeo.
Este ltimo es opcional ya que esta funcionalidad
puede residir en cada uno de los terminales,.

Control

Datos

Audio

G.7xx H.26x
H.225.0 H.245 T.120

Los protocolos de sealizacin ms importantes

utilizados en el seno de la H.323 son:
H.225.0 [11]: Define la sealizacin entre
terminales/gateways y gatekeeper (RAS).
Tambin define la sealizacin para
establecimiento y liberacin de la llamada

Control

Gatekeeper
Regist.
RTCP Admision
Status
(RAS)

RTP

TCP/UDP v3

Vdeo A/V Ctrl

UDP
IP

Figura 3. Arquitectura de Protocolos en H.323

Proporciona una conexin lgica entre los dos

terminales. En las primeras versiones de la
norma, H.225.0 se implementaba sobre TCP
pero a partir de la versin 3 existe la
posibilidad de utiliza UDP por problemas de
retardo.
-

110
ARQ ( destino=210)

ACF ( dir transporte=Y.Y.Y.Y:X)

Alerting
Connect

Release Complete
DRQ

Un ejemplo de una llamada H.323 puede verse en la

figura 4.
Los paquetes de audio y vdeo se transmiten sobre
UDP, por lo que pueden desordenarse, perderse o
retrasarse. Por esta razn 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
recepcin. El protocolo RTCP (RTP Control
Protocol) se usa junto con RTP y permite cierta
realimentacin sobre la calidad recibida.
Para intentar mejorar la calidad de servicio en los
streams de audio y vdeo, 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 sealizacin H.225.0 y H.245 puede
encaminarse por el GKR o no en funcin de que se
utilice el denominado modelo directo o indirecto. Si
el GKR intercepta todos los mensajes de
sealizacin puede realizar gestin de las llamadas
manteniendo una tabla con las llamadas activas, el
estado de los terminales, etc.
Por tanto, para establecer una comunicacin H.323
se abren 3 canales de sealizacin (H.225.0, H.245
y RAS) ms los canales lgicos de audio, vdeo y
datos.
Uno de los mayores problemas de H.323 es elevado
retardo de establecimiento de llamadas. Con objeto
de mejorar la eficiencia, a partir de la versin 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.

3 Proyecto PISCIS
El proyecto PISCIS: Plataforma Piloto de Servicios
de Comunicaciones sobre Internet de Servicios
Integrados es un proyecto de investigacin nacional
que trabaja en la problemtica de la transmisin de
voz sobre redes de paquetes.

210

ACF ( dir transporte=X.X.X.X:Y)

Setup
ARQ ( destino=110)

H.245: Tan pronto como acaba la fase anterior,

los dos terminales intercambian sus
capacidades. Se ponen de acuerdo en el tipo de
informacin que van a mandar.

Despus de estas tres fases, se abren los canales

lgicos entre los dos terminales de acuerdo con las
capacidades intercambiadas y la comunicacin
multimedia comienza.

GKR

DCF

DRQ
DCF

Figura 4. Ejemplo de sealizacin H.323

El objetivo del proyecto PISCIS es el desarrollo de
una plataforma de experimentacin de red que
permite soportar la prestacin 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
investigacin de la Universidad Politcnica de
Madrid, Universidad de Sevilla y Universidad
Carlos III de Madrid y cuenta con la colaboracin
de las empresas Teldat como fabricante de equipos
y SuperCable y CyC como operadores de red.
Los objetivos del proyecto sobre los que ms se ha
trabajado son el despliegue de una red piloto que
interconecte las tres universidades utilizando
tcnicas de transmisin de VoIP que permitan
probar la utilidad de los servicios de red
desarrollados.
En esta lnea, se mantiene activa una plataforma
entre las tres universidades. El escenario tipo de
cada una de ellas sigue el esquema de la figura 5.
Cada escenario cuenta con PCs con software
especfico (NetMeeting, OpenPhone, ...), una
pasarela
Teldat
para
conectar
telfonos
tradicionales y una lnea telefnica conectada a la
misma pasarela para poder cursar llamadas
desde/hacia la Red Telefnica Conmutada (RTC).
Durante el ao 2000, han montado las tres redes
obteniendo una plataforma estable cuyo aspecto es
el de la figura 6 y se han realizado pruebas de
interconexin entre ambas con unos resultados
satisfactorios.
Tras las pruebas de conectividad bsica inicial se
decidi utilizar la funcionalidad de un gatekeeper
para ofrecer servicios de valor aadido como son: la
funcin de directorio, el control de acceso, el
soporte de servicios de Help Desk o grupo de salto,
la coordinacin con mecanismos de calidad de
servicio y el desarrollo de pasarelas de buzn de
voz-email, funciones que se describirn en los
siguientes apartados.

GKR

PC
multimedia

207

206

205

PC
multimedia

PC
multimedia

Ethernet

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

sealizacin de llamada y autorizacin de la
llamada.

214
GW

RTC

GW

RDSI

211

212

201

Figura 5. Escenario tipo pruebas locales

4 Desarrollo de Servicios en redes

VoIP
Como ya se ha comentado en apartados anteriores,
el gatekeeper (GKR) es un componente que
inicialmente se consider opcional en el modelo,
debido a la aparicin en el mercado de terminales
que podan 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 ms que un juguete. Las funciones que
dicho elemento debe realizar son al menos:
-

Funcin de Registro: Los terminales al

arrancar deben registrase en el GKR (alias,
direccin IP, puerto).

Traduccin de direcciones: el GKR debe

traducir los alias a direcciones de transporte
(IP+puerto). La traduccin se hace usando una
tabla actualizada con los mensajes de registro.

Control de admisin: el GKR controla el

acceso a la red mediante los mensajes H.225.0
ARQ (Admission Request), ACF (Admission
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 comunicacin
entre terminales , en funcin de los
codificadores seleccionados.
GKR

GW

Ethernet UC3M
GW

Ethernet US

Internet

GW

Ethernet UPM

RTC

Figura 6. Escenario de interconexin

En la primera versin de la recomendacin, las

funciones que deba realizar el GKR eran mucho
ms reducidas y han ido incluyndose segn las
necesidades del sistema H.323. La tarificacin es
una de las funciones que no se podran introducir en
un escenario H.323 sin la presencia de un GKR o
de otro componente adicional. El GKR permite que
los clientes sean ms 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 mquinas con el mismo alias. De esta forma
no necesitas saber la direccin IP o el telfono del
trabajo, de casa,... del usuario con el que quieres
hablar, basta con conocer el alias.
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.

4.1 Entornos de desarrollo.

Intentar programar los componentes desde la
primera lnea de cdigo no parece una solucin
muy sencilla, adems de que nos llevara mucho
tiempo. Por esa razn, se buscaron distintos
entornos de desarrollo. El objetivo era encontrar un
cliente y un GKR con la funcionalidad bsica para
luego aadir el cdigo necesario para desarrollar
servicios adicionales.
Varios son los fabricantes que ofrecen estos
entornos de desarrollo. En el caso de entornos de
desarrollo de libre distribucin, la seleccin ms
adecuada en funcin de la funcionalidad
proporcionada, dinamicidad y disponibilidad de
cdigo para plataformas tipo Linux y tipo Windows
lo constituyen el proyecto OpenH323 y
Opengatekeeper.
Estas dos organizaciones proporcionan cdigo
escrito en C++ para el desarrollo de los
componentes de un escenario H.323. Actualmente,
se han desarrollado clientes, gateways y
gatekeeper. El cdigo y los ejecutables estn
disponibles en [15] y [16].
El proyecto OpenH323 pretende crear una
implementacin completa del protocolo para
teleconferencia ITU H.323 que pueda ser utilizada

sin cargo tanto por desarrolladores como por

usuarios comerciales.

4.2 Servicios de valor aadido.

OpenH323 se coordina por una compaa

australiana, Equivalence Pty Ltd, pero est abierto.

Como puede verse, el cdigo implementa las

funciones obligatorias del GKR as como alguna de
las opcionales.

OpenH323 ofrece las libreras PWLib DLL

compuestas por una serie de clases que facilitan la
programacin.

Tras un periodo de tiempo para tomar contacto con

el cdigo. Hemos intentado introducir algunas de
las funciones que nos han parecido ms interesantes
y ms tiles en un nuestra plataforma PISCIS.

El cdigo de Openh323 incluye clases que

implementan los mensajes definidos en las
recomendaciones H.225.0, H.245 y H.235 adems
de proporcionar el soporte para la transmisin de
audio y vdeo (codificadores, rtp, ...).
OpenGatekeeper da soporte a todas las
caractersticas bsicas de un gatekeeper H.323
como registro, admisin, traduccin de direcciones
y control y monitorizacin de ancho de banda.
Adems, da soporte
avanzadas como:

otras

Llamadas encaminadas por

(soporte de mtodo indirecto)

Soporte de los alias definidos en H.323v2

(party_number, URL, transport_id y
email_address).

Creacin de ficheros log de registro y

llamada.

Base de datos de GKRs vecinos.

Registro del tiempo de vida.

el

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.

MulticastThread
opengate
CallThread
1
n
SignallingThread
PRasLog
RasThread
n

CallTable
1

1
n

n
TimeToLiveEntry

control de acceso: permite discriminar los

terminales que tienen acceso al servicio a
travs de la negacin de registro en el GKR. De
esta forma, podemos controlar que terminal
puede o no utilizar el servicio de VoIP.

autorizacin de llamadas: permite controlar

quin puede realizar las llamadas y quin
puede recibirlas. Por ejemplo, si no quieres
recibir llamadas de un usuario determinado o
no quieres recibir llamadas durante un cierto
tiempo pero si 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

buzn de voz - correo electrnico: 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 direccin de correo
electrnico fijada por ellos. Este mensaje
contendr un fichero de voz con una grabacin
del usuario que ha realizado la llamada. Es un
servicio similar al contestador automtico.

GKR

El diagrama de clases de esta distribucin se

muestra en la fig. 7.

Endpoint

caractersticas

EndpointTable
1
1

La funcionalidad introducida ha sido:

RasServer
n

CallDetails

Figura 7. Diagrama de clases del gatekeeper

La principal dificultad encontrada a la hora de

introducir nueva funcionalidad al gatekeeper es
encontrar el mtodo 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 libreras PWLib y Openh323. Por
esa razn, se empez implementando servicios
sencillos como los dos primeros que aaden,
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
interconexin comprobando la utilidad de las
nuevas funciones en la misma. Actualmente, la
plataforma se encuentra activa con el GKR
operativo.
A continuacin vamos a comentar como se han
implementado cada una de estas nuevas funciones.

4.2.1 Control de acceso

modificar el cdigo para incluir bases de datos,

solucin ms apropiada.

Permite al propietario de la red controlar el acceso a

la misma. Impide el registro con el gatekeeper con
lo que tambin impide el uso de cualquiera de sus
funciones.

Los pasos seguidos

funcionalidad son:
-

Permitir que dos endpoints en la tabla

EndpointTable tengan el mismo alias.

La implementacin de esta funcin 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.

Hacer rotacin 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, aadir al array de Alias de un
terminal el alias del servicio al que est
asociado.

Servicios privados y pblicos: no se permite

que ningn terminal se registre con el nombre
del servicio privado.

4.2.2 Autorizacin 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
comunicacin.
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 peticin de admisin para
realizar una llamada (ARQ) se comprueban las
listas aceptando o rechazando la misma en funcin
de la informacin all contenida.

4.2.3 Grupo de salto.

Cada servicio tiene asociado un grupo de alias que
pueden ser un nmero E.164 o un identificador
H.323. Dado que el escenario incluye pasarelas que
permiten realizar llamadas con telfonos
convencionales, los alias sern nmeros E.164 para
que sean accesibles desde todos los terminales.
La implementacin permite que una serie de
terminales contesten a la llamada para un mismo
alias. Por ejemplo, tenemos un servicio para dar
informacin sobre el trfico (200). Cuando el
usuario llame a ese nmero el GKR internamente le
va a redirigir a uno de los terminales pertenecientes
a este servicio que est libre o le indicar que estn
todos ocupados.
Adems de tener asociado un servicio, los
terminales son accesibles desde el exterior
independientemente siempre que no estn
ocupados.
La implementacin actual de este servicio lee
peridicamente de un fichero la informacin sobre
las tres funciones anteriores. Sin embargo, se puede

para

implementar

esta

4.2.4 Buzn de voz - correo electrnico

Esta nueva funcin aadida el 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 automtico o a un buzn de
voz.
Para implementar el buzn de voz ha sido
necesario modificar los clientes ya que se necesita
informacin adicional a la proporcionada (direccin
de correo electrnico). Sin embargo, no se modifica
el protocolo de sealizacin con lo que un cliente
que no tenga la modificacin puede seguir
utilizando el GKR.
El objetivo de este servicio es que un usuario que
pertenece a l reciba en la direccin de correo
electrnico que decida un e-mail. Este mensaje
contiene una grabacin 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 tambin la sealizacin H.225.0. Si
no se contesta la llamada en un tiempo
determinado, el GKR desva la llamada a un cliente
especial (buzn de voz). Para ello, se lanza un timer
cuando llega el mensaje Alerting y se sigue la
recomendacin H.450.3 de desvo de llamada que
se muestra en la figura 8.
El buzn de voz reproduce una grabacin indicando
que se puede grabar un mensaje para el usuario que
no contest a la llamada. Se realiza la grabacin, 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
nmero
predeterminado. Si el usuario se apunta, el GKR
manda un mensaje de peticin de informacin
(IRR) al cliente para que ste le conteste con su

Referencias
origen

GKR
destino
Setup
Setup
Call Proceeding
Alerting
Alerting
Expira el
timer
Setup

buzn de voz

ARQ
ACF
Alerting
Release Complete
Connect

Connect

Figura 8. Desvio de llamada

direccin de correo. El GKR guarda esta
informacin en tablas que vuelca peridicamente a
ficheros para evitar perder esta informacin en caso
de cada del GKR.

5 Conclusiones
La evolucin de la tecnologa de transmisin de
Voz sobre redes de paquetes presente a medio plazo
un mbito en gran crecimiento motivado por la
adopcin de este modelo en la evolucin de la
futura tecnologa UMTS, as como la incorporacin
cada vez mayor en mbitos corporativos, como
solucin competitiva en coste, calidad y
complejidad frente a las actuales redes conmutadas.
En este artculo se han presentado los protocolos de
sealizacin estandarizados para la provisin del
servicio de VoIP, centrndose en el protocolo
H.323 por su madurez y disponibilidad de equipos
comerciales. De la arquitectura del mismo, destaca
el GateKeeper, elemento clave de la arquitectura
para la provisin de servicios.
En este mbito el proyecto de investigacin 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 distribucin OpenGatekeeper.

[1] 3GPP TS 23.002 v3.3.0: Network Architecture

(Release 1999), Marzo 2000.
http://www.3gpp.org
[2] 3GPP TS 23.002 v.5.0.0: Network Architecture
(Release 5), octubre 2000
[3] ITU-T H.323: Packet-based Multimedia
Communications Systems, noviembre 2000
[4] http://matrix.it.uc3m.es/piscis
[5] S. Blake et al, An Arquitecture for
Differentiated Services, IETF 2475, diciembre
1998, http://www,ietf.org/rfc/rfc2475.txt
[6] http://www.ietf.org/html.charters/intservcharter.html
[7] M. Handley et al, SIP: Session Initiation
Protocol, IETF 2543, marzo 1999
http://www.ietf.org/rfc/rfc2543.txt
[8] M. Arango et al, Media Gateway Control
Protocol (MGCP), IETF 2705, octubre 1999
http://www.ietf.org/rfc/rfc2705.txt
[9] F. Cuervo, N. Greene, A. Rayhan et al,
Megaco Protocol Version 1.0, IETF 3015,
noviembre 2000,
http://www.ietf.org/rfc/rfc3015.txt
[10] ITU-T H.248: Gateway Control Protocol,
junio 2000
[11] ITU-T H.225.0: Call Signalling protocols and
media stream packetization for packet-based
multimedia communication, noviembre 2000
[12] ITU-T H.245: Control Protocol for
Multimedia Communications, febrero 2000.
[13] ITU-T H.235: Security and encryption for Hseries (H.323 and other H.245-based)
multimedia terminals, noviembre 2000
[14] ITU-T H.450.3: Call diversion suplementary
service for H.323, febrero 1998.
[15] OpenH323 project: http://www.openh323.org

Agradecimientos

[16] Opengatekeeper project:

http://OpenGatekeeper.sourceforge.net

Este trabajo ha sido realizado al amparo del

proyecto PISCIS del Plan Nacional de
Investigacin, programa FEDER.

[17] O. Hersent, D. Gurle & Jean-Pierre Petit, IP

Telephony: Packet-base multimedia
communications systems,Addison-Wesley,
2000

Los autores agradecen a la empresa Teldat S.A., la

colaboracin realizada en el desarrollo del proyecto
PISCIS, con la cesin de equipamiento de red
incorporado a la plataforma PISCIS.

[18] D. Collins, Voice Over IP, McGraw-Hill,

2001
[19] TELDAT. S.A. http://www.teldat.es