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

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 01 Mar 2000 01:58:16 -0500

Comments inline below:

Bryan Byerly wrote:
> 
> ------------------
> 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".

They're not hugely different; (1) is relying on the PRACK to convey
reservation confirmation, whereas (2) is using RSVP for this purpose.
The problem in using PRACK for this purpose is that the 183 will be
retransmitted until the PRACK comes. If you are delaying the PRACK
waiting for reservation completion, lots of needless messages are sent.
The fundamental problem is that PRACK meant for the sole purpose of
acknowledging a provisional response. The overload in its meaning here
is having an interaction with the reliability mechanism.

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

Reservation merging happens only for multicast. I don't think we are
really considering that case here. The meaning of "don't ring until
resources are reserved" only really has meaning in a point to point
call. For something like an mbone session, I'm not sure how it works.
Our original draft on the SDP/QoS preconditions actually talks about SAP
usage, but I think there are issues with it.

> 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?

183, according to draft-ietf-sip-183, has no meaning beyond "your
session is proceeding". 

For the service DCS is trying to do, there needs to be some way for both
sides to know the reservation is complete. It seems we have a few
different call flows each with a different way to do this:

1. INFO method
2. PRACK/183
3. RESVCONF

The tradeoffs, it seems, are relying on RSVP (in case 3) vs. building it
into the application protocol (1 and 2), overloading existing mechanisms
(in case 2) vs. having mechanisms specifically convey the confirmation
(3 and also 1). 

-Jonathan R.

-- 
Jonathan D. Rosenberg                       200 Executive Drive
Chief Scientist                             Suite 120 
dynamicsoft                                 West Orange, NJ 07052
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: Manoj Bhatia <[email-masked]>
Date: Wed, 01 Mar 2000 10:56:11 -0500

Jonathan

Your comment about 183 clearly says
"according to draft-ietf-sip-183, has no meaning beyond "your
session is proceeding".

However, we do have provisions for QoS and Security as Session Headers
for 183. In fact the drafts says that header value of QoS can be used to
establish QoS
relationship between caller and callee.

How does all that fit into the question Bryan raised ?

thanks
-manoj

--
Manoj Bhatia                           |        |         |
[email-masked]                       |       :|:       :|:
7025 Kit Creek Road, P.O. Box 14987    |     :|||||:   :|||||:
Research Triangle Park, NC 27709       |   .:|||||||:.:|||||||:.
919-392-3873      fax: 919-392-6801    |  C i s c o S y s t e m s

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 02 Mar 2000 01:07:48 -0500

Manoj Bhatia wrote:
> for 183. In fact the drafts says that header value of QoS can be used
> to establish QoS

183 by itself has no meaning beyond "your session is proceeding", as I
suggested. Inclusion of the Session: header with a value of "qos"
implies that the UAS wishes to couple resource reservation and call
signaling. This does not imply that the UAS has completed resource
reservation.

-Jonathan R.