1 / 12

Alert-Info URNs for the Session Initiation Protocol (SIP)

Alert-Info URNs for the Session Initiation Protocol (SIP). draft-liess-dispatch-alert-info-urns-02 L. Liess, R. Jesske, D. Alexeitsev (Deutsche Telekom) A. Johnston, A. Siddiqui (Avaya) IETF 78 – Maastricht, Netherlands July 2010. Status and Goals. Status:

ashton-larsen
Download Presentation

Alert-Info URNs for the Session Initiation Protocol (SIP)

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. Alert-Info URNs for the Session Initiation Protocol (SIP) draft-liess-dispatch-alert-info-urns-02 L. Liess, R. Jesske, D. Alexeitsev (Deutsche Telekom) A. Johnston, A. Siddiqui (Avaya) IETF 78 – Maastricht, Netherlands July 2010 IETF-78, July 2010

  2. Status and Goals Status: Major changes since the 01 version, including document structure and syntax definition. Goals: • Discuss the current version and open issues. • Consolidate the sections Definition, Requirements, Use Cases, ABNF-syntax, where we seem to have a „high level“ consensus • Clarify what to do with the „180 vs. 18x“ issue • Discuss/ solve major open issues (single vs. multiple URNs, value definitions, combination rules, extensibility) IETF-78, July 2010

  3. #1 Alert-Info URN Definition and Purpose • Initial definition and purpose: semantic identifiers instead of particular rendering in the Alert-Info header. • Long discussion in the past if / how we should allow non-semantic identifiers, e.g. „short“. • Ad-hoc agreement on „semantic indication and names for rendering characteristics”(based on Dale’s proposal) IETF-78, July 2010

  4. #2 180 vs. 18x responses • The RFC 3261 allows the Alert-Info header in 180 responses. • Ad-hoc agreement to allow it in provisional responses excepting 100. • Change to RFC 3261. Gonzalo will check if this change is minor enough so it can be done in this draft. IETF-78, July 2010

  5. #3 Requirements • Dale‘s requirements added in version 02. • More work is needed on the requirements text to make the requirements more clear and non-redundant. • Any other key issues on the Requirements section? IETF-78, July 2010

  6. #4 Use Cases • A.S0014 defines: • 1. Normal Alerting • 2. Inter-group Alerting • 3. Special/Priority Alerting • 4. Ping Ring (abbreviated alert) • 5. Abbreviated intercept • 6. Abbreviated reorder • Additionally, A.S0014 allows indication of pitch (high, normal, low) as part of the ringtone designation. • TIA/EIA values: • 1. Long (Normal) • 2. Short-Short • 3. Short-Short-Long • 4. Short-Short2 • 5. Short-Long-Short • 6. Short-Short-Short-Short • 7. PBX Long (Normal) • 8. PBX Short-Short • 9. PBX Short-Short-Long • 10. PBX Short-Long-Short • 11. PBX Short-Short-Short-Short • Adam‘s Use Cases (TIA/EIA-41-D and 3GPP2 A.S0014) • Ad-hoc agreement to add them to the Use Case section. • Need to clarify the meaning for some of them. • Any other issues on the Use Cases section? IETF-78, July 2010

  7. # 5 ABNF-Syntax • Ad-hoc agreed to get rid of top-level indication and sub-indication alert-category = name alert-indication= name *("." name) name = let-dig [ *25let-dig-hyp let-dig ] Instead of alert-category = let-dig [ *25let-dig-hyp let-dig ] alert-indication= top-level *("." sub-indication) top-level = let-dig [ *25let-dig-hyp let-dig ] sub-indication = let-dig [ *let-dig-hyp let-dig ] ”top-level” and ”sub-indication” no needed any longer. IETF-78, July 2010

  8. #6 Key Issue: Single URN vs. multiple URNs • Single URN • We had it in the initial draft in BLISS • Concerns that we have to register a very high number of combinations with IANA • URNs can be interpreted individually, and the Alert-Info list is just a list of URNs, of which the UA can use any that it understands. • Multiple URNs • The set of URNs is small and fixed • Modifications through intermediaries may be easier • Renderer may want to combine URNs inserted by two independent specifiers, e.g. „delayed“, inserted by the PBX, and „italian“, inserted by the UA. • Proxy may want to discard „high priority“ and leave „italian“ (both inserted by the UA). IETF-78, July 2010

  9. #7 A-I URN Values and extensibility rules • Ad-hoc agreement on Paul‘s proposal as starting point • urn:alert:source: • unclassified (default) • internal • external • friend • family • private.<private-name> • urn:alert:priority: • normal (default) • low • high • private.<private-name> • urn:alert:duration: • normal (default) • short (or "zip") • long • private.<private-name> • urn:alert:delay: • none (default) • yes • private.<private-name> • urn:alert:service: • normal (default) • call-waiting • forward • recall.callback • recall.hold • recall.transfer • private.<private-name> • urn:alert:locale: • default (default) • country.<ISO 3166-1 country code> • private.<private-name> IETF-78, July 2010

  10. #8 Combination and Priority Rules • Depend on how “single or multiple URNs” issue is solved. • Rules proposals so far: • Categories are orthogonal • One instance for each alert-category. • Syntax: Multiple URNs separated by “,” • Priority= order IETF-78, July 2010

  11. #9 Extensibility Rules So far three extension mechanisms recognized: • Allow further dimensions created. • Allow sub-trees is also possible. • Allow existing items to be subdivided. IETF-78, July 2010

  12. Thank you! IETF-78, July 2010

More Related