IETF 75 Stockholm
BLISS WG
draft-alexeitsev-bliss-alert-info-urns-02
Denis  Alexeitsev d.alexeitsev@telekom.de
Laura Liess l.liess@telekom.de
Alan Johnston alan@sipstation.com
Roland Jesske r.jesske@telekom.de

History
Based on ideas expressed by Paul Kyzivat on the BLISS WG mailing list
Version 00 August 2008
Version 01 Sept. 2008
First presentation and discussion in an IETF meeting
We had comments on the mailing list for the 00 and 01 versions from Paul Kyzivat, Jari Mutikainen, John Elwell, Dale Worley

The Alert-Info Interoperability Problem (1)
The RFC 3261 allows an UAS or proxy to provide  a specific ring- /ringback-tone as a reference (e.g. HTTP URI) which can be played to the user in the Alert-Info header.
This mechanism does not ensure interoperability when there is no common understanding of the referenced content (different countries or vendors, hearing impaired) or when the user uses his own tones configured in the end device.
For interoperability for services as Call Waiting, a mechanism is needed which allows the callee‘s UA to transmit to the caller a semantic indication which signals that the call is a waiting call and allows the caller’s UA to decide how to render the received information to the user.

The Alert-Info Interoperability Problem (2)
Common usages of Alert-Info for common PBX ring tones are not interoperable, e.g.
Alert-Info: <file://ring.pcm>;alert=internal
Alert-Info: <file://intermal.ring.pcm>
Alert-Info: <sip:internal-ringtone@example.com>
draft-ietf-bliss-shared-appearances needs to specify a default ringtone when using appearance Alert-Info parameter.

Proposal
The draft allows to provide a semantic indication that signals the intent and allows the recipient to decide how to render the received information, to ensure interoperability for services as Call Waiting and for common PBX ring tone types.
Define a URN to be used instead of a URI in the Alert-Info header field
Examples:
Alert-Info: <urn:alert:service:call-waiting> in a 180 Ringing
Alert-Info: <urn:alert:tone:normal>;appearance=3 in an INVITE
Alert-Info: <urn:alert:tone:internal> in an INVITE
Alert-Info: <urn:alert:tone:external.priority> in an INVITE
Alert-Info: <urn:alert:service:hold-recall> in an INVITE

Changes from Version 01(1)
Alan Johnston is co-author and added the use cases, syntax and definitions for PBX ring tones and service tones.
The „standard tones“  use-case was replaced with „ring-tones generated by PBX“ (there are concrete intentions to implement the second).
Old Syntax:
alert-URN       = "URN:alert:" indication
indication      = top-level *("." sub-indication)
( e.g. urn:alert:service. call-waiting)
New Syntax:
  alert-URN       = "URN:alert:" alert-identifier
       alert-identifier= alert-category ":" alert-indication
       alert-category  = "tone"/"service"
       alert-indication= top-level *("." sub-indication)
( e.g. urn:alert:service:call-waiting or urn:alert:tone:internal.priority )

Changes from Version 01(2)
Definitions for PBX tones (normal, external, internal) and sub-indications (priority, short, delayed) added.
Definitions for service tones (forward, transfer-recall, auto-callback, hold-recall, crisis) added.

Next Steps
Are people interested in working on this topic in BLISS WG?
Is this document a good starting point?
Any additional Alert-Info topics which should be put into the draft?