Subject: RE: Prioritization limitation question

From: "James M. Polk" <[email-masked]>
Date: Wed, 05 Jan 2000 11:05:55 -0600

Adam

Brian states the conclusions I wish to accomplish. There are quite a few IP
only Voice environments being planned and implemented -- with PSTN access in
and out very controlled or non-existent. In this case, having the 5 priorities 
explicitly allows SIP into environments requiring MLPP. Not having all 5
completely eliminates SIP -- as "Flash Override" is a very required
feature/application. I do understand why there needs to be a great amount of
individuality within the development of a protocol with specific
interoperability interfacing requirements defined and limited to not overwhelm
the new protocol's intent. But with inclusion of this 5th priority, virtually
all MLPP implementations will at that point include SIP as viable; likely not
before this time though.

I'm just suggesting the addition of a single value within a defined
variable-set. I'm not suggesting a new variable, or taking the protocol in a
new direction.

At 08:16 AM 1/5/2000 -0500, Rosen, Brian wrote:
>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
>> 
>
>

_______________________________________________________ 
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: Wed, 5 Jan 2000 11:45:17 -0600 (CST)

>explicitly allows SIP into environments requiring MLPP. 

I mistook your problem to be a PSTN interworking one; sorry.

>Not having all 5

The SIP Priority: header does not currently provide anything like MLPP. 
It is not specified that it is to be used for call pre-emption. I beleive 
you'll find that most clients use it to render the incoming call (e.g. 
making the screen flash, or making the phone ring particularly urgently), 
if at all.

Extending the number of priorites will merely change the syntax without
adding the semantics you desire.

I propose that, if you need this functionality, you write up an
internet draft specifying how to negotiate between clients that
MLPP is available, the exact behavior expected, and the method
of conveying MLPP priority levels. For simplicity of mapping,
I'd take a look at ITU Q.733.3 and Q.955.3. As an overview,
I'd include a header (similar to the CCBS diagnostic) in the
486, 600, and 603 (and possibly 182) responses to INVITE which 
indicates that the client is CCBS-capable. The originating client 
would then re-launch the INVITE with some indication that it is 
invoking the CCBS service, along with the priority of the incoming 
call.

But merely extending the enumeration of values allowed in the
Priority: header is *wildly* insufficient for what you require.

-- 
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: Jonathan Rosenberg <[email-masked]>
Date: Wed, 05 Jan 2000 13:41:43 -0500

I agree 100% with Adam here. 

The semantics of Priority are not what you want. If this feature is
critical to your deployment, please do write up a draft with a proposal
on how it works. 

-Jonathan R.

-- 
Jonathan D. Rosenberg                       200 Executive Drive
Chief Scientist                             Suite 120 
dynamicsoft                                 West Orange, NJ 07052
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com