Subject: clarifications on 183 and "manyfolks" drafts

From: Rohan Mahy <[email-masked]>
Date: Wed, 15 Mar 2000 10:27:01 -0800

Hi,

There is a lot of emphasis in the 183 draft on interworking with the 
PSTN.  Very little space is devoted to the Session: QoS and Session: 
Security  headers though.

First issue/question:
I can think of two ways to interpret the "Session: QoS" header.  The first 
interpretation is that the user agent establishes QoS, and then once it has 
been
established, it does whatever it would normally do with that 18x message 
(like ring or play ringback for a 180).

The second is that you would use a 183 first with Session: QoS or Security 
to establish QoS or security, but you wouldn't do anything else about it. 
Then once QoS is established, you could send a new 18x message to trigger 
the desired behavior.

(Short call flows are below, assuming RSVP)
Which method is correct (if either)?

  INVITE -->
  <-- 180 Ringing (Session: QoS) [wait for QoS, then ring]
  <-- PATH
  PRACK (180)-->
  PATH -->
  RESV -->
  <-- 200 OK (PRACK)
  <-- RESV
  <-- RESV CONF
  [A plays ringback]
  --> RESV CONF
  [B alerts]

  or

  INVITE -->
  <-- 183 Session Progress (Session: QoS) [wait for QoS, then send 180]
  <-- PATH
  PRACK (183)-->
  PATH -->
  RESV -->
  <-- 200 OK (PRACK)
  <-- RESV
  <-- RESV CONF
  --> RESV CONF
  [B alerts]
  <-- 180 Ringing
  [A plays ringback]
  PRACK (180) -->
  <-- 200 OK (PRACK)

Second question:
Is the PRECONDITION-MET method from "manyfolks" intended to be used for all 
QoS enabled sessions, or just those using the DCS Gateserver method of QoS?

Third question/issue:
Let say that A calls [email-masked], and a proxy forks INVITEs in parallel 
to B, C, and D.  If A wants to establish QoS before ringing, how does the 
proxy tell A about all the relevant session descriptions?

It seems that if the proxy just forwarded each 18x message with its session 
description to A, that A would discard prior QoS relationships in favor of 
the most recent. (Not what we want)

The proxy could send multiple session descriptions (multiple SDP bodies) in 
a single 18x message to A.  If this is the right way to handle this 
situation, I think it should be more explicitly defined. If this is 
correct, would it be reasonable to put language in the next version of the 
183 draft that says that user agents MUST be able to deal with multiple SDP 
bodies if they request Session: QoS?

Last question/issue:
If peers include a key (and crypto algorithm, key length, etc.) in the 
session description (for example, using a k= tag in SDP), instead of later 
using IKE to establish an SA, do they include "Session: Security"?

thanks,
-rohan

---

From: "Donovan, Steven R." <[email-masked]>
Date: Tue, 28 Mar 2000 00:26:52 +0000

Jonathan Rosenberg wrote:
> 
> However, I disagree that the Session header only makes sense 
> for 183. I
> see no reason why. My view of the Session header is that it 
> informs the
> UA that there is some dependency on signaling behavior because of the
> session. The QoS and security Session: tokens in a request 
> indicate that
> the INVITE should not cause local alerting until the preconditions are
> met, and that a provisional response with SDP should be sent. The QoS 
> and security Session: in the provisional response indicates a similar
> thing - don't do anything with this message until the 
> preconditions are
> met. So, I would argue its OK to put a Session header in a 
> 180, in which
> case ringing (signaled by 180) doesn't occur until the 
> preconditions are
> met.
> 

It is also the case that not all scenarios require that the QoS and security
be established prior to alerting the called user.  We have outlined two
options in draft-sinnreich-interdomain-sip-qos-osp-01.txt.  The first is
call QoS assured, which is inline with the procedures outlined in the
manyfolks draft and would use the PRECONDITIONS-MET method.

The second is refered to as enabled, which decouples the SIP and QoS
signaling.  In this case, the SDP with called UA QoS information can be
carried in a 180 or 183 (depending on the type of called ua).  This scenario
does not require a PRECONDITIONS-MET method.

The confirm attribute in the proposed SDP extension drive the use of
PRECONDITIONS-MET.