Subject: [Sip] New draft modifying RFC 4412 for Responses

From: "James M. Polk" <[email-masked]>
Date: Sat, 16 Jun 2007 16:13:37 -0500

SIP WG

Here is a new ID I've written because of implementation 
considerations to allow a SIP Resource-Priority header (RPH) in 
responses, which RFC 4412 currently disallows, assuming only that 
stateful devices will use RPH.  There have been many requests to have 
this "only stateful devices" restriction relaxed, in certain 
scenarios.  This ID does this, and proposes how IANA is changed 
accordingly wrt RPH.  This ID does nothing else.

Comments are appreciated.

>A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
>
>         Title           : Allowing SIP Resource Priority Header in 
> SIP Responses
>         Author(s)       : J. Polk
>         Filename        : draft-polk-sip-rph-in-responses-00.txt
>         Pages           : 6
>         Date            : 2007-6-15
>
>    The Session Initiation Protocol (SIP) Resource Priority Header
>    (RPH), in its current form, is ignored in SIP responses.  This was a
>    design choice during RFC 4412's development. This is now considered
>    a bad design choice in certain scenarios.  This document corrects
>    RFC 4412's communications model by optionally allowing a SIP server
>    or user agent client to process the Resource-Priority Header in a
>    response.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-polk-sip-rph-in-responses-00.txt

_______________________________________________
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: "Francois Audet" <[email-masked]>
Date: Mon, 18 Jun 2007 11:29:11 -0500

Hi James,

It might be useful to have some wording on the limitations of using a
response
to carry a Resource-Priority header in a response.

Specifically, a UAS can not use a response to carry the
Resource-Priority
in cases where the Resource-Priority "absolutely has" to be delivered to
the 
UAC. It is therefore only useable for cases where a forking proxy 
may discard the response (i.e., forward another instead) without
breaking
anything. In other words,you need to think about HEFP before using this
draft.

In some scenarios, this is probably the desired behavior.

In other scenarios, it may not acceptable. So instead, for those
scenarios,
the terminating side would have to send a new request with a
Resource-Priority 
instead of using a response.

> -----Original Message-----
> From: James M. Polk [mailto:[email-masked]] 
> Sent: Saturday, June 16, 2007 14:14
> To: [email-masked]
> Subject: [Sip] New draft modifying RFC 4412 for Responses
> 
> SIP WG
> 
> considerations to allow a SIP Resource-Priority header (RPH) 
> in responses, which RFC 4412 currently disallows, assuming 
> only that stateful devices will use RPH.  There have been 
> many requests to have this "only stateful devices" 
> restriction relaxed, in certain scenarios.  This ID does 
> this, and proposes how IANA is changed accordingly wrt RPH.  
> This ID does nothing else.
> 
> >http://www.ietf.org/internet-drafts/draft-polk-sip-rph-in-res
> ponses-00.
> >txt
> 
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: Janet P Gunn <[email-masked]>
Date: Mon, 25 Jun 2007 15:02:13 -0400

In working on specifying and deploying systems that will actually use the 
RPH with the ets and wps namespaces, we have found several contexts in 
which the RPH  on the response is very useful.

1)      Error reporting.  RFC 4412 does not give clear direction on the 
treatment of RPH with syntax errors (out of range priority values, 
duplicate namespaces, etc.)  We have found that including the RPH in the 
4xx responses is usesful in addressing the errors.
2)      In our system, we often set the ets  RPH (with default priority) 
based on the “ETS-DN”“dialed number” or uri, before authentication and 
before knowing the correct priority value.  Including the RPH in the 
response is a useful way of conveying the correct priority value back to 
nodes earlier in the “call flow”.
3)      Similarly, if an RP actor receives a SIP INVITE with the ETS-DN, 
but no RPH it may, after authenticating the call, include RPH in the 
responses in order to inform  nodes earlier in the call flow that this is 
a priority call.
4)      If the RPH is being used to prioritize processing (of both 
messages and responses) in the SIP user agent, including the RPH in the 
response allows the receiving RP actor to give the response “ETS 
treatment” before checking on the “state” of the call.  This is 
particularly relevant when the RP actor itself is congested.

Janet

---

From: "DOLLY, MARTIN C, ATTLABS" <[email-masked]>
Date: Fri, 29 Jun 2007 10:29:24 -0500

Hello,
 
Agreed. In addition, not having the RPH in the responses would mean the
proxies would have to maintain the state of the RPH value.
 
Martin

________________________________

From: Janet P Gunn [mailto:[email-masked]] 

In working on specifying and deploying systems that will actually use
the RPH with the ets and wps namespaces, we have found several contexts
in which the RPH  on the response is very useful. 

1)        Error reporting.  RFC 4412 does not give clear direction on
the treatment of RPH with syntax errors (out of range priority values,
duplicate namespaces, etc.)  We have found that including the RPH in the
4xx responses is usesful in addressing the errors. 
2)        In our system, we often set the ets  RPH (with default
priority)  based on the "ETS-DN""dialed number" or uri, before
authentication and before knowing the correct priority value.  Including
the RPH in the response is a useful way of conveying the correct
priority value back to nodes earlier in the "call flow". 
3)        Similarly, if an RP actor receives a SIP INVITE with the
ETS-DN, but no RPH it may, after authenticating the call, include RPH in
the responses in order to inform  nodes earlier in the call flow that
this is a priority call. 
4)        If the RPH is being used to prioritize processing (of both
messages and responses) in the SIP user agent, including the RPH in the
response allows the receiving RP actor to give the response "ETS
treatment" before checking on the "state" of the call.  This is
particularly relevant when the RP actor itself is congested. 

Janet