System and method for controlling and managing sessions between endpoints in a communications system
Abstract
This record has no abstract on file.
Term
Term ended
Expired 18 December 2023, 2.8 years ago.
- Priority
- Filed
- Granted
- Expired
- Today
8 claims: 2 independent, 6 dependent
- 1論理エンティティおよびその物理対応物をそれぞれ備える複数のエンド・ポイントを有する通信システムにおいて、少なくとも二つの前記エンド・ポイント間のセッションを制御および管理するシステムであって、 前記通信システムにおける前記論理エンティティのそれぞれとその物理対応物との間の関連付けを維持して、前記論理エンティティのそれぞれへのアプリケーション層ルーティングを可能にする登録マネージャと、 前記登録マネージャによって維持される関連付けに応じて宛先となる論理エンティティに制御および情報メッセージを送信するアプリケーション層ルータと、 通信システム・リソースおよび前記少なくとも二つのエンド・ポイントのリソースに応じて少なくとも二つのエンド・ポイントの間のリクエストされたセッションの状態を判断し、前記リクエストされたセッションを許可する際に対応するセッション・パラメータの組を決定するセッション・コントローラと、 前記アプリケーション層ルータに通信可能に接続され、少なくとも一つのグループを含むグループ・リストを保持し、該グループ・リストに含まれる各グループに対して、 該グループに加入した各エンド・ポイントからのAFFILIATE要求を処理することにより、該各エンド・ポイントを追跡して、 該グループと少なくとも一つの加入したエンド・ポイントとの間の関連付けを維持するグループ・データベース・マネージャと、 前記グループ・データベース・マネージャに通信可能に接続され、前記グループ・データベース・マネージャによって保持されるグループ・リスト中の各グループに関連付けられる少なくとも一つのグループ・エンティティであって、該グループ・エンティティのそれぞれは前記登録マネージャおよび前記セッション・コントローラに通信可能に接続され、前記アプリケーション層ルータから送信されるメッセージを受信するために前記アプリケーション層においてアドレスが命名され前記アドレスを使用して接続可能になり、該グループ・エンティティのそれぞれは、更に、前記アプリケーション層ルーティングによって、開始側エンド・ポイントとグループ・エンティティの関連するグループとの間でのグループ指向セッションをリクエストする第1のメッセージを受信し、前記リクエストされたグループ指向セッションを前記セッション・コントローラに通信し、前記アプリケーション層ルーティングによって、前記リクエストされたグループ指向セッションの状態および前記セッション・コントローラにより許可されたグループ指向セッションに関して対応するセッション・パラメータの組を前記開始側エンド・ポイントに通信し、前記許可されたグループ指向セッションおよび前記対応するセッション・パラメータの組を前記関連付けられたグループに加入している他のエンド・ポイントのそれぞれに通信するように構成される、少なくとも一つのグループ・エンティティと、を備える、エンド・ポイント間のセッションを制御および管理するシステム。
- 2請求項1に記載のシステムであって、更に、前記セッション・コントローラおよび前記グループ・データベース・マネージャに通信可能に接続され、少なくとも二つのエンド・ポイント間のセッションにおいて使用可能であり、かつ前記少なくとも二つのエンド・ポイント間の前記セッション・コントローラにより許可されたセッションの対応するセッション・パラメータの組を決定するために前記セッション・コントローラによって使用可能な少なくとも一組のセッション・パラメータを確立するパラメータ・リゾルバを備える、エンド・ポイント間のセッションを制御および管理するシステム。
- 3請求項1に記載のシステムであって、更に、前記登録マネージャおよび前記セッション・コントローラに通信可能に接続され、開始側エンド・ポイントと少なくとも一つの宛先であるエンド・ポイントとの間での個別指向セッションをリクエストする前記アプリケーション層ルータから送信された第1のメッセージを傍受し、前記リクエストされた個別指向セッションを前記セッション・コントローラに通信し、前記アプリケーション層ルーティングによって、前記リクエストされた個別指向セッションの状態および許可された個別指向セッションに関して対応するセッション・パラメータの組を前記開始側エンド・ポイントに通信し、前記許可された個別指向セッションおよび対応するセッション・パラメータの組を前記少なくとも一つの宛先であるエンド・ポイントに通信する少なくとも一つの個別プロキシを備える、エンド・ポイント間のセッションを制御および管理するシステム。
- 4請求項1に記載のシステムであって、更に、前記通信システムに通信可能に接続され、マルチキャスト・アドレスのプールを管理し、専用のマルチキャスト・アドレスに対するリクエストに応答して前記専用のマルチキャスト・アドレスを割り当てるマルチキャスト・アドレス・マネージャを備え、該マルチキャスト・アドレス・マネージャは、前記セッション・コントローラに通信可能に接続され、専用のマルチキャスト・アドレスに対する前記セッション・コントローラからのリクエストに応答して前記専用のマルチキャスト・アドレスを割り当て、該マルチキャスト・アドレス・マネージャは、前記グループ・データベース・マネージャに通信可能に接続され、専用のマルチキャスト・アドレスに対する前記グループ・データベース・マネージャからのリクエストに応答して前記専用のマルチキャスト・アドレスを割り当てる、エンド・ポイント間のセッションを制御および管理するシステム。
- 5請求項1に記載のシステムにおいて、前記対応するセッション・パラメータは、前記グループに加入している少なくとも一つのエンド・ポイントをサービス指定エンティティ宛てに送信する情報を含む、システム。
- 6論理エンティティおよびその物理対応物をそれぞれ備え、かつセッション開始プロトコル(SIP)プロトコル・ユーザ・エージェント・クライアント(UAC)、およびSIPユーザ・エージェント・サーバ(UAS)をそれぞれ含む複数のエンド・ポイントを有する通信システムにおいて、少なくとも二つの前記エンド・ポイント間のセッションを制御および管理するシステムであって、 前記通信システムにおける前記論理エンティティのそれぞれとその物理対応物との間の関連付けを維持して、前記SIPプロトコルを介して前記論理エンティティのそれぞれへのアプリケーション層ルーティングを可能にする登録マネージャと、 前記登録マネージャによって維持される関連付けに応じて宛先となる論理エンティティに制御および情報メッセージを送信するSIPプロキシと、 通信システム・リソースおよび前記少なくとも二つのエンド・ポイントのリソースに応じて少なくとも二つのエンド・ポイントの間のリクエストされたセッションの状態を判断し、前記リクエストされたセッションを許可する際に対応するセッション・パラメータの組を決定するセッション・コントローラと、 前記SIPプロキシに通信可能に接続され、少なくとも一つのグループを含むグループ・リストを保持し、該グループ・リストに含まれる各グループに対して、 該グループに加入した各エンド・ポイントからのAFFILIATE要求を処理することにより、該各エンド・ポイントを追跡して、 該グループと少なくとも一つの加入したエンド・ポイントとの間の関連付けを維持するグループ・データベース・マネージャと、 前記グループ・データベース・マネージャに通信可能に接続され、前記グループ・データベース・マネージャによって保持されるグループ・リスト中の各グループに関連付けられる少なくとも一つのグループ・エンティティであって、該グループ・エンティティのそれぞれは前記登録マネージャおよび前記セッション・コントローラに通信可能に接続され、前記SIPプロキシから送信されるメッセージを受信するためにSIP UASを含み、更に、開始側エンド・ポイントとグループ・エンティティの関連するグループとの間でのグループ指向セッションをリクエストする第1のメッセージを前記開始側エンド・ポイントのSIP UACから受信し、前記リクエストされたグループ指向セッションを前記セッション・コントローラに通信し、前記リクエストされたグループ指向セッションの状態および許可されたグループ指向セッションに関して対応するセッション・パラメータの組を前記開始側エンド・ポイントのSIP UACに通信し、前記許可されたグループ指向セッションおよび前記対応するセッション・パラメータの組を前記関連付けられたグループに加入している他のエンド・ポイントのそれぞれに通信するように構成される、少なくとも一つのグループ・エンティティと、を備える、エンド・ポイント間のセッションを制御および管理するシステム。
- 7請求項6に記載のシステムであって、更に、前記セッション・コントローラに通信可能に接続され、少なくとも二つのエンド・ポイント間のセッションにおいて使用可能であり、かつ前記少なくとも二つのエンド・ポイント間の許可されたセッションに対して対応するセッション・パラメータの組を決定するために前記セッション・コントローラによって使用可能な少なくとも一組のセッション・パラメータを確立するパラメータ・リゾルバを備える、エンド・ポイント間のセッションを制御および管理するシステム。
- 8請求項6に記載のシステムであって、更に、前記登録マネージャおよび前記セッション・コントローラに通信可能に接続された少なくとも一つの個別プロキシを備え、該個別プロキシのそれぞれは、前記SIPプロキシから送信されたメッセージを傍受するSIP UASを含み、更に、開始側エンド・ポイントと少なくとも一つの宛先となるエンド・ポイントとの間での個別指向セッションをリクエストする第1のメッセージを前記開始側エンド・ポイントのUACから受信し、前記リクエストされた個別指向セッションを前記セッション・コントローラに通信し、前記リクエストされた個別指向セッションの状態および前記セッション・コントローラにより許可された個別指向セッションに関して対応するセッション・パラメータの組を前記開始側エンド・ポイントのUACに通信し、前記許可された個別指向セッションおよび対応するセッション・パラメータの組を前記少なくとも一つの宛先となるエンド・ポイントの前記UASに通信するように構成される、エンド・ポイント間のセッションを制御および管理するシステム。
Independent claims8
82 paragraphs, as filed
The present invention generally relates to devices and methods that enable group-oriented sessions between at least two endpoints in a communication system. (Citation of related application) The present invention relates to the following US applications commonly owned by Motorola with the present application.
December 31, 2002, entitled "Methods for Managing a Pool of Multicast Addresses and Allocating Addresses in a Communications System" by Newberg et al. US Patent Application No. 10 / 334,635 filed on the same day (agent reference number CM05666G), Filed on December 31, 2002, entitled "Apparatus and Method for Controlling and Managing Individual Directed Sessions in a Communications System" by Lillie et al. U.S. Patent Application No. 10 / 334,523 (Agent Reference No. CM05665G), Newberg ) Etc. entitled "Methods for Affiliating Endpoints with a Group and Determining Common Communication Capabilities for the Affiliated Endpoints" US Patent Application No. 10 / 334,439 filed on December 31, 2002 (agent reference number CM05638G), U.S. Patent Application No. 10 / 334,521 (agent) filed December 31, 2002, entitled "Method and System for Group Communication" by Lillie et al. Reference number CM05100G).
Multimedia and group communications are important features of telecommunications, and their demand continues to grow. For example, the final report of the Public Safety Radio Advisory Board to the Federal Communications Commission (FCC) dated 1996 explains the important need for communications resources for multimedia. The FCC then established a band plan for the 764MHz frequency in 1998, including spectra for public safety broadband. In addition, the Internet Engineering Task Force (IETF) has developed a set of protocols designed for use in multimedia communications. These protocols include Session Initiation Protocol (SIP), Session Announcement Protocol (SAP), and Session Description Protocol (SDP).
Since being approved as an official standard in early 1999, SIP has gained strong market support for signaling communications services over the Internet. Many products, including but not limited to SIP desktop phones, SIP telephony servers, and personal computer (PC) devices that run SIP applications, incorporate the SIP standard. SIP is a text-based signaling transaction protocol similar to Hyper Text Transfer Protocol (HTTP) and Simple Mail Transfer Protocol (SMTP), and is Open Systems Interconnection (OSI). : Open System Interconnection ) Works in the application layer of the communication model. SIP messages are used to control interactive communication sessions such as voice, video, and chat between users (also referred to herein as callers) in a communication network. Each user is typically associated with a communication device (also referred to as a terminal device in the present application) connected to the network.
SIP is designed to control a media session and establish a media session between the initiating endpoint and one receiving endpoint or a small group of receiving endpoints. However, SIP is not easily extensible to establish a media session between a starting endpoint and a large group of receiving endpoints. This is because in standard SIP, three messages (INVITE / OK / ACK) must be exchanged between the starting endpoint and each receiving endpoint in a given group. Excessive messaging causes bandwidth and timing issues that are undesirable for time-dependent communications, such as in areas of public security, especially when groups are large.
Known systems for group communication attempt to use standard SIP to enable group communication. To this end, the system implements a call control architecture according to the server-centric architecture 100 shown in Figure 1. Architecture 100 may be included in a push-to-talk (PTT) communication system. Architecture 100 includes a service-designated server 102, such as a PTT server, that is communicably connected to a signaling path between endpoint 104 and group 110 with endpoints 112, 114, and 116.
Using this framework, group communication is supported by PTT server 102, which is known to endpoints 112, 114, and 116 as the target of all call control signaling. To set up a session, the initiating endpoint must target the session request to PTT server 102 using an Internet Protocol (IP) address. Specifically, call control signaling used in session requests somehow identifies groups, while routing to PTT server 102 performs Domain Name System (DMS) lookups and networks. It is realized using the layer IP protocol. This approach limits the performance of systems that perform load balancing and failure recovery by linking group communication to a particular server, giving the starting endpoint not only the group name but also the appropriate server IP address. There are restrictions as it imposes an additional burden by requiring knowledge.
In addition, existing group communications approaches limit scalability and performance because well-defined SIP call legs must be used to bring members of each group into the session. Therefore, as the number of members in a group increases, more three-way signaling exchanges must be performed on shared wire lines and wireless links before the session setup is complete. For larger groups, serialization delay increases call setup time beyond the tolerance of certain systems, especially public safety dispatch systems.
One embodiment of a system that uses SIP signaling in the restricted manner described above for group communication is "METHOD AND APPARATUS FOR PARTICIPATING IN GROUP COMMUNICATION SERVICES IN AN EXISTING". It is disclosed in WO0167674A2 (09/518776) entitled "COMMUNICATION SYSTEM". The specification describes a PTT server that can be added to a packet data system to provide Voice over IP (VoIP) group communication. When a terminal wants to communicate with the net (a group of endpoints), the terminal uses DNS to determine the IP address of the appropriate top-level server and resolves the SIP server address to the Internet network address. And SIP to the server Send INVITE and request a session with the net. The server is also a target for call control signaling, speaker arbitration signaling, and media. Moreover, only point-to-point SIP signaling is used.
<p> Therefore, we take advantage of SIP's application layer routing control to allow users to initiate sessions based solely on the target name and domain, regardless of which particular device they are using, and even larger groups. There is a need for a call control architecture that includes features that allow users greater scalability and faster call setup.</p>
Preferred embodiments of the present invention will be described below as an example with reference to the accompanying drawings. It will be understood that the elements shown in the drawings are not necessarily drawn in a constant proportion for the sake of simplicity and clarity of the illustration. For example, the dimensions of some elements are relatively exaggerated. Further, where appropriate, the same reference numbers are repeated to indicate the corresponding elements between the drawings.
FIG. 2 illustrates a call control architecture 200 with several entities and their communication paths that allow communication between at least two endpoints in a communication system, according to a preferred embodiment of the invention. Each endpoint typically comprises a logical entity such as a user and a physical counterpart such as a terminal. Entities connected by a solid black line are communicated using a transaction protocol or broadcast putrocol. The preferred transaction protocol is SIP and the preferred broadcast protocol is SAP. Other entities connected by a broken line are communicated using a suitable protocol known in the art. Architecture 200 is ideal for time-critical communication systems such as public safety dispatch systems.
Architecture 200 is named in session controller 206, group database manager 208, and application layer to allow group communication between at least two endpoints (eg endpoints 240 and 242). It comprises at least one addressable group entity 210. To further facilitate application layer routing, architecture 200 preferably includes an application layer router 204, preferably a registration manager 202 and a SIP proxy. Finally, architecture 200 includes group entity manager 212, parameter resolver 214, at least one individual proxy 216, individual proxy manager 218, multicast address manager 220, policy manager 224, floor controller 230, media. -It is preferable to include a manager 226 and a bandwidth manager 232. Architecture 200 has been simplified for the purpose of exemplifying the present invention. However, those skilled in the art will appreciate that architecture 200 may include multiple of each of the exemplary entities, depending on the size of the system.
Architecture 200 is configured independently of the underlying network and air interfaces and relies on entities such as Bandwidth Manager 232 for network-specified functionality.
As shown in Figure 3, architecture 200 includes session signaling layer 304, session service layer 306, and radio access network (RAN). Network) It is summarized in three layers of layer 308. Session signaling layer 304 terminates session control signaling such as SIP, SAP, and SDP, which are used in combination to start, modify, and terminate a session. The session signaling layer 304 also makes a request to the session service layer 306 and receives an event such as lack of bandwidth from the session service layer 306. Session service layer 306 provides session services such as session interactions for priority and preferential use, as well as for features such as critical users. Session service layer 306 also enforces system policies such as allowing users or groups to make certain types of calls or use a certain amount of bandwidth, and further end. Provide in-session services such as floor control or media management services (eg, transcoding) directly to endpoints such as point 302. RAN layer 308 is SAM (Scalable Adaptive Modulation) Network designation to recognize the execution of underlying wire lines and wireless networks such as Modulation)) 310 and Wireless Local Area Network (WLAN) 312 and to support session service layer 306. Provides functionality. This functionality includes bandwidth management for various wired and wireless links, as well as terminal location management in the system.
The hierarchy diagram 300 is advantageous in that each layer is changed independently of the other layers. For example, if another call control protocol is desired, the session signaling layer 304 is modified without affecting the other layers. Moreover, this hierarchical treatment allows Architecture 200 to support a variety of air interfaces and mobility schemes without affecting session services or session signaling.
FIG. 4 shows the hierarchy diagram 400 of architecture 200 and the assignment of architecture 200 components to various layers. Registration manager 202, group database manager 208, group entity 210, and individual proxy 216 are assigned to session signaling layer 402. Session controller 206, media manager 226, and floor controller 230 are assigned to session service layer 404, and bandwidth manager 232 is assigned to RAN layer 406. As described in more detail below, the interface between the session controller 206 and the individual proxies 216, group entity 210, and bandwidth manager 232 is for systems that use different RANs or different session signaling protocols. Provides flexibility to adapt. In addition, the hierarchical treatment maintains a standard SIP transaction model in terms of endpoints, thereby simplifying interaction with both dispatched and non-dispatched endpoints and future SIP standards. And enable better use of the product.
Architecture 200 preferably supports two types of session setup methods, confirmed and unconfirmed. In an unconfirmed session setup, session notifications to endpoints are not acknowledged, providing better scalability for large groups. Therefore, all unconfirmed session setups are automatically performed by the target terminal without human intervention and without giving the target user the opportunity to decline the session or indicate which terminal they want to use. It is preferable to be accepted. Unidentified session setups are preferably used, for example, for mission-critical group dispatch sessions, because these sessions typically need to be up and running within hundreds of milliseconds. , The session notification will be broadcast to the group.
Confirmation session setup is used when expecting or requesting a response from all target users or terminals. In this type of session setup, for example, the session initiator can say that the target endpoint is actually in session, the session is directed only to the terminal where the user is, or the target endpoint is media. Used when you want to ensure that you are ready to receive. The session setup can be a combination of confirmed and unconfirmed, where the majority of session invitations are ideally unconfirmed, and only a few strategic or necessary users receive confirmed session invitations.
Preferred embodiments of each of the entities shown in FIG. 2 include their preferred functionality and are described below. Each entity preferably includes a receiver that receives information in a communication system, a transmitter that transmits information in a communication network, and a processor that allows the entity to perform various functions.
Each endpoint in the system, eg, endpoints 240, 242, and 246, has its own user and terminal binding, and each terminal has a minimum of PTT functionality to allow communication with the floor controller 230. It is preferred to be a dispatch terminal that has performance, can join groups, and can exchange media and control (SAP) via IP multicast. On the contrary, the non-dispatch terminal cannot perform one or more of the above three functions. The endpoints are preferably the SIP User Agent Client (UAC) and the SIP User Agent Server (UAS: User Agent). It has both Sever) and allows the endpoint to interact with the communication system to set up, modify, and terminate either a group-oriented or individual-oriented session, when the group-oriented session goes into a group. An individual-oriented session is an invitation to at least one individual endpoint, eg, point-to-point. The endpoint must first be registered with the system for outgoing or incoming calls. The SIP REGISTER method is used because SIP signaling is preferably utilized for all session control signaling, and all SIP REGISTER requests are preferably sent to Registration Manager 202. If the endpoint wishes to become a member of the group, it must join the group using the AFFILIATE method according to the invention, and all join requests are preferably sent to the group database manager 208.
The endpoint is preferably configured to receive SAP announcements to inform the endpoint of the addition and removal of sessions within the context of the group, during which the endpoint is the media for a particular session. -It is preferable to interact directly with the floor controller 203 for the purpose of controlling the source for the stream. The protocol used to interact with the floor controller is specified in SDP as part of SIP and SAP session signaling.
Focusing on session controller 206, for example, in a multizone system, there may be many session controllers, which are system resources such as radio and wire line bandwidth, endpoints. Maintains state for all sessions in the control area, depending on endpoint resources such as whether is currently participating in another session, and factors such as target endpoint performance. Session controller 206 is responsible for deciding whether the requested multimedia session is established and works with bandwidth manager 232 to ensure bandwidth and is appropriate for a given session. Ensuring quality of service (QoS). Session controller 206 also works with parameter resolver 214 to determine the corresponding set of session parameters that can be used during an accepted session.
The session controller 206 is preferably the only entity in the system that can recognize all sessions and participants in all sessions. Therefore, it is preferable to use information such as important users to determine whether important users are valid or not. That way, if a critical user is not valid, the session will be queued. Further, the session controller 206 may determine to pull an important user out of the lower priority session and place that user in another higher priority session. In addition, session controller 206 can support any number of sessions from either Group Database Manager 208 or Registration Manager 202 at the same time, and therefore whether or not to enter the session being set up. It is preferable to recognize.
Focusing on group entity 210, it is preferably a specialized SIP entity that combines SIP UAC, SIP UAS, and optionally the SAP session directory into a single entity. The functionality of SIP UAC and SIP UAS gives you single-point control over group communication, and the functionality of the SAP directory improves scalability and performance.
Each group entity is named and addressable at the application layer so that endpoints can send SIP signaling to the group's associated group entities to set up a session with the group. .. This feature distinguishes the invention from the conventional server model described in connection with FIG. 1, and the server responsible for group communication communicates with the network layer.
Upon receiving the session request, the group entity 210 determines the set of endpoints to pull into the session based on the group enrollment information from the group database manager 208, and all to the group members along with the request to set up the session. It is preferably configured to send the requested session parameters and performance of the session controller 206. When session controller 206 grants the request, group entity 210 uses a session announcement protocol such as SIP INVITE for confirmed session setup or multicast SAP announcement for unconfirmed session setup. Signal session setup to endpoints subscribed through.
Focusing on the individual proxy 216, it allows access to the underlying session controller 206 when an individualized session (eg point-to-point) is set up between at least two endpoints. It is preferably a "stateful" SIP proxy that represents the signaling point of the control to make. Each individual proxy 216 is instantiated by the individual proxy manager 218 on behalf of the requested session and has a life cycle equal to the session. The individual proxy 216 must insert itself into a set of SIP routes for individual oriented sessions to ensure that all session control signaling goes through the individual proxy 216 as handled by the underlying session controller 206. It doesn't become. Most important for the rest of the system, especially for the endpoint, is to ensure that SIP signaling is sent between terminals even if the individual proxies 216 indicate that they are unable to modify the SDP or advance the session. It is to be seen. This allows for compliance with SIP standards and, possibly, better compatibility with standard SIP equipment.
During operation, the individual proxy 216 blocks SIP INVITE messages from the initiating endpoint's UAC and determines which endpoint is involved in the session based on the destination and system policy information identified by INVITE. Preferably determined. Different policies may specify that the user is called on all of its terminals, on its mobile terminal, or only on the terminal specified in the SIP session setup request. Once a list of endpoints is selected, it is preferred that the individual proxies 216 determine a preferred list of performance useful for the session. This information is sent to session controller 206 with a list of requested session participants. Given a session, the individual proxy 216 sends a SIP session INVITE message to all intended endpoints and the session is set up. In addition, the individual proxy 216 SIPs to be invisible to endpoints during the session. Fill the FROM header with the address of the session starter instead of its own address.
As mentioned above, all individualized session requests are like system resources, endpoint resources, and performance effectiveness, or authentication, authorization, and access policies required to handle session traffic. It is blocked by a separate proxy 216 that interacts with session controller 206 to determine whether a session is established or rejected depending on factors that contain other parameters. Individual proxy 216 sends information about the requested session to session controller 206, as described by the SIP request payload. This information is usually in the form of SDP packets. This interaction with session controller 206 causes individual proxy 216 to route the request to the intended receiving endpoint and return the appropriate response to the session initiator. The interaction between the individual proxy 216 and the session controller 206 is IPC (Inter Process). Communications)) It is done via any of several traditional mechanisms such as messaging, RPC messaging, CORBA, RMI, or dedicated interprocess communication means.
When the underlying session controller 206 informs the individual proxy 216 that the session is advanced, that is, the system resources required to handle the requested session are valid, the individual proxy 216 announces that the individual proxy 216 has the updated session. -It is preferable that it functions in the same way as a normal SIP routing proxy except that it rewrites the SDP so that the session controller 206 performs parameter determination (based on available bandwidth, policies, etc.). These updated parameters are returned to the initiating endpoint and the target endpoint using a successful SIP transaction, but both endpoints have begun to be controlled by a third party for session negotiations. I don't know. If the requested session does not currently have resources available, or if session controller 206 determines that one of the endpoints is currently in another session that cannot be interrupted, session controller 206 will use session controller 206. Instruct individual proxies 216 to respond to the initiating endpoint with an appropriate SIP response to reject or queue the request.
Session controller 206 is independent of any request from any endpoint if the network state changes during the connection, or if either party needs to be pulled into another session. It is preferable to be able to instruct the individual proxies 216 to end the session between endpoints at any time. The individual proxy 216 then sends to each endpoint a corresponding SIP BYE request that is formatted to appear as part of the control dialog established between the endpoints. To perform the above functions, the individual proxies 216 may be present in the session starter start route set, or through standard SIP routing rules, the proxy may itself, for example, by appropriate use of the SIP's RECORD-ROUTE header. Must be added to the root set of the dialog. This allows all future SIP requests from any endpoint to be a complementary SIP. The use of the ROUTE header ensures that it is routed through the individual proxy 216. With this standard mechanism, all future SIP requests that could potentially affect the allocation of network resources pass through individual proxies 216 for inspection by the underlying session controller 206.
Focusing on the parameter resolver 214, it is configured to establish at least one set of communication performance common to the endpoints subscribed to a given group. These performances include audio codecs, video codecs, screen size, full duplex, support for multicast, and more. Once the set of group performance for a given group is resolved, it is preferably stored in the database for future use in determining the corresponding session parameters for the session with the given group. Will be done.
FIG. 5 shows method 500 according to the invention, which causes the parameter resolver 214 to generate a set of common communication performance for a particular group. The process is triggered in step 502 by several events, including endpoint registration, enrollment requests, explicit requests to carry out the process, or other means. In step 504, the parameter resolver 214 preferably derives the user list for the group from the appropriate database, and in step 506, the parameter resolver 214 preferably derives the performance for each of the user's terminals from the appropriate database. In step 508, parameter resolver 214 determines if there is at least one set of communication performance common to at least a partial set of user terminals. If the decision is affirmed, in step 510 the parameter resolver 214 generates a common set, and in step 512 to determine the corresponding set of session parameters for the accepted session between group members. The common set is stored, for example, in a suitable database for future use by session controller 206 or group database manager (208). If the decision in step 508 is denied, the parameter resolver 214 preferably produces an error condition in step 514. One possible solution to the error condition is to remove non-essential users from the group so that a common set of session parameters can be formed.
The parameter resolver 214 may perform the steps of Method 500 on the required media or any media. In addition, parameter resolver 214 may perform step 508 in response to transcoding or software download to determine if at least a set of common performance is produced. If transcoding is feasible, common performance and transcoding parameters are preferably stored in the database. If software downloads are feasible, common performance is preferably stored in the database, and suitable software is flagged to be downloaded immediately or during call setup.
When a set of common performances is resolved across the group by any of the effective means described above, these parameters are stored in the database. Otherwise, Method 500 is performed to generate one (or several) sets of common performance for one or more partial sets of group members. Then, when session parameters are requested during call setup, etc., the process will database based on user request, system policy, call type, bandwidth availability, context (eg, emergency), etc. Select the "optimal" set of parameters from the possible sets in. Once the common performance database is established, the common parameters are distributed by the call process function during call setup or by the join function during subscription to reduce the amount of signaling between processes. In addition, these parameters can be written explicitly (eg, audio = IMBE, bitrate = 4.4kbps) or by a given set of logics (eg, A = slow audio only, B = fast audio only, C = slow audio +). Represented by slow video).
A bounce chart exemplifying the execution of a particular system according to the invention in which Parameter Resolver 214 implements Method 500 is shown below. This run is performed by three users, Registration Manager (202), Group (Database) Manager (208), who are registered at Endpoint 1, Endpoint 2, and Endpoint 3 and join Group 1. It also includes the following seven functional steps performed by the entity in Architecture 200 (Figure 2), including the parameter resolver (214).
<tables num="1"><img file="JP4391423B2_D0001.tif" /></tables> Steps 1 to 7 of this execution are as follows. 1. Upon power-up, the group manager who tracks and manages group enrollment is enrolled with the enrollment manager to receive notifications of all endpoint enrollments. 2. When powered up, the endpoint registers its performance (eg codec, screen resolution, etc.) with the registration manager, and the group manager is notified of the existence of each new endpoint and its performance. Since these endpoints have not yet joined any group, there are no parameters to resolve at this point. 3. As each endpoint joins Group 1, a request to recalculate common group parameters is triggered according to Method 500 (Figure 5) in anticipation of a group call. When endpoint 1 is added, it becomes the only group member, so all its performance (A, B, C) is common to the group. When endpoint 2 is added, only performances B and C will be common to group members. When endpoint 3 is added, only performance C becomes common to group members. 4. When endpoint 1 is re-registered with the new performance, only performance D becomes common to group members. 5. The endpoint initiates the call by sending a SIP INVITE message to Group 1. 6. Group 1 requests the current common call parameter (D in this example) from the group manager. 7. Call parameters are distributed to various endpoints as part of call setup signaling.
Turning to Registration Manager 202, it is preferably the modified SIP registry, representing a repository containing information about users, terminal endpoints, and bindings between them. The registration manager 202 is preferably configured to register both dispatched and non-dispatched devices. Registration Manager 202 is preferably configured to perform standard SIP registry functions, including handling SIP REGISTER requests to register endpoints (user / terminal bindings) on the system. SIP requests may be queried by SIP proxy 204 to determine possible destinations to be routed. For example, it is preferred that the SIP proxy 204 supplies the username and the registration manager 202 responds with a list of terminal addresses in which the user is registered.
In addition to implementing the standard SIP registry features described above, the Registration Manager 202 is preferably configured to maintain the media performance of each terminal endpoint and optionally the information describing the user profile. These terminal performances may be sent, for example, as an extension to a standard REGISTER request, describing attributes such as screen size, input / output performance, and valid codecs. Registration manager 202 is preferably configured to notify group database manager 208 of each successful registration or re-registration request it processes.
Turning to Group Database Manager 208, it represents a repository containing information about the various group contexts provided within the system (ie, group voices, videos, and data). Group database manager 208 tracks group member enrollment for each group in the system, preferably processing AFFILIATE requests from endpoints to enroll in one or more groups. When one member of the group sends, all members will receive the media. Group Database Manager 208 provides system provisioning of consent for specific users to join a specific group, compatibility with the communication performance of all other endpoints to which the user's terminal has already joined the group. Allow or deny subscription based on factors such as whether there is, that is, it can be resolved and whether it has communication performance. Group database manager 208 is also preferably the keeper of system policies for individual groups such as priorities, allowed session parameters, session time limits, and so on.
Session parameters are preferably calculated in advance because the resolution of session parameters is potentially complex and time consuming for the group. Therefore, the group database manager 208 preferably stores a valid set of resolved session parameters for each group, calculated by the parameter resolver. When a group member joins, the group database manager 208 updates the stored set (or several sets) of valid session parameters for the group. A larger number of sets of session parameters may be stored for different categories of usage scenarios. For example, there may be a set specifically for high quality video, or there may be a set for audio.
FIG. 6 shows method 600 according to the invention, with steps performed by group database manager 208 to enroll the endpoint into a particular group. Method 600 contains a subscription request according to the invention, preferably a first message from the requester (eg, an endpoint or group entity impersonating a non-dispatched terminal) by application layer routing, which is SIP. It includes step 602 to receive, step 604 to generate a response to the above-mentioned subscription request according to the type of subscription request received, and step 606 to communicate the response to the subscription request to the request side by application layer routing.
AFFILIATE requests are sent from SIP UAC, 1) a list of one or more user groups wishing to join through the use of the Associate extension header in accordance with the present invention, 2) one or more groups to join a given group. It may include a query for a list of Contact headers or 3) a list of groups that can be joined. Upon receiving the AFIILIATE request, Group Database Manager 208 also generates one of several possible SIP responses to review and interpret the request, for example Sucess, Partial Success, Deny and Error. It is preferable that the configuration is as follows.
Specifically, if the request identifies at least one group through the Associate header and at least one Contact header, the response, if applicable, will be accompanied by the multicast address at which each group will be announced. Each Contact address in contains the group to which it is currently subscribed. If the request does not include an Associate header but contains at least one Contact header, the response includes a list of groups to which each identified Contact address subscribes. If the request contains at least one Associate header but no Contact header, the response will list all Contact addresses for a given user (identified by the To header) currently subscribed to the identified group. Including. In addition, if the request does not include Associate and Contact header information, the response will be joined by any user of the identified endpoint (eg, all Contact addresses) (eg, identified by the request's To header). Includes a list of all groups you are doing.
The following preferred extensions to SIP may be used to enable the functionality of the subscription described above. The AFFILIATE REQUEST message is generated by SIP UAC to associate a user with a group. The AFFILIATE REQUEST message must contain information that allows the user to be associated with the group name. The preferred format of the AFFILIATE REQUEST message is shown below. According to the general SIP header format for Request messages (ie, including headers Via, From, To, Call-ID, Cseq, Expires), it also includes AFFILIATE headers and Associate headers according to the invention.
<tables num="2"><img file="JP4391423B2_D0002.tif" /></tables> In the example below, the AFFILIATE request is found in a hypothetical system where users are subscribed to a large number of groups. In this example, the recorded address (AoR: Address of Record) is such that the user "m.korus" groups his contact endpoint address "korus@ht2137.mot.com" with the group "casper_team" and " Indicates that you are trying to join "tech_team". Upon successful enrollment, the user can join a session for these groups at the enrolled contact endpoint. The request is preferably in the following format:
<tables num="3"><img file="JP4391423B2_D0003.tif" /></tables> The user can also query the subscription server (ie, Group Database Manager 208) by sending an AFFILIATION request with the desired combination of Associate or Contact headers instead of both. For example, to get a list of all contact addresses for a given user who is subscribed to a given group. The request is preferably in the following format:
<tables num="4"><img file="JP4391423B2_D0004.tif" /></tables>In addition, a request with the following preferred format will generate a response containing a list of all subscribed groups for a particular user.
<tables num="5"><img file="JP4391423B2_D0005.tif" /></tables> Similar to SIP RESPONSE for SIP REGISTER messages, SIP RESPONSE messages are required to complete the AFFILIATE REQUET transaction. The content of the AFFILIATE response includes Accept / Deny for each group that the user requests to join, and a list of multicast addresses (for control) or unicast or multicast addresses (for media) assigned to each group. But it may be. The preferred format for AFFILIATE responses is
<tables num="6"><img file="JP4391423B2_D0006.tif" /></tables>Is.
For all groups that are denied enrollment, the expiration date is preferably set to zero, and an alternative response status is used to indicate to the requester that some requested enrollments have been rejected. You may. Like SIP REGISTER requests and their responses, AFFILIATE request response messages are preferably returned to the requester according to the route specified by the list of Via headers for the received request. The Contact header is preferably used only to identify the join binding in the request for maximum consistency with the SIP REGISTER request semantics.
Turning to floor controller 230, it is responsible for managing access to the associated media stream or multiple streams. The floor controller 230 processes the request from the endpoint to the floor and arbitrates to determine which endpoints can source media on the media channel. Floor controller 230 provides separate arbitration for each media stream, which is based on rules or policies in the system. When the floor controller 230 gives a floor to a particular endpoint, the bandwidth allocation is shifted to the new endpoint, if necessary, by preferably notifying the bandwidth manager 232 of the change. .. If the session is controlled by a hang time on the media, the floor controller 230 preferably informs the session controller 206 when the hang time will expire.
Turning to SIP proxy 204, it is a standard SIP proxy that directs control and informational messages to target logical entities according to the relevance maintained by Registration Manager 202.
Turning to group entity manager 212, it is preferably responsible for creating, maintaining, and disabling each group entity 210. Preferably configured as a dedicated SIP proxy that routes SIP requests to the appropriate group entity 210. All requests for establishing a new session in the group context are routed through the group entity manager 212. Group entity manager 212 creates an instance of group entity 210 for a group when a session is set up when the group entity does not exist. Future session setup signaling to the group is preferably routed to group entity 210 by group entity manager 212.
Turning to the individual proxy manager 218, it is preferably responsible for creating, maintaining, and disabling each individual proxy 216. Preferably configured as a dedicated SIP proxy that routes SIP requests to the appropriate individual proxy 216. All requests for establishing a new session individually, eg, in a point-to-point context, are routed through the individual proxy manager 218. The individual proxy manager 218 creates an instance of the individual proxy 216 for the endpoint when the session is set up.
Turning to the multicast address manager 220, it manages a pool of multicast addresses and makes both semi-permanent and temporary allocations. The multicast address manager 220 preferably has the ability to monitor the type and length of use of the assigned address to determine how, when and how much it will be used. This allows the manager 220 to reclaim addresses that have not been used for some time and prioritize reclaiming used addresses if the pool becomes empty.
Therefore, the multicast address manager 1) temporarily or semi-permanently supplies the multicast address from the pool when requested by external processing, and 2) restores the address to the pool when returned by external processing. 3) Statistics on when and for what purpose the address is used, 4) unused beyond a certain threshold time allotted to fill the pool and keep the router state minimized. Reclaim semi-permanent addresses, 5) reclaim unused and non-timed addresses when the pool is empty, 6) stream priority, stream type when the pool is empty , Reclaiming actively used addresses based on stream usage history, etc. 7) Configured to perform the function of aggregating media and control streams that utilize multiple multicast addresses into a single address. Will be done. Functions 4-7 may optionally require authorization from the system.
FIG. 7 shows method 700 according to the invention of a multicast address manager 220 for managing a pool of available multicast addresses. Method 700 includes step 702 to generate a pool of available multicast addresses, step 704 to receive requests for multicast addresses, and step 706 to allocate at least the first restricted multicast address for use. Step 708 to monitor the use of the above-mentioned assigned multicast address, and reclaim the above-mentioned assigned multicast address when it is detected that the first condition is met according to the above-mentioned monitoring. Step 710, which returns the above-mentioned assigned multicast address to its original position in the pool of available multicast addresses.
Below is a bounce chart showing the execution of a particular system according to the invention, in which the multicast address manager 220 implements method 700. This run is an architecture 200 (Figure) that includes a SIP endpoint, a group (database) manager (208), a group (entity) gateway (210), a session controller (206), and a (multicast) address manager (220). It includes the following six functional steps performed by the entity in 2).
<tables num="7"><img file="JP4391423B2_D0007.tif" /></tables> Steps 1 to 6 of this execution are as follows. 1. When creating a group, the group manager requests a multicast address for a semi-permanent allocation. The address manager returns "multicast address 1". 2. The endpoint joins the group. The response informs the endpoint of "multicast address 1" to which the endpoint will participate. 3. The endpoint initiates a session on two media streams (eg, audio and video) by sending an INVITE to the group gateway. The group gateway asks the session controller for session permission and requests resources. The session controller recognizes that only one of the media streams is assigned a multicast address, requests an additional address from the address manager, and is assigned "multicast address 2". The session controller then informs the address manager that "multicast address 1" and "multicast address 2" are in use. 4. "Multicast address 2" is returned to the group gateway, creating a response indicating that "multicast address 1" and "multicast address 2" should be used for the session and back to the source. .. The endpoint begins procuring the first media (eg, voice) at the already participating "multicast address 1". At the same time, the endpoint joins "multicast address 2" and begins procuring a second medium (eg, video). 5. At the end of the session, the endpoint sends a BYE message. This causes the session controller to free "multicast address 2" into the pool (because it was a temporary allocation) and inform the address manager that "multicast address 1" is idle again. 6. If "Multicast Address 1" has not been used for some time, the timer expires, the address manager reclaims the allocation, and forces any endpoint that is part of the tree. Be separated.
In this execution, the session controller is known as a control point for requesting and releasing short-term addresses, but other entities may perform this function. According to the present invention, an extension to the standard SDP semantics is provided so that the media channel is assigned by the recipient of the SIP session invitation. The following embodiments of the present invention use these extensions to perform a method of assigning at least one address (eg, a multicast address) for media exchange in a session between endpoints.
SDP packets typically identify the session, media type, channel port number, channel IP address, and media encoding. For example, the following SDP packet uses H332 floor control to identify a multicast audio session on the associated media control channel.
<tables num="8"><img file="JP4391423B2_D0008.tif" /></tables> The "m =" field of the SDP packet identifies the media type to be used in the session and the port on which the media is received. The "c =" field of the SDP packet identifies the channel (IP address) to be used for a particular media type. The channel identifier is applicable to all media streams or individual media types in SDP packets. In the latter case, the media type identifier is followed by the corresponding channel identifier.
However, the packet structure described above cannot be used when the endpoint requests a new session with a large number of parties in order to procure multicast media for the session among all parties. In this case, some form of multicast channel allocation coordination is required that is centralized by some process in the system infrastructure. To address this shortcoming, standard SDP packets are preferably reconfigured for such tuning of the multicast channel as described below in accordance with the present invention.
It is preferable that the SDP packet of the session start request can still identify the type of media carried out by the session. Usually, a channel identifier that identifies an empty address (eg, c = IN IP40.0.0.0) indicates that the corresponding media stream must wait. The combination of the corresponding media type that identifies the null port identifier and the channel identifier semantic provides a means to signal the coordinating entity that an appropriate address needs to be assigned to the session initiator. The session initiator preferably creates the following SDP packet to describe the session to be created.
<tables num="9"><img file="JP4391423B2_D0009.tif" /></tables> The session attribute (a = type: H332) signals the recipient that the requested session requires H.332 floor control. Media identifiers and channel identifiers have null port and address assignments, respectively. This signals the recipient that the corresponding multicast media channel and port and the unicast (or multicast) control channel and port should be assigned. The recipient coordinates with the corresponding system-level process to determine the address and port assignments to be assigned to this session and returns modified SDP packets containing the assigned addresses and ports. The initiator accepts the modified SDP packet on the newly assigned media channel.
Instead, using the extension mechanism defined in RFC2327, new session level attributes are defined, how addresses are assigned to multiparty sessions, and used on a given media stream. Provides more explicit control over the type of messaging (eg, unicast vs. multicast). The following is an embodiment of the present invention in which SDP packets are enhanced with extended attributes for media address allocation.
<tables num="10"><img file="JP4391423B2_D0010.tif" /></tables> In this example, the session level attribute (x_multiparty) is used to inform the media control entity that it will assign a multicast address to all unassigned media streams. However, the session level attribute (x_peer2peer) tells the media controller that the floor control entity should be assigned a unicast address. Various session and stream level attributes allow the system to assign any combination of multicast and unicast streams.
Finally, the policy money directed attention to the manager 224. Due to the nature of the various uses of multimedia systems in the future by consumers, the system must have a lot of flexibility built into it. By creating a clear and manageable set of policies that control system behavior, consumers can adapt their systems without the need for special software builds. The policy manager is preferably configured to control access to the policy database where various policies are stored.
As mentioned above, the endpoint in Architecture 200 (FIG. 2) is preferably the dispatch endpoint. However, if at least one endpoint comprises a non-dispatched terminal, one embodiment of the invention provides a method of facilitating a session with a non-dispatched terminal. FIG. 8 is a flow chart showing a method 800 for facilitating communication with a non-dispatched terminal. In step 802, a first message is received that contains information including a request for a session between a first endpoint with a non-dispatched terminal and at least one other endpoint. In step 804, a first endpoint with a non-dispatched terminal is detected in response to the non-dispatched terminal being unable to perform at least one function. Finally, in step 806, at least one service entity replaces the first endpoint to perform at least one function to facilitate sessions with non-dispatched endpoints.
Preferably, the group entity 210 receives the first message and detects that the non-dispatched device is about to make a group call. For example, when a non-dispatched terminal sends an INVITE to group entity 210, the group entity lacks a floor control profile in INVITE SDP, lacks a dedicated dispatch header, lacks registration and / or join records, or OPTIONS. It can detect that it is not a possible dispatch by any one of the means indicated by the performance queried by the command.
Using these means, the group entity detects that the endpoint is incapable of joining the group. In this case, the group entity automatically joins the endpoint. The group entity preferably produces signaling specifically targeted at the standard device that directs the media of the standard device to the media manager. This signaling has different session parameters than those distributed to dispatchable endpoints.
The group entity may also detect that the terminal is unable to communicate with the floor controller 230. In this case, the endpoint directs the media to a full-duplex device, eg, a media manager configured to impose arbitrated floor control on the non-dispatched endpoint. , Group entities preferably generate signaling to non-dispatched endpoints. The media manager preferably generates a floor request to the floor controller when the audio is procured by a non-dispatched endpoint. Optionally, tones or other audio information is sent to the user trying to speak when they have a floor that prevents someone else from speaking anymore. Audio information is used for this purpose instead of explicit signaling, as blocking the speaker is not supported by SIP signaling.
The group entity detects that the terminal cannot exchange media via IP multicast. In this case, the group entity preferably generates signaling to non-dispatched endpoints, and the endpoints are preferably configured for media managers to bridge unicast and multicast media streams. Try to orient the media. For example, when a non-dispatched device has a floor, its unicast media is retransmitted by the media manager over a common multicast channel used by dispatch terminals. When a dispatch terminal has a floor, its multicast media is replicated and sent to non-dispatched devices using unicast. In addition, if the non-dispatched device is multicast capable, the device is directed to listen for normal multicast traffic instead of generating another unicast stream. However, in the incoming path, the standard equipment preferably does not transmit over the multicast channel as the transmission is not trained by the floor controller.
A bounce chart exemplifying a particular system execution according to the invention that allows communication with a non-dispatched terminal by Method 800 is shown below. This run is a standard (ie, non-dispatched) terminal, two dispatched terminals joined to a group, a group (entity) gateway (210), a group (database) manager (208), a policy manager (224), a media manager. It includes the following nine functional steps performed by entities in Architecture 200 (Figure 2), including a manager (226) and a floor controller (230).
<tables num="11"><img file="JP4391423B2_D0011.tif" /></tables>1. A standard SIP device initiates a group call by addressing the group with a SIP address. 2. Optionally, the group gateway queries the device for its performance using standard SIP procedures. 3. Optionally, allow the group gateway and the initiator to make that decision partly based on the system's policies. In addition, the group manager may choose to automatically join this endpoint to the group and be part of all future group calls. When this enrollment is enforced, it imposes more restrictions than the group members provided by the user. 4. SIP signaling is returned to the starter along with the address of the media manager (for incoming media) and session parameters (codec, bitrate, etc.). Group dispatch session parameters are sent to successful group members using broadcast announcements. In addition, the media manager is programmed to translate the beginnings of all talk spurts from this user into requests for floor control and between unicast and multicast media. 5. The initiator begins speaking and sends a voice packet to the media manager. The media manager detects the presence of audio and generates a request to the floor. The media is multicast to normal group members. When the starter finishes speaking, silence releases the floor. 6. Normal group members request floors using explicit floor control signaling. 7. Given the floor, the user begins sending voice over multicast. Multicast media is sent via unicast to standard endpoints. 8. If the standard endpoint tries to speak over the current speaker, the talk spurt will regenerate the request to the floor and be rejected. This rejection is indicated by sending a short burst of tone or other audio data to the endpoint to make it unspeakable. 9. The current floor holder releases the PTT and gives up the floor.
A summary of how a communication session according to the invention exemplified by Architecture 200 is preferably set up is presented. Endpoint 240 sends SIP INVITE to Application Layer Router 204 and forwards it to either Group Entity Manager 212 or Individual Proxy Manager 218 based on the subdomain identified by the destination address in the INVITE To header. Will be done. When the group entity manager 212 receives an INVITE, it instantiates a new group entity 210 for the group if none exist. Future session setup signaling for that group will be routed to group entity 210. When the individual proxy manager 218 receives the INVITE, it instantiates a new individual proxy 216 for the new individual session.
The individual proxy 216 or group entity 210 communicates with session controller 206 to determine if a session is set up. Upon accepting a session, the session controller informs the group entity or individual of the information needed to proceed with the session. When the group entity receives the information, the group entity generates session signaling to the endpoints involved in the session. Session signaling takes the form of SIP INVITE messages for confirmed group sessions (or individual sessions) or SAP announcements for unconfirmed group sessions. The source indicated by the From header of INVITE is the group name for the group session (session starter for the individual session). Group members receive SAP announcements on the multicast channel set up for the group, and group members know and join the multicast channel while joining the group.
Once the session is in place, the endpoint sends floor control signaling to the floor controller 230 to request a floor. The floor controller 230 uses the rules and policies for that session to stream to determine whether to give a floor. Finally, the session is described in US Patent Application No. 10/10 / 334,521, entitled "METHOD AND SYSTEM FOR GROUP COMMUNICATIONS," filed at the same time as this application. It will be changed and terminated according to.
The present invention has been described with certain embodiments, but further advantages and modifications will be facilitated by those skilled in the art. Thus, the invention is not limited in its broad sense to the specific details illustrated and described, the representative device, and the exemplary examples. Various changes, changes, and variations will be apparent to those skilled in the art in light of the above description. Accordingly, the present invention is not limited by the above description and includes all modifications, modifications and variations in accordance with the technical ideas and scope of the appended claims.
<figref num="1">A simple block diagram of the prior art call model architecture.</figref><figref num="2">Block diagram of the call model architecture according to the present invention.</figref><figref num="3">The hierarchical diagram of the call model architecture according to the present invention shown in FIG.</figref><figref num="4">The hierarchical diagram of the call model architecture according to the present invention shown in FIG.</figref><figref num="5">The figure which shows the method by this invention which generates a set of common communication performance for a group.</figref><figref num="6">The figure which shows the method by this invention which makes an endpoint join a group.</figref><figref num="7">The figure which shows the method according to this invention which manages a pool of multicast addresses.</figref><figref num="8">The figure which shows the method according to this invention which enables communication with the endpoint which comprises a non-dispatch terminal.</figref>
Every citation, both ways
| Document | Relation | Office |
|---|---|---|
| JP2001346267A | Cites | Japan |
| JP08292923A | Cites | Japan |
| JP63211940A | Cites | Japan |
| JP09284210A | Cites | Japan |
| JP61135269A | Cites | Japan |
| JP10154980A | Cites | Japan |
| WO02093953A1 | Cites | World Intellectual Property Organization (WIPO) |
| JP2001339592A | Cites | Japan |
| JP04104567A | Cites | Japan |
| JP2001145136A | Cites | Japan |
| JP10242963A | Cites | Japan |
| US20020073208A1 | Cites | United States of America |
17 members in 8 offices
Priority claims9
| Document | Office | Kind | Date |
|---|---|---|---|
| 10334577 | United States of America | – | |
| 33457702 | United States of America | A | |
| 33457702 | United States of America | A | |
| 0340696 | United States of America | W | |
| 0340696 | United States of America | W | |
| 2002334577 | – | – | – |
| 2003040696 | – | – | – |
| US20020334577 | – | – | – |
| WO2003US40696 | – | – | – |
Members17
| Document | Office | Kind | |
|---|---|---|---|
| US2004133683A1 | United States of America | A1 | |
| CA2511937A1 | Canada | A1 | |
| WO2004062176A2 | World Intellectual Property Organization (WIPO) | A2 | |
| AU2003301156A1 | Australia | A1 | |
| AU2003301156A8 | Australia | A8 | |
| TW200420101A | Taiwan Province of China | A | |
| WO2004062176A3 | World Intellectual Property Organization (WIPO) | A3 | |
| EP1584043A2 | European Patent Office (EPO) | A2 | |
| TWI242357B | Taiwan Province of China | B | |
| JP2006512857A | Japan | A | |
| US7366780B2 | United States of America | B2 | |
| US2008168172A1 | United States of America | A1 | |
| JP4391423B2This record | Japan | B2 | |
| CA2511937C | Canada | C | |
| IL169234A | Israel | A | |
| EP1584043A4 | European Patent Office (EPO) | A4 | |
| US8412829B2 | United States of America | B2 |
33 legal events, as the office reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | |
|---|---|---|
| Cancellation because of no payment of annual feesLAPS | LAPS | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Written notification of registration of transferJAPANESE INTERMEDIATE CODE: R350R350 | R350 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Written request for registration of change of domicileJAPANESE INTERMEDIATE CODE: R313531S531 | S531 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Renewal fee payment (event date is renewal date of database)FPAY | FPAY | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Renewal fee payment (event date is renewal date of database)FPAY | FPAY | |
| Renewal fee payment (event date is renewal date of database)FPAY | FPAY | |
| Written notification of registration of transferJAPANESE INTERMEDIATE CODE: R350R350 | R350 | |
| Written request for registration of change of nameJAPANESE INTERMEDIATE CODE: R313533S533 | S533 | |
| Renewal fee payment (event date is renewal date of database)FPAY | FPAY | |
| Certificate of patent or registration of utility modelJAPANESE INTERMEDIATE CODE: R150R150 | R150 | |
| Certificate of patent or registration of utility modelJAPANESE INTERMEDIATE CODE: R150R150 | R150 | |
| First payment of annual fees (during grant procedure)JAPANESE INTERMEDIATE CODE: A61A61 | A61 | |
| Written decision to grant a patent or to grant a registration (utility model)JAPANESE INTERMEDIATE CODE: A01A01 | A01 | |
| Written decision to grant a patent or to grant a registration (utility model)JAPANESE INTERMEDIATE CODE: A01A01 | A01 | |
| Decision of grant or rejection writtenTRDD | TRDD | |
| Request for written amendment filedJAPANESE INTERMEDIATE CODE: A523A521 | A521 | |
| Written permission of extension of timeJAPANESE INTERMEDIATE CODE: A602A602 | A602 | |
| Written request for extension of timeJAPANESE INTERMEDIATE CODE: A601A601 | A601 | |
| Notification of reasons for refusalJAPANESE INTERMEDIATE CODE: A131A131 | A131 | |
| Request for written amendment filedJAPANESE INTERMEDIATE CODE: A523A521 | A521 | |
| Written permission of extension of timeJAPANESE INTERMEDIATE CODE: A602A602 | A602 | |
| Written request for extension of timeJAPANESE INTERMEDIATE CODE: A601A601 | A601 | |
| Notification of reasons for refusalJAPANESE INTERMEDIATE CODE: A131A131 | A131 | |
| Report on retrievalJAPANESE INTERMEDIATE CODE: A971007A977 | A977 |
Numbers
- Publication
- 4391423
- Publication, DOCDB
- 4391423
- Publication, EPODOC
- JP4391423B
- Application
- 2004565604
- Application, DOCDB
- 2004565604
- Application, EPODOC
- JP20040565604
Titles2
- Japanese
- エンド・ポイント間のセッションを制御および管理すること
- English
- Controlling and managing sessions between endpoints
Classification
- CPC, 13
- H04L65/1069
- H04L67/14
- H04L69/329
- H04L61/4535
- H04L61/5069
- H04L65/1104
- H04L65/65
- H04L67/63
- H04L65/756
- Y02E60/36
- Y02E60/32
- H04L9/40
- H04L65/1101
- IPC, 6
- H04M3 00
- H04L12 56
- H04L12 18
- H04L29 06
- H04L29 08
- H04L29 12