ES2430392T3 - Establecimiento posterior de conexiones de circuitos conmutados y de paquetes conmutados - Google Patents

Abstract

Un aparato para un primer terminal (1), configurado para: soportar conexiones en paralelo de un primer y un segundo tipo con un segundo terminal (2) como unadisposición lógica única de comunicación, estando configurado el aparato para establecer una primeraconexión del primer tipo con el segundo terminal (2) usando una dirección del primer tipo del segundo terminal(2). determinar durante la primera conexión establecida que se va a usar una conexión en paralelo del segundo tipopara proporcionar un servicio mejorado, caracterizado porque el aparato está configurado para:recibir desde el segundo terminal (2) una dirección del segundo tipo del segundo terminal (2) por medio deseñalización de paquetes conmutados de usuario a usuario, siendo la dirección del primer tipo diferente dela dirección del segundo tipo, y establecer, durante la primera conexión establecida, la conexión en paralelo del segundo tipo con elsegundo terminal (2) usando dicha dirección recibida del segundo tipo del segundo terminal.

Description

Establecimiento posterior de conexiones de circuitos conmutados y de paquetes conmutados

La presente invención se refiere al establecimiento de conexiones en un sistema de comunicaciones tal como un sistema de telefonía móvil.

La Figura 1 es un diagrama simplificado de una forma de sistema de comunicaciones. La estructura de la figura 1 está basada en la arquitectura del sistema de comunicaciones móviles UMTS de la tercera generación (3G). El sistema de la figura 3 incluye dos dispositivos de equipos de usuario o terminales (UE) 1, 2 que son capaces de comunicar por medio de una red 3. Cada uno de los terminales comunica con la red por radio, y obtienen el acceso a la red 3 a través de una red de acceso de radio (RAN) 4, 5. La red 3 proporciona dos formas de comunicaciones entre los terminales. Las conexiones de circuitos conmutados, por ejemplo para la comunicación de voz, pasan entre las redes de acceso de radio 4, 5 a través de los centros de conmutaciones móviles (MSC) 6, 7. Las conexiones de paquetes conmutados, por ejemplo para las conexiones de datos, pasan entre las redes de acceso de radio a través del nodo de soporte de GPRS en servicio (SGSN) 8, 9 y el nodo de soporte de GPRS de la puerta de enlace (GGSN) 10, 11.

Convencionalmente, cuando se va a establecer una conexión entre dos terminales, los terminales deciden sobre la base de la naturaleza de la conexión propuesta - por ejemplo la tasa de datos requerida y la cantidad de retardo que se puede tolerar - bien para establecer una conexión de paquetes conmutados o una conexión de circuitos conmutados. Algunas aplicaciones se pueden satisfacer mediante cualquier tipo de conexión. Por ejemplo, en muchas situaciones el tráfico de voz se puede realizar satisfactoriamente sobre una conexión de circuitos conmutados o una conexión de paquetes conmutados (por ejemplo, por medio de SIP o protocolo H.323). Especialmente con conexiones de paquetes conmutados los datos se puede transportar de más de una forma sobre el enlace, de modo que (por ejemplo) los datos de voz y video se podrían transportar simultáneamente. Esto proporciona un modo conveniente para implementar servicios mejorados tales como la pizarra electrónica de clic para hablar y el chat.

Sin embargo, la voz de paquetes conmutados es relativamente nueva. En la mayoría de las redes existentes el tráfico de voz se realiza casi exclusivamente sobre enlaces de circuitos conmutados ya que en los enlaces de redes de paquetes conmutados no se puede garantizar que proporcionen una calidad suficiente del servicio, por ejemplo debido a la posibilidad de que haya retardos que sean excesivos para el tráfico de voz. Se puede esperar que en las futuras redes sea posible transportar tráfico de paquetes conmutados en un nivel de servicio que permita servicios mejorados de los tipos listados anteriormente para soportar fiabilidad sobre enlaces de paquetes conmutados. Sin embargo, mientras tanto, a medida que aumenta la demanda de tales servicios mejorados, hay una necesidad de cubrir el hueco antes de que las redes de mayor capacidad estén disponibles de forma general, y permitir la provisión de tales servicios mejorados sobre redes más convencionales.

