IETF 81 Proceedings

Introduction  |  Area, Working Goup & BoF Reports  |  Plenaries  |  Training  |  Internet Research Task Force

Sip ALerting for User Devices (salud) (WG)

No Minutes Submitted  | Audio Archives  |  Jabber Logs  |  Mailing List Archives

Additional information is available at tools.ietf.org/wg/salud

Chair(s): Dale Worley Real-time Applications and Infrastructure Area Director(s): Gonzalo Camarillo Robert Sparks * The Real-time Applications and Infrastructure Area Directors were seated during the IETF 65. Real-time Applications and Infrastructure Area Advisor: Gonzalo Camarillo

Meeting Slides

No Slides Present

Internet-Drafts:

• Alert-Info URNs for the Session Initiation Protocol (SIP) (0 bytes) Failed to copy /a/www/ietf-ftp/internet-drafts/draft-ietf-salud-alert-info-urns-02.txt

No Request For Comments

Charter (as of 2011-08-18)

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)