Internet Engineering Task Force I. Butcher/Pingtel Internet Draft S. Lass/MCI draft-sinnreich-sipdev-req-01.txt D. Petrie/Pingtel July 2003 H. Sinnreich/MCI - editor Expires: February 2004 C. Stredicke/snom SIP Telephony Device Requirements, Configuration and Data 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 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, 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 Page 1 6/17/2003 SIP Telephony Device Requirements July 2003 enable similar ease of purchase, installation and operation as found for standard PCs, analog feature phones or mobile phones. 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 [2]. The syntax and semantics used here extend those defined in SIP, [2]. Table of Contents 1. Introduction...................................................3 2. Generic Requirements...........................................4 2.1 Link Layer Requirements....................................4 2.2 IP Requirements............................................5 2.3 SIP Transport Requirements.................................5 2.4 SIP User Agent Services....................................6 2.5 Support for SIP Services..................................10 2.6 SIP and Other Related Protocols...........................11 2.7 SIP Security..............................................12 2.8 Voice Codecs..............................................12 2.9 Voice-Telephony Requirements..............................14 2.10 International Requirements...............................14 2.11 Support for Applications.................................15 2.12 Web-based Feature Management.............................15 2.13 Firmware Update..........................................16 2.14 Firewall/NAT Traversal...................................16 2.15 Device Interfaces........................................17 3. Automatic Configuration.......................................18 4. Configuration Settings........................................18 4.1 Device ID.................................................19 4.2 Network Related Settings..................................19 4.3 Address Completion........................................20 4.4 Audio.....................................................21 4.5 Local and Regional Parameters.............................22 4.6 Inbound authentication....................................23 4.7 Voice mail settings.......................................23 4.8 Phonebook and Call History................................24 4.9 Ringer Behavior...........................................24 4.10 User Related Settings and Roaming........................25 4.11 Line Related Settings....................................26 4.12 Line Identification......................................26 4.13 Registration period......................................26 H. Sinnreich Informational [Page 2] SIP Telephony Device Requirements July 2003 4.14 Maximum connections......................................26 4.15 Call handling............................................27 4.16 Available Behavior.......................................27 4.17 Busy Behavior............................................28 4.18 Call Waiting Behavior....................................28 4.19 Do Not Disturb...........................................29 5. Examples of Configuration Data................................29 5.1. Requirements for Configuration Data Representation.......30 5.2 Configuration Data Format.................................30 5.3 Format Definition.........................................31 5.4 Handling of Unrecognized Element Names....................31 5.5 XML Configuration Data....................................31 5.6 Device settings...........................................31 5.7 User settings.............................................33 6. IANA Considerations...........................................34 7. Configuration Security........................................35 8. Acknowledgements..............................................35 9. Authors Addresses.............................................36 10. References...................................................37 11. Full Copyright Statement.....................................40 1. Introduction This informational I-D has the objective of focusing the Internet communications community on requirements for SIP [3] Telephony devices. We base this information on experience from developing and using a large number of SIP telephony device types and on the experience gained from large scale deployments in carrier and private IP networks and on the Internet. This deployment has shown the need for generic requirements for SIP telephony devices and also the need for some specifics that can be used in SIP interoperability testing. SIP telephony devices, also referred to as SIP User Agents (UAs) 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 and fax machines, conference speakerphones, 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; H. Sinnreich Informational [Page 3] SIP Telephony Device Requirements July 2003 however the non-voice requirements are not specified in this document, except when providing enhanced telephony features, as will be shown. 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 even 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, as well as 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. 2.1 Link Layer Requirements SIP devices MUST support either: Link-1: Wired Ethernet IEEE 802.3 10Base-T 10 Mb/s Half Duplex, or Link-2: Wireless Ethernet 802.11a/b/g 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 Link-6: SIP devices SHOULD support VLAN tagging as per IEEE 802.1q H. Sinnreich Informational [Page 4] SIP Telephony Device Requirements July 2003 Link layers used in 3rd generation mobile phone networks are out of the scope for this document. 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 the RTP traffic over the shared network connection. 2.2 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 DSCP field for RTP streams that supercedes the TOS bits described in RFC 791. The DSCP bit setting MUST be possible to be configured by either the user or automatically by the downloaded configuration data. The Assured Forwarding DSCP value Low Drop Precedence for RTP voice packets MUST be 100010 [4]. IP-5: SIP devices SHOULD support IP version 6. 2.3 SIP Transport Requirements Transport-1: SIP clients MUST support UDP transport of SIP messages. Transport-2: SIP clients MUST support TCP transport of SIP messages. Transport-3: SIP devices MAY support RSVP (RFC 2205). H. Sinnreich Informational [Page 5] SIP Telephony Device Requirements July 2003 2.4 SIP User Agent Services The requirements listed in this section may be used for device testing. To verify correct functionality for specific services, the support for the requirements in the next section should be tested. The various call features listed here are also described in detail in the SIP Service Examples [5]. SIP-1: SIP telephony devices MUST support RFC 3261 [2]. SIP-2, DNS SRV: SIP clients MUST support RFC 3263 [6] for locating a SIP Server and select a transport protocol using NAPTR. When making a SRV query, the client MUST use the 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: Users MUST be able to set the state of the device to Do Not Disturb (DND). The change of the DND state SHOULD be communicated in a PUBLISH with a tuple for this device to a configured presence server. Re-invite: Clients MUST respond to new INVITES with a ô486 Busy Hereö. Clients MUST respond to re-INVITES on existing dialogs as normal behavior. SIP-4, call hold resume: SIP clients MUST follow RFC 3264 [7] when placing a call on hold. More specifically, the a=sendonly attribute MUST be used. The SDP answer of SIP clients that are being placed on hold MUST NOT contain "held" SDP, unless the user session was originally on hold. SIP-5, multiple calls: SIP clients that support call on hold 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. 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. H. Sinnreich Informational [Page 6] SIP Telephony Device Requirements July 2003 SIP-7, message waiting indicator: SIP clients MUST support SIP message waiting [8] and the integration with voicemail platforms. SIP-8, local dial plan: SIP clients MAY 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. Note: Mobile SIP phones or PCs may not need a dial plan. When using URL's and calling in the local domain, the local domain (@domain) MAY be appended to facilitate calling. If the destination SIP device is specified as an IP address, the SIP client MUST not attempt to resolve the address with DNS as specified in RFC 3263 [6]. If the destination SIP device is a string value, the SIP client MUST make normal DNS SRV and A record queries as specified in RFC 3263. SIP-9, transfer: SIP devices MUST support REFER and NOTIFY as required to support the transfer [9]. SIP clients MUST support escaped headers in the Refer-To: header. SIP-10, unattended transfer: SIP devices MUST support an unattended transfer. SIP clients MUST support escaped headers in the Refer-To: header. SIP-11, attended call transfer: SIP devices MUST support attended call transfer. SIP clients MUST support escaped headers in the Refer-To: header. SIP-12, device based conferencing: SIP devices MAY be able to support device based conferencing. A SIP client MAY be able to initiate and mix the audio streams of at least 2 separate calls (i.e. 3 way conference calling). SIP-13, DMTF in-band mixing: SIP devices MUST generate in-band DTMF tones for use with the G.711 codec. SIP-14: DTMF RTP payload: SIP clients MUST be able to send DTMF specified by RFC 2833 [10]. RFC 2833 negotiation must behave as follows: Receiving endpoint must reply with payload type sent by initiator. For example, if the H. Sinnreich Informational [Page 7] SIP Telephony Device Requirements July 2003 initiating client sends payload type 101, receiving endpoint must reply with payload type 101. Payload type negotiation MUST comply with RFC 3264. 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 devices SHOULD support Flow Identification (FID) as defined in RFC 3388 [11]. SIP-15, 180 ignores earlier media: SIP devices MUST generate local ringing and MUST ignore any early RTP media when a ô180 Ringingö response is received. SIP-16, 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-17, 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-18, error-info support: SIP devices MUST support the Error-Info header. SIP-19, 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 MAY use an internal ôStatus Codeö table if there was a problem with the language negotiation. SIP-20, fax support: SIP adapter devices (for analog phone lines) MUST support the ITU-T T.38 standard [12] using UDPTL [13]. SIP devices MUST fallback to G.711 if T.38 fails. Multi-line Requirements SIP-21, multi-line support: Multi-line SIP devices MUST register using more than one set of credentials. H. Sinnreich Informational [Page 8] SIP Telephony Device Requirements July 2003 SIP-22, multi-line Do Not Disturb: SIP multi-line 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 dialogs as normal. SIP-23, 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-24, Dynamic login/logout for user mobility: SIP devices SHOULD support user mobility. SIP clients MAY store a static profile in non-volatile memory so that this information is available during the power up sequence. SIP clients MAY allow a user to walk up to a client, login, and be able to send and receive calls with his/her profile information. For emergency numbers (e.g. 911, SOS URL) the client MUST send the credentials username/password) of the static profile. SIP-25, multi-line ring tones: SIP devices MUST be able to provision a different ring tone for each line (i.e. registration or static identity). Analog text support for hearing or speech disabled users SIP-26, analogue and digital text support for hearing and speech impaired users: As per RFC 3351 [14], communicating with legacy relay services and devices. SIP adapter devices (for analog phone lines) supporting conversion between real time text transmission using RFC 2793 [15] and analog text telephones according to ITU-T V.18 MUST allow alternating use of text and voice. SIP clients MUST fallback to G.711 if the RFC 2793 connection fails. H. Sinnreich Informational [Page 9] SIP Telephony Device Requirements July 2003 SIP devices must support TCP as specified in RFC 3261 for longer text messages. Digital text support: SIP telephone devices MAY support real time text conversation using RFC 2793 for the text stream. It MUST be possible to use text simultaneously with voice. Note: Though SIP telephony devices supporting Instant Messaging based on the SIMPLE [21] standard allow text conversation based on blocks of text. However, interactive text conversation is required for hearing and speech disabled users due to its streaming-like nature. SIP-27, call-info: SIP devices with a display MUST support the call- info header and depending on the display capabilities MAY for example display an icon or the image of the caller. SIP-28, Priority header: SIP devices SHOULD support the Priority header for such applications as emergency calls or for selective call acceptance. SIP-29: SIP devices MUST support music on hold as shown in "SIP Service Examples" [5]. SIP-30: SIP devices SHOULD support the OPTION method as per RFC 3261. 2.5 Support for SIP Services SIP devices used for enterprise communications SHOULD support the call flows for the basic and enhanced SIP services. The list here MAY be used for system integration testing to support specific commercial services. The schema for uploading the identity from a PDA is outside the scope of these requirements. The call flows illustrated in the references shown below assure not only minimal support for SIP phones, as required for PSTN-style consumer services, but also for the most widely used Centrex-style and PBX-style services. H. Sinnreich Informational [Page 10] SIP Telephony Device Requirements July 2003 3rd party call control enables many value added services, such as standards based control of a SIP phone from a call manager application on the PC collocated on the desk with the SIP phone. The following IETF references for rich presence, instant messaging, caller preferences and service mobility specify SIP specific services that go beyond the capability of PSTN and PBX based services and can be best supported by SIP telephony devices. Srv-1: SIP Call Flow Examples [16], Srv-2: SIP Service Examples [17], Srv-3: PSTN call flows [18], Srv-4: Third Party Call Control in SIP [19], Srv-5: SIP call control and multiparty features [20], Srv-6: SIP devices MAY support conferencing services [21] for voice and IM [22], so as to be able act as host for a 3-way conference at least. Srv-7: Rich Presence based services [23], Srv-8: Caller and called party preferences [24], Srv-9: Service mobility: SIP desk devices MAY allow roaming users to upload their identity so as to have access to their services and preferences from the home SIP server. Examples of user data to be available for roaming users are: User service ID, the dialing plan, personal directory and caller/called party preferences. 2.6 SIP and Other Related Protocols SDP: SIP devices MUST support Session Description Protocol, RFC2327 [25]. RTP/RTCP: SIP devices MUST support Real-Time Protocol and Real-Time Control Protocol, RFC 1889. SIP devices SHOULD use RTCP Extended Reports for logging and reporting on network support for voice quality [26]. H. Sinnreich Informational [Page 11] SIP Telephony Device Requirements July 2003 SIP clients MUST support Simple Network Time Protocol (RFC2030), or use the Date: header of the 200 OK in response to a REGISTER request. Network Management SNMP: SIP clients SHOULD support SNMP reporting. SIP clients SHOULD support the RTP and RTCP MIBs to report jitter, delay, and packet loss. 2.7 SIP Security Sec-1: SIP devices MUST support digest authentication as per RFC 3261. Sec-2: SIP devices MUST be able to password protect configuration information and administrative functions. Sec-3: SIP devices MUST not display the password to the user or administrator after it has been entered. Sec-4: SIP clients MUST be able to disable remote access, i.e. block incoming SNMP, HTTP, and other services not necessary for basic operation. Sec-5: SIP clients MUST be able to reject an incoming INVITE where the user-portion of the SIP request URI is blank or does not match a provisioned Contact. The setting to accept/reject MUST be provisioned. Sec-6: SIP clients MUST be able to reject an incoming INVITE when the message does not come from the 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. 2.8 Voice Codecs Internet telephony devices face the problem of supporting multiple codecs due to various historic reasons, on how telecom 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 [27]. H. Sinnreich Informational [Page 12] SIP Telephony Device Requirements July 2003 Codec-1: Three main classes of voice codecs are supported by Internet telephony devices; (1) default G.711, (2) compressed and (3) wideband. At least two codecs, the default G.711 codec and one compressed codec listed below MUST be supported. 1. 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. 2. The compressed Internet Low Bit Rate codec (iLBC) [28], [29] MUST be supported. Other compressed codecs SHOULD be supported. Compressed Voice codecs used in 2nd and 3rd generation mobile phone systems, such as various GSM codecs are also found in various implementations and SHOULD be supported. The narrow bandwidth codecs such as G.723.1 with such low speed as 5.3 kb/s and 6.3 kb/s (without RTP/UDP/IP overhead) as to work well even on dial-up access MAY be supported. Compressed codecs such as G.729 derived from delta-PCM encoding, found in networks with frugal Internet access bandwidth using frame relay or DSL access MAY be supported. 3. Wideband codecs using typically 16 kHz voice sampling for better- than-PSTN voice quality, such as G.722 and other MAY be supported. Such codecs are found in conferencing systems to increase the perceived quality of conferencing. Note: A summary count reveals up to 25 and more voice codec types currently in use. The authors believe there is a need for a single multi-rate Internet codec, such as [30] 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 and the receiver has "final" choice of codec selected. Both endpoints MUST use the first codec listed by the receiver. H. Sinnreich Informational [Page 13] SIP Telephony Device Requirements July 2003 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 devices MAY support comfort noise generated in the receiver, without using up end-to-end bandwidth. It is also RECOMMENDED that SIP clients comply with performance specified for the "handset receive comfort noise" requirements outlined in the ANSI/EIA/TIA-810-A-2000 standard. 2.9 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 the TIA/EIA standards [31], and [32]. 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 and TIA/EIA-579-A, at any voice-band 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 (i.e. From: header). 2.10 International Requirements H. Sinnreich Informational [Page 14] SIP Telephony Device Requirements July 2003 International-1, language support: SIP devices SHOULD indicate the preferred language using SIP Caller Preferences. The setting for this header MUST be provisioned. International-2, international display support: SIP devices intended to be used in various language settings, MUST support other languages for menus, help, and labels. 2.11 Support for Applications The following requirements apply to functions placed in the SIP telephony device. App-1, SIMPLE Integration: SIP devices that support presence MUST provide a buddy list and use SIP extensions to leverage presence [33]. App-2, address-book integration: SIP devices SHOULD allow a 3rd party to initiate a call for the client, such as using the address book in the PC to initiate a call. App-3, LDAP phonebook: SIP devices MAY support LDAP for client-based directory lookup. App-4, automatic ring-down: SIP devices MAY support a phone setup where a URL is automatically dialed when the client goes off-hook. App-5, 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. 2.12 Web-based Feature Management Web-1: SIP devices SHOULD support an internal web server to allow users to manually configure the phone and to set up personal 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 MAY be accessible to authenticated users or operations personnel from remote locations. H. Sinnreich Informational [Page 15] SIP Telephony Device Requirements July 2003 2.13 Firmware Update Firm-1: SIP devices MUST be able to upgrade their firmware as described in section 3. 2.14 Firewall/NAT Traversal 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 used for NAT traversal. SIP devices MUST have the capability to be configured so that the default domain and the outbound SIP 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 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 [34]. 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 MAY be able to operate with a UPnP (http://www.upnp.org/) firewall device. UPnP will support the traversal of the local NAT/FW and is adequate on its own when no other NATs are placed in the service provider network. H. Sinnreich Informational [Page 16] SIP Telephony Device Requirements July 2003 FW/NAT-4, STUN capable configuration: SIP telephony devices MUST be able to operate with a STUN server. 2.15 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 and MAY have various interface models, such as for phones, IM GUI 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, transfer, conference, hold, 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 entry or graffiti for PDAs. Phone number entry SHOULD be supported in human friendly fashion, by allowing the usual separators and brackets between digits and digit groups. Int-3: SIP telephony devices MUST have two types of interface capabilities, for both phone numbers and URLs, both accessible to the end user. 1. SIP device configuration and management interface: SIP telephony adapters and high end phones MAY support SNMP v.3 for managing the device. The required MIB is outside the scope of this memo. The access to the SIP device configuration interface MAY be blocked by the service provider so as not allow misconfiguration of the settings. 2. 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 may also H. Sinnreich Informational [Page 17] SIP Telephony Device Requirements July 2003 facilitate remote device settings from a help desk, without user intervention. 3. Automatic Configuration Automatic SIP telephony device configuration SHOULD use the processes and requirements described in [35] and [36]. The user name or the realm in the domain name SHOULD be used by the configuration server to automatically configure the device for individual or group specific settings, without any settings by the user. Image and service data upgrades SHOULD also not require any settings by the user. 4. Configuration Settings 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 endpoint. 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 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 misconfiguration of important settings by inexperienced users generating 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. H. Sinnreich Informational [Page 18] SIP Telephony Device Requirements July 2003 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 up a setting 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 default value for the setting. The line concept allows configuration of phones in a user specific context. It simplifies unconstrained seating in offices, can support roaming users and allows users to subscribe to more than one service provider. 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.1 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.2 Network Related Settings Network-1: SIP Ports. The port that MUST be used for a specific transport protocol MAY be indicated with the SIP ports setting. If this setting is omitted, the device MAY choose any port. 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). These settings help network operators identifying voice packets in their network and allow them to transport them with the necessary quality. The settings are independently configurable for the different transport layers and signaling, media or administration. For both categories of network traffic, the device SHOULD permit configuration of the type of service settings for both layer 3 (IP DiffServ) and layer 2 (IEEE 802.1D/Q) of the network protocol stack. H. Sinnreich Informational [Page 19] SIP Telephony Device Requirements July 2003 Network-3: Network parameters. The parameters for SIP (like timer T1) and other network related settings MAY be indicated. An example of usage would be the reduction of the DNS SRV failover time. Network-4: RTP Port range. A range of port numbers MUST be used by a device for the consecutive pairs of ports which MUST be used to receive audio and control information (RTP and RCTP) for each concurrent connection. This is required to support firewall traversal. This again helps network operators to identify voice packets and makes it possible to configure port ranges on firewalls only for voice packets. Network-5: 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-6: Default Call Handling. All of the call handling settings defined below in section 5.3.2 can be defined here as default behaviors. Network-7: Outbound Proxy. The outbound proxy for a line or for a device MUST 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. Using this setting, private networks can control outbound traffic and send it through an application layer gateway. Network-8: 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. Network-9: 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 SHOULD be used if provided. If there is no value provided, the device MAY use a default value (e.g. 3600 seconds). 4.3 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 URL or TEL URL). H. Sinnreich Informational [Page 20] SIP Telephony Device Requirements July 2003 Dial-1: SIP phones need to understand entries into the phone book of the most common separators used between dialed digits, such as spaces, angle and round brackets, dash and dots. Dial-2: Dial Plan and/or Dial/OK key. A dial plan which defines the maximum expected length of a typical telephone number MAY be used. If no dial plan is used, the device MAY have a "Dial" or "OK" key, similar to mobile phones. Zero or more digit maps which map a dial plan and a SIP address to which phone numbers of that type SHOULD be routed to 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 be 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-3: Default Digit Map. The end point SHOULD support the configuration of a default digit map. If the end point does not support digit maps, it SHOULD 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-4: Overlap-Dial. Some operators support overlap dialing 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.4 Audio Audio-1: Codecs. In some 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. Service providers MUST have the possibility of plugging in their own codecs of choice. H. Sinnreich Informational [Page 21] SIP Telephony Device Requirements July 2003 The range for parameters of the codecs MUST be adjustable. This includes the packet length (ms of audio), which is a function of the sample rate. However, the negotiation of the media for individual calls is being done on a per call basis. Audio-2: DTMF method. DTMF allows different ways of indicating that a key has been pressed as per RFC 2833. 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.5 Local and Regional Parameters Certain settings are dependent 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 One database [37]. 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 (RFC 2030) time servers where the device can get a centrally defined time value MAY be used. Regional-4: The time server MAY be used. DHCP is the preferred way to provide this setting. Setting the correct language is important for simple installation around the globe. H. Sinnreich Informational [Page 22] SIP Telephony Device Requirements July 2003 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 [38] 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. Language-3: A SIP UA MUST be able to parse and accept requests containing international characters encoded as UTF-8 even if it canÆt display those characters in the user interface. 4.6 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. In-Auth-1: A device SHOULD support 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 MAY be used by the device. The credentials MAY 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.7 Voice mail settings Various voice mail settings require the use of URL's as specified in [39]. VM-1: The message waiting indicator (MWI) address setting controls where the client MAY SUBSCRIBE to a voice mail server [40]. 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. H. Sinnreich Informational [Page 23] SIP Telephony Device Requirements July 2003 4.8 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. 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.9 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 for the ringer alert. Ringer sound files MAY be specified for the following types of incoming calls normal, high priority, internal and external. H. Sinnreich Informational [Page 24] SIP Telephony Device Requirements July 2003 Different ringer sound files MAY also be associated with different lines. The location of a call MAY also be indicated. This allows using the phone by hearing-impaired or in noisy environments where external speakers are used to render the sound. The location of the call is also useful for paging by speakerphones. 4.10 User Related Settings and Roaming 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 to 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 agent 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 agent 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 agent to individually configure all of the lines individually (this 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. However the ability to uniquely identify the device and H. Sinnreich Informational [Page 25] SIP Telephony Device Requirements July 2003 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.11 Line Related Settings SIP telephony devices MUST use the line related settings, as specified here. 4.12 Line Identification A line represents an address-of-record 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. 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. 4.13 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.14 Maximum connections H. Sinnreich Informational [Page 26] SIP Telephony Device Requirements July 2003 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. The number of simultaneous connections may be also limited by the access bandwidth, such as of DSL, cable and wireless users. MaxConn-1: A SIP telephony device MAY support at least two connections for three-way conference calls that are locally hosted. 4.15 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 accept the call and alert the end user. Some settings tend to change irregularly like their voicemail forwarding address while other 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.16 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. H. Sinnreich Informational [Page 27] SIP Telephony Device Requirements July 2003 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.17 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 SIP devices 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.18 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 H. Sinnreich Informational [Page 28] SIP Telephony Device Requirements July 2003 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 support 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. 4.19 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 parameters defined within call handling, however, it addresses both an end user needs 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. Examples of Configuration Data The section describes the requirements and format for an implementation of the settings described in section 4. H. Sinnreich Informational [Page 29] SIP Telephony Device Requirements July 2003 5.1. Requirements for Configuration Data Representation From reading the preceding 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 an administration point of view to be able to easily relate settings. This document recognizes that as features multiply on devices, so will the amount of settings. Any format proposed SHOULD be readily and intuitively extensible. 5.2 Configuration Data Format The choices for the configuration data formats are best left to the discretion of the implementers and service providers. Open Issue: The authors believe it would be useful to specify a grammar for the default name space. This document 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 4. Note for potential grammar designers and implementers: The authors believe it is very useful to have CDATA sections in XML documents where the content itself may break XML syntax rules. This is the case of SIP URLs. An example of is given in Example E below. 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 3. An example of an extension to the time zone setting is show below. H. Sinnreich Informational [Page 30] SIP Telephony Device Requirements July 2003 00:d0:1e:00:1a:0e NORTH AMERICA America/Los_Angeles "PST" 10.1.1.1 US:English 5.3 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 4 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.4 Handling of Unrecognized Element Names 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. 5.5 XML Configuration Data This section aims to provide some samples of the settings defined in section 4, using XML [41]. A complete grammar/schema definition is not provided here, since this serves as an example only. 5.6 Device settings A. Network Settings 5060 H. Sinnreich Informational [Page 31] SIP Telephony Device Requirements July 2003 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 H. Sinnreich Informational [Page 32] SIP Telephony Device Requirements July 2003 E. Line definition for 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. Note: The authors' preference for potentially long values in XML is to use an element rather than an attribute. Added to which, in an element you can wrap values which would normally break the XML syntax in a CDATA. This would allow SIP URLs to be formatted without having to escape them. Example: <[!CDATA[ôExtension 123ö]] 5.7 User settings F. Voice mail settings 10.1.1.1 10.1.1.2 H. Sinnreich Informational [Page 33] SIP Telephony Device Requirements July 2003 G. Line definition for user <Fred Bloggs>sip:fbloggs@Pingtel.com 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: [Christian Stredicke] Published Specification: This document. MIME Registration for Application The MIME Registration for application/sip-endpoint-configuration is: MIME media type name: application H. Sinnreich Informational [Page 34] SIP Telephony Device Requirements July 2003 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 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. Configuration Security Please see also the above section 2.7 on SIP Security. The device configuration MAY contain sensitive information that MUST 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 [42]. For devices which use FTP or TFTP for content delivery this can be achieved using symmetric key encryption. Access to retrieving configuration information is also an important issue. A configuration server SHOULD challenge a subscriber before sending configuration information. 8. Acknowledgements The authors would like to thank numerous persons for contributions and comments to this Internet Draft: Henning Schulzrinne from H. Sinnreich Informational [Page 35] SIP Telephony Device Requirements July 2003 Columbia University, J÷rgen Bj÷rkner from HotSIP, Jay Batson from PingTel, Eric Tremblay from Mediatrix, Gunnar Hellstr÷m from Omnitor AB, David Oran and Denise Caballero McCann from Cisco, Brian Rosen from Marconi, Jean Brierre from MCI, Kai Miao from Intel, Adrian Lewis from Profile-ICT and Franz Edler from UTA Telekom AG. Jonathan Knight from MCI has contributed significantly to earlier versions of parts of this Internet 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 Ian Butcher Pingtel Corp. 400 W. Cummings Park Suite 2200 Woburn, MA 01801, USA Phone: +1 781 938 5306 Email: ibutcher@pingtel.com Steven Lass MCI 400 International Parkway Richardson, TX 75081, USA EMail: steven.lass@mci.com Phone: +1 972 729 4469 Daniel G. Petrie Pingtel Corp. 400 W. Cummings Park Suite 2200 Woburn, MA 01801, USA Phone: +1 781 938 5306 Email: dpetrie@pingtel.com Henry Sinnreich MCI 400 International Parkway Richardson, TX 75081, USA EMail: henry.sinnreich@mci.com Christian Stredicke snom technology AG Pascalstrasse 10e 10587 Berlin, Germany H. Sinnreich Informational [Page 36] SIP Telephony Device Requirements July 2003 Phone: +49(30)39833-0 Email: cs@snom.de 10. References [1] RFC2026: "The Internet Standards Process -- Revision 3" by Scott Bradner, IETF, October 1996. [2] RFC 2119: "Key words for use in RFCs to Indicate Requirement Levels" by Scott Bradner, IETF, 1997. [3] J. Rosenberg et. al.: "SIP: Session Initiation Protocol, RFC 3261, IETF, June 2002. [4] RFC 2597: "Assured Forwarding PHB Group" by Heinanen, J. et al. IETF, June 1999. [5] Johnston, A. et al., "SIP Service Examples", work in progress, February 2003. [6] RFC 3263: "Session Initiation Protocol (SIP): Locating SIP Servers" by J. Rosenberg and H. Schulzrinne. IETF, June 2002. [7] RFC 3264: "An Offer/Answer Model with Session Description Protocol (SDP)" by J. Rosenberg and H. Schulzrinne. IETF, June 2002. [8] Mahy, R.: "A Message Summary and Message Waiting Indication Event Package for SIP". Work in progress, IETF March 2003. [9] RFC 3515: "The SIP Refer Method" by R. Sparks, IETF, April 2003. [10] RFC 2833: "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals" by H. Schulzrinne and S. Petrack. IETF, May 2000. [11] RFC 3388: "Grouping of Media Lines in the Session Description Protocol (SDP)" by G. Camarillo et al. IETF, December 2002. [12] ITU-T Recommendation T.38. [13] Johnston, A. et al.: "Session Initiation Protocol Torture Test Messages". Work in progress, August, 2002. [14] RFC 3351: "Requirements for the Session Initiation Protocol (SIP) in Support of Deaf, Hard of Hearing and Speech-impaired Individuals" by Charlton, N. et al. IETF, August 2002. H. Sinnreich Informational [Page 37] SIP Telephony Device Requirements July 2003 [15] RFC 2793: "RTP Payload for Text Conversation" by G. Hellstrom. IETF, May 2000. [16] Johnston, A. et al.: "Session Initiation Protocol Basic Call Flow Examples". Work in progress, IETF, August 2003. [17] Johnston, A. et al.: "Session Initiation Protocol Service Examples", work in progress, IETF, February 2003. [18] Johnston, A. and Donovan S: "Session Initiation Protocol PSTN Call Flows". Work in progress, IETF, November 2003. [19] Rosenberg, J., et al., " Best Current Practices for Third Party Call Control in the Session Initiation Protocol", work in progress, March 2003 [20] Mahy, R.et al., "A Call Control and Multi-party usage framework for the Session Initiation Protocol (SIP)", work in progress, IETF, March 2003. [21] Johnston A. and Levin O.: "Session Initiation Protocol Call Control - Conferencing for User Agents", work in progress, IETF, April 2003. [22] Rosenberg, J. and Isomaki, A.: "Requirements for Manipulation of Data Elements in Session Initiation Protocol (SIP) for Instant Messaging and Presence Leveraging Extensions (SIMPLE) Systems ", work in progress, IETF, August 2003. [23] Rosenberg, J., et al., "Rich Presence Information Data Format for Presence Based on the Session Initiation Protocol (SIP) ", work in progress, IETF, August 2003. [24] Rosenberg, J. et al.: "Caller Preferences and Callee Capabilities for the Session Initiation Protocol (SIP) ", work in progress, IETF, September 2003. [25] RFC 2327: "SDP: Session Description Protocol" by M. Handley and V. Jacobson. IETF, April 1998. [26] T. Friedman et al: "RTP Control Protocol Extended Reports (RTCP XR)", work in progress, IETF, April 2003. [27] H. Schulzrinne et al.: "RTP Profile for Audio and Video H. Sinnreich Informational [Page 38] SIP Telephony Device Requirements July 2003 Conferences with Minimal Control", RFC 1890, IETF, January 1996. [28] Andersen,S.V. et al.: "Internet Low Bit Rate Codec", work in progress, IETF March 2003. [29] Duric A. et al.: "RTP Payload Format for iLBC Speech", work in progress. IETF March 2003. [30] Herlein, G: "RTP Payload Format for the Speex Codec", work in progress, IETF, February 2003. [31] TIA/EIA-810-A, "Transmission Requirements for Narrowband Voice over IP and Voice over PCM Digital Wireline Telephones", July 2000. [32] TIA-EIA-IS-811, "Terminal Equipment - Performance and Interoperability Requirements for Voice-over-IP (VoIP) Feature Telephones", July 2000. [33] Rosenberg, J.: "A Presence Event Package for the Session Initiation Protocol (SIP)", work in progress, IETF, January 2003. [34] Rosenberg, J. et al: "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)". IETF, March 2003. [35] Petrie, D.: "A Framework for SIP User Agent Configuration", work in progress. IETF, February 2003. [36] Petrie, D. and Jennings, C.: "Requirements for SIP User Agent Profile Delivery Framework", work in progress, IETF, February 2003. [37] Eggert, P.: "Sources for time zone and daylight saving time data." Available at http://www.twinsun.com/tz/tz-link.htm [38] Alvestrand, H.: "Tags for the Identification of Languages", RFC 3066, IETF, January 2001. [39] Mahy, R. et al.: "A Multi-party Application Framework for SIP", Internet Draft, IETF, June 2002, work in progress. [40] Mahy, R.: "A Message Summary and Message Waiting Indication Event Package for SIP", work in progress, IETF, march 2003. [41] T. Bray, J. Paoli, C. Sperberg-McQueen and E. Maler, "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C H. Sinnreich Informational [Page 39] SIP Telephony Device Requirements July 2003 Recommendation, October 2000, http://www.w3.org/TR/2000/REC-xml- 20001006. [42] RFC 2818: "HTTP over TLS" by E. Rescorla. IETF, May 2000. 11. Full Copyright Statement Copyright (c) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE 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. H. Sinnreich Informational [Page 40]