Internet Engineering Task Force  SIP WG
INTERNET-DRAFT  Schulzrinne/Petrie
schulzrinne-sip-config-event-00.ps  Columbia U./Pingtel

March 24, 2001 Expires: August 2001

The SIP Configuration Event Packages

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 To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html.

Copyright Notice

Copyright (c) The Internet Society (2001). All Rights Reserved.

Abstract This document describes the SIP configuration event packages, used for configuring SIP-based end

systems.

1 Introduction

In large deployments of SIP-based Internet telephony devices (“SIP phones”, for short), manually configuring SIP and other related parameters manually is not feasible. In addition, we want to be able to support user interface configuration such as speed-dial lists, dial plans, small dowloadable applications or other services. Since configurations can change while the system is operational, we use the SIP event mechanism to inform end systems of these changes. Actual configuration data is typically transferred using a separate retrieval protocol. This specification describes a set of SIP events packages that enable such configuration. Each type of configuration is assigned its own event type, allowing end systems to subscribe only to configuration information of interest to them.

The event packages are named config-basic for basic configuration, …

We allow the SIP configuration server to be a separate entity, but it can be colocated with other SIP servers.

This specification does not describe the format of configuration information.

2 Operation

On start-up and after the subscription expiration, end systems subscribe to the desired configuration events. A device can subscribe to the same information under multiple identities, for example, the basic system identity, the main temporary “owner” of the device and visiting guests. For example, basic configuration information and dial plans may be device-specific, speed dial configuration is likely to be tailored to the owner while guests may run applets.

INTERNET-DRAFT  schulzrinne-sip-config-event-00.ps  March 24, 2001

Each system should subscribe to mac@local domain, where mac is the MAC address, expressed in hexadecimal with hyphen separators, e.g., 00-90-27-97-DA-48@example.com.

TBD: Should they be labeled as “type=device” or similar?

Colons are reserved in the “user” component of SIP URLs.

Note that systems may subscribe to configuration information in other networks (“home network”). Such subscriptions are routed like normal SIP requests.

(NOTE: It would be helpful if registration allowed indication of event types handled, so that the proxy can route the request to the right server and so that the registration server can register with the proxy for these events.)

The default subscription expiration interval is 12 hours (?). Systems should randomize their subscription intervals by half of the nominal value.

Before powering down, end systems should unsubscribe from the configuration information.

To avoid overloading the configuration server when a large number of end systems all wake up at approximately the same time, e.g., after a power failure, end systems should randomly delay their subscription, with the delay interval chosen uniformly between 0 and 60 seconds. Systems may multicast notifications containing common system parameters to speed up initial configuration. End systems must be able to perform basic SIP calls prior to receiving configuration information.

This requirement is motivated by the need to be able to complete emergency calls even if the configuration server has not yet responded or is unavailable.

The body of the SIP NOTIFY message typically contains data of type text/uri-list [1] pointing to the configuration information. URL schemes http [2] and tftp [?] are preferred. If several URIs are listed, the device may choose any of them. The order of the URIs listed has no significance.

3 Scaling Considerations

Configuration may suffer from scaling problems if large numbers of end systems request configuration updates simultaneously or subscribe to these updates. As pointed out, this may occur after power failures. Servers may drop subscription requests, leading to retransmissions and further traffic amplification. This specification addresses this by having SIP phones subscribe after a randomized delay. Unfortunately, scaling techniques such as reconsideration [3] are not applicable here. Additionally, servers distribute basic configuration information via multicast to avoid unnecessary duplicate retrievals by each SIP phone.

For very short configuration, it may be preferable to allow notifications to contain the actual data.

4 Modifying Configuration Data

We use the mechanism described in [4] to allow SIP clients to update their configuration information. TBD: The configuration server may be a separate server, so some mechanism needs to be found for the configuration server to obtain this information. It is possible that the configuration server can register (without a Contact header) or the server can use the new configuration method that has been proposed.

5 Security Considerations

While some of the configuration information is public or not particularly sensitive, configuration information such as speed dial lists or end-systems call handling scripts are sensitive. SIP phones and configuration servers must use appropriate authentication, using the same keys as for registration.

6 Authors’ Addresses

Henning Schulzrinne Dept. of Computer Science Columbia University 1214 Amsterdam Avenue New York, NY 10027 USA electronic mail: schulzrinne@cs.columbia.edu

Daniel G. Petrie Pingtel

References

[1] M. Mealling and R. Daniel, “URI resolution services necessary for URN resolution,” Request for Comments 2483, Internet Engineering Task Force, Jan. 1999.

[2] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, and T. Berners-Lee, “Hypertext transfer protocol – HTTP/1.1,” Request for Comments 2068, Internet Engineering Task Force, Jan. 1997.

[3] J. Rosenberg and H. Schulzrinne, “Timer reconsideration for enhanced RTP scalability,” in Proceedings of the Conference on Computer Communications (IEEE Infocom), (San Francisco, California), March/April 1998.

[4] J. Lennox and H. Schulzrinne, “Transporting user control information in SIP REGISTER payloads,” Internet Draft, Internet Engineering Task Force, Oct. 2000. Work in progress.

Full Copyright Statement

Copyright (c) The Internet Society (2001). 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 assigns.

This document and the information contained herein is provided on an ”AS IS” basis and THE IN-TERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WAR-RANTIES, 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.