Subject: [Sip] sip based 3pcc

From: "Medhavi Bhatia" <[email-masked]>
Date: Sat, 29 Sep 2001 08:39:40 -0400

Hi all,

I had earlier proposed a mechanism for third party
call control. Here are some more analytical details on it:

http://www22.brinkster.com/mbhatia/draft-bhatia-3pcc-refer-00.txt

Some simple advantages of the technique against the one specified in
Rosenberg/Peterson/Schulzrinne/Camarillo draft:

- Controller has the option of acting as a proxy or a back
to back user agent for the duration of the call after the REFER.

- Controller does no have to manipulate any SDP, unless the
application desires it.

- Does not rely on the usage of INVITE without SDP (a large number
of proxies and UAs have trouble handling it).

- Does not require putting A or B on hold, which generally causes the 
UA to put the peer back on hold.

- Does not suffer from any potential timeout issues, or assume any
special behavior of the clients (some controllers use "flow 1" in the
sip-3pcc draft, which works best when B is some kind of automatic
device, like a media server).

- Cannot cause an "infinite loop" of INVITEs (Some controllers tend to
use the "flow 2" in the sip-3pcc draft, which suffers from this
problem). 

The approach does use the SIP REFER method and the Replaces header:

        A               Controller             B
        |                   |                  |
        |             create callid1           |
        |   REFER callid1   |                  |
        |<------------------|                  |
        |                   |                  |
        |   202 Accepted    |                  |
        |------------------>|                  |
        |                   |                  |
        |INVITE callid1 SDPA|                  |
        |------------------>|                  |
        |                   |                  |
        |                   |  INVITE SDP A    |
        |                   |----------------->|
        |                   |                  |
        |                   |  200 SDP B       |
        |                   |<-----------------|
        |                   |                  |
        |   200 SDP B       |                  |
        |<------------------|                  |
        |                   |                  |
        |    ACK            |                  |
        |------------------>|                  |
        |                   |                  |
        |                   |    ACK           |
        |                   |----------------->|
        |                   |                  |
        |                   |            RTP   |
        |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx|
        |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx|

In this scenario, the controller has no ongoing calls with A and B
in the beginning. It creates a local context for callid1. This context
MUST contain a SIP call id, and MAY contain from and to tags locally
generated at the controller. At this point the controller sends a REFER
with the Replaces callid1 header to A. If A is interested in the call, 
it sends a 202 Accepted back to the controller. At this point the 
controller starts a timer, "timer-callid1", on callid1 for TC seconds.
(TC is an application specific timer, which should at least take into
account the retransmissions from A. ~10*T2 seconds is probably a good
value).
When the INVITE arrives from A with the Replaces callid1 header, the
timer is cancelled, the INVITE is forwarded to B. At this point the 
controller may act as a Back to Back user agent or a proxy for the
call duration, depending on the kind of application running on the
controller. The 200 OK from B arrives and is forwared to A. This way
the controller does not need to assume anything about what SDP will
be used for the call.

1. Controller creates SIP call leg 1 (Call id=12345%40192.168.118.3;
              to-tag=12345;from-tag=5FFE-3994), and sends a REFER to A:
          
        REFER sip:A@agentland SIP/2.0
        Via: SIP/2.0/UDP controller.nextone.net
        To: <sip:A@agentland>
        From: <sip:[email-masked]>;tag=193402342
        Call-ID: [email-masked]
        CSeq: 93809823 REFER
        Refer-To: <sip:B@[email-masked]?Replaces:12345%40192.168.118.3;
                   to-tag=12345;from-tag=5FFE-3994>
        Referred-By: <sip:[email-masked]>
        Contact: sip:[email-masked]
        Content-Length: 0

     Note the presence of the To tag, even though the INVITE is
     being sent by A. The Controller may or may not put the To tag.

     2. B sends a 202 Accepted to the Controller.
     
     3. B sends an INVITE to the Controller

        INVITE <sip:B@[email-masked]?Replaces:12345%40192.168.118.3;
                   to-tag=12345;from-tag=5FFE-3994> SIP/2.0
        Via:     SIP/2.0/UDP sip:A@agentland
        From:    A <sip:A@agentland>;tag=3pcc
        To:      B <B@[email-masked]>
        Call-ID: 31415@agentland
        CSeq:    1 INVITE
        Contact: A@agentland

MID-call:

The same mechanism can be used in the middle of a call. This is the
scenario when the controller already has a call up with A. The only
change in this case is that the REFER is sent on the existing call leg.
The call flows in this case are similar to the call transfer call
flows given the sip-call-transfer draft. In this case A sends a NOTIFY
back to the controller, containing the status of the REFER, and the
controller disconnects the old call with A by sending a BYE to it.

        A               Controller             B
        |                   |                  |
        |                   |                  |
        |   REFER callid1   |                  |
        |<------------------|                  |
        |                   |                  |
        |   202 Accepted    |                  |
        |------------------>|                  |
        |                   |                  |
        |INVITE callid1 SDPA|                  |
        |------------------>|                  |
        |                   |                  |
        |                   |  INVITE SDP A    |
        |                   |----------------->|
        |                   |                  |
        |                   |  200 SDP B       |
        |                   |<-----------------|
        |                   |                  |
        |   200 SDP B       |                  |
        |<------------------|                  |
        |                   |                  |
        |    ACK            |                  |
        |------------------>|                  |
        |                   |                  |
        |                   |    ACK           |
        |                   |----------------->|
        |   NOTIFY (200 OK) |                  |
        |------------------>|                  |
        |                   |                  |
        |   200 OK          |                  |
        |<------------------|                  |
        |                   |                  |
        |   BYE             |                  |
        |<------------------|                  |
        |                   |                  |
        |                   |       RTP        |
        |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx|
        |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx|