SIPPING D. Petrie Internet-Draft SIPez LLC. Expires: April 20, 2006 M. Dolly AT&T Labs V. Hilt Bell Labs/Lucent Technologies Oct. 17, 2005 The Session Initiation Protocol User Agent VoIP Features Data Set draft-petrie-sipping-voip-features-dataset-00.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 20, 2006. Copyright Notice Copyright (C) The Internet Society (2005). 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 20, 2006 [Page 1] Internet-Draft VoIP Features Data Set Oct. 2005 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. mwi_properties Element . . . . . . . . . . . . . . . . . . 4 2.2. digit_map Element . . . . . . . . . . . . . . . . . . . . 5 2.3. call_waiting . . . . . . . . . . . . . . . . . . . . . . . 7 2.4. call_transfer Element . . . . . . . . . . . . . . . . . . 7 3. Security Considerations . . . . . . . . . . . . . . . . . . . 8 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Normative References . . . . . . . . . . . . . . . . . . . 9 5.2. Informational References . . . . . . . . . . . . . . . . . 9 Appendix A. SIP Protocol Dataset Schema . . . . . . . . . . . . . 10 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . . . 12 Petrie, et al. Expires April 20, 2006 [Page 2] Internet-Draft VoIP Features Data Set Oct. 2005 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: mwi_properties digit_maps, including identification of emergency numbers (e.g., 911) call_waiting call_transfer 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 20, 2006 [Page 3] Internet-Draft VoIP Features Data Set Oct. 2005 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 digit_map element above containing an outbound_identity element, the value "work" refers to the "id" attribute of a sip_identity 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. mwi_properties Element Message Waiting Indication (MWI) is a service where the subscriber can access their voice mail message using a message_uri, be informed on the status of unheard messages with a device depenendent Petrie, et al. Expires April 20, 2006 [Page 4] Internet-Draft VoIP Features Data Set Oct. 2005 indicator. mwi_properties - 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 "property_set" element. It serves as a container for mwi elements: message_uri mwi_status_uri mwi_indicator The message_uri and mwi_status_uri elements have values of type string that contain a SIP uri of the form name-addr from [RFC3261]. message_uri - The optional message_uri element MAY contain the URI to use for retrieving messages. There MAY be zero or one message_uri element in mwi_properties element. mwi_status_uri - The mwi_status_uri element contains the SIP URI used to subscribe to MWI event package [RFC3841]. Exactly one mwi_status_uri element SHOULD be contained in mwi_properties. mwi_indicator - The mwi_indicator element sets the new message indication behavior of the user agent when there are new or unheard messages for the resource contained in mwi_status_uri element provided by the MWI event package [RFC3841]. The values of the mwi_indicator 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 mwi_status_uri. 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. . mwi_properties elements may be provided in both the Device and User profiles. There may be multiple mwi_properties in the device and user profiles. All instances of mwi_properties 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 mwi_properties 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. digit_map Element Digitmaps allow the user agent to decide when user is done dialing. The digit_map element contains the call_priority element which allow the user agent to categorize the type of call according to digit string patterns (e.g. emergency vs normal). The digit_map element contains the uri_template element which defines how the user agent Petrie, et al. Expires April 20, 2006 [Page 5] Internet-Draft VoIP Features Data Set Oct. 2005 should construct the INVITE request URI based upon digits dialed. The uri_template element allow routing of the outbound call based upon the digit string patterns by providing different information in the INVITE request URI. The digit_map element can optionally contain a outbound_id element which allows the definition of which identity to use for the call based upon digit string patterns. The digit_map is an XML elelment that extends on the XML setting element contained in digit_maps. 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 digit_map element SHOULD contain exactly one digit_pattern element and one uri_template. The digit_map element MAY contain at most one call_priority element and one outbound_id element. digit_pattern - The digit_pattern element is of type string containing a digit map pattern using the DigitMap Syntax defined in [RFC3015]. Using the "|" (or) construct, the digit_pattern MAY contain more than one match pattern. There SHOULD be exactly one digit_pattern element in a digit_map element. call_priority - The call_priority element contains the the value "normal" or "emergency". For calls initiated with digit strings that match the digit_pattern contained in the digit_map, the call_priority 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 call_priority of value "emergency" appropriate for emergency service E911 calls. There MAY be at most one call_priority element in a digit_map element. The default value for the call_priority element is "normal". uri_template - The uri_template element defines how the user agent SHOULD form the INVITE request URI for a given digit string. The uri_template element contains a string which MAY contain the variable "{digits}". If the uri_template 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 digit_map elements above, if the user dialed the string 918005551212, the resulting INVITE request URI would be: "sip:918005551212@example.com". outbound_id - The outbound_id element MAY be included in the digit_map 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 sip_identity element which has an "id" attribute value matching the value of the outbound_id element, is used as the From header field value in the INVITE. The digit_map element SHOULD contain at most one outbound_id element. There may be multiple sources of the digit_map across the device and Petrie, et al. Expires April 20, 2006 [Page 6] Internet-Draft VoIP Features Data Set Oct. 2005 user profiles. All digit_map 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 digit_pattern elements. The first digit_map element containing a digit_pattern element that matches the user dialed digit string is used. 2.3. call_waiting 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. call_waiting - is an XML element that extends on the XML "setting_element" contained in the root "property_set" element. It may provide by the device and/or user profile. The call_waiting element contains the value: "enable" or "disable". The default value is "enable". If multiple call_waiting 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. call_transfer Element call_transfer - This property specifies a container for call_transfer, and is an XML element that extends on the XML "setting_element" contained in the root "property_set" 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 call_transfer element specifies which is the default operation. If the user agent supports only one method of performing transfer, the call_transfer element SHOULD be ignored by the user agent. The values for the call_transfer 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 Petrie, et al. Expires April 20, 2006 [Page 7] Internet-Draft VoIP Features Data Set Oct. 2005 flows for blind and consultative transfer. The call_transfer element may be provided in either the Device or User profiles. If both the Device and User profiles contain call_transfer elements, than the call_transfer 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 call_transfer element. The call_transfer 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 [Need to define a namespace for the VoIP Features data set.] 5. References Petrie, et al. Expires April 20, 2006 [Page 8] Internet-Draft VoIP Features Data Set Oct. 2005 5.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-07 (work in progress), July 2005. [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-02 (work in progress), July 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., Sperberg-McQueen, C., Bray, T., and E. Maler, "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C FirstEdition REC-xml-20001006, October 2000. [W3C.REC-xml-names-19990114] Hollander, D., Bray, T., and A. Layman, "Namespaces in XML", W3C REC REC-xml-names-19990114, January 1999. 5.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. Petrie, et al. Expires April 20, 2006 [Page 9] Internet-Draft VoIP Features Data Set Oct. 2005 [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]. Note: name-addr is defined in the ABNF for SIP [RFC3261]. Appendix B. Acknowledgments Petrie, et al. Expires April 20, 2006 [Page 10] Internet-Draft VoIP Features Data Set Oct. 2005 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 20, 2006 [Page 11] Internet-Draft VoIP Features Data Set Oct. 2005 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 (2005). 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 20, 2006 [Page 12]