Abstract:
A multimedia multiparty communication system and method which includes one or more “agents” and one or more “brokers”. Each communication session is managed by a broker which creates and maintains the session. An agent may cause a broker to alter a communication session by entering into “negotiations” with the broker. It is also possible for an agent, through the broker, to enter into negotiations with one or more other agents. Negotiations, between agents and between agents and brokers may consist of any number of exchanged messages (or “offers”), thereby allowing for the dynamic negotiations necessary for effective multimedia multiparty communications.

Description:
TECHNICAL FIELD 
     This invention relates to the building and using of communication services, and more particularly to a protocol for building and using computer based communication services. 
     BACKGROUND OF THE INVENTION 
     The client-server model is currently the most popular model for building and using computer based communication services. The model represents the user of a service as a client that sends requests to, and receives responses from, a server. In a typical client-server architecture, both the client and server are computing facilities, and the request-response pair is implemented through distributed software using method invocation. For an example of how a client-server architecture is implemented through distributed software see: Orfali and Harkey, “Client/Server with Distributed Objects”, Byte Magazine, April, 1995, pp. 151-162. 
     The distributed software client-server architecture is well suited for those applications in which requests and responses are limited and inflexible, such as in those situations where the user and/or server has access to limited computing facilities. For example, the user facility may be a telephone set and the server facility may be a voice conference bridge that simply responds to requests initiated by the user with the telephone set. 
     However, the client-server model is not well-suited for the development of services that involve more extensive interactions. Two services which often involve extensive interactions are multimedia services and multiparty services. Such services include, for example, a user who might want to choose a video conferencing service based on the cost at the time of use. As another example, two users might decide to interact through both voice and video only after they have exchanged several messages. As a further example, a video bridging server might interact with several logging servers before locating one that can store video minutes of a meeting under some set of constraints. In these types of services, interactions between a user and a server, between users, or between servers may take on the form of “negotiations”, a form of interaction to which the client-server architecture does not lend itself. 
     SUMMARY OF THE INVENTION 
     It has been recognized that in order to support a wide range of new communication services, it is highly desirable to have a software framework that permits not only the fixed, negotiations associated with remote procedure calls, but also the dynamic, protracted negotiations associated with peer-to-peer interactions. The present invention provides a software framework that permits dynamic negotiation. 
     In a communication system in accordance with the present invention a communication session involves one or more “agents” and one or more “brokers”. Each communication session is managed by a broker which creates and maintains the session. An agent may cause a broker to alter a communication session by entering into “negotiations” with the broker. It is also possible for an agent, through the broker, to enter into negotiations with one or more other agents. Negotiations, between agents and between agents and brokers may consist of any number of exchanged messages (or “offers”), thereby allowing for the dynamic negotiations necessary for effective multimedia multiparty communications. 
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS 
     FIG. 1 is a block diagram depicting a single broker communication system in accordance with the present invention. 
     FIG. 2 is a block diagram depicting a multiple broker communication system in accordance with the present invention. 
     FIG. 3 is a block diagram depicting how a partial ordering of events is implemented in a preferred embodiment of the present invention. 
     FIG. 4 is a block diagram depicting how a total ordering of events is implemented in a preferred embodiment of the present invention. 
     FIG. 5 is a flowchart depicting how the software modules in a preferred embodiment of the present invention interact. 
    
    
     DETAILED DESCRIPTION 
     The present invention is based upon a “broker-agent” communication model. In the broker-agent model, a negotiation is defined as a sequence of offers, where an offer is a message and the computation that defines its interpretation. The model focuses on relationships among offers, and thus provides means for one to define a negotiation as relations among offers. The relations that form a negotiation description define the parties to the negotiation and the characteristics of the offers exchanged among those parties. 
     In addition to emphasizing relations, the broker-agent model emphasizes party and offer characteristic descriptions. The components of these descriptions are termed attributes. Attributes may be organized by type. For example, one characteristic of an offer is its originator. For a particular offer, the value of this originator attribute may be classified as belonging to type “server”, or the originator attribute may be classified as belonging to type “negotiating party”. 
     Having described the underlying concepts of the broker/agent model, a description of a communication system in accordance with the broker/agent model is presented below. 
     Referring to FIG. 1, there is shown a communication system in accordance with the present invention. The system includes a Context Broker (CB)  102  and three Context Agents (CAs)  104 ,  106  and  108 . For purposes of illustration, the Broker of FIG. 1 is said to be a general purpose computer running broker software, while the Agents of FIG. 1 are each said to be a general purpose computer running agent software. It should be noted, however, that in practice both the Broker and Agents may take any one of many possible forms. For example, the Context Broker may be a telephone network switch that is appropriately configured; while the Context Agent can be a telephone set, or a telephone set interfaced with an agent computer via Dual Tone Frequency Modulation (DTFM) signaling. In any event, each communication session occurring in the system of FIG. 1 is created and maintained (managed) by only one entity, the Context Broker (CB)  102  (although, in general, a given context broker can manage several communication sessions). The Context Agents (CAs)  104 ,  106  and  108  use the Context Broker to establish communication sessions. 
     FIG. 2 shows an alternative broker-agent embodiment in which the communication system of includes two Context Brokers  202  and  204 , and a single Context Agent  206 . As can be seen from the figure, there can be multiple context brokers in a communication system even though each communication session is always managed by one context broker. That is, management of a communication session itself is never distributed, but a context agent can converse with more than one Context Broker for the purpose of participating in multiple communication sessions. 
     At this point, prior to describing the negotiation protocol in detail, it will be helpful to describe an illustrative negotiation with reference to FIG.  1 . In this regard, FIG. 1 will now be assumed to represent a “video on demand” scenario, with Context Agent  108  representing a video server, Context Agent  104  representing a first viewer&#39;s home computer, and Context Agent  106  representing a second viewer&#39;s home computer. It is further assumed that the viewer computers are equipped with the appropriate agent software and are capable of displaying any received video. The Context Broker  102  is assumed to be operated by a network that couples the viewers to the server. 
     Assume that viewer  104  is watching a movie supplied by server  108  (through Broker  102 ) and that viewer  106  enters a request for service. Viewer  106 &#39;s request (sent to Broker  102 ) may be for Movie “X” at time “Y”. Broker  102  may then negotiate with server  108  to see if Movie X is available to be shown to viewer  106  at time Y. The Broker may do this by sending the following sequence of messages (offers) to server  108 : “Do you have Movie X?”, “Can you show it at time Y?”. If the answers from the video server are: “Yes”, “No, but the movie is currently in progress”; then the Broker responds to viewer  106  with an appropriate message such as: “Movie X is available but not at time Y, do you wish to join the movie in progress?”. If the answer from viewer  106  is yes, the Broker adds viewer  106  to the communication session that exists between server  108  and viewer  104 . 
     Moreover, the negotiations between the Broker and the video server may be dynamic. That is, viewer  106  may vary the number and/or type of conditions included in the request. For example, as an alternative to the request described above, viewer  106  may ask for Movie X, at time Y, at a price less than $5.00. In that case, the broker/server negotiation would extend to three inquiries: “Do you have Movie X?”; “Can you show it at time Y?”, “Can you show Movie X for less than $5.00?”. 
     In the above described “video on demand” negotiation, broker  102  negotiated with server  108  on behalf of viewer  106 . As an alternative to the above scenario, viewer  106  may negotiate with server  108  directly, with broker  102  merely acting as a conduit for messages passing between the two viewers. Thus, if viewer  106  requests service, broker  102  establishes a communication link between viewer  106  and server  108 , and thereafter viewer  106  and server  108  negotiate directly with broker  102  merely relaying messages between the two. 
     Having described an illustrative negotiation, the negotiation protocol is now described in detail below. 
     The following list contains the communication session (or “context”) manipulation operations that may be performed during a negotiation. Each operation is a transaction initiated by a Context Agent and directed to a Context Broker. The Context Broker may involve one or more Context Agents in the transaction based on the operation. Since the Context Broker is the manager of a context, the Context Broker ensures closure of all transactions concerning the context. The operations are atomic operations as far as the context is concerned, although each operation may involve many steps. These atomic context operations are used to build more complex transactions needed by some advanced telecommunication services. In the description that follows, each transaction is specified as a method invocation with parameters. Each transaction consists typically of a Transaction_Begin, GenericNegotiate, and Transaction_End steps. The GenericNegotiate step can happen a finite number of times, during which the Context Broker just acts as a conduit between the Context Agents. The terms “member” and “Context Agent” are used interchangeably in the ensuing discussion. 
     1. CreateContext: This transaction is used to create a new context with certain specified attributes. A Context Agent issues a CreateContext_Begin to the Context Broker to create a new context. On successful creation of the context, the Context Broker sends a CreateContext_End to the Context Agent. 
     CreateContext_Begin (NegotiationId, SrcInfo, ContextAttributes) 
     CreateContext_End (NegotiationId, Result, ContextHandle, ContextAttributes) 
     2. DestroyContext: This transaction is used to destroy a context. A Context Agent issues a DestroyContext_Begin to the Context Broker to destroy a context. On successful destruction of the context, the Context Broker sends a DestroyContext_End to the Context Agent. 
     DestroyContext_Begin (NegotiationId, SrcInfo, ContextHandle) 
     DestroyContext_End (NegotiationId, ContextHandle, Result) 
     3. AddMember: This transaction is used to add a new member to the specified context. A Context Agent issues a AddMember_Begin to the Context Broker to add a new member. The Context Broker will send an AddMember_Invite to the Context Agent who is being added. The invited Context Agent can either send a AddMember_End to the Context Broker or prolong the negotiation by sending a GenericNegotiate to the calling member (or any other member of the context) through the Context Broker. The Context Broker does not interpret the GenericNegotiate and just passes it to the right destination member. The Context Broker closes the transaction when the called member sends an AddMember_End (or if the Context Broker coerces some policy requirement based on some finite number of the negotiation steps). This is an example of a peer to peer negotiation between the two intelligent members with the transaction actually governed by a central authority. Since the peer to peer negotiation is general, new services can be built without ever changing the basic context operations. 
     AddMember_Begin (NegotiationId, SrcInfo, ContextHandle, DestInfo) 
     AddMember_Invite (NegotiationId, SrcInfo, ContextHandle) 
     GenericNegotiate (ContextHandle, SrcInfo, DestInfo, NegotiationVal) 
     AddMember_End (NegotiationId, Result, ContextHandle, DestInfo, NegotiationVal) 
     4. DropMember: This transaction is used to drop a member from the context. 
     5. SuspendContextActivity: This transaction is used to suspend the activity of all members in the context. 
     6. ResumeContextActivity: This transaction is used to resume the activity of all members in the context who were previously suspended by SuspendContextActivity. 
     7. SuspendMemberActivity: This transaction is used to suspend the activity of the specified member in the context. 
     8. ResumeMemberActivity: This transaction is used to resume the activity of the specified member in the context who was previously suspended by SuspendMemberActivity. 
     9. SetOperation: This transaction is used to create/destroy/manipulate a set within the context. A set describes a notion of association between a subset of the context members. The maximum number of sets in a context is the power set of the context members. The set is usually used to model finer collaborations among the context members. 
     10. SetContextAttributes: This transaction is used to set the attributes of the context. 
     The protocol described above is a generic multiparty protocol. Race conditions are possible in the multiparty protocol if there is out of band communication. What follows is a description of the race condition ordering schemes and solutions that are supported by the present invention. 
     The Context Broker/Context Agent protocol supports two event ordering schemes: partial ordering and total ordering. The total ordering mechanism is more expensive than the partial ordering mechanism, although it will alleviate all race conditions in the protocol. Race conditions in the protocol can arise if entities involved in the negotiation attempt to have out of band communication based on a transaction termination (here out of band means communication bypassing the Context Broker). Partial ordering and total ordering are illustrated in FIGS.  3  and  4 , respectively. Both figures depict a multiparty communication involving members (Context Agents) A, B and C who wish to add a new member, D. 
     Referring to FIG. 3, there is shown a multiparty communication session in accordance with the present invention. A Context Broker  302  is said to manage the communication session (Context X), which includes Context Agents  304 ,  306  and  308 . Partial ordering of events will be considered for a scenario in which Agent  304  desires to add a new agent  310  (D). 
     After negotiations, the new member  310  sends the AddMember_End to the Context Broker  302  informing the Context Broker of its intent to commit the AddMember transaction. The Context Broker then has to broadcast the AddMember_Event to the other members ( 304 ,  306  and  308 ) of the Context to inform them that a new member has been added to Context X. Meanwhile, D has already assumed that it has been added as a member in the context and so it attempts to establish an out of band connection with B (for example, B could have been a passive server, and D&#39;s server agent might have attempted to connect to B&#39;s server port). B might not have received the AddMember_Event from the Context Broker yet and hence may not know if it should honor D&#39;s connection request. As a policy, B could have accepted the connection and deferred the integrity checking until it received the AddMember_Event (or a timeout). Thus, when implementing a partial ordering of events in a communication session, every member of the session should know how to handle the race condition. 
     Referring now to FIG. 4, the total ordering of events will be considered. In FIG. 4, as in FIG. 3, a Context Broker  410  manages a communication session (Context Y). The session concerns a multiparty communication between Context Agents  404 ,  406  and  408 , with Agent  404  desiring to add a new agent  410  (D). When the new member D sends the AddMember_End, the transaction has not yet been “committed” by the Context Broker. No member can assume that the transaction has been “committed” until it receives a commit event from the Context Broker for this transaction. The Context Broker sends the AddMember_Event to all the other members of the Context Y and waits for the acknowledgement ack (note that there is a timeout policy here in the Context Broker for the acknowledgement wait). After it receives the acknowledgement ack from all the members of the context, the Context Broker sends a commit event to all the members, including the newly added member. Any member may assume that the transaction has been “committed” only at this point. (Note that the Context Broker need not wait for the acknowledgement of the commit event.) Now if D attempts an out of band communication with B based on the previous transaction, B will honor the request appropriately. 
     FIG. 5 is a flowchart which shows how the software modules of a preferred embodiment of the present invention implement the negotiation broker-agent protocol described above. The embodiment depicted in the figure includes two agents,  502  and  506 , denoted as “User  1 ” and “User  2 ”, respectively, and a Context Broker  504 . For purposes of illustration, it will be assumed that User  1  desires to negotiate (send and/or receive a series of messages) with User  2 . 
     To initiate communication with User  2 , User  1  executes a state begin operation (step  508 ) and enters into its GenericNegotiate state (step  510 ). The execution of step  508  results in the sending of a begin signal to the Context Broker. The Context Broker responds to the begin signal by executing its own state begin operation (step  512 ), sending a begin signal to User  2 , and executing its own GenericNegotiate operation (step  514 ). User  2 , in turn, executes its state begin (step  516 ) and GenericNegotiate (step  518 ) operations. 
     At this point, negotiations between users  1  and  2  can take place. In the embodiment of FIG. 5, User  1  negotiates directly with User  2 . Therefore, the Context Broker merely acts as a conduit between the two Users. This stands in contrast to the alternative embodiment mentioned above, in which User  1  has the Context Broker negotiate with User  2  on User  1 &#39;s behalf. Nevertheless, in the FIG. 5 embodiment, as the Users and Broker loop through their respective GenericNegotiate operations, they may each implement one or more “policies”, or software routines that modify their GenericNegotiate operations. FIG. 5 shows the Users and the Broker implementing two policies each,  510   a  and  510   b  for User  1 ,  514   a  and  514   b  for the Broker, and  518   a  and  518   b  for User  2 . Although the figure shows the Users and Broker implementing two policies each, it is possible for both the Users and Broker to implement any number or policies, or no policies at all. An example of a policy that a Broker might implement is: “after 5:00 pm there will be a three message limit on all negotiations”. 
     At the completion of the negotiations, the Users and Broker enter their end state operations. Thus, User  2  recognizes the end of the negotiation and executes its end state operation (step  520 ) while sending an end notification to the Broker. The Broker, in turn, executes its end state operation (step  522 ) and sends an end notification to User  1 . Finally, User  1  executes its end state operation (step  524 ). 
     The foregoing is merely illustrative of the principles of the invention. Those skilled in the art will be able to devise numerous arrangements, which, although not explicitly shown or described herein, nevertheless embody those principles that are within the spirit and scope of the invention.