SIPPING M. Dolly
Internet-Draft AT&T Labs
Expires: January 13, 2005 July 15, 2004
Data Content for SIP User Agent Profile Delivery
draft-dolly-sipping-config-content-01.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 January 13, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document defines the data content for providing profile data to
SIP user agents in support of the framework defined in
I-D.ietf-sipping-config-framework-03.txt and is intended to be input
to the data sets defined by
draft-petrie-sipping-profile-datasets-00.txt..
Conventions used in this document
RFC2119 [1] provides the interpretations for the key words "MUST",
"MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", and "OPTIONAL" found in this document.
Dolly Expires January 13, 2005 [Page 1]
Internet-Draft Config Content July 2004
I-D.ietf-sipping-config-framework-02.txt [6] provides the
interpretations for the terms "profile", "device", "profile content
server", "notifier", and "profile delivery server".
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Data Content . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Data Set Examples . . . . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 7
8. Change History . . . . . . . . . . . . . . . . . . . . . . . . 7
9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
10.1 Normative References . . . . . . . . . . . . . . . . . . . . 7
10.2 Informative References . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 8
A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 8
B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . 9
Dolly Expires January 13, 2005 [Page 2]
Internet-Draft Config Content July 2004
1. Introduction
This document defines the data content for providing profile data to
SIP user agents in support of the framework defined in
I-D.ietf-sipping-config-framework-02.txt [6]. The current framework
draft identifies two types of profiles, defined as "user" and
"device". It is anticipated, per discussion at the previous meeting,
that the draft 03 version will define a profile for "local".
The profile delivery framework is intended to enable a first phase
migration to a standard means of providing profiles to SIP user
agents. It is expected that UA vendors willbe able to use this
framework as a means of delivering their existing proprietary user
and device data profiles.
2. Overview
The three types of content to be defined are user, device and local.
The profile delivery server will provide the content or URI(s)
associated with the user and device profiles. The local profile is
optional and its content will be provided by the local domain serving
the SIP User Agent.
The content of the device profile is a function of the vendor, model,
and version parameters associted with the device, which are specified
by the vendor of the user agent. These parameters allow the profile
delivery server to provide different profiles based upon these
variables.
As noted in the framework, a default user maybe assigned to a device.
In this scenario the profile delivery server may provide the URI(s)
in the NOTIFY request for the default user when subscribing to the
device profile type. Effectively the device profile type becomes a
superset of the user profile subscription. The user type is still
useful in this scenario to allow the user agent to obtain profile
data or URI(s) for a user other than the default user. This provides
the ability to support a hoteling function where a user may "login"
to a local domain and obtain the content of the local profile.
3. Data Content
The data content list below is intended as input into the datasets to
be defined in draft-petrie-sipping-profile-datasets-00.txt.
The local data may be inputted by the subscriber or the local access
domain.
Elements of the User Data include:
Dolly Expires January 13, 2005 [Page 3]
Internet-Draft Config Content July 2004
-- Proxy and Registration Server URIs - IP addresses of the
primary SIP proxyand registration servers that will be used.
(address format is the in IP dotted-decimal notation)
--Preloaded Route Set
-- User Address of Record and Display Name - A user'sline
represents an address-of-record identified by a URL There are many
properties which may be associated with or should be applied to
the line or signaling addressed to or from the line. The display
name is the identifiation as it should appear for the Caller ID
associated with the user.
-- User Authentication Information and Other Credentials -
Authentication name - name used by the device for authenication
if a registration is challenged.
Authenication Password - Password used by the device for
athentication. The device may have a default logical password
(e.g., MAC IP address).
-- Privacy Settings - calling party presentation restriction.
-- Pre Media Configuration Parameters (e.g., Audio Configuration)
-- Dial Plan - A dial plan which defines the maximum expected
length of a typical telephone. Zero or more digit maps that map a
dial plan and a SIP address to which phone numbers of the type
should be routed. The digit maps define numeric patterns that when
matched define:
1) a rule by which the end point has to judge that the user has
completed dialing;
2) a rule to construct a URL from the dialed digits;
3) Optionally, an outbound proxy to be used in routing the SIP
INVITE.
Note: Intra-Digit and Howler tone timers are associated with
the dial plan.
The end point must support the configuration of a default digit
map.
Some operators support overlap dialing and may want the SIP
device to operate in that mode.
-- Progess Tone Settings - These include confirmation, reorder,
and "ring-ping" type tones.
-- ENUM Settings - IP address and port address of ENUM server.
-- International Settings - This may include language preference,
and default server addreses.
Dolly Expires January 13, 2005 [Page 4]
Internet-Draft Config Content July 2004
-- Call Forwarding and Redirection Settings - contains the forward
to/redirection addresses, conditions of forwarding/redirection,
and methiods used to forward/redirect.
-- Speed Dial Settings - users speed dial numbers and associated
device keys.
-- Local Control Feature Settings (e.g., transfer, conference) -
-- Alert Settings, including pre-caller alerting - The manner in
which a user is alerted to an incoming call (visually, audibly, or
possibly both) used by a device. This includes different volumes
and melodies. There may be a pointer to a file to obtain the
melody. Ringer sound files may be specified to alert the user to
the type of incoming call (e.g., normal, high priority, internal,
external).
-- URIs and timers for additional profile configuration - contains
URIs of functional specific servers (e.g., Voice Mail, Phonebook,
Directory).
-- Logging Settings
-- Firmware Upgrade
-- Response Status Code Handling - mapping of response status
codes to device final handling treatment (e.g., tones and
annoucements).
-- Protocol Data Sets - Contains SIP extensions, body types,
transport protocols (UDP, TCP, TLS, SCTP) or external protocols
(e.g., http) that need to be supported.
-- Media Data Set - This includes Codec DATA set, maximum number
of streams, allowed bandwidth per stream, IPaddresses/ports, etc.
-- RTP Parameters
RTP Port Range - A range of port numbers used by a device for
the consecutive pairs of ports that are used to receive audio
and ontrol information (RTP and RCTP) for each concurrent
connection.
-- SDP Payload Types
-- Audio Configurations
Dolly Expires January 13, 2005 [Page 5]
Internet-Draft Config Content July 2004
-- Firewall and NAT Support Parameters
NAT Address - WAN IP address of the NAT or firewall server. A
network address (such as an IP address) used by a device to
make calls through a NAT. The device includes this IP address
in the SIP messages and SDP it sends to the other SIP agents to
indicate that this is the adddress to which SIP, RTP, and RTCP
packets are be sent. This supports the case where the NAT is
configured to statically map specific ports on hte external
interface to a specific end point in side the NAT. The end
point in turn is configured to spoof other SIP entities into
thinking it is the external interface on the NAT.
Manual Network Addressing
Local Administration Settings
4. Data Set Examples
Telephony Prompts, Tones and Final Handling:
Audio Configurations
Alert Settings
International Settings (or at least tones)
Progess Tone Settings
Pre Media Configuration Parameters
Response Status Code Handling
5. IANA Considerations
This document introduces no requirements for IANA.
6. Security Considerations
Profiles may contain sensitive data such as user credentials. The
protection of this data depends upon how the data is delivered. If
the data is delivered in the NOTIFY body, SIP authentication MUST be
used for SUBSCRIPTION and SIPS and/or S/MIME MAY be used to encrypt
the data. If the data is provided via content indirection, SIP
authentication is not necessary for the SUBSCRIBE request. With
content indirection the data is protected via the authentication,
authorization and encryption mechanisms provided by the profile URL
scheme. Use of the URL scheme security mechanisms via content
indirection simpifies the security solution as the SIP event package
does not need to authenticate, authorize or protect the contents of
the SIP messages. Effectively the profile delivery server will
provide profile URL(s) to anyone. The URLs themselves are protected
via authentication, authorization and snooping (e.g., via HTTPS).
Dolly Expires January 13, 2005 [Page 6]
Internet-Draft Config Content July 2004
7. Open Issues
This section identifies issues yet to be addressed.
8. Change History
This section identifies changes to the document per draft revision.
9. Examples
This section is informative in nature. If there is a discrepancy
between this section and the normative sections above, the normative
sections take precedence.
10. References
10.1 Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC
3023, January 2001.
[3] 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.
[4] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[5] Daigle, L., van Gulik, D., Iannella, R. and P. Faltstrom,
"Uniform Resource Names (URN) Namespace Definition Mechanisms",
BCP 66, RFC 3406, October 2002.
10.2 Informative References
[6] Petrie, D., "A Framework for SIP User Agent Profile Delivery",
draft-ietf-sipping-config-framework-02.txt (work in progress),
February 2004.
[7] Rosenberg, J., "Obtaining and Using Globally Routable User
Agent (UA) URIs (GRUU) in the Session Initiation Protocol
(SIP)", draft-ietf-sip-gruu-01 (work in progress), February
2004.
[8] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L.,
Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
Dolly Expires January 13, 2005 [Page 7]
Internet-Draft Config Content July 2004
HTTP/1.1", RFC 2616, June 1999.
[9] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler,
"Extensible Markup Language (XML) 1.0 (Second Edition)", W3C
REC REC-xml-20001006, October 2000.
[10] Rosenberg, J. and H. Schulzrinne, "An INVITE Inititiated Dialog
Event Package for the Session Initiation Protocol (SIP",
draft-ietf-sipping-dialog-package-02 (work in progress), June
2003.
Author's Address
Martin Dolly
AT&T Labs
EMail: mdolly@att.com
Appendix A. Contributors
Many thanks to Rohan Mahy for for his input and guidance.
Appendix B. Acknowledgements
Thanks to Eric Burger on the use of the XML tools.
Dolly Expires January 13, 2005 [Page 8]
Internet-Draft Config Content July 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Dolly Expires January 13, 2005 [Page 9]
Internet-Draft Config Content July 2004
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Dolly Expires January 13, 2005 [Page 10]