The present application is related to the following U.S. applications commonly owned together with this application by Motorola, Inc.:
The present invention relates generally to group communications and more specifically to a method and system for initiating, controlling, and terminating a session between a plurality of endpoints affiliated with a group that correlates to a group entity.
Multimedia and group communications have become an important aspect of telecommunications, and the demand for such continues to increase. For instance, the Final Report of the Public Safety Wireless Advisory Committee to the Federal Communications Committee (“FCC”), dated 1996, expressed the critical need for communication resources for multimedia. Subsequently in 1998, the FCC established a band plan for the 764 MHz frequencies that included spectrum set aside for public safety wideband. In addition, the Internet Engineering Task Force (“IETF”) has developed a suite of protocols that are designed for use in multimedia communications. These protocols include a Session Initiation Protocol (“SIP”), a Session Announcement Protocol (“SAP”), and a Session Description Protocol (“SDP”).
Since its approval in early 1999 as an official standard, SIP has gained tremendous market acceptance for signaling communications services on the Internet. As such, numerous products incorporate the SIP standard, including but not limited to SIP desktop telephones, SIP telephony servers, and personal computing (“PC”) devices running SIP applications. SIP is a text-based signaling transactional protocol, similar to Hypertext Transfer Protocol (“HTTP”) and Simple Mail Transfer Protocol (“SMTP”), and works in the Application layer of the Open Systems Interconnection (“OSI”) communications model. A SIP message is used to initiate an interactive communications session, such as voice, video, and chat, between users (also referred to herein as callers) in a communications network. Each user is typically associated with a communications device (also referred to herein as a terminal device or an endpoint) that is connected to the network.
SIP is not only used to initiate sessions, SIP messages are also used to terminate and to modify sessions. SIP does not, however, actually define what a “session” is, e.g., which Internet Protocol (“IP”) channel (addresses and ports), media codec specification, floor control channels, etc., are to be used during the session. This is described by content carried in the SIP messages. SIP conveys information about the protocol used to describe the session through multipurpose Internet mail extensions (MIME), widely used in web and e-mail services to describe content (HTML, audio, video, etc.). The most common protocol used to describe sessions is SDP, described in the IETF Request for Comments [RFC]2327. SIP can also be used to negotiate a common format for describing sessions, so that other protocols besides SDP can be used.
SIP is based on the request-response paradigm. Thus, to initiate a session, a caller who is associated with an initiating endpoint sends a request (called an INVITE) addressed to the user, associated with a recipient endpoint, that the caller wants to talk to. In SIP, addresses are Uniform Resource Locators (“URLs”). SIP defines a URL format that is very similar to the popular mailto URL. For instance, if the user's e-mail address is janedoe@company.com, the SIP URL would be sip:janedoe@company.com. Once the user has been located and the session description delivered, SIP is used to convey the response to the session initiation (accept, reject, etc.). If accepted (via a SIP OK), the session is now active, wherein a SIP ACK is then sent from the initiating endpoint to the recipient endpoint.
In SIP, a successful INVITE/OK/ACK exchange creates a SIP control dialog (also referred to as a SIP dialog, a call leg or a SIP transaction). Once a session is active, SIP can be used to modify the session as well. To modify a session, the initiating endpoint simply re-initiates the session, sending the same message as the original, but with a new session description. For this reason, modification of sessions (which includes things like adding and removing audio streams, adding video, changing codecs, hold and mute) are easily supported with SIP, so long as the session description protocol can support them (SDP supports all of the above). Finally, SIP can be used to terminate the session. Sending a SIP BYE message performs this function.
SIP is good for controlling media sessions and for establishing media sessions between an initiating endpoint and one recipient endpoint or a small group of recipient endpoints. However, SIP is not readily scalable for establishing media sessions between an initiating endpoint and a large group of recipient endpoints. This is because in standard SIP, three messages (INVITE/OK/ACK) must be sent between the initiating endpoint and each recipient endpoint in a given group. If a group is particularly large, this excessive messaging could cause bandwidth and timing problems, which is not desirable for communications that are time sensitive, e.g., as in the area of public safety.
SAP, on the other hand, is a broadcast protocol that is defined in RFC2974. SAP is used by a session directory server, referred to as a SAP announcer, to announce multicast based conferences, wherein, for instance, multimedia files (usually audio and video streams) are sent to multiple users at the same time somewhat as radio and TV programs are broadcast over airwaves. Although SAP is scalable for large group communications, a shortcoming of how SAP is currently implemented is that it has a low update or announcement rate that does not support dynamically assigned sessions.
Thus, there exists a need for a method and a system architecture that supports dynamically assigned sessions for group communication between a plurality of endpoints and that is scalable for any size group and overcomes the bandwidth and timing problems in the current art.
A preferred embodiment of the invention is now described, by way of example only, with reference to the accompanying figures in which:
It will be appreciated that for simplicity and clarity of illustration, elements shown in the figures have not necessarily been drawn to scale. For example, the dimensions of some of the elements are exaggerated relative to each other. Further, where considered appropriate, reference numerals have been repeated among the figures to indicate corresponding elements.
Group entity 104 is preferably a specialized SIP entity that combines a SIP user agent client, a SIP user agent server, and a SAP session directory into a single entity to provide a single point of control and to transform unicast SIP signaling to broadcast SAP signaling for increased scalability and performance. Session initiation, modification, and termination are controlled by SIP messages addressed to the group entity. The group entity maintains a session directory of all active sessions within a group's context and informs affiliated endpoints of the current state of any sessions via unicast SIP signaling and broadcast SAP announcements.
System 100 is simplified for purposes of illustrating the present invention. However, those of ordinary skill in the art will realize that system 100 may be designed to include a much larger number of users and associated terminal devices. System 100 may be, for instance, a dispatch system for use in public safety that includes a plurality of dispatch groups of varying sizes, wherein each dispatch group has a correlating group entity for mediating sessions between a plurality of endpoints affiliated with the respective group. The dispatch system may also include additional entities not shown in
In system 100, one or more users and their corresponding terminals are made known to group entity 104 and thereby affiliated with group 1, for purposes of, e.g., group communications and media exchange, through a registration process.
A suitable tag-value type or schema-based protocol is used for describing session parameters. In a preferred embodiment of the present invention, a SDP packet is used for session descriptions. The SDP packet may, for instance, describe all of the media streams that correspond to the same session. The session description for each stream may also be bundled into the same SDP packet to make it easier for the endpoints to associate the streams together to logically form a single session. Moreover, one of the advantages of using SDP for session descriptions is that this protocol may be extended to carry new information specific to sessions in a given system.
Once group entity 104 receives the SIP INVITE 412, group entity 104 will cause the session to be accepted or declined. Group entity 104 will coordinate with any other entity in the system, as needed, to make this determination. If group entity 104 accepts the session, a set of session parameters must first be selected (resolved). Again, group entity 104 will coordinate with any other entity in the system, as needed, to cause a suitable set of session parameters to be selected.
As stated above, SIP INVITE 412 may contain requested parameters. In this case, the set of selected session parameters is preferably, but not necessarily, at least a subset of the requested parameters if all of the requested parameters cannot be accommodated. However, whether INVITE 412 contains requested parameters or not, group entity 104 may be configured to cause session parameters to be selected as a function of a number of factors, including but not limited to: (1) available system resources such as the available bandwidth, the available media resources, e.g., transcoding, policies, e.g., this group always uses high resolution video, and critical users; (2) a capabilities list for all of the endpoints affiliated with group 1, which is made available through the registration process described above; and (3) one or more sets default parameters known to group entity 104. At a minimum, if the session is accepted, the required data and possible control channels are established. Thereafter, group entity 104 causes the set of selected session parameters to be entered into a SAP session directory. Conversely, if group entity 104 declines the session (not illustrated), group entity 104 communicates this to the initiating endpoint 102 preferably by sending an error message using the transactional protocol, e.g. SIP.
Assuming group entity 104 accepts the session initiated by the SIP INVITE 412 from endpoint 102, the presence of the session would then need to be communicated to the endpoints affiliated with group 1.
The SAP announcements can be constructed to carry the identification of the group for which the announcement is intended as well as a session description. Specialized media control information can be identified through specialized media types in this session. Separating media control information from session control signaling improves functional layering within the system. Preferably, each SAP announcement carries in its payload an SDP packet describing the selected session parameters. Traditionally, in accordance with the standard, SAP announcements are sent out on a relatively long periodic basis to announce sessions that will be taking place at some time in the future, much like an active TV Guide instructing someone to tune in to channel 7 at 8:00 PM on June 23rd to see a particular program. However, in accordance with the present invention, SAP announcements are sent contemporaneously with the start of a session and are preferably repeated to increase the probability of the endpoints receiving them in a short time window. A reliable multicast technology may alternatively be used to verify receipt of the SAP announcements. Moreover, the SAP announcements are periodically multicast for the life of the session.
The acceptance of the session must also be communicated to the initiating endpoint using the transactional protocol.
Once a session is established according to the present invention, users of the system may desire to have one or more of the following termination requests implemented: a request by any of the endpoints to terminate the session for all endpoints in the session; a request by any of the endpoints joined to the session to leave the session, while the session remains active; or a request by any of the endpoints to end only a SIP control dialog (i.e., a call leg) between the endpoint and the system that is no longer needed, while the session remains active. The session or a particular call leg may also be terminated automatically by the system where, for instance, the session or call leg has been idle for a predetermined amount of time or at the expiration of a hang-timer in the system. Such termination requests are communicated, in accordance with the present invention, preferably by transmitting a SIP BYE message.
Any one of the endpoints affiliated with group 1 may also terminate the established session.
Furthermore, an established session can be modified by any of the endpoints affiliated with group 1. For instance, one or more endpoints may wish to change session parameters such as bit rates, codecs, encryption, etc., or may wish to add or remove media streams. An endpoint preferably modifies a session by sending a SIP RE-INVITE message addressed to the appropriate group that contains a SDP packet in its payload that describes the modified session parameters. For endpoints that do not have a call leg already in place, i.e., receiving only broadcast announcements, the endpoint must first establish a SIP control dialog through a typical SIP INVITE/OK/ACK transaction. Thereafter, the group entity notifies all endpoints with a SIP dialog in place of the modified session parameters through SIP signaling and notifies the other endpoints in the group of the modified session parameters through repeated SAP announcements.
While the invention has been described in conjunction with specific embodiments thereof, additional advantages and modifications will readily occur to those skilled in the art. The invention, in its broader aspects, is therefore not limited to the specific details, representative apparatus, and illustrative examples shown and described, wherein SIP, SAP and SDP protocols were used to implement the present invention. Various alterations, modifications and variations will be apparent to those skilled in the art in light of the foregoing description, which include but are not limited to implementing the present invention using other transactional, broadcast or session description protocols. In addition, the present invention does not preclude the use of standard SIP devices, such as telephones. Thus, it should be understood that the invention is not limited by the foregoing description, but embraces all such alterations, modifications and variations in accordance with the spirit and scope of the appended claims.
Number | Name | Date | Kind |
---|---|---|---|
5434852 | LaPorta et al. | Jul 1995 | A |
5517494 | Green | May 1996 | A |
6005848 | Grube et al. | Dec 1999 | A |
6108705 | Svennevik et al. | Aug 2000 | A |
6275852 | Filepp | Aug 2001 | B1 |
6438114 | Womack et al. | Aug 2002 | B1 |
6449260 | Sassin et al. | Sep 2002 | B1 |
6477150 | Maggenti et al. | Nov 2002 | B1 |
6529882 | Park et al. | Mar 2003 | B1 |
6823364 | Sollee et al. | Nov 2004 | B1 |
6845389 | Sen et al. | Jan 2005 | B1 |
6934279 | Sollee et al. | Aug 2005 | B1 |
6301245 | Luzeski et al. | Oct 2005 | B1 |
6965614 | Osterhout et al. | Nov 2005 | B1 |
7079495 | Pearce et al. | Jul 2006 | B1 |
7366780 | Keller et al. | Apr 2008 | B2 |
7502837 | Westman et al. | Mar 2009 | B2 |
20020037735 | Maggenti et al. | Mar 2002 | A1 |
20020061760 | Maggenti et al. | May 2002 | A1 |
20020061761 | Maggenti et al. | May 2002 | A1 |
20020061762 | Maggenti et al. | May 2002 | A1 |
20020077136 | Maggenti et al. | Jun 2002 | A1 |
20020086665 | Maggenti et al. | Jul 2002 | A1 |
20020998840 | Hanson | Jul 2002 | |
20020119821 | Sen | Aug 2002 | A1 |
20020141383 | Schaefer et al. | Oct 2002 | A1 |
20020150091 | Lopponen et al. | Oct 2002 | A1 |
20020150092 | Bontempi et al. | Oct 2002 | A1 |
20020156903 | Bach Corneliussen | Oct 2002 | A1 |
20020177466 | Laurila et al. | Nov 2002 | A1 |
20030079037 | Donnelly et al. | Apr 2003 | A1 |
20030095510 | Dorenbsoch | May 2003 | A1 |
Number | Date | Country |
---|---|---|
05-308634 | Nov 1993 | JP |
WO 0167674 | Sep 2001 | WO |
WO 0167675 | Sep 2001 | WO |
WO 0167787 | Sep 2001 | WO |
Number | Date | Country | |
---|---|---|---|
20040125802 A1 | Jul 2004 | US |