Método de procesado de comunicaciones basadas en sesiones, en el que el método comprende:

transmitir (S10, S20), por parte de un terminal (10, 100), un mensaje PUBLICACIÓN del Protocolo de Inicio de Sesión, SIP, hacia un servidor (30, 300) en una red para informar si el terminal soporta sesiones simultáneas del tipo Pulsar para, PT, siendo usado el mensaje PUBLICACIÓN del SIP por el servidor para determinar si debe funcionar en un modo de Agente de Usuario Encarado a Ambos Extremos, B2BUA, o en un modo proxy del SIP, e incluyendo un valor fijado a activo para indicar que el terminal soporta sesiones de PT simultáneas o fijado a no activo para indicar que el terminal no soporta sesiones de PT simultáneas; recibir, por parte del terminal, un mensaje de respuesta desde el servidor en respuesta al mensaje PUBLICACIÓN del SIP; establecer (S16, S25), por parte del terminal basándose en el mensaje de respuesta, una sesión de PT con el servidor que ha determinado funcionar en el modo B2BUA basándose en el valor del mensaje PUBLICACIÓN del SIP y basándose en una indicación de que el servidor soporta las sesiones de PT simultáneas; y enviar, por parte del terminal a través de la sesión de PT establecida, datos del Protocolo de Tiempo Real, RTP, o datos del Protocolo de Control de Ráfagas de Conversación, TBCP, al servidor que funciona en el modo B2BUA.

Campo técnico

La presente invención se refiere a un servicio basado en sesiones, de un Subsistema Multimedia IP (IMS), y particularmente, a un equipo de usuario (UE), a un método y a un sistema para controlar una sesión simultánea para servicios tales como un servicio del tipo Pulsar para Hablar a través del Celular (PoC).

Antecedentes de la técnica

En general, en un documento RFC 3261 de un Grupo de Trabajo de Ingeniería de Internet (IETF), los métodos de funcionamiento de servidores del Protocolo de Inicio de Sesión (SIP), tales como un servidor del PoC, se pueden dividir en un método proxy del SIP y un método de Agentes de Usuario Encarados a Ambos Extremos (B2BUA).

Las figuras 1 y 2 son diagramas de flujo para explicar respectivamente el método de los B2BUA y el método proxy del SIP según la técnica relacionada.

Tal como se ilustra en la figura 1, en el modo de funcionamiento B2BUA, los datos del Protocolo de Tiempo Real (RTP), los datos del Protocolo de Control de Tiempo Real (RTCP) y los datos del Protocolo de Control de Ráfagas de Conversación (TBCP) así como los mensajes del SIP, que son transmitidos y recibidos entre un cliente del PoC y un servidor B del PoC (servidor que ejecuta una función de control), deben pasar siempre a través de un servidor A del PoC (servidor que ejecuta una función de participación). De modo similar, tal como se ilustra en la figura 2, en el modo de funcionamiento proxy del SIP, los mensajes del SIP transmitidos y recibidos entre el cliente del PoC y el servidor B del PoC pasan siempre a través del servidor A del PoC. No obstante, en el modo proxy del SIP, los datos del RTP, los datos del RTCP y los datos del TBCP no pasan a través del servidor A del PoC, sino que son transmitidos y recibidos directamente entre el cliente del PoC y el servidor B del PoC.

Como tales, el modo proxy del SIP y el modo del B2BUA se pueden diferenciar entre sí dependiendo de si los datos del RTP, del RTCP y del TBCP pasan a través del servidor A del PoC. Es decir, tal como se ilustra en la figura 1, cuando el servidor A del PoC funciona en un modo B2BUA, los datos del RTP, del RTCP y del TBCP que son transmitidos y recibidos entre el cliente del PoC y el servidor B del PoC pasan siempre a través del servidor A del PoC. No obstante, tal como se ilustra en la figura 2, cuando el servidor A del PoC funciona en un modo proxy del SIP, los datos del RTP, del RTCP y el TBCP que son transmitidos y recibidos entre el cliente del PoC y el servidor B del PoC no pasan a través del servidor A del PoC. El servidor A del PoC que funciona en el modo proxy del SIP según la técnica relacionada no puede recibir y no recibe los datos del RTP, del RTCP y del TBCP desde el cliente del PoC o el servidor B del PoC, y por consiguiente no puede controlar dichos datos. No obstante, existen situaciones en las que dicho control es necesario.