Además, incluso cuando las redes de mayor capacidad estén disponibles se puede anticipar que en muchos casos estarán disponibles canales de circuitos conmutados y de paquetes conmutados. Los inventores de la presente invención han observado que para equilibrar la utilización del ancho de banda sobre ambas partes de la red sería útil tener una flexibilidad adicional en la asignación de las conexiones para las formas disponibles de canal.

El documento EP 102 1053 desvela una disposición de terminal inalámbrico y un procedimiento de canales de transmisión de datos en una conexión multimedia que tiene una disposición en paralelo de un canal de tiempo real y un canal de paquetes no en tiempo real. El procedimiento comprende las etapas de establecimiento de la conexión por la comunicación de las capacidades de conexión entre las partes comunicantes a través de una conexión de circuitos conmutados. Si ambas partes comunicantes son capaces de mantener tanto un canal de tiempo real como un canal de paquetes no en tiempo real entonces se establecen ambas conexiones en tiempo real.

La petición de comentarios (RFC) 2916 "E.164 number DNS" de P. Falstrom, Cisco Systems Inc. de septiembre de 2000, desvela el uso del Sistema de Nombres de Dominio (DNS) para el almacenamiento de los nombres de E.164, y cómo se pueden usar los DNS para identificar servicios disponibles y la información de dirección conectada a un número de E.164.

En la reivindicación 1 se define un aparato de acuerdo con la invención y en la reivindicación 10 se define un procedimiento de acuerdo con la invención. La reivindicación 15 define un sistema de comunicaciones de acuerdo con la invención.

Las reivindicaciones dependientes definen realizaciones más específicas de la invención.

La red es preferiblemente una red de comunicaciones móviles. Los terminales son preferiblemente terminales móviles. Los terminales preferiblemente son capaces de comunicar sobre la interfaz de radio con la red. La red y/o los terminales pueden ser operables de acuerdo con los sistemas GSM, GPRS o UMTS o una derivación de los mismos. La red puede comprender una o más redes centrales.

La presente invención ser describirá ahora a modo de ejemplo con referencia a los dibujos adjuntos, en los que:

la figura 1 es un diagrama esquemático de una red de comunicaciones; la figura 2 muestra una arquitectura funcional simplificada de un terminal de equipo de usuario; la figura 3 muestra un flujo de mensajes durante el establecimiento de una sesión de comunicaciones de pizarra electrónica; la figura 4 muestra el flujo de mensajes durante la continuación de una sesión de comunicaciones; la figura 5 muestra otra arquitectura funcional simplificada de un terminal de equipo de usuario; la figura 6 muestra un flujo de mensajes durante la continuación de una sesión de comunicaciones de paquetes conmutados por una conexión de circuitos conmutados;

La presente invención se describirá a modo de ejemplo con referencia a la arquitectura de una red 3G. Sin embargo se entenderá que se puede aplicar a cualquier otra forma adecuada de red.

Numerosos servicios mejorados que los usuarios de servicios de comunicaciones están comenzando a demandar hacen uso tanto de datos de retardo altamente crítico, tal como la información de voz, como de datos de retardo asociado menos crítico. Ejemplos de tales datos de retardo menos crítico incluyen las imágenes para soportar los servicios de clic para hablar, dibujos que se comparten en los servicios de pizarra electrónica y datos de soporte sobre las acciones de los participantes para soportar los servicios de chat. En cada uno de estos casos, los datos de voz se deberían transportar normalmente con retardo mínimo, pero los datos de soporte pueden tolerar más retardo. Como se describirá más adelante, estos servicios se pueden soportar convenientemente por medio de enlaces simultáneos de circuitos conmutados y paquetes conmutados entre terminales o puntos finales comunes. Tal disposición se puede implementar en una red de la forma esquemática mostrada en la figura 1, pero con los terminales / equipos de usuario y los componentes del lado de la red que tienen la arquitectura y las capacidades descritas más adelante.

