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
