IETF 76 Hiroshima DISPATCH WG SIP Alert-Info URN

1. IETF 76 HiroshimaDISPATCH WGSIP Alert-Info URN draft-liess-dispatch-alert-info-urns-00 Denis Alexeitsev d.alexeitsev@telekom.de Laura Liess l.liess@telekom.de Alan Johnston alan@sipstation.com Roland Jesske r.jesske@telekom.de Anwar Siddiqui anwars@avaya.com

2. Agenda • History, Proposed charter and decision on how to continue • Mechanism, mechanism-related topics and next steps

3. History • Based on ideas expressed by Paul Kyzivat on the BLISS WG mailing list • Version 00, 01, 02 in BLISS • Decision at the IETF 75 to submit the draft and mini-charter proposal for dispatch • Mini-charter proposal and 00 draft version submitted in DISPATCH • Comments on the draft at the IETF 75 and on the mailing list from Paul Kyzivat, Adam Roach, John Elwell, Dean Willis, Tom Taylor. Thank you!

4. Charter Proposal 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: • ring-/ringback-tones services as call waiting, call forwarding, blind transfer, automatic callback, call hold or for emergency announcements sent over PBX systems • PBX ring tones when proxy and UAs are from different vendors with no external ring file being used • country-specific ringback tones 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)

5. Decisions to be taken in DISPATCH 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?

6. Requirements REQ-1 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. REQ-2 The mechanism will allow to ensure interoperability for services as call waiting, forward, call forwarding, transfer-recall, auto-callback, hold-recall, crisis. REQ-3 The mechanism will allow to render common PBX ring tone types. REQ-4 The mechanism will allow to render specific country tones. REQ-5 The mechanism will allow to render tones for emergency alerts. REQ-6 The mechanism will allow rendering using other means than tones, e.g. text or images.

7. Requirements (continued) REQ-7 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. REQ-8 The mechanism will allow to store the actual encoding locally rather than fetching it. REQ-9 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. REQ-10 The mechanism will be flexible and can be extended for use cases not described in this specification . REQ-11 The mechanism will allow transmission in SIP requests and responses.

8. Requirements Topics for Discussion • T1: Some confusion around country specific tones 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) • T2: REQ-3 and REQ-7 can currently not coexist 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”.

9. Use Cases 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. • PBX ring-tones • normal (default, no special indication) • external • internal • PBX ring-tones modifiers • priority: a priority level alert should be applied for the type of alerting specified • short (abreviated): the alert type specified should be rendered shorter than normal . • delayed: the alerting type specified should be rendered after a short delay Country-specific ringback tones The Alert-Info URN identifier is sent in the 180 Ringing response and inserted by the callee’s UA. Service tones • The Alert-Info URN identifier is sent in INVITE to enable the user UA to distinguish the corresponding the service call from a normal incoming call • transfer-recall: used by a blind transfer server when it calls back the transferor after a failed blind transfer. • auto-callback: used by a callback server when it initiates the callback by calling the UAC of the previous unsuccessfuly call. • hold-recall: used when a server implements a call hold timer on behalf of an endpoint. After a certain period of time of being on hold, the user who placed the call on hold is alerted to either retrieve the call or otherwise dispose of the call. • crisis • The Alert-Info URN identifier is sent in 180 Ringing to enable the caller from a normal ringback • call-waiting: is added by a server (UAS, proxy, AS) at the callee's side to indicate a call waiting condition at the callee’s side • forward: is added by a server (UAS, proxy, AS) at the callee's side to indicate that call forwarding feature has been initiated on the previous INVITE. Eventually ring tones for public emergency alerts? (TBD)

10. Proposed 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:tone:internal , urn:alert:service:call-waiting) Topic for Discussion: T3: confusion between ring-tones and ringback-tones Q: Should we split “tone” in • “ring-tone” (sent in INVITE) and • “ringback-tone” (sent in 180 Ringing) alert-category = “ring-tone"/ “ringback-tone"/ "service" urn:alert:ringback-tone:de

11. IANA Registrations TopicsT4: Hierarchy or Multiple Discrete Tokens ? 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 Cons: • Rules on how to combine Alert-URNs can be complicated • Handling of multiple URNs more difficult for the UA Q: Is “Multiple discrete tokens“ the prefered alternative ?

12. IANA Registrations Topics T5: Country Codes • Reference to ISO 3166-1 instead of registring every country code (agreed on the ML) • Q: Need to define a general “country-code” URN ? We do not want to do it in this specification.

13. Next Steps • Consolidate the requirements • Consolidate the use cases • More discussion on the IANA registration open items • New draft version before the next IETF meeting