Subject: [SIP] Feedback on manyfolks

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 09 Oct 2000 09:32:31 +0300

Hi,

Here you have a new I-D that contains feedback on the manyfolks draft.

http://search.ietf.org/internet-drafts/draft-camarillo-manyfolks-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

---

From: "Mark Watson" <[email-masked]>
Date: Mon, 9 Oct 2000 11:01:43 +0100

Gonzalo,

A small comment: in section 1 your write:

"As soon as the calleeÆs UA
   has finished the resource reservation in the callee-caller direction
   (using RSVP for instance) and a COMET arrives from the caller
   (confirming that resources are also available in the caller-callee
   direction) the callee will be alerted."

Reading the manyfolks draft 'cold', without having been involved in the
original discussions, I did not get the impression that there was any
asumption that the callee was responsible for 'callee->caller' reservation
and the caller for the reverse direction. This assumption seems to be
specific to certain reservation technologies.

Rather, I read the draft as implying that the COMET from caller to callee
was sent when the caller had done 'whatever is necessary' to provide the
QoS/Security preconditions which were negotiated in the SDP.

Does there need to be an assumption about what 'whenever is necessary' is ?
Surely this, and whether or not the caller/callee needs the other to confirm
it, is dependent on the particular QoS technology being used ?

Regards,

Mark Watson
Nortel Networks

-----Original Message-----
From: Gonzalo Camarillo [mailto:[email-masked]]
Sent: 09 October 2000 07:33
To: sip
Subject: [SIP] Feedback on manyfolks

Hi,

http://search.ietf.org/internet-drafts/draft-camarillo-manyfolks-confirm-00.
txt

"
Abstract

Best regards,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 09 Oct 2000 13:21:40 +0300

Hi,

The example tries to show an scenario where RSVP is used. Actually what
you say is exactly the goal of this draft. The UAS has to wait until it
receives the COMET, rather than relying on other mechanisms (such as the
ResvConf in RSVP).

Probably the example can be reworded, but I believe the meaning is clear
enough.

The draft basically outlines a mechanism that allows the UAC to ask the
UAS to wait until a COMET from UAC to UAS arrives. The rest are just
examples (such as the 3pcc) that help understand the need for the
mechanism.

Thanks for the feedback,

Gonzalo

> Mark Watson wrote:
> Reading the manyfolks draft 'cold', without having been involved in
> the original discussions, I did not get the impression that there was
> any asumption that the callee was responsible for 'callee->caller'
> reservation and the caller for the reverse direction. This assumption
> seems to be specific to certain reservation technologies.
> 
> Rather, I read the draft as implying that the COMET from caller to
> callee was sent when the caller had done 'whatever is necessary' to
> provide the QoS/Security preconditions which were negotiated in the
> SDP.
> 
> Does there need to be an assumption about what 'whenever is necessary'
> is ? Surely this, and whether or not the caller/callee needs the other
> to confirm it, is dependent on the particular QoS technology being
> used ?
> 
> Regards,
> 
> Mark Watson
> Nortel Networks
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 10 Oct 2000 02:32:29 -0400

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

> Sent: Monday, October 09, 2000 2:33 AM
> To: sip

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 10 Oct 2000 17:46:09 +0300

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

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 10 Oct 2000 16:43:13 -0500

These are more comments on the manyfolk draft itself.

When a user is alerted in band, should a second 183 response be sent
when the alerting actually start after the COMET? The 4th paragraph in 7.1 
of manyfolks says that it does send a second 183 in that case.

Also, the 3rd paragraph in 7.1 says that "the UAC does not generate local
ringback until the mandatory preconditions are met". Shouldn't it be
the 180 response that would trigger local alerting at the UAC instead of
completion of resource reservation (that's what the 4th paragraph says)? 
Section 7.2 has similar wording.  

----
François AUDET, Nortel Networks
mailto:[email-masked], tel:+1 408 495 3756

> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Monday, October 09, 2000 11:32 PM
> To: 'Gonzalo Camarillo'; 'sip'
> Subject: RE: [SIP] Feedback on manyfolks
> 
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 11 Oct 2000 22:44:16 -0400

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.

---

> Sent: Tuesday, October 10, 2000 10:46 AM
> To: Jonathan Rosenberg
> Cc: 'sip'
> Subject: Re: [SIP] Feedback on manyfolks
> 
> 
> Hi,
>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 12 Oct 2000 08:37:32 +0300

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

---

From: "Mark Watson" <[email-masked]>
Date: Tue, 24 Oct 2000 11:46:36 +0100

Good point.

What is the point of the UAS to UAC COMET at all ? If you need two-way
confirmation of resource reservation, won't the 180 provide the backwards
confirmation in all cases ?

The point about resource reservation is that the progress of the session -
which has a definate direction UAC -> UAS - needs to be delayed pending
completion of the reservation.

Once it has received the INVITE, it is the UAS which is in control of the
session progress. The UAS knows for itself when it has completed its local
preconditions, so surely the only precondition-met signalling which is
needed it forwards, from UAC to UAS ?

Regards,

Mark Watson
Nortel Networks

> From: William Marshall [mailto:[email-masked]]
> Sent: 23 October 2000 22:47
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: FW: [SIP] Feedback on manyfolks
> 
> 
> 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]
> 
> 
> Sent: Thursday, October 12, 2000 1:38 AM
> To: Jonathan Rosenberg
> Cc: 'sip'
> > Its just thats its more options, more complexities ontop of 
> a thing which
> is
> > > > > From: Gonzalo Camarillo 
> [mailto:[email-masked]]