Side channel for membership management within conference control

Description of equivalent WO 2004034270 A1

SIDE CHANNEL FOR MEMBERSHIP MANAGEMENT WITHIN CONFERENCE CONTROL

FIELD OF THE INVENTION

The present invention relates to communications within IP Multimedia Subsystems (IMS) and in particular IMS conferencing services.

BACKGROUND OF THE INVENTION Internet Protocol (IP) Multimedia Subsystem (IMS) provides a framework for offering real-time, person-to-person communication services that combine the best aspects of switched networks (telephony) and packet networks (IP). IMS integrates speech and video telephony with digital services such as telemetry, telecommand, text messaging, etc. Due to the vast array of protocols and media that will be handled by IMS, open and extensible protocols are needed define parameters used for various IMS services such as transport methods, stream and data formats, and directory services. One such protocol is Session Initiation Protocol (SIP). As defined in RFC3261, SIP is "an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences."

When establishing multimedia conferences, there are a number of communication channels that must be established using different protocols. One such channel is known as "floor control". Floor control is the arbitration of control of the media and/or data streams. Since only one user should be speaking or controlling a cursor at any given time, the establishing and passing of floor control will require one of the communication channels be set up with all users.

Media signaling requires another communications channel. The floor control can therefore be considered as a side channel, and the media signaling would be considered a main channel within the conference. The SIP provides a means for establishing chamiels such as media signaling, floor control, and other side channels that may be needed. These channels can be established through SIP methods such as "PUBLISH" for floor control and "INVITE" for media signaling. Other new SIP methods could also be proposed for these purposes.

Another aspect of multimedia conferences is group management. Group management involves, among other things, establishing the users who are invited to the conference and establishing privileges of users.

What is needed in the art is a way to perform group management in IMS conference services. Further needed is a system that utilizes available protocols that are open and extensible. The present invention fulfills these and other needs, and addresses other deficiencies of prior art implementations.

SUMMARY OF THE INVENTION

To overcome the limitations in the prior art described above, and to overcome other limitations that will become apparent upon reading and understanding the present specification, the present invention discloses a method for group management of multimedia conference sessions between at least one conference server and a plurality user terminals coupled to the conference server via a network.

In accordance with one embodiment of the invention, the method involves creating a conference request at a moderator terminal. The conference request is configured by specifying a member list comprising a plurality of user identity records. The conference request is communicated to the conference server over a membership control channel. A publishable reference to the member list is created at the conference server. The publishable reference defines a conference session.

The method may further involve creating a floor control list from the member list. The floor control list is usable for allowing floor control access to the conference session as part of floor control management. The member list may include a mass invitation list or an access list. The membership control channel may use HTTP or SIP as a transportation protocol. The membership control channel can use an XML based protocol for group management, including CGMP or SOAP.

In one aspect, the method further involves modifying the member list to add and remove user identity records from the member lists. Modifying the member list may occur while the plurality of user terminals are engaged in an active multimedia conference. In another embodiment of the present invention, a conferencing server is coupled to a plurality of terminals over a network. Each terminal is coupled to the conferencing server via concurrently active control channels and media channels. The conferencing server includes a memory configured to store a plurality of member lists. Each member list includes one or more user identity records.

The conferencing server further includes a processing system coupled to the memory and configured to identify at least one member list and publish the at least one member list to one or more of the terminals. A data transmission module is coupled to the processing system to communicate with the at least one member list to a terminal over one of the control channels (defined as a membership management channel) to establish a multimedia conference over the membership management channel.

One of the control channels of the conferencing server may be defined as a floor control channel. The processing system in this arrangement is configured to create a floor control list from the at least one member list. The data transmission module communicates the floor control list to a terminal over the floor control channel.

The member list of the conferencing server may include a mass invitation list or an access list. The membership control channel may use HTTP or SIP as a transportation protocol. The membership control channel may use an XML based protocol for group management, including CGMP, SOAP or a Remote Procedure Call (RPC) with similar functionality.

The processing system of the conferencing server may be configured to add and remove user identity records from one or more of the member lists. Adding and removing user identity records from the member lists may occur while users corresponding to one or more identity records are engaged in an active multimedia conference.

In another embodiment of the present invention, a multimedia system, includes a plurality of user agents that are engagable in a multimedia conference. At least one moderator terminal is configured to create a member list request. At least one conference server is configured to receive a member list request from the moderator terminal over a membership management channel established between the conference server and the moderator terminal. The conference server is also configured to store the member list request as a member list. The member list includes one or more user identity records. The conference server communicates the member list to the plurality of user agents.

