Subject: Re: [Sip] sip based 3pcc

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 05 Oct 2001 00:23:35 +0300

Hello,

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

One simple and big advantage of the
Rosenberg/Peterson/Schulzrinne/Camarillo draft is that you do not need
to use any SIP extension. That is, a controller can establish a session
between the simplest SIP UAs that you can get (no REFER, no Replaces,
etc...).

Of course, if what you want to do is to establish a session between two
particular UAs that support a number of fancy features, then you can do
everything that those fancy features allow you to do... but I would not
go so far to call this an advantage over the 3pcc approach.

Regards,

Gonzalo

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

-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              [email-masked]

_______________________________________________
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Medhavi Bhatia" <[email-masked]>
Date: Fri, 5 Oct 2001 09:25:27 -0400 (Eastern Daylight Time)

The approach using REFER is not meant to replace the 3pcc-draft method.
Quite analogous to the 3pcc approach which describes how a smart controller
can instrument a 3pcc call without any extensions, the REFER based approach
is really describing a mechanism based on REFER. All the smarts to do it
have
to reside on the controller. The endpoint must support REFER - which most
proxies
and UAs will do, as REFER is needed for call transfer.

However consider the following assumptions, under which the 3pcc-draft based
approach
breaks down:

1) UA does not support INVITE w/o SDP. - There are quite a lot of those. To
add to the
whole set of numbers, we have the SIP/H.323 interworking gateways, which
probably
never will support such scenarios, unless they make special assumtions about
media.

2) UA will respond with a new media set of media ports whenever it is
offered something
different from previous INV-OK-ACK.

3) UA will respond with a HOLD to a HOLD initiated by the peer.

Now "flow 1" in the 3ppc draft violates (1), and can be used only in mid
calls or when the UA
is automatic in responding with a 200 OK.

"flow 2" fails under (2).

"flow 3" violates (1), and gets complicated when we have (3).

-------Original Message-------

From: Gonzalo Camarillo
Date: Thursday, October 04, 2001 05:05:24 PM
To: Medhavi Bhatia
Cc: [email-masked]
Subject: Re: [Sip] sip based 3pcc

Hello,

Regards,

Gonzalo