[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 draft-ietf-sipping-3pcc

Internet Engineering Task Force                                     SIP WG
Internet Draft                    Rosenberg/Peterson/Schulzrinne/Camarillo
draft-rosenberg-sip-3pcc-03.txt   dynamicsoft,Neustar,Columbia U.,Ericsson
November 21, 2001
Expires: May 2002


                    Third Party Call Control in SIP

STATUS OF THIS MEMO

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

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

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   To view the list Internet-Draft Shadow Directories, see
   http://www.ietf.org/shadow.html.


Abstract

   This document discusses the usage of the Session Initiation Protocol
   (SIP) for third party call control. Third party call control refers
   to the ability of one entity to create a call in which communications
   is actually between other parties. We present a SIP mechanism for
   accomplishing third party call control that does not require any
   extensions or changes to SIP.


1 Introduction

   In the traditional telephony context, third party call control allows
   one entity (which we call the controller) to set up and manage a
   communications relationship between two or more other parties. Third
   party call control is often used for operator services (where an
   operator creates a call that connects two participants together), and



Rosenberg/Peterson/Schulzrinne/Camarillo                      [Page 1]

Internet Draft                    3pcc                 November 21, 2001


   conferencing.

   On the Internet, a wider range of services are enabled through a
   third party session control mechanism. This is because other IP
   applications, such as web, email, presence, instant messaging, and
   chat can now be brought into the picture. An excellent example is
   click-to-dial. This service allows a user to click on a web page when
   they wish to speak to a customer service representative. The web
   server then creates a call between the user and a customer service
   representative. The call can be between two phones, a phone and an IP
   host, or two IP hosts.

   In order to support third party call control applications, a
   mechanism is needed that allows a controller to create, modify, and
   terminate calls with other entities. In this document, we present a
   mechanism using the Session Initiation Protocol (SIP) [1] which
   allows a controller to execute third party services. The mechanism is
   not an extension to SIP. It is merely an application of the tools
   enabled through RFC 2543. A controller can create calls between any
   entity that contains a normal SIP user agent. After desribing the
   mechanism, we present three third party services which take
   advtantage of this mechanism. One is click-to-dial, the second is a
   feature that enables a mid-call announcement for credit card
   authorization , and the third is a timed conference bridge
   initiation.

2 Third Party Control

   The basic idea behind the third party mechanism is simple. A
   controller first calls one of the participants, A, and presents the
   INVITE without any media. When this call is complete, the controller
   has the SDP needed to communicate with A. The controller then uses
   SDP A to initiate a call to participant B. When this call is
   completed, the controller has the SDP needed to communicate with B.
   This information is then passed to A. The result is that there is a
   call leg between the controller and A, a call leg between the
   controller and B, but media between A and B.

   To demonstrate the recommended call flow for achieving this result,
   we step through an evolution of the call flows and explain the
   benefits and drawbacks of each, eventually arriving at the
   recommended flow.

2.1 First Attempt

   The controller first sends an INVITE to the first user, A, whose
   phone is to ring. This is a standard INVITE, but it contains no SDP.
   When A answers, the controller does not yet send an ACK. It generates



Rosenberg/Peterson/Schulzrinne/Camarillo                      [Page 2]

Internet Draft                    3pcc                 November 21, 2001


   a second INVITE. This INVITE is addressed to the second user, B, to
   be connected in the call. This INVITE contains the SDP as received
   from the 200 OK from A. When the 200 OK to this second INVITE
   arrives, the controller ACK s it, takes the SDP, and includes that in
   the ACK for the first call. A flow diagram for this mechanism is
   given in 1.


   This flow is simple, requires no manipulation of the SDP by the
   controller, and works for any media types supported by both
   endpoints. However, it has a serious timeout problem. User B may not
   answer the call immediately. The result is that the controller cannot
   send the ACK to A. This causes A to retransmit the 200 OK response
   periodically. In fact, if B does not answer within 32 seconds, the
   call with A times out.

2.2 Second Attempt

   To fix this problem, consider the call flow in Figure 2. The
   controller first sends an INVITE to the first user whose phone is to
   ring, user A. This is a standard INVITE, but its SDP contains a
   single audio media line, with one codec, a random port number (but
   not zero), and a connection address of 0.0.0.0. This creates an
   initial media stream "on hold".

   When A answers, the controller sends an ACK. It then generates a
   second INVITE. This INVITE is addressed to the second user, B, to be
   connected in the call. This INVITE contains the SDP as received from
   the 200 OK from A. When the 200 OK to this second INVITE arrives, the
   controller ACK s it, takes the SDP, and then re-INVITEs the first
   user with this updated SDP.


   This flow has the advtange that all final responses are immediately
   ACKed. If therefore does not suffer from the timeout and message
   inefficiency problems of flow 1. However, it too has troubles. First
   off, it requires that the controller know the media types to be used
   for the call (since it must generate an "on hold" SDP, which requires
   media lines). Secondly, the first INVITE to A contains media on hold.
   The controller expects that the response contains valid SDP for the
   call. However, experience has shown that many UAs respond to media-
   on-hold with media-on-hold, which won't work. Lastly, the flow
   assumes that after the re-INVITE, user A returns the same SDP, SDP A,
   as was returned to the original INVITE. This may not be the case. If
   it is not, the controller needs to re-INVITE B, which may result in
   getting a different SDP, SDP C, in the 200 OK. Then, the controller
   needs to re-INVITE A again, and so on. The result is an infinite loop
   of re-INVITEs. It is possible to break this cycle by having very



Rosenberg/Peterson/Schulzrinne/Camarillo                      [Page 3]

Internet Draft                    3pcc                 November 21, 2001




       A                Controller            B
        |  INV no SDP       |                  |
        |<------------------|                  |
        |                   |                  |
        |  200 SDP A        |                  |
        |-----------------> |  INV SDP A       |
        |                   |----------------->|
        |                   |                  |
        |                   |  200 SDP B       |
        |                   |<-----------------|
        |                   |                  |
        |                   |  ACK             |
        |  ACK SDP B        |----------------->|
        |<------------------|                  |
        |                   |                  |
        |                   |       RTP        |
        |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx |
        |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx |
        |                   |                  |
        |                   |                  |
        |                   |                  |
        |                   |                  |
        |                   |                  |
        |                   |                  |
        |                   |                  |
        |                   |                  |














   Figure 1: 3pcc Flow Attempt 1


   smart UAs which can return the same SDP whenever possible, or really
   smart controllers that can analyze the SDP to determine if a re-
   INVITE is really needed. However, we wish to keep this mechanism
   simple, and avoid SDP awareness in the controller. As a result, this



Rosenberg/Peterson/Schulzrinne/Camarillo                      [Page 4]

Internet Draft                    3pcc                 November 21, 2001




       A                Controller            B
        |  INV held SDP     |                  |
        |<------------------|                  |
        |                   |                  |
        |  200 SDP A        |                  |
        |-----------------> |  INV SDP A       |
        |  ACK              |----------------->|
        |<----------------- |                  |
        |                   |  200 SDP B       |
        |                   |<-----------------|
        |                   |                  |
        |                   |  ACK             |
        |  INV SDP B        |----------------->|
        |<------------------|                  |
        |  200 OK SDP A     |                  |
        |------------------>|                  |
        |  ACK              |                  |
        |<------------------|                  |
        |                   |     RTP          |
        |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx |
        |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx |
        |                   |                  |
        |                   |                  |
        |                   |                  |
        |                   |                  |
        |                   |                  |
        |                   |                  |
        |                   |                  |
        |                   |                  |



   Figure 2: 3pcc Flow Attempt 2


   flow is not really workable. We show it here for completeness.

2.3 Third Flow

   The general purpose recommended flow is shown in Figure 3.


   First, the controller sends an INVITE to the first user, A, without
   any SDP (which is good, since it means that the controller doesn't
   need to assume anything about the media of the devices). User A
   responds with its SDP, A1, in a 200 OK, which is immediately ACKed
   with an on-hold SDP generated by the controller.



Rosenberg/Peterson/Schulzrinne/Camarillo                      [Page 5]

Internet Draft                    3pcc                 November 21, 2001




  A                Controller            B
  |  INV  no SDP      |                  | time t = 0
  |<------------------|                  |
  |                   |                  |
  |  200 SDP A1       |                  |
  |-----------------> |                  |
  |                   |                  |
  |    ACK  SDP held  |                  |
  |<------------------|                  |
  |                   |                  |
  |                   |  INV no SDP      |
  |                   |----------------->|
  |                   |                  |
  |                   |  200 SDP B       |
  |                   |<-----------------|
  |     INV SDP B'    |                  |
  |<------------------|                  |
  |                   |                  |
  |  200 SDP A2       |                  |
  |-----------------> |                  |
  |                   |                  |
  |                   |  ACK  SDP A2'    |
  |  ACK              |----------------->|
  |<------------------|                  |
  |                   |                  |
  |                   |       RTP        |
  |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx |
  |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx |
  |                   |                  |
  |                   |                  |



   Figure 3: 3pcc Recommended Flow


   Next, the controller sends an INVITE to the second user, B, also
   without SDP. The SDP in the 200 OK, SDP B, is used to create a re-
   INVITE to the first user. That re-INVITE is based on SDP B, but may
   need to be reorganized to match up media lines. We therefore call
   that SDP B'. Since this is a re-INVITE, it should complete quickly in
   the general case. Thats good, since user B is retransmitting their
   200 OK, waiting for an ACK. The SDP in the 200 OK from A, SDP A2
   (which may be different than A1), is then passed to user B in the
   ACK. It may also need reorganization to match up m lines.

   This flow has many benefits. First, it will usually operate without



Rosenberg/Peterson/Schulzrinne/Camarillo                      [Page 6]

Internet Draft                    3pcc                 November 21, 2001


   any spurious retransmissions or timeouts (although this may still
   happen if a re-INVITE is not responded to quickly). Secondly, it does
   not require the controller to guess the media that will be used by
   the participants. Thirdly, it does not assume that a device responds
   properly to an INVITE with SDP on hold.

   There are some drawbacks. The controller does need to perform SDP
   manipulations. Specifically, it must take some SDP, and generate
   another SDP which has the same media composition, but is on hold.
   Secondly, it may need to reorder an SDP X, so that its media lines
   match up with those in some other SDP, Y. Finally, the flow is far
   more complicated than the simple and elegant flow in Figure 1.

   As a result of these drawbacks, it is our recommendation that flow 1,
   shown in Figure 1 be used if, and only if, the controller knows that
   user B is actually an automata that will answer the call immediately.
   This is the case for devices such as media servers, conferencing
   servers, and messaging servers, as described in [2]. Since we expect
   a great deal of third party call control to be to automata, special
   caseing this scenario is reasonable.

   For calls to unknown entities, or to entities known to represent
   people, it is recommended that the flow in Figure 3 be used for third
   party call control. It is most likely to be interoperable and most
   likely to work in the largest number of cases.

2.4 Continued Processing

   Once the calls are established, both participants believe they are in
   a single point-to-point call with some control system (assuming the
   controller identified itself as such in the From field of the
   INVITE). However, they are exchanging media directly with each other,
   rather than with the controller. The result is that the controller
   has set up a call between both participants.

   Since the controller is still a central point for signaling, it now
   has complete control over the call. If it receives a BYE from one of
   the participants, it can create a new BYE and hang up with the other
   participant. This is shown in 4.


   As an alternative, when the controller receives a BYE from A, it can
   generate a new INVITE to a third party, C, and connect B to that
   participant instead. A call flow for this is shown in 5, assuming the
   case where C represents an end user, not an automata. Note that it is
   simply the bottom 2/3 of the primitive 3pcc flow of Figure 3.





Rosenberg/Peterson/Schulzrinne/Camarillo                      [Page 7]

Internet Draft                    3pcc                 November 21, 2001





        A                Controller            B
        |                   |                  |
        |                   |                  |
        |  BYE From A       |                  |
        |-----------------> |   BYE From Cont. |
        |      200 OK       |----------------> |
        |<----------------- |   200 OK         |
        |                   |<---------------- |
        |                   |                  |
        |                   |                  |
        |                   |                  |
        |                   |                  |
        |                   |                  |
        |                   |                  |
        |                   |                  |
        |                   |                  |
        |                   |                  |
        |                   |                  |



   Figure 4: Hanging Up with 3PCC


   From here, new parties can be added, removed, transferred, and so on,
   as the controller sees fit.

   The general idea behind the mechanism is that there is a point to
   point SIP relationship between each participant and the controller.
   However, by passing the SDP it receives from one participant to
   another, it can causes users to actually communicate with each other
   rather than the controller.

3 Back to Back User Agents

   The call flow in Section 2.3 assumes that the controller is the
   entity that initiates the call. It is possible for the controller to
   take ownership of a call setup by a different party by acting as a
   Back to Back User Agent (B2BUA). The call flow in this case is shown
   in Figure 6.


   In this call flow, the controller looks deceptively like a proxy, but
   it is not. The controller acts as a UAS for the INVITE received by A,
   and then as a UAC when it initiates a call to B. It is this fact
   which allows the controller to generate its own ringing messages, or



Rosenberg/Peterson/Schulzrinne/Camarillo                      [Page 8]

Internet Draft                    3pcc                 November 21, 2001




        A                Controller            B                  C

        |                   |                  |                  |
        |                   |                  |                  |
        |  BYE From A       |                  |                  |
        |-----------------> |    INV no SDP    |                  |
        |      200 OK       |------------------------------------>|
        |<----------------- |                  |  200 SDP C       |
        |                   |<------------------------------------|
        |                   |                  |                  |
        |                   |                  |                  |
        |                   | INV SDP C'       |                  |
        |                   |----------------->|                  |
        |                   | 200 SDP B2       |                  |
        |                   |<-----------------|                  |
        |                   | ACK              |                  |
        |                   |----------------->|                  |
        |                   |                  |                  |
        |                   |                  |     ACK SDP B2'  |
        |                   |------------------------------------>|
        |                   |                  |                  |
        |                   |                  |                  |
        |                   |                  |   RTP            |
        |                   |                  | xxxxxxxxxxxxxxxx |
        |                   |                  | xxxxxxxxxxxxxxxx |




   Figure 5: Alternative to Hangup


   to generate an ACK for a 200 OK, both of which are done in this call
   flow.

   Once set up, the controller is exactly in the same state as if it had
   initiated the call as described in Section 2.3. The controller can
   hang up to one side, hang up to both sides, reconenct the users to
   media servers, and so on.

4 Third party call control and SDP preconditions

   In unicast sessions there is a number of media streams flowing
   between two entities. In order to perform resource reservation it is
   necessary to know the session descriptions from both parties. When
   third party call control is performed the information needed to
   establish the QoS required is not available from the beginning. The



Rosenberg/Peterson/Schulzrinne/Camarillo                      [Page 9]

Internet Draft                    3pcc                 November 21, 2001




  A                Controller            B
  |  INV  SDP A1      |                  | time t = 0
  |------------------>|                  |
  |  180 Ringing      |                  |
  |<------------------|  INV SDP A1      |
  |                   |----------------->|
  |                   |                  |
  |                   |                  |
  |                   |                  |
  |                   |                  |
  |                   |                  |
  |                   |                  |
  |                   |                  |
  |                   |  200 SDP B       |
  |                   |<-----------------|
  |                   |  ACK             |
  |     200 SDP B     |----------------->|
  |<------------------|                  |
  | ACK               |                  |
  |-----------------> |                  |
  |                   |                  |
  |                   |                  |
  |                   |       RTP        |
  |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx |
  |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx |
  |                   |                  |
  |                   |                  |







   Figure 6: Back to Back User Agent


   call flow shown in Figure 7 shows how the exchange of SDPs between
   both parties can be performed.


   The controller INVITEs A in (1). At this point of time there is no
   information available about codecs to be used port numbers or IP
   addresses. The SDP of this INVITE just contains SDP preconditions and
   the media stream types (audio, video, etc...). As specified in [3],
   the called UAS returns a 183 immediately containing SDP information
   needed for QoS signaling (2).



Rosenberg/Peterson/Schulzrinne/Camarillo                     [Page 10]

Internet Draft                    3pcc                 November 21, 2001


   INVITE (3) contains the SDP received from A. This INVITE is sent to
   B. When B responses with (4) 183 it is ready to perform resource
   reservation. However, B will not start resource reservation until the
   PRACK (7) is received. This allows B's SDP to be sent to A in (5).
   This way both parties have all the information needed to perform
   resource reservation. Note that, since reliable provisional responses
   are used [4], the 183 (2) is retransmitted until the PRACK (5)
   arrives from the controller. This PRACK is transmitted only when the
   183 arrives from B (4). Fortunately, this 183 is generated
   automatically, so that the first 183 (2) should not be retransmitted
   that much, if at all.

   The PRACK matching (2) is sent at (5). This PRACK is not sent before
   because it is used to send B's SDP to A. The controller does not get
   this information until (4).

   When the preconditions from B to the controller and from A to the
   controller are met two COMETs are received (9) and (11). At this
   point of time is up to the controller to let the session
   establishment go on sending a COMET to A (13). When A accepts joining
   the session (15), a COMET (16) is sent to B so B is alerted.


        This is really complex; and it also works such that the
        controller decides whether preconditions are used. Is there
        a simpler solution?

5 Click to Dial

   The first application of this capability we discuss is click to dial.
   In this service, a user is browsing the web page of an e-commerce
   site, and would like to speak to a customer service representative.
   They click on a link, and a call is placed to a customer service
   representative. When the representative picks up, the phone on the
   user's desk rings. When they pick up, the customer service
   representative is there, ready to talk to the user.

   We assume for purposes of this discussion that the web server is
   actually an applications server that contains an http interface. In
   this case, when the user clicks on the URL, the application server
   knows, through cookies or some other state mechanism, the addresses
   of the participants to be connected.

   The call flow for this service is given in 8. Note that it is
   identical to that of Figure 3, with the exception that the service is
   triggered through an http GET request when the user clicks on the
   link.




Rosenberg/Peterson/Schulzrinne/Camarillo                     [Page 11]

Internet Draft                    3pcc                 November 21, 2001




       Controller              A                  B

           |    (1) INVITE     |                  |
           |------------------>|                  |
           |    (2) 183 SDP A  |                  |
           |<------------------|                  |
           | (3) INVITE SDP A  |                  |
           |------------------------------------->|
           |    (4) 183 SDP B  |                  |
           |<-------------------------------------|
           | (5) PRACK SDP B   |                  |
           |------------------>|                  |
           | (6) 200 OK (PRACK)|                  |
           |<------------------|                  |
           |    (7) PRACK      |                  |
           |------------------------------------->|
           | (8) 200 OK (PRACK)|                  |
           |<-------------------------------------|
           |    (9) COMET      |                  |
           |<-------------------------------------|
           |(10) 200 OK (COMET)|                  |
           |------------------------------------->|
           |    (11) COMET     |                  |
           |<------------------|                  |
           |(12) 200 OK (COMET)|                  |
           |------------------>|                  |
           |    (13) COMET     |                  |
           |------------------>|                  |
           |(14) 200 OK (COMET)|                  |
           |<------------------|                  |
           |(15) 200 OK (INVITE)                  |
           |<------------------|                  |
           |    (16) COMET     |                  |
           |------------------------------------->|
           |(17) 200 OK (COMET)|                  |
           |<-------------------------------------|
           |(18) 200 OK (INVITE)                  |
           |<-------------------------------------|
           |    (19) ACK       |                  |
           |------------------>|                  |
           |    (20) ACK       |                  |
           |------------------------------------->|
           |                   |                  |

       Controller              A                  B



   Figure 7: Call Flow for Preconditions

Rosenberg/Peterson/Schulzrinne/Camarillo                     [Page 12]

Internet Draft                    3pcc                 November 21, 2001



   We note that this service can be provided through other mechanisms,
   namely PINT [5]. However, there are numerous differences between the
   way in which the service is provided by pint, and the way in which it
   is provided here:

        o The pint solution enables calls only between two PSTN
          endpoints. The solution described here allows calls between
          PSTN phones (through SIP enabled gateways) and native IP
          phones.

        o When used for calls between two PSTN phones, the solution here
          may result in a portion of the call being routed over the
          Internet. In pint, the call is always routed only over the
          PSTN. This may result in better quality calls with the pint
          solution, depending on the codec in use and QoS capabilities
          of the network routing the Internet portion of the call.

        o The PINT solution requires extensions to SIP (PINT is an
          extension to SIP), whereas the solution described here is done
          with baseline SIP.

        o The PINT solution allows the controller (acting as a PINT
          client) to "step out" once the call is established. The
          solution described here requires the controller to maintain
          call state for the entire duration of the call.

6 Mid-Call Announcement Capability

   The third party call control mechanism described here can also be
   used to enable mid-call announcements. Consider a service for pre-
   paid calling cards. Once the pre-paid call is established, the system
   needs to set a timer to fire when they run out of minutes. When this
   timer fires, we would like the user to hear an announcement which
   tells them to enter a credit card to continue. Once they enter the
   credit card info, more money is added to the pre-paid card, and the
   user is reconnected to the destination party.

   We consider here the usage of third party call control just for
   playing the mid-call dialog to collect the credit card information.

   We assume the call is set up, perhaps as described in Section 3, so
   that the controller is in the call. When the timer fires, we wish to
   connect the caller to a dialog server. The flow for this is shown in
   Figure 9.


   When the timer expires, the controller places the called party on



Rosenberg/Peterson/Schulzrinne/Camarillo                     [Page 13]

Internet Draft                    3pcc                 November 21, 2001


   hold. It then sends an INVITE without SDP to the the pre-paid caller.
   The SDP returned from the caller (which should be the same as the SDP
   it returned previously), is used in an INVITE to the media server
   which will be collecting digits. The media server offers its SDP in
   the response. The controller then sends an ACK to the pre-paid user
   using the SDP returned from the media server. The result is that now,
   the media server and the pre-paid caller have their media streams
   connected. The media server plays an announcement, and prompts the
   user to enter a credit card number. After collecting the number, the
   card number is validated. The controller can then hang up the call to
   the media server. How the controller can know when to hang up the
   call is outside the scope of this document, but is described in
   complete detail in [2], which discusses the interface between
   controllers and media servers.

   After hanging up with the media server, the controller reconnects the
   user to the original called party.

7 Timed Conference Intitation

   In this service, a conference bridge is booked for some number of
   participants. In order to make sure the conference begins on time,
   the conference bridge will call each participant at the time of the
   call. If a participant doesn't answer, the bridge tries to contact
   them again (unless they call in) five minutes later.

   The controller makes use of a conference server for this service. The
   conference server is of the type described in [2], which means that
   it will mix together all calls for the same request URI. The
   controller will use third party call control to get each participant
   to send media to the conference server. Note that since the
   conference server is an automata, we use the 3pcc flow of Figure 1.

   The call flow for this service is shown in Figure 10. The controller
   calls each participant, then calls the conference server (using the
   same request URI for all calls to the conference server). The result
   is that each participant sends media to the conference server, and
   the conference server sends media back. The third user, user C, does
   not answer right away, and is re-tried a few minutes later.


8 Implementation Notes

   Most of the work involved in supporting third party call control is
   within the controller. A standard SIP UA should be controllable in
   the mechanism described here. However, the mechanism relies on a few
   features that might not be implemented. As such, we strongly
   recommend implementors of user agent servers to support the



Rosenberg/Peterson/Schulzrinne/Camarillo                     [Page 14]

Internet Draft                    3pcc                 November 21, 2001




 Customer          Controller           Gateway             Users PC
 Service                                 to
 Representative                         Customer


   |                   |    HTTP GET      |                   |
   |                   |<-------------------------------------|
   |                   |     200 OK       |                   |
   |                   |------------------------------------->|
   |                   |                  |                   |
   |                   |                  |                   |
   |  INV no SDP       |                  |                   |
   |<------------------|                  |                   |
   |  200 SDP A1       |                  |                   |
   |------------------>|                  |                   |
   |  ACK SDP held     |                  |                   |
   |<------------------|  INV no SDP      |                   |
   |                   |----------------->|                   |
   |                   |  200 SDP B1      |                   |
   |                   |<-----------------|                   |
   |  INV SDP B1'      |                  |                   |
   |<------------------|                  |                   |
   |  200 SDP A2       |                  |                   |
   |------------------>|                  |                   |
   |                   |  ACK SDP A2'     |                   |
   |                   |----------------->|                   |
   |  ACK              |                  |                   |
   |<------------------|                  |                   |
   |                   |                  |                   |
   |                   |       RTP        |                   |
   |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx |                   |
   |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx |                   |
   |                   |                  |                   |
   |                   |                  |                   |
   |                   |                  |                   |
   |                   |                  |                   |
   |                   |                  |                   |
   |                   |                  |                   |
   |                   |                  |                   |
   |                   |                  |                   |






   Figure 8: Click to Dial Call Flow



Rosenberg/Peterson/Schulzrinne/Camarillo                     [Page 15]

Internet Draft                    3pcc                 November 21, 2001




  Pre-paid         Controller           Called              Media
   Caller                               Party               Server
  "A"                                     "B"                 "C"


   |       RTP         |                  |                   |
   |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx|                   |
   |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx|                   |
   |                   | INV SDP 0 (hold) |                   |
   |                   |----------------->|                   |
   |                   | 200 OK SDP B2    |                   |
   |                   |<-----------------|                   |
   |                   |    ACK           |                   |
   |                   |----------------->|                   |
   |  INV no SDP       |                  |                   |
   |<------------------|                  |                   |
   |  200 SDP A        |                  |                   |
   |------------------>| INV SDP A        |                   |
   |                   |------------------------------------->|
   |                   |                  |  200 SDP C        |
   |  ACK SDP C        |<-------------------------------------|
   |<------------------| ACK              |                   |
   |                   |------------------------------------->|
   |                   |                  |                   |
   |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx|
   |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx|
   |                   |  BYE             |                   |
   |                   |------------------------------------->|
   |                   |  200 OK          |                   |
   |                   |<-------------------------------------|
   |                   | INV no SDP       |                   |
   |                   |----------------->|                   |
   |                   | 200 SDP B2       |                   |
   |     INV SDP B2'   |<-----------------|                   |
   |<------------------|                  |                   |
   |     200 SDP A3    |                  |                   |
   |------------------>|   ACK A3'        |                   |
   |     ACK           |----------------->|                   |
   |<------------------|                  |                   |
   |                   |                  |                   |
   |       RTP         |                  |                   |
   |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx|                   |
   |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx|                   |
   |                                      |                   |









Rosenberg/Peterson/Schulzrinne/Camarillo                     [Page 16]

Internet Draft                    3pcc                 November 21, 2001


   Figure 9: Mid-Call Announcement


        o Re-invites that change the port to which media should be sent

        o Re-invites that change the connection address

        o Re-invites that add a media stream

        o Re-invites that remove a media stream (setting its port to
          zero)

        o Re-invites that add a codec amongst the set in a media stream

        o Hold (connection address of zero)

        o Initial invites on hold

        o Initial invites with no SDP

        o Re-invites with no SDP (in which case the UAS returns the same
          SDP it returned previously)

9 Security Considerations

   The mechanism described here introduces several security
   considerations. The first issue is the calling party identities
   delivered to the participants which the controller invites. The
   controller could indicate that the call is from itself (From:
   sip:controller@company.com), but in many cases, the service is more
   usable if it "spoofs" the identity of the participant that is
   actually calling. However, to differentiate legitimate use of 3pcc
   from real attacks, user agents SHOULD authenticate the requests. The
   controller MUST sign the request as itself, not as A or B (it cannot
   sign as A or B in any case). This will allow both parties to know
   that the call is actually being established through a controller, but
   on behalf of another user. User agents SHOULD be configured to
   authorize requests from entities known to be controllers.

   Note that this will result in SIP messages whose From field does not
   match the identity of the signator (as indicated in the signed-by
   field of the request).

   The third party mechanism can also have an impact on encryption of
   the media that is part of the session. If negotiation of session keys
   is done through some kind of key exchange within SIP, the controller
   will, in all likelihood, not be able to set it up so that
   participants in the call arrive at the same key. This means that the



Rosenberg/Peterson/Schulzrinne/Camarillo                     [Page 17]

Internet Draft                    3pcc                 November 21, 2001




  User 1         Controller       User 3          Conference      User 2
   "A"              "X"             "C"             Server          "B"

    | INV no SDP     |               |               |               |
    |<---------------|               |               |               |
    | 200 SDP A1     |               |               |               |
    |--------------->| INV SDP A1    |               |               |
    |                |------------------------------>|               |
    |                | 200 SDP CS1   |               |               |
    |                |<------------------------------|               |
    |                | ACK           |               |               |
    | ACK SDP CS1    |------------------------------>|               |
    |<---------------| INV no SDP    |               |               |
    |                |---------------------------------------------->|
    |                | 200 SDP B1    |               |               |
    |                |<----------------------------------------------|
    |                | INV SDP B1    |               |               |
    |                |------------------------------>|               |
    |                | 200 SDP CS2   |               |               |
    |                |<------------------------------|               |
    |                | ACK SDP CS2   |               |               |
    |                |---------------------------------------------->|
    |                | ACK           |               |               |
    |                |------------------------------>|               |
    |                | INV no SDP    |               |               |
    |                |-------------->|               |               |
    |                | 408 Timeout   |               |               |
    |                |<--------------|               |               |
    |                | ACK           |               |               |
    |                |-------------->|               |               |
    |                |               |               |               |
    |                |               |               |               |
    |                |               |               |               |
    |                | INV no SDP    |               |               |
    |                |-------------->|               |               |
    |                | 200 SDP C1    |               |               |
    |                |<--------------|               |               |
    |                | INV SDP C1    |               |               |
    |                |------------------------------>|               |
    |                | 200 SDP CS3   |               |               |
    |                |<--------------+---------------|               |
    |                | ACK SDP CS3   |               |               |
    |                |-------------->|               |               |
    |                | ACK           |               |               |
    |                |-------------------------------|               |



   Figure 10: Timed Conference Initiation Call Flow

Rosenberg/Peterson/Schulzrinne/Camarillo                     [Page 18]

Internet Draft                    3pcc                 November 21, 2001


   controller may need to act as an RTP translator, decrypting with one
   key and re-encrypting with another.

   Third party call control has unfortunate interactions with NATs and
   firewalls. The problems arise when the controller is on one side of a
   firewall/NAT that is being controlled by a proxy [6] [7] that
   receives the controller's requests, and the controlled users are on
   the other side. Pinholes in the firewall may be opened when, in fact,
   the media does not pass through the firewall. One way to avoid this
   is for the firewall controlling proxy to recognize that the address
   of the media is not within its private network, and so not perform
   NAT or firewall control in those cases.

10 Conclusions

   We have presented a basic third party call control mechanism that
   uses SIP. This mechanism does not require any extensions to SIP and
   is completely backwards compatible.

11 Open Issues

        o Update to handle early media; this depends on how we handle
          early media.

        o How to handle the case when the 2nd leg rings (sends a 180) or
          is busy (therefore sending a 486), and you wish to convey that
          to the first leg. Since the controller initiated the request
          to the user, it can't propagate these responses. One way is to
          use a new reason code/phrase in a reINVITE. Another is to
          "turn the leg around", so that the controller is the UAS. How
          to do that?  Refer/replaces?

        o Update interactions with preconditions draft.

12 Changes since -02

        o Added open issues section.

13 Changes since -01

        o Included all the flows which have been discussed, weighing
          pros and cons.

        o Made a recommendation for which flows to use in which
          scenarios.

        o Updated the flows to be consistent with [2].




Rosenberg/Peterson/Schulzrinne/Camarillo                     [Page 19]

Internet Draft                    3pcc                 November 21, 2001


        o Added open issue with preconditions.

        o Added B2BUA discussion.

14 Authors Addresses



   Jonathan Rosenberg
   dynamicsoft
   72 Eagle Rock Avenue
   First Floor
   East Hanover, NJ 07936
   email: jdrosen@dynamicsoft.com

   Jon Peterson
   NeuStar, Inc
   1800 Sutter Street, Suite 570
   Concord, CA 94520
   USA
   email: jon.peterson@neustar.com

   Henning Schulzrinne
   Columbia University
   M/S 0401
   1214 Amsterdam Ave.
   New York, NY 10027-7003
   email: schulzrinne@cs.columbia.edu

   Gonzalo Camarillo
   Ericsson
   Advanced Signalling Research Lab.
   FIN-02420 Jorvas
   Finland
   Phone: +358 9 299 3371
   Fax: +358 9 299 3052
   Email: Gonzalo.Camarillo@ericsson.com




   Full Copyright Statement

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

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published



Rosenberg/Peterson/Schulzrinne/Camarillo                     [Page 20]

Internet Draft                    3pcc                 November 21, 2001


   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


15 Bibliography

   [1] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:
   session initiation protocol," Request for Comments 2543, Internet
   Engineering Task Force, Mar. 1999.

   [2] J. Rosenberg, P. Mataga, and H. Schulzrinne, "An application
   server component architecture for SIP," Internet Draft, Internet
   Engineering Task Force, Mar. 2001.  Work in progress.

   [3] W. Marshall et al.  , "Integration of resource management and
   SIP," Internet Draft, Internet Engineering Task Force, Aug. 2001.
   Work in progress.

   [4] J. Rosenberg and H. Schulzrinne, "Reliability of provisional
   responses in SIP," Internet Draft, Internet Engineering Task Force,
   Sept. 2001.  Work in progress.

   [5] S. Petrack and L. Conroy, "The PINT service protocol: Extensions
   to SIP and SDP for IP access to telephone call services," Request for
   Comments 2848, Internet Engineering Task Force, June 2000.

   [6] P. Srisuresh, J. Kuthan, J. Rosenberg, A. Molitor, and A. Rayhan,
   "Middlebox communication architecture and framework," Internet Draft,
   Internet Engineering Task Force, Oct. 2001.  Work in progress.




Rosenberg/Peterson/Schulzrinne/Camarillo                     [Page 21]

Internet Draft                    3pcc                 November 21, 2001


   [7] J. Rosenberg, D. Drew, and H. Schulzrinne, "Getting SIP through
   firewalls and NATs," Internet Draft, Internet Engineering Task Force,
   Feb. 2000.  Work in progress.
















































Rosenberg/Peterson/Schulzrinne/Camarillo                     [Page 22]


Html markup produced by rfcmarkup 1.111, available from https://tools.ietf.org/tools/rfcmarkup/