IETF 75 Stockholm BLISS WG

1
IETF 75 StockholmBLISS WG

• draft-alexeitsev-bliss-alert-info-urns-02
• Denis Alexeitsev d.alexeitsev_at_telekom.de
  
• Laura Liess l.liess_at_telekom.de
• Alan Johnston alan_at_sipstation.com
• Roland Jesske r.jesske_at_telekom.de

2
History

• 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

3
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
  callees UA to transmit to the caller a semantic
  indication which signals that the call is a
  waiting call and allows the callers UA to decide
  how to render the received information to the
  user.

4
The Alert-Info Interoperability Problem (2)

• Common usages of Alert-Info for common PBX ring
  tones are not interoperable, e.g.
• Alert-Info ltfile//ring.pcmgtalertinternal
• Alert-Info ltfile//intermal.ring.pcmgt
• Alert-Info ltsipinternal-ringtone_at_example.comgt
  
• draft-ietf-bliss-shared-appearances needs to
  specify a default ringtone when using appearance
  Alert-Info parameter.

5
Proposal

• 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 lturnalertservicecall-waitinggt in a
  180 Ringing
• Alert-Info lturnalerttonenormalgtappearance3
  in an INVITE
• Alert-Info lturnalerttoneinternalgt in an
  INVITE
• Alert-Info lturnalerttoneexternal.prioritygt in
  an INVITE
• Alert-Info lturnalertservicehold-recallgt in an
  INVITE

6
Changes from Version 01(1)

• 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 "URNalert" indication
• indication top-level ("." sub-indication)
• ( e.g. urnalertservice. call-waiting)
• New Syntax
• alert-URN "URNalert"
  alert-identifier
• alert-identifier alert-category ""
  alert-indication
• alert-category "tone"/"service"
• alert-indication top-level ("."
  sub-indication)
• ( e.g. urnalertservicecall-waiting or
  urnalerttoneinternal.priority )

7
Changes from Version 01(2)

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

8
Next Steps

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