ES2442593T3 - Procedimiento y dispositivo de tratamiento de llamadas en una red de comunicación que comprende unos terminales en itinerancia tales como unos terminales de telefonía del tipo softphone - Google Patents

Abstract

Procedimiento de gestión de servicios en un servidor de aplicación de telefonía (135) conectado a una red de comunicación (125), al menos una caja de conexión (110) que está conectada a esa red de comunicación, al menos un terminal itinerante (140) que está directamente conectado a dicha red de comunicación o que está conectado a dicha red de comunicación a través de dicha al menos una caja de conexión, comprendiendo dicho al menos un terminal una identidad pública vinculada a dicha al menos una caja de conexión y compartida con al menos otro terminal (105) conectado a dicha al menos una caja de conexión, distinto de dicho al menos un terminal denominado primer terminal, comprendiendo este procedimiento las etapas siguientes: - recepción (310) de al menos una solicitud de servicio desde dicho primer terminal, comprendiendo dicha al menos una solicitud de servicio una indicación de dicha localización relativa de dicho primer terminal, permitiendo dicha indicación de localización determinar si dicho terminal está conectado a la red de comunicaciones directamente o bien a través de la caja de conexión; - análisis (318, 414) de dicha al menos una solicitud de servicio según una lógica predeterminada, siendo dicha lógica predeterminada función de una indicación de localización relativa; y - en respuesta a dicha etapa de análisis, rechazo (322, 504) o implementación (326, 520) de dicho al menos un servicio solicitado.

Description

Procedimiento y dispositivo de tratamiento de llamadas en una red de comunicacion que comprende unos terminales en itinerancia tales como unos terminales de telefonia del tipo softphone.

La presente invencion se refiere a la telefonia en unas redes de comunicacion del tipo Internet y, mas particularmente, a un procedimiento y un dispositivo de tratamiento de llamadas en una red de comunicacion que comprende unos terminales en itinerancia tal como unos terminales de telefonia del tipo softphone.

La telefonia a traves de una red de comunicacion del tipo Internet, por ejemplo la comunicacion denominada VoIP (acronimo de Voice over Internet Protocol en terminologia anglosajona), tambien denominada voz sobre red IP (siglas de Internet Protocol en terminologia anglosajona), permite la transmision de la voz sobre una red de comunicacion en modo unicast (punto a punto), broadcast (un emisor y varios receptores), o multicast (un receptor y potencialmente todos los receptores). Un modo de comunicacion VoIP de ese tipo se basa tipicamente en el protocolo SIP (acronimo de Session Initiation Protocol en terminologia anglosajona).

La implementacion de la voz sobre red IP se realiza generalmente con ayuda de una aplicacion de software denominada softphone en terminologia anglosajona, ejecutada sobre un ordenador, por ejemplo un ordenador del tipo PC (siglas de Personal Computer en terminologia anglosajona), un asistente personal, tambien denominado PDA (siglas de Personal Digital Assistant en terminologia anglosajona) o un telefono movil inteligente, tambien denominado smartphone en terminologia anglosajona. El uso de la voz sobre red IP se desarrolla fuertemente desde hace algunos aros, particularmente en unas propuestas fijas denominadas Multiplay segun las cuales un usuario suscribe una propuesta que combina la telefonia y un acceso a Internet asi como en unas propuestas de telefonia movil.

El establecimiento de un enlace de comunicacion entre un terminal del tipo softphone y la red de comunicacion utilizada se realiza a traves de un punto de acceso personal, o caja de conexion, por ejemplo un modem a ADSL (siglas de Asymmetric Digital Subscriber Line en terminologia anglosajona) o una caja de conexion por cable, o a traves de un punto de acceso publico, por ejemplo un terminal WiFi de un operador de telecomunicacion.

Cuando se conectan unos terminales del tipo softphone a la red de comunicacion a traves de una caja de conexion, se consideran como unos terminales clasicos tales como los telefonos RTC (siglas de Red Telefonica Conmutada) o DECT (acronimo de Digital Enhanced Cordless Telephone en terminologia anglosajona). En situacion de itinerancia, los terminales del tipo softphone se benefician generalmente de tarifas planas asociadas a las cajas de conexion de sus usuarios a traves de la red del proveedor de acceso de los servicios correspondientes.

Antes de cualquier utilizacion, las aplicaciones "softphone" deben ser descargadas desde un sitio web, instaladas en un ordenador o cualquier tipo de terminal compatible y posteriormente deben obtener un archivo de configuracion que permita la utilizacion del servicio VoIP.

La figura 1 ilustra esquematicamente un entorno de telefonia en el que se puede usar un terminal de tipo softphone.

El entorno de telefonia 100 permite en este caso a un terminal clasico de telefonia 105, por ejemplo un terminal DECT, conectado a una caja de conexion 110, establecer o recibir una llamada con otro terminal clasico de telefonia 115, conectado a una caja de conexion 120, estando conectadas las cajas de conexion 110 y 120 a la red 125. El control y la gestion de las llamadas se realiza en este caso por el servidor CSCF 130 (siglas de Call Session Control Function en terminologia anglosajona) conectado al servidor 135 de aplicaciones de telefonia a traves de la red 125. La caja de conexion 110 permite igualmente a un terminal del tipo softphone, ejecutado por ejemplo por el ordenador 140, establecer o recibir llamadas, particularmente a traves de una conexion del tipo WiFi, entre el ordenador 140 y la caja de conexion 110. El terminal 105 y el terminal del tipo softphone implementado en el ordenador 140 comparten en este caso la misma identidad publica.

El terminal del tipo softphone implementado en el ordenador 140 se puede utilizar igualmente desde un punto de acceso distinto a la caja de conexion 110, particularmente desde el punto de acceso 145 que puede ser, por ejemplo, un tipo de acceso del tipo WiFi. En este contexto, el ordenador 140 se referencia como 140'.

