ES2398124T3

ES2398124T3 - Procedimiento y dispositivos para la modificación de sesión de terceros

Info

Publication number: ES2398124T3
Application number: ES07734382T
Authority: ES
Inventors: Jari Mutikainen; Arto Leppisaari
Original assignee: Core Wiresless Licensing SARL; Motorola Mobility LLC
Current assignee: Conversant Wireless Licensing SARL; Motorola Mobility LLC
Priority date: 2006-04-25
Filing date: 2007-04-24
Publication date: 2013-03-13
Anticipated expiration: 2027-04-24
Also published as: US20070250569A1; ES2398124T8; EP2014013B1; CN101427513A; WO2007122500A1; US8719342B2; US20140222921A1; CN103124264A; EP2014013A1; CN101427513B

Abstract

Procedimiento de control de la composición de los medios en una conversación multicompartida que implica unpunto de control central (50), comprendiendo dicho procedimiento las etapas siguientes: seleccionar en un participante (10-40) de dicha conversación multicompartida la información de alcance (SoM) queespecifica uno o más miembros de dicha conversación multicompartida, a los cuales va a aplicarse unamodificación de los medios recibida por dichos uno o más miembros especificados desde el punto de controlcentral (50); añadir dicha información de alcance seleccionada (SoM) a una petición de modificación de sesión; transmitir dicha petición de modificación de sesión a dicho punto de control central (50); y iniciar la modificación de medios en dichos uno o más miembros especificados en respuesta a dicha informaciónde alcance (SoM).

Description

Procedimiento y dispositivos para la modificación de sesión de terceros.

Campo de la invención

La presente invención se refiere a un procedimiento, un sistema, un dispositivo cliente, un servidor de conferencia y un producto de programa informático para controlar la composición de medios en una conversación multicompartida. Según un ejemplo particular, la presente invención se refiere a la modificación de medios en el marco de conferencias del protocolo de inicio de sesión (SIP).

Antecedentes de la invención

El marco de conferencias SIP (definido en el documento draft-ietf-sipping-conferencing-framework-05.txt) establece los procedimientos, las funciones y la arquitectura básicos y la manera en que los participantes pueden crear una sesión de conferencia SIP multimedia y tomar parte en ella, invitar a otros participantes a la sesión, excluir participantes de la sesión, percatarse de la incorporación de otros participantes en la sesión, etc. El marco de conferencias se ha adaptado pues a muchas normas de conferencias basadas en el protocolo SIP, tales como el servicio de conferencias 3GPP R6 IMS (3rd Generation Partnership Project Release 6 Internet Protocol (IP) Multimedia Subsystem, especificado por ejemplo en la TS 24,147), OMA-PoC (Open Mobile Alliance - Push-to-talk over Cellular) y OMA-IM (Open Mobile Alliance - Instant Messaging).

El marco anterior describe cómo el mecanismo de oferta/respuesta SDP (Service Description Protocol), definido en la especificación IETF (Internet Engineering Task Force) RFC (Request for Comments) 3264, se puede utilizar para añadir, eliminar y modificar flujos de medios y sus atributos en la sesión de conferencia multimedia.

En una sesión de conferencia multimedia, el usuario debería ser capaz de iniciar la sesión con unos medios particulares (por ejemplo, audio PoC, IM o dúplex completo, vídeo dúplex completo, etc.) y agregar otros medios más adelante. La función de control de conferencia deberá comunicar pues los medios agregados a los otros participantes en la sesión de conferencia, por ejemplo, a través de una oferta SDP en una petición SIP re-INVITE o SIP UPDATE como las descritas en la especificación IETF RFC 3311. De esta manera, los demás participantes sabrán que se han añadido unos nuevos medios y que pueden empezar a utilizarlos durante la sesión.

Por otra parte, un participante puede utilizar también el mismo mecanismo de oferta/respuesta SDP para modificar la parte de conexión, es decir, el tramo de llamada, entre el participante y el punto de control central (por ejemplo, el foco en terminología de conferencias SIP) de la conferencia solamente. En este tipo de modificación de sesión del marco de conferencias SIP, el foco no debería modificar las sesiones de medios de los otros participantes. Por ejemplo, en el marco de conferencias SIP, si un participante desea poner en espera los medios de audio dúplex completo, se utiliza el mecanismo de oferta/respuesta SDP de re-INVITE / 200 OK entre el participante y el foco, pero el foco no debe enviar la petición re-INVITE a los demás participantes, puesto que estos no se hallan en espera y por lo tanto deben poder continuar comunicándose como antes.

Por lo tanto, el punto de control central debe ser capaz de determinar qué ofertas SDP deben transmitirse a los otros participantes y qué ofertas se mantienen entre el participante solicitante y el foco solo. En algunas modificaciones de medios, el punto de control central puede llegar a esta determinación basándose en los atributos de la oferta SDP. Por ejemplo, si un participante pone los medios de una sesión de conferencia "en espera", comúnmente el punto de control central no deberá poner los otros participantes en espera, sino que en su lugar mantendrá la modificación de los medios dentro del diálogo SIP particular, es decir, entre el participante y el foco. Sin embargo, con algunas ofertas SDP, el punto de control central no tiene modo de saber si la modificación de medios debe alcanzar otros destinos. Esto sucede, por ejemplo, si la sesión de conferencia comprende medios de audio y vídeo y un participante desea excluir el vídeo de su tramo solo (por ejemplo, si se desplaza a una celda que no puede ofrecer suficiente ancho de banda para vídeo), pero el resto de los participantes no tienen esta limitación, es decir, desean continuar tanto con audio como con vídeo.

