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 PROTECTED]> wrote on 07/22/2007 08:54:45 AM: > 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 PROTECTED] > Sent: Monday, June 25, 2007 8:02 PM > To: James M. Polk > Cc: [email protected] > 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 PROTECTED]> wrote on 06/16/2007 05:13:37 PM: > > > 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 PROTECTED] for questions on current sip > > Use [EMAIL PROTECTED] for new developments on the application of > sip_______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use [EMAIL PROTECTED] for questions on current sip > Use [EMAIL PROTECTED] for new developments on the application of sip
_______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
