Subject: I-D ACTION:draft-polk-sip-mlpp-mapping-00.txt

From: "James M. Polk" <[email-masked]>
Date: Tue, 14 Mar 2000 17:39:01 -0600

All

Like so many others -- I'm letting you know of a new Draft
(draft-polk-sip-mlpp-mapping-00.txt) that addresses 'Multi-Level Precedence and
Preemption' in SIP environments. Specifically it provides the background of
existing Voice Networks that have specific requirements for differentiating
Classes of Voice traffic, not just Voice from all other types of traffic. This
I-D also recommends the ability to mandate the Header-Field 'Priority:' during
session set-up within a domain (analagous to how the existing MLPP  networks
function today), but with the obvious advantages of IP (vs. TDM). I know that
should get some attention by itself.

Your comments regarding this draft are greatly appreciated.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-polk-sip-mlpp-mapping-00.txt

Cheers! 
*************************************
"At the end of the day... the most committed win!"

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.5280
www.cisco.com

---

From: Ken Carlberg <[email-masked]>
Date: Thu, 16 Mar 2000 11:00:46 -0500

> (draft-polk-sip-mlpp-mapping-00.txt) that addresses 'Multi-Level 
> Precedence and Preemption' in SIP environments. Specifically it provides 
> the background of existing Voice Networks that have specific requirements 
> for differentiating Classes of Voice traffic, not just Voice from all other 
> types of traffic. This I-D also recommends the ability to mandate the 
> Header-Field 'Priority:' during session set-up within a domain (analagous 
> to how the existing MLPP  networks function today), but with the obvious 
> advantages of IP (vs. TDM). I know that should get some attention by itself.

Nice piece of work, however I have some concerns.  First, some background 
info.

Within the U.S., MLPP (ANSI-T1.619A) is only available on some military 
systems like Autovon.  It is _illegal_ to use it (i believe by mandate of 
FCC) in the U.S. PSTN because it involves *preemption* of calls.  I don't 
believe there is another country that allows its PSTN to preempt existing 
calls, though I would appreciate being corrected on this.  So I have some
concern about mandating SIP receivers to recognize MLPP if it can only
be used within closed-loop/non-public systems.  

On the other hand, the SS7 system of Sprint, MCI, and AT&T support 
ANSI-T1.631-1993 -- High Probability of Completion (HPC), in which 
emergency calls are marked accordingly and are queued to improve the
*probability* that their call will be completed.  I.e., no preemption
is generated by the emergency call.  

Part of the reason I bring this up is that if one is going to specify a 
more definitive description of priority for SIP, as well as the action to 
be taken, then I would prefer a document that included both preemptive and 
non-preemptive values.  I agree there is a need/marketplace for SIP-MLPP, 
but I'd prefer to see a more encompasing document.

I'm curious as to the position on this subject of the SIP chairs.  Does
the group advance a document that is not (and cannot be) supported by 
the PSTN?

cheers,

-ken

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 16 Mar 2000 22:27:35 -0600

Ken

Thanks for the comments.

To address your concern, I purposely included the following at the end of page
3 of the I-D:
"Further, this document recommends the ability to make the Header-Field
"Priority:" mandatory within an Administrator's Domain if they choose, for all
SIP based call signaling devices. "

Key phrase here is "...if they choose..."

and

Section 7 (page 7) states as the 4th bullet: 
    * MUST allow Administrator to make it mandatory for any SIP receiving
device
    to be MLPP-enabled (goal to have any non-MLPP device not able to engage in
    any call session - in a MLPP environment, this capability should be
    required of all devices by that Domain's Administrator) 
Here is the stated purpose and control a Domain Administrator has within that
Domain only. Not the PSTN. I guess I need to make that clearer in the next
version. I'll do this with no hesitation. 

I think I also address what you state:
"would prefer a document that included both preemptive and non-preemptive
values"

in two ways:

#1      By making this Preemptive Capability only "enabled" within a Domain if
the DA chooses to mandate this feature, if they don't (like the PSTN), there
isn't any preemption; and

#2      By stating that the default Header-Field "Priority:" value be "Routine"
-- thereby meaning most traffic even within a MLPP enabled SIP network will not
Preempt any other voice sessions -- as they would be of the same Precedence
Level, preventing Preemption.

Though again, I can make this clearer with the next I-D version.

James M. Polk