Como es sabido, un servidor del PoC tiene tanto una función del PoC de control como una función del PoC de participación. La función del PoC de control del servidor del PoC proporciona una gestión centralizada de las sesiones del PoC, incluyendo una distribución de medios del RTP, un control de las Ráfagas de Conversación, una potenciación de las políticas para participar en una sesión de grupo, control de información de los participantes, y similares. La función del PoC de participación del servidor del PoC proporciona una potenciación de políticas para sesiones del PoC entrantes, y un procesado de sesiones del PoC para retransmitir un mensaje de control de Ráfagas de Conversación entre el cliente del PoC y el servidor del PoC que ejecuta la función del PoC de control. La función del PoC de participación puede retransmitir unos medios del RTP entre el cliente del PoC y el servidor del PoC que ejecuta la función del PoC de control.

La función del PoC de participación de un servidor del PoC (por ejemplo, servidor A del PoC) puede soportar (es capaz de proporcionar) una “sesión de PoC simultánea” para el cliente del PoC. En la presente descripción, una “sesión de PoC simultánea” es una sesión durante la cual el servidor del PoC ejecuta una función de prioridades de sesiones de PoC o una función de enganche de PoC. La función de prioridades de sesiones de PoC por parte del servidor del PoC da prioridad a una sesión de PoC específica, para el cliente del PoC que ha iniciado o recibido invitaciones a una pluralidad de sesiones de PoC. La función de enganche de PoC por parte del servidor del PoC permite la transmisión de datos de medios relacionados solamente con una sesión de PoC específica, hacia el cliente del PoC mientras que retiene la transmisión de datos de medios asociados a otras sesiones. De esta manera, se puede decir que la sesión de PoC simultánea conlleva el filtrado de ciertos datos (por ejemplo, conjuntos de datos del RTP) para proporcionar solamente un conjunto de datos del RTP, por ejemplo, correspondientes a la sesión enganchada o sesión principal. Algunos servidores del PoC y clientes del PoC pueden soportar la sesión de PoC simultánea mientras que otros servidores del PoC y clientes del PoC puede que no soporten la sesión de PoC simultánea.

Como ejemplo, supóngase que existe un cliente del PoC y un servidor del PoC que soportan y llevan a cabo una sesión de PoC simultánea. Según la función de prioridades de sesiones de PoC, el cliente del PoC fija solamente una sesión de PoC como Principal, y otras sesiones de PoC como Secundarias. Preferentemente, se transfiere un valor de dicha prioridad de la sesión de PoC desde el cliente del PoC al servidor del PoC que ejecuta la función del PoC de participación (por ejemplo, el servidor A del PoC) usando un mensaje INVITACIÓN (INVITE), REINVITACIÓN (RE-INVITE) o ACTUALIZACIÓN (UPDATE).

Al producirse la fijación del valor de prioridad de la sesión del PoC, el servidor del PoC que ejecuta la función de participación (servidor A del PoC) transfiere datos al cliente del PoC basándose en el valor fijado de prioridad de la sesión de PoC. A saber, una vez que se ha fijado una sesión de PoC como Principal, cuando se reciben datos de medios desde la sesión de PoC principal mientras el servidor del PoC recibe datos de medios de las sesiones de PoC secundarias, el cliente del PoC puede recibir inmediatamente los datos de medios de la sesión de PoC principal por encima de los datos de medios de las sesiones de PoC secundarias bajo el control del servidor A del PoC. Es decir, según la prioridad de sesión fijada por el cliente del PoC, el servidor A del PoC puede transmitir selectivamente (transmitir o no transmitir) datos de medios asociados a cada sesión de PoC hacia el cliente del PoC en un cierto orden de prioridad.

