One document matched: draft-sinnreich-sipdev-req-06.txt
Differences from draft-sinnreich-sipdev-req-05.txt
SIPPING WG H. Sinnreich/pulver.com, editor
Internet Draft S. Lass/MCI
C. Stredicke/snom
May 2005
SIP Telephony Device Requirements and Configuration
draft-sinnreich-sipdev-req-06.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 November 13, 2005.
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 November 2005 [Page 1]
draft-sinnreich-sipdev-req-06.txt November 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..................................4
2.3. SIP Device Resident Telephony Features................5
2.4. Support for SIP Services..............................8
2.5. Basic Telephony and Presence Information Support......8
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.............................13
2.11. SIP Device Security Requirements....................13
2.12. Quality of Service..................................14
2.13. Media Requirements..................................14
2.14. Voice Codecs........................................14
2.15. Telephony Sound Requirements........................15
2.16. International Requirements..........................16
2.17. Support for Related Applications....................16
2.18. Web Based Feature Management........................16
2.19. Firewall and NAT Traversal..........................17
2.20. Device Interfaces...................................18
3. Glossary and Usage for the Configuration Settings.........18
3.1. Device ID............................................19
3.2. Signaling Port.......................................19
3.3. RTP Port Range.......................................19
3.4. Quality of Service...................................20
3.5. Default Call Handling................................20
3.5.1. Outbound Proxy..................................20
3.5.2. Default Outbound Proxy..........................20
3.5.3. SIP Session Timer...............................20
3.6. Telephone Dialing Functions..........................21
3.6.1. Phone Number Representations....................21
3.6.2. Digit Maps and/or the Dial/OK Key...............21
3.6.3. Default Digit Map...............................22
3.7. SIP Timer Settings...................................22
3.8. Audio Codecs.........................................22
3.9. DTMF Method..........................................23
3.10. Local and Regional Parameters.......................23
3.11. Time Server.........................................23
Expires November 13, 2005 [Page 2]
draft-sinnreich-sipdev-req-06.txt November 2005
3.12. Language............................................23
3.13. Inbound Authentication..............................24
3.14. Voice Message Settings..............................24
3.15. Phonebook and Call History..........................24
3.16. User Related Settings and Mobility..................25
3.17. AOR Related Settings................................25
3.18. Maximum Connections.................................26
3.19. Automatic Configuration and Upgrade.................26
3.20. Security Configurations.............................26
4. Security Considerations...................................27
4.1. Threats and Problem Statement........................27
4.2. SIP Telephony Device Security........................28
4.3. Privacy..............................................29
4.4. Support for NAT and Firewall Traversal...............29
5. IANA Considerations.......................................30
6. Acknowledgments...........................................30
7. Changes from Previous Versions............................31
8. References................................................32
9. Author's Addresses........................................38
10. Copyright Notice.........................................38
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 November 13, 2005 [Page 3]
draft-sinnreich-sipdev-req-06.txt November 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 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.
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.
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.
Expires November 13, 2005 [Page 4]
draft-sinnreich-sipdev-req-06.txt November 2005
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 [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.
Expires November 13, 2005 [Page 5]
draft-sinnreich-sipdev-req-06.txt November 2005
Req-16: SIP telephony devices MUST support SIP message waiting
[43] 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 consist of a pattern
string to match dial digits, and the ability to strip
and also append prefix digits, and also append suffix
digits.
Req-18: SIP telephony devices MUST support the URIs for
Telephone numbers as per RFC 3966 [9].
Req-19: SIP telephony devices MUST support REFER and NOTIFY as
required to support call transfer [45], [46]. SIP
telephony devices MUST support 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 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 November 13, 2005 [Page 6]
draft-sinnreich-sipdev-req-06.txt November 2005
Req-26: SIP telephony devices MUST generate local ringing and
SHOULD ignore any early RTP media when a "180 Ringing"
response is received. Any received media that is not
early media (i.e., not received within the context of an
early session, as specified in [71] should be rendered
as soon as it arrives in order to avoid speech clipping.
SIP telephony devices MUST play the RTP stream for the
established dialog and ignore any other RTP media
streams when a "183 Session Progress" response is
received.
Req-27: SIP telephony devices SHOULD obey the last 18x message
received when multiple 18x responses are received. If
the last response is "180 Ringing", the client MUST
generate local ringing. If the last response is "183
Session Progress", the client MUST play the RTP stream.
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 listening 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.
Expires November 13, 2005 [Page 7]
draft-sinnreich-sipdev-req-06.txt November 2005
2.4. Support for SIP Services
Req-32: SIP telephony devices MUST support the SIP Basic Call
Flow Examples [47].
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 for example 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
Expires November 13, 2005 [Page 8]
draft-sinnreich-sipdev-req-06.txt November 2005
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 [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
Expires November 13, 2005 [Page 9]
draft-sinnreich-sipdev-req-06.txt November 2005
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 [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.
Req-48: Multi-line SIP telephony devices MUST be able to
support a few different ring tones for different lines.
Expires November 13, 2005 [Page 10]
draft-sinnreich-sipdev-req-06.txt November 2005
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 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 for noisy environments and 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 confused
person, and the additional information that can be observed
from watching the message as it is composed.
Expires November 13, 2005 [Page 11]
draft-sinnreich-sipdev-req-06.txt November 2005
Req-52: SIP telephony devices such as SIP display phones and
IP-analog adapters SHOULD support the accessibility for
user 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 FXO port to support FXS
devices. If an RJ-11 (FXO) 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 MUST pass-through all
text-telephone protocols according to ITU-T
Recommendation V.18, November 2000, in a transparent
fashion.
Expires November 13, 2005 [Page 12]
draft-sinnreich-sipdev-req-06.txt November 2005
Req-58: SIP telephony devices MAY provide a 2.5 mm audio port,
in portable SIP devices, such as PDA"s 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.
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
accept/reject MUST be configurable.
Expires November 13, 2005 [Page 13]
draft-sinnreich-sipdev-req-06.txt November 2005
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.
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 [24] lists 17 registered MIME subtypes for audio
codecs. This memo however requires the support of a minimal
number of codecs used in wireline VoIP, and also codecs found
in mobile phones.
Expires November 13, 2005 [Page 14]
draft-sinnreich-sipdev-req-06.txt November 2005
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 3G wireless mobile phones. 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 is needed (for dial-up Internet access) or
G.722 for high quality audio conferences.
Req-75: SIP telephony devices MAY support G.729 and its
annexes.
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
burden of the additional 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].
Expires November 13, 2005 [Page 15]
draft-sinnreich-sipdev-req-06.txt November 2005
Req-78: SIP telephony devices MAY provide a full-duplex
speakerphone 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.
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
Expires November 13, 2005 [Page 16]
draft-sinnreich-sipdev-req-06.txt November 2005
supported by the individual device, or MAY be supported
in managed networks from centralized web servers.
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.
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) are given
in [76].
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.
Expires November 13, 2005 [Page 17]
draft-sinnreich-sipdev-req-06.txt November 2005
2.20. Device Interfaces
Req-90: SIP telephony devices MUST have two types of interface
capabilities, for both phone numbers and URIs, both
accessible to the end user.
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 PC"s, PDA"s and
mobile phones and wireless phones.
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.
Expires November 13, 2005 [Page 18]
draft-sinnreich-sipdev-req-06.txt November 2005
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.
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 MUST be used for a specific transport
protocol for SIP MUST be indicated with the SIP ports
setting. If this setting is omitted, the device MAY
choose any port. For UDP, the port must 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"
Expires November 13, 2005 [Page 19]
draft-sinnreich-sipdev-req-06.txt November 2005
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
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"
Expires November 13, 2005 [Page 20]
draft-sinnreich-sipdev-req-06.txt November 2005
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 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
Expires November 13, 2005 [Page 21]
draft-sinnreich-sipdev-req-06.txt November 2005
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
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"
Expires November 13, 2005 [Page 22]
draft-sinnreich-sipdev-req-06.txt November 2005
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 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.
Expires November 13, 2005 [Page 23]
draft-sinnreich-sipdev-req-06.txt November 2005
A SIP UA MUST be able to parse and accept requests
containing international characters encoded as UTF-8
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
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 November 13, 2005 [Page 24]
draft-sinnreich-sipdev-req-06.txt November 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 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
Expires November 13, 2005 [Page 25]
draft-sinnreich-sipdev-req-06.txt November 2005
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 settings 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].
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
Expires November 13, 2005 [Page 26]
draft-sinnreich-sipdev-req-06.txt November 2005
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.
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
Expires November 13, 2005 [Page 27]
draft-sinnreich-sipdev-req-06.txt November 2005
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 that operates 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 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
Expires November 13, 2005 [Page 28]
draft-sinnreich-sipdev-req-06.txt November 2005
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 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'.
Expires November 13, 2005 [Page 29]
draft-sinnreich-sipdev-req-06.txt November 2005
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
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.
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.
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,
Expires November 13, 2005 [Page 30]
draft-sinnreich-sipdev-req-06.txt November 2005
Jorgen Bjorkner, Jay Batson, Eric Tremblay, Gunnar Hellstrom,
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 raft-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
. 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.
Expires November 13, 2005 [Page 31]
draft-sinnreich-sipdev-req-06.txt November 2005
. 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] R. Droms:: "Dynamic Host Configuration Protocol", RFC 2131.
IETF, March 1997.
[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.
Expires November 13, 2005 [Page 32]
draft-sinnreich-sipdev-req-06.txt November 2005
[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.
[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.
[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 2611. IETF, November 2003.
Expires November 13, 2005 [Page 33]
draft-sinnreich-sipdev-req-06.txt November 2005
[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-avt-rtp-speex-00.txt, IETF, March 2003.
[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
[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.
Expires November 13, 2005 [Page 34]
draft-sinnreich-sipdev-req-06.txt November 2005
[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 Message Specification" RFC
2633. IETF, June 1999.
[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.
[45] S. Olson and O. Levin: "REFER extensions",draft-olson-
sipping-refer-extensions-02,IETF July 2004.
[46] A. Johnston: "SIP Service Examples", draft-ietf-sipping-
service-examples-07, IETF July 2004. 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-02.txt, IETF, June 2004.
Expires November 13, 2005 [Page 35]
draft-sinnreich-sipdev-req-06.txt November 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-04, IETF, October 2004.
[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. 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-05, October 2004.
[56] G. Hellstrom and P. Jones: "RTP Payload for Text
Conversation", draft-ietf-avt-rfc2793bis-09.txt, IETF, August
2004, work in progress.
[57] A. Johnston: "A Performance Report Event Package For SIP",
draft-johnston-sipping-rtcp-summary-04, IETF, October 2004.
Work in progress.
[58] C. Jennings: "NAT Classification Results using STUN",
draft-jennings-midcom-stun-results-02, IETF, October 2004. 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-05.txt, IETF,
October 2004.
[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-06.txt, IETF, October. 2004, work
in progress.
Expires November 13, 2005 [Page 36]
draft-sinnreich-sipdev-req-06.txt November 2005
[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-01, IETF, February
2004.
[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 AES Requirements for SIP" draft-ietf-
sip-smime-aes, IETF, June 2003.
[68] J. Peterson and C. Jennings: "Enhancements for
Authenticated Identity Management in the Session Initiation
Protocol (SIP)", draft-ietf-sip-identity, May 2004.
[69] J. Peterson and C. Jennings: "Certificate Management
Services for SIP", draft-sipping-certs, October 2004.
[70] G. Hellstrom and P. Jones: "RTP Payload for Text
Conversation", RFC 2793bis. Internet Draft. Work in progress.
draft-ietf-avt-rfc2793bis-09.txt, IETF, August 2004.
[71] G. Camarillo: "The Early Session Disposition Type for the
Session Initiation Protocol (SIP)", RFC 3959. 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". IETF, January 2005, work in progress.
[74] R. Mahy: "Connection Reuse in the Session Initiation
Protocol (SIP)". IETF, October 2004. Work in progress.
[75] C. Boulton et al: "Guidelines for implementers using
connection-oriented transports in the Session Initiation
Protocol (SIP)". IETF, February 2005. Work in progress.
[76] J. Rosenberg: "Interactive Connectivity Establishment
(ICE): A Methodology for Network Address Translator (NAT)
Expires November 13, 2005 [Page 37]
draft-sinnreich-sipdev-req-06.txt November 2005
Traversal for Multimedia Session Establishment Protocols".
Internet Draft, IETF, October 2004. Work in progress.
[77] J. Polk: "Requirements for Session Initiation Protocol
Location Conveyance". 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
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
Expires November 13, 2005 [Page 38]
draft-sinnreich-sipdev-req-06.txt November 2005
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 November 13, 2005 [Page 39]
| PAFTECH AB 2003-2026 | 2026-04-21 11:54:03 |