Subject: [Sipping] Re: [Sip] Comments on Resource Priority Header

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 07 Mar 2002 10:22:47 -0500

Moved to sipping, given the draft name.

> I point I think I was trying to make before is there can't be an "igonre"
> case. Since the point of the information is to tell equipment how to treat a
> call setup, in an environment/network that uses this capability, every call
> attempt must have a designated treatment, whether explicitly signaled, or a
> "default" when not present. An unknown value is equivalent to no value, which
> must default to something (unless the call attempt is rejected).

This is really a local policy decision. I see no reason to prescribe
this. For any SIP header or value, an implementation can decide that it
doesn't like the looks of it and ditch the request, just like you're
free to program your email filters any way you like. (Not that I would
recommend such a behavior, mind you, and there may well be local
non-discrimination and common carrier rules that prohibit this, but
that's not a protocol issue.)

A policy can decide that a missing header is legit or not; it can decide
that an invalid namespace or unknown header value simply yields default
treatment, lowest priority treatment or rejection or a visit by
counterintelligence.

> 
> Unknown namespace is another issue: I would expect the call to be rejected,
> since it is obviously someplace where it shouldn't be.

This is a policy decision; your and my policy may well differ and both
be "correct". (For example, it may not be good to reject such calls if
somebody plugs in a commercial system into a military network in an
emergency.)

> No, I don't think it is academic. It is worth considering. The result is that
> an added item would be needed in resource-priority to designate which level
> is the default for each namespace and to include the action it says above. I
> don't know that this would be a "well-defined" value. It would be different
> in each domain (namespace). For the dsn namespace, it would be "Routine"; for
> the q735 namespace, it would be "4".

I've added a sentence in each about the default value.

> Mike

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

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 07 Mar 2002 13:26:47 -0600

Mike

comments in-line

At 10:22 AM 3/7/2002 -0500, Henning Schulzrinne wrote:
>This is really a local policy decision.
<snip> 

This header is for Gateways and Proxy Servers, right? Within a single domain
each will have to support this header AND have a list of acceptable
namespace.value(s) with a vendor's choice of the way to treat each variable
[X.Y] (namespace being one, and the value being another). The vendor's
mechanisms for treatment should match the customer's expected domain treatment
for each [X.Y] in order for that equipment to be installed. 

>
>A policy can decide that a missing header is legit or not; 

see above

>it can decide
>be "correct". 
<snip>

If there were an adjacent SIP network to the DSN (a network you're familiar
with), connecting both IP networks with an established border, do you expect
that border to strip this Header if the namespace isn't recognized or reject
all INVITE's inbound to the DSN network that don't have this R-P Header with
DSN acceptable namespace.value fields? If there is no SLA between the two IP
domains to carry R-P treatments (which will likely be the case sooner or
later), an unknown namespace shouldn't cause the call to be rejected, but
should treat the call as if the header weren't there (in either/both
directions). Local policy in each domain will then dictate how that call should
be handled (probably to the default "dsn.routine" values).

I believe a similar situation occurs today between someone calling outside of
the DSN into the DSN; that outside in call doesn't have MLPP markings before
the DSN boundary, yet it's not rejected. This analogy should be possible in SIP
networks traversing domain boundaries too.

*************************************
"People generally demand more respect for their own rights than they are
willing to allow for others"

James M. Polk
Consulting Engineer
Office of the CTO

Cisco Systems
2200 East President George Bush Turnpike 
Richardson, TX  75082 USA
w) 972.813.5208
f)  972.813.5280
www.cisco.com

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 07 Mar 2002 19:12:08 -0500

> 
> This header is for Gateways and Proxy Servers, right? Within a single

SIP UAs (such as gateways) and proxies, yes.

> domain each will have to support this header AND have a list of
> acceptable namespace.value(s) with a vendor's choice of the way to
> treat each variable [X.Y] (namespace being one, and the value being
> another). The vendor's mechanisms for treatment should match the
> customer's expected domain treatment for each [X.Y] in order for that
> equipment to be installed.

True, but beyond the scope of the protocol (as opposed to a network RFP)
specification. This also works if only some systems support it, as the
non-supporting systems will just ignore the header field.

> If there were an adjacent SIP network to the DSN (a network you're
> familiar with), connecting both IP networks with an established
> border, do you expect that border to strip this Header if the
> namespace isn't recognized or reject all INVITE's inbound to the DSN
> network that don't have this R-P Header with DSN acceptable
> namespace.value fields? If there is no SLA between the two IP domains
> to carry R-P treatments (which will likely be the case sooner or
> later), an unknown namespace shouldn't cause the call to be rejected,
> but should treat the call as if the header weren't there (in
> either/both directions). Local policy in each domain will then dictate
> how that call should be handled (probably to the default "dsn.routine"
> values).

Indeed, I think rejecting calls due to a missing R-P header would in
almost all cases be an exceedingly bad idea, in terms of system
robustness. After all, you want calls to get through, even if the army
officer has to borrow a "civilian" SIP phone.

> 
> I believe a similar situation occurs today between someone calling
> outside of the DSN into the DSN; that outside in call doesn't have
> MLPP markings before the DSN boundary, yet it's not rejected. This
> analogy should be possible in SIP networks traversing domain
> boundaries too.

Yet another motivation not to drop such calls.