La figura 2 muestra la arquitectura funcional de un terminal adecuado para actuar como un UE 1, 2 en la arquitectura de la figura 1, y proporcionar enlaces simultáneos de circuitos conmutados y paquetes conmutados entre puntos finales comunes. El nivel superior 20 de la arquitectura es la interfaz de usuario, que maneja la interacción entre los componentes del nivel inferior y el usuario. Por debajo de la interfaz del usuario 20 está una aplicación 21 que se ejecuta sobre el terminal. En este ejemplo la aplicación es una que puede soportar servicios mejorados o de "llamada rica". Por debajo de la aplicación están las capas que formatean los datos salientes o que procesan los datos entrantes de acuerdo con los requisitos de los paquetes conmutados o circuitos conmutados. En este ejemplo, las capas de paquetes conmutados (PS) comprenden una capa superior del protocolo de internet (IP) 22 y una capa del servicio de radio general de paquetes de la puerta de enlace (G-GPRS) 23. El procesamiento de los circuitos conmutados (CS) se maneja por una capa de protocolos de CS 24. Las capas específicas de PS y CS están efectivamente en paralelo. Por debajo de las capas de PS y CS está la interfaz de radio para el CDMA de banda ancha de 3G (W-CDMA).

En la provisión de un servicio de llamada rica la aplicación de llamada rica (RCA) 21 es capaz de comunicar tanto con la funcionalidad específica de PS 22, 23 como la funcionalidad específica de CS 24. La RCA coordina el uso de las conexiones de CS y PS y proporciona una experiencia de usuario coherente a través de la interfaz de usuario cuando el servicio está en uso.

Cuando un terminal del tipo ilustrado en la figura 2 está en comunicación con otro de tales terminales por medio de un servicio de llamada rica, los usuarios de cada uno de los terminales activan las aplicaciones 21 sobre sus terminales respectivos para soportar el servicio. Las aplicaciones negocian entre sí sobre la red 3 para determinar cómo se proporciona el servicio. Una posible disposición para los terminales es acordar que los datos de retardo más crítico, tal como los datos de voz, se enviarán sobre una conexión de circuitos conmutados entre los terminales y que los datos de retardo menos crítico, tal como los datos visuales o descriptivos asociados, se enviarán sobre una conexión de paquetes conmutados entre los mismos terminales. Una vez que los terminales han establecido que ambos soportan tal disposición y han acordado proceder, los terminales establecen conexiones simultáneas de circuitos conmutados y de paquetes conmutados sobre la red, y a continuación proceden con la comunicación para proporcionar el servicio.

Un medio preferido por el que se puede proporcionar la conexión de PS es el protocolo de internet (IP). Es este caso, los terminales deberían conocer cada una de las direcciones IP de los otros y los números de puerto que se usarán para establecer la conexión combinada de CS y PS. Esta información podría comunicarse entre los terminales usando la señalización de usuario a usuario (UUS), por ejemplo. Un enfoque específico es usar el protocolo de descripción de sesión (SDP) que se define en el documento RFC-2327.

La información sobre las direcciones IP de los terminales etc. se podría enviar durante el procedimiento de establecimiento de la llamada o más tarde durante la llamada, por ejemplo si los usuarios deciden durante una llamada convencional activar un servicio mejorado. En circunstancias normales se preferiría el primer enfoque.

Se describirá un ejemplo de operación del procedimiento del establecimiento con referencia a la figura 3. El ejemplo de la figura 3 muestra el establecimiento de una sesión de pizarra electrónica entre usuarios denominados Ann (A) y Bob (B). La figura 3 muestra el terminal de A 30 y el terminal de B 31. Cada uno de los terminales incluye una aplicación de llamada rica 32, 33; una pila de IP 34, 35 para el manejo de las comunicaciones de PS; y una

disposición de procesamiento del protocolo de CS 36, 37 para el manejo de las comunicaciones de CS. Los terminales se conectan para la comunicación de CS a través del centro de conmutación móvil 38 de la red. Por simplicidad las unidades PS de la red no se muestran.

En este ejemplo se asume que ambos terminales tienen inicialmente contextos de PDP activos con direcciones de IP asignadas. De otro modo, esto se podría disponer antes de que proceda un establecimiento adicional.