El mecanismo de oferta/respuesta SDP actual en el marco de conferencias SIP no permite determinar si la manipulación de los medios debe limitarse a un tramo de llamada o comunicarse a todos los participantes. En IETF XCON, se está resolviendo actualmente un caso de uso similar. Este grupo de trabajo define un marco para un protocolo de control de medios que cada participante puede utilizar para controlar las políticas de los medios de los demás participantes, por ejemplo eliminar el vídeo de cierto participante, silenciar a uno de los participantes (eliminar la capacidad de envío de audio) y así sucesivamente. Aunque el trabajo del grupo XCON ha sido muy lento, el resultado será un nuevo protocolo entre el participante y el foco.

Lo que necesitan los servicios OMA-IM y OMA-PoC es una solución SIP sencilla para agregar y retirar medios, ya que desde el punto de vista del calendario de normalización, los servicios IM y POC no pueden esperar a obtener los resultados XCON y no necesitan el complejo marco XCON y las otras capacidades más avanzadas del protocolo de control de política de medios.

El documento US 2006/083244 da a conocer un procedimiento de gestión de varios recursos en sesiones de conferencia multimedia multipartitas. El documento 2006/083244 da a conocer un sistema que comprende un servidor y varios clientes. El servidor gestiona la sesión. Durante una sesión, el servidor puede recibir medios desde un cliente y puede enviarlos a todos los participantes en la sesión. Los participantes y los recursos pueden ser recursos lógicos o físicos. Los recursos físicos pueden ser, por ejemplo, un altavoz, un micrófono, una pantalla, etc.

El documento de Johnston et al. "Session Initiation Protocol Call control - Conferencing for User Agents" [IETF-STANDARD-WORKING-DRAFT, INTERNET ENGINEERING TASK FORCE, IETF, CH, vol. Sipping, n.º 7, 3 de junio de 2005 (2005-06-03)], da a conocer una especificación que define las características de control de llamadas de conferencia para el protocolo de inicio de sesión (SIP). Dicha exposición pretende fundamentarse en los documentos sobre los requisitos de conferencia y el marco para definir cómo funciona una conferencia SIP altamente acoplada. En ella se trata acerca de cómo analizar un planteamiento desde la perspectiva de diferentes tipos de agente de usuario (UA): los insensibles a las convenciones de la conferencia, los sensibles a las convenciones de la conferencia y los de foco. El uso de los URI en las conferencias, el método OPTIONS para descubrir capacidades y el control de llamada mediante el método REFER se tratan en detalle con los ejemplos de diagramas de flujo para una llamada. Se define el uso de la etiqueta de característica de foco.

Sumario de la invención

La presente invención se expone en las reivindicaciones independientes.

Uno de los objetivos de ciertas formas de realización de la presente invención consiste en intentar proporcionar un sistema de manipulación de sesión sencillo, por medio del cual se puedan agregar y retirar componentes de los medios de una manera sencilla y flexible.

Según un aspecto de la presente exposición, está previsto un procedimiento para controlar la composición de medios de una conversación multicompartida en la que interviene un punto de control central, comprendiendo dicho procedimiento las etapas siguientes:

en un participante de dicha conversación multicompartida, seleccionar la información de alcance que indica los miembros de dicha conversación multicompartida;

añadir dicha información de alcance a una petición de modificación de sesión;

transmitir dicha petición de modificación de sesión a dicho punto de control central e

iniciar una modificación de medios en dichos miembros indicados como respuesta a dicha información de alcance.

Según otro aspecto de la presente exposición, que está previsto un dispositivo cliente para controlar la composición de medios en una conversación multicompartida en la que interviene un punto de control central, comprendiendo dicho dispositivo cliente:

•: unos medios de selección para seleccionar información de alcance que indica los miembros de dicha conversación multicompartida;

•: unos medios de adición para añadir dicha información de alcance seleccionada a una petición de modificación de sesión y

•: unos medios de transmisión para transmitir dicha petición de modificación de sesión a dicho punto de control central.

Según otro aspecto, se ofrece un dispositivo de servidor de conferencia para llevar el control central de una conversación multicompartida, comprendiendo dicho dispositivo de servidor de conferencia:

•: unos medios de detección para detectar información de alcance que indica los miembros de dicha conversación multicompartida, en una petición de modificación de sesión recibida, y

•: unos medios de inicio, sensibles a dicha información de alcance, para iniciar una modificación de medios dirigida a dichos miembros indicados en dicha información de alcance.

