BLISS Denis Alexeitsev Internet-Draft Deutsche Telekom AG Intended status: Standards Track August 18, 2008 Expires: February 19, 2009 Alert-Info header URNs for Session Initiation Protocol (SIP) draft-alexeitsev-bliss-alert-info-urns-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on February 19, 2009. Abstract The Session Initiation Protocol (SIP) supports the capability to provide a reference to the alternative ringback tone for the caller using the Alert-Info header. However, the reference addresses only the network resources with specific rendering properties. There is currently no support for predefined standard identifiers for ringback tones or semantic indications without tied rendering. To overcome this limitations and support new applications a family of the URNs is defined in this specification. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", Denis Alexeitsev Expires February 19, 2009 [Page 1] Internet-Draft Alert-Info URNs August 2008 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 4 3. User Agent Client Behavior . . . . . . . . . . . . . . . . . . 4 4. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Call is a waiting call . . . . . . . . . . . . . . . . . . 5 5. Registration template . . . . . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6.1. New Indication identifying lables . . . . . . . . . . . . 7 6.2. Sub-Indications for the 'service' Indication . . . . . . . 8 6.3. Sub-Indications for the 'tone' Indication . . . . . . . . 8 6.4. Initial IANA Registration . . . . . . . . . . . . . . . . 8 7. Internationalization Considerations . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 10.2. Informative References . . . . . . . . . . . . . . . . . . 10 Appendix A. An Appendix . . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . . 11 Denis Alexeitsev Expires February 19, 2009 [Page 2] Internet-Draft Alert-Info URNs August 2008 1. Introduction The Session Initiation Protocol (SIP) [RFC3261] allows for user agent servers (UAS) and proxies to provide the specific ringback tone to the user agent (UA). In RFC 3261 this is done by including a URI reference in the Alert-Info header field, that points to the rinback tone. The URI reference is most commonly the HTTP URI to the audio file. On the receipt of the Alert-Info header the user agent may fetch the referenced ringback tone and play it to the user. Current solution is sufficient for human users that share the same understanding of the ringback tones. However if caller and callee are from the different countries the understanding of the ringback tones may vary significantly. Hearing impaired users may not sense the specific ringback tone if it is provided as an audio file. The ringback tone is not useful for automata. Another limitation of the current solution is that the referenced ringback tones are tied to particular rendering. It is not possible to provide a semantic indication that signals the intent and allows the recipient to decide how to render it in an appropriate way. To solve the described issues and support new applications this specification defines the new URN namespace 'alert' for the Alert- Info header that can be understood by an automaton, would allow for programmatic handling, including user interface adaptation, or conversion to equivalent protocol parameters in the Public Switched Telephone Network (PSTN) when the client is a gateway. Using 'alert' namespace provides syntax for several different application spaces: o Names for services like "call is a waiting call", not tied to any particular rendering. o Names for standard tones, such as those used by the PSTN. For instance there could be names for all the various country-specific ring tones and ringback tones o Names for things with specific renderings that aren't purely audio. They might be static icons, video sequences, text, etc. Some advantages of a URN rather than a net reference to a downloadable resource: no need to download it you don't have to worry if you support the format downloaded Denis Alexeitsev Expires February 19, 2009 [Page 3] Internet-Draft Alert-Info URNs August 2008 there is no "danger" that you might end up rendering something unexpected and undesirable you can render as high (or low) quality as your device can use The downside is that if the recipient does not understand the URN then it won't be able to render anything. To provide the general awareness about the Alert-Info URNs this document provides IANA template for registering the URNs and defines several typical identifiers. 2. Server Behavior A server MAY add a URN or multiple URNs to the Alert-Info header in a provisional response when it needs to provide additional information about the status of the callee. A server SHOULD NOT add a mixture of URNs and URIs to the Alert-Info header that may cause disturbing rendering interference at the callee's UA. Following example shows both the network audio resource referenced by the HTTP URI and the URN indication for the call-waiting service transported by the Alert-Info header. Alert-Info: , 3. User Agent Client Behavior Upon receiving a provisional response with an Alert-Info header that contains a single or multiple alert URNs, the User Agent Client (UAC) attempts to match the URNs with the known indications. If no match is found, the UA ignores the received URNs and proceed with normal operation. If the one or multiple URNs matches a known indication the UAC renders the indication(s) to the user according to the type of indication. The UAC is responsible for the non disturbing rendering if multiple indications and network resources are to rendered simultaneously. 4. Use cases This section describes the use cases that are supported by the Alert- Info header URNs. Denis Alexeitsev Expires February 19, 2009 [Page 4] Internet-Draft Alert-Info URNs August 2008 4.1. Call is a waiting call The call waiting Service [TS24.615] permits a callee to be notified of an incoming call whilst the media resources are not available for the incoming call and the callee is engaged in an active or held call. Subsequently, the callee can either accept, reject, or ignore the incoming call. There is an interest on the caller side to be informed about the call waiting situation on the callee side. Having this information the caller can decide whether to continue waiting for callee to pickup, or better to call some time later when it is estimated, that the callee could finished the ongoing conversation. To provide this information callee's UAS or proxy aware of the call waiting condition can add the call-waiting indication URN to the Alert-Info header. As call-waiting information may be subject to the callee's privacy concerns, the exposure of this information SHALL be done only if explicitly required by the user 5. Registration template Below is the registration template for the 'alert' URN scheme according to the RFC 3406 [RFC3406] Namespace ID: alert Registration Information: Registration version: 1 Registration date: 2008-08-14 Declared registrant of the namespace: Registering organization: IETF Designated contact: Denis Alexeitsev Designated contact email: d.alexeitsev@telekom.de Declaration of syntactic structure: The URN consists of a hierarchical alert service identifier, with a sequence of labels separated by periods. The left-most label is the most significant one and is called 'top-level alert service', while names to the right are called 'alert sub-services'. The set of allowable characters is the same as that for domain names [RFC1123]. Denis Alexeitsev Expires February 19, 2009 [Page 5] Internet-Draft Alert-Info URNs August 2008 Labels are case-insensitive, but MUST be specified in all lower-case. For any given service URN, service- identifiers can be removed right- to-left; the resulting URN is still valid, referring to a more generic service. In other words, if a service 'x.y.z' exists, the URNs 'x' and 'x.y' are also valid service URNs. The ABNF [RFC4234] is shown below. alert-URN = "URN:alert:" indication indication = top-level *("." sub-indication) top-level = let-dig [ *25let-dig-hyp let-dig ] sub-indication = let-dig [ *let-dig-hyp let-dig ] let-dig-hyp = let-dig / "-" let-dig = ALPHA / DIGIT ALPHA = %x41-5A / %x61-7A ; A-Z / a-z DIGIT = %x30-39 ; 0-9 Relevant ancillary documentation: None Community considerations: The alert URN is believed to be relevant to a large cross-section of Internet users, including both technical and non-technical users, on a variety of devices and with a variety of perception capabilities. The alert URN will allow Internet users to better understand the alert status of the callee in the foreign country, or better understand if the callee is able to answer the call. For example, specific ringback tone from the foreign country can be rendered by the user interface in the familiar way to the user. Call is a waiting call indication meaning that the callee is occupied with the different session can be provided to the caller that would help to better assert the answer probability. User interfaces for the perception impaired users can better render the ringback indication based on the alert URN. The assignment of identifiers is described in the IANA Considerations (Section 6). The alert URN does not prescribe a particular resolution mechanism, but it is assumed that a number of different entities could operate and offer such mechanisms. Namespace considerations: There do not appear to be other URN namespaces that serve the same need of uniquely identifying alert communication and information services. Identifier uniqueness considerations: An alert URN identifies a logical service or tone, specified in the alert indication registration (see IANA Considerations (Section 6)). Resolution of the registered URN, will return a particular instance of the alert indication. Alert indication URNs MUST be unique for each unique indication; this is guaranteed through the registration of each alert indication within this namespace, described in (Section 6). Denis Alexeitsev Expires February 19, 2009 [Page 6] Internet-Draft Alert-Info URNs August 2008 Identifier persistence considerations: The alert URN for the same indication is expected to be persistent, as long as it is registered with IANA. Process of identifier assignment: The process of identifier assignment is described in the IANA Considerations (Section 6). Process for identifier resolution: alert URNs are statically resolved according to the IANA registry. Rules for lexical equivalence: alert URNs are compared according to case-insensitive string equality. Conformance with URN syntax: The BNF in the 'Declaration of syntactic structure' above constrains the syntax for this URN scheme. Validation mechanism: Validation determines whether a given string is currently a validly-assigned URN [RFC3406]. Static validation is performed based on the currently registered alert URNs at IANA. Scope: The scope for this URN is public and global. 6. IANA Considerations This section registers a new URN scheme with the registration template provided in section Registration Template. Below, the section 7.1 details how to register new alert indication identifying labels. Descriptions of sub-indications for the first two indications to be registered, service and tone, are given in Section 7.2 and Section 7.3, respectively. Finally, Section 7.4 contains the initial registration table. 6.1. New Indication identifying lables Indications and sub-indications are identified by labels managed by IANA, according to the processes outlined in [RFC2434] in a new registry called "Alert URN Labels". Thus, creating a new indication requires IANA action. The policy for adding top-level indication labels is 'Standards Action'. (This document defines the top-level indication labels 'service' and 'tone'.) The policy for assigning labels to sub-indications may differ for each top-level indications designation and MUST be defined by the document describing the top- level indication. Entries in the registration table have the following format: Denis Alexeitsev Expires February 19, 2009 [Page 7] Internet-Draft Alert-Info URNs August 2008 Indication Reference Description ------------------------------------------------------------------------------- foo RFCxyz Brief description of the 'foo' top-level service or tone foo.bar RFCabc Description of the 'foo.bar' service or tone All top-level indication labels MUST NOT exceed 27 characters. 6.2. Sub-Indications for the 'service' Indication This section defines the first indication registration within the IANA registry defined in Section 7.1, using the top-level indication label 'service'. 'service' indication label provides information about additional services performed on the callee side. Sub-indications of the service indication are not tied to any particular rendering and signal the service invocation, that allows the recipient to decide on the best way to render this indication. urn:alert:service:call-waiting indication provides information to the caller about the call-waiting situation on the callee side. Call- waiting situation for the callee means that very limited resources are available for an incoming communication. The callee normally has the choice of accepting, rejecting or ignoring the waiting call. 6.3. Sub-Indications for the 'tone' Indication The 'tone' indication type describes tones that should be rendered to the caller. The normal rendering is audio, however there can be other renderings applicable if needed by the user interface specifics. urn:alert:tone:XYZ 6.4. Initial IANA Registration The following table contains the initial IANA registration for service and tone indications. Indication Reference Description -------------------------------------------------------------------- service RFC XYZ Invoked services service.call-waiting RFC XYZ Call-waiting service tone RFC XYZ Ringback tones tone.xyz RFC XYZ XYZ tone Denis Alexeitsev Expires February 19, 2009 [Page 8] Internet-Draft Alert-Info URNs August 2008 7. Internationalization Considerations The indication labels are protocol elements [RFC3536] and are not normally seen by users. Thus, the character set for these elements is restricted, as described in Section 6. 8. Security Considerations As an identifier, the alert indication URN does not appear to raise any particular security issues. The indications described by the alert URN are meant to be well-known, so privacy considerations do not apply to the URN. Provision of the specific indications from callee to caller may raise privacy issues. Such provision SHALL always be explicitly authorised by the callee. 9. Acknowledgements The draft is based on the ideas expressed by Paul Kyzivat on the BLISS WG mailing list. 10. References 10.1. Normative References [RFC1123] , R., "Requirements for Internet Hosts -- Application and Support", October 1898. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2141] , R., "URN Syntax", May 1997. [RFC3261] , J. and , H., "SIP: Session Initiation Protocol", June 2002. [RFC3406] , L., , D., , R., and P. , "Uniform Resource Names (URN) Namespace Definition Mechanisms", October 2002. [RFC4234] Ed, D. and P. , "Augmented BNF for Syntax Specifications: ABNF", October 2005. Denis Alexeitsev Expires February 19, 2009 [Page 9] Internet-Draft Alert-Info URNs August 2008 10.2. Informative References [RFC2434] , T. and H. , "Guidelines for Writing an IANA Considerations Section in RFCs", October 1998. [RFC3536] , P., "Terminology Used in Internationalization in the IETF", May 2003. [TS24.615] "3GPP TS 24.615 Communication Waiting (CW) using IP Multimedia (IM) Core Network (CN) subsystem". Appendix A. An Appendix Author's Address Denis Alexeitsev Deutsche Telekom AG Heinrich-Hertz Str 3-7 Darmstadt, Hessen 64293 Germany Phone: +49-6151-6282773 Email: d.alexeitsev@telekom.de Denis Alexeitsev Expires February 19, 2009 [Page 10] Internet-Draft Alert-Info URNs August 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Denis Alexeitsev Expires February 19, 2009 [Page 11]