En el procedimiento ilustrado en la figura 3, el terminal de Ann presenta un icono en el que Ann hace clic (en 40) para iniciar una llamada. La RCA 32 interpreta la petición y determina que sería preferible satisfacer la petición de llamada por medio de una conexión de CS. En consecuencia, el terminal 30 y el terminal 31 comunican en el modo normal como se muestra en las etapas 41 y 50 para establecer una llamada de CS entre los terminales y abrir una trayectoria para hablar usando un canal portador de CS.

Los terminales intercambian adecuadamente información de SDP entre sí a través de UUS durante el establecimiento de llamada.

A continuación Bob decide abrir una sesión de pizarra electrónica (en 51). La RCA 33 determina que preferiblemente se deberían usar conexiones en paralelo de CS y PS para satisfacer los requisitos para la voz y los datos de la pizarra electrónica. En consecuencia, la aplicación 33 señala la pila de IP 35 para iniciar la sesión de pizarra electrónica (en 52). Con el conocimiento de la dirección de IP del terminal 30, el terminal 31 señala al terminal 30 para invitarle a iniciar una sesión de pizarra electrónica sobre el enlace de PS en paralelo (en 53). La pila de IP 34 señala a la RCA 32 que se solicita una sesión de pizarra electrónica (en 54). Ann indica a través de la interfaz de usuario del terminal 30 que acepta la sesión de pizarra electrónica (en 55). La RCA 32 indica a la pila de IP que se acepta la petición (en 56) y la pila de IP 34 devuelve el mensaje de OK 200 (en 57) a la pila de IP 35, que indica (en 58) a la RCA que la sesión de pizarra electrónica está establecida. La sesión de pizarra electrónica puede continuar entonces usando un canal portador de paquetes conmutados, como se indica en 59.

Como se ilustra en la figura 4, la sesión puede continuar solicitando por Ann una reserva de sesión con Bob. Para esto, se intercambia la información de sesión como se ilustra de forma general en 60 usando un intercambio adicional de PS. Este intercambio no da como resultado una sesión / canal de comunicación en marcha de la forma ilustrada en 59.

Cuando la llamada va a terminar, Ann indica a la RCA 32 que la llamada va a terminar (en 61). La RCA indica a la pila de IP 34 que la sesión de pizarra electrónica en marcha se va a terminar (en 62) e indica a los protocolos de CS 36 que la llamada de CS va a terminar (en 62, 63). Se envían mensajes de desconexión 64, 64 en el modo normal. Los protocolos de CS 37 informan a la RCA 35 de la parte que no inició la terminación que se va a desconectar la llamada (en 66). Esa RCA 35 informa a la pila de IP 36 que la sesión de pizarra electrónica va a terminar y confirma a los protocolos de CS la desconexión de la llamada (en 67 y 68). Las confirmaciones 69, 70, 71 se envían a continuación en el modo normal. Las conexiones de CS y PS se manejan como una única disposición lógica de comunicaciones. Este enlazamiento de las conexiones significa que es sencillo para el terminal terminar una de las conexiones si se ha terminado la otra.

La aplicación del usuario final maneja el número y la naturaleza de las conexiones de forma transparente desde el punto de vista del usuario, de modo que para el usuario las conexiones se pueden constituir y terminar fácilmente incluso aunque sean de tipos diferentes.

Las figuras 5 y 6 ilustran otra disposición. En la realización de las figuras 5 y 6 los terminales A y B incluyen una capa de adaptación 80 (véase la figura 5). La capa de adaptación permite que el establecimiento de las llamadas de CS o PS sea transparente a la aplicación 81 que se está ejecutando sobre el terminal. La capa de adaptación se puede proporcionar en los terminales independientemente de cualquier aplicación que se esté ejecutando sobre los mismos. La capa de adaptación se asienta entre la aplicación y las capas de comunicación de CS y PS. Cuando la aplicación emite una petición de una conexión, la capa de adaptación interpreta esa petición y la pasa a las capas de CS y PS como sea apropiado.