Según otro aspecto adicional, se ofrece un producto de programa informático que comprende unos medios de código para generar las etapas de selección, adición y transmisión del procedimiento anterior cuando se ejecuta en un dispositivo informático. Por otra parte, el objetivo anterior se alcanza mediante un producto de programa informático que comprende unos medios de código para generar la etapa de inicio del procedimiento anterior cuando se ejecuta en un dispositivo informático.

Según otro aspecto más, se ofrece un sistema para controlar la composición de medios en una conversación multicompartida, comprendiendo dicho sistema por lo menos un dispositivo cliente como el definido anteriormente y un dispositivo de servidor de conferencia como el definido anteriormente.

En consecuencia, un cliente o participante puede controlar individualmente el alcance de la modificación de los medios, es decir los miembros de una conversación multicompartida a los cuales va a aplicarse la modificación de medios solicitada. Por ejemplo, el participante solicitante puede seleccionar si la modificación de medios se aplica a toda la conferencia o solamente entre el cliente y el servidor de conferencia (es decir, el punto de control central). En ese caso, el cliente solicitante puede excluir uno o más componentes de los medios de manera localizada o global para el conjunto de la conferencia.

Según un primer aspecto, la información de alcance puede añadirse como un nuevo parámetro de cabecera de la petición de modificación de sesión.

Según un segundo aspecto, la información de alcance puede añadirse como un atributo de la petición de modificación de sesión. Este atributo puede ser, por ejemplo, un atributo SDP y la información de alcance puede añadirse entonces como un valor de línea a.

En un ejemplo concreto, la información de alcance puede indicar si la modificación de los medios va a aplicarse solo al participante o a todos los miembros de la conversación multicompartida.

Según un tercer aspecto, la información de alcance puede añadirse como una lista de direcciones de los participantes a los cuales se va a aplicar la modificación de medios. Esta lista de direcciones puede comprender, por ejemplo, por lo menos un identificador uniforme de recurso (URI) SIP.

En los aspectos primero a tercero anteriores, la petición de modificación de sesión puede ser una petición SIP re-INVITE o una petición SIP UPDATE.

Según un cuarto aspecto, la petición de modificación de sesión puede indicar un destinatario que debe ponerse en contacto con una tercera parte mediante la información de alcance. En este caso, la petición de modificación de sesión puede comprender un parámetro de cabecera utilizado para comunicar al punto de control central que se va a modificar un diálogo existente, en lugar de crear uno nuevo. Como opción adicional, la petición de modificación de sesión puede comprender información de las capacidades del destinatario de la llamada que indica de qué manera va a modificarse el diálogo. En el cuarto aspecto, la información de alcance puede agregarse como una lista de direcciones. Esta lista de direcciones puede comprender, por ejemplo, por lo menos un URI SIP.

Otras modificaciones convenientes se definen en las reivindicaciones subordinadas.

Breve descripción de los dibujos

En adelante, la presente invención se describe con mayor detalle tomando como base las formas de realización, haciendo referencia a los dibujos adjuntos en los cuales:

la figura 1 representa un diagrama esquemático que indica una arquitectura de conferencia multipartita, en la cual puede implementarse la presente invención;

la figura 2 representa un diagrama de bloques esquemático de un sistema de modificación de medios según las formas de realización preferidas;

la figura 3 representa un listado de un ejemplo de petición re-INVITE como la utilizada en una segunda forma de realización;

la figura 4 representa un listado de un ejemplo de atributo SDP como el utilizado en una tercera forma de realización;

la figura 5 representa un listado de un ejemplo de petición REFER como la utilizada en un primer ejemplo de una cuarta forma de realización y

la figura 6 representa un listado de un ejemplo de petición REFER anidada como la utilizada en un segundo ejemplo de la cuarta forma de realización.

Descripción de la forma de realización preferida

A continuación, se describen las formas de realización preferidas tomando como base una arquitectura de conferencia multipartita SIP como la representada en la figura 1.

En la presente memoria, el término "conferencia" se utiliza para designar una conversación multicompartida particular, en la que un único punto de control, que puede ser un agente de usuario SIP al que se denomina "foco" 50, mantiene un diálogo por medio de unos respectivos tramos de llamada 70 con cada uno de los participantes P1 10 a P4 40. Cada participante es un elemento o rutina de software que se ejecuta en un dispositivo informático o un terminal del cliente que conecta un usuario o aparato con una conferencia. Como mínimo, se implementa un agente de usuario SIP, aunque también se pueden implementar mecanismos no específicos de SIP para obtener funciones adicionales. Este agente de usuario SIP puede ser una aplicación de PC, un teléfono IP SIP o una puerta de enlace a la red telefónica pública conmutada (PSTN). También puede ser otro foco.

El foco 50 desempeña el papel de administrador centralizado de la conferencia, y se accede a él mediante un URI de conferencia, por ejemplo, un URI que generalmente es un URI SIP que indica el foco 50 de la conferencia. El foco 50 es una función lógica que mantiene una relación de señalización SIP con cada participante, por ejemplo P1 10 a P4 40, en la conferencia. El foco 50 es el responsable de garantizar, de alguna manera, que cada participante reciba los medios que conforman la conferencia. El foco 50 también implementa políticas de conferencia.

