Technical Summary
The resource priority specification defines two new SIP header fields for
call priority in the SIP user agents, namely "Resource-Priority" and
"Accept-Resource-Priority". The "Resource-Priority" header field can
influence call handling by SIP user agents, such as telephone gateways
and IP telephones, and SIP proxies.
The specification extending the SIP reason header to add preemption
is a companion to the above specification. When a call is ended in
a SIP user agent due to a resource management choice, the extensions
in this specification allow communicating specific causes.
Working Group Summary
The working group had a fair amount of difficulty getting the
details of this to its liking, because it had to accomodate
goals of groups with current requirements, while still leaving
room for generality. The solution of independent namespaces
and reuse of the SIP authorization and authentication mechanisms
was reviewed and much discussed till consensus was reached.
The specification received detailed word-by-word review and
comment until consensus was reached, and it required intensive
efforts by the chairs and members of the working group, as well
as the editor and the responsible AD.
Protocol Quality
These headers have been implemented by at least one vendor for
several namespaces. In some cases, implemented systems associate
router resource management with the RP in SIP, somewhat ahead of
the scope of IETF design.
Note to the RFC Editor
draft-ietf-sip-resource-priority:
OLD:
e.g., in an ISUP IAM message originated by the gateway.
NEW:
e.g., on an ISUP (ISDN User Part) IAM (Initial Address Message)
originated by a SIP gateway with the PSTN.
OLD:
There should not be a unique namespace for different jurisdictions.
This will greatly increase interoperability and reduce development
time, and probably reduce future confusion if there is ever a need
to map one namespace to another in an interworking function.
NEW:
There should be a single namespace for all jurisdictions. This will
greatly increase interoperability and reduce development time, and
probably reduce future confusion if there is ever a need to map one
namespace to another in an interworking function.
[Only the first sentence is changed, for readability]
draft-ietf-sipping-reason-header-for-preemption:
Introduction
OLD:
What is proposed here is extending SIP
NEW:
What is proposed here is extending SIP [2]
[add the citation; it's in the Normative References already]