Internet Engineering Task Force                                MMUSIC WG
Internet Draft                                     Schulzrinne/Rosenberg
draft-ietf-mmusic-sip-cc-01.txt            Columbia U./Bell Laboratories
March 13, 1998
June 17, 1999
Expires: August 1, 1998 December, 1999

                       SIP Call Control Services


   This document is an Internet-Draft. Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-Drafts. Internet-

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts Internet- Drafts as reference
   material or to cite them other than as ``work work in progress''.

   To learn the current status progress.

   The list of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories on (Africa), (Europe), (Pacific Rim), (US East Coast), or (US West Coast).

   Distribution of this document is unlimited.

                                 ABSTRACT can be accessed at


   This document describes the a set of extensions to the Session Initiation Protocol (SIP). SIP which allow for
   various call control services. Example services include blind
   transfer, transfer with consultation, multi-party calls, bridged
   conferences, and ad-hoc conferencing. The document
         also describes how standard telephony services are supported in a
   fully distributed manner, so that they can be
         implemented in SIP. 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

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and
   indicate requirement levels for compliant SIP implementations.

2 Introduction

   This document describes the extensions to the

   The Session Initiation Protocol (SIP) [2]. When [2] is a signaling protocol
   used for the initiation of multimedia sessions. SIP also defines
   mechanisms for termination of sessions using the extensions
   described here, BYE method. However,
   SIP has less support for signaling of services that take place during
   the client MUST call itself. These kinds of services can be broken into several

   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 extension name session), hold, and mute.

   Call Control Services These services relate to participant
        management. These services are all built on the basic blocks of
        adding and removing users from a call. Examples include transfer
        (the simultaneous removal and addition of a member from a call),
        multi-party calling, call bridging, and ad-hoc bridged

   This document describes extensions to SIP for providing call control
   services. The services are supported in a
   Require header.

3 Headers

                             type   ACK   BYE   INV   OPT   REG
         Accept-Location      R      -     -     o     o     -
         Also                 R      -     -     o     o     -
         Also                 r      -     -     o     o     -
         Call-Disposition     R      -     o     o     -     -
         Replaces             R      -     -     o     o     -
         Replaces             r      -     -     o     o     -
         Requested-By         R      -     -     o 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. 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

3 Services

   We overview the services which we desire to support at a minimum. For
   each, we define the requirements for the service, with a particular
   focus on security. Security is a primary concern for many of these
   services. As such, the following general principles apply:

        o     -
         Requested-By         r      -     - Parties involved in some service should be able to
          cyryptographically verify the identity of the other parties in
          the service

        o Parties involved in some service should have a choice about
          their participation in the service

        o     -

   Table 1: Summary Parties involved in some service should know what the service
          being invoked is

   These three basic requirements are a natural consequence of an
   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.

3.1 Blind Transfer

   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

                  -> | Transferred-to |
                 /   |     party      |
                /    ----------------
  --------------                          ----------------
 | Transferred  |<------------------------| Transferring   |
 |    party     |                         |    party       |
  --------------                          ----------------

   Figure 1: Transfer Service

   Some of the requirements for this service include:

        o The original call terminates regardless of whether the
          transfer succeeds or not.

        o The transferring party does not know whether the transfer
          succeeds or not.

        o The transferred party should be able to know that they are
          being transferred

        o The transferred party should be able to know to whom they are
          being transferred

        o The transferred party should be able to decide whether to
          accept or reject the transfer

        o If the transferred party rejects the transfer, the call with
          the transferring party still terminates

        o The transferred party should be able to verify that they are
          being transferred by the transferring party

        o The transferred-to party should know that they are being

        o The transferred-to party should be able to know the identity
          of the transferring party

        o The transferred-to party should be able to accept or reject
          the transferred call just like any other call

3.2 Transfer and Hold

   This service is a variation on blind transfer. The difference is that
   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:

        o The call between the transferring and transferred parties
          remains active, regardless of the status of the new call
          between the transferred and transferred-to parties.

        o The transferring party does not know whether the transfer
          succeeds or not.

        o The transferred party should be able to know that they are
          being transferred
        o The transferred party should be able to know to whom they are
          being transferred

        o The transferred party should be able to decide whether to
          accept or reject the transfer

        o If the transferred party rejects the transfer, the call with
          the transferring party remains unchanged

        o The transferred party should be able to verify that they are
          being transferred by the transferring party

        o The transferred-to party should know that they are being

        o The transferred-to party should be able to know the identity
          of the transferring party

        o The transferred-to party should be able to accept or reject
          the transferred call just like any other call

        o The transferred-to party should not be able to ascertain,
          through signaling messages, that the transferring party is
          still communicating with the transferred party. In other
          words, blind transfer and transfer and hold appear identical
          to the transferred-to party.

3.3 Transfer with Consultation

   This service is similar to blind transfer. However, the transferring
   party first contacts the transferred-to party to approve the transfer
   through multimedia communication. Pending approval, the transferring
   party then simultaneosly disconnects from the transferred-to and
   transferred parties, and connects the transferred and transferred-to
   parties. The transferring and transferred parties stay connected if,
   for some reason, the transfer fails.

   The requirements for this service are more complex. They include:

        o The transferring party should not need to know ahead of time
          that they will transfer the call to the transferred-to party.
          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.

        o The transferred party should be able to know that they are
          being transferred
        o The transferred party should be able to know to whom they are
          being transferred

        o The transferred party should be able to decide whether to
          accept or reject the transfer

        o The transferred party should be able to verify that they are
          being transferred by the transferring party

        o The transferred-to party should know that they are being

        o The transferred-to party should be able to know the identity
          of the transferring party

        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.

        o The transferred-to party should be able to accept or reject
          the transferred call just like any other call

        o If the transferred-to party accepts the transfer, the
          transferring party should be able to know this

        o If the transferred-to party rejects the transfer, the
          transferring party should be able to know this

        o The call between the transferring and transferred-to party
          terminates at the same time as the call between the
          transferring and transferred party, should the transfer be

   This service is harder to implement. To be done in a distributed
   manner requires that information on the success of the call between
   transferred and transferred-to parties is communicated back to the
   transferring party.

