ES2305768T3 - Conexion de abonados en redes de comunicacion hibridas. - Google Patents

Abstract

Procedimiento para la conexión de abonados con al menos una red de comunicación con un primer abonado (A) y con un segundo abonado (B), que comprende las siguientes etapas: - establecer una primera conexión (SIP [A]) de señalización entre el servidor y el primer abonado y una segunda conexión (SIP [B], SS7, DSS1) de señalización entre el servidor y el segundo abonado teniendo en cuenta los datos, - combinar las dos conexiones de señalización para obtener una conexión (SIP, SS7, DSS1) de señalización continua entre los dos abonados, caracterizado porque, - se captan datos caracterizadores del primer abonado (A) y del segundo abonado (B) a través de un servidor (S), - estando configurado el servidor como aplicación web (APL) a la que se accede a través de un protocolo (HTTP) basado en Internet (IN) y/o IP, - captándose como dato caracterizador la dirección IP con la que se accede a la aplicación web.

Description

Conexión de abonados en redes de comunicación híbridas.

En el pasado se han formado dos tipos fundamentales de redes de comunicación para la transmisión de información: redes (de datos) orientadas a paquetes y redes (de voz) orientadas a línea. En el curso de la convergencia de estos dos tipos de red se han formado redes convergentes (de voz-datos). Mediante la unión de estos diferentes tipos de red se producen redes híbridas, en las que se utiliza de manera especialmente ventajosa el objeto de la presente invención.

[ROSENBERG et al., "Best Current Practices for Third Party Call Control in the Session Initiation Protocol (draft-ietf-sipping-3pcc-04)"] se refiere a un procedimiento para el control de conexión utilizando SIP (Session Initiation Protocol, protocolo de iniciación de sesión).

[ROSENBERG et al., "Third party call control in SIP"] se refiere a un control de conexión iniciado por una unidad de control utilizando el SIP.

Las redes orientadas a línea, también denominadas redes de voz o redes de telefonía, están configuradas para la transmisión de información (de voz) que fluye de manera continua que los expertos en la técnica también denominan conversación, llamada o sesión. La transmisión de la información se realiza a este respecto habitualmente con una calidad de servicio y seguridad elevadas. Por ejemplo para la voz es importante un retraso (delay) mínimo, por ejemplo < 200 ms, sin variaciones en el tiempo de retraso (Delay-Jitter, variación de retraso), ya que la voz requiere un flujo de información continuo al reproducirla en el aparato receptor. Una pérdida de información no puede compensarse por tanto mediante una nueva transmisión de la información no transmitida y en el aparato receptor lleva habitualmente a un chasquido que puede percibirse de manera acústica. Los expertos en la técnica denominan la transmisión de voz de manera generalizada también servicio (de transmisión) en tiempo real o "Realtime-Service".

Las redes orientadas a paquetes, también denominadas redes de datos, están configuradas para la transmisión de flujos de paquetes denominados por los expertos de la técnica también "flujos de paquetes de datos" o "flujo". A este respecto no tiene que garantizarse habitualmente una calidad de servicio elevada. Sin una calidad de servicio garantizada la transmisión de los flujos de paquetes de datos se realiza por ejemplo con retrasos que varían en el tiempo, ya que los paquetes de datos individuales de los flujos de paquetes de datos se transmiten habitualmente en el orden de su acceso a la red, es decir, los retrasos en el tiempo aumentan tanto más, cuantos más paquetes deban transmitirse por una red de datos. Por tanto, los expertos en la técnica también denominan la transmisión de datos servicio de transmisión sin condiciones en tiempo real o "Non-Realtime-Service", "Servicio no en tiempo real".

Los paquetes pueden estar configurados por ejemplo según el tipo de la red orientada a paquetes como paquetes de Internet, X.25 o Frame Relay, o también como células ATM. A veces también se denominan mensajes, especialmente cuando se transmite un mensaje en un paquete.

Una red de datos conocida es Internet. Esta se denomina a veces también red IP debido al protocolo IP de Internet que se utiliza en la misma, debiendo entenderse este término fundamentalmente en un contexto amplio y comprendiendo todas las redes en las que se utiliza el protocolo IP. Internet está configurada como red de datos (de tráfico de larga distancia) abierta con interfaces abiertas para la conexión de redes de datos (en la mayoría de los casos locales y regionales) de diferentes fabricantes. Proporciona una plataforma de transporte independiente del fabricante.

Las conexiones son relaciones de comunicación entre al menos dos abonados para una transmisión de información en la mayoría de los casos mutua, es decir bidireccional. El abonado que inicia la conexión se denomina habitualmente "abonado A". Un abonado conectado mediante una conexión con un abonado A se denomina "abonado B". En una red sin conexión las conexiones representan al menos la relación unívoca en un plano abstracto lógico entre el abonado A y el abonado B, es decir, según este punto de vista los flujos sin conexión en Internet representan por ejemplo conexiones abstraídas de manera lógica (por ejemplo abonado A = navegador y abonado B = servidor web). En una red orientada a conexión las conexiones representan además en un plano físico trayectos unívocos a través de la red, a lo largo de los que se transmite la información.

En el curso de la convergencia de las redes de voz y de datos se realizan servicios de transmisión de voz y cada vez más también servicios de ancho de banda mayor, tales como por ejemplo la transmisión de información de imagen movida, también en redes orientadas a paquetes, es decir, la transmisión de los servicios en tiempo real transmitidos hasta ahora habitualmente de manera orientada a línea se realiza en una red convergente, también denominada red de voz y datos, de manera orientada a paquetes, es decir, en flujos de paquetes. Estos se denominan también flujos de paquetes en tiempo real. La transmisión de información de voz a través de una red IP orientada a paquetes se designa a este respecto también con "VoIP" (Voice over IP, voz sobre IP).

