Internet Engineering Task Force SIP WG Internet Draft Mark/Kelley draft-mark-sip-dmcs-00.txt Dialogic Corporation March 8, 2000 Expires: September, 2000 Distributed Multipoint Conferences using SIP STATUS OF THIS MEMO This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as work in progress. The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes a set of extensions to SIP, which allows distributed multipoint conferencing techniques. Building on prior work [1], we refine implementation strategies and advance additional services. We present refinements on existing multipoint call and transfer signaling techniques and introduce new services of merge and split. Table of Contents 1 Terminology......................................................3 2 Introduction.....................................................3 3 Full mesh conference practices...................................3 3.1 Flooding.......................................................3 3.1.1 Direct adjacency.............................................4 3.1.2 State versioning.............................................6 3.2 Other issues...................................................7 3.2.1 Unqualified endpoints........................................7 3.2.2 Unresponsive endpoints.......................................8 3.2.3 Frustrated admissions........................................8 3.2.4 Admissions progress..........................................9 3.2.5 Coincident joins.............................................9 3.2.6 Timing considerations.......................................11 Mark/Kelley [Page 1] Internet Draft Distributed Multipoint Conferences March 8, 2000 3.3 Sample call flows.............................................11 3.3.1 Add party...................................................11 3.3.2 Disconnect..................................................12 3.3.3 Simultaneous add party......................................13 3.3.4 Add party during disconnect.................................15 4 Merge...........................................................16 4.1 Merge Implementation..........................................17 4.1.1 Merge Request...............................................18 4.1.2 Admission Control...........................................18 4.1.3 Accepted....................................................20 4.1.4 Transition..................................................20 4.2 Merging Options...............................................21 4.3 Special Cases.................................................22 4.3.1 Merge during Add Party......................................22 4.3.2 Merge during Merge..........................................23 4.3.2.1 Red to Blue, Green to Blue................................23 4.3.2.2 Red to Blue, Blue to Green................................24 4.3.2.3 Blue to Red, and Blue to Green............................25 5 Transfer........................................................25 5.1 Transfer Implementation.......................................27 5.1.1 Single Party Transfer.......................................27 5.1.1.1 Blind Transfer............................................28 5.1.1.2 Attended Transfer.........................................29 5.1.1.3 Transfer with Consultation................................31 5.1.1.4 Transfer and Hold.........................................32 5.1.2 Multi-Party Transfer........................................33 6 Split...........................................................34 6.1 Split Implementation..........................................35 6.2 Split Issues..................................................38 6.2.1 Some Accept, Some Reject....................................38 6.2.2 All Reject..................................................40 6.2.3 Disjoint Failure............................................40 6.3 Special Cases.................................................42 6.3.1 Add-Party & Split...........................................43 6.3.2 Merge & Split...............................................44 6.3.3 Transfer & Split............................................47 6.3.3.1 Blind Transfer............................................48 6.3.3.2 Attended Transfer.........................................48 6.3.3.3 Transfer with Consultation................................48 6.3.3.4 Transfer and Hold.........................................48 6.3.4 Split & Split...............................................49 7 Crossing INVITEs................................................50 7.1 Back off......................................................50 7.2 Deference.....................................................50 7.3 A deference algorithm for crossing INVITEs....................51 7.4 Proactive application of deference............................52 7.5 Egalitarian deference.........................................52 8 Syntax and Semantics............................................53 8.1 Headers.......................................................53 8.1.1 Also Header.................................................53 8.1.2 Replaces Header.............................................53 8.1.3 Call-Disposition Header.....................................53 Mark/Kelley [Page 2] Internet Draft Distributed Multipoint Conferences March 8, 2000 8.1.4 Status Header...............................................54 8.1.5 Rejected-By Header..........................................54 8.1.6 Unresponsive Header.........................................54 8.2 Response Codes................................................54 8.2.1 1xx Seeking Admission.......................................54 8.2.2 1yy Pending Request.........................................55 8.2.3 4ww Admission Failed........................................55 8.2.4 4zz Colliding Request.......................................55 9 Acknowledgements................................................55 10 Author's Addresses.............................................55 11 Bibliography...................................................56 1 Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [3] and indicate requirement levels for compliant SIP implementations. 2 Introduction This document describes refinements and extensions to work in progress in the area of SIP-based distributed multipoint conferencing. Our intent is to address open issues identified with earlier work and introduce new services where merited. We begin by reviewing the basic implementation approach proposed in earlier work, identifying unresolved or problematic issues with this approach and suggesting alternatives where appropriate. In subsequent sections we turn to specific services, illustrating concepts and implementation approach with sample scenarios and call flows. We conclude with a description of the syntax and semantics of the headers and response codes that are introduced in the prior sections. 3 Full mesh conference practices The requirements of a distributed multipoint ("full mesh") conference are enumerated in [2]. Such conferences require each participating endpoint to first obtain and subsequently maintain an accurate and consistent view of the conference without the benefit of a central conferencing server. There are numerous difficulties in meeting this requirement without adversely compromising implementation simplicity and efficiency. 3.1 Flooding Mark/Kelley [Page 3] Internet Draft Distributed Multipoint Conferences March 8, 2000 Implementation work in [2] proposed to apply a distributed database synchronization technique used in the OSPF link-state routing protocol [4] to solve the problems that are faced by more obvious and direct approaches. While we agree that the proposed technique, termed "flooding" because it relies upon the step-by-step propagation of database state from node to node in a distributed database, is well-suited to the solution of these problems, we suggest that the implementation may benefit from a more opportunistic application of the technique than has previously been proposed. In particular, we propose to adapt current implementation practice in two significant ways; first, by curtailing flooding of database state when that state can be presumed to be delivered over more appropriate paths, and second, by eliminating the largely unnecessary versioning of endpoint state. 3.1.1 Direct adjacency Flooding database state changes from a node to its "adjacent" nodes is essential in distributed databases when individual database nodes are adjacent only to a subset of the other database nodes; such nodes are necessarily dependent upon adjacent nodes to supply them with the most recent state of database records originating from other non-adjacent nodes, and each adjacent node must consequently assume the responsibility of propagating the state of these records to the other nodes adjacent to it. It is generally gratuitous, however, for a node to flood database state to adjacent nodes that are known to themselves be directly adjacent to the nodes from which that state originates, since the originating node can reasonably be expected (barring exceptional circumstances including network oversubscription, link failure, and endpoint error, which we'll address later) to propagate the state directly to its own adjacencies. The same logic can also be applied to situations in which a direct adjacency may not currently exist, but which is anticipated to develop in the immediate future. Endpoints can be divided into one of three distinct categories relative to any distributed full mesh conference. They may be (a) members of the conference, (b) non-members seeking to join the conference, hereafter referred to as "joiners" or (c) non-members who are not seeking to join the conference, hereafter simply "non- members". The synchronization problem lies in assuring that whenever an endpoint transitions between these categories that the other endpoints associated with the conference are properly informed of the transition. Given the three categories above, four allowed transitions between categories can be identified (two transitions, from member to joiner, and non-member to member, are not expected to occur directly.) These transitions are propagated as described in the table that follows. Mark/Kelley [Page 4] Internet Draft Distributed Multipoint Conferences March 8, 2000 Transition Database state propagation Member leaves The member communicates its departure directly to other members and joiners it has admitted to the conference by sending BYEs to them. Joiners that subsequently contact the former member seeking admission will be informed that the party is not a member of the conference (see 3.2.1 for more details.) Non-member The non-member is invited to join by an existing seeks to join member. Since the non-member is made adjacent only to the inviting member by this action, the inviting member floods the state of other members and joiners it has admitted to the conference to the non-member. This is, however, a one-time flooding event. The non-member, now a joiner, is expected to establish adjacency with other specified members itself by sending triggered INVITEs to these parties, so subsequent changes to the the state of these parties received by the inviting member is not flooded to the joiner. When the joiner contacts other members, those members must flood the state of joiners they have already admitted to the new joiner on admission. This is because these members don't know if the joiner seeking admission is adjacent to those other joiners or not. Again, this flooding is a one-time event, since the joiner is expected to immediately establish adjacency with any such other joiners. Joiner is fully The joiner signals to members and other joiners admitted that it has become a member by sending ACKs to members and joiners that accepted its triggered INVITEs, and a 200 response to the member that originally invited it. Joiner is The joiner signals other parties that have already denied admitted it by sending a BYE to those parties. admission or elects to The joiner informs other joiners that subsequently abandon efforts seek admission from it that it is not a member of to join the conference (see 3.2.1 for more details.) Mark/Kelley [Page 5] Internet Draft Distributed Multipoint Conferences March 8, 2000 We observe that the endpoints associated with a distributed mesh conference are typically adjacent to one another or anticipated to be establishing such adjacency, and hence directly inform each other of state changes (i.e. departure from the conference) without flooding this state through intermediate endpoints. Indirect flooding of database state occurs only when an adjacency between two endpoints is first established, a situation which occurs only when a party is first invited to join a conference by an existing member, and when a joiner seeks admission from other members of the conference. 3.1.2 State versioning Versions are attached to flooded state information in order to allow state change reports that may be received via different paths to be correctly serialized. While this is generally a sound practice, we believe that its costs (in terms of additional implementation complexity) outweigh its advantages in the current context. In the first place, such a mechanism is of value only when multiple conflicting reports are received. Since, as we've demonstrated above, indirect flooding is the exception rather than the rule for propagating state change information within distributed mesh conferences, the scenarios in which such conflicts may occur are strikingly limited. In point of fact, the only scenario where such an event may be expected to occur is when the state of endpoints reported by the member which invited the joiner to participate, and the state of endpoints reported by other members or joiners subsequently contacted by the invited party prove to be in conflict. We presume that joining endpoints act in parallel to establish adjacencies with each of the endpoints listed by the original member as potential members, rather than attempting to establish these connections in series. If this presumption is correct, the circumstances in which versioning might help an endpoint to avoid sending gratuitous triggered invitations are further narrowed. In essence, what versioning winds up buying us is the ability to avoid sending triggered invitations to parties that have left a conference exactly when the member inviting a party to join has learned of the other member's departure, but other members have not. While such a scenario will occasionally arise, forcing endpoints to create and propagate versioning information with participant state seems more costly than the problem it solves. We suggest that a more direct approach is to simply require a joining endpoint to attempt to contact and receive admission from any endpoint which the original inviting member, or any subsequent admission-granting members list as potential members of the call. While this may result in the occasional transmission of superfluous invitations to Mark/Kelley [Page 6] Internet Draft Distributed Multipoint Conferences March 8, 2000 parties that have left a conference but have not yet successfully informed all other members of this fact, these uncommon invitations are easily detected and harmlessly handled by the recipient (see discussion of unqualified endpoints in 3.2.1). Consequently, we propose to dispense with state versioning. 3.2 Other issues Flooding by itself does not address all of the problems identified in [2]. In particular, although flooding may allow an endpoint seeking admission to a conference to determine which of various conflicting reports regarding the status of another party is correct, it doesn't specify how a party seeking admission should disambiguate between the differing failure responses that may be received from a party that is putatively a member of the conference, but may, in one case, be in the process of leaving it or, in another, simply denying the newcomer admission. We specify a simple technique by which endpoints seeking to join a conference can make this determination. Additionally, while our amended flooding practices simplify user agent implementations, they do so at the cost of eliminating mechanisms which could have been used by the members of a distributed mesh conference to automatically identify and resolve situations in which a member of the conference or party seeking admission to it becomes unresponsive or fails, intentionally or otherwise, to complete the behavior expected of it. We identify mechanisms that might be used to keep such conferences from becoming crippled. 3.2.1 Unqualified endpoints [2] does not explicitly specify how an endpoint seeking to join a conference should handle a failure response from an endpoint that was in the conference, but has subsequently left. Flooding mechanisms are unable to preclude such an occurrence; it is always possible for a joining endpoint's triggered INVITE to reach a member just after the member has elected to leave the conference, but before any other members have learned about this departure and been able to propagate such information to the joiner. What is needed is for joining endpoints to interpret failure responses received from a supposed member of the conference in different ways. In particular, non-members of a conference (and this includes former members who have left the conference) MUST respond to triggered invitations to the conference with a response code that indicates that it is not a member of the conference. [2] introduces a 6xx (Not in Call) response for this purpose. A joining endpoint receiving this particular failure response is no longer required to establish a signaling relationship with the responding Mark/Kelley [Page 7] Internet Draft Distributed Multipoint Conferences March 8, 2000 endpoint, which is deemed unqualified to exercise admission control over the joiner. Other failure responses continue to represent an inability to connect with a conference member, and consequently require the joining party to abandon its attempts to join the conference. 3.2.2 Unresponsive endpoints The mechanisms specified elsewhere in this section should work correctly and efficiently, provided that each endpoint successfully fulfills its responsibilities. As noted earlier, things break down in the event that such responsibilities are not met, whether due to network oversubscription, link failure, endpoint error, or deliberate disregard or malice. If a member of a conference becomes unreachable, for example, it is impossible for other endpoints to join the conference. While new endpoints cannot be admitted to a conference under these conditions, it may be possible once the situation is diagnosed for existing members of the conference to restore order to the conference (either by collectively agreeing to "split" from the unresponsive party, or having any endpoint that is still able to communicate with the offending endpoint act as a bridge to it.) Flooding potentially offered mechanisms for diagnosing these sorts of problems within a conference, although [2] did not call out how it might take place. If a member endpoint came to the conclusion that another member had become unresponsive, it could assume that the party was no longer in the call, and propagate such state information to other endpoints. This could serve as an automatic mechanism for disconnecting unresponsive parties before they have the opportunity to exercise a deleterious influence on the conference. Problematic situations become apparent when parties seek to join a conference. During this process, the joining party may observe that one or more endpoints are unresponsive. By informing members that admitted the party about these unresponsive endpoints, it becomes possible for the members to take action (i.e. split from the offending endpoints, or bridge them in.) To accommodate this mechanism, we introduce a new header (Unresponsive) which is supplied in the BYEs sent by a joining party to members that admitted it to a conference and the 4xx response it sends to the member that invited it. The header includes the endpoint(s) that failed to respond to the joiner's query. 3.2.3 Frustrated admissions Mark/Kelley [Page 8] Internet Draft Distributed Multipoint Conferences March 8, 2000 A joining endpoint that is rejected by one or more members to the conference should also return a list of the parties that rejected it back to the member issuing the invitation and other members that admitted it, so that these members are able to know the reason that the invited endpoint was unable to join. We introduce a new header (Rejected-By) for this purpose. The header lists any endpoints that rejected the joiner's request for admission. Without this addition, the inviting member is denied important feedback on the specific reason for invitation failure. Rejection anonymity allows a single member of the conference to indefinitely frustrate attempts by other members to add additional parties to the conference. By supplying a mechanism to strip such anonymity, inviting members can seek additional explanation from the rejecting party (within the media stream) and/or potentially seek other remedies, such as removing the uncooperative member from the conference using the "split" service. 3.2.4 Admissions progress It is desirable for inviting members to be apprised of progress in the invited party's attempt to join the call. Provisional responses are defined in the base SIP specification for communicating such progress, but these do not include responses aimed specifically at relating admissions progress in full mesh conferences. Such information is useful both to reassure the inviting member that progress in the call attempt is being made, and may be used to forestall the expiration of call attempt timers (more on this in 3.2.6.) We define an additional 1xx class response (Seeking Admission) which is intended to be used to relay the current status of an attempt to gain admissions from the party seeking admission to the member that originally invited it to join. This response SHOULD be sent by the joining party back to the originator whenever a new provisional or final status is received to its triggered INVITEs; a new header (Status) is defined to carry the URI of the responding party and its updated response. Reliable provisional response mechanisms could be used in conjunction with this approach to ensure that status changes are successfully propagated back to the call originator. An alternative approach, involving periodic retransmission of this response with separate Status headers for each of the members that have responded thus far to the joining party's triggered INVITEs, is for further study. 3.2.5 Coincident joins Mark/Kelley [Page 9] Internet Draft Distributed Multipoint Conferences March 8, 2000 One of the problems identified by [2] is associated with the possibility that multiple endpoints will be invited to join a conference in progress at more or less the same time. How will these endpoints learn about each other, and which (if either) will be granted admissions control? The flooding practices identified in 3.1 should enable joiners to learn about each other. Assuming that there is at least one member that remains in the conference throughout the attempt by both joiners to gain admission, that member will propagate the state of the first joiner seeking admission through it to the second joiner seeking admission through it. (If no such member exists, it's evident that all of the original members left the conference while the joiners were seeking admission. In such cases, it's possible to construct scenarios in which a conference may devolve into multiple disjoint conferences (sharing the same Call-Id) consisting of subsets of the joiners that were seeking admission. While these scenarios are not envisioned to be likely or typically problematic, mechanisms for safeguarding against these scenarios are for further study.) Since at least one of the joiners is aware of the other, it will attempt to establish a connection with that other joiner. When the other joiner receives the triggered invitation indicating that the requestor is seeking to join the conference, its response is contingent upon its current state, capabilities, and desires. 1. If the receiving joiner has already been fully admitted to the conference, and is consequently a member thereof, it may respond in any way it wishes to the request, just as any other member would. 2. However, if it is still seeking to join the conference, it SHOULD accept the invitation if a connection is possible and desirable. 3. However, if connection is impossible or undesirable to the joiner receiving the invitation, it MUST return a 6xx Not In Call response, thereby allowing the other party to continue to seek admission to the conference while the responder continues to seek admission from other endpoints. In such cases, the responder must itself seek admission from the requestor once it has received admission from all other known participants in the conference before it can be considered to have gained admission. These rules do not eliminate the possibility of deadlocks in certain scenarios resulting when three or more joiners who are each unwilling or unable to communicate with at least one of the other such joiners are simultaneously invited at the same time; dependency loops when three or more parties are seeking admission are possible. Mark/Kelley [Page 10] Internet Draft Distributed Multipoint Conferences March 8, 2000 Although these scenarios are expected to occur infrequently, solutions to them are for further study. 3.2.6 Timing considerations For further study. 3.3 Sample call flows In this section we present call flows associated with various full mesh conference scenarios. 3.3.1 Add party SIP endpoints A, B, and C are connected in a full mesh conference. Endpoint A invites endpoint D to join the conference. A B C D (i) ---------------------------------> INVITE D/Also: B,C (ii) <---------------------- INVITE B/Requested-By: A <----------- INVITE C/Requested-By: A (iii) ----------------------> 200 OK (iv) -----------> 200 OK (v) <----------- ACK <---------------------- ACK <--------------------------------- 200 OK (i) Endpoint A invites endpoint D to join the conference. Although the INVITE from A will establish an adjacency between A and D, D is presumed to not be adjacent to the other members of the conference (B,C), so A floods the identities of other members to D using the Also: header. (ii) D elects to accept the invitation from A, but must establish signaling relationships with the other members in the call before becoming a member. In our parlance, D has become a joiner. D sends triggered INVITEs to the endpoints that A suggested were either members or other joiners. Note that the "Requested-By" header is used to indicate that the invitation was triggered by an action initiated by the endpoint identified by the header (in this case, A). (iii) B accepts the triggered invitation from D, granting D consent to join the conference. If B were aware of other conference joiners, it would have supplied an Also: header to the 200 response identifying them. (iv) C accepts the triggered invitation from D, granting D consent to join the conference. If C were aware of other conference Mark/Kelley [Page 11] Internet Draft Distributed Multipoint Conferences March 8, 2000 joiners, it would have supplied an Also: header to the 200 response identifying them. (v) D has received 200 responses from all of the parties that were identified by A. It now sends ACKs to each endpoint that accepted its triggered INVITEs (B,C), and a 200 OK response to the member that originally invited it (A). If B had declined D's triggered invitation, the following flow would result: A B C D (i) ---------------------------------> INVITE D/Also: B,C (ii) <---------------------- INVITE B/Requested-By: A <----------- INVITE C/Requested-By: A (iii) -----------> 200 OK (iv) ----------------------> 603 Declined (v) <----------- BYE/Rejected-By: B <--------------------------------- 4zz Rejected/Rejected-By: B (i) Endpoint A invites endpoint D to join the conference. Although the INVITE from A will establish an adjacency between A and D, D is presumed to not be adjacent to the other members of the conference (B,C), so A floods the identities of other members to D using the Also: header. (ii) D elects to accept the invitation from A, but must establish signaling relationships with the other members in the call before becoming a member. In our parlance, D has become a joiner. D sends triggered INVITEs to the endpoints that A suggested were either members or other joiners. Note that the "Requested-By" header is used to indicate that the invitation was triggered by an action initiated by the endpoint identified by the header (in this case, A). (iii) C accepts the triggered invitation from D, granting D consent to join the conference. If C were aware of other conference joiners, it would have supplied an Also: header to the 200 response identifying them. (iv) B declines the triggered invitation from D, denying D consent to join the conference. (v) Since D was rejected by B, it informs the endpoints (C) that accepted it for admission of this fact by sending BYEs containing a Rejected-By header identifying the rejecting endpoints. It also returns a Rejected response to the endpoint that originally invited it (A). 3.3.2 Disconnect SIP endpoints A, B, and C are connected in a full mesh conference. Endpoint A elects to leave the conference. Mark/Kelley [Page 12] Internet Draft Distributed Multipoint Conferences March 8, 2000 A B C D -----------> BYE ----------------------> BYE ---------------------------------> BYE An obvious implementation! 3.3.3 Simultaneous add party SIP endpoints A and B are connected in a point-to-point conference. Endpoint A invites C to join the conference. Meanwhile endpoint B invites D to join the conference. A B C D (i) ----------------------> INVITE C/Also: B (ii) ----------------------> INVITE D/Also: A (iii) <----------- INVITE B/Requested-By: A (iv) <--------------------------------- INVITE A/Requested-By: B (v) -----------> 200 OK/Also: D (vi) -----------> INVITE D/Requested-By: B (vii) <----------- 200 OK (viii) -----------> ACK <----------- ACK <---------------------- 200 OK (ix) ----------------------> ACK (x) ---------------------------------> 200 OK (xi) <--------------------------------- ACK <---------------------- 200 OK (xii) ----------------------> ACK (i) Endpoint A invites endpoint C to join the conference. Although the INVITE from A will establish an adjacency between A and C, C is presumed to not be adjacent to the other members of the conference (B), so A floods the identities of other members to C using the Also: header. (ii) Endpoint B invites endpoint D to join the conference. Although the INVITE from B will establish an adjacency between B and D, D is presumed to not be adjacent to the other members of the conference (A), so B floods the identities of other members to D using the Also: header. (iii) C elects to accept the invitation from A, but must establish signaling relationships with the other members in the call before becoming a member (or returning a final response to A). In our parlance, C has become a joiner. C sends triggered INVITEs to the endpoints (B) that A suggested were either members or other joiners. Note that the "Requested- By" header is used to indicate that the invitation was Mark/Kelley [Page 13] Internet Draft Distributed Multipoint Conferences March 8, 2000 triggered by an action initiated by the endpoint identified by the header (in this case, A). (iv) D elects to accept the invitation from B, but must establish signaling relationships with the other members in the call before becoming a member (or returning a final response to B). In our parlance, D has become a joiner. D sends triggered INVITEs to the endpoints (A) that B suggested were either members or other joiners. Note that the "Requested- By" header is used to indicate that the invitation was triggered by an action initiated by the endpoint identified by the header (in this case, B). (v) B elects to admit C to the conference, accepting C's triggered invitation with a 200 OK response. However, since B has invited a new party to the conference (D), it floods that party's state to C in the response using the Also: D header. (vi) C receives B's response to its triggered invitation. Since the response identifies another potential joiner or member, C must contact the identified party (if it has not done so already.) So, C sends out yet another triggered invitation, this time to D, indicating in the Requested-By header that it learned about D through B. (vii) D accepts C's triggered invitation, although it is not yet a member. The other options open to D are to (i) hold off responding to C until later, or (ii) send back a 6xx Not In Call response. Taking either of these approaches is undesirable if D is willing and able to talk to C. Returning a Not In Call response would require D to initiate its own request back to C later in order to gain admission. (viii) C receives D's 200 response, and realizes that it has been granted admission by all the relevant parties, and hence is a full member of the conference. It confirms this by sending ACKs to the parties it send triggered INVITEs to (B,D), and responding to the member that asked it to join the call (A). (ix) A acknowledges C's 200 OK response. (x) A decides to accept D's request for admission, sending back a 200 OK. Note that while A should place a list of joiners it has admitted into the Also header of this response, it has already received C's 200 response indicating that C has gained admission, so it is not required to flood C's state to D (the state of members is only flooded in non-triggered invitations.) (xi) D recognizes there are no more endpoints that it needs to seek admission through, and hence it is a full member of the Mark/Kelley [Page 14] Internet Draft Distributed Multipoint Conferences March 8, 2000 conference. It sends ACKs to the parties that accepted its triggered invitations, and a 200 OK response back to the party that invited it to join the call. (xii) B acknowledges D's 200 OK response. There are a number of variants on this basic call flow depending upon the precise sequence in which messages are sent and/or received. For example, if B's invitation to D (step 2) is not received by D until after step 6, D will receive C's triggered invitation before it receives B's original invitation. This presents some interesting problems. In the first place, the triggered INVITE received from C looks like a transfer operation (at least as implemented in prior work.) Something must be introduced to distinguish the present case from a garden-variety transfer (see later discussion re: transfers for a proposal.) Second, D must be careful not to blindly return a 6xx Not In Call response without recording the transaction for future reference. Failure to do so may result in a partially connected conference (a no-no) if the member inviting C (A) leaves before D seeks admission from it. Two approaches are reasonable candidates here. D could treat the triggered INVITE as though it were untriggered, although this may have disagreeable security ramifications. Alternatively, D can hold its response until it hears from the requesting party B (or a suitably lengthy timer elapses), contact B directly before responding, or simply note that if a call with the same Call-Id arrives from B within a reasonable amount of time, that C must be considered a joiner or member, and consequently contacted for admission. 3.3.4 Add party during disconnect SIP endpoints A, B, and C are connected in a full mesh conference. Endpoint A invites D to join the conference. Meanwhile endpoint B elects to leave the conference. A B C D (i) ---------------------------------> INVITE D/Also: B,C (ii) <----------- BYE -----------> BYE (iii) <---------------------- INVITE B/Requested-By: A <----------- INVITE C/Requested-By: A (iv) ----------------------> 6xx Not In Call (v) -----------> 200 OK (vi) <----------- ACK <--------------------------------- 200 OK (i) Endpoint A invites endpoint D to join the conference. Although the INVITE from A will establish an adjacency Mark/Kelley [Page 15] Internet Draft Distributed Multipoint Conferences March 8, 2000 between A and D, D is presumed to not be adjacent to the other members of the conference (B,C), so A floods the identities of other members to D using the Also: header. (ii) Endpoint B elects to leave the conference, and sends BYEs to the other members (A,C) to communicate its departure. (iii) D decides that it wants to join the conference, so it sends triggered INVITEs to the other members (B,C). (iv) B is no longer in the conference when it receives D's triggered invite, so it responds as required indicating that it is not qualified in the conference. (v) C accepts D's request for admission. (vi) Since D has heard from all of the members and/or other joiners, and was accepted by all qualified endpoints, it realizes that it has become a full member of the conference, and sends an appropriate acknowledgement to the party that accepted its triggered INVITE (C), and a 200 OK response to the party that originally invited it. 4 Merge This service allows two full mesh calls to merge into one full mesh call. The participant initiating the endpoint must be a member of both full mesh calls. The calls are otherwise unrelated. The following participants are involved in the merge: @ Merging Party -- the participant invoking the merge operation. This participant must be a member of both the transitioned call and the home call. @ Transitioned Call -- the call asked to merge. These participants have the option of staying in the transitioned call, or joining the home call. @ Home Call -- the call the transitioned participants have been asked to join. The requirements are: @ Only the merging participant may invoke this service. @ The merging participant must choose one call to be the home call and the other to be the transitioned call. @ The transitioned call participants will move over to the home call. @ Participants in the transitioned call should know the set of participants they are merging with. @ Participants in the home call should know the set of participants asked to merge into the home call. Mark/Kelley [Page 16] Internet Draft Distributed Multipoint Conferences March 8, 2000 @ The home call participants have admission control over the participants of the transitioned call. @ A home call participant may reject a transitioned call participant. The rejected participant stays connected in the transitioned call. @ A transitioned call participant may reject merging into the home call. This participant stays connected in the transitioned call. @ A transitioned call participant may elect to both join the home call and stay connected in the transitioned call. @ The merging participant may elect to stay connected in the transitioned call. @ At the end of the merge, the transitioned call is still active if and only if two or more participants stayed in the transitioned call as a result of being rejected or by electing to stay. 4.1 Merge Implementation Merging two calls is essentially performing an add-party operation for each participant in the transitioned call adding them to the home call. After the add-party operation completes, the participant leaves the transitioned call. To accomplish this, the merging participant sends an INVITE to each participant in the transitioned call using the home call's Call-ID. The Also header includes the list of participants in the home call. This is the same as the add- party operation. The Replaces header includes 'A; call- id=transitioned call' indicating this leg should change from a transitioned call leg to a home call leg. The Replaces header is optional and indicates a participant's desire to disconnect from the transitioned call. If omitted, this indicates the participant would like to keep the transitioned call leg active. To instruct the transitioned call participants a merge is happening, the Call- Disposition header is included with 'merge; call-id=transitioned call'. The call-id indicates the transitioned call-id. This tells the participant to merge into the home call, then disconnect (if he wants) from the transitioned call. Consider the following example. There are two full mesh calls. The 'red' call includes {A, B, C}. The 'blue' call contains {A, X, Y}. {A} is the common participant. {A} wishes to merge the calls choosing 'blue' to be the transitioned call, and 'red' to be the home call. Assuming everyone accept and decide to disconnect from the transitioned 'blue' call, the result would be a 'red' call with {A, B, C, X, Y}. The message flow is shown below. Mark/Kelley [Page 17] Internet Draft Distributed Multipoint Conferences March 8, 2000 C B A X Y Merge --F1-----> Request --F2-----> ---------> Admission <--------- ------F3-- Control <--------- ---------- ------F4-- <--------- ---------- ------F5-- <--------- ---------- ---------- ------F6-- --F7------ ---------> --F8------ ---------- ---------> --F9------ ---------- ---------> --F10----- ---------- ---------- ---------> Accepted <--------- -----F11-- <--------- ---------- -----F12-- <----F13-- --F14----> <--------- ---------- -----F15-- <--------- ---------- ---------- -----F16-- <--------- -----F17-- --F18----- ---------> Transition --F19----> <----F20-- --F21----> Simple Merge Flow 4.1.1 Merge Request A sends a merge request to participants X and Y. The messages are essentially the same. F1 (A->X): INVITE X To: X From: A Call-ID: red Also: B, C Replaces: A; call-id=blue Call-Disposition: merge;call-id=blue F2 (A->Y): INVITE Y To: Y From: A Call-ID: red Also: B, C, X Replaces: A; call-id=blue Call-Disposition: merge;call-id=blue 4.1.2 Admission Control Mark/Kelley [Page 18] Internet Draft Distributed Multipoint Conferences March 8, 2000 X & Y now try and gain admission to the red call. This is done through triggered INVITEs to each participant in the red call. This is the very similar to the add-party case. A "Merge" header is included as an informational guide to the home (red) call participants indicating the participants in the transitioned (blue) call attempting to merge into the red call. This header serves as a flag to differentiate this message from a standard add-party operation. The merging participant {A} is already connected in the red call so it is not necessary to include {A} in the Merge header. F3 (X->B): INVITE B To: B From: X Requested-By: A Call-ID: red Merge: Y F4 (X->C): INVITE C To: C From: X Requested-By: A Call-ID: red Merge: Y F5 (Y->B): INVITE B To: B From: Y Requested-By: A Call-ID: red Merge: X F6 (Y->C): INVITE C To: C From: Y Requested-By: A Call-ID: red Merge: X The following responses include an Also header indicating the participants in the red call. This tells the transitioned call participants of any other participants they might not already know about. For example, if an add-party operation was in progress on the red call, the transitioned call participants may not have received this participant from the merging participant {A}. This is also how an add-party response is formulated. F7 (B->X): 200 OK To: B From: X Call-ID: red Also: A, C Mark/Kelley [Page 19] Internet Draft Distributed Multipoint Conferences March 8, 2000 F8 (C->X): 200 OK To: C From: X Call-ID: red Also: A, B F9 (B->Y): 200 OK To: B From: Y Call-ID: red Also: A, C, X F10 (C->Y): 200 OK To: C From: Y Call-ID: red Also: A, B, X 4.1.3 Accepted At this point the blue call participants (X and Y) have been admitted into the red call. X and Y ACK each red call participant (B and C) and respond to the initiator of the merge request (A). This is the same as the add-party case. F11 (X->B): ACK F12 (X->C): ACK F13 (X->A): 200 OK To: X From: A Call-ID: red F14 (A->X): ACK F15 (Y->B): ACK F16 (Y->C): ACK F17 (Y->A): 200 OK To: Y From: A Call-ID: red F18 (A->Y): ACK 4.1.4 Transition Mark/Kelley [Page 20] Internet Draft Distributed Multipoint Conferences March 8, 2000 Now the blue call participants are in the red call. Each blue participant needs to contact the other blue participants to confirm the call merge. The rest of the blue call legs are transitioned into red call legs. The signaling for this stage is pretty much the same as the signaling in the merge request stage. There is a possibility of a crossing INVITE if both parties (in this case X & Y) get to this step at the same time. See section 7 on Crossing INVITEs on how to handle this problem. F19 (X->Y): INVITE To: Y From: X Call-ID: red Also: A, B, C Replaces: X; call-id=blue Transitioned: blue F20 (Y->X): 200 OK To: Y From: X Call-ID: red F21 (X->Y): ACK 4.2 Merging Options The above call flow outlined the best scenario for how a merge operation should take place. However, this is not always the same flow in a merge scenario. Even though this appears to be an add- party operation followed by a transition, the add-party operation is slightly modified to support a merge. Below is an overview of the different options an endpoint has in each of the stages identified in Figure 1. @ Merge Request - when X & Y receive this request they have two options - either to accept the merge and attempt to join the home call, or reject the merge and send no further signaling. In either case the transitioned (blue) call leg they have with 'A' is deleted. @ Admission Control - this is essentially the same as the add-party case. X & Y send triggered INVITEs to each participant in the home (red) call. The red participants have the option of accepting (sending a 200 response) or rejecting (sending a 4xx response) X & Y. Assuming they accept, they would include an Also header in the 200 response. This list of participants may include blue call participants. This appears in messages F9 and F10. Since Y knows X is in the blue call, Y will not attempt to contact X during the admission control stage. Y just needs to contact everyone in the Also headers that are not in the blue call. This Mark/Kelley [Page 21] Internet Draft Distributed Multipoint Conferences March 8, 2000 is the difference from the traditional add-party case. @ Accepted - after receiving 200 responses from all participants included in the Also headers that we were not already connected with in the transitioned (blue) call, an ACK is sent to each accepting participant and a 200 is sent back to the merge initiator (A). At this stage we are concerned full members of the call. A later sends us an ACK to confirm our leg with A. @ Transition - now that we are in the home (red) call, we will try to remove any transitioned (blue) call-legs that are still active. This message is an untriggered INVITE. It looks essentially the same as the original merge request. As a result, some members in the blue call will get the same merge request from multiple participants. Upon receiving the second merge request, we must accept the request if we accepted the original request. If we rejected the original request, we may change our mind when the second request is received and accept this. If we do not want to merge over, we will get a merge request from each participant in the transitioned call that wants to merge. This is needed to delete the transitioned call-legs with those that are merging. 4.3 Special Cases The following sections explain the interaction between merge and the other supplementary services when invoked simultaneously on a call. 4.3.1 Merge during Add Party There are two cases to consider. The add-party operation could be taking place on the home or the transitioned call. The home call views the merge operation as a series of add-party operations. Multiple add-party operations on the home call would not cause a problem. This would be the same as an add-party during add-party operation discussed in the full mesh case. If an add-party operation takes place on the transitioned call, the late arriver would eventually get connected. Once connected, the participants in the transitioned call would send a new INVITE message to the late arriver asking him to merge into the new call. This is also not a problem and is solvable by our current implementation. Again, the user that issued the add-party operation would see it through. Once the user is connected to the transitioned call, another INVITE would be issued to pull this new user over to the home call. In order to see how this works, the diagram below shows the state changes a transitioned participant goes through: Transitioned Call Home Call (1) connected disconnected Mark/Kelley [Page 22] Internet Draft Distributed Multipoint Conferences March 8, 2000 (2) connected admission control (3) transition connected (4) disconnected connected The transitioned call participant is (1) connected with the transitioned call. Once the participant receives a merge request we are attempting to get accepted in the home call (2). Once accepted (3), the participant queries other participants in the transitioned call to see if they merged over. After getting a response from everyone (4) we are disconnected from the transitioned call. In step (1) and (2) we can receive and accept an add-party operation for the transitioned call. If we were accepted by the home call and move to step (3) and we knew about a user trying to get added to the transitioned call, we must wait for the final ACK (or timeout) from this new user before disconnecting the transitioned call and moving to step (4). Once we receive a final ACK in step 3 we immediately issue a transition INVITE to this new participant just like we did to the other participants that were connected to the call. Once we are in step (3) we may no longer accept add-party admission control requests since we are trying to get out of this call. 4.3.2 Merge during Merge There are four different configurations for simultaneous merging resulting from two participants attempting a merge involving two or three separate calls. For each of the scenarios refer to the following setup: Red Call: A, B, C Blue Call: C, D, E, F Green Call: E, F, G, H Red Blue Green A---===C===---===E===---G | / |\ /| |\ /| | / | / | | / | |/ |/ \| |/ \| B D---===F===---H 4.3.2.1 Red to Blue, Green to Blue In the above diagram C is merging the red call (ABC) into the blue call (CDEF) while E is merging the green call (EFGH) into the blue call (CDEF). This is essentially multiple add party operations happening simultaneously. All the participants are merging into the same call. The participants in the blue call will be asked to add both red and green participants. Upon accepting a participant, any Mark/Kelley [Page 23] Internet Draft Distributed Multipoint Conferences March 8, 2000 further admission control requests will also learn of the new participant. Consider the following argument. Hypothesis: B & G are both participants in the blue call and connected to each other at the completion of both merge. In order for B & G to gain admission to the blue call, they must both contact a blue participant, D. D will receive one triggered INVITE from B and another triggered INVITE from G. D may receive the invites simultaneously, but must respond to them sequentially. If D responds to B first, then the response from D to G will contain B's address. If D responds to G first, then the response from D to B will contain G's address. This step ensures B & G will attempt to connect with each other. Therefore B & G must contact each other. Since they are both in the blue call they must have accepted each other into the call. 4.3.2.2 Red to Blue, Blue to Green In the above figure, participant C is merging the red call (ABC) into the blue call (CDEF). At the same time E is merging the blue call (CDEF) into the green call (EFGH). After everything settles down and assuming all involved participants accept the merge, the result would be one of two cases. There could be two calls: a blue call (ABC) and a green call (CDEFGH). Or there could be one call: a green call (ABCDEFGH). The two call scenario happens in the following situation. After the simultaneous merge requests are sent out, the participants of the blue call happen to receive and process E's blue to green merge request first. All the blue participants are accepted into the green call and successfully transition to the green call (CDEFGH). DEF removes all state associated with the blue call. C still has an outstanding blue request and therefore is still tracking the blue call. When A and B try to contact D, E, and F on the blue call, D, E, & F all respond with a 4XX Not In Call response. A & B consider themselves accepted into this empty blue call and respond 200 OK to C. A & B then change their red leg to a blue leg and the result is a blue call (ABC). C knows A & B didn't get connected to the original blue participants (CDEF). At this point, C can attempt to send another merge request to move the new blue call (ABC) into the new green call (CDEFGH). Everyone will end up in one green call (ABCDEFGH) if at least one of the red participants (AB) successfully contacts and is accepted by at least one of the blue participants (DEF). The blue participants treat this the same as an add-party during merge operation. Let's say B is trying to merge into the blue call and is accepted by D. D now thinks B is part of the blue call. After all the green participants accept D, D attempts to transition all current blue participants to the green call. This causes an INVITE from D to B to be sent. Now B knows about green call and will move over to Mark/Kelley [Page 24] Internet Draft Distributed Multipoint Conferences March 8, 2000 green. Similarly, after B is accepted into the green call, B will contact any remaining blue participants it knows about (i.e. participant A). Now the call is complete including all participants in the green call. 4.3.2.3 Blue to Red, and Blue to Green In this scenario C is merging the blue call (CDEF) into the red call (ABC) while E is merging the blue call (CDEF) into the green call (EFGH). This leaves the blue participants in a complicated situation. They are being pulled into two different directions. There are several options that come to mind on how to handle this. First, we could restrict the endpoints to have only one merge operation ongoing at a time. If an endpoint was in the process of merging, they must reject any other merge requests. This leads to an awkward situation in which the blue call is split up -- some participants go into the red call, others move over to green. To prevent the blue call from being split up, we could allow endpoints to accept and process simultaneous merge operations. This leads to a possible problem when the endpoints reach the transitioning phase. Since they are now processing two merges, in the transition phase they need to replace each existing blue leg with a red and a green leg. Since a merge is essentially an add- party operation followed by the transitioning stage, the following actions seem reasonable. The first merge request will be processed as described earlier. All subsequent merge requests on this call will be processed not as merge operations, but as an add-party request. If an endpoint receives a merge request and has no record to the transitioning call, the endpoint treats the request as an add-party request. 5 Transfer Essentially a transfer service allows one participant to both add another participant to the call, while at the same time leaving the call. There are three groups of participants involved in the transfer: @ Transferring Party: the participant invoking the transfer. @ Transferred Call: the group of participants being transferred. This may be only one person. @ Transferred-To Call: the call the transferred participants are moving to, or just a single party. Mark/Kelley [Page 25] Internet Draft Distributed Multipoint Conferences March 8, 2000 The requirements below outline what is needed for a transfer of a multi-party call to a single party or transferring a multi-party call to another multi-party call. @ Any participant may invoke the transfer. This is the transferring party. @ The transferring party may request the transfer and not care about whether the transfer succeeded or not (i.e. a blind transfer), or the transferring party may wish to find out the success of the transfer (i.e. attended or consultation transfer). @ The transferred parties may accept or reject the transfer. @ The transferred-to call may either be a single participant, or an entire call. The transferring party must be a participant in the transferred-to call to invoke the transfer. Transferring one call to another call is very similar to merging two calls. @ The transferred-to call may accept or reject the transfer. @ Upon completion of the transfer, the transferring party disconnects. There are four types of transfer -- blind, attended, transfer with consultation, and transfer & hold. @ Blind Transfer -- the transferring party instructs the transferred call (one or more participants) to transfer to the transferred-to call (one or more participants). At the same time, the transferring party disconnects from the transferred call. The transferring party does not know whether or not the transfer succeeded. The transferred call has the option to accept or reject the transfer. The transferred-to call also has the option to accept or reject. @ Attended Transfer -- this is similar to blind transfer. The only difference is the transferring party only disconnects if the transfer was successful. In this mode, the transferring party first learns of the success or failure of the transfer before disconnecting from the call. @ Transfer with Consultation -- the transferring party and transferred-to call consult before the transfer is invoked. This is very similar to merging two calls. The transferring party is in two separate calls: the transferring call and the transferred- to call. Upon completion the two calls are merged and the transferring party disconnects. @ Transfer & Hold -- this service is similar to the blind transfer. The difference is the transferring party does not disconnect, but may be put on hold. The transferring party instructs the Mark/Kelley [Page 26] Internet Draft Distributed Multipoint Conferences March 8, 2000 transferred call to connect with the transferred-to call. The transferring party is still connected, and may still be communicating, with the transferred call. The service title "transfer & hold" is primarily a legacy service. With SIP, an endpoint can be active in multiple calls simultaneously so the "hold" aspect of this service is now an optional part. 5.1 Transfer Implementation There are several combinations of a transfer operations. There are four separate types of transfer, two configurations of transferred calls, and two configurations of transferred-to calls. The different types of transfer were discussed above. When the transfer operation is invoked, we can transfer a single party (a two-party call) to a single party, multiple parties (a three or more party mesh call) to a single party, a single party to multiple parties, or multiple parties to multiple parties. First we will focus on transferring to a single party discussed in the Single Party Transfer section below. Transfer to a multi-party call is very similar to merging two calls. The differences will be discussed in section 5.1.2 on Multi-Party Transfer. 5.1.1 Single Party Transfer A single party transfer refers to a single transferred-to participant. This is the simplest form of transfer. Below we will discuss the implementation options for each of the four forms of transfer. Each sub section will discuss two options. The transferred call may either be a single endpoint (i.e. a two-party call shown in figure 1 or a bridged call shown in figure 2) or multiple endpoints (i.e. a multi-party full mesh call shown in figure 3 or an ad-hoc bridge shown in figure 4). The diagram below illustrates the transfer example. The sub sections below will refer to this diagram. The transferring party is always {A} and the transferred-to party is always {T} (not pictured). Single Endpoint Multiple Endpoints Fig 1: A---B Fig 3: A---B \ / C or or Fig 2: X Fig 4: X /|\ / \ A B C A-B-C Mark/Kelley [Page 27] Internet Draft Distributed Multipoint Conferences March 8, 2000 The bridged scenarios (figures 2 & 4) are not explicitly discussed below. In the context of transfer, it does not matter whether a participant is a bridge or a regular user. Transferring a bridge transfers a group of participants the bridge represents but from the signaling perspective the transfer involves just another endpoint. Because of this, transferring a single endpoint is handled the same in figures 1 and 2. Similarly, transferring multiple endpoints is the handled the same in figures 3 and 4. 5.1.1.1 Blind Transfer In blind transfer, the transferring party {A} disconnects no matter what the outcome of the transfer. For this reason it makes sense to use a BYE message to invoke the transfer. Invoking a blind transfer for a single endpoint (figures 1 or 2) or for multiple endpoints (figures 3 or 4) is essentially the same. For each endpoint in the call, {A} would issue a BYE message indicating the transferred-to party {T} in the Also header field. Using figure 3 as an example, the signaling would look like this: First {A} initiates the transfer request to both {B} and {C}: A->B: BYE B Call-ID: ABC Also: T A->C: BYE C Call-ID: ABC Also: T {B, C} responds and accepts the transfer request. Now {A} is out of the call. {B} and {C} are still connected to each other. B->A: 200 OK C->A: 200 OK {B, C} attempts to connect with {T} by sending triggered INVITEs. These triggered INVITEs contain an Also header indicating the other participants of the call. When T receives this message, T will know who he needs to connect with to complete the transfer. If only one participant was transferring to T, an Also header would not be present. B->T: INVITE T Call-ID: ABC Requested-By: A Also: C C->T: INVITE T Call-ID: ABC Mark/Kelley [Page 28] Internet Draft Distributed Multipoint Conferences March 8, 2000 Requested-By: A Also: B {T} has two choices. {T} can accept the transfer and attempt to connect with the other participants in the transferring call, or reject the transfer. {T} treats this just as he would if asked to join an existing call. This is very similar to what happens in an add-party operation. If {T} decides to accept, {T} must contact all participants, or receive INVITEs from all participants. In this flow above, {T} received INVITEs from all participants and now can respond to each with a 200 OK. The final message flow is shown below: T->B: 200 OK Also: B, C T->C: 200 OK Also: B, C B->T: ACK C->T: ACK Let's assume {T} received the B->T triggered INVITE and {T} sent off his own INVITE to {C} before receiving the C->T triggered INVITE. {C} could either receive this INVITE before sending one to {T}, or the two INVITEs may cross on the wire. If {C} received the INVITE before sending one, {C} could respond to {T} allowing {T} to complete the link with the call by sending a 200 OK response to {B} and an ACK response to {C}. If {C} and {T} send INVITEs to each other that crossed on the wire, a resolution to this problem is discussed in section 7. 5.1.1.2 Attended Transfer An attended transfer is almost identical to a blind transfer. The transferring party only disconnects if the transfer was successful. To distinguish an attended transfer from a blind transfer we introduce the header 'Call-Disposition: transfer=attended'. The message flow is almost identical, however since this 'BYE' message should only succeed if the transfer was a success, the response to the transfer 'BYE' message should wait until the transferred endpoint(s) find out if the transfer succeeded. The message flow below illustrates an attended transfer. Again, we will use figure 3 as the example setup. {A} indicates the intent to do an attended transfer. A->B: BYE B Call-ID: ABC Also: T Mark/Kelley [Page 29] Internet Draft Distributed Multipoint Conferences March 8, 2000 Call-Disposition: transfer=attended A->C: BYE C Call-ID: ABC Also: T Call-Disposition: transfer=attended {B, C} receives the message, agrees to the transfer, and sends back a provisional response to {A} as an update message and to stop {A}s retransmission timer. B->A: 100 Trying C->A: 100 Trying {B} and {C} send triggered INVITEs to {T} just like the blind transfer case. {T} will eventually respond. This allows {B} and {C} to ACK {T} successfully completing the transfer. {B} and {C} would send a final response (200 Transfer Succeeded) to disconnect {A}. What happens if the transfer fails? This could happen in one of two ways. Either a transferred participant or the transferred-to participant could reject the transfer request. Let's assume that in the above flow {B} decided to reject the transfer. The abbreviated flow is shown below. {A} invokes the attended transfer: A->B: BYE B / Also: T / Call-Dis: transfer=attended A->C: BYE C / Also: T / Call-Dis: transfer=attended {B} rejects the transfer. B->A: 4XX Reject Transfer A->B: ACK {C} attempts to continue with the transfer, without knowledge of {B}s rejection. C->T: INVITE T / Req-By: A / Also: B {T} continues to get linked up with all participants of the transferred call. {T} finds out {B} rejected the transfer. T->B: INVITE B / Req-By: C B->T: 4XX Reject Transfer T->B: ACK Mark/Kelley [Page 30] Internet Draft Distributed Multipoint Conferences March 8, 2000 {T} reports back informing {C} of the bad news. {C} responds to {A} with the bad news. T->C: 4XX Rejected / Rejected-By: B C->A: 4XX Transfer Rejected / Rejected-By: B A->C: ACK The transfer failed. Since both {B} and {C} rejected the BYE, {A} is still connected in the original call. 5.1.1.3 Transfer with Consultation This is similar to the attended transfer. The only difference in this case is the transferring party {A} first connects with the transferred-to party {T} to consult to approve the transfer. Once the transfer completes and was successful, {A} disconnects from both the transferred-to party and the transferred call. The flow for this transfer is shown below. Again, I will use figure 3 as the example. The transferring party {A} consults with the transferred-to party {T}. A->T: INVITE T Call-ID: AT T->A: 200 OK A->T: ACK After {A} and {T} finish consulting, {A} initiates the transfer. A->B: BYE B Call-ID: ABC Also: T Call-Disposition: transfer=consultation A->C: BYE C Call-ID: ABC Also: T Call-Disposition: transfer=consultation {B} and {C} attempt to transfer over to {T}. B->T: INVITE T Call-ID: ABC Requested-By: A Also: C Mark/Kelley [Page 31] Internet Draft Distributed Multipoint Conferences March 8, 2000 C->T: INVITE T Call-ID: ABC Requested-By: A Also: B {T} received both transfer requests so can respond. {B} and {C} ACK {T}. This causes {T} to disconnect his consultation link with {A}. T->B: 200 OK / Also: B, C T->C: 200 OK / Also: B, C B->T: ACK C->T: ACK {B} and {C} respond to {A} letting him know the transfer was a success. Since this was a consultation transfer, {A} should disconnect his link with {T}. Since this is a 200 response to a BYE message, {A} would also disconnect his link with {B} and {C}. This completes the transfer with consultation. B->A: 200 OK / Replaces: T C->A: 200 OK / Replaces: T A->T: BYE / Call-ID: AT Just like the attended transfer case, if one of the participants reject, {A} will receive an indication that the transfer failed and will stay connected with both the transferred call and the transferred-to participant. 5.1.1.4 Transfer and Hold This service varies slightly from the previous three. This is the only service where the transferring party does not disconnect from the call. Instead, the transferring party is either put on hold or may decide to stay active in the call. Since we are not disconnecting from the call, the initial message is an INVITE rather than a BYE message. The message flow is shown below, again using figure 3 as an example. {A} initiates the transfer and hold operation. {A} includes a media description which either stops the flow of media thereby asking to be put on hold, or indicates the previous media description to stay active in the call. A->B: INVITE B Call-ID: ABC Mark/Kelley [Page 32] Internet Draft Distributed Multipoint Conferences March 8, 2000 Also: T; call-id=blue Call-Disposition: transfer=hold A->C: INVITE C Call-ID: ABC Also: T; call-id=blue Call-Disposition: transfer=hold {B} and {C} attempt to connect with {T}. B->T: INVITE T Requested-By: A Call-ID: blue Also: C C->T: INVITE T Requested-By: A Call-ID: blue Also: B {T} accepts and responds to both. T->B: 200 OK / Call-ID: blue T->C: 200 OK / Call-ID: blue B->T: ACK / Call-ID: blue C->T: ACK / Call-ID: blue {B} and {C} responds and informs {A} the transfer was a success. {A} is now on hold. B->A: 200 OK Call-ID: ABC C->A: 200 OK Call-ID: ABC Now there are two full mesh calls. {A,B,C} comprise one call, {B,C,T} comprise the other. If {A} decided to stay active in the ABC call, both {B} and {C} would be active in two calls. If {A} decided to put himself on hold while invoking the transfer, {B} and {C} would still be active in two calls, but the ABC call would be on hold, while the BCT call is active. 5.1.2 Multi-Party Transfer A multi-party transfer refers to multiple transferred-to participants connected in another call. The transferring participant in one call is telling the transferred call to go over Mark/Kelley [Page 33] Internet Draft Distributed Multipoint Conferences March 8, 2000 to the transferred-to call. The transferring party must know who is in the transferred-to call in order to invoke this service. In order to know who is in the call, the transferring party must be a member of this call. So, the transferring party is a member of both the transferred and transferred-to call. Now, this is almost the same as a merge operation. After the operation completes, the transferring party disconnects from the merged call. Since the transferring party must be connected with both calls before invoking the operation, transfer with consultation is the only transfer type that really makes sense for this type of operation. Also, since the transferring party is consulting with both calls, he can communicate via the media stream that he is going to 'transfer' (i.e. merge then disconnect). This is how the users would distinguish between this from just a plain merge operation. 6 Split The split service allows one multi-party meshed call to split into two disjoint calls. This service allows large multi-party conferences to split up into smaller conferences to focus on specific topics. This is similar to a large meeting where people break up and move into separate conference rooms. The requirements for this service are the following: @ Any participant in a full mesh call may initiate the split. @ The participant initiating the split is called the splitter. @ The participants requested to split are called the splitting participants. @ The split call is the original call being split. @ The split-to call is the newly formed call containing the splitter and splitting participants. @ After the split operation, the splitter and splitting participants leave the split call. @ The splitting participants are a subset of the split call participants. @ Each splitting participant must be a member of the split call. @ Each splitting participant may accept or reject the split. @ Each splitting participant should know who the other splitting participants are. Mark/Kelley [Page 34] Internet Draft Distributed Multipoint Conferences March 8, 2000 @ The splitting participants that accept the split operation leave the split call and join the split-to call. @ The non-splitting participants and the splitting participants that rejected the split operation stay in the split call. @ Splitting (n-1) participants from an n-way call is viewed as a unanimous vote to expel the lone party. +------------------+ +-------------+ | {A} Splitter | | {A} {X...} | | | +-------------+ Split-To Call | {X...} Splitting | ==> | | +-------------+ | {Y...} Others | | {Y...} | +------------------+ +-------------+ Split Call Split Call 6.1 Split Implementation Implementation of this service is very similar to an add-party request. The splitter wishes to setup a new call. This is essentially the same as adding multiple parties at the same time to a new call. The difference is once the members accept they will disconnect their connection with the existing call. The splitter sends out INVITE messages indicating the intent to the splitting participants. The splitting participants are included in the Also header. The splitting participants first link up with the members in the Also header. During this link up, the existing split call legs are subsumed with split-to call legs. The splitter would receive a 200 OK response from each participant that accepted and successfully negotiated the new call parameters with other splitting participants. The splitter sends an ACK to each splitting participant indicating the split-to call has been established. The split-to call participants now send BYE messages to each participant left in the split call. This completes the split operation and we now have 2 separate calls. An example of how this takes place might be useful. Consider the following setup. There is a 6 party full mesh call with participants {A, B, C, D, E, F}. This is the split call (call-id blue). {A} decides he wants to split into the split-to call (call- id red) with {B, C, D}. The signaling for this intent would look like the following. Initially {A} notifies {B, C, D} of the intent to split. The Also header indicates the other splitting participants already contacted about the split-to call. The Replaces header indicates the endpoint should tear down the existing split call leg (blue leg) with {A}. The Replaces header is optional and used only if {A} wants to disconnect from the blue call. If {A} is willing to stay connected in the blue call, {A} won't include a Replaces header. The Call- Mark/Kelley [Page 35] Internet Draft Distributed Multipoint Conferences March 8, 2000 Disposition header indicates this is a split operation and if the endpoint wants to split, they must disconnect any legs they had on the call-id indicated after the operation succeeds. For this example, let's say {A, B, D} want to split and disconnect from the blue call. {C} wants to split but stay connected in the blue call. Below, {A} sends out the intent to split and let's {B, C, D} know that {A} wishes to disconnect from the split call (blue). A->B: INVITE B Call-ID: red Also: C, D Replaces: A; call-id=blue Call-Disposition: split; call-id=blue A->C: INVITE C Call-ID: red Also: B, D Replaces: A; call-id=blue Call-Disposition: split; call-id=blue A->D: INVITE D Call-ID: red Also: B, C Replaces: A; call-id=blue Call-Disposition: split; call-id=blue {B, C, D} would receive this split request and decide if they agree to the split, or if they want to stay connected with the existing call. Regardless of their decision, they must disconnect their blue leg with {A} as indicated by the Replaces header. Let's assume all the splitting participants wish to move into the split-to call. The signaling is included below. First, {B} receives the request and sends out triggered INVITEs to the others involved in the split operation. B->C: INVITE Call-ID: red Requested-By: A Also: A, D Replaces: B; call-id=blue Call-Disposition: split; call-id=blue B->D: INVITE Call-ID: red Requested-By: A Also: A, C Replaces: B; call-id=blue Call-Disposition: split; call-id=blue Mark/Kelley [Page 36] Internet Draft Distributed Multipoint Conferences March 8, 2000 Next, {C} receives both the original split request from {A} and the triggered request from {B}. {C} will accept {B}'s request and attempt to contact {D}. Remember, {C} wants to stay connected in the blue call, so will not include a Replaces header in the triggered request. C->B: 200 OK Call-ID: red C->D: INVITE Call-ID: red Requested-By: A Also: A, B Call-Disposition: split; call-id=blue Finally, {D} receives the original split request from {A} and both triggered requests from {B} and {C}. {D} would respond to {B} and {C} and respond to the original request from {A}. Since {A} and {B} both requested to disconnect their blue legs, {D} will tear down the media parameters for these legs. {C} did not request to disconnect from the blue call, but {D} wants to disconnect. To indicate this, {D} will include a Replaces header in the response to {C}. D->B: 200 OK Call-ID: red D->C: 200 OK Call-ID: red Replaces: D; call-id=blue D->A: 200 OK Call-ID: red Both {B} and {C} have received responses from everyone involved with the split operation so they may ACK these responses and respond to {A}. B->C: ACK Call-ID: red B->D: ACK Call-ID: red B->A: 200 OK Call-ID: red C->D: ACK Call-ID: red C->A: 200 OK Call-ID: red Mark/Kelley [Page 37] Internet Draft Distributed Multipoint Conferences March 8, 2000 Now everyone invited to split has successfully connected with the other splitting participants. Those that wished to disconnect from the blue call (i.e. {A, B, D}) will send BYEs to the other blue participants. {A,B,D}->{E,F}: BYE / Call-ID: blue {E,F}->{A,B,D}: 200 OK This completes the split operation. The result is a new split call (red) with participants {A, B, C, D} and the existing blue call now contains participants {C, E, F}. Note {C} is in both red and blue calls since {C} elected to stay in the blue call upon accepting the split request. 6.2 Split Issues This section describes the various different scenarios involved with the split service if not all splitting participants accept the operation. 6.2.1 Some Accept, Some Reject Let's say we have the same situation as above. The splitter {A} wants to split off forming a split-to call (call-id red) with {B, C, D}, leaving the {E, F} split call (call-id blue). {C} doesn't want to be part of this split operation. After {A} sends the initial INVITE messages requesting the split the following messages are sent: {B} accepted the split and tries to link up with the other members. B->C: INVITE Call-ID: red Requested-By: A Also: A, D Replaces: B; call-id=blue Call-Disposition: split; call-id=blue B->D: INVITE Call-ID: red Requested-By: A Also: A, C Replaces: B; call-id=blue Call-Disposition: split; call-id=blue {C} rejected the split and responds accordingly to {A} and {B}'s requests. Mark/Kelley [Page 38] Internet Draft Distributed Multipoint Conferences March 8, 2000 C->A: 4XX Reject Split Call-ID: red A->C: ACK Call-ID: red C->B: 4XX Reject Split Call-ID: red B->C: ACK Call-ID: red {D} accepts the split, responds successfully to {B}, and attempts to contact {C}. D->B: 200 OK Call-ID: red D->C: INVITE Call-ID: red Requested-By: A Also: A, C Replaces: D; call-id=blue Call-Disposition: split; call-id=blue {C} rejects the split request allowing {D} to complete and sends a successful response to {A}. C->D: 4XX Reject Split Call-ID: red D->C: ACK Call-ID: red D->A: 200 OK Call-ID: red {B} receives {D}'s response allowing {B} to complete the split sending a successful response to {A}. B->A: 200 OK Call-ID: red Now {A} sends ACKs to everyone that accepted the split. The splitting participants would proceed in sending BYEs to the rest of the split call (blue) participants. A->{B,D}: ACK {A,B,D}->{E,F}: BYE / Call-ID: blue {E,F}->{A,B,D}: 200 OK Mark/Kelley [Page 39] Internet Draft Distributed Multipoint Conferences March 8, 2000 Since {C} rejected, {C} will not send BYEs but stay connected in the split call (blue). The split call legs with {C} have already been severed by the INVITEs from {A, B, D} to {C}. The result is the split-to red call {A, B, D} and the split blue call {C, E, F}. 6.2.2 All Reject This is an interesting scenario. All the splitting participants reject the splitter. In the above example {A} is the splitter wishing to split with {B, C, D}. They all reject the split. If {A} decided to disconnect from the split call by including a Replaces header in the request, this would leave {A} in a partially connected mesh. {A} is connected in the split call with {E, F} but disconnected from {B, C, D} as a result of the Replaces header in the INVITE. To rectify this situation, {A} must either re-establish links with {B, C, D} or must disconnect with {E, F}. If {A} is unable to re-establish links with {B, C, D}, {A} must leave the call entirely. This leaves the splitter of the split request in an awkward position. If everyone declines the split operation, the splitter must be prepared to leave the call entirely should he be rejected upon trying to seek re-admission to the call. If {A} decided to stay connected with the blue call by not including a Replaces header, this situation would not happen. The splitting participants would reject {A}'s split request and still have a blue leg active with {A}. To prevent the above situation, {A} could always send a split request without a Replaces header. If one or more of the splitting participants accepts, {A} could change his mind at the end of the split operation and issue a BYE to all the participants connected on the blue call. 6.2.3 Disjoint Failure What happens when all splitting participants want to split but for some reason cannot connect with everyone? Consider the following example. {A, B, C, D, E, F} are in a blue call. {A} is the splitter asking splitting participants {B, C, D} to join him in the split-to red call. {A} is cautious because of the reasoning in 6.2.2 and does not include a Replaces header in the original request. {B, C, D} all wish to disconnect from the blue call and only maintain split-to red call legs. {A}'s initial request to {B, C, D}. A->{B, C, D}: INVITE Call-ID: red Also: B, C, D Call-Disposition: split; call-id=blue Mark/Kelley [Page 40] Internet Draft Distributed Multipoint Conferences March 8, 2000 {B} wants to split and disconnect from the blue call. {B} sends triggered INVITEs to {C} and {D}. B->{C, D}: INVITE Requested-By: A Call-ID: red Also: A, C, D Replaces: B; call-id=blue Call-Disposition: split; call-id=blue {C, D}->B: 200 OK Call-ID: red B->A: 200 OK Call-ID: red {C} and {D} must connect with each other to complete the split operation. For some reason there is a failure. C->D: INVITE Requested-By: A Call-ID: red Also: A, B Replaces: C; call-id=blue Call-Disposition: split; call-id=blue D->C: 4XX Failure Call-ID: red C->D: ACK Call-ID: red At this point there is a partial mesh formed with the red call. The following pairs of participants are connected in the split-to red call: {AB}, {BC}, {BD}. {AC} and {AD} legs have not been established yet ({C} and {D} haven't responded to {A}). Since {D} failed to connect with one of the endpoints, {D} is obligated to back out of the split. {D} maintains whatever blue legs are active and stays in the blue split call. Since {D} already responded to {B} with a success, {D} must now send a BYE to {B} indicating the failure. {D} also responds to the original request with a failure response. D->B: BYE Call-ID: red B->D: 200 OK Call-ID: red D->A: 4XX Failed Call-ID: red Mark/Kelley [Page 41] Internet Draft Distributed Multipoint Conferences March 8, 2000 A->D: ACK Call-ID: red Finally, to complete the split operation, {B} and {C} respond to the original request. Since both {B} and {C} want to disconnect from the blue call, they include the Replaces header. B->A: 200 OK Call-ID: red Replaces: B; call-id=blue C->A: 200 OK Call-ID: red Replaces: C; call-id=blue A->B: ACK Call-ID: red A->C: ACK Call-ID: red To finish the split transition, {B} and {C} must sent BYEs to the other blue participants. {B,C}->{E,F}: BYE Call-ID: blue {E,F}->{B,C}: 200 OK Call-ID: blue This completes the split operation. The split-to red call contains participants {A, B, C}, and the split blue call contains participants {A, D, E, F}. 6.3 Special Cases The following section describes the various scenarios that may take place while a split is in progress. There are four situations we must consider: add-party, merge, transfer, and split. We will discuss each case, show examples, and explain what additional mechanisms are needed to resolve the issues that arise during a simultaneous invocation of supplementary services. For each case we will use the following model for how the call is initially setup. The original call before any services are invoked is referred to as the "blue" call. This call contains the following participants: {A} -- the splitter. X = {X1...Xn} -- {A}'s splitting participants. Y = {Y1...Ym} -- the non-splitting participants. Blue = {A} + X + Y -- the participants in the split "blue" call. Mark/Kelley [Page 42] Internet Draft Distributed Multipoint Conferences March 8, 2000 The results of this split operation would be a split-to "red" call containing the splitter and splitting participants from the split call, and a "blue" call containing the left over participants. S < X -- the subset of participants accepting the split. Red = {A} + S -- the participants in the new "red" split-to call. Blue' = Y + (X - S) -- the participants still in the "blue" call. 6.3.1 Add-Party & Split This section explains what would happen if an add-party during split were to take place. One endpoint is initiating a split operation on the blue call while another endpoint initiates an add-party operation on the blue call. Using the above model we can see the different participants involved in the split operation. There are 3 separate sets where the add-party initiator may be located: {A}, X, or Y. Let's define the invited participant to be {P}. {P} is invited to the blue call. Consider the first case. The endpoint initiating the add-party operation is the same endpoint initiating the split operation. This situation could take place if {A} first initiated an add-party operation and then, before completion of the add-party, initiates a split. Since {P} has not yet been fully admitted into the blue call, {A} may not invite {P} to take part in the split. The message flow would proceed between {A} and set X asking them to split into the new call. At the same time {P} would be contacting participants from set X and set Y. Those participants in set Y would not cause any problems. This would be a normal add-party admission control operation and they could accept or reject {P} from joining the blue call. Participant {Xi} in set X can do the same. {Xi} can be in one of two states. Either {Xi} has already received and intend to accept the split request from {A}, or {Xi} has not received the split request (or rejected the split request) from {A}. In the first case, {Xi} should respond to {P} with a not in call response. {Xi} is currently trying to transition to the new red call and is disconnecting his blue legs. Now consider what would happen if participant {Xi} did accept (grant admission) to {P} and subsequently received the split request. {Xi} can elect to accept the split request. {Xi} will either complete the split setup before or after {P} sends the final ACK. In either case {Xi} should treat {P} as any other blue participant and disconnect the leg by sending a BYE message. {P} will interpret this as {Xi} leaving the call. The split operation does not effect {P} from gaining admission to the blue call. Presumably, {P} would contact some members of set X, be accepted by them, and later discover they have left the call. Other members of set X would respond saying they are no longer in the call. And finally, members of set Y would respond accepting {P} into the blue call. {P} would eventually return a final response to {A} indicating {P} was successfully added to the blue call. {A} has split from the blue call so would either send a BYE message to {P} Mark/Kelley [Page 43] Internet Draft Distributed Multipoint Conferences March 8, 2000 if the split succeeded before {P} was added, or a BYE message to {P} after receiving the final response from {P}. In either case, {P} should interpret the BYE as the single party {A} leaving the call, not a request to cancel the add-party request. The second case is where {A} is the split initiator, and {Xi} @ X is the add-party initiator. This is similar to the first case. Here {Xi} submits the add-party request to user {P} trying to add them to the blue call. Then {Xi} receives the split request. {Xi} can decide to accept the split and start that process, or decline the split. In the meantime {P} is trying to get added to the blue call. {P} may contact some participants in set X that have already received the split request, and may contact others that have not already received the split request. {P} would receive a similar response to case 1 -- some participants may accept and then later leave the blue call, others may state they are no longer in the call. The third set of participants - those in set Y - would accept {P} as in the normal add-party case. Finally, when {P} reports back to {Xi} it may have already received a BYE request from {Xi} indicating {Xi} had left the blue call, or shortly after sending the final response to {Xi}'s add-party request, would receive indication that {Xi} left the blue call. In either case, {P} is fully connected with the set of blue participants that were left over from the split operation. In the third case, {A} is again the split initiator, and {Yj} ~ Y is the add-party initiator. This is the simplest case since the add- party initiator {Yj} will not leave the call in the middle of the add-party operation. While {P} is being added to the call, {P} would contact endpoints of set X. Those endpoints would have either received the split request, or not. The X endpoints would respond the same as in case one or two. {P} would again receive some responses granting him admission, and then shortly after receive a BYE request indicating an X endpoint left the call. After {P} contacts all endpoints, {P} sends a final response to {Yj} completing the add-party operation. In the meantime, {A} and the set of endpoints in X are busy performing the split. At the end of the split operation, all the blue participants would receive a BYE request from those participants that split. As demonstrated in the above scenarios, an add-party during a split operation does not cause a problem. 6.3.2 Merge & Split Before we start describing this scenario, let's define the participants involved in this scenario. Above we've defined the participants involved in the split operation. Below are the additional participants needed to allow for a merge operation. Blue = {A} + X + Y -- the original blue call. Mark/Kelley [Page 44] Internet Draft Distributed Multipoint Conferences March 8, 2000 Z = {Z1...Zp} -- the set of participants in the green call. {B} ~ Z x Blue -- the participant initiating the merge operation. {B} is a member of both the green and the original blue calls. {B} has a couple choices on how to complete the merge. {B} could choose either the green or the blue call to be the home call. {B} may have been selected to be part of the split operation ({B} ~ X) or {B} may not be selected ({B} ~ Y). Given these options we have four possibilities for how a merge during split could take place. Merge Home {B} ---------- --- (1) Blue X (2) Blue Y (3) Green X (4) Green Y In the first scenario (1), we have {A} trying to split the blue call into a blue / red call. In addition, {B} is trying to merge the green call into the blue call. {B} is also asked to split and move into the red call. {B} can only issue the merge operation if he does not received any signaling about the split, or has rejected the split operation. If {B} was in the process of splitting and decided at the last minute to merge the green call into the blue call, {B} may have already disconnected from several blue participants thereby providing a shorter list of participants the green call participants would need to connect with. This list may be participants that are presently leaving the call because they've been asked to split or they have sent a BYE for other reasons. This would lead to a case where the green call participants convert to a blue call failing to link up with the other members of a blue call. This leads to 2 disjoint blue calls. To prevent this situation, we require the participants in the process of a split refrain from invoking a merge. {A} sends the split request to participants in set X. At the same time, {B} sends a merge request to participants in set Z. Participants in set X are trying to split, sending messages to each other. Participants in set Z are trying to merge, sending messages to members of the original blue call. The signaling for these four types of messages is illustrated below. Mark/Kelley [Page 45] Internet Draft Distributed Multipoint Conferences March 8, 2000 {A} X {B} Z Y | | | | | |-+-split--->| |---merge--->| | | \---------------------->| | | | | | | | | |<----+-merge-----------+--| | |<----------------/ \--------->| | | | | | | |--split-\ | | | | |<-------/ | | | | | | | | Upon receipt of the split request, set X and {B} can decide whether or not to accept the split. If the split is accepted, the splitting process begins. These endpoints would continue sending messages renegotiating the session and changing legs with other split participants. While this is happening, set Z received the merge request. If the Z participants accept the merge, they go about their way and proceed to try and gain admission into the original blue conference. Z participants would send messages to {A}, set X, and set Y trying to get accepted in the conference. Some of these members, notably set X and {A}, are involved in the split operation. They would respond indicating they are no longer in the blue call (they technically are, but in the process of leaving). The Z participants would continue merging into the blue call unaffected by the leaving participants (part of set X and {A}). After {B} sent out the merge request, {B} received the split request. At this point {B} can decide to accept the split. {B} would simply act as any other split participant. After linking up with the other split users, {B} would send a BYE to anyone in the blue call. This includes all the Z participants that he sent a merge request too. The Z participants may not be finished trying to merge. This is ok, and the Z participants would remove {B} from the blue call treating this as if {B} left the call. The Z participants would continue with the merge request. In the second scenario (2) the blue call is again the home call of the merge. {B} is trying to merge the green call into the blue call. This time {B} is not requested to split with the {A} and set X participants. This makes this scenario a little simpler. The merge participants in set Z will still try and contact {A}, set X, and set Y. Some members of X would have already received a split request and respond with a not in call response. Other participants of X could initially accept but later send a BYE after accepting the split request. The split would proceed as usual and the merge would proceed with a few not in call responses, but would eventually get connected with anyone that wasn't asked to split away from the blue call. In the third scenario (3) the green call is the home call and {B} has been requested to split. {A} has sent the split request Mark/Kelley [Page 46] Internet Draft Distributed Multipoint Conferences March 8, 2000 approximately the same time {B} has sent the merge request. The participants in set X will receive both merge and split requests. Some of these participants will receive the merge request first, others the split request. Those receiving the split request may decide to accept or reject the split. If they accept and start the process of splitting, they must reject the merge request. The participant is splitting away from the blue call and therefore should reject any further messaging related to the blue call. If the participant first accepted the merge request to move from blue to green, this participant is also attempting to leave the blue call. This time the participant is merging into the green call. Since the participant must first get admission from the green call participants, the merge is not yet complete. Because of this, it is ok for a participant to accept the split request and abandon the merge in progress. Again, as in case (1), {B} has the option of accepting or rejecting the split operation. {B} may accept this, and disconnect from the blue call. Since {B} is disconnecting from the blue call anyway, nothing really changes. {B} stays in the green call, other blue participants may have joined the green call because of the merge. In the fourth scenario (4) the green call is again the home call and {B} has not been asked to split. This is similar to case (3) discussed above and most everything will be the same. {B} will not receive a split request making this operation even more transparent. The users leaving the blue call to split into the red call will appear as participants leaving the call or rejecting the merge. As in case (3) the participants in set X must decide whether to split or merge depending on which message they receive first. This is handled the same way as case (3). 6.3.3 Transfer & Split There are two modes of transfer: transfer to a single party and transfer to another call. Transferring to another call during a split is essentially the same as a merge and split operation. The only difference is the transferring party issues a BYE upon completion of the merge. Because of the similarities, the focus is on transferring to a single participant during a split operation. Using the same definitions for the split participants, the additional participants involved in the transfer operation are defined below: {B} -- the participant initiating the transfer operation. {B} ~ X (invited to split) or {B} ~ Y (not invited to split). {T} -- the transferred-to participant. {B} is issuing the transfer operation on the blue call. At the same time {A} is issuing a split operation on the blue call. Mark/Kelley [Page 47] Internet Draft Distributed Multipoint Conferences March 8, 2000 6.3.3.1 Blind Transfer Once {B} issues the transfer, {B} is out of the process. {B} will get responses from each participant in the blue call to complete the blind transfer request. If {B} were to receive the split operation after issuing the transfer, {B} must reject the split. {B} is no longer involved with the blue call and trying to leave the call. If {B} received and accepted the split operation first, {B} must not initiate a transfer operation. {B} is no longer in the call after accepting the split and therefore cannot transfer the call. During the transfer, some participants (those in set X) receive both a split and transfer request. These participants can accept the transfer request, then later accept the split request, but cannot accept the split request, and then transfer. Once accepting the split request, the participant is no longer associated with the call and should return a not in call response. 6.3.3.2 Attended Transfer The only difference between blind transfer and attended transfer is when {B} is actually removed from the call. However, both types of transfer involve similar messaging. {B} sends BYE messages in both cases. After sending a BYE, {B} should assume he is out of the call and therefore reject any further request pertaining to the call. If {B} issues the attended transfer request and then receives a split request, {B} must decline the split with a not in call response. During the transfer some participants may receive a split request then transfer. This is handled the same way in the blind transfer during split scenario. 6.3.3.3 Transfer with Consultation Transfer with consultation is a three-part operation. First {B} must contact and communicate with the transferred-to participant {T}. After the consultation, {B} issues a merge of the two calls. Finally, {B} leaves the merged call. The first step is not interrupted in any way by a split operation. This is a regular two party call being setup. After the consultation, {B} issues a merge operation. The same rules for merge during split applies. Finally, {B} leaves the merged call. This is a simple leave call operation and is not affected by a split operation that may be taking place. 6.3.3.4 Transfer and Hold Finally, the last mode of transfer to consider is transfer and hold. Transfer and hold is different from the previous three transfer configurations. The transferring party {B} does not leave the call upon completion of the transfer. The transfer and hold instructs the transferred parties to connect with another participant {T}. When finished, the transferred participants are connected with {T} in a new call. The original call with {B} is still active. Because Mark/Kelley [Page 48] Internet Draft Distributed Multipoint Conferences March 8, 2000 of this, if a split is happening at the same time as a transfer, {B} could issue the transfer, then receive and decide to accept the split operation. At this point, {B} could abandon the transfer & hold and decide to split. {B} would proceed with a split and then send a BYE to those participants involved with the transfer. 6.3.4 Split & Split The participants involved in a split during split operation are outlined below: {A} -- the participant initiating the blue-to-red split request. {B} -- the participant initiating the blue-to-green split request. W = {W1...Wm} -- the participants only invited to split with {A}. Wa ~ W -- the participants that accepted {A}'s split request. Wr ~ W -- the participants that rejected {A}'s split request. X = {X1...Xn} -- the participants only invited to split with {B}. Xb ~ X -- the participants that accepted {B}'s split request. Xr ~ X -- the participants that rejected {B}'s split request. Y = {Y1...Yp} -- the participants invited to split by both {A} and {B}. Ya ~ Y -- the subset of participants that elected to split with {A}. Yb ~ Y - Ya -- the subset of participants that elected to split with {B}. Yr = Y - Ya - Yb -- the subset of participants that rejected both split. Z = {Z1...Zq} -- the participants not invited to split by either {A} or {B}. Blue = {A} + W + X + Y + Z -- the participants in the original "blue" call. Blue' = Wr + Xr + Yr + Z -- the participants in the blue call after both splits. Red = {A} + Wa + Ya -- the participants in the red call after the split. Green = {B} + Xb + Yb -- the participants in the green call after the split. Note that a couple of the sets (Y and Z) may be empty. Set Y would be empty if there is no overlap between the two splits. Set Z would be empty if all the participants are covered in at least one of the split modes. The only problem with a split during split operation occurs with the participants that are invited to split into multiple calls (set Y participants). Some Y participants would receive the split request from {A}, then the split request from {B}. Others would receive {B}'s split request, then {A}'s. Participants in set Y can either accept or reject the split request. As mentioned earlier in this draft, if a participant accepts a split request and then later receives another request on the call he is splitting from, he must reject that request. This means if participants in set Y accepted Mark/Kelley [Page 49] Internet Draft Distributed Multipoint Conferences March 8, 2000 the first split request they received, they must reject the second split request. Other than that, the split requests don't interfere with each other. During the split a user would either accept it, reject it, or respond with a not in call response. 7 Crossing INVITEs In section 8.4 of [2], the authors recognize the possibility that triggered INVITEs between two signaling entities that are in the process of joining a multipoint conference may cross "on the wire", and propose a simple implementation approach for resolving the situation. The issue is a new flavor of an old problem that has in other contexts been referred to as "glare", "resource contention", or "collision." 7.1 Back off A common approach to such problems is for the contending parties to abandon ("back off") their attempts to use the resource, and try again after a short delay. The delay should be random in order to keep the parties from simply repeating the colliding attempts some duration later. This approach is commonly used in daily conversation when two speakers both attempt to speak at once. Typically, the parties cease speaking and begin again after a more or less random duration (although in face-to-face communications the process is aided by both short verbal and non-verbal cues.) Variants of the back off technique are in use in numerous engineering contexts; the [2] proposal adapts the technique to the particulars of the IP telecommunications scenario. The problem with approaches that rely upon backing off and retrying later is the introduction of additional latency. In many situations this additional latency can be ignored, particularly if the introduced delay can be made short enough or the incidence rate of such scenarios is sufficiently slight. Unfortunately, this is not the case when considering INVITE collisions in full mesh multipoint conferences. While sufficiently improbable in ordinary scenarios, various conference services are implemented using algorithms that markedly increase the likelihood of crossing invitations. Furthermore, since signaling across IP networks already involves not insignificant latency, the introduced back off delay must itself be significant enough to ensure that the difference between the randomly selected endpoint delays will generally exceed the time required to propagate the INVITEs across the network. This means that the introduced delay will be measurable. 7.2 Deference Mark/Kelley [Page 50] Internet Draft Distributed Multipoint Conferences March 8, 2000 An alternative to random back offs is for the endpoints to share a mechanism for deciding which of the conflicting attempts will be successful and which should be abandoned. If there is a mechanism by which both endpoints are certain to come the same conclusion, then back off can be avoided altogether. We term this approach "deference", noting that it is routinely practiced in verbal communication when one of the communicating parties has a lower status than the other, and hence defers to the former party. Successful application of deference techniques to the problem of resource contention requires that the contending parties share a common understanding of which of the two parties is expected to defer in any particular scenario. While deference is easily applied to resolve resource contention when the relationship between two specific parties is known explicitly by both parties (e.g. boss and employee), it is less apparent how to apply it when the parties were heretofore unknown to each other. Here, deference mechanisms depend upon the consistent application of a set of "deference rules" by each of the contending parties. The anachronistic adage "ladies first" is an example of this kind of technique. We term this "algorithmic deference". Algorithmic deference assumes that there is a set of relevant observable data to which the deference algorithms may be applied. For example, the "ladies first" rule cannot be applied unless the gender of the contending parties is known. 7.3 A deference algorithm for crossing INVITEs The "hard part" in crafting a rule-based deference algorithm lies in determining the rule or rules that may be efficiently applied to the available data at each endpoint with unambiguous result. For the crossing INVITE problem, the set of data available to any such rule(s) is rather tightly constrained, consisting of just the content carried within the INVITE messages themselves. Although it is tempting to propose a technique that involves comparison of the endpoints' IP addresses, these addresses may be modified in transit (NAT), rendering the values used for comparison different at each endpoint. We propose to use the URIs passed in the To and From headers of the INVITE messages as the basis for comparison. The party whose URI is the lesser of the URIs, hereafter referred to as the master, (as evaluated by ordinary string comparison) MUST reply to the request from the other party, hereafter the slave, with either a provisional 1yy Pending Request or 4zz Colliding Request response. Use of 4zz indicates that this request has been abandoned in favor of a request Mark/Kelley [Page 51] Internet Draft Distributed Multipoint Conferences March 8, 2000 going the other way. Rather than immediately responding to the slave request with 4zz, it is permissible for the master to hold the slave request until it has been determined whether or not the slave accepted the master request; in this case the slave should use the provisional 1yy response to indicate the status of the slave request. This option allows the slave request to also be attempted in the event that the master request is not successful. 7.4 Proactive application of deference If it is known that a resource contention situation will develop, it may be possible to apply deference techniques proactively, thereby avoiding the development of contention altogether. However, while crossing INVITEs may be expected to occur with some regularity in full mesh conferences, we do not currently recommend proactive application of deference; the slave in a signaling relationship should continue to send out INVITEs even when a crossing INVITE is expected in order to ensure that signaling between the two endpoints occurs as rapidly as possible. 7.5 Egalitarian deference Certain deference algorithms, including the one proposed herein, exhibit a predictable and continual preference for a particular party over another. Needless to say, such unequal access to resources is not always acceptable. In this case, the resource in contention is the opportunity to propose the types and formats of the media that will be used in communication between the contending endpoints. While we do not believe that either party is likely to care which of the parties is cleared to make the communications proposal, it is possible to imagine scenarios where that would not be the case. To deal with such situations, the present algorithm could be modified to introduce a semi-random element into the equation (perhaps a computation involving either the Cseq or Call-Id headers could cause the determination algorithm to flip-flop between preferring the lesser and greater URIs.) Or a new header could be introduced in which the parties would have the equivalent of a "rock-paper-scissors" battle, albeit with more conclusive results (i.e. each endpoint places a randomly generated number in the Deference header. If the sum of the numbers is odd, the request with the lower number is preferred ... ) At present we recommend use of the simpler, non-egalitarian algorithm. We leave alternative proposals, and a determination of whether or not they are desirable, for further study. Mark/Kelley [Page 52] Internet Draft Distributed Multipoint Conferences March 8, 2000 8 Syntax and Semantics The following section describes some new headers and response codes introduced in this draft. Some existing headers defined in [2] have slightly different semantics in this draft. These differences are outlined here as well. 8.1 Headers The following section outlines the headers introduced or changed in this draft. 8.1.1 Also Header The Also header was defined in [2]. The only change proposed in this draft was the removal of the status and version params. The Also participant list contains those participants that we believe to either be connected in the call, or attempting to join the call at the time the Also header is formulated. This ensures a full mesh will be setup. Any participants that used to be in the call, but have since left, are not included in the Also header. The Also header is included in INVITEs, BYEs, and INVITE responses. Not all messages require an Also header. As a general rule, they are used only when necessary. For example, an Also header is used in an INVITE response to inform a participant joining a call the full set of participants known to be connected in the call. However, the joining member does not include an Also header in triggered INVITEs sent to existing members of the call. 8.1.2 Replaces Header The Replaces header was defined in [2] and syntax remain unchanged. The header may be either a request or a response header. The Replaces header is used in a merge or split operation in an INVITE request or response. Participants receiving a Replaces header in a message treat this the same as if they received a BYE request from the participant specified in the header thereby disconnecting the call leg between the two endpoints 8.1.3 Call-Disposition Header The Call-Disposition header indicates what type of request is sent. This allows the recipient to distinguish between split, merge, and transfer requests. The header also conveys additional information such as what other call is involved (for a split or merge) or what kind of transfer is being invoked. Mark/Kelley [Page 53] Internet Draft Distributed Multipoint Conferences March 8, 2000 Call-Disposition = "Call-Disposition" ":" 1#CD-Type CD-Type = CD-Transfer | CD-MergeSplit CD-Transfer = "transfer" "=" 1#( "attended" | "consultation" | "hold" ) CD-MergeSplit = 1#("merge" | "split") call-id-param call-id-param = ";" "call-id" "=" token 8.1.4 Status Header The Status header is used in conjunction with responses (such as 1xx Seeking Admission) to a request, in order to report responses to triggered requests arising from that original request. This gives the originator of a request visibility into the progress of the responding endpoint's attempts to fulfill the request. Status = "Status" ":" 1#Status-List Status-List = Status-Code ":" 1#name-addr 8.1.5 Rejected-By Header The Rejected-By header should accompany the 4ww Admission Failed response when the reason for admission failure included rejection by members of the conference. The header lists the parties that rejected the party's attempt to gain admission to the conference. Rejected-By = "Rejected-By" ":" 1#name-addr 8.1.6 Unresponsive Header The Unresponsive header can accompany any request message or any response to a request whose fulfillment depends upon triggered requests directed at other endpoints. The header lists any parties that have not responded to a party's requests, either with provisional or final responses. Unresponsive = "Unresponsive" ":" 1#name-addr 8.2 Response Codes The following response codes were introduced in this draft. 8.2.1 1xx Seeking Admission The party desires to communicate, and is seeking admission to the conference from other members of the conference. The response MAY Mark/Kelley [Page 54] Internet Draft Distributed Multipoint Conferences March 8, 2000 contain a Status header listing the admissions-related responses most recently received from other conference members. 8.2.2 1yy Pending Request The party had dispatched a crossing INVITE request prior to receiving this INVITE and is waiting to respond to this request until the peer first responds to its request. This response SHOULD only be issued when the crossing request is determined (by a commonly accepted algorithm) to take precedence over this request. 8.2.3 4ww Admission Failed The party desired to join the conference, but could not gain admission with all of the other conference members. The response should include Rejected-By or Unresponsive headers (or both) identifying why the attempt to gain admission failed. 8.2.4 4zz Colliding Request The party had already dispatched a crossing INVITE request prior to receiving this invite and is consequently denying this request. This response SHOULD only be issued when the crossing request is determined (by a commonly accepted algorithm) to take precedence over this request. 9 Acknowledgements We would like to acknowledge the following people for their discussions on this paper: Jonathan Rosenberg, Mark Grosen, and Steve Magnell. 10 Author's Addresses Kalon Kelley Dialogic Santa Barbara Labs 201 Mentor Drive, Suite 100 Santa Barbara, CA 93111 USA e-mail: Kalon.Kelley@dialogic.com Jeff Mark Dialogic Santa Barbara Labs 201 Mentor Drive, Suite 100 Mark/Kelley [Page 55] Internet Draft Distributed Multipoint Conferences March 8, 2000 Santa Barbara, CA 93111 USA e-mail: Jeff.Mark@dialogic.com 11 Bibliography [1] H. Schulzrinne and J. Rosenberg, "SIP Call Control Services", Internet Draft, Internet Engineering Task Force, June 1999. Work in progress. [2] H. Schulzrinne and J. Rosenberg, "SIP Call Control Services", Internet Draft, Internet Engineering Task Force, June 1999. Work in progress. [3] S. Bradner, "Key words for use in RFCs to indicate requirement levels," Request for Comments (Best Current Practice) 2119, Internet Engineering Task Force, Mar. 1997. [4] J. Moy, "OSPF Version 2," Request for Comments 2328, Internet Engineering Task Force, April 1998. Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Mark/Kelley [Page 56]