MULTIVIDEOCONFERENCIAS BREVES OBJETO DE LA INVENCION

La presente invención, tal y como se expresa en el enunciado de esta memoria descriptiva, se refiere a un sistema de intercambio de mensajes PTT para multivideoconferencias breves cuya finalidad esencial consiste en facilitar un sistema alternativo a los que se emplean actualmente para intercambio de mensajes multimedia o videoconferencias cortas, y alternativo a los que se encuentran en proceso de estandarización por organismos oficiales tales como OMA (Open Mobile Alliance) ; y de manera que el sistema de la invención presente una mayor sencillez y unos menores costes de aplicación.

ANTECEDENTES DE LA INVENCION

Con el incremento de la disponibilidad de redes de acceso de banda ancha fijas y móviles se está produciendo un incremento de la demanda de servicios de comunicaciones multimedia en tiempo real. Además, las nuevas redes NGN demandan que estos servicios se proporcionen desde cualquier red de acceso.

En la actualidad, los servicios de videoconferencia entre dos o más participantes se ofrecen como un servicio que requiere infraestructura de red con equipamiento especifico para gestionar el establecimiento de la sesión, el control de flujo y la mezcla de audio y video, con lo que el equipamiento correspondiente presenta un coste excesivamente elevado, tal y como se refleja en la figura 6 de este documento.

En dicha figura 6 pueden verse los siguientes elementos :

60: red de datos.

61: MCU (Multipoint Control Unit).

62: usuarios de multivideoconferencia .

63: terminal multimedia. 64: cámara de videoconferencia .

65: micrófono.

66: proyector.

67: terminal de datos.

68: pantalla.

El elemento MCU, referenciado como 61, de la figura 6 del estado de la técnica sirve para gestionar el flujo de datos de los terminales conectados a la videoconferencia, mezclar, conmutar y procesar el audio y el video, asi como soportar el rango de estándares de audio, video y datos. En la videoconferencia multipunto, todos los terminales envían audio, video, datos y flujos de control a la MCU en un comportamiento punto a punto. La MCU gestiona de forma centralizada la conferencia usando las funciones de control.

Por otra parte, para poder hacer una multivideoconferencia es necesario acordar una hora entre todos los participantes e iniciar un largo y complejo procedimiento de establecimiento de llamada antes de poder empezar la comunicación. Este servicio resulta ineficiente cuando se trata de comunicar rápidamente un mensaje a nuestros interlocutores.

En la figura 7 de este documento, también perteneciente al estado de la técnica, se muestra un esquema básico de señalización y flujo de datos en un sistema de multivideoconferencia tradicional.

En esa figura 7, además del referido bloque MCU referenciado como 61, se pueden distinguir los siguientes elementos :

11: cliente que establece la multivideoconferencia .

13: cliente invitado a la multivideoconferencia .

111: flujo de establecimiento de multivideoconferencia .

112: flujo de invitación a la multivideoconferencia .

113: control del flujo multimedia entre 11 y 61.

114: flujo multimedia entre 11 y 61. 115: finalización de la multivideoconferencia .

122: flujo de invitación a la multivideoconferencia

desde MCU.

123: control del flujo multimedia entre 13 y 61.

124: flujo multimedia entre 13 y 61.

125: abandono de la multivideoconferencia .

Asi, según el esquema de la figura 7, con el procedimiento que se sigue para establecer una multivideoconferencia en un sistema tradicional, y mostrando solo un cliente invitado 13, se tiene el modelo básico del estado de la técnica, pero este modelo habría que replicarlo tantas veces como clientes interviniesen en la multivideoconferencia . Primeramente ha de establecerse la multivideoconferencia (mensaje 111) y después invitar a cada uno de los participantes (mensajes 112 y 122) . Es entonces cuando comienza el intercambio de flujos multimedia bidireccionales (mensajes 114 y 124), asi como la señalización para el control de esos flujos (mensajes 113 y 123) entre cada uno de los clientes participantes y la MCU (61) .

