Subject: [MIB-DOCTORS] FW: WG Review: Sip ALerting for User Devices (salud)

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 23 Jun 2010 12:06:53 +0200

Please find below the proposed charter of the SALUD WG in RAI. Please
send your questions, comments and concerns before 6/29 COB. 

Thanks and Regards,

Dan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
IESG Secretary
Sent: Tuesday, June 22, 2010 8:15 PM
To: [email-masked]
Subject: WG Review: Sip ALerting for User Devices (salud) 

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 ([email-masked]) 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 <[email-masked]>
  Robert Sparks <[email-masked]>

Real-time Applications and Infrastructure Area Advisor:
  Gonzalo Camarillo <[email-masked]>

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)