One document matched: draft-mark-sip-dmcs-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-23 23:25:53 |