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

From: "GOLDMAN, STUART O \(STUART\)" <[email-masked]>
Date: Tue, 3 Jul 2007 15:17:39 -0500

Folks,

It does seem useful to be able to include the RPH in the response
messages, and I don't see any downside in allowing this.

Stuart Goldman

Alcatel-Lucent 

[email-masked]

602 493 8438

________________________________

From: DOLLY, MARTIN C, ATTLABS [mailto:[email-masked]] 
Sent: Friday, June 29, 2007 8:29 AM
To: Janet P Gunn; James M. Polk
Cc: [email-masked]
Subject: RE: [Sip] New draft modifying RFC 4412 for Responses

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

_______________________________________________
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: "James M. Polk" <[email-masked]>
Date: Thu, 05 Jul 2007 17:35:14 -0500

Francois

in-line

At 11:29 AM 6/18/2007, Francois Audet wrote:
>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.

Do you have any text (or direction) to offer that you would want to 
see in this ID?

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

I have to admit, I do not understand this use-case (as it is 
written), since I'm not sure what you are referring to when you say 
"..."absolutely has" to be delivered to the  UAC".  Right now, RPH 
isn't in any response, so when did it become a situation of 
"..."absolutely has" to be delivered...".

Remind me what HEFP is again...

>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
> >
> > 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-res
> > ponses-00.
> > >txt
> >
> >
> > This list is for NEW development of the core SIP Protocol Use
> > [email-masked] for questions on current sip

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 17 Jul 2007 16:45:58 -0500

> Sent: Thursday, July 05, 2007 15:35
> To: Audet, Francois (SC100:3055); [email-masked]
> >It might be useful to have some wording on the limitations 
> of using a 
> >response to carry a Resource-Priority header in a response.
> 
> Do you have any text (or direction) to offer that you would 
> want to see in this ID?

> "..."absolutely has" to be delivered...".

What I mean is that the error response may not be delivered to the UAC
because a forking proxy will only deliver one final response. If there
are multiple error responses on the individual forks, one being the one
with the RPH, and the other being some other response, it is up to the
proxy to decide which one to forward back.

