C. Stredicke Internet Draft snom AG Document: draft-stredicke-sipping-ep-config-00.txt I. Butcher Expires: August 2002 Pingtel Corp. February 2002 SIP End Point Configuration Data Format 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. Abstract Mass deployment of SIP compliant devices requires a simple mechanism for configuring and maintaining them. For the economical success of SIP based devices on a large scale, a platform independent mechanism for finding and exchanging the required information is vital. The goal of this draft is to reduce the amount of effort required for administrators to provision devices. This draft focuses on defining a common data set to configure SIP end points. The mechanism for providing and maintaining the configuration data to the end point is defined elsewhere [7]. This Internet draft is a sub-package to SIP-Specific Event Notification [2]. Stredicke, Butcher Informational - February 2002 1 Table of Contents Status of this Memo................................................1 Abstract...........................................................1 1 Overview.......................................................4 2 Conventions used in this document..............................4 3 Configuration Setting Content Requirements.....................4 3.1 Device settings..............................................5 3.1.1 Device ID...................................................5 3.1.2 Proxy and Registration Settings.............................6 3.1.2.1 SIP Session Timer.........................................6 3.1.3 Network Related Settings....................................6 3.1.3.1 SIP Ports.................................................6 3.1.3.2 Type of Service...........................................6 3.1.3.2 Network parameters........................................6 3.1.3.3............................................................6 3.1.3.4 RTP Port range............................................7 3.1.3.5 External Network Address..................................7 3.1.3.6 HTTP Outbound proxy.......................................7 3.1.4 Line default settings.......................................7 3.1.4.1 Registration period.......................................7 3.1.4.2 Call handling.............................................7 3.1.4.3 Outbound Proxy............................................8 3.1.4.4 Default outbound line.....................................8 3.1.5 Address Completion..........................................8 3.1.5.1 Dial Plan.................................................8 3.1.5.2 Default digit map.........................................8 3.1.5.3 Overlap-Dial..............................................9 3.1.5 Audio.......................................................9 3.1.6..............................................................9 3.1.6.1 Codecs....................................................9 3.1.6.2 DTMF method...............................................9 3.1.6.3 Silence suppression.......................................9 3.1.7 Locale......................................................9 3.1.7.1 Daylight savings rule and time zone.......................9 3.1.7.2 Time server..............................................10 3.1.7.3 Language.................................................10 3.1.8 Inbound authentication.....................................10 3.1.8.1 Authentication enabled...................................10 3.1.8.2 Allowed Users............................................10 3.2 User settings...............................................11 3.2.1 User ID....................................................11 3.2.2 Voice mail settings........................................11 3.2.2.1 Message Waiting Indicator (MWI) address..................11 3.2.2.2 Retrieve address.........................................12 3.2.2.3 Deposit Address..........................................12 Stredicke, Butcher Informational - February 2002 2 3.2.3 Phonebook and Call History.................................12 3.2.3.1 Servers..................................................12 3.2.4 Ringer behavior............................................12 3.2.5 Ringer types...............................................12 3.3 Line Related Settings.......................................13 3.3.1 Line Identification........................................13 3.3.2 Registration period........................................13 3.3.3 Call handling..............................................13 3.3.3.1 Maximum connections......................................14 3.3.3.2 Available Behavior.......................................14 3.3.3.3 Busy Behavior............................................14 4 Configuration Detail Representation...........................16 4.1 Requirements................................................16 4.2 Proposed format.............................................16 4.3 Format Definition...........................................17 4.3.1 Handling Of Unrecognized Element Names.....................18 4.4 Example XML.................................................18 4.4.1 Device settings............................................18 4.4.1.1 Network Settings.........................................18 4.4.1.2 Address Completion.......................................19 4.4.1.3 Audio....................................................19 4.4.1.4 Line default settings....................................19 4.4.1.5 Line definition (device).................................19 4.4.2 User settings..............................................20 4.4.2.1 Voice mail settings......................................20 4.4.2.2 Line definition (user)...................................20 4.5 Grammar.....................................................21 5 IANA Considerations...........................................21 5.1 SIP Event Package Registration for configuration............21 5.2 MIME Registration for application/sip-endpoint-configuration 21 6 Security......................................................22 7 Open issues...................................................22 8 References....................................................24 9 Acknowledgements..............................................25 10 Author's Addresses............................................25 Stredicke, Butcher Informational - February 2002 3 1 Overview Popular networks like GSM and CDMA have shown that maintenance and installation costs may make up a significant part of the total cost of ownership of a network device. For the economical success of SIP based devices on a large scale, a platform independent mechanism for finding and exchanging the required information is vital. This allows operators to offer their services to a large number of different devices without caring about the specifics of the actual device. The goal of this draft is to reduce the amount of effort required for administrators to provision devices. Having a core set of configuration settings may allow plug-and-play type installation for the basic operations of a device. This would mean that users of those devices would not have to perform manual interaction with them to use basic services. While this draft defines the content of the configuration information, the exchange of the information (via http, tftp or other) is described in "A Framework for SIP User Agent Configuration" [7]. The term end point and device are used interchangeably in this draft but mean either a SIP telephone, SIP soft phone or SIP adapter (IAD). 2 Conventions used in this document In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and indicate requirement levels for compliant SIP guidelines implementations 3 Configuration Setting Content Requirements Settings are the information on a client that it needs to be a functional SIP end point. It is an implementation choice whether the device stores the data across power cycles and hardware restarts or it reloads the data every time upon startup. The configuration framework [7] supports either approach. The settings defined in this document are not intended to be all inclusive. It MUST be possible for vendor specific parameters to be added. Parameters which are not understood by an end point MUST be ignored. Configuration information related to the network identity of a device that can be discovered through other network protocols are not part of the configuration settings described in this document. Typical network identity configuration settings are IP address, netmask, IP gateway, DNS servers, host name, and domain. This information MAY be discovered through DHCP or defined via manual provisioning. Stredicke, Butcher Informational - February 2002 4 The list of available configuration settings includes settings that MUST, SHOULD or MAY be used by all devices (when present) and that make up the common denominator that is used and understood by all devices. However, the list is open to vendor specific extensions that support additional settings, which enable a rich and valuable set of features. Settings MAY be read-only on the device. This avoids the miss- configuration of important settings by inexperienced users producing service cost for operators. This draft describes how operator MAY protect some settings from end users. In order to achieve wide adoption of any configuration settings format it is important that it not be excessive in size so as to allow modest devices to use it. Any format should be structured enough to allow elegant extensions to it by vendors. A distinction made in this document is that settings pertain to devices, users or occasionally both. This separation of device and user is an important concept. A specific user is not always associated with a specific device. The separation allows user mobility from device to device. Certain network settings such as the default SIP port number and list of available codecs inherently belong to devices. Settings like registry servers and voice mail forwarding configuration belong to users. User mobility across devices and the ability to reassign users to different devices is provided through a means outside the scope of this document (see [7]). An end point typically has at least one address-of-record [9] for which it accepts SIP requests. In this document the address-of- record is said to represent an identity or line. A single user of an end point may have multiple lines. Line definitions can be associated with either devices or users. Devices may maintain their own line definition associated with the serial number, MAC address, physical location or an extension number. Users may have zero or more lines defined with a variety of addresses and identities (user name, extension number, sales associate, etc.). In order to ease definition of lines a group of settings for default line definition settings is provided. If a device or line definition does not provide a particular setting then the device SHOULD use the equivalent setting in the device line default settings if it exists. 3.1 Device settings 3.1.1 Device ID Stredicke, Butcher Informational - February 2002 5 A deviceÆs settings MAY include some unique identifier for the device it represents. This may be the MAC address, some manufacturer serial number or some other unique piece of data. 3.1.2 Proxy and Registration Settings 3.1.2.1 SIP Session Timer The re-invite timer allows user agents to detect broken sessions caused by network failures. A value indicating the number of seconds for the next re-invite for the re-invite period SHOULD be used by the device. 3.1.3 Network Related Settings 3.1.3.1 SIP Ports The port that MUST be used for a specific transport protocol MAY be indicated with the SIP ports setting. 3.1.3.2 Type of Service The Type of Service settings for outbound packets SHOULD be configurable for network packets associated with call signalling (SIP) and media transport (RTP/RTCP). For both categories of network traffic, the device SHOULD permit configuration of the type of service settings for both layer 3 (IP DiffServ) [16] and layer 2 (IEEE 802.1D/Q) [17, 18] of the networking stack. [Open issue: Should a device support more than one group of TOS settings for media transport? For example, a device might be configured for three different levels of service (e.g., Gold, Silver and Bronze). On a per call basis, the device user interface MAY permit the user to request which of the three level of service to use for media transport in that call.] [Open issue: Should the type of service be configurable based on codec type? For example, G.711 will use one set of TOS settings, G.729A will use a different set of TOS settings.] 3.1.3.3 Network parameters The parameters for SIP (like timer T1 [9]) and other network related settings MAY be indicated. Stredicke, Butcher Informational - February 2002 6 3.1.3.4 RTP Port range A range of port numbers MAY be used by a device for the consecutive pairs of ports which should be used to receive audio and control information (RTP and RCTP) for each concurrent connection. 3.1.3.5 External Network Address A network address (such as an IP address) MAY be used by devices which make calls through a NAT. The device includes this IP address in the SIP messages and SDP it sends to other SIP user agents to indicate that this is the address to which SIP, RTP and RTCP packets should be send. This supports the case where the NAT is configured to statically map specific ports on the external interface to a specific end point inside the NAT. The end point in turn is configured to spoof other SIP entities into thinking it is the external interface on the NAT. The address consists of a host name plus an optional port number, like sent-by in the Via header [9]. 3.1.3.6 HTTP Outbound proxy An outbound HTTP proxy server IP address and port number MAY be used in cases where the device both supports an HTTP client and requires HTTP traffic to use a proxy server. 3.1.4 Line default settings Default values which are used in cases where explicit values are not set on line definitions MAY be specified. This provides a mechanism for factoring out line definition settings. Not all line definition settings can be defaulted some such as identification are inherently bound to an individual line. 3.1.4.1 Registration period A line definition MAY contain a period (in seconds) which once exceeded will cause the device to re-register its registration server(s). 3.1.4.2 Call handling All of the call handling settings defined below (section 3.3.2) can be defined here as default behaviors. Stredicke, Butcher Informational - February 2002 7 3.1.4.3 Outbound Proxy The outbound proxy [9] for a line or for a device MAY be set. The address is encoded as SIP URI. The setting MAY contain alternative outbound proxies, which MAY be used in case of a server failure. 3.1.4.4 Default outbound line The default outbound line SHOULD be a global setting (not related to a specific line). This setting MUST not be used as part of a line definition. 3.1.5 Address Completion As most telephone users are used to dialing digits to indicate the address of the destination, there is a need for specifying the rule by which digits are transformed into a URL (usually SIP or TEL). 3.1.5.1 Dial Plan A dial plan which defines the maximum expected length of a typical telephone number SHOULD be used. Zero or more digit maps which map a dial plan and a SIP address to which phone numbers of that type should be routed SHOULD be supported. The digit maps define numeric patterns that when matched define: 1) a rule by which the end point can judge that the user has completed dialing and 2) a rule to construct a URL from the dialed digits and optionally 3) an outbound proxy to used in routing the SIP INVITE. [Open issue: Is there a standard for describing a dial plan? If yes, reference it, if no, describe the syntax.] A critical timer MAY be provided which determines how long the device should wait before dialing if a dial plan contains a ôTö character. It MAY also provide a timer for the maximum elapsed time which should be waited before dialing if the digits entered by the user match no dial plan. 3.1.5.2 Default digit map The end point MUST support the configuration of a default digit map. If the end point does not support digit maps it minimally must support a default digit map rule to construct a URL from digits. If Stredicke, Butcher Informational - February 2002 8 the end point does support digit maps, this rule applies if none of the digit maps match. 3.1.5.3 Overlap-Dial Some operators support overlap dialing [4] and MAY want to indicate to the SIP devices that this mode is to be used. This setting is Boolean and may be set to ôtrueö or ôfalseö. 3.1.6 Audio 3.1.6.1 Codecs In many cases operators want to control which codecs may be used in their network. The desired subset of codecs supported by the device MUST be configurable along with order of preference. The range for parameters of the codecs MUST be adjustable. This includes the packet length (msecs of audio), and the sample rate. However, the negotiation of the media for a calls is being done on a per call basis. 3.1.6.2 DTMF method DTMF allows different ways of indicating that a key has been pressed [14, 15]. The method for sending these events SHOULD be configurable with the order of precedence. 3.1.6.3 Silence suppression It SHOULD be possible to disable silence suppression on the end point such that RTP audio packets are sent even if silence is detected. 3.1.7 Locale Certain settings are dependant upon the devices regional location. 3.1.7.1 Daylight savings rule and time zone Different rules exist for when daylight saving time (DST) starts and ends. For example in North America begins on the first Sunday in April whereas in Western Europe is begins on the last Sunday in March. A DST rule MAY be used by the device. Stredicke, Butcher Informational - February 2002 9 An offset from Coordinated Universal Time (UTC) in seconds MAY be used. A timzeone MAY be specified for the user. Where one is specified it SHOULD use the scheme used by the Olson Time Zone database [12]. Examples of the database naming scheme are ôAsia/Dubaiö or ôAmerica/Los_Angelesö where the first part of the name is the continent or ocean and the second part is normally the largest city on that timezone. 3.1.7.2 Time server The network addresses of SNTP time servers where the device can get a centrally defined time MAY be used. 3.1.7.3 Language Setting the correct language is important for simple installation around the globe. A language MAY be specified for a device. Where it is specified it SHOULD use the codes defined in RFC3066 [11] to provide some predictability. It is RECOMMENDED that servers set the Language as writable, so that the user may change this. This setting SHOULD NOT be line related. 3.1.8 Inbound authentication SIP allows a device to limit incoming signaling to those made by a predefined set of authorized users with valid passwords. 3.1.8.1 Authentication enabled A device SHOULD the setting as to whether authentication (on the device) is required and what type of authentication is required : NONE or DIGEST 3.1.8.2 Allowed Users If inbound authentication is enabled then a list of users and credentials which are allowed to call this device SHOULD be used by the device. The credentials contain the same data as the credentials for a line (i.e. URL, user, password digest and realm). This applies to SIP control signaling as well as call initiation. For example who is allowed to send a REFER or an INVITE with the Join or Replaces header. Stredicke, Butcher Informational - February 2002 10 3.2 User settings 3.2.1 User ID A device MAY specify the user which is currently registered on the device. This SHOULD be an address-of-record URL specified in a line definition. The purpose of specifying which user is currently assigned to this device is to provide the device with the identity of the user whose settings are defined in the user section. This is primarily interesting with regards to user roaming. Devices may allow users to sign-on to them and then request that their particular settings retrieved [7]. Likewise a user may stop using a device and want to disable their lines while not present. For the device to understand what to do it must have some way of identifying users and knowing which user is currently using it. By separating the user and device properties it becomes clear what the user wishes to enable or disable. Providing an identifier in the configuration for the user gives an explicit handle for the user. For this to work the device must have some way of identifying users and knowing which user is currently assigned to it. One possible scenario for roaming is an administrator who has definitions for several lines (e.g. one or more personal lines and one for each executive for whom the administrator takes calls) that they are registered for. If the administrator goes to the copy room they would sign-on to a device in that room and their user settings (including their lines) would roam with them. The alternative to this is to require the administrator to individually configure all of the lines individually (which would be particularly irksome using standard telephone button entry). The management of user profiles, aggregation of user or device lines and profile information from multiple management sources are configuration server concerns which are out of the scope of this document (see [7]). However the ability to uniquely identify the device and user within the configuration data enables easier server based as well as local (i.e. on the device) configuration management of the configuration data. 3.2.2 Voice mail settings 3.2.2.1 Message Waiting Indicator (MWI) address The MWI address setting controls where the client MAY SUBSCRIBE [8] to a voice mail server. Stredicke, Butcher Informational - February 2002 11 3.2.2.2 Retrieve address An address MAY be used by the device so it can get any voicemail messages it has. 3.2.2.3 Deposit Address An address MAY be used to specify where voicemail messages should be left if the device is unable or unwilling to take a call. 3.2.3 Phonebook and Call History Phonebook directory servers can provide a centralized store of phone numbers/addresses and potentially other information. A common example being LDAP directory servers. DeviceÆs call history, a record of the last calls made and received may also be stored in a centralized location and referenced from devices. If the phone maintains only one last dialed number, it should compare incoming Last-Calls header against tried and dialed and store the newest entry. Devices that are not able to differentiate call history entries between "tried" and "dialed" SHOULD use "dialed". 3.2.3.1 Servers Zero or more servers MAY be used for storing phonebook directories or call histories. If a server is defined and address such as a URL MUST be used and user name and credentials MAY be used for that server. A server MAY be used for storing the phonebook and call history. The flush timeout MAY be specified for the server. Users MAY wish to limit the number of data items that are returned to their device if a query is issued against one of the directory servers. 3.2.4 Ringer behavior The manner in which a user is alerted to an incoming call (visually, audibly or possibly both) MAY be used by the device. This includes the different volumes and MAY point to a file that contains the melody. 3.2.5 Ringer types Stredicke, Butcher Informational - February 2002 12 Ringer sound files MAY be specified for the following types of incoming calls normal, high priority, internal and external. 3.3 Line Related Settings Many SIP devices support only one identity. These devices should ignore all line related settings that do no affect the default outbound line settings they receive. Phones SHOULD maintain read access information on a per line basis. If this is not possible, phones SHOULD mix the permissions on a common denominator basis, that means if one of the settings is read only, all settings are read only. 3.3.1 Line Identification A line represents an address-of-record [9] 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. Lines may be defined for a device or a user of the device. At least one line MUST be defined in the configuration settings, this may pertain to either the device itself or the user. A line MUST provide a address or record URL which both distinguishes the line and provides the URL which optionally will be registered for the line. A user friendly display name SHOULD be taken from the address-or-record URL for the line. A line definition MUST specify whether the line should automatically register with a registration server. It MUST be possible to specify at least one set of realm, user name and authentication credentials for each line. The user name and authentication credentials are used upon authentication challenges [9]. A line definition MUST use call handling settings and the state of the phone to determine how to handle inbound calls. Inbound calls may be rejected, redirected, or accepted. 3.3.2 Registration period A line definition MAY contain a period (in seconds) which once exceeded will cause the device to re-register its registration server(s). 3.3.3 Call handling Stredicke, Butcher Informational - February 2002 13 Call Handling settings define how the phone reacts to a new incoming call given different situations. In some cases, an end user may want to redirect calls to another party, rejected the call, or accepted the call and alert the end user. Some settings tend to be change irregularly like their voicemail forwarding address while others settings such as the do not disturb state may change often. 3.3.3.1 Maximum connections A setting defining the maximum number of simultaneous connections that a device can support MUST be used by the device. Obviously the end point has some maximum limit, however this allows the limit to be set to a lower number. 3.3.3.2 Available Behavior The Available Behavior defines how a new call is handled when the phone is not actively engaged in a call or when Call Waiting is enabled. Options include RING (ôringö) and FORWARD_ON_NO_ANSWER (ôforwardö). A setting of RING alerts the user (as defined by the Ringer Behavior in 3.2.3) for a practical length of time before returning an error response to the caller if not answered. FORWARD_ON_NO_ANSWER should alert the user for a configured amount of time (Forward on No Answer Timeout) and if not answered, forward to the Forward on No Answer address. All end points MUST use an available behavior setting. The Forward on No Answer setting identifies the address forwarded to after an alerting call exceeds the Forward On No Answer Timeout period. End points MUST use this parameter if the available behavior is set to FORWARD ON NO ANSWER and MAY define this parameter otherwise. The Forward on No Answer Timeout defines the length of time that a user should be alerted for before the call is automatically redirect to the Forward on no answer SIP URL. This parameter is specified in seconds, where approximately 4 seconds is equivalent to a ring. End points MUST use this parameter if the available behavior is set to FORWARD ON NO ANSWER and MAY define this parameter otherwise. 3.3.3.3 Busy Behavior The Busy Behavior defines how a new call is handled when the phone is engaged in an active call and call waiting is disabled or when the phone has reached the maximum number of connections. Options include BUSY and FORWARD. A BUSY setting instructs the phone to respond with a 486/Busy here. A FORWARD setting redirects the caller Stredicke, Butcher Informational - February 2002 14 to the Forward on Busy Address. All end points MUST use a busy behavior setting. The Forward on Busy SIP URL setting identifies the address forwarded to when the end point is busy. The end point is considered busy if a call is active and call waiting is disabled and when the phone has reached the maximum number of simultaneous connections. Since this parameter is dependant on the busy behavior, end points MUST define this setting if the BUSY behavior is set to FORWARD and MAY define this setting otherwise. 3.3.3.3.1 Call Waiting Behavior Call Waiting controls the behavior of new calls when an existing call is already active and the device has not met the maximum number of connections. Options include ALERT and BUSY, where ALERT will alert the user as defined by the Ringing behavior and Available Behavior and BUSY will follow the busy behavior logic. All end points MUST use a call waiting behavior setting. 3.3.3.3.2 Unconditional Forwarding The Unconditional Forwarding setting allows end users or administrators to forward all inbound calls to a designated Unconditional Forwarding SIP URL. This is useful if one wants to temporarily redirect all calls to another end point and administrative access to the directory servers is unavailable. Options include ENABLE and DISABLE, where ENABLE indicates that all inbound calls will be redirected and DISABLE indicates that all inbound calls will be treated as specified by the available, busy, and call waiting behaviors. All end points MUST use unconditional forwarding. The Unconditional Forwarding SIP URL identifies the address that inbound calls are redirected to if Unconditional Forwarding is enabled. All end points MUST use the unconditional forwarding address if unconditional forwarding is enabled, otherwise they MAY use it. 3.3.3.3.3 Do Not Disturb The Do Not Disturb settings enables end users to quickly and easily enable and disable inbound calls for a particular line. Options include ENABLE and DISABLE, where ENABLE will handle a call as indicated by the Do Not Disturb Method and DISABLE allows normal call handling. This setting MUST be used by all end points. Stredicke, Butcher Informational - February 2002 15 This setting may seem redundant to other the parameters defined within call handling, however, it addresses both an end user need along with administrative requirements. In some configurations, an end point may be configured to return a BUSY response to an inbound call so that a user agent within the network can try another party. The same results are required for Do Not Disturb. Do Not Disturb Method MUST be able to support multiple methods of rejecting calls. Options include BUSY, FORWARD_ON_BUSY, and FORWARD_ON_NO_ANSWER. A setting of BUSY will return a BUSY response so that other network user agents can redirect the call as needed. FORWARD_ON_BUSY will redirect the call to the FORWARD_ON_BUSY SIP URL and FORWARD_ON_NO_ANSWER will for privacy reasons allow the caller to believe the call is alerting before forwarding to the Forward on No Answer SIP URL. 4 Configuration Detail Representation The section describes the requirements and format for an implementation of the settings described in section 3. 4.1 Requirements From reading section 3 it is apparent that many of the settings are composite and related. As the number and complexity of the settings grows it is useful from and administration point of view to be able to easily relate settings. This document recognizes that as features increase on devices so will the amount of settings. Any format proposed should be readily and intuitively extensible. 4.2 Proposed format This document proposes using XML as the file format for the configuration settings primarily for the reasons stated above. XML naturally maps the settings defined in section 3. Line-oriented formats such as RFC822 were also considered. XML is considered preferable in this instance primarily because line orientated formats tend to rely on clever naming to relate related settings. For example: Line.1.URL = sip:ibutcher@Pingtel.com Line.1.Realm.Pingtel.user = ibutcher Line.1.Realm.Pingtel.password = foobar Line.1.Realm.anyrealm.user = anyuser Line.1.Realm.anyrealm.password = anypass Line-oriented formats tend not to require any ordering of the lines that they contain. In the example of the line definition above the Stredicke, Butcher Informational - February 2002 16 individual lines need not be in the logical order shown. They could have all the URLs, passwords, etc. for all the lines together or even have the line definitions dispersed throughout the file. XML namespaces are a useful tool when processing documents which may contain elements from more than one source. The default namespace for any XML document using the definitions described in this document MUST define the default namespace in the root node with URL [open issue this URL isnÆt that significant do we need to provide an IETF specific one http://XXX]. Vendors may add their own content within the XML document but MUST provide qualified names with their own namespace. The general format for the XML is to have device and user elements as direct children of the root node. Those elements will contain all of the appropriate settings describe in section 3. An example of an extension to the timezone setting is show below. <settings xmlnshttp://someurl xmlns:acme=öhttp://amce.comö> <device> <id>00:d0:1e:00:1a:0e</id> à à <locale> <dstrule>NORTH AMERICA</dstrule> <timezone>America/Los_Angeles</timezone> <!-- vendor extension --> <acme:timezonedisplay>"PST"</acme:timezonedisplay > <timeserver>10.1.1.1</timeserver> <language>US:English</language> </locale> à à </device> <user/> </settings> 4.3 Format Definition The definitions of the elements and attributes will not be included in this version of the draft. Examples follow to illustrate some concepts of the format. A future version of this draft will expand upon and define the semantics of the elements and tags. Section 3 defines the requirements from which the XML elements and attributes will be derived. Stredicke, Butcher Informational - February 2002 17 4.3.1 Handling Of Unrecognized Element Names [Stolen from draft-ietf-impp-cpim-pidf-01.txt, should give reference] The default rule is that any element with an unrecognized name is ignored (i.e. having an unrecognized namespace URI, or an unrecognized local name within that namespace). This includes all of the element content, even if it appears to use recognized names. 4.4 Example XML This section aims to provide some samples of the settings defined in section 3. A complete grammar/schema definition is not provided at this point. 4.4.1 Device settings 4.4.1.1 Network Settings <network> <tcp> <port>5060</port> </tcp> <udp> <port>5060</port> </udp> <rtp> <ports>100</ports> </rtp> <dhcpLease>300</dhcpLease> <externalIpAddress>10.1.1.1</externalIpAddress> <httpOutboundProxy> <ipAddress>10.1.1.1</ipAddress> <port>80</port> </httpOutboundProxy> <ethnetDuplex value="full"/> </network> Stredicke, Butcher Informational - February 2002 18 4.4.1.2 Address Completion <addressCompletion> <dialplan length="10"/> <digitmap> <pattern>91XXXXXXXX</pattern> <targetAddress>sip:{digits}@provider1</targetAddress> <outboundProxy>proxy.provider1:port</outboundProxy> </digitmap> <digitmap> <pattern>011X*</pattern> <targetAddress>sip:internation</targetAddress> </digitmap> </addressCompletion> 4.4.1.3 Audio <audio> <codecs> <codec priority="1">G729</codec> <codec priority="3">G711</codec> <codec priority="2">aLAW</codec> </codecs> </audio> 4.4.1.4 Line default settings <lineDefaults> <outboundProxy>10.1.1.1</outboundProxy> <callHandling> <busy behavior=öbusyö/> <callWaiting behavior=öbusyö/> </callHandling> </lineDefaults> 4.4.1.5 Line definition (device) <line aor-url=ö<Extension 123>sip:1234@Pingtel.comö register=öprovisionö> <credential> <realm>Pingtel.com</realm> <userId>anon</userId> Stredicke, Butcher Informational - February 2002 19 <passToken>password</passToken> <credential> <callHandling> <maxConnections>2</maxConnections> <available behavior=öforward-no-answerö> <seconds>32<seconds> <url>sip:admin@acme.com</url> </available> </callHandling> </line> In this example the outbound proxy and call handling settings defined in the line default settings example SHOULD be used in addition to the line definition. 4.4.2 User settings 4.4.2.1 Voice mail settings <voicemail> <mwi>10.1.1.1</mwi> <retrieve>10.1.1.2</retrieve> </voicemail> 4.4.2.2 Line definition (user) <user> <id><Fred Bloggs>sip:fbloggs@Pingtel.com</id> <line aor-url=ö<Fred Bloggs>sip:fbloggs@Pingtel.comö register=öregisterö> <credential> <realm>Pingtel.com</realm> <userId>fredb</userId> <passToken>abdc342RRe</passYoken> <credential> <credential> <realm>provider1.com</realm> <userId>fredbloggs</userId> <passToken>bdc42jjRe</passToken> <credential> <callHandling> <available behavior=öbusyö/> </callHandling> </line> </user> Stredicke, Butcher Informational - February 2002 20 Credentials are supplied for two realms in this example. In this example the outbound proxy and call handling settings defined in the line default settings example SHOULD be used in addition to the line definition. 4.5 Grammar [Open issue: how should define this, DTD, XML Schema, WSDL ? To be filled in for next version of the draft] 5 IANA Considerations 5.1 SIP Event Package Registration for configuration Package name: configuration Type: package Contact: [Stredicke] Published Specification: This document 5.2 MIME Registration for application/sip-endpoint-configuration MIME media type name: application MIME subtype name: sip-endpoint-configuration Required parameters: none. Optional parameters: none. Encoding considerations: See SIP [3] message header definition. Security considerations: See the "Security Considerations" (Section 6) section in this document. Interoperability considerations: none Published specification: This document. Applications which use this media: SIP configuration server and clients subscribing to these servers. Additional information: 1. Magic number(s): N/A Stredicke, Butcher Informational - February 2002 21 2. File extension(s): N/A 3. Macintosh file type code: N/A 6 Security Configuration MAY contain sensitive information that SHOULD be protected. Examples include authentication information, private address books and call history entries. Because of this, it is RECOMMENDED to use an encrypted transport mechanism. Where devices use http this could be TLS [6]. For devices which use ftp or tftp for content delivery this can be achieve using symmetric key encryption. Access to retrieving configuration information is also an important issue. Both configuration server and clients SHOULD be able to do Digest authentication. A configuration server [7] SHOULD challenge a subscriber before sending configuration information 7 Open issues [Open issue: Should a device support more than one group of TOS settings for media transport? For example, a device might be configured for three different levels of service (e.g., Gold, Silver and Bronze). On a per call basis, the device user interface MAY permit the user to request which of the three level of service to use for media transport in that call.] [Open issue: Should the type of service be configurable based on codec type? For example, G.711 will use one set of TOS settings, G.729A will use a different set of TOS settings.] [open issue this URL isnÆt that significant do we need to provide an IETF specific one http://XXX] [Open issue: how should define this, DTD, XML Schema, WSDL ? To be filled in for next version of the draft] [Open issue: Reference RFC2445 for daylight savings and other time related settings?] [Open issue: Does using this configuration schema automatically mean we use SIP as signaling protocol? If we open the proposal for H.323, MGCP and others, we get a better acceptance, but the number of settings will significantly increase.] [Open issue: Should we use a tag for referencing nested configuration resources? That would allow a flexible way of Stredicke, Butcher Informational - February 2002 22 providing multiple lines, multiple profiles, etc; however would add additional complexity. Current concept is more fixed, but simpler.] [Open issue: Should we propose a reload time for refreshing the configuration? The configuration framework proposes a push technology, however, in simple environments polling could make sense] [Open issue: Should this draft be informational, best current practices or standards track?] Stredicke, Butcher Informational - February 2002 23 8 References [1] S. Bradner, "Key words for use in RFCs to indicate requirement levels," Request for Comments 2119, Internet Engineering Task Force, Mar. 1997. [2] Adam Roach, "SIP-Specific Event Notification," <draft-ietf-sip- events-01.txt>, IETF; November 2001. Work in progress. [3] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: session initiation protocol," Request for Comments 2543, Internet Engineering Task Force, Mar. 1999. [4] G. Camarillo, A. Roach, J. Peterson, L. Ong, "Mapping of ISUP Overlap Signalling to SIP", <draft-ietf-sip-overlap-01.txt>, IETF; August 2001. Work in progress. [5] M. Handley, V. Jacobson, "SDP: Session Description Protocol", Request for Comments 2327, Internet Engineering Task Force, April 1998 [6] T. Dierks and C. Allen, "The TLS protocol version 1.0," Request for Comments 2246, Internet Engineering Task Force, Jan. 1999. [7] D. Petrie, "A Framework for SIP User Agent Configuration", <draft-petrie-sip-config-framework-01.txt>, IETF; November 2001. Work in progress. [8] R. Mahy, I. Slain, ôSIP Event Package for Message Waiting Indicationö, <draft-mahy-sip-message-waiting-02.txt>, IETF; July 2001. Work in progress [9] Various Authors, ôSIP: Session Initiation Protocolö, draft-ietf- sip-rfc2543bis-07.txt, IETF; February 2002. Work in progress. [10] I. Slain ôConfiguration Parameters for IP Telephony End Systemsö, <draft-ietf-slain-sip-config-parameters-01.txt>, IETF, 2001. [11] H. Alvestrand ôTags for the Identification of Languagesö, <rfc3066.txt_number=3066>, RFC 3066, Network Working Group, January 2001. [12] P. Eggert, "Sources for time zone and daylight saving time data." Available at http://www.twinsun.com/tz/tz-link.htm. [13] Arango et al, ôMedia Gateway Control Protocolö, IETF, RFC 2705, October 1999. [14] S. Donovan, ôThe SIP INFO Methodö, IETF, RFC 2976, October 2000. Stredicke, Butcher Informational - February 2002 24 [15] H. Schulzrinne, S. Petrack, äRTP Payload for DTMF Digits, Telephony Tones and Telephony Signalsö, IETF, RFC 2833, May 2000. [16] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. [17] ISO/IEC 15802-3: 1998 ANSI/IEEE Std 802.1D, 1998 Edition, Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Common specifications - Part 3: Media Access Control (MAC) Bridges [18] IEEE Std 802.1Q-1998, IEEE Standards for Local and Metropolitan Area Networks: Virtual Bridged Local Area Networks 9 Acknowledgements We would like to thank Bob Andreasen, Steven Lass, Dan Petrie, Henry Sinnreich, Henning Schulzrinne and Rich Schaaf for their input and review of this document. We would also like to thank Henry Sinnreich for his help in coordination of this effort. Illya SlainÆs Internet Draft [10] provided and excellent starting point for this work. 10 Author's Addresses Christian Stredicke snom technology AG Pascalstr. 10e Phone: +49(30)39833-0 10587 Berlin, Germany Email: cs@snom.de Ian Butcher Pingtel Corp. 400 W. Cummings Park Phone: +1 781 938 5306 Woburn, MA USA Email: ibutcher@pingtel.com Stredicke, Butcher Informational - February 2002 25