1 / 7

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

normaruiz
Download Presentation

Resource Priority

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. Resource Priority Henning Schulzrinne James Polk Columbia University/Cisco SIP WG (IETF 56, San Francisco, March 2003)

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

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

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

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

  6. 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:1-555-123-4567@ets-gateway.gov • 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

  7. Open issues • Mechanism alternatives? • Proxy-Require useful? (draft does not mention) • Likely candidate for capability credentials (once authenticated)

More Related