3.4 Multi-party Conferencing

   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.

3.4.1 Loosely Coupled Multicast Conference

   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

   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

3.4.2 Distributed Full Mesh

   In this conference model, each participant has a SIP signaling
   session open with each other participant. The media session may be
   multi-unicast or multicast. To support these conferences, the
   signaling must provide support for:

        o Transitioning gracefully from a normal two-party call to a
          conference without knowing apriori this will happen

        o Adding parties to the conference

        o Leaving the conference

   The requirements for the service are:

        o Any member of an existing conference can add another party to
          the conference.

        o The new party should know they are being asked to join an
          existing conference.

        o The new party should be able to accept or reject the
          invitation to join the existing call.

        o If the new party rejects the invitation to the conference, no
          other participant should have received any messages which
          indicates they were ever asked to join the conference

        o The new party should be able to know, within the limits of
          synchronization of state across participants, the current set
          of participants in the call before they decide whether to
          reject or accept the invitation.

        o Each participant in the call should learn that a new party is
          being added.

        o Each participant in the call should be able to
          cryptographically verify that the new party has been invited
          by a specific participant.

        o Each participant in the call should be able to decide whether
          to accept or reject the new participant.

        o If any existing participant in the call rejects the new
          participant, the new participant is not added to the call at

        o The inviting party can learn the success or failure of the
          addition of the new party.

        o Each participant should be able to know whether the new party
          was successfully added or not.

        o Any participant should be able to leave the conference at any

        o Each participant should know within a short period of time
          when some other participant has left

        o A participant who leaves the conference should have its SIP
          signaling relationship terminated with all other participants.

        o It must be possible for two participants to simultaneously add
          a new party to the conference.

        o It must be possible for a participant to add another to the
          conference while some other participant leaves the conference.

        o The existence of the conference does not depend on the
          presence of any single user in the conference.

        o The conference terminates when the last two parties terminate
          their signaling relationships.

   It is important to note that this kind of conference does not require
   the use of a centralized conference controller.

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.

   The requirements for this kind of conference are:

        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.

        o Participants should be able to join the conference at any time
          by dialing in.

        o Participants should be able to invite another participant to
          join the conference call.

        o Participants should still be able to learn, through some
          means, the identity of the other participants in the call.

        o Participants should be able to leave the conference at any

        o When a participant leaves or joins, this information should be
          propagated to all other conference participants through some
          means besides tones or announcements in the media stream.

        o It must be possible for the conference bridge to authenticate
          the identity of participants.

3.4.4 Ad-hoc Bridge

   This service is not so much another conferencing model, as a
   transition mechanism between conferencing models. A conference starts
   out as a fully distributed mesh. These conferences become unwieldy as
   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.

   The requirements for this service are:

        o The transition must be at the behest of one of the

        o Any participant can cause the transition to take place.

        o It is not necessary for the protocol to detect and resolve
          simultaneous transitions. It is assumed that the persons in
          the conference would coordinate this themselves.

        o The conference should continue to be operable during the

        o Participants should be informed of the transition, but it must
          be possible for the perception to be that there has been no

        o It should be possible for some participants to accept the
          transition, and appear through the bridge, and for others to
          remain in full mesh.

        o Participants should be able to leave the conference at any
          time, including the transition period.

        o Participants should be able to invite others to the
          conference, even during the transition period. The mechanism
          for inviting them should not depend on the fact that a
          transition is taking place.

3.4.5 Conference out of Consultation

   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.

   The requirements for this service are:

        o Only participant A can invoke the service

        o It must not be neccesary for A to know that he will merge the
          two calls before any or either of them is made

        o It must not be neccesary for A to have been the initiator of
          the calls that are being merged
        o It must be possible to merge an arbitrary number of calls

        o The participants being merged must be informed that the
          merging is taking place

        o A participant must be able to reject the merge, in which case
          they are disconnected with all parties

        o A participant must be able to verify that A was the party that
          initiated the merge.

4 Discussion of Implementation Options

   This section discusses some of the technical issues in designing a
   protocol mechanism to support the above requirements.

4.1 Transfer

   For the discussion which follows, we assume the transferring party is
   A, the transferred party is B, and the transferred-to party is C.

   The nature of the transfer service is that the transferred party (B)
   must be informed about the transfer and accept it before C (the
   transferred-to party) is contacted. This implies that the messaging
   flow for the service must consist of a message from A to B, and then
   B to C.

   The message from A to B must simultaneously disconnect A and B, and
   alert B about the transfer. This is most readily accomplished by
   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
   is described in greater detail in section 5.1. It contains the
   address of a participant, along with a signed token. This token is
   the signature over the sender of the message (the From field), the
   address in the Also header, and the Call-ID. Since C needs to know
   that he is being contacted as a result of a transfer, the INVITE from
   B to C must contain some kind of header indicating that it was A who
   asked for the transfer. This header needs to contain A's name along
   with the authorization token from the Also header. This token allows
   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.

   Therefore, the basic transfer messaging flow is simple. A sends a 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.

