SIPPING D. Petrie
Internet-Draft SIPez LLC.
Intended status: Best Current S. Channabasappa
Practice CableLabs
Expires: May 20, 2008 S. Ganesan
Motorola
November 17, 2007
The Session Initiation Protocol User Agent VoIP Features Data Set
draft-petrie-sipping-voip-features-dataset-02.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 May 20, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
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 May 20, 2008 [Page 1]
Internet-Draft VoIP Features Data Set November 2007
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-01 . . . . . . 9
5.2. 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 . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 13
Petrie, et al. Expires May 20, 2008 [Page 2]
Internet-Draft VoIP Features Data Set November 2007
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 May 20, 2008 [Page 3]
Internet-Draft VoIP Features Data Set November 2007
<mwiProperties>
<messageUri>sip:alice-voicemail@example.com</messageUri>
<mwiStatusUri>sip:alice@example.com</mwiStatusUri>
<mwiIndicator >enable</mwiIndicator)>
</mwiProperties>
<mwiProperties>
<messageUri>sip:1000@home.example.com</messageUri>
<mwiStatusUri>sip:alice@example.com</mwiStatusUri>
<mwiIndicator >enable</mwiIndicator)>
</mwiProperties>
<digitMap>
<digitPattern>91xxxxxxxxxx|1xxxxxxxxxx</digitPattern>
<callPriority>normal</callPriority>
<uriTemplate>sip:{digits}@example.com</uriTemplate>
<outboundIdentity>work</outboundIdentity>
</digitMap>
<digitMap>
<digitMap>911|9911|91911</digitMap>
<callPriority>emergency</callPriority>
<uriTemplate>sip:911@10.1.1.100</uriTemplate>
</digitMap>
<digitMap>
<digitPattern>011xxxT|0011xxxT</digitPattern>
<callPriority>normal</callPriority>
<uriTemplate>
sip:{digits}@international.example.com
</uriTemplate>
</digitMap>
<callWaiting>enable</callWaiting>
<callTransfer>blind</callTransfer>
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 May 20, 2008 [Page 4]
Internet-Draft VoIP Features Data Set November 2007
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 May 20, 2008 [Page 5]
Internet-Draft VoIP Features Data Set November 2007
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 May 20, 2008 [Page 6]
Internet-Draft VoIP Features Data Set November 2007
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
Petrie, et al. Expires May 20, 2008 [Page 7]
Internet-Draft VoIP Features Data Set November 2007
blind and 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:
<sipMethod policy="disallow">REFER</sipMethod>
The following will disable consultative transfer:
<sipOptionTags policy="disallow">replaces</sipOptionTags>
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 May 20, 2008 [Page 8]
Internet-Draft VoIP Features Data Set November 2007
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-01
Re-revved and activated draft
5.2. 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.
Petrie, et al. Expires May 20, 2008 [Page 9]
Internet-Draft VoIP Features Data Set November 2007
Changed names of elements, attributes and other data types which
contained "-" or "_" to use camel case.
6. References
6.1. Normative References
[I-D.ietf-sipping-config-framework]
Channabasappa, S., "A Framework for Session Initiation
Protocol User Agent Profile Delivery",
draft-ietf-sipping-config-framework-14 (work in progress),
November 2007.
[I-D.petrie-sipping-profile-datasets]
Petrie, D., "A Schema and Guidelines for Defining Session
Initiation Protocol User Agent Profile Datasets",
draft-petrie-sipping-profile-datasets-04 (work in
progress), November 2007.
[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]
Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler,
"Extensible Markup Language (XML) 1.0 (Second Edition)",
World Wide Web Consortium FirstEdition REC-xml-20001006,
October 2000,
<http://www.w3.org/TR/2000/REC-xml-20001006>.
[W3C.REC-xml-names-19990114]
Hollander, D., Bray, T., and A. Layman, "Namespaces in
XML", World Wide Web Consortium FirstEdition REC-xml-
Petrie, et al. Expires May 20, 2008 [Page 10]
Internet-Draft VoIP Features Data Set November 2007
names-19990114, January 1999,
<http://www.w3.org/TR/1999/REC-xml-names-19990114>.
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, <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]. [Need to convert this to Relax NG]
<!ELEMENT mwiProperties (messageUri?, mwiStatusUri,
mwiIndicator) >
<!ELEMENT messageUri (name-addr) >
<!ELEMENT mwiStatusUri (name-addr) >
<!ELEMENT mwiIndicator ("enable" | "disable") >
<!ELEMENT digitMap (digitPattern, callPriority?, uriTemplate,
outboundIdentity) >
<!ELEMENT digitPattern ( TBD ) >
<!ELEMENT callPriority ("normal" | "emergency") >
<!ELEMENT uriTemplate ( TBD) >
<!ELEMENT outboundIdentity (TBD) >
<!ELEMENT callWaiting ("enable" | "disable") >
<!ELEMENT callTransfer ("none" | "blind" | "consult") >
Petrie, et al. Expires May 20, 2008 [Page 11]
Internet-Draft VoIP Features Data Set November 2007
Note: name-addr is defined in the ABNF for SIP [RFC3261].
Appendix B. Acknowledgments
Authors' Addresses
Daniel Petrie
SIPez LLC.
34 Robbins Rd.
Arlington, MA 02476
US
Phone: +1 617 273 4000
Email: dan.ietf@SIPez.com
URI: http://www.sipez.com/
Sumanth Channabasappa
CableLabs
858 Coal Creek Circle
Louisville, CO 80027
US
Phone:
Email: sumanth@cablelabs.com
URI:
Sam Ganesan
Motorola
80 Central Street
Boxborough, MA 01719
US
Phone:
Email: sam.ganesan@motorola.com
URI:
Petrie, et al. Expires May 20, 2008 [Page 12]
Internet-Draft VoIP Features Data Set November 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Petrie, et al. Expires May 20, 2008 [Page 13]