ES2737173T3 - Método y sistema para la selección en un escenario de múltiples dispositivos - Google Patents
Método y sistema para la selección en un escenario de múltiples dispositivos Download PDFInfo
- Publication number
- ES2737173T3 ES2737173T3 ES15165017T ES15165017T ES2737173T3 ES 2737173 T3 ES2737173 T3 ES 2737173T3 ES 15165017 T ES15165017 T ES 15165017T ES 15165017 T ES15165017 T ES 15165017T ES 2737173 T3 ES2737173 T3 ES 2737173T3
- Authority
- ES
- Spain
- Prior art keywords
- user
- sip
- request
- application server
- user device
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/10—Architectures or entities
- H04L65/1016—IP multimedia subsystem [IMS]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/10—Architectures or entities
- H04L65/1063—Application servers providing network services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1069—Session establishment or de-establishment
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1073—Registration or de-registration
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1101—Session protocols
- H04L65/1104—Session initiation protocol [SIP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/14—Session management
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Business, Economics & Management (AREA)
- General Business, Economics & Management (AREA)
- Telephonic Communication Services (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
Un método para determinar qué dispositivo de usuario (UD) de una pluralidad de dispositivos de usuario debe recibir una solicitud (RQ) de protocolo de inicio de sesión, SIP, para un servicio de comunicación en un sistema de telecomunicaciones, que comprende: - una pluralidad de dispositivos de usuario (UD) adaptado para ejecutar un servicio de comunicación; - un servidor de aplicación (AS) en comunicación con la pluralidad de dispositivos de usuario en los que está comprendido un registro de la pluralidad de dispositivos de usuario (UD), comprendiendo el registro asociaciones entre dispositivos de usuario e instancias de SIP, estando asociado cada dispositivo de usuario con una identidad de usuario respectiva; y, - una red de telecomunicaciones en comunicación con la pluralidad de dispositivos de usuario (UD) y con el servidor de la aplicación (AS), en donde el método comprende, en el servidor de la aplicación (AS): a) recibir una solicitud (RQ) de SIP (21, 31, 41, 51, 61) para establecer un servicio de comunicación, la solicitud de SIP prevista para una identidad de usuario de la red de telecomunicaciones; b) determinar dinámicamente (22, 32, 42, 52, 64) qué instancia de SIP debe recibir la solicitud (RQ) de SIP en base a la identidad del usuario para la cual está prevista la solicitud de SIP y los parámetros asociados con el dispositivo del usuario o la instancia de SIP en el registro, incluyendo los parámetros la capacidad de recibir una llamada de voz sobre IP (VoIP); y c) encaminar (23, 33, 35, 53, 613, 616) la solicitud (RQ) para un servicio de comunicación para el dispositivo de usuario (UD) determinado o dispositivos de usuario (UD) determinados, incluyendo el encaminamiento el envío a las instancias de SIP asociadas a los dispositivos de usuario con capacidad de voz sobre IP si la solicitud (RQ) es una llamada de voz sobre IP, y el envío a instancias de SIP de una identidad de usuario conectada a una red de circuitos conmutados si la solicitud es una llamada de voz sobre IP y no hay dispositivos de usuario con capacidad de voz sobre IP.
Description
DESCRIPCIÓN
Método y sistema para la selección en un escenario de múltiples dispositivos
Sector técnico de la invención
La presente invención está comprendida en el sector técnico de los servicios de comunicación de encaminamiento en las redes de telecomunicación. Particularmente, en el sector de la gestión de solicitudes de comunicaciones en un subsistema multimedia de IP desarrollado en una red de telecomunicaciones móviles.
La invención se refiere a la gestión de encaminamiento de una comunicación de entrada de cualquier tipo de servicio en un escenario de múltiples dispositivos, en el que los dispositivos tienen la misma identidad o una identidad diferente.
Antecedentes de la invención
En escenarios de múltiples dispositivos en un entorno de red de telecomunicaciones, los usuarios tienen varios dispositivos de usuario que ejecutan múltiples aplicaciones en cada dispositivo de usuario. Esto implica que la red de telecomunicaciones tiene que gestionar llamadas y también sesiones para cada aplicación y para cada dispositivo de usuario. Debido al uso de múltiples aplicaciones en los dispositivos de usuario, estos dispositivos de usuario pueden tener la misma identidad o identidades diferentes para cada aplicación y/o dispositivo de usuario. Por lo tanto, es necesario conseguir una solución para la gestión y el control de todas estas solicitudes de comunicación, de manera integrada.
En el estado de la técnica, los escenarios de múltiples dispositivos se gestionan aprovechando la funcionalidad de la red, es decir, la red solo implementa la lógica en función del dispositivo del usuario o de la identidad está conectada. Sin embargo, no existe un mecanismo que otorgue el control a la capa de servicio, en la la información y los servicios del usuario que el usuario soporta están disponibles para la lógica.
Actualmente hay servicios (por ejemplo, fonyou™) en los que el usuario puede tener dos números en el mismo dispositivo de usuario con una sola tarjeta SIM. Asimismo, este servicio le permite al usuario enviar llamadas de voz a varios dispositivos de usuario del mismo usuario, en base a una configuración introducida mediante una GUI (interfaz gráfica de usuario - Graphical User Interface, en inglés). Sin embargo, esto solo resuelve que el usuario puede prestar servicios relacionados con las llamadas de voz y en función del número de teléfono de cada dispositivo de usuario.
Otras soluciones que manejan este tipo de comunicación para varios dispositivos que son propiedad del mismo usuario no permiten tener la misma identidad de usuario en varios dispositivos de usuario.
El documento US 8.504.708 B2 se relaciona con un método y un sistema para puertas de enlace residenciales multimedia de IP genéricas. Una interfaz de dispositivo de cliente de capa IP común en una puerta de enlace multimedia de IP (IMG - IP Multimedia Gateway, en inglés) está configurada para conectar dispositivos de cliente a redes IP de banda ancha, tal como Internet, en base a determinadas capacidades del dispositivo. Asimismo, la IMG está configurada para permitir la comunicación entre la IMG y las redes IP de banda ancha en base a las capacidades determinadas del dispositivo.
Este documento proporciona compatibilidad de comunicación entre dispositivos con diferentes usuarios en una puerta de enlace residencial. Sin embargo, no resuelve el problema de encaminar una comunicación de entrada a varios dispositivos con la misma identidad o con una identidad diferente, con diferentes usuarios en diferentes tipos de redes de telecomunicación.
El documento EP 2.489.210 A1 se refiere a un método para permitir la entrega de un mensaje entre un dominio de IMS y un dominio de circuitos conmutados (CS - Circuit Switched, en inglés). El método recibe un mensaje de un dispositivo de usuario, que comprende un identificador de equipo y una IMPI (Identidad privada multimedia de IP -IP Multimedia Private Identity, en inglés) válidos para el usuario, y almacena la información en un servidor de la aplicación. El método realiza una asignación (mapping, en inglés) de dichos parámetros de la red IMS para encaminar los mensajes. Este método funciona para resolver el encaminamiento de los mensajes de voz y de texto, pero no resuelve el problema del encaminamiento de la voz, el video y cualquier sesión de datos que se pueda utilizar con el protocolo de inicio de sesión (SIP - Session Initiation Protocol, en inglés) a varios dispositivos que utilizan una identidad de usuario común, donde la identidad de usuario se refiere a un registro de usuarios que almacena la configuración personal, que, en el caso de un servicio de telecomunicaciones, sería la cuenta de usuario para dicho servicio. En este caso, los mensajes solo son encaminados a diferentes dispositivos según su IMSI (identidad de abonado móvil internacional - International Mobile Subscriber Identity, en inglés, es decir, la identidad de usuario pública utilizada por el IMS típico) registrada en un servidor.
El documento EP 1.886.458 B1 se refiere a un método y aparato para identificar un servicio de IMS al que se refiere un mensaje de protocolo de inicio de sesión (SIP). Uno o más identificadores de servicio de comunicación, por ejemplo, una cabecera de contacto, se agregan al mensaje de SIP como una marca de característica, la marca de
característica es un identificador de servicio de comunicación que identifica uno de una pluralidad de servicios de comunicación. Este método utiliza dichas marcas para encaminar las transacciones de SIP a un dispositivo de usuario registrado en el IMS, pero el método no proporciona compatibilidad con un dispositivo registrado con conmutación de circuitos y no se utiliza ningún campo de la transacción de SIP para decidir el encaminamiento. El documento US 20130151665 A1 se refiere al sistema y método de hojear contenido multimedia. Esta solicitud de patente describe un método para transferir una sesión de medios ya establecida a otro dispositivo de usuario, pero no encamina la sesión a un dispositivo de usuario o incluso a una aplicación antes de establecer la sesión de medios. Tampoco encamina la comunicación a una red de circuitos conmutados.
El documento EP 2.425.348 A1 se refiere a un sistema y método de procesamiento de información que proporciona un servicio combinado. Esta patente describe un método para armonizar las capacidades de diferentes dispositivos situados en diferentes redes de área local (LAN - Local Area Network, en inglés), incluida la adaptación de protocolo a través de un servicio de terceros. Este método se basa en la publicación de cada dispositivo y en las capacidades de la LAN. Este método no incluye ninguna decisión de encaminamiento, ya que cada dispositivo de usuario tiene una identidad de usuario diferente.
Por lo tanto, las soluciones del estado de la técnica no gestionan una solicitud de conexión a un dispositivo de usuario o a un conjunto de dispositivos de usuario determinados, para varios tipos de tráfico. Sería deseable encontrar un método que aumente la funcionalidad de la red. Además, ninguna de las publicaciones anteriores resuelve el problema de encaminar una solicitud en un escenario de múltiples dispositivos y múltiples aplicaciones de manera dinámica, dejando la carga de la decisión al IMS.
El documento US 2009/0150562 describe un aparato y un método asociado para dirigir las comunicaciones de una sesión de comunicación a un dispositivo de comunicación seleccionado. Una política de dirección del dispositivo se crea y almacena en una entidad de red. Se proporciona un mensaje de invitación de SIP u otra sesión de comunicación a la entidad de la red, que, a continuación, accede a la política y la reenvía en el mensaje correspondiente.
El documento US 2008/0281971 describe un método para la comunicación multimedia entre dispositivos en una red. Se puede recibir una solicitud de una sesión de comunicación en un servidor, se pueden identificar los parámetros para la sesión y se puede identificar un dispositivo para recibir la sesión de comunicación en base a los parámetros. Declaración de la invención
La presente invención proporciona una solución para la sesión de comunicación. El problema mencionado anteriormente proporciona un método para determinar un dispositivo de usuario para recibir una solicitud de un servicio de comunicación según la reivindicación 1, un servidor de la aplicación según la reivindicación 9 y un medio legible por ordenador, según la reivindicación 10.
Las reivindicaciones dependientes definen realizaciones preferidas de la invención. Todas las características descritas en esta memoria descriptiva (incluidas las reivindicaciones, la descripción y los dibujos) y/o todas las etapas del método descrito se pueden combinar en cualquier combinación adecuada, con la excepción de combinaciones de dichas características y/o etapas exclusivas entre sí.
En particular, en un primer aspecto de la invención se da a conocer un método para determinar qué dispositivo de usuario de entre una pluralidad de dispositivos de usuario debería recibir un protocolo de inicio de sesión, SIP y solicitar un servicio de comunicación en un sistema de telecomunicaciones, comprendiendo el sistema: una pluralidad de dispositivos de usuario, adaptados para ejecutar un servicio de comunicación; un servidor de la aplicación, en comunicación con la pluralidad de dispositivos de usuario, en el que está comprendido un registro de la pluralidad de dispositivos de usuario, comprendiendo el registro asociaciones entre dispositivos de usuario e instancias de SIP, estando asociado cada dispositivo de usuario con una identidad de usuario respectiva; una red de telecomunicaciones, en comunicación con la pluralidad de dispositivos de usuario y con el servidor de la aplicación, en donde el método comprende, en el servidor de la aplicación: recibir una solicitud de SIP para establecer un servicio de comunicaciones, estando destinada la solicitud SIP a una identidad de usuario de la red de telecomunicaciones; y, determinar de manera dinámica qué instancia de SIP debe recibir la solicitud de SIP en base a la identidad del usuario para el cual está destinada la solicitud de SIP y los parámetros asociados con el dispositivo de usuario o la instancia de SIP en el registro.
La solicitud de un servicio de comunicación es, por ejemplo, una llamada telefónica o una invitación para jugar a un juego de varios jugadores en línea, y puede ser enviada a un dispositivo móvil capaz de ejecutar aplicaciones para voz sobre IP o aplicaciones de juegos. En un entorno en el que múltiples dispositivos de usuario en un IMS son capaces de recibir dicha solicitud de comunicación, y siempre que la solicitud se reciba como una sesión de protocolo de inicio de sesión (SIP) y un servidor de la aplicación tenga en cuenta o comprenda un registro de la pluralidad de dispositivos de usuario, existe la posibilidad de determinar que un dispositivo de usuario reciba la comunicación, implementando las etapas de recibir y determinar.
La principal diferencia con respecto al estado de la técnica, y, por lo tanto, la principal ventaja, es que cualquier tipo de servicio SIP, tal como llamadas, mensajes de texto, video, juegos, servicios de comunicaciones enriquecidos mejorados, RCS-e (Rich Communications Services - Enhanced, en inglés), o cualquier otra sesión multimedia se pueden establecer y encaminar de manera dinámica a un dispositivo de usuario basando la decisión en parámetros no estándar, tal como las capacidades del dispositivo de usuario que actúa como receptor y las condiciones de entorno como las preferencias del usuario. En la presente invención, el término dinámico se debe entender como variable o adaptable a diferentes situaciones o requisitos.
La presente invención introduce un grado de control y flexibilidad en las comunicaciones. Un usuario puede tener las mismas características en varios dispositivos. Convencionalmente, todos los escenarios de múltiples dispositivos se realizan aprovechando la funcionalidad de la red. La presente invención es operable para implementar lógica diseñada específicamente para lógica en base a factores externos independientes de la funcionalidad de la red. En una realización del método para determinar un dispositivo de usuario para recibir una solicitud según la invención, la etapa de determinar comprende, además, determinar qué instancia de SIP debe recibir la solicitud (RQ - ReQuest, en inglés) de SIP en base a un parámetro estático asociado a un dispositivo de usuario (UD - User Device, en inglés) o a un grupo de dispositivos de usuario (UD). El parámetro estático se puede configurar por aplicación o por identidad de usuario.
En el caso de que una acción se realice de manera independiente del contexto de la situación, se toma una decisión estática que cancela o anula cualquier decisión dinámica. Esto permite, ventajosamente, decidir el destino de la solicitud dependiendo de reglas fijas.
En una realización del método para determinar un dispositivo de usuario para recibir una solicitud según la invención, los parámetros asociados con el dispositivo de usuario o instancia de SIP en el registro incluyen uno o más seleccionados de un grupo que comprende: capacidades del dispositivo de usuario (UD) asociadas a cada instancia de SIP en el registro; tecnología de soporte de comunicación del dispositivo; información contextual; y las preferencias del usuario almacenadas.
Estos parámetros se pueden elegir, ventajosamente, dependiendo de los requisitos del sistema en el que se implementa el método y, por lo tanto, permiten una versatilidad en términos de adaptación a diferentes escenarios. El método puede comprender además encaminar la solicitud (RQ) para un servicio de comunicación al dispositivo de usuario determinado (UD) o a los dispositivos de usuario determinados (UD).
Este método permite, ventajosamente, encaminar la sesión al dispositivo de usuario determinado que actúa como receptor y, en base a una respuesta, proseguir con el establecimiento del diálogo, redirigiendo la sesión a otra instancia o no hacer nada. Este método permite entregar no solo llamadas de voz, sino también cualquier sesión, tal como chat, transferencia de archivos, video compartido y llamadas de voz sobre IP (VoIP - Voice over IP, en inglés). Además, estas llamadas y sesiones de voz se pueden entregar no solo en base a los números de los diferentes dispositivos de usuario, sino también en base a las capacidades de cada dispositivo de usuario que actúan como receptores potenciales, es decir, qué tipo de sesión o aplicación pueden recibir, por lo que la libertad en la decisión del dispositivo de usuario de recepción es mayor que en el estado de la técnica. Por lo tanto, es posible decidir dónde manejar una sesión dependiendo de la capacidad, es decir, los chats deben ser enviados a un dispositivo en particular, y las llamadas, a otro dispositivo, o la transferencia de archivos, a otro diferente.
En un escenario como el que se indicó anteriormente, es posible que la solicitud de SIP llegue a un dispositivo de usuario particular asociado a la instancia de SIP para la cual está destinada la solicitud. Además, en base a la respuesta de dichas instancias de SIP, es posible continuar con el inicio de un diálogo para una llamada o juego, o bien redirigir la solicitud a otra instancia de SIP asociada con dicho servicio de comunicación en caso de que no haya disponibilidad, por ejemplo, de un juego en línea, a otro dispositivo de usuario capaz de ejecutarlo.
En un ejemplo, el método identifica los dispositivos e identifica cuáles de ellos están en línea. Tras una llamada o sesión entrante, el método permite al servidor de la aplicación decidir con qué dispositivo de usuario o instancia de SIP establecer la comunicación, teniendo en cuenta las capacidades de todos ellos. Este método permite que un usuario tenga varios dispositivos de usuario y aplicaciones con varias identidades, o varios dispositivos de usuario y aplicaciones con la misma identidad, o una combinación de ambos.
Conceptualmente, el método se puede realizar en dos etapas. La primera etapa se puede denominar registro y la segunda se puede denominar determinación.
En cuanto a la primera etapa de “registro”, el servidor de la aplicación toma conciencia de los registros de las diferentes identidades y aplicaciones del mismo usuario. Este mecanismo se realiza mediante el registro del dispositivo del usuario en un servidor de la aplicación, que forma parte del estado de la técnica, como parte de un subsistema multimedia de IP (IMS). La información relevante sobre el registro, o mensaje de registro de SIP, se puede enviar al servidor de la aplicación a través de un tercero o se puede cargar en el servidor de la aplicación de manera periódica, como una forma de actualizar el registro.
Como para la segunda etapa de “determinación”, permite al servidor de la aplicación conocer las llamadas entrantes o los servicios de comunicación, tales como las solicitudes de videoconferencias a un usuario, y, a continuación, en base a las capacidades de cada dispositivo de usuario, las identidades registradas para el usuario y las instancias de SIP asociadas del usuario, el servidor de la aplicación puede establecer la comunicación encaminando la llamada o la sesión de juego al dispositivo determinado del usuario, que se asociará a una instancia de SIP dentro del servidor de la aplicación.
La etapa de encaminamiento puede incluir el envío de la solicitud:
- al protocolo de inicio de sesión (SIP) determinado, o
- al dispositivo de usuario asociado a dicha instancia, o
- a las diversas instancias determinadas del protocolo de inicio de sesión, o a los dispositivos de usuario asociados a las mismas, si existen varias instancias de protocolo de inicio de sesión, o
- a la identidad del usuario o a las identidades del usuario conectadas a una red de conmutación de circuitos, o - a ninguno de ellos, en caso de que ninguna instancia sea capaz de ejecutar el servicio para el que está prevista la solicitud.
En este caso, se puede suponer que cada instancia de SIP puede estar asociada a más de un dispositivo de usuario, de tal manera que si una solicitud está destinada a una instancia de SIP en particular y el servidor de la aplicación encamina la solicitud a un dispositivo de usuario, en caso de que no haya disponibilidad, el dispositivo del usuario envía una respuesta de rechazo y el servidor de la aplicación puede redirigir o encaminar la solicitud a otro dispositivo de usuario asociado a la misma instancia de SIP. En este escenario, el servidor de la aplicación comprende una asociación entre instancias de SIP y más de un dispositivo de usuario. Ventajosamente, el encaminamiento es dinámico en el sentido de buscar alternativas cuando una comunicación no es posible para una determinada instancia de SIP. Esto representa una diferencia con respecto al estado de la técnica, ya que las políticas de encaminamiento se corrigen cuando se va a iniciar una sesión de SIP.
El encaminamiento se puede realizar según diferentes casos, en los que:
- la solicitud es enviada a las instancias de protocolo de inicio de sesión asociadas a los dispositivos de usuario que tienen capacidad de voz sobre IP si la solicitud es una llamada de voz sobre IP, o
- la solicitud es enviada a la instancia de protocolo de inicio de sesión para una identidad de usuario conectada a una red de circuitos conmutados si la solicitud es una llamada de voz sobre IP y no hay dispositivos de usuario disponibles con capacidad de voz sobre IP.
Ventajosamente, esto permite versatilidad en términos de redireccionar una llamada, a través de una puerta de enlace, hacia una red de circuitos conmutados. En este caso, en el servidor de la aplicación, una instancia de SIP está asociada tanto a dispositivos de usuario con capacidad de VoIP como a dispositivos de usuario que no tienen capacidad de VoIP.
El encaminamiento se puede realizar hacia todos los dispositivos de usuario con capacidades de protocolo de inicio de sesión (SIP) si se recibe una solicitud basada en el protocolo de inicio de sesión (SIP) que no sea de VoIP.
En este caso, ventajosamente, se envía una solicitud de difusión para que la decisión se pueda basar, por ejemplo, en el primer dispositivo que responde a la solicitud.
La etapa de recibir una respuesta comprende recibir una respuesta de una de las instancias de protocolo de inicio de sesión (SIP) o de un dispositivo de circuitos conmutados conectado. Ventajosamente, el método permite recibir respuestas no solo desde un escenario en los estándares de comunicación, tal como el de paquetes conmutados, sino también desde el de circuitos conmutados utilizando, por ejemplo, una puerta de enlace y la lógica adecuada en el servidor de la aplicación.
El servicio de comunicación puede ser una llamada de voz, y la etapa de recibir una respuesta comprende:
- recibir una respuesta parcial, preferiblemente uno del tipo que comprende una respuesta en formato 18X, en base a la cual el servidor de la aplicación toma una decisión, o
- recibir una respuesta final, preferiblemente una del tipo que comprende una respuesta de formato 2XX, o 3XX, 4XX o 5XX, en base a la cual el servidor de la aplicación toma una decisión.
Ventajosamente, esto permite tener una integración completa con el protocolo de SIP, de tal modo que, cuando, por ejemplo, se recibe una respuesta final que indica que la instancia de recepción de SIP está ocupada, la lógica en el servidor de la aplicación está adaptada para redirigir una llamada a otra instancia de SIP.
Si durante una solicitud de protocolo de inicio de sesión de SIP el servidor de la aplicación recibe un mensaje 302 de SIP de la instancia SIP que ha recibido la solicitud, el servidor de la aplicación puede redirigir dicha solicitud a un circuito conmutado. Esta realización permite la integración con la tecnología de circuitos conmutados, de tal manera que una llamada es redirigida a través de una puerta de enlace en caso de que no haya disponibilidad por una instancia de SIP capaz de ejecutar una llamada de VoIP.
En una realización, el método comprende terminar el establecimiento de la comunicación. A partir de este punto, la sesión de SIP continúa intercambiando datos entre el solicitante y el receptor, o el diálogo finaliza.
En una realización, el método comprende enviar un mensaje de difusión a todos los dispositivos de usuario registrados asociados con una identidad de usuario particular, y encaminar la solicitud de SIP a un dispositivo que responde al mensaje de difusión. Ventajosamente, esta capacidad se puede utilizar como una forma de acción predeterminada, en la que no se necesita ningún requisito en cuanto a las capacidades en el dispositivo de recepción; esto sería una ventaja en los casos en los que es más importante recibir la solicitud que recibirla con la mejor calidad.
En una realización, el método comprende determinar qué instancia de SIP debe recibir la solicitud (RQ) de SIP en base a un parámetro estático, incluyendo el parámetro estático uno o más parámetros seleccionados de un grupo que comprende: hora del día, fecha, difusión en todos los casos, encaminamiento por defecto configurado y tipo de identidad de usuario asociado con un dispositivo de usuario. Ventajosamente, esto permite seleccionar un tipo de encaminamiento de manera predeterminada o dependiendo de las condiciones ambientales.
El método difiere del estado de la técnica en que permite tener un escenario de múltiples dispositivos y mejora la eficiencia de la red. El método, a su vez, traslada el control hacia la capa de servicio, que comprende la información del usuario y los servicios soportados por los dispositivos de usuario asociados a las instancias de SIP en el registro, en un escenario de múltiples dispositivos, en el que se proporcionan diferentes servicios.
Ventajosamente, un servidor de la aplicación en una red de telecomunicaciones según la invención, se puede configurar para llevar a cabo el método para determinar un dispositivo de usuario para recibir una solicitud de un servicio de comunicación. Adicionalmente, el servidor puede implementar otros métodos para encaminar la solicitud recibida de un servicio de comunicación y recibir la respuesta originada en dicho encaminamiento. También se puede proporcionar un medio legible por ordenador configurado adecuadamente.
En otro aspecto de la invención se puede proporcionar un servidor de la aplicación en una red de telecomunicaciones, estando el servidor adaptado para llevar a cabo las etapas de un método según el primer aspecto de la invención.
En otro aspecto de la invención se puede proporcionar una aplicación para determinar un dispositivo de usuario para recibir una solicitud de protocolo de inicio de sesión, SIP, para un servicio de comunicación en un sistema de telecomunicaciones que comprende, comprendiendo la aplicación:
• medios para recibir una solicitud de protocolo de inicio de sesión, SIP, por parte de un servidor de la aplicación, para establecer un servicio de comunicación destinado a una identidad de usuario de una red de telecomunicaciones; y,
• medios para determinar, por parte del servidor de la aplicación, qué instancia de protocolo de inicio de sesión debe recibir la solicitud de SIP, estando basada dicha determinación en una decisión dinámica, y estando basada dicha decisión dinámica, preferiblemente, en parámetros relacionados con las capacidades de un dispositivo de usuario asociado a una instancia de SIP en el registro.
Descripción de los dibujos
Estas y otras características y ventajas de la invención se comprenderán claramente a la vista de la descripción detallada de la invención, que se hace evidente a partir de realizaciones preferidas de la invención, dadas solo como ejemplo y sin estar limitado a ellas, con referencia a los dibujos.
Figura 1 Esta figura representa una realización de la arquitectura de una red de telecomunicaciones en la que se implementa un método según la invención.
Figura 2 Esta figura representa una realización de un sistema que implementa un método en el que existe un dispositivo de usuario solicitante (26), que envía la solicitud (21) para establecer una sesión de juego con un usuario para el cual existe una identidad de usuario registrada en el servidor de la aplicación (AS - Application Server, en inglés) que comprende dos dispositivos de usuario (27, 28), ejecutándose el primer dispositivo de usuario (27) en un entorno xDSL / LAN / WiFi, y el segundo dispositivo de usuario (28) en un entorno de red de cobertura 2G.
Figura 3 Esta figura representa una realización de un sistema que implementa un método según la invención.
Existe un dispositivo de usuario solicitante (38) que envía una llamada de voz sobre IP (VoIP) a un
usuario que tiene dos dispositivos de usuario asociados con instancias de SIP en el registro: un primer dispositivo de usuario (310) en un entorno de red de cobertura 2G y un segundo dispositivo de usuario (39) que funciona bajo cobertura WiFi y es capaz de ejecutar una llamada de VoIP.
Figura 4 Esta figura representa una realización del método en el que existe un dispositivo de usuario solicitante (44) que envía una solicitud para una llamada de sesión de servicios de comunicación ricos mejorada (RSC-e), con una identidad de usuario en la que todos los dispositivos de usuario asociados a las instancias de SIP están fuera de línea.
Figura 5 Esta figura representa un diagrama de flujo de una realización del método. El diagrama de flujo representa el caso de recibir (51) una solicitud (RQ) determinar (52) y encaminar (53) según el tipo de solicitud (RQ) recibida y el entorno de la red de telecomunicación (TN - Telecommunication Network, en inglés).
Figura 6 Esta figura representa un diagrama de flujo que explica una realización del método, que comprende las siguientes etapas: recibir (61) por parte del servidor de la aplicación (AS) una solicitud (RQ) para un servicio de SIP, verificar (62) si existen dispositivos multimedia disponibles. Si no existen dispositivos multimedia disponibles, el servidor de la aplicación (AS) redirige (63) al circuito conmutado (CS), y dependiendo de la solicitud recibida, determina (64) el encaminamiento.
Descripción detallada de la invención
Una vez que el objeto de la invención ha sido esbozado, a continuación, en el presente documento, se describen realizaciones no limitativas específicas.
A modo de ejemplo, en la figura 1 se muestra la arquitectura de una red de telecomunicaciones en la que se implementa un método según la invención. Los elementos según la invención se muestran en la figura 1:
- AS: servidor de la aplicación a cargo de todas las etapas determinantes, en el que se ejecuta el método. El servidor de la aplicación comprende un registro con identidades de SIP asociadas a diferentes identidades de usuario; a su vez, las identidades de usuario están asociadas con los usuarios.
- UD: dispositivos de usuario,
- IMS: red del subsistema multimedia de IP.
Además, la red de telecomunicación de la figura 1 comprende:
- ISC: el control de servicios multimedia IP es la interfaz entre el servidor de la aplicación (AS) y la función de control de sesión de llamada (CSCF - Call Session Control Function, en inglés).
- GW: la puerta de enlace que permite la conexión entre diferentes redes.
- MGW: la puerta de enlace de medios es un dispositivo o servicio de traducción que convierte flujos de medios digitales entre distintas redes de telecomunicaciones, tales como una red telefónica pública conmutada (PSTN - Public Switched Telephone Network, en inglés). Sistema de señalización N° 7 (SS7), redes de próxima generación (redes de acceso de radio 2G, 2.5G y 3G) o centralita privada (PBX - Private Branch Exchange, en inglés).
- MSC: centro de conmutación móvil (Mobile Switching Center, en inglés) es el nodo principal de suministro de servicios para el sistema global para comunicaciones móviles / acceso múltiple por división de código (GSM / CDMA - Global System for Mobile communications / Code Division Multiple Access, en inglés), responsable de encaminar las llamadas de voz y el servicio de mensajes cortos (SMS - Short Message Service, en inglés), así como otros servicios (tal como conferencia telefónica, fax y datos de circuitos conmutados (CS - Switched Services, en inglés).
- HLR: Registro de abonados locales (Home Location Register, en inglés) es una base de datos central que comprende los detalles de cada abonador de teléfono móvil que está autorizado para utilizar la red central de GSM.
- HSS: servidor de abonados locales (Home Subscriber Server, en inglés) es una base de datos principal de usuarios que soporta las entidades de la red del subsistema multimedia de IP (IMS) y gestión de llamadas. Comprende la información relacionada con la suscripción (perfiles de abonado), realiza la autenticación y la autorización del usuario y puede proporcionar información acerca de la ubicación del abonado e información de IP.
- CSCF: la función de control de sesión de llamada se utiliza para procesar paquetes de señalización de SIP en el subsistema multimedia de IP (IMS).
- ENUM: el sistema de asignación electrónica de números permite conectar los dispositivos utilizando el estándar IP al sistema telefónico tradicional.
En una realización, un método según la invención se implementa de tal manera que los dispositivos de usuario (UD) en el sistema se registren en un servidor de la aplicación (AS) identificando la información de la instancia de SIP. En una realización, un método según la invención se implementa de tal manera que el registro de los dispositivos de usuario (UD) funciona de la siguiente manera:
La funcionalidad para saber qué instancia se registra se puede realizar implementando un registro de terceros en un nodo de función de terminación de sesión en el servidor de la aplicación (AS) con la siguiente información relevante: - Marca de instancia de SIP en el campo Cabecera de contacto, indicando el dispositivo o pila utilizado. El campo de contacto contiene la dirección en la que la persona llamada se puede comunicar con la persona que llama para futuras solicitudes. Por ejemplo, es necesario para que la persona que llama pueda enviar un ADIÓS o un re-INVITAR a la persona que llama.
- Capacidades en el aceptar cabecera de contacto indicando qué capacidades son necesarias para ser soportadas por la instancia del abonado llamado. El aceptar cabecera de contacto le permite a la persona que llama proporcionar un conjunto de funciones que expresa sus preferencias sobre las características del dispositivo que se debe alcanzar. Se combina con un conjunto de funciones proporcionadas por un dispositivo a su registrador.
El servidor de la aplicación (AS) debe almacenar el estado de la instancia del usuario y la capacidad soportada, para poder utilizar esta información para la ejecución lógica. El servidor de la aplicación (AS) debe rechazar aquellos registros provenientes de un dispositivo de usuario que indiquen una capacidad no permitida, es decir, si un dispositivo de usuario intenta registrarse con una instancia que indica VoIP y el dispositivo de usuario no soporta VoIP, el método debe rechazar el registro.
En una realización de un método según la invención, se pueden implementar los siguientes comportamientos, cuando se recibe una solicitud de servicio de comunicaciones (RQ) desde un dispositivo de usuario solicitante (UD): - Tras la recepción de una solicitud de llamada entrante (RQ), ya sea una llamada de circuitos conmutados, CS, o una llamada de voz sobre IP (VoIP), el servidor de la aplicación (AS) transmite la llamada a todos los dispositivos de usuario (UD) registrados con capacidades de VoIP. Si no existen dispositivos de usuario (UD) de VoIP registrados, el método encamina la llamada a CS; o
- En el caso de que la solicitud (RQ) de llamada entrante sea una solicitud (RQ) de llamada de VoIP, el servidor de la aplicación (AS) envía la llamada a los dispositivos de usuario de VoIP registrados. En el caso de que haya más de un dispositivo de usuario con capacidad de VoIP, y el servidor de la aplicación reciba respuestas positivas de más de uno de ellos, un método según la invención maneja las múltiples respuestas utilizando las siguientes consideraciones:
- Si el servidor de la aplicación recibe una respuesta desde cualquier dispositivo de usuario (UD), se envía una respuesta al dispositivo de usuario (UD) solicitante; o
- si el servidor de la aplicación recibe un mensaje de ocupado desde cualquier dispositivo de usuario (UD), se envía una indicación de ocupado al dispositivo de usuario (UD) solicitante; o
- si el servidor de la aplicación recibe un mensaje de no registrado desde todos los dispositivos de usuario (UD), se envía un mensaje de dispositivo no registrado al dispositivo de usuario (UD) solicitante; o - si el servidor de la aplicación recibe una respuesta de ninguna instancia, se envía una señal de cancelación al dispositivo del usuario (UD) solicitante.
- En el caso de que durante una llamada establecida con un cliente de VoIP, el servidor de la aplicación reciba un mensaje 302 que indica la redirección a CS, el método envía la llamada a CS.
- En el caso de recibir una solicitud (RQ) de sesión de RCS-e, el servidor de la aplicación envía la solicitud (RQ) a todos los dispositivos de usuario (UD) con capacidades de RCS-e. En este caso, cuando se recibe más de una respuesta de más de una instancia de SIP, se pueden realizar las mismas consideraciones que en el caso anterior para varias respuestas.
- En el caso de recibir una solicitud (RQ) de sesión de juego, el servidor de la aplicación envía la solicitud (RQ) al dispositivo del usuario (UD) con esa capacidad. La situación habitual es que solo un dispositivo de usuario (UD) tiene tal capacidad para un usuario con varias identidades de usuario, donde la identidad del usuario se refiere a una entrada de registro de usuario, el registro que almacena la configuración personal, que, en el caso de un
servicio de telecomunicación, sería la cuenta del usuario para dicho servicio, por ejemplo, una cuenta de usuario para un servicio de voz sobre IP, o para un servicio de juegos.
Los siguientes ejemplos se pueden obtener de la realización anterior; es decir, control de itinerancia, función de terminación de llamada de voz y sesiones de RCS-E, función de terminación de llamada para un usuario con voz, ya sea en un dominio CS o de IMS (cliente de VoIP), gestión de opciones en escenarios de múltiples dispositivos, gestión de múltiples pistas para juegos y gestión de escenarios de múltiples dispositivos
- Control de itinerancia
Este ejemplo muestra una realización según la etapa b) de determinación dinámica de la invención, en la que el servidor de la aplicación (AS) puede identificar si el dispositivo de usuario (UD) está en itinerancia, y comprende los siguientes aspectos:
- Si la cabecera “X - itinerancia” está incluida en la solicitud (RQ) entrante y, si el valor es “MSISDN itinerancia”, el dispositivo del usuario (UD) está en itinerancia. Si el valor es “MSISDN no itinerancia” el usuario no estará en itinerancia.
- Si la cabecera de “X - itinerancia” no está incluida, o si la MSISDN incluida en la “X - cabecera” no coincide con el destino, el servidor de la aplicación puede verificar si el usuario está en itinerancia o no.
Si el usuario está en itinerancia, el servidor de la aplicación (AS) puede verificar si la cuenta de usuario es de pospago o de prepago, para poner el prefijo correcto para enviar la llamada al sistema de prepago o al sistema de itinerancia de pospago y aplicar el cargo correspondiente en la factura del usuario.
- Función de terminación de llamada para sesiones de voz y de RCS-e
Este ejemplo muestra una realización según la etapa b) de determinación dinámica de la invención, en la que el servidor de la aplicación (AS) puede identificar si la llamada entrante es una llamada de voz de CS o una sesión de RCS-e. Esta identificación se logra verificando el campo de llamada entrante en la solicitud (RQ) de SIP, el campo conocido como campo de aceptar cabecera de contacto. Dentro del campo de aceptar cabecera de contacto, el servidor de la aplicación (AS) puede identificar que la marca incluida es la que corresponde a una sesión de RCS-e. Para llevar a cabo la etapa c) de encaminamiento a una red internacional de telecomunicaciones (TN), el servidor de la aplicación (AS) puede agregar un prefijo a URI_de_Solicitud de la llamada entrante. Por ejemplo, el prefijo puede ser 34000000001 si el destino es un número de usuario español o 340000000002 si el destino es un número de usuario internacional.
- Función de terminación de llamada para un usuario con voz en el dominio de CS o en el dominio de IMS (cliente de VoIP)
Este ejemplo muestra una realización según la etapa b) de determinación dinámica de la invención, en la que el servidor de la aplicación (AS) puede identificar si la llamada es una llamada de voz de CS o una llamada de VoIP. Esta identificación se logra verificando el parámetro en la solicitud (RQ): aceptar cabecera de contacto. Dentro de aceptar cabecera de contacto, el servidor de la aplicación (AS) puede identificar que la marca incluida es la que corresponde a una llamada de VoIP.
Para llevar a cabo la etapa c) de encaminamiento a una red de telecomunicaciones CS (TN), el servidor de la aplicación (AS) puede agregar un prefijo a la URI_de_Solicitud de la llamada entrante. Por ejemplo, este prefijo es 340000000001. Si la llamada es una llamada de VoIP, el servidor de la aplicación (AS) puede verificar si el destino tiene cobertura 2G o no. Esta información se obtiene del registro de la instancia correspondiente. No existe ninguna cabecera que indique esta información.
Si uno de los clientes de VoIP responde a la llamada, el servidor de la aplicación (AS) puede agregar una cabecera de llamada de “llamada inteligente” para identificar que un cliente de VoIP respondió a la llamada.
- Gestión de opciones en escenarios de múltiples dispositivos
Este ejemplo muestra una realización en la que la etapa de encaminamiento c) (23, 33, 35, 53, 613, 616) comprende enviar la solicitud (RQ). En este caso, el servidor de la aplicación (AS) puede recibir un mensaje de opción; el servidor de la aplicación (AS) puede identificar las instancias de entre las registradas por el usuario, y enviar la opción a cada una.
Solo se consideran las respuestas de mensajes 200 OK y que el servidor de la aplicación (AS) puede esperar hasta que todas las instancias registradas hayan respondido. El servidor de la aplicación (AS) puede enviar solo un 200 Ok con la combinación de todas las capacidades.
- Gestión de múltiples pilas para juegos
Este ejemplo muestra una realización en la que la etapa de encaminamiento c) (23, 33, 35, 53, 613, 616) comprende enviar la solicitud (RQ). En este caso, el servidor de la aplicación (AS) puede identificar si la llamada entrante es una sesión de juego. Esta identificación se puede lograr verificando la disponibilidad de aceptar cabecera de contacto y la disponibilidad de la marca de juego en la misma. En caso de que no se haya registrado ninguna instancia con esta capacidad, se envía un mensaje 480 al origen. La única información para almacenar es la estadística generada para cada sesión establecida o que se intenta establecer.
- Gestión de escenarios de múltiples dispositivos
Este ejemplo muestra una realización en la que la etapa de encaminamiento c) (23, 33, 35, 53, 613, 616) comprende enviar la solicitud (RQ) a las instancias que soportan una capacidad predeterminada y el servidor de la aplicación (AS) puede gestionar las respuestas desde las diferentes instancias.
Algunos ejemplos de consideraciones de respuesta son:
- respuesta: mensajes de 200 OK,
- ocupado: mensajes de 486 ocupado y
- usuario no registrado: mensaje de 480; este mensaje se puede identificar verificando las instancias registradas por la identidad del usuario.
En el caso de una llamada entrante, el servidor de la aplicación (AS) puede considerar que ya existen servicios que manejan servicios de múltiples dispositivos. El servidor de la aplicación (AS) puede recibir una nueva cabecera que indica que la llamada está dirigida a dispositivos específicos y, dependiendo de eso, el servidor de la aplicación (AS) puede enviar la llamada al dominio de CS o a la instancia correspondiente registrada en el dominio de IMS.
En otra realización, un servicio de voz sobre IP (VoIPSRV) está configurado en el servidor de la aplicación (AS) para encaminar las llamadas de voz a los dispositivos del usuario a través de CS normal y de las diferentes instancias de SIP que el usuario ha registrado en el servidor de la aplicación. Los dispositivos de usuario asociados a las instancias de SIP también tienen capacidades de Joyn™ y de VCOM™, que son servicios de IMS que no están diseñados para manejar este tipo de llamadas de voz. En esta realización, el usuario ha registrado diferentes instancias de SIP:
MSISDN para instance1_de_VCOM.SIP = MSISDN GRRU (VCOM)
MSISDN para instance2_de_Joyn.SIP = MSISDN GRUU (JOYN)
VoIP-PC instance3_de_client.SIP = MSISDN GRUU (VoIP)
En este caso, la identidad de usuario común es la misma para los tres casos (la identidad de usuario es la IMPU tal como se define en el RFC 3261). Lo que es diferente es la instancia de SIP o GRUU. En la mayoría de los casos, la IMPU es la propia MSISDN, que es la identidad primaria o la clave principal en la mayoría de los servicios de telecomunicaciones.
Una solicitud de llamada de VoIP llega al AS dirigido a este usuario. El AS determina que la solicitud es para el servicio VoIPSRV, por lo que la solicitud se reenvía al cliente VoIP-PC y a la identidad CS, mientras que los otros clientes nunca reciben esta solicitud.
En la figura 2 se muestra una realización de un sistema que implementa un método según la invención, que tiene la misma arquitectura descrita para la figura 1. Se muestra un dispositivo de usuario solicitante (26) que envía la solicitud (21) para establecer una sesión de juego con un usuario para el cual existe una identidad de usuario registrada en el servidor de la aplicación (AS) que comprende dos dispositivos de usuario (27, 28), ejecutándose el primer dispositivo de usuario (27) en un entorno xDSL / LAN / WiFi y el segundo dispositivo de usuario (28) en un entorno de la red de cobertura 2G.
El servidor de la aplicación (AS) recibe la solicitud (21) del dispositivo de usuario (26). El servidor de la aplicación (AS) determina (22) a qué dispositivo de usuario (27, 28) asociado a la identidad del usuario debe enviar la solicitud (21) según la solicitud de tipo (21). En esta realización, puesto que el segundo dispositivo de usuario (28) está en un entorno de red de cobertura 2G, la solicitud de juego (21) se encamina (23) al primer dispositivo de usuario (27), porque es el único dispositivo de usuario (47) que puede recibir la solicitud de sesión de juego (21).
Después de que el primer dispositivo de usuario (27) acepta la solicitud, el servidor de la aplicación (AS) recibe (24) una respuesta final 2XX del protocolo de inicio de sesión (SIP) (Respuesta satisfactoria), por ejemplo, un mensaje 200 (indicando que la solicitud tuvo éxito). Finalmente, el servidor de la aplicación (AS) envía la respuesta (25) al dispositivo del usuario solicitante (26) y finaliza el establecimiento de la comunicación. El dispositivo de usuario solicitante (26) inicia la sesión de juego con el primer dispositivo de usuario (27).
En la figura 3, se muestra una realización de un sistema que implementa un método según la invención. Existe un dispositivo de usuario solicitante (38) que envía una llamada de voz sobre IP (VoIP) a un usuario que tiene dos dispositivos de usuario asociados con instancias de SIP en el registro: un primer dispositivo de usuario (310) en un entorno de red de cobertura 2G y un segundo dispositivo de usuario (39) que funciona bajo cobertura WiFi y capaz de ejecutar una llamada de VoIP.
El servidor de la aplicación (AS) recibe la solicitud (31) del dispositivo de usuario solicitante (38). El servidor de la aplicación (AS) determina (32) el dispositivo de usuario (UD) al que se debe enviar la solicitud de llamada de VoIP. La mejor opción es, según el registro, enviar (33) la solicitud (31) al segundo dispositivo de usuario, ya que tiene capacidad de VoIP. En esta realización, puesto que el segundo dispositivo de usuario (39) está en cobertura 2G y el servidor de la aplicación (AS) recibe (34) un mensaje de ocupado desde el segundo dispositivo de usuario (39). El usuario, en esta realización, tiene una opción configurada predeterminada para lo cual, si se recibe una solicitud (31) sin importar de qué tipo, desde el dispositivo del usuario solicitante (38) de ejemplo, se deben verificar todas las identidades de usuario asociadas al usuario. Por lo tanto, el servidor de la aplicación, cuando recibe (34) la señal de ocupado del segundo dispositivo de usuario (39) redirige (35) la llamada hacia la red de CS en la que el primer dispositivo de usuario (310) está disponible para responder. A continuación, se envía una respuesta 200 positiva (36) hacia el servidor de la aplicación (AS).
Finalmente, el servidor de la aplicación (AS) responde (37) con una invitación al dispositivo del usuario solicitante (38) para que se conecte a la red de circuitos conmutados.
En la figura 4, se muestra una realización del método en la que existe un dispositivo de usuario solicitante (44) que envía una solicitud de una llamada de sesión de (RSC-e) de servicios de comunicación enriquecidos mejorados con una identidad de usuario en la que todos los dispositivos de usuario asociados a las instancias de SIP están fuera de línea.
El servidor de la aplicación (AS) recibe (41) la solicitud, desde el dispositivo de usuario solicitante (44). El servidor de la aplicación (AS) determina (42) a qué dispositivo de usuario (UD) asociado al identificador de usuario se debe enviar la solicitud (41) según el tipo de solicitud (41). En esta realización, todos los dispositivos de usuario (UD) están fuera de línea y el servidor de la aplicación (AS) envía (43) un mensaje final 4XX del protocolo de inicio de sesión (respuestas de fallo de cliente), por ejemplo, un mensaje 480 (el receptor no está disponible actualmente). En la figura 5 se representa un diagrama de flujo que muestra las etapas de un método según la invención, que comprende:
- recibir (51) una solicitud (RQ) en el servidor de la aplicación (AS),
- determinar (52) qué dispositivo de usuario puede recibir la solicitud (RQ) y, dependiendo del caso, el método continúa de la siguiente manera:
Caso 1: encaminar (53) una solicitud (RQ) dirigida a dispositivos de usuario (UD) que no tienen capacidad para recibirla, o no están disponibles para recibirla
En este caso, el servidor de la aplicación (AS) no encuentra ningún dispositivo de usuario (UD) en línea asociado a la identidad del usuario, o la solicitud (RQ) no está en la lista de aplicaciones asociada a la identidad del usuario. En este caso, el método rechaza (54) la solicitud (51) y el método finaliza (55).
Caso 2: encaminar (53) una solicitud de voz sobre IP (VoIP)
En este caso, la solicitud (51) es una solicitud (RQ) de voz sobre IP (VoIP). El servidor de la aplicación (AS) verifica (56) si hay al menos un dispositivo de usuario capaz de aceptar una solicitud (RQ) de voz sobre IP (VoIP) asociada a la identidad del usuario. En este caso, el servidor de la aplicación (AS) redirige (57) la comunicación en la red de circuitos conmutados (CS).
Cuando hay al menos un dispositivo de usuario (UD) capaz de aceptar una solicitud (RQ) de voz sobre IP (VoIP) asociada a la identidad del usuario, el servidor de la aplicación (AS) envía (58) la solicitud (RQ) a un dispositivo de usuario (UD) compatible asociado con la identidad de dicho usuario.
Posteriormente, el servidor de la aplicación recibe (59) una respuesta de al menos un dispositivo de usuario (UD) asociado a la identidad del usuario y dependiendo del tipo de respuesta:
- al recibir una respuesta final (510),
- o al recibir una respuesta parcial (511),
el servidor de la aplicación (AS)
- termina el método (55), o
- si el servidor de la aplicación (AS) recibe un mensaje 302 de SIP (512) (desplazado temporalmente), el servidor de la aplicación (AS) redirige (57) la conexión a la red de circuitos conmutados (CS), y el método termina (55). En la figura 6, se muestra un diagrama de flujo que representa una realización del método, que comprende las siguientes etapas:
i. recibir (61) por parte del servidor de la aplicación (AS), una solicitud (RQ) para un servicio de SIP;
ii. verificar (62) si hay dispositivos multimedia disponibles, si no hay dispositivos multimedia disponibles, el servidor de la aplicación (AS) redirige (63) a la red de circuitos conmutados (CS); y,
iii. determinar (64) qué tipo de servicio de comunicación se solicita. Dependiendo de la solicitud recibida, el método continúa de la siguiente manera:
Caso 1 (65): No hay dispositivos de usuario (UD) registrados que sean capaces de ejecutar dicho servicio de comunicación o aplicación
En este caso, la aplicación incluida en la solicitud (RQ) no se encuentra en el conjunto de aplicaciones registradas que la identidad del usuario ha registrado en el servidor de la aplicación (AS). En este caso, el servidor de la aplicación (AS) envía (69) una respuesta final del protocolo de inicio de sesión 4XX (respuestas de fallos de clientes), por ejemplo, un mensaje 480 (el receptor no está disponible actualmente).
Caso 2 (66): El servicio de comunicación solicitado es una sesión mejorada de servicios de comunicación enriquecidos (RCS-e)
En este caso, el servicio de comunicación que está previsto para el usuario es una sesión mejorada de servicios de comunicación enriquecidos (RSC-e). En este caso, el servidor de la aplicación (AS) verifica (610) si hay un escenario de múltiples dispositivos. A continuación, el servidor de la aplicación (AS) verifica (612) si hay algún dispositivo de usuario (UD) registrado, si no hay ningún dispositivo de usuario (UD) registrado, el servidor de la aplicación (AS) responde (69) con una respuesta final 4XX de protocolo de inicio de sesión (respuestas de fallo de cliente) al dispositivo del usuario solicitante, por ejemplo, un mensaje 480 (el receptor no está disponible actualmente).
Cuando hay al menos un usuario registrado en el servidor de la aplicación, el servidor de la aplicación (AS) envía (613) una invitación de difusión, y continúa terminando (621) el establecimiento de la comunicación y, por lo tanto, continúa con un diálogo normal entre el dispositivo del usuario solicitante y el dispositivo del usuario receptor.
Caso 3 (67): El servicio de comunicación solicitado es una sesión de juego
En este caso, el servicio de comunicación previsto para el usuario es una sesión de juego. En este caso, el servidor de la aplicación (AS) verifica (610) si hay una situación de múltiples dispositivos. A continuación, el servidor de la aplicación (AS) verifica (612) si hay algún dispositivo de usuario (UD) registrado; si no hay ningún dispositivo de usuario (UD) registrado, el servidor de la aplicación (AS) responde (69) con una respuesta final 4XX de protocolo de inicio de sesión (respuestas de fallo de cliente), por ejemplo, un mensaje 480 (el receptor no está disponible actualmente).
Si hay al menos un usuario capaz de jugar registrado en el servidor de la aplicación, el servidor de la aplicación (AS) difunde o encamina (613) una invitación a todos los dispositivos disponibles para el usuario, y continúa terminando (621) el establecimiento de la comunicación y, por lo tanto, continúa un diálogo normal entre el dispositivo del usuario solicitante y el dispositivo del usuario receptor.
Caso 4 (68): La aplicación solicitada es una sesión de voz sobre IP (VoIP)
En este caso, el servicio de comunicación previsto para el usuario es una sesión de voz sobre IP (VoIP). En este caso, el servidor de la aplicación comprueba (611) si los dispositivos de usuario disponibles funcionan solo con cobertura 2G, en cuyo caso, el servidor de la aplicación (AS) redirige (63) a la red de circuitos conmutados (CS). Cuando los dispositivos de usuario funcionan en un entorno 3G, 4G o Wifi, el servidor de la aplicación (AS) verifica (614) si hay una situación de múltiples dispositivos. Posteriormente, el servidor de la aplicación (AS) verifica (615) si hay algún dispositivo de usuario (UD) capaz de registrarse para VoIP. Si no hay un dispositivo de usuario (UD) de voz sobre IP (VoIP) registrado, el servidor de la aplicación (AS) redirige (63) a la red de circuitos conmutados (CS). En el caso de que haya al menos un dispositivo de usuario (UD) con capacidad de VoIP registrado en el servidor de la aplicación, el servidor de la aplicación (AS) difunde o encamina (616) la solicitud (RQ) a todos ellos, y recibe (617) una respuesta. Si el servidor de la aplicación (AS) recibe una respuesta final 3XX del protocolo de inicio de sesión (respuestas de redirección) de al menos un dispositivo de usuario (UD), por ejemplo, un mensaje 302 (desplazado temporalmente), en este caso el servidor de la aplicación (AS) redirige (618) la conexión a la red de circuitos conmutados.
Cuando el servidor de la aplicación (AS) recibe (619) una respuesta final 2XX del protocolo de inicio de sesión respuesta con éxito), por ejemplo un mensaje 200 (indica que la solicitud tuvo éxito), el servidor de la aplicación (AS) agrega la cabecera “llamada inteligente” (320) y continúa terminando (621) el establecimiento de la comunicación y, por lo tanto, continúa un diálogo normal entre el dispositivo del usuario solicitante y el dispositivo del usuario receptor.
En el caso de que el servidor de la aplicación no haya recibido una respuesta 2XX de protocolo de inicio de sesión (respuesta con éxito), el servidor de la aplicación (AS) continúa (621) el establecimiento de la comunicación y, por lo tanto, determina la sesión, ya que no ha sido posible ninguna comunicación.
Adicionalmente, la decisión de qué dispositivo debe recibir la solicitud se puede basar en preferencias configurables, por ejemplo, en caso de “sábado”, redirigir todas las llamadas al dispositivo de usuario personal y no a un dispositivo de usuario de trabajo). Además, por ejemplo: si todo lo demás no conduce a una decisión de encaminamiento, abandona la llamada. Los parámetros pueden ser configurables por aplicación o por abonado.
La presente invención se enfoca en el encaminamiento de los mensajes o transacciones de SIP, la invención no se ocupa de las sesiones.
En los métodos actuales a modo de ejemplo, la propia aplicación puede utilizar el mensaje REGISTRO de SIP para indicar las capacidades propias. Esto se puede hacer de manera explícita o implícita (en base a parámetros tales como el agente de usuario). Solo en función de esta información y del mensaje de SIP que se transmitirá, el AS decide qué punto final recibirá el mensaje.
Como ejemplo, un método según la invención comprende determinar qué instancia de SIP debe recibir la solicitud (RQ) de SIP en base a un parámetro estático, el parámetro estático es la hora del día; es decir, de 1 pm a 2 pm durante los fines de semana, un usuario puede preferir hacer una parada para almorzar en el trabajo, de modo que cada llamada o cada solicitud de un servicio de telecomunicación proveniente de contactos relacionados con la empresa puede ser rechazada, y cada llamada personal puede ser redirigida a la instancia de usuario asociada a un dispositivo de usuario personal. Esto implicaría la utilización del tipo de identidad personal del usuario asociada con un dispositivo personal del usuario.
Por ejemplo, otro parámetro estático sería el tipo de servicio solicitado, esto es, si las preferencias del usuario incluyen recibir una videollamada siempre en el mismo dispositivo, independientemente de la determinación del AS, la videollamada se enviará al dispositivo seleccionado de manera estática.
Claims (10)
1. Un método para determinar qué dispositivo de usuario (UD) de una pluralidad de dispositivos de usuario debe recibir una solicitud (RQ) de protocolo de inicio de sesión, SIP, para un servicio de comunicación en un sistema de telecomunicaciones, que comprende:
- una pluralidad de dispositivos de usuario (UD) adaptado para ejecutar un servicio de comunicación;
- un servidor de aplicación (AS) en comunicación con la pluralidad de dispositivos de usuario en los que está comprendido un registro de la pluralidad de dispositivos de usuario (UD), comprendiendo el registro asociaciones entre dispositivos de usuario e instancias de SIP, estando asociado cada dispositivo de usuario con una identidad de usuario respectiva; y,
- una red de telecomunicaciones en comunicación con la pluralidad de dispositivos de usuario (UD) y con el servidor de la aplicación (AS),
en donde el método comprende, en el servidor de la aplicación (AS):
a) recibir una solicitud (RQ) de SIP (21, 31, 41, 51, 61) para establecer un servicio de comunicación, la solicitud de SIP prevista para una identidad de usuario de la red de telecomunicaciones;
b) determinar dinámicamente (22, 32, 42, 52, 64) qué instancia de SIP debe recibir la solicitud (RQ) de SIP en base a la identidad del usuario para la cual está prevista la solicitud de SIP y los parámetros asociados con el dispositivo del usuario o la instancia de SIP en el registro, incluyendo los parámetros la capacidad de recibir una llamada de voz sobre IP (VoIP); y
c) encaminar (23, 33, 35, 53, 613, 616) la solicitud (RQ) para un servicio de comunicación para el dispositivo de usuario (UD) determinado o dispositivos de usuario (UD) determinados, incluyendo el encaminamiento el envío a las instancias de SIP asociadas a los dispositivos de usuario con capacidad de voz sobre IP si la solicitud (RQ) es una llamada de voz sobre IP, y el envío a instancias de SIP de una identidad de usuario conectada a una red de circuitos conmutados si la solicitud es una llamada de voz sobre IP y no hay dispositivos de usuario con capacidad de voz sobre IP.
2. Un método según la reivindicación 1, en el que la etapa b) (22, 32, 42, 52, 64) nos obliga a determinar qué instancia de SIP debe recibir la solicitud (RQ) de SIP en base a un parámetro estático asociado a un dispositivo de usuario (UD) o aun grupo de dispositivos de usuario (UD).
3. Un método según la reivindicación 2, en el que el parámetro estático es configurable por aplicación o por identidad de usuario.
4. Un método según cualquiera de las reivindicaciones anteriores, en el que el parámetro estático incluye uno o más parámetros seleccionados de un grupo que comprende: hora del día, fecha, encaminamiento predeterminado configurado y tipo de identidad de usuario asociada con un dispositivo de usuario.
5. Un método según cualquiera de las reivindicaciones anteriores, en el que los parámetros asociados con el dispositivo de usuario o instancia de SIP en el registro incluyen, además, uno o más seleccionados de un grupo que comprende:
• capacidades del dispositivo de usuario (UD) asociado a cada instancia de SIP en el registro;
• tecnología portadora de comunicación del dispositivo de usuario actual;
• información contextual; y,
• preferencias de usuario almacenadas.
6. Método según la reivindicación 1, en el que la etapa de encaminamiento c) (23, 33, 35, 53, 613, 616) comprende enviar la solicitud (RQ):
- a la instancia determinada del protocolo de inicio de sesión (SIP), o
- si hay varias instancias de protocolo de inicio de sesión (SIP), enviar la solicitud (RQ) a varias instancias determinadas del protocolo de inicio de sesión (SIP), o a los dispositivos de usuario (UD) asociados, o - a la identidad de usuario o a las identidades de usuario (Ul) conectadas a una red de circuitos conmutados (CS), o
- a ninguno de ellos, en caso de que ninguna instancia sea capaz de ejecutar el servicio para el que está destinada la solicitud (RQ).
7. Un método según cualquiera de las reivindicaciones anteriores, que comprende, además, finalizar (55, 621) el establecimiento de la comunicación en base a los parámetros.
8. Un método según cualquiera de las reivindicaciones anteriores, que comprende, además, enviar un mensaje de difusión a todos los dispositivos de usuario registrados asociados con una identidad de usuario particular, y encaminar la solicitud de SIP a un dispositivo que responde al mensaje de difusión.
9. Un servidor de la aplicación comprendido en una red de telecomunicaciones, estando adaptado el servidor para realizar las etapas de las reivindicaciones 1 a 8.
10. Un medio legible por ordenador, que comprende una instrucción que, cuando es ejecutada por un ordenador, hace que el ordenador lleve a cabo las etapas de las reivindicaciones 1 a 8.
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| ES201430614 | 2014-04-25 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2737173T3 true ES2737173T3 (es) | 2020-01-10 |
Family
ID=53191470
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES15165017T Active ES2737173T3 (es) | 2014-04-25 | 2015-04-24 | Método y sistema para la selección en un escenario de múltiples dispositivos |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US20150312281A1 (es) |
| EP (1) | EP2938041B1 (es) |
| ES (1) | ES2737173T3 (es) |
Families Citing this family (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR102218693B1 (ko) * | 2014-01-02 | 2021-02-22 | 삼성전자주식회사 | 복수의 심 정보 처리 방법 및 그 전자 장치 |
| US10448241B2 (en) * | 2015-05-07 | 2019-10-15 | Huawei Technologies Co., Ltd. | Service processing method, and user equipment |
| US11659012B2 (en) * | 2015-06-15 | 2023-05-23 | Apple Inc. | Relayed communication channel establishment |
| US10904343B2 (en) * | 2015-07-07 | 2021-01-26 | T-Mobile Usa, Inc. | Message delivery based on subsets of network identities |
| US10476920B2 (en) * | 2017-05-31 | 2019-11-12 | T-Mobile Usa, Inc. | Enhanced telephony application server session management |
| US10958706B2 (en) | 2018-11-02 | 2021-03-23 | Infinite Convergence Solutions, Inc. | Devices and method for voice over internet protocol call continuity |
| US20230098402A1 (en) * | 2020-02-03 | 2023-03-30 | Nokia Solutions And Networks Oy | Providing multi-device service using network application programming interface |
Family Cites Families (19)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6985961B1 (en) * | 2001-12-04 | 2006-01-10 | Nortel Networks Limited | System for routing incoming message to various devices based on media capabilities and type of media session |
| WO2003103259A1 (ja) * | 2002-05-31 | 2003-12-11 | ソフトバンク株式会社 | 端末接続装置、接続制御装置及び多機能電話端末 |
| US7305681B2 (en) * | 2003-03-20 | 2007-12-04 | Nokia Corporation | Method and apparatus for providing multi-client support in a sip-enabled terminal |
| EP1886458B2 (en) | 2005-05-25 | 2016-03-02 | Optis Wireless Technology, LLC | Method and apparatus for identifying an ims service |
| US9100408B2 (en) * | 2006-05-02 | 2015-08-04 | Telefonaktiebolaget L M Ericsson (Publ) | Method for registering multi-contact devices |
| CN101072251A (zh) * | 2006-05-08 | 2007-11-14 | 松下电器产业株式会社 | 通话方法、装置及系统 |
| US20080281971A1 (en) * | 2007-05-07 | 2008-11-13 | Nokia Corporation | Network multimedia communication using multiple devices |
| US20090052442A1 (en) * | 2007-08-20 | 2009-02-26 | International Business Machines Corporation | Automatically routing session initiation protocol (sip) communications from a consumer device |
| US20090150562A1 (en) * | 2007-12-07 | 2009-06-11 | Research In Motion Limited | Apparatus and method for directing a communication session to a communication device of a group of devices having a common registration identity |
| US8724619B2 (en) * | 2007-12-31 | 2014-05-13 | Apple Inc. | Transparently routing a telephone call between mobile and VOIP services |
| US8417786B2 (en) * | 2008-09-23 | 2013-04-09 | Research In Motion Limited | Methods and systems for aggregating presence information to provide a simplified unified presence |
| ES2355561B1 (es) * | 2008-11-07 | 2012-02-02 | Vodafone España, S.A.U. | Establecimiento de llamada en una red de comunicacion |
| EP2425348A4 (en) | 2009-05-01 | 2015-09-02 | Ericsson Telefon Ab L M | SYSTEM AND METHOD FOR PROCESSING INFORMATION PROVIDING COMPOUND SERVICE |
| WO2011046476A1 (en) | 2009-10-14 | 2011-04-21 | Telefonaktiebolaget Lm Ericsson (Publ) | Method for enabling delivery of a message between an ims domain and a cs domain |
| US8504708B2 (en) | 2010-07-01 | 2013-08-06 | Broadcom Corporation | Method and system for generic IP multimedia residential gateways |
| US9350769B2 (en) * | 2011-03-10 | 2016-05-24 | Genband Us Llc | SIP device-level call/session/service management |
| US9374613B2 (en) | 2011-12-07 | 2016-06-21 | Verizon Patent And Licensing Inc. | Media content flicking systems and methods |
| GB201122387D0 (en) * | 2011-12-28 | 2012-02-08 | Vodafone Espana Sau | Establishing international calls |
| US9372963B2 (en) * | 2012-08-30 | 2016-06-21 | Verizon Patent And Licensing Inc. | User device selection |
-
2015
- 2015-04-24 US US14/695,475 patent/US20150312281A1/en not_active Abandoned
- 2015-04-24 ES ES15165017T patent/ES2737173T3/es active Active
- 2015-04-24 EP EP15165017.3A patent/EP2938041B1/en active Active
Also Published As
| Publication number | Publication date |
|---|---|
| EP2938041B1 (en) | 2019-06-12 |
| US20150312281A1 (en) | 2015-10-29 |
| EP2938041A1 (en) | 2015-10-28 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2737173T3 (es) | Método y sistema para la selección en un escenario de múltiples dispositivos | |
| ES2669200T3 (es) | Procedimiento y aparato para gestionar un fallo P-CSCF y recuperar la conectividad | |
| KR101503569B1 (ko) | 가입자 장치의 전역 고유 식별자의 생성 | |
| EP3044944B1 (en) | Voice call continuity in hybrid networks | |
| ES2235065T3 (es) | Metodo y sistema para gestionar multiples registros. | |
| CN101795244B (zh) | Ip通信网络或子网络之间的网络互操作性 | |
| KR101565626B1 (ko) | 패킷 교환 방식 멀티미디어 가입자 서비스들을 제공하는 아키텍처에 의해 정의된 기능들을 갖는 인터페이스들을 갖는 이동 교환국 플랫폼 | |
| US9172582B2 (en) | Cellular network call management | |
| US20110113141A1 (en) | Controlling a Session in a Service Provisioning System | |
| US7990957B2 (en) | Method and device for selecting service domain | |
| US8325707B2 (en) | Session initiation from application servers in an IP multimedia subsystem | |
| US8661097B2 (en) | Service node, control method thereof, user node, and control method thereof | |
| JP2010506467A (ja) | 通信ネットワークにおけるアクセス情報の提供 | |
| CN101401383B (zh) | Ip多媒体子系统中的消息路由 | |
| CN106941669B (zh) | 无线通信方法和p-cscf设备 | |
| ES2665875T3 (es) | Método de acceso en una WLAN para un teléfono móvil IP con autenticación mediante HLR | |
| US20130060954A1 (en) | Enabling set up of a connection from a non-registered ue in ims | |
| ES2880477T3 (es) | Procedimiento y entidad de procesamiento de un mensaje | |
| ES2782527T3 (es) | Procedimiento de registro de al menos una dirección pública en una red IMS y aplicación correspondiente | |
| US10182037B2 (en) | Method for the transmission of a message by a server of an IMS multimedia IP core network, and server | |
| KR100527633B1 (ko) | 이동통신망에서의 멀티미디어 서비스 제공 시스템 및 그방법 | |
| KR101562470B1 (ko) | 개인용 이동통신 단말기를 이용한 기업용 전화 서비스 제공 방법 및 시그널링 게이트웨이 | |
| KR101005431B1 (ko) | 발신번호 통합관리 시스템 및 장치, 그리고 그 방법 | |
| WO2023095031A1 (en) | Method for transmitting and receiving multimedia data | |
| KR20130041665A (ko) | Ｇｒｕｕ 사용 가입자 간의 ｉｍｓ망에서의 ｓｉｐ 메시지 전송 방법 및 그 장치 |