Ietf 76 hiroshima dispatch wg sip alert info urn
1 / 13

IETF 76 Hiroshima DISPATCH WG SIP Alert-Info URN - PowerPoint PPT Presentation

  • Uploaded on

IETF 76 Hiroshima DISPATCH WG SIP Alert-Info URN. draft-liess-dispatch-alert-info-urns-00 Denis Alexeitsev Laura Liess Alan Johnston Roland Jesske Anwar Siddiqui Agenda.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'IETF 76 Hiroshima DISPATCH WG SIP Alert-Info URN' - helen

An Image/Link below is provided (as is) to download presentation

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.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Ietf 76 hiroshima dispatch wg sip alert info urn

IETF 76 HiroshimaDISPATCH WGSIP Alert-Info URN


Denis Alexeitsev

Laura Liess

Alan Johnston

Roland Jesske

Anwar Siddiqui


  • History, Proposed charter and decision on how to continue

  • Mechanism, mechanism-related topics and next steps


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

Charter proposal
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)

Decisions to be taken in dispatch
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?



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.

Requirements continued
Requirements (continued)


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.

Requirements topics for discussion
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”.

Use cases
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)

Proposed syntax
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"


Iana registrations topics t4 hi erarchy or multiple discrete tokens
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


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

Iana registrations topics t5 country codes
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.

Next steps
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