En este contexto, un servicio en el que haya un intercambio de mensajes multimedia en tiempo real de forma unidireccional y que los destinatarios puedan contestar a ese mensaje de la misma forma seria enormemente útil. Este servicio se conoce habitualmente como Push To Talk y en el caso de las redes móviles se denomina Push To Talk over Cellular (PoC) .

La diferencia principal de este servicio respecto a una llamada telefónica convencional reside en que se trata de comunicaciones unidireccionales y de corta duración (normalmente mientras el usuario mantiene pulsado un botón) , y que son aceptadas automáticamente y de forma cuasi-instantánea (en tiempo real) por el receptor.

La diferencia principal de este servicio respecto al envió de mensajes multimedia por otros medios (email, MMS) reside en el envío en tiempo real del contenido multimedia que está siendo grabado en lugar de utilizar un mecanismo de grabación y posterior envío.

Este tipo de servicios, en el caso de ofrecerse sobre redes IP (Internet Protocol) , pueden hacer uso de los mecanismos definidos en los protocolos SIP y RTP para el establecimiento de sesiones multimedia y el intercambio de dichos contenidos multimedia respectivamente. En el caso de servicios ofrecidos por operadores de telecomunicaciones, las redes que soportan los servicios multimedia basados principalmente en esos mismos protocolos son conocidas como redes IMS o NGN.

Aunque el nombre habitual de este servicio es Push To Talk, las tecnologías de comunicaciones sobre IP subyacentes permiten aplicarlos no sólo a contenidos de audio/voz sino a cualquier otro tipo de comunicación multimedia (video, texto, juegos, etc) sin requerir la definición de procedimientos adicionales.

Actualmente el organismo de estandarización OMA (Open Mobile Alliance) está definiendo el estándar para el servicio Push-To-Talk over Cellular pare redes IMS que en su versión 2.0 contempla nuevos tipos multimedia además del intercambio de mensajes de voz (video, imágenes, texto y ficheros ) [ 1 ] .

La solución propuesta por OMA no resta complejidad en comparación a los sistemas de videoconferencia tradicionales, ya que, al igual que éstos requiere de un establecimiento de sesión previo al intercambio de mensajes, así como un continuo intercambio de mensajes para el control del flujo que se transmite por el canal. Por otra parte, el estándar de OMA tiene la limitación de que solo es posible la transmisión de un mensaje Push2Video al mismo tiempo entre los participantes de una sesión. Más adelante se describe con mayor detalle los problemas que presenta la solución de OMA. Además, existen algunas implementaciones del servicio propietarias, tales como Movial Push-To-Video [2] y el Push-To-Talk/Push-To-Xperience de Motorola [3].

También existen otras soluciones que intentan emular este tipo de servicios de forma simplificada prescindiendo de alguna de sus funcionalidades, como es el caso de los mensajes de Voz de Windows Live Messenger de Microsoft, donde estos mensajes no se envían en tiempo real.

En la figura 8, perteneciente al estado de la técnica de este documento, se ha representado un esquema del procedimiento de intercambio de mensajes PTT según OMA, donde se tienen las siguientes referencias:

21: cliente que establece la sesión y origen del

mensaje PTT.

22: servidor PTT.

23: cliente invitado a la sesión PTT y destino del

mensaje PTT.

211: flujo de establecimiento de sesión.

212: flujo de reserva del canal.

213: flujo multimedia.

214: liberación del canal.

215: flujo de cierre de sesión.

221: flujo de establecimiento de sesión desde 22.

222: flujo para informar la reserva del canal.

223: flujo multimedia desde 22.

224: flujo para informar la liberación del canal.

225: flujo de cierre de sesión.

Respecto a los problemas que se dan con las soluciones existentes, tal y como la representada en la referida figura 8, se puede indicar que el intercambio de mensajes multimedia dentro de un servicio PTT entre uno o varios usuarios tal y como ha definido la OMA, según se muestra en dicha figura 8, resulta muy complejo. Así, previamente al intercambio de mensajes PTT se requiere el establecimiento de una sesión (mensajes 211 y 221), y posteriormente el cierre (mensajes 215 y 225) por parte del origen (bloque 21) con un servidor (bloque 22) que mantiene el estado de la conferencia de manera que todos los mensajes de la misma pueden ser reenviados correctamente a todos los destinatarios (bloque 23) . El estándar que se utiliza para esta gestión de la sesión es SIP.