La figura 6 muestra un ejemplo de una operación que se soporta por los terminales que tienen la arquitectura mostrada en la figura 5. En el ejemplo de la figura 6 se supone que los dos terminales 90 y 91 ya están en comunicación por medio de una conexión de paquetes conmutados (véase 92). Los terminales tienen las capas de aplicación 93, 94; las capas de adaptación 95, 96; las pilas de IP 97, 98 y las pilas de protocolos de circuitos conmutados 99, 100. Los terminales pueden comunicar para las llamadas de CS a través del MCS 101.

El usuario A decide iniciar una llamada de voz con el usuario B. El usuario A señala a la capa de aplicación 93 de su terminal para indicar que se debería iniciar la llamada de voz (en 102). Como los terminales ya están ocupados en una llamada de PS, en este ejemplo se supone que la capa de aplicación inicia la llamada de voz por medio de una petición (formateado para el ejemplo como se indica en la figura 6) basada en la dirección del terminal de la otra parte como sea apropiado para una conexión de PS, por ejemplo en el formato SIP (protocolo de iniciación de sesión). La capa de adaptación podría intentar iniciar la llamada de voz sobre un enlace PS. Sin embargo, en este ejemplo se asume que la capa de adaptación decide que se debería usar un portador de CS. Esta decisión se podría tomar basándose en el conocimiento de la unidad de adaptación de las capacidades de la red. Como se muestra en

la figura 6, la capa de adaptación envía un mensaje INVITE SIP a través de la pila de IP 97 al terminal B. El mensaje INVITE contiene los parámetros de SIP que indican que se debería usar un portador de CS e indica el MSISDN del terminal A (véase 103). El conocimiento de este MSISDN posibilitará al terminal B la identificación de la llamada cuando la petición de establecimiento de la llamada llegue al terminal B.

La capa de adaptación en el terminal B detecta el mensaje entrante INVITE. Como la forma del mensaje INVITE indica una petición de una llamada de CS entrante, responde con un mensaje OK 200 que incluye el MSISDN del terminal B (véase 104). El conocimiento de MSISDN del terminal B posibilitará al terminal A para llamar a ese MSISDN para establecer la llamada de CS inminente.

Cuando el mensaje OK con el MSISDN del terminal B llega al terminal A, la capa de adaptación 95 del terminal A comienza el establecimiento de una llamada al MSISDN (véase 105). La capa de adaptación 98 del terminal de recepción compara el MSISDN de la llamada entrante con la recibida en la etapa 103. Como coinciden, informa a la capa de aplicación 100 del terminal B de la llamada entrante (en 106). La capa de aplicación 100 que responde con un mensaje de aceptación 107 y en respuesta a la capa de adaptación 98 acepta la llamada de CS (en 108). La llamada de CS se establece entonces (en 109) al mismo tiempo, y entre los mismos extremos finales que la conexión de IP original 92.

El mismo procedimiento se puede usar si están involucrados proxy de SIP (o CSCF).

Se pueden usar otros medios para establecer la conexión de PS.

Si dos terminales de GPRS (servicio de radio general de paquetes) están ocupados en una llamada de circuitos conmutados, cada uno de ellos conoce el número E.164 del otro, pero ninguno conoce necesariamente la dirección de IP del otro ya que se asigna por la GGSN. En este caso, si se va a establecer a continuación una conexión de PS en paralelo con la conexión CS existente es necesario un medio para que los terminales accedan mutuamente a cada una de direcciones de IP del otro y cualquier información transversal necesaria del cortafuegos y/o proxy.

En esta situación, se puede usar el protocolo SIP (RFC - 2543), que se diseñó originalmente para llamadas de voz sobre IP, mientras que la llamada de CS está en progreso. Para determinar el URL de SIP de un usuario de CS, es preferible un mapeo definido de antemano de las identidades de E.164 a los URL de SIP. Este mapeo puede hacer uso de una lógica predefinida, o se puede almacenar como una tabla de búsqueda. Tal mapeo de direcciones se puede realizar por el proxy de SIP en la red (120 en la figura 1). Puede implementar una simple tabla de mapeo, o puede usar una base de datos más compleja que tiene que examinarse para determinar un mapeo. En la primera solución, la tabla de búsqueda podría listar el proxy de SIP correspondiente a cada número E.164, por ejemplo:

Número E.164 Proxy SIP Operador

+

358 40 sip.soneragprs.fi SONERA

