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

[Janet P Gunn <[e-mail]>]

Multiple namespaces.

It is highly likely that an NS/EP (National Security/Emergency
Preparedness) call will carry both the ets and wps namespaces.  This is
because you can not determine ahead of time whether the call will progress
to a WIRELINE gateway (in which case the mapping associated with the ets
namespace is needed) or to a WIRELESS gateway (in which case the mapping
associated with the wps namespace is needed).  We initially tired to define
a single namespace that would work for both situations, but were unable to,
given the constraints on namespace structure.

There is also the POSSIBILITY of a call (within one of the military
networks) carrying both the ets namespace and one of the MLPP based
namespaces (especially a call that is expected to terminate on the Public
network where the MLPP based namespace could be dropped while the ets
namespace is retained).  But this situation is still hypothetical.

Janet

----------------------------------------------------------------------------------------

This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery. NOTE: Regardless of content, this e-mail shall not operate to
bind CSC to any order or other contract unless pursuant to explicit written
agreement or government initiative expressly permitting the use of e-mail
for such purpose.
----------------------------------------------------------------------------------------




                                                                                                                               
                      Mpierce1                                                                                                 
                      @aol.com                 To:      [e-mail], [e-mail]                                
                      Sent by:                 cc:                                                                             
                      sip-bounces              Subject: Re: [Sip] -resource-priority-05.txt: Comments and Recommendations (1)  
                                                                                                                               
                                                                                                                               
                      11/12/2004 09:53                                                                                         
                      AM                                                                                                       
                                                                                                                               
                                                                                                                               




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




_______________________________________________
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