SIPPING Working Group H. Sinnreich Internet-Draft S. Lass Expires: August 22, 2002 J. Knight WorldCom D. Petrie pingTel Corp. C. Stredicke snom technology AG February 21, 2002 SIP Telephony Device Requirements draft-sinnreich-sipping-device-requirements-00 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. This Internet-Draft will expire on August 22, 2002. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract The SIP Telephony Device Requirements in this document are aimed to enable users to procure SIP phones from various vendors and install them using a configuration process over the network, though still allowing manual configuration data input if desired. SIP telephony devices are also required to be updated up automatically, without the intervention of the end user. The requirements are aimed to allow Sinnreich, et al. Expires August 22, 2002 [Page 1] Internet-Draft SIP Telephony Device Requirements February 2002 service providers to support large numbers of SIP telephony devices from different vendors and SHOULD be used as a checklist for developers of SIP phones. SIP telephony devices may support basic telephony as well as advanced services such as PBX and Centrex-like telephony, third party call control, presence based services, roaming and other applications. The requirements aim to insure multi-vendor interoperability over the Internet and in private IP networks for such services. User interface and display requirements aim for consistency for service provider personnel and also to minimize the need for end user training across various SIP telephony devices. Other requirements specify such capabilities as the supported codecs for voice and video and also power feeding over the Ethernet copper cable. Sinnreich, et al. Expires August 22, 2002 [Page 2] Internet-Draft SIP Telephony Device Requirements February 2002 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Conventions Used In This Document . . . . . . . . . . . . . 5 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . 5 3.1 Classes of Requirements . . . . . . . . . . . . . . . . . . 6 4. Protocol Requirements . . . . . . . . . . . . . . . . . . . 6 5. Automatic Device Configuration and Configuration Data Profile . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1 Independence of Device, User and Service Configuration Servers . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.2 Configuration for Emergency Calling . . . . . . . . . . . . 7 5.3 Configuration Processes . . . . . . . . . . . . . . . . . . 7 5.3.1 Discovery of the Configuration Server . . . . . . . . . . . 8 5.3.2 Enrollment and Configuration Change Notification . . . . . . 8 5.3.3 Configuration Retrieval . . . . . . . . . . . . . . . . . . 9 5.3.4 Configuration Upload . . . . . . . . . . . . . . . . . . . . 9 5.3.5 Firmware Upgrade . . . . . . . . . . . . . . . . . . . . . . 9 5.3.6 Example of an Automatic Configuration Process with SUBSCRIBE/NOTIFY. . . . . . . . . . . . . . . . . . . . . . 9 5.3.7 Example of an Automatic Configuration Process without SUBSCRIBE/NOTIFY . . . . . . . . . . . . . . . . . . . . . . 9 6. Codecs and Media . . . . . . . . . . . . . . . . . . . . . . 10 6.1 Media Capabilities . . . . . . . . . . . . . . . . . . . . . 10 6.2 DTMF RTP Payload . . . . . . . . . . . . . . . . . . . . . . 10 6.3 Local Ringing . . . . . . . . . . . . . . . . . . . . . . . 10 6.3.1 Play Single Early Media Stream . . . . . . . . . . . . . . . 10 6.3.2 Use Last 18x Message Received . . . . . . . . . . . . . . . 11 6.4 Media and RTP/RTCP Support for Device Based Conferencing . . 11 6.5 Codec Support and Negotiation . . . . . . . . . . . . . . . 11 6.5.1 License Free Voice Codecs . . . . . . . . . . . . . . . . . 11 6.5.2 Voice Codecs and License Requirements . . . . . . . . . . . 12 6.5.3 Video Codecs . . . . . . . . . . . . . . . . . . . . . . . . 12 7. Acoustic Properties . . . . . . . . . . . . . . . . . . . . 12 8. SIP Services Support . . . . . . . . . . . . . . . . . . . . 13 9. User Interface Requirements and Settings . . . . . . . . . . 13 9.1 Address Input by User (Dialing) . . . . . . . . . . . . . . 14 9.1.1 Dialing Phone Numbers . . . . . . . . . . . . . . . . . . . 14 9.1.2 Entering URLs . . . . . . . . . . . . . . . . . . . . . . . 14 9.1.3 Emergency (911) Calling . . . . . . . . . . . . . . . . . . 14 9.2 Display and Settings for SIP Devices . . . . . . . . . . . . 15 9.2.1 General Behavior . . . . . . . . . . . . . . . . . . . . . . 15 9.2.2 Network Settings . . . . . . . . . . . . . . . . . . . . . . 15 9.2.3 SIP Settings . . . . . . . . . . . . . . . . . . . . . . . . 16 9.2.4 Called Party Preferences . . . . . . . . . . . . . . . . . . 17 9.2.5 Codec Settings . . . . . . . . . . . . . . . . . . . . . . . 17 9.2.6 Redirection of Fax Calls . . . . . . . . . . . . . . . . . . 17 9.2.7 Diagnostics . . . . . . . . . . . . . . . . . . . . . . . . 17 Sinnreich, et al. Expires August 22, 2002 [Page 3] Internet-Draft SIP Telephony Device Requirements February 2002 9.2.8 Dedicated Announcement Lamps/Display Windows . . . . . . . . 17 10. Security . . . . . . . . . . . . . . . . . . . . . . . . . . 18 11. Network Management for SIP Telephony Devices . . . . . . . . 18 12. Wired and Wireless LAN Support . . . . . . . . . . . . . . . 18 12.1 Wired LAN Support . . . . . . . . . . . . . . . . . . . . . 18 12.2 Wireless LAN Support . . . . . . . . . . . . . . . . . . . . 19 13. Power for SIP Desk Phones . . . . . . . . . . . . . . . . . 19 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 References . . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 21 Full Copyright Statement . . . . . . . . . . . . . . . . . . 23 Sinnreich, et al. Expires August 22, 2002 [Page 4] Internet-Draft SIP Telephony Device Requirements February 2002 1. Introduction SIP telephony devices, also referred to as SIP User Agents can be any type of IP networked computing device optimized for SIP based IP communications. SIP telephony devices can be SIP phones, PCs, laptops, PDAs, mobile and cordless phones that support SIP functionality and may support various media such as text, voice, video, games and possibly other Web/Internet applications besides real time communications. SIP telephony devices should meet the requirements in this document. The objectives of the requirements in this document are a minimum set of interoperability and multi-vendor supported core features across the Internet, so as to enable similar ease of purchase, installation and operation as found for standard PCs or feature phones. Given the cost of some screen phones or enterprise phones approaches the cost of PCs, and the larger number of phones compared to PCs, similar ease of use is expected by both end users and network administrators. 2. 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, (RFC 2543-bis06 [2]). SIP is described in an augmented Backus-Naur form (ABNF). See [2], section 26 for an overview of ABNF. 3. Problem Statement It is desirable to purchase SIP phones similar to purchasing ordinary phones, plug them in and have them working. SIP phones are however an advanced type of specialized networked computer device and they need to be configured accordingly. Also, the software and firmware needs to be updated from time to time. Other challenges come from the fact that there are expected to be large number of SIP devices in the network, in a mix from various vendors and with various model specific capabilities. It is therefore desirable for service providers to manage large numbers of SIP telephony devices in a consistent way without stifling innovation by vendors who may compete with enhanced features. Roaming/traveling users SHOULD be able to configure any convenient locally available SIP telephony device (compliant with these requirements) by downloading their personal configuration preferences and data from a home network server. Sinnreich, et al. Expires August 22, 2002 [Page 5] Internet-Draft SIP Telephony Device Requirements February 2002 3.1 Classes of Requirements Not all SIP devices are or should be equal or need to meet all requirements listed in this document. Furthermore, location or market specific requirements are not the object of this document. Regional market specific requirements for some narrowband and feature types of Voice over IP Telephones have been published in [3], [4]. User interface and network specific requirements are the core of the SIP device requirements in this document. 4. Protocol Requirements SIP devices MUST support as a minimum the following protocols: o Link layer protocols: Ethernet, 802.11a, 3G wireless, etc. o IPv4 [5] o TCP o UDP o DNS o TFTP - optional for backward compatibility o HTTP o RTP and RTCP o SIP o SDP o NTP 5. Automatic Device Configuration and Configuration Data Profile In any network, a SIP end system needs to establish SIP-related configuration parameters, namely the outbound proxy. There are many possible ways this information can be configured, but manual configuration is ill-advised. It is RECOMMENDED that the end system obtain this information via the SIP server DHCP option [7]. In this approach, both local registrar and proxy server are assumed to be the same. In the absence of DHCP or manual configuration, a SIP end system has to assume that there is no outbound proxy. Sinnreich, et al. Expires August 22, 2002 [Page 6] Internet-Draft SIP Telephony Device Requirements February 2002 Device configuration SHOULD to be fully automatic by default. Manual device configuration MUST also be possible, but SHOULD be hidden for non-technical users. 5.1 Independence of Device, User and Service Configuration Servers The requirements listed here are necessary to enable network managers and service providers to support various SIP telephony devices using the same server infrastructure for all brands of SIP devices. Within this infrastructure, separate configuration servers MAY be supported, so as to have a server for each device specific configuration. The URLs are likely to be different, but the server may be the same for different SIP device types. Server content for device software can thus be maintained for example by the device manufacturer and other server content can be hosted by the service provider for user and service specific data. 5.2 Configuration for Emergency Calling SIP devices MUST support emergency calling either by entering an emergency number (such as 911 in the USA) or have a preconfigured universal emergency URL for "SOS" [9]. Emergency calls have to be routed to the preconfigured SIP server for emergency service. The SIP UA may also obtain the SIP capable public safety access point (PSAP in the USA) or a dedicated gateway port to the PSTN for PSAP as part of the configuration. In case of manual configuration, or when automatic configuration cannot supply the geographic location for desktop phones, a prompt should be displayed for entering the geographic location required for emergency calls. 5.3 Configuration Processes The following configuration processes are required for SIP devices [6]: o Discovery of a configuration server o Enrollment with a configuration server o Retrieval of configuration data o Change Notifications from the configuration server o Configuration Upload from the SIP device to the configuration server. Sinnreich, et al. Expires August 22, 2002 [Page 7] Internet-Draft SIP Telephony Device Requirements February 2002 The content and format of the configuration data is not specified in this document and can be vendor specific. Devices from different vendors may use different URLs for the configuration server. The detailed protocol requirements for exchanging SIP configuration are specified in [8]. 5.3.1 Discovery of the Configuration Server A SIP device SHOULD support all of the listed discovery mechanisms of the configuration server (this is different from the outgoing SIP proxy) in the order shown here and MUST support at least one of them. o The DHCP option - least costly in terms of look-up time [7] o DNS A record o Manual provisioning - last resort SIP devices MUST support manual configuration from a web browser. The default IP address of the web server to configure a SIP device should be a de facto standard address, such as used by small office and home firewalls, NATs and ISDN modems. We propose 192.168.254.1 for SIP devices as the initial factory default value. The concept of a device-specific HTTP URL is very useful and MUST be supported. This is different from a user URL that may move or roam. The device specific URL lets you address a specific device (e.g. the phone in the user's office, not the phone on which the user has his/ her personal URLs registered from). This is very important in the context of edge based 3rd party call control services using REFER. SIP devices MUST support two or more DNS resolver entries. If the first DNS server does not respond, the second DNS server MUST be queried. SIP devices must have the capability to be configured with a User Name for DNS entry, in case there is no permanent IP address for the device or when moving the device. 5.3.2 Enrollment and Configuration Change Notification The enrollment of the SIP device at the configuration server and notifications of change from the configuration server to the SIP device MAY use the Event Notification in SIP [10], [11]. o A SIP device MAY enroll with the configuration servers using the Sinnreich, et al. Expires August 22, 2002 [Page 8] Internet-Draft SIP Telephony Device Requirements February 2002 SUBSCRIBE request. o The configuration server MAY provide the Configuration Change using the NOTIFY request. SIP devices MAY make use of the Config-Allow header field as specified in [2]. 5.3.3 Configuration Retrieval The SIP device MAY retrieve its configuration profile using the URLs specified by the configuration server in the NOTIFY request. 5.3.4 Configuration Upload The configuration server should support the ability to upload a changed configuration profile via the same URL the SIP device used to retrieve the configuration profile. 5.3.5 Firmware Upgrade The configuration server MUST provide the URL for the HTTP server for firmware upgrades. 5.3.6 Example of an Automatic Configuration Process with SUBSCRIBE/ NOTIFY. The target automatic configuration process SHOULD use the SIP SUBSCRIBE/NOTIFY messages. We refer the reader to [8] for message flows and example messages for an automatic configuration process using SUBSCRIBE/NOTIFY. This configuration method does not require an HTTP client and has the advantage that the server from can push the configuration data, without being prompted by the user. 5.3.7 Example of an Automatic Configuration Process without SUBSCRIBE/ NOTIFY Existing systems processes MAY use automatic configuration without SIP SUBSCRIBE/NOTIFY on a temporary basis. Such systems have the advantage of simplicity but have the disadvantage of requiring a different support infrastructure and different processes for each brand of SIP telephony device and may thus be a bigger operational burden for network managers and service providers.The method without SUBSCRIBE/NOTIFY SHOULD only be used until SIP-aware equipment is available. However, this method allows using existing NAT and firewall equipment.An example implementation would 1. acquire an Internet identity via DHCP or manual setup, Sinnreich, et al. Expires August 22, 2002 [Page 9] Internet-Draft SIP Telephony Device Requirements February 2002 2. load a generic configuration from a http URL that has previously been setup, and then 3. load a device specific configuration from a http URL that contains device specific information like its MAC address, device type and time zone. The http URL for retrieving configuration data is one of the configuration parameters, so that an operator may control where configuration data is read from. Generic configuration contain settings that apply to all devices that use this URL. This mechanism can be used to control the phones of a specific manufacturer in the realm of one operator.Device specific information can be addressed with additional parameters in the URL and MAY contain settings like SIP identities for the device. This way, a PERL script may set up the required device specific information. After plugging a phone the first time, the manufacturer can redirect the configuration URL to the operator that will control the device. For this purpose, the manufacturer has to maintain a database that lists which phone has been shipped to which operator. 6. Codecs and Media 6.1 Media Capabilities SIP devices MUST support at least one of the two basic media types: Text for IM and/or voice for the codecs listed in these requirements. SIP devices MAY support other media types such as video, whiteboard, data applications and games depending on the device type. SIP phones MUST have echo control, such as specified in the ITU-T G.165 Recommendation [13]. 6.2 DTMF RTP Payload SIP phones should be able to send DTMF digits as specified by RFC 2833 [14]. 6.3 Local Ringing 6.3.1 Play Single Early Media Stream SIP phones should play the first RTP stream and ignore any other RTP media streams when a "183 Session Progress" response is received. Sinnreich, et al. Expires August 22, 2002 [Page 10] Internet-Draft SIP Telephony Device Requirements February 2002 6.3.2 Use Last 18x Message Received SIP phones should obey the last 18x message received when multiple 18x responses are received. If the last response is "180 Ringing," the phone should generate local ringing. If the last response is "183 Session Progress," the phone should play the RTP stream. 6.4 Media and RTP/RTCP Support for Device Based Conferencing SIP devices MUST support audio mixing for at least two other conferencing participants for endpoint conference hosting in a three- way call. SIP devices that are advertised as "supporting conferencing" MUST support: 1. RTCP receiver reports for performance checking by the service provider or network administrator, and 2. Advertise the RTCP Synchronization Source Identifier to reliably inform all other conference participants who else is in the conference at any given time. This feature MUST be disabled in applications such as in call centers where the supervisor "barges in" to monitor agent handling of customers. 6.5 Codec Support and Negotiation SIP devices MUST support codec negotiation using SDP to accommodate various codec types and MAY support several of the available codecs from the list shown here. Silence suppression MUST be configurable, depending on the preferences of the service provider or the end user. 6.5.1 License Free Voice Codecs o G.711: SIP devices MUST support the G.711 codec with some form of Packet Loss Concealment (PLC) on the receiver side. o GSM Codec: SIP devices SHOULD support the GSM-EFR codec for mobile or otherwise bandwidth limited users. o ILBR Codec: SIP devices SHOULD support the emerging Internet Low Bit Rate Codec [12]. Sinnreich, et al. Expires August 22, 2002 [Page 11] Internet-Draft SIP Telephony Device Requirements February 2002 6.5.2 Voice Codecs and License Requirements o G.711: All SIP devices MUST support the license-free G.711 codec. Other codecs listed here MAY also be supported. o G.729: G.729A codec with silence suppression and Voice Activity Detections (VAD) MAY be supported. There MAY be a capability to turn VAD on or off via the configuration options in the server, or by input in the SIP device. o G.723.1: SIP devices MAY support G.723.1 codecs for users with narrowband access. o G.722: SIP devices MAY support the G.722 wideband audio codec with 16 kHz sampling rate or the GIPS wideband codec. 6.5.3 Video Codecs o H.263: SIP video devices MUST support H.263 as the default codec. o H.261: H.261 codecs MAY be also supported for interoperability with older systems. QCIF size images (176x144) SHOULD be supported. 7. Acoustic Properties SIP audio devices, such as used for telephony and conferencing MUST support: o Full phone to phone duplex communications when using the handset. Devices having a speakerphone may implement full duplex for the speakerphone function depending on the price-point of the device. o Echo control as specified by ITU-T G.165. It is the responsibility of the SIP telephony device to provide echo control. SIP telephony devices MUST NOT count on echo control in IP telephony gateways or elsewhere in the network. Acoustic properties for the headset, speakerphone and related features such as volume control and display of volume control depend on the class of device and on site specific requirements. Requirements for acoustic properties can be the object of site specific attachments to the generic requirements document. Sinnreich, et al. Expires August 22, 2002 [Page 12] Internet-Draft SIP Telephony Device Requirements February 2002 8. SIP Services Support SIP devices used for commercial enterprise communications SHOULD support the call flows for the basic and enhanced SIP services: 1. SIP Call Flow Examples [15] 2. SIP Service Examples [16] 3. Third Party Call Control in SIP [17] 4. SIP call control features [16] 5. SIP devices MAY support conferencing services for voice and IM [17], so as to be able act as host for a 3-way conference at least. 6. Presence based services [18] 7. Caller and called party preferences [19] 8. Roaming users: 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 user preferences. 9. The schema for uploading the identity from a PDA is outside the scope of these requirements. The call flows for items 1. and 2. 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. 3rd party call control enables many value added services, such as standard control of a SIP phone from a call manager application on the PC collocated on the desk with the SIP phone. 9. User Interface Requirements and Settings Installers and network administrators: Though the setup of SIP phones can be completely automatic and the device settings hidden from the end user, the device settings when made visible to installers and network administrators MUST use the terminology shown here. End users: SIP devices MUST comply with a minimal set of end user interface requirements, similar to those found in mobile phones or in automobiles, so that end users should be able to perform basic Sinnreich, et al. Expires August 22, 2002 [Page 13] Internet-Draft SIP Telephony Device Requirements February 2002 operations without any device specific training. To minimize the training required by end users and network support engineers, the terminology used in the display of SIP devices, network configuration and management MUST use the terminology in the list. 9.1 Address Input by User (Dialing) 9.1.1 Dialing Phone Numbers The phone number dialing procedure MAY be identical with the procedure employed for mobile phones: o A "backspace" or "clear" button SHOULD allow correcting mistaken entries, o An "enter" or "OK" button MAY initiate the call setup, o Overlap dialing MAY be supported. 9.1.2 Entering URLs SIP devices SHOULD have a convenient way of entering URLs in the form of e-mail style addresses. Suggested methods for entering URLs: o URL-guessing: From call history and/or from phone book o Auxiliary keyboard o Handwriting and/or keyboard on touch-screen o From a desktop PC, laptop or PDA o Voice recognition in the device or in the network o "Multitap" entry using the 12 key phone keypad, similar to mobile phones. Multitap is the least desirable fallback method for entering URLs 9.1.3 Emergency (911) Calling SIP devices SHOULD support emergency (911) calling either by entering an emergency number such as 911 (in the USA) or with a dedicated button. Emergency calls have to be routed to a preconfigured SIP server for emergency service. See par. 5.2 on setting of the Public Sinnreich, et al. Expires August 22, 2002 [Page 14] Internet-Draft SIP Telephony Device Requirements February 2002 Safety Access Point (PSAP) URL. The URL for emergency calls MUST use the universal emergency SIP URL sip:sos@domain in the SIP INVITE message, as specified in [8]. The SIP device MUST be able to make a DNS lookup to use the SIP URL for emergency calling. 9.2 Display and Settings for SIP Devices 9.2.1 General Behavior The display of the settings MAY become visible with a few keystrokes and SHOULD NOT be visible at all times. o Language: Specifies the language. SIP phones SHOULD display the local language and also MAY display the settings in English. Network and SIP parameters MUST be displayed exactly as they are used in relevant IETF documents. o Date and Time: Displays the current date and time for a given time zone. SIP devices SHOULD use a network time server. o Phone Type: Identifies the phone as SIP Phone, SIP version, Manufacturer and Type. Serial number MAY also be displayed. The software version MUST also be displayed. o User ID and Password: Displays the fields for user name and password required to access the embedded web server in the SIP phone. The entered password MUST be concealed. o Phone Name: Displays the name of the phone used in SIP signaling. 9.2.2 Network Settings o MAC Address: The read only MAC address of the device. o Configuration Server: Displays the URL for the configuration file. Can be HTTP (default) or TFTP. Examples: http:// phonesettings.isp.com/ http://settings.profispdevices.com/ o SIP Proxy: Displays the URL for the requests to the outgoing SIP server. o IP Address: Displays the IP address of the device. Sinnreich, et al. Expires August 22, 2002 [Page 15] Internet-Draft SIP Telephony Device Requirements February 2002 o Network Mask: Displays the mask for the IP address of the device. o DNS Domain: Displays the domain for DNS searching. o DNS Server(s): Displays one or more DNS servers used by the SIP device. o Update Server: Displays the URL of the server for software updates. o DHCP: Displays if DHCP is turned "ON" or "OFF". o Gateway: Displays the default router, not a VoIP gateway. o Time Server(s): Displays the URL of the network time server(s). 9.2.3 SIP Settings o User Real Name: This is the name displayed on the SIP phone owned by the user. o User (remote) Display Name: This is the name that is conveyed in the request URL, for example sip:John.Doe@sip3.isp.com o SIP Registrar Server: Displays the SIP registrar server in the request URI, for example in sip:John.Doe@sip3.isp.com, the registrar server is sip3.isp.com. o Contact Preference Q: Q indicates the order of preference in a list of contacts. Q can have values between 0.0 and 1.0. The value Q=1.0 expresses the highest preference. o Expire the Registration: The proposed expiration time for the registration. o User SIP URL: The SIP URL associated with the sip user, not the device. o Authentication Realm, User and Password: Displays the tuple for the SIP registrar and proxy authentication. The realm depends on the service provider. User name and password are provisioned on the SIP registrar. o Outgoing SIP Proxy: Displays the URL of the SIP proxy used for outgoing calls. o SIP retry timers T1 and T2: Should be set to 500 ms and 4,000 ms Sinnreich, et al. Expires August 22, 2002 [Page 16] Internet-Draft SIP Telephony Device Requirements February 2002 respectively. o Trace: For devices with logging capability. Can be set to true or false. o Session Timer: Displays the session timer in seconds. 0 disables the session timer, 3,600 is the default value. o SIP Refer: Displays the use of REFER. This flag can be set to "true" or "false". 9.2.4 Called Party Preferences These parameters SHOULD reflect the features in the Internet Draft on Caller Preferences [19]. Feature rich SIP phones that support Called Party Preferences SHOULD enable the caller to instruct the outgoing SIP server for which URI's to proxy or redirect to, whether to fork or not, whether to search recursively or not and whether to search in parallel or sequentially. The specific display to the user of the menu for caller preferences is beyond the objective of this document. Redirect Event: Can be "all" for redirect always, "none" for never, "busy" when encountering busy or "time" after the redirect timer times out. 9.2.5 Codec Settings SIP devices SHOULD display the available codecs, such as G.711, G.723.1, G.729, G.722, GSM, GIPS and their variants. Though codec negotiation is automatic, there SHOULD be the provision to select a certain codec as default or on a per call basis. 9.2.6 Redirection of Fax Calls SIP telephony devices MAY by configured with the users preferred fax URL. With this feature, incoming fax calls can be forwarded to the users fax machine. 9.2.7 Diagnostics SIP telephony devices MAY feature a log file for the most recent call, accessible to expert users, to determine for example why a call has failed. 9.2.8 Dedicated Announcement Lamps/Display Windows SIP devices SHOULD be provided with dedicated announcement lamps or Sinnreich, et al. Expires August 22, 2002 [Page 17] Internet-Draft SIP Telephony Device Requirements February 2002 announcement windows on display screens, such as for: o Call Waiting indicator o Message Waiting indicator o Single Line Extension using Presence [9]. Frugal SIP devices that do not have some of these announcement lamps and no screen, SHOULD alert users of message waiting and call waiting with tones or speech alerts. 10. Security SIP devices exposed to the public Internet SHOULD support HTTP over TLS [20] for device configuration messages. SIP phones exposed to the public Internet MUST support SIP Digest Authentication. 11. Network Management for SIP Telephony Devices Large organizations may require advanced systems to manage SIP devices in an efficient manner. For this reason, at least high-end SIP devices such as agent workstations, executive desktop phones, and conference room audio/video systems MUST provide adequate network management support. High-end SIP devices SHOULD support SNMP and standard MIBs for SIP [21] and RTP [22]. High-end SIP devices MAY generate RTCP receiver reports for the network management system and make them also accessible to the end user of the SIP telephony device. 12. Wired and Wireless LAN Support 12.1 Wired LAN Support Desktop SIP telephony devices MUST support 802.3 Ethernet LAN connectivity and MAY support other link layers as well. 802.3 Ethernet LAN connectivity SHOULD be manually configurable for: o 10 Mb/s - 100 Mb/s LAN speed o Half duplex and full duplex setting at both speeds, o Auto-sensing MAY be supported Sinnreich, et al. Expires August 22, 2002 [Page 18] Internet-Draft SIP Telephony Device Requirements February 2002 12.2 Wireless LAN Support Cordless SIP devices and PDAs MAY support wireless Ethernet 802.11b LANs and MAY also support emerging 802.11a wireless LANs. Besides the link layers listed here, SIP telephony devices MAY support any other wired and wireless link layers, especially those for existing and emerging mobile services. 13. Power for SIP Desk Phones SIP desk phones SHOULD be able to obtain operating electrical power be supplied via the Ethernet cable from the Ethernet hub or switch, where available [23]. Power for all SIP desktop devices MUST be able to be powered by an AC power supply. AC power supplies MAY have universal 110/220 V, 50-60 Hz power input that requires no location specific configuration. 14. Acknowledgements The authors would like to thank 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. References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Rosenberg, J., et al, "SIP: Session Initiation Protcol", work in progress draft-ietf-sip-rfc2543bis-06, January 2002. [3] TIA/EIA-810-A, "Transmission Requirements for Narrowband Voice over IP and Voice over PCM Digital Wireline Telephones", July 2000. [4] TIA-EIA-IS-811, "Terminal Equipment - Peformance and Interoperability Requirements for Voice-over-IP (VoIP) Feature Telephones", July 2000. [5] Braden, R., "Requirements for Internet Hosts -- Communication Layers", RFC 1122, October 1989. [6] Petrie, D., "A Framework for SIP User Agent Configuration", draft-petrie-sip-config-framework, work in progress, March 2001. Sinnreich, et al. Expires August 22, 2002 [Page 19] Internet-Draft SIP Telephony Device Requirements February 2002 [7] Schulzrinne, H., "DHCP Option for SIP Servers", draft-ietf-sip- dhcp-05, work in progress, November 2001. [8] Petrie, D., "Exchanging SIP Configuration", work in progress , February 2002. [9] Schulzrinne, H., "Universal Emergency Address for SIP-based Internet Telephony", IETF Internet Draft work in progress, July 2001. [10] Rosenberg, J. and H. Schulzrinne, "SIP Event Packages for Call Leg and Conference State", work in progress, November 2001. [11] Roach, A., "SIP-Specific Event Notification", work in progress, November 2001. [12] Andersen, S. V., et. al., "Internet Low Bit Rate Codec", draft- andersen-mmusic-ilbc-01, work in progress, February 2002. [13] ITU-T G.165, "ITU-T Recommendation G.165: Digital Network Echo Cancellers", April 2000. [14] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals", RFC 2833, May 2000. [15] Johnston, A. et al., "SIP Call Flow Examples", work in progress, June 2001. [16] Johnston, A. et al., "SIP Service Examples", work in progress, November 2001. [17] Rosenberg, J., et al., "Third Party Call Control", work in progress, November 2001. [18] Mahy, R., "A Call Control Model for SIP", work in progress, November 2001. [19] Rosenberg, J., et al., "SIP Extensions for Instant Messaging", work in progress, July 2001. [20] Rosenberg, J., et al., "SIP Extensions for Presence", work in progress, November 2001. [21] Schuzlrinne, H. and J. Rosenberg, "SIP Caller Preferences and Callee Capabilities", work in progress, November 2001. [22] Rescorla, E., "HTTP over TLS", RFC 2818, May 2000. Sinnreich, et al. Expires August 22, 2002 [Page 20] Internet-Draft SIP Telephony Device Requirements February 2002 [23] Lingle, K., "Management Information Base for Session Initiation Protocol", work in progress, June 2001. [24] Baugher, M., et al., "Real-Time Transport Protocol Management Information Base", RFC 2959, October 2000. [25] 802.3af Task Force, "", http://http://grouper.ieee.org/groups/ 802/3/af/public/documents/index.html . Authors' Addresses Henry Sinnreich WorldCom 400 International Parkway Richardson, TX 75081 US EMail: henry.sinnreich@wcom.com URI: http://www.worldcom.com/ Steven Lass WorldCom 400 International Parkway Richardson, TX 75081 US EMail: steven.lass@wcom.com URI: http://www.worldcom.com/ Jonathan Knight WorldCom 2424 W. Garden of the Gods Colorado Springs, CO 80919 US EMail: steven.lass@wcom.com URI: http://www.worldcom.com/ Sinnreich, et al. Expires August 22, 2002 [Page 21] Internet-Draft SIP Telephony Device Requirements February 2002 Daniel Petrie pingTel Corp. 400 West Cummings Park Suite 2200 Woburn, MA 01801 US EMail: dpetrie@pingtel.com URI: http://www.pingtel.com/ Christian Stredicke snom technology AG Pascalstrasse 10 Berlin 10587 US EMail: stredicke@snom.de URI: http://www.snom.de/ Sinnreich, et al. Expires August 22, 2002 [Page 22] Internet-Draft SIP Telephony Device Requirements February 2002 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Sinnreich, et al. Expires August 22, 2002 [Page 23]