Subject: [Sip] Queries/Comments on Resource Priority-04

From: "Piers O'Hanlon" <[email-masked]>
Date: Tue, 12 Oct 2004 11:45:18 +0100

Hi,

I've taken a look at the draft and have the following comments:

General comments:
- The fact that it isn't mandatory to mark all responses with RP headers means that one should at least make it a SHOULD(MUST?) to provide "resource prioritization" based on a dialog or session initiated with the RP header (possibly requiring Stateful proxy?). Otherwise it seems that being able to know if a node "supports Resource priority" (using OPTIONS or a Require hdr) may not be of use if you can't be assured the whole dialog/session will be assured of the "resource prioritization"? If it's not specified in this document then I guess it will need to be specified in some external policy document...(out of scope)

Section 3.3
- minor comment: It might be useful to label table something like 'Table 1'.
- In the second the paragraph the 420 response is incorrectly defined as "(Not Supported)" - when it should be "(Bad Extension)".
- In the same paragraph the explanation following the handling of the 420 response seems at odds with the description in section 4.2.2 and that of RFC3261. Firstly this is because it indicates that a 420 is generated when it encounters a unknown RP value (on an RP capable node) -  shouldn't that be covered in section 4.2.2 - Shouldn't a 420 be generated only by non RP capable node in response to Require? Secondly it seems to reccomend adding an 'Accept-Resource-Priority' header when RFC3261 specifies adding an "Unsupported" header for a 420 response? Or maybe it was intended to talk about the 417 handling here?

Example 7.2
- In this example - according to section 4.2.2 a 417 response should only generated when in strict mode, in which case the shouldn't the INVITE contain the Require header?

Piers O'Hanlon
--------------_____________
Computer Science Department
University College London

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 25 Oct 2004 23:12:38 -0400

> I've taken a look at the draft and have the following comments:

Thanks for your comments.

> 
> General comments: - The fact that it isn't mandatory to mark all
> responses with RP headers means that one should at least make it a
> SHOULD(MUST?) to provide "resource prioritization" based on a dialog
> or session initiated with the RP header (possibly requiring Stateful
> proxy?). Otherwise it seems that being able to know if a node
> "supports Resource priority" (using OPTIONS or a Require hdr) may not
> be of use if you can't be assured the whole dialog/session will be
> assured of the "resource prioritization"? If it's not specified in
> this document then I guess it will need to be specified in some
> external policy document...(out of scope)

There are two types of resource prioritization, as alluded to in the 
document (Introduction), namely to prioritize the signaling handling 
itself and, more importantly, the resources such signaling controls, 
e.g., trunk circuits.

Resources such as trunk circuits are inherently stateful, as they are at 
UAs, and thus don't require the response to carry the R-P indication.

The only time the response would need to carry the R-P header is for 
prioritizing the handling of the SIP request itself. Since a response is 
part of a transaction, transaction-stateful proxies (i.e., most of them) 
would already know that the transaction has high priority and can handle 
this without additional indication. Thus, only the rare case of a 
stateless proxy is relevant. However, since that proxy can't readily 
ascertain that the response is authorized (ignoring S/MIME for now), 
this isn't likely to be useful.

I'll add a sentence that summarizes this.

> 
> 
> Section 3.3 - minor comment: It might be useful to label table
> something like 'Table 1'. 

Done.

- In the second the paragraph the 420
> response is incorrectly defined as "(Not Supported)" - when it should
> be "(Bad Extension)". 

Fixed.

- In the same paragraph the explanation
> following the handling of the 420 response seems at odds with the
> description in section 4.2.2 and that of RFC3261. Firstly this is
> because it indicates that a 420 is generated when it encounters a
> unknown RP value (on an RP capable node) -  shouldn't that be covered
> in section 4.2.2 

That part of the paragraph below the table is an orphaned remnant of 
some earlier behavioral description. The error behavior is now described 
in Section 4.2. I ditched the confusing set of sentences.

- Shouldn't a 420 be generated only by non RP
> capable node in response to Require? Secondly it seems to reccomend
> adding an 'Accept-Resource-Priority' header when RFC3261 specifies
> adding an "Unsupported" header for a 420 response? Or maybe it was
> intended to talk about the 417 handling here?

See above.

> 
> Example 7.2 - In this example - according to section 4.2.2 a 417
> response should only generated when in strict mode, in which case the
> shouldn't the INVITE contain the Require header?

Indeed.

> 
> 
> Piers O'Hanlon --------------_____________ Computer Science
> Department University College London