Subject: RE: Prioritization limitation question

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 5 Jan 2000 08:16:46 -0500

What if you were trying to implement MLPP where the individual
stations were trusted, in particular, for a customer like the
government?  You are saying SIP cannot be used for a government application,
which typically require MLPP.

There isn't any reason NOT to use the existing convention; they
do everything the current SIP priority does.  If you make them
backwards compatible, you lose nothing, you gain compatibility.

Brian
------------
Brian Rosen, Principal Engineer
Marconi (Formerly FORE Systems)
1000 FORE Drive, Warrendale, PA 15086
(724) 742-6826  mailto:[email-masked] 

> -----Original Message-----
> From: Adam B. Roach [mailto:[email-masked]]
> Sent: Tuesday, January 04, 2000 8:35 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: Prioritization limitation question
> 
> 
> >Anyone/everyone
> >
> >Reading the ANSI document T1.619-1992 a colleague pointed 
> out to me, I came
> >across its MLPP Prioritization requirements as being the following:
> >
> >1)      0       Flash Override (Highest)
> >2)      1       Flash
> >3)      2       Immediate
> >4)      3       Priority
> >5)      4       Routine  (Lowest)
> 
> >But looking at SIP grammar/syntax, it only stipulates 4 
> levels of priority as
> >the following:
> >
> >priority-value = "emergency" | "urgent" | "normal" | "non-urgent" 
> >
> >Question: Has there been any discussion (which I haven't 
> found yet) on matching
> >these two specifications? And for clarification, I strongly 
> prefer SIP moving
> >up to having 5 levels instead of ANSI moving down to 4 
> levels in order to meet
> >current US Government/Military Regulations I really don't 
> want to ask them to
> >change.
> 
> No, this has not been discussed; however, consider that SIP 
> clients are
> not to be treated as trusted nodes (since users have direct 
> control over
> them). If some PSTN gateway were taking my client's word for it, I'd
> hack mine to send out whatever would generate "flash override" as the 
> priority whenever I couldn't get through. Not the sort of thing you 
> really want me to be able to do, I imagine.
> 
> So, given that you will only trust this information when it comes from
> another PSTN gateway, I would propose that, instead of trying to mold
> the SIP architecture to fit ITU and ANSI documents, it would seem to
> make sense to tunnel your ISUP and TCAP messages end-to-end (which
> you're obviously *already* doing, since you can't activate CCBS 
> without receiving an appropriate indicator in the diagnostic field of
> the cause parameter of a REL message, right?).
> 
> It wouldn't hurt to map MLPP priorities down into the SIP priorities, 
> just in case you *do* terminate on a native SIP client (flash 
> override 
> and flash translate to emergency; immediate and priority translate to 
> urgent; routine translates to normal) -- but I wouldn't 
> actually trust 
> these going back *into* the PSTN. The reason for this is 
> that, in SIP, 
> the priorities are a heuristic, meant more for conveying 
> information to 
> the user. In the PSTN, the MLPP priorities are absolutes, meant for
> conveying information to the network.
> 
> Finally, you'll note that there are actually sixteen 
> priorities available
> for MLPP (even though only five are defined by the ITU and 
> ANSI). It's 
> possible that current proprietary or future ISUP protocols 
> will define 
> further priorities. It would, of course, be absurd to come up 
> with sixteen 
> SIP priority names to accomodate this possible eventuality, 
> and the prospect 
> of having numeric priorities for SIP has already been 
> discussed and soundly 
> rejected (if my occasonally fuzzy memory serves me well today).
> 
> --
> Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. 
> Arapaho, MS L-04
> [email-masked]   | Fax: +1 972 669 0154 | 
> Richardson, TX 75081 USA
>