+

358 41 sipgw.teliagprs.com TELIA

+

1 30 mcigprs.com MCI

En la última solución, el proxy de SIP puede proporcionar en esencia un servicio de interrogación de DNS (servicio de nombres de dominio) usando los registros SRV de DNS.

Durante una llamada de CS, los usuarios conocen la dirección de E.164 de la parte remota. La aplicación en un terminal de iniciación que va a iniciar la conexión de portadora de PS con otro terminal usa la dirección de E.164 para crear un mensaje SIP INVITE (o SIP INFO) y lo envía al proxy SIP local. El destino es el número de E.164 de la otra parte (enviado con una etiqueta para indicar que la dirección es un número de teléfono en lugar de un número de usuario) y que el proxy local use su tabla de mapeo (o un esquema más complejo) para determinar el proxy SIP del destino correspondiente. La identidad del proxy SIP de destino se devuelve al terminal de iniciación. El terminal de iniciación envía un mensaje INVITE (o INFO) a ese proxy de destino indicando la identidad de E.164 del otro terminal. El proxy de destino determina la dirección URL de SIP que se ha asignado al terminal que usa esa identidad E.164. El proxy de destino puede redirigir a continuación esa petición a dicho otro terminal por medio de su dirección de IP, y el establecimiento de la conexión de PS puede continuar generalmente como en condiciones normales. Obsérvese que el proxy de destino puede determinarse a partir del hecho de que no hay información de sesión en la carga útil del mensaje INVITE (o INFO) que el mensaje no indica un establecimiento de llamada.

Se pueden aplicar los procedimientos de facturación adecuados, por ejemplo basados en el tipo de carga útil analizada o el tamaño de los datos a transportar. Por ejemplo grandes ficheros de imagen sin comprimir pueden ser más costosos de transferir que ficheros de imágenes comprimidas más pequeños. Los proxy de SIP también pueden mantener un servicio de registro que puede aplicar diferentes funciones dependiendo de la hora del día, el tipo de carga útil, etc. Por ejemplo, un usuario puede definir que si recibe una imagen GIF y la hora es posterior a las 16:00 entonces la imagen se redirija a una dirección de correo electrónica asignada.

Como alternativa, los mensajes SIP INVITE o INFO se podrían usar por si mismos para transferir datos de usuario.

La presente invención se ha descrito con referencia específica a los sistemas UMTS y GPRS. Sin embargo, no está limitada a estos sistemas.

El solicitante llama la atención del hecho de que la presente invención puede incluir cualquier característica o combinación de características desveladas en este documento bien implícita o explícitamente o cualquier generalización de las mismas, sin limitación del alcance de cualquiera de las presentes reivindicaciones. A la vista de la descripción anterior será evidente para un experto en la materia que se pueden realizar diversas modificaciones dentro del alcance de la invención.

Claims (15)

1. REIVINDICACIONES

   1. Un aparato para un primer terminal (1), configurado para:

   soportar conexiones en paralelo de un primer y un segundo tipo con un segundo terminal (2) como una disposición lógica única de comunicación, estando configurado el aparato para establecer una primera conexión del primer tipo con el segundo terminal (2) usando una dirección del primer tipo del segundo terminal (2). determinar durante la primera conexión establecida que se va a usar una conexión en paralelo del segundo tipo para proporcionar un servicio mejorado, caracterizado porque el aparato está configurado para:

   recibir desde el segundo terminal (2) una dirección del segundo tipo del segundo terminal (2) por medio de señalización de paquetes conmutados de usuario a usuario, siendo la dirección del primer tipo diferente de la dirección del segundo tipo, y establecer, durante la primera conexión establecida, la conexión en paralelo del segundo tipo con el segundo terminal (2) usando dicha dirección recibida del segundo tipo del segundo terminal.

2. 2.

   Un aparato de acuerdo con la reivindicación 1, configurado para establecer una conexión de circuitos conmutados y una conexión de paquetes conmutados con el segundo terminal en el que la primera conexión es una conexión de circuito conmutado y la segunda conexión es una conexión de paquetes conmutados, o viceversa.