La flecha 150 ilustra un ejemplo de establecimiento de la llamada entre el terminal 115 y un terminal unido a la caja de conexion 110, es decir uno de los terminales (105, 140, 140') que comparten una misma identidad publica vinculada a la caja de conexion 110.

Tipicamente, los terminales del tipo softphone utilizan la arquitectura IMS (siglas de IP Multimedia Subsystem en terminologia anglosajona) que utiliza, para identificar los terminales, las identidades siguientes:

-

una identidad privada denominada IMPI (siglas de IP Multimedia Private Identity en terminologia anglosajona); y

-

una identidad publica denominada IMPU (siglas de IP Multimedia PUblic Identity en terminologia anglosajona).

Estas identidades son del tipo URI (siglas de Uniform Resource Identifier en terminologia anglosajona).

Los terminales del tipo softphone, complementarios a los terminales fisicos conectados a una caja de conexion, pueden llevar la misma identidad publica (IMPU) que los terminales clasicos y, segun el caso, la misma identidad privada (IMPI) o no.

Se observa en este caso que la comparticion de una identidad publica entre varios terminales permite particularmente alertar a todos los terminales que comparten una misma identidad publica cuando se detecta una llamada entrante. Permite igualmente reducir los recursos implementados por el suministrador del servicio, en particular el numero de licencias de software en el seno de la arquitectura IMS, siendo tipicamente el modelo economico el asociar una licencia por direccion publica. Ademas, es mas facil establecer una facturacion por identidad publica que mediante identificacion del cliente.

No obstante, la utilizacion de identidades publicas multiples para los terminales del tipo softphone es, segun ciertos aspectos, mas facil de implementar. En efecto, en este caso, el servidor de aplicacion utilizado puede distinguir facilmente las llamadas procedentes de cada terminal y, en consecuencia, aplicar unas logicas de servicio diferentes. Se recuerda en este caso que un servidor de aplicacion SIP no puede conocer mas que las identidades publicas, siendo utilizadas unicamente las identidades privadas (IMPI) para la autentificacion de los terminales.

Considerando que la eleccion de compartir una misma identidad publica (IMPU) se realiza para el conjunto de los terminales de un cliente, el suministrador de servicios puede fijar unas restricciones de utilizacion complementarias para los terminales del tipo softphone. Tales restricciones son, por ejemplo, las siguientes:

-

cuando el terminal del tipo softphone esta conectado a una caja de conexion (es decir al domicilio de un cliente): se autoriza solamente una llamada entrante/saliente en un instante dado, o bien desde un terminal telefonico fisico conectado a la caja de conexion, o bien desde un terminal del tipo softphone unido a la caja de conexion. Este requisito funcional se puede imponer por el suministrador de servicios con el fin de habituar a los clientes a considerar sus terminales del tipo softphone como unos terminales clasicos. Se puede proponer una opcion del tipo "llamadas simultaneas" para autorizar varias llamadas entrantes/saliente simultaneas; y

-

cuando el terminal del tipo softphone se utiliza en situacion de itinerancia: el suministrador de servicios desea generalmente autorizar dos llamadas simultaneas (una desde un terminal clasico conectado a la caja de conexion y otra desde un terminal del tipo softphone en situacion de itinerancia) por unas razones reglamentarias. En efecto, si el terminal del tipo softphone se utiliza en situacion de itinerancia para una primera llamada activa, una persona en su domicilio debe poder utilizar su terminal clasico para llamar a un servicio de urgencias (bomberos, policia,...) cualquiera que sea su suscripcion.

En consecuencia, en razon de los servicios deseados y en consideracion a que los terminales del cliente comparten una misma identidad publica, el servidor de aplicacion telefonico a cargo del contador de llamadas simultaneas debe disponer de la informacion de localizacion del o de los terminales del tipo softphone de un cliente para implementar la logica de servicios correspondiente.

Las tablas 1 y 2 dadas en el anexo ilustran, a titulo de ejemplo, las posibilidades de combinacion de llamadas simultaneas deseadas por un suministrador de servicios segun la configuracion de conexion de un terminal del tipo softphone asociado con la caja de conexion cuando un servicio de doble llamada no esta implementado (tabla 1) y cuando este implementado (tabla 2).

No obstante, se recuerda aqui que las informaciones de localizacion se suministran generalmente de manera estatica en el servidor de aplicacion telefonica durante el registro de los clientes porque los equipos de suministro dinamico de localizacion no estan disponibles o tienen un coste particularmente elevado. Ademas, en el seguimiento del punto de acceso de un terminal del tipo softphone en situacion de itinerancia, no es seguro que el suministrador del enlace (por ejemplo un punto de acceso WiFi) este en posicion de suministrar esta informacion. Ademas, incluso si la conociese, deberia disponer de un equipo del tipo punto de entrada a la red VoIP de manera que inserte esta informacion de localizacion en el protocolo SIP a traves de la cabecera SIP P-ANI (siglas de P Access Network Information en terminologia anglosajona), lo que no es el caso. Ademas, una situacion de ese tipo engendraria unos problemas de confidencialidad de informaciones que podrian considerarse como personales.

Los documentos US 2005//282559 y WO 2008/2008/074122 describen una arquitectura del sistema de gestion de servicios de telefonia segun el estado de la tecnica anterior

La invencion permite resolver al menos uno de los problemas expuestos anteriormente permitiendo particularmente detectar las llamadas salientes procedentes de la caja de conexion y de terminales de tipo softphone asociados a esta caja y despues detectar si los terminales del tipo softphone estan conectados a traves de la caja de conexion o utilizados en situacion de itinerancia. Estas identidades publicas comunes se utilizan para el conjunto de los terminales de un cliente para, particularmente, evitar los costes de licencia de software complementario y, ademas, facilitar unos aspectos vinculados a los sistemas de tratamiento de informacion utilizados que se refieren, por ejemplo, al registro de clientes, la facturacion y la sincronizacion de informaciones personales asi como para simplificar los mecanismos de configuracion de la VoIP de los terminales (sin necesidad de identificar precisamente cada uno de los terminales de tipo softphone).

La invencion tiene asi por objeto un procedimiento de gestion de servicios en un servidor de aplicacion de telefonia conectado a una red de comunicacion, estando unida al menos una caja de conexion a dicha red de comunicacion, estando al menos un terminal en itinerancia, por ejemplo un terminal del tipo softphone, directamente unido a dicha red de comunicacion o estando unido a dicha red de comunicacion a traves de dicha al menos una caja de conexion, comprendiendo dicho al menos un terminal una identidad publica vinculada a dicha al menos una caja de conexion y compartida con al menos otro terminal conectado a dicha al menos una caja de conexion, distinto de dicho al menos un terminal denominado primer terminal, comprendiendo este procedimiento las etapas siguientes:

-

recepcion de al menos una solicitud de servicio de dicho primer terminal, comprendiendo dicha al menos una solicitud de servicio una indicacion de localizacion relativa de dicho primer terminal;

-

analisis de dicha al menos una solicitud de servicio segun una logica predeterminada, siendo dicha logica predeterminada funcion de una indicacion de localizacion relativa; y

-

en respuesta a dicha etapa de analisis, rechazar o implementar dicho al menos un servicio solicitado.

El procedimiento segun la invencion permite de ese modo gestionar unas solicitudes de servicio procedentes de terminales vinculados a una caja de conexion y que comparten una identidad publica con otros terminales vinculados a esta caja segun la localizacion de los terminales que solicitan estos servicios y una propuesta de acceso a estos servicios. Como se ha indicado anteriormente, la utilizacion de identidades comunes permite evitar particularmente unos costes de licencia de software complementario, facilitar unos aspectos vinculados a los sistemas de tratamiento de informacion utilizados que se refiere, por ejemplo, al registro de los clientes, la facturacion y la sincronizacion de informaciones personales asi como simplificar los mecanismos de configuracion de los terminales.

Segun un modo de realizacion particular, dicha al menos una solicitud de servicio es un mensaje de seralizacion de llamada, comprendiendo dicha etapa de analisis una etapa de comparacion de un numero de llamadas en curso vinculadas a dicha al menos una caja de conexion con un numero maximo de llamadas autorizadas segun dicha al menos una indicacion de localizacion relativa. El procedimiento segun la invencion permite de ese modo gestionar facilmente el acceso a unos servicios segun unas condiciones vinculadas a un numero de llamadas maximas autorizadas y asociadas a unas propuestas suscritas por unos usuarios.

De manera ventajosa, dicho mensaje de seralizacion es un mensaje de acuerdo con el protocolo SIP, siendo transmitida dicha indicacion de localizacion relativa en un campo dedicado de dicho mensaje. El procedimiento segun la invencion permite de ese modo obtener simplemente una informacion de localizacion de un terminal en el origen de una solicitud de acceso a un servicio.

Siempre segun un modo de realizacion particular, el procedimiento comprende ademas una etapa de carga de un perfil de servicios, estando vinculado dicho perfil a un usuario de dicho primer terminal y a dicha indicacion de localizacion relativa. El procedimiento segun la invencion permite de ese modo gestionar facilmente el acceso a unos servicios segun unas condiciones asociadas a los usuarios, en funcion de su localizacion.

Siempre segun un modo de realizacion particular, el procedimiento comprende ademas una etapa de transmision de al menos una informacion de configuracion de dicho primer terminal, previamente a dicha etapa de recepcion de al menos una solicitud de servicio, siendo transmitida dicha al menos una informacion de configuracion en respuesta a una solicitud de activacion de dicho primer terminal, siendo representativa dicha informacion de configuracion de dicha indicacion de localizacion relativa, siendo implementadas en un servidor de configuracion la recepcion de dicha solicitud de activacion y dicha etapa de transmision de al menos una informacion de configuracion del primer terminal.

Dicha indicacion de localizacion relativa se determina ventajosamente segun una direccion de origen comprendida en dicha solicitud de activacion.

Siempre segun un modo de realizacion particular, el procedimiento comprende ademas una etapa de activacion inicial de dicho primer terminal, estando unido dicho primer terminal a dicha al menos una caja de conexion, comprendiendo dicha etapa de configuracion la creacion y la transmision a dicho primer terminal de una cookie de sesion que comprende una identificacion de dicho primer terminal que permite particularmente la identificacion posterior del terminal, evitando asi una nueva solicitud de entrada de parametros de identificacion y/o de autentificacion del terminal durante su arranque.

El procedimiento comprende ademas, preferiblemente, una etapa de recepcion de dicha cookie de sesion y una etapa de identificacion de dicho primer terminal a partir de dicha cookie de sesion recibida.

La invencion tiene igualmente por objeto un programa de ordenador que comprende unas instrucciones adaptadas para la implementacion de cada una de las etapas del procedimiento descrito anteriormente cuando dicho programa se ejecuta en un ordenador, un servidor de aplicacion de telefonia que comprende unos medios adaptados para la implementacion de cada una de las etapas del procedimiento descrito anteriormente asi como un dispositivo que comprende al menos un servidor de aplicacion de telefonia y al menos un servidor de configuracion, comprendiendo el dispositivo unos medios adaptados para la implementacion de cada una de las etapas del procedimiento descrito anteriormente.

Las ventajas proporcionadas por este programa de ordenador, este servidor de aplicacion de telefonia y este dispositivo son similares a las enumeradas anteriormente.

Surgiran otras ventajas, objetivos y caracteristicas de la presente invencion con la descripcion detallada a continuacion, realizada a titulo de ejemplo no limitativo, con relacion a los dibujos adjuntos en los que:

-

la figura 1 ilustra esquematicamente un entorno de telefonia en el que se puede utilizar un terminal de tipo softphone;

-

la figura 2 ilustra esquematicamente ciertas etapas de configuracion de un terminal del tipo softphone durante su primera activacion;

-

la figura 3 ilustra esquematicamente ciertas etapas de gestion de una llamada emitida por un terminal de tipo softphone cuando este ultimo se conecta a la caja de conexion a la que esta vinculado;

-

la figura 4 ilustra esquematicamente ciertas etapas de configuracion de un terminal de tipo softphone durante su activacion en situacion de itinerancia;

-

la figura 5, que comprende las figuras 5a y 5b, ilustra esquematicamente ciertas etapas implementadas en un servidor de aplicacion para tratar unas llamadas de acuerdo con la invencion; y

-

la figura 6 muestra un ejemplo de dispositivo que permite implementar al menos parcialmente la invencion.

De manera general, la invencion se refiere a un mecanismo de gestion de llamadas para asociar una logica de servicios segun unas informaciones de localizacion relativa. Estas ultimas se transmiten por los terminales en itinerancia, por ejemplo unos terminales de tipo softphone, a un servidor de aplicacion, en un mensaje de seralizacion de llamada, siendo compartida la identidad publica del terminal con otros terminales vinculados a una misma caja de conexion. Estas informaciones de localizacion relativa se refieren esencialmente al modo de conexion del terminal con el fin de determinar si esta conectado a traves de la caja de conexion a la que esta vinculado o a traves de un punto de acceso distinto. Puede tomar particularmente los valores "domicilio" o "itinerancia". Se utiliza por un servidor de aplicacion que genera un contador de llamadas para controlar las llamadas seralizadas, entrantes y salientes, con el fin de establecer o no segun una logica predeterminada y un nivel de suscripcion.

Segun un modo de realizacion particular, la invencion se implementa utilizando el protocolo SIP. Un campo particular, llamado en este caso SIP User Agent, se evalua en la pila SIP. Contiene una informacion de localizacion relativa del terminal de tipo softphone que permiten al servidor de aplicacion que recibe esta informacion controlar en consecuencia las llamadas.

De manera ventajosa, la informacion de localizacion relativa se determina por el servidor de aplicacion al que se conecta el terminal de tipo softphone durante la fase de arranque, permitiendo particularmente su configuracion de VoIP. La informacion de localizacion relativa se puede determinar, en particular, segun la direccion logica del terminal, por ejemplo su direccion IP, y la direccion logica de la caja de conexion a la que esta vinculado al terminal. La informacion de localizacion relativa se puede determinar de modo diferente, particularmente comparando la posicion geografica de un terminal, identificado, por ejemplo, con la ayuda de un modulo GPS (siglas de Global Positioning System en terminologia anglosajona), con la posicion geografica de la caja de conexion determinada segun los datos de registro del usuario del terminal.

Para responder a ciertas solicitudes operativas del suministrador de servicios (contadores de llamadas autorizadas diferentes segun la localizacion) y al hecho de que todos los terminales vinculados a una misma caja de conexion posean una misma identidad publica (IMPU), el campo SIP User Agent del protocolo SIP comprende una informacion de localizacion obtenida cuando el terminal solicita su configuracion de VoIP desde que esta activo.

Conviene recordar aqui que por unas condiciones de seguridad, la configuracion de un terminal de tipo softphone no se memoriza de manera local, se descarga en cada activacion del terminal.

Durante su primera activacion, el terminal de tipo softphone debe en este caso estar conectado a la caja de conexion a la que esta vinculado. Puede de ese modo descargar su configuracion de VoIP desde un servidor de tipo FCPE (siglas de Frontal Customer Premise Equipment en terminologia anglosajona) cuya direccion absoluta (direccion FQDN, siglas de Fully Qualified Domain Name en terminologia anglosajona) se le suministra en su codigo de aplicacion. La solicitud de descarga puede, por ejemplo, ser una solicitud http (siglas de Hyper Text Transfer Protocol en terminologia anglosajona).

El servidor de configuracion FCPE extrae la direccion de origen del mensaje recibido, por ejemplo la direccion IP de un paquete IP recibido que pertenece a este mensaje. Esta direccion se utiliza particularmente para permitir responder a la solicitud y tambien como referencia. El servidor de descarga de configuracion FCPE transmite esta direccion a un servidor de identificacion para identificar al cliente en el origen de esta solicitud. Se observa aqui que cuando la caja de conexion ha establecido su sesion de Internet PPPoE (siglas de Point-to-Point Protocol over Ethernet en terminologia anglosajona) con el fin de obtener una direccion IP y las direcciones de los servidores DNS (siglas de Domain Name Server en terminologia anglosajona), el cliente ha sido identificado a traves de su identificador y su palabra clave utilizadas para la sesion PPPoE y el servidor BAS/Radius (acronimo de Broadband Access Server en terminologia anglosajona) para la atribucion de la direccion IP. Estas informaciones se memorizan por parte del servidor de identificacion.

Al ser en este caso la primera activacion del terminal de tipo softphone, el servidor de configuracion FCPE solicita, preferentemente, al cliente su identificador de mensajeria (caja de correo electronico) para asegurar inicialmente el servicio. Si estas informaciones recogidas por el cliente son correctas, el servidor de configuracion genera una cookie de sesion por una duracion significativa, por ejemplo dos meses, evitando asi una nueva solicitud de establecimiento de los parametros de autentificacion en cada arranque del terminal de tipo softphone.

El servidor de configuracion FCPE suministra entonces el fichero de configuracion de VoIP al terminal. Se observa en este caso que el fichero de configuracion de VoIP contiene un campo complementario vinculado a la invencion, el campo "Localizacion=Domicilio". Esa informacion se suministra en base al reconocimiento de la direccion IP de origen atribuida a la caja de conexion por el servidor BAS.

El terminal de tipo softphone inicializa entonces su pila SIP con los campos siguientes:

-

IMPU=IMPU@nombre de dominio contenido en el fichero de configuracion;

-

IMPI=IMPI@nombre de dominio contenido en el fichero de configuracion;

-

Password=Password SIP contenida en el fichero de configuracion; y

-

SIP User Agent=Softphone Domicilio

El terminal puede registrarse entonces y autentificarse en el nucleo de la red IMS utilizando el punto de entrada de este ultimo, suministrado igualmente en el fichero de configuracion. Entonces puede pasary recibir llamadas.

La figura 2 ilustra esquematicamente ciertas etapas de configuracion del terminal 200 de tipo softphone durante su primera activacion en funcion de la caja de conexion 202 (Box), del servidor BAS/Radius 204, del servidor de identificacion 206, del servidor de DNS 208, del servidor FCPE 210 y del nucleo del IMS 212.

Una etapa inicial (etapa 214) tiene por objetivo la solicitud de establecimiento de la sesion PPPoE. Esta solicitud, emitida por la caja de conexion 202 con destino en el servidor BAS/Radius 204, comprende un identificador y una palabra clave de usuario para establecer una conexion de Internet. Permite a la caja de conexion 202 establecer una sesion de Internet PPPoE.

Esta etapa va seguida de una solicitud de identificacion del cliente (etapa 216). Se transmite desde el servidor BAS/Radius 204 al servidor de identificacion 206. Comprende el identificador y la palabra clave recibidas que permiten al usuario establecer una conexion de Internet. En respuesta, el servidor BAS/Radius 204 recibe del servidor de identificacion 206 la identificacion del cliente y la lista de los servicios de Internet autorizados (etapa 218).

El servidor BAS/Radius 204 determina entonces una direccion IP para la caja de conexion 202 y las direcciones IP DNS primaria y secundaria. Estas direcciones se transmiten por el servidor BAS/Radius 204 a la caja de conexion 202 (etapa 220).

La caja de conexion 202 establece entonces una sesion de Internet PPPoE que permite una activacion del terminal

200.

Durante su activacion, el terminal 200, conectado a traves de la caja de conexion 202, emite una solicitud de resolucion de direccion para obtener una direccion de un servidor FCPE a partir de una direccion del tipo FQDN (etapa 222). Esta solicitud se transmite por el terminal 200 al servidor de DNS 208 traves de la caja de conexion 202 y el servidor BAS/Radius 204. En respuesta, el servidor de DNS transmite la direccion IP del servidor FCPE 210 que corresponde a la direccion de tipo FQDN recibida (etapa 224).

El terminal 200 transmite entonces al servidor FCPE 210 una solicitud de obtencion del fichero de configuracion de VoIP (etapa 226). Esta solicitud se transmite aqui segun el protocolo http del terminal 200 al servidor FCPE 210 a traves de la caja de conexion 202 y del servidor BAS/Radius 204. Con la recepcion de esta solicitud, el servidor FCPE 210 interroga al servidor de identificacion 206 (etapa 228) para solicitarle la identidad del cliente en funcion de la direccion IP de origen de la solicitud de obtencion del fichero de configuracion de VoIP. Esta direccion IP corresponde a la direccion IP de la caja de conexion 202. En respuesta, el servidor FCPE 210 recibe del servidor de identificacion 206 la identidad del cliente (etapa 230).

Despues de la obtencion de la identidad del cliente, el servidor FCPE 210 solicita, preferiblemente, al terminal 200 autentificarse transmitiendo un identificador y una palabra clave de mensajeria (etapa 232). Esta solicitud se transmite por el servidor FCPE 210 con destino en el terminal 200 a traves del servidor BAS/Radius 204 y la caja de conexion 202. En respuesta, el terminal 200 transmite al servidor FCPE 210, a traves de la caja de conexion 202 y del servidor BAS/Radius 204, una solicitud de obtencion del fichero de configuracion de VoIP, que comprende el identificador y la palabra clave de mensajeria del usuario, segun el protocolo http (etapa 234).

Con la recepcion de esta solicitud, el servidor FCPE 210 verifica acerca del servidor de identificacion 206 que el cliente identificado posee este identificador y esta palabra clave de mensajeria (etapa 236). El servidor de identificacion 206 responde al servidor FCPE 210 positiva o negativamente (etapa 238).

Si el cliente identificado tiene este identificador y esta palabra clave de mensajeria, el servidor FCPE 210 verifica que el cliente dispone del servicio VoIP, genera una cookie de sesion que tiene, preferiblemente, un periodo de validez de varios meses, y genera un fichero de configuracion de VoIP en el que figura la informacion que precisa que el terminal 200 esta conectado a la caja de conexion 202, es decir que el terminal 200 esta en una configuracion "domicilio" (etapa 240).

El servidor FCPE 210 transmite entonces el fichero de configuracion de VoIP y la cookie de sesion, generadas en el terminal 200, a traves del servidor BAS/Radius 204 y la caja de conexion 202 (etapa 242). El fichero de configuracion de VoIP se transmite, preferiblemente, en el formato xml (siglas de e�tensible Markup Language en terminologia anglosajona).

Como se ha representado, el fichero de configuracion de VoIP 244 recibido comprende la informacion de localizacion relativa "localizacion=domicilio".

Para registrarse, el terminal 200 transmite entonces una solicitud de resolucion de direccion al servidor de DNS 208, a traves de la caja de conexion 202 y del servidor BAS/Radius 204, con el fin de obtener una direccion IP del nucleo del IMS 212 a partir de una direccion de tipo FQDN (etapa 246). En respuesta, el terminal 200 recibe del servidor de DNS 208, a traves del servidor BAS/Radius 204 y la caja de conexion 202, la direccion IP de un punto de entrada del nucleo del IMS 212 (etapa 248).

El terminal 200 puede entonces dirigir una solicitud de registro al nucleo del IMS 212 (etapa 250). La solicitud, que comprende la identidad publica del terminal 200, se transmite a traves de la caja de conexion 202 y del servidor BAS/Radius 204. En respuesta el nucleo del IMS 212 solicita al terminal 200, a traves del servidor BAS/Radius 204 y la caja de conexion 202, autentificarse (etapa 252). El terminal 200 transmite entonces una solicitud de registro que comprende la identidad publica del terminal 200 y unos datos de autentificacion, al nucleo del IMS 212 a traves de la caja de conexion 202 y el servidor BAS/Radius 204 (etapa 254). El nucleo del IMS 212 registra entonces el terminal 200 y se lo confirma, a traves del servidor BAS/Radius 204 y la caja de conexion 202, indicandole la duracion del registro (etapa 256).

El terminal 200 esta entonces listo para emitir y para recibir unas llamadas.

Despues del registro, si el terminal de tipo softphone intenta pasar una llamada saliente, la seralizacion de la llamada transita en el nucleo del IMS y los servicios telefonicos vinculados al que llama, tambien denominados originating en terminologia anglosajona, son activados.

La seralizacion de llamada SIP transita por tanto en el servidor de aplicacion. Este ultimo puede encontrar la cuenta del cliente a traves de su identidad publica disponible en los campos From, P-Preferred-ID y/o P-Asserted-ID del mensaje SIP. Puede verificar de ese modo que servicios vinculados al que llama deben ser activados para este cliente (secreto de llamadas, restriccion de llamadas, etc.).

El servidor de aplicacion verifica el contador de llamadas simultaneas autorizadas para este cliente. �abiendo aqui valorado el campo SIP User Agent un "Softphone-Domicilio", el servidor de aplicacion no debe autorizar mas que una unica llamada simultanea (a menos que el cliente haya suscrito una propuesta que permita varias llamadas simultaneas). Esta regla se configura, preferiblemente, en el servidor de aplicacion.

Si no esta activa ninguna llamada en la caja de conexion, el contador de llamadas en curso se evalua en cero. La llamada saliente iniciada por el terminal de tipo softphone se autoriza por tanto y el contador de llamadas en curso se incrementa en uno durante el tiempo de la llamada y posteriormente se disminuye en uno al final de la llamada (a traves del mensaje del tipo B�E). Si, durante esta llamada, la caja de conexion intenta establecer otra llamada, el servidor de aplicacion compara el valor del contador de llamadas con el valor maximo de llamadas simultaneas para el cliente y autoriza o no la llamada segun el resultado de la comparacion. A titulo de ilustracion, si esta autorizada una unica llamada simultanea, el servidor de aplicacion no autoriza el establecimiento de una segunda llamada cuando se emite una llamada desde el terminal de tipo softphone y este ultimo esta localizado en el domicilio. Igualmente, si la caja de conexion ha establecido una primera llamada antes de la solicitud de establecimiento de llamada por parte del terminal de tipo softphone, el servidor de aplicacion rechaza la solicitud de llamada procedente de este terminal si este ultimo esta situado en el domicilio.

La figura 3 ilustra esquematicamente ciertas etapas de gestion de una llamada emitida por un terminal 300 de tipo softphone en funcion del nucleo del IMS 304, del servidor de aplicacion de telefonia 306, indicado como AS Tel, y del terminal denominado 308, cuando el terminal se conecta a la caja de conexion a la que esta vinculado.

Se observa en este caso que aunque todas las comunicaciones entre el terminal 300 y los otros dispositivos transitan a traves de una caja de conexion y un servidor BAS/Radius, estos ultimos no estan representados por razones de claridad.

Cuando se emite una llamada saliente por el terminal 300, se transmite un mensaje de seralizacion de llamada SIP por el terminal 300 al nucleo del IMS 304 (etapa 310). Este mensaje, de tipo INVITE, comprende la identidad publica (IMPU) del terminal que llama, el numero de terminal del llamado (tipicamente la identidad publica del terminal llamado) y, de acuerdo con la invencion, una indicacion de localizacion, en este caso el campo SIP User Agent que tiene el valor "domicile".

En respuesta, el nucleo del IMS 304 transmite el mensaje de tipo 100 TR�ING al terminal 300 para indicarle que la solicitud esta en curso de tratamiento (etapa 312). Ademas, el nucleo del IMS 304 transmite el mensaje de seralizacion de llamada SIP recibido, con la identidad publica del terminal que llama, el numero del terminal llamado y el campo SIP User Agent, al servidor de aplicacion de telefonia 306 (etapa 314). Este ultimo transmite un mensaje del tipo 100 TR�ING al nucleo del IMS 304 para indicarle que la solicitud esta en curso de tratamiento (etapa 316).

Un algoritmo de autorizacion de llamada, que comprende particularmente una etapa de comparacion del valor de un contador de llamadas autorizadas con un numero de llamadas maximas autorizadas para el cliente, se utiliza entonces para determinar si la llamada puede establecerse o no (etapa 318).

En caso negativo, se transmite un mensaje de rechazo del tipo 403 Forbidden por el servidor de aplicacion de telefonia 306 al nucleo del IMS 304 (etapa 320) que la transmite al terminal 300 (etapa 322). El terminal 300 acusa entonces el recibo de este rechazo en el nucleo del IMS 304 (etapa 324) que a su vez retransmite esta informacion al servidor de aplicacion (no representado en la figura 3).

Si por el contrario, se puede establecer la llamada, el servidor de aplicacion de telefonia 306 transmite un mensaje de tipo INVITE, que comprende la identidad publica del terminal que llama y el numero del terminal llamado, con o sin el campo SIP User Agent, incluso con una modificacion del campo SIP User Agent, al nucleo del IMS 304 (etapa 326). En respuesta, el nucleo del IMS 304 transmite un mensaje del tipo 100 TR�ING al servidor de aplicacion de telefonia 306 para indicarle que la solicitud esta en curso de tratamiento (etapa 328).

De manera similar, el nucleo del IMS 304 transmite entonces un mensaje de tipo INVITE, que comprende la identidad publica del terminal que llama y el numero del terminal llamado, con o sin el campo SIP User Agent, al terminal llamado 308 (etapa 330) que, en respuesta, transmite un mensaje del tipo 100 TR�ING al nucleo del IMS 304 para indicarle que la solicitud esta en curso de tratamiento (etapa 332) y despues un mensaje del tipo 180 RINGING (etapa 334).

El nucleo del IMS 304 transmite entonces el mensaje de tipo 180 RINGING recibido al servidor de aplicaciones de telefonia 306 (etapa 336) que la retransmite al nucleo del IMS 304 (etapa 338) desde donde se transmite al terminal 300 (etapa 340).

Si el terminal llamado 308 acepta la llamada, se transmite un mensaje de aceptacion de tipo 200 �� por este ultimo al nucleo del IMS 304 (etapa 342). Este mensaje de aceptacion se transmite entonces al servidor de aplicacion de telefonia 306 (etapa 344) que lo retransmite al nucleo del IMS 304 (etapa 346) desde donde se transmite al terminal 300 (etapa 348).

El terminal 300 confirma entonces la llamada transmitiendo el mensaje de aceptacion de tipo AC� al nucleo del IMS 304 (etapa 350). Este mensaje de aceptacion se transmite a continuacion al servidor de aplicacion de telefonia 306 (etapa 352) que lo retransmite al nucleo del IMS 304 (etapa 354) desde donde se retransmite al terminal llamado (etapa 356).

Se establece entonces un flujo de audio 358, por ejemplo un flujo de audio RTP (siglas de Real-time Transport Protocol en terminologia anglosajona), entre el terminal 300 y el terminal llamado 308.

Cuando se utiliza un terminal de tipo softphone de acuerdo con la invencion en una situacion de itinerancia, se conecta, despues de su arranque, a un servidor de configuracion de VoIP FCPE para obtener, en particular, un fichero de configuracion de VoIP.

El servidor de configuracion FCPE extrae la direccion de origen del mensaje recibido, por ejemplo la direccion IP de un paquete IP recibido que pertenece a ese mensaje. Esta direccion se utiliza particularmente para permitir responder a la peticion pero tambien igualmente como referencia. El servidor de configuracion FCPE transmite esta direccion a un servidor de identificacion para identificar al cliente en el origen de esta peticion.

Con este fin, el servidor de identificacion analiza esta direccion IP. Sin embargo, al estar en este caso conectado el terminal a traves de un punto de acceso y no a traves de la caja de conexion a la que esta vinculado el terminal, la direccion IP identificada no corresponde a ningun cliente. En esta configuracion, cuando el cliente no puede ser identificado mediante una direccion IP, el servidor de configuracion puede encontrar el identificador del cliente en la base al cookie de sesion creado durante la primera activacion y la transmite con la solicitud de obtencion de un fichero de configuracion de VoIP.

Si la cookie es valida, el servidor de configuracion genera el fichero de configuracion de VoIP indicando que el terminal esta en situacion de itinerancia, es decir, por ejemplo, utilizando el valor de "itinerancia" en el campo del fichero de configuracion ("Localizacion= Itinerancia").

Si la duracion de validez de la cookie de sesion esta sobrepasada, el servidor de configuracion solicita al cliente autentificarse de nuevo, por ejemplo a partir de un identificador y de la palabra clave de mensajeria. Si el cliente se autentifica, se genera una nueva cookie de sesion por el servidor de configuracion con una validez predeterminada, tipicamente varios meses o varias horas. Se asocia al identificador del cliente.

El servidor de configuracion genera entonces el fichero de configuracion de VoIP que comprende el campo "Localizacion= Itinerancia".

El terminal de tipo softphone inicializa entonces su pila SIP con los campos siguientes:

-

IMPU=IMPU@nombre de dominio contenido en el fichero de configuracion;

-

IMPI=IMPI@nombre de dominio contenido en el fichero de configuracion;

-

Password=Password SIP contenida en el fichero de configuracion; y

-

SIP User Agent=Softphone Itinerancia

El terminal de tipo softphone puede registrarse entonces y autentificarse en el nucleo de la red IMS utilizando el punto de entrada de este ultimo suministrado igualmente en el fichero de configuracion.

El softphone puede entonces pasar y recibir llamadas.

La figura 4 ilustra esquematicamente ciertas etapas de configuracion de un terminal 400 de tipo softphone durante su activacion en situacion de itinerancia en funcion del servidor de identificacion 402, del servidor de DNS 404, del servidor FCPE 406 y del nucleo del IMS 408.

Se observa en este caso que, aunque todas las comunicaciones entre el terminal 400 y los otros dispositivos pasan a traves de un punto de acceso, este ultimo no esta representado por razones de claridad.

Una primera etapa tiene por objetivo obtener una direccion IP del servidor FCPE 406. Con este fin, se transmite una solicitud de resolucion de direccion por el terminal 400 al servidor de DNS 404 (etapa 410). Esta solicitud comprende la direccion de tipo FQDN del servidor FCPE 406. En respuesta, el servidor de DNS 404 transmite la direccion IP del servidor FCPE 406 (etapa 412).

El terminal 400 transmite entonces una peticion al servidor FCPE 406 para obtener un fichero de configuracion de VoIP (etapa 414). Esta peticion comprende particularmente la cookie de sesion previamente recibida por el terminal

400. Se emite, por ejemplo, segun el protocolo http. A la recepcion de esta peticion, el servidor FCPE 406 solicita al servidor de identificacion 402 la identidad del cliente que utiliza el terminal 400 (etapa 416). Esta solicitud comprende la direccion IP de origen de la peticion de obtencion de un fichero de configuracion de VoIP, es decir la direccion IP del punto de acceso a traves del que el terminal 400 esta conectado a la red de comunicacion.

Al no conocer el servidor de identificacion 402 la direccion IP que el recibe responde al servidor FCPE 406 que el cliente es desconocido (etapa 418).

El servidor FCPE 406 determina entonces a quien pertenece la cookie de sesion recibida en la peticion de obtencion de un fichero de configuracion de VoIP (por ejemplo preguntandolo al servidor de identificacion) y genera un fichero de configuracion correspondiente (etapa 420). Este fichero comprende una indicacion segun la que el terminal 400 esta en situacion de itinerancia.

Como se ha indicado anteriormente, si la cookie de sesion ya no es valida, el servidor FCPE 406 puede transmitir al terminar 400 una solicitud de autentificacion con el fin de renovar la cookie de sesion (no representada).

El fichero de configuracion de VoIP asi como la cookie de sesion se transmiten a continuacion por el servidor FCPE 406 al terminal 400 (etapa 422). El fichero de configuracion de VoIP se transmite, preferiblemente, en el formato xml.

Como se ha representado, el fichero de configuracion de VoIP 424 recibido comprende la mencion "localizacion= itinerancia".

Para registrarse, el terminal 400 transmite entonces una solicitud de resolucion de direccion al servidor de DNS 404 con el fin de obtener una direccion IP del nucleo del IMS 408 a partir de una direccion de tipo FQDN (etapa 426). En respuesta, el terminal 400 recibe del servidor de DNS 404 la direccion IP de un punto de entrada del nucleo del IMS 408 (etapa 428).

El terminal 400 puede dirigir entonces una solicitud de registro al nucleo del IMS 408 (etapa 430). La solicitud comprende la identidad publica del terminal 400. En respuesta, el nucleo del IMS 408 solicita al terminal 400 autentificarse (etapa 432). El terminal 400 transmite entonces una solicitud de registro que comprende la identidad publica del terminal 400 y los datos de autentificacion al nucleo del IMS 408 (etapa 434). El nucleo del IMS 408 registra entonces el terminal 400 y se lo confirma indicandole la duracion de registro (etapa 436).

El terminal 400 esta entonces listo para emitir y recibir unas llamadas.

Como se indico anteriormente, despues del registro, si el terminal de tipo softphone intenta pasar una llamada saliente, la seralizacion de llamada pasa por el nucleo del IMS y se inician los servicios telefonicos vinculados al que llama.

De nuevo, la seralizacion de llamada SIP transita por el servidor de aplicacion y este ultimo puede encontrar la cuenta del cliente a traves de su identidad publica disponible en los campos From, P-Preferred-ID y/o P-Asserted-ID del mensaje SIP. Se puede verificar asi que los servicios vinculados al que llama deben ser activados para este cliente (secreto de llamada, restriccion de llamadas, etc.).

El servidor de aplicacion verifica entonces el contador de llamadas simultaneas autorizadas para este cliente. Siendo entonces valorado el campo SIP User Agent como un "Softphone Itinerancia", el servidor de aplicacion debe autorizar al menos dos llamadas simultaneas: una sola desde el domicilio y al menos una desde un terminal en situacion de itinerancia (a menos que el cliente no haya suscrito una propuesta que permita varias llamadas simultaneas a partir del domicilio y/o desde una situacion de itinerancia). Esta regla se configura, preferiblemente, en el servidor de aplicacion.

Como en el caso anterior segun el que el terminal de tipo softphone emite una llamada estando conectado a la caja de conexion a la que esta vinculado, el contador de llamadas en curso se evalua en el valor cero si no esta en curso ninguna llamada. La llamada saliente procedente del terminal en situacion de itinerancia se autoriza y el contador de llamadas en curso se incrementa en uno y posteriormente se disminuye en uno durante la liberacion de la llamada a traves del mensaje de tipo B�E.

Si, durante una llamada efectuada por el terminal en situacion de itinerancia, la caja de conexion del domicilio intenta establecer una llamada en paralelo, por ejemplo hacia un numero de urgencia, el servidor de aplicacion constata que el valor del contador de llamadas es igual a uno con una llamada en curso en situacion de itinerancia. Autoriza entonces esta segunda llamada desde el domicilio.

Igualmente, si la caja de conexion del domicilio ha establecido una primera llamada antes de la solicitud de establecimiento de llamada por el terminal en situacion de itinerancia, el servidor de aplicacion acepta esta llamada.

Sin embargo, si se intenta una segunda llamada desde el domicilio, suponiendo que otro terminal de tipo softphone este conectado a la caja de conexion ademas del terminal telefonico utilizado, el servidor de aplicacion no autoriza esta segunda llamada por medio del analisis de los campos SIP "User Agent".

Al utilizar el campo SIP "User Agent", el servidor de aplicacion puede aplicar por tanto una logica de tratamiento de llamada diferente para los terminales de tipo softphone en situacion de itinerancia y para los terminales conectados a una caja de conexion a la que estan vinculados, a pesar del hecho de que tengan la misma identidad publica IMPU.

La gestion de una llamada emitida por un terminal de tipo softphone cuando este ultimo esta en situacion de itinerancia es similar a la de una llamada emitida por un terminal de tipo softphone cuando este ultimo esta directamente conectado a la caja de conexion a la que esta vinculado. Solo difiere el algoritmo de autorizacion de llamadas.

En consecuencia, con la excepcion de la autorizacion de llamadas, el algoritmo descrito con referencia a la figura 3 se aplica a la gestion de una llamada emitida por un terminal de tipo softphone cuando este ultimo esta en situacion de itinerancia.

La figura 5, que comprende las figuras 5a y 5b, ilustra esquematicamente ciertas etapas implementadas en un servidor de aplicacion para tratar llamadas de acuerdo con la invencion. La figura 5a se refiere a la deteccion del tipo de llamada y el tratamiento de las llamadas salientes mientras que la figura 5b se refiere a las llamadas entrantes.

Como se ilustra en la figura 5a, una primera etapa tiene por objetivo determinar el tipo de llamada, es decir determinar si se trata de una llamada entrante o una llamada saliente (etapa 500).

Si se trata de una llamada saliente, una etapa siguiente tiene por objetivo determinar si la identidad publica del terminal que llama es conocida por el servidor de aplicacion y esta memorizada en una base de datos (BdD) en la que estan almacenadas las identidades publicas de los terminales autorizados a llamar a traves del servicio propuesto (etapa 502).

Si la identidad publica del terminal del que llama no es conocida para el servidor de aplicacion, se dirige una respuesta de rechazo de llamada al terminal del que llama (etapa 504) que transmite entonces un acuse de recibo al servidor de aplicacion (etapa 506). El algoritmo llega a su fin.

Si, por el contrario, la identidad publica del terminal del que llama es conocida para el servidor de aplicacion, se realiza una prueba para determinar si el terminal del que llama se encuentra en situacion de itinerancia o no (etapa 508). Si el terminal del que llama no se encuentra en situacion de itinerancia, se carga en la memoria del servidor de aplicacion un perfil de servicios segun el cual la llamada recibida se emite desde el domicilio (del terminal clasico o de un terminal de tipo softphone) (etapa 510). En caso contrario, si el terminal del que llama se encuentra en situacion de itinerancia, se carga en la memoria del servidor de aplicacion un perfil de servicios segun el que la llamada recibida se emite desde un terminal de tipo softphone no conectado a la caja de conexion a la que esta vinculado (etapa 512). Los perfiles de servicio cargados en la memoria son en este caso los servicios del tipo originating. Permiten particularmente determinar la logica de servicios que se debe utilizar.

El numero de llamadas establecidas en curso, sin considerar la llamada en curso de tratamiento, se compara a continuacion con el numero maximo de llamadas simultaneas autorizadas para el cliente que llama, segun el perfil previamente cargado (etapa 514). Esta etapa se refiere tambien a comparar el numero de llamadas en curso con el numero de llamadas simultaneas maximas segun el origen de las llamadas en curso. A titulo de ilustracion, se pueden autorizar dos llamadas simultaneas si como maximo se establece una llamada con la caja de conexion considerada.

Si el numero de llamadas establecidas en curso no es inferior al numero maximo de llamadas simultaneas autorizadas para el cliente que llama, segun el perfil previamente cargado, se rechaza la llamada en curso de tratamiento. Con este fin, se dirige una respuesta de rechazo de llamada al que llama (etapa 504) que transmite entonces un acuse de recibo al servidor de aplicacion (etapa 506). El algoritmo llega a su fin.

Por el contrario, si el numero de llamadas establecidas en curso es inferior al numero maximo de llamadas simultaneas autorizadas para el cliente que llama, segun el perfil previamente cargado, el numero de llamadas en curso se aumenta en uno (etapa 516). Los servicios vinculados al que llama se activan entonces en funcion del perfil previamente cargado en memoria (etapa 518), se repite el mensaje de seralizacion de llamada (INVITE) con destino al terminal llamado (etapa 520) y se analizan los mensajes recibidos por el servidor de aplicacion (etapa 522).

Cuando el mensaje recibido es del tipo 100 TR�ING, el algoritmo se cierra en bucle sobre si mismo (al menos durante un tiempo predeterminado) esperando un nuevo mensaje.

Cuando el mensaje recibido es del tipo ��, el mensaje se repite traves del terminal del que llama (etapa 524). El algoritmo se cierra entonces en bucle sobre si mismo (al menos durante un tiempo predeterminado) esperando un nuevo mensaje.

Cuando el mensaje recibido es del tipo AC�, el mensaje recibido se repite hacia el terminal del llamado (etapa 526). El algoritmo se cierra entonces en bucle sobre si mismo (al menos durante un tiempo predeterminado) esperando un nuevo mensaje.

Cuando el mensaje recibido es del tipo B�E o CANCEL, el numero de llamadas en curso se disminuye en uno (etapa 528) y el mensaje recibido se retransmite hacia el terminal del llamado o del que llama para poner fin a la llamada y al algoritmo (etapa 530).

Finalmente, cuando el mensaje recibido este tipo 487 REQUEST� TERMINATED, se pone fin al algoritmo.

El tratamiento de las llamadas entrantes se ilustra en la figura 5b.

Si la llamada en curso de tratamiento es una llamada entrante (figura 5a, etapa 500), una etapa siguiente tiene por objetivo determinar si la identidad publica del terminal llamado es conocida para el servidor de aplicacion y esta memorizada en una base de datos (BdD) en la que estan almacenadas las identidades publicas de los terminales autorizados a ser llamados a traves del servicio propuesto (etapa 532).

Si la identidad publica del terminal llamado no es conocida para el servidor de aplicacion, se dirige una respuesta de rechazo de llamada del tipo 404 Not Found al terminal del que llama (etapa 534) que transmite entonces un acuse de recibo al servidor de aplicacion (etapa 536). El algoritmo llega a su fin.

Si, por el contrario, la identidad publica del terminal del llamado es conocida para el servidor de aplicacion, se carga en la memoria un perfil de servicios para el llamado, generalmente denominados servicios terminating en terminologia anglosajona, (etapa 538).

Se efectua entonces una prueba para determinar si el servicio de reenvio de llamadas incondicional esta activado (etapa 540). Este servicio tiene por objetivo reenviar todas las llamadas entrantes hacia un numero predeterminado, por ejemplo un numero de mensajeria vocal o un tercer numero.

Si el servicio de reenvio de llamadas incondicional esta configurado, la llamada entrante se reenvia hacia un numero predeterminado referenciado en el perfil terminating del llamado (etapa 542). El algoritmo llega a su fin.

Si, por el contrario, el servicio de reenvio de llamadas incondicional no esta configurado, se efectua una prueba para comparar el numero de llamadas establecidas en curso, sin considerar la llamada en curso de tratamiento, con el numero maximo de llamadas simultaneas autorizadas para el cliente llamado, segun el perfil previamente cargado (etapa 544). Esta etapa se refiere asi a comparar el numero de llamadas en curso con el numero de llamadas simultaneas maximas segun el origen de las llamadas en curso. A titulo de ilustracion, se pueden autorizar dos llamadas simultaneas si como maximo se establece la llamada con la caja de conexion considerada.

Si el numero de llamadas establecidas en curso no es inferior al numero maximo de llamadas simultaneas autorizadas para el cliente llamado, la llamada en curso de tratamiento se reenvia hacia un numero predeterminado referenciado en el perfil terminating del llamado (etapa 542). El algoritmo llega a su fin.

Por el contrario, si el numero de llamadas establecidas en curso es inferior al numero maximo de llamadas simultaneas autorizadas para el cliente llamado, se activan los servicios terminating del cliente llamado (etapa 546) y se reenvia el mensaje de llamada INVITE hacia el terminal del llamado (etapa 548).

El numero de llamadas en curso se incrementa entonces en uno (etapa 550) y los mensajes recibidos por el servidor de aplicacion son analizados (etapa 552).

Cuando el mensaje recibido es del tipo 100 TR�ING, el algoritmo se cierra en bucle sobre si mismo (al menos durante un tiempo predeterminado) esperando un nuevo mensaje.

Cuando el mensaje recibido es del tipo 200 ��, el mensaje se repite traves del terminal del que llama (etapa 554). El algoritmo se cierra entonces en bucle sobre si mismo (al menos durante un tiempo predeterminado) esperando un nuevo mensaje.

Cuando el mensaje recibido es del tipo AC�, el mensaje recibido se repite hacia el terminal del llamado (etapa 556). El algoritmo se cierra entonces en bucle sobre si mismo (al menos durante un tiempo predeterminado) esperando un nuevo mensaje.

Cuando el mensaje recibido es del tipo B�E o CANCEL, el numero de llamadas en curso se disminuye en uno (etapa 558) y el mensaje recibido se retransmite hacia el terminal del llamado o del que llama para poner fin a la llamada y al algoritmo (etapa 560).

Finalmente, cuando el mensaje recibido este tipo 487 REQUEST� TERMINATED, el mensaje recibido se retransmite hacia el terminal del llamado o del que llama para poner fin a la llamada y al algoritmo (etapa 560).

Se ilustra en la figura 6 un dispositivo adaptado para implementar la invencion o una parte de la invencion. El dispositivo 600 es por ejemplo una estacion de trabajo o un ordenador de tipo PC.

El dispositivo 600 comprende en este caso un bus de comunicacion 605 al que estan conectados:

-

una unidad central de procesamiento o un microprocesador 610 (CPU, Central Processing Unit);

-

una memoria no volatil 615 (ROM, acronimo de Read �nly Memory en terminologia anglosajona) que puede comprender los programas "Prog", "Prog1" y "Prog2";

-

una memoria volatil o memoria cache 620 (RAM, acronimo de Random Access Memory en terminologia anglosajona) que comprende unos registros adaptados para registrar unas variables y parametros creados y modificados en el curso de la ejecucion de los programas antes citados; y

-

una interfaz de comunicacion 650 adaptada para transmitir y para recibir unos datos, particularmente unos mensajes relativos a unas llamadas entrantes y salientes.

Opcionalmente, el dispositivo 600 puede disponer igualmente:

-

de una pantalla 625 (Ec) que permite visualizar unos datos y/o servir de interfaz grafica con el usuario que podra interactuar con los programas segun la invencion, con la ayuda de un teclado y de un raton 630 (CS) o de otro dispositivo puntero, una pantalla tactil o un mando a distancia;

-

de un disco duro (DD) 635 que puede comprender los programas "Prog", "Prog1" y "Prog2" antes citados y unos datos tratados o a tratar segun la invencion; y

-

de un lector de tarjetas de memoria 640 (Lc) adaptado para recibir una tarjeta de memoria 645 (C) y para leer en ella o escribir en ella unos datos tratados o a tratar segun la invencion.

El bus de comunicacion permite la comunicacion y la interoperabilidad entre los diferentes elementos incluidos en el dispositivo 600 o conectados a el. La representacion del bus no es limitativa y, particularmente, la unidad central es susceptible de comunicar unas instrucciones a cualquier elemento del dispositivo 600 directamente o por medio de otro elemento del dispositivo 600.

El codigo ejecutable de cada programa que permite al dispositivo programable implementar los procesos segun la invencion, puede estar almacenado, por ejemplo, en el disco duro 635 o en la memoria no volatil 615.

Segun una variante, la tarjeta de memoria 645 puede contener unos datos asi como el codigo ejecutable de los programas antes citados que, una vez leido por el dispositivo 600, se almacena en el disco duro 635.

Segun otra variante, el codigo ejecutable de los programas se podra recibir, al menos parcialmente, por medio de la interfaz 650, para ser almacenado de manera identica a la descrita anteriormente.

De manera mas general, el o los programas se podran cargar en uno de los medios de almacenamiento del dispositivo 600 antes de ser ejecutados.

La unidad central 610 controlara y dirigira la ejecucion de las instrucciones o partes del codigo de software del o de los programas segun la invencion, instrucciones que estan almacenadas en el disco duro 635 o en la memoria no volatil 615 o bien en los otros elementos de almacenamiento antes citados. Durante la puesta en tension, el o los programas que estan almacenados en una memoria no volatil, por ejemplo el disco duro 635 o la memoria no volatil 615, se transfieren a la memoria volatil 620 que contiene entonces el codigo ejecutable del o de los programas segun la invencion, asi como unos registros para memorizar las variables y parametros necesarios para la realizacion de la invencion.

Conviene hacer notar que el aparato de comunicacion que comprende el dispositivo segun la invencion puede ser igualmente un aparato programado. Este aparato contiene entonces el codigo del o de los programas informaticos por ejemplo fijado en un circuito integrado de aplicacion especifica (ASIC).

Aunque la descripcion se ha orientado esencialmente hacia el problema de la gestion de llamadas simultaneas, la invencion se puede realizar para resolver unos problemas similares.

En particular, es posible proponer unas propuestas de servicios telefonicos diferentes para los terminales conectados a una caja de conexion y para los terminales de tipo softphone, unidos a esta caja, en situacion de itinerancia, pudiendo considerarse estos ultimos como unos terminales secundarios. En particular, el tiempo de llamada de los terminales conectados a una caja de conexion puede ser diferente al de los terminales del tipo softphone, unidos a esta caja, en situacion de itinerancia, particularmente para evitar el fraude y el consumo excesivo de llamadas gratuitas. Igualmente, es posible prohibir las llamadas muy altamente recargadas pasadas desde los terminales de tipo softphone en situacion de itinerancia. Es posible igualmente no proponer ciertos servicios, por ejemplo el servicio conocido con el nombre de "Secreto de llamada" desde los terminales de tipo softphone en situacion de itinerancia. Es igualmente posible proponer unos parametros diferentes segun las situaciones, por ejemplo proponer unas listas de telefonos diferentes para el servicio conocido bajo nombre de "Restriccion de llamadas" para los terminales conectados a una caja de conexion y para los terminales de tipo softphone, unidos a esta caja, en situacion de itinerancia.

Por supuesto, es posible utilizar un campo existente para transmitir las informaciones memorizadas en este caso en el campo SIP "User Agent". Por ejemplo, es posible utilizar el campo de localizacion SIP PANI. Sin embargo, al estar su codificacion generalmente normalizada puede desaconsejarse hacerlo.

Finalmente, la informacion de localizacion suministrada en el campo "User Agent" puede obtenerse de diferente manera. En particular, se puede obtener a partir de un modulo de posicionamiento, por ejemplo un modulo GPS instalado en el terminal de tipo softphone. En este caso, la informacion de localizacion se puede explotar por el servidor de aplicacion y se pueden proponer unos servicios de geolocalizacion vinculados al que llama. Esas informaciones se pueden obtener en tiempo real antes de cada llamada saliente y suministradas en el campo SIP "User Agent" (User agent= Softphone-Latitud-Longitud).

Es igualmente concebible extender la semantica del campo SIP User Agent de manera que se afine la logica de servicio representada por el servidor de aplicacion, por ejemplo concatenando una o varias otras informaciones explotables por el servidor de aplicacion. Asi, el tipo de terminal se puede concatenar con la informacion de localizacion (tipo de terminal -localizacion). La informacion complementaria, en este caso "tipo de terminal", podria tomar, por ejemplo, uno de los valores SoftPC, SoftMac, Softlphone, SoftAndroid o TabletPC. De ese modo, a titulo de ilustracion, el o los terminales de tipo iPhone (iPhone es una marca), identificados por el valor SoftIphone, podrian tener otorgadas mas llamadas simultaneas en situacion de itinerancia que los terminales de tipo Android (Android es una marca) identificados por el valor SoftAndroid. Otra informacion podria ser el tipo de propuesta comercial utilizada por el o los diferentes terminales, pudiendo ofrecer ciertas propuestas mas servicios que otras.

Naturalmente, para satisfacer unas necesidades especificas, una persona experta en la materia podra aplicar unas modificaciones en la descripcion precedente.

Anexo

Tabla 1 (sin posibilidad de llamadas simultaneas)

2" llamada

Llamada saliente (term. clasico)

Llamada saliente (softphone, domicilio) Llamada saliente (softphone, itinerante) Llamada entrante

1" llamada

Llamada saliente (term. clasico) No No Si Si / Indicacion de llamada en el terminal ocupado (si disponible)

Llamada saliente (softphone, domicilio)

No No Si

Llamada saliente (softphone, itinerante)

Si Si Si

Llamada entrante (domicilio)

No No Si

Llamada entrante (itinerante)

Si Si Si

Tabla 2 (con posibilidad de llamadas simultaneas)

2" llamada

Llamada saliente (term. clasico)

Llamada saliente (softphone, domicilio) Llamada saliente (softphone, itinerante) Llamada entrante

1" llamada

Llamada saliente (term. clasico) Si Si Si Indicacion de llamada (si disponible)

Llamada saliente (softphone, domicilio)

Si Si Si

Llamada saliente (softphone, itinerante)

Si Si Si

Llamada entrante (domicilio)

Si Si Si

Llamada entrante (itinerante)

Si Si Si

Claims (12)

1. REIVINDICACIONES

   1. Procedimiento de gestion de servicios en un servidor de aplicacion de telefonia (135) conectado a una red de comunicacion (125), al menos una caja de conexion (110) que esta conectada a esa red de comunicacion, al menos un terminal itinerante (140) que esta directamente conectado a dicha red de comunicacion o que esta conectado a dicha red de comunicacion a traves de dicha al menos una caja de conexion, comprendiendo dicho al menos un terminal una identidad publica vinculada a dicha al menos una caja de conexion y compartida con al menos otro terminal (105) conectado a dicha al menos una caja de conexion, distinto de dicho al menos un terminal denominado primer terminal, comprendiendo este procedimiento las etapas siguientes:

   -

   recepcion (310) de al menos una solicitud de servicio desde dicho primer terminal, comprendiendo dicha al menos una solicitud de servicio una indicacion de dicha localizacion relativa de dicho primer terminal, permitiendo dicha indicacion de localizacion determinar si dicho terminal esta conectado a la red de comunicaciones directamente o bien a traves de la caja de conexion;

   -

   analisis (318, 414) de dicha al menos una solicitud de servicio segun una logica predeterminada, siendo dicha logica predeterminada funcion de una indicacion de localizacion relativa; y

   -

   en respuesta a dicha etapa de analisis, rechazo (322, 504) o implementacion (326, 520) de dicho al menos un servicio solicitado.

2. 2.

   Procedimiento segun la reivindicacion 1, segun el cual dicha al menos una solicitud de servicio es un mensaje de seralizacion de llamada, comprendiendo dicha etapa de analisis una y de comparacion de un numero de llamadas en curso vinculadas a dicha al menos una caja de conexion con un numero maximo de llamadas autorizadas segun dicha al menos una indicacion de localizacion relativa.

3. 3.

   Procedimiento segun la reivindicacion 2, siendo dicho mensaje de seralizacion un mensaje de acuerdo con el protocolo SIP, siendo transmitida dicha indicacion de localizacion relativa en un campo dedicado de dicho mensaje.

4. 4.

   Procedimiento segun la reivindicacion 1, comprendiendo el procedimiento ademas una etapa de carga de un perfil de servicios (510, 512), estando vinculado el perfil a un usuario de dicho primer terminal y a dicha indicacion de localizacion relativa.

5. 5.

   Procedimiento segun una cualquiera de las reivindicaciones precedentes, comprendiendo el procedimiento ademas una etapa de transmision (242, 422) de al menos una informacion de configuracion de dicho primer terminal, previamente a dicha etapa de recepcion de al menos una solicitud de servicio, siendo transmitida dicha al menos una informacion de configuracion en respuesta a una solicitud de activacion de dicho primer terminal (234, 414), siendo representativa dicha informacion de configuracion de dicha indicacion de localizacion relativa; siendo implementada la recepcion de dicha solicitud de activacion y dicha etapa de transmision de al menos una informacion de configuracion de dicho primer terminal en un servidor de configuracion (210, 406).

6. 6.

   Procedimiento segun la reivindicacion 5, segun el cual dicha indicacion de localizacion relativa se determina segun una direccion de origen comprendida en dicha solicitud de activacion.

7. 7.

   Procedimiento segun la reivindicacion 5, que comprende ademas una etapa de activacion inicial de dicho primer terminal, estando vinculado dicho primer terminal a dicha al menos una caja de conexion, comprendiendo dicha etapa de configuracion la creacion (240) y la transmision a dicho primer terminal de una cookie de sesion que comprende una identificacion de dicho primer terminal.

8. 8.

   Procedimiento segun la reivindicacion 7, comprendiendo el procedimiento ademas una etapa de recepcion de dicha cookie de sesion (414) y una etapa de identificacion de dicho primer terminal a partir de dicha cookie de sesion recibida.

9. 9.

   Programa de ordenador que comprende unas instrucciones adaptadas para la realizacion de cada una de las etapas del procedimiento segun una cualquiera de las reivindicaciones 1 a 4 cuando dicho programa se ejecuta en un ordenador.

10. 10.

    Programa de ordenador que comprende unas instrucciones adaptadas para la realizacion de cada una de las etapas del procedimiento segun una cualquiera de las reivindicaciones 5 a 8 cuando dicho programa se ejecuta en un ordenador.

11. 11.

    Servidor de aplicacion de telefonia que comprende unos medios adaptados para la realizacion de cada una de las etapas del procedimiento segun una cualquiera de las reivindicaciones 1 a 4.

12. 12.

    Dispositivo que comprende al menos un servidor de aplicacion de telefonia y al menos un servidor de configuracion, comprendiendo el dispositivo unos medios adaptados para la realizacion de cada una de las etapas del procedimiento segun una cualquiera de las reivindicaciones 5 a 8.