So the UAC can not rely on receiving the RPH to "re-intiate" the session
or
provide some alternative treatment. This may or may not be a problem
depending
on the application (that's why I said "if it absolutely has").

> Remind me what HERFP is again...

HERFP is the problem described above. It stands for "Heterogeneous Error
Response Forking Problem".

> >In other words,you need to think about HERFP before using this draft.
> >

What I'm looking for is just a description of the limitation of using
a response for carrying the information, in order to alert the
implementors.

I'm not looking for a solution to the HERFP problem in this draft.

---

From: Janet P Gunn <[email-masked]>
Date: Tue, 17 Jul 2007 22:20:26 -0400

> on the application (that's why I said "if it absolutely has").

I don't think that will be a problem.

For one thing (for the namespaces I am working with) the expectation would 
be that ALL the responses (except 100 and 403) would have the RPH on the 
response, so it wouldn't matter which one made it back to the UAC.

Secondly, the expectation is that the devices responsible for 
"re-initiating" WOULD be stateful, and not dependant on the information in 
the RPH in the response.  It is the intervening devices that might not be 
stateful, and would take advantage of the RPH information in the 
responses.

Janet

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 18 Jul 2007 10:26:54 -0500

> > are multiple error responses on the individual forks, one being the 
> > one with the RPH, and the other being some other response, 
> it is up to 
> > the proxy to decide which one to forward back.
> > 
> > So the UAC can not rely on receiving the RPH to "re-intiate" the 
> > session or provide some alternative treatment. This may or 
> may not be 
> > a problem depending on the application (that's why I said "if it 
> > absolutely has").
> > 
> 
> For one thing (for the namespaces I am working with) the 
> expectation would be that ALL the responses (except 100 and 
> 403) would have the RPH on the response, so it wouldn't 
> matter which one made it back to the UAC. 

I am not talking about multiple provisional responses from the same
endpoint.

I am talking about multiple responses (provisional and final) from 
multiple forks. For example, multiple 4XX responses.

While it is possible that a single forking proxy may decide to 
include the RPH in all responses, that proxy has absolutely no 
control over downstream and upstream proxies who may not include it
(they may be proxies in different domains).

That's the point I'm trying to make. You can not enforce the 
presence RPH in responses in a global system.

> "re-initiating" WOULD be stateful, and not dependant on the 
> information in the RPH in the response.  It is the 
> intervening devices that might not be stateful, and would 
> take advantage of the RPH information in the responses. 

That is precisely the type of clarfication that needs to be included
in the draft. It points out the constrainsts of the mechanism so 
implementors use the feature properly.

Some text explaining that the UAC needs to be able to deal with the RPH
not being present in responses gracefully (and why) is needed.

Similar text for proxies also need to be there. What if a proxy 
forwards a request with RPH and it receives nultiple responses from
the downstream proxies, with some including the RPH and others not
including it? Does this need to be standardized?

---

From: Janet P Gunn <[email-masked]>
Date: Wed, 18 Jul 2007 13:40:57 -0400

In line.

> multiple forks. For example, multiple 4XX responses.

Yes, I understood that.
> presence RPH in responses in a global system.

Agree. For the context I am working in, a "global system" is not of 
concern.  I would not expect universal "RPH in responses" in a global 
system.

> That is precisely the type of clarification that needs to be included
> in the draft. It points out the constraints of the mechanism so 

I am not sure why that needs to be in the ID.  It is an implementation 
specific issue. 

Since  RFC 4412, as currently published, forbids RPH in responses, I think 
it "goes without saying" that "the UAC needs to be able to deal with the 
RPH not being present in responses".

Further, while I know that the systems (and namespaces) _I_ work with 
intend to use RPH in responses, I also have been told that other systems 
(using other namespaces) do not intend to put RPH in ANY responses.  I do 
not think there is any need to standardize this aspect, just to adjust the 
standard so it is PERMITTED.
> including it? Does this need to be standardized?

Again, I do not think there is a need to standardize this aspect.

Janet

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 18 Jul 2007 13:58:39 -0500

I will be happy if the document is revised to explain that you cannot
expect that responses received by a UAC or Proxy will necessarily
include RPM, in particular in systems where forking occurs, and that
therefore, applications that use this draft must take it into account.

	From: Janet P Gunn [mailto:[email-masked]] 
	Sent: Wednesday, July 18, 2007 10:41
	To: Audet, Francois (SC100:3055)
	Cc: [email-masked]; James M. Polk
	Subject: RE: [Sip] New draft modifying RFC 4412 for Responses

	In line. 
	
	"Francois Audet" <[email-masked]> wrote on 07/18/2007 11:26:54
AM:
	
	> > > What I mean is that the error response may not be
delivered 
	> > to the UAC 

	
	Yes, I understood that.

	> presence RPH in responses in a global system. 
	
	Agree. For the context I am working in, a "global system" is not
of concern.  I would not expect universal "RPH in responses" in a global
system. 
	
	> not being present in responses gracefully (and why) is needed.

	I am not sure why that needs to be in the ID.  It is an
implementation specific issue.   
	
	Since  RFC 4412, as currently published, forbids RPH in
responses, I think it "goes without saying" that "the UAC needs to be
able to deal with the RPH not being present in responses". 
	
	Further, while I know that the systems (and namespaces) _I_ work
with intend to use RPH in responses, I also have been told that other
systems (using other namespaces) do not intend to put RPH in ANY
responses.  I do not think there is any need to standardize this aspect,
just to adjust the standard so it is PERMITTED.
	> including it? Does this need to be standardized? 
	
	Again, I do not think there is a need to standardize this
aspect. 
	
	Janet

---

From: Janet P Gunn <[email-masked]>
Date: Wed, 18 Jul 2007 15:42:32 -0400

Fine with me.

Janet

"Audet, Francois (SC100:3055)" <[email-masked]> wrote on 07/18/2007 
02:58:39 PM:

> I will be happy if the document is revised to explain that you 
> cannot expect that responses received by a UAC or Proxy will 
> necessarily include RPM, in particular in systems where forking 
> occurs, and that therefore, applications that use this draft must 
> take it into account.
> 

system.
> Since  RFC 4412, as currently published, forbids RPH in responses, I
> think it "goes without saying" that "the UAC needs to be able to 
> deal with the RPH not being present in responses". 
> 
> with intend to use RPH in responses, I also have been told that 
> other systems (using other namespaces) do not intend to put RPH in 
> ANY responses.  I do not think there is any need to standardize this
> aspect, just to adjust the standard so it is PERMITTED.
> >

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Thu, 19 Jul 2007 13:12:10 +0200

Hi,
 
Maybe sending the RPH to the UAC is something that the 199 mechanism could be used for.
 
Regards,
 
Christer

	From: Francois Audet [mailto:[email-masked]] 
	Sent: 18. heinäkuuta 2007 21:59
	To: Janet P Gunn
	Cc: [email-masked]; James M. Polk
	Subject: RE: [Sip] New draft modifying RFC 4412 for Responses

	I will be happy if the document is revised to explain that you cannot expect that responses received by a UAC or Proxy will necessarily include RPM, in particular in systems where forking occurs, and that therefore, applications that use this draft must take it into account.

		
		In line. 

		
		Yes, I understood that.
		> presence RPH in responses in a global system. 
		
		Agree. For the context I am working in, a "global system" is not of concern.  I would not expect universal "RPH in responses" in a global system. 
		
		> not being present in responses gracefully (and why) is needed. 
		
		I am not sure why that needs to be in the ID.  It is an implementation specific issue.   
		
		Since  RFC 4412, as currently published, forbids RPH in responses, I think it "goes without saying" that "the UAC needs to be able to deal with the RPH not being present in responses". 
		
		Further, while I know that the systems (and namespaces) _I_ work with intend to use RPH in responses, I also have been told that other systems (using other namespaces) do not intend to put RPH in ANY responses.  I do not think there is any need to standardize this aspect, just to adjust the standard so it is PERMITTED.

		Janet

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Sun, 22 Jul 2007 14:54:45 +0200

I notice that on 1) below you seem to deal with error reporting rather than priority.
 
In RFC 4412 the semantics are to treat the request, the transaction (and possibly the dialog) with priority according to the given namespace.
 
In James draft, the semantics would appear to be to treat the response with priority according to the given namespace.
 
What you seem to be requesting here is that any 4xx response with a RPH header is indicating the namespace usage that was in error.
 
That seems to be overloading the semantics of the header somewhat.
 
regards
 
Keith

	From: Janet P Gunn [mailto:[email-masked]] 
	Sent: Monday, June 25, 2007 8:02 PM
	To: James M. Polk
	Cc: [email-masked]
	Subject: Re: [Sip] New draft modifying RFC 4412 for Responses

	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

	"James M. Polk" <[email-masked]> wrote on 06/16/2007 05:13:37 PM:
	
	> 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.
	> 
	> >    (RPH), in its current form, is ignored in SIP responses.  This was a
	> >    design choice during RFC 4412's development. This is now considered
	> >    RFC 4412's communications model by optionally allowing a SIP server
	> >http://www.ietf.org/internet-drafts/draft-polk-sip-rph-in-responses-00.txt
	> 
	>

---

From: Janet P Gunn <[email-masked]>
Date: Sun, 22 Jul 2007 11:41:10 -0400

Yes, we probably are guilty of "overloading" to a certain extent.  But no, 
I did not mean "any 4xx response with a RPH header is indicating the 
namespace usage that was in error."  It is only on a few specific error 
messages (based on the combination of 4xx value and the Reason Header) 
that we would be looking at the  RPH in order to log the errored RPH.  In 
all cases, the response (whether 4xx or other) would be treated "with 
priority according to the given namespace."

Janet

"DRAGE, Keith \(Keith\)" <[email-masked]> wrote on 07/22/2007 
08:54:45 AM:

> In RFC 4412 the semantics are to treat the request, the transaction 
> (and possibly the dialog) with priority according to the given 
namespace.
> 
> In James draft, the semantics would appear to be to treat the 
> response with priority according to the given namespace.
> 
> What you seem to be requesting here is that any 4xx response with a 
> RPH header is indicating the namespace usage that was in error.
> 

> 
> 
> 
> 
> 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. 
> 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”. 
> 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. 
> 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 
considered
> > Use [email-masked] for new developments on the application of 
> sip_______________________________________________