El estado de la conferencia comprende el estado del foco 50, el conjunto de participantes 10 a 40 conectados a la conferencia y el estado de sus respectivos diálogos. Se ofrece un servicio de notificación para la conferencia como una función lógica del foco 50 que, por lo tanto, puede actuar como componente notificador, aceptando suscripciones para el estado de conferencia y avisando a los abonados acerca de los cambios de ese estado.

Además, puede disponerse de un servidor de política de conferencia 60 como función lógica que puede almacenar y manipular la política de conferencia. Esta función lógica no es específica del protocolo SIP y puede no existir físicamente. Dicha función se refiere al componente que interconecta un protocolo con la política de conferencia que es el conjunto completo de normas que rigen una conferencia particular.

Además, puede disponerse de un mezclador (no representado) que recibe un conjunto de flujos de medios del mismo tipo y combina los medios de una manera específica para cada tipo, redistribuyendo el resultado a cada participante 10 a 40.

Un servidor de conferencia es un servidor físico que contiene, como mínimo, las funciones del foco. Dicho servidor puede comprender también las funciones del servidor de política de conferencia y del mezclador.

Como puede deducirse a partir de la figura 1, el componente central de la arquitectura de conferencia SIP es el foco 50, lo cual da por resultado una topología en estrella. El foco 50 es el responsable de asegurar que los flujos de medios que constituyen la conferencia estén disponibles para los participantes 10 a 40 en la conferencia. Esto se logra mediante el uso de uno o más mezcladores, cada uno de los cuales combina una serie de flujos de medios de entrada para generar uno o más flujos de medios de salida. El foco 50 utiliza una política de medios para determinar la configuración correcta de los mezcladores.

El foco 50 tiene acceso a la política de conferencia de cada conferencia. En realidad, la política de conferencia puede ser considerada como una base de datos que describe la forma en que la conferencia debería funcionar. El responsable de hacer cumplir estas políticas es el foco 50, que además de necesitar acceso de lectura a la base de datos, necesita saber cuándo se producen cambios en esta. Dichos cambios pueden dar por resultado una señalización SIP (por ejemplo, la exclusión de un usuario de la conferencia mediante el método SIP BYE), siendo necesario, en el caso de los cambios que afectan al estado de conferencia, enviar un aviso a los abonados a través del servicio de notificación de la conferencia.

Cada conferencia presenta un foco exclusivo 50 y un URI exclusivo que identifica a dicho foco 50. Las peticiones al URI de la conferencia se encaminan hacia el foco 50 de la conferencia particular. Habitualmente, los usuarios se incorporan a la conferencia enviando una petición INVITE al URI de la conferencia. En la medida de lo permitido por la política de conferencia, el foco 50 acepta la petición INVITE y el usuario se incorpora a la conferencia. Los usuarios pueden abandonar la conferencia enviando un mensaje BYE, tal como harían en una llamada normal.

Análogamente, el foco 50 puede terminar un diálogo con un participante, en caso de que la política de conferencia cambie para indicar que el participante ya no está admitido en la conferencia. El foco 50 puede iniciar también un método INVITE para incorporar a un participante en la conferencia.

El participante puede comunicarse con el servidor de política de conferencia 60 mediante algún tipo mecanismo no específico de SIP, lo cual puede afectar a la política de conferencia. Esto se indica en la figura 1 mediante la flecha situada entre el participante P4 40 y el servidor de política de conferencia 60, que no tiene por qué estar presente en cada conferencia particular, aunque siempre esté presente una política de conferencia.

Las interfaces entre el foco 50 y la política de conferencia, y el servidor de política de conferencia 60 y la política de conferencia no son específicas de SIP. A los efectos de llevar a término una conferencia basada en SIP, estas interfaces no representan una descomposición física, sino que sirven como funciones lógicas que intervienen en la

conferencia.

El URI de la conferencia es exclusivo, de tal manera que no habrá dos conferencias que presenten el mismo URI de conferencia, que puede ser un URI SIP. La información contextual que rodea al URI (por ejemplo, los parámetros de cabecera SIP) puede indicar que el URI representa una conferencia. Cuando se envía una petición SIP al URI de la conferencia, dicha petición se encamina hacia el foco 50. El URI de la conferencia puede representar una conferencia o un foro de discusión duradero, tal como el descrito en "sip:discussion-on-dogs@example.com ". El foco indicado por este URI siempre existirá y siempre dirigirá la conferencia, sean cuales sean los participantes que intervengan en ella actualmente. Otros URI de conferencia pueden representar conferencias de corta duración, tales como una conferencia para un fin determinado. Los parámetros de capacidades del destinatario de la llamada también se emplean para indicar que el foco 50 admite el servicio de notificaciones de la conferencia. Esto puede lograrse declarando la compatibilidad con el método SIP SUBSCRIBE y el paquete o los paquetes correspondientes en los parámetros de características de preferencias del destinatario de la llamada asociados al URI de la conferencia.

