1 / 9

SIP Extension for MLPP: Multilevel Precedence and Preemption

This draft outlines an extension to SIP for MLPP interoperability, ensuring priority ranking for call flows within a network. The document addresses the necessity and implementation of the MLPP standards within SIP-based voice signaling topologies.

hernandezn
Télécharger la présentation

SIP Extension for MLPP: Multilevel Precedence and Preemption

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. 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

  3. 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

  4. 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

  5. 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"

  6. 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

  7. 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"

  8. *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)

  9. 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

More Related