Subject: FW: [SIP] Feedback on manyfolks

From: William Marshall <[email-masked]>
Date: Mon, 23 Oct 2000 17:47:23 -0400 (EDT)

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

---

From: Gonzalo Camarillo <[email-masked]>
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