The conference server may be configured to create a floor control list from the member list and communicate the floor control list to at least one of the user agents over a floor control channel. The member list request may include a mass invitation list request or an access list request. The membership management channel may use SIP or HTTP for transport. The membership management channel may use an XML based protocol for group management, including CGMP and SOAP. The conference server may be configured to add and remove user identity records from the member list. The conference server may be configured to add and remove user identity records from the member list while user agents are engaged in an active multimedia conference. The conference server may be configured to receive a subscription for conference status changes and membership status changes. The conference server may also be configured to send a synchronous and/or asynchronous membership status change notification.

The above summary of the present invention is not intended to describe each embodiment or every implementation of the present invention. Advantages and attainments, together with a more complete understanding of the invention, will become apparent and appreciated by referring to the following detailed description and claims taken in conjunction with the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

Fig. 1 is a block diagram illustrating an IMS system according to one embodiment of the present invention;

Fig. 2 is an example SDP session description usable for establishing communication channels according to an aspect of the present invention;

Fig. 3 is a block diagram illustrating grouping of channels for a multimedia session according to an embodiment of the present invention; Fig. 4 is a block diagram illustrating an exemplary group management message being passed to a conference server according to an aspect of the present invention; Fig. 5 is a block diagram of the conference server showing arrangement of group management user lists;

Fig. 6 is an HTTP code excerpt showing the establishment of a user list using a POST operation according to the principles of the present invention; Fig. 7 is an HTTP code excerpt showing a server response to the post operation shown in Fig.6;

Fig. 8 is an XML schema fragment showing a user list data representation according to an embodiment of the present invention;

Fig. 9A is a sequence diagram showing establishment of user groups by a moderator before a conference begins according to an aspect of the present invention;

Fig. 9B is a sequence diagram continuing from Fig. 9A showing establishment of user groups by a moderator before a conference begins according to an aspect of the present invention;

Fig. 10A is a sequence diagram showing establishment of user groups according to another aspect of the present invention;

Fig. 10B is a sequence diagram continuing from Fig. 10A showing establishment of user groups according to another aspect of the present invention; and

Fig. 11 is a sequence diagram showing establishment of user groups according to yet another aspect of the present invention. While the invention is amenable to various modifications and alternative forms, specifics thereof have been shown by way of example in the drawings and will be described in detail herein. It is to be understood, however, that the intention is not to limit the invention to the particular embodiments described. On the contrary, the invention is intended to cover all modifications, equivalents, and alternatives falling within the scope of the invention as defined by the appended claims.

DETAILED DESCRIPTION OF THE VARIOUS EMBODIMENTS

A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the reproduction of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyrights and associated copyright ownership privileges. In the following description of the illustrated embodiments, references are made to the accompanying drawings which form a part hereof, and in which is shown by way of illustration, various embodiments in which the invention may be practiced. It is to be understood that other embodiments may be utilized, and structural and functional changes may be made without departing from the scope of the present invention.

The present invention involves providing group management functions within IMS services, particularly conferencing services. Group management generally involves creating conference membership groups for purposes of access control, invitation, floor control, and tracking member status. Referring now to Fig. 1, one possible arrangement of an IMS conferencing system is shown. A conference server 100 acts as central control point for IMS conferencing between user terminals or other such multimedia capable devices. One function of the conference server 100 is to control the shared resources. For example, the conference server 100 can control a mixer for selectively choosing the media sources for output to the data streams. It is appreciated that the conference server 100 need not be a standalone server, but may be part of a user terminal/device, for example, where peer-to-peer conferencing is desired.

Also shown in Fig. 1 is a router 116 that can interface to a wireless system 120. The wireless system 120 can establish a Radio Access Network (RAN) 124. Mobile devices 128, 132 can access the RAN and join in conference services provided by the conference server 100.

At least one moderator 104 can act as an overseer in establishing and managing the conference. The moderator 104 and other user terminals 108, 112 send floor control commands to the conference server 100 to change floor status. Depending on the rules of engagement of the conference, floor control can be passed to a user by either manual or automatic approval at the conference server 100. The conference server 100 notifies changes in floor status to the moderator(s) 104 and other participants.

A floor control protocol is used to transport the floor control messages among various users associated with conference. Such a protocol is defined in draft-wu-sipping- floor-control-01.txt by Wu et al. The approach outlined by Wu et al. involves adding extensions to the Session Description Protocol (SDP).

SDP is general-purpose text based protocol used for a wide range of network environments and applications. SDP serves to define certain parameters of a multimedia session and communicates the relevant session setup information to prospective participants. SDP allows a session to be joined by users without the users having a priori knowledge of all the particulars of the underlying session parameters and data streams. Particulars of SDP are described in Internet Engineering Task Force (IETF) RFC

