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 © 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 some requirements for further discussions.

Table of Contents

1.  Problem Statement

2.  Assumptions

3.  Overview of the existing Solutions
    3.1.  DHCP Options
    3.2.  Download configuration-file using FTP/TFTP/WebDAV

4.  Requirements
    4.1.  Minimal Manual Intervention
    4.2.  Works in different Environments with different Network Attachment Points
    4.3.  Based on the SIP protocol
    4.4.  Support of SIP and non-SIP configurations

5.  Framework
    5.1.  Possibilities for Extending SIP
    5.2.  Configuration Information

6.  Security Considerations

7.  References
    7.1.  Normative References
    7.2.  Informative References

§  Authors' Addresses
§  Intellectual Property and Copyright Statements

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] (Schulzrinne, H., “Dynamic Host Configuration Protocol (DHCP-for-IPv4) Option for Session Initiation Protocol (SIP) Servers,” August 2002.) [RFC3319] (Schulzrinne, H. and B. Volz, “Dynamic Host Configuration Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) Servers,” July 2003.) 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.

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.

Extending the Session Initiation Protocol (SIP) protocol [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) 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] (Roach, A., “Session Initiation Protocol (SIP)-Specific Event Notification,” June 2002.) 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 be tackled reasonably.

7. References

7.1. Normative References

7.2. Informative References

Authors' Addresses

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 © 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.