ES2957556T3

ES2957556T3 - Sistema y método de gestión de sesiones

Info

Publication number: ES2957556T3
Application number: ES18382632T
Authority: ES
Inventors: Perea Rogelio Martínez; Rafael Dominguez; Gracia Victor Ortuzar; Joaquin López
Original assignee: Vodafone Espana SA; Vodafone IP Licensing Ltd
Current assignee: Vodafone Espana SA; Vodafone IP Licensing Ltd
Priority date: 2018-08-29
Filing date: 2018-08-29
Publication date: 2024-01-22
Anticipated expiration: 2038-08-29
Also published as: EP3618390B1; EP3618390A1; EP3618390B8

Abstract

Esta invención se refiere a un sistema para configurar una opción de sesión para una sesión de un usuario en una red de telecomunicaciones móviles. El sistema comprende: un módulo de servicio para proporcionar al menos al usuario un servicio de configuración de opciones de sesión para configurar la opción de sesión; y un terminal para el usuario. La red de telecomunicaciones móviles está configurada para reenviar al módulo de servicio, cuando el usuario está registrado para el servicio de configuración de opciones de sesión, mensajes de registro del usuario y mensajes de configuración de sesión para el usuario. El módulo de servicio está configurado para identificar, al recibir un mensaje de registro del usuario y enviarse a través del terminal, información del terminal para el terminal y para detectar, al recibir un mensaje de establecimiento de sesión para configurar una sesión para el usuario, el estado actual. configuración para la sesión para la sesión. El sistema está configurado para, si se determina que la configuración actual de la opción de sesión no es la configuración deseada y si, basándose en la información del terminal identificado para el terminal, se determina que el terminal para el usuario es compatible con la configuración deseada. configuración para la opción de sesión, modifique el mensaje de configuración de sesión para configurar la opción de sesión en la configuración deseada. (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN

Sistema y método de gestión de sesiones

Campo de la invención

La presente divulgación se refiere a la gestión de opciones de sesión en una sesión y es aplicable, de forma particular, aunque no exclusiva, a la gestión de las condiciones previas que se pueden negociar para establecer sesiones. La divulgación se refiere a sistemas, métodos y aparatos para gestionar opciones de sesión.

Antecedentes

Cuando un usuario intenta establecer una llamada de Voz por LTE (VoLTE), se proporcionan procedimientos definidos para configurar la llamada de acuerdo con una serie de condiciones o parámetros. Se implementa un procedimiento de condiciones previas (en ocasiones también denominado "condición previa") para intentar garantizar que estén disponibles los recursos de red mínimos necesarios para que la llamada pueda tener éxito. La negociación de las condiciones previas la realizan ambas partes de la llamada antes de pasar al estado de tono de llamada, para evitar problemas relacionados con recursos de la red.

De manera más general, cuando se intenta establecer una sesión, se pueden configurar parámetros de la sesión dependiendo de uno o más de: la tecnología de acceso de radiocomunicaciones (por ejemplo, 2G, 3G, etc.), el tipo de llamada (por ejemplo, Conmutación de Circuitos "CS" o Subsistema Multimedia de IP "IMS"), la suscripción del usuario, las condiciones de la red, las capacidades del terminal de usuario, etc. Las condiciones del usuario se pueden evaluar para una parte o para cada una de las partes de la llamada y las condiciones de la red se pueden evaluar para una de las redes o para la red correspondiente a cada parte de la llamada.

Sin embargo, si bien estos procedimientos de establecimiento de llamada generalmente están bien definidos y funcionan bien, en algunos casos pueden derivar en un fallo de la llamada, por ejemplo, una interrupción de la misma o que esta presente una mala calidad. Si los parámetros de la llamada no se configuran adecuadamente, el establecimiento de las llamadas, por ejemplo, puede fracasar o las mismas pueden interrumpirse rápidamente después de establecerse, mientras que, en otros ejemplos, las llamadas pueden establecerse pero de manera subóptima, de modo que la experiencia del usuario sea baja o incluso tan baja que esté por debajo de niveles aceptables (por ejemplo, que el sonido sea apenas audible). Por ejemplo, con el procedimiento de condiciones previas, no todos los terminales admiten su implementación o no de la misma manera. Por ejemplo, el comportamiento de los terminales varía entre diferentes terminales para gestionar casos en los que se activa el procedimiento de condiciones previas y en los que no se activa. Esto puede derivar en fallos de las llamadas y una mala experiencia del usuario. Por lo tanto, puede ser deseable proporcionar una disposición que ayude a reducir la configuración errónea de sesiones establecidas entre las partes.

El documento WO-2011/071810 describe la determinación de la capacidad de anticipación a través de perfiles de dispositivos. El documento GB2539843 describe un nodo de red que mantiene una base de datos de preferencias de condiciones previas del protocolo de descripción de sesión (SDP) para elementos de red en sentido descendente.

Compendio

La invención está definida por las reivindicaciones.

Según un primer ejemplo, se proporciona un sistema para configurar una opción de sesión para una sesión de un usuario en una red de telecomunicaciones móviles. El sistema comprende un módulo de servicio para proporcionar al menos al usuario un servicio de configuración de opciones de sesión para configurar la opción de sesión; y un terminal correspondiente al usuario. La red de telecomunicaciones móviles está configurada para reenviar al módulo de servicio, cuando el usuario está registrado en el servicio de configuración de opciones de sesión, mensajes de registro del usuario y mensajes de establecimiento de sesión correspondientes al usuario. El módulo de servicio está configurado para identificar, al producirse la recepción de un mensaje de registro del usuario y enviado a través del terminal, información de terminal correspondiente al terminal y para detectar, al producirse la recepción de un mensaje de establecimiento de sesión para establecer una sesión para el usuario, la configuración actual correspondiente a la sesión. El sistema está configurado para, si se determina que la configuración actual de la opción de sesión no es la configuración deseada y si, basándose en la información de terminal identificada correspondiente al terminal, se determina que el terminal correspondiente al usuario es compatible con la configuración deseada para la opción de sesión, modificar el mensaje de establecimiento de sesión con el fin de configurar la opción de sesión en la configuración deseada.

En algunos ejemplos, el mensaje de establecimiento de sesión o bien está dirigido al menos al usuario o bien se origina en el usuario.

La configuración deseada puede ser una o más de: una activación de la opción de sesión, una desactivación de la opción de sesión y un parámetro de configuración de la opción de sesión.

El sistema puede comprender un segundo terminal correspondiente al usuario. El módulo de servicio puede entonces configurarse además para identificar, al producirse la recepción de un mensaje de registro del usuario y enviado a través del segundo terminal, información de terminal correspondiente al segundo terminal y para detectar, al producirse la recepción de un mensaje de establecimiento de sesión para establecer una sesión para el usuario, la configuración actual correspondiente a la sesión. A continuación, el sistema se puede configurar adicionalmente para modificar el mensaje de establecimiento de sesión con el fin de configurar la opción de sesión en la configuración deseada cuando se determina que la configuración actual de la opción de sesión no es la configuración deseada y, basándose en la información de terminal identificada correspondiente al terminal y correspondiente al segundo terminal, que tanto el terminal como el segundo terminal son compatibles con la configuración deseada para la opción de sesión.

La red de telecomunicaciones móviles puede comprender una red de Subsistema Multimedia de IP "IMS". A continuación, el sistema se puede configurar para registrar al usuario en el servicio de gestión de opciones utilizando un esquema de registro de terceros de la red de IMS.

El sistema puede configurarse para registrar al usuario para utilizar el servicio de gestión de opciones llevando a cabo una o más de (i) configurar un perfil de usuario correspondiente al usuario para indicar que el usuario está registrado para utilizar el servicio de gestión de opciones; y (ii) fijar una configuración predeterminada para usuarios de la red de manera que los usuarios se registren en el servicio de gestión de opciones. En algunos casos, la configuración predeterminada se puede desestimar de modo que los usuarios se registren en el servicio de gestión de opciones, a menos que se configure lo contrario.

El módulo de servicio puede ser un servidor de aplicaciones en una red de Subsistema Multimedia de IP "IMS".

La información de terminal puede comprender uno o más de la totalidad o parte de: un identificador de agente de usuario, un identificador de dispositivo, una IMEI y un identificador de sistema operativo.

La opción de sesión puede estar asociada a un intercambio de condiciones previas o a un procedimiento de extensión de SIP de condiciones previas. Por ejemplo, la opción de sesión puede ser una opción que, cuando se activa, configura al usuario para negociar parámetros de sesión de acuerdo con el procedimiento de condiciones previas o con el procedimiento de extensión de SIP de condiciones previas, respectivamente.

El sistema que está configurado para modificar el mensaje de establecimiento de sesión puede comprender uno o más de: (i) el módulo de servicio que está configurado para modificar el mensaje de establecimiento de sesión con el fin de configurar la opción de sesión en la configuración deseada en el mensaje de establecimiento de sesión; y (ii) el módulo de servicio que está configurado para identificar el mensaje de establecimiento de sesión para su modificación, en donde el sistema comprende un módulo adicional configurado para modificar, tras la detección del mensaje de establecimiento de sesión que se identifica para su modificación, el mensaje de establecimiento de sesión con el fin de configurar la opción de sesión en la configuración deseada en el mensaje de establecimiento de sesión. En algunos ejemplos, el módulo adicional puede ser un Controlador de Borde de Sesión "SBC".

El mensaje de establecimiento de sesión puede ser un mensaje INVITE de SIP y/o el mensaje de registro puede ser un mensaje REGISTER de SIP.

De acuerdo con un segundo aspecto de la presente divulgación, se proporciona un módulo de servicio para configurar una opción de sesión para una sesión de un usuario en una red de telecomunicaciones móviles. El módulo de servicio está configurado para identificar, al producirse la recepción de un mensaje de registro de un usuario registrado en el servicio de gestión de opciones y enviado a través de un terminal correspondiente al usuario, información de terminal correspondiente al terminal; detectar, al producirse la recepción de un mensaje de establecimiento de sesión para el usuario, la configuración actual para la opción de sesión correspondiente a la sesión; determinar, basándose en la información de terminal identificada correspondiente al usuario, si el terminal correspondiente al usuario es compatible con la configuración deseada para la opción de sesión; y hacer que, si se determina que la configuración actual para la opción de sesión no es la configuración deseada y que el terminal es compatible con la configuración deseada para la opción de sesión, el mensaje de establecimiento de sesión se modifique para configurar la opción de sesión a la configuración deseada.

La red de telecomunicaciones móviles puede configurarse, por ejemplo, para reenviar al módulo de servicio, cuando el usuario está registrado en un servicio de gestión de opciones, mensajes de registro del usuario y mensajes de establecimiento de sesión correspondientes al usuario.

El módulo de servicio puede ser un servidor de aplicaciones en una red de IMS de la red de telecomunicaciones móviles.

El módulo de servicio que está configurado para hacer que se modifique el mensaje de establecimiento de sesión puede comprender que el módulo de servicio esté configurado para una o más de: modificar el mensaje de establecimiento de sesión para configurar la opción de sesión en la configuración deseada en el mensaje de establecimiento de sesión; e identificar el mensaje de establecimiento de sesión para su modificación con el fin de desactivar la opción, enviar el mensaje de establecimiento de sesión a un módulo adicional y notificar al módulo adicional que el mensaje de establecimiento de sesión ha sido identificado para su modificación con el fin de configurar la opción de sesión en la configuración deseada en el mensaje de establecimiento de sesión.

Según otro aspecto de la presente divulgación, se proporciona un método para configurar una opción de sesión para una sesión de un usuario en una red de telecomunicaciones móviles usando un módulo de servicio para proporcionar al menos al usuario un servicio de configuración de opciones de sesión para configurar la opción de sesión, en donde la red de telecomunicaciones móviles está configurada para reenviar al módulo de servicio, cuando el usuario está registrado en el servicio de configuración de opciones de sesión, mensajes de registro del usuario y mensajes de establecimiento de sesión correspondientes al usuario. El método comprende identificar, al producirse la recepción de un mensaje de registro de un usuario registrado en el servicio de gestión de opciones y enviado a través de un terminal correspondiente al usuario, información de terminal correspondiente al terminal; detectar, al producirse la recepción de un mensaje de establecimiento de sesión para establecer una sesión para el usuario, que la configuración actual para la opción de sesión está activada para la sesión; determinar, basándose en la información de terminal identificada correspondiente al usuario, si el terminal correspondiente al usuario es compatible con la configuración deseada para la opción de sesión; y si se determina que la configuración actual para la opción de sesión no es la configuración deseada y si, basándose en la información de terminal identificada correspondiente al terminal, se determina que el terminal correspondiente al usuario es compatible con la configuración deseada para la opción de sesión, modificar el mensaje de establecimiento de sesión para configurar la opción de sesión en la configuración deseada.

El método puede comprender además una o ambas de: reenviar el mensaje de establecimiento de sesión modificado al usuario y reenviar el mensaje de establecimiento de sesión modificado a la parte de destino, siendo la parte de destino diferente del usuario.

El método puede comprender registrar al usuario en el servicio de gestión de opciones utilizando un esquema de registro de terceros en una red de Subsistema Multimedia de IP "IMS".

El método puede comprender además una o más de: configurar un perfil de usuario correspondiente al usuario para indicar que el usuario está registrado para utilizar el servicio de gestión de opciones; y fijar una configuración predeterminada para usuarios de la red de modo que los usuarios estén registrados en el servicio de gestión de opciones a menos que se configure lo contrario.

La modificación del mensaje de establecimiento de sesión puede comprender una o más de: el módulo de servicio modifica el mensaje de establecimiento de sesión para configurar la opción de sesión en la configuración deseada en el mensaje de establecimiento de sesión; y el módulo de servicio identifica el mensaje de establecimiento de sesión para su modificación y un módulo adicional, al detectar que el mensaje de establecimiento de sesión se identifica para su modificación, modifica el mensaje de establecimiento de sesión para configurar la opción de sesión en la configuración deseada en el mensaje de establecimiento de sesión. En algunos ejemplos, el módulo adicional puede ser un Controlador de Borde de Sesión "SBC".

El mensaje de establecimiento de sesión puede ser un mensaje INVITE de SIP y/o en el que el mensaje de registro es un mensaje REGISTER de SIP.

Los pasos del método para cualquiera de los métodos de acuerdo con este otro aspecto pueden ser llevados a cabo por el módulo de servicio.

Según un aspecto adicional de la presente divulgación, se proporciona un método para hacer funcionar un módulo de servicio con vistas a configurar una opción de sesión para una sesión de un usuario en una red de telecomunicaciones móviles. El método comprende el módulo de servicio: identifica, al producirse la recepción de un mensaje de registro de un usuario registrado en un servicio de gestión de opciones y enviado a través de un terminal correspondiente al usuario, información de terminal correspondiente al terminal; detecta, al producirse la recepción de un mensaje de establecimiento de sesión correspondiente al usuario, la configuración actual para la opción de sesión correspondiente a la sesión; determina, basándose en la información de terminal identificada correspondiente al usuario, si el terminal correspondiente al usuario es compatible con la configuración deseada para la opción de sesión; y hace que, si se determina que la configuración actual para la opción de sesión no es la configuración deseada y que el terminal es compatible con la configuración deseada para la opción de sesión, se modifique el mensaje de establecimiento de sesión para configurar la opción de sesión con la configuración deseada.

Según otro aspecto más de la presente divulgación, se proporciona un programa informático que comprende instrucciones que, cuando se llevan a cabo, hacen que se implemente cualquiera de los métodos antes expuestos.

Breve descripción de las figuras

La presente divulgación se describirá a continuación con referencia a los dibujos en los que:

La figura 1 ilustra un flujo de llamada simplificado correspondiente a un establecimiento de llamada con tramos de origen y destino en el IMS;

La figura 2 ilustra un diagrama simplificado de una red de IMS;

La figura 3 ilustra un ejemplo de flujo de llamada simplificado de acuerdo con la presente divulgación.

La figura 4 ilustra un sistema de ejemplo de acuerdo con la presente divulgación;

La figura 5 ilustra un método de ejemplo de acuerdo con la presente divulgación;

La figura 6 ilustra otro método de ejemplo de acuerdo con la presente divulgación;

La figura 7 ilustra un dispositivo de ejemplo para su uso en una red de telecomunicaciones móviles; y

La figura 8 ilustra ejemplos de flujos de llamadas simplificados de acuerdo con la presente divulgación.

Descripción de ejemplos

Si bien la presente divulgación se presenta en general en el contexto de Voz por LTE (VoLTE) y del procedimiento de condiciones previas, se entenderá que las enseñanzas de la presente invención se aplican igualmente a otros ejemplos. Por ejemplo, las enseñanzas pueden aplicarse a cualquier situación en la que dos o más partes estén intentando establecer una sesión y en la que haya disponible una opción de sesión para configurar la llamada, por ejemplo usando un procedimiento de negociación de establecimiento de llamada o cualquier otra opción de configuración de sesión adecuada. Por ejemplo, cuando se establece[“established orsetup"]una sesión, podría haber disponibles otros procedimientos de negociación de recursos para garantizar que la sesión se establezca con parámetros apropiados, por ejemplo parámetros que sean compatibles con uno o más de: las capacidades del otro terminal, tipo de acceso o conexión a la red, disponibilidad de recursos de red, etc. Las enseñanzas y técnicas analizadas en este documento también pueden ser útiles para opciones que no se refieren a la negociación entre partes y pueden ser útiles para cualquier tipo de opción de sesión que se pueda configurar usando información en un mensaje de establecimiento de sesión (por ejemplo, un mensaje INVITE de SIP).

Volviendo a un caso de uso de ejemplo de la invención y como se ha mencionado anteriormente, cuando un usuario intenta establecer una llamada de VoLTE, se podría usar un procedimiento de condiciones previas. Este procedimiento se ha estandarizado y tiene una serie de ventajas, como minimizar los problemas de establecimiento de llamadas (por ejemplo, reducir las llamadas fantasma) y mejorar la calidad de las llamadas. Por otro lado, este procedimiento también presenta una serie de desventajas:

(i) Mayor tiempo de establecimiento de la llamada: los intercambios de mensajes adicionales necesarios para completar el acuerdo de condiciones previas pueden añadir una cantidad significativa de tiempo antes de que el teléfono comience a emitir el tono de llamada. Los tiempos elevados de establecimiento de llamada generalmente se consideran no deseables

(ii) Complejidad añadida: el flujo de llamada para establecer la llamada es considerablemente más complejo cuando se utilizan condiciones previas. Esto hace que aumente la probabilidad de tener un error en el establecimiento de la llamada y generalmente dará como resultado más puntos posibles de fallo en redes complejas.

(iii) Mayor utilización de la capacidad: los nodos de la red de IMS involucrados en el flujo de llamada necesitarán procesar más mensajes de SIP (debido al aumento del número de mensajes de SIP requeridos), lo que afecta al número total de llamadas que se pueden entregar. A medida que aumenta el número de mensajes a procesar, se reduce la capacidad de llamadas de la red.

Debido a estos inconvenientes del procedimiento de condiciones previas, en desarrollos más recientes se ha decidido eliminar las condiciones previas siempre que sea posible, haciendo efectivamente que este procedimiento sea opcional. En consecuencia, algunos terminales lo admitirán y otros no. Para gestionar estas diferencias en los comportamientos y expectativas de los terminales, el comportamiento de los terminales se ha definido de manera que deben poder establecer una sesión de VoLTE sin fisuras, independientemente de si ambos terminales implementan el procedimiento, si ninguno de los terminales implementa el procedimiento o si uno lo implementa y otro no. Sin embargo, estándares diferentes han proporcionado métodos diferentes para gestionar la situación en la que la llamada se establece sin condiciones previas. En particular, los estándares del 3GPP y los estándares del IETF brindan una orientación diferente para gestionar tal situación. Como resultado, los terminales no tienen un comportamiento estándar único y esto puede generar problemas a la hora de establecer llamadas.

Se remite a los expertos, por ejemplo, a la TS24.229 del 3GPP Rel13 [1] para casos de llamadas de VoLTE sin las condiciones previas. Más específicamente, [1] exige que se espere un Mensaje de Progresión de Sesión 183 del SIP con una declaración del Protocolo de Descripción de Sesión (SDP) en respuesta a un INVITE del SIP sin condiciones previas activadas, antes de que el terminal entre en el estado de tono de llamada. Esto permite a las dos partes negociar recursos para la sesión o al menos garantizar que haya recursos suficientes para que se establezca una llamada. Sin embargo, algunos dispositivos no se comportan según este estándar y en su lugar envían un Mensaje de Tono de Llamada 180 del SIP sin una declaración del SDP. Esto se parece más al comportamiento de la TR 29.962 V6.1.1 del 3GPP [2] que al comportamiento de [1] que se espera de estos dispositivos. Esto puede causar problemas importantes porque, si el mensaje del SIP 180 se envía antes de la negociación de recursos que puede iniciarse con un Mensaje de Progresión de Sesión 183 del SIP, la llamada podría fallar debido a la falta de recursos. Sin embargo, esto sólo ocurriría después de que la persona que llama cogiese el teléfono y la emisión del tono de llamada también se clasificaría entonces como llamada fantasma. Por otro lado, esto también puede causar problemas al intentar un traspaso de acuerdo con la Continuidad de Llamadas de Voz con una Sola conexión de Radiocomunicaciones (SRVCC o SR-VCC) en modo de alerta. En consecuencia, incluso aunque en ocasiones puede ser deseable desactivar las condiciones previas para evitar las complejidades y los inconvenientes comentados anteriormente, se espera que desactivar la opción conduzca, por un lado, a una experiencia de usuario mejorada para algunos casos en los que los terminales responden con un mensaje del SIP 183 y, por otro lado, a un mayor número de llamadas interrumpidas y llamadas fantasma. En consecuencia, ni el mantenimiento ni las condiciones previas cuando se activan en las sesiones de una red serán satisfactorios y la calidad de la llamada se verá afectada de todos modos, aunque de forma diferente.

En otras palabras, varias sesiones pueden fallar debido a que la opción de condiciones previas está desactivada y debido a que la parte de destino no se comporta de la manera esperada cuando no se utilizan condiciones previas de modo que la parte de destino responderá de una manera inesperada o al menos de una manera que conduce a un aumento de la tasa de fallo de llamadas.

Como entenderá el experto en la materia, en la presente divulgación las expresiones fallo de llamada o fallo de sesión pretenden incluir tanto llamadas como sesiones establecidas de manera insatisfactoria (por ejemplo, con una calidad de llamada por debajo de un umbral según al menos una métrica de calidad) y llamadas o sesiones que no consiguen establecerse (por ejemplo, cuando la llamada no se establece en absoluto y se archiva antes de que se pueda completar el procedimiento de establecimiento de sesión o cuando la llamada se establece solo por un corto espacio de tiempo antes de finalizar).

Cuando se afrontan estos problemas con el procedimiento de condiciones previas, una de las opciones para abordar este problema es desactivar o deshabilitar las condiciones previas en la red. Si el procedimiento de condiciones previas está deshabilitado en toda la red, entonces los problemas y limitaciones de condiciones previas identificados anteriormente ya no pueden producirse, por lo que esta solución aborda el problema de gestionar implementaciones diferentes o deficientes del procedimiento de condiciones previas; sin embargo, esto introduciría un nuevo problema, como también se ha analizado anteriormente. Esta desactivación general de opciones se puede implementar, por ejemplo, utilizando las Reglas de Manipulación de Encabezamientos (HMR) en el Controlador de Borde de Sesión (SBC). La figura 1 ilustra un flujo de llamada simplificado de un establecimiento de llamada con tramos de origen y destino de IMS. En una primera etapa, el UE de origen (UE1) enviará un mensaje de establecimiento de llamada (INVITE de SIP) al UE de destino (u E2). El mensaje pasará por el SBC (SBC1) para el UE1, por el resto de la red de IMS (o las redes de UE1 y UE2 están asociadas a diferentes redes de IM) y a continuación por el SBC (SBC2) para el UE2 antes de llegar a UE2. Asimismo, el mensaje del SIP 180 RINGING enviado en la etapa 2 pasará por los mismos nodos en la otra dirección. Es digno de mención que, como sabrá el experto, en algunos casos el terminal puede responder a un INVITE del SIP con un Mensaje de Progresión de Sesión 183 del SIP. Como se ha analizado anteriormente, cuando se desactivan las condiciones previas, este comportamiento de respuesta 183 del SIP es el comportamiento esperado de VoLTE que ayudaría con la reserva de recursos y a reducir la interrupción de llamadas y las llamadas fantasma.

La respuesta 200 OK enviada en la etapa 3 (si UE2 responde a la llamada) también pasará por los mismos nodos, en la misma dirección que los mensajes del SIP 180 RINGING, es decir, de UE2 a UE1. En consecuencia, los mensajes de SIP pasarán por el SBC para cada parte del IMS y el SBC puede aplicar manipulación de encabezamientos para modificar los encabezamientos con el fin de eliminar la opción de condiciones previas para desactivar o deshabilitar el procedimiento de condiciones previas para la llamada. Por ejemplo, si UE1 está configurado en la red para no usar las condiciones previas, SBC1 puede modificar cualquier mensaje de UE1 (y/o cualquier mensaje para el UE1) para eliminar las condiciones previas del mensaje. Asimismo, SBC2 puede modificar cualquier mensaje para el UE2 (y/o cualquier mensaje de UE2) para eliminar las condiciones previas. En consecuencia, si uno o los dos de UE1 y UE2 están marcados como que no admiten las condiciones previas, entonces el INVITE de SIP puede modificarse de modo que, una vez que llegue a UE2, las condiciones previas no se habiliten. En consecuencia, la llamada debe desarrollarse entonces normalmente sin condiciones previas. Cabe señalar que en otro ejemplo un elemento distinto del SBC puede llevar a cabo la señalización para eliminar las condiciones previas, pero en este caso, se aplican igualmente los mismos principios y enseñanzas.

En otras palabras, al utilizar esta opción de desactivación general, el procedimiento de condiciones previas se puede deshabilitar para evitar problemas causados por el propio procedimiento de condiciones previas al tiempo que la cantidad de modificación de señalización necesaria para implementar la solución sigue siendo baja.

De acuerdo con la presente divulgación, se proporciona un enfoque diferente para reducir el efecto de las limitaciones de las implementaciones de condiciones previas en terminales al tiempo que se aborda el hecho de que terminales diferentes tendrán comportamientos diferentes cuando se desactivan las condiciones previas. Se ha reconocido que esta solución basada en una desactivación general de las condiciones previas para todos los usuarios, si bien es útil hasta cierto punto, tiene sus propias limitaciones en cuanto a la calidad de las sesiones que se establecen y en cuanto a la aparición de llamadas fantasma, por ejemplo. Este enfoque se basa en deshabilitar la opción como una elección de todo o nada que no tiene en cuenta este comportamiento variable observado en los terminales.

En consecuencia, la presente divulgación proporciona una disposición para gestionar (1) el comportamiento específico de implementación de los terminales y (2) la fase crítica de establecer una sesión, tal como una llamada, entre terminales.

Una de las dificultades cuando se intenta evitar una desactivación “general” de la opción de condiciones previas y cuando se intenta, en cambio, tener una disposición en la que la opción será utilizada por algunos terminales (por ejemplo, con implementaciones que funcionan como se espera) y se desactivará para otros terminales (por ejemplo, con implementaciones rebeldes), es determinar cuándo mantener la opción y cuándo deshabilitarla. Sin embargo, en la práctica, esto sólo podrá determinarse una vez que la parte de destino (UE2) envíe el primer Mensaje de Progresión de Sesión 183 del SIP en la etapa 2. Sólo entonces la red será consciente de que la parte de destino realmente se comporta como se espera si se desactivan las condiciones previas (o no se comporta como se esperaba si, en cambio, envía primero una respuesta de SIP 180). Sin embargo, en esta etapa, ya es demasiado tarde para corregir la situación y aumenta el riesgo de fallo de llamada y de llamadas fantasma. En otras palabras, una implementación que se proporciona en función de cada llamada individual afronta el problema de no poder determinar si la parte de destino admite la desactivación de las condiciones previas hasta que el establecimiento de la llamada ya está demasiado adelantado para configurar la opción. Como resultado, varios operadores de red no han podido desactivar esta opción aunque en ocasiones desean hacerlo.

En un ejemplo, en lugar de utilizar una desactivación general de las condiciones previas en toda la red, se utiliza una base de datos interna (por ejemplo, un repositorio de usuarios común). La base de datos puede comprender información relacionada con un abonado, tal como uno o más de un Número de Directorio Internacional de Abonados de Estación Móvil (MSISDN), una Identidad Internacional de Equipo Móvil (IMEI) y servicios para el abonado. Por ejemplo, los primeros ocho dígitos de la IMEI generalmente representan el modelo de terminal de manera que parte de la IMEI se puede usar para obtener un modelo de terminal correspondiente al terminal que envía un mensaje donde la IMEI está incluida o se puede obtener a partir del mensaje. En esta disposición, la base de datos interna puede ser utilizada, por ejemplo, por el SBC. El SBC puede determinar si la IMEI se corresponde con un terminal que no se comporta como se esperaba cuando las condiciones previas están habilitadas y, de ser así, puede llevar a cabo una modificación del encabezamiento para deshabilitar el procedimiento de condiciones previas, antes de que llegue al terminal el mensaje de establecimiento de llamada. Si bien esto podría aliviar algunas de las limitaciones de una desactivación general de la opción, también tiene algunas limitaciones. Por ejemplo, la información puede no estar actualizada y/o puede no reflejar qué terminal está utilizando actualmente un abonado (por ejemplo, entre dos o más terminales que podría tener).

En cuanto a cómo determinar si utilizar el procedimiento de condiciones previas de una manera que no se espera que cause problemas, se pueden utilizar diferentes métodos. Dicho método puede ayudar a construir una comprensión y/o una base de datos de cómo se comporta cada terminal ya analizado dependiendo de la configuración correspondiente a la opción de sesión (por ejemplo, condiciones previas). Terminales diferentes tendrán un comportamiento diferente y, para determinar si un terminal particular es compatible con el comportamiento esperado cuando se activan o desactivan las condiciones previas, se podrían utilizar diferentes técnicas - de forma individual o en combinación. Por ejemplo, el documento WO 2011/071810 titulado "Look-Ahead Capability Determination via Device Profiles" describe una base de datos de información de compatibilidad de códecs para dispositivos que se puede construir basándose en la retroalimentación de fallos de llamadas reales y actualizarse de acuerdo con los problemas experimentados por los terminales. Utilizando las técnicas de este documento, se podría imaginar una disposición en la que, basándose en las capacidades del terminal que se han observado en la vida real, se pueda construir una base de datos que pueda indicar (para cada terminal que se haya utilizado) si el terminal ha sido capaz de utilizar el procedimiento de condiciones previas.

En otros ejemplos, la base de datos no se construye basándose en llamadas fallidas reales, sino sobre la base de pruebas de dispositivos que se pueden realizar sin conexión, por ejemplo. En este ejemplo, los dispositivos se pueden probar y (i) los dispositivos que pasan la prueba se pueden incluir en una lista blanca para dispositivos donde se pueden eliminar las condiciones previas y/o (ii) los dispositivos que no pasan la prueba se pueden incluir en una lista negra para dispositivos donde las condiciones previas no deben desactivarse (por ejemplo, porque se espera que respondan con un mensaje del SIP 180 en lugar de un mensaje del SIP 183).

Cualesquiera que sean los criterios y métodos que se utilicen para evaluar los dispositivos, pueden incluirse en la lista blanca y/o en la lista negra dependiendo de su capacidad para gestionar el procedimiento de condiciones previas. A continuación, basándose en una o más de que un terminal esté presente o ausente en una lista blanca y que un terminal esté presente o ausente en una lista negra, el procedimiento de condiciones previas se puede deshabilitar o no para el terminal.

Independientemente de las técnicas utilizadas para construir la información sobre la compatibilidad de los terminales con las condiciones previas (u otra opción de sesión), dicha base de datos se puede utilizar entonces, por ejemplo, en el método analizado anteriormente, en el que el SBC consulta la base de datos para determinar si mantener o desactivar la opción. Sin embargo, esto todavía no aborda el problema de este método de ejemplo de no siempre poder predecir el comportamiento del terminal de destino de una manera fiable. Si por ejemplo un usuario cambia de terminal, esta información no se actualizará en tiempo real y eso podría dar como resultado fallos de llamada y una experiencia de usuario insatisfactoria.

De acuerdo con la presente divulgación, se proporciona una disposición para tomar una decisión en función de cada llamada individual y antes de que sea demasiado tarde usando un módulo de servicio (por ejemplo, un Servidor de Aplicaciones "AS" en el IMS) que está registrado para recibir al menos algunos de los mensajes de un terminal. El módulo de servicio se utiliza para controlar la activación o desactivación de la opción. Por ejemplo, en una red de IMS, la presente divulgación puede hacer uso de los procedimientos de registro de terceros para que al AS se le pueda notificar cuándo se registró un terminal y cuándo el terminal envía o recibe un INVITE del SIP.

Para comprender mejor cómo se pueden aplicar las técnicas de la presente divulgación en una red de IMS, primero se analizará la arquitectura básica de una red de IMS. La figura 2 ilustra un diagrama simplificado de una red de IMS que se utilizará para ilustrar cómo se puede implementar la invención. En este diagrama simplificado, un terminal o U<e>201 se conecta a una red 202 de acceso. Generalmente se espera que sea una red de telecomunicaciones móviles (aunque podría ser o incluir una red diferente) y puede ser gestionada por el mismo operador o por uno diferente al operador que gestiona la red 210 de IMS. La red 202 de acceso sirve para dar al terminal acceso a una red a través de una red central, por ejemplo una red central móvil y/o una red central de IMS. El terminal también puede tener acceso a una o más redes públicas tales como Internet a través de la red 202 de acceso. En el caso de una VoLTE o caso equivalente, se espera que la red de acceso incluya una red de datos móviles, tal como una Red Central por Paquetes Evolucionada según se proporciona en las redes de LTE o NR o una red de datos equivalente, de modo que el terminal pueda establecer una llamada a través de la red de datos proporcionada por la red de acceso móvil (a diferencia de, por ejemplo, a través de una red de voz o por Conmutación de Circuitos "CS").

El terminal 201 se conecta a través de la red 210 de IMS a través de la red 202 de acceso y primero está conectado a una Función de Control de Sesiones de Llamada Proxy "P-CSCF" 212. La P-CSCF 212 incluye las funciones de un SBC 211. Es digno de mención que en ocasiones se puede hacer referencia a la P-CSCF como "SBC", ya que la P-CSCF proporciona funciones similares a las de un SBC. Desde cierta perspectiva, la P-CSCF 212 puede verse como un SBC 211 con funcionalidades de IMS especializadas o, desde una perspectiva diferente, puede verse como una P-CSCF 212 con funcionalidades de SBC. Como sabrá el experto, un SBC es una entidad que lleva a cabo el control de señalización para la señalización de Voz por IP (VoIP) y ayuda a proteger y regular la señalización que entrará en la red, por ejemplo la red de IMS en el ejemplo de la figura 2. Estas funciones son parte de las funciones que cumple la P-CSCF. La P-CSCF 212 es efectivamente un SBC (que por lo tanto será el primer punto de entrada a la red de IMS) y que actúa como proxy de SIP para el terminal y que también proporcionará cifrado para las comunicaciones entre el terminal y la red de IMS. Por ejemplo, en un caso de itinerancia, la P-CSCF puede estar en la red visitada.

Como apreciará el experto, cuando se hace referencia a un SBC o a una P-CSCF en el ejemplo de VoLTE, las mismas enseñanzas se aplican igualmente a un SBC, a una P-CSCF y/o a cualquier otro nodo que cumpla las mismas funciones de primer punto de entrada para la señalización de la sesión. Además, los términos SBC y P-CSCF se utilizarán indistintamente en el presente documento cuando se utilicen en el contexto de una red de IMS.

La P-CSCF 212 está conectada a una S-CSCF 213 que es la CSCF de Servicio para el terminal. La S-CSCF actúa como anclaje de señalización en la red central de IMS para el terminal y, por lo tanto, se encontrará en la red doméstica del usuario. Como resultado, también es el nodo que gestiona Servidores de Aplicaciones (AS) tales como el AS 221 y 222 en la figura 2. Como apreciará el experto, las enseñanzas proporcionadas con respecto a la S-CSCF en el ejemplo de VoLTE pueden aplicarse igualmente a cualquier otro nodo de anclaje de señalización en la red doméstica del usuario que gestione señalización hacia servidores de aplicaciones (o nodos equivalentes). La red central de IMS también incluye un Servidor de Abonados Domésticos (HSS) 214 que es la base de datos de usuarios para usuarios de IMS. El HSS 214 puede verse como el equivalente del Registro de Posiciones Locales (HLR) en una red móvil. Si bien el HSS 214 se ha incluido en la figura 2, tiene una relevancia limitada para la presente divulgación, por lo que no se analizará con mayor detalle. Asimismo, la red central del IMS puede incluir elementos adicionales, por ejemplo CSCF Interrogante (I-CSCF) que no se ilustran en la figura 2. En general, estos elementos adicionales o cualquier otro elemento de relevancia limitada para la presente divulgación no se analizarán en el presente documento en aras de la concisión.

Aunque no forma parte de la red central de IMS, una red de IMS también puede incluir Servidores de Aplicaciones para proporcionar uno o más servicios a los abonados de IMS. Si un abonado (usuario) de IMS está registrado en un servicio, la S-CSCF enviará parte de la señalización a los servidores de aplicaciones relevantes. En particular, la S-CSCF enviará al AS (que proporciona el servicio para el cual está registrado el terminal) los mensajes REGISTER de SIP del terminal correspondiente al usuario y los mensajes INVITE de SIP que están siendo enviados por el terminal o enviados al terminal. A continuación, el AS procesará los mensajes según corresponda para proporcionar el servicio y reenviará los mensajes procesados a la S-CSCF. Si hay servicios de AS adicionales en los que el usuario está registrado, la S-CSCF reenviará el mensaje al AS correspondiente y una vez que se hayan cubierto todos, la S-CSCF puede enviar el mensaje hacia el destino.

La presente divulgación proporciona una disposición con un enfoque completamente diferente en comparación con los enfoques analizados anteriormente. En lugar de confiar en datos pasados o en una desactivación general de la opción de sesión, en el presente documento se propone identificar la parte de destino en tiempo real, pero incluso antes de que se inicie la sesión y, por tanto, antes de que la sesión o la llamada llegue a la parte de destino - como quedará claro a partir del siguiente análisis.

Más específicamente, en el ejemplo de VoLTE, se proporciona un Servidor de Aplicaciones (por ejemplo, AS de Condiciones Previas "P-AS") para gestionar la configuración de las condiciones previas para las llamadas. El P-AS puede hacer uso del esquema de registro de terceros en IMS (o un esquema equivalente) para recibir mensajes de señalización desde y hacia el usuario. Una vez que el usuario está suscrito al servicio de gestión de las condiciones previas, el AS de Condiciones Previas (P-AS) puede hacer por tanto que se modifique el mensaje INVITE para eliminar las condiciones previas, si procede.

Es digno de mención que, si bien el esquema de registro de terceros puede ser útil tanto para obtener información de terminales como para identificar qué mensajes modificar, se pueden usar otras técnicas en lugar o además del esquema de registro de terceros. Por ejemplo, la S-CSCF para la parte de origen y/o la parte de destino puede configurarse para determinar cuándo reenviar - y para reenviar - el mensaje de establecimiento de llamada al módulo para su procesamiento. Se remite al lector, por ejemplo, al análisis de la posterior figura 8.

La figura 3 ilustra un ejemplo de flujo de llamadas simplificado de acuerdo con la presente divulgación. En este ejemplo, UE-B es un abonado de IMS y el SBC (P-CSCF), la S-CSCF y el P-AS son el nodo respectivo para este usuario particular. El UE de origen "UE-A" puede ser de la misma red o de una red diferente - la ubicación o suscripción correspondiente al UE-A no es relevante para el resto del análisis de la figura 3. Primero, el UE-B se registrará en la red central de IMS en la etapa S301. Con el IMS, el terminal UE-B incluirá un agente de usuario para conectarse a la red de IMS, tal como un agente de usuario de SIP que enviará un REGISTER MESSAGE del SIP. El mensaje REGISTER de SIP llegará primero al SBC (P-CSCF) antes de que pueda llegar a la S-CSCF. En este ejemplo, el usuario de UE-B se ha suscrito al servicio de gestión de opciones de condiciones previas en el que el P-AS está asociado a este servicio. En consecuencia, la S-CSCF reenviará el mensaje REGISTER de SIP al P-AS. En este caso, la S-CSCF esperará la finalización del procedimiento de registro, es decir, hasta la etapa en la que se puede enviar el mensaje de respuesta de SIP 200 OK, para iniciar la segunda etapa S302 de notificar al P-AS el registro del usuario.

Es digno de mención que en algunos casos la etapa 302 puede iniciarse antes de que la S-CSCF pueda enviar el mensaje del SIP 200 OK. En algunos ejemplos, la S-CSCF puede haber determinado que el registro es exitoso y, por lo tanto, haber iniciado S302 antes de que se envíe realmente el mensaje del SIP 200 OK. En otros ejemplos, la S-CSCF puede enviar el mensaje de registro al P-AS antes de que se complete el procedimiento de registro. Sin embargo, esta segunda opción puede aumentar la señalización ya que el mensaje REGISTER se enviaría al P-AS independientemente de que el usuario complete o no el registro. En consecuencia, si el usuario no se registra, el REGISTER se habría enviado al P-AS aun cuando el usuario tendrá que intentar registrarse nuevamente antes de poder iniciar una llamada o ser contactado para una llamada. En consecuencia, si bien esta segunda opción sigue siendo una implementación posible, en la mayoría de los casos es probable que se prefiera la primera opción (la S-CSCF envía el mensaje REGISTER al P-AS una vez que le consta que el usuario puede registrarse) debido a la señalización reducida.

Volviendo al ejemplo de la figura 3, una vez que se notifica al P-AS el registro y se le notifica el registro del usuario, puede usar información del mensaje REGISTER de SIP para detectar información de terminal correspondiente al terminal que actualmente utiliza el usuario de UE-B. Por ejemplo, el mensaje REGISTER de SIP generalmente indicará un identificador correspondiente al agente de usuario que fue utilizado por UE-B para enviar el mensaje REGISTER de SIP. La información de agente de usuario se puede utilizar posteriormente como información de terminal para determinar si el terminal puede utilizar el procedimiento de condiciones previas de la manera esperada.

Una vez que el usuario está registrado en la red de IMS, si un usuario UE-A inicia una llamada a UE-B, enviará un INVITE del SIP a UE-B en S303, en donde el INVITE del SIP alcanzará la S-CSCF correspondiente al UE-B. Debido a que el usuario está registrado en la opción de gestión de condiciones previas, en la siguiente etapa S304 la S-CSCF reenviará el INVITE del SIP al P-AS y esperará la respuesta del P-AS. Una vez que el P-AS recibe el INVITE de SIP, puede determinar si es necesario cambiar la configuración de las condiciones previas utilizando uno o más criterios. El P-AS puede determinar si el INVITE de SIP tiene habilitado el procedimiento de condiciones previas o no. Si no está habilitado, entonces el INVITE de SIP no requerirá ninguna modificación y, por lo tanto, puede enviarse de regreso a la S-CSCF sin ningún cambio. Por otro lado, si el procedimiento de condiciones previas está habilitado para la llamada, el P-AS puede determinar si el terminal correspondiente al UE-B es compatible o no con la desactivación del procedimiento de condiciones previas, antes de que la llamada llegue realmente al UE-B. Por ejemplo, si el terminal identificado es uno que no se comporta de la manera esperada cuando la opción de condiciones previas no está activada, por ejemplo si el terminal envía un mensaje distinto a un mensaje del SIP 183 con un SDP en respuesta al mensaje INVITE de SIP (por ejemplo, un mensaje del SIP 180), la opción de condiciones previas se puede dejar activada. Si por otro lado se espera que el terminal responda con un mensaje del SIP 183 con un mensaje SDP, se puede desactivar la opción y no se espera que esto provoque ningún fallo de llamada ni llamadas fantasma.

Más específicamente, el P-AS puede recuperar la información de terminal obtenida del mensaje de registro anterior, tal como el agente de usuario, para determinar el comportamiento del terminal actual cuando la opción de condiciones previas no está activada. En algunos casos, el P-AS puede gestionar la(s) base(s) de datos de la información de terminal actual y/o de la relación entre la información de terminal y la compatibilidad con la opción de llamada mientras que en otros casos puede conectarse a una base de datos externa que gestiona esta información. Por ejemplo, en S302 o después de S302, el P-AS puede actualizar su propia base de datos o una base de datos externa (relativa al P-AS) con información relativa a la información de terminal actual correspondiente al usuario. A continuación, en S304, el P-AS puede consultar esta base de datos para determinar la información de terminal actual correspondiente al usuario. A partir de esta información de terminal, se puede determinar información relativa a la compatibilidad del terminal con la opción de condiciones previas. En algunos casos, esta información de compatibilidad se puede determinar directamente a partir de la información de terminal (por ejemplo, directamente desde el agente de usuario) o indirectamente a partir de la información de terminal. En este último caso, se puede obtener información de terminal adicional (por ejemplo, marca y/o modelo del terminal) a partir de la información de terminal (por ejemplo, agente de usuario) y se puede determinar la idoneidad del terminal para usar las opciones de condiciones previas basándose en la información de terminal adicional.

Como se ha mencionado anteriormente, se pueden usar diferentes métodos adecuados para determinar si un terminal puede comportarse de una manera aceptable o deseada cuando el procedimiento de condiciones previas está desactivado. En un ejemplo, se determina si el terminal y/o el agente de usuario han sido incluidos en la lista blanca como compatibles con la desactivación de este procedimiento. Si está en la lista blanca, la opción se puede desactivar. Por otro lado, si el terminal no ha sido incluido en la lista blanca y/o si ha sido incluido en la lista negra, se puede considerar que el terminal no es compatible con la desactivación de la opción y el P-AS puede decidir dejar activado el procedimiento de condiciones previas con vistas a evitar posibles problemas durante el establecimiento de la sesión.

Es digno de mención que si bien se han hecho referencias a una o más bases de datos, el experto apreciará que las técnicas de la presente divulgación son igualmente aplicables a otras estructuras de datos que permiten asociar datos a otros datos. Por ejemplo, sería adecuado usar cualquier otro tipo de estructura de datos (base de datos, tabla u otras) que pueda asociar datos de identidad del abonado a datos de información de terminal, o datos de información de terminal (iguales a los anteriores o diferentes) a datos de compatibilidad de opciones cuando se intenta determinar información para identificar el terminal y/o el agente de usuario o si el terminal puede usar el procedimiento de condiciones previas o la falta del mismo de una manera aceptable.

Volviendo a la figura 3, si el P-AS determina que el terminal correspondiente al UE-B se comportará como se espera si se desactiva el procedimiento de condiciones previas, el P-AS hará que se modifique el mensaje INVITE de SIP para deshabilitar la opción de condiciones previas con el fin de usar el procedimiento de condiciones previas. Si, por otro lado, se espera que el terminal se comporte de una manera que pueda causar problemas en el establecimiento de la llamada, la opción permanecerá activada. En otras palabras, basándose en el terminal identificado y en el comportamiento de este terminal cuando se activa y/o desactiva la opción, el P-AS puede decidir si desactivar la opción o no. Es de destacar que en otro caso, el P-AS puede desear activar una opción que no fue activada previamente, si corresponde, basándose en el terminal identificado correspondiente a la parte de destino (y cualquier otra información, si corresponde). Cuando se deshabilitan las condiciones previas antes de que INVITE de SIP llegue al UE-B y cuando se espera que el UE-B gestione una llamada sin condiciones previas sin crear problemas, se puede reducir la probabilidad de experimentar fallos en las llamadas debido al procedimiento de condiciones previas. Por otro lado, al dejar las condiciones previas activadas cuando no se espera que el UE-B gestione bien una llamada sin condiciones previas, se puede reducir el riesgo de fallos de llamada y/o llamadas fantasma.

En cuanto a cómo hacer que se deshabilite la opción de condiciones previas, se pueden utilizar diferentes técnicas. En una primera técnica de ejemplo, el P-AS puede modificar el INVITE de SIP para deshabilitar la opción antes de enviar el INVITE de SIP (modificado) de vuelta a la S-CSCF, como parte del flujo esperado en la etapa S304. En otro ejemplo, el P-AS no puede modificar el INVITE de SIP directamente para deshabilitar la opción. Por ejemplo, el P-AS podría marcar, en cambio, el INVITE de SIP como que debe ser modificado para que la opción se desactive. Dicha modificación no deshabilitará la opción en esta etapa, pero puede usarse, en cambio, para informar a otro nodo de que la opción debe eliminarse o deshabilitarse. Por ejemplo, como al SBC ya se le han confiado varias reglas de modificación de encabezamientos, también se le puede confiar al SBC la modificación del INVITE de SIP para deshabilitar las condiciones previas. Por lo tanto, permitir que el SBC lleve a cabo la deshabilitación real de la opción puede resultar más eficiente en cuanto a tiempo y recursos que hacer que un AS modifique los parámetros de la sesión en esta etapa. En este caso, el P-AS modifica el INVITE de SIP solo para marcarlo para la desactivación de condiciones previas y el INVITE de SIP marcado se envía de regreso a la S-CSCF. La modificación para desactivar las condiciones previas será llevada a cabo por la SBC. En comparación con la opción de que el P-AS deshabilite la opción, usar el SBC para llevar a cabo la modificación permite al SBC llevar a cabo cualquier resolución de conflicto en caso de que diferentes AS deseen llevar a cabo modificaciones, que entren en conflicto, en el INVITE de SIP.

Cabe señalar que en el ejemplo de la figura 3, solo se ha mostrado un AS, concretamente el P-AS, pero que también podrían estar involucrados otros Servidores de Aplicaciones, si por ejemplo el terminal está registrado en otros servicios o si se proporcionan algunos servicios a todos los usuarios de la red. En consecuencia, las etapas S302 y S304 pueden repetirse tantas veces como sea necesario, en cualquier orden relevante. Por ejemplo, como apreciará el experto, se pueden repetir antes y/o después de la etapa correspondiente para el P-AS.

Si bien se han proporcionado dos técnicas de ejemplo para modificar el INVITE de SIP, el experto apreciará que la presente divulgación no se limita a estas dos opciones particulares y que se puede utilizar cualquier otra técnica adecuada. Por ejemplo, el P-AS podría comunicar a la S-CSCF o al SBC de una manera diferente que el mensaje INVITE de SIP requiere modificación. En un ejemplo alternativo, el P-AS podría enviar un mensaje o comunicación independiente a la S-CSCF o al SBC para informarles de que la opción debe deshabilitarse en el INVITE de SIP.

Una vez que el P-AS ha procesado el mensaje en S304 y lo ha devuelto a la S-CSCF, y una vez que la S-CSCF ha repetido la etapa S304 tantas veces como sea apropiado (dependiendo del número de AS/servicios a los que se está suscrito), en la etapa S305 el INVITE del SIP se puede enviar al UE de destino UE-B a través del SBC correspondiente al UE-B.

De acuerdo con las presentes técnicas, independientemente de cuándo y dónde se puede modificar el INVITE de SIP para deshabilitar el procedimiento de condiciones previas, cuando el terminal se considera compatible con la desactivación del procedimiento de condiciones previas y cuando la llamada tenía la opción de condiciones previas activada, el mensaje INVITE de SIP que es recibido por UE-B como final de la etapa S305 es un INVITE de SIP modificado. Es decir, el INVITE de SIP se ha modificado para deshabilitar las condiciones previas en el INVITE de SIP si el UE-B se considera compatible con esta configuración. Esto se hace porque el P-AS ha determinado en tiempo real qué terminal o agente de usuario está utilizando el usuario de destino (en lugar de confiar en información de terminal anterior) y, por lo tanto, puede controlar la deshabilitación de las condiciones previas de forma correspondiente, antes de que el INVITE de SIP incluso llegue al terminal UE-B.

Como apreciará el experto en la materia, de acuerdo con las presentes técnicas, incluso si un abonado cambia de terminal (por ejemplo, compra un dispositivo nuevo o cambia entre diferentes dispositivos del mismo abonado), el usuario tendrá que registrarse de nuevo una vez que empiece a utilizar el terminal nuevo y, en consecuencia, el P-AS podrá utilizar información sobre el terminal actual utilizando información de terminal obtenida del último mensaje de registro del usuario. Esto se hace automáticamente a través de la S-CSCF que envía automáticamente los mensajes de registro y establecimiento de llamada a la S-CSCF. Esto permite que el P-AS utilice información en tiempo real actualizada para el usuario y el terminal / agente de usuario sin tener que depender de una base de datos de terminales externa sobre la cual no tiene control ni opinión con respecto a la frecuencia de actualización. En consecuencia, tanto la fiabilidad de la información de terminal como la precisión de la modificación del establecimiento de llamada aumentan al tener el mismo módulo de servicio (por ejemplo, P-AS) recibiendo mensajes de registro y mensajes de establecimiento de llamada con el propósito combinado de actualizar el mensaje de establecimiento de llamada (si corresponde) basándose en la información de terminal.

En otras palabras, el procedimiento de condiciones previas se puede desactivar, cuando sea apropiado, basándose en el terminal que el usuario está utilizando actualmente y antes de que el mensaje INVITE de SIP llegue a la parte de destino UE-B (lo cual sería demasiado tarde para evitar los problemas mencionados anteriormente si las condiciones previas se desactivan cuando el UE-B no se comporta de la manera esperada). Esto, a su vez, permite utilizar el procedimiento de condiciones previas cuando sea apropiado, desactivando así este procedimiento cuando sea posible al tiempo que se deja activado cuando se crea que es beneficioso. Como resultado, la calidad de las sesiones se puede mejorar cuando se utilizan condiciones previas en el establecimiento de la sesión y se puede reducir la probabilidad de tener fallos en las llamadas debido a las diferentes implementaciones del terminal.

La figura 5 ilustra un método de ejemplo de acuerdo con la presente divulgación. En este ejemplo, el método se implementa mediante una aplicación en una red de IMS, pero el experto apreciará que las mismas enseñanzas y funciones equivalentes se pueden aplicar e implementar, respectivamente, en otros entornos. El método comienza en S501 y el AS puede a continuación recibir mensajes de SIP de cualquier usuario que esté suscrito al servicio que proporciona el AS, utilizando el proceso de registro de terceros. En el IMS, la S-CSCF enviará los mensajes al As , pero es concebible que en otros entornos el AS reciba los mensajes de manera diferente, por ejemplo el mismo nodo de red puede llevar a cabo la interceptación y el procesamiento de mensajes). Volviendo al ejemplo de IMS, el AS se sitúa a continuación a la espera de mensajes de su(s) abonado(s) en S503.

Una vez que se recibe un mensaje, el AS procesará los mensajes REGISTER de SIP e INVITE de SIP de manera diferente y, por lo tanto, determinará en S503 si el mensaje es un mensaje REGISTER o INVITE. Se apreciará que, en el caso de que el AS pueda procesar otros mensajes, también puede tomar una determinación basándose en otros tipos de mensaje. El análisis de la figura 5 se centra únicamente en los mensajes REGISTER e INVITE, por lo que no en este análisis se considerarán expresamente otros tipos de mensaje.

Si el mensaje es un mensaje REGISTER, el método se traslada al paso S504 donde se obtiene información de terminal correspondiente al usuario, basándose en el mensaje REGISTER. Normalmente, el mensaje de registro incluye un identificador de agente de usuario, en el que el agente de usuario es un elemento que se ejecuta en el terminal de usuario. En otros casos, se puede utilizar información diferente o adicional como información de terminal o para obtener a partir de ella la información de terminal. Si se utiliza el agente de usuario, la información de terminal real bien puede ser el agente de usuario (o cualquier otro tipo de primera información de terminal que se incluye en el mensaje de registro) o bien puede ser información de terminal que se obtiene de la primera información de terminal. En un ejemplo, se extrae un identificador de agente de usuario del mensaje de registro como primera información de terminal y, a partir de la primera información de terminal, se obtiene información de terminal adicional. Por ejemplo, de la primera información de terminal puede obtenerse una marca y/o modelo de terminal y/o como al menos parte de la información de terminal (adicional) puede obtenerse información relativa a la compatibilidad del terminal o agente de usuario que se ejecuta en el terminal con la condición previa. Independientemente de si la información de terminal es información contenida en el mensaje de registro (por ejemplo, la "primera" información de terminal anterior) u obtenida indirectamente del mensaje de registro (por ejemplo, información de terminal "adicional"), la información de terminal obtenida en S504 se asocia al usuario en S505. Si el terminal estaba previamente asociado a información de terminal, la información de terminal obtenida en S504 puede sustituir o sobrescribir la información de terminal previa y/o el terminal previo puede registrarse como información de terminal histórica correspondiente al usuario. El AS puede entonces volver a monitorizar mensajes en S502, esperando mensajes de registro y establecimiento de sesión para sus abonados.

Si el mensaje es un mensaje INVITE, el método se traslada al paso S506 donde se determina si las condiciones previas están activadas en el mensaje de establecimiento de sesión correspondiente al usuario. Si no se utilizan las condiciones previas, entonces no se espera que las condiciones previas causen ningún problema al establecer las sesiones y el AS no necesita llevar a cabo ninguna acción y puede trasladarse directamente al paso S510 (para que el INVITE pueda enviarse devuelto sin modificaciones en S511). Sin embargo, cabe señalar que en otros casos, por ejemplo con otras opciones, puede ser deseable considerar si se activa una opción que no se activó en el mensaje de establecimiento de sesión. El experto apreciará que las mismas enseñanzas se aplican igualmente si el sistema está considerando si desactivar o activar una opción que fue activada y desactivada, respectivamente, en el mensaje de establecimiento de llamada. De manera más general, las mismas enseñanzas se aplican al decidir cómo configurar una opción, lo que puede incluir, por ejemplo, configurar un parámetro o valor para una opción cambiando el estado de activación de la opción.

Volviendo al análisis de la figura 5, si sin embargo las condiciones previas son utilizadas por la parte de origen, la información de terminal actualmente asociada al usuario puede recuperarse en S507. Según la presente divulgación, se espera que esta información sea la información del último mensaje REGISTER recibido del usuario, de modo que se espera que sea información de terminal actualizada correspondiente al usuario. Basándose en la información de terminal asociada al usuario, se determina si se espera que el terminal (o agente de usuario) sea compatible con la desactivación de las condiciones previas (S508). Dicho de otra manera, se determina si se espera que el terminal se comporte de la forma deseada al responder a un mensaje de establecimiento de sesión con las condiciones previas desactivadas. Si no se espera que el terminal se comporte adecuadamente, el AS no realiza ninguna acción (S510) con respecto al INVITE y deja las condiciones previas activadas. Por otro lado, si las condiciones previas están activadas (S506-SÍ) y si el terminal es compatible con la desactivación de las condiciones previas (S508), el método se traslada al paso S509 donde el AS puede disponer que se modifique el INVITE para eliminar las condiciones previas. En un ejemplo, el AS puede modificar el INVITE y desactivar o deshabilitar la opción. En otro ejemplo, el AS podría marcar el INVITE como que necesita modificación para eliminar las condiciones previas y permitir que otro elemento (por ejemplo, el SBC/P-CSCF) realice la modificación. En un ejemplo, marcar un mensaje de establecimiento de sesión puede incluir añadir un parámetro para informar a otro nodo (por ejemplo, el SBC) de que la opción de sesión (por ejemplo, condiciones previas) debe deshabilitarse o eliminarse de la sesión. En el caso de una sesión de SIP, esto se puede lograr, por ejemplo, utilizando un campo de encabezamiento reservado (por ejemplo, "X-Remove-Preconditions", que se puede fijar a "TRUE" cuando se deban eliminar las condiciones previas). En el ejemplo de IMS, permitir que el SBC/P-CSCF modifique el mensaje INVITE hace que la eliminación sea más fácil y consuma menos recursos. Estos y otros ejemplos ya se han analizado con mayor detalle anteriormente.

Una vez que el AS ha procesado el INVITE y ha dispuesto su modificación si corresponde, el AS puede reenviar entonces el INVITE en S511. En una red de IMS, el INVITE procesado se devolvería a la S-CSCF pero en otros casos el INVITE puede, por ejemplo, reenviarse hacia la parte de destino a un elemento que no haya recibido o procesado este INVITE antes. El experto podrá determinar cómo enrutar este mensaje en función de la arquitectura y los flujos de llamadas del sistema en cuestión.

La figura 4 ilustra un sistema de ejemplo de acuerdo con la presente divulgación. El sistema de la figura 4 es similar al sistema de ejemplo de la figura 2, de modo que los elementos correspondientes tendrán números de referencia correspondientes. A modo de ejemplo, el UE 401 de la figura 4 se puede corresponder con el UE 201 de la figura 2 de manera que la descripción de la mayoría de los elementos de la figura 4 no se repetirá en el presente documento. En aras de la concisión y claridad, también se han omitido algunos elementos de la ilustración de la figura 4, pero el experto apreciará que la figura 4 es una ilustración simplificada y que estos elementos (y potencialmente cualquier otro elemento adecuado que no esté representado en las figuras 2 y 4) pueden, no obstante, incluirse en el sistema real. Volviendo a la figura 4, el sistema incluye un AS de Condiciones Previas "P-AS" 421 para gestionar las opciones de condiciones previas en llamadas para el terminal 401. El P-AS 421 está conectado a un repositorio o base 431 de datos de información de terminales. Como apreciará el experto, la ilustración de la figura 4 se puede ver desde una perspectiva lógica tal que el repositorio 431 puede implementarse, por ejemplo, como parte del P-AS 421 o como un elemento independiente que el P-AS 421 consultará para determinar información adicional sobre el terminal. También cabe señalar que se pueden proporcionar dos o más repositorios. Por ejemplo, un primero puede proporcionar información sobre el posible modelo de terminal en función de la compilación [build]del agente de usuario en el mensaje de registro, mientras que el segundo puede proporcionar información sobre el cumplimiento del modelo de terminal con las condiciones previas. Nuevamente, de acuerdo con la presente divulgación, ninguno de ellos, uno de ellos o ambos pueden implementarse dentro del P-AS 421, si corresponde. También se pueden implementar en cualquier estructura de datos y/o sistema de gestión de datos apropiado. Por ejemplo, si el P-AS 421 ha determinado el agente de usuario utilizado por el UE 401, puede determinar basándose en información del repositorio 431 qué modelo de terminal está asociado al agente de usuario y asociar el modelo de terminal al usuario. Opcionalmente, una vez que el P-AS 421 recibe posteriormente un INVITE correspondiente al UE 401, puede recuperar el modelo de terminal actualmente asociado al usuario y consultar el repositorio 431 para determinar si el modelo de terminal tiene un comportamiento aceptable cuando se utilizan condiciones previas. En otro ejemplo, el P-AS 421 puede asociar la información de agente de usuario al usuario y, si el P-AS recibe posteriormente un INVITE correspondiente al terminal, puede usar información del repositorio para determinar si el agente de usuario correspondiente al usuario se asocia a un comportamiento esperado cuando se utilizan condiciones previas.

La figura 6 ilustra otro método de ejemplo de acuerdo con la presente divulgación. En este ejemplo, el método se presenta desde la perspectiva del sistema, pero muchas de las enseñanzas y técnicas de este método de ejemplo se corresponden con o son similares a las analizadas con respecto a la figura 5. El método comienza en S601 y en S602 el sistema reenviará al módulo un mensaje de registro de un abonado al servicio para proporcionar el servicio. En una red de IMS se espera que la S-CSCF sea la que lleve a cabo el paso S602, por ejemplo basándose en un perfil de usuario correspondiente al usuario y en si el perfil de usuario indica que el usuario es un abonado de este servicio para gestionar la opción de llamada (por ejemplo, condiciones previas).

A continuación, en S603, el módulo puede identificar información de terminal correspondiente al terminal que el usuario está usando para registrarse, basándose en el mensaje de registro recibido desde el terminal. Por ejemplo, el mensaje de registro puede incluir información tal como información relativa a un cliente y/o agente de usuario que se ejecuta en el terminal, información del sistema operativo, información de marca y/o modelo. Si el mensaje de registro incluye información tal como una compilación de un agente de usuario o de un sistema operativo, puede ser posible obtener a partir de esta información información adicional sobre el terminal. Por ejemplo, puede ser detectable un modelo o una marca. En otros casos, esta información podría ser suficiente para determinar el comportamiento esperado con respecto a la opción. Por ejemplo, puede ser que el comportamiento pueda clasificarse en función de cada agente de usuario o cada compilación de agente de usuario individualmente, de modo que esta información pueda ser suficiente para tomar una determinación sobre el comportamiento esperado.

En el paso S604, se reenvía al módulo un mensaje de establecimiento de sesión correspondiente al usuario. Si bien los pasos de método correspondientes al método de la figura 6 (o figura 5) se pueden llevar a cabo en cualquier orden apropiado, generalmente se espera que el usuario sólo pueda recibir un mensaje de establecimiento de sesión cuando esté registrado y activo. En consecuencia, el comportamiento esperado es que el terminal envíe un mensaje de registro (que puede procesarse en S602-S603) antes de que pueda recibir (o enviar) un mensaje de establecimiento de sesión para establecer una sesión. En este caso, el módulo habrá recibido un mensaje de registro y habrá realizado los pasos S602-S603 antes de recibir un mensaje de establecimiento de sesión y puede llevar a cabo los pasos S604-S605. Una vez que al módulo se le ha reenviado el mensaje de establecimiento de sesión, puede identificar si la opción de sesiones está activada o no para la sesión (S605).

A continuación, en S606, si la opción se activa sobre la base de S605 y si se determina que el terminal es compatible con la desactivación de la opción de sesión (basándose en la información de terminal de S603), el mensaje de establecimiento de sesión se modifica para deshabilitar la opción de sesión. Como se ha mencionado anteriormente, este en ocasiones puede ser modificado por el módulo o puede ser modificado por otro elemento (por ejemplo, una P-CSCHSBC en una red de IMS).

La figura 7 ilustra un dispositivo de ejemplo para uso en una red de telecomunicaciones móviles. Por ejemplo, la estructura de la figura 7 se puede aplicar a una estación base y/o a un terminal de la presente divulgación. Más específicamente, el dispositivo 700 puede incluir al menos una unidad 701 de procesamiento, tal como una CPU, una GPU, etc.; una memoria 702 que puede ser cualquier combinación de memoria volátil y no volátil/persistente. Por ejemplo, la memoria 702 puede usarse para almacenar cualquier dato tal como un sistema operativo,software(que puede, por ejemplo, ser ejecutado por la unidad de procesamiento), información de configuración para el dispositivo, información de sesión, información de configuración para cualquier otro nodo, etc. Dicho terminal se puede hacer funcionar para ejecutar un sistema operativo, un agente de usuario, un cliente de SIP, etc. Al menos la unidad 701 de procesamiento está conectada a un transmisor 703 y a un receptor 704. Mientras que en el ejemplo de la figura 7 el transmisor 703 y el receptor 704 se han representado como dos elementos independientes, en otros casos, pueden proporcionarse y/o representarse como un único transceptor, y en otros casos, pueden proporcionarse más de un transmisor, receptor y/o transceptor. Además, el experto apreciará que la figura 7 es una representación esquemática de un dispositivo y que la implementación real de un dispositivo puede incluir más/menos elementos, mientras que las conexiones entre los diferentes elementos pueden diferir, por ejemplo, dependiendo de las elecciones de implementación para el dispositivo. Por ejemplo, se puede decidir que la unidad 701 de procesamiento pueda conectarse al transmisor 703 y/o al receptor 704 a través de un administrador de radiocomunicaciones o cualquier otro adecuado. Por ejemplo, el administrador de radiocomunicaciones puede configurarse para procesar datos para su transmisión, recibidos de capas superiores (por ejemplo, de una aplicación, una capa de IP, etc.), para generar mensajes que pueden transmitirse de forma inalámbrica de acuerdo con un protocolo de comunicaciones móviles. Asimismo, puede configurarse para procesar mensajes recibidos por vía aérea para pasar información/datos a una capa superior, según corresponda.

De acuerdo con la presente divulgación, se proporciona una disposición para configurar una opción para una sesión (por ejemplo, una opción de condiciones previas) dependiendo de si el usuario está utilizando un terminal que se cree que es compatible con la activación y/o desactivación de la opción, antes de que el mensaje de establecimiento de sesión llegue a la parte de destino.

En consecuencia, las enseñanzas y técnicas de la presente divulgación se pueden aplicar en función de cada llamada individual, al tiempo que se proporciona una técnica de procesamiento de mensajes para mensajes de establecimiento de sesión que intenta limitar el tiempo y la complejidad adicionales que pueden asociarse al procesamiento de mensajes. Por ejemplo, se puede evitar o reducir el uso de consultas externas y flujos complicados, lo que reduce la latencia y la complejidad y también aumenta la precisión de la evaluación, ya que se espera que la información de terminal sea más fiable y esté actualizada cuando se obtiene a partir de los mensajes de registro en lugar de una base de datos de terceros.

Es de destacar que, aunque la invención se ha descrito desde la perspectiva de comprobar información sobre la parte de destino antes de decidir si se modifica la información de establecimiento de sesión para deshabilitar la opción, en otros casos se pueden usar las mismas técnicas para la parte de origen. En el ejemplo de IMS, este caso de uso es menos relevante ya que el agente de usuario u otra información de terminal correspondiente a la parte de origen a menudo está disponible en el mensaje de establecimiento de sesión (por ejemplo, en un campo de agente de usuario en un mensaje INVITE de SIP). En consecuencia, obtener esta información a partir del mensaje REGISTER podría ser, entonces, redundante y por tanto no óptimo. Sin embargo, en otros casos, puede haber información que no esté disponible en el mensaje de establecimiento de sesión y que esté disponible en el mensaje de registro. Dicha información puede ser útil para determinar si se deben cambiar los parámetros u opciones de las sesiones en función de la información de terminal correspondiente a la parte de origen.

Además, si bien la revisión y modificación (si corresponde) del mensaje de establecimiento de sesión sobre la base de la información de terminal para la parte de destino se puede llevar a cabo en el tramo de destino de la sesión (por ejemplo, como se esperaría cuando se utiliza un esquema de registro de terceros), las técnicas presentes también se pueden aplicar en el tramo de origen de la sesión. La figura 8 proporciona tres ejemplos ilustrativos de cómo se pueden implementar las técnicas analizadas en este documento. En aras de la concisión y claridad, no se ha representado el flujo de llamada de registro, pero el experto entenderá que para los ejemplos 1 y 2, al menos la parte B habría realizado un procedimiento de registro en la red (del cual se puede obtener información de terminal) y, para el ejemplo 3, al menos la parte A habría realizado un procedimiento de registro en la red (del cual también se puede obtener información de terminal). En la figura 8, ambas partes han sido representadas como abonados de IMS pero, como quedará claro a partir del análisis siguiente, en algunos casos, una de las partes puede no ser un abonado de IMS e, incluso cuando lo sea, quedará claro que, en algunos casos, no es necesario que sean abonados de la misma red de IMS.

-Ejemplo 1:en este ejemplo el análisis y modificación - si procede - del mensaje de establecimiento de llamada se produce en el tramo de destino de la llamada. Aunque no es obligatorio, esto resulta en particular muy adecuado para el escenario de registro de terceros analizado anteriormente. Este ejemplo ya se ha analizado anteriormente, por lo que este análisis no se repetirá aquí. Aunque la parte A (parte de origen) se ha ilustrado como un abonado de IMS (de la misma red de IMS o una diferente), esto no es necesario y el mensaje de establecimiento de llamada puede proceder, en cambio, de una red PLMN convencional.

-Ejemplo 2:en este ejemplo, el mensaje de establecimiento de llamada también se analiza y procesa basándose en información de terminal correspondiente a la parte B (la parte de destino), pero esto se lleva a cabo en el tramo de origen de la sesión. En algunos casos, puede resultar beneficioso reconfigurar (si corresponde) la sesión lo antes posible y esto permitiría un procesamiento más temprano del mensaje de establecimiento de sesión. Por ejemplo, la S-CSc F<a>puede ser capaz de detectar que el UE-B (el terminal de la parte B) está registrado en la red de IMS (o cualquier comunicación correspondiente). En consecuencia, puede enviar automáticamente el mensaje de establecimiento de llamada al módulo ("P-AS" en la figura 8) para ver si sería apropiado reconfigurar el mensaje de establecimiento de sesión. Si bien aún sería posible enviar el mensaje de establecimiento de llamada al módulo en el tramo de destino (como se ilustra en el ejemplo 1), como el mensaje ya ha sido procesado a este respecto, sería menos complejo y llevaría menos tiempo no enviarlo al módulo nuevamente.

-Ejemplo 3:este caso ilustra el procesamiento del mensaje de establecimiento de llamada basado en información de terminal correspondiente a la parte A (la parte de origen) donde esto se lleva a cabo en el tramo de origen. Como se ha analizado anteriormente, con la configuración actual del IMS, no se espera que se dependa de las técnicas analizadas en este documento (ya que la información de terminal se puede obtener del INVITE de SIP) pero en otro contexto donde en el mensaje de registro haya disponible información de terminal que no está disponible en el mensaje de establecimiento de llamada, esta podría ser una implementación útil. Nuevamente, no existe ningún requisito para que la parte B sea un abonado de IMS.

Como apreciará el experto, la redacción utilizada en la presente divulgación generalmente utiliza la terminología del IMS, pero las enseñanzas de la presente divulgación no se limitan al IMS. Asimismo, el experto apreciará que los términos usuario y abonado pueden usarse de forma intercambiable. En particular, generalmente se esperará que el usuario sea un abonado de al menos un servicio (por ejemplo, el IMS, una red móvil, un servicio más específico o un conjunto de dos o más de dichos servicios) y que el usuario - o terminal del usuario - envíe un mensaje de registro para registrarse de acuerdo con esta suscripción de servicio.

Además, aunque los pasos del método en general se han presentado en un orden específico, la presente divulgación abarca métodos en los que cualquiera de los pasos del método se lleva a cabo en un orden diferente y/o en paralelo a otro u otros pasos, siempre que sea técnicamente viable. Por ejemplo, en la figura 5, los pasos S507 y S506 podrían intercambiarse. En tal caso, se obtendrá la información de terminal correspondiente al usuario antes de comprobar las condiciones previas. En otro ejemplo, podrían llevarse a cabo primero los pasos S507 y S508 y si el resultado de S508 es SÍ, el método podría entonces llevar a cabo el paso S506 y trasladarse a S509 si se activan las condiciones previas. En otro ejemplo más, los pasos S506 y S508 podrían llevarse a cabo en paralelo o en conjunto y dependiendo del resultado de las dos pruebas, el método a continuación proseguiría hacia S509 o S510. Estos son ejemplos de variaciones no exhaustivas de los métodos analizados en el presente documento que siguen siendo acordes a las enseñanzas de la presente divulgación, independientemente del orden en el que se llevan a cabo los pasos. Los mismos principios se aplican igualmente con respecto a la figura 6. Por ejemplo, los pasos S603 y S604 pueden llevarse a cabo en paralelo.

Además, en aras de la concisión, no se han analizado explícitamente aquí todas las alternativas. Como apreciará el experto, en la presente divulgación cualquier aspecto analizado desde la perspectiva de que un elemento sea operativo para llevar a cabo una acción también revela la misma característica desde la perspectiva del método para llevar a cabo la acción. Y de la misma manera, cualquier análisis presentado desde la perspectiva de un paso del método también revela las mismas características desde la perspectiva de que uno o más elementos adecuados cualesquiera sean operativos para llevar a cabo parte o la totalidad del paso del método. También se considera dentro de la presente divulgación que para cualquier paso(s) del método, puede haber un programa informático configurado para llevar a cabo, cuando se ejecute, el(los) paso(s) del método. Además, un dispositivo, tal como un terminal o un nodo de red, se considera generalmente desde una perspectiva lógica, como elemento que lleva a cabo la función apropiada. Por lo tanto, cualquier dispositivo de este tipo puede implementarse utilizando uno o más elementos físicos según se considere apropiado. Por ejemplo, puede implementarse en uno (o más) de: un dispositivo físico autónomo, en dos o más dispositivos físicos independientes, en un sistema distribuido, en un entorno virtual utilizando cualquierhardwareo combinación dehardwareadecuado, etc. Por ejemplo, cuando se analiza que el módulo procesa información del mensaje de registro e información del mensaje de establecimiento de sesión, se apreciará que dos elementos diferentes pueden estar implementando estas funciones respectivas. Por ejemplo, un primer módulo o nodo puede estar procesando el mensaje de registro del terminal (y por ejemplo actualizar una base de datos de los terminales actuales para abonados) mientras que un segundo módulo o nodo puede estar procesando el mensaje de establecimiento de llamada del terminal y puede estar consultando la base de datos para revisar la información obtenida por el primer nodo o módulo. En el contexto de la presente divulgación y desde una perspectiva lógica, dicho primer y segundo nodos pueden verse como un único módulo (lógico) de gestión de llamadas. Como se ha mencionado anteriormente, el primer y segundo nodos pueden verse como elementos lógicos de modo que pueden implementarse como una función de un nodo existente en el sistema y el módulo de gestión de llamadas puede verse como una combinación (lógica) de estas dos funciones.

Asimismo, para cualquier divulgación de un dispositivo configurado u operativo para llevar a cabo una función, también se considera por la presente divulgada cualquier circuitería (que comprende por ejemplo un transmisor y/o receptor, según corresponda), que esté configurada para llevar a cabo, cuando se esté usando, la misma función. Además, cualquier dispositivo o elemento funcional descrito en el presente documento puede incluir, si corresponde, un número menor o mayor de funciones o elementos. Por ejemplo, y como se ha mencionado anteriormente, los terminales o estaciones base generalmente pueden tener la estructura ilustrada en la figura 7 pero en algunos casos también pueden incluir un elemento adicional tal como un programador, un administrador de radiocomunicaciones (por ejemplo, para gestionar diferentes antenas y/o sectores), etc. según corresponda. En otro ejemplo, un dispositivo que tiene la estructura representada de manera general en la figura 7 también puede incluir cualquiera de: un SIM, un administrador de SIM, un sistema operativo, etc., según corresponda.

De acuerdo con la presente divulgación, se ha proporcionado por lo tanto un método para configurar una sesión, donde la sesión puede ser, por ejemplo, una llamada (sesión de voz) tal como una llamada de Voz por LTE "VoLTE", una videollamada o cualquier otra sesión para que al menos dos partes establezcan una sesión. Un mensaje de establecimiento de sesión puede ser cualquier mensaje de establecimiento adecuado, como un INVITE del SIP en el caso de una llamada de VoLTE. Asimismo, el mensaje de registro puede ser cualquier mensaje adecuado para que el abonado se registre en un servicio de acuerdo con su suscripción, tal como un mensaje REGISTER de SIP en el caso del IMS y/o VoLTE. En algunos casos, el mensaje de registro puede ser para una suscripción a la red (por ejemplo, para informar a la red de IMS que el terminal está en línea) mientras que en otros casos, el mensaje de registro puede ser para registrarse en el servicio de gestión de sesiones de acuerdo con la presente divulgación para que el abonado se beneficie de las técnicas de gestión de sesiones aquí analizadas. También se apreciará que en algunos casos el mensaje de registro puede servir efectivamente como un mensaje de registro combinado tanto para una suscripción a la red como para una o más suscripciones a servicios proporcionados por la red. Además, aunque los ejemplos antes proporcionados cubren en general un caso en el que una parte A llama a una parte B, el experto apreciará que la sesión puede involucrar más de dos partes. Por ejemplo, la parte A puede llamar a dos o más partes B, C, etc. o una o más partes podrían ser contactadas por un servicio en lugar de una parte. Por ejemplo, un servicio de conferencia puede contactar con una o más partes para establecer una llamada de conferencia con dos o más asistentes. Para una o más de las partes contactadas, las enseñanzas proporcionadas en este documento se pueden utilizar para configurar los parámetros de la sesión.

Del mismo modo, si el mensaje de establecimiento de llamada es para una sola parte pero esta parte tiene dos o más dispositivos, se aplica el mismo principio. Esto implicará una bifurcación de llamada en la que el mensaje se enviará a los dos o más dispositivos y la parte puede establecer la sesión desde cualquiera de ellos. En un ejemplo, cada invitación se adaptará para el dispositivo al que va dirigida. En un ejemplo de configuración de condiciones previas, una de las invitaciones puede tener las condiciones previas activadas y otra podría tener las condiciones previas desactivadas. Dependiendo de dónde se produce la bifurcación de la llamada y de dónde se aplican las técnicas de configuración de sesión proporcionadas en este documento, puede resultar difícil disponer de un mensaje de establecimiento de llamada diferente para dispositivos diferentes. En este caso, se puede enviar el mismo mensaje de establecimiento de llamada a todos los dispositivos. En este caso, se analizará en su conjunto el grupo de terminales (registrados) del usuario. Si uno o más terminales del grupo de terminales no admite la eliminación de las condiciones previas, entonces el módulo puede decidir no eliminar las condiciones previas (incluso aunque otros terminales pudieran admitirla). Esto evitaría la aparición de problemas si se eliminan las condiciones previas y si el usuario establece la llamada desde un dispositivo que en realidad no admite su eliminación.

Además, la configuración deseada puede en algunos casos tener en cuenta la información de terminal. Con el procedimiento de condiciones previas, se espera que la configuración deseada sea desactivar las condiciones previas siempre que el(los) terminal(es) de destino pueda(n) gestionar esto adecuadamente. No obstante, en otros casos la configuración puede depender de la información de terminal. Por ejemplo, una opción puede estar asociada a un parámetro de opción y la configuración deseada podría ser tener que dejar la opción activada siempre que sea posible y tener un valor que se adapte a la clase de dispositivo. Por ejemplo, un terminal que no se comporta de la manera esperada cuando se recibe el mensaje de establecimiento de llamada puede tener la opción desactivada (con el fin de reducir el número de mensajes recibidos por este terminal con esta opción activada). Sin embargo, por otro lado, entre terminales que se comportan como se espera, el valor al que se fija este parámetro de opción de llamada se puede modificar, si corresponde, en función de la información de terminal. En otros casos, la opción siempre estará activada o desactivada y el parámetro de valor asociado a ella puede seleccionarse en función del(de los) terminal(es) de la parte de destino. En consecuencia, el mensaje de establecimiento de llamada se puede configurar basándose en el(los) terminal(es) correspondiente(s) a la parte incluso antes de que se haya recibido una respuesta. Esto es especialmente útil cuando esperar la respuesta de un terminal supone una mayor probabilidad de tener problemas con la sesión.

Si bien la presente técnica se centra en utilizar información de terminal para tomar una determinación sobre cómo configurar una opción de sesión, se apreciará que se puede utilizar información adicional cuando sea apropiado. En algunos ejemplos, los datos de la red de acceso pueden obtenerse a partir del mensaje de registro y esta información actualizada y precisa puede usarse si posteriormente se recibe un mensaje de establecimiento de sesión correspondiente al usuario. Por ejemplo, el módulo de servicio se puede configurar para que también acepte información de la red de acceso para determinar si un terminal es compatible con la configuración deseada. Por ejemplo, generalmente se puede esperar que un terminal que accede a la red a través de una red Wi-Fi o un tipo equivalente de red de acceso tenga más recursos disponibles y/o más fiabilidad con respecto a la disponibilidad de recursos. Por consiguiente, dependiendo de la opción y de la complejidad de la implementación, esto se puede tener en cuenta a la hora de determinar si el terminal es compatible con la configuración deseada. Mirando el ejemplo de condiciones previas, a un terminal que responde a un INVITE de SIP sin condiciones previas con un mensaje del SIP 180 (y no un mensaje 183 con un SDP) no se le podría permitir, por ejemplo, tener las condiciones previas desactivadas si accede a la red a través de una red de acceso móvil pero podría tener la opción desactivada al utilizar una red Wi-Fi o doméstica (incluso si la red doméstica proporciona conectividad móvil al terminal). En otros casos también se puede tener en cuenta la tecnología de la red de acceso. Por ejemplo, si una tecnología móvil está asociada a una mayor fiabilidad y/o un mayor caudal de datos y/o menores retardos que otras, esto puede afectar a la decisión sobre cómo configurar el terminal (la configuración deseada) y/o afectar a si un terminal se considera compatible con la configuración deseada. Aparte de la información de la red de acceso obtenida a partir del mensaje de registro, para realizar una o ambas acciones de entre determinar la configuración deseada para el mensaje de establecimiento de sesión y si uno o más terminales son compatibles con la configuración deseada, puede usarse cualquier otro tipo adecuado de información que pueda obtenerse de este mensaje y/o cualquier otro tipo adecuado de información obtenida de una manera diferente.

También cabe señalar que "o" se utiliza aquí en el sentido no exclusivo (es decir, y/o) a menos que la "o exclusiva" sea la única lectura posible en términos de lógica o técnica. Además, siempre que se analicen los elementos como conectados, esto abarca que estos elementos estén conectados directa o indirectamente. Por ejemplo, en la figura 3, en general no se esperaría que ningún mensaje del UE-B al SBC fuera directamente al SBC sino que primero pasaría por una estación base y uno o más equipos de la red móvil o de acceso antes de que pudiese llegar al SBC. Asimismo, la unidad 701 de procesamiento de la figura 7 puede no estar conectada directamente a los otros elementos 702, 703 y/o 704 del dispositivo y la conexión puede incluir uno o más elementos adicionales.

De acuerdo con la presente divulgación, se ha proporcionado por tanto un sistema para configurar una opción de sesión para una sesión de un usuario en una red de telecomunicaciones móviles. El sistema comprende un módulo de servicio para proporcionar al menos al usuario un servicio de configuración de opciones de sesión para configurar la opción de sesión; y un terminal correspondiente al usuario. La red de telecomunicaciones móviles está configurada para reenviar al módulo de servicio, cuando el usuario está registrado en el servicio de configuración de opciones de sesión, mensajes de registro del usuario y mensajes de establecimiento de sesión correspondientes al usuario. El módulo de servicio está configurado para identificar, al producirse la recepción de un mensaje de registro del usuario y enviado a través del terminal, información de terminal correspondiente al terminal y para detectar, al producirse la recepción de un mensaje de establecimiento de sesión para establecer una sesión correspondiente al usuario, la configuración actual correspondiente a la opción de sesión para la sesión. El sistema está configurado para, si se determina que la configuración actual para la opción de sesión no es la configuración deseada y si, basándose en la información de terminal identificada correspondiente al terminal, se determina que el terminal correspondiente al usuario es compatible con la configuración deseada para la opción de sesión, modificar el mensaje de establecimiento de sesión con el fin de configurar la opción de sesión en la configuración deseada. Como se ha analizado anteriormente, se pueden configurar más de un elemento del sistema para implementar esta disposición. Por ejemplo, el módulo de servicio puede determinar que el terminal correspondiente al usuario es compatible (o no) con la configuración deseada para la opción de sesión y otro elemento (por ejemplo, el SBC anterior) del sistema puede modificar el mensaje de establecimiento de sesión para configurar la opción de sesión de manera que se sitúe en la configuración deseada.

El mensaje de establecimiento de sesión bien puede estar dirigido al menos al usuario (caso de destino) o bien puede originarse en el usuario (caso de origen).

La configuración deseada es una o más de: una activación de la opción de sesión, una desactivación de la opción de sesión y un parámetro de configuración de la opción de sesión. Por ejemplo, con la opción de condiciones previas, una configuración deseada puede ser tener la opción desactivada. En otros casos, puede que se desee tener la opción activada y/o tener la opción configurada de una manera específica (en los casos en los que dicha configuración esté disponible). Por ejemplo, si la opción de sesión se puede configurar con uno o más parámetros, estos parámetros se pueden configurar antes de que la parte de destino reciba el mensaje.

La red de telecomunicaciones móviles puede comprender una red de Subsistema Multimedia de IP "IMS" y el sistema puede entonces configurarse para registrar al usuario en el servicio de gestión de opciones utilizando un esquema de registro de terceros de la red de IMS. En consecuencia, los mensajes de registro y establecimiento de sesión del usuario serán enviados al módulo de servicio en función de la suscripción a este servicio de gestión de opciones.

El sistema se puede configurar para registrar al usuario para utilizar el servicio de gestión de opciones configurando un perfil de usuario correspondiente al usuario con el fin de indicar que el usuario está registrado para utilizar el servicio de gestión de opciones (por ejemplo, un perfil de IMS para el abonado de IMS, estando activada esta opción) y/o fijando una configuración predeterminada para usuarios de la red de modo que los usuarios se registren en el servicio de gestión de opciones a menos que se configure lo contrario. Por ejemplo, todos los usuarios pueden inscribirse automáticamente en este servicio y la opción de sesiones para terminar y/o iniciar sesiones para todos los usuarios puede configurarse de acuerdo con las enseñanzas de la presente divulgación. En tal caso, todos los mensajes de establecimiento de sesión dirigidos a uno o más terminales que estén registrados en la red se enviarán a un elemento o nodo para ver si se cambiará o no la configuración de la opción de sesión. En algunos casos, si corresponde, podría haber una opción para omitir esta configuración predeterminada y excluir a algunos de los usuarios. Esto podría, por ejemplo, excluir a usuarios seleccionados (por ejemplo, usuarios de prueba, usuarios de uno o más clientes empresariales, etc.).

Como habrá comprendido el experto, la opción de sesión puede ser en ocasiones una opción asociada a un intercambio de condiciones previas o a un procedimiento de extensión de SIP de condiciones previas. Por ejemplo, puede ser una opción para indicar si se debe utilizar un procedimiento de condiciones previas.

Como se ha analizado, el módulo de servicio puede configurarse para modificar el mensaje de establecimiento de sesión con el fin de configurar la opción de sesión en la configuración deseada en el mensaje de establecimiento de sesión (por ejemplo, para desactivar la opción en el ejemplo de condiciones previas analizado en el presente documento) o configurarse para identificar el mensaje de establecimiento de sesión para su modificación. En este último caso, el sistema puede comprender un módulo adicional (por ejemplo, SBC / P-CSCF) configurado para modificar, al detectar que el mensaje de establecimiento de sesión se identifica para su modificación, el mensaje de establecimiento de sesión con el fin de configurar la opción de sesión en la configuración deseada en el mensaje de establecimiento de sesión (por ejemplo, desactivar la opción de condiciones previas). El módulo adicional puede llevar a cabo esa detección basándose en el propio mensaje (si, por ejemplo, el mismo ha sido marcado) o utilizando cualquier otra indicación adecuada, por ejemplo, un mensaje independiente del módulo de servicio que identifica este mensaje para su modificación.

Como recordatorio, la invención solo se define por las reivindicaciones y no está limitada por las implementaciones de ejemplo proporcionadas en la divulgación.

Referencias

[1] 3GPP TS 24.229 V13.13.0 (2018-03-28) "IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (<s>D<p>)''

[2] 3GPP TR 29.962 V6.1.1 (2005-10-20) "Signalling interworking between the 3GPP profile of the Session Initiation Protocol (SIP) and non-3GPP SIP usage"

Claims

REIVINDICACIONES

1. Un sistema para configurar una opción de sesión para una sesión de un usuario en una red (210) de telecomunicaciones móviles, en donde el sistema comprende:

un módulo (221,222) de servicio para proporcionar al menos al usuario un servicio de configuración de opciones de sesión para configurar la opción de sesión; y

un terminal (201) para el usuario,

en el que la red (210) de telecomunicaciones móviles está configurada para reenviar al módulo (221, 222) de servicio, cuando el usuario está registrado en el servicio de configuración de opciones de sesión, mensajes de registro del usuario y mensajes de establecimiento de sesión correspondientes al usuario;

en el que el módulo (221, 222) de servicio está configurado para identificar, al producirse la recepción de un mensaje de registro del usuario y enviado a través del terminal (201), información de terminal correspondiente al terminal (201) y para detectar, al producirse la recepción de un mensaje de establecimiento de sesión para establecer una sesión para el usuario, la configuración actual de la sesión;

en el que el sistema está configurado para, cuando se determina que la configuración actual de la opción de sesión no es la configuración deseada y cuando, basándose en la información de terminal identificada correspondiente al terminal (201), se determina que el terminal (201) correspondiente al usuario es compatible con la configuración deseada para la opción de sesión, modificar el mensaje de establecimiento de sesión para configurar la opción de sesión en la configuración deseada, en donde la opción de sesión está asociada a un intercambio de condiciones previas o a un procedimiento de extensión de SIP de condiciones previas y en donde la configuración deseada es una desactivación de la opción de sesión.

2. El sistema de la reivindicación 1, en el que el mensaje de establecimiento de sesión bien está dirigido al menos al usuario o bien se origina en el usuario.

3. El sistema de cualquiera de las reivindicaciones 1 a 2 que comprende además un segundo terminal correspondiente al usuario y en el que:

el módulo (221, 222) de servicio está configurado además para identificar, al producirse la recepción de un mensaje de registro del usuario y enviado a través del segundo terminal, información de terminal correspondiente al segundo terminal y para detectar, al producirse la recepción de un mensaje de establecimiento de sesión para establecer una sesión para el usuario, la configuración actual de la sesión;

en el que el sistema está configurado además para modificar el mensaje de establecimiento de sesión con el fin de configurar la opción de sesión en la configuración deseada cuando se determina que la configuración actual de la opción de sesión no es la configuración deseada y, basándose en la información de terminal identificada correspondiente al terminal y correspondiente al segundo terminal, que tanto el terminal (201) como el segundo terminal son compatibles con la configuración deseada para la opción de sesión.

4. El sistema de cualquiera de las reivindicaciones 1 a 3, en el que la red (210) de telecomunicaciones móviles comprende una red de Subsistema Multimedia de IP "IMS" y en el que el sistema está configurado para registrar al usuario en el servicio de gestión de opciones utilizando un esquema de registro de terceros de la red de IMS.

5. El sistema de cualquiera de las reivindicaciones 1 a 4, en el que el sistema está configurado para registrar al usuario para utilizar el servicio de gestión de opciones llevando a cabo una o más de:

configurar un perfil de usuario correspondiente al usuario para indicar que el usuario está registrado para utilizar el servicio de gestión de opciones; y

fijar una configuración predeterminada para usuarios de la red de modo que los usuarios se registren en el servicio de gestión de opciones a menos que se configure lo contrario de modo que, de forma predeterminada, todos los mensajes de establecimiento de sesión correspondientes a usuarios registrados serán procesados por el módulo (221,222) de servicio.

6. El sistema de cualquiera de las reivindicaciones 1 a 5, en el que el módulo (221,222) de servicio es un servidor de aplicaciones en una red de Subsistema Multimedia de IP "IMS".

7. El sistema de cualquiera de las reivindicaciones 1 a 6, en el que la información de terminal comprende uno o más de la totalidad o parte de: un identificador de agente de usuario, un identificador de dispositivo, una IMEI y un identificador de sistema operativo.

8. El sistema de cualquiera de las reivindicaciones 1 a 7, en el que la opción de sesión es una opción que, cuando se activa, configura al usuario para negociar parámetros de sesión de acuerdo con el intercambio de condiciones previas o con el procedimiento de extensión de SIP de condiciones previas, respectivamente.

9. El sistema de cualquiera de las reivindicaciones 1 a 8, en donde que el sistema esté configurado para modificar el mensaje de establecimiento de sesión comprende una o más de:

el módulo (221,222) de servicio está configurado para modificar el mensaje de establecimiento de sesión con el fin de configurar la opción de sesión en la configuración deseada en el mensaje de establecimiento de sesión; y

el módulo (221, 222) de servicio está configurado para identificar el mensaje de establecimiento de sesión para su modificación, en donde el sistema comprende un módulo adicional configurado para modificar, al producirse la detección de que el mensaje de establecimiento de sesión se ha identificado para su modificación, el mensaje de establecimiento de sesión para configurar la opción de sesión en la configuración deseada en el mensaje de establecimiento de sesión.

10. Un módulo (221,222) de servicio para configurar una opción de sesión para una sesión de un usuario en una red (210) de telecomunicaciones móviles, en donde el módulo (221,222) de servicio está configurado para:

identificar, al producirse la recepción de un mensaje de registro de un usuario registrado en un servicio de gestión de opciones y enviado a través de un terminal (201) correspondiente al usuario, información de terminal correspondiente al terminal (201);

detectar, al producirse la recepción de un mensaje de establecimiento de sesión correspondiente al usuario, la configuración actual para la opción de sesión correspondiente a la sesión;

determinar, basándose en la información de terminal identificada correspondiente al usuario, si el terminal (201) correspondiente al usuario es compatible con la configuración deseada para la opción de sesión; y

cuando se determina que la configuración actual para la opción de sesión no es la configuración deseada y que el terminal (201) es compatible con la configuración deseada para la opción de sesión, hacer que el mensaje de establecimiento de sesión se modifique para configurar la opción de sesión con la configuración deseada, en donde la opción de sesión se asocia a un intercambio de condiciones previas o a un procedimiento de extensión de SIP de condiciones previas y en donde la configuración deseada es una desactivación de la opción de sesión.

11. Un método para configurar una opción de sesión para una sesión de un usuario en una red (210) de telecomunicaciones móviles usando un módulo (221,222) de servicio para proporcionar al menos al usuario un servicio de configuración de opciones de sesión para configurar la opción de sesión, en el que la red (210) de telecomunicaciones móviles está configurada para reenviar al módulo (221, 222) de servicio, cuando el usuario está registrado en el servicio de configuración de opciones de sesión, mensajes de registro del usuario y mensajes de establecimiento de sesión correspondientes al usuario, comprendiendo el método:

identificar, al producirse la recepción de un mensaje de registro de un usuario registrado en el servicio de gestión de opciones y enviado a través de un terminal (201) correspondiente al usuario, información de terminal correspondiente al terminal (201);

detectar, al producirse la recepción de un mensaje de establecimiento de sesión para establecer una sesión correspondiente al usuario, que la configuración actual para la opción de sesión está activada para la sesión;

cuando se determina que la configuración actual para la opción de sesión no es la configuración deseada y cuando, basándose en la información de terminal identificada correspondiente al terminal (201), se determina que el terminal (201) correspondiente al usuario es compatible con la configuración deseada para la opción de sesión, modificar el mensaje de establecimiento de sesión para configurar la opción de sesión en la configuración deseada, en donde la opción de sesión se asocia a un intercambio de condiciones previas o a un procedimiento de extensión de SIP de condiciones previas y en donde la configuración deseada es una desactivación de la opción de sesión.

12. Un método para hacer funcionar un módulo (221, 222) de servicio con vistas a configurar una opción de sesión para una sesión de un usuario en una red (210) de telecomunicaciones móviles, comprendiendo el método que el módulo (221,222) de servicio:

identifique, al producirse la recepción de un mensaje de registro de un usuario registrado en un servicio de gestión de opciones y enviado a través de un terminal (201) correspondiente al usuario, información de terminal correspondiente al terminal (201);

detecte, al producirse la recepción de un mensaje de establecimiento de sesión correspondiente al usuario, la configuración actual para la opción de sesión correspondiente a la sesión;

determine, basándose en la información de terminal identificada correspondiente al usuario, si el terminal (201) correspondiente al usuario es compatible con la configuración deseada para la opción de sesión; y

cuando se determina que la configuración actual para la opción de sesión no es la configuración deseada y que el terminal (201) es compatible con la configuración deseada para la opción de sesión, haga que el mensaje de establecimiento de sesión se modifique para configurar la opción de sesión con la configuración deseada, en donde la opción de sesión se asocia a un intercambio de condiciones previas o a un procedimiento de extensión de SIP de condiciones previas y en donde la configuración deseada es una desactivación de la opción de sesión.

13. Un programa informático que comprende instrucciones que, cuando se llevan a cabo, hacen que se implemente el método de la reivindicación 11 ó 12.