DISPATCH WG SIP AlertInfo URN draftliessdispatchalertinfourns00 Denis Alexeitsev dalexeitsevtelekomde Laura Liess lliesstelekomde Alan Johnston alansipstationcom ID: 175070
Download Presentation The PPT/PDF document "1 IETF 76 Hiroshima" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Slide1
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.comSlide2
2
AgendaHistory, Proposed charter and decision on how to continue
Mechanism, mechanism-related topics and next stepsSlide3
3
HistoryBased on ideas expressed by Paul Kyzivat on the BLISS WG mailing listVersion 00, 01, 02 in BLISSDecision 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! Slide4
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)Slide5
5
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?
Decisions to be taken in DISPATCHSlide6
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.
Slide7
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.Slide8
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”. Slide9
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)Slide10
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
Slide11
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 ? Slide12
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.Slide13
13
Next StepsConsolidate the requirementsConsolidate the use cases
More discussion on the IANA registration open items
New draft version before the next IETF meeting