* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Salud Status Pages

Sip ALerting for User Devices (Concluded WG)
Rai Area: Alissa Cooper, Ben Campbell | 2010-Jul-13 — 2015-Feb-03 
Chairs
 


2014-03-05 charter

Sip ALerting for User Devices (salud)
-------------------------------------

 Charter

 Current Status: Active

 Chair:
     Dale R. Worley <worley@ariadne.com>

 Real-time Applications and Infrastructure Area Directors:
     Richard Barnes <rlb@ipv.sx>
     Alissa Cooper <alissa@cooperw.in>

 Real-time Applications and Infrastructure Area Advisor:
     Richard Barnes <rlb@ipv.sx>

 Mailing Lists:
     General Discussion: salud@ietf.org
     To Subscribe:       https://www.ietf.org/mailman/listinfo/salud
     Archive:            http://www.ietf.org/mail-archive/web/salud/

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 2012 - Alert-Info URN specification to IESG (PS)


All charter page changes, including changes to draft-list, rfc-list and milestones:



Generated from PyHt script /wg/salud/charters.pyht Latest update: 24 Oct 2012 16:51 GMT -