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

From: [email-masked]
Date: Fri, 8 Mar 2002 08:38:13 EST

In a message dated 3/7/02 2:29:04 PM Eastern Standard Time, [email-masked] 
writes:

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

I guess we have to consider each case:

1. If another network were carrying traffic for the DSN in accordance with an 
SLA, then I would expect it to understand the "dsn" namespace, otherwise it 
could not provide the required functionality.
2. If a call comes from outside the DSN, and there is no way to indicate the 
priority value, it defaults to lowest at the boundary (similar to the PSTN to 
DSN today). A call without an R-P header from another domain gets one when it 
enters the DSN.
3. If a call comes from another IP domain with an R-P header into the DSN and 
the proper interworking arrangements have been made, there will have to be a 
"gateway" function that translates from some other domain.value to the 
dsn.value. The gateway at the border "undestands" both namespaces. It 
probably does other interworking functions as well.
4. Considering a call from a DSN, going through some unknown domain, to get 
to another DSN segment, is the only difficult part. The R-P header should be 
transferred transparently without rejecting the call. So yes, its really a 
policy decision and the R-P header document doesn't need to say one way or 
the other how to handle "unknown" namespaces. But I could argue that every 
network would know "dsn" if it is defined in the document, just like it would 
know "q735".

Mike