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

From: William Marshall <[email-masked]>
Date: Wed, 25 Oct 2000 18:26:33 -0400 (EDT)

Gonzalo wrote:
> The other issue is the one I am after. Both, UAC and UAS understand the
> a=QoS: line. So, considering that both understand it, the UAC wants the
> UAS to wait until the COMET is sent. And, as I said before, I can think
> of many cases where this is needed.

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.

If we add a new confirmation-tag value that can be sent by the UAC, "wait",
the revised enumeration of cases is:

	UAC sends	UAS sends	result
	confirm		confirm		2 COMETs, UAS->UAC, then UAC->UAS
	wait		confirm		1 COMET, UAC->UAS
	<nothing>	<nothing>	0 COMETs
	<nothing>	confirm		1 COMET, UAC->UAS

The semantics of this at the UAS are kept very simple:  if either a "confirm"
or a "wait" appears as a confirmation-tag in the SDP in the INVITE, then
a "confirm" MUST be sent in the SDP in the 183 response.  All other
procedures unchanged.

I believe this covers the third-party call control case.  Agree?

Bill Marshall
[email-masked]

p.s.
There is only one case not covered, that of the UAC sending <nothing> but
the UAS wanting a double-COMET exchange.  However, the single COMET (which
UAS can force to happen) gives the UAS all the resource results from the UAC,
and the UAS can then decide whether to proceed with a 180-Ringing or to
return a 580-failure.  No loss of functionality here, and no reason to
extend the table to allow the UAS to force a double-COMET.

-----original message-----
Date: Wed, 25 Oct 2000 22:40:58 +0300
From: Gonzalo Camarillo <[email-masked]>
To: William Marshall <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: FW: [SIP] Feedback on manyfolks

Hi,

William Marshall wrote:
> 
> This sounds like a request for a Requires: header for support of the
> resource reservation procedures.  This was considered and rejected;
> perhaps it should be re-opened, but I don't think it solves anything.
> 
> The basic problem of a "Requires:" header is what to do if the
> response indicates lack of support.  In many cases, that means
> just re-issuing the same request with slight modifications.  Such
> appears to be the case with the manyfolks draft.
> 
> The current procedures shorten this iteration, by allowing the
> session to proceed and informing the UAC that resource preconditions
> will not be honored.  The UAC can then cancel the request if it wants,
> or figure that it is getting the best that it can to that destination.
> 
> The notion of a UAC *demanding* that the session not proceed was
> thrown out with the two-phase INVITE that DCS originally proposed.

As it is shown in the draft this feature is useful in some cases. Among
many others, the third party call control draft needs this in order to
work.

> 
> Presumably, if the UAS supports the resource reservation extension but
> choses not to indicate this in the response messages, it must have a
> good reason for the behavior and should not be overridden by the UAC.

You are saying that the UAS has a good reason for not adding a confirm
tag to the 183 response??

I think you are mixing here two different issues.
One is when the UAS do not understand the a=QoS: line. In this situation
we cannot really do anything (we can  just CANCEL the INVITE).

The other issue is the one I am after. Both, UAC and UAS understand the
a=QoS: line. So, considering that both understand it, the UAC wants the
UAS to wait until the COMET is sent. And, as I said before, I can think
of many cases where this is needed.

Best regards,

Gonzalo

