[secdir] [New-work] WG Review: Sip ALerting for User Devices (salud)

[IESG Secretary <[e-mail]>]

A new IETF working group has been proposed in the Real-time Applications
and Infrastructure Area.  The IESG has not made any determination as yet.
The following draft charter was submitted, and is provided for
informational purposes only. Please send your comments to the IESG mailing
list ([e-mail]) by Tuesday, June 29, 2010.  

Sip ALerting for User Devices (salud)
--------------------------------------------------
Current Status: Proposed Working Group

Last modified: 2010-06-21

Chair(s):
  TBD

Real-time Applications and Infrastructure Area Director(s):
  Gonzalo Camarillo <[e-mail]>
  Robert Sparks <[e-mail]>

Real-time Applications and Infrastructure Area Advisor:
  Gonzalo Camarillo <[e-mail]>

Mailing Lists: TBD

Description of Working Group:

The SALUD (Sip ALerting for User Devices) working group is chartered
to define a new URN namespace that allows SIP to convey a particular
alert indication using a name instead of a referenced URI. The
Alert-Info URN namespace addresses issues encountered in current
systems that use the Alert-Info header field. It is expected that this
group will collaborate with the Applications area on the definition of
the URN namespace.

RFC 3261 allows a user agent server to provide a specific ringing
tone, which can be played to the calling user, as a reference (e.g.,
an HTTP URI) in the Alert-Info header. In some situations, the calling
user may not be able to understand the meaning of the ringing tone
being played. For example, a user from a given country may not be
familiar with the tone used to indicate call waiting in another
country. Similarly, a hearing impaired person may prefer to get a
visual call waiting indication instead of a call waiting tone.

RFC 3261 also allows a user agent client to provide a reference to a
specific alerting tone, which can be played to the called user (e.g.,
tones for emergency announcements sent over PBX systems or over the
local telephone network). As in the previous examples, in some
situations, the calling user may not be able to understand the meaning
of the alerting tone being played.

These issues can be resolved with a mechanism for user agents to
exchange this type of alerting information in a semantic way. In this
way, different user agents can use different renderings for the same
semantics. For example, a user agent client instructed to inform its
user about a call waiting service being provided can use the
personalized tones that were previously configured by the user.

Traditionally, SIP has used status codes to encode session state
information (e.g., 180 Ringing). Status codes are used by SIP entities
in an automatic fashion. The information this working group is
concerned with is related to rendering and may not represent the state
of the session. Additionally, the exchange of this information does
not affect the way SIP entities process the session. That is why
status codes are not an appropriate vehicle to encode this type of
information. This working group will work on encoding this information
in URNs.

In addition to defining URNs that are associated to particular events
(e.g., a call waiting service is being applied), this working group
will also define URNs that describe the characteristics of the
alerting to be applied (e.g., play a short tone followed by a long
tone).

There are a variety of non-interoperable URI conventions and
proprietary Alert-Info header field parameters to provide this type of
information today. 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 that:

* describes the problem statement.

* describes requirements and  use cases.

* defines an Alert-Info URN-scheme which allows to resolve the
  interoperability problems described in the use cases.

* defines the specific Alert-Info URNs identifiers for some of the use
  cases above.

The Alert-Info URN namespace must be open, so that additional
Alert-Info URNs can be defined later if necessary.

Goals and Milestones
====================
Aug 2011 - Alert-Info URN specification to IESG (PS)
_______________________________________________
New-work mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/new-work