Subject: Re: clarifications on 183 and "manyfolks" drafts

From: William Marshall <[email-masked]>
Date: Mon, 20 Mar 2000 23:48:14 -0500 (EST)

> The 183 draft says you can use the Session header in any 18x message (with 
> Media, QoS, or Security).  If your interpretation is correct, why would 
> anyone ever use Session QoS with a 180 or 182?

Our draft says a response of 180 or 182 to the INVITE means the UAS doesn't
understand the preconditions, and UAC should do the best it can without them.
That part is independent of whether the 180/182 contained a Session: header
or not.

But what might it mean?  For cases where the media flow is one-way, UAC -> UAS,
it might be reasonable for the UAC to play ringback as soon as reservation is
complete, and UAS do the alterting on receipt of PRECONDITION-MET (i.e.
no additional 180-Ringing response.  However, my preference is for simplicity.

> 
> So it doesn't make sense to use PRECONDITION-MET if you are just using 
> "plain-vanilla" RSVP or IKE. You take a hit for message efficiency, and you 
> don't gain any functionality, yeah?
> 

There are two separate issues there.  First, one of your cisco colleagues 
pointed out that RESV-CONF is not a reliable message (sent via the "send 
and pray" transport mechanism) and very difficult to force a retransmission.  
The mechanism in this draft provides reliability to the message exchanges.

Second, the UAS needs to know whether the UAC will be using "plain-vanilla"
RSVP before it sends the request for a SIP confirmation in the 183.  How can it
know that?  That seems to be a hit for message efficiency there.  The
solution in the draft handles arbitrary reservation protocols, whether they
have a confirmation mechanism built in or not.  That seems a big gain in
functionality.

Bill Marshall
[email-masked]

-----original message-----
Date: Mon, 20 Mar 2000 10:55:11 -0800
To: William Marshall <[email-masked]>
From: Rohan Mahy <[email-masked]>
Subject: Re: clarifications on 183 and "manyfolks" drafts
Cc: [email-masked]
> 
> Hi,
> 
> Thanks for the reply.  Comments inline...
> 
> At 02:37 PM 3/17/00 , William Marshall wrote:
> > > I can think of two ways to interpret the "Session: QoS" header.  ...
> >
> >Our interpretation of the "Session: QoS" header is that it carries
> >the SDP from the called party back to the calling party, so that both
> >endpoints can simultaneously establish QoS.  Once the QoS is established,
> >(unless a confirm attribute was requested) another 18x message is
> >sent from called party back to calling party to play ringback.
> 
> The 183 draft says you can use the Session header in any 18x message (with 
> Media, QoS, or Security).  If your interpretation is correct, why would 
> anyone ever use Session QoS with a 180 or 182?
> 
> >This is the second sample call flow in your email (attached below).
> >
> > > 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?
> >
> >The intention is that PRECONDITION-MET can be used for all types of QoS
> >setup protocols, including those that do not have a mechanism to reliably
> >inform both endpoints of the success or failure of the request.  The
> >PRECONDITION-MET is also used to confirm all types of security associations,
> >that likewise may not have a mechanism to reliably inform both endpoints 
> >of the
> >success or failure of the request.
> 
> So it doesn't make sense to use PRECONDITION-MET if you are just using 
> "plain-vanilla" RSVP or IKE. You take a hit for message efficiency, and you 
> don't gain any functionality, yeah?
> 
> > > 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?
> >
> >If the proxy forks the request to three endpoints, each of those endpoints
> >will send a 183-Session-Progress back to A, each including one SDP for
> >the media stream to them.  These are presumably distinguished by a tag
> >field in the call-leg identification.  A has the job of managing three
> >separate QoS reservations (or one reservation that can be used for three
> >destinations), depending on the interfaces it has available.  In general, I'd
> >expect three separate PRECONDITION-MET messages, one each to B, C, and D,
> >with the success/failure results for each.  No additional work for the proxy.
> 
> While this approach might work for a stateless proxy, I'm interested in the 
> behavior of a stateful, parallel, forking proxy.  The behavior you 
> described would be illegal (forwarding off the Via list) in this kind of 
> proxy, since the INVITEs to B, C, & D would be sourced from the proxy, 
> which would be the last stop on the Via list of each forked INVITE.  A 
> would never see any responses to the proxy's forked INVITEs.
> 
> thanks,
> -rohan
> 
> > > 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"?
> >
> >I don't see much distinction between "Session: QoS" and "Session: Security"
> >in the 183 message.  In both cases it means there is an SDP attached,
> >and the UAC needs to look at it and decide how to meet the preconditions.
> >If "a=security:mandatory" is in there, and a "k=" line too, meeting
> >the security precondition should be so easy the UAS shouldn't need a
> >confirmation (though it can ask for one anyway).
> >
> >Bill Marshall
> >[email-masked]
> >
> >-----original message-----
> >Date: Wed, 15 Mar 2000 10:27:01 -0800
> >To: [email-masked]
> >From: Rohan Mahy <[email-masked]>
> >Subject: clarifications on 183 and "manyfolks" drafts
> >
> > >
> > > 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: Rohan Mahy <[email-masked]>
Date: Tue, 21 Mar 2000 11:12:35 -0800

Hi,

OK, I get the need for preconditions.  We still need to get session 
descriptions from B,C, and D to A.  My proposal was sending these in one 
183 with multiple bodies.  Is this reasonable?

thanks,
-rohan

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 22 Mar 2000 00:23:53 -0500

Rohan Mahy wrote:
> 
> Hi,
> 
> OK, I get the need for preconditions. 

I am in agreement with Bill's assessment here. The idea is to keep the
precondition mechanism independent of the underlying QoS protocol.

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.

 We still need to get session

> would never see any responses to the proxy's forked INVITEs.

This is not correct. The INVITE is originated at A. When the proxy
forks, it does not re-originate the request. It will add a Via header,
different for each forked request in the branch-id parameter. Thus, the
three provisional responses can all be distinguished at the proxy. The
proxy should forward all three upstream, even if its stateful. In fact,
since the proxy forked, its not allowed to be stateless. The UAC will be
able to distinguish the provisional responses by tag in the To field.

A proxy should definitely not try to aggregate bodies from multiple
provisional responses. There are numerous problems with doing so, not
the least of which is invalidating signatures, mandating MIME multipart,
processing burden on the proxy, latency for sending a provisional
response (you must wait for all of them), and so on. 

> > using IKE to establish an SA, do they include "Session: Security"?

Including a k= tag in SDP is probably not the best way to establish a SA
for the media session. It is completely insecure unless the SIP message
is encrypted, and there are some issues with blind encryption of SIP
messages before the called parties identity is known. The security task
force is considering the right approach for this.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: Rohan Mahy <[email-masked]>
Date: Wed, 22 Mar 2000 19:22:32 -0800

>case ringing (signaled by 180) doesn't occur until the preconditions are

great.  this could save a whole cycle of 183/ PRACK/ 200 messages in some 
circumstances.

>able to distinguish the provisional responses by tag in the To field.

OK, I was confused here.  To do this right, the UAC should be able to setup 
QoS with all the potential target UASs, and then release the unused 
reservations when a 200 OK arrives.

>force is considering the right approach for this.

Some of Cisco's customers were interested in a combination of hop-by-hop 
signaling encryption with RTP payload encryption, since this method works 
with SIP, MGCP, or MEGACO.  I don't think there is a one-size fits all 
approach, so Cisco will probably support this model as well as the 
Digest/PGP model (and perhaps others as well).

I'd be happy to provide you with more detail if you are interested.

thanks,
-rohan