SIP Extension for Multilevel Precedence and Preemption (MLPP) draft-polk-sip-mlpp-mapping-01.txt James M. Polk March 23rd, 2001

Background on MLPP Precedence: MLPP stipulates a relative priority ranking order (5 levels) of *all* Call flows from the source device (calling) to the Called device Preemption: Once it has been determined anywhere within the MLPP network that there is a bottleneck or interface saturation preventing a call from completion, the Precedence level is compared to all other calls at that saturation point, and if this new call is of a higher Priority, lower Priority call(s) are discarded/preempted to seize those necessary resources to complete this higher Priority call

Basic premise of I-D This I-D proposes an extension to SIP for MLPP interoperability Should be in the SIP Core because of its (desired) Standards Track theme, with semantics surrounded for necessity within the I-D (hence some confusion) Should not take too much effort from either group and should be parallel effort due to customer demands This document will further include semantics to evolve and/or replace existing TDM-based MLPP network topologies with SIP-based Voice Signaling topologies with no loss of capability or functionality. Not seen as a PSTN replacement, but as a customer-driven requirement for IP to penetrate certain markets which have this environment now Seen as a parallel effort to 2543bis where not everyone is obligated to implement these features, but those that choose to, can Mentions additional environments that could enable this, or a subset of this feature-set

Updates from the -00 version in Adelaide Changed the name and scope of this draft to "SIP Extension for MLPP” Hinted at the potential synergies with both IEPS and GETS efforts Suggested the use of a sub-set of the MLPP effort outside the strict environments that still require all of MLPP's features such as Hospitals and Financial Institutions Added section 9.0 "Unknowns" to this version to attempt to bring out the known differences in the way in which Voice networks operated 'then' verses how they could now and in the near future; Mentioned it not being limited to Voice, but that Voice is easily first for implementation

RFC2543 Header-Field “Priority:” SIP defines the Priority request-header field and its possible non-mandatory values in section "6.25 Priority" as the following (exact text from page 40 of RFC2543): " Priority = "Priority" ":" priority-value priority-value = "emergency" | "urgent" | "normal" | "non-urgent"

SIP (2543bis) Header-Field “Priority:” 2543bis changed the Priority request-header field and its possible non-mandatory values in section "6.31 Priority" as the following (exact text from page 66&67 of RFC2543): Priority = "Priority” ":" priority-value priority-value = "emergency" | "urgent" | "normal" | "non-urgent" | other-priority other-priority = token with the semantics being close to the same, with no explanation of the “other-priority = token” addition

Proposed SIP Header-Field “MLPP-Enabled:” Specifically this I-D creates the *New* Request Header-Field “MLPP-Enabled” with the semantics explained within the I-D MLPP-Enabled = "MLPP-Enabled" ":" MLPP-priority-value MLPP-priority-value = "Flash Override" | "Flash" | "Immediate" | "Priority" | "Routine"

*Unknowns* needing discussion still 3 examples here: Conferencing - problem: a number of people on a conference bridge of any sort, a call clearing event occurs to one of the people on the bridge, how noticeable is that to the others on the bridge? Do they hear the tone? Doesn’t the System need to be signaled which person is going/gone away (maybe to have Person’s name announced that is preempted; is this the same for midstream preemption)? ?? Version ID - problem: section 4.3.1 of the 2543bis I-D states the requirement to have the SIP version number included in the header (I don’t know what this should be here; e.g. SIP/2.0a, or SIP/2.1 or what….) Speaker - problem: ANSI spec states that if the called party refuses to acknowledge and ‘switch-over’ to the new inbound call, the speaker on the phone is enabled to complete the call (not sure we still want this feature)

Summary recommendations of I-D Continue as SIP WG effort parallel to the 2543bis effort Creating within this effort a new Request Header-field - which is purposely not required by all to implement Solve and update original MLPP Spec for a Managed-IP capable Network (from “Unknowns” section within I-D) Synergize with overall MLPP Arch into IP efforts