Disclosure of 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 of user terminals coupled to the conference server via a network.
According to one embodiment of the invention, the method includes creating a conference request on a moderator terminal (modenterminal). The conference request is configured by specifying a member list, the member list including a plurality of user identity records. The conference request is transmitted to the conference server over a membership control channel. An issuable reference to the member list is created on the conference server. The publishable reference defines a conference session.
The method may also include creating a floor control list from the member list. The floor control list may be used to allow 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 transport protocol. The membership control channel may use XML based protocols (including CGMP or SOAP) for group management.
In one aspect, the method further comprises modifying the member list to add and remove user identity records from the member list. Modifications to the member list may be made when multiple user terminals are participating in an active multimedia conference.
In another embodiment of the invention, the conference server is coupled to a plurality of terminals via a network. Each terminal is coupled to the conference server via a control channel and a media channel that are active simultaneously. The conference server includes a memory configured to store a plurality of member lists. Each member list includes one or more user identity records.
The conference server also includes a processing system coupled to the memory and configured to identify at least one member list, publish the at least one member list to one or more of the terminals. The data transmission module is coupled to the processing system to transmit the at least one member list to the terminal over a control channel (defined as a membership management channel) for establishing the multimedia conference on the membership management channel.
One control channel of the conference 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 transmits the floor control list to the terminal through the floor control channel.
The member list of the conference server may include a mass invitation list or an access list. The membership control channel may use HTTP or SIP as a transport protocol. The membership control channel may use XML based protocols including CGMP, SOAP, or Remote Procedure Calls (RPCs) with similar functionality for group management.
The processing system of the conference server may be configured to add and remove user identity records from one or more member lists. Adding and deleting user identity records from a member list may occur when a user corresponding to one or more identity records participates in an active multimedia conference.
In another embodiment of the present invention, a multimedia system includes a plurality of user agents that can participate 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 a moderator terminal over a membership management channel established between the conference server and the moderator terminal.
The conference server is further configured to store the member list request as a member list. The member list may include one or more user identity records. The conference server transmits 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 to transmit the floor control list to the at least one user agent over the 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 XML-based protocols (including CGMP and SOAP) for group management.
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 user list when the user agent is participating in an active multimedia conference. The conference server may be configured to receive subscriptions to conference state changes and membership state changes. The conference server may also be configured to send synchronous and/or asynchronous membership state change notifications.
The above summary of the present invention is not intended to describe each implementation or every embodiment of the present invention. Advantages, aspects, and advantages of the invention will become apparent and appreciated by referring to the following detailed description and claims taken in conjunction with the accompanying drawings.
Detailed description of 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 facsimile 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 copyright rights whatsoever and the associated copyright owner's privileges.
In the following description of the illustrated embodiments, reference is made to the accompanying drawings which form a part hereof, and in which is shown by way of illustration different 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 comprises providing group management functions in IMS services, in particular conference services. Group management generally involves creating conference member groups for access control, invitation, floor control, and tracking membership status purposes.
Referring now to fig. 1, one possible arrangement of an IMS conferencing system is shown. The conference server 100 serves as a central control point for IMS conferencing between user terminals or other such multimedia-enabled devices. One function of the conference server 100 is to control shared resources. For example, the conference server 100 may control a mixer for selectively selecting media resources for output to the data stream. It will be appreciated that the conference server 100 need not be a stand-alone 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 may interface with a wireless system 120. Wireless system 120 may establish a Radio Access Network (RAN) 124. The mobile devices 128, 132 may access the RAN and join the conferencing services provided by the conferencing server 100.
At least one moderator 104 can act as a monitor in establishing and managing the conference. The modulator 104 and the other user terminals 108, 112 send floor control commands to the conference server 100 to change the floor status. Floor control may be delivered to the user through manual or automatic approval at the conference server 100, depending on the appointment rules for the conference. The conference server 100 notifies the moderator 104 and the other participants of the speech state change.
The floor control protocol is used to communicate floor control messages between different users associated with the conference. This protocol is defined in draft-Wu-compressing-fllor-control-01. txt, filed by Wu et al. The method outlined by Wu et al includes adding an extension in the Session Description Protocol (SDP).
SDP is a text-based generic protocol for a large number of network environments and applications. SDP is used to define certain parameters of a multimedia session and to convey relevant session establishment information to potential participants. SDP allows users to join a session without prior knowledge of the details of the underlying session parameters and data flows.
The details of SDP are described in the Internet Engineering Task Force (IETF) RFC 2327. Fig. 2 shows an exemplary SDP session description 200 that may be used to announce a multimedia conference. The use of SDP for establishing multimedia connections is for purposes of example. It is understood that the concept according to the invention is applicable to any form of dedicated or open method of establishing a multimedia connection.
For ease of discussion, the various communication paths that comprise the multimedia connection are each referred to as "channels". It should be understood that the channel as used herein is an abstraction that refers to a priori agreed upon communication paths between terminals/users/servers on the network. Although the media channel and the control channel are simultaneously considered active while a session (e.g., a teleconference) is in progress, there need not always be an active connection during the session. Indeed, for example, when using the HTTP over TCP/IP protocol, multiple socket connections are opened and closed after each "GET" or "POST" transaction. It is understood that machines on either side of an HTTP session may record sessions, states, and identities using various methods known in the art that do not rely on a continuous socket connection to define a channel.
Referring again to fig. 2, the SDP session description 200 is shown for the purpose of establishing a multimedia conference using audio, video, and whiteboard media channels (the media channels may also be referred to as "streams"). The first row 202 of the session description 200 indicates the metadata associated with the description 200, including the protocol version (v), owner/creator and session identifier (o), session name(s), session validity time (t) (in this case the session is permanent, since both start and stop times are set to 0), and the connection information (c) details of the conference server.
Line 204 is an attribute line indicating the conference type. In this example, the session is hosted, meaning that a floor control facility is employed. The attribute lines 206 and 208 define the floor control groups for the audio/video and whiteboard channels.
Each row starting with an "m ═ field is a media description field. The media field has several sub-fields. The first subfield is the media type. The currently defined media are "audio", "video", "application", "data" and "control", however, the list can be extended when new communication modalities are present. An "application" is a media stream such as whiteboard information. "control" specifies an additional conference control channel for the session. The second sub-field is the transmission port to which the media stream is to be transmitted. The third subfield is the transport protocol (e.g. RTP/AVP-IETF real-time transport protocol using audio/video profiles transported over UDP). The fourth and subsequent subfields are media formats.
Line 210 defines an audio channel on port 10000 with a payload type of 0 using an RTP audio/video profile (profile). Row 210 "a ═ mid: section 1 "defines the media ID" 1 "of the channel. Likewise, lines 212, 214, 216 and 218 define channels 2-5, which correspond to video, whiteboard, AV control and whiteboard control channels, respectively.
Referring back to line 206, it can now be seen how the "FL" semantics of line 206 group the audio and video channels 210, 212 with the AV control channel 216. Similarly, the row 208 defines a group of whiteboard channels 214 with their associated control channels 218.
Fig. 3 illustrates how a connection according to the SDP session description 200 is represented between the session server 100 and a User Agent (UA) 330. User agent 330 may be any form of terminal or device capable of communicating over a network, including computing devices, personal digital assistants, wireless/wireline telephony devices, and the like. Groups 306, 308 are defined in the session descriptions 206, 208, shown as contiguous groups of connecting lines. The AV group 306 contains audio and video RTP streams 310, 312 and an AV control channel 316. The whiteboard group 308 includes a whiteboard data channel 314 and a whiteboard control channel 318.
As defined in line 216 of session description 200, AV control channel 316 uses hypertext transfer protocol (HTTP) as the transport protocol, while whiteboard control channel 318 uses SIP as the transport protocol (defined in line 218 of fig. 2). The data format of channels 316 and 318 is Simple Object Access Protocol (SOAP). SOAP allows remote procedure calls over SIP or HTTP using extensible markup language (XML). It will be appreciated that alternative XML-based mechanisms may be used in place of SOAP to make RPC calls (RPC). Since HTTP, XML, SIP, and SOAP are open and widely implemented, employing these protocols can provide rich functionality without relying on proprietary or non-standard RPC mechanisms for floor control.
The floor control protocol does not relate to conference management, e.g. how to select the moderator of the conference. The floor control protocol also does not involve policies in the conference server, such as who can participate in the conference. The object of the present invention is to illustrate how group management can be implemented in IMS conferencing and other applications by exploiting the concepts associated with floor control channel creation.
In one aspect of the invention, one or more membership control channels are created between the conference server 100 and several UAs, including presenters and users. Fig. 3 shows two such exemplary control channels 320, 322. While there may be one or more active membership control channels open during a session, typically only one channel is used. Preferably, more than one channel may be designated so that the UA may select from different transport and application level protocols.
Referring back to fig. 2, lines 220 and 222 define two side channels 320, 322 that may be used for membership control. The channel in row 220 uses HTTP for transport and the channel in row 222 uses SIP for transport. The SIP channel 222 is defined to employ the SIP "PUBLISH" method, however other SIP methods such as the "MEMBER" method or other proposed but not yet standardized methods may be employed. In both cases, a group management protocol is used to provide conference management capabilities.
The group management protocol may be implemented using a protocol that defines a group of operations for creating and managing user groups. These operations may be implemented using XML-based commands or SOAP commands, for example. In the example of fig. 2, the Client Group Management Protocol (CGMP) is used to provide conference management capabilities. CGMP is a SOAP-based protocol that implements the required group management functions. It is to be understood that the group management operation is not limited to the use of CGMP, where CGMP is used to illustrate certain operations required for managing a multimedia group.
Once the membership control channel is defined, the moderator 104 can create an access list, mass invitation list, or other user identity data set defined in the CGMP specification or known in the art. It will be appreciated that although the group management function is described herein in terms of CGMP, alternative protocols (existing or yet to be defined) may be suitable substitutes for CGMP for providing functionality within the membership control channel. The moderator 104 sends this list to the conference server 100, and the conference server 100 stores the list and returns an issuable reference to the list. The publishable reference is typically a Uniform Resource Locator (URL), which is a standard method of locating data over an IP network. This concept is illustrated in fig. 4 and 5.
In fig. 4, the moderator 104 sends a list 402 of user identity records to the conference server. The list 402 may be an invitation list, an access list, or any combination of the two. The list 402 may be sent by any method of transferring data, including HTTP/SOAP, email (SMTP), HTTP "POST", JAVA down program (Applet), etc. For purposes of this example, list 402 will be sent using CGMP and some sort of RPC mechanism (e.g., 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 that may include other access lists 404, 406, as shown in FIG. 5. The conference server 100 stores the list set in a memory 502, which memory 502 is accessible by the processor 504 for adding, deleting and modifying lists.
The list 402 is given an ID, which in this case is GroupID3 (group ID 3). The user identity records contained in the list 402 may be parsed on the conference server 100 to enumerate users, check validity, check user availability, and any other authentication tasks. The lists 402, 404, 406 stored on the conference server are published (e.g., made accessible by the data transfer module 506). The conference server 100 also notifies the moderator 104 that the list 402 has been added and returns a "handle" to the published list, such as a URL that uniquely identifies each published list on the conference server 100.
An example HTTP session is shown in fig. 6, where the moderator sends the list using SOAP. Fig. 6 is an exemplary HTTP "POST" operation 600 in which CGMP calls are made using SOAP. The purpose of this call is to create a user group on the conference server 100 called "MyFriends". As shown at line 602, the SOAP Envelope (Envelope) is making a "CreateGroupRequest" call as shown at line 602. The CreateGroupRequest is sent by the UA to create a group of members. CreateGroupRequest involves passing in parameters such as group name, participant list, other group and member attributes.
The list of members in the CreateGroupRequest is shown on line 604. The group contains two users "sip: com "and" sip: john @ sonera. Note that the user in this example is defined using a SIP Uniform Resource Identifier (URI), which is a format similar to an email address.
Once the CreateGroupRequest shown in fig. 6 is submitted, the conference server 100 responds with an HTTP response, an example of which is shown in fig. 7. HTTP response 700 is a SOAP encoded message. On line 702, it can be seen that the conference server has specified a group ID "sip: com ". Note that the group ID of the list is also a URI similar to the ID of each user 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 who can claim the floor. The XML fragment 800 in fig. 8 illustrates how this is done. Fragment 800 is an illustration of the type "userType," which can contain a user list URI as shown in line 802 or a "user" element list as shown in line 804.
The system according to the invention can be used to build a user list for a conference before and during the conference. Turning now to fig. 9A and 9B, a sequence diagram 900 illustrates how groups are established when the moderator 104 creates an access list before the conference begins. After creating the access list, the moderator 104 sends a CreateGroupRequestRPC to the conference server 100 using SOAP or XML at event 902. The conference server 100 responds with a response event 904, the event 904 including the URL that created the group. At event 906, the moderator 104 sends the mass invitation list using CreateGroupRequest, and the conference server 100 responds with event 908, which includes the URL of the mass invitation list.
The moderator 104 now initiates an event 910, the event 910 being a call to CreateConference. The group IDs of the access list and the mass invitation list are included as parameters of the CreateConference procedure call so that users in these lists can be invited and given appropriate floor control access. Event 912 is a response by the conference server 100 to the moderator 104 corresponding to the CreateConference process.
At event 914, the conferencing server 100 parses the invitation and access list to locate and contact the invitees. At event 916 in fig. 9A and events 920, 922 in fig. 9B, the conference invitation is transmitted via SIP to moderator 104, user a 108, and user B112, respectively. The SIP INVITE method includes SDP descriptors that are used to define channels for floor control and membership management. These channels can also be used for meta-management (meta-management).
At events 924 and 926, user A108 and user B112 respond by subscribing to the conference using the "SUBSCRIBE" method of SIP. Employing the SUBSCRIBE method and NOTIFY method for subscription to NOTIFY about changes, a synchronization method for notifying any change in conference state or participant membership state is implemented. The asynchronous mechanism may be implemented using the SIP MESSAGE (message) method, and the SIP MESSAGE method is automatically sent from the conference server to all members in the participant list created using the conference group management protocol defined herein. In the asynchronous mechanism, the body of SIP MESSAGE may include any content type that is readable by the user (i.e., text data) or readable by the readable terminal (i.e., calendar invitation, etc.).
At event 928, the moderator 104 executes a GetGroupPropertiesRequest procedure call to get group-specific information, group attributes, and service-specific information. At event 930, a GetGroupProperties response is sent from the conference server 100 to the moderator 104.
At event 932 in fig. 9B, the moderator 104 invokes a createfluor (create floor) process on the conference server using the group ID. In this case, the group ID is the group ID of the mass invitation list. At event 934, the conference server 100 responds with a createfluorresponse. At event 936, the conference server 100 again parses the group list and then sends SIP NOTIFY events 938 and 940 to NOTIFY user a 108 and user B112 of the floor creation.
Fig. 10A and 10B are sequence diagrams illustrating another case of conference creation according to an embodiment of the present invention. In this case, the CGMP is used online during an ongoing conference. Events 1002, 1004, 1006, 1008, 1010, 1012, and 1014 are conference setup steps similar to those described with reference to fig. 9A and 9B. At event 1016, the moderator 104 sends an AddGroupMember request to the conference server 100. The request includes the user's MemberID to be added and the group ID of the group to which the user is to join (GroupID 1). At event 1020, the conference server 100 responds to the moderator 104 with an addgroupmemberberresponse in fig. 10B.
At event 1022, the modulator 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 the URL of the group in the CreateGroupResponse of event 1024. In events 1026 (request) and 1028 (response), the moderator 104 creates a floor for the newly created group. The new group is parsed in step 1030 and if the participant uses the SUBSCRIBE method with the conference URL, the participant is notified of the newly created utterance by events 1032 and 1034 using the SIP NOTIFY method. The conference server may also notify the participants of the created utterance by sending SIP MESSAGE methods to the participants that are asynchronous and do not require a previous SUBSCRIBE.
Sequence 1100 in FIG. 11 illustrates the case when an "allow list (allowlist)" is created online or offline and the moderator 104 decides to manage the allow list. Managing the allow list may include adding members, deleting members, modifying member attributes, and the like. Note that the allow list is not generally used to manage user interactions while the conference is in progress. Those functions are provided by a user management protocol. The conference server 100, when sending the invitation, accesses the allow list in this example, which also may be accessed by other agents on the network for other users not related to the ongoing conference.
Similar to the process described above in connection with FIG. 9A, events 1102, 1104, 1106, and 1108 in FIG. 11 are standard events for creating an allow list and creating 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. The event 1120 may also be any other CGMP group management request such as DeleteGroupMember (delete group member) that deletes a member from the allow list. Event 1122 is a standard conference server 100 response to request 1120.
It will, of course, be understood that various modifications and additions may be made to the preferred embodiment discussed hereinabove without departing from the scope of the present invention. Thus, the scope of the invention should not be limited by the specific embodiments described above, but should be defined only by the claims set forth below and equivalents thereof.