En las organizaciones de normalización internacionales IETF (Internet Engineering Task Force, Grupo de Trabajo en Ingeniería de Internet) e ITU (International Telecommunications Union, Unión Internacional de Telecomunicaciones) se describen varias arquitecturas para redes de voz y datos. Todas tienen en común que el plano de control de llamada y el plano de control de recursos están claramente separados entre sí.

\newpage

El plano de control de llamada comprende a este respecto al menos un controlador de llamada (opcional) al que están asociadas entre otras cosas las siguientes funciones:

-

traducción de dirección: conversión de números de teléfono E.164 y otras direcciones alias (por ejemplo, nombres de ordenador) en direcciones de transporte (por ejemplo, direcciones de Internet).

-

Control de admisión (opcional): comprobación fundamental de admisión, si y en qué medida dispositivos (por ejemplo, compatibles con VoIP) pueden utilizar la red de comunicación.

-

Control de ancho de banda (opcional): administración de capacidades de transmisión.

-

Gestión de zona: registro de dispositivos (por ejemplo, compatibles con VoIP) y provisión de las funciones anteriores para todos los dispositivos registrados en el controlador de llamada.

De manera opcional pueden asociarse a un controlador de llamada además las siguientes funciones de caso en caso:

-

señalización de control de llamada: todos los mensajes de señalización se conmutan por al menos un controlador de llamada, es decir, todos los dispositivos envían y reciben mensajes de señalización sólo a través del controlador de llamada. Un intercambio directo de mensajes de señalización entre los dispositivos está prohibido.

-

Autorización de llamada: comprobación de admisión para llamadas entrantes y salientes.

-

Gestión de ancho de banda: control del número admisible de dispositivos que simultáneamente pueden utilizar la red de comunicación.

-

Gestión de llamada: administración de una lista de conversaciones existentes por ejemplo para poder generar una señal de ocupado, si ésta no puede generarse por el propio dispositivo.

-

Modificación de dirección alias: devolución de una dirección alias modificada, por ejemplo con un mensaje H.225.0 ACF (Admission Confirmation, confirmación de admisión). El punto final debe utilizar esta dirección en el establecimiento de la conexión.

-

Traducción de cifras marcadas: traducción de las cifras marcadas a un número de teléfono E.164 o un número a partir de un esquema de numeración privado.

El "guardián" propuesto por la ITU en la familia de estándares H.323 o el "SIP Proxy" propuesto por el IETF representan ejemplos para controladores de llamada. Si una red de comunicación mayor se divide en varios dominios, también denominados "zonas", puede preverse en cada dominio un controlador de llamada separado. Un dominio puede hacerse funcionar también sin un controlador de llamada. Si varios controladores de llamada están previstos en un dominio, sólo uno de éstos debe estar activado. Desde el punto de vista lógico un controlador de llamada debe considerarse separado de los dispositivos. Desde el punto de vista físico sin embargo no tiene que estar realizado en un dispositivo de controlador de llamada separado, sino que también puede preverse en cualquier punto final de una conexión (por ejemplo configurado como punto final H.323 o SIP, terminal, pasarela de medios, unidad de control multipunto) o también de un dispositivo configurado de manera primaria para el procesamiento de datos controlado por programa (por ejemplo: ordenadores, ordenadores personales, servidores). También es posible una realización distribuida de manera física.

El plano de control de recursos comprende al menos un controlador de recursos al que están asociadas entre otras cosas las siguientes funciones:

- Control de capacidad: control del volumen de tráfico suministrado a la red de comunicación a través de flujos de paquetes, por ejemplo mediante el control de la capacidad de transmisión de flujos de paquetes individuales.

- Activación de política (opcional): reservar recursos en la red de comunicación para su transmisión, dado el caso para un flujo de paquetes con prioridad.

- Administración de prioridad (opcional): poner características de prioridad en los paquetes según la prioridad de sus flujos de paquetes, controlar y, dado el caso, corregir, si los paquetes ya están caracterizados con prioridades.

El controlador de recursos se denomina también "Policy Decision Point (Punto de decisión de política, PDP)". Está realizado por ejemplo dentro de denominados encaminadores de borde, también denominados dispositivos de borde, nodos de acceso o en la asociación a un proveedor de servicios de Internet (PSI) también denominado encaminador de borde de proveedor (PER, Provider Edge Router). Estos encaminadores de borde pueden estar configurados también como pasarela de medios hacia otras redes con las que se conectan las redes de voz y datos. Estas pasarelas de medios están conectadas entonces tanto con una red de voz y datos como también con las otras redes y sirven internamente para la conversión entre los distintos protocolos de las diferentes redes. El controlador de recursos también puede estar configurado sólo como Proxy y retransmitir información relevante para el controlador de recursos a un dispositivo separado en el que está realizado el controlador de recursos.

La acción conjunta principal del controlador de llamada y el controlador de recursos según el protocolo de inicio de sesión (PIS) del IETF o de la familia de protocolos H.323 de la ITU se explica en el ejemplo de una configuración de llamada entre dos dispositivos VoIP configurados como terminales de abonado. A este respecto se parte en primer lugar de una red de voz y datos homogénea.