> 
> Bill Marshall
> [email-masked]
> 
> -----original message-----
> From: Gonzalo Camarillo <[email-masked]>
> To: William Marshall <[email-masked]>
> Cc: [email-masked], [email-masked]
> Subject: Re: FW: [SIP] Feedback on manyfolks
> Date: Tue, 24 Oct 2000 19:52:56 +0300
> 
> Hi Bill,
> 
> 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.
> 
> An 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.
> 
> Best regards,
> 
> Gonzalo
> 
> William Marshall wrote:
> >
> > This discussion took me a little while to figure out, because there
> > was clearly something missing in the manyfolks draft that I wasn't
> > seeing.
> >
> > The current manyfolks draft shows two examples, one where a confirmation
> > is requested by the UAS from the UAC, and one where two confirmations
> > are requested, first by the UAC from the UAS, then by the UAS from the UAC.
> >
> > However, (and the part I missed several times re-re-re-reading the draft),
> > the wording of the spec also allows the UAC to request a confirmation from
> > the UAS without the UAS requesting a confirmation from the UAC.  This
> > seems pointless.
> >
> >   |----(1)INVITE------->|
> >   |<---(2)183-----------|
> >   |----(3)PRACK-------->|
> >   |<---(4)200-----------|
> >   |<---(5)COMET---------|
> >   |----(6)200---------->|
> >   |<---(7)180-----------|
> >
> > If message (1)INVITE includes a request for a confirmation, i.e. (5)COMET,
> > but message (2)183 does not also request a confirmation, then there is
> > nothing the UAC can do upon receipt of the (5)COMET.  The UAS is already
> > doing the alerting and the (7)180 is probably already on its way.  The fact
> > that (7)180 is sent indicates the resource preconditions were met by UAS,
> > because otherwise it would have responded with a 580-precondition-failure
> > response.  So why even bother with (5)COMET?
> >
> > My original intention in writing the procedures for the two-way COMET
> > exchange was that it be triggered by the UAC requesting a confirmation.
> > The UAS, on receipt of a SDP containing a precondition line with a
> > confirmation request, MUST include a precondition line in its SDP with
> > a confirmation request.  This text doesn't appear, and would solve
> > the problem presented by third party call control.
> >
> > Did anyone see a case where the one-way confirmation shown in the
> > diagram above was actually useful and should be allowed?  Otherwise,
> > I think we should add the requirement on UAS behavior.
> >
> > If the response to the INVITE(with confirmation requested) is a 180, or
> > a 183 without a precondition line, it indicates the UAS doesn't support
> > the resource extension.  A 183 response with a precondition line that
> > doesn't include a confirmation would also, in this case, indicate lack
> > support of the UAS (or lack of sanity).
> >
> > Bill Marshall
> > [email-masked]
> >
> > -----Original Message-----
> > From: Gonzalo Camarillo [mailto:[email-masked]]
> > Sent: Thursday, October 12, 2000 1:38 AM
> > To: Jonathan Rosenberg
> > Cc: 'sip'
> > Subject: Re: [SIP] Feedback on manyfolks
> >
> > Hi,
> >
> > I agree. This is getting pretty complex.
> >
> > Anyway, for this specific matter we have three choices:
> >
> > 1) COMET is always mandatory in both directions. It does not matter if
> > the preconditions are mandatory or optional.
> >
> > 2) COMET is mandatory just when the preconditions are mandatory.
> >
> > 3) COMET is just sent when requested by any of the parties. This would
> > be the mechanism used so far (with the extension defined in
> > draft-camarillo-manyfolks-confirm-00.txt)
> >
> > Approach number 1 is the simplest. After doing whatever in order to
> > fulfil the preconditions a COMET is sent.
> >
> > Number 2 is also pretty simple. If the preconditions were mandatory, the
> > session is stopped until the COMET is sent. If the preconditions were
> > optional the session establishment goes on, so no COMET is sent.
> >
> > The gain of approach number 3 is that it saves some messages. However,
> > as you pointed out, they are not a lot. In the most common situation it
> > would save 2 messages (1 RTT). This is when A calls B in a two-party
> > session where there is just one COMET from A towards B. The COMET from B
> > to A is not normally needed since B just begins alerting the user once
> > the preconditions are met.
> >
> > So, we have a little more complexity for a little gain.
> >
> > My only concern is the amonut of signalling messages that we already
> > have for establishing a session using preconditions (PRACKs, COMETs). A
> > RTT for a workstation in an ethernet is not a big deal, but for a
> > terminal using a cellular access begins to be more important.
> >
> > Anyway, I do not have a religious position here, so any of the 3
> > solutions is alright for me. Let's pick one and go on resolving
> > different issues.
> >
> > Opinions?
> >
> > Regards,
> >
> > Gonzalo
> >
> > Jonathan Rosenberg wrote:
> > >
> > > Its just thats its more options, more complexities ontop of a thing which
> > is
> > > growing more and more complex. We need to remove options, not add them. I
> > > don't see what they need is for the negotiation. We need to justify the
> > > existence of it, not the elimination of it.
> > >
> > > -Jonathan R.
> > >
> > > ---
> > > Jonathan D. Rosenberg                       72 Eagle Rock Ave.
> > > Chief Scientist                             First Floor
> > > dynamicsoft                                 East Hanover, NJ 07936
> > > [email-masked]                     FAX:   (973) 952-5050
> > > http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
> > > http://www.dynamicsoft.com
> > >
> > > > -----Original Message-----
> > > > From: Gonzalo Camarillo [mailto:[email-masked]]
> > > > Sent: Tuesday, October 10, 2000 10:46 AM
> > > > To: Jonathan Rosenberg
> > > > Cc: 'sip'
> > > > Subject: Re: [SIP] Feedback on manyfolks
> > > >
> > > >
> > > > Hi,
> > > >
> > > > Certainly we are not talking about tons of messages. However, in this
> > > > case I would rather let the confim be negotiated. The negotiation is
> > > > rather simple.
> > > >
> > > > The UAC can request:
> > > > 1) No COMET
> > > > 2) one COMET UAC->UAS
> > > > 3) one COMET UAC-<UAS
> > > > 4) two COMETs
> > > >
> > > > The UAS should accept what the UAC requests, and possibly request more
> > > > (e.g. two COMETs when the UAC just requested one).
> > > >
> > > > I believe this is not a complicated mechanism. It is just a
> > > > deterministic two-way handshake.
> > > >
> > > > Best regards,
> > > >
> > > > Gonzalo
> > > >
> > > >
> > > >
> > > > Jonathan Rosenberg wrote:
> > > > >
> > > > > This seems reasonable to me, and needed, as Gonzalo points out.
> > > > >
> > > > > My only issue is whether all this stuff should be optional
> > > > at all. Wouldn't
> > > > > it be easier if both sides always sent COMET, period? All
> > > > this negotiation
> > > > > stuff is a pain. We're not talking tons of messages here.
> > > > Can't we keep it
> > > > > simple?
> > > > >
> > > > > -Jonathan R.
> > > > >
> > > > > ---
> > > > > Jonathan D. Rosenberg                       72 Eagle Rock Ave.
> > > > > Chief Scientist                             First Floor
> > > > > dynamicsoft                                 East Hanover, NJ 07936
> > > > > [email-masked]                     FAX:   (973) 952-5050
> > > > > http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
> > > > > http://www.dynamicsoft.com
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Gonzalo Camarillo [mailto:[email-masked]]
> > > > > > Sent: Monday, October 09, 2000 2:33 AM
> > > > > > To: sip
> > > > > > Subject: [SIP] Feedback on manyfolks
> > > > > >
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > Here you have a new I-D that contains feedback on the
> > > > manyfolks draft.
> > > > > >
> > > > > > http://search.ietf.org/internet-drafts/draft-camarillo-manyfol
> > > > > > ks-confirm-00.txt
> > > > > >
> > > > > > "
> > > > > > Abstract
> > > > > >
> > > > > >    This document describes certain functionality that is
> > > > > > missing in the
> > > > > >    current "Integration of Resource Management and SIP"
> > > > [1] (a.k.a.
> > > > > >    manyfolks draft). An extension to add this functionality is
> > > > > >    outlined.
> > > > > >
> > > > > >    This functionality is needed in general to provide richer
> > > > > > signalling
> > > > > >    capabilities and can be employed in several scenarios.
> > > > This draft
> > > > > >    describes its use in third party call control applications.
> > > > > >
> > > > > >    If this extension is accepted it is foreseen that this
> > > > draft would
> > > > > >    be merged with [1].
> > > > > > "
> > > > > >
> > > > > > 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
> > > > > >
> > > > > > _______________________________________________
> > > > > > SIP mailing list
> > > > > > [email-masked]
> > > > > > http://lists.bell-labs.com/mailman/listinfo/sip
> > > > > >
> > > >
> > > > --
> > > > 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
> > > >
> > > > _______________________________________________
> > > > SIP mailing list
> > > > [email-masked]
> > > > http://lists.bell-labs.com/mailman/listinfo/sip
> > > >
> >
> > --
> > 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
> >
> > _______________________________________________
> > SIP mailing list
> > [email-masked]
> > http://lists.bell-labs.com/mailman/listinfo/sip
> 
> _______________________________________________
> SIP mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/sip
> 
> _______________________________________________
> SIP mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/sip

