Subject: Re: [Sipping] Re:I-DACTION:draft-loreto-sipping-dialog-correlation-00.txt

From: Gonzalo Camarillo <[email-masked]>
Date: Sat, 01 Apr 2006 19:00:24 +0300

Hi,

> I think it is fair to say there are people that want to do it
> both ways. 

Exactly. Both approaches have pros and cons. Depending on what is more 
important for you, you would choose to use one or another.

It seems that the two more important aspects of this discussion are:

o complexity
o support of an extension at the remote end

The proposal in the draft requires the remote end to support a new 
extension. On the other hand, it simplifies a great deal the call flow 
and the user agent's implementation.

Regarding complexity, let's look at a concrete example: preconditions.

Using the same-session header, A would issue a REFER transaction to C (6 
messages), and C would send an INVITE to B following the call flow in 
Figure 1 of RFC 3312 (11 messages).
http://www.ietf.org/rfc/rfc3312.txt

Using 3pcc, A behaves as the controller in Figure 11 of RFC 3725 (26 
messages).
http://www.ietf.org/rfc/rfc3725.txt

Alternatively, we can use 3pcc in a different way. A sends a REFER to C 
(6 messages) and C initiates the INVITE towards A. A would be B in 
Figure 2 of RFC 4117, but with the addition of preconditions. The flow 
without precondition already has 11 messages.
http://www.ietf.org/rfc/rfc4117.txt

After that, any session change between C and B will involve A as well 
(note that if A is on a low-bandwidth access, any operation will take a 
while).

Additionally, not many terminals are going to implement what is needed 
to be a 3pcc controller. However, any terminal will implement REFER.

Cheers,

Gonzalo

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