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

From: William Marshall <[email-masked]>
Date: Fri, 17 Mar 2000 17:37:08 -0500 (EST)

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

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.

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

> 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: Mon, 20 Mar 2000 10:55:11 -0800

Hi,

Thanks for the reply.  Comments inline...

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

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

>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