Por otro lado, según la función de enganche de PoC, el cliente del PoC fija un “enganche” (se enganchará) con una sesión de PoC, y de este modo puede recibir datos de medios relacionados solamente con la sesión de PoC enganchada mientras que no recibe datos de medios relacionados con otras sesiones de PoC desde el servidor A del PoC (servidor que ejecuta la función de participación). De esta manera, la función de enganche desestima datos de medios de ciertas sesiones de PoC. Preferentemente, el valor de enganche de la sesión de PoC se transfiere desde el cliente del PoC al servidor A del PoC a través de un mensaje INVITACIÓN, RE-INVITACIÓN o ACTUALIZACIÓN, y se fija en el servidor A del PoC. Al producirse la fijación del valor de enganche de la sesión de PoC, el servidor A del PoC determina si transferir o no datos de medios al cliente del PoC basándose en el valor de enganche fijado de la sesión de PoC, y transfiere selectivamente (transfiere o no) los datos de medios hacia el cliente del PoC según el resultado de la determinación.

Por lo tanto, para ejecutar una sesión de PoC simultánea (por ejemplo, una función de prioridad de sesión de PoC, una función de enganche de PoC, etcétera) para un servicio PoC, tal como se ilustra en la figura 1, es necesario que los datos de medios, incluyendo datos de RTP, datos de RTCP, datos de TBCP, etcétera, pasen a través del servidor A del PoC (que ejecuta la función de participación) cuando los mismos se comunican entre el cliente del PoC y el servidor B del PoC (que ejecuta la función de control) puesto que el servidor A del PoC debe controlar el flujo de datos según la función de enganche de PoC o la función de prioridades de sesiones de PoC. Por ejemplo, es necesario que el servidor A del PoC que ejecuta la función de PoC de participación reciba los datos de RTP (por ejemplo, datos... [Seguir leyendo]

1. Método de procesado de comunicaciones basadas en sesiones,

en el que el método comprende:

transmitir (S10, S20), por parte de un terminal (10, 100), un mensaje PUBLICACIÓN del Protocolo de Inicio de Sesión, SIP, hacia un servidor (30, 300) en una red para informar si el terminal soporta sesiones simultáneas del tipo Pulsar para, PT,

siendo usado el mensaje PUBLICACIÓN del SIP por el servidor para determinar si debe funcionar en un modo de Agente de Usuario Encarado a Ambos Extremos, B2BUA, o en un modo proxy del SIP, e incluyendo un valor fijado a activo para indicar que el terminal soporta sesiones de PT simultáneas o fijado a no activo para indicar que el terminal no soporta sesiones de PT simultáneas;

recibir, por parte del terminal, un mensaje de respuesta desde el servidor en respuesta al mensaje PUBLICACIÓN del SIP;

establecer (S16, S25), por parte del terminal basándose en el mensaje de respuesta, una sesión de PT con el servidor que ha determinado funcionar en el modo B2BUA basándose en el valor del mensaje PUBLICACIÓN del SIP y basándose en una indicación de que el servidor soporta las sesiones de PT simultáneas; y

enviar, por parte del terminal a través de la sesión de PT establecida, datos del Protocolo de Tiempo Real, RTP, o datos del Protocolo de Control de Ráfagas de Conversación, TBCP, al servidor que funciona en el modo B2BUA.

2. Método según la reivindicación 1, que comprende además:

recibir, por parte del terminal, un mensaje de notificación desde el servidor cuando un número de sesiones de PT en las que está implicado el terminal supera un número máximo de sesiones de PT simultáneas permisibles.

3. Terminal (10, 100) para procesar comunicaciones basadas en sesiones, en el que el terminal comprende:

un controlador (12, 120) adaptado para controlar comunicaciones basadas en sesiones con una red;

una unidad de transmisión adaptada para cooperar con el controlador para transmitir un mensaje PUBLICACIÓN del Protocolo de Inicio de Sesión, SIP, hacia un servidor en la red para informar de si el terminal soporta sesiones simultáneas del tipo Pulsar Para, PT,

siendo usado el mensaje PUBLICACIÓN del SIP por el servidor para determinar si debe funcionar en un modo de Agente de Usuario Encarado a Ambos Extremos, B2BUA, o en un modo proxy del SIP, e incluyendo un valor fijado a activo para indicar que el terminal soporta sesiones de PT simultáneas o fijado a no activo para indicar que el terminal no soporta sesiones de PT simultáneas; y

una unidad de recepción adaptada para cooperar con el controlador para recibir un mensaje de respuesta desde el servidor en respuesta al mensaje PUBLICACIÓN del SIP,

estando adaptado además el controlador para establecer, basándose en el mensaje de respuesta, una sesión de PT con el servidor que ha determinado funcionar en el modo B2BUA basándose en el valor del mensaje PUBLICACIÓN del SIP y basándose en una indicación de que el servidor soporta las sesiones de PT simultáneas,

estando adaptada además la unidad de transmisión para cooperar con el controlador con el fin de enviar, a través de la sesión de PT establecida, datos del Protocolo de Tiempo Real, RTP, o datos del Protocolo de Control de Ráfagas de Conversación, TBCP, hacia el servidor que funciona en el modo B2BUA.

4. Terminal según la reivindicación 3,

en el que la unidad de recepción está adaptada asimismo para recibir un mensaje de notificación desde el servidor cuando un número de sesiones de PT en las que está implicado el terminal supera un número máximo de sesiones de PT simultáneas permisibles.

5. Método de procesado de comunicaciones basadas en sesiones, en el que el método comprende:

recibir (S11), por parte de un servidor (30, 300), un mensaje PUBLICACIÓN del Protocolo de Inicio de Sesión, SIP, desde un terminal (10, 100) que informa sobre si el terminal soporta sesiones simultáneas del tipo Pulsar-para, PT, incluyendo el mensaje PUBLICACIÓN del SIP un valor fijado a activo para indicar que el terminal soporta sesiones de PT simultáneas o fijado a no activo para indicar que el terminal no soporta sesiones de PT simultáneas;

determinar (S12, S21), por parte del servidor, si debe funcionar en un modo de Agente de Usuario Encarado a Ambos Extremos, B2BUA, basándose en el valor del mensaje PUBLICACIÓN del SIP y basándose en si el servidor soporta o no las sesiones de PT simultáneas;

funcionar (S13, S22), por parte del servidor, en el modo B2BUA basándose en un resultado de la etapa de determinación;

establecer (S16, S25), por parte del servidor que funciona en el modo B2BUA, una sesión de PT con el terminal; y

recibir, por parte del servidor, a través de la sesión de PT establecida, datos del Protocolo de Tiempo Real, RTP, o datos del Protocolo de Control de Ráfagas de Conversación, TBCP, desde el terminal.

6. Método según la reivindicación 5, que comprende además:

almacenar, por parte del servidor, uno o más valores de fijación relacionados con sesiones de PT simultáneas que están incluidos en el mensaje PUBLICACIÓN recibido del SIP.

7. Método según la reivindicación 5, que comprende además,

transmitir, por parte del servidor, un mensaje de notificación al terminal cuando un número de sesiones de PT en las que está implicado el terminal supera un número máximo de sesiones de PT simultáneas permisibles.

8. Método según la reivindicación 5, en el que la etapa de recibir el mensaje PUBLICACIÓN del SIP incluye recibir, por parte del servidor, el mensaje PUBLICACIÓN del SIP desde el terminal a través de un servidor intermedio.