Request for Comments: 4504 pulver.com
Category: Informational S. Lass
Verizon
C. Stredicke
snom
May 2006
SIP Telephony Device Requirements and Configuration
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document describes the requirements for SIP telephony devices,
based on the deployment experience of large numbers of SIP phones and
PC clients using different implementations in various networks. The
objectives of the requirements are a well-defined set of
interoperability and multi-vendor-supported core features, so as to
enable similar ease of purchase, installation, and operation as found
for PCs, PDAs, analog feature phones or mobile phones.
We present a glossary of the most common settings and some of the
more widely used values for some settings.
Table of Contents
1. Introduction ....................................................3
1.1. Conventions used in this document ..........................4
2. Generic Requirements ............................................4
2.1. SIP Telephony Devices ......................................4
2.2. DNS and ENUM Support .......................................5
2.3. SIP Device Resident Telephony Features .....................5
2.4. Support for SIP Services ...................................8
2.5. Basic Telephony and Presence Information Support ...........9
2.6. Emergency and Resource Priority Support ....................9
2.7. Multi-Line Requirements ...................................10
2.8. User Mobility .............................................11
2.9. Interactive Text Support ..................................11
2.10. Other Related Protocols ..................................12
2.11. SIP Device Security Requirements .........................13
2.12. Quality of Service .......................................13
2.13. Media Requirements .......................................14
2.14. Voice Codecs .............................................14
2.15. Telephony Sound Requirements .............................15
2.16. International Requirements ...............................15
2.17. Support for Related Applications .........................16
2.18. Web-Based Feature Management .............................16
2.19. Firewall and NAT Traversal ...............................16
2.20. Device Interfaces ........................................17
3. Glossary and Usage for the Configuration Settings ..............18
3.1. Device ID .................................................18
3.2. Signaling Port ............................................19
3.3. RTP Port Range ............................................19
3.4. Quality of Service ........................................19
3.5. Default Call Handling .....................................19
3.5.1. Outbound Proxy .....................................19
3.5.2. Default Outbound Proxy .............................20
3.5.3. SIP Session Timer ..................................20
3.6. Telephone Dialing Functions ...............................20
3.6.1. Phone Number Representations .......................20
3.6.2. Digit Maps and/or the Dial/OK Key ..................20
3.6.3. Default Digit Map ..................................21
3.7. SIP Timer Settings ........................................21
3.8. Audio Codecs ..............................................21
3.9. DTMF Method ...............................................22
3.10. Local and Regional Parameters ............................22
3.11. Time Server ..............................................22
3.12. Language .................................................23
3.13. Inbound Authentication ...................................23
3.14. Voice Message Settings ...................................23
3.15. Phonebook and Call History ...............................24
3.16. User-Related Settings and Mobility .......................24
3.17. AOR-Related Settings .....................................25
3.18. Maximum Connections ......................................25
3.19. Automatic Configuration and Upgrade ......................25
3.20. Security Configurations ..................................26
4. Security Considerations ........................................26
4.1. Threats and Problem Statement .............................26
4.2. SIP Telephony Device Security .............................27
4.3. Privacy ...................................................28
4.4. Support for NAT and Firewall Traversal ....................28
5. Acknowledgements ...............................................29
6. Informative References .........................................31
1. Introduction
This document has the objective of focusing the Internet
communications community on requirements for telephony devices using
SIP.
We base this information from developing and using a large number of
SIP telephony devices 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 user device enabled for SIP-
based IP telephony. SIP telephony user devices can be SIP phones,
adaptors for analog phones and for fax machines, conference
speakerphones, software packages (soft clients) running on PCs,
laptops, wireless connected PDAs, ’Wi-Fi’ SIP mobile phones, as well
as other mobile and cordless phones that support SIP signaling for
real-time communications. SIP-PSTN gateways are not the object of
this memo, since they are network elements and not end user devices.
SIP telephony devices can also be instant messaging (IM) applications
that have a telephony option.
SIP devices MAY support various other media besides voice, such as
text, video, games, and other Internet applications; however, the
non-voice requirements are not specified in this document, except
when providing enhanced telephony features.
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, (3) manufacturers, and
(4) system integrators.
The objectives of the requirements are a well-defined 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 feature-rich display phones may approach the cost of PCs
and PDAs, similar or even better ease of use as compared to personal
computers and networked PDAs is expected by both end users and
network administrators.
While some of the recommendations of this document go beyond what is
currently mandated for SIP implementations within the IETF, this is
believed necessary to support the specified operational objectives.
However, it is also important to keep in mind that the SIP
specifications are constantly evolving; thus, these recommendations
need to be considered in the context of that change and evolution.
Due to the evolution of IETF documents in the standards process, and
the informational nature of this memo, the references are all
informative.
1.1. Conventions used in this document
This document is informational and therefore the key words "MUST",
"SHOULD", "SHOULD NOT", and "MAY", in this document are not to be
interpreted as described in RFC 2119 [1], but rather indicate the
nature of the suggested requirement.
2. Generic Requirements
We present here a minimal set of requirements that MUST be met by all
SIP [2] telephony devices, except where SHOULD or MAY is specified.
2.1. SIP Telephony Devices
This memo applies mainly to desktop phones and other special purpose
SIP telephony hardware. Some of the requirements in this section are
not applicable to PC/laptop or PDA software phones (soft phones) and
mobile phones.
Req-1: SIP telephony devices MUST be able to acquire IP network
settings by automatic configuration using Dynamic Host
Configuration Protocol (DHCP) [3].
Req-2: SIP telephony devices MUST be able to acquire IP network
settings by manual entry of settings from the device.
Req-3: SIP telephony devices SHOULD support IPv6. Some newer
wireless networks may mandate support for IPv6 and in such
networks SIP telephony devices MUST support IPv6.
Req-4: SIP telephony devices MUST support the Simple Network Time
Protocol [4].
Req-5: Desktop SIP phones and other special purpose SIP telephony
devices MUST be able to upgrade their firmware to support
additional features and the functionality.
Req-6: Users SHOULD be able to upgrade the devices with no special
applications or equipment; or a service provider SHOULD be
able to push the upgrade down to the devices remotely.
2.2. DNS and ENUM Support
Req-7: SIP telephony devices MUST support RFC 3263 [5] for locating a
SIP server and selecting a transport protocol.
Req-8: SIP telephony devices MUST incorporate DNS resolvers that are
configurable with at least two entries for DNS servers for
redundancy. To provide efficient DNS resolution, SIP
telephony devices SHOULD query responsive DNS servers and skip
DNS servers that have been non-responsive to recent queries.
Req-9: To provide efficient DNS resolution and to limit post-dial
delay, SIP telephony devices MUST cache DNS responses based on
the DNS time-to-live.
Req-10: For DNS efficiency, SIP telephony devices SHOULD use the
additional information section of the DNS response instead of
generating additional DNS queries.
Req-11: SIP telephony devices MAY support ENUM [6] in case the end
users prefer to have control over the ENUM lookup. Note: The
ENUM resolver can also be placed in the outgoing SIP proxy to
simplify the operation of the SIP telephony device. The
Extension Mechanisms for DNS (EDNSO) in RFC 2671 SHOULD also
be supported.
2.3. SIP Device Resident Telephony Features
Req-12: SIP telephony devices MUST support RFC 3261 [2].
Req-13: SIP telephony devices SHOULD support the SIP Privacy header
by populating headers with values that reflect the privacy
requirements and preferences as described in "User Agent
Behavior", Section 4 of RFC 3323 [7].
Req-14: SIP telephony devices MUST be able to place an existing call
on hold, and initiate or receive another call, as specified
in RFC 3264 [8] and SHOULD NOT omit the sendrecv attribute.
Req-15: SIP telephony devices MUST provide a call waiting indicator.
When 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 the call waiting indicator.
Req-16: SIP telephony devices MUST support SIP message waiting [9]
and the integration with message store platforms.
Req-17: SIP telephony devices MAY support a local dial plan. If a
dial plan is supported, it MUST be able to match the user
input to one of multiple pattern strings and transform the
input to a URI, including an arbitrary scheme and URI
parameters.
Example: If a local dial plan is supported, it SHOULD be configurable
to generate any of the following URIs when "5551234" is dialed:
tel:+12125551234
sip:+12125551234@example.net;user=phone
sips:+12125551234@example.net;user=phone
sip:5551234@example.net
sips:5551234@example.net
tel:5551234;phone-context=nyc1.example.net
sip:5551234;phone-
context=nyc1.example.net@example.net;user=phone
sips:5551234;phone-
context=nyc1.example.net@example.net;user=phone
sip:5551234;phone-
context=nyc1.example.net@example.net;user=dialstring
sips:5551234;phone-
context=nyc1.example.net@example.net;user=dialstring
tel:5551234;phone-context=+1212
sip:5551234;phone-context=+1212@example.net;user=phone
sips:5551234;phone-context=+1212@example.net;user=phone
sip:5551234;phone-context=+1212@example.net;user=dialstring
sips:5551234;phone-context=+1212@example.net;user=dialstring
If a local dial plan is not supported, the device SHOULD be
configurable to generate any of the following URIs when "5551234" is
dialed:
sip:5551234@example.net
sips:5551234@example.net
sip:5551234;phone-
context=nyc1.example.net@example.net;user=dialstring
sips:5551234;phone-
context=nyc1.example.net@example.net;user=dialstring
sip:5551234;phone-context=+1212@example.net;user=dialstring
sips:5551234;phone-context=+1212@example.net;user=dialstring"
Req-18: SIP telephony devices MUST support URIs for telephone numbers
as per RFC 3966 [10]. This includes the reception as well as
the sending of requests. The reception may be denied
according to the configurable security policy of the device.
It is a reasonable behavior to send a request to a
preconfigured outbound proxy.
Req-19: SIP telephony devices MUST support REFER and NOTIFY for call
transfer [11], [12]. SIP telephony devices MUST support
escaped Replaces-Header (RFC 3891) and SHOULD support other
escaped headers in the Refer-To header.
Req-20: SIP telephony devices MUST support the unattended call
transfer flows as defined in [12].
Req-21: SIP telephony devices MUST support the attended call transfer
as defined in [12].
Req-22: SIP telephony devices MAY support device-based 3-way calling
by mixing the audio streams and displaying the interactive
text of at least 2 separate calls.
Req-23: SIP telephony devices MUST be able to send dual-tone multi-
frequency (DTMF) named telephone events as specified by RFC
2833 [13].
Req-24: Payload type negotiation MUST comply with RFC 3264 [8] and
with the registered MIME types for RTP payload formats in RFC
3555 [14].
Req-25: The dynamic 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 the initial payload type. SIP
devices MAY support Flow Identification as defined in RFC
3388 [15].
Req-26: When acting as a User Agent Client (UAC), SIP telephony
devices SHOULD support the gateway model of RFC 3960 [16].
When acting as a User Agent Server (UAS), SIP telephony
devices SHOULD NOT send early media.
Req-27: SIP telephony devices MUST be able to handle multiple early
dialogs in the context of request forking. When a confirmed
dialog has been established, it is an acceptable behavior to
send a BYE request in response to additional 2xx responses
that establish additional confirmed dialogs.
Req-28: SIP devices with a suitable display SHOULD support the call-
info header and depending on the display capabilities MAY,
for example, display an icon or the image of the caller.
Req-29: To provide additional information about call failures, SIP
telephony devices with a suitable display MUST render the
"Reason Phrase" of the SIP message or map the "Status Code"
to custom or default messages. This presumes the language
for the reason phrase is the same as the negotiated language.
The devices MAY use an internal "Status Code" table if there
was a problem with the language negotiation.
Req-30: SIP telephony devices MAY support music on hold, both in
receive mode and locally generated. See also "SIP Service
Examples" for a call flow with music on hold [17].
Req-31: SIP telephony devices MAY ring after a call has been on hold
for a predetermined period of time, typically 3 minutes.
2.4. Support for SIP Services
Req-32: SIP telephony devices MUST support the SIP Basic Call Flow
Examples as per RFC 3665 [17].
Req-33: SIP telephony devices MUST support the SIP-PSTN Service
Examples as per RFC 3666 [18].
Req-34: SIP telephony devices MUST support the Third Party Call
Control model [19], in the sense that they may be the
controlled device.
Req-35: SIP telephony devices SHOULD support SIP call control and
multi-party usage [20].
Req-36: SIP telephony devices SHOULD support conferencing services
for voice [21], [22] and interactive text [23] and if
equipped with an adequate display MAY also support instant
messaging (IM) and presence [24], [25].
Req-37: SIP telephony devices SHOULD support the indication of the
User Agent capabilities and MUST support the caller
capabilities and preferences as per RFC 3840 [26].
Req-38: SIP telephony devices MAY support service mobility: Devices
MAY allow roaming users to input 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, dialing plan, personal directory,
and caller preferences.
2.5. Basic Telephony and Presence Information Support
The large color displays in some newer models make such SIP phones
and applications attractive for a rich communication environment.
This document is focused, however, only on telephony-specific
features enabled by SIP Presence and SIP Events.
SIP telephony devices can also support presence status, such as the
traditional Do Not Disturb, new event state-based information, such
as being in another call or being in a conference, typing a message,
emoticons, etc. Some SIP telephony User Agents can support, for
example, a voice session and several IM sessions with different
parties.
Req-39: SIP telephony devices SHOULD support Presence information
[24] and SHOULD support the Rich Presence Information Data
Format [27] for the new IP communication services enabled by
Presence.
Req-40: Users MUST be able to set the state of the SIP telephony
device to "Do Not Disturb", and this MAY be manifested as a
Presence state across the network if the UA can support
Presence information.
Req-41: SIP telephony devices with "Do Not Disturb" enabled MUST
respond to new sessions with "486 Busy Here".
2.6. Emergency and Resource Priority Support
Req-42: Emergency calling: For emergency numbers (e.g., 911, SOS
URL), SIP telephony devices SHOULD support the work of the
ECRIT WG [28].
Req-43: Priority header: SIP devices SHOULD support the setting by
the user of the Priority header specified in RFC 3261 for
such applications as emergency calls or for selective call
acceptance.
Req-44: Resource Priority header: SIP telephony devices that are used
in environments that support emergency preparedness MUST also
support the sending and receiving of the Resource-Priority
header as specified in [29]. The Resource Priority header
influences the behavior for message routing in SIP proxies
and PSTN telephony gateways and is different from the SIP
Priority header specified in RFC 3261. Users of SIP
telephony devices may want to be interrupted in their lower-
priority communications activities if such an emergency
communication request arrives.
Note: As of this writing, we recommend that implementers follow the
work of the Working Group on Emergency Context Resolution with
Internet Technologies (ecrit) in the IETF. The complete solution is
for further study at this time. There is also work on the
requirements for location conveyance in the SIPPING WG, see [30].
2.7. Multi-Line Requirements
A SIP telephony device can have multiple lines: One SIP telephony
device can be registered simultaneously with different SIP registrars
from different service providers, using different names and
credentials for each line. The different sets of names and
credentials are also called ’SIP accounts’. The "line" terminology
has been borrowed from multi-line PSTN/PBX phones, except that for
SIP telephony devices there can be different SIP registrars/proxies
for each line, each of which may belong to a different service
provider, whereas this would be an exceptional case for the PSTN and
certainly not the case for PBX phones. Multi-line SIP telephony
devices resemble more closely e-mail clients that can support several
e-mail accounts.
Note: Each SIP account can usually support different Addresses of
Record (AORs) with a different list of contact addresses (CAs), as
may be convenient, for example, when having different SIP accounts
for business and personal use. However, some of the CAs in different
SIP accounts may point to the same devices.
Req-45: Multi-line SIP telephony devices MUST support a unique
authentication username, authentication password, registrar,
and identity to be provisioned for each line. The
authentication username MAY be identical with the user name
of the AOR and the domain name MAY be identical with the host
name of the registrar.
Req-46: Multi-line SIP telephony devices MUST be able to support the
state of the client to Do Not Disturb on a per line basis.
Req-47: Multi-line SIP telephony devices MUST support multi-line call
waiting indicators. Devices MUST allow the call waiting
indicator to be set on a per line basis.
Req-48: Multi-line SIP telephony devices MUST be able to support a