IETF-78, July 2010 1

Alert-Info URNs for the Session Initiation Protocol

(SIP)

draft-liess-dispatch-alert-info-urns-02L. Liess, R. Jesske, D. Alexeitsev (Deutsche Telekom)

A. Johnston, A. Siddiqui (Avaya)

IETF 78 – Maastricht, NetherlandsJuly 2010

IETF-78, July 2010 2

Status and GoalsStatus:

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

• 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 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

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>

• Ad-hoc agreement on Paul‘s proposal as starting point

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:

1. Allow further dimensions created.

2. Allow sub-trees is also possible.

3. Allow existing items to be subdivided.

IETF-78, July 2010 12

Thank you!