Como ya se ha mencionado y representado en la figura 1, el foco 50 es el centro de la conferencia. Todos los participantes 10-40 en la conferencia están conectados a esta mediante un diálogo SIP. El foco 50 es responsable de mantener los diálogos conectados a la conferencia y asegurar que los diálogos estén conectados a un conjunto de participantes que tienen autorización para intervenir en la conferencia, tal como se establece en la política de admisión. Asimismo, el foco 50 utiliza el protocolo SIP para manipular las sesiones de medios, a fin de asegurar que cada participante obtenga todos los medios para la conferencia. Para ello, el foco 50 utiliza los mezcladores. A través de esa interacción, se asegura que todos los participantes válidos 10 a 40 hayan recibido una copia de los flujos de medios, y que cada participante envíe los medios a una dirección y puerta IP del mezclador a fin de que estos se mezclen correctamente con los otros medios de la conferencia.

Cada conferencia se compone de un conjunto de medios particular gestionado por el foco 50. Por ejemplo, una conferencia puede contener un flujo de vídeo y un flujo de audio. Los participantes 10 a 40 pueden cambiar el conjunto de flujos de medios que conforman la conferencia. Cuando el conjunto de medios de la conferencia cambie, el foco 50 deberá generar una petición re-INVITE para cada participante a fin de agregar o retirar el flujo de medios para cada participante. Un participante puede utilizar una petición SIP re-INVITE para añadir o retirar un flujo de medios. Esto se logra utilizando las técnicas de oferta/respuesta estándar para añadir flujos de medios a una sesión. Esto desencadenará la generación y transmisión por el foco de sus propias peticiones re-INVITE hacia los demás participantes 10 a 40 de la conferencia.

La figura 2 representa un diagrama de bloques esquemático que indica las unidades o funciones de un participante 10 o su respectivo dispositivo de hardware de cliente y el foco 50 o su respectivo dispositivo de hardware de servidor de conferencia, que interviene en un sistema de modificación de sesión de terceros propuesto, por medio de las cuales el participante 10 puede manipular con facilidad y flexibilidad los componentes de medios.

Según la figura 2, el participante 10 comprende una unidad o unas funciones de selección 102 para seleccionar el alcance de la modificación de medios deseado, es decir, los participantes de la conferencia específicos a los cuales se va a aplicar la modificación de medios. Unas funciones de software o una función de entrada de hardware dispuestos en el respectivo dispositivo cliente pueden controlar esta selección. Como respuesta a dicha operación de control o entrada, las funciones de selección 102 generan información de alcance de modificación (SoM) que se añade a través de una unidad o unas funciones de generación de mensajes 104 a una petición de modificación de sesión. Esta petición puede ser una petición adecuada cualquiera que pueda utilizarse para iniciar cualquier tipo de modificación de sesión. Más adelante, se describen ejemplos de dichas modificaciones tomando como base el ejemplo de arquitectura de conferencia SIP.

Una unidad o unas funciones de señalización de mensajes 106 del participante 10 transmiten o encaminan hacia el foco 50 la petición de modificación de sesión ampliada con la información de alcance SoM agregada, basándose en el URI de la conferencia. En el foco 50, una unidad o unas funciones de señalización de mensajes similares 506 reciben y facilitan la petición de modificación de sesión ampliada a una unidad o funciones de detección de alcance 502 que detectan la información de alcance SoM. La información de alcance SoM detectada se suministra a una unidad o función de generación de mensajes 504 del foco, y la modificación de medios solicitada se inicia, por medio de las funciones de señalización de mensajes 506 en combinación con unas respectivas funciones de mezclador (no representadas), en relación con los participantes indicados en la información de alcance SoM.

Debe observarse que las unidades o funciones anteriores 102, 104 y 106 del participante 10 y las unidades o funciones anteriores 502, 504 y 506 del foco 50 pueden implementarse como rutinas o componentes de software que cooperan o están integrados en los respectivos programas de control (por ejemplo, agentes de usuario SIP o similares) del participante 10 y el foco 50, respectivamente. Como alternativa, las unidades o funciones indicadas pueden implementarse como unidades de hardware del respectivo dispositivo cliente o dispositivo de servidor de conferencia, respectivamente. Como es evidente, una parte o la totalidad del resto de participantes 20 a 40 pueden disponer de las unidades o funciones anteriores 102, 104 y 106 , también.

En adelante, se describen diferentes formas de realización que se pueden diferenciar en función del tipo de mensaje y la parte del mensaje que transmite la información de alcance SoM.

Según las formas de realización primera a tercera, las peticiones re-INVITE o UPDATE se modifican para brindar a los participantes una manera fácil y flexible de modificar selectivamente las composiciones de medios de una conferencia. Estos mecanismos se utilizan cuando debe modificarse una sesión y no se añade ni excluye a ningún participante. Las peticiones re-INVITE o UPDATE se utilizan para modificar los medios de la sesión. El servicio del método UPDATE es opcional para la red, pudiéndose enterar el participante o cliente de la capacidad de la red durante el establecimiento de la sesión. Aunque para simplificar no siempre se menciona en la presente memoria el método UPDATE como método alternativo a re-INVITE, este debe tomarse en consideración como alternativa a todos los casos de uso de re-INVITE en conexión con las formas de realización primera a tercera.