Durante o parcialmente también antes de la propia configuración de llamada al conectarse un terminal a la red IP (por ejemplo a través de un proveedor de servicios de Internet) se ejecutan las etapas autenticación, autorización e (inicio de la) contabilización. Esta denominada funcionalidad "AAA" se realiza habitualmente mediante el acceso a una base de datos de abonado, en la que todos los usuarios están almacenados con sus identificaciones, contraseñas, derechos, etc. Este acceso es lento y complejo en comparación. En las redes IP actuales de "máximo esfuerzo" ("best effort") este proceso AAA tiene lugar normalmente una vez durante la conexión del usuario. Otra autenticación se realiza en el caso de utilizar un controlador de llamada cuando el terminal se registra en el controlador de llamada del proveedor de servicios de Internet. Según la norma ITU H.323 esta autenticación o registro de un terminal se realiza en el guardián asociado según el protocolo RAS (Registration, Admission, Status (registro, admisión, estado) que está descrito en la norma ITU H.225.0.

La propia configuración de llamada empieza habitualmente con que en una primera etapa los terminales de los abonados intercambian sus capacidades (por ejemplo lista de los códec soportados) para determinar los recursos requeridos (por ejemplo ancho de banda) y la calidad de servicio (por ejemplo retraso, variación) exigida. Los terminales están configurados en la telefonía por voz por ejemplo como teléfonos IP, en el caso de vídeos en línea uno de los terminales sería un servidor de contenido o aplicación, por ejemplo en la red del proveedor de servicios de Internet.

El intercambio de los mensajes de señalización se realiza o bien de manera directa entre los terminales o bien conmutando un controlador de llamada. A este respecto se establece de manera individual en cada llamada para cada terminal y para cada sentido de transmisión qué variante utilizar. La primera variante se denomina en la terminología H.323 también "Direct Endpoint Call Signalling" (señalización de llamada de punto final directa) y la segunda "Gatekeeper Routed Call Signalling" (señalización de llamada encaminada por el guardián). En la señalización de llamada de punto final directa pueden transmitirse a un controlador de llamada, dado el caso, copias de mensajes de señalización seleccionados, de modo que con frecuencia en esta variante un controlador de llamada también tiene conocimiento de los requisitos de recursos y calidad de servicio adaptados entre los terminales. Sin embargo, éste no verifica o influye activamente en estos requisitos.

En una segunda etapa opcional el requisito de recursos y calidad de servicio adaptado de este modo puede transmitirse de manera directa por los terminales de los abonados a su controlador de recursos asociado. Tras comprobar el requisito de recursos y calidad de servicio se reenvía una confirmación (o rechazo) desde el controlador de recursos al terminal.

En una tercera etapa, también opcional, se activa una política en el encaminador de borde y, dado el caso, encaminadores adicionales en la red, con la que estos encaminadores comprueban y garantizan que el tráfico originado por el terminal se encuentra dentro de los límites que se especificaron en el requisito. Un ejemplo para un mecanismo de reserva de este tipo es RSVP (Resource ReSerVation Protocol, protocolo de reserva de recursos).

Para realizar las tres etapas se envía una pluralidad de mensajes que sólo sirven para la adaptación de los componentes implicados entre sí, pero no para la transmisión de la "propia información" entre los terminales. Esta información transmitida con los mensajes se denomina habitualmente información de señalización, datos de señalización o simplemente señalización. El término ha de entenderse a este respecto en un contexto amplio. Así están comprendidos, por ejemplo aparte de los mensajes de señalización, también los mensajes según el protocolo RAS, los mensajes según la norma ITU H.245 para el control de canales útiles de conversaciones existentes así como todos los demás mensajes configurados de manera similar. El protocolo de señalización para el establecimiento (configuración de llamada) y liberación (liberación de llamada) de conexión según la ITU se describe por ejemplo en la norma H.225.0, aquél según el IETF en el RFC 2453bis ("SIP: Session Initiation Protocol, protocolo de inicio de sesión"). La "propia información" se denomina también para diferenciarla de la señalización información útil, carga útil, información de medios, datos de medios o simplemente medios.

Las relaciones de comunicación que sirven para la transmisión de la señalización se denominan a continuación también conexiones de señalización. Las relaciones de comunicación utilizadas para la transmisión de la información útil se denominan por ejemplo conexión de voz, conexión de canal útil o, de manera simplificada, canal útil, canal de portadora o simplemente portadora.

Al combinar una red de voz y datos convergente de este tipo con una red de voz orientada a línea convencional al transmitir información más allá de los límites de las respectivas redes surgen nuevos problemas técnicos debido a las diferentes tecnologías que se utilizan en los respectivos tipos de red.

Es objetivo de la invención reconocer al menos uno de estos problemas y enriquecer el estado de la técnica al indicar al menos una solución.

La invención se plantea la cuestión de por qué la tecnología VoIP no ha conseguido hasta ahora establecerse de manera global como alternativa a redes de telefonía convencionales, orientadas a línea. Mientras que VoIP ya podía establecerse dentro de redes privadas (de empresas), en redes públicas, también denominadas Red Telefónica Pública Conmutada (RTPC), esto aún no ha tenido lugar. Es cierto que la expansión continua de denominadas aplicaciones Messenger en ordenadores usados de manera privada, también denominados ordenadores personales, permite mientras tanto también el establecimiento de conexiones de voz de ordenador a ordenador. Sin embargo, aún no están muy generalizadas llamadas telefónicas desde el ordenador a la red telefónica pública.

Un motivo de esta expansión lenta de VoIP en redes híbridas que también comprenden una red telefónica pública, se basa desde el punto de vista de la invención en la tarificación. En la transferencia de la conexión a la RTPC se producen costes para el operador de la RTPC que finalmente ha de asumir el abonado que llama. Identificar a este abonado de manera unívoca y cobrarle posteriormente los costes de su conversación es sin embargo difícil y hasta ahora aún no se ha solucionado de manera satisfactoria.

Se conoce que los abonados de VoIP se instalen un software de cliente en su ordenador y se registren con ayuda de este software a continuación en el servidor de comunicación central de su proveedor de VoIP (por ejemplo MSN, Yahoo). Debido a que habitualmente todos los usuarios de un determinado software de cliente se registran en el mismo servidor central, en comparación es fácil desde el punto de vista técnico, establecer relaciones de comunicación entre todos los abonados registrados. Puesto que estas conexiones quedan dentro de la red IP, tampoco se producen costes de llamada que deberían cobrarse a los abonados.

La situación es diferente si se desea establecer una llamada con un software de cliente de este tipo en la RTPC. El proveedor de VoIP debe guiar (encaminar) en este caso la conexión a través de una pasarela de medios a una determinada RTPC. El operador de la RTPC (operador RTPC) tiene entonces habitualmente un acuerdo de pagos con el proveedor de VoIP para cobrarle los costes de conexión que se han producido. El proveedor de VoIP pedirá a su vez el dinero del usuario del software de cliente.

Este procedimiento tiene desventajas al menos para dos de las partes implicadas:

- el operador de RTPC debe conectar su red con una pluralidad de diferentes proveedores de VoIP. Además debe establecer para cada uno de estos proveedores de VoIP un procedimiento de cobro individual. Sin embargo tampoco puede direccionar de manera directa a los abonados de VoIP, por ejemplo para anunciar su servicio o cobrar de manera directa, puesto que no tiene ninguna posibilidad fiable de identificar al abonado.

- El abonado de VoIP depende en las conexiones de RTPC de las condiciones que le ofrece su proveedor de VoIP. Esto limita la flexibilidad de los abonados de VoIP cuando el enlace con la red a través de una pasarela de medios sólo se realiza a la RTPC de uno o unos pocos operadores de RTPC. Esta limitación se intensifica cuando en un proveedor de VoIP que actúa a nivel mundial existe esta selección reducida de operadores de RTPC en muchos países.

Una solución para esta situación problemática en la que se basa la invención está indicada en las reivindicaciones de patente.

Con esta solución está asociada una pluralidad de ventajas:

- a través de la asignación de la identificación de abonado a un servidor se resuelve la configuración hasta ahora rígida, en la que la identidad de un abonado de VoIP sólo la conoce su proveedor de VoIP asociado. Esta flexibilización permite otras configuraciones, en las que según su configuración, además del proveedor de VoIP también otros pueden conocer la identidad del abonado A. Especialmente este otro puede ser también un operador de RTPC.

- A través del desplazamiento del establecimiento de la conexión de señalización a la RTPC, que hasta ahora partía del operador de VoIP a continuación del deseo de conexión del abonado A, hacia el servidor, la tarificación se desacopla por parte del proveedor de VoIP, puesto que la tarificación habitualmente se cobra al que inicia el establecimiento de una conexión, es decir, en el presente caso al operador del servidor y ya no al operador de VoIP.

- Un operador de RTPC puede captar de manera directa clientes finales para su servicio en el caso de desacoplamiento de servidor y operador de VoIP, sin depender de la colaboración con un proveedor de VoIP.

- Este desacoplamiento permite una centralización en la que están previstos menos servidores que proveedores de VoIP. En este caso se reduce el número de los servidores para los que ha de establecerse un procedimiento de cobro individual por los operadores de RTPC, por lo que se soluciona de manera ventajosa uno de los problemas reconocidos por la invención.

- En el caso de la opción hecha posible por la invención de una centralización del servidor ha de esperarse una conexión a varios operadores de RTPC debido al entonces menor número de servidores, que dado el caso además compiten entre sí, puesto que disminuye el número de conexiones y por tanto se vuelve más manejable, y la competencia beneficia la formación de una oferta amplia de operadores de RTPC como consecuencia de la diferenciación ofrecida en el mismo. Esto reduce el problema de los abonados de VoIP de estar limitados en su selección de operadores de RTPC.

Otras configuraciones ventajosas de la invención se dan a partir de las reivindicaciones dependientes o secundarias.

En el caso de la configuración del servidor como aplicación web, es decir, como programa informático, al que puede accederse de manera libre con cualquier navegador actual (por ejemplo Microsoft Internet Explorer, Netscape Communicator) mediante la indicación de un URL globalmente unívoco, se origina un desacoplamiento completo entre el acceso a la red físico de abonados y la disposición del servidor. Esto significa que en principio el servidor puede colocarse en cualquier lugar del mundo.

Cuando se capta la dirección IP de un abonado que accede a la aplicación web, ésta puede deducirse de manera automática de los paquetes IP entrantes, de modo que de manera ventajosa no es necesaria una introducción manual de la dirección IP. En este caso sólo es necesaria la captación manual de aquellos datos a través de los que se caracteriza el abonado al que se llama.

Mediante una consulta en el abonado, cuya dirección IP se conoce puede determinarse qué software de cliente se utiliza en este abonado para el uso de VoIP. Esto lleva a la ventaja de que el abonado de VoIP ya no debe instalar un software de cliente especial, tal como aún es habitual hoy en día. El abonado de VoIP ya no debe comprometerse a un determinado proveedor de VoIP e instalar su cliente en su ordenador, por lo que se compromete a los operadores de RTPC que han establecido un procedimiento de pagos con el proveedor de VoIP. Por el contrario puede elegir entre una pluralidad de operadores de RTPC el más adecuado para sus necesidades y cobrarse de manera directa por el mismo.

A través de la determinación de la identidad de un abonado, por ejemplo a través de relaciones de sus datos caracterizadores con una base de datos de registro existente puede realizarse una tarificación directa a este abonado con ayuda de los datos almacenados en la base de datos de registro. Esto se soporta preferiblemente porque se soporta el establecimiento de una portadora por el servidor y a este respecto se protocoliza la duración de tiempo de la existencia de la portadora a través de un registro de datos de tarificación. Para evitar registros de datos de tarificación inconsistentes se vigila a este respecto preferiblemente la existencia de la portadora con un mecanismo de temporizador, que puede estar configurado por ejemplo como perro guardián y que parte del servidor.

Se dan ventajas buenas cuando el servidor se asocia a un operador de RTPC. Un operador de RTPC puede cobrar en el caso ideal de manera directa a su cliente incluso los costes de llamada que se producen sin ningún registro a través de la factura de teléfono normal. Un ejemplo para ello es un abonado de VoIP que accede a través de T-DSL y T-Online al servidor VoIP de Deutsche Telekom. El servidor de Deutsche Telekom puede entonces de manera unívoca a través de la dirección IP del abonado de VoIP administrada en T-Online deducir la cuenta de teléfono de RTPC del abonado. Puede prescindirse de un procedimiento separado para la autentificación del abonado.

La invención se explica a continuación mediante ejemplos de realización adicionales que también están representados en las figuras. Muestra a este respecto:

la figura 1, una disposición para la realización del procedimiento según la invención con una red de comunicación híbrida compuesta por un Internet orientado a paquetes, una RTPC orientada a línea, una pasarela de medios y controlador de pasarela de medios interconectados así como dos puntos finales de una transmisión de informa-
ción

la figura 2, un diagrama de flujo en el que está ilustrada una realización del procedimiento según la invención a modo de ejemplo.

En la figura 1 está representada una disposición a modo de ejemplo para la realización del procedimiento según la invención. Ha de destacarse el hecho de que las realizaciones ilustradas en este caso deben entenderse a este respecto sólo a modo de ejemplo y no de manera restrictiva a pesar del detalle en parte preciso de su representación. Comprende una red de comunicación RTPC orientada a línea y una red de comunicación IN orientada a paquetes que están combinadas a través de una pasarela de medios interconectada para la conversión entre diferentes tecnologías de canal útil RTP/RTCP (Real Time [Control] Protocol, protocolo [de control] en tiempo real), y TDM (Time Division Multiplex, multiplexación por división de tiempo) específicas de la red y un controlador de pasarela de medios interconectado para la conversión entre diferentes protocolos de señalización SIP (Session Initiation Protocol, protocolo de inicio de sesión) específicos de la red y SS7 (Signalling System No. 7, sistema de señalización nº 7) para formar una red híbrida. La pasarela MG se controla a este respecto por un controlador MGC a través de un protocolo, preferiblemente normalizado a nivel internacional, por ejemplo MGCP (Media Gateway Control Protocol, protocolo de control de pasarela de medios) o H.248. La red IN está configurada preferiblemente como Internet. Para el experto en la técnica relevante es obvio a este respecto que la invención evidentemente puede utilizarse en otras redes orientadas a paquetes, tales como por ejemplo Intranet, Extranet, una red local (Local Area Network - LAN, red de área local) o una red interna de la empresa (Red corporativa) configurada por ejemplo como red privada virtual (VPN).

A la red IN está conectado un servidor S al que se accede por ejemplo con ayuda de un protocolo HTTP basado en IP. El servidor S comprende por ejemplo aplicaciones APL configuradas como producto P de programa informático, especialmente aplicaciones web que comprenden secciones de código de software para la realización soportada en procesador (múltiple) del procedimiento según la invención. Opcionalmente partes de los productos P de programa informático también pueden estar realizados a este respecto con ayuda de hardware especial (por ejemplo procesadores de señalización). Al servidor está asociada una base de datos de abonados para la identificación, el registro y/o la verificación de abonados y sus derechos, a la que se accede por ejemplo con un protocolo LDAP (Lightweight Directory Access Protocol, protocolo ligero de acceso a directorios) correspondiente.

Un primer abonado A está asociado a la red IN, un segundo abonado B a la red RTPC. El acceso a la red IN se produce con ayuda de una técnica de conexión IP conocida (por ejemplo IP over xDSL (IP sobre xDSL), controlada a través del protocolo PPP y conmutada a través de un ISP interconectado para la asignación dinámica de direcciones IP para el direccionamiento unívoco, en la mayoría de los casos limitado en el tiempo, del abonado A en la red IP), y aquél a la red RTPC con ayuda de una tecnología de conexión TDM conocida (por ejemplo RDSI, controlada a través del protocolo DSS1).

En la figura 2 está representada una realización del procedimiento según la invención en el ejemplo de una secuencia temporal a modo de ejemplo de una llamada CALL entre los dos abonados A, B con ayuda de un diagrama de flujo. En el diagrama están ilustrados mensajes normalizados (de señalización) SIP:INVITE (INVITAR), 100 TRYING
(INTENTANDO), 180 RINGING (LLAMANDO), 200 OK, SIP:ACK y SIP:BYE (ADIÓS) para el intercambio de datos de señalización entre el abonado A, el servidor S y el controlador MGC. Estos mensajes se extraen del protocolo SIP normalizado que se ha desarrollado en el IETF para el control de conexiones RTP entre puntos finales de una conexión RTP. En el presente diagrama de flujo a modo de ejemplo estos puntos finales están configurados como abonado A y pasarela MG. Para el experto en la técnica es obvio que pueden utilizarse otros protocolos de señalización, por ejemplo los de la familia de protocolo H.323, con el mismo efecto.

Como otro ejemplo de realización de la invención se realiza una acción conjunta entre el abonado A de VoIP (o su cliente C de VoIP), el servidor B, el controlador MGC, la pasarela MG, del punto final A y el abonado B de RTPC (o su teléfono T), en el que se permite a un operador de RTPC ofrecer conexiones de abonados de VoIP a abonados de RTPC de su red y tarificar de manera directa a la persona que llama de VoIP que las inicia. La configuración de red en la que se basa el ejemplo está ilustrada a este respecto en la figura 1, asumiéndose las siguientes asignaciones:

Componentes del operador de RTPC:

- La red RTPC orientada a línea

- El controlador MGC de pasarela de medios, en este caso también denominado pasarela IP-RTPC (por ejemplo un hiQ9200 de la empresa Siemens)

- Al menos una pasarela MG de medios (por ejemplo un hiG1200 de la empresa Siemens)

\vskip1.000000\baselineskip

Componentes en los que el abonado de VoIP A basa su acceso a la red IN:

- Una conexión en línea existente a través de un (su) proveedor ISP de Internet al Internet IN orientado a paquetes

- Cualquier navegador web (por ejemplo un Internet Explorer de la empresa Microsoft)

- Cualquier cliente C de VoIP instalado (por ejemplo un cliente SIP Sigma de la empresa Siemens).

Además se utiliza en este ejemplo de realización un servidor S web y/o de aplicación según la invención que preferiblemente está asociado al operador de RTPC.

En el escenario descrito el servidor S se comunica tanto con la pasarela MGC IP-RTPC como con el cliente C de VoIP del abonado A a través del protocolo SIP (Session Initiation Protocol, protocolo de inicio de sesión) normalizado. Sin embargo, el procedimiento descrito también es posible fundamentalmente en el caso de utilizar otros protocolos de señalización, por ejemplo mediante el protocolo H.323.

La realización del servidor S comprende un servidor web para soportar el protocolo HTTP y un servidor de aplicación para la realización del procedimiento según la invención. El servidor S está configurado por ejemplo como un único servidor físico (denominado servidor web/de aplicación). Ambos componentes podrían situarse igualmente en diferentes servidores interconectados entre sí.

Para establecer una conexión al abonado B de RTPC el abonado A de VoIP va en el momento START (INICIO) con su navegador mediante la indicación de un determinado URL a una página web del operador del servidor, a través de la que se realiza una superficie gráfica de la aplicación APL. El servidor S realiza a continuación opcionalmente una autentificación del abonado A. Para ello existen varias posibilidades:

- El abonado A se registra una vez en el servidor S y entonces se da de alta en cada acceso adicional al servidor S con nombre de usuario y contraseña.

- La identificación de abonado se realiza de manera automática, por ejemplo mediante la dirección IP del abonado A. La dirección IP del abonado puede reconocer el servidor S por ejemplo mediante los mensajes HTTP recibidos por el abonado A, en los que habitualmente está contenida su dirección IP como identificación de la fuente del mensaje. Esta automatización es posible por ejemplo cuando el operador de RTPC es idéntico al ISP del abonado A de VoIP o coopera con el mismo.

A continuación pueden determinarse opcionalmente por el servidor S las posibilidades técnicas con respecto a la disponibilidad del abonado A de VoIP para averiguar si, y en caso de que sí, cómo se puede llamar al cliente de VoIP. También para ello existen varias posibilidades:

- El abonado A introduce su dirección SIP en un formulario y el servidor S web/de aplicación almacena estos datos en un perfil de este abonado A que está depositado en la base de datos de abonado.

- El servidor S web/de aplicación realiza una identificación automática de cliente. Puede enviar a este respecto por ejemplo un mensaje SIP:OPTIONS al puerto 5060 del ordenador del abonado y reconocer a partir de una respuesta recibida si, y, en caso afirmativo, qué cliente C está instalado en el ordenador del abonado de VoIP A. Si no está instalado o instanciado un cliente, no puede establecerse una conexión SIP [A] de señalización. El tipo del cliente puede utilizarse para adaptar la secuencia según la figura 2 de manera correspondiente a las particularidades específicas del cliente C, por ejemplo mediante una transmisión alternativa de datos SDP.

A continuación el abonado de VoIP A introduce en su navegador en un formulario el número de llamada del abonado de RTCP B deseado. De manera alternativa el operador de RTPC puede ofrecer también un servicio de agenda de teléfono, con cuya ayuda, un simple clic sobre una determinada entrada lleva al establecimiento de la conexión entre los dos abonados A, B. El servidor S web/de aplicación determina a partir de esta información de dirección la pasarela MGC IP-RTPC relevante.

La siguiente etapa muestra una diferencia clara con respecto a conexiones de VoIP anteriores: Mientras que normalmente el abonado A (o su operador de VoIP asociado) establece una conexión (de señalización) con un abonado B, en el escenario descrito en este caso el servidor S web/de aplicación inicia dos conexiones de señalización separadas, una primera SIP [A] con el abonado de VoIP y una segunda SIP [B], SS7, DSS1 con el abonado B e interconecta éstas a continuación para obtener una conexión SIP, SS7, DSS1 de señalización continua.

A este respecto el protocolo de la segunda conexión SIP [B], SS7, DSS1 de señalización se convierte de manera conocida varias veces como consecuencia del escenario de red híbrido, y concretamente el protocolo SIP [B] que se utiliza entre el servidor y la pasarela MGC IP-RTPC, de la pasarela MGC IP-RTPC al protocolo SS7 de la red RTPC y en última instancia a continuación del nodo STP (Signalling Transfer Point, Punto de transferencia de señalización) al protocolo DSS1 de la conexión de abonado. Estas conversiones quedan ocultas para el servidor S, de modo que la segunda conexión SIP [B] SS7, DSS1 de señalización existe de manera virtual entre el servidor S y el abonado B. La pasarela MGC IP-RTPC funciona, dicho de otro modo, como proxy del abonado B con respecto al servidor S.

Además del establecimiento de una conexión SIP, SS7, DSS1 de señalización continua es necesaria la interconexión directa de una conexión de canal útil/portadora RTP, TDM entre los abonados A y B. Ésta se compone en este ejemplo por una portadora RTP orientada a paquetes en la red IN y una portadora TDM orientada a línea en la red RTPC. Los puntos finales de la portadora RTP en la red IN son a este respecto la pasarela MG de medios así como el cliente de VoIP C del abonado A, y los de la portadora TDM en la red RTPC son la pasarela MG de medios así como el teléfono T convencional del abonado B.

El servidor S web/de aplicación soporta a este respecto el intercambio mutuo de información que se requiere para el establecimiento de la portadora RTP orientada a paquetes. Este intercambio se realiza por ejemplo con ayuda del protocolo SDP (Session Description Protocol, Protocolo de Descripción de Sesión) que forma parte de SIP. A este respecto se dan unas ventajas especialmente buenas cuando se mantiene la secuencia estándar según el modelo oferta-respuesta de SIP. Esta secuencia estándar prevé que en el lado del abonado que llama se introduce un registro SDP de datos en el mensaje SIP:INVITE que entre otras cosas también contiene una lista de todos los códec que se soportan en el lado del abonado que llama (=Offer, Oferta), y que en el lado del abonado llamado se introduce un registro SDP de datos en el mensaje 200 OK, en el que se indica el códec que debe utilizarse para la siguiente llamada CALL (=Answer, Respuesta). Este soporte se explica más en detalle en el diagrama de flujo de la figura 2:

En primer lugar se envía un mensaje SIP:INVITE desde el servidor S a la pasarela MGC IP-RTPC. Si bien este mensaje ya podría contener la dirección IP del cliente C, puesto que ésta ya se conoce con el acceso al primer mensaje HTTP. Sin embargo, para un establecimiento con éxito de la portadora RTP aún falta en este momento al menos la indicación del puerto del cliente C así como la lista de los códec que se soportan por el cliente C, de modo que el mensaje SIP:INVITE no contiene un registro SDP de datos o al menos no contiene un registro SDP de datos completo.

La pasarela MGC IP-RTPC indica a continuación al servidor S, con un mensaje 100 TRYING, que se intenta localizar el abonado B, y se realiza el establecimiento conocido de la portador TDM en la red RTPC. En este contexto en la pasarela MG de medios se ocupan un puerto RTPC que lleva a la red RTPC y un puerto RTP que lleva a la red IP. La señalización entre la pasarela MGC IP-RTPC y el abonado B según el protocolo SS7, en este caso especialmente el protocolo ISUP, y el protocolo DSS1 pertenece al estado de la técnica y no se describe con más detalle. Lo mismo es válido para la señalización entre la pasarela MGC IP-RTPC y la pasarela MG de medios con los protocolos MGCP o H.248.

Tras el establecimiento con éxito de la portadora TDM se aplica el tono de llamada en la red RTPC y se transmite en la portadora TDM hasta la pasarela MG de medio. La pasarela MGC IP-RTPC envía el mensaje 180 RINGING al servidor, en el que está contenido un registro SDP [MG] de datos completo, especialmente el puerto RTP en la pasarela MG así como la lista de los códec soportados por el puerto RTP de la pasarela MG de medios.

El servidor S utiliza el registro SDP [MG] de datos paran generar un mensaje SIP:INVITE que contiene un registro SDP de datos completo en el sentido de una oferta. Este mensaje SIP:INVITE (SDP [MG]) se envía al abonado A. Dicho de otro modo: el mensaje SIP:INVITE en la dirección del abonado A se retrasa en este ejemplo de realización hasta que se reciba el registro SDP de datos [MG de la] pasarela MG de medios por el servidor S. Esta secuencia evidentemente también podría variarse según el modelo oferta/respuesta de SIP. La secuencia descrita en este caso sin embargo resulta, en la dirección del cliente C, en la secuencia estándar descrita anteriormente. Eso conlleva la ventaja especialmente buena de que esta secuencia debería soportarse por todos los clientes SIP C.

Tras la recepción del mensaje SIP:INVITE el cliente de VoIP C del abonado inicia la indicación de la llamada entrante. Esto se le indica al servidor con los mensajes 100 TRYING y 180 RINGING habituales. Una vez que el abonado A acepta la llamada, se le envía un mensaje 200 OK al servidor S. Como muy tarde en este mensaje se introduce un registro SDP [A] de datos con el que se indican entre otras cosas el puerto del cliente de VoIP C y el códec seleccionado. La portadora RTP ya puede hacerse funcionar de manera unidireccional por el cliente C en la dirección de la pasarela MG de medios.

Para una activación en la dirección contraria desde la pasarela MG de medios al cliente C es necesario además retransmitir el registro SDP [A] de datos a la pasarela MG de medios. Una vez que estos datos están retransmitidos por el servidor S a la pasarela MG de medios puede hacerse funcionar la portadora RTP de manera bidireccional. Entonces los abonados A y B pueden hablar el uno con el otro.

Una posibilidad para la retransmisión de los datos SDP [A] consiste en comunicarlos a la pasarela IP-RTPC con el mensaje SIP:ACK que se transmite como confirmación del mensaje 200 OK, con el que se indica que el abonado B ha aceptado la llamada entrante.

Otra posibilidad consiste en retransmitir los datos SDP [A] directamente tras su recepción con un mensaje SIP:xxx separado. Esto tiene la ventaja de que con la recepción de los datos SDP [A], el puerto RTP de la pasarela MG de medios puede activarse y el tono de llamada ya presente desde la red RTPC puede transmitirse también como tonos o avisos (ocupado, evento de error, etc.) al cliente C hasta que el abonado B objetivo descuelgue el teléfono.

El mensaje SIP:xxx puede estar configurado como mensaje SIP:UPDATE (ACTUALIZAR). Si bien esto representa una contravención deliberada contra el modelo oferta/respuesta, puesto que el mensaje SIP:UPATE fundamentalmente representa una oferta nueva. Sin embargo esto puede compensarse a través de una adaptación correspondiente de la pasarela MGC IP-RTPC.

De manera alternativa el mensaje SIP:xxx puede estar configurado como mensaje SIP:PRACK. Para soportar esta alternativa se le indica a este respecto en el mensaje SIP:INVITE anterior a la pasarela MGC IP-RTPC que se soportan "respuestas provisionales fiables". En este caso la pasarela MGC IP-RTPC ya transmite los datos SDP [MG] en el mensaje 180 RINGING y espera a continuación el mensaje SIP:PRACK como confirmación. En esta confirmación se introducen a continuación los datos SDP [A] recibidos por el abonado A. A este respecto se retrasa el envío del mensaje SIP:PRACK por el servidor S hasta que el mensaje 200 OK se haya recibido por el abonado A.

Como variante pueden transmitirse los datos SDP [A] independientemente de la transmisión con un mensaje SIP:xxx separado en cada caso con el mensaje SIP:ACK (SDP [A]). De este modo se soportan por el servidor S también pasarelas MG de medios cuya pasarela MGC IP-RTPC asociada no soporta la recepción de un mensaje SIP:xxx separado.

En el caso de que el abonado B descuelgue el teléfono antes de que el abonado A acepte la llamada que se le pasa, puede aplicarse, por ejemplo a través de un procedimiento de redireccionamiento de portadora, un aviso para el abonado B de que se trata de una llamada de VoIP y que se desea que el abonado B espere un momento hasta que se establezca la conexión.

Una vez que el servidor S web/de aplicación haya recibido ambos mensajes 200 OK como respuesta a los mensajes SIP:INVITE enviados, inicia la tarificación de la llamada CALL. La tarificación finaliza cuando el servidor web/de aplicación recibe un mensaje SIP:BYE por uno de los puntos finales implicados. A este respecto se escribe por ejemplo un registro de datos final para la tarificación.

Según una realización adicional de la invención se comprueba a intervalos cíclicos la existencia de la portadora RTP. De manera ventajosa puede finalizarse de este modo la tarificación en caso de una caída del software de cliente C. El protocolo SIP contiene para este fin un mecanismo temporizador de sesión que podría aplicarse por ejemplo en este caso.

Claims (15)

1. Procedimiento para la conexión de abonados con al menos una red de comunicación con un primer abonado (A) y con un segundo abonado (B), que comprende las siguientes etapas:

- establecer una primera conexión (SIP [A]) de señalización entre el servidor y el primer abonado y una segunda conexión (SIP [B], SS7, DSS1) de señalización entre el servidor y el segundo abonado teniendo en cuenta los datos,

- combinar las dos conexiones de señalización para obtener una conexión (SIP, SS7, DSS1) de señalización continua entre los dos abonados,

caracterizado porque,

- se captan datos caracterizadores del primer abonado (A) y del segundo abonado (B) a través de un servidor (S),

- estando configurado el servidor como aplicación web (APL) a la que se accede a través de un protocolo (HTTP) basado en Internet (IN) y/o IP,

- captándose como dato caracterizador la dirección IP con la que se accede a la aplicación web.

2. Procedimiento según la reivindicación anterior, en el que se determina en caso de un acceso con ayuda de una consulta direccionada con la dirección IP, especialmente con el puerto 5060, con qué software el abonado que accede al servidor transmite información en la red de comunicación.

3. Procedimiento según una de las reivindicaciones anteriores, en el que se determina la identidad de los abonados que acceden al servidor teniendo en cuenta los datos captados.

4. Procedimiento según la reivindicación anterior, en el que para la determinación de la identidad del abonado se realiza un primer registro en el que se capta la identidad de datos caracterizadores de manera unívoca.

5. Procedimiento según una de las reivindicaciones anteriores, en el que el servidor soporta el intercambio de información que es necesaria para el establecimiento de una portadora (RTP, TDM) entre los abonados.

6. Procedimiento según la reivindicación anterior, en el que la existencia de la portadora se comprueba por el servidor, preferiblemente mediante el uso de un mecanismo temporizador.

7. Procedimiento según una de las dos reivindicaciones anteriores, en el que se protocoliza por el servidor al menos un registro de datos de tarificación, a partir del que puede deducirse al menos la duración de la existencia de la portadora.

8. Procedimiento según una de las reivindicaciones anteriores, en el que el servidor está asociado a un operador de RTCP.

9. Procedimiento según las dos reivindicaciones anteriores, en el que la tarificación se realiza a través de la factura de teléfono del operador de RTCP para aquellos abonados que están asociados a la RTCP del operador.

10. Producto (P) de programa informático que comprende secciones de código de software con las que se realiza un procedimiento según una de las reivindicaciones de procedimiento anteriores a través de al menos un procesador.

11. Producto de programa informático según la reivindicación 10, configurado como cliente de VoIP o aplicación web (APL).

12. Dispositivo que comprende medios para la realización del procedimiento según una de las reivindicaciones de procedimiento anteriores.

13. Dispositivo según la reivindicación 12, configurado como servidor (S) web o de aplicación.

14. Disposición que comprende los productos de programa informático y/o dispositivos necesarios para la realización de un procedimiento según una de las reivindicaciones de procedimiento anteriores.

15. Disposición según la reivindicación 14, configurado como red (IN, RTPC, MC, MCC) de comunicación híbrida.