Subject: SIP/RSVP: How should the 183 be used?

From: Bryan Byerly <[email-masked]>
Date: Tue, 29 Feb 2000 19:46:31 -0500

Hi Shai/Burcak,

> Bryan, Burcak
>
> Let me make a few assumptions:
>
> 1. We are talking about Cable modems and PacketCable DQoS (DOCSIS 1.1)

> 2. We are looking per-call QoS
> 3. "Assured" means Resources are allocated before a ring (a ring
requires
>   QoS), and resources are committed after the other side picked up
>   (call commences).

Shai, assumptions (2) and (3) are good.  However, (1) is off the mark.
I'm actually tryng to understand QoS with vanilla SIP.
Thanks for the responses guys!

Along those lines, here's a follow up question:

Assuming an objective of assured QoS between two SIP gateways,
I can think of 2 different ways to trigger the messages.
(If anyone can anyone think of more, I'd appreciate a call flow sketch)

I'm trying to understand the tradeoffs between the two
triggering methods and would be interested on preferences
anyone has.  I'm especially interested in if the 183 implies
one flow over the other and is the ResvConf reliable.

-------------------
SIP/RSVP message flow 1:
-------------------

      SIP               SIP               SIP
      GW                Proxy             GW
       |                 |                 |
       |--[1]INVITE----->|                 |
       |                 |                 |
       |<-[2]100---------|                 |
       |                 |--[3]INVITE----->|  1 ott
       |                 |                 |
       |                 |<-[4]100---------|
       |                 |                 |
 2 ott |<------[5]Path---------------------|
       |                 |                 |
       |-------[6]Resv-------------------->|  3 ott
       |                 |                 |
 4 ott |<-[8]183---------|<-[7]183---------|
       |                 |                 |
       |-------[9]Path-------------------->|  5 ott
       |                 |                 |
 6 ott |<------[10]Resv--------------------|
       |                 |                 |
       |--[11]PRACK(183)>|--[12]PRACK(183)>|  7 ott
       |                 |              ringing
       |                 |                 |
 8 ott |<---[14]180------|<-[13]180--------|
    ringback             |                 |
       |                 |                 |
       |                 |              off hook
       |<---[16]200------|<-[15]200--------|
       |                 |                 |
       |----[17]ACK----->|--[18]ACK------->|
       |                 |                 |
       |<===============RTP===============>|
       |                 |                 |

Event   Triggered by:
[1]     dialed digits
[2]     [1]  optional
[3]     [1]
[4]     [3]  optional
[5]     [3]
[6]     [5]
[7]     [6]
[8]     [7]
[9]     [8]
[10]    [9]
[11]    [10]
[12]    [11]
[13]    [12]
[14]    [13]
[15]    off hook
[16]    [15]
[17]    [16]
[18]    [17]

This triggering method incurs 8 one-way trip times (ott's) until
ringback.

-------------------
SIP/RSVP message flow 2:
-------------------

      SIP               SIP               SIP
      GW                Proxy             GW
       |                 |                 |
       |--[1]INVITE----->|                 |
       |                 |                 |
       |<-[2]100---------|                 |
       |                 |--[3]INVITE----->|  1 ott  --+
       |                 |                 |           |
       |                 |<-[4]100---------|  <--------+
       |                 |                 |           |
 2 ott |<-[6]183---------|<-[5]183---------|  <--------+
       |                 |                 |           |
       |-------[7]Path-------------------->|  3 ott    |
       |                 |                 |           |
 4 ott |<------[8]Resv---------------------|           |
       |                 |                 |           |
       |-------[9]ResvConfirm------------->|  5 ott    |
       |                 |                 |           |
 2 ott |<------[10]Path--------------------|   <-------+
       |                 |                 |
       |-------[11]Resv------------------->|  3 ott
       |                 |              ringing
 6 ott |<-[13]180--------|<-[12]180--------|  triggered by [9] & [11]
     ringback            |                 |
       |                 |                 |
       |                 |              offhook
       |<-[15]200--------|<-[14]200--------|
       |                 |                 |
       |--[16]ACK------->|--[17]ACK------->|
       |                 |                 |
       |<===============RTP===============>|
       |                 |                 |

Event   Triggered by:
[1]     dialed digits
[2]     [1]  optional
[3]     [1]
[4]     [3]  optional
[5]     [3]
[6]     [5]
[7]     [6]
[8]     [7]
[9]     [8]
[10]    [3]
[11]    [10]
[12]    [9] & [11]
[13]    [12]
[14]    offhook
[15]    [14]
[16]    [15]
[17]    [16]

This triggering method incurs 6 one-way trip times (ott's) until
ringback.

Discussion & Questions:

So, flow 1 is sequential; whereas flow 2 has some parallelism.
Both flows are providing "assured QoS".

BTW, my guess is someone will complain about the added complexity
of having a SIP proxy in the middle.  Feel free to mentally edit
it out.  (For now, my (rather simplistic) assumption is to ignore its
affect on ott times).

I recall reading in the RSVP RFC (RFC 2205, section 2.6, bullet 2) that:

      o    The receipt of a ResvConf gives no guarantees.  Assume the
           first two reservation requests from receivers R1 and R2
           arrive at the node where they are merged.  R2, whose
           reservation was the second to arrive at that node, may
           receive a ResvConf from that node while R1's request has not
           yet propagated all the way to a matching sender and may still

           fail.  Thus, R2 may receive a ResvConf although there is no
           end-to-end reservation in place; furthermore, R2 may receive
           a ResvConf followed by a ResvErr.

1) Does this mean that the ResvConf is not reliable and should not be
   depended upon (as shown in SIP/RSVP message flow 2)?

2) It seems like ResvConf may only be unreliable if merging of RSVP
    messages occurs.
    a) In reality, does anyone actually merge RSVP messages?
    b) Are there any other cases to consider when ResvConf is
unreliable?

2) Can anyone do better than 6 ott until ringback?

3) Does the 183 have any inherent meaning such as:
    Flow of the 183 message implies the sender has already
    established one-way QoS? (as shown in SIP/RSVP message flow 1)?
    or conversely, 183 implies that the sender has not yet
    establised one-way QoS?

Thanks for your help!

Bryan

Bryan J. Byerly
[email-masked]
(919) 392-7091