Subject: [SIP] Feedback on manyfolks

From: [email-masked]
Date: Mon, 23 Oct 2000 17:03:47 -0500

How does this document address a case where I have a network with phones that
know nothing about the QoS issues
and only the intermediate proxies are aware ( or are involved in QoS setup ) of
it?

Thanks,

Anoop

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

---

From: William Marshall <[email-masked]>
Date: Tue, 24 Oct 2000 10:49:27 -0400 (EDT)

> How does this document address a case where I have a network 
> with phones that know nothing about the QoS issues
> and only the intermediate proxies are aware ( or are 
> involved in QoS setup) of it?

If the phone truly knows nothing about QoS, then it responds to
the INVITE containing preconditions with the normal 180-Ringing
or 200-OK, and the UAC knows that the preconditions didn't happen
(spec requires a UAS supporting the extension to respond with a
183 response).

It is also possible that the phone knows nothing about
QoS, but an intermediate proxy does know how to do the QoS.  The 
proxy can hold the INVITE and send the 183 response, with a Contact
header pointing to the proxy.  Thus the COMET will go to the proxy,
and then the proxy sends the INVITE on to the endpoint.  The
200-OK contains a new Contact header with the endpoint address for
future signaling.  Manyfolks draft deals with the separate Contact
header values, and even a separate Record-Route/Route value for the
COMET, in the same way that PRACK allows a proxy to request and
receive the acknowledgement.

Bill Marshall
[email-masked]

-----original message-----
From: [email-masked]
To: William Marshall <[email-masked]>
Cc: [email-masked]
Subject: [SIP] Feedback on manyfolks
Date: Mon, 23 Oct 2000 17:03:47 -0500

How does this document address a case where I have a network 
with phones that know nothing about the QoS issues
and only the intermediate proxies are aware ( or are 
involved in QoS setup) of it?

Thanks,

Anoop

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 26 Oct 2000 05:29:19 -0400

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:[email-masked]]
> Sent: Thursday, October 26, 2000 3:10 AM
> To: William Marshall
> Cc: [email-masked]; [email-masked]
> Subject: Re: FW: [SIP] Feedback on manyfolks
> 
> 
> Hi,
> 
> William Marshall wrote:
> > 
> > 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).
> 
> I cannot think of any useful application of case 1 either.
> 
> > 
> > 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.

I'd still argue that this whole thread is an artifact of the overly-flexible
mechanism defined in the preconditions draft. All this negotiation is simply
confusing, and can lead to cases like this where someone wants something,
but the other guy doesn't do it, etc. The KISS principle would argue that
once the UAC sends a request with preconditions, we have COMET in both
directions (assuming, of course, the UAS understands it). Period. This is
equivalent to the "comet sendrecv" case below always being used by the UAC.

Gonzalo wrote:
> 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.
> 

-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

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 26 Oct 2000 12:55:47 +0300

Hi Jonathan,

> equivalent to the "comet sendrecv" case below always being used by the UAC.

I agree with you. We do not need an overflexible mechanism. But what I
am proposing here is actually very close to what you are saying.

Your suggestion is:
     UAC sends               result

My suggestion is:
     UAC sends               result

Neither of both nechanisms allow for negotiation or complicated stuff.
Actually both mechanisms very similar.

However, the second one would save one RTT is certain situations.
Actually, it would save one RTT in the most common situation (two-party
session where the UAS waits for the COMET from the UAC and then, when
the UAS is allset with the QoS reservation alerts the user).

Therefore, you achieve this gain by adding negligible complexity.

I still believe that the second mechanism is the one we should go for.
It does not break the KISS principle at all and it would decrease the
session establishment time for terminals using low-rate accesses. 

Best regards,

Gonzalo

---

From: William Marshall <[email-masked]>
Date: Mon, 30 Oct 2000 16:00:16 -0500 (EST)

[email-masked] wrote:
> 
> Hi Bill,
> 
> William Marshall wrote:
> 
> > For the simple call from A to T, A inserts the SDP line a=qos:mandatory
> > sendrecv" which T is willing to accept.  But T can't do the send&recv QoS
> > itself - it needs help from A for the A->T direction.
> > (Note that T doesn't know whether A will be using RSVP, so it can't
> > depend on using a RESV-CONF to do this trick).
> 
> So, T does not know whether A uses RSVP or not...
> Is there a negotiation of the QoS reservation scheme used?
> That is, my terminal sends an INVITE with SDP preconditions (sendrecv),
> and I get the 183 with the same preconditions (sendrecv). What should my
> terminal do?
> 
> Should it use RSVP to reserve resources in the recv direction and expect
> the other end to do the same in the other direction?
> Should it reserve resources for send&recv over its radio access and
> expect the other end to perform also resorce reservation on its access
> (maybe an ethernet)?
> You mention also bi-directional resource reservation schemes. Should my
> terminal use its bi-directional resource reservation mechanism and
> perform the sendrecv reservation?
> 
> Who decides which resource reservation mechanism is to be used?
> Do we need negotiation of the reservation mechanism?
> 
> 
> 
<snip>

With the first roundtrip, the UAC and UAS agree exactly what the
preconditions will be for the session.  The UAC proposes "sendrecv"
in the INVITE, and the UAS responds "sendrecv" in the 183.  So both
sides have agreed to get bi-directional QoS before allowing the
session to proceed.

The UAC then performs whatever it can in order to meet this
precondition.  For a typical RSVP implementation, it can only
guarantee the "send" direction, and would respond in the COMET
a=qos:success send

The UAS performs whatever it can to meet the precondition.  For a 
typical RSVP implementation, it will guarantee its "send" direction
(which is not enough for the session to proceed).  When UAS receives
the COMET, "sendrecv" has been achieved, and the session can proceed.

I don't think it is worthwhile trying to negotiate the type of
resource reservation protocol used, since only the results
of the reservation are important to the SIP session.  The
mechanism is already general enough to handle the variations.

With QoS architectures where bi-directional reservations
can be made:  UAC could do the bi-directional reservation and
respond with "a=qos:success sendrecv" in the COMET;  UAS need
do nothing.  Alternately, UAS could do the bi-directional reservation
and let the call proceed when it completes; in this case the UAS
would likely not request a COMET since it is irrelevant.

In yet other QoS architectures (such as cable and wireless), the UAC
does access reservation (typically bi-directional) and one-way end-end
reservation; it sends a COMET with "a=qos:success send".  The UAS
does its one-way reservation (which may overlap with the downstream
on the cable or radio).  I see no need to complicate the mechanism
to be able to say "slightly more than one-way in send direction",
since interoperating with standard endpoints works with just "send" -
anything more than just "send" but less than "sendrecv" is still "send".

Bill Marshall
[email-masked]