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