En el estándar de OMA existen dos tipos de sesiones en función de cómo se creen éstas. En las "pre-established" se negocian los parámetros (dirección IP, puertos y codees) que se usarán para el envió del flujo multimedia antes de crear la sesión. En las sesiones "on demand", esa negociación previa no existe, lo que resulta menos eficiente en tiempo.

Por otra parte, el envió del tráfico multimedia (mensajes 213 y 223) dentro de esa sesión PTT global requiere de señalización adicional para indicar los momentos en los que comienza (mensajes 212 y 222) y termina (mensajes 214 y 224) la transmisión del flujo. Para ello, la OMA ha definido un protocolo que se denomina Media Burst Control Protocol (MBCP) para la gestión del intercambio de ráfagas multimedia en el canal. Para implementar el MBCP se han diseñado unos diagramas de estados que han de implementar clientes y servidores.

El problema técnico derivado de esta solución actual es por una parte la complejidad del método definido, lo que dificulta la implementación del servicio y por otra parte el consumo de recursos en equipamiento especifico en la red del proveedor del servicio ya que debe mantener el estado de las sesiones y la conferencia PTT durante mucho tiempo y realizando tareas más complejas, que hace más costoso el despliegue del mismo.

Asi mismo, la gestión de la transmisión de los flujos multimedia con el MBCP, es de tal forma que los participantes no puedan transmitir sus mensajes de video si cualquier otro lo está haciendo en ese mismo momento; es decir, no puede estar transmitiendo más de un participante a la vez. Esta es otra de las limitaciones de la implementación del servicio que propone OMA.

Abreviaturas :

IMS IP Multimedia Subsystem.

IP Internet Protocol.

MBCP Media Burst Control Protocol.

MIME Multipurpose Internet Mail Extensions.

MMS Multimedia Messaging System.

NGN Next Generation Network.

OMA Open Mobile Alliance.

PoC Push To Talk over Cellular.

PTT Push To Talk.

RTP Real-time Transport Protocol.

SDP Session Description Protocol.

SIP Session Initiation Protocol.

XML Extensible Markup Language .

Referencias entre corchetes :

[1] Open Mobile Alliance (OMA), Push To Talk over Cellular

http : //www . openmobilealliance . org/Technical/release_program /poc_v2_l . aspx

[2] Movial,

http : //www . movial . fi/en/client_software/Other_Products/Push _to_Video/.

[3] Push-To-Talk/Push-To-Xperience de Motorola, http : //www . motoróla . com/networkoperators/pdfs/PTX_Brochure . pdf

DESCRIPCION DE LA INVENCION

Para lograr los objetivos y evitar los inconvenientes indicados en anteriores apartados, la invención consiste en un sistema de intercambio de mensajes PTT ( Push-to-Talk) para multivideoconferencias breves que es aplicable al intercambio, entre al menos dos usuarios, de mensajes multimedia cortos, para lo cual, se emplean infraestructuras PTT con una implementación en la que existe bien clientes y servidor, o bien, con una implementación en la que existe clientes sin servidor. El mensaje PTT queda definido por el intercambio de información en tiempo real y de manera unidireccional entre cada dos usuarios, en contraposición a la manera tradicional bidireccional para videoconferencias , en la que hay comunicación simultánea de ida y vuelta entre cada dos usuarios. Además, el mensaje PTT comprende adicionalmente la generación del mensaje multimedia de forma simultánea a su transmisión, de manera que se evita la inclusión de medios de grabación y almacenaje del mensaje multimedia previos a dicha transmisión.

Novedosamente, según la invención, el sistema de la misma comprende al menos los siguientes cuatro rasgos técnicos esenciales:

