SIP Telephony Device Requirements, Configuration and Data Internet Draft - Informational S. Lass/WorldCom draft-sinnreich-sipdev-req-00.txt D. Petrie/Pingtel Date: November 2002 H. Sinnreich/WorldCom Expires: June 2003 C. Stredicke/snom AG SIP Telephony Device Requirements, Configuration and Data draft-sinnreich-sipdev-req-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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. Abstract This informational I-D describes the requirements for SIP Telephony devices, based on the deployment experience of large numbers of SIP phones and PC clients using different implementations. The document reviews the generic requirements for SIP telephony devices, the automatic device configuration process, the device configuration data and examples for XML configuration data formats. SIP telephony devices are highly complex IP endpoints that speak many Internet protocols, have text, audio and visual interfaces, various input modes, and require functionality targeted at several constituencies: (1) End users, (2) service providers and network administrators and (3) manufacturers and system integrators. The objectives of the requirements are a minimum set of interoperability and multi-vendor supported core features, so as to enable similar ease of purchase, installation and operation as found for standard PCs, analog feature phones or mobile phones. draft-somefolks-sipdevice-req-00 [Page 1] SIP Telephony Device Requirements, Configuration and Data Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1]. The syntax and semantics used here extend those defined in SIP, [2]. Table of Contents 1. Introduction...................................................3 2. Generic Requirements...........................................3 3. Configuration Processes.......................................12 4. Configuration Settings and Data...............................17 4.1 General Behavior..........................................17 4.2 Device ID.................................................18 4.3 Proxy and Registration Settings...........................18 4.4 Network Related Settings..................................18 4.5 Address Completion........................................20 4.6 Audio.....................................................20 4.7 Local and Regional Parameters.............................21 4.8 Inbound authentication....................................21 4.9 Voice mail settings.......................................22 4.10 Phonebook and Call History...............................22 4.11 Ringer Behavior..........................................23 4.12 User Related Settings....................................23 4.13 Line Related Settings....................................24 4.14 Registration period......................................25 4.15 Maximum connections......................................25 4.16 Call handling............................................25 4.17 Available Behavior.......................................25 4.18 Busy Behavior............................................26 4.19 Call Waiting Behavior....................................26 4.20 Do Not Disturb...........................................27 5. Configuration Data Representation.............................27 5.1 Configuration Data Format - Examples......................27 5.2 Format Definition.........................................28 5.3 Handling of Unrecognized Element Names....................28 5.4 Example XML Configuration Data............................29 6. IANA Considerations...........................................31 7. SIP Telephony Device Security.................................32 8. Acknowledgements..............................................32 9. Authors Addresses.............................................32 10. References...................................................33 draft-somefolks-sipdevice-req-00 [Page 2] SIP Telephony Device Requirements, Configuration and Data 1. Introduction This informational I-D has the objective of focusing the Internet communications community on requirements for SIP Telephony devices. We base this information on experience from developing and using a large number of SIP telephony devices types and on the experience gained from large scale deployments in private IP networks and on the Internet. This experience has shown the need for generic requirements for SIP telephony devices. SIP telephony devices, also referred to as SIP User Agents can be any type of IP networked computing device enabled for SIP based IP telephony. SIP telephony devices can be SIP phones, adaptors for analog phones, conference speakerphones, and software packages (soft clients) running on PCs, laptops, wireless connected PDAs, as well as mobile and cordless phones that support SIP signaling for real time communications. SIP devices MAY also support various other media besides voice, such as text, video, games and also possibly other Internet applications; however the non-voice requirements are not specified in this document, though we believe they need to be kept in mind. SIP telephony devices SHOULD meet the requirements in this document. The objectives of the requirements are a minimum set of interoperability and multi-vendor supported core features, so as to enable similar ease of purchase, installation and operation as found for standard PCs, analog feature phones or mobile phones. Given the cost of some screen phones or enterprise phones may approach the cost of PCs and PDAs, and the larger number of phones compared to PCs, similar or better ease of use as compared to personal computers and networked PDAs is expected by both end users and network administrators. As will be seen from the following, SIP telephony devices are highly complex IP endpoints that speak many Internet protocols, have audio and visual interfaces and require functionality targeted at several constituencies: (1) End users, (2) service providers and network administrators and (3) manufacturers and system integrators. 2. Generic Requirements We present here a minimal set of requirements that MUST be met by all SIP telephony devices, as specified here, except where SHOULD or MAY is specified. Link Layer Requirements SIP devices MUST support either: draft-somefolks-sipdevice-req-00 [Page 3] SIP Telephony Device Requirements, Configuration and Data Link-1: Wired Ethernet IEEE 802.3 10Base-T 10 Mb/s Half Duplex, or Link-2: Wireless Ethernet 802.11b and or 802.11a, SIP devices MAY also support other link layer protocols, such as Link-3: IEEE 802.3 10Base-T Full Duplex Link-4: IEEE 802.3 100Base-T Half Duplex Link-5: IEEE 802.3u 10/100Mb Auto-sensing Power over Ethernet Power-1: SIP telephony devices intended for desktop use MAY support in-line power over Ethernet as specified in IEEE 802.3af. Integrated Switch/Hub SIP devices designed for wired Ethernet SHOULD have an uplink port such that another IP device, such as a personal computer, MAY share the network connection. SIP clients MUST prioritize the transmission of RTP traffic over the shared network connection. IP Requirements IP-1: SIP telephony devices MUST be able to acquire an IP address by: Automatic IP address configuration using DHCP, or Manual IP address entry from the device. IP-2: SIP devices MUST support multiple DNS entries. If the primary DNS server does not respond to a DNS request, a secondary DNS server MUST be queried. IP-3: SIP devices MUST support IPv4. IP-4: SIP clients MUST be able to set the IPv4 Precedence Field bits of the Type of Service (ToS) byte for media streams. SIP clients SHOULD also be able to set the delay bit, the throughput bit, and the reliability bit. SIP User Agent Services SIP-1: SIP telephony devices MUST support RFC 3261 [2]. SIP-2, DNS SRV: SIP clients MUST t support RFC2782 [3] and MAY support the SIP service examples [4] for basic PBX-like or Centrex- like functions. SIP clients MUST support DNS SRV for locating a SIP Server. When making a SRV query, the client MUST t use the DNS draft-somefolks-sipdevice-req-00 [Page 4] SIP Telephony Device Requirements, Configuration and Data additional information in the response that contains the IP addresses for the A records. If the DNS additional information is not present, the client MUST make DNS A record queries to resolve the hostnames. SIP-3, Do Not Disturb: SIP clients MUST be able to set the state of the client as Do Not Disturb. Clients MUST respond to new INVITES with a ô486 Busy Hereö. Clients MUST respond to re-INVITES on existing call legs as normal behavior [4]. SIP-4, call hold resume: SIP clients MUST be able to place a call on hold/resume [4]. SIP-5, multiple calls: SIP clients MUST be able to support at least two or more calls. By placing the current call ôon holdö, the client MUST be able to initiate or receive another call [4]. SIP-6, call waiting indicator: SIP clients MUST support a call waiting indicator. When already participating in a call, the user MUST be alerted audibly and/or visually of another incoming call. The user MUST be able to enable/disable call waiting. SIP-7, message waiting indicator: SIP clients MUST support SIP message waiting and an indicator for integration with voicemail platforms [5]. SIP-8, local dial plan: SIP clients MUST support a local dial plan. The dial plan MUST consist of a pattern string to match dial digits, and the ability to strip, append prefix digits, and/or append suffix digits and send messages directly to another SIP device, bypassing the proxy. If the destination SIP device is specified as an IP address, the SIP client MUST not attempt to resolve the address with DNS. If the destination SIP device is a string value, the SIP client MUST make normal DNS SRV and A record queries. SIP-9, transfer: SIP devices MUST support REFER and NOTIFY as required to support the transfer [6]. SIP clients MAY support escaped headers in the Refer-To: header. SIP-10, unattended transfer: SIP devices MUST support an unattended transfer [3], [4]. SIP clients MAY support escaped headers in the Refer-To: header. SIP-11, attended call transfer: SIP devices MUST support attended call transfer [3], [4]. SIP clients MAY support escaped headers in the Refer-To: header. SIP-12, music on hold: SIP devices MUST support music on hold [4]. draft-somefolks-sipdevice-req-00 [Page 5] SIP Telephony Device Requirements, Configuration and Data SIP-13, client-based conferencing: SIP devices MUST be able to support handset based conferencing. A SIP client MUST be able to initiate and mix the audio streams of at least 2 separate calls (i.e. 3 way conference calling). SIP-14, DMTF in-band mixing: SIP devices MUST generate in-band DTMF tones for use with the G.711 codec. SIP-15: DTMF RTP payload: SIP clients MUST be able to send DTMF specified by RFC2833 [7]. Payload type negotiation MUST comply with RFC 3264 [8]. Payload type MUST remain constant throughout the session. For example, if an endpoint decides to renegotiate codecs or put the call on hold, the payload type for the re-invite MUST be the same as initial payload type. SIP-16, 180 ignores earlier media: SIP devices MUST generate local ringing and ingore any early RTP media when a ô180 Ringingö response is received. SIP-17, play single early media stream: SIP devices MUST play the first RTP stream and ignore any other RTP media streams when a ô183 Session Progressö response is received. SIP-18, use the last 18x message received: SIP devices MUST obey the last 18x message received when multiple 18x responses are received. If the last response is ô180 Ringingö, the client MUST generate local ringing. If the last response is ô183 Session Progressö, the client MUST play the RTP stream. SIP-19, error-info support: SIP devices MUST support the Error-Info header. SIP-20, reason phrase display: If the ôReason Phraseö of a response message is displayed, the client MUST use ôReason Phraseö in the response packet. The client MUST not use an internal ôStatus Codeö table. Another SIP device MAY respond with ô403 Forbiddenö, or various other messages. SIP-21, fax support: SIP adapter devices (for analog phone lines) MUST support the ITU-T T.38 standard [9]using UDPTL [10]. SIP clients MUST fallback to G.711 if T.38 fails. SIP-22, multi-line support: Multi-line SIP devices MAY register using more than one set of credentials. draft-somefolks-sipdevice-req-00 [Page 6] SIP Telephony Device Requirements, Configuration and Data SIP-23, multi-line do not disturb: SIP devices MUST be able to set the state of the client to Do Not Disturb on a per line basis. Clients MUST respond to new INVITES with a ô486 Busy Hereö. Clients MUST respond to re-INVITES on existing call legs as normal. SIP-24, multi-line call waiting indicator: Multi-line SIP devices MUST support multi-line call waiting indicators. When already participating in a call, the user MUST be alerted audibly and/or visually of another incoming call. This setting MUST be provisioned by the user. SIP devices with multiple identities (ie. registrations/lines) MUST allow Call Waiting Indicator to be set on a per identity basis. If call waiting is set for an identity, the client MUST respond with ô486 Busy Hereö when an incoming call to that identity is received and the client has an existing call with any of the identities. SIP-25, Dynamic login/logout for user mobility: SIP devices MUST support user mobility. SIP clients MUST store a static profile in non-volatile memory so that this information is available during the power up sequence. SIP clients MUST allow a user to walk up to a client, login, and be able to send and receive calls with his profile information. For emergency numbers (e.g. 911) the client MUST send the credentials (username/password) of the static profile. SIP-26, multi-line ring tones: SIP devices MUST be able to provision a different ringtone for each line (ie. registration or static identity). SIP Related Protocols SDP: SIP devices MUST support Session Description Protocol, RFC2327 [11]. RTP/RTCP: SIP devices MUST support Real-Time Protocol and Real-Time Control Protocol, RFC1889 [12]. SIP Security SIPsec-1, SIP Digest Authentication: SIP devices MUST support SIP Digest Authentication [2] SIPsec-2, password protection: SIP devices MUST be able to password protect configuration information and administrative functions. SIPsec-3, disabling of remote services: SIP devices MUST be able to disable remote access, i.e. block incoming SNMP, HTTP, and other services not necessary for basic operation. SIPsec-4, INVITE user portion acceptance: SIP devices MAY be able to reject an incoming INVITE when the message does not come from the draft-somefolks-sipdevice-req-00 [Page 7] SIP Telephony Device Requirements, Configuration and Data proxy or proxies where the client is registered. For DNS SRV specified proxy addresses, the client MUST accept an INVITE from all of the resolved proxy IP addresses. Voice Codecs Internet telephony devices face the problem of supporting multiple codecs due to various historic reasons, on how industry players have approached codec implementations and the serious intellectual property and licensing problems associated with most codec types. Many, but not all voice codec payload types are described in RFC 1890 [13] and other IETF MMUSIC WG [14] documents. Codec-1: Three main classes of voice codecs are supported by Internet telephony devices: SIP telephony devices MUST support AVT payload type 0 [G.711 uLaw] as the default codec. The packet size MUST be 20 milliseconds. The matching ITU-T Appendix I and Appendix II decoders SHOULD also be supported. Compressed codecs such as G.729 derived from delta-PCM encoding, found in private networks with frugal bandwidth using frame relay or DSL access MAY be supported. The narrow bandwidth codecs such as G.723.1 with such low speed (5.3 and 6.3 kb/s without RTP/UDP/IP overhead) as to work well even on dial-up access MAY be supported. A compressed codec for Internet use without license fee is on the IETF standards track [15], MUST be supported. Voice codecs used in 2nd generation mobile phone systems, such as various GSM codecs are also found in various implementations and MAY be supported. Wideband codecs using typically 16 kHz voice sampling for better- than-PSTN voice quality, such as G.722 and GIPS MAY be supported. Such codecs are found in conferencing systems to increase the value of conferencing. Note: A summary count reveals up to and more than 15 voice codec types currently in use. The authors believe there is a need for a single multi-rate Internet codec that can effectively be substituted for all the multiple codec types listed here and avoid the complexity and cost implementers and service providers alike are faced by supporting so many codec types, including especially those that have not been developed specifically for Internet use. Codec-2, codec negotiation: Endpoints MUST follow these guidelines in RFC 3264 : Initiator specifies "preferred" codec. draft-somefolks-sipdevice-req-00 [Page 8] SIP Telephony Device Requirements, Configuration and Data Receiver has "final" choice of codec selected. Both endpoints MUST use first codec listed by the receiver. If an endpoint cannot dynamically switch between available codecs, it MUST offer a single codec and send a new INVITE with another codec if the original fails due to the SIP 488 Media Unsupported message. Codec-3, comfort noise: SIP device MAY support comfort noise generation [16]. It is also RECOMMENDED that SIP clients comply with the "handset receive comfort noise" requirements outlined in the ANSI/EIA/TIA-810-A-2000 standard. Voice-Telephony Requirements Voice-1, loudness: SIP telephony devices MUST conform to the electro- acoustical requirements for send loudness rating (SLR), receive loudness rating (RLR), weighted terminal coupling loss (TCLw), stability loss, etc.) of TIA/EIA-810-A standard [17], [18]. Stability loss is a measure of the contribution of the telephone set or terminal to the overall connection stability requirements. Stability loss is defined as the minimum loss from the terminal digital input (receive) to the terminal digital output (transmit), at any test frequency. Voice-2, stability loss: SIP device SHOULD meet the following stability loss requirements: The stability or minimum loss, per ITU-T G.177, TIA/EIA-810-A [17], [18 ] and TIA/EIA-579-A, at any voiceband frequency SHOULD be greater than 6 dB, and preferably greater than 10 dB. Digital telephone sets or terminal equipment with adjustable receive level SHOULD maintain stability over the entire range of adjustable receive levels. Voice-3, speakerphone: SIP devices MAY provide a full-duplex speakerphone with echo and side-tone cancellation. Voice-4, programmable ring-tones: SIP device MAY be able to use different ring-tones based on the caller identity (ie. From header). International Requirements International-1, language support: SIP devices MAY indicate the preferred language using SIP Caller Preferences [19]. The setting for this header MUST be provisioned. International-2, international display support: SIP devices MAY support other languages for menus, help, and labels. Applications Requirements draft-somefolks-sipdevice-req-00 [Page 9] SIP Telephony Device Requirements, Configuration and Data The following requirements apply to functions placed in the SIP telephony device. App-1, automatic ring-down: SIP devices MAY support a ôbat phoneö setup where a URL is automatically dialed when the client goes off- hook. App-2, hold ring-back: SIP devices MAY ring after a call has been on hold for a predetermined period of time, typically 3 minutes. This time value MUST be provisioned. App-3, LDAP phonebook: SIP devices MAY support LDAP for client-based directory lookup. App-4, address-book integration: SIP devices MUST allow a 3rd party to initiate a call for the client. [20]. App-5, SIMPLE Integration: SIP devices MUST provide a ôbuddy- list/addressbookö and use SIP extensions to leverage presence [21]. Web-based Feature Management Web-1: SIP devices MUST support a web server to allow users to manually configure the phone and to setup phone services such as the address book, speed-dial, ringer tones, and last but not least the call handling options for the various lines, aliases, in a user friendly fashion. Web pages to manage the SIP telephony device MAY be supported by the individual device, or in managed networks from centralized web servers. Managing SIP telephony devices SHOULD NOT require special client software on the PC or on a management console. Web-2: The telephone settings MUST be accessible to authenticated users or operations personnel from remote locations. Firmware Update Firm-1: SIP devices MUST be able to upgrade their firmware as described in section 4. Firewall/NAT Traversal Requirements The following requirements allow SIP clients to properly function behind various firewall architectures: FW/NAT-1, outbound proxy support: SIP devices MUST support a default domain. SIP devices MUST have the capability to be configured so that the default domain and the proxy are different. The provisioned user identity on the device MUST include a full URL to be included in the SIP From: header or a provisioned domain name MUST be appended. Configuration Information draft-somefolks-sipdevice-req-00 [Page 10] SIP Telephony Device Requirements, Configuration and Data Name: userA Proxy Address: sip.outbound.domain.com Domain: domain.com Example Message sent to sip.outbound.domain.com REGISTER sip:domain.com SIP/2.0 To: sip:userA@domain.com From: sip:userA@domain.com Contact: sip:10.10.10.215 FW/NAT-2, NAT capable configuration: SIP devices MUST be able to operate behind a static NAT/PAT (Network Address Translation/Port Address Translation) device using the STUN protocol [x22]. SIP clients MUST be able to populate SIP messages with the public, external address of the NAT/PAT device and use specific port ranges for RTP. FW/NAT-3, UPnP capable configuration SIP devices MUST be able to operate with a UPnP (http://www.upnp.org/) firewall device. Device Interfaces SIP telephony devices MAY have various types of interfaces, such as resembling a desktop phone, cordless phone, mobile phone, handheld computer, laptop computer or with various interface models, such as for phones, IM or personal organizer. Given the variety of possible interfaces, the generic requirements only can be listed here. Int-1: SIP telephony devices MUST have a telephony-like dial-pad and MAY have telephony style buttons like mute, redial, etc. Int-2: SIP telephony devices MUST have a convenient way for entering SIP URLs and phone numbers. This includes all alphanumeric characters allowed in legal SIP URLs. Possible approaches include using a web page, display and keyboard or graffiti for PDAs. Phone number entry SHOULD be supported in human friendly fashion, allowing the usual separators and brackets between digits and digit groups. Int-3: SIP telephony devices MUST have two types of interface capabilities, for phone numbers and URLs, accessible to the end user. SIP device configuration and management interface. The access to the SIP device configuration interface MAY be blocked by the service provider so as not allow misconfiguration of the settings. draft-somefolks-sipdevice-req-00 [Page 11] SIP Telephony Device Requirements, Configuration and Data End user options interface, such as personal address book, auto- forwarding, ringer tones, etc. Desktop and other phone-style SIP devices can meet the above requirements with a device web page. Device web pages also facilitate remote device settings from a help desk, without user intervention. Multiple Line Appearances SIP telephony devices SHOULD support multiple SIP registrars and outgoing proxies with different user aliases. Lines-1: SIP telephony devices MAY support multiple lines. Lines-2: SIP telephony device line settings MAY support different SIP registrars, SIP proxy servers and different user names and password on each line, as well as different authentication mechanisms, such as password or SIP digest authentication. 3. Configuration Processes Functional Configuration Groups The requirements for the configuration of a SIP user agent can be divided into the following high-level functions [23]: Discovery Enrollment Profile Retrieval Change Notification Profile Upload Security Data Container. These functional groups are intended only to provide a means to think about and organize the requirements. They are NOT REQUIRED to be discrete steps, and they are not intended to dictate a specific model. Discovery is the means by which a new SIP user agent can automatically discover how and where to enroll and retrieve desired device and user profile(s). Enrollment is the means by which the user agent makes the profile server(s) aware of its presence and desire of specific users and/or device profiles. Profile Retrieval is the means by which the user agent gets the desired profiles(s). draft-somefolks-sipdevice-req-00 [Page 12] SIP Telephony Device Requirements, Configuration and Data Change Notification is the means by which the profile server tells the user agent that profiles of interest have changed. Typically, the intention would be for the user agent to get those changes or the updated profiles. Profile Upload this is the means by which the user agent or other entities in the network can update or propagate changes to a profile on the server. The primary focus of security is on protecting the profiles from unauthorized access or change as well as integrity. Data Container is the container or object model for the profile data during transport to and from the server. The primary issues are structure and hierarchy. Generic Configuration Requirements The SIP telephony device configuration requirements in this document are understood to be part of a configuration framework that includes both end devices and configuration servers. The platforms (server and user agent) upon which this profile delivery framework MUST be deployed are very different in capability. The user agents are largely embedded systems with limited resources for code and data size as well as CPU power (pure software based user agents are less constrained). The profile server is likely to run on general purpose servers and therefore not as resource constrained. Roaming GenConf-1: The profile delivery framework MUST support the ability for profiles to roam. That is, a user MAY go to another user agent within the server domain and with proper authorization, the user agent MUST be able to retrieve the user profile from the server and use the profile. Open and Extensible for Vendor Implementations OpenExt-1: The profile framework MUST allow vendor differentiation on both the server and user agent sides. This is largely an issue of how easy it is to make a more intelligent or active server or client without breaking the standard. OpenExt-2: The profile framework MUST allow vendor differentiation on both the server and user agent sides. This is largely an issue of how easy it is to make a more intelligent or active server or client without breaking the standard. NAT/Firewall Support for Configuration draft-somefolks-sipdevice-req-00 [Page 13] SIP Telephony Device Requirements, Configuration and Data The primary issue relating to the profile delivery framework is the presence of NATs and/or firewalls between the profile server and the user agent. It is assumed that if NATs or firewalls are present (in between) the user agents are on the inside and the profile server is effectively on the outside (e.g. public Internet). NAT/FW-Conf-1: The user agent MUST be able to reach the profile server through a NAT or firewall to perform all of the functions in the delivery framework. NAT/FW-Conf-2: The firewall or NAT SHOULD NOT require any additional configuration to enable the profile delivery framework to work. It is assumed that certain protocols are typically enabled on the NAT or firewall by default (e.g. HTTP access to servers outside). It is assumed that SIP access in both directions is enabled or the user agent is not likely to be of much use. Discovery The purpose of discovery is to provide the means by which zero or minimal user interaction is required when plugging in a user agent for the first time in a specific profile server domain. It is likely there is no single protocol solution for discovery due to the wide variety of typical network configurations including but not limited to networks: not connected to the Internet, with no DHCP server [24], [25] with no DNS SRV support, with a non-configurable DNS server. DIS-1: The user agent SHOULD be able to discover the profile server without human input. DIS-2: It MUST be possible to manually set the location of the profile server for a user agent. This is primarily a user agent implementation issue, not a protocol issue. Enrollment ENR-1: A user agent MUST be able to provide a unique identity to the profile server which does not change for the life of the UA. This allows user and device profiles to be associated with a particular user agent. ENR-2: A user agent requiring profiles SHOULD make itself known to the profile server. ENR-3: The user agent MUST identify profiles that it requires. draft-somefolks-sipdevice-req-00 [Page 14] SIP Telephony Device Requirements, Configuration and Data ENR-4: The profile server MAY be provisioned to know what profiles a user agent needs by default. There are a number of reasons for the above requirements. In large scale deployments this MAY be important for load balancing purposes. This MAY be needed by the profile server so that it can understand which user agents are dependent upon which profiles. ENR-5: A user agent MAY request additional or different user profiles beyond the default provisioned for the user agent. This is primarily to support the notion of roaming. ENR-6: The user agent MUST provide specific information which MAY required by the server to customize the profile(s) for the user agent. It MAY be necessary to provide different views of a profile based upon the specific configuration of the user agent. (for example, Vendor, Model number, Software or firmware version, serial number, MAC address, etc.). ENR-7: It SHOULD be possible for the profile server to deliver different views of a profile based upon characteristics of the user agent. Though the objective is to provide a standardized profile that has the same content for all vendors user agents, in reality there are changes or differences to work around. That is it MAY be desirable to put intelligence in the profile server to work around differences in user agent behavior or changes in the standardized profile content specification. ENR-8: It MUST be possible to reassigned device-specific profiles, stored in the server, to a different user agent. This is to facilitate hardware swap out. ENR-9: It MUST be possible for the profile server, over time, to change the location(s) from which configuration data is retrieved. The intention is to allow server handoff as the result of failure, administration changes, load balancing, etc. ENR-10: The user agent SHOULD re-enroll periodically. The user agent basically SHOULD check in periodically with the profile server in case a network problem prevented change notification from getting to the user agent. Profile Retrieval RET-1: It MUST be possible for the user agent to retrieve the profile(s) it requires on demand. RET-2: It MUST be possible for the entire population of user agents to request and retrieve the required profiles in a short period of time. draft-somefolks-sipdevice-req-00 [Page 15] SIP Telephony Device Requirements, Configuration and Data This is a scalability requirement: e.g. during a power outage tens or hundreds of thousands of user agents MAY power up at once. Change Notification CN-1: The profile server MUST be able to notify dependent user agents of profile changes. CN-2: The user agent MUST be able to get the new updated profile. CN-3: The server MAY specify in advance that a configuration change is to occur. That is the profile server MAY schedule changes. CN-4: The user agent MAY defer making profile changes effective until it is safe to do so. Some profile changes MAY disrupt the operation of the user agent. The user agent SHOULD alert the user and use discretion as to whether the change will disrupt critical operation (e.g. a call) of the user agent. Profile Upload PU-1: A user agent MUST be able to upload changes to a profile on the profile server. This is to facilitate changes made either via a user interface on the user agent which are desired to be permanent as well as a means by which a external interface (e.g. a rich GUI on a general purpose computer) MAY interface with the profile server. PU-2: The profile server SHOULD provide an access control mechanism to constrain who can read, write, delete, or be notified about change to profile data. Security User and device profiles MAY contain sensitive data such as passwords and identities. It MUST be possible to protect the profiles and information about the profiles. SEC-1: The profile server SHOULD NOT provide access to profile data without authentication and authorization. SEC-2: The profile server MUST NOT allow a user agent to update profile data without authentication and authorization. SEC-3: The profile data, when transmitted over the network, SHOULD be protected against man in the middle attacks and snooping. draft-somefolks-sipdevice-req-00 [Page 16] SIP Telephony Device Requirements, Configuration and Data SEC-4: The profile server SHOULD NOT allow enrollment without authentication and authorization. SEC-5: The profile server SHOULD NOT provide change notification of profiles without authentication and authorization. SEC-6: The user agent SHOULD NOT interact with or trust any information from the profile server before authenticating the profile server. SEC-7: The information exchanged between the user agent and the profile server SHOULD be integrity protected. 3.2.8. Data Container DA-1: The data container MUST support hierarchical and structured data. Note: for a better understanding of rational for this requirement see [26]. DA-2: It MUST be possible to define a standardized set of profile data that all user agents SHOULD support. DA-3: It MUST be possible for user agent vendors to add vendor specific data without breaking the standardized data set or requiring the creation of additional profiles. DAR-4: The data container MUST be flexible enough to contain additional data without breaking the profile server or the user agent, e.g. non-standard, vendor specific or standard updates. DAREQ-5: The user agent MUST be able to determine the differences when a profile has changed. Note: This can be determined either by getting only the added, removed or changed data or by calculating the difference between two profiles. 4. Configuration Settings and Data 4.1 General Behavior Configuration information related to the network identity of a device that can be discovered is described in the preceding chapter 4. Besides network parameters, SIP telephony devices MAY also be configured with user data described here. 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 settings defined in this document are not intended to be all inclusive. It MUST be draft-somefolks-sipdevice-req-00 [Page 17] SIP Telephony Device Requirements, Configuration and Data possible for vendor specific parameters to be added. Parameters which are not understood by an end point MUST be ignored. 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 flexible extensions to it by vendors. Settings may belong to the device or to a ôlineö. When the endpoint acts in the context of a line, it will first try to look a setting up in the line context. If the setting can not be found in that context, the device will try to find the setting in the device context. If that also fails, the device MAY use a built-in value for the setting. The line concept allows configuration of phones in a user specific context. It simplifies unconstrained seating in offices and can support roaming users. In principle, all settings may be present in line and in device context. For some settings (e.g. the MAC address of the device), devices MAY set restrictions on the availability of settings in either line or device context. 4.2 Device ID A device setting MAY include some unique identifier for the device it represents. This MAY be an arbitrary device name chosen by the user, the MAC address, some manufacturer serial number or some other unique piece of data. 4.3 Proxy and Registration Settings Server-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. 4.4 Network Related Settings draft-somefolks-sipdevice-req-00 [Page 18] SIP Telephony Device Requirements, Configuration and Data Network-1: SIP Ports. The port that MUST be used for a specific transport protocol MAY be indicated with the SIP ports setting. Network-2: Quality of Service. The Quality of Service settings for outbound packets SHOULD be configurable for network packets associated with call signaling (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) [27] and layer 2 (IEEE 802.1D/Q) [28], [29] of the network protocol stack. Network-3: Network parameters. The parameters for SIP (like timer T1 [9]) and other network related settings MAY be indicated. Network-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. Network-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 [2]. Network-6: Outbound HTTP 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. Network-7: 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). The default value is one hour. Network-8: Default Call Handling. All of the call handling settings defined below in section 5.3.2 can be defined here as default behaviors. Network-9: 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. draft-somefolks-sipdevice-req-00 [Page 19] SIP Telephony Device Requirements, Configuration and Data Network-10: 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. 4.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). Dial-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. 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 pass before dialing if the digits entered by the user match no dial plan. Dial-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 MUST at least support a default digit map rule to construct a URL from digits. If the end point does support digit maps, this rule applies if none of the digit maps match. Dial-3: Overlap-Dial. Some operators support overlap dialing [2] 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. 4.6 Audio Audio-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 the order of preference. The range for parameters of the codecs MUST be adjustable. This includes the packet length (ms of audio), and the sample rate. However, the negotiation of the media for individual calls is being done on a per call basis. draft-somefolks-sipdevice-req-00 [Page 20] SIP Telephony Device Requirements, Configuration and Data Audio-2: DTMF method. DTMF allows different ways of indicating that a key has been pressed [30]. The method for sending these events SHOULD be configurable with the order of precedence. Audio-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. 4.7 Local and Regional Parameters Certain settings are dependant upon the devices regional location, such as the daylight saving time rules and the time zone. Regional-1: Time Zone. A time zone MAY be specified for the user. Where one is specified it SHOULD use the scheme used by the Olson Time Zone database [31]. 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 time-zone. Regional-2: UTC Offset. An offset from Coordinated Universal Time (UTC) in seconds MAY be used. 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. Regional-3: A DST rule MAY be used by the device. The network addresses of SNTP time servers where the device can get a centrally defined time MAY be used. Regional-4: The time server MAY be used. Setting the correct language is important for simple installation around the globe. Language-1: Language settings MAY be deployed. A language MAY be specified for a device. Where it is specified it SHOULD use the codes defined in RFC3066 [32] to provide some predictability. Language-2: It is RECOMMENDED that servers set the Language as writable, so that the user MAY change this. This setting SHOULD NOT be line related. 4.8 Inbound authentication SIP allows a device to limit incoming signaling to those made by a predefined set of authorized users from a list and/or with valid passwords. draft-somefolks-sipdevice-req-00 [Page 21] SIP Telephony Device Requirements, Configuration and Data In-Auth-1: A device SHOULD the setting as to whether authentication (on the device) is required and what type of authentication is REQUIRED: NONE or DIGEST In-Auth-2: If inbound authentication is enabled then a list of allowed users and credentials 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. The list shows for example who is allowed to send a REFER or an INVITE with the Join or Replaces header. 4.9 Voice mail settings Various voice mail settings require the use of URL's as specified in [33]. VM-1: The MWI address setting controls where the client MAY SUBSCRIBE [8] to a voice mail server. VM-2: A retrieve address MAY be used by the device so it can get any voicemail messages it has. VM-3: A deposit address MAY be used to specify where voicemail messages SHOULD be left if the device is unable or unwilling to take a call. 4.10 Phonebook and Call History IP Telephony devices can store locally a phonebook and also the history of recent calls. As an alternative, phonebook directory servers can provide a centralized store of phone numbers/addresses and potentially other information, such as provided by LDAP directory servers. Phonebook-1: SIP telephony devices MAY store telephone book entries locally and/or MAY use a central LDAP directory. A record of the last calls made and received MAY also be stored locally or in a centralized location and referenced from devices. Call Hisytory-1: SIP telephony devices MAY store locally a recent (limited) call history or MAY make use of a central server for call history. If the phone maintains only one last dialed number, it SHOULD compare the incoming Last-Calls header against tried and dialed and store the newest entry. draft-somefolks-sipdevice-req-00 [Page 22] SIP Telephony Device Requirements, Configuration and Data Devices that are not able to differentiate call history entries between "tried" and "dialed" SHOULD use "dialed". A server MAY be used for storing the phonebook and call history. PhoneServers-1: 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. 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. 4.11 Ringer Behavior Simple 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. 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. Ringer sound files MAY be specified for the following types of incoming calls normal, high priority, internal and external. Different ringer sound files MAY also be associated with different lines. 4.12 User Related Settings 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 be retrieved. 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. draft-somefolks-sipdevice-req-00 [Page 23] SIP Telephony Device Requirements, Configuration and Data 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. UserID-1: User ID MAY be specified. If the user ID is specified, the address-of-record URL MAY be specified for the line definition. 4.13 Line Related Settings 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. draft-somefolks-sipdevice-req-00 [Page 24] SIP Telephony Device Requirements, Configuration and Data 4.14 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). The default time is one hour. 4.15 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, most likely determined by the media handling capability. MaxConn-1: A SIP telephony device MAY support at least two connections for three-way conference calls that are locally hosted. 4.16 Call handling 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. Private networks and service provider networks MAY enable very sophisticated call handling options that MAY be supported more effectively on SIP servers, rather than in all SIP telephony devices. In such networks, call handling options in the SIP telephony device MUST be disabled to avoid feature interaction. CallOptions-1: Local call handling options like forwarding, such as to voice mail or other locations, available and busy behavior MUST have the option of being disabled locally, in case these services are provided by a SIP server. 4.17 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 and FORWARD_ON_NO_ANSWER. 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. Available-1: All end points MUST use an available behavior setting. Available-2: 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. draft-somefolks-sipdevice-req-00 [Page 25] SIP Telephony Device Requirements, Configuration and Data 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. 4.18 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 to the Forward on Busy Address. Busy-1: 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 dependent on the busy behavior, end points MUST define this setting if the BUSY behavior is set to FORWARD and MAY define this setting otherwise. 4.19 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. Fwd-1, 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. draft-somefolks-sipdevice-req-00 [Page 26] SIP Telephony Device Requirements, Configuration and Data 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. 4.20 Do Not Disturb The Do Not Disturb setting 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. 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. DND-1: 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. 5. Configuration Data Representation The section describes the requirements and format for an implementation of the settings described in section 3. Requirements for Configuration Data Representation From reading section 4 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. 5.1 Configuration Data Format - Examples The choice of the configuration data formats are best left to the discretion of the implementers and service providers. This document draft-somefolks-sipdevice-req-00 [Page 27] SIP Telephony Device Requirements, Configuration and Data illustrates however using XML as the file format for the configuration settings primarily for the reasons stated above. XML naturally maps the settings defined in section 5. 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 a URL. 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 data 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 5. An example of an extension to the time zone setting is show below. 00:d0:1e:00:1a:0e NORTH AMERICA America/Los_Angeles "PST" 10.1.1.1 US:English 5.2 Format Definition The definitions of the elements and attributes will not be included in this version of the draft, given that only examples are shown here. The examples follow to only illustrate some concepts of the format. Section 5 defines the requirements from which the XML elements and attributes will be derived. The authors believe the data format definitions and grammar for SIP telephony device configuration data SHOULD be the object of separate documents. 5.3 Handling of Unrecognized Element Names The default rule [34] 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. draft-somefolks-sipdevice-req-00 [Page 28] SIP Telephony Device Requirements, Configuration and Data 5.4 Example XML Configuration Data This section aims to provide some samples of the settings defined in section 5, using XML [35]. A complete grammar/schema definition is not provided here, since this serves as an example only. Device settings A. Network Settings 5060 5060 100 300 10.1.1.1 10.1.1.1 80 B. Address Completion 91XXXXXXXX sip:{digits}@provider1 proxy.provider1:port 011X* sip:internation C. Audio D. Line default settings 10.1.1.1 E. Line definition (device) Pingtel.com anon password 2 32 sip:admin@acme.com 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. User settings F. Voice mail settings 10.1.1.1 10.1.1.2 G. Line definition (user) <Fred Bloggs>sip:fbloggs@Pingtel.com draft-somefolks-sipdevice-req-00 [Page 30] SIP Telephony Device Requirements, Configuration and Data Pingtel.com fredb abdc342RRe provider1.com fredbloggs bdc42jjRe 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. 6. IANA Considerations SIP Event Package Registration for Configuration Package name: SIP Telephony Device Configuration Type: package Contact: [Stredicke] Published Specification: This document. MIME Registration for Application The MIME Registration for application/sip-endpoint-configuration is: 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" in Section 8 n this document. Interoperability considerations: none draft-somefolks-sipdevice-req-00 [Page 31] SIP Telephony Device Requirements, Configuration and Data 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 2. File extension(s): N/A 3. Macintosh file type code: N/A. 7. SIP Telephony Device Security The device 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 for configuration data. Where devices use HTTP this could be TLS [36]. 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 SHOULD challenge a subscriber before sending configuration information 8. Acknowledgements Ian Butcher from Pingtel and Jonathan Knight from WorldCom have contributed significantly to earlier versions of parts of this Internet Draft. The authors would like to thank Prof. Henning Schulzrinne from Columbia University and Jay Batson from PingTel for detailed comments to the draft. Peter Baker from Polycom has also provided valuable pointers to TIA/EIA IS 811 requirements to IP phones that are referenced here. 9. Authors Addresses Steven Lass WorldCom 400 International Parkway Richardson, TX 75081, USA EMail: steven.lass@wcom.com Phone: +1 972 729 4469 Daniel G. Petrie Pingtel Corp. 400 W. Cummings Park Suite 2200 Woburn, MA 01801, USA draft-somefolks-sipdevice-req-00 [Page 32] SIP Telephony Device Requirements, Configuration and Data Phone: +1 781 938 5306 Email: dpetrie@pingtel.com Henry Sinnreich WorldCom 400 International Parkway Richardson, TX 75081, USA EMail: henry.sinnreich@wcom.com Christian Stredicke snom technology AG Pascalstr. 10e 10587 Berlin, Germany Phone: +49(30)39833-0 Email: cs@snom.de 10. References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [2] J. Rosenber et. al.:"SIP: Session Initiation Ptotocol, RFC 3261, IETF, June 2002. [3] A. Gulbrandsen et. al "A DNS RR for specifying the location of services (DNS SRV)" RFC 2782, February 2000. [4] A. Johnston et al. "SIP Service Examples", IETF, June 2002, work in progress. [5] R. Mahy: "A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP)", IETF, October 2002, work in progress. [6] R. Sparks: "SIP Call Control - Transfer", IETF, July 2001, work in progress. [7] H. Schulzrinne et al: "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals', RFC 2833, IETF, May 2000. [8] J. Rosenberg and H. Schulzrinne: "An Offer/Answer Model with the Session Description Protocol (SDP)", RFC 3264, IETF, June 2002. [9] ITU-T Recommendation T.38, "Procedures for real-time Group 3 facsimile communication over IP networks", June 1998. [10] A. Johnston et al.: "Session Initiation Protocol Torture Test Messages". IETF, Feb. 2002, work in progress. draft-somefolks-sipdevice-req-00 [Page 33] SIP Telephony Device Requirements, Configuration and Data [11] M. Handley et al.: "SDP: Session Initiation Protocol", RFC 2327. IETF, April 1998. [12] H. Schulzrinne et al.: " RTP: A Transport Protocol for Real-Time Applications", RFC 1889, IETF, January 1996. [13] H. Schulzrinne et al.: "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 1890, IETF, January 1996. [14] The Multiparty Multimedia Session Control (mmusic) IETF working Group site, http://ietf.org/html.charters/mmusic-charter.html [15] Steven Andersen et. al.: "Internet Low Bit Rate Codec", IETF, September 2002, work in progress. [16] R. Zopf: "Real-time Transport Protocol (RTP) Payload for Comfort Noise (CN) ", RFC 3389, IETF, September 2002. [17] TIA/EIA-810-A, "Transmission Requirements for Narrowband Voice over IP and Voice over PCM Digital Wireline Telephones", July 2000. [18] TIA-EIA-IS-811, "Terminal Equipment - Peformance and Interoperability Requirements for Voice-over-IP (VoIP) Feature Telephones", July 2000. [19] H. Schulzrinne et. al.: " Session Initiation Protocol (SIP) Caller Preferences and Callee Capabilities", IETF, July 2002, work in progress. [20] J. Rosenberg et al.: " Best Current Practices for Third Party Call Control in the Session Initiation Protocol", IETF, June 2002, work in progress. [21] J. Rosenberg: " Session Initiation Protocol (SIP) Extensions for Presence", IETF, May 2002, work in progress. [22] J. Rosenberg et al. " STUN - Simple Traversal of UDP Through Network Address Translators", Internet Draft, IETF, April 2002, work in progress. [23] D. Petrie and C. Jennings: " Requirements for SIP User Agent Profile Delivery Framework", IETF, June 2002. Work in progress. [24] G.Nair, H.Schulzrinne , DHCP Option for SIP Servers, , IETF; March 1, 2002, Work in progress. draft-somefolks-sipdevice-req-00 [Page 34] SIP Telephony Device Requirements, Configuration and Data [25] M. Mealling and R. Daniel, "The naming authority pointer (NAPTR) DNS resource record," Request for Comments 2915, Internet Engineering Task Force, Sept. 2000. [26] "SIP End Point Configuration Data Format" by C. Stredicke and Ian Butcher. Internet Draft, IETF, February 2002, work in progress. [27] 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. [28] 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. [29] IEEE Std 802.1Q-1998, IEEE Standards for Local and Metropolitan Area Networks: Virtual Bridged Local Area Networks. [30] H. Schulzrinne, S. Petrack, RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals, IETF, RFC 2833, May 2000. [31] P. Eggert, "Sources for time zone and daylight saving time data." Available at http://www.twinsun.com/tz/tz-link.htm [32] H. Alvestrand "Tags for the Identification of Languages", RFC 3066, IETF, January 2001. [33] R. Mahy et al.: " A Multi-party Application Framework for SIP", Internet Draft, IETF, June 2002, work in progress. [34] H. Sugano et. al.: "Common Presence and Instant Messaging (CPIM) Presence Information Data Format". Internet Draft, IETF, October 2002, work in progress. [35] T. Bray, J. Paoli, C. Sperberg-McQueen and E. Maler, "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C Recommendation, October 2000, . [36] "HTTP over TLS" by E. Rescorla, RFC 2818, IETF, May 2000. draft-somefolks-sipdevice-req-00 [Page 35] SIP Telephony Device Requirements, Configuration and Data Full Copyright Statement Copyright (C) The Internet Society (2002). 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 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 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. draft-somefolks-sipdevice-req-00 [Page 36]