| TOC |
|
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 March 6, 2009.
The Session Initiation Protocol (SIP) supports the capability to provide a reference to the alternative ringback tone (RBT) for caller, or ring tone (RT) for callee 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.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].
1.
Introduction
2.
Server Behavior
3.
User Agent Client Behavior
4.
Use cases
4.1.
Call is a waiting call
5.
Registration template
6.
IANA Considerations
6.1.
New Indication identifying lables
6.2.
Top-level indications
6.3.
Sub-Indications for the 'service' Indication
6.4.
Sub-Indications for the 'tone' Indication
6.5.
Initial IANA Registration
7.
Internationalization Considerations
8.
Security Considerations
9.
Acknowledgements
10.
References
10.1.
Normative References
10.2.
Informative References
Appendix A.
An Appendix
§
Author's Address
§
Intellectual Property and Copyright Statements
| TOC |
The Session Initiation Protocol (SIP) [RFC3261] (, J. and , H., “SIP: Session Initiation Protocol,” June 2002.) allows for user agent servers (UAS) and proxies to provide the specific ringback or ring 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 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 or ring tone and play it to the user. Current solution is sufficient for human users that share the same understanding of the tones. However if caller and callee are from the different countries the understanding of the tones may vary significantly. Hearing impaired users may not sense the specific tone if it is provided as an audio file. The tone per se is also not useful for automata. Another limitation of the current solution is that the referenced 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 the received information 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:
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
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.
| TOC |
A server MAY add a URN or multiple URNs to the Alert-Info header in an appropriate SIP message when it needs to provide additional information about the status of the user. A server SHOULD NOT add a mixture of the 'alert' URNs and URIs to the Alert-Info header that may cause disturbing rendering interference at the recepient'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 in a 183 Session Progress provisional response.
Alert-Info: <http://www.example.com/sound/moo.wav>, <urn:alert:service:call-waiting>
| TOC |
Upon receiving a SIP message with an Alert-Info header that contains a single or multiple 'alert' URNs, the User Agent (UA) attempts to match the received URNs with the known indications.
If no match is found, the UA ignores the received 'alert' 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 UA is responsible for the non disturbing rendering if multiple indications and network resources are to be rendered simultaneously.
| TOC |
This section describes the use cases that are supported by the 'alert' URNs.
| TOC |
The call waiting Service [TS24.615] (, “3GPP TS 24.615 Communication Waiting (CW) using IP Multimedia (IM) Core Network (CN) subsystem,” .) 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
| TOC |
Below is the registration template for the 'alert' URN scheme according to the RFC 3406 (, L., , D., , R., and P. , “Uniform Resource Names (URN) Namespace Definition Mechanisms,” October 2002.) [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 indication identifier, with a sequence of labels separated by periods. The left-most label is the most significant one and is called 'top-level alert indication', while names to the right are called 'alert indication'. The set of allowable characters is the same as that for domain names [RFC1123] (, R., “Requirements for Internet Hosts -- Application and Support,” October 1898.). Labels are case-insensitive, but MUST be specified in all lower-case.
Some 'alert' URNs, indication- identifiers can be removed right-to-left; the resulting URN is still valid, referring to a more generic indication. In other words, if an indication 'x.y.z' exists, the URNs 'x' and 'x.y' are also valid 'alert' URNs. Each alert indication identifier SHALL explicitly define it's validity respective the sub-indications.
The ABNF [RFC4234] (Ed, D. and P. , “Augmented BNF for Syntax Specifications: ABNF,” October 2005.) 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 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 (IANA Considerations)). 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 (IANA Considerations))). 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 (IANA Considerations)).
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 (IANA Considerations)).
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] (, L., , D., , R., and P. , “Uniform Resource Names (URN) Namespace Definition Mechanisms,” October 2002.). Static validation is performed based on the currently registered 'alert' URNs at IANA.
Scope: The scope for this URN is public and global.
| TOC |
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.
| TOC |
Indications and sub-indications are identified by labels managed by IANA, according to the processes outlined in [RFC2434] (, T. and H. , “Guidelines for Writing an IANA Considerations Section in RFCs,” October 1998.) 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 indication designation and MUST be defined by the document describing the top-level indication.
Entries in the registration table have the following format:
Indication Reference Description -------------------------------------------------------------------- foo RFCxyz Description of the 'foo' top-level indication foo.bar RFCabc Description of the 'foo.bar' sub-indication
Each top-level or sub-indication label MUST NOT exceed 27 characters.
| TOC |
This section defines the indication registration within the IANA registry defined in Section 7.1, using the top-level indication labels 'service' and 'tone'.
The '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.
Validity of the 'service' top-level indication: this indication is not valid without respective sub-indications.
The 'tone' indication label 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.
Validity of the 'tone' top-level indication: this indication is not valid without respective sub-indications.
| TOC |
This section defines the indication registration within the IANA registry defined in Section 7.1, using the sub-indication label 'service:call-waiting'.
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.
Validity of the 'service:call-waiting' sub-indication: this indication is valid without respective sub-indications
| TOC |
This section defines the indication registration within the IANA registry defined in Section 7.1, using the sub-indication label 'tone.xyz'.
[anchor11] (Input on the 'tone' sub-indication is requested.)
urn:alert:tone:xyz
| TOC |
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
| TOC |
The indication labels are protocol elements [RFC3536] (, P., “Terminology Used in Internationalization in the IETF,” May 2003.) and are not normally seen by users. Thus, the character set for these elements is restricted, as described in Section 6.
| TOC |
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.
| TOC |
The draft is based on the ideas expressed by Paul Kyzivat on the BLISS WG mailing list.
| TOC |
| TOC |
| [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 (TXT, HTML, XML). |
| [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. |
| TOC |
| [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.” |
| TOC |
| TOC |
| Denis Alexeitsev | |
| Deutsche Telekom AG | |
| Heinrich-Hertz Str 3-7 | |
| Darmstadt, Hessen 64293 | |
| Germany | |
| Phone: | +49-6151-6282773 |
| Email: | d.alexeitsev@telekom.de |
| TOC |
Copyright © 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.
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.