2327. Fig. 2 shows an exemplary SDP session description 200 that could be used to advertise a multimedia conference. The use of SDP for establishing multimedia connections is provided for purposes of example. It is appreciated that concepts according to the present invention can be applied to any form of proprietary or open methods of establishing multimedia connections.

For the purposes of this discussion, the various communication paths that comprise a multimedia connection are referred to as "channels". It is appreciated that a channel as used herein is an abstraction used to designate an a priori agreed upon communication path between terminals/users/servers on the network. Although media channels and control channels are considered concurrently active while a session (e.g. teleconference) is underway, there need not be an active connection at all times during the session. Indeed, when using the HTTP protocol over TCP/IP, for example, a plurality of socket connections are opened and closed after each "GET" or "POST" transaction. It is appreciated that machines on either side of an HTTP session have various methods known in the art to keep track of sessions, states, and identities that do not rely on a continuous socket connection to define a channel.

Referring again to Fig. 2, the purpose of the illustrated SDP session description 200 is to establish a multimedia conference utilizing an audio, video, and a white-board media chamiels (media chamiels may alternately be referred to as "streams"). The first lines 202 of the session description 200 is metadata associated with the description 200, including protocol version (v), owner/creator and session identifier (o), session name (s), time the session is active (t) (in this case the session is permanent, since start and stop times are set to 0), and connection information (c) particulars of the conference server.. Line 204 is an attribute line indicating the type of conference. In the example, the session is moderated indicating the use of a floor control tool. The attribute lines 206 and 208 define floor control groups for the audio/video and white board channels.

