Transcript Resource Priority

Resource Priority
Henning Schulzrinne
James Polk
Columbia University/Cisco
SIP WG (IETF 56, San Francisco, March 2003)
Background
• Basic goal: higher probability of call completion when
PSTN is overloaded during emergencies (ETS)
• Discussion moved from SIP/PING to IEPREP
• resulting in requirements document RFC 3487
Requirements for Resource Priority Mechanisms for the
Session Initiation Protocol (SIP)
• Does not describe a mechanism, just security and
operational requirements
• Not a complete solution; does not address:
– IP network congestion
– QOS routing
• Primarily motivated to support hybrid SIP-PSTN
scenarios with scarce PSTN trunk circuits
Some key requirements
•
•
Not specific to one country or scheme
Independent of network architecture
– assume that many network may not support service
– does not interfere with non-ETS-aware network entities
•
•
•
•
•
•
•
•
•
•
•
Invisible to IP layer
Support existing ETS schemes
No loss of information
Extensibility
Separation of policy and mechanism
Method-neutral
Address-neutral
Identity-independent
Independent of network location
Support discovery and testing
Proxy-visible (call routing)
Design options
• SIP options: URI scheme, URI parameter,
header field, request method, caller
preference, body content
• non-SIP options: some kind of IP or
separate-protocol indication  not likely to
satisfy transparency
• SIP: URI, method, cp, body all violate at
least one requirement (see draft appendix)
• leaves header field as only option
Summary of mechanism
• Resource-Priority: label
• Accept-Resource-Priority indicates capabilities
after failure (new status: 417) or as OPTIONS
response
• Non-aware proxies and UAS ignore indication,
but can be discovered via OPTIONS
• Generally, don’t want to restrict choices, but can
use Require: Resource-Priority to force failure
(e.g., to remove branches that queue)
Transition
• Initially, most of SIP entities won’t know about this
• Thus, “tel” routing may go to RP-unaware gateway
• Short-term: Force routing to appropriate gateway:
– sip:[email protected]
– usual SIP source routing
– same gateway likely to support both ETS and regular calls
• Mid-term: most carriers support ETS (like GETS)
– proxies use TRIP or hard-coded routes to find right gateway
– allows larger choice of gateways
• Long-term: international may never work
– ok for typical traveling-abroad-official model as long as foreign
network does not violate SIP spec (by stripping header)
– can embed in RFC 3420 message/sipfrag to ensure end-system
treatment
Open issues
• Mechanism alternatives?
• Proxy-Require useful? (draft does not
mention)
• Likely candidate for capability credentials
(once authenticated)