Como ejemplo particular, la presente memoria propone que la petición re-INVITE contenga como información de alcance SoM un parámetro que indique si la modificación de medios propuesta por el cliente debe aplicarse a toda la sesión o solo al cliente solicitante. Esta indicación puede transmitirse en las cabeceras SIP o en la carga útil SDP de las peticiones INVITE o UPDATE.

En la primera forma de realización, se da a conocer una nueva cabecera SIP, por ejemplo, la cabecera Media-Handling (Conference/Client). Puesto que puede utilizarse una petición INVITE para modificar varios medios, el valor de parámetro de cabecera SIP se aplica a todos los medios que se negocian en la petición re-INVITE. En caso de que algunas modificaciones de medios de la petición re-INVITE estén dirigidas a toda la conferencia y algunas a los medios o el tramo de llamada del participante solo, el participante deberá enviar una petición re-INVITE separada.

Como opción adicional para la primera forma de realización, algunas cabeceras SIP disponibles, por ejemplo, la cabecera SIP Request-Disposition pueden utilizarse para transmitir la información de alcance SoM.

En la segunda forma de realización, se propone el servicio de lista SIP URI para transmitir la información de alcance SoM. En este caso, la petición SIP INVITE/UPDATE contiene lista SIP URI como carga útil de la petición. El servicio de lista SIP URI se utiliza para indicar a cuáles de los participantes debe aplicarse la modificación de medios. El servicio de lista SIP URI también puede contener el URI de la conferencia que indica que se aplican modificaciones de medios a todos los participantes de la conferencia. Al igual que en la primera forma de realización y de forma predeterminada, todas las modificaciones de medios propuestas (varias líneas m en la figura 3) se aplican a los participantes indicados en el servicio de lista SIP URI. Si el participante desea añadir unos medios al conjunto de la conferencia, y otros medios a un subconjunto de participantes solo, se necesitan dos peticiones re-INVITE/UPDATE separadas.

Además del servicio de lista SIP URI especificado en "draft-ietf-sipping-uri-services-05.txt", puede necesitarse alguna indicación adicional en la petición re-INVITE/UPDATE para indicar al foco 50 cómo debe utilizar la información de lista SIP URI. El servicio de lista SIP URI podría estar presente ya en la petición re-INVITE/UPDATE por otras razones. Por consiguiente, los mecanismos propuestos pueden estar disponibles en combinaciones tales como las del servicio de lista SIP URI y la cabecera SIP, el servicio de lista SIP URI y el atributo SDP, y además el propio servicio de lista SIP URI podría contener un nuevo campo para indicar que la lista se utiliza con ese propósito particular.

La figura 3 representa un ejemplo de listado de una petición re-INVITE según la segunda forma de realización, que contiene dos grupos, el protocolo SDP y el servicio de lista SIP URI para un servicio PoC.

En la tercera forma de realización preferida, se da a conocer un nuevo atributo SDP, por ejemplo, Conference/Clientonly o media-treatment Conference/Client-only, para transmitir la información de alcance SoM, por ejemplo, como un valor de línea a.

La figura 4 representa un listado de un ejemplo del atributo SDP propuesto. En este caso, un nuevo valor de línea a "conference" indica que la modificación de medios se aplica a toda la conferencia, y un nuevo valor "client-only" indica que la modificación de medios se aplica solo entre el participante solicitante particular y el servidor de conferencia.

Este nuevo atributo SDP es más flexible, puesto que el participante puede agregar varios medios a la misma petición re-INVITE y solicitar un tratamiento diferente para cada uno de los medios. El servidor de conferencia, es decir, el foco 50, puede negociar modificaciones del propio tramo de inmediato, mientras que los nuevos medios para el conjunto de la conferencia pueden tardar cierto tiempo.

Según la cuarta forma de realización, el método REFER descrito en la IETF RFC 3515 se utiliza como una petición de modificación de sesión a la cual se añade la información de alcance.

En particular, podría insertarse una nueva cabecera SIP "Alternates" (en contraposición a "Replaces"). Esta cabecera se usa en el método SIP REFER para avisar al elemento de referencia, es decir, el foco 50, que la petición

INVITE enviada tras la recepción de REFER debería modificar el diálogo existente, en lugar de crear un nuevo diálogo. Además, las capacidades del destinatario de la llamada pueden utilizarse junto con el URI de contacto en la cabecera Refer-to del método REFER. Las capacidades del destinatario de la llamada junto con la nueva cabecera Alternates indican al foco 50 de qué manera debe modificarse el diálogo.

Como opción adicional, el servicio de lista SIP URI puede utilizarse para que el método REFER genere la petición re-INVITE para todos los participantes 10 a 40 de la sesión de conferencia. Con el servicio de lista SIP URI, también es posible solicitar que se genere y envíe la petición re-INVITE solo a algunos de los participantes en la conferencia. En este caso, el participante o cliente solicitante puede agregar la lista de participantes a la petición REFER como un servicio de lista SIP URI.

