Servicios Avanzados de Voz
of 8
Transcript of Servicios Avanzados de Voz
-
7/26/2019 Servicios Avanzados de Voz
1/8
Desarrollo de Servicios Avanzados de Voz sobre redes de Paquetes
M Carmen Bartolom1, Raquel Panadero
1, Carlos Garca
1, Jos Ignacio Moreno
1, David Fernndez
2
1Departamento de Ingeniera Telemtica
Universidad Carlos III de Madrid
Avda. de la Universidad 30
28911 Legans (MADRID)
E-mail: {cbc, rpa, cgarcia, jmoreno}@it.uc3m.es
2Departamento de Ingeniera Telemtica
ETSI TelecomunicacinUniversidad Politcnica de Madrid
Ciudad universitaria sn28040 Madrid
e-mail: [email protected]
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 estndarescomo 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 devoz 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 lasdistintas 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 deproductos 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 depaquetes 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 devoz 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 reduccinde 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 deorganizaciones 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 desoluciones tcnicas para permitir el
encaminamiento de trfico telefnico a travs de lapasarela 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 unared de datos
-
7/26/2019 Servicios Avanzados de Voz
2/8
Telfono-Telfono: en el caso de utilizar
terminales tradicionales. En este caso, para la
interconexin de los mismos se utiliza unbackbone 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 redestelefnicas 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 yel coste son mayores porque se necesita una
gateway, adems de la harmonizacin de
direcciones IP-E-164. La tercera opcin es la mscompleja. Se necesita una gateway y adems un
software compatible con ella.
En todos los casos, la necesidad de transmisin entiempo 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 esttrabajando 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 de sealizacin en
VoIP
Diversos organismos trabajan en la normalizacindel 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 detrfico 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 estsiendo debatida su adopcin como estndar para latransmisin 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 queH.323 haca mediante cuatro o cinco intercambios
de mensajes, cada uno de ellos especificado en un
documento distinto del ITU-T. Por esta razn tieneun tiempo de establecimiento menor.
Junto a estas dos soluciones, existe una terceradenominada MGCP, MEGACO o H.248. Estanueva 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 losprrafos siguientes procedemos a explicar cada uno
de estos componentes con detalle.
0
500
1000
1500
2000
2500
3000
3500
1997 1998 1999 2000 2001 2002 2003
VoInternet
VoPrivate IP
VoFRVToA
ECU M
Source: Lucent, Dataque
Figura 1: Previsiones de evolucin de VoPKT
en Europa
-
7/26/2019 Servicios Avanzados de Voz
3/8
El terminal H.323 proporciona comunicacinbidireccional 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 existenotras combinaciones posibles como: audio msdatos, 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 devdeo y las aplicaciones de datos son opcionales.
El gateway permite la comunicacin entre
terminales H.323 y terminales ITU conectados a
otras redes. Soporta conversin de formatos detransmisin transcodificacin- (por ejemplo
H.225.0 a/desde H.221) y procedimientos decomunicacin (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 setratar 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,.
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
(Setup, Alerting,...) que va por el canal de
sealizacin de llamada. En este caso se utilizaun subconjunto de las funciones
proporcionadas por la Q.931.
H.245 [12]: Sealizacin de control extremo a
extremo. La funcin principal es el intercambiode 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 dellamada, llamada en espera,...)
La arquitectura de protocolos utilizada por H.323 esla mostrada en la figura 3.
Una llamada H.323 puede dividirse en tres fases en
relacin con los protocolos de sealizacin queintervienen 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 aliasdel 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 decideencaminar 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.
Video I/O equip.
Audio I/O equip.
User Data Appl.
T.120, etc.
System Control
User Interface
Video Codec
H.261, H.263
AudioCodecG.711, G.722, G.723,
G,728, G.729
System Control
H.245 Control
Call ControlH.225.0 (Q.931)
RAS ControlH.225.0
Receive
Path
delay
H.225.0
Local
Area
Network
Interface
Figura 2: Estructura de un Terminal H.323
IP
TCP/UDP v3 UDP
H.225.0 H.245 T.120
RTP
G.7xx H.26x
RTCP
Gatekeeper
Regist.
Admision
Status
(RAS)
Control Datos Audio Vdeo A/V Ctrl Control
Fi ura 3. Ar uitectura de Protocolos en H.323
-
7/26/2019 Servicios Avanzados de Voz
4/8
Proporciona una conexin lgica entre los dos
terminales. En las primeras versiones de lanorma, H.225.0 se implementaba sobre TCP
pero a partir de la versin 3 existe la
posibilidad de utiliza UDP por problemas de
retardo.
- H.245: Tan pronto como acaba la fase anterior,
los dos terminales intercambian suscapacidades. 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.
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 TransportProtocol). 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 fronteraproporcionado 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.245y RAS) ms los canales lgicos de audio, vdeo y
datos.
Uno de los mayores problemas de H.323 es elevadoretardo 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.
El objetivo del proyecto PISCIS es el desarrollo deuna plataforma de experimentacin de red que
permite soportar la prestacin de serviciosavanzados 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 utilizandotcnicas 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 resultadossatisfactorios.
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.
ARQ ( destino=210)
ACF ( dir transporte=X.X.X.X:Y)
Setup
ARQ ( destino=110)
ACF ( dir transporte=Y.Y.Y.Y:X)
Alerting
Connect
Release CompleteDRQ
DCFDRQ
DCF
110 210GKR
Figura 4. Ejemplo de sealizacin H.323
-
7/26/2019 Servicios Avanzados de Voz
5/8
4 Desarrollo de Servicios en redes
VoIP
Como ya se ha comentado en apartados anteriores,
el gatekeeper (GKR) es un componente queinicialmente 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 quedicho 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 (AdmissionConfirm) 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 loscodificadores seleccionados.
- Gestin de una zona: el GKR debe
proporcionar las funciones anteriores a losterminales, MCUs y gateways que se han
registrado con l.
Opcionalmente, el GKR debe implementar:
sealizacin de llamada y autorizacin de lallamada.
En la primera versin de la recomendacin, lasfunciones 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 quelos 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 deobligar a todos los usuarios a modificar sus clientes.
Otra ventaja es que un usuario puede conectarse envarias 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 msadecuada en funcin de la funcionalidad
proporcionada, dinamicidad y disponibilidad de
cdigo para plataformas tipo Linux y tipo Windowslo 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 ygatekeeper. 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
GKR
GWGWRTC
RDSI
201212211
Ethernet
214
205206207
PC
multimediaPC
multimediaPC
multimedia
Figura 5. Escenario tipo pruebas locales
Internet
Ethernet UC3M
Ethernet US
Ethernet UPM
GKR
RTC
GW
GW
GW
Figura 6. Escenario de interconexin
-
7/26/2019 Servicios Avanzados de Voz
6/8
sin cargo tanto por desarrolladores como por
usuarios comerciales.
OpenH323 se coordina por una compaa
australiana, Equivalence Pty Ltd, pero est abierto.
OpenH323 ofrece las libreras PWLib DLLcompuestas por una serie de clases que facilitan la
programacin.
El cdigo de Openh323 incluye clases queimplementan 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.323como registro, admisin, traduccin de direcciones
y control y monitorizacin de ancho de banda.
Adems, da soporte a otras caractersticas
avanzadas como:
Llamadas encaminadas por el GKR(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 diagrama de clases de esta distribucin se
muestra en la fig. 7.
En este sentido los desarrollos realizados en el senodel proyecto PISCIS han sido enviados a estas
organizaciones para contribuir como
desarrolladores de los componentes H.323.
4.2 Servicios de valor aadido.
Como puede verse, el cdigo implementa las
funciones obligatorias del GKR as como alguna delas opcionales.
Tras un periodo de tiempo para tomar contacto con
el cdigo. Hemos intentado introducir algunas delas funciones que nos han parecido ms interesantes
y ms tiles en un nuestra plataforma PISCIS.
La funcionalidad introducida ha sido:
- 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 quinpuede 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 grabacindel usuario que ha realizado la llamada. Es un
servicio similar al contestador automtico.
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, lasdirecciones 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.
opengate
EndpointTable
CallTable
PRasLog
CallThread
RasThread
MulticastThread
RasServer
1
n
Endpoint
1
n
TimeToLiveEntry
1
n
SignallingThread
1
n
CallDetails
1
n
Figura 7. Diagrama de clases del gatekeeper
-
7/26/2019 Servicios Avanzados de Voz
7/8
4.2.1 Control de acceso
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.
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.
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 queno 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 ficherode 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 laslistas 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 telfonosconvencionales, los alias sern nmeros E.164 para
que sean accesibles desde todos los terminales.
La implementacin permite que una serie determinales contesten a la llamada para un mismo
alias. Por ejemplo, tenemos un servicio para dar
informacin sobre el trfico (200). Cuando elusuario 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, losterminales 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
modificar el cdigo para incluir bases de datos,
solucin ms apropiada.
Los pasos seguidos para implementar esta
funcionalidad son:
- Permitir que dos endpoints en la tabla
EndpointTable tengan el mismo 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 permiteque ningn terminal se registre con el nombre
del servicio privado.
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 devoz.
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 clienteque 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 tiempodeterminado, 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 serviciorealizando 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
-
7/26/2019 Servicios Avanzados de Voz
8/8
direccin de correo. El GKR guarda estainformacin 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 lafutura 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 delservicio 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 PISCISha 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 dedesarrollo de libre distribucin OpenGatekeeper.
Agradecimientos
Este trabajo ha sido realizado al amparo delproyecto PISCIS del Plan Nacional de
Investigacin, programa FEDER.
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.
Referencias
[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, diciembre1998, http://www,ietf.org/rfc/rfc2475.txt
[6] http://www.ietf.org/html.charters/intserv-
charter.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 H-
series (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
[16] Opengatekeeper project:
http://OpenGatekeeper.sourceforge.net
[17] O. Hersent, D. Gurle & Jean-Pierre Petit, IPTelephony: Packet-base multimedia
communications systems,Addison-Wesley,
2000
[18] D. Collins, Voice Over IP, McGraw-Hill,
2001
[19] TELDAT. S.A. http://www.teldat.es
origen GKR destino buzn de voz
SetupSetup
Call ProceedingAlerting
Alerting
Expira el
timer Setup
ARQ
ACF
Alerting
Release Complete
ConnectConnect
Figura 8. Desvio de llamada