a) la sesión de multivideoconferencia con envió de al menos un mensaje PTT se establece en el momento en el que un primer usuario (también denominado cliente o participante) activa un pulsador de usuario y se finaliza cuando este primer usuario desactiva ese pulsador;

b) en el inicio de la sesión de multivideoconferencia se transmite obligadamente un listado de participantes que comprende al menos todos los participantes de la sesión; donde estos participantes son propuestos por el primer cliente mencionado en el punto a) ; incluyéndose además en el listado de participantes al propio primer usuario (cliente o participante) ;

c) en el inicio de la sesión de multivideoconferencia se transmite obligadamente un identificador global de la sesión en concreto iniciada;

d) los clientes (también denominados usuarios o participantes) comprendidos en el listado de participantes participan por defecto en la sesión de multivideoconferencia al recibir el mensaje PTT. Según la realización preferente de la invención, en el sistema de la misma, además de los rasgos expresados anteriormente, un cliente comprendido en el listado de participantes, según el referido punto d) , cuando decide comunicarse con los participantes del listado de participantes para un determinado mensaje PTT, envia obligadamente ese mismo listado de participantes expresado en el punto b) a cada uno de los participantes del listado de participantes.

Además, según la realización preferente del sistema de la invención, los terminales de usuario correspondientes a los mencionados clientes adicionalmente comprenden unos medios de filtrado y de autorización previos a las salidas y entradas de sus mensajes multimedia para posibilitar revisiones y limitaciones de los mismos previas a su emisión y recepción.

Por otra parte, en la realización preferente de la invención, en los establecimientos y cierres de las sesiones se emplea el protocolo SIP (Session Initiation Protocol) .

Además, en la realización preferente de la invención, en el sistema de la misma, para la realización del referido listado de participantes de la multivideoconferencia se emplea el estándar XML .

Con la estructura que se ha descrito, el sistema de la invención presenta ventajas relativas a que se mantiene el concepto de "conversación ρττ " entre un grupo de usuarios con aplicación a multivideoconferencia, y simplificándose al máximo la señalización para establecer sesiones PTT.

Por otra parte, tal y como está definido el servicio, no hay limitación en el número de usuarios que pueden estar mandando un mensaje PTT unidireccional a un grupo de personas al mismo tiempo, por lo que resulta sencillo convertir el servicio PTT en una conferencia bidireccional tradicional entre dos o más personas con la mayor simplicidad. Además, los canales que se establecen para el intercambio de estos mensajes PTT son unidireccionales, de manera que un cliente PTT puede tener al mismo tiempo un canal de transmisión y varios canales para recepción.

A continuación, para facilitar una mejor comprensión de esta memoria descriptiva y formando parte integrante de la misma, se acompañan unas figuras en las que con carácter ilustrativo y no limitativo se ha representado el objeto de la invención.

BREVE DESCRIPCION DE LAS FIGURAS

Figura 1.- Representa esquemáticamente a un sistema de intercambio de mensajes PTT para multivideoconferencias breves, realizado según la presente invención y en el que intervienen clientes y servidor.

Figura 2.- Representa esquemáticamente al sistema de la invención referido en la anterior figura 1 pero interviniendo clientes sin servidor.

Figura 3.- Es una representación esquemática de un intercambio de mensajes SIP al activar un pulsador de usuario, según un ejemplo de aplicación del sistema de la invención referido en las anteriores figuras.

Figura 4.- Representa un intercambio de mensajes SIP cuando se desactiva el referido pulsador en la aplicación de la anterior figura 3.

Figura 5.- Representa esquemáticamente un intercambio de mensajes SIP para enviar mensajes PTT simultáneamente, según una segunda aplicación del sistema de la invención referido en las dos primeras figuras.

Figura 6.- Representa esquemáticamente a un servicio tradicional de videoconferencia, según el estado de la técnica . Figura 7.- Representa a un esquema básico de señalización y flujo de datos en un sistema de multivideoconferencia tradicional según el estado de la técnica .

Figura 8.- Representa a un esquema de un procedimiento de intercambio de mensajes PTT según una estandarización propuesta por OMA y perteneciente al estado de la técnica.