4.2 Full mesh conferences

   We assume the conference starts as a standard two party call in SIP.
   One of the parties wishes to add a third to the conference. Based on
   the requirements, the new party needs to first be asked if they wish
   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.

   Thus, in the simplest scenario, A (who is in a call with C), sends an
   INVITE to B. This INVITE contains an Also header, indicating C. B
   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.

   On the surface, this simple mechanism appears sufficient. However, it
   is not. Consider the following problematic cases (assume A,B, and C
   are already in a conference):

        o While A is adding D, B adds E. Since A did not tell D about E
          (as it didn't know about E), D may not know of E's existence.
          This results in a partially connected conference.

        o While A is adding D, B sends a BYE to the group. If this BYE
          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.

        o What happens if a transfer takes place at the same time as an
          add party?

        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.

   The problems can all be categorized as difficulties in synchronizing
   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

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

   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

        o The conference is identified by a single URL -
, 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 -
 The specific conference is
          identified by a passcode sent as the password in the URI:

        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

   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

   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

   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

   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 header fields. "o": optional, "m": mandatory,  "-
   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  applicable,  "R': 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 header, "r": and response header, "g":
   general header, "*": needed if message body 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 not empty.  A  numeric
   value in a token which is copied into the "type" column indicates Requested-By
   header for requests that are "triggered" as a result of an Also
   header. The token is a signature over the status code 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 field is used with.

3.1  Accept-Location 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  Accept-Location Requested-By header is a request header allows the caller to provide
   hints to proxy and redirect servers. only. It uses identifies the same parameters as
   participant who asked the Location header (Section 3.4).

3.2  Also 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 request and response header advises Requested-By Header Semantics

   This section overviews the recipient to issue detailed semantics associated with the
   Also and Requested-By headers.

6.1 Sending an Untriggered INVITE requests

   When a UAC sends an INVITE containing an Also header, without having
   been asked by some other UAC to the addresses listed. Each of these invitations
   SHOULD 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 contains the  From field
   of UAC wishes the message containing recipient to send an INVITE to those
   parties listed in the Also field. The  Also header MUST only
   be processed by the calling or called user agent, headers. If sent to a party not by any
   intermediate proxy or redirect servers. already in
   the call, the INVITE effects an add party operation. If sent to a message contains both  Also
   party already in a call, it affects a transfer and  Replaces, the invitations
   requested 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 header MUST be completed, successfully or not,
   before list should additionally contain a status
   and a version parameter. If the terminations requested UAC believes the participant is no
   longer in the Replaces header.

   Also    =    "Also" ":" 1#( SIP-URL | URI ) [ comment ]
   Example header:

     Also: sip://, sip://

   If A, B and C are end points, call, the following status parameter is a typical scenario:

   A -> B:    INVITE B SIP/2.0
              Call-ID: 19971214T123503.33@A
              Also: C
              From: A
   B -> A:    SIP/2.0 200 OK
              Call-ID: 19971214T123503.33@A
              From: A
   B -> C:    INVITE C SIP/2.0
              Call-ID: 19971214T123503.33@A
              From: B
              Requested-By: A
   C -> B:    SIP/2.0 200 OK
              Call-ID: 19971214T123503.33@A
              From: B

   If G set to inactive,
   otherwise its active. The version parameter contains the version of
   the status for each participant that the UAC is a group address with members X through Z, a group invitation
   may proceed as follows:

   A -> G:    INVITE G SIP/2.0
              From: A
              Call-ID: 19971214T124523.00@A

   G -> A:    SIP/2.0 200 OK
              From: A
              Call-ID: 19971214T124523.00@A
              Also: X, Y, Z

   A -> X:    INVITE X SIP/2.0
              From: A
              Call-ID: 19971214T124523.00@A
              Requested-By: G

   A -> Y:    INVITE Y SIP/2.0
              From: A
              Call-ID: 19971214T124523.00@A
              Requested-By: G
   A -> Z:    INVITE Z SIP/2.0
              From: A
              Call-ID: 19971214T124523.00@A
              Requested-By: G currently aware of.

   The Also header makes it possible SHOULD contain a token parameter for each URI listed.
   This parameter is computed in the following fashion:

        1.   Initialize a string to create full meshes
        (generalized "three-way" calling) and supports the
        resolution value of group addresses. Unlike the  Location header,
        which enumerates alternatives to be tried, Call-ID.

        2.   Append the URI from the Also, not including any
             displaynames, but otherwise including all URI parameters.
             Also append the Also header
        lists addresses to parameters status and version.

        3.   Append the URI that will be all invited.

3.3  Call-Disposition

   The  Call-Disposition request header field allows included in the client to
   indicate how From field of
             the server is to handle INVITE.

        4.   Append the call. The following options
   can URI that will be used singly or included in combination:

   all: If the user part To field of the SIP request address identifies

        5.   Compute a group
        rather than an individual, signature over this field, using a XXX hash and
             encryption using XXX.

        6.   The signature is then base64 encoded. The result is the " all" feature indicates

   The response to the INVITE is a
        proxy or redirect server that it should resolve non-200 value if the address UAS failed to
   establish a
        list of group members and return a 300 (Multiple Choices)
        response. The list of group members is contained 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

   do-not-forward: The "do-not-forward" request prohibits proxies from
        forwarding 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 another individual (e.g., A should all other call legs become
   established. Furthermore, if other participants have joined the call is
        personal or
   since A sent the caller does not want INVITE to be shunted B, B may have established call legs to
   them as well. The triggered INVITE will fail if B fails to establish
        secretary call leg with those participants, even if the line is busy.)

   queue: If the called party is temporarily unreachable, e.g., because
        it is they are not listed in another call,
   the caller can indicate that it wants Also header.

   Thus, a UAC SHOULD NOT treat a 200 OK to
        have its an untriggered INVITE as an
   indication that a call queued rather than rejected immediately. If leg was established with all (and only) the
        call is queued,
   participants listed in the server returns "181 Queued" (see Section
        4.1). Also header.

6.2 Receiving an Untriggered INVITE

   A pending call be terminated by a SIP  BYE request.

   do-not-respond: The  do-not-respond directive indicates to the callee
        that it should UAS can determine whether or not issue a response, informational an INVITE was triggered or final.
        This may be used to send invitations to multicast groups.

   untriggered based on the combination presence of do-not-respond and all could be
        used for group invitations to larger lists?

   Call-Disposition    =    "Call-Disposition" ":" 1#( "all" | "do-not-forward"
                      |     "queue" | "do-not-respond" )


     Call-Disposition: all, do-not-forward, queue

