Method and system for group communications

[Background of invention]

The present invention relates to group communications in general, and more specifically to methods and systems for initiating, controlling, and terminating sessions between a plurality of endpoints participating in a group associated with a group entity.

[Reference to related applications]

This application relates to the following US patent application owned by Motorola with this application: "System and Method for Controlling and Managing Sessions Between Endpoints in a" by Keller et al., Filed December 31, 2002. US Patent Application No. 10 / 334,577 entitled "Communications System" (agent reference number CM05607G); "Methods for Managing a Pool of Multicast Addresses and Allocating Addresses in" by Newberg et al., Filed on December 31, 2002. US Patent Application No. 10 / 334,635 entitled "a Communications System" (agent reference number CM05666G); U.S. Patent Application No. 10 / 334,523 (agent reference number CM05665G) entitled "Apparatus and Method for Controlling and Managing Individual Directed Sessions in a Communications System" by Lillie et al., Filed December 31, 2002; U.S. Patent Application No. 10 / 334,439 entitled "Methods for Affiliating Endpoints with a Group and Determining Common Communication Capabilities for the Affiliated Endpoints" filed on December 31, 2002 by Newberg et al. ).

[Background of invention]

Multimedia and group communications have become important aspects of telecommunications, and demand for them continues to grow. For example, the 1996 Federal Communications Commission (FCC) final report of the Public Security Radio Advisory Board states that demand for communications resources for multimedia is tight. Then, in 1998, the FCC established a band plan for the 764MHz frequency, which included a group of spectra for public security broadband. In addition, the Internet Engineering Task Force (IETF) has developed a set of protocols designed for use in multimedia communications. These protocols include the Session Initiation Protocol (SIP), the Session Announcement Protocol (SAP), and the Session Description Protocol (SDP).

SIP has been widely accepted in the market for signaling communication services over the Internet since it was approved as an official standard in early 1999. As such, a number of products incorporate SIP standards, including, but not limited to, SIP desktop phones, SIP phone servers, and personal computing (PC) devices that run SIP applications. SIP is an open systems interconnection ("OSI"), a transaction protocol for text-based signaling, similar to the Hypertext Transfer Protocol ("HTTP") and Simple Mail Transfer Protocol ("SMTP"). It works in the application layer of the communication model. SIP messages are used to initiate interactive communication sessions such as voice, video and chat between users within a communication network (also referred to herein as callers). Each user is typically associated with a communication device (also referred to herein as a terminal device or endpoint) connected to that network.

Not only is SIP used to start a session, but SIP messages are also used to end or modify a session. However, SIP actually constitutes a "session", such as which Internet Protocol ("IP") channels (addresses and ports), which media codec specifications, and which floor control channels are used during the session. Etc. are not specified. This is described by the content carried in the SIP message. SIP conveys information about the protocols used to describe sessions through the Multipurpose Internet Mail Extensions (MIME), which is widely used in web and email services to describe content (HTML, audio, video, etc.). To do. The most commonly used protocol for describing sessions is the SDP described in IETF RFC 2327. SIP can also be used to negotiate a common format for describing sessions, so other protocols besides SDP can be used.

SIP is based on the request-response paradigm. Therefore, to start a session, the caller associated with the initiating endpoint makes a request (called INVITE) associated with the receiving endpoint and addressed to the user that the caller wants to call. Send. In SIP, the address is a uniform resource locator ("URL"). SIP defines a URL format that is very similar to the commonly used mailto URL. For example, the user's email address<maths num="1"><img file="JP2006513610A_D0001.tif" /></maths>If, then the SIP URL is<maths num="2"><img file="JP2006513610A_D0002.tif" /></maths>

Will be. Once the user is identified and the session description is transferred, SIP is used to convey the response (permit, deny, etc.) to the start of the session. If allowed (by SIP OK), the session is active at that point, after which a SIP ACK is sent from the initiating endpoint to the receiving endpoint.

In SIP, a successful SIP control dialog (also known as a SIP dialog, call leg or SIP transaction) is created when an INVITE / OK / ACK exchange is successful. Once a session is active, you can also use SIP to modify it. To change a session, the initiating endpoint simply resumes the session and sends a message that is the same as the original message but with a new session description. As such, the session description protocol accommodates session changes (including adding audio streams, removing audio streams, adding videos, changing codecs, holding and muting, etc.) (SDP has them). It is easy for the SIP to respond to session changes as long as it can accommodate all of the changes in. Finally, SIP can be used to end the session. This function is performed by sending a SIP BYE message.