DESCRIPCION DE UN EJEMPLO DE REALIZACION DE LA INVENCION

Seguidamente se realiza una descripción de un ejemplo de la invención haciendo alusión a las referencias de las figuras .

Asi, el sistema de intercambio de mensajes PTT para multivideoconferencias breves de este ejemplo de la invención se aplica al intercambio, entre dos o más usuarios, de mensajes multimedia cortos, utilizando infraestructuras PTT en las que existen clientes 31, 33 y servidor 32, tal y como muestra la figura 1, o bien clientes 41, 42 sin servidor, según se refleja en la figura 2.

Las referencias numéricas de esas figuras 1 y 2 representan lo siguiente:

31: cliente origen del mensaje PTT con el sistema de la invención.

32: servidor PTT en el sistema de la invención.

33: cliente destino del mensaje PTT empleando el sistema de la invención.

311: flujo de datos de establecimiento de la sesión. 312: flujo de datos del mensaje multimedia.

313: flujo de datos de cierre de la sesión.

321: flujo de datos de establecimiento de sesión desde el servidor.

322: flujo de datos del mensaje multimedia desde el servidor .

323: flujo de datos correspondiente a cierre de sesión desde el servidor. 41: cliente origen del mensaje PTT con el sistema de la invención y sin servidor.

42: cliente destino del mensaje PTT con el sistema de la invención y sin servidor.

411: flujo de datos correspondiente al establecimiento de la sesión y sin servidor.

412: flujo de datos correspondiente al mensaje multimedia y sin servidor.

413: flujo de datos correspondiente a cierre de la sesión y sin servidor.

El sistema del presente ejemplo se aplica en un conjunto formado por elementos habituales de una infraestructura PTT tales como los referidos clientes y servidor, pero modificando los procedimientos de interacción entre ellos, dándose además la funcionalidad añadida de que se posibilita la transmisión simultánea de mensajes PTT entre varios participantes de una sesión o conferencia PTT.

Cuando un usuario desea enviar un mensaje PTT a varios destinatarios, dicho usuario pulsa el botón "talk" en su aplicación de cliente y es en ese momento cuando la sesión se establece, a través del servidor PTT. A continuación, se envia el mensaje multimedia desde el usuario que inicia la sesión multivideoconferencia al servidor o a otro usuario. En el momento que decide dejar de transmitir el mensaje, el usuario suelta ese botón y la sesión se cierra. Asi, las sesiones PTT están activas únicamente mientras el mensaje PTT está siendo transmitido, ya que los tiempos de inicio y fin de sesión son muy cortos en comparación con el tiempo durante el cual se transmite el mensaje multimedia.

El establecimiento y cierre de las sesiones se puede hacer con el protocolo SIP; pudiendo no obstante en otros ejemplos de la invención utilizar otros protocolos.

Además, según el ejemplo de la invención, en el inicio de la sesión los usuarios destino, 33, 42, reciben un listado con todos los participantes de la multivideoconferencia, asi como un identificador global de la misma.

Antes de decidir su participación en la multivideoconferencia, los clientes destino 33, 42 pueden visualizar los referidos identificador y listado.

Cuando un usuario desea enviar un mensaje PTT a varios destinatarios 33, este usuario pulsa el botón correspondiente en su aplicación de cliente 31 y en ese momento es cuando la sesión se establece. A continuación se envían los mensajes correspondientes a los flujos de datos 311 y 321 a través del servidor 32. En el momento en el que se decide dejar de transmitir el mensaje, el usuario suelta ese botón y la sesión se cierra mediante los mensajes 313 y 323; de manera que las sesiones PTT están activas únicamente mientras el mensaje PTT está siendo transmitido con los flujos de datos 312 y 322 correspondientes al mensaje multimedia, teniendo en cuenta que los tiempos de inicio (311 y 321) y fin (313 y 323) de sesión son muy cortos en comparación con el tiempo durante el cual se transmite el mensaje multimedia.