3. 3.

   Un aparato de acuerdo con la reivindicación 1 o 2, en el que el aparato está configurado para establecer las conexiones en paralelo estableciendo en primer lugar una conexión de circuito conmutado, y comunicando a continuación con el segundo terminal (2) información de la dirección de paquetes conmutados del segundo terminal.

4. 4.

   Un aparato de acuerdo con la reivindicación 1 o 2, en el que el aparato está configurado para establecer las conexiones en paralelo estableciendo en primer lugar una conexión de paquetes conmutados y comunicando a continuación la información de una dirección de circuitos conmutados por medio de la señalización de paquetes conmutados de usuario a usuario.

5. 5.

   Un aparato de acuerdo con cualquiera de las reivindicaciones anteriores en el que la dirección del segundo tipo del segundo terminal (2) es una dirección del protocolo de internet.

6. 6.

   Un aparato de acuerdo con cualquiera de las reivindicaciones de 1 a 3 o 5, en el que la dirección del segundo tipo del segundo terminal (2) es una dirección de paquetes conmutados, estando configurado el aparato para recibir información acerca de la dirección de paquetes conmutados del segundo terminal (2) por medio de la señalización de paquetes conmutados de usuario a usuario.

7. 7.

   Un aparato de acuerdo con la reivindicación 6, en el que la información acerca de la dirección de paquetes conmutados se recibe basada en un protocolo de descripción de sesión o un protocolo de iniciación de sesión.

8. 8.

   Un aparato de acuerdo con cualquiera de las reivindicaciones anteriores en el que el aparato está configurado para acceder a la información transversal de cortafuegos y/o del proxy del segundo terminal (2).

9. 9.

   Un aparato de acuerdo con cualquiera de las reivindicaciones anteriores en el que el aparato está configurado para controlar el establecimiento de la conexión del segundo tipo de forma transparente desde el usuario.

10. 10.

    Un procedimiento que comprende:

    establecer una primera conexión del primer tipo entre un primer terminal (1) y un segundo terminal (2) usando una dirección del primer tipo del segundo terminal (2), determinar durante la primera conexión establecida que se va a proporcionar un servicio mejorado usando conexiones en paralelo del primer tipo y de un segundo tipo como una única disposición lógica de comunicación entre el primer terminal (1) y el segundo terminal (2), caracterizado por:

    recibir desde el segundo terminal (2) una dirección del segundo tipo del segundo terminal (2) por medio de señalización de paquetes conmutados de usuario a usuario, siendo la dirección del primer tipo diferente de la dirección del segundo tipo, y establecer, durante la primera conexión establecida, una segunda conexión del segundo tipo entre el primer terminal (1) y el segundo terminal (2) usando una dirección del segundo tipo del segundo terminal.

11. 11.

    Un procedimiento de acuerdo con la reivindicación 10, que comprende recibir durante el primer tipo de conexión, información acerca de una dirección de paquetes conmutados del segundo terminal por medio de un protocolo de descripción de sesión o una conexión del protocolo de iniciación de sesión.

12. 12.

    Un procedimiento de acuerdo con la reivindicación 10 u 11, que comprende acceder a la información transversal del cortafuegos y/o del proxy del segundo terminal (2).

13. 13.

    Un procedimiento de acuerdo con cualquiera de las reivindicaciones de 10 a 12, que comprende en primer lugar establecer una conexión de circuito conmutado y a continuación comunicar la información de la dirección de paquetes conmutados del segundo terminal con el segundo terminal (2).

14. 14.

    Un programa de ordenador que comprende medios de código de programa, estando configurado el programa de

    5 ordenador para realizar las etapas de cualquiera de las reivindicaciones de 10 a 13 cuando el programa se ejecuta sobre un procesador.
15. 15. Un sistema de comunicaciones capaz de transportar datos por medio de un primer y un segundo tipos de conexiones, que comprende un primer terminal (1) y un segundo terminal (2), siendo capaz cada uno de los terminales (1, 2) de soportar simultáneamente una conexión de un primer tipo y una conexión de un segundo tipo

    10 con el otro terminal, en el que al menos uno de los terminales comprende un aparato de acuerdo con cualquiera de las reivindicaciones 1 a 9.