Subject: Prioritization limitation question

From: "James M. Polk" <[email-masked]>
Date: Tue, 04 Jan 2000 18:06:31 -0600

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.

Comments/clarifications are welcome, thank you.

_______________________________________________________ 
A sobering reflection upon this century's greatest accomplishments and
discoveries:
"There is no keystroke that rewrites racism... nor is there any software that
takes care of Mother Earth"

James M. Polk 
Sr. Product Manager, Multiservice Architecture and Standards
Enterprise Voice Business Unit
Cisco Systems
Dallas, Texas
w) 972.813.5208
f)  972.813.5199
www.cisco.com

---

From: "Adam B. Roach" <[email-masked]>
Date: Tue, 4 Jan 2000 19:35:00 -0600 (CST)

>current US Government/Military Regulations I really don't want to ask them to

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

---

From: Bob Bell <[email-masked]>
Date: Tue, 04 Jan 2000 19:30:16 -0700

Adam -

Comments imbedded.

 >>>Bob
In a totally IP environment, there would be no PSTN gateways. The 
precedence values would be used to determine the order in which packets 
would be dropped at congestion points so as to allow the higher priority 
"calls" to be undegraded under congested conditions. For the enforcement, 
perhaps this service requires the use of a "trusted" proxy to authenticate 
a user request for a high priority call.
<<<Bob

 >>>Bob
Mapping the Flash and Flash Override into the same value basically 
eliminates the differences between them. There is a real, tactical 
difference for the distinction.
<<<Bob

 >>>Bob
Perhaps using only a keyword followed by a numeric value could be used.
<<<Bob

Bob Bell
Cisco Systems Inc.
801-294-3034(v)
801-294-3023(f)

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 07 Jan 2000 10:55:49 -0500

While the conclusion of this discussion appears to be that a more
elaborate mechanism is required to serve this purpose, I wonder if it
would be helpful to allow extensions to priority-value in the SIP spec,
with the obvious caveat that an application may simply ignore new
values, although a reasonable application may decide to render the token
as-is, without interpretation. If there are local conventions that
encompass the existing priorities, this would seem preferable to forcing
people to use 

X-Priority: local-label

and the normal Priority otherwise. I18N, among other reasons, argues
against allowing this.

James M. Polk wrote:
> 
> 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:
> 
> But looking at SIP grammar/syntax, it only stipulates 4 levels of
> priority as the following:
> 
> 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.
> 
>     "There is no keystroke that rewrites racism... nor is there any
>                software that takes care of Mother Earth"
> 
> James M. Polk