Internet DRAFT - draft-brunner-sipping-sipautoconf
draft-brunner-sipping-sipautoconf
Sipping Working Group M. Brunner
Internet-Draft M. Stiemerling
Expires: April 17, 2006 S. Niccolini
NEC
October 14, 2005
Requirements and Framework for SIP User Agent Auto-Configuration
draft-brunner-sipping-sipautoconf-00
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 17, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
The problem of today's VoIP user agents (hardware terminals, SIP soft
phones) is the need for quite a bit of manual configuration at the
initialization time as well as when moving from one environment to
another. The information to be configured is typically not known by
the end-user. Automatic configuration of SIP user agents would
release the user of these configuration tasks. This memo describes
the challenges of auto-configuration of SIP user agents and gives
Brunner, et al. Expires April 17, 2006 [Page 1]
Internet-Draft SIP Auto-Conf October 2005
some requirements for further discussions.
Table of Contents
1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of the existing Solutions . . . . . . . . . . . . . . 3
3.1 DHCP Options . . . . . . . . . . . . . . . . . . . . . . . 3
3.2 Download configuration-file using FTP/TFTP/WebDAV . . . . 3
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1 Minimal Manual Intervention . . . . . . . . . . . . . . . 4
4.2 Works in different Environments with different Network
Attachment Points . . . . . . . . . . . . . . . . . . . . 4
4.3 Based on the SIP protocol . . . . . . . . . . . . . . . . 4
4.4 Support of SIP and non-SIP configurations . . . . . . . . 4
5. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5.1 Possibilities for Extending SIP . . . . . . . . . . . . . 5
5.2 Configuration Information . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1 Normative References . . . . . . . . . . . . . . . . . . . 6
7.2 Informative References . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 6
Intellectual Property and Copyright Statements . . . . . . . . 8
Brunner, et al. Expires April 17, 2006 [Page 2]
Internet-Draft SIP Auto-Conf October 2005
1. Problem Statement
The problem of today's VoIP user agents (hardware terminals, SIP soft
phones) is the need for quite a bit of manual configuration at the
initialization time as well as when moving from one environment to
another. The information to be configured is typically not known by
the end-user. Additionally, the information might depend on the
location of the terminal in the network (so the environment might
have changed, NATs, Firewalls, access speed, ...). Finally, also
service specific configurations typically require a certain degree of
configuration (e.g., the presence server location, etc.). Currently,
users are forced to enter this type of information manually into the
SIP phones, which is a cumbersome and error prone task. Users need
to edit configuration files or enter the configuration data into a
Graphical User Interface in the better case. However, a full
configuration set for SIP phones is likely to not be easily handled
by an everyday average user and automatic configuration of these user
agents is needed.
2. Assumptions
1. We assume that the IP configuration (e.g., IP address, netmask,
default router, etc) has happened beforehand, for example,
through DHCP or IPv6 auto-configuration.
2. Additionally, we assume that the SIP proxy to be used by that
user agent (home SIP proxy) can be found through DNS given the
SIP URI of the user, or received via DHCP as well.
3. Overview of the existing Solutions
3.1 DHCP Options
The has been standards for using DHCP options for automatically
configure the local SIP proxy [RFC3361] [RFC3319] the mechanisms can
be used for other configurations. However, only the local
configuration is possible to get through that mechanism. So in case
of different network attachment of the same terminal the mechanism
does not really work.
3.2 Download configuration-file using FTP/TFTP/WebDAV
Various product use different types of means to download a SIP client
configuration file from a server using FTP, TFTP, or WebDAV or other
means for getting a file. However, this requires an additional peace
of software to be installed on the user agent's device.
Brunner, et al. Expires April 17, 2006 [Page 3]
Internet-Draft SIP Auto-Conf October 2005
4. Requirements
4.1 Minimal Manual Intervention
Any user configuring a SIP client must only enter his SIP URI and
potentially some security relevant material such as a password.
Everything else must be done automatically.
4.2 Works in different Environments with different Network Attachment
Points
Since SIP terminals are getting mobile, the SIP client must
potentially get re-configured when attached to a network at a
different location. Or when the configuration of the network, in
which the terminal currently is located, changes due to a change in
configuration, the SIP client must be re-configured automatically.
4.3 Based on the SIP protocol
The benefit of using SIP is that it easily integrates with the
required SIP stack already available on the client. No other
protocols are required.
4.4 Support of SIP and non-SIP configurations
It should be possible to configure SIP related information as well as
non-SIP related information at the user agent through the auto-
configuration mechanism. Non-SIP configuration refers to further
information used in the process of getting a SIP session up and
running. For instance, configurations required for proper operation
of VoIP, such as STUN server, etc. (see a preliminary list of such
information below)
5. Framework
We need to differentiate two base cases, the initial configuration
per user and constant refinement and re-checking of the
configuration. The initial configuration is performed when the user
agent is plugged and/or switched on the very first time and when a
user utilizes a particular user agent the first time. In all this
cases the user has still to enter his SIP URI and authentication
material. In the phase of constant refinement the configuration
needs to change because the SIP proxy or other SIP infrastructure
devices have changed, or because the environment of the phone has
changed. Environment changes mainly apply to all NAT/FW issues and
to the potential requirements of using the local SIP proxy for the
SIP communication.
Brunner, et al. Expires April 17, 2006 [Page 4]
Internet-Draft SIP Auto-Conf October 2005
Extending the Session Initiation Protocol (SIP) protocol [RFC3261] to
automatically configure SIP user agents in fixed as well as in
dynamic environments has benefits. The SIP message exchanges between
SIP user agents and SIP proxies are used to provide the means of
setting configuration information to the SIP user agent. This
typically happens in one of the first SIP protocol exchanges between
the SIP proxy and the SIP user agent.
5.1 Possibilities for Extending SIP
Typically the first exchange is the SIP REGISTER message and its
reply from the SIP proxy (typically, but not limited to, a "401
UNAUTHORIZED" or "200 OK"). So this first SIP exchange can be used
for getting configurations from the SIP proxy to the SIP user agent.
Another possibility is the definition of a separate new message
exchange for the auto-configuration purpose only. This has the
benefit of separating concerns.
Finally, also the event mechanisms [RFC3265] could be used.
Basically subscribe for configuration events and than receiving
events containing the configuration information.
5.2 Configuration Information
Several configuration information relating to the SIP communication
should be transferred to the user agent including the following.
1. A list of other candidate SIP proxies.
2. The first and primary configuration information are SIP proxy
capabilities including the list and preferred transport protocols
available, and the list and preferred SIP proxy port numbers.
3. SIP stack settings (listen ports (SIP/RTP), timeout
configurations.)
4. Configuration information for SIP services including Presence
server location, push-to-talk (P2T) server, conference server,
...
5. if the network where the home SIP proxy is located is maintaining
a STUN server or known of one, the location of one or several
STUN servers will be configured, and also other STUN settings for
stack/client/server are part of the configuration information.
6. if the network where the home SIP proxy is located is maintaining
one or more Data (RTP) relay servers, the server location (e.g.
TURN server) is sent to the SIP user agent.
6. Security Considerations
There are security issues with configuring devices, and they need be
Brunner, et al. Expires April 17, 2006 [Page 5]
Internet-Draft SIP Auto-Conf October 2005
be tackled reasonably.
7. References
7.1 Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
Event Notification", RFC 3265, June 2002.
7.2 Informative References
[RFC3319] Schulzrinne, H. and B. Volz, "Dynamic Host Configuration
Protocol (DHCPv6) Options for Session Initiation Protocol
(SIP) Servers", RFC 3319, July 2003.
[RFC3361] Schulzrinne, H., "Dynamic Host Configuration Protocol
(DHCP-for-IPv4) Option for Session Initiation Protocol
(SIP) Servers", RFC 3361, August 2002.
Authors' Addresses
Marcus Brunner
NEC
Kurfuersten-Anlage 36
Heidelberg, D-69115
Germany
Phone: +49 6221 905 11 29
Fax: +49 6221 905 11 55
Email: brunner@netlab.nec.de
Brunner, et al. Expires April 17, 2006 [Page 6]
Internet-Draft SIP Auto-Conf October 2005
Martin Stiemerling
NEC
Kurfuersten-Anlage 36
Heidelberg, D-69115
Germany
Phone: +49 6221 905 11 13
Fax: +49 6221 905 11 55
Email: stiemerling@netlab.nec.de
Saverio Niccolini
NEC
Kurfuersten-Anlage 36
Heidelberg, D-69115
Germany
Phone: +49 6221 905 11 18
Fax: +49 6221 905 11 55
Email: saverio.niccolini@netlab.nec.de
Brunner, et al. Expires April 17, 2006 [Page 7]
Internet-Draft SIP Auto-Conf October 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.
Brunner, et al. Expires April 17, 2006 [Page 8]