Cuando, como en el caso de la figura 2, no existe servidor PTT el usuario o cliente PTT de origen 41 envía la comunicación correspondiente a cada uno de los clientes PTT destino 42 mediante los flujos de datos 411, 412 y 413.

De este modo cambiamos el concepto de lo que sería una sesión PTT en OMA, donde las sesiones engloban varios mensajes transmitidos dentro de un mismo contexto o conversación PTT.

Los mensajes de invitación para el establecimiento de sesión llegarán a las aplicaciones cliente destino. Normalmente, cuando esto ocurre, la petición es aceptada automáticamente por el cliente, puesto que la idea del servicio es que el mensaje se reproduzca prácticamente en tiempo real en destino. Sin embargo, existe la posibilidad de que el terminal del usuario sea configurado para que esto no ocurra asi, mediante la definición de unas reglas de filtrado y autorización.

Un mensaje PTT puede ser enviado a uno o varios destinatarios. La lista de usuarios que van a recibir el mensaje es enviada como parte de la invitación a la sesión de multivideoconferencia .

Los clientes que reciben el mensaje de invitación a la sesión PTT extraen la lista de participantes de esa conversación PTT y la guardan en almacenamiento local en el historial de mensajes PTT. El flujo multimedia que se transmitirá después de que el cliente emisor haya recibido la aceptación a la invitación de la sesión PTT se guarda igualmente en el cliente local, asociado a dicha lista de participantes.

La sucesión temporal y la lista de participantes asociadas a los mensajes PTT constituyen el contexto de una conversación PTT.

En caso de que alguno de los participantes de esa conversación desee responder a este mensaje previo en este mismo contexto, únicamente tendrá que seleccionar esa entrada en el historial de mensajes PTT y apretar el botón "Talk". El cliente creará una nueva invitación, la cual contendrá la misma lista de participantes que el mensaje PTT seleccionado.

La lista de participantes incluye al propio emisor del mensaje PTT. Esto debe ser asi para evitar que los clientes tengan que procesar los datos de dicha lista y sustituir la dirección del usuario que envió el mensaje seleccionado por la dirección del usuario que envia este nuevo mensaje. Por lo tanto, cuando se emplea el sistema con servidor, ha de ser el servidor el encargado de procesar la lista de participantes de las invitaciones de sesión y reenviar dichas invitaciones a todos los clientes que aparecen en la lista excepto al cliente que originó esa invitación. Con el sistema de la invención se posibilita una funcionalidad que no da el servicio descrito en el organismo de estandarización OMA, consistente en que con el sistema de la presente invención se hace posible que varios participantes de una conversación PTT manden un mensaje simultáneamente .

Seguidamente se van a describir dos aplicaciones concretas empleando el sistema del presente ejemplo de la invención y con ayuda de las figuras 3 y 4 para la primera aplicación, y la figura 5 para la segunda.

En estas aplicaciones se utiliza el protocolo SIP para el establecimiento de la sesión y el estándar XML para describir la lista de participantes dentro de los mensajes de establecimiento de la sesión SIP.

En ambas aplicaciones se da por supuesto que los flujos multimedia correspondientes incluyen audio y video.

Primera aplicación:

El usuario A selecciona a varios amigos en su lista de contactos (usuario B y usuario C) y aprieta el botón "Talk" en su aplicación de cliente. El cliente PTT del usuario A establece una sesión con el servidor PTT, para ello manda una petición SIP INVITE a través del núcleo de red SIP/IM. Posteriormente el servidor PTT establecerá la sesión con los clientes PTT B y C; para ello les mandará igualmente una petición SIP INVITE a través de la red SIP/IMS. Los clientes PTT B y C contestan automáticamente a la petición de establecimiento de sesión con una confirmación SIP 200 OK. Esta contestación es automática porque, tal y como hemos definido, en el servicio los mensajes PTT son transmitidos y reproducidos inmediatamente en el cliente receptor, no hay que esperar a que el usuario acepte la invitación .