Each line starting with "m=" field is a media description field. A media field has several sub-fields. The first sub-field is the media type. Currently defined media are "audio", "video", "application", "data" and "control", though this list may be extended as new communication modalities emerge. "Application" is a media flow such as whiteboard information. "Control" is used to specify an additional conference control channel for the session. The second sub-field is the transport port to which the media stream will be sent. The third sub-field is the transport protocol (e.g. RTP/ANP - the IETF's Realtime Transport Protocol using the Audio/Video profile carried over UDP.) The fourth and subsequent sub-fields are media formats.

Lines 210 define an audio channel on port 10000 using RTP Audio/Video profile as payload type 0. The "a^mid:!" part of lines 210 define the media ID of "1" for this channel. Likewise, lines 212, 214, 216, and 218 define channels 2-5, which correspond to video, white board, AN control, and whiteboard control channels, respectively.

Referring back to line 206, it can now be seen how the "FL" semantic of line 206 groups the audio and video chamiels 210, 212 with the AV control channel 216. Similarly, line 208 defines the grouping of the whiteboard channel 214 with its associated control channel 218.

Fig. 3 illustrates how the connections according to the SDP session description 200 may be represented between the conference server 100 and a user agent (UA) 330. The user agent 330 may be any form of terminal or device capable of communicating over a network, including computing equipment, personal digital assistants, wireless/wired telephonic apparatus, etc. The groupings 306, 308 are defined in the session descriptions 206, 208 and are shown as sets of adjacent connection lines. The AN grouping 306 contains the audio and video RTP streams 310, 312 and the AN control channel 316. The whiteboard grouping 308 contains the whiteboard data channel 314 and the whiteboard control channel 318. As defined in line 216 of the session description 200, the AV control channel 316 uses the Hypertext Transfer Protocol (HTTP) as a transport protocol, whereas the whiteboard control channel 318 uses SIP as a transport protocol (defined in line 218 of Fig. 2). The data format for both channels 316, 318 is the Simple Object Access Protocol (SOAP). SOAP allows making Remote Procedure Calls (RPC) using the Extensible Markup Language (XML) over SIP or HTTP. It is appreciated that alternate XML based mechanisms can be used in place of SOAP for making RPC calls. Because HTTP, XML, SIP, and SOAP are open and widely implemented, the use of these protocols can provide rich functionality without relying on proprietary or non-standard RPC mechanisms for floor control.

The floor control protocol does not deal with the conference management such as how to elect the moderator of the conference. Neither does it deal with the policies in the conference server such as who can join the conference. It is an object of the present invention to show how group management can be implemented in IMS conferencing and other applications by utilizing concepts associated with creation of floor control channels.

In one aspect of the present invention, one or more membership control channels are created between the conference server 100 and UAs, the UAs including moderators and users. Two such exemplary control channels 320, 322 are shown in Fig. 3. Although there may be one or more active membership control channels open during a session, usually only a single channel will be used. More than one channel may be beneficially designated so that UAs may choose from different transport and application level protocols.

Referring back to Fig. 2, lines 220 and 222 define the two side channels 320, 322 that can be used for membership control. The channel in line 220 uses HTTP for transport while the channel in line 222 uses SIP for transport. The SIP channel 222 is defined as using the SIP "PUBLISH" method, although other SIP methods such as "MEMBER" or other proposed but not yet standardized methods may also be used. In both cases, a group management protocol is used to provide conference management capabilities.

Group management protocols can be implemented using a protocol that defines a set of operations for creating and managing groups of users. Those operations could, for example, be implemented using XML-based or SOAP commands. In the example of Fig. 2, the Client Group Management Protocol (CGMP) is used to provide conference management capabilities. CGMP is a SOAP based protocols that implements the required group management functions. It is appreciated that group management operations are not limited to using CGMP, but CGMP is used herein as illustrative of certain operations required to manage multimedia groups.

Once a membership control channel has been defined, the moderator 104 can create access lists, mass invitation lists, or other user identity data collections defined in the CGMP specification or otherwise known in the art. It is appreciated that where group management functions are described herein in terms of CGMP, alternative protocols, either existing or yet to be defined, may be suitable replacements for CGMP to provide functions within a membership control channel. The moderator 104 sends this list to conference server 100, which stores the list and returns a publishable reference to the list. This publishable reference is typically a Uniform Resource Locator (URL), which is the standard way of locating data on IP networks. This concept is shown in Figs. 4 and 5.

In Fig. 4, the moderator 104 sends the conference server a list 402 of user identity records. The list 402 may be an invitation list, access list or any combination thereof. The list 402 may be sent by any method of transferring data, including HTTP/SOAP, email (SMTP), HTTP "POST", Java Applet, etc. For the purposes of this example, the list 402 will be sent using CGMP and some sort of RPC mechanism such as HTTP/SOAP.

After the list 402 is submitted to the conference server 100 as shown in Fig. 4, the list 402 is added to a collection which may include other access lists 404, 406, as seen in Fig. 5. The conference server 100 stores the list collection in memory 502 which can be accessed by a processor 504 for adding, deleting, and modifying lists.

The list 402 is given an ID, which in this case is GroupID3. The user identity records contained within the list 402 may be resolved at the conference server 100 to enumerate users, check validity, check availability of users, and any other verification tasks. The lists 402, 404, 406 stored on the conference server are published (e.g. made accessible by a data transmission module 506). The conference server 100 will also notify the moderator 104 that the list 402 has been added and return a "handle" to the published list, such as a URL that uniquely identifies each published list on the conference server 100.

An example of an HTTP session wherein the moderator sends the list using SOAP is shown in Fig. 6. Fig. 6 is a sample HTTP "POST" operation 600 where a CGMP call is made using SOAP. The purpose of this call is to create a user group called "My Friends" on the conference server 100. As indicated on line 602, the SOAP envelope is making a "CreateGroupRequest" call as indicated on line 602. CreateGroupRequest is sent by a UA to create a membership group. The CreateGroupRequest involves passing in parameters such as a group name, participant list, and other group and member properties. The members list in the CreateGroupRequest is shown on line 604. This group contains two users, "sip :j ennifer@sonera.com" and "sip:john@sonera.com". Note that the users in this example are defined using a SIP Uniform Resource Identifier (URI), which is a format similar to an email address. Once the CreateGroupRequest shown in Fig. 6 has been posted, the conference server 100 would respond with an HTTP response, an example of which is shown in Fig. 7. The HTTP response 700 is a SOAP encoded message. On line 702, it can be seen that the conference server has assigned this list the group ID of "sip:allowlist@conference.com". Note, the list's group ID is also a URI similar to the ID of individual users in the list.

After obtaining the group ID from the conference server's HTTP response 700, the moderator 104 can use the group ID to send a floor control primitive to define the users that can claim the floor. The XML fragment 800 in Fig 8 illustrates how this is done. The fragment 800 is a schema of type "userType" which can contain either the URI of the user list as shown in line 802 or a list of "user" elements as shown in line 804. A system according to the present invention can be used to establish user lists for a conference before and during the conference. Turning now to Figs. 9A and 9B, a sequence diagram 900 illustrates how groups are established when the moderator 104 creates the access lists before the conference begins. After creating an access list, the moderator 104 sends a CreateGroupRequest RPC to the conference server 100 either using SOAP or XML at event 902. The conference server 100 responds with a response event 904, the event 904 including the URL of the created group. At event 906, the moderator 104 sends a mass invitation list using CreateGroupRequest, and the conference server 100 responds with event 908 which includes the URL for the mass invitation list.

The moderator 104 now initiates event 910, which is a call to CreateConference. As parameter of the CreateConference procedure call, the group IDs of the access and mass invitation lists are included so that the users in these lists can be invited and given the appropriate floor control access. Event 912 is the response from the conference server 100 to the moderator 104 for the CreateConference procedure.

At event 914, the conference server 100 resolves the invite and access lists in order locate and contact the invitees. At event 916 in Fig 9A and events 920 and 922 of Fig. 9Bj the conference invitations are delivered via SIP to the moderator 104, user A 108, and user B 112, respectively. The SIP "INVITE" method includes an SDP descriptor used to define the channels for floor control and membership management. The channels may also be used for meta-management.

At events 924 and 926, user A 108 and user B 112 respond by subscribing to the conference using the "SUBSCRIBE" method of SIP. Using SUBSCRIBE method for subscribing and NOTIFY method to inform about changes, implements a synchronous method for notification of any changes in the conference or membership of the participant status. An asynchronous mechanism can be implemented using SIP MESSAGE method that is sent automatically from the conferencing server to all the members in the list of participants created with the herein defined conference group management protocol. In the asynchronous mechanism the body of the SIP MESSAGE can include any content-type that is readable either to the user (i.e. text data) or terminal readable (i.e. calendar invitation, etc).

At event 928, the moderator 104 makes a GetGroupPropertiesRequest procedure call to get specific group information and group properties as well as service specific information. The GetGroupPropertiesResponse is sent from the conference server 100 to the moderator 104 at event 930.

At event 932 in Fig. 9B, the moderator 104 calls the CreateFloor procedure at the conference server using a group ID. In this case, the group ID is that of the mass invitation list. The conference server 100 responds at event 934 with a

CreateFloorResponse. At event 936, the conference server 100 again resolves the group list, and then sends SIP NOTIFY events 938 and 940 to inform users A 108 and B 112 of floor creation.

The sequence diagram 1000 in Figs. 10A and 10B illustrate another scenario of conference creation according to an embodiment of the present invention. In this scenario, CGMP is used online during an ongoing conference. Events 1002, 1004, 1006, 1008, 1010, 1012, and 1014 are conference establishment steps similar to those described regarding Figs. 9A and 9B. At event 1016, an AddGroupMember request is sent by the moderator 104 to the conference server 100. The request includes the MemberlD of the user to be added and the group ID (GroupIDl) of the group to which the user is to be added. The conference server 100 responds to the moderator 104 at event 1020 with an AddGroupMemberResponse in Fig. 10B. At event 1022, the moderator 104 requests a CreateGroup procedure call and the conference server 100 responds with event 1024. The conference server 100 creates another group (GroupID3) and publishes a URL for that group in the CreateGroupResponse of event 1024. In events 1026 (request) and 1028 (response), the moderator 104 creates the floor for the newly created group. The new group is resolved in step 1030 and participants are notified of the newly created floor by events 1032 and 1034 using SIP NOTIFY method if the participants used a SUBSCRIBE method with the conference URI. The conference server can also inform the participants about the created floor by sending them a SIP MESSAGE method that is asynchronous and does not require a previous SUBSCRIBE.

The sequence diagram 1100 in Fig 11 shows a scenario where an "allow list" is created either on-line or off-line and the moderator 104 decides to manage the allow list. Managing the allow list may include adding members, removing members, modifying member properties, etc. Note that the allow list is not typically used to manage user interactions while the conference is going on. Those functions are provided by the user management protocol. The allow list in this example is accessed by the conference server 100 when sending invitations and can also be accessed by other agents on the network for various other uses not related to an ongoing meeting.

Similar to the procedures previously described in relation to Fig. 9A, events 1102, 1104, 1106, and 1108 in Fig. 11 are standard events used to create an allow list and create a publishable reference to the allow list. Similarly, events 1110, 1112, 1114, 1116, and 1118 invite and join participants as previously described. Event 1120 is an AddGroupMember request to add another member to the existing allow list. This event 1120 could also be any other CGMP group management request, such as DeleteGroupMember to remove a member from the allow list. Event 1122 is the standard conference server 100 response to the request 1120.

It will, of course, be understood that various modifications and additions can be made to the preferred embodiments discussed hereinabove without departing from the scope of the present invention. Accordingly, the scope of the present invention should not be limited by the particular embodiments described above, but should be defined only by the claims set forth below and equivalents thereof.