Este nuevo mecanismo basado en REFER que emplea la cabecera Alternates puede utilizarse siempre que el participante desee modificar las sesiones de otros participantes. Si el participante desea modificar su propio tramo de llamada 70 hasta el foco 50, debe utilizar el mecanismo de oferta/respuesta SDP habitual descrito en la tercera forma de realización preferida.

La figura 5 representa un listado de un primer ejemplo de una petición REFER según la cuarta forma de realización, en la que el usuario A desea excluir el vídeo de todos los participantes en la sesión de conferencia multimedia de audio/vídeo. El usuario A envía una petición REFER al foco 50. La petición REFER contiene una cabecera Refer-to con el URI del foco. El URI del foco de la cabecera Refer-to indica que el método debe enviarse a todos los participantes que intervienen actualmente en la sesión con el foco 50.

El foco 50 genera, a continuación, una petición re-INVITE para cada participante que interviene actualmente en la sesión. Además, el foco 50 añade una oferta SDP a la petición re-INVITE basándose en los medios negociados actualmente en la sesión de cada participante. En función de las capacidades del destinatario de la llamada (audio, en este ejemplo) facilitadas en la cabecera Refer-to de la petición REFER, el foco 50 genera una oferta SDP que comprende solo los medios de audio. Como respuesta de cada participante, el vídeo se excluye de todos los participantes.

Otra manera de excluir el vídeo en un segundo ejemplo de la cuarta forma de realización consiste en enviar una petición REFER anidada al foco.

La figura 6 representa un listado de la petición REFER según el segundo ejemplo. El foco anidado genera una petición REFER para cada participante. Esta segunda petición REFER comprende la nueva cabecera Alternates y, basándose en esta, el participante genera una petición re-INVITE para enviarla nuevamente al foco. Esta petición re-INVITE comprende una oferta SDP que excluye los medios de vídeo del diálogo en curso.

Como ejemplo específico, los mecanismos de modificación de medios sencillos y flexibles dados a conocer anteriormente en relación con las formas de realización primera a cuarta pueden implementarse en la tecnología OMA PoC 2.0. Por lo tanto, se ofrecen unos nuevos medios para una característica PoC, en la que una sesión puede contener varios medios.

En resumen, en la presente memoria se ha descrito un procedimiento, un sistema, un dispositivo cliente, un dispositivo de servidor de conferencia y un producto de programa informático para controlar la composición de medios en una conversación multicompartida en la que interviene un punto de control central. En un participante de dicha conversación multicompartida, se selecciona información de alcance que indica los miembros de dicha conversación multicompartida, y dicha información se añade a una petición de modificación de sesión. La petición de modificación de sesión se transmite al punto de control central que inicia una modificación de medios en los miembros indicados como respuesta a la información de alcance. De ese modo, el cliente puede controlar si una modificación de medios se aplica a toda la conferencia, a unos participantes seleccionados o solamente entre el cliente y el servidor de conferencia.

Debe tenerse en cuenta que la presente invención no se limita a las formas de realización basadas en el protocolo SIP preferidas y mencionadas anteriormente, sino que se puede aplicar en relación con cualquier tipo de modificación de medios para conversaciones multicompartidas, en las que se pueden utilizar peticiones de modificación de sesión para modificar componentes de medios. Puede utilizarse o incorporarse cualquier cabecera, parte o parámetro de carga útil nuevos para añadir y transmitir la información de alcance propuesta. Las formas de realización preferidas pueden pues variar dentro del alcance de las reivindicaciones adjuntas.

Claims

REIVINDICACIONES

1. Procedimiento de control de la composición de los medios en una conversación multicompartida que implica un punto de control central (50), comprendiendo dicho procedimiento las etapas siguientes:

seleccionar en un participante (10-40) de dicha conversación multicompartida la información de alcance (SoM) que especifica uno o más miembros de dicha conversación multicompartida, a los cuales va a aplicarse una modificación de los medios recibida por dichos uno o más miembros especificados desde el punto de control central (50);

añadir dicha información de alcance seleccionada (SoM) a una petición de modificación de sesión;

transmitir dicha petición de modificación de sesión a dicho punto de control central (50); y

iniciar la modificación de medios en dichos uno o más miembros especificados en respuesta a dicha información de alcance (SoM).
2.

Procedimiento según la reivindicación 1, en el que dicha información de alcance se añade como un parámetro de cabecera o un atributo de dicha petición de modificación de sesión.
3.

Procedimiento según la reivindicación 1, en el que dicha información de alcance se añade como una lista de direcciones de los participantes a los cuales se va a aplicar dicha modificación de medios.
4.

Procedimiento según la reivindicación 3, en el que dicha lista de direcciones comprende una lista de SIP URI o por lo menos un identificador uniforme de recurso del protocolo de inicio de sesión.
5.

Procedimiento según la reivindicación 1, en el que dicha petición de modificación de sesión identifica un punto de control central que debe ponerse en contacto con un tercero utilizando dicha información de alcance.
6.

