IETF-78, July 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 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 #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 #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 Change to RFC Gonzalo will check if this change is minor enough so it can be done in this draft.

IETF-78, July #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 #4 Use Cases Adam‘s Use Cases (TIA/EIA-41-D and 3GPP2 A.S0014) 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 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 # 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 #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 #7 A-I URN Values and extensibility rules urn:alert:source: -unclassified (default) -internal -external -friend -family -private. urn:alert:priority: -normal (default) -low -high -private. urn:alert:duration: -normal (default) -short (or "zip") -long -private. urn:alert:delay: -none (default) -yes -private. urn:alert:service: -normal (default) -call-waiting -forward -recall.callback -recall.hold -recall.transfer -private. urn:alert:locale: -default (default) -country. -private. Ad-hoc agreement on Paul‘s proposal as starting point

IETF-78, July #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 #9 Extensibility Rules So far three extension mechanisms recognized: 1.Allow further dimensions created. 2.Allow sub-trees is also possible. 3.Allow existing items to be subdivided.

IETF-78, July Thank you!