-- 
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 31 18
FIN-02420 Jorvas          Email :  [email-masked]
Finland

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

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 26 Oct 2000 10:09:31 +0300

Hi,

> I've heard no argument to my proposal of dropping case (1).

I cannot think of any useful application of case 1 either.

> choice (2), thereby saving one round-trip time and one UAS->UAC message.

Yes, that's right.

> a "confirm" MUST be sent in the SDP in the 183 response.  All other

I agree that this mechanisms is not complicated either. However, I still
prefer the direction tag after the confirm (confirm sendrecv). The
mechanism is as simple as this one, and just by examining the response,
it is very clear which messages will be exchanged.

That is, if the 183 carries "confirm sendrecv" there will be 2 COMETS.
If the 183 response carries "confirm recv", there will be one COMET
UAC->UAS.

Actually if you want the mechanism to be even clearer you could
substitute the word "confirm" by the word "comet".

So, you will have in the 183 response: "comet sendrecv"... very
straightforward.

I would like to hear the advantages that you find in the "wait" tag.
I find it a bit cumbersome. When the UAC wants to send the COMET, the
UAC should ask the UAS to ask the UAC to send it... why?

I find it more natural if the UAC requests the COMET directly: "comet
send" in the INVITE.

As I said, I find both mechanisms pretty simple, but I see some
advantages with the use of the direction tag.

