SIPPING D. Petrie Internet-Draft SIPez LLC. Expires: April 26, 2007 M. Dolly AT&T Labs V. Hilt Bell Labs/Lucent Technologies October 23, 2006 The Session Initiation Protocol User Agent VoIP Features Data Set draft-petrie-sipping-voip-features-dataset-01.txt 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 April 26, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document defines the properties and format for the SIP user agent VoIP Features data set. The properties defined in this document are expected to be common to most SIP user agents that provide VoIP capabilities. These VoIP Feature properties are considered to be a data set. Several types of datasets may be Petrie, et al. Expires April 26, 2007 [Page 1] Internet-Draft VoIP Features Data Set October 2006 combined into documents that are provided to SIP user agents so that they can operate with the desired behavior. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Terminology . . . . . . . . . . . . . . . . . 3 1.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. VoIP Features Data Set . . . . . . . . . . . . . . . . . . . . 4 2.1. mwiProperties Element . . . . . . . . . . . . . . . . . . 4 2.2. digitMap Element . . . . . . . . . . . . . . . . . . . . . 5 2.3. callWaiting . . . . . . . . . . . . . . . . . . . . . . . 7 2.4. callTransfer Element . . . . . . . . . . . . . . . . . . . 7 3. Security Considerations . . . . . . . . . . . . . . . . . . . 8 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 4.1. Content-type registration for 'application/uapvoip+xml' . 8 5. Change History . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Changes from draft-petrie-sipping-voip-features-dataset-00 . . . . . . 9 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.1. Normative References . . . . . . . . . . . . . . . . . . . 10 6.2. Informational References . . . . . . . . . . . . . . . . . 11 Appendix A. SIP Protocol Dataset Schema . . . . . . . . . . . . . 11 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 14 Petrie, et al. Expires April 26, 2007 [Page 2] Internet-Draft VoIP Features Data Set October 2006 1. Introduction [I-D.ietf-sipping-config-framework] defines a configuration framework for finding, retrieving and notification of profile data for SIP [RFC3261] user agents. It is intended that the VoIP Features dataset defined in this document may be contained in the user and device profiles described in the configuration framework. [I-D.petrie- sipping-profile-datasets] defines a general XML schema to contain user agent profile data. This document defines VoIP specific feature data by extending the profile data sets schema. The VoIP Features Data Sets defined in this document support the principle to enable SIP User Agents to obtain and use profile data sets from multiple sources in order to support a wide range of applications without undue complexity. The VoIP Feature Data Set suppports VoIP Features that are common across devices with SIP UAs. This data set contains properties that all user agents require. That does not mean that all of these properties are mandatory. The following elements are defined in this document to contain VoIP feature properties: mwiProperties digitMaps, including identification of emergency numbers (e.g., 911) callWaiting callTransfer 1.1. Requirements Terminology Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and "MAY" that appear in this document are to be interpreted as described in RFC 2119[RFC2119]. 1.2. Overview The VoIP Feature data set is defined in Section 3 and complies with the guidelines provided in Section 5 of [I-D.petrie-sipping-profile- datasets] Section 4 provides illustrative example profiles and use cases for merging. Security considerations are addresed in Section 5. The following is an example instance of the VoIP Feature data set. Petrie, et al. Expires April 26, 2007 [Page 3] Internet-Draft VoIP Features Data Set October 2006 sip:alice-voicemail@example.com sip:alice@example.com enable sip:1000@home.example.com sip:alice@example.com enable 91xxxxxxxxxx|1xxxxxxxxxx normal sip:{digits}@example.com work 911|9911|91911 emergency sip:911@10.1.1.100 011xxxT|0011xxxT normal sip:{digits}@international.example.com enable blind Note: in the digitMap element above containing an outboundIdentity element, the value "work" refers to the "id" attribute of a sipIdentity element to use for the outbound call (see draft-petrie-identity-dataset-00.txt). 2. VoIP Features Data Set The XML schema defined in this document extends the root element property set schema defined in I-D.petrie-sipping-profile-datasets. 2.1. mwiProperties Element Message Waiting Indication (MWI) is a service where the subscriber can access their voice mail message using a messageUri, be informed on the status of unheard messages with a device depenendent Petrie, et al. Expires April 26, 2007 [Page 4] Internet-Draft VoIP Features Data Set October 2006 indicator. mwiProperties - This element contains properties related to Message Waiting Indication, and is an XML elelment that extends on the XML setting container element contained in the root "propertySet" element. It serves as a container for mwi elements: messageUri mwiStatusUri mwiIndicator The messageUri and mwiStatusUri elements have values of type string that contain a SIP uri of the form name-addr from [RFC3261]. messageUri - The optional messageUri element MAY contain the URI to use for retrieving messages. There MAY be zero or one messageUri element in mwiProperties element. mwiStatusUri - The mwiStatusUri element contains the SIP URI used to subscribe to MWI event package [RFC3841]. Exactly one mwiStatusUri element SHOULD be contained in mwiProperties. mwiIndicator - The mwiIndicator element sets the new message indication behavior of the user agent when there are new or unheard messages for the resource contained in mwiStatusUri element provided by the MWI event package [RFC3841]. The values of the mwiIndicator element are: "enable" or "disable". A value of "enable" means that the user agent SHOULD indicate when there are messages available for the resource id contained in the mwiStatusUri. A value of "disable" means that the user agent SHOULD NOT indicate whether messages are available or not. The means of indication is a user agent implementation decision. It may be a audable "stutter dial tone", a light indication or other user interface mechanism. . mwiProperties elements may be provided in both the Device and User profiles. There may be multiple mwiProperties in the device and user profiles. All instances of mwiProperties elements across the device and user profiles are used. If a user agent supports the ablity to subscribe to a limited number of MWI resource IDs, the first N mwiProperties elements found when search through the device and then the user profile will be subscribe to, where N is the maximum number of resource IDs that the user agent can subscribe to. 2.2. digitMap Element Digitmaps allow the user agent to decide when user is done dialing. The digitMap element contains the callPriority element which allow the user agent to categorize the type of call according to digit string patterns (e.g. emergency vs normal). The digitMap element contains the uriTemplate element which defines how the user agent Petrie, et al. Expires April 26, 2007 [Page 5] Internet-Draft VoIP Features Data Set October 2006 should construct the INVITE request URI based upon digits dialed. The uriTemplate element allow routing of the outbound call based upon the digit string patterns by providing different information in the INVITE request URI. The digitMap element can optionally contain a outboundId element which allows the definition of which identity to use for the call based upon digit string patterns. The digitMap is an XML elelment that extends on the XML setting element contained in digitMaps. It serves as a container for a list of digit patterns. Each pattern is associated with a SIP URI. Digit patterns associated with emergency numbers are marked. There may be one or more elements. The digitMap element SHOULD contain exactly one digitPattern element and one uriTemplate. The digitMap element MAY contain at most one callPriority element and one outboundId element. digitPattern - The digitPattern element is of type string containing a digit map pattern using the DigitMap Syntax defined in [RFC3015]. Using the "|" (or) construct, the digitPattern MAY contain more than one match pattern. There SHOULD be exactly one digitPattern element in a digitMap element. callPriority - The callPriority element contains the the value "normal" or "emergency". For calls initiated with digit strings that match the digitPattern contained in the digitMap, the callPriority element may be used to set the assocated priority of the call. The user agent SHOULD give call processing priorities to calls initiated with a callPriority of value "emergency" appropriate for emergency service E911 calls. There MAY be at most one callPriority element in a digitMap element. The default value for the callPriority element is "normal". uriTemplate - The uriTemplate element defines how the user agent SHOULD form the INVITE request URI for a given digit string. The uriTemplate element contains a string which MAY contain the variable "{digits}". If the uriTemplate element value contains "{digit}", the "{digits}" string is substitued with the actual digit string that the use dialed to form the INVITE request URI. So for the example digitMap elements above, if the user dialed the string 918005551212, the resulting INVITE request URI would be: "sip:918005551212@example.com". outboundId - The outboundId element MAY be included in the digitMap element to indicate which identity from the identity dataset (see draft-petrie-identity-dataset-00.txt) is to be used for the outbound call. The aor element value from the sipIdentity element which has an "id" attribute value matching the value of the outboundId element, is used as the From header field value in the INVITE. The digitMap element SHOULD contain at most one outboundId element. There may be multiple sources of the digitMap across the device and Petrie, et al. Expires April 26, 2007 [Page 6] Internet-Draft VoIP Features Data Set October 2006 user profiles. All digitMap elements SHOULD be used in the order found in the device and user profiles. Order is important as a dialed string of digits may match multiple patterns defined in the digitPattern elements. The first digitMap element containing a digitPattern element that matches the user dialed digit string is used. 2.3. callWaiting Call Waiting is a feature where the user while on a call in an establish INVITE dialog can receive indication of incoming INVITE for a new dialog. When call waiting is enabled, the uesr agent SHOULD give indication of incoming INVITEs for new dialogs if a INVITE dialog is already established. When call waiting is disabled, the user agent SHOULD send a 486 Busy response to incoming INVITE requests for new dialogs if an INVITE dialog is already established. callWaiting - is an XML element that extends on the XML setting element contained in the root "propertySet" element. It may provide by the device and/or user profile. The callWaiting element contains the value: "enable" or "disable". The default value is "enable". If multiple callWaiting elements appear in accross the device and user profiles, the first appearance will be used when searching through the device and then user profiles. 2.4. callTransfer Element callTransfer - This property specifies a container for callTransfer, and is an XML element that extends on the XML setting element contained in the root "propertySet" element. For user agents that support the Call Transfer feature, this property defines the default behavior for the transfer operation on the user agent. Typically the user agent will have a function key or button or locally processed * code sequence which invokes the transfer operation. If the user agent support multiple types of transfer operation, the callTransfer element specifies which is the default operation. If the user agent supports only one method of performing transfer, the callTransfer element SHOULD be ignored by the user agent. The values for the callTransfer element are "blind", "consult" or "none". "blind" indicates that only the REFER method SHOULD be used for transfer, but the "Replaces header SHOULD not used. "consult" indicates that the REFER method SHOULD be used and the "Replaces header SHOULD be used in the transfer operation. "none" indicates that the user agent SHOULD not expose or allow the transfer operation to the user. See [I-D.ietf-sip- cc-transfer] for descriptions and call flows for blind and Petrie, et al. Expires April 26, 2007 [Page 7] Internet-Draft VoIP Features Data Set October 2006 consultative transfer. The callTransfer element may be provided in either the Device or User profiles. If both the Device and User profiles contain callTransfer elements, than the callTransfer element found first when searching through the device and then user profiles will be used. Note: [I-D.petrie-sipping-profile-datasets] defines a mechanism to disable blind or consultative transfer at a protocol level. For example the following will disable transfer completely: REFER The following will disable consultative transfer: replaces This is not the intended function of the callTransfer element. The callTransfer element specifies that the default transfer operation is either blind or consultative. 3. Security Considerations Security is mostly a profile delivery problem. The delivery framework MUST provide a secure means of delivering the profile data as it may contain sensitive data that would be undesirable if it were stolen or sniffed. Storage of the profile on the profile delivery server and user agent is an implementation problem. The profile delivery server and the user agent MUST provide protection that prevents unauthorized access of the profile data. The profile delivery server and the user agent MUST enforce the access control policies defined in the profile data sets if present. 4. IANA Considerations XML name space registration: urn:ietf:params:xml:ns:uaprof:voip 4.1. Content-type registration for 'application/uapvoip+xml' Petrie, et al. Expires April 26, 2007 [Page 8] Internet-Draft VoIP Features Data Set October 2006 To: ietf-types@iana.org Subject: Registration of MIME media type application/uapvoip+xml MIME media type name: application MIME subtype name: uapvoip+xml Required parameters: (none) Optional parameters: charset Indicates the character encoding of enclosed XML. Default is UTF-8. Encoding considerations: Uses XML, which can employ 8-bit characters, depending on the character encoding used. See RFC 3023 [RFC 3023], section 3.2. Security considerations: This content type is designed to carry SIP user agent profile data, which may be considered private information. Appropriate precautions should be adopted to limit disclosure of this information. Interoperability considerations: This content type provides a common format for exchange of SIP user agent profile information. Published specification: RFC XXXX (Note to RFC Editor: Please fill in XXXX with the RFC number of this specification) Applications which use this media type: SIP user agents and profile delivery servers. Additional information: Magic number(s): File extension(s): Macintosh File Type Code(s): Person & email address to contact for further information: Daniel Petrie EMail: dan.ietf AT sipez DOT com Intended usage: LIMITED USE Author/Change controller: This specification is a proposed work item of the IETF SIPPING working group, with mailing list address: sipping@ietf.edu. Other information: This media type is a specialization of application/xml [RFC 3023], and many of the considerations described there also apply to application/uapvoip+xml. 5. Change History [[RFC Editor: Please remove this entire section upon publication as an RFC.]] 5.1. Changes from draft-petrie-sipping-voip-features-dataset-00 Defined XML name space for schema: "urn:ietf:params:xml:ns:uaprof:voip" Defined mime type: application/uapvoip+xml for schema. Changed names of elements, attributes and other data types which contained "-" or "_" to use camel case. Petrie, et al. Expires April 26, 2007 [Page 9] Internet-Draft VoIP Features Data Set October 2006 6. References 6.1. Normative References [I-D.ietf-sipping-config-framework] Petrie, D., "A Framework for Session Initiation Protocol User Agent Profile Delivery", draft-ietf-sipping-config-framework-09 (work in progress), October 2006. [I-D.petrie-sipping-profile-datasets] Petrie, D., "A Schema and Guidelines for Defining Session Initiation Protocol User Agent Profile Data Sets", draft-petrie-sipping-profile-datasets-03 (work in progress), October 2005. [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999. [RFC3015] Cuervo, F., Greene, N., Rayhan, A., Huitema, C., Rosen, B., and J. Segers, "Megaco Protocol Version 1.0", RFC 3015, November 2000. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller Preferences for the Session Initiation Protocol (SIP)", RFC 3841, August 2004. [W3C.REC-xml-20001006] Paoli, J., Maler, E., Bray, T., and C. Sperberg-McQueen, "Extensible Markup Language (XML) 1.0 (Second Edition)", World Wide Web Consortium FirstEdition REC-xml-20001006, October 2000, . [W3C.REC-xml-names-19990114] Layman, A., Hollander, D., and T. Bray, "Namespaces in XML", World Wide Web Consortium Recommendation REC-xml- names-19990114, January 1999, . Petrie, et al. Expires April 26, 2007 [Page 10] Internet-Draft VoIP Features Data Set October 2006 6.2. Informational References [I-D.ietf-sip-cc-transfer] Sparks, R., "SIP Call Control - Transfer", draft-ietf-sip-cc-transfer-05 (work in progress), May 2002. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3470] Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols", BCP 70, RFC 3470, January 2003. [W3C.REC-xmlschema-1] Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, "XML Schema Part 1: Structures", W3C REC-xmlschema-1, May 2001, . [W3C.REC-xmlschema-2] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes", W3C REC-xmlschema-2, May 2001, . Appendix A. SIP Protocol Dataset Schema The following is the EBNF for the SIP VoIP Featrues data set using the format defined in [XML]. [Need to convert this to Relax NG] Note: name-addr is defined in the ABNF for SIP [RFC3261]. Petrie, et al. Expires April 26, 2007 [Page 11] Internet-Draft VoIP Features Data Set October 2006 Appendix B. Acknowledgments Petrie, et al. Expires April 26, 2007 [Page 12] Internet-Draft VoIP Features Data Set October 2006 Authors' Addresses Daniel Petrie SIPez LLC. 34 Robbins Rd. Arlington, MA 02476 US Phone: +1 617 273 4000 Email: dan.ietf AT SIPez DOT com URI: http://www.sipez.com/ Martin Dolly AT&T Labs 200 Laurel Avenue Middletowm, NJ 07748 US Phone: Email: mdolly AT att DOT com URI: Volker Hilt Bell Labs/Lucent Technologies 101 Crawfords Corner Rd Holmdel, NJ 07733 US Phone: Email: volkerh@bell-labs.com URI: Petrie, et al. Expires April 26, 2007 [Page 13] Internet-Draft VoIP Features Data Set October 2006 Intellectual Property Statement 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. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2006). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Petrie, et al. Expires April 26, 2007 [Page 14]