Subject: Re: FW: [SIP] Feedback on manyfolks

From: William Marshall <[email-masked]>
Date: Thu, 26 Oct 2000 10:01:12 -0400 (EDT)

I'm lost in this discussion.  

Based on Jonathan's comments, with which I completely agree,
I think we have third-party-call-control covered, with only the
one simple clarification to the manyfolks draft (that a confirm
in the SDP from the UAC requires a double COMET).

Is there some other application of this procedure that should be
covered and isn't?

So let me try to recap, and see where we stand.

I wrote (Wednesday):
> 
> In enumerating the cases, I see the confirmation-tag choices as follows:
> 
>         UAC sends       UAS sends       result
> 1.      confirm         <nothing>       1 COMET, UAS->UAC, useless
> 2.      confirm         confirm         2 COMETs, UAS->UAC, then UAC->UAS
> 3.      <nothing>       <nothing>       0 COMETs
> 4.      <nothing>       confirm         1 COMET, UAC->UAS
> 
> I've heard no argument to my proposal of dropping case (1).
> 
> Third party call control wants to force choice (4), without going as far as
> choice (2), thereby saving one round-trip time and one UAS->UAC message.
> 

Jonathan wrote (Thursday) (responding to Gonzalo who responded to me):
> > > 
> > > Third party call control wants to force choice (4), without 
> > > going as far as
> > > choice (2), thereby saving one round-trip time and one 
> > > UAS->UAC message.
> > > 
> > 
> > Yes, that's right.
> 
> I don't follow this. For 3pcc, the controller needs to know when both UAs
> have completed resource reservation. This is needed so it, in turn, knows
> when to send a COMET back to them. This seems to imply that 3pcc really
> requires case 2. The controller wants COMET from the UA's, and the UA's wait
> to get COMET from the UAC. The problem described in
> draft-camarillo-manyfolks-confirm is that there might case (1), that is:
> 
>    After (12), all the preconditions are met. However, the controller
>    does not send a COMET to B (16) until A has answered the INVITE
>    (15). Therefore, if A relied on mechanisms different than COMET
>    (such as ResvConf in RSVP) to check if the resource reservation was
>    already done third party call control mechanisms would fail, since A
>    would go on with the session establishment after (12), instead of
>    waiting for (15). Preconditions met confirmations must rely solely
>    on application layer mechanisms - SIP.
> 
> But, as Bill has pointed out, the easier way to solve this is to forbid this
> case when the UAS understands preconditions. In other words, if A requests
> confirmation from B, and B understands the extension, B MUST include a
> confirmation request in its 183 back to A. This seems to address the problem
> you are describing.
> 

But, when this was first proposed on Monday, Gonzalo wrote (Tuesday):
> 
> There is one scenario you are missing.
> 
> The UAC wants to send a COMET (UAC->UAS), but it is not interested in
> receiving a COMET from the UAS.
> 
> A scenario containing just one COMET from the UAC to the UAS is already
> in the manyfolks draft, but there, the decision is made by the UAS. The
> UAS is the one deciding that it whishes to receive the COMET from the
> UAC. That's why it adds a confirm in the response.
> 
> In the scenario I am after, the UAC is the one that makes the decision.
> He wants the UAS to stop the session establishment until there is a
> COMET from the UAC to the UAS. But he is not interested in the COMET in
> the other direction.
> 
> Your suggestion does not solve this problem.
> 

So before considering this discussion closed, let me ask whether there
is an application where the single-COMET decision can't be made by the UAS?

It seems to me that the UAC requesting "sendrecv" QoS is stating exactly that
as a precondition, that the QoS be established in both directions.  RSVP
only does one direction, so a UAS that uses RSVP will necessarily require
a COMET in order to achieve bi-directional QoS before proceeding with
the session.  So the choices at the UAS are (1) a=qos:sendrecv confirm,
or (2) respond with a=qos:send, or (3) use something other than RSVP to 
get bi-directional QoS.  If the UAS does choice (3), there is no reason 
for a COMET, and the UAC should not require it.

Bill Marshall
[email-masked]

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 26 Oct 2000 17:27:27 +0300

Hi,

> is an application where the single-COMET decision can't be made by the UAS?

In some situations the UAC wants the UAS to "wait" until there is a
COMET (UAC->UAS). This decision MUST be done by the UAC because the UAS
does not have a clue about this need.

You can find an example in 
http://search.ietf.org/internet-drafts/draft-camarillo-3pcc-qos-00.txt

We have A, a transcoder and B. The media path will traverse the
transcoder.

The presence of a transcoder is transparent to B. The SDP of the INVITE
from A to B contains the IP address of the transcoder. Thus, even when
the QoS is granted in the transcoder-B leg, there is a need for QoS in
the other leg (transcoder-A). B is completely unaware of this, so it is
A (the UAC) the one that MUST require a COMET from UAC to UAS.
This way, it can perform resource reservation between A and the
transcoder and then send the COMET to B (that will resume session
establishment).

Note that in this example I use 2 COMETs between A and B, but actually
COMET from B to A is not needed for anything.

However, in the other leg (transcoder-A), 2 COMETs are needed.

This illustrates that the UAC always has the information about how many
COMETs are needed.

OK, now, let me re-write my suggestion (it appears already in my
previous mail):
My suggestion is:
     UAC sends               result
     comet sendrecv          2 COMETs, UAS->UAC, then UAC->UAS
     comet send              1 COMET, UAC->UAS
     <nothing>               0 COMETs

This mechanism includes all the comments received in this thread so far:
1) It is simple, because there is no negotiation of how many COMETs have
to be sent. The UAC makes the decision and the UAS obeys.

Question: Do you have any situation where the UAS would like to change
the decision made by the UAC regarding the number of COMETs sent? I
cannot think of any useful scenario.

2) It saves one RTT in the most common situation (just one COMET
UAC->UAS).

3) The syntax is really "human readable". Direction tags are very easy
to interpret. Even easier when they are already used in the a=QoS line.

Do you have any objection against this approach?

Practically this is the same mechanism described by Jonathan (where the
UAC also makes the decision). I have just added the posibility of just
one COMET (for saving bandwidth basically).

Thanks,

Best regards,

Gonzalo
-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  [email-masked]
Finland                   http://www.hut.fi/~gonzalo