En la figura 3 se ha detallado el intercambio de mensajes SIP entre los tres clientes, asi como las acciones de los usuarios. En las correspondientes transmisiones se incluyen algunos detalles importantes de los mensajes SIP intercambiados para el establecimiento de la sesión PTT, tales como los parámetros SDP para describir las características de los canales y el XML donde aparece la lista de los participantes.

En las sesiones PTT los canales son unidireccionales por lo que se pueden utilizar los atributos SDP a=sendonly y a=recvonly para fijar esta característica de los mismos. Los mensajes SIP INVITE tendrán en el SDP el atributo a=sendonly, ya que el que inicia la sesión es el que va a transmitir el flujo multimedia. Los mensajes SIP 200 OK tendrán en el SDP el atributo a=recvonly, porque sólo van a recibir el flujo multimedia.

Como podemos observar a continuación, el mensaje SIP INVITE que se envía tanto del origen del mensaje PTT al servidor como del servidor a los destinatarios contiene en su cuerpo una parte de texto XML en el que vienen enumerados los participantes de la conversación PTT.

1. INVITE, 3. INVITE, 5. INVITE, 6. INVITE, 13. INVITE y 14. INVITE

SDP MIME BODY

Content-Type : application/sdp

c= IN IP6 5555 : : aaa :bbb : ccc : ddd

a= sendonly

m= audio 3456 RTP/AVP 97

m= video 5678 RTP/AVP 99 XML MIME BODY

Content-Type : application/resource-lists+xml Content-Disposition : recipient-list <?xml version="l .0" encoding="UTF-8 " ?> <resource-lists

xmlns="urn : ietf:params :xml :ns : resource-lists " xmlns :xsi="http : //www. w3. org/2001/XMLSchema- instance ">

<list>

<entry uri="sip : UserA@domain . com" /> <entry uri="sip : UserB@domain . com" /> <entry uri="sip : UserC@domain . com" /> </list>

</resource-lists>

7. 200 OK, 8. 200 OK, 9. 200 OK y 10. 200 OK

SDP MIME BODY

Content-Type : application/sdp

c= IN IP6 5777 : : eee : fff: aaa :bbb

a= recvonly

m= audio 57787 RTP/AVP 97

m= video 23456 RTP/AVP 99

15. 200 OK, 16. 200 OK, 17. 200 OK & 18. 200 OK

SDP MIME BODY

Content-Type: application/sdp

c= IN IP6 5888 : : ggg:hhh : ccc : ddd

a= recvonly

m= audio 58898 RTP/AVP 97

m= video 37567 RTP/AVP 99

A continuación el usuario A suelta el botón de "Talk", según se ilustra en la figura 4. Consecuentemente, el cliente Push To Talk A manda un mensaje SIP BYE al servidor Push To Talk a través de la red SIP/IMS. El servidor termina la sesión con los clientes B y C. Una vez recibido uno de estos mensajes PTT existe la posibilidad de que cualquiera de los participantes responda al mismo. En el caso de que el usuario B seleccionase el mensaje PTT mandado por el usuario A en el menú "Historial" de su aplicación cliente y apretase el botón "Talk", el cliente PTT B mandaría una petición SIP INVITE a los clientes A y C a través del servidor PTT y la infraestructura SIP/IMS.

Este sería un nuevo mensaje PTT procesado de forma independiente al anterior pero que los usuarios podrían relacionar con el anterior bien sea por los participantes del mismo, por el contenido multimedia o por algún identificador de conversación que se incluya en los mensajes PTT.

Segunda aplicación:

La segunda aplicación del sistema del presente ejemplo se ilustra mediante la figura 5, y describe el caso del uso del sistema cuando uno de los clientes quiere mandar otro mensaje PTT al grupo de la correspondiente multivideoconferencia aún cuando el usuario que está enviando un mensaje no ha terminado todavía (no ha soltado el botón en su aplicación de cliente) . En este caso, y con la base de la primera aplicación anterior de las figuras 3 y 4, se supone que el usuario B es el que manda este segundo mensaje, de manera que la sesión 1 establecida por A y la sesión 2 establecida por B tienen lugar al mismo tiempo, tal y como puede verse en la referida figura 5.