Transcript SIP Extension for Multilevel Precedence and Preemption (MLPP) draft-polk-sip-mlpp-mapping-01.txt

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 HeaderField “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