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
<mwi_properties>
<message_uri>sip:alice-voicemail@example.com</message_uri>
<mwi_status_uri>sip:alice@example.com</mwi_status_uri>
<mwi_indicator >enable</mwi_indicator)>
</mwi_properties>
<mwi_properties>
<message_uri>sip:1000@home.example.com</message_uri>
<mwi_status_uri>sip:alice@example.com</mwi_status_uri>
<mwi_indicator >enable</mwi_indicator)>
</mwi_properties>
<digit_map>
<digit_pattern>91xxxxxxxxxx|1xxxxxxxxxx</digit_pattern>
<call_priority>normal</call_type>
<uri_template>sip:{digits}@example.com</uri_template>
<outbound_identity>work</outbound_identity>
</digit_map>
<digit_map>
<digit_map>911|9911|91911</digit_map>
<call_priority>emergency</call_priority>
<uri_template>sip:911@10.1.1.100</uri_template>
</digit_map>
<digit_map>
<digit_pattern>011xxxT|0011xxxT</digit_pattern>
<call_priority>normal</call_priority>
<uri_template>
sip:{digits}@international.example.com
</uri_template>
</digit_map>
<call_waiting>enable</call_waiting>
<call_transfer>blind</call_transfer>
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:
<sip_method policy="disallow">REFER</sip_method>
The following will disable consultative transfer:
<sip_option_tags policy="disallow">replaces</sip_option_tags>
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, <http://www.w3.org/TR/xmlschema-1/>.
[W3C.REC-xmlschema-2]
Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes",
W3C REC-xmlschema-2, May 2001,
<http://www.w3.org/TR/xmlschema-2/>.
Appendix A. SIP Protocol Dataset Schema
The following is the EBNF for the SIP VoIP Featrues data set using
the format defined in [XML].
<!ELEMENT mwi_properties (message_uri?, mwi_status_uri,
mwi_indicator) >
<!ELEMENT message_uri (name-addr) >
<!ELEMENT mwi_status_uri (name-addr) >
<!ELEMENT mwi_indicator ("enable" | "disable") >
<!ELEMENT digit_map (digit_pattern, call_priority?, uri_template,
outbound_identity) >
<!ELEMENT digit_pattern ( TBD ) >
<!ELEMENT call_priority ("normal" | "emergency") >
<!ELEMENT uri_template ( TBD) >
<!ELEMENT outbound_identity (TBD) >
<!ELEMENT call_waiting ("enable" | "disable") >
<!ELEMENT call_transfer ("none" | "blind" | "consult") >
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]