Subject: Thoughts on SIP RSVP QOS Interworking

From: "Donovan, Steven R. (MCI)" <[email-masked]>
Date: Tue, 23 Feb 1999 22:26:18 -0000

All,

The current thread on getting SDP information in a 1xx got me to thinking
again about the interworking of SIP and RSVP for QOS.  

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.

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 23 Feb 1999 21:26:58 -0500

> "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...

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

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.

> 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:
> 
> 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: Jonathan Rosenberg <[email-masked]>
Date: Wed, 24 Feb 1999 12:26:12 -0500

> - in the ACK for some H.323 interworking

In fact, I don't think there is really one "right" way to work RSVP and
SIP together. A nice thing about having them be really orthogonal is
that you can set up the timing based on your specific requirements. In
the case where the media is just one thing (g.711), you can take this
approach (as Henning indicated), but when its negotiated, you may need
to wait till later, or readjust.

Along these lines, I'm not sure you need message support for RSVP within
SIP. If the callee is RSVP capable, it can send the PATH messages as
soon as it sends its 183, whether or not the caller asked or knows about
it. If the caller is not RSVP capable, it will ignore the PATH messages
and never send a RESV. Anyway, the RSVP may not even go end to end. An
intranet may use it for local reservation and for establishing dynamic
SLA's at the service provider boundary, but it may not be forwarded
beyond that. In this case, the both parties might want to send RSVP
messages indpendent of whether the other side supports it.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: [email-masked]
URL: http://www.cs.columbia.edu/~jdrosen