<p> SIP is suitable for controlling a media session and for establishing a media session between one starting endpoint and one receiving endpoint or a small group of receiving endpoints. There is. However, SIP cannot be easily extended to establish a media session between one starting endpoint and a large group of receiving endpoints. This is because in a standard SIP, three messages (INVITE / OK / ACK) must be sent between the initiating endpoint and each receiving endpoint in a given group. These excessive message transmissions can cause bandwidth and timing issues, especially if the group is large, which is desirable in situations where communication is at stake, such as in the public security sector. Absent.</p><p> On the other hand, SAP is a broadcast protocol specified in RFC 2974. SAP is used by a session directory server called the SAP Announcer to announce a conference by multicast, in which case, for example, a multimedia file (almost at the same time that radio and TV programs are broadcast on the air. Usually audio and video streams) are sent to a large number of users. Although SAP can be extended to large groups of communications, the disadvantage of the methods currently used by SAP is the slow update or announcement speed, which does not correspond to dynamically assigned sessions.</p>

<p> Therefore, how to accommodate sessions dynamically allocated for group communication between multiple endpoints, expand to groups of any size, and overcome the bandwidth and timing issues of current technology. System architecture is required.</p><p> By way of example only, a preferred embodiment of the present invention will be described herein with reference to the accompanying drawings.</p>

[Detailed Description of Preferred Embodiment]

For the sake of brevity and clarity, the components shown in the drawings are not necessarily drawn to scale. For example, the dimensions of some components are exaggerated relative to each other. In addition, reference numbers are repeated to indicate the corresponding components throughout the drawing, where appropriate.

FIG. 1 shows a communication network system 100 according to the present invention that uses a method for group communication within a user's network. System 100 includes endpoint 102 associated with user 1 (not shown) and terminal 1 connected to the network, and endpoint 106 associated with user 2 (not shown) and terminal 2 connected to the network. Join Group 1 with endpoint 108 associated with user 3 (not shown) and terminal 3 connected to the network, and endpoint 110 associated with user 4 (not shown) and terminal 4 connected to the network. Includes a group entity 104 that represents a logical control point for all media sessions initiated by the endpoint. Group 1 will include multiple users and associated terminal devices that, when configured, need to share information among the users who join the group. In addition, servers and other groups in the network, if any, can join Group 1. For each terminal device 1, 2, 3 and 4, one of, but not limited to, a cellular telephone, a wireless mobile information terminal, a mobile computer and a desktop terminal can be used.

Group entity 104 integrally configures the SIP user agent client, SIP user agent server, and SAP session directory as one entity to provide one control point and unicast SIP signaling for scalability and performance. It is preferably a specialized SIP entity that translates into broadcast SAP signaling. Session start, change, and end are controlled by SIP messages addressed to group entities. The group entity maintains a session directory for all active sessions associated with a group and notifies the participating endpoints of the current state of any session via unicast SIP signaling and broadcast SAP announcements. ..

System 100 has been simplified to illustrate the present invention. However, it will be appreciated by those skilled in the art that the system 100 can be designed to include a much larger number of users and associated terminal equipment. System 100 can use a dispatch system for use in public security, including, for example, multiple dispatch groups of various sizes, in which case each dispatch group is between multiple endpoints participating in an individual group. Has a related group entity for mediating sessions at. The dispatch system can also include additional entities not shown in Figure 1 to further increase the efficiency of the system. These additional entities can be configured to help group entities relay sessions for group communication.

In system 100, through the registration process, one or more users and their corresponding terminals become known to group entity 104, thereby joining group 1 for example for group communication and media exchange. FIG. 2 shows that endpoints 102, 106, 108, 110 register with group entity 104. The registration process is shown in Figure 2 by an arrow labeled 212, pointing to the group entity 104 from each endpoint. Registration with the group entity 104 serves to provide the group entity 104 with information about individual terminals, including, for example, the capabilities of each terminal. Each endpoint registers with group entity 104, preferably through a SIP REGISTER message. However, it will be appreciated by those skilled in the art that registration with group entity 104 can be achieved through any other suitable registration process.

FIG. 3 is a flow diagram illustrating a method 300 according to the invention for establishing group communication in a system having at least one group entity and a plurality of endpoints. Method 300 comprises receiving a message from the initiating endpoint in one group entity requesting a session between multiple endpoints participating in a group associated with that group entity using a transaction protocol with step 310. Using a transaction protocol, step 320 to allow the session to be allowed, and step 330 to allow the existence of the session to be communicated to multiple endpoints participating in the group using a broadcast protocol. It includes step 340, which informs the initiating endpoint that the session has been granted by the group entity. Details of steps 310-340 according to a preferred embodiment of the present invention will now be described with reference to FIGS. 4-6.

