SIP Telephony Device Requirements and Configuration
draft-sinnreich-sipdev-req-08
The information below is for an old version of the document that is already published as an RFC.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 4504.
|
|
|---|---|---|---|
| Authors | Christian Stredicke , Steven Lass , Dr. Henry Sinnreich | ||
| Last updated | 2018-12-20 (Latest revision 2005-10-21) | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | Informational | ||
| Formats | |||
| Stream | WG state | (None) | |
| Document shepherd | (None) | ||
| IESG | IESG state | Became RFC 4504 (Informational) | |
| Action Holders |
(None)
|
||
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | Jon Peterson | ||
| Send notices to | henry.sinnreich@mci.com |
draft-sinnreich-sipdev-req-08
SIPPING WG H. Sinnreich/pulver.com, editor
Internet Draft S. Lass/MCI
C. Stredicke/snom
October 2005
SIP Telephony Device Requirements and Configuration
draft-sinnreich-sipdev-req-08.txt
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.
By submitting this Internet-Draft, each author represents
that any applicable patent or other IPR claims of which he
or she is aware have been or will be disclosed, and any of
which he or she becomes aware will be disclosed, in
accordance with Section 6 of BCP 79.
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 May 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.
Expires May 2006 [Page 1]
draft-sinnreich-sipdev-req-08.txt October 2005
Conventions used in this document
This document is informational and therefore the key words
"MUST", "SHOULD", "SHOULD NOT", "MAY", in this document are
not to be interpreted as described in RFC 2119 [2], but
rather indicate the nature of the suggested requirement.
Table of Contents
1. Introduction...............................................3
2. Generic Requirements.......................................4
2.1. SIP Telephony Devices.................................4
2.2. DNS and ENUM Support..................................5
2.3. SIP Device Resident Telephony Features................6
2.4. Support for SIP Services..............................9
2.5. Basic Telephony and Presence Information Support.....10
2.6. Emergency and Resource Priority Support..............11
2.7. Multi-Line Requirements..............................12
2.8. User Mobility........................................13
2.9. Interactive Text Support.............................13
2.10. Other Related Protocols.............................15
2.11. SIP Device Security Requirements....................15
2.12. Quality of Service..................................16
2.13. Media Requirements..................................16
2.14. Voice Codecs........................................17
2.15. Telephony Sound Requirements........................18
2.16. International Requirements..........................18
2.17. Support for Related Applications....................19
2.18. Web Based Feature Management........................19
2.19. Firewall and NAT Traversal..........................19
2.20. Device Interfaces...................................20
3. Glossary and Usage for the Configuration Settings.........21
3.1. Device ID............................................22
3.2. Signaling Port.......................................22
3.3. RTP Port Range.......................................22
3.4. Quality of Service...................................22
3.5. Default Call Handling................................23
3.5.1. Outbound Proxy..................................23
3.5.2. Default Outbound Proxy..........................23
3.5.3. SIP Session Timer...............................23
3.6. Telephone Dialing Functions..........................23
3.6.1. Phone Number Representations....................23
3.6.2. Digit Maps and/or the Dial/OK Key...............24
3.6.3. Default Digit Map...............................25
3.7. SIP Timer Settings...................................25
3.8. Audio Codecs.........................................25
3.9. DTMF Method..........................................25
3.10. Local and Regional Parameters.......................26
3.11. Time Server.........................................26
Expires May, 2006 [Page 2]
draft-sinnreich-sipdev-req-08.txt October 2005
3.12. Language............................................26
3.13. Inbound Authentication..............................27
3.14. Voice Message Settings..............................27
3.15. Phonebook and Call History..........................27
3.16. User Related Settings and Mobility..................28
3.17. AOR Related Settings................................28
3.18. Maximum Connections.................................29
3.19. Automatic Configuration and Upgrade.................29
3.20. Security Configurations.............................29
4. Security Considerations...................................30
4.1. Threats and Problem Statement........................30
4.2. SIP Telephony Device Security........................31
4.3. Privacy..............................................32
4.4. Support for NAT and Firewall Traversal...............32
5. IANA Considerations.......................................33
6. Acknowledgments...........................................33
7. Changes from Previous Versions............................34
8. References................................................36
9. Author's Addresses........................................42
10. Copyright Notice.........................................43
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.
Expires May, 2006 [Page 3]
draft-sinnreich-sipdev-req-08.txt October 2005
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 and (3) manufacturers, as well as (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 being evolved, 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
usual distinction between normative and informative
references is not made here.
2. Generic Requirements
We present here a minimal set of requirements that MUST be
met by all SIP [3] 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.
Expires May, 2006 [Page 4]
draft-sinnreich-sipdev-req-08.txt October 2005
Req-1: SIP telephony devices MUST be able to acquire IP
network settings by automatic configuration using
DHCP [4].
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 [5].
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 [6] 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.
Expires May, 2006 [Page 5]
draft-sinnreich-sipdev-req-08.txt October 2005
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 [7] 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.
2.3. SIP Device Resident Telephony Features
Req-12: SIP telephony devices MUST support RFC 3261 [3].
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 "Section 4 User Agent Behavior" in RFC 3323 [8].
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 [12] 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 [43] and the integration with message store
platforms.
Expires May, 2006 [Page 6]
draft-sinnreich-sipdev-req-08.txt October 2005
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"
Expires May, 2006 [Page 7]
draft-sinnreich-sipdev-req-08.txt October 2005
Req-18: SIP telephony devices MUST support URIs for telephone
numbers as per RFC 3966 [9]. 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 [45], [46]. 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 [46].
Req-21: SIP telephony devices MUST support the attended call
transfer as defined in [46].
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 DTMF named
telephone events as specified by RFC 2833 [11].
Req-24: Payload type negotiation MUST comply with RFC 3264
[12] and with the registered MIME types for RTP
payload formats in RFC 3555 [13].
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
[14].
Expires May, 2006 [Page 8]
draft-sinnreich-sipdev-req-08.txt October 2005
Req-26: When acting as a UAC, SIP telephony devices SHOULD
support the gateway model of RFC 3960 [71]. When
acting as a 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 or locally generated. See also "SIP
Service Examples" for a call flow with music on hold
[46].
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 [47].
Expires May, 2006 [Page 9]
draft-sinnreich-sipdev-req-08.txt October 2005
Req-33: SIP telephony devices MUST support the SIP-PSTN
Service Examples as per RFC 3666 [16].
Req-34: SIP telephony devices MUST support the Third Party
Call Control model [17], in the sense that they may
be the controlled device.
Req-35: SIP telephony devices SHOULD support SIP call control
and multiparty usage [42].
Req-36: SIP telephony devices SHOULD support conferencing
services for voice [48], [49] and interactive text
[56] and if equipped with an adequate display MAY
also support instant messaging (IM) and presence
[50], [59].
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
[52].
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, the 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.
Expires May, 2006 [Page 10]
draft-sinnreich-sipdev-req-08.txt October 2005
Req-39: SIP telephony devices SHOULD support Presence
information [50] and SHOULD support the Rich Presence
Information Data Format [51] 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 [54].
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 [55]. 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 implementers to follow
the work of the Working Group on Emergency Context Resolution
with Internet Technologies (ecrit) in the IETF. The complete
Expires May, 2006 [Page 11]
draft-sinnreich-sipdev-req-08.txt October 2005
solution is for further study at this time. There is also
work on the requirements for location conveyance in the
SIPPING WG, see [77].
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 registrar/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 (AOR) with a different list of contact
addresses (CA), as may be convenient for example when having
different SIP accounts for business and for the private
life. Some of the CAs in different SIP accounts may though
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.
Expires May, 2006 [Page 12]
draft-sinnreich-sipdev-req-08.txt October 2005
Req-48: Multi-line SIP telephony devices MUST be able to
support a few different ring tones for different
lines. We specify here "a few", since provisioning
different tones for all lines may be difficult for
phones with many lines.
2.8. User Mobility
The following requirements allow users with a set of
credentials to use any SIP telephony device that can support
personal credentials from several users, distinct from the
identity of the device.
Req-49: User mobility enabled SIP telephony devices MUST
store static credentials associated with the device
in non-volatile memory. This static profile is used
during the power up sequence.
Req-50: User mobility enabled SIP telephony devices SHOULD
allow a user to walk up to a device and input their
personal credentials. All user features and settings
stored in home SIP proxy and the associated policy
server SHOULD be available to the user.
Req-51: User mobility enabled SIP telephony devices
registered as fixed desktop with network
administrator MUST use the local static location data
associated with the device for emergency calls.
2.9. Interactive Text Support
SIP telephony devices supporting Instant Messaging based on
SIMPLE [50] support text conversation based on blocks of
text. However, continuous interactive text conversation may
be sometimes preferred as a parallel to voice, due to its
interactive and more streaming-like nature, thus more
appropriate for real time conversation. It also allows for
text captioning of voice in noisy environments and for those
who cannot hear well or cannot hear at all.
Finally continuous, character by character text is what is
preferred by emergency and public safety programs (e.g. 112
and 911) because of its immediacy, efficiency, lack of
crossed messages problem, better ability to interact with a
Expires May, 2006 [Page 13]
draft-sinnreich-sipdev-req-08.txt October 2005
confused person, and the additional information that can be
observed from watching the message as it is composed.
Req-52: SIP telephony devices such as SIP display phones and
IP-analog adapters SHOULD support the accessibility
requirements for the deaf, hard of hearing and speech
impaired individuals as per RCF 3351 [18] and also
for interactive text conversation [56], [70].
Req-53: SIP telephony devices SHOULD provide a way to input
text and to display text through any reasonable
method. Built-in user interfaces, standard wired or
wireless interfaces, and/or support for text through
a web interface are all considered reasonable
mechanisms.
Req-54: SIP telephony devices SHOULD provide an external
standard wired or wireless link to connect external
input (keyboard, mouse) and display devices.
Req-55: SIP telephony devices which include a display, or
have a facility for connecting an external display,
MUST include protocol support as described in RFC
2793 for real-time interactive text.
Req-56: There may be value of having RFC 2793 support in a
terminal also without a visual display. A synthetic
voice output for the text conversation may be of
value for all who can hear, and thereby having the
opportunity to have a text conversation with other
users.
Req-57: SIP telephony devices MAY provide analog adaptor
functionality through an RJ-11 FXS port to support
FXS devices. If an RJ-11 (FXS) port is provided, then
it MAY support a gateway function from all text-
telephone protocols according to ITU-T Recommendation
V.18 to RFC 2793 text conversation (in fact this is
encouraged in the near term during the transition to
widespread use of SIP telephony devices). If this
gateway function is not included or fails, the device
Expires May, 2006 [Page 14]
draft-sinnreich-sipdev-req-08.txt October 2005
MUST pass-through all text-telephone protocols
according to ITU-T Recommendation V.18, November
2000, in a transparent fashion.
Req-58: SIP telephony devices MAY provide a 2.5 mm audio
port, in portable SIP devices, such as PDAs and
various wireless SIP phones.
2.10. Other Related Protocols
Req-59: SIP telephony devices MUST support the Real-Time
Protocol and the Real-Time Control Protocol, RFC 3550
[20]. SIP devices SHOULD use RTCP Extended Reports
for logging and reporting on network support for
voice quality, RFC 2611 [21] and MAY also support the
RTCP summary report delivery [57].
2.11. SIP Device Security Requirements
Req-60: SIP telephony devices MUST support digest
authentication as per RFC3261. In addition, SIP
telephony devices MUST support TLS for secure
transport [36] for scenarios where the SIP registrar
is located outside the secure, private IP network in
which the SIP UA may reside. Note: TLS need not be
used in every call though.
Req-61: SIP telephony devices MUST be able to password
protect configuration information and administrative
functions.
Req-62: SIP telephony devices MUST NOT display the password
to the user or administrator after it has been
entered.
Req-63: SIP clients MUST be able to disable remote access,
i.e. block incoming SNMP (where this is supported),
HTTP, and other services not necessary for basic
operation.
Expires May, 2006 [Page 15]
draft-sinnreich-sipdev-req-08.txt October 2005
Req-64: SIP telephony devices MUST support the option to
reject an incoming INVITE where the user-portion of
the SIP request URI is blank or does not match a
provisioned contact. This provides protection against
war-dialer attacks, unwanted telemarketing and spam.
The setting to reject MUST be configurable.
Req-65: When TLS is not used, SIP telephony devices MUST be
able to reject an incoming INVITE when the message
does not come from the proxy or proxies where the
client is registered. This prevents callers from
bypassing terminating call features on the proxy. For
DNS SRV specified proxy addresses, the client must
accept an INVITE from all of the resolved proxy IP
addresses.
2.12. Quality of Service
Req-66: SIP devices MUST support the IPv4 DSCP field for RTP
streams as per RFC 2597 [22]. The DSCP setting MUST
be configurable to conform with the local network
policy.
Req-67: If not specifically provisioned, SIP telephony
devices SHOULD mark RTP packets with the recommended
DSCP for expedited forwarding (codepoint 101110); and
mark SIP packets with DSCP AF31 (codepoint 011010).
Req-68: SIP telephony devices MAY support RSVP [23].
2.13. Media Requirements
Req-69: To simplify the interoperability issues, SIP
telephony devices MUST use the first matching codec
listed by the receiver if the requested codec is
available in the called device. See the offer/answer
model in RFC 3261.
Req-70: To reduce overall bandwidth, SIP telephony devices
MAY support active voice detection and comfort noise
generation.
Expires May, 2006 [Page 16]
draft-sinnreich-sipdev-req-08.txt October 2005
2.14. Voice Codecs
Internet telephony devices face the problem of supporting
multiple codecs due to various historic reasons, on how
telecom industry players have approached codec
implementations and the serious intellectual property and
licensing problems associated with most codec types.
RFC 3551 for example [24] lists 17 registered MIME subtypes
for audio codecs.
Ideally, the more codecs can be supported in a SIP telephony
device, the better, since it enhances the chances of success
during the codec negotiation at call setup and avoids media
intermediaries used for codec mediation.
Implementers interested in a short list MAY however support
a minimal number of codecs used in wireline VoIP, and also
codecs found in mobile networks for which the SIP UA is
targeted. An ordered short list of preferences may look as
this:
Req-71: SIP telephony devices SHOULD support AVT payload type
0 (G.711 uLaw) as in reference [25] and its Annexes 1
and 2.
Req-72: SIP telephony devices SHOULD support the Internet Low
Bit Rate codec (iLBC) [26], [27].
Req-73: Mobile SIP telephony devices MAY support codecs found
in various wireless mobile networks. This can avoid
codec conversion in network based intermediaries.
Req-74: SIP telephony devices MAY support a small set of
special purpose codecs, such as G.723.1, where low
bandwidth usage is needed (for dial-up Internet
access), SPEEX [28] or G.722 for high quality audio
conferences.
Req-75: SIP telephony devices MAY support G.729 and its
annexes. Note: The G.729 codec is included here for
backward compatibility only, since the iLBC and the
G.723.1 codecs are preferable in bandwidth
constrained environments.
Expires May, 2006 [Page 17]
draft-sinnreich-sipdev-req-08.txt October 2005
Note: The authors believe the Internet Low Bit Rate
codec (iLBC) should be the default codec for Internet
telephony.
A summary count reveals up to 25 and more voice codec
types currently in use. The authors believe there is
also a need for a single multi-rate Internet codec,
such as Speex [28] or similar that can effectively be
substituted for all of the multiple legacy G.7xx
codec types, such as G. 711, G.729, G.723.1, G.722,
etc. for various data rates, thus avoiding the
complexity and cost to implementers and service
providers alike who are burdened by supporting so
many codec types, besides the licensing costs.
2.15. Telephony Sound Requirements
Req-76: SIP telephony devices SHOULD comply with the handset
receive comfort noise requirements outlined in the
ANSI standards [29], [30].
Req-77: SIP telephony devices SHOULD comply with the
stability or minimum loss defined in ITU-T G.177
[31].
Req-78: SIP telephony devices MAY support a full-duplex
speakerphone function with echo and side tone
cancellation. The design of high quality side tone
cancellation for desktop IP phones, laptop computers
and PDAs is outside the scope of this memo.
Req-79: SIP telephony device MAY support different ring-tones
based on the caller identity.
2.16. International Requirements
Req-80: SIP telephony devices SHOULD indicate the preferred
language [34] using User Agent Capabilities [52].
Req-81: SIP telephony devices intended to be used in various
language settings [34], MUST support other languages
for menus, help, and labels.
Expires May, 2006 [Page 18]
draft-sinnreich-sipdev-req-08.txt October 2005
2.17. Support for Related Applications
The following requirements apply to functions placed in the
SIP telephony device.
Req-82: SIP telephony devices that have a large display and
support presence SHOULD display a buddy list [50].
Req-83: SIP telephony devices MAY support LDAP for client-
based directory lookup.
Req-84: SIP telephony devices MAY support a phone setup where
a URL is automatically dialed when the phone goes
off-hook.
2.18. Web Based Feature Management
Req-85: SIP telephony devices SHOULD support an internal web
server to allow users the option to manually
configure the phone and to set up personal phone
applications such as the address book, speed-dial,
ring tones, and last but not least the call handling
options for the various lines, aliases, in a user
friendly fashion. Web pages to manage the SIP
telephony device SHOULD be supported by the
individual device, or MAY be supported in managed
networks from centralized web servers linked from a
URI.
Managing SIP telephony devices SHOULD NOT require
special client software on the PC or require a
dedicated management console. SIP telephony devices
SHOULD support https transport for this purpose.
In addition to the Web Based Feature Management
Requirement the device MAY have an SNMP interface
for monitoring and management purposes.
2.19. Firewall and NAT Traversal
The following requirements allow SIP clients to properly
function behind various firewall architectures.
Expires May, 2006 [Page 19]
draft-sinnreich-sipdev-req-08.txt October 2005
Req-86: SIP telephony devices SHOULD be able to operate
behind a static NAPT (Network Address
Translation/Port Address Translation) device. This
implies the SIP telephony device SHOULD be able to 1)
populate SIP messages with the public, external
address of the NAPT device, 2) use symmetric UDP or
TCP for signaling, and 3) Use symmetric RTP [72].
Req-87: SIP telephony devices SHOULD support the STUN
protocol [32] for determining the NAPT public
external address. A classification of scenarios and
NATs where STUN is effective is reported in [58].
Detailed call flows for interactive connectivity
establishment (ICE) [76] are given in [63].
Note: Developers are strongly advised to follow the
document on best current practices for NAT traversal
for SIP [63].
Req-88: SIP telephony devices MAY support UPnP
(http://www.upnp.org/) for local NAPT traversal. Note
that UPnP does not help if there are NAPT in the
network of the services provider.
Req-89: SIP telephony devices MUST be able to limit the ports
used for RTP to a provisioned range.
2.20. Device Interfaces
Req-90: SIP telephony devices MUST support two types of
addressing capabilities, to enable end users to
"dial" either phone numbers or URIs.
Req-91: SIP telephony devices MUST have a telephony-like
dial-pad and MAY have telephony style buttons like
mute, redial, transfer, conference, hold, etc. The
traditional telephony dial-pad interface MAY appear
as an option in large screen telephony devices using
other interface models, such as Push-To-Talk in
mobile phones and the Presence and IM GUI found in
PCs, PDAs, in mobile phones and in cordless phones.
Expires May, 2006 [Page 20]
draft-sinnreich-sipdev-req-08.txt October 2005
Req-92: SIP telephony devices MUST have a convenient way for
entering SIP URIs and phone numbers. This includes
all alphanumeric characters allowed in legal SIP
URIs. Possible approaches include using a web page,
display and keyboard entry, type-ahead or graffiti
for PDAs.
Req-93: SIP telephony devices should allow phone number entry
in human friendly fashion, with the usual separators
and brackets between digits and digit groups.
3. Glossary and Usage for the Configuration Settings
SIP telephony devices are quite complex and their
configuration is made more difficult by the widely diverse
use of technical terms for the settings. We present here a
glossary of the most common settings and some of the more
widely used values for some settings.
Settings are the information on a SIP UA that it needs so as
to be a functional SIP endpoint. The settings defined in this
document are not intended to be a complete listing of all
possible settings. It MUST be possible to add vendor specific
settings.
The list of available settings includes settings that MUST,
SHOULD or MAY be used by all devices (when present) and that
make up the common denominator that is used and understood by
all devices. However, the list is open to vendor specific
extensions that support additional settings, which enable a
rich and valuable set of features.
Settings MAY be read-only on the device. This avoids the
misconfiguration of important settings by inexperienced users
generating service cost for operators. The settings
provisioning process SHOULD indicate which settings can be
changed by the end-user and which settings should be
protected.
In order to achieve wide adoption of any settings format it
is important that it should not be excessive in size for
modest devices to use it. Any format SHOULD be structured
enough to allow flexible extensions to it by vendors.
Settings may belong to the device or to a SIP service
provider and the address of record (AOR) registered there.
When the device acts in the context of an AOR, it will first
try to look up a setting in the AOR context. If the setting
can not be found in that context, the device will try to find
the setting in the device context. If that also fails, the
device MAY use a default value for the setting.
Expires May, 2006 [Page 21]
draft-sinnreich-sipdev-req-08.txt October 2005
The examples shown here are just of informational nature.
Other documents may specify the syntax and semantics for the
respective settings.
3.1. Device ID
A device setting MAY include some unique identifier
for the device it represents. This MAY be an
arbitrary device name chosen by the user, the MAC
address, some manufacturer serial number or some
other unique piece of data. The Device ID SHOULD also
indicate the ID type.
Example: DeviceId="000413100A10;type=MAC"
3.2. Signaling Port
The port that will be used for a specific transport
protocol for SIP MAY be indicated with the SIP ports
setting. If this setting is omitted, the device MAY
choose any port within a range as specified in 3.3.
For UDP, the port may also be used for sending
requests so that NAT devices will be able to route
the responses back to the UA.
Example: SIPPort="5060;transport=UDP"
3.3. RTP Port Range
A range of port numbers MUST be used by a device for
the consecutive pairs of ports which MUST be used to
receive audio and control information (RTP and RTCP)
for each concurrent connection. Sometimes this is
required to support firewall traversal and it helps
network operators to identify voice packets.
Example: RTPPorts="50000-51000"
3.4. Quality of Service
The QoS settings for outbound packets SHOULD be
configurable for network packets associated with call
signaling (SIP) and media transport (RTP/RTCP). These
settings help network operators identifying voice
packets in their network and allow them to transport
them with the required QoS. The settings are
independently configurable for the different
transport layers and signaling, media or
administration. The QoS settings SHOULD also include
the QoS mechanism.
For both categories of network traffic, the device
SHOULD permit configuration of the type of service
Expires May, 2006 [Page 22]
draft-sinnreich-sipdev-req-08.txt October 2005
settings for both layer 3 (IP DiffServ) and layer 2
(for example IEEE 802.1D/Q) of the network protocol
stack.
Example: RTPQoS="0xA0;type=DiffSrv,
5;type=802.1DQ;vlan=324"
3.5. Default Call Handling
All of the call handling settings defined below can
be defined here as default behaviors.
3.5.1. Outbound Proxy
The outbound proxy for a device MAY be set. The
setting MAY require that all signaling packets MUST
be sent to the outbound proxy or that only in the
case when no route has been received the outbound
proxy MUST be used. This ensures that application
layer gateways are in the signaling path. The second
requirement allows the optimization of the routing by
the outbound proxy.
Example: OutboundProxy="sip:nat.proxy.com"
3.5.2. Default Outbound Proxy
The default outbound proxy SHOULD be a global setting
(not related to a specific line).
Example: DefaultProxy="sip:123@proxy.com"
3.5.3. SIP Session Timer
The re-invite timer allows user agents to detect
broken sessions caused by network failures. A value
indicating the number of seconds for the next re-
invite SHOULD be used if provided.
Example: SessionTimer="600;unit=seconds"
3.6. Telephone Dialing Functions
As most telephone users are used to dialing digits to
indicate the address of the destination, there is a
need for specifying the rule by which digits are
transformed into a URI (usually SIP URI or TEL URI).
3.6.1. Phone Number Representations
SIP phones need to understand entries in the phone
book of the most common separators used between
Expires May, 2006 [Page 23]
draft-sinnreich-sipdev-req-08.txt October 2005
dialed digits, such as spaces, angle and round
brackets, dashes and dots.
Example: A phonebook entry of "+49(30)398.33-401"
should be translated into "+493039833401".
3.6.2. Digit Maps and/or the Dial/OK Key
A SIP UA needs to translate user input before it can
generate a valid request. Digit maps are settings
that describe the parameters of this process.
If present, digit maps define patterns that when
matched define:
1) A rule by which the end point can judge that the
user has completed dialing, and
2) A rule to construct a URI from the dialed digits,
and optionally
3) An outbound proxy to be used in routing the SIP
INVITE.
A critical timer MAY be provided which determines how
long the device SHOULD wait before dialing if a dial
plan contains a T (Timer) character. It MAY also
provide a timer for the maximum elapsed time which
SHOULD pass before dialing if the digits entered by
the user match no dial plan. If the UA has a Dial or
Ok key, pressing this key will override the timer
setting.
SIP telephony devices SHOULD have a Dial/OK key.
After sending a request, UA SHOULD be prepared to
receive a 484 Address Incomplete response. In this
case, the user agent should accept more user input
and try again to dial the number.
An example digit map could use regular expressions
like in DNS NAPTR (RFC2915) to translate user input
into a SIP URL. Additional replacement patterns like
"d" could insert the domain name of the used AOR.
Additional parameters could be inserted in the flags
portion of the substitution expression. A list of
those patterns would make up the dial plan:
|^([0-9]*)#$|sip:\1@\d;user=phone|outbound=proxy.com
|^([a-zA-Z0-9&=+\$,;?\-_.!~*'()%]+@.+)|sip:\1|
|^([a-zA-Z0-9&=+\$,;?\-_.!~*'()%]+)$|sip:\1@\d|
|^(.*)$|sip:\1@\d|timeout=5
Expires May, 2006 [Page 24]
draft-sinnreich-sipdev-req-08.txt October 2005
3.6.3. Default Digit Map
The SIP telephony device SHOULD support the
configuration of a default digit map. If the SIP
telephony device does not support digit maps, it
SHOULD at least support a default digit map rule to
construct a URI from digits. If the end point does
support digit maps, this rule applies if none of the
digit maps match.
For example, when a user enters "12345", the UA might
send the request to "sip:12345@proxy.com;user=phone"
after the user presses the OK key.
3.7. SIP Timer Settings
The parameters for SIP (like timer T1) and other
related settings MAY be indicated. An example of
usage would be the reduction of the DNS SRV failover
time.
Example: SIPTimer="t1=100;unit=ms"
Note: The timer settings can be included in the digit
map.
3.8. Audio Codecs
In some cases operators want to control which codecs
may be used in their network. The desired subset of
codecs supported by the device SHOULD be configurable
along with the order of preference. Service providers
SHOULD have the possibility of plugging in their own
codecs of choice. The codec settings MAY include the
packet length and other parameters like silence
suppression or comfort noise generation.
The set of available codecs will be used in the codec
negotiation according to RFC 3264 [12].
Example: Codecs="speex/8000;ptime=20;cng=on,
gsm;ptime=30"
The settings MUST include hints about privacy for
audio using SRTP that either mandate or encourage the
usage of secure RTP.
Example: SRTP="mandatory"
3.9. DTMF Method
Keyboard interaction can be indicated with in-band
tones or preferable with out-of-band RTP packets (RFC
2833) [11]. The method for sending these events
Expires May, 2006 [Page 25]
draft-sinnreich-sipdev-req-08.txt October 2005
SHOULD be configurable with the order of precedence.
Settings MAY include additional parameters like the
content-type that should be used.
Example: DTMFMethod="INFO;type=application/dtmf,
RFC2833", [11].
3.10. Local and Regional Parameters
Certain settings are dependent upon the regional
location for the daylight saving time rules and for
the time zone.
Time Zone and UTC Offset: A time zone MAY be
specified for the user. Where one is specified; it
SHOULD use the schema used by the Olson Time One
database [33].
Examples of the database naming scheme are Asia/Dubai
or America/Los Angeles where the first part of the
name is the continent or ocean and the second part is
normally the largest city on that time-zone. Optional
parameters like the UTC offset may provide additional
information for UA that are not able to map the time
zone information to a internal database.
Example: TimeZone="Asia/Dubai;offset=7200"
3.11. Time Server
A time server SHOULD be used. DHCP is the preferred
way to provide this setting. Optional parameters may
indicate the protocol that SHOULD be used for
determining the time. If present, the DHCP time
server setting has higher precedence than the time
server Setting.
Example: TimeServer="12.34.5.2;protocol=NTP"
3.12. Language
Setting the correct language is important for simple
installation around the globe.
A language Setting SHOULD be specified for the whole
device. Where it is specified it MUST use the codes
defined in RFC 3066 [34] to provide some
predictability.
Example: Language="de"
It is recommended to set the Language as writable, so
that the user MAY change this. This setting SHOULD
NOT be AOR related.
A SIP UA MUST be able to parse and accept requests
containing international characters encoded as UTF-8
Expires May, 2006 [Page 26]
draft-sinnreich-sipdev-req-08.txt October 2005
even if it cannot display those characters in the
user interface.
3.13. Inbound Authentication
SIP allows a device to limit incoming signaling to
those made by a predefined set of authorized users
from a list and/or with valid passwords. Note that
the inbound proxy from most service providers may
also support the screening of incoming calls, but in
some cases users may want to have control in the SIP
telephony device for the screening.
A device SHOULD support the setting as to whether
authentication (on the device) is required and what
type of authentication is required.
Example: InboundAuthentication="digest;pattern=*"
If inbound authentication is enabled then a list of
allowed users and credentials to call this device MAY
be used by the device. The credentials MAY contain
the same data as the credentials for an AOR (i.e.
URL, user, password digest and domain). This applies
to SIP control signaling as well as call initiation.
3.14. Voice Message Settings
Various voice message settings require the use of
URI's for the service context as specified in RFC
3087 [35].
The message waiting indicator (MWI) address setting
controls where the client SHOULD SUBSCRIBE to a voice
message server and what MWI summaries MAY be
displayed [43].
Example: MWISubscribe="sip:mailbox01@media.proxy.com"
User Agents SHOULD accept MWI information carried by
SIP MESSAGE without prior subscription. This way the
setup of voice message settings can be avoided.
3.15. Phonebook and Call History
UA SHOULD have a phonebook and keep a history of
recent calls. The phonebook SHOULD save the
information in permanent memory that keeps the
information even after restarting the device or save
the information in an external database that
permanently stores the information.
Expires May, 2006 [Page 27]
draft-sinnreich-sipdev-req-08.txt October 2005
3.16. User Related Settings and Mobility
A device MAY specify the user which is currently
registered on the device. This SHOULD be an address-
of-record URL specified in an AOR definition.
The purpose of specifying which user is currently
assigned to this device is to provide the device with
the identity of the user whose settings are defined
in the user section. This is primarily interesting
with regards to user roaming. Devices MAY allow users
to sign-on to them and then request that their
particular settings be retrieved. Likewise a user MAY
stop using a device and want to disable their AOR
while not present. For the device to understand what
to do it MUST have some way of identifying users and
knowing which user is currently using it. By
separating the user and device properties it becomes
clear what the user wishes to enable or to disable.
Providing an identifier in the configuration for the
user gives an explicit handle for the user. For this
to work the device MUST have some way of identifying
users and knowing which user is currently assigned to
it.
One possible scenario for roaming is an agent who has
definitions for several AOR (e.g. one or more
personal AOR and one for each executive for whom the
administrator takes calls) that they are registered
for. If the agent goes to the copy room they would
sign-on to a device in that room and their user
settings including their AOR would roam with them.
The alternative to this is to require the agent to
individually configure all of the AORs individually
(this would be particularly irksome using standard
telephone button entry).
The management of user profiles, aggregation of user
or device AOR and profile information from multiple
management sources are configuration server concerns
which are out of the scope of this document. However
the ability to uniquely identify the device and user
within the configuration data enables easier server
based as well as local (i.e. on the device)
configuration management of the configuration data.
3.17. AOR Related Settings
SIP telephony devices MUST use the Address of Record
(AOR) related settings, as specified here.
There are many properties which MAY be associated
with or SHOULD be applied to the AOR or signaling
Expires May, 2006 [Page 28]
draft-sinnreich-sipdev-req-08.txt October 2005
addressed to or from the AOR. AORs MAY be defined for
a device or a user of the device. At least one AOR
MUST be defined in the settings, this MAY pertain to
either the device itself or the user.
Example: AOR="sip:12345@proxy.com"
It MUST be possible to specify at least one set of
domain, user name and authentication credentials for
each AOR. The user name and authentication
credentials are used for authentication challenges.
3.18. Maximum Connections
A setting defining the maximum number of simultaneous
connections that a device can support MUST be used by
the device. The end point might have some maximum
limit, most likely determined by the media handling
capability. The number of simultaneous connections
may be also limited by the access bandwidth, such as
of DSL, cable and wireless users. Other optional
settings MAY include the enabling or disabling of
call waiting indication.
A SIP telephony device MAY support at least two
connections for three-way conference calls that are
locally hosted.
Example: MaximumConnections="2;cwi=false;bw=128". See
the recent work on connection reuse [74] and the
guidelines for connection oriented transport for SIP
[75].
3.19. Automatic Configuration and Upgrade
Automatic SIP telephony device configuration SHOULD
use the processes and requirements described in [60].
The user name or the realm in the domain name SHOULD
be used by the configuration server to automatically
configure the device for individual or group specific
settings, without any configuration by the user.
Image and service data upgrades SHOULD also not
require any settings by the user.
3.20. Security Configurations
The device configuration usually contains sensitive
information that MUST be protected. Examples include
authentication information, private address books and
call history entries. Because of this, it is
RECOMMENDED to use an encrypted transport mechanism
for configuration data. Where devices use HTTP this
could be TLS [36].
Expires May, 2006 [Page 29]
draft-sinnreich-sipdev-req-08.txt October 2005
For devices which use FTP or TFTP for content
delivery this can be achieved using symmetric key
encryption.
Access to retrieving configuration information is
also an important issue. A configuration server
SHOULD challenge a subscriber before sending
configuration information.
The configuration server SHOULD NOT include passwords
through the automatic configuration process. Users
SHOULD enter the passwords locally.
4. Security Considerations
4.1. Threats and Problem Statement
While section 2.11 states the minimal security requirements
and NAT/firewall traversal that have to be met respectively
by SIP telephony devices, developers and network managers
have to be aware of the larger context of security for IP
telephony, especially for those scenarios where security may
reside in other parts of SIP enabled networks.
Users of SIP telephony devices are exposed to many threats
[61] that include but are not limited to fake identity of
callers, telemarketing, spam in IM, hijacking of calls,
eavesdropping, learning of private information such as the
personal phone directory, user accounts and passwords and
the personal calling history. Various DOS attacks are
possible, such as hanging up on other people's conversations
or contributing to DOS attacks of others.
Service providers are also exposed to many types of attacks
that include but are not limited to theft of service by
users with fake identities, DOS attacks and the liabilities
due to theft of private customer data and eavesdropping in
which poorly secured SIP telephony devices or especially
intermediaries such as stateful back-to-back user agents
with media (B2BUA) may be implicated.
SIP security is a hard problem for several reasons:
. Peers can communicate across domains without any pre-
arranged trust relationship,
. There may be many intermediaries in the signaling path,
. Multiple endpoints can be involved in such telephony
operations as forwarding, forking, transfer or
conferencing,
. There are seemingly conflicting service requirements
when supporting anonymity, legal intercept, call trace
and privacy,
. Complications arise from the need to traverse NATs and
firewalls.
Expires May, 2006 [Page 30]
draft-sinnreich-sipdev-req-08.txt October 2005
There are a large number of deployment scenarios in
enterprise networks, using residential networks and
employees using VPN access to the corporate network when
working from home or on travel. There are different security
scenarios for each. The security expectations are also very
different, say within an enterprise network or when using a
laptop in a public wireless hotspot and it is beyond the
scope of this memo to describe all possible scenarios in
detail.
The authors believe that adequate security for SIP telephony
devices can be best implemented within protected networks,
be they private IP networks or service provider SIP enabled
networks where a large part of the security threats listed
here are dealt with in the protected network. A more general
security discussion that includes network based security
features, such as network based assertion of identity [37]
and privacy services [38] are outside the scope of this
memo, but must be well understood by developers, network
managers and service providers.
In the following some basic security considerations as
specified in RFC 3261 are discussed as they apply for SIP
telephony devices.
4.2. SIP Telephony Device Security
Transport Level Security
SIP telephony devices that operate outside the
perimeter of secure private IP networks (this
includes telecommuters and roaming users) MUST use
TLS [36] to the outgoing SIP proxy for protection on
the first hop. SIP telephony devices that use TLS
must support SIPS in the SIP headers.
Supporting large numbers of TLS channels to endpoints
is quite a burden for service providers and may
therefore constitute a premium service feature.
Digest Authentication
SIP telephony devices MUST support digest
authentication to register with the outgoing SIP
registrar. This assures proper identity credentials
that can be conveyed by the network to the called
party. It is assumed that the service provider
operating the outgoing SIP registrar has an adequate
trust relationship with their users and knows its
customers well enough (identity, address, billing
relationship, etc.). The exceptions are users of
prepaid service. SIP telephony devices that accept
Expires May, 2006 [Page 31]
draft-sinnreich-sipdev-req-08.txt October 2005
prepaid calls MUST place "unknown" in the "From"
header.
End User Certificates
SIP telephony devices MAY store personal end user
certificates that are part of some PKI [39] service
for high security identification to the outgoing SIP
registrar as well as for end to end authentication.
SIP telephony devices equipped for certificate based
authentication MUST also store a key ring of
certificates from public certificate authorities
(CA"s).
Note the recent work in the IETF on certificate
services that do not require the telephony devices to
store certificates [69].
End-to-End Security Using S/MIME
S/MIME [40] MUST be supported by SIP telephony
devices to sign and encrypt portions of the SIP
message that are not strictly required for routing by
intermediaries. S/MIME protects private information
in the SIP bodies and in some SIP headers from
intermediaries. The end user certificates required
for S/MIME assure the identity of the parties to each
other. Note: S/MIME need not be used though in every
call.
4.3. Privacy
Media Encryption
Secure RTP (SRTP) [41] MAY be used for the encryption
of media such as audio, text and video, after the
keying information has been passed by SIP signaling.
Instant messaging MAY be protected end-to-end using
S/MIME.
4.4. Support for NAT and Firewall Traversal
The various NAT and firewall traversal scenarios
require support in telephony SIP devices. The best
current practices for NAT traversal for SIP are
reviewed in [63]. Most scenarios where there are no
SIP enabled network edge NAT/firewalls or gateways in
the enterprise can be managed if there is a STUN [32]
client in the SIP telephony device and a STUN server
on the Internet, maintained by a service provider. In
some exceptional cases (legacy symmetric NAT) an
external media relay must also be provided that can
support the TURN protocol exchange [62] with SIP
Expires May, 2006 [Page 32]
draft-sinnreich-sipdev-req-08.txt October 2005
telephony devices. Media relays such as TURN come at
a high bandwidth cost to the service provider, since
the bandwidth for many active SIP telephony devices
must be supported. Media relays may also introduce
longer paths with additional delays for voice.
Due to these disadvantages of media relays, it is
preferable to avoid symmetric and non-deterministic
NAT"s in the network, so that only STUN can be used,
where required. Reference [73] deals in more detail
how NAT has to 'behave'.
It is not always obvious to determine the specific
NAT and firewall scenario under which a SIP telephony
device may operate.
For this reason, the support for Interactive
Connectivity Establishment (ICE) [76] has been
defined to be deployed in all devices that required
end-to-end connectivity for SIP signaling and RTP
media streams, as well as for streaming media using
RTSP. ICE makes use of existing protocols, such as
STUN and TURN.
Call flows using SIP security mechanisms
The high level security aspects described here are
best illustrated by inspecting the detailed call
flows using SIP security, such as in [64].
Security enhancements, certificates and identity management
As of this writing, recent work in the IETF deals
with the SIP authenticated body (AIB) format [66],
new S/MIME requirements [67] enhancements for the
authenticated identity [68], and Certificate
Management Services for SIP [69]. We recommend
developers and network managers to follow this work
as it will develop into IETF standards.
5. IANA Considerations
This document has no actions for IANA.
6. Acknowledgments
Paul Kyzivat and Francois Audet have made useful comments
how to support to the dial plan requirements in Req-17.
Mary Barnes has kindly made a very detailed review on
version 04 that has contributed to significantly improving
the document. Useful comments on version 05 have also been
made by Ted Hardie, David Kessens, Russ Housley and Harald
Alvestrand that are reflected in this version of the
document.
Expires May, 2006 [Page 33]
draft-sinnreich-sipdev-req-08.txt October 2005
We would like to thank Jon Peterson for very detailed
comments on the previous version 0.3 that has prompted the
rewriting of much of this document. John Elwell has
contributed with many detailed comments to version of the 04
of the draft. Rohan Mahy has contributed several
clarifications to the document and leadership in the
discussions on support for the hearing disabled. These
discussions have been concluded during the BOF on SIP
Devices held during the 57th IETF and the conclusions are
reflected in the section on interactive text support for
hearing or speech disabled users.
Gunnar Hellstrom, Arnoud van Wijk and Guido Gybels have been
instrumental in driving the specification for support of the
hearing disabled.
The authors would also like to thank numerous persons for
contributions and comments to this work: Henning
Schulzrinne, Jorgen Bjorkner, Jay Batson, Eric Tremblay,
David Oran and Denise Caballero McCann, Brian Rosen, Jean
Brierre, Kai Miao, Adrian Lewis and Franz Edler. Jonathan
Knight has contributed significantly to earlier versions of
the requirements for SIP phones. Peter Baker has also
provided valuable pointers to TIA/EIA IS 811 requirements to
IP phones that are referenced here.
Last but not least, the co-authors of the previous versions,
Daniel Petrie and Ian Butcher have provided support and
guidance all along in the development of these requirements.
Their contributions are now the focus of separate documents.
7. Changes from Previous Versions
Changes from draft-sinnreich-sipdev-req-07
. Updated the references from the IETF and explained in
the intro that due to the informational nature of this
memo, no distinction is made here between normative and
informative references.
. Specified that ideally, the more codecs can be
supported the better and given the reasons. Also
specified for implementers interested in a short list,
what an ordered short list of codecs may look like.
. Deleted any specifics on codecs for various mobile
networks.
. Specified that G.729 codecs may be supported for
backward compatibility but that iLBC and G.723.1 codecs
will perform better in low bandwidth environments.
Expires May, 2006 [Page 34]
draft-sinnreich-sipdev-req-08.txt October 2005
. Clarified Req-85 that instead of an internal web server
in the device, a URI may link to the web page for
manual configuration.
. Changed in Section 3.2 the "MUST be indicated" for
ports for the transport protocol to MAY.
. Changed Req-90 for clarity on the support for "dialing"
both phone numbers and URIs.
Changes from draft-sinnreich-sipdev-req-06
We have updated a number of requirements based on
discussions on the SIPPING WG list (sipping.ietf.org) and
helpful comments by Paul Kyzivat and Francois Audet.
.
Edited and added example for a dial plan in Req-17,
.
Edited Req-18, Req-19, Req-26, Req-27 and Req-64 so as
to match recently issued RFCs that are quoted in the
Reference.
Changes from draft-sinnreich-sipdev-req-05
Updated the references and made edits as suggested by Mary
Barnes and from comments by Russ Housley, David Kessen and
Ted Hardie.
Changes from draft-sinnreich-sipdev-req-05
. Added edits on text over IP has suggested by Gunnar
Hellstrom and Jon Peterson.
Changes from draft-sinnreich-sipdev-req-04
. Removed the section on IANA Considerations that was
meant to register the event package for automatic
configuration, since this topic is now dealt elsewhere
in [60].
. Removed the reference to RFC 791, since that is implied
by referencing the DiffServ code points in RFC 2597
[22].
. Reviewed and tightened the language based on comments
by John Elwell.
Changes from draft-sinnreich-sipdev-req-03
Expires May, 2006 [Page 35]
draft-sinnreich-sipdev-req-08.txt October 2005
. Version 03 of the memo is focused more narrowly on SIP
telephony device requirements and configuration only.
. Automatic configuration over the network has been
ommitted since it is addressed separately in [60].
. The section with the example with XML based
configuration data has been omitted, since such data
formats are different topic altogether.
. The section on security considerations has been re-
written from scratch so as to keep up with recent work on
SIP security, and such items as user identity,
certificates, S/MIME and the SIP Authenticated Body (AIB)
format.
Changes to -02 since draft-sinnreich-sipdev-req-01
. Re-edited the section on Interactive text support for
hearing or speech disabled users.
. Shortened the sections on phonebook, call history and
line related settings.
. Deleted the section on ringer behavior.
. Updated and added references.
8. References
Note: The references provided here should be considered
informative, since this is an informational memo. Also, as
of this writing, some references are work in progress at the
IETF. As a result the version number on some key draft may
be obsolete at the time of reading this memo and other
Internet Drafts are advanced to RFC status.
[1] Scott Bradner: "The Internet Standards Process, Revision
3", RFC 2026. IETF, October 1996.
[2] Scott Bradner: "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, IETF, 1997.
[3] J. Rosenberg et. al: "SIP: Session Initiation Protocol",
RFC 3261. IETF, June 2002.
[4] T. Lemon et al: "Encoding Long Options in the DHCP", RFC
3396. IETF, November 2002.
Expires May, 2006 [Page 36]
draft-sinnreich-sipdev-req-08.txt October 2005
[5] D. Mills: "Simple Network Time Protocol (SNTP) Version 4
for IPv4 and IPv6 and OSI" RFC 2030. IETF, October 1996.
[6] J. Rosenberg and H. Schulzrinne: "Session Initiation
Protocol (SIP): Locating SIP Servers", RFC 3263. IETF, June
2002.
[7] J.Peterson "ENUM Service Registration for Session
Initiation Protocol (SIP) Address of Record", RFC 3764.
IETF, April 2004.
[8] R J. Peterson: "A Privacy Mechanism for the Session
Initiation Protocol", RFC 3323. IETF, November 2002.
[9] H. Schulzrinne: "The tel URI for Telephone Numbers", RFC
3966. IETF, December 2004.
[10] R. Sparks: "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515. IETF, April 2003.
[11] H. Schulzrinne and S. Petrack: RTP Payload for DTM
Digits, Telephony Tones and Telephony Signals", RFC 2833.
IETF, May 2000.
[12] J. Rosenberg and H. Schulzrinne: "An Offer/Answer Model
with the Session Description Protocol (SDP", RFC 3264. IETF,
June 2002.
[13] S. Casner and P. Hoschka: S. "MIME Type Registration of
RTP Payload Formats", RFC 3555. IETF, July 2003. Updated by
RFC 3625.
[15] A. Johnston et al: "Session Initiation Protocol (SIP)
Basic Call Flow Examples", RFC 3665. IETF, December 2003.
[14] G. Camarillo et al: "Grouping of Media Lines in the
Session Description Protocol (SDP)" RFC 3388. IETF, December
2002.
[16] A. Johnston: "Session Initiation Protocol (SIP) Public
Switched Telephone Network (PSTN) Call Flows", RFC 3666.
IETF, December 2003.
[17] J. Rosenberg et al: "Best Current Practices for Third
Party Call Control (3pcc) in the Session Initiation Protocol
(SIP)", RFC 3725. IETF, April 2004.
Expires May, 2006 [Page 37]
draft-sinnreich-sipdev-req-08.txt October 2005
[18] N. Charlton et al: "User Requirements for the Session
Initiation Protocol (SIP) in Support of Deaf, Hard of
Hearing and Speech-impaired Individuals". RFC 3351. IETF,
August 2002.
[19] M. Handley and V. Jacobson: "SDP: Session Description
Protocol", RFC 2327. IETF, April 1998.
[20] H. Schulzrinne et al: "RTP: A Transport Protocol for
Real-Time Applications", RFC 3550. IETF, July 2003.
[21] T. Friedman et al: "RTP Control Protocol Extended
Reports (RTCP XR)", RFC 3611. IETF, November 2003.
[22] J. Heinanen et al: "Assured Forwarding PHB Group", RFC
2597. IETF, June 1999.
[23] R. Braden et al: "Resource ReSerVation Protocol (RSVP)-
Version 1 Functional Specification", RFC 2205. IETF,
September 1997.
[24] H. Schulzrinne and S. Casner: "RTP Profile for Audio
and Video Conferences with Minimal Control", RFC 3551. IETF,
July 2003.
[25] ITU-T Recommendation G.711 available online from the
ITU bookstore at http://www.itu.int.
[26] S.V. Anderson et al: "Internet Low Bit Rate Codec", RFC
3951. IETF, December 2004.
[27] R A. Duric: "RTP Payload Format for iLBC Speech", RFC
3952. IETF, December 2004.
[28] G. Herlein et al.: "RTP Payload Format for the Speex
Codec", draft-herlein-speex-rtp-profile-02, IETF, April
2005.
[29] TIA/EIA-810-A, "Transmission Requirements for
Narrowband Voice over IP and Voice over PCM Digital Wireline
Telephones", July 2000.
[30] TIA-EIA-IS-811, "Terminal Equipment - Performance and
Interoperability Requirements for Voice-over-IP (VoIP)
Feature Telephones", July 2000.
[31] ITU-T Recommendation G.177 available online from the
ITU bookstore at http://www.itu.int
Expires May, 2006 [Page 38]
draft-sinnreich-sipdev-req-08.txt October 2005
[32] J. Rosenberg et al: "STUN - Simple Traversal of User
Datagram Protocol (UDP) Through Network Address Translators
(NATs)" RFC 3489. IETF, March 2003.
[33] P. Eggert, "Sources for time zone and daylight saving
time data." Available at http://www.twinsun.com/tz/tz-
link.htm
[34] H. Alvestrand: "Tags for the Identification of
Languages" RFC 3066. IETF, January 2001.
[35] B. Campbell and R. Sparks: "Control of Service Context
using SIP Request-URI" RFC 3087. IETF, April 2001.
[36] T. Dierks: "The TLS protocol Version 1.0" RFC 2246.
IETF, January 1999. Updated by RFC 3546.
[37] C. Jennings et al: "Private Extensions to the Session
Initiation Protocol (SIP) for Asserted Identity within
Trusted Networks", RFC 3325. IETF, November 2002.
[38] J. Peterson: "A Privacy Mechanism for the Session
Initiation Protocol (SIP)", RFC 3323. IETF, Nov. 2002.
[39] S. Chokhani et al: "Internet X.509 Public Key
Infrastructure, Certificate Policy and Certification
Practices Framework" RFC 3647. IETF, Nov. 2003.
[40] B. Ramsdell: "S/MIME Version 3.1 Message Specification"
RFC 3851. IETF, July 2004.
[41] M. Baugher et al: "The Secure Real-time Transport
Protocol (SRTP)", RFC 3711. IETF March 2004.
[42] Mahy, R. et al: "A Call Control and Multi-party usage
framework for the Session Initiation Protocol (SIP)",
draft-ietf-sipping-cc-framework-02. March 2003.
http://www.softarmor.com/wgdb/docs/draft-ietf-sipping-cc-
framework-02.html
[43] R. Mahy: "A Message Summary and Message Waiting
Indication Event Package for the Session Initiation Protocol
(SIP)", RFC 3842. IETF, August 2004.
[44] J. Peterson: "Telephone Number Mapping (ENUM) Service
Registration for Presence Services". RFC 3953. IETF, January
2005.
Expires May, 2006 [Page 39]
draft-sinnreich-sipdev-req-08.txt October 2005
[45] O. Levin and A. Johnston: "Conveying Feature Tags with
Session Initiation Protocol REFER Method", draft-ietf-sip-
refer-feature-param-00,IETF July 2005.
[46] A. Johnston: "SIP Service Examples", draft-ietf-
sipping-service-examples-09, IETF July 2005. Work in
progress.
[47] A. Johnston et al: "Session Initiation Protocol (SIP)
Basic Call Flow Examples" RFC 3665. IETF, December 2003.
[48] A. Johnston and O. Levin: "Session Initiation Protocol
Call Control - Conferencing for User Agents", draft-ietf-
sipping-cc-conferencing-06.txt, IETF, November 2004, work in
progress.
[49] R. Even and N. Ismail: "Conferencing Scenarios" draft-
ietf-xcon-conference-scenarios-05.txt, IETF, September 2005.
[50] J. Rosenberg et al: "Session Initiation Protocol (SIP)
Extension for Instant Messaging", RFC 3428. IETF, December
2002.
[51] H. Schulzrinne et al.: "RPID: Rich Presence Extensions
to the Presence Information Data Format (PIDF)", draft-ietf-
simple-rpid-09, IETF, September 2005.
[52] J. Rosenberg et al: "Indicating User Agent Capabilities
in the Session Initiation Protocol (SIP)" RFC 3840. IETF,
August 2004.
[53] H. Schulzrinne and B. Rosen: "Emergency Services for
Internet Telephony Systems", draft-schulzrinne-sipping-
emergency-arch-02, IETF, October 2004. IETF, work in
progress.
[54] See the Working Group on Emergency Context Resolution
with Internet Technologies at
http://www.ietf.org/html.charters/ecrit-charter.html
[55] H. Schulzrinne and J. Polk: "Communications Resource
Priority for the Session Initiation Protocol", IETF, draft-
ietf-sip-resource-priority-10, July 2005, work in progress.
[56] G. Hellstrom and P. Jones: "RTP Payload for Text
Conversation", RFC 4103, IETF, June 2005.
Expires May, 2006 [Page 40]
draft-sinnreich-sipdev-req-08.txt October 2005
[57] A. Johnston: "A Performance Report Event Package For
SIP", draft-johnston-sipping-rtcp-summary-07, IETF, July
2005. Work in progress.
[58] C. Jennings: " NAT Classification Test Results", draft-
jennings-behave-test-results-01, IETF, July 2005. Work in
progress.
[59] J. Rosenberg: "A Presence Event Package for the Session
Initiation Protocol (SIP)", RFC 3856. IETF, October 2004.
[60] D. Petrie: "A Framework for SIP User Agent Profile
Delivery", draft-ietf-sipping-config-framework-07.txt, IETF,
July 2005, work in progress.
[61] C. Jennings: "SIP Tutorial: SIP Security" presented at
the VON Spring 2004 conference, March 29, 2004, Santa Clara,
CA.
[62] J. Rosenberg et al.: "Traversal Using Relay NAT
(TURN)", draft-rosenberg-midcom-turn-08.txt, IETF, September
2005, work in progress.
[63] C. Boulton and J. Rosenberg: "Best Current Practices
for NAT Traversal for SIP", IETF, October 2004, work in
progress.
[64] C. Jennings: "Example call flows using SIP security
mechanisms", draft-jennings-sip-sec-flows-03, IETF, July
2005.
[65] J. Rosenberg et al: "Caller Preferences for the Session
Initiation Protocol (SIP)", RFC 3841. IETF, August 2004.
[66] J. Peterson: "Session Initiation Protocol (SIP)
Authenticated Identity Body (AIB) Format", RFC 3893. IETF,
September 2004.
[67] J. Peterson: "S/MIME Advanced Encryption Standard (AES)
Requirement for the Session Initiation Protocol (SIP), RFC
3853. IETF, July 2004.
[68] J. Peterson and C. Jennings: "Enhancements for
Authenticated Identity Management in the Session Initiation
Protocol (SIP)", draft-ietf-sip-identity-03, September 2004.
[69] J. Peterson and C. Jennings: "Certificate Management
Services for SIP", IETF, October 2004.
Expires May, 2006 [Page 41]
draft-sinnreich-sipdev-req-08.txt October 2005
[70] A. van Wijk: "Framework of requirements for real-time
text conversation using SIP", draft-ietf-sipping-toip-
03.txt, IETF, September 2005, work in progress.
[71] G. Camarillo and H. Schulzrinne: "Early Media and
Ringing Tone Generation in the Session Initiation Protocol
(SIP)", RFC 3960. IETF, December 2004.
[72] "D. Wing: "Symmetric RTP and RTCP Considered Helpful".
IETF, October 2004, work in progress.
[73] F. Audet and C. Jennings: "NAT Behavioral Requirements
for Unicast UDP", draft-ietf-behave-nat-udp-02, IETF, June
2005, work in progress.
[74] R. Mahy: "Connection Reuse in the Session Initiation
Protocol (SIP)", draft-ietf-sip-connect-reuse-04.txt, IETF,
July 2005, work in progress.
[75] C. Jennings and R. Mahy: "Managing Client Initiated
Connections in the Session Initiation Protocol", draft-ietf-
sip-outbound-00, IETF, July 2005, work in progress.
[76] J. Rosenberg: "Interactive Connectivity Establishment
(ICE): A Methodology for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", draft-ietf-mmusic-
ice-05, Internet Draft, IETF, July 2005, work in progress.
[77] J. Polk and B. Rosen: "Session Initiation Protocol
Location Conveyance", draft-ietf-sip-location-conveyance-
01.txt, Internet Draft. October 2004, work in progress.
9. Author's Addresses
Henry Sinnreich
Pulver.com
115 Broadhollow Road
Melville, NY 11747, USA
Email: henry@pulver.com
Phone: +1-631-961-8950
Steven Lass
MCI
1201 East Arapaho Road
Richardson, TX 75081, USA
Email: steven.lass@mci.com
Phone: +1-972-728-2363
Expires May, 2006 [Page 42]
draft-sinnreich-sipdev-req-08.txt October 2005
Christian Stredicke
snom technology AG
Gradestrasse, 46
D-12347 Berlin, Germany
Email: cs@snom.de
Phone: +49(30)39833-0
10. Copyright Notice
Copyright (C) The Internet Society (2005). This document is
subject to the rights, licenses and restrictions contained
in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are
provided on an "AS IS" basis and THE CONTRIBUTOR, THE
ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY),
THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE
DISCLAIM 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.
The IETF takes no position regarding the validity or scope
of any Intellectual Property Rights or other rights that
might be claimed to pertain to the implementation or use of
the technology described in this document or the extent to
which any license under such rights might or might not be
available; nor does it represent that it has made any
independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents
can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat
and any assurances of licenses to be made available, or the
result of an attempt made to obtain a general license or
permission for the use of such proprietary rights by
implementers or users of this specification can be obtained
from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its
attention any copyrights, patents or patent applications, or
other proprietary rights that may cover technology that may
be required to implement this standard. Please address the
information to the IETF at ietf-ipr@ietf.org.
Expires May, 2006 [Page 43]
draft-sinnreich-sipdev-req-08.txt October 2005
Expires May, 2006 [Page 44]