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]