FIG. 4 shows that, according to the present invention, endpoint 102 initiates a session with a plurality of endpoints participating in group 1 via group entity 104. To initiate the session, the initiating endpoint 102 preferably sends a SIP INVITE message addressed to the group entity 104, as indicated by the arrow 412 from the endpoint 102 to the group entity 104. The session description is carried in the payload of the SIP INVITE message and is used to describe any required session parameters. Usually, the session description for a given group communication includes any of a single media stream, multiple media streams or multiple synchronized media streams (eg Quicktime). For example, the session description can indicate that the user wants to start a session with the H.263 video stream and IMBE audio stream. In such a case, SIP INVITE will initiate the establishment of a single multimedia stream within a group of communications, in which case each media stream will preferably be established through its own SIP call leg. Alternatively, a single SIP call can be used to establish both media streams.

Appropriate tag value types or schema-based protocols are used to describe session parameters. In one preferred embodiment of the invention, SDP packets are used to describe the session. An SDP packet can, for example, describe all media streams corresponding to the same session. Session descriptions for each stream can be grouped together in the same SDP packet, making it easier for endpoints to associate those streams in order to logically form a single session. In addition, one of the advantages of using SDP to describe a session is that this protocol can be extended to carry new information specific to a session in a given system.

Once group entity 104 receives SIP INVITE 412, group entity 104 will allow or deny the session. Group entity 104 will make this determination in coordination with any other entity in the system as needed. If group entity 104 allows the session, a set of session parameters must first be selected (determined). Again, group entity 104 will coordinate with any other entity in the system as needed to ensure that the appropriate set of session parameters is selected.

As mentioned earlier, SIP INVITE412 can include the requested parameters. In this case, if not all of the requested parameters can be accepted, the set of selected session parameters is preferably, but not necessarily, part of the requested parameters. However, whether or not INVITE412 contains the required parameters, without limitation, (1) available bandwidth, available media resources such as transcoding, this group always has high resolution video. Policies such as using, and available system resources such as tight users, (2) a list of capabilities for all endpoints participating in Group 1, which will be available through the registration process above, and (3). ) The group entity 104 can be configured such that session parameters are selected according to a number of factors, including one or more sets of default parameters known to the group entity 104. At a minimum, if the session is allowed, the required data channels and possible control channels are established. The group entity 104 then populates the SAP session directory with a set of selected session parameters. Conversely, if group entity 104 rejects the session (not shown), group entity 104 initiates this, preferably by sending an error message using a transaction protocol, such as SIP. Communicate to endpoint 102.

Assuming that group entity 104 allows sessions initiated by SIP INVITE 412 from endpoint 102, the existence of the session would need to be communicated to endpoints participating in group 1. FIG. 5 shows that group entity 104 uses a broadcast protocol to convey the existence of a session and selected session parameters to endpoints 106, 108, and 110. Group agent 104 uses Internet Protocol (IP) multicast to send SAP announcements to endpoints 102, 106, 108, and 110 over the assigned multicast channel (arrow 514). Each group in the system, if not necessarily, preferably has a unique multicast address for signaling that can be selected by the group entity 104.

SAP announcements can be configured to carry identification information and session descriptions for the groups that the announcement is intended for. Dedicated media control information can be identified through the dedicated media type within this session. Decoupling media control information from session control signaling improves the configuration of functional layers in the system. Each SAP announcement preferably carries an SDP packet in its payload that describes the selected session parameters. Traditionally, according to that standard, SAP announcements have been sent out on a relatively long cycle to announce sessions that will occur at some point in the future, with active TV guides. It's very similar to instructing you to select 7 channels at 8 pm on June 23 to watch a particular show. However, according to the present invention, SAP announcements are preferably delivered at the start of the session and repeated to increase the probability that the endpoint will receive them in a short time window. Alternatively, reliable multicast technology can be used to verify the receipt of SAP announcements. In addition, SAP announcements are periodically multicast over the duration of the session.

The authorization of the session must also be propagated to the initiating endpoint using the transaction protocol. FIG. 6 shows that group entity 104 communicates the existence of a session and selected session parameters to the initiating endpoint 102. Group entity 104 preferably responds by sending a SIP OK to endpoint 102 to allow the session (indicated by arrow 616). This SIP OK preferably carries an SDP packet in its payload that describes the selected session parameters. In response, endpoint 102 is SIP Send an ACK. At this point, the INVITE / OK / ACK transaction for that session is complete and all endpoints 102, 106, 108 and 110 participating in Group 1 are informed of the session and the selected session parameters. 5 and 6 show a preferred embodiment in which the SAP announcement is sent before the group entity 104 propagates the session authorization to the initiating endpoint 102, but these two steps are in reverse order. Those skilled in the art will understand that it may be done in.

