< draft-ietf-mmusic-sip-cc-00.txt   draft-ietf-mmusic-sip-cc-01.txt >
Internet Engineering Task Force MMUSIC WG Internet Engineering Task Force MMUSIC WG
Internet Draft Schulzrinne/Rosenberg Internet Draft Schulzrinne/Rosenberg
draft-ietf-mmusic-sip-cc-00.txt Columbia U./Bell Laboratories draft-ietf-mmusic-sip-cc-01.txt Columbia U./Bell Laboratories
March 13, 1998 June 17, 1999
Expires: August 1, 1998 Expires: December, 1999
SIP Call Control Services SIP Call Control Services
STATUS OF THIS MEMO STATUS OF THIS MEMO
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft and is in full conformance with
documents of the Internet Engineering Task Force (IETF), its areas, all provisions of Section 10 of RFC2026.
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. 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 Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as ``work in progress''. material or to cite them other than as work in progress.
To learn the current status of any Internet-Draft, please check the The list of current Internet-Drafts can be accessed at
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow http://www.ietf.org/ietf/1id-abstracts.txt
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Distribution of this document is unlimited. The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
ABSTRACT Abstract
This document describes the org.ietf.sip.call extensions This document describes a set of extensions to SIP which allow for
to the Session Initiation Protocol (SIP). The document various call control services. Example services include blind
also describes how standard telephony services can be transfer, transfer with consultation, multi-party calls, bridged
implemented in SIP. conferences, and ad-hoc conferencing. The services are supported in a
fully distributed manner, so that they can be provided without a
central conference server. However, a SIP proxy can act as a
conference server to provide these services. For the various services
described here, we overview the requirements for the service, and
specify the protocol functions needed to support it. We then define a
basic set of SIP primitives which can be used to construct these
services, and others.
1 Terminology 1 Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED", In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and
indicate requirement levels for compliant SIP implementations. indicate requirement levels for compliant SIP implementations.
2 Introduction 2 Introduction
This document describes the org.ietf.sip.call extensions to the The Session Initiation Protocol (SIP) [2] is a signaling protocol
Session Initiation Protocol (SIP) [2]. When using the extensions used for the initiation of multimedia sessions. SIP also defines
described here, the client MUST include the extension name in a mechanisms for termination of sessions using the BYE method. However,
Require header. SIP has less support for signaling of services that take place during
the call itself. These kinds of services can be broken into several
classes:
3 Headers Session Control Services These services relate to the media session.
Examples include floor and chair control (which controls who can
send/receive data in the session), hold, and mute.
type ACK BYE INV OPT REG Call Control Services These services relate to participant
_________________________________________________________ management. These services are all built on the basic blocks of
Accept-Location R - - o o - adding and removing users from a call. Examples include transfer
Also R - - o o - (the simultaneous removal and addition of a member from a call),
Also r - - o o - multi-party calling, call bridging, and ad-hoc bridged
Call-Disposition R - o o - - conferences.
Replaces R - - o o -
Replaces r - - o o -
Requested-By R - - o o -
Requested-By r - - o o -
Table 1: Summary of header fields. "o": optional, "m": mandatory, "- This document describes extensions to SIP for providing call control
": not applicable, "R': request header, "r": response header, "g": services. The services are supported in a fully distributed manner,
general header, "*": needed if message body is not empty. A numeric so that they can be provided without a central conference server.
value in the "type" column indicates the status code the header field However, a SIP proxy can act as a conference server to provide these
is used with. services. Our aim is to provide a general set of tools which can be
used to construct, at a minimum, a core set of services, but be
potentially useful as building blocks for future services. To
accomplish this goal, we begin by overviewing the requirements for
each of the core services. This includes its basic functional
requirements and its security requirements. Then, we overview the
technical issues in providing these services, and outline the basic
primitives that we have concluded are needed. The next section
formally defines these primitives through new headers and UA
behavior.
3.1 Accept-Location 3 Services
The Accept-Location request header allows the caller to provide We overview the services which we desire to support at a minimum. For
hints to proxy and redirect servers. It uses the same parameters as each, we define the requirements for the service, with a particular
the Location header (Section 3.4). focus on security. Security is a primary concern for many of these
services. As such, the following general principles apply:
3.2 Also o Parties involved in some service should be able to
cyryptographically verify the identity of the other parties in
the service
The Also request and response header advises the recipient to issue o Parties involved in some service should have a choice about
INVITE requests to the addresses listed. Each of these invitations their participation in the service
SHOULD contain a Requested-By header that contains the From field
of the message containing the Also field. The Also header MUST only
be processed by the calling or called user agent, not by any
intermediate proxy or redirect servers.
If a message contains both Also and Replaces, the invitations o Parties involved in some service should know what the service
requested in the Also header MUST be completed, successfully or not, being invoked is
before the terminations requested in the Replaces header.
Also = "Also" ":" 1#( SIP-URL | URI ) [ comment ] These three basic requirements are a natural consequence of an
Example header: architecture where endpoints are assumed to be intelligent. Note,
however, that just because the protocol provides information and
gives choices, does not mean all implementations need to take
advantage of this. Thin and dumb endpoints can choose not to provide
information to the end users, and can choose not to provide choices
to them. This has the advantage of enabling one common protocol for
smart and dumb endpoints alike.
Also: sip://jones@foo.com, sip://mueller@bar.edu 3.1 Blind Transfer
If A, B and C are end points, the following is a typical scenario: In the blind transfer service, two parties are in an existing call.
One party, the transferring party , wishes to terminate the call with
the other party the transferred pary , and at the same time, transfer
them to another party, the transferred-to party
A -> B: INVITE B SIP/2.0 ----------------
Call-ID: 19971214T123503.33@A -> | Transferred-to |
Also: C / | party |
From: A / ----------------
B -> A: SIP/2.0 200 OK /
Call-ID: 19971214T123503.33@A /
From: A -------------- ----------------
B -> C: INVITE C SIP/2.0 | Transferred |<------------------------| Transferring |
Call-ID: 19971214T123503.33@A | party | | party |
From: B -------------- ----------------
Requested-By: A
C -> B: SIP/2.0 200 OK
Call-ID: 19971214T123503.33@A
From: B
If G is a group address with members X through Z, a group invitation Figure 1: Transfer Service
may proceed as follows:
A -> G: INVITE G SIP/2.0 Some of the requirements for this service include:
From: A
Call-ID: 19971214T124523.00@A
G -> A: SIP/2.0 200 OK o The original call terminates regardless of whether the
From: A transfer succeeds or not.
Call-ID: 19971214T124523.00@A
Also: X, Y, Z
A -> X: INVITE X SIP/2.0 o The transferring party does not know whether the transfer
From: A succeeds or not.
Call-ID: 19971214T124523.00@A
Requested-By: G
A -> Y: INVITE Y SIP/2.0 o The transferred party should be able to know that they are
From: A being transferred
Call-ID: 19971214T124523.00@A
Requested-By: G
A -> Z: INVITE Z SIP/2.0 o The transferred party should be able to know to whom they are
From: A being transferred
Call-ID: 19971214T124523.00@A
Requested-By: G
The Also header makes it possible to create full meshes o The transferred party should be able to decide whether to
(generalized "three-way" calling) and supports the accept or reject the transfer
resolution of group addresses. Unlike the Location header,
which enumerates alternatives to be tried, the Also header
lists addresses to be all invited.
3.3 Call-Disposition o If the transferred party rejects the transfer, the call with
the transferring party still terminates
The Call-Disposition request header field allows the client to o The transferred party should be able to verify that they are
indicate how the server is to handle the call. The following options being transferred by the transferring party
can be used singly or in combination:
all: If the user part of the SIP request address identifies a group o The transferred-to party should know that they are being
rather than an individual, the " all" feature indicates to a transferred-to
proxy or redirect server that it should resolve the address to a
list of group members and return a 300 (Multiple Choices)
response. The list of group members is contained in an Also
header.
do-not-forward: The "do-not-forward" request prohibits proxies from o The transferred-to party should be able to know the identity
forwarding the call to another individual (e.g., the call is of the transferring party
personal or the caller does not want to be shunted to a
secretary if the line is busy.)
queue: If the called party is temporarily unreachable, e.g., because o The transferred-to party should be able to accept or reject
it is in another call, the caller can indicate that it wants to the transferred call just like any other call
have its call queued rather than rejected immediately. If the
call is queued, the server returns "181 Queued" (see Section
4.1). A pending call be terminated by a SIP BYE request.
do-not-respond: The do-not-respond directive indicates to the callee 3.2 Transfer and Hold
that it should not issue a response, informational or final.
This may be used to send invitations to multicast groups.
Maybe the combination of do-not-respond and all could be This service is a variation on blind transfer. The difference is that
used for group invitations to larger lists? the transferring party does not leave the call with the transferred
party. If the service is successful, the transferred party is
involved in two calls - one with the transferring party, and one with
the transferred to party. Many of the requirements are similar. The
requirements for the service are:
Call-Disposition = "Call-Disposition" ":" 1#( "all" | "do-not-forward" o The call between the transferring and transferred parties
| "queue" | "do-not-respond" ) remains active, regardless of the status of the new call
between the transferred and transferred-to parties.
Example: o The transferring party does not know whether the transfer
succeeds or not.
Call-Disposition: all, do-not-forward, queue o The transferred party should be able to know that they are
being transferred
3.4 Location o The transferred party should be able to know to whom they are
being transferred
This document adds extension parameters to the Location header. o The transferred party should be able to decide whether to
accept or reject the transfer
extension-name = token o If the transferred party rejects the transfer, the call with
extension-value = *( token | quoted-string | LWS | extension-specials) the transferring party remains unchanged
extension-specials = < any element of tspecials except <"> >
language-tag = < see [H3.10] >
priority-tag = "urgent" | "normal" | "non-urgent"
service-tag = "fax" | "IP" | "PSTN" | "ISDN" | "pager"
media-tag = Internet media type [ "/" subtype ]
feature-list = "voice-mail" | "attendant" | "permanent"
extension-attribute | "class" "=" ( "personal" | "business" ) o The transferred party should be able to verify that they are
| "description" "=" quoted-string being transferred by the transferring party
| "duplex" "=" ( "full" | "half" |
"receive-only" | "send-only" )
| "features" "=" 1# feature-list
| "language" "=" 1# language-tag
| "media" "=" 1# media-tag
| "mobility" "=" ( "fixed" | "mobile" )
| "priority" "=" 1# priority-tag
| "service" "=" 1# service-tag
class: The class parameter indicates whether this terminal is found o The transferred-to party should know that they are being
in a residential or business setting. (A caller may defer a transferred-to
personal call if only a business line is available, for
example.)
description: The description field further describes, as text, the o The transferred-to party should be able to know the identity
terminal. It is expected that the user interface will render of the transferring party
this text.
duplex: The duplex parameter lists whether the terminal can o The transferred-to party should be able to accept or reject
simultaneously send and receive ("full"), alternate between the transferred call just like any other call
sending and receiving ("half"), can only receive ("receive-
only") or only send ("send-only"). Typically, a caller will
prefer a full-duplex terminal over a half-duplex terminal and
these over receive-only or send-only terminals.
features: The feature list enumerates additional features of this o The transferred-to party should not be able to ascertain,
address. The "permanent" flag indicates that this address is a through signaling messages, that the transferring party is
new, permanent address. When used for registration, the server still communicating with the transferred party. In other
SHOULD return a 301 status instead of 302. words, blind transfer and transfer and hold appear identical
to the transferred-to party.
language: The language parameter lists, in order of preference, the 3.3 Transfer with Consultation
languages spoken by the person answering. This feature may be
used to have a caller automatically select the appropriate
attendant or customer service representative, without having to
declare its own language skills.
media: The media tag lists the media types supported by the terminal. This service is similar to blind transfer. However, the transferring
Media types can be the standard Internet media types ("audio", party first contacts the transferred-to party to approve the transfer
"video", "text", "application"), optionally followed by a through multimedia communication. Pending approval, the transferring
subtype (e.g., "text/html"). In addition, the type party then simultaneosly disconnects from the transferred-to and
"application/email" is defined. transferred parties, and connects the transferred and transferred-to
parties. The transferring and transferred parties stay connected if,
for some reason, the transfer fails.
mobility: The mobility parameter indicates if the terminal is fixed The requirements for this service are more complex. They include:
or mobile. In some locales, this may affect voice quality or
charges.
priority: The priority tag indicates the minimum priority level this o The transferring party should not need to know ahead of time
terminal is to be used for. It can be used for automatically that they will transfer the call to the transferred-to party.
restricting the choice of terminals available to the user. In other words, it should not be neccesary to know ahead of
time that the consultation call (between the transferring and
transferred-to parties) is for the purposes of a transfer.
service: The service tag describes what service is being provided by o The transferred party should be able to know that they are
the terminal. being transferred
Attributes which are unknown should be omitted. New tags for class- o The transferred party should be able to know to whom they are
tag and service-tag can be registered with IANA. The media tag uses being transferred
Internet media types, e.g., audio, video, application/x-wb. This is
meant for indicating general communication capability, sufficient for
the caller to choose an appropriate address.
Location: sip://watson@worcester.bell-telephone.com ;q=0.7 o The transferred party should be able to decide whether to
;service=IP,voice-mail accept or reject the transfer
;media=audio+video+application/x-wb ;duplex=full
Location: rtsp://tape.bell-telephone.com?watson482178 ;q=0.6
;service=IP,voice-mail
;media=audio+video ;duplex=full
Location: phone://1-415-555-1212 ;q=0.5
;service=ISDN;mobility=fixed;
language=en,es,iw
Location: phone://1-800-555-1212 ;q=0.2
;service=pager;mobility=mobile;
duplex=send-only;media=text; priority=urgent;
description="For emergencies only"
Location: mailto:watson@bell-telephone.com ;q=0.1
;media=application/email
Location: http://www.bell-telephone.com/~watson ;q=0.1
;service=text/html
A 301 or 302 response MAY contain additional information in human- o The transferred party should be able to verify that they are
readable form, e.g., as Content-Type: text/html. It is up to the being transferred by the transferring party
server issuing the Location header to ensure consistency between the
content of the Location header and the response entity.
3.5 Replaces o The transferred-to party should know that they are being
transferred-to
The Replaces request and response header is analogous to the Also o The transferred-to party should be able to know the identity
header (Section 3.2, except that it asks the recipient to issue a of the transferring party
BYE to the addresses listed, with the same Call-ID as the request
containing the Replaces header. The special address "*" indicates
that the recipient should replace all existing legs of the call
within the Call-ID. If a message contains both Also and Replaces,
the invitations requested in the Also header MUST be completed,
successfully or not, before the terminations requested in the
Replaces header.
For example, with entities A, B and M (an MCU): o The transferred-to party should be able to know that the
transferred party is being transferred as a result of the
consultation call in progress with the transferring party.
A -> B: INVITE B SIP/2.0 o The transferred-to party should be able to accept or reject
Call-ID: 19971214T123503.33@A the transferred call just like any other call
From: A
B -> A: SIP/2.0 200 OK o If the transferred-to party accepts the transfer, the
Call-ID: 19971214T123503.33@A transferring party should be able to know this
From: A
M -> B: INVITE B SIP/2.0 o If the transferred-to party rejects the transfer, the
Call-ID: 19971214T123503.33@A transferring party should be able to know this
From: M
Replaces: *
B -> M: SIP/2.0 200 OK o The call between the transferring and transferred-to party
Call-ID: 19971214T123503.33@A terminates at the same time as the call between the
From: M transferring and transferred party, should the transfer be
successful
B -> A: BYE A SIP/2.0 This service is harder to implement. To be done in a distributed
Call-ID: 19971214T123503.33@A manner requires that information on the success of the call between
From: B transferred and transferred-to parties is communicated back to the
Requested-By: M transferring party.
A -> B: SIP/2.0 200 OK 3.4 Multi-party Conferencing
Call-ID: 19971214T123503.33@A
From: A
3.6 Requested-By Multiparty conferencing allows multiple participants to
simultaneously exchange media so that each party hears media from
every other one. There are many flavors of this service.
The Requested-By request header is only used in requests triggered 3.4.1 Loosely Coupled Multicast Conference
by Also or Replaces. It contains the URI of the entity that issued
the request containing the Also header. The URI is taken from the
From header of the request. For example, if A sends an invitation to
B containing Also: C, B issues an invitation to C with Requested-
By: A.
4 Status Code Definitions In this flavor, there is a very large conference, for which multicast
is being used to distribute the media. The conference is large enough
so that there is not a direct signaling relationship between all
parties. Session participants simply join the multicast group, and
learn about each other through RTCP [3]. This kind of conference
model is often referred to as a loosely coupled conference
This feature set defines one additional status code. The main requirement is to be able to invite another participant to
join in this conference. In fact, this kind of conference is readily
supported by baseline SIP, as it was the initial application for it.
The only new requirement is that the called party needs some way to
know that there will not be an actual SIP session - no BYE will ever
arrive (nor should one be sent). The INVITE delivers the session
invitation, and thats it. Relying on session parameters for this is
undesirable, since it leads to a dependency between SIP behavior and
the specific session type. Furthermore, it may not be possible to
ascertain from the media session whether an actual SIP session is
needed.
4.1 181 Queued 3.4.2 Distributed Full Mesh
The called party was temporarily unavailable, but the caller In this conference model, each participant has a SIP signaling
indicated via a "Call-Disposition: Queue" directive (Section 3.3) to session open with each other participant. The media session may be
queue the call rather than reject it. When the callee becomes multi-unicast or multicast. To support these conferences, the
available, it will return the appropriate final status response. The signaling must provide support for:
reason phrase MAY give further details about the status of the call,
e.g., "5 calls queued; expected waiting time is 15 minutes". The
server may issue several 181 responses to update the caller about the
status of the queued call.
5 ISDN and Intelligent Network Services o Transitioning gracefully from a normal two-party call to a
conference without knowing apriori this will happen
SIP may be used to support a number of ISDN [4] and Intelligent o Adding parties to the conference
Network [5] telephony services, described below. Due to the
fundamental differences between Internet-based telephony and
conferencing as compared to public switched telephone network
(PSTN)-based services, service definitions cannot be precisely the
same. Where large differences beyond addressing and location of
implementation exist, this is indicated below. The term address
implies any SIP address.
This section is for information and illustration only. There are many o Leaving the conference
different ways of implementing services in SIP. Since SIP only
describes the behavior induced by messages, different means of
implementing services will interoperate.
5.1 Call Redirection and "Number"-Translation Services The requirements for the service are:
Call transfer (TRA) enables a user to transfer an established (i.e., o Any member of an existing conference can add another party to
active) call to a third party. SIP signals this via the Location the conference.
header in the BYE method.
Call forwarding (CF) permits the called user to forward particular o The new party should know they are being asked to join an
pre-selected calls to another address. Unlike telephony, the existing conference.
choice of calls to be forwarded depends on program logic
contained in any of the SIP servers and can thus be made
dependent on time-of-day, subject of call, media types, urgency
or caller identity, rather than being restricted to matching
list entries. This forwarding service encompasses:
Call forwarding busy/don't answer (CFB/CFNR, SCF-BY/DA) allows the o The new party should be able to accept or reject the
called user to forward particular pre-selected calls if the invitation to join the existing call.
called user is busy or does not answer within a set time.
Selective call forwarding (SCF) permits the user to have her incoming o If the new party rejects the invitation to the conference, no
calls addressed to another network destination, no matter what other participant should have received any messages which
the called party status is, if the calling address is included indicates they were ever asked to join the conference
in, or excluded from, a screening list. The user's originating
service is unaffected.
Destination call routing (DCR) allows customers to specify the o The new party should be able to know, within the limits of
routing of their incoming calls to destinations according to synchronization of state across participants, the current set
of participants in the call before they decide whether to
reject or accept the invitation.
- time of day, day of week, etc.; o Each participant in the call should learn that a new party is
being added.
- area of call origination; o Each participant in the call should be able to
cryptographically verify that the new party has been invited
by a specific participant.
- network address of caller; o Each participant in the call should be able to decide whether
to accept or reject the new participant.
- service attributes; o If any existing participant in the call rejects the new
participant, the new participant is not added to the call at
all.
- priority (e.g., from input of a PIN or password); o The inviting party can learn the success or failure of the
addition of the new party.
- charge rates applicable for the destination; o Each participant should be able to know whether the new party
was successfully added or not.
- proportional routing of traffic. o Any participant should be able to leave the conference at any
time.
In SIP, destination call routing is implemented by user agents, proxy o Each participant should know within a short period of time
and redirect servers that implement custom call handling logic, with when some other participant has left
parameters including, but not limited to the set listed above. Caller
preferences are expressed in the Accept-Location header, callee
preferences in the Location header.
Follow-me diversion (FMD) allows the service subscriber to remotely o A participant who leaves the conference should have its SIP
control the redirection (diversion) of calls from his primary signaling relationship terminated with all other participants.
network address to other locations.
In SIP, finding the current network-reachable location of a callee is o It must be possible for two participants to simultaneously add
left to the location service and is outside the scope of this a new party to the conference.
specification. However, users may use the REGISTER method to
appraise their "home" SIP server of their new location.
Universal access number (UAN) allows a subscriber with several o It must be possible for a participant to add another to the
network addresses to be reached with a single, unique address. conference while some other participant leaves the conference.
The subscriber may specify which incoming calls are to be routed
to which address. SIP offers this functionality through proxies
and redirection.
Universal personal telecommunications (UPT) is a mobility service o The existence of the conference does not depend on the
which enables subscribers to be reached with a unique personal presence of any single user in the conference.
telecommunication number (PTN) across multiple networks at any
network access. The PTN will be translated to an appropriate
destination address for routing based on the capabilities
subscribed to by each service subscriber. A person may have
multiple PTNs, e.g., a business and private PTN. In SIP, a
host-independent address of the form user@domain serves as the
PTN, which is translated into one or more host-dependent
addresses.
5.2 Camp-on o The conference terminates when the last two parties terminate
their signaling relationships.
Completion of calls to busy subscriber (CCBS) allows a calling user It is important to note that this kind of conference does not require
encountering a busy destination to be informed when the busy the use of a centralized conference controller.
destination becomes free, without having to make a new call attempt.
SIP supports services close to CCBS by allowing a callee to indicate
a more opportune time to call back with the Retry-After header.
Also, calling and called user agents can easily record the URI of
outgoing and incoming calls, so that a user can re-try or return
calls with a single mouse click or automatically. Call-Disposition:
queue allows a caller to wait until the line becomes available. This
service is also known as a "camp-on" service.
5.3 Call Screening 3.4.3 Dial-in Bridge
Another conferencing application is the "dial-up bridge". In this
scenario, a media bridge is used, and this device also acts as a
centralized signaling server. Users join the conference by "dialing-
in", which means they try and initiate a SIP session with the
conference bridge directly. Participants do not maintain a signaling
session with each other. Rather, each participant maintains a single
SIP session with the conference bridge.
Originating call screening (OCS) controls the ability of a node to The requirements for this kind of conference are:
originate calls. In a fashion similar to closed user groups, a
firewall would have to be used to restrict the ability to initiate
SIP invitations outside a designated part of the network. In many
cases, gateways to the PSTN will require appropriate authentication.
5.4 Directed Call Pickup o It should not be neccesary for a participant to know apriori
that they are contacting a dial-up bridge - it should take
place as a regular SIP call.
Directed call pickup allows a station user to answer calls directed o Participants should be able to join the conference at any time
to a specific address from any other address by providing the address by dialing in.
of the line to be answered. The rung station must permit pickup. If
the call has not been answered at the ringing station, regular call
pickup occurs. If the call has been answered already, an error is
generated.
5.5 Directed Call Pickup with Barge-In o Participants should be able to invite another participant to
join the conference call.
Directed call pickup with barge-in establishes a 3-way call if the o Participants should still be able to learn, through some
call has been answered at the original destination. means, the identity of the other participants in the call.
5.6 Outgoing Call Routing o Participants should be able to leave the conference at any
time.
User-defined routing (UDR) allows a subscriber to specify how o When a participant leaves or joins, this information should be
outgoing calls, from the subscriber's location, shall be routed. SIP propagated to all other conference participants through some
cannot specify routing preferences; this is presumed to be handled by means besides tones or announcements in the media stream.
a policy-based routing protocol, source routing or similar
mechanisms. However, the SIP Accept-Location header may be used by
proxies and redirect servers to route calls according to caller
preferences.
5.7 End-System Services o It must be possible for the conference bridge to authenticate
the identity of participants.
Some telephony services can be provided by the end system, without 3.4.4 Ad-hoc Bridge
involvement by SIP:
Abbreviated dialing allows users to reach local subscribers without This service is not so much another conferencing model, as a
specifying the full address (domain or host name). For SIP, the transition mechanism between conferencing models. A conference starts
user application completes the address to be a fully qualified out as a fully distributed mesh. These conferences become unwieldy as
domain name. this number of participants approaches tens to hundreds. Someone in
the conference then decides to transition the call to a conference
bridge. The bring a conference bridge into the call, and then
instruct each participant to drop their signaling relationships with
the other participants in favor of a single signaling relationship
with the bridge. After the transition is complete, the conference
runs similar to the dial-in bridge case. However, there are some
distinctions. In the dialup conference, any participant can join in
without being invited if they know a conference code of some sort. In
the ad-hoc bridge case, participants must still be actively invited.
Call waiting (CW) allows the called party to receive a notification The requirements for this service are:
that another party is trying to reach her while she is busy
talking to another calling party.
For SIP-based telephony, the called party can maintain several call o The transition must be at the behest of one of the
presences at the same time, limited by local resources. Thus, it is participants.
up to the called party to decide whether to accept another call. The
separation of resource reservation and call control may lead to the
situation that the called party accepts the incoming call, but that
the network or system resource allocation fails. This cannot be
completely prevented, but if the likely resource bottleneck is at the
local system, the user agent may be able to determine whether there
are sufficient resources available or roughly track its own resource
consumption.
Consultation calling (COC) allows a subscriber to place a call on o Any participant can cause the transition to take place.
hold, in order to initiate a new call for consultation. In
systems using SIP, consultation calling can be implemented as
two separate SIP calls, possibly with the temporary release of
reserved resources for the call being put on hold.
Customized ringing (CRG) allows the subscriber to allocate a o It is not necessary for the protocol to detect and resolve
distinctive ringing to a list of calling parties. In a SIP-based simultaneous transitions. It is assumed that the persons in
system, this feature is offered by the user application, based the conference would coordinate this themselves.
on caller identification ( From header) provided by the SIP
INVITE request.
Malicious call identification (MCI) allows the service subscriber to o The conference should continue to be operable during the
control the logging (making a record) of calls received that are transition
of a malicious nature. In SIP, by default, all calls identify
the calling party and the SIP servers that have forwarded the
call. In addition, calls may be authenticated using standard
HTTP methods or transport-layer security. A callee may decide
only to accept calls that are authenticated.
Multiway calling (MWC) allows the user to establish multiple, o Participants should be informed of the transition, but it must
simultaneous calls with other parties. For a SIP-based end be possible for the perception to be that there has been no
system, the considerations for consultation calling apply. change.
Terminating call screening (TCS) allows the subscriber to specify o It should be possible for some participants to accept the
that incoming calls either be restricted or allowed, according transition, and appear through the bridge, and for others to
to a screening list and/or by time of day or other parameters. remain in full mesh.
5.8 Billing Features o Participants should be able to leave the conference at any
time, including the transition period.
Billing features such as account card dialing , automatic alternative o Participants should be able to invite others to the
billing , credit card calling (CCC) , reverse charging , freephone conference, even during the transition period. The mechanism
(FPH) , premium rate (PRM) and split charging are supported through for inviting them should not depend on the fact that a
authentication. However, mechanisms for indicating billing transition is taking place.
preferences and capabilities have not yet been specified for SIP.
Advice of charge allows the user paying for a call to be informed of 3.4.5 Conference out of Consultation
usage-based charging information. Charges incurred by reserving
resources in the network are probably best indicated by a protocol
closely affiliated with the reservation protocol. Advice of charge
when using Internet-to-PSTN gateways through SIP appears feasible,
but is for further study. Desirable facilities include indication of
charges at call setup time, during the call and at the end of the
call
Closed user groups (CUGs) that restrict members to communicate only
within the group can be implemented using firewalls and SIP proxies.
5.9 User-to-User Signaling In this service, a user A has a call in progress with B, and a
separate call in progress with C. These calls are unrelated, with
different Call-ID's. From this double call scenario, the conference
out of consultation service allows the calls to be merged, resulting
in a single, full-mesh conference, as described above.
User-to-user signaling is supported within SIP through the addition The requirements for this service are:
of headers, with predefined header fields such as Subject or
Organization.
5.10 Operator Services o Only participant A can invoke the service
There are a number of services which involve three parties, for o It must not be neccesary for A to know that he will merge the
example, a secretary dialing for boss, an auto-dialer handing a call two calls before any or either of them is made
to a telemarketer, attended call transfer, operator services such as
person-to-person calls and full-mesh "multicast".
Operator services can be implemented in a number of ways, combining o It must not be neccesary for A to have been the initiator of
Also, Replaces with either INVITE or BYE. The callee's end system the calls that are being merged
does not have to be cognizant of the fact that this an operator
service. The services make use of the Call-ID rules that stipulate
that a new INVITE for an existing Call-ID does not alert the user,
but is added silently.
Figure 1 shows the example of an autodialer connecting to a o It must be possible to merge an arbitrary number of calls
prospective customer and, once the callee picks up, transfering the
call to the telemarketer. (This goes to show that SIP is morally
neutral.)
telemarketer o The participants being merged must be informed that the
T ------------. n merging is taking place
^ : ----> nth step; INVITE (Also:)
| : ....> nth step; BYE (Also:)
2(C) | : 4 3(
| : (
| V 5 V
.................>
A C
----------------->
auto dialer 1 customer
Figure 1: Telemarketer example o A participant must be able to reject the merge, in which case
they are disconnected with all parties
5.11 Multipoint Control Unit (MCU) Services o A participant must be able to verify that A was the party that
In the language of IN services, SIP supports: initiated the merge.
Conferencing (CON) allows the user to communicate simultaneously with 4 Discussion of Implementation Options
multiple parties, which may also communicate among themselves.
SIP can initiate IP multicast conferences with any number of
participants, conferences where media are mixed by a conference
bridge (multipoint control unit or MCU) and, for exceptional
applications with a small number of participants, fully-meshed
conferences, where each participant sends and receives data to
all other participants. This is described in more detail in
Sections 5.11 and 5.12.
Conference calling add-on allows a user to add and drop participants This section discusses some of the technical issues in designing a
once the conference is active. Participants in the SIP session protocol mechanism to support the above requirements.
accomplish this by sending INVITE and BYE requests to the
parties to be added and dropped. If A wants B to drop out of a
conference, it sends a BYE request with " Replaces: *".
Conference calling meet-me (MMC) allows the user to set up a 4.1 Transfer
conference or multi-party call, indicating the date, time,
conference duration, conference media and other parameters. The
conference session description included in the SIP invitation
may indicate a time in the future. For multicast conferences,
participants do not have to connect using SIP at the actual time
of the conference; instead, they simply subscribe to the
multicast addresses listed in the announcement. For MCU-based
conferences, the session description may contain the address of
the MCU to be called at the time of the conference.
Some conferences use a multipoint control unit (MCU) to mix, convert For the discussion which follows, we assume the transferring party is
and replicate media streams. While this solution has scaling A, the transferred party is B, and the transferred-to party is C.
problems, it is widely deployed in traditional telephony and ISDN
conferencing settings, as so-called conference bridges. In a MCU-
based conference, the conference initiator or any authorized member
invites a new participant and indicates the address of the MCU in the
Also header. The invitee then contacts the MCU using the same session
description and requests to be added to the call, just like a normal
two-party call.
Parties inviting others to a conference do not have to know that the The nature of the transfer service is that the transferred party (B)
conference media is managed by an MCU. The inviting party A treats must be informed about the transfer and accept it before C (the
the MCU M like another participant and includes it in the Also list. transferred-to party) is contacted. This implies that the messaging
The newly invited participant B invites the MCU, which in turn sends flow for the service must consist of a message from A to B, and then
a Replaces header with all participants. (See example in Section B to C.
3.5). Figure 2 shows the transition from a fully-meshed conference
(see below) to an MCU-based conference.
MCU MCU -----------, The message from A to B must simultaneously disconnect A and B, and
1 ^ 2 | alert B about the transfer. This is most readily accomplished by
Also:B / Replace:A | including some kind of header in the BYE message which indicates that
/ | B should initiate a call to C. This header is the Also header, which
/ 3 V | is described in greater detail in section 5.1. It contains the
A........B A.<xxxxx.B | address of a participant, along with a signed token. This token is
: : : : : ^ : ^ | the signature over the sender of the message (the From field), the
: : : : : x : x 4| Replace: A,B address in the Also header, and the Call-ID. Since C needs to know
: :: : : 6 x: x 5 | that he is being contacted as a result of a transfer, the INVITE from
: :: : : :x x | B to C must contain some kind of header indicating that it was A who
: : : : : : x x | asked for the transfer. This header needs to contain A's name along
: : : : : : x x | with the authorization token from the Also header. This token allows
D........C D........C <------' C to verify that A requested the transfer to C for this particular
call. This header is the Requested-By header, described in greater
detail in section 5.3.
----> INVITE Therefore, the basic transfer messaging flow is simple. A sends a BYE
xxxx> BYE to B, containing an Also header listing C. The BYE causes A and B to
be disconnected. User B is alerted about the transfer. If accepted, B
sends an INVITE to C, including a Requested-By header in the INVITE.
Figure 2: Transition from fully-meshed to MCU-based conference 4.2 Full mesh conferences
Operator-assisted dial-out: The operator calls each participant, and We assume the conference starts as a standard two party call in SIP.
simply indicates the MCU in the Also list. The Call-ID and/or One of the parties wishes to add a third to the conference. Based on
the address used by the operator serves as the identifier to the the requirements, the new party needs to first be asked if they wish
MCU. For example: to join the conference. This implies that messaging begins with the
inviting party (party A) sending a message to the new participant
(party B). This message must contain a list of the other
participants. If the invitation is acceptable to B, B can begin to
join the conference. To join the conference, a signaling relationship
must be established between B and all other participants. This can be
done by having existing participants contact B, or B contacting
existing participants. Since B has the list of participants in the
initial INVITE from A, the most efficient approach is to have B
contact each participant directly.
O -> A: INVITE A SIP/2.0 Thus, in the simplest scenario, A (who is in a call with C), sends an
From: O INVITE to B. This INVITE contains an Also header, indicating C. B
Also: conference176@M sends an INVITE to C, containing a Requested-By header naming A. C
accepts, and then B sends a 200 OK to A. Now, there is a signaling
relationship between all parties. Adding additional parties is done
in a similar fashion.
A -> M: INVITE conference176@M On the surface, this simple mechanism appears sufficient. However, it
Requested-By: O is not. Consider the following problematic cases (assume A,B, and C
are already in a conference):
Meet-me: The leader and participants dial into their conference at o While A is adding D, B adds E. Since A did not tell D about E
the scheduled time with an assigned conference identifier and (as it didn't know about E), D may not know of E's existence.
security code. This results in a partially connected conference.
A -> M: INVITE conference189@M o While A is adding D, B sends a BYE to the group. If this BYE
From: A is sent by B before the INVITE from D arrives at B, B should
respond to the INVITE with an error. As far as B is concerned,
the INVITE has failed, and it responds with an error to A.
What should A do now? It cannot tell whether the add party
failed because someone left the group, or because someone
refused to add that party. In one case, the add should be
tried again, and in the other, it should not. Even worse,
should B accept the call from D, a partially disconnected
conference will occur.
5.12 Fully-Meshed Conferences o What happens if a transfer takes place at the same time as an
For very small conferences, such as adding a third party to a two- add party?
party call, multicast may not always be appropriate or available.
Instead, when inviting a new participant, the caller asks the new
member to call the remaining members. The Call-ID for all
participants is the same.
6 Acknowledgements o A participant leaves the conference, but fails to send a BYE
to all the other participants (either on purpose or by
accident). The result is a partially disconnected conference.
Parameters of the terminal negotiation mechanism in the Location The problems can all be categorized as difficulties in synchronizing
header were influenced by Scott Petrack's CMA design. a distributed database. The database, in this case, is the set of
participants. This database is replicated at each participant. The
database is dynamic, with each participant owning the entry in the
database corresponding to itself. As changes occur, everyone must be
quickly synchronized to achieve a consistent view of the conference
participants.
7 Bibliography 4.2.1 Approach I: Caretaker
In this approach, the party (A) that invites another (D) to the
conference is its caretaker. When A adds D, it informs D of the other
participants it knows about. D then sends an INVITE to each of these
in turn, establishing a signaling relationship. Should the
participant list (at A) change during the time D is being addded
(until a 200 OK arrives from D), A makes note of these changes, and
then propagates them to D.
The difficulty with this approach is there is no easy way for A to
know when it can cease being caretaker for D. Lets say A invited D,
and told it to contact B and C, which it did. After receiving the 200
OK from D, A receives an INVITE from E, a new party added by B. Now,
does A need to inform D about E? If B had invited E after knowing
about D, A does not have to inform E, but if B invited E before
knowing about D, A does have to inform D.
Furthermore, should the caretaker itself leave the conference, the
mechanism ceases to work. As a result, we don not believe this
approach is viable.
4.2.2 Approach II: Flooding
We make the following important observation:
synchronization of the set of participants in a fully
meshed multiparty conference is similar to the problem of
database synchronization in link state routing protocols,
like OSPF.
Based on this, we can develop mechanisms for SIP based on the same
synchronization, flooding, and adjacency notions in OSPF. We further
observe that this approach has already been used as the basis for
existing conferencing mechanisms [4].
To solve the first problem above, we introduce additional semantics
and behavior into the Also header. When A invites D into the
conference, the INVITE includes an Also header listing B and C. This
prompts D to send an INVITE to both B and C. In OSPF terminology,
this effectively establishes an adjacency between D and B, and D and
C. These INVITEs contain Also headers as well, listing the set of
participants the D believes is in the call.
When B and C receive this INVITE, they compare the set of
participants in the Also header with the set of participants they
believe are in the call. Note that this is effectively the same
operation as database synchronization in OSPF. The result is three
sets for each pair (assume B below):
S1: S1 is BD - the intersection of the set of participants B and D
both believe to be in the conference.
S2: S2 is B - BD - the set of participants B believes to be in the
conference, but D is not aware of
S3: S3 is D - BD - the set of participants D has been asked to
contact, which are not known to B
First consider S2. There are only two ways this inconsistency can
happen. The first way is that B has learned of a new participant
before A issued the add party to D. The second is that A has learned
the party has left the call before the INVITE from D arrives at B.
Unfortunately, the desired behavior is different in each case. If B
is correct, and a new party has joined, B should return the address
of the party in the 200 OK to the INVITE from D. This would prompt D,
in turn, to add those parties. On the other hand, if B is wrong, and
the party has left the conference, B should say nothing in the 200 OK
about this participant.
To enable these differing cases, we can add two additional pieces of
information to the addresses in the Also header. These are the
participant state (either active or inactive), and the version
number. When a participant receives a BYE from another, they mark
that participant as inactive, and hold onto the state for a short
duration (time TBD). This member is included in Also headers as other
participants, but they are marked as inactive. Based on this, in the
case above, B can ascertain the right behavior.
The version number satisfies a different need. What happens if the
participant that left, comes back because they are re-INVITEd? In
this case, some of the participants will think this participant is
inactive, and others will consider them active. To determine which
piece of state is correct, the version number increments each time
the state changes. The version with the highest value is always the
most recent. (TBD: who sets this? Can't always be the originator).
This is identical to the use of sequence numbers in LSA's in OSPF.
Consider now the set S3. When B receives the INVITE, this represents
the set of users D claims is in the conference, but B does not know
about. Since B keeps a cache of users who have left the conference, B
can be sure these are new participants that it has not learned of
yet. B should then send an INVITE to these users to establish
signaling relationships with them. As with other INVITEs' the Also
field contains B's perspective on the set of conference participants.
This is effectively the same process as flooding of new LSA's in
OSPF.
TBD: How is requested-by handled in these various cases?
We believe the flooding approach to be robust and well-proven from
many other protocols.
4.3 Dial-up Bridges
Dial up bridges are easily supported. We model them as virtual users.
When a user wants to join a dial-up conference, they send an INVITE
to the conference bridge. The bridge answers the call, and
establishes a point to point signaling relationship with the new
participant. The bridge performs the mixing locally, and sends the
mixed stream to each participant separately. As far as each
participant is concerned, they have a single signaling relationship
with one other entity - the conference server.
Fortunately, this does not prohibit each party from learning the
identity of the others in the call. The bridge is effectively an RTP
mixer. As such, it can use contributing sources (CSRC) in the RTP and
RTCP packets to identify the other participants in the call.
A user leaves the conference by hanging up with the bridge, as they
would hang up with any other user in a normal two party call.
An important issue is how conferences are identified. In the
telephone network, there is usual a dial-in number and a passcode
that the participant must know. In SIP, there are many more
possibilities:
o The conference is identified by a single URL -
sip:conference332@conferences.com, for example. A user sends
an INVITE to this address. The bridge identifies the
conference by looking at the URI in the Request-URI.
o There is a single URI for each bridge -
sip:bridge3@conferences.com. The specific conference is
identified by a passcode sent as the password in the URI:
sip:bridge3:9987097@conferences.com.
o The conference is identified by a single URL, as in the first
case. However, participants must also have a passcode. When
the server receives an INVITE for this URI, it responds with a
401 demanding digest authorization. The shared secret used for
authenticating the caller is the passcode.
o The conference is identified by a single URL, as in the first
case. The server is programmed with the public keys of those
participants allowed to join. When a participant tries to join
the conference by sending an INVITE to its address, the server
uses PGP authentication to verify the user is one of those
permitted. This allows for tight, per user controls on
conference participation.
Some have suggested identifying the conference by Call-ID. We do not
believe this is the right approach. The Call-ID represents a SIP
signaling relationship shared among two or more users. Since, in the
conference bridge case, each user has a separate signaling
relationship with the bridge, using a common Call-ID is not
appropriate.
Note that, based on this description, dial-in conferences are readily
supported in baseline SIP without any extensions. However, the
situation is more complex when a participant wishes to add another to
the conference.
We believe it is essential that the act of adding a party to a
bridged conference is no different than the act of adding a party to
a fully meshed one. Consider a bridged conference with participants
A, B, and C. Each has a signaling relationship with the bridge, X. A
wishes to bring D into the conference. Using the same mechanisms as
for fully meshed conferences, A sends an INVITE to D, with the Also
header indicating X. D then sends an INVITE to X, which accepts. The
result is that D has a signaling relationship with the bridge, but is
still maintaining its signaling relationship with A.
To resolve this, the bridge needs to step up and instruct D to
effectively abandon its signaling relationship with A (and vice a
versa). This does not mean the bridge wants A to send an BYE to D.
Rather, the bridge wants another one call leg to subsume another. For
D, this means that the D-X call leg should subsume the D-A call leg.
To accomplish this, the bridge sends an INVITE to D with a header
called Replaces. Replaces indicates that the call leg the INVITE
arrived on is subsuming the one identified in the header. The
Replaces contains the address of A. The request must also be
authenticated, since the Replaces header presents a powerful DOS
attack. Users should accept an INVITE with a Replaces header only
after either requesting confirmation from the user, or if the request
is signed by an authorized bridging service.
4.4 Conference out of Consultation
In this service, A is in a call with B, and separately, A is in a
call with C. These are two separate calls, and thus have identical
Call-IDs. Transitioning to a full mesh multiparty conference is
relatively straightforward. A can simply send an INVITE to B, with an
Also listing C. As far as B is concerned, the process is a normal add
party.
The only difference is that the Call-ID is different in both calls.
Thus, the INVITE to C from B would not appear to be for the same
call. To resolve this, A must effectively change the Call-ID with B,
and then perform an add party. The change in Call-ID is accomplished
by having A send an INVITE to B (using the Call-ID from the A-C
call), with a Replaces header containing the A-B Call-ID and A's
address. The Replaces header has the same semantic here as in the
bridged conference case above. The call leg identified in the
Replaces header is subsumed by the call-leg of the INVITE.
Once this transition has taken place, A can send an INVITE to B,
containing Also:C, as discussed above.
If the calls being connected are multi-party calls, the situation is
more complex. (TBD: does this mechanism work for bridging two full
mesh calls?)
4.5 Ad-hoc conference bridging
To support an ad-hoc conference bridge, the following operations must
take place:
o One of the parties in the call must contact a bridge,
informing it of the set of participants
o The bridge must contact those participants, and cause them to
replace their signaling relationship with the other parties
with the relationship with the bridge
To support the first, the initiator sends a message to the bridge,
containing the list of participants. We use an INVITE method for
this, and the participants are listed in the Also headers. It is not
clear if this is the right approach. The semantics of INVITE with
Also are not the same here. The bridge is not being asked to join the
call, rather, its being asked to take over the the signaling and
media connectivity for the call. For this reason, it might be
appropriate to define a new method to indicate this, or perhaps a new
header or parameter to Also.
Once the bridge has been contacted with the list of participants, it
must send an INVITE to each (using the same Call-ID as the current
call) to establish a relationship with them. This call leg must
eventually replace the call legs the user has with all the other
users. However, the user should not subsume a call leg with some
other user until the bridge has succesfully contacted that other
user.
For this to work, the initial INVITE with each user is treated as a
normal add-party. The Also list contains those users the bridge knows
about (initially, those the initiator told the bridge about). As far
as the contacted user is concerned, a normal add party is taking
place. The response is (under normal cases) a 200 OK containing those
additional parties the contacted user knows about. This way, if a
user was in the process of an add party while someone else
transitioned to a bridge, the bridge can learn about the new party.
Should the user add parties after being contacted by the bridge, the
user will tell the new party about the bridge. This allows the bridge
to learn about all users that come (and go) during the transition
period.
Once the bridge has completed contacting all participants in the
party, it attempts to subsume the various call legs into its own call
leg. To do this, it sends another INVITE to each participant, listing
those call legs which must be subsumed. In the case where a
participant has added another user after the response to the bridges
initial INVITE was sent, but before the the "subsuming INVITE"
arrives, things still work. The new party will be informed about the
bridge, contact the bridge, and the bridge accepts. The bridge can
then send another INVITE to each user subsuming this particular new
call leg.
4.6 Transfers to Multiparty Conferences
This situation is more complex than normal transfers. We first
consider the case of a full mesh signaling relatioship. Assume A, B,
and C are already in a call. A wishes to transfer both B and C to Z.
Extending the mechanism for a single party call is the ideal choice.
In this case, A would ask B to contact Z, and A would ask C to
contact Z. Everything works fine so long as (1) both B and C perform
the transfer (i.e., both contact Z), and (2) Z accepts both B and C's
invitations. However, if these assumptions fail to hold, the
resulting transfer will only partially complete. For example, it is
possible that only A gets transferred to Z.
Whether this behavior is acceptable or not is a good question. We
believe that since the blind transfer mechanism has no guarantees on
success (the transferring party disconnects in either case), this
behavior is acceptable.
Another issue that arises for multiparty conference transfers is a
flooding effect at the transferred-to party. If a large number of
participants where transferred, Z would receive, in rapid succession,
an INVITE from each. To facilitate a usable application, Z should not
really prompt the user about accepting each of these parties. Rather,
it should accept them all if it accepts the first. So, we therefore
have the rule: if a user accepts a transfer, it must accept all other
parties which have been transferred.
The specific mechanism is the same for multiparty conferences. A
sends a BYE to B and C containing an Also header listing Z. B and C
send a 200 OK to the BYE, and then send an INVITE to Z. This INVITE
contains a Requested-By header listing A. When Z gets the first of
these, it alerts the user and accepts the call. (TBD: should these
triggered INVITEs contain Also's? Probably. But, in this case, Z is
going to get the first INVITE with lots of Also's. Many of these (but
perhaps not all) will eventually contact Z directly. So, should Z
send an INVITE to those in the Also headers it doesn't know about
already? Perhaps it should wait a while to see who contacts it first.
As an alternative, the BYE from A can contain Z's address, PLUS those
it send the BYE to. As a result, the INVITE from B or C to Z would
only contain those users in the Also which Z did not list in the BYE.
What is the right approach here?)
5 Header Syntax
This section defines the syntax for the three new headers defined
here - Also, Replaces, and Requested-By.
5.1 Also
The Also header is used to list other participants in a call. It is a
request and response header, and contains a list of SIP URI's, along
with some special parameters.
Also = ``Also'' ``:'' 1#Also-Values
Also-Values = name-addr [parameters]
parameters = 1*parameter
parameter = ``;'' (status-param | version-param | crypto-param)
status-param = ``status'' ``='' (``active'' | ``inactive'')
version-param = ``version'' ``='' 1*3digit
crypto-param = ``token'' ``='' token
The crypto-param is a token which is copied into the Requested-By
header for requests that are "triggered" as a result of an Also
header. The token is a signature over the URI of the entity
generating the Also header, the address in the Also header itself,
and the Call-ID. See section 6.1 for details on its computation.
5.2 Replaces
The Replaces header is used to indicate that the call leg identified
in the header is to be subsumed by the one initiated by this INVITE.
It is a request header only, valid only in INVITE messages. The
syntax is:
Replaces = ``Replaces'' ``:'' 1#Replaces-Values
Replaces-Values= SIP-URI [call-id-param]
call-id-param = ``;'' ``call-id'' ``='' token
When the call-id parameter is not present, it is presumed to be the
same as the Call-ID of the INVITE itself.
5.3 Requested-By
The Requested-By header is a request header only. It identifies the
participant who asked the UAC to send the request. The syntax is:
Requested-By = ``Requested-By'' ``:'' name-addr [req-params]
req-params = ``;'' token-param
token-param = ``token'' ``='' token
6 Also and Requested-By Header Semantics
This section overviews the detailed semantics associated with the
Also and Requested-By headers.
6.1 Sending an Untriggered INVITE
When a UAC sends an INVITE containing an Also header, without having
been asked by some other UAC to do so, it is called an untriggered
INVITE. Untriggered INVITEs are sent when a user wishes to add
another user to a call, or to perform a transfer and hold service.
Other uses may exist.
An untriggered INVITE MUST NOT contain a Requested-By header. This
header is used to determine whether an INVITE is triggered or not.
When a UAC sends an untriggered INVITE containing an Also header, it
implies that the UAC wishes the recipient to send an INVITE to those
parties listed in the Also headers. If sent to a party not already in
the call, the INVITE effects an add party operation. If sent to a
party already in a call, it affects a transfer and hold operation. To
ensure fully connected conferences, it is RECOMMENDED that a UAC
include a URI for each participant it is aware of.
Each element in the Also list should additionally contain a status
and a version parameter. If the UAC believes the participant is no
longer in the call, the status parameter is set to inactive,
otherwise its active. The version parameter contains the version of
the status for each participant that the UAC is currently aware of.
The Also header SHOULD contain a token parameter for each URI listed.
This parameter is computed in the following fashion:
1. Initialize a string to the value of the Call-ID.
2. Append the URI from the Also, not including any
displaynames, but otherwise including all URI parameters.
Also append the Also parameters status and version.
3. Append the URI that will be included in the From field of
the INVITE.
4. Append the URI that will be included in the To field of the
INVITE.
5. Compute a signature over this field, using a XXX hash and
encryption using XXX.
6. The signature is then base64 encoded. The result is the
token.
The response to the INVITE is a non-200 value if the UAS failed to
establish a call leg with all the participants listed in the Also
fields, or if the UAS was unwilling or unable to execute the request.
A 200 OK response means that the UAS successfully established the
call with those participants which have not already left the call. In
other words, if A sends an untriggered INVITE to B, containing C in
the Also header, B will send an INVITE to C. If C has left the call
(a fact which A did not know yet), C will respond with a specific
error code indicating this. In this fashion, B will know that it may
still respond with a 200 OK to A should all other call legs become
established. Furthermore, if other participants have joined the call
since A sent the INVITE to B, B may have established call legs to
them as well. The triggered INVITE will fail if B fails to establish
a call leg with those participants, even if they are not listed in
the Also header.
Thus, a UAC SHOULD NOT treat a 200 OK to an untriggered INVITE as an
indication that a call leg was established with all (and only) the
participants listed in the Also header.
6.2 Receiving an Untriggered INVITE
A UAS can determine whether or not an INVITE was triggered or
untriggered based on the presence of the Requested-By header.
Presence of this header means that the INVITE was triggered, and its
absence implies untriggered.
If the UAS receiving the INVITE is not currently in the call
identified by the Call-ID, the UAS is being invited to join an
existing call as a new member. The UAS SHOULD alert the user and ask
for confirmation.
If the UAS receiving the INVITE is currently in a call identified by
the Call-ID, the UAS is being transferred and held. The UAS SHOULD
alert the user and ask for confirmation.
6.2.1 New Call
The UAS SHOULD send a 100 Trying response. If the transfer or add
party request is not acceptable to the user, a 6XX response SHOULD be
sent to the UAC. If the transfer/add-party is acceptable, the UAS
MUST NOT respond definitively at this point.
Instead, the UA formulates an INVITE for each participant listed in
the Also header. Each INVITE MUST also contain a Requested-By header.
This header is formed by attaching the URI in the From field in the
INVITE to the Requested-By header. The token from the element in the
Also field is copied to the token parameter in the Requested-By
header. The URI for the Also field is copied into the To field of the
INVITE. The remaining fields are initialized as they would be for any
other INVITE sent by this UA. The INVITE's generated by the UA are
called triggered INVITEs.
The UA also formulates an internal participant list. This list
contains a set of URIs for each user, and for each, a version and
status parameter. This list is initialized to the set contained in
the Also header in the INVITE. This list is also placed into the Also
headers of each triggered INVITE. The token in the Also field is
generated as described in section 6.1. Note that this is NOT the same
token received for this Also element in the untriggered INVITE. It is
regenerated with the UA as the originator.
Each triggered INVITE is then sent. The INVITEs MAY be sent in
parallel, or MAY be sent sequentially, or MAY be sent in any
groupings deemed appropriate. However, for sake of low latencies,
sending the triggered INVITEs all at once is RECOMMENDED.
If the UA receives a response to any of these INVITEs that is not 200
or 6XX (Not in Call), the UA determines that it was not successfully
added to the call. It MUST send a BYE to those participants which:
o responded to a triggered INVITE with a 200
o have not yet responded
o sent it a triggered INVITE for the same call
The latter case occurs when another party in the call (who has
received an INVITE from the UA) adds a new party as well. This new
party is informed of the UA, and sends it a triggered INVITE.
The UA MUST then respond to the original untriggered INVITE with an
error code (TBD: what code?).
If a response to a triggered INVITE is a 200, this response may
contain additional Also headers. These headers contain additional
participants that the recipient of the triggered INVITE knew about,
but the UA did not. The 200 may also contain updated status on
participants the UA knew about.
The UA uses this list to update its own list of participants. New
users learned about from the 200 OK are added to the list. Users
listed in the 200 OK, which are known to the UA, but whose version
number in the 200 OK is higher, are updated.
If the resulting update generates new active members, the UA MUST
generate additional triggered INVITEs for them. The generation of
these triggered INVITEs is identical to the above process, with an
important difference. The URI in the Requested-By field is copied
from the To field in the 200 OK. 200 responses to these triggered
INVITEs may cause further triggered invites.
If the resulting update causes members to move from active to
inactive, the UA should not send them a triggered INVITE if it has
not already done so.
If the response to a triggered INVITE is a 6xx (not in call), the UA
changes the status of that member to inactive, and increments the
version number (TBD: should this be an increment? Perhaps the 6xx
should contain the new version number).
Once responses have been received to all triggered INVITEs, all of
which were either 200 or 6xx, the UA responds to the original INVITE
(TBD: should this contain an Also list?). The UA is now in the call.
6.2.2 Existing Call
When a UA receives an INVITE containing an Also field, but no
Requested-By field, the INVITE is to transfer/hold the UA.
If the originator of the INVITE is not already in the call, the
INVITE is ignored. A 200 OK response is sent, however. (Transfers can
only take place from parties already in the call). Those users in the
Also header, who are already in the call, are ignored. If there are
no remaining users from the Also list, the INVITE is ignored.
The UA then generates triggered INVITEs to the remaining UA's in the
Also list. The behavior from this point forward is identical to
processing triggered INVITE responses in the previous section.
6.3 Receiving a Triggered INVITE
When a UA receives an INVITE containing a Requested-By header, it has
received a triggered INVITE. If the INVITE is for a new call, the UA
has just been transferred-to. If the INVITE is for an existing call,
the UA is being informed of a new party in this call.
6.3.1 New Call
The UA has just been transferred-to. The Requested-By header contains
the address of the transferring party. The UA SHOULD verify that the
token in the Requested-By header is valid. This will verify that the
transferring party is, in fact the one listed, and that this party
did, in fact, transfer the user listed in the From field. If the
token is not verified, the UAS SHOULD respond with a 4xx code, and
SHOULD NOT alert the user.
If the token is verified, the UA SHOULD alert the user, and ask for
confirmation. If the user rejects the transfer-to, the UAS SHOULD
send a 6xx response.
In either case, the UA MUST remember that it rejected the transfer
for this Call-ID. Subsequent triggered INVITEs for the same call MUST
be responded to with the same error response code. The UA MUST cache
its rejection of this transfer (identified by the Call-ID and URI of
the transferring party) for at least XX minutes. (TBD - what happens
if a very old INVITE arrives after the cache expires, and the user
accepts this time - we get a partial disconnect). The UA SHOULD alert
the user if it receives a triggered INVITE with a different user
listed in the Requested-By header, and MAY respond differently to
this transfer.
If the INVITE is acceptable, the UA sends a 200 OK. Processing of
subsequent triggered INVITEs (one will likely come from each
participant in the call) follows the rules below for an existing
call.
6.3.2 Existing Call
When a UA receives a triggered INVITE for an existing call, the
INVITE is an attempt to inform the participant of new members for
that call.
The UA SHOULD first verify the token. It does so by computing the
hash of the Call-ID, To address, Requested-By address, and From
address. This is compared to the decrypted value of the token using
the public key of the user listed in the Requested-By. If the two
match, the token is verified.
If the token is not verified, the INVITE is rejected with a 4xx
response. If the token is verified, the UA checks to see if the user
listed in the Requested-By is an active call participant. If they are
not, the INVITE is rejected with a 4xx response (TBD: is there a case
where the UA might not know about this participant yet?). If the user
is a participant, the INVITE is accepted. The user SHOULD NOT be
alerted.
The list of users in the Also header is then examined. If this list
contains users already known to the UA, the local list of
participants is updated if the version number is higher. If the list
contains users not known to the UA, they are added to the local list
of participants.
The UA then computes a difference set between its updated list and
the list in the Also header. This set includes any users in its local
list and not in the Also list. The set also includes users in both
lists, but whose version is higher in the local list. This set is
included in the Also header in the 200 OK to the INVITE. The token in
the 200 OK is generated as described in 6.1.
The UA then computes a second difference set between its updated list
and the list in the Also header. This set includes any users in the
Also list not in its local list. The set also includes users in both
lists, but whose version is higher than in the local list. The active
users from this set are then sent triggered INVITEs. The Requested-By
and Also fields in these triggered INVITEs are computed as described
above. The inactive users in this set are then sent triggered BYE's.
The Requested-By and Also fields in the triggered BYEs are computed
in the same fashion as triggered INVITEs, except a triggered BYE
contains no Also fields.
6.4 Sending an untriggered BYE
A UA MAY send a BYE, containing Also headers, at any time. This BYE
simulataneously terminates a call leg with the recipient, and causes
the recipient to attempt to set up a call leg to the parties listed
in the Also header. Unlike the INVITE, the BYE response is sent
immediately, without first adding the various parties. Sending an
untriggered BYE is equivalent to a blind transfer.
The Also headers in the untriggered BYE MUST contain tokens. These
tokens are generated in the same way described in section 6.1.
6.5 Receiving an untriggered BYE
If the BYE corresponds to an existing call leg, the UA sends a 200 OK
to the BYE. If it does not, it sends a 481.
The UA then generates triggered INVITEs to all participants listed in
the Also field. Generation of the triggered INVITEs, and processing
of their responses, is done in the same fashion as described in
section 6.1. The difference is, of course, that no additional
response is sent to the BYE.
6.6 Receiving a triggered BYE
If the BYE doesn't correspond to an existing call leg, the UA sends a
481. The UA then validates the token in the Requested-By header. If
it is validated, a 200 OK is sent to the BYE, and the call-leg is
torn down.
7 Replaces header semantics
The Replaces header is used to allow one call leg to subsume another.
The new call leg is identified by the combination of To, From, and
Call-ID in the INVITE carrying the Replaces header. Replaces is a
request header only, and MUST appear only in INVITEs. A UAS receiving
a Replaces header in a non-INVITE request MUST respond with a 4xx
status code.
The request containing a Replaces header SHOULD be authenticated.
The Replaces header contains a list of call-legs, identified by the
URI of the remote party and a Call-ID. If any of these are not valid
call-legs as known to the UAS, the INVITE MUST be responded to with a
4xx status code. Otherwise, the UAS "abandons" each call leg listed -
acting as if it had never been established. No BYE is sent. A 200 OK
is then sent to the client.
If a BYE additionally contains Also headers, the UAS MUST first
generate the triggered INVITEs implied by the Also headers. Only if
all triggered INVITEs succeed should the UAS act on the Replaces
header.
8 Example Call Flows
This section illustrates some example call flows. Messages are of the
form:
INV B Also:C,D
BYE A Also:Y
Where INV implies an INVITE request, and BYE a BYE request. The
letter after the method is the Request URI. Also:C,D implies that
URI's C and D were in the Also header.
8.1 Basic Transfer
Figure 2 exemplifies the basic transfer in a two party call. A first
sets up a call to B, and then transfers B to C.
8.2 Basic Add Party
Figure 3 exemplifies the basic add party. A and B are already in a
call. A adds C to the call.
8.3 Add Party during Add Party
In this example (Figure 4), A and B are in a call. A adds another
party, C, while B adds a different party, D. In the example, B adds D
before learning about C.
A B C
INV
----------------->
200 OK
<----------------
ACK
----------------->
BYE B Also:C
------------------>
200 OK
<------------------ INV C ReqBy:A
--------------------->
200 OK
<---------------------
ACK
--------------------->
Figure 2: Transfer Message Flow
In the example, C acts on the untriggered INVITE, and sends a
triggered INVITE to B. B responds with a 200 OK, also alerting it to
D's new presence in the call. D, acting on its untriggered INVITE,
sends a triggered INVITE to A, and learns about C. Now, both C and D
know about each other. In the example, C sends the INVITE to D first.
It is possible in other cases for D to send the INVITE to C first, or
for both INVITEs cross each other on the wire (in this case, both
sides back off with a 500 and a Retry-After, so that eventually one
invitation reaches the other side without an invite in transit in the
other direction).
Having received an INVITE from C, D doesn't bother to INVITE C. Both
D and C then OK their respective INVITEs.
8.4 Party leaves during add party
In this example (Figure 5), a three party call is in place between A,
A B C
INV C Also:B
---------------------------------->
INV B Also:C ReqBy:A
<-------------------
200 OK
-------------------->
ACK
<--------------------
200 OK
<-----------------------------------
ACK
----------------------------------->
Figure 3: Add Party Message Flow
B and C. A adds another user, D, and shortly thereafer, C leaves the
call.
Since D learns from B that C has left the call, D does not bother to
contact C, and responds right away to the add party. The result is
now a three party call with A,B, and D.
9 A note on multicast media
Another useful service, which we have not discussed so far, is to
transition a conference from distributing media through multi-unicast
to distribution through multicast. In fact, this is not a SIP issue
at all. However, we discuss it here for completeness.
Assume a call between A, B, and C. Media is being distributed through
multi-unicast. At some point, A decides its appropriate to transition
to multicast. It should send a re-INVITE to B and C, containing an
updated SDP with a multicast group (allocated by A by some means,
perhaps MADCAP [5]. If the transition to multicast is acceptable,
both B and C respond with a 200 OK. No SDP is needed in the response,
as per [2].
If B and C decide to switch to multicast, it is in their interest
(but not required) to send a re-INVITE to the other participants they
A B C D
INV C Also:B
---------------------------------->
INV D Also:A
--------------------------------->
INV B Also:A ReqBy:A
<----------------
200 OK Also:D
----------------->
INV A Also:A,B
<--------------------------------------------------
200 OK Also:C
--------------------------------------------------->
INV D Also:A,B ReqBy:B
------------------>
200 OK
<------------------
ACK
------------------->
200 OK
<-----------------------------------
ACK
----------------------------------->
200 OK
<-----------------
ACK
------------------>
Figure 4: Add Party During Add Party Message Flow
know about, containing the SDP describing the multicast session. The
result is that some or all of the sessions on the call-legs
transition to multicast. If not all have transitioned, the user may
still need to send some packets unicast.
There is no capability for determining the codec parameters for the
multicast session based on the intersection of the capabilities of
each participant. The model for multicast media distribution in a
tightly coupled conference is identical to that for loosely coupled
sessions. The initiator of the multicast session chooses a codec, and
that is what is used. Note, however, that in the case where the
A B C D
INV D Also:B,C
-------------------------------------------------->
BYE B
<-----------------
BYE A
<--------------------------------
200 OK
----------------->
200 OK
-------------------------------->
INV B Also:A,B,C ReqBy:A
<-----------------------------------
200 OK Also:C;status=inactive
----------------------------------->
ACK
<-----------------------------------
200 OK
<--------------------------------------------------
ACK
-------------------------------------------------->
Figure 5: Party Leaves During Add Message Flow
sessions start as multi-unicast, the originator will know the
capabilities of all the other parties, and thus can intelligently
choose the codecs for the session.
10 Security Considerations
Security issues are addressed throughout this document.
The call control mechanisms have serious security issues. An INVITE
with an Also cause the recipient to add or drop other parties,
possibly without user interaction. This implies that authorization of
the requests is critical.
11 Open Issues
There are many, many open issues:
1. How to do this with shared secrets rather than public keys?
2. If the transferred-to party in a transfer accepts some, but
not all (or rejects some, but not all) of the INVITEs for
it, we end up with a partially disconnected conference.
3. Should we use a session timer to refresh things and
periodically re-flood the participant list, in an attempt
to keep things synchronized?
4. The version/status concept is still very vague. Does it
work? Is it needed?
5. Conference out of consultation for multi-party calls - not
clear the Replaces mechanism works here.
12 Acknowledgements
The authors would like to especially thank Jonathan Lennox for his
many insightful comments and contributions to this work.
13 Bibliography
[1] S. Bradner, "Key words for use in RFCs to indicate requirement [1] S. Bradner, "Key words for use in RFCs to indicate requirement
levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. levels," Request for Comments (Best Current Practice) 2119, Internet
Engineering Task Force, Mar. 1997.
[2] M. Handley, H. Schulzrinne, and E. Schooler, "SIP: Session [2] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:
initiation protocol," Internet Draft, Internet Engineering Task session initiation protocol," Request for Comments (Proposed
Force, Nov. 1997. Work in progress. Standard) 2543, Internet Engineering Task Force, Mar. 1999.
[3] M. Handley and V. Jacobson, "SDP: Session description protocol," [3] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: a
Internet Draft, Internet Engineering Task Force, Mar. 1997. Work in transport protocol for real-time applications," Request for Comments
progress. (Proposed Standard) 1889, Internet Engineering Task Force, Jan. 1996.
[4] International Telecommunication Union, "Integrated services [4] C. Elliott, "A 'sticky' conference control protocol," vol. 5, pp.
digital network (ISDN) service capabilities -- definition of 97--119, 1994.
supplementary services," Recommendation I.250, Telecommunication
Standardization Sector of ITU, Geneva, Switzerland, 1993.
[5] International Telecommunication Union, "General recommendations [5] S. Hanna, B. Patel, and M. Shah, "Multicast address dynamic
on telephone switching and signaling -- intelligent network: client allocation protocol (MADCAP)," Internet Draft, Internet
Introduction to intelligent network capability set 1," Recommendation Engineering Task Force, May 1999. Work in progress.
Q.1211, Telecommunication Standardization Sector of ITU, Geneva,
Switzerland, Mar. 1993. Full Copyright Statement
Copyright (c) The Internet Society (1999). 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.
Table of Contents Table of Contents
1 Terminology ......................................... 1 1 Terminology ......................................... 1
2 Introduction ........................................ 1 2 Introduction ........................................ 2
3 Headers ............................................. 2 3 Services ............................................ 2
3.1 Accept-Location .................................... 2 3.1 Blind Transfer ...................................... 3
3.2 Also ............................................... 2 3.2 Transfer and Hold ................................... 4
3.3 Call-Disposition ................................... 4 3.3 Transfer with Consultation .......................... 5
3.4 Location ........................................... 5 3.4 Multi-party Conferencing ............................ 6
3.5 Replaces ........................................... 7 3.4.1 Loosely Coupled Multicast Conference ................ 6
3.6 Requested-By ....................................... 8 3.4.2 Distributed Full Mesh ............................... 7
4 Status Code Definitions ............................. 8 3.4.3 Dial-in Bridge ...................................... 8
4.1 181 Queued .......................................... 8 3.4.4 Ad-hoc Bridge ....................................... 9
5 ISDN and Intelligent Network Services ............... 8 3.4.5 Conference out of Consultation ...................... 10
5.1 Call Redirection and "Number"-Translation Services 4 Discussion of Implementation Options ................ 11
................................................................ 9 4.1 Transfer ............................................ 11
5.2 Camp-on ............................................. 10 4.2 Full mesh conferences ............................... 12
5.3 Call Screening ...................................... 10 4.2.1 Approach I: Caretaker ............................... 13
5.4 Directed Call Pickup ................................ 11 4.2.2 Approach II: Flooding ............................... 13
5.5 Directed Call Pickup with Barge-In .................. 11 4.3 Dial-up Bridges ..................................... 15
5.6 Outgoing Call Routing ............................... 11 4.4 Conference out of Consultation ...................... 17
5.7 End-System Services ................................. 11 4.5 Ad-hoc conference bridging .......................... 17
5.8 Billing Features .................................... 12 4.6 Transfers to Multiparty Conferences ................. 18
5.9 User-to-User Signaling .............................. 13 5 Header Syntax ....................................... 19
5.10 Operator Services ................................... 13 5.1 Also ................................................ 19
5.11 Multipoint Control Unit (MCU) Services .............. 13 5.2 Replaces ............................................ 20
5.12 Fully-Meshed Conferences ............................ 15 5.3 Requested-By ........................................ 20
6 Acknowledgements .................................... 16 6 Also and Requested-By Header Semantics .............. 20
7 Bibliography ........................................ 16 6.1 Sending an Untriggered INVITE ....................... 20
6.2 Receiving an Untriggered INVITE ..................... 22
6.2.1 New Call ............................................ 22
6.2.2 Existing Call ....................................... 24
6.3 Receiving a Triggered INVITE ........................ 24
6.3.1 New Call ............................................ 24
6.3.2 Existing Call ....................................... 25
6.4 Sending an untriggered BYE .......................... 26
6.5 Receiving an untriggered BYE ........................ 26
6.6 Receiving a triggered BYE ........................... 26
7 Replaces header semantics ........................... 26
8 Example Call Flows .................................. 27
8.1 Basic Transfer ...................................... 27
8.2 Basic Add Party ..................................... 27
8.3 Add Party during Add Party .......................... 27
8.4 Party leaves during add party ....................... 28
9 A note on multicast media ........................... 29
10 Security Considerations ............................. 31
11 Open Issues ......................................... 31
12 Acknowledgements .................................... 32
13 Bibliography ........................................ 32
 End of changes. 145 change blocks. 
548 lines changed or deleted 1357 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/