IETF 76 Hiroshima DISPATCH WG SIP Alert-Info URN. draft-liess-dispatch-alert-info-urns-00 Denis Alexeitsev firstname.lastname@example.org Laura Liess email@example.com Alan Johnston firstname.lastname@example.org Roland Jesske email@example.com Anwar Siddiqui firstname.lastname@example.org. Agenda.
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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.
Denis Alexeitsev email@example.com
Laura Liess firstname.lastname@example.org
Alan Johnston email@example.com
Roland Jesske firstname.lastname@example.org
Anwar Siddiqui email@example.com
The SIP Alert-Info URN (SAIU) working group is chartered to define a new URN-scheme which allows SIP to convey a particular alert indication using a name instead of a referenced URI. The Alert-Info URN solves interoperability problems which we encounter today around the use of the Alert-Info header field.
RFC 3261 allows a 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, hearing impaired) or when the user has his own tones configured in the end device. This is the case, e.g. for:
There are a variety of URI conventions and proprietary Alert-Info header field parameters to provide this today, all of which are non-interoperable.
A standardized set of Alert-Info URNs will increase SIP interoperability for this header field by replacing proprietary conventions.
The group will produce a specification which describes the problem statement, the requirements and use cases, and defines the scheme Alert-Info URN-scheme and the specific Alert-Info URNs identifiers to solve the interoperability problems above.
Goals and Milestones
Dec 10 - Alert-Info URN specification to IESG (PS)
Q1: Are people interested to work on this problem?
Q2: Charter proposal OK or additional information required?
Q3: Work in new mini-WG, BLISS, something else?
The mechanism will allow user agents (UAs) and proxies to provide a semantic indication in the Alert-Info SIP-header that signals the intent of the rendering and allows the recipient to decide how to render the received information.
The mechanism will allow to ensure interoperability for services as call waiting, forward, call forwarding, transfer-recall, auto-callback, hold-recall, crisis.
The mechanism will allow to render common PBX ring tone types.
The mechanism will allow to render specific country tones.
The mechanism will allow to render tones for emergency alerts.
The mechanism will allow rendering using other means than tones, e.g. text or images.
The mechanism will allow rendering to be semantic, not biased towards a a particular representation which might not be suitable for all devices or users.
The mechanism will allow to store the actual encoding locally rather than fetching it.
The mechanism will allow the identifier to be specified "by name" rather than "by value", to enable local policy decisions whether to use it or not.
The mechanism will be flexible and can be extended for use cases not described in this specification .
The mechanism will allow transmission in SIP requests and responses.
Q: Is there a need for country specific tones other than ringback? Can we restrict REQ-4 to ringback tones?
Note: We can not use Alert-Info in “busy”-response ( out of scope)
Is there a need for country-specific ring tones? Ring-tones do not change for each call. Ring-tones can be carrier-specific. E. g. there is no “German” ringing tone, but a DT ring tone.
People use today personal, downloaded ringing tones. ( out of scope)
Q: Can we relax REQ-7 in closed environments, where a common understanding for rendering-oriented ringing tone can be assumed, e.g. “normal” or “short” for PBX systems ?
If not, we will remove “short”.
PBX ring-tones and ring-tone modifiers
The Alert-Info URN identifier is sent in the SIP INVITE and inserted by the callee’s proxy/B2BUA.
Country-specific ringback tones
The Alert-Info URN identifier is sent in the 180 Ringing response and inserted by the callee’s UA.
Eventually ring tones for public emergency alerts? (TBD)
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:tone:internal , urn:alert:service:call-waiting)
Topic for Discussion:
T3: confusion between ring-tones and ringback-tones
Q: Should we split “tone” in
alert-category = “ring-tone"/ “ringback-tone"/ "service"
Alt. 1: Hierarchy (e.g. urn:alert:tone:internal.priority)
Pro: The UA only needs a look-up to resolve
Con:Combinatorial growth of the IANA registrations number
Alt. 2: Multiple discrete tokens (e.g. urn:alert:tone:internal and urn:alert:tone:priority)
Pro: Linear growth of the IANA registrations number
Q: Is “Multiple discrete tokens“ the prefered alternative ?
We do not want to do it in this specification.