RE: [Sip] Strict, Semi-Strict and Loose mode in RPH - not a good fit for ets and wps

["James M. Polk" <[e-mail]>]

comments in-line below

At 11:47 PM 11/6/2004 -0500, Janet P Gunn wrote:
>From: "Ken Carlberg"
> > Unfortunately, this  (semi-strict) is NOT the behavior desired for the
>ets
> > and wps namespaces.

Janet - I like your list. It is quite valuable because it gives very good 
points for discussion.  As Ken has stated already, a couple of issues from 
your list (I believe) are already addressed within this current version.

> >
> > The behavior desired for the ets and wps namespaces are
> > 1 RPH is optional (semi-strict and loose)

got it

> > 2 SIP element ignores a namespace it does not recognize (loose)

To this, remember the ID does not say to "fail" the call, just that 
Request. This is one way to inform the calling UAC to know it included a 
namespace or priority value that was not recognizable (meaning not 
ets.0/1/2/3/4 or wps.0/1/2/3/4).

There is no way to inform the UAC of this issue within the SIP Request 
(with the bad namespace.priority-value) without failing the request. 
Meaning, there can be no preferential treatment without the sending element 
being told so. SIP doesn't have a "pass, but this wasn't a good choice" 
provisional response like other protocols.

To the user, they might not notice several SIP Request failures, the person 
is merely waiting for the call to be set up (still under a second).


>I would prefer a strict or semi-strict mode because these provide feedback
>in
>case: a) a misconfigured UA sends the wrong namespace.priority, and/or b)
>initial selection of a server/proxy that does not support the desired
>namespace.  The former is quite possible given an ability (and possibly,
>necessity) of the user to configure their own device to support the given
>namespace.value combination.
>
>[JG] Before posting this, I checked with Dr. Fonash (head of NCS, which
>"owns" GETS and WPS).  He was very clear about wanting "If the SIP element
>does not recognize the namespace (wps or ets) it should pass it on without
>acting on it, rather than rejecting it."

again - this doesn't mean the call attempt has failed and the user needs to 
dial again  - which is one way to read what you wrote. The text in this doc 
clearly needs to not call for failing the call in the ets/wps use-case 
because of a bad namespace or priority-value.

Ironically this is where the A-R-P header would be handy, if it didn't 
reveal to everyone who purposely or inadvertently included a bad or unknown 
RP header.


> > 3 The content of the error message should not reveal (to the end user)
>the
> > valid values for that namespace (strict)
>
>section 4.5 of the drafts states:
>
>    If the UAS understands the resource value, but refuses to honor the
>    request with elevated priority for this particular user, it returns
>    the 403 (Forbidden) response code.  It MAY include the list of
>    resource values that the user is allowed to use in the
>    'Accept-Resource-Priority' response header field.
>
>The "MAY" is the critical term.

I feel this MAY answers your concern - as Ken points out. You may mandate 
vendor's equipment be able to be configured to *not* send the A-R-P in this 
case. That is a useful marketing requirement.

>My understanding would be that this
>decision
>is a local policy issue.  Outside of that I personally don't see a problem
>with
>providing "hints" of accepted values under the context that they can only
>acted
>upon by authorized users.  Informing the user of the acceptable set of
>priorities does not bypass or circumvent the need for proper authentication
>credentials.
>
>[JG]I am not as concerned about this case (valid namespace.valid value -
>just not authorized).

I would think this is of concern - as anyone (literally) can be in this group.

>I am more concerned about the  error message when
>the namespace, or value are not recognized.  But if ets and wps operate
>with the behavior "SIP element ignores a namespace it does not recognize",
>half of that goes away.
>
>[JG]I am still not entirely sure about the desired behavior for the other
>half- (valid namespace.invalid value).  But I suspect that it would be
>better to
>a) Reject the message
>b) NOT return the list of valid values.

I consider this to be the case every time a message is not accurate, but 
want to discuss it with you to tease out any "ships in the night" scenarios 
we're missing


>[JG] I do not think that the full loose mode as defined (if the SIP element
>gets (valid namespace.invalid value) it processes the message as if it had
>no RPH) is the right approach.

nor do I

>I think these messages should be rejected,
>and get an error message.

I agree


>[JG]But I am open to other approaches.

we have time to talk



> > 4 SIP messages that include the RPH with the ets or wps namespaces should
> > include the authorization header (or equivalent mechanism) (semi-strict)

this should be self evident in public networks....

> > 5 Precedence (queueing) is generally the means of providing priority, but
> > exemption from network management controls, for instance call admission
> > within an IP domain, when a "regular" call would not be admitted, is also
> > needed.  Pre-emption is not used.  (semi-strict "plus more")

I do not understand what you have written above, can you rephrase please?


>the "plus more" would seem to be a product of local policy
>
>[JG] Agree.  While it doesn't explicitly state it, the document leads you
>to believe that queueing is the only behavior permitted in semi-strict
>mode.

This is stated a couple of times in the doc, including in the IANA section 
in the table


> > 6 There is no a priori requirement to use, or not use, the "Require"
> > header field.
>
>isn't this addressed in section 4.3.2 below?  or am I missing something?
>
>    If the request includes a 'Require' header field with the
>    'Resource-Priority' option tag, a UAS MUST follow the strict or
>    semi-strict mode rules, otherwise UAS and proxies MUST operate in
>    loose mode.
>
>
>[JG]I guess I wasn't clear.   I simply meant that there wasn't a concern
>about the "require" header itself, independent of the
>strict/semi-strict/loose mode.  Once that is "right", the approach to the
>"require" header will follow

hmmmm

The "Require" header is to mandate that SIP Responses use the header as is 
(copied from request to response without change). If ever there is a case 
needed in which preferential treatment is within the processing of SIP 
elements (such as Proxies), knowing there will always be more than one SIP 
message necessary to complete a transaction - meaning both Request and 
Response will need to be RP marked for preferential treatment for the 
session/transaction to be given priority over other transactions.

To put this simply, if the INVITE is consistently moved to the head of the 
line in all SIP elements between UAs 1 & 2, and the 200 OK is 
slowed/delayed or lost in the congestion of one or more Proxies, the call 
will not be established. In this case, the INVITE, 200 OK and ACK will need 
the RP indication to gain the preferential treatment of that domain; and 
any other messages within that transaction will require it too (such as 
183, PRACK and UPDATE messages if RFC 3312 Preconditions were to be 
required to set up, say RSVP between endpoints).


>-ken


cheers,
James

                                *******************
                 Truth is not to be argued... it is to be presented


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