Once a session has been established in accordance with the present invention, users of the system may wish to have one or more of the following termination requests fulfilled. That is, the session is active by any of the endpoints requesting to end the session for all endpoints in the session, and by any of the endpoints participating in the session. In the meantime, a SIP control dialog (ie, a system) between the endpoint and a system that is no longer needed while the session is active, due to a request to exit the session, or any of the endpoints. It is a request to end only the call leg). The system can also automatically terminate the session or a particular call leg, in which case, for example, the session or call leg will be idle for a given period of time or when the stop timer in the system expires. There is. Such termination requests are conveyed in accordance with the present invention, preferably by transmitting a SIP BYE message.

FIG. 7 shows that group entity 104 terminates a media session established between endpoints joining group 1 in accordance with the present invention. To end that session, group entity 104 SIPs to endpoint 102 with at least one working SIP call leg. Send BYE (indicated by arrow 712). Group entity 104 may end its session, for example, in response to the expiration of the system timer. This BYE message indicates that the request ends the session for all endpoints, including all corresponding call legs. To communicate session termination to endpoints 106, 108 and 110, group entity 104 preferably immediately sends an SAP announcement (also known as a "deletion announcement") to these endpoints (indicated by arrow 714). ). These deletion announcements are preferably repeated to increase the probability that the endpoint will receive them in a short time window. Alternatively, reliable multicast technology can be used to verify the receipt of SAP announcements. At that time, the endpoint 102 sends SIP OK to the group entity 104 (arrow 716) to complete the end of the session.

Any of the endpoints participating in Group 1 can also end the established session. FIG. 8 shows that endpoint 110 terminates a session according to the present invention. One such embodiment of the invention is useful, for example, when an officer initiates a session from his vehicle to a group dispatch endpoint and some other endpoints and then leaves the vehicle. Sometimes. Another user, such as the dispatcher, may want to end the session rather than asking the officer to return to the car and end the session. To end that session, endpoint 110 first has a standard SIP A SIP call dialog with group entity 104 must be established by using INVITE / OK / ACK transactions (indicated by arrows 812, 814 and 816, respectively). Once the SIP call dialog with this group entity 104 worked, endpoint 110, as described earlier with reference to FIG. 7, indicating that endpoint 102 is terminating the session, You can end the session. Specifically, endpoint 110 will first send a SIP BYE message to group entity 104 (indicated by arrow 818). The group entity 104 will then send the SAP delete announcement to endpoints 106 and 108 that were receiving the broadcast announcement (arrow 822). However, since the starting endpoint has a SIP control dialog in function with the endpoint 102, this endpoint will be notified of the end of the session via a SIP BYE request (arrow 824), in which case the endpoint 102 will SIP Respond with OK (arrow 826). Finally, session termination is completed by group entity 104 sending a SIP OK message to endpoint 110 (arrow 828).

In addition, the established session can be modified by any of the endpoints participating in Group 1. For example, one or more endpoints may want to change session parameters such as bitrate, codec, cipher, or add or remove media streams. The endpoint preferably modifies the session by sending a SIP RE-INVITE message addressed to the appropriate group, including an SDP packet in its payload describing the modified session parameters. For an endpoint that does not have a call leg that is already working, that is, it is receiving only broadcast announcements, that endpoint will first have a regular SIP. The SIP control dialog must be established through the INVITE / OK / ACK transaction. The group entity then notifies all endpoints with a functioning SIP dialog of the changed session parameters through SIP signaling and changes to other endpoints in the group through repeated SAP announcements. Notify the session parameters that have been made.

Although the present invention has been described with specific embodiments thereof, one of ordinary skill in the art will readily come up with yet another advantage and modification. Therefore, the invention is, in its broader aspects, not limited to the specific details, representative devices and examples in which the invention has been practiced using SIP, SAP and SDP protocols. In view of the above description, various modifications, modifications and modifications will be apparent to those skilled in the art, including, but not limited to, implementing the present invention using other transactional, broadcast or session description protocols. Moreover, the present invention does not preclude the use of standard SIP devices such as telephones. Therefore, it should be understood that the present invention is not limited by the above description and includes all such modifications, modifications and modifications according to the spirit and scope of the appended claims.

<figref num="1">The block diagram which shows the system which uses the method for group communication by this invention.</figref><figref num="2">A block diagram according to the present invention showing a plurality of endpoints participating in a group associated with a given group entity.</figref><figref num="3">The flow diagram which shows the method for establishing group communication between a plurality of endpoints in one system according to this invention.</figref><figref num="4">A block diagram showing that one endpoint initiates a session with multiple endpoints participating in this group through a group entity associated with that group according to the present invention.</figref><figref num="5">A block diagram showing that SAP announcements are sent to multiple endpoints joining a group in accordance with the present invention to convey the presence of a session.</figref><figref num="6">A block diagram showing that a group entity propagates session authorization to the initiating endpoint according to the present invention.</figref><figref num="7">A block diagram showing a group entity ending a session according to the present invention.</figref><figref num="8">A block diagram showing an endpoint joining a group ending a session according to the present invention.</figref>