Re: [Sip] -resource-priority-05.txt: Comments and Recommendations (1)

Corey,

Thanks for the great analysis of the situation and the suggestions. I agree 
almost completely with what you suggested. I'll follow this up with a few minor 
points on your suggestions. But first, some comments on your questions, which 
might help understand why this approach was taken.

In a message dated 11/11/2004 6:12:39 PM Eastern Standard Time, 
coreya@nortelnetworks.com writes:

> 1. Why support multiple namespace/priority (n-p) values in a single 
> message, in one or more R-P headers?  And if supported, should not the 
> n-p values in the message equate to the same priority level (for 
> example, dsn.flash and q735.1 would be equal)?  Would it not be better 
> to support only one n-p value per message, and recommend that a 
> proxy/gateway between networks supporting two different namespaces 
> handle mapping n-p values?
> ---- There may be/are networks which would support multiple levels.  The 
> draft is not dictating that there must be multiple levels.
> ---- As for having the n-p levels be "equal", James cited a GETS call 
> with a specific precedence which becomes a Routine call on the DSN.
> ---- Having a proxy/gateway mapped between namespaces is an viable 
> alternative.
> 

While it is a little hard to describe specific cases for the use of multiple 
namespaces, I believe it could be used, such as a GETS call originated in a 
military network that normally uses only the dsn namespace. The caller, knowing 
that the call will likely go outside the dsn, might be able to specify both 
dsn=flash and ETS=3. It is not possible to say that they "equal", since they are 
two separately defined lists of priorities which have no direct relationship. 
In one application, only the dsn namespace would have an effect while the 
call remains within the private network (DOD) for which it was defined. When the 
call gets to a PSTN gateway to jump into the "public" network, the dsn 
namespace/priority is discarded, since the "public" network does not support it. At 
the GW, the ETS namespace/priority is converted to the appropriate PSTN 
signaling which that netwrok supports. Note that in this case, the PSTN signaling 
does not have any further signaling of this value beyond the initial call setup 
message, which is why the SIP signaling would not include this R-P header in 
anything beyond the INVITE.

When an ETS call from the public network enters the dsn, it could be mapped 
to Routine or to some higher priority level if the PSTN signaling provided that 
information. That will be determine by the administrator of the network and 
what the GW is told to do. It certainly can't be defined in the R-P header 
draft.

Another application is a gateway between two networks which each use the R-P 
header but with different definitions. Lets say between the US DOD network 
with 5 values and another country's military network when that other country uses 
only 3 levels. The GW must map between the two sets according to a mutually 
agreed mapping. In each network, only one R-P header is used.

I believe it was agreed long ago that the R-P header draft should not try to 
define the interoperation/mapping between different namespaces. I think this 
approach should remain, since any attempt to define relationships would be 
overly complex and may conflict with what network operators want to do.

The first example above, with two namespaces being carried, is the reason why 
the required mode of operation in the dsn is that unknown namespaces are 
simply ignored and passed on. Known namespaces with unknown priorities need to be 
treated as errors, but not necessarily by failing a call.

Mike Pierce
Artel