Subject: RE: Thoughts on SIP RSVP QOS Interworking

From: "Donovan, Steven R. (MCI)" <[email-masked]>
Date: Thu, 25 Feb 1999 14:44:43 -0000

> -----Original Message-----
> From:	Henning Schulzrinne [SMTP:[email-masked]]
> Sent:	Tuesday, February 23, 1999 8:27 PM
> To:	Donovan, Steven R. (MCI)
> Cc:	'confctrl'
> Subject:	Re: Thoughts on SIP RSVP QOS Interworking
> 
> > "Donovan, Steven R. (MCI)" wrote:
> > 
> > All,
> > 
> 
> > 
> > The problem is that as SIP is currently constructed, the two RSVP
> > flows cannot be setup until after the session has been accepted by the
> > called user agent.  This is due to the fact that the SDP portion that
> > contains the necessary IP addresses does not get exchanged until the
> > 200 OK is send by the called user agent.
> > 
> > Thus we cannot offer a service that guarantees of a level of QOS if
> > that QOS needs to be setup prior to alerting of the called user.
> > 
> > There is overlap between this problem and the 180 to ACM mapping
> > problem that has recently been discussed on this mailing list in that
> > in order to solve both problems the called user agents SDP information
> > needs sent prior to the 200 OK.
> > 
> 
> One potential problem is that this only works if the media selection is
> either implied (as in Internet telephony, assuming that codecs are
> acceptable) or automatic, rather than user-driven. There's no point
> reserving resources for video if I then don't want to send and/or
> receive video. If you do base the reservation on the 18x indication, you
> may have to downgrade it after the call has been accepted. As a
> sidenote, modifying reservations isn't necessarily supported by existing
> RSVP implementations like altq.
> 
> Clearly, implementations would have to be careful depending on who pays
> for the reservation. If holding a reservation costs money, I can ring
> your phone and make you pay...
> 
	SRD> This is true.  The model implied in my note is that the calling
party is responsible for paying for the reservation.  

> It is interesting to note that, depending on the circumstances, the
> callee session description could appear in one or more of
> - in 1xx for announcements and per-flow QOS
> - in 2xx for "normal" calls
> - in the ACK for some H.323 interworking
> 
	SRD> This is one of the reasons I sent this message.  There already
two reasons identified for being able to include session descriptions in 1xx
messages.  I seems to me to be prudent to design a generic method to handle
this requirement.

> Also, unless the 18x (Session Information) is the first 1xx message, you
> run into reliability problems, as a lost 18x would not be recovered,
> unless people used something like the 1xx reliability mechanism that
> Jonathan and I have been proposed.
> 
	SRD> I am not familiar with the reliability mechanism you mention.
Can you send me a pointer.

	Another approach would be to define a new method for early delivery
of session description information.  This would allow the use of the
existing ACK method to ensure reliability.  This, however, seems to add a
potentially unacceptable amount of extra overhead.

> > The following is a proposed solution using the SIP defined Require
> > header.  It is based on the calling user indicating the desire for a
> > QOS call by including the necessary header(s) in the INVITE message:
> > 
> > Calling UA -> Called UA  INVITE
> >                          ...
> >                          Required: org.ietf.qos
> >                          QOS-Signaling: RSVP
> >                          ...
> >                          SDP
> > 
> > Calling UA <- Called UA  18X Session Information
> >                          ...
> >                          SDP
> > 
> > Calling UA -> Called UA  RSVP PATH
> > 
> > Calling UA <- Called UA  RSVP PATH
> > 
> > Calling UA -> Called UA  RSVP RESV
> > 
> > Calling UA <- Called UA  RSVP RESV
> > 
> > Calling UA <- Called UA  180 Ringing
> > 
> > Calling UA <- Called UA  200 OK
> > 
> > Calling UA -> Called UA  ACK
> > 
> > If the called user agent did not understand the QOS mechanism then it
> > would respond with a 420 Bad Extension (per the SIP spec).  The
> > calling user agent would then have the ability to decide whether or
> > not a best effort session is sufficient.
> > 
> > Thoughts?
> > 
> > Steve Donovan
> > MCI Worldcom
> 
> -- 
> Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 25 Feb 1999 12:35:28 -0500

> 
>      SRD> This is true.  The model implied in my note is that the
>      calling party is responsible for paying for the reservation.

Enforcing caller-pays in something like RSVP, with RESV messages from
both sides is probably not easy, but a wholly separate problem.

> 
>      SRD> I am not familiar with the reliability mechanism you
>      mention.  Can you send me a pointer.

http://www.cs.columbia.edu/~hgs/sip/drafts.html has the pointer.
Warning: The draft needs work.

> 
>      Another approach would be to define a new method for early
>      delivery of session description information.  This would allow
>      the use of the existing ACK method to ensure reliability.  This,
>      however, seems to add a potentially unacceptable amount of extra
>      overhead.

One could have a multi-stage session setup, where each stage has
different properties. However, this seems to open the door to all kinds
of complexity.

---

From: Anup Rao <[email-masked]>
Date: Thu, 25 Feb 1999 18:07:59 -0800

> - in the ACK for some H.323 interworking
        SRD> This is one of the reasons I sent this message.  There
already
two reasons identified for being able to include session descriptions in
1xx
messages.  I seems to me to be prudent to design a generic method to
handle
this requirement.

I think this alone is not sufficient to have enough information to meet
your requirement in this case(ie. reserve before you ring the phone). In
the scheme you propose, I think the callee does not know whether the
callers reservation has succeeded or not before it sends the 180.

-Anup.

---

From: Jon Crowcroft <[email-masked]>
Date: Fri, 26 Feb 1999 08:44:57 +0100

>>both sides is probably not easy, but a wholly separate problem.

enforcing ANY particular pay model by design condstraints of any signaling 
level mechanisms is a VERY bad idea and probanbly illegal in some
countries..

one of the critical factors i nthe USA's failure to depoy mobile telephony
as succesfully as europe is the high number of early services that had
a receiver pays only model..
 
having said that, i actually dont see how any signaling system does
constrain who pays unless it hides the identiy of one end...since so
long as the service provider has both end's (authed) caller-ids, it can always turn
around a bill...

 cheers

   jon