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

["Nguyen, An" <[e-mail]>]

Mike,
 
I agree with you that it would be overly complex to address all possible
mappings between namespaces in this draft. Mappings between namespaces
issues should be specifically addressed in different documents. Can we just
add a sentence to the draft saying mapping between namespaces is out of
scope and it should be addressed separately? Otherwise, we would never get
this draft published.
 
An

[Nguyen, An]  From: [e-mail] [mailto:[e-mail]]
Sent: Friday, November 12, 2004 9:54 AM
To: [e-mail]; [e-mail]
Subject: 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,
[e-mail] 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 

_______________________________________________
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