> extend the table to allow the UAS to force a double-COMET.

What you are saying here is that the UAC has to decide always:
1)If the UAC wants a COMET from UAC->UAS, it makes no sense for the
server to request the COMET from UAS->UAC.
2)If the UAC wants 2 COMETS, it makes no sense for the UAS to change
this choice.
3)If the UAC wants a COMET from UAS->UAC, it makes no sense for the UAS
to request the COMET from UAC->UAS, because the UAC is not interested in
sending it. That is, the UAC does not want the session establishment to
stop waiting for this COMET.

Therefore, what you are trying to do is eliminating the useless cases.
After this analysis, it is pretty clear that the UAC can always make the
decision of which COMETs should be exchanged.

Therefore, I suggest to include in the INVITE the direction tag: "comet
send" or "comet sendrecv". Then, the UAS is forced to honor this. The
UAS cannot change this.

         UAC sends               result
         comet sendrecv          2 COMETs, UAS->UAC, then UAC->UAS
         comet send              1 COMET, UAC->UAS
         <nothing>               0 COMETs

The only case from your table that is not cover is the following:
         UAC sends       UAS sends       result
         <nothing>       confirm         1 COMET, UAC->UAS

As I said before, this case is not unseful. If the strengh parameter was 
"mandatory", the UAC wants the session establishment to stop until the
QoS is granted. But if the UAC did not include "comet send" in the
INVITE, it jast can be before he is allset with his part. Therefore, the
UAS is not interested in the COMET from UAC->UAS.

I believe this is the simplest mechanism and the one we should go for.

Best regards,

Gonzalo