Procedimiento según la reivindicación 5, en el que dicha petición de modificación de sesión comprende un parámetro de cabecera utilizado para informar a dicho punto de control central (50) de que se va a modificar un diálogo existente, en lugar de crear un nuevo diálogo, o comprende información de capacidades del destinatario de la llamada que indica de qué forma se va a modificar dicho diálogo existente.
7.

Dispositivo cliente para controlar la composición de medios en una conversación multicompartida que implica un punto de control central (50), comprendiendo dicho dispositivo cliente (10-40):

unos medios de selección (102) para seleccionar la información de alcance (SoM) que especifica uno o más miembros de dicha conversación multicompartida, a los cuales va a aplicarse una modificación de medios recibida por dichos uno o más miembros especificados desde el punto de control central (50);

unos medios de adición (104) para añadir dicha información de alcance (SoM) seleccionada a una petición de modificación de sesión; y

unos medios de transmisión (106) para transmitir dicha petición de modificación de sesión a dicho punto de control central (50).
8.

Dispositivo cliente según la reivindicación 7, en el que dichos medios de adición (104) están configurados para añadir dicha información de alcance como un parámetro de cabecera de dicha petición de modificación de sesión o como un atributo de mensaje de dicha petición de modificación de sesión.
9.

Dispositivo cliente según cualquiera de las reivindicaciones 7 a 8, en el que dicha información de alcance especifica si dicha modificación de medios va a aplicarse únicamente al participante que ha transmitido dicha petición de modificación de sesión o a todos los miembros de dicha conversación multicompartida.
10.

Dispositivo cliente según la reivindicación 7, en el que dichos medios de adición (104) están configurados para añadir dicha información de alcance como una lista de direcciones de los participantes a los cuales se va a aplicar dicha modificación de medios.
11.

Dispositivo cliente según la reivindicación 7, en el que dicha petición de modificación de sesión comprende un parámetro de cabecera utilizado para informar a dicho punto de control central (50) de que se va a modificar un diálogo existente, en lugar de crear un nuevo diálogo, o comprende una información de capacidades del destinatario de la llamada que indica de qué forma se va a modificar dicho diálogo existente.
12.

Dispositivo cliente según la reivindicación 7, en el que dicha información de alcance comprende una lista de direcciones.
13.

Dispositivo de servidor de conferencia para proporcionar un control central para una conversación multicompartida, comprendiendo dicho dispositivo de servicio de conferencia (50):

5 unos medios de recepción para recibir una petición de modificación de sesión de un participante de dicha conversación multicompartida, en el que la petición de modificación de sesión comprende información de alcance (SoM) que especifica uno o más miembros de dicha conversación multicompartida, a los cuales va a aplicarse una modificación de medios recibida por dicho uno o más miembros especificados desde el punto de control central (50);

10 unos medios de detección (502) para detectar la información de alcance (SoM) en la petición de modificación de sesión recibida; y

unos medios de inicio (504), sensibles a dicha información de alcance, para iniciar la modificación de medios en 15 relación con dicho uno o más miembros especificados por dicha información de alcance (SoM).
14. Dispositivo de servidor de conferencia según la reivindicación 13, en el que dichos medios de detección (504) están configurados para detectar dicha información de alcance en una cabecera de dicha petición de modificación de sesión o en un atributo de mensaje de dicha petición de modificación de sesión, o para detectar en dicha petición

20 de modificación de sesión un parámetro de cabecera utilizado para informar a dicho dispositivo de servidor de conferencia (50) de que se va a modificar un diálogo existente, en lugar de crear un nuevo diálogo, o para detectar, en dicha petición de modificación de sesión, una información de capacidades del destinatario de la llamada que indica de qué manera se va a modificar el diálogo existente.

25 15. Producto de programa informático que comprende unos medios de código, que cuando se ejecuta en un dispositivo informático (10-40) provoca la realización de las etapas siguientes:

seleccionar, en un participante (10-40) de una conversación multicompartida que implica un punto de control central (60), una información de alcance (SoM) que especifica uno o más miembros de dicha conversación

30 multicompartida, a los cuales va a aplicarse una modificación de medios recibida por dichos uno o más miembros especificados desde el punto de control central (50);

añadir dicha información de alcance seleccionada (SoM) a una petición de modificación de sesión; y

35 transmitir dicha petición de modificación de sesión a dicho punto de control central (50).
16. Producto de programa informático que comprende unos medios de código que cuando se ejecuta en un dispositivo informático (50) provoca la realización de las etapas siguientes:

40 recibir en un punto de control central (50), una petición de modificación de sesión de un participante de una conversación multicompartida, que implica el punto de control central (50), en el que la petición de modificación de sesión comprende información de alcance (SoM) que especifica uno o más miembros de dicha conversación multicompartida, a los cuales va a aplicarse una modificación de medios recibida, por dichos uno o más miembros especificados desde el punto de control central (50);

45 detectar la información de alcance (SoM) en la petición de modificación de sesión recibida; y

iniciar, en respuesta a dicha información de alcance (SoM), de la modificación de medios en relación con dicho uno

o más miembros especificados por dicha información de alcance (SoM). 50