A new IETF working group has been formed in the Real-time Applications and Infrastructure Area. For additional information, please contact the Area Directors or the WG Chairs. Sip ALerting for User Devices (salud) -------------------------------------------------- Chair(s): Dale Worley <dworley@avaya.com> Real-time Applications and Infrastructure Area Director(s): Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> Robert Sparks <rjsparks@nostrum.com> Real-time Applications and Infrastructure Area Advisor: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> Mailing List: Address: 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 2011 - Alert-Info URN specification to IESG (PS) _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