3.4  Location

   This document adds extension parameters to the  Location Requested-By header.

   extension-name       =    token
   extension-value      =    *( token | quoted-string | LWS | extension-specials)
   extension-specials   =     < any element
   Presence 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" )
                              |    "description"    "="    quoted-string
                              |    "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 header means that the INVITE was triggered, and its
   absence implies untriggered.

   If the UAS receiving the INVITE is found not currently in a residential or business setting. (A caller may defer a
        personal the call if only a business line
   identified by the Call-ID, the UAS is available, for

   description: The description field further describes, being invited to join an
   existing call as text, a new member. The UAS SHOULD alert the user and ask
   for confirmation.

   If the
        terminal. It UAS receiving the INVITE is expected that currently in a call identified by
   the user interface will render
        this text.

   duplex: The duplex parameter lists whether Call-ID, the terminal can
        simultaneously send UAS is being transferred and receive ("full"), alternate between
        sending held. The UAS SHOULD
   alert the user and receiving ("half"), can only receive ("receive-
        only") or only ask for confirmation.

6.2.1 New Call

   The UAS SHOULD send ("send-only"). Typically, a caller will
        prefer a full-duplex terminal over a half-duplex terminal and
        these over receive-only 100 Trying response. If the transfer or send-only terminals.

   features: The feature list enumerates additional features of this
        address. The "permanent" flag indicates that this address add
   party request is not acceptable to the user, a
        new, permanent address. When used 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 registration, each participant listed in
   the server
        SHOULD return Also header. Each INVITE MUST also contain a 301 status instead of 302.

   language: The language parameter lists, Requested-By header.
   This header is formed by attaching the URI in order of preference, the
        languages spoken by From field in the person answering. This feature may be
   INVITE to have a caller automatically select the appropriate
        attendant or customer service representative, without having Requested-By header. The token from the element in the
   Also field is copied to
        declare its own language skills.

   media: the token parameter in the Requested-By
   header. The media tag lists URI for the media types supported by Also field is copied into the terminal.
        Media types can be To field of the standard Internet media types ("audio",
        "video", "text", "application"), optionally followed
   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
        subtype (e.g., "text/html"). In addition, 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 type
        "application/email" INVITE. This list is defined.

   mobility: also placed into the Also
   headers of each triggered INVITE. The mobility parameter indicates if token in the terminal Also field is fixed
        or mobile. In some locales,
   generated as described in section 6.1. Note that this may affect voice quality or

   priority: The priority tag indicates is NOT the minimum priority level same
   token received for this
        terminal is to be used for. Also element in the untriggered INVITE. It can be used for automatically
        restricting is
   regenerated with the choice of terminals available to UA as the user.

   service: The service tag describes what service originator.

   Each triggered INVITE is being provided by
        the terminal.

   Attributes which are unknown should then sent. The INVITEs MAY be omitted. New tags for class-
   tag and  service-tag can sent in
   parallel, or MAY be registered with IANA.  The media tag uses
   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:// ;q=0.7
               ;media=audio+video+application/x-wb ;duplex=full
     Location: rtsp:// ;q=0.6
               ;media=audio+video ;duplex=full
     Location: phone://1-415-555-1212 ;q=0.5
     Location: phone://1-800-555-1212 ;q=0.2
               duplex=send-only;media=text; priority=urgent;
               description="For emergencies only"
     Location: ;q=0.1
     Location: ;q=0.1

   A 301 sent sequentially, or 302 response MAY contain additional information be sent in human-
   readable form, e.g., as  Content-Type: text/html. It is up to the
   server issuing the  Location header to ensure consistency between the
   content any
   groupings deemed appropriate. However, for sake of low latencies,
   sending the  Location header and triggered INVITEs all at once is RECOMMENDED.

   If the UA receives a response entity.

3.5  Replaces

   The  Replaces request and response header is analogous to any of these INVITEs that is not 200
   or 6XX (Not in Call), the Also
   header (Section 3.2, except UA determines that it asks the recipient was not successfully
   added to issue the call. It MUST send a BYE to the addresses listed, 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-ID as call

   The latter case occurs when another party in the request
   containing call (who has
   received an INVITE from the  Replaces header. UA) adds a new party as well. This new
   party is informed of the UA, and sends it a triggered INVITE.

   The special address "*" indicates 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 should replace all existing legs of the call
   within triggered INVITE knew about,
   but the  Call-ID. If a message contains both  Also and  Replaces, 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 invitations requested 200 OK are added to the list. Users
   listed in the  Also header MUST be completed,
   successfully or not, before 200 OK, which are known to the terminations requested UA, but whose version
   number in the
   Replaces header.

   For example, with entities A, B and M (an MCU):

   A -> B:    INVITE B SIP/2.0
              Call-ID: 19971214T123503.33@A
              From: A

   B -> A:    SIP/2.0 200 OK
              Call-ID: 19971214T123503.33@A
              From: A

   M -> B:    INVITE B SIP/2.0
              Call-ID: 19971214T123503.33@A
              From: M
              Replaces: *

   B -> M:    SIP/2.0 200 OK
              Call-ID: 19971214T123503.33@A
              From: M

   B -> A:    BYE A SIP/2.0
              Call-ID: 19971214T123503.33@A
              From: B
              Requested-By: M

   A -> B:    SIP/2.0 200 OK
              Call-ID: 19971214T123503.33@A
              From: A

3.6  Requested-By

   The  Requested-By request header is only used in requests triggered
   by  Also or  Replaces. It contains the URI of higher, are updated.

   If the entity that issued resulting update generates new active members, the request containing UA MUST
   generate additional triggered INVITEs for them. The generation of
   these triggered INVITEs is identical to the  Also header. above process, with an
   important difference. The URI in the Requested-By field is taken copied
   from the
   From header of To field in the request. For example, if A sends an invitation to
   B containing  Also: C, B issues an invitation 200 OK. 200 responses to C with  Requested-
   By: A.

4 Status Code Definitions

   This feature set defines one additional status code.

4.1 181 Queued

   The called party was temporarily unavailable, but these triggered
   INVITEs may cause further triggered invites.

   If the caller
   indicated via a "Call-Disposition: Queue" directive (Section 3.3) resulting update causes members to
   queue the call rather than reject it. When move from active to
   inactive, the callee becomes
   available, UA should not send them a triggered INVITE if it will return the appropriate final status response. The
   reason phrase MAY give further details about the status of has
   not already done so.

   If the call,
   e.g., "5 calls queued; expected waiting time is 15 minutes". The
   server may issue several 181 responses response to update a triggered INVITE is a 6xx (not in call), the caller about UA
   changes the status of the queued call.

5 ISDN that member to inactive, and Intelligent Network Services

   SIP may increments the
   version number (TBD: should this be used an increment? Perhaps the 6xx
   should contain the new version number).

   Once responses have been received to support a number all triggered INVITEs, all of ISDN [4] and Intelligent
   Network [5] telephony services, described below. Due to
   which were either 200 or 6xx, the
   fundamental differences between Internet-based telephony and
   conferencing as compared UA responds 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, original INVITE
   (TBD: should this is indicated below. contain an Also list?). The term address
   implies any SIP address.

   This section UA is for information and illustration only. There are many
   different ways of implementing services now 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 call.

6.2.2 Existing Call transfer (TRA) enables

   When a user to transfer UA receives an established (i.e.,
        active) call INVITE containing an Also field, but no
   Requested-By field, the INVITE is to a third party. SIP signals this via transfer/hold the Location
        header UA.

   If the originator of the INVITE is not already in the  BYE method.

   Call forwarding (CF) permits call, the called user to forward particular
        pre-selected calls to another address. Unlike telephony,
   INVITE is ignored. A 200 OK response is sent, however. (Transfers can
   only take place from parties already in the
        choice of calls to be forwarded depends on program logic
        contained call). Those users in the
   Also header, who are already 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 are ignored. If there are
   no remaining users from the
        called user 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 particular pre-selected calls if is identical to
   processing triggered INVITE responses in the
        called user 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 busy or does not answer within for a set time.

   Selective call forwarding (SCF) permits new call, the user to have her incoming
        calls addressed to another network destination, no matter what UA
   has just been transferred-to. If the called party status is, if INVITE is for an existing call,
   the calling address UA is included
        in, or excluded from, being informed of a screening list. new party in this call.

6.3.1 New Call

   The user's originating
        service is unaffected.

   Destination call routing (DCR) allows customers to specify UA has just been transferred-to. The Requested-By header contains
        routing of their incoming calls to destinations according to

        - time of day, day of week, etc.;

        - area of call origination;

        - network address of caller;

        - service attributes;

        - priority (e.g., from input of a PIN or password);

        - charge rates applicable for the destination;

        - proportional routing of traffic.

   In SIP, destination call routing transferring party. The UA SHOULD verify that the
   token in the Requested-By header is implemented by user agents, proxy
   and redirect servers valid. This will verify that implement custom call handling logic, with
   parameters including, but not limited to the set listed above. Caller
   preferences are expressed
   transferring party is, in fact the  Accept-Location header, callee
   preferences one listed, and that this party
   did, in fact, transfer the  Location header.

   Follow-me diversion (FMD) allows user listed in the service subscriber to remotely
        control From field. If the redirection (diversion) of calls from his primary
        network address to other locations.

   In SIP, finding
   token is not verified, the current network-reachable location of UAS SHOULD respond with a callee 4xx code, and
   SHOULD NOT alert the user.

   If the token is
   left to verified, the location service UA SHOULD alert the user, and is outside ask for
   confirmation. If the scope of this
   specification. However, users may use user rejects the  REGISTER method to
   appraise their "home" SIP server of their new location.

   Universal access number (UAN) allows transfer-to, the UAS SHOULD
   send a subscriber with several
        network addresses to 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 reached responded to with a single, unique address. the same error response code. The subscriber may specify which incoming calls are to be routed
        to which address. SIP offers UA MUST cache
   its rejection of this functionality through proxies transfer (identified by the Call-ID and redirection.

   Universal personal telecommunications (UPT) is URI of
   the transferring party) for at least XX minutes. (TBD - what happens
   if a mobility service
        which enables subscribers to be reached with very old INVITE arrives after the cache expires, and the user
   accepts this time - we get a unique personal
        telecommunication number (PTN) across multiple networks at any
        network access. partial disconnect). The PTN will be translated to an appropriate
        destination address for routing based on UA SHOULD alert
   the capabilities
        subscribed to by each service subscriber. A person may have
        multiple PTNs, e.g., user if it receives a business and private PTN. In SIP, triggered INVITE with a
        host-independent address of different user
   listed in the form user@domain serves as Requested-By header, and MAY respond differently to
   this transfer.

   If the
        PTN, which INVITE is translated into one or more host-dependent

5.2 Camp-on

   Completion acceptable, the UA sends a 200 OK. Processing of calls to busy subscriber (CCBS) allows
   subsequent triggered INVITEs (one will likely come from each
   participant in the call) follows the rules below for an existing

6.3.2 Existing Call

   When a calling user
   encountering UA receives a busy destination to be informed when triggered INVITE for an existing call, the busy
   destination becomes free, without having
   INVITE is an attempt to make a inform the participant of new call attempt.
   SIP supports services close to CCBS members for
   that call.

   The UA SHOULD first verify the token. It does so by allowing a callee to indicate
   a more opportune time to call back with computing the  Retry-After header.
   Also, calling
   hash of the Call-ID, To address, Requested-By address, and called user agents can easily record From
   address. This is compared to the URI decrypted value of
   outgoing and incoming calls, so that a the token using
   the public key of the user can re-try or return
   calls 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 single mouse click or automatically.  Call-Disposition:
   queue allows a caller 4xx
   response. If the token is verified, the UA checks to wait until see if the line becomes available. This
   service user
   listed in the Requested-By is also known as a "camp-on" service.

5.3 Call Screening

   Originating an active call screening (OCS) controls participant. If they are
   not, the ability of INVITE is rejected with a node to
   originate calls. In 4xx response (TBD: is there a fashion similar to closed case
   where the UA might not know about this participant yet?). If the user groups,
   is a
   firewall would have to participant, the INVITE is accepted. The user SHOULD NOT be used to restrict

   The list of users in the ability Also header is then examined. If this list
   contains users already known to initiate
   SIP invitations outside a designated part the UA, the local list of
   participants is updated if the network. In many
   cases, gateways version number is higher. If the list
   contains users not known to the PSTN will require appropriate authentication.

5.4 Directed Call Pickup

   Directed call pickup allows a station user to answer calls directed UA, they are added to a specific address from any other address by providing the address local list
   of the line to be answered. participants.

   The rung station must permit pickup. If UA then computes a difference set between its updated list and
   the call has list in the Also header. This set includes any users in its local
   list and not been answered at in the ringing station, regular call
   pickup occurs. If Also list. The set also includes users in both
   lists, but whose version is higher in the call has been answered already, an error local list. This set is

5.5 Directed Call Pickup with Barge-In

   Directed call pickup with barge-in establishes a 3-way call if
   included in the
   call has been answered at Also header in the original destination.

5.6 Outgoing Call Routing

   User-defined routing (UDR) allows a subscriber 200 OK to specify how
   outgoing calls, from the subscriber's location, shall be routed. SIP
   cannot specify routing preferences; this INVITE. The token in
   the 200 OK is presumed to be handled by generated as described in 6.1.

   The UA then computes a policy-based routing protocol, source routing or similar
   mechanisms.  However, the SIP  Accept-Location header may be used by
   proxies second difference set between its updated list
   and redirect servers to route calls according to caller

5.7 End-System Services

   Some telephony services can be provided by the end system, without
   involvement by SIP:

   Abbreviated dialing allows list in the Also header. This set includes any users to reach in the
   Also list not in its local subscribers without
        specifying list. The set also includes users in both
   lists, but whose version is higher than in the full address (domain or host name). For SIP, 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
        user application completes triggered BYEs are computed
   in the address to be same fashion as triggered INVITEs, except a triggered BYE
   contains no Also fields.

6.4 Sending an untriggered BYE

   A UA MAY send a fully qualified
        domain name.

   Call waiting (CW) allows the called party to receive BYE, containing Also headers, at any time. This BYE
   simulataneously terminates a notification
        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
   presences at leg with the same time, limited by local resources. Thus, it is
   up to recipient, and causes
   the called party recipient to decide whether attempt to accept another call. The
   separation of resource reservation and set up a call control may lead leg to the
   situation that parties listed
   in the called party accepts Also header. Unlike the incoming call, but that INVITE, the network or system resource allocation fails. This cannot be
   completely prevented, but if BYE response is sent
   immediately, without first adding the likely resource bottleneck various parties. Sending an
   untriggered BYE is at equivalent to a blind transfer.

   The Also headers in the
   local system, untriggered BYE MUST contain tokens. These
   tokens are generated in the user agent may be able same way described in section 6.1.

6.5 Receiving an untriggered BYE

   If the BYE corresponds to determine whether there
   are sufficient resources available or roughly track its own resource

   Consultation calling (COC) allows an existing call leg, the UA sends a subscriber 200 OK
   to place the BYE. If it does not, it sends a call on
        hold, in order 481.

   The UA then generates triggered INVITEs to initiate a new call for consultation. In
        systems using SIP, consultation calling can be implemented as
        two separate SIP calls, possibly with all participants listed in
   the temporary release Also field. Generation of
        reserved resources for the call being put on hold.

   Customized ringing (CRG) allows triggered INVITEs, and processing
   of their responses, is done in the subscriber same fashion as described in
   section 6.1. The difference is, of course, that no additional
   response is sent to allocate the BYE.

6.6 Receiving a
        distinctive ringing triggered BYE

   If the BYE doesn't correspond to an existing call leg, the UA sends a list of calling parties. In
   481. The UA then validates the token in the Requested-By header. If
   it is validated, a SIP-based
        system, this feature 200 OK is offered by sent to the user application, based
        on caller identification ( From header) provided by BYE, and the SIP
        INVITE request.

   Malicious call-leg is
   torn down.

7 Replaces header semantics

   The Replaces header is used to allow one call identification (MCI) allows the service subscriber leg to
        control the logging (making a record) of calls received that are
        of a malicious nature. In SIP, subsume another.
   The new call leg is identified by default, all calls identify the calling party combination of To, From, and
   Call-ID in the SIP servers that have forwarded INVITE carrying the
        call. In addition, calls may be authenticated using standard
        HTTP methods or transport-layer security. A callee may decide Replaces header. Replaces is a
   request header only, and MUST appear only to accept calls that are authenticated.

   Multiway calling (MWC) allows the user to establish multiple,
        simultaneous calls in INVITEs. A UAS receiving
   a Replaces header in a non-INVITE request MUST respond with other parties. For a SIP-based end
        system, the considerations for consultation calling apply.

   Terminating call screening (TCS) allows the subscriber to specify
        that incoming calls either 4xx
   status code.

   The request containing a Replaces header SHOULD be restricted or allowed, according
        to authenticated.

   The Replaces header contains a screening list and/or of call-legs, identified by time the
   URI of day or other parameters.

5.8 Billing Features

   Billing features such as account card dialing , automatic alternative
   billing , credit card calling (CCC) , reverse charging , freephone
   (FPH) , premium rate (PRM) the remote party and split charging a Call-ID. If any of these are supported through
   authentication. However, mechanisms for indicating billing
   preferences and capabilities have not yet been specified for SIP.

   Advice of charge allows valid
   call-legs as known to the user paying for 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 be informed of
   usage-based charging information. Charges incurred by reserving
   resources in the network are probably best indicated by client.

   If 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 BYE additionally contains Also headers, the call and at UAS MUST first
   generate the end of triggered INVITEs implied by the
   Closed user groups (CUGs) that restrict members to communicate only
   within Also headers. Only if
   all triggered INVITEs succeed should the group can be implemented using firewalls and SIP proxies.

5.9 User-to-User Signaling

   User-to-user signaling is supported within SIP through UAS act on the addition
   of headers, with predefined header fields such as  Subject or

5.10 Operator Services

   There Replaces

8 Example Call Flows

   This section illustrates some example call flows. Messages are a number of services which involve three parties, for
   example, a secretary dialing for boss, the

   INV B Also:C,D
   BYE A Also:Y

   Where INV implies an auto-dialer handing a call
   to a telemarketer, attended call transfer, operator services such as
   person-to-person calls INVITE request, and full-mesh "multicast".

   Operator services can be implemented in BYE a number of ways, combining
   Also,  Replaces with either  INVITE or  BYE. BYE request. The callee's end system
   does not have to be cognizant of
   letter after the fact that this an operator
   service. The services make use of method is the  Call-ID rules that stipulate Request URI. Also:C,D implies that a new  INVITE for an existing  Call-ID does not alert
   URI's C and D were in the user,
   but is added silently. Also header.

8.1 Basic Transfer

   Figure 1 shows 2 exemplifies the example of an autodialer connecting to basic transfer in a two party call. A first
   sets up a
   prospective customer and, once the callee picks up, transfering the call to B, and then transfers B to C.

8.2 Basic Add Party

   Figure 3 exemplifies the telemarketer. (This goes basic add party. A and B are already in a
   call. A adds C to show that SIP is morally

          T  ------------.         n
         ^ :                    ----> nth step; INVITE (Also:)
         | :                    ....> nth step; BYE (Also:)
    2(C) | : 4             3(
         | :                 (
         | V        5         V
            .................> 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
     auto dialer    1      customer

   200 OK


   BYE B Also:C

   200 OK
<------------------    INV C ReqBy:A

                       200 OK


   Figure 1: Telemarketer example

5.11 Multipoint Control Unit (MCU) Services 2: Transfer Message Flow

   In the language of IN services, SIP supports:

   Conferencing (CON) allows example, C acts on the user untriggered INVITE, and sends a
   triggered INVITE to communicate simultaneously B. B responds with
        multiple parties, which may a 200 OK, also communicate among themselves.
        SIP can initiate IP multicast conferences with any number of
        participants, conferences where media are mixed by alerting it to
   D's new presence in the call. D, acting on its untriggered INVITE,
   sends a conference
        bridge (multipoint control unit 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 MCU) and,
   for exceptional
        applications both INVITEs cross each other on the wire (in this case, both
   sides back off with a small number of participants, fully-meshed
        conferences, where each participant sends 500 and receives data to
        all a Retry-After, so that eventually one
   invitation reaches the other participants. This is described side without an invite in more detail transit in
        Sections 5.11 and 5.12.

   Conference calling add-on allows a user the
   other direction).

   Having received an INVITE from C, D doesn't bother to add INVITE C. Both
   D and drop participants
        once the conference C then OK their respective INVITEs.

8.4 Party leaves during add party

   In this example (Figure 5), a three party call is active. Participants in the SIP session
        accomplish this by sending  INVITE place between A,

A              B                  C

         INV C Also:B
                INV B Also:C ReqBy:A
                     200 OK
          200 OK

   Figure 3: Add Party Message Flow

   B and  BYE requests to C. A adds another user, D, and shortly thereafer, C leaves the

   Since D learns from B that C has left the call, D does not bother to be added
   contact C, and dropped. If A wants B responds right away to drop out of a
        conference, it sends the add party. The result is
   now a  BYE request three party call with " Replaces: *".

   Conference calling meet-me (MMC) allows the user A,B, and D.

9 A note on multicast media

   Another useful service, which we have not discussed so far, is to set up
   transition a conference or multi-party call, indicating the date, time,
        conference duration, conference from distributing 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 through multi-unicast
   to connect using distribution through multicast. In fact, this is not a SIP issue
   at the actual time
        of the conference; instead, they simply subscribe 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 addresses listed is acceptable,
   both B and C respond with a 200 OK. No SDP is needed in the announcement. For MCU-based
        conferences, the session description may contain the address of
        the MCU response,
   as per [2].

   If B and C decide to be called at the time of the conference.

   Some conferences use a multipoint control unit (MCU) switch to mix, convert
   and replicate media streams. While this solution has scaling
   problems, multicast, 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 their interest
   (but not required) to send a new participant and indicates re-INVITE to the address of 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
                               200 OK
                      200 OK

   Figure 4: Add Party During Add Party Message Flow

   know about, containing the MCU in SDP describing the
   Also header. multicast session. The invitee then contacts the MCU using
   result is that some or all of the same session
   description and requests to be added to sessions on the call, just like a normal
   two-party call.

   Parties inviting others call-legs
   transition to a conference do multicast. If not all have to know that transitioned, the
   conference media user may
   still need to send some packets unicast.

   There is managed by an MCU. The inviting party A treats no capability for determining the MCU M like another participant and includes it in codec parameters for the  Also list.
   The newly invited participant B invites
   multicast session based on the MCU, which in turn sends
   a  Replaces header with all participants. (See example in Section
   3.5). Figure 2 shows intersection of the transition from a fully-meshed conference
   (see below) to an MCU-based conference.

      MCU             MCU -----------,
                   1  ^   2         |
             Also:B  /    Replace:A |
                    /               |
                   /    3   V        |
   A........B      A.<xxxxx.B        |
   : :    : :      : ^    : ^        |
   :  :  :  :      :  x  :  x       4| Replace: A,B
   :   ::   :      : 6 x:   x 5      |
   :   ::   :      :   :x   x        |
   :  :  :  :      :  :  x  x        |
   : :    : :      : :    x x        |
   D........C      D........C <------'

   ---->  INVITE
   xxxx>  BYE

   Figure 2: Transition from fully-meshed to MCU-based capabilities of
   each participant. The model for multicast media distribution in a
   tightly coupled conference

   Operator-assisted dial-out: is identical to that for loosely coupled
   sessions. The operator calls each participant, and
        simply indicates initiator of the MCU multicast session chooses a codec, and
   that is what is used. Note, however, that in the  Also list. The  Call-ID and/or
        the address used by case where the operator serves

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
                200 OK

   Figure 5: Party Leaves During Add Message Flow

   sessions start as multi-unicast, the identifier to originator will know the
        MCU. For example:

   O -> A:    INVITE A SIP/2.0
              From: O
              Also: conference176@M

   A -> M:    INVITE conference176@M
              Requested-By: O

   Meet-me: The leader and participants dial into their conference at
   capabilities of all the scheduled time with an assigned conference identifier 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 code.

   A -> M: issues. An INVITE conference189@M
              From: A

5.12 Fully-Meshed Conferences
   For very small conferences, such as adding a third party
   with an Also cause the recipient to a two-
   party call, multicast may not always be appropriate add or available.
   Instead, when inviting a new participant, drop other parties,
   possibly without user interaction. This implies that authorization of
   the caller asks 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 new
   member 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 call refresh things and
             periodically re-flood the remaining members. participant list, in an attempt
             to keep things synchronized?

        4.   The  Call-ID for all
   participants version/status concept is the same.

6 Acknowledgements

   Parameters still very vague. Does it
             work? Is it needed?

        5.   Conference out of consultation for multi-party calls - not
             clear the terminal negotiation Replaces mechanism in the Location
   header were influenced by Scott Petrack's CMA design.

7 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
   levels," RFC Request for Comments (Best Current Practice) 2119, Internet
   Engineering Task Force, Mar. 1997.

   [2] M. Handley, H. Schulzrinne, and E. Schooler, and J. Rosenberg, "SIP: Session
   session initiation protocol," Internet Draft, Request for Comments (Proposed
   Standard) 2543, Internet Engineering Task Force, Nov. 1997.  Work in progress. Mar. 1999.

   [3] M. Handley H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "SDP: Session description "RTP: a
   transport protocol for real-time applications," Request for Comments
   (Proposed Standard) 1889, Internet Engineering Task Force, Jan. 1996.

   [4] C. Elliott, "A 'sticky' conference control protocol," vol. 5, pp.
   97--119, 1994.

   [5] S. Hanna, B. Patel, and M. Shah, "Multicast address dynamic
   client allocation protocol (MADCAP)," Internet Draft, Internet
   Engineering Task Force, Mar. 1997. May 1999.  Work in progress.

   [4] International Telecommunication Union, "Integrated services
   digital network (ISDN) service capabilities -- definition

   Full Copyright Statement

   Copyright (c) The Internet Society (1999). All Rights Reserved.

   This document and translations of
   supplementary services," Recommendation I.250, Telecommunication
   Standardization Sector of ITU, Geneva, Switzerland, 1993.

   [5] International Telecommunication Union, "General recommendations it may be copied and furnished to
   others, and derivative works that comment on telephone switching or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and signaling -- intelligent network:
   Introduction 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 intelligent network capability set 1," Recommendation
   Q.1211, Telecommunication Standardization Sector of ITU, Geneva,
   Switzerland, Mar. 1993. 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

   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

                           Table of Contents

   1          Terminology .........................................    1
   2          Introduction ........................................    1    2
   3          Headers .............................................          Services ............................................    2
   3.1         Accept-Location ....................................    2        Blind Transfer ......................................    3
   3.2         Also ...............................................    2
   3.3         Call-Disposition        Transfer and Hold ...................................    4
   3.4         Location ...........................................
   3.3        Transfer with Consultation ..........................    5
   3.5         Replaces ...........................................
   3.4        Multi-party Conferencing ............................    6
   3.4.1      Loosely Coupled Multicast Conference ................    6
   3.4.2      Distributed Full Mesh ...............................    7
   3.6         Requested-By .......................................
   3.4.3      Dial-in Bridge ......................................    8
   3.4.4      Ad-hoc Bridge .......................................    9
   3.4.5      Conference out of Consultation ......................   10
   4          Status Code Definitions .............................    8          Discussion of Implementation Options ................   11
   4.1        181 Queued ..........................................    8        Transfer ............................................   11
   4.2        Full mesh conferences ...............................   12
   4.2.1      Approach I: Caretaker ...............................   13
   4.2.2      Approach II: Flooding ...............................   13
   4.3        Dial-up Bridges .....................................   15
   4.4        Conference out of Consultation ......................   17
   4.5        Ad-hoc conference bridging ..........................   17
   4.6        Transfers to Multiparty Conferences .................   18
   5          ISDN and Intelligent Network Services ...............    8          Header Syntax .......................................   19
   5.1        Call Redirection and "Number"-Translation Services
   ................................................................    9        Also ................................................   19
   5.2        Camp-on .............................................   10        Replaces ............................................   20
   5.3        Requested-By ........................................   20
   6          Also and Requested-By Header Semantics ..............   20
   6.1        Sending an Untriggered INVITE .......................   20
   6.2        Receiving an Untriggered INVITE .....................   22
   6.2.1      New Call Screening ......................................   10
   5.4        Directed ............................................   22
   6.2.2      Existing Call Pickup ................................   11
   5.5        Directed .......................................   24
   6.3        Receiving a Triggered INVITE ........................   24
   6.3.1      New Call Pickup with Barge-In ..................   11
   5.6        Outgoing ............................................   24
   6.3.2      Existing Call Routing ...............................   11
   5.7        End-System Services ................................. .......................................   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
   5.8        Billing Features ....................................         Open Issues .........................................   31
   5.9        User-to-User Signaling ..............................   13
   5.10       Operator Services ...................................   13
   5.11       Multipoint Control Unit (MCU) Services ..............   13
   5.12       Fully-Meshed Conferences ............................   15
   6         Acknowledgements ....................................   16
   7   32
   13         Bibliography ........................................   16   32