GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4504

Network Working Group H. Sinnreich, Ed. Request for Comments: 4504 pulver.com Category: Informational S. Lass

                                                               Verizon
                                                          C. Stredicke
                                                                  snom
                                                              May 2006
        SIP Telephony Device Requirements and Configuration

Status of This Memo

 This memo provides information for the Internet community.  It does
 not specify an Internet standard of any kind.  Distribution of this
 memo is unlimited.

Copyright Notice

 Copyright (C) The Internet Society (2006).

Abstract

 This document describes the requirements for SIP telephony devices,
 based on the deployment experience of large numbers of SIP phones and
 PC clients using different implementations in various networks.  The
 objectives of the requirements are a well-defined set of
 interoperability and multi-vendor-supported core features, so as to
 enable similar ease of purchase, installation, and operation as found
 for PCs, PDAs, analog feature phones or mobile phones.
 We present a glossary of the most common settings and some of the
 more widely used values for some settings.

Table of Contents

 1. Introduction ....................................................3
    1.1. Conventions used in this document ..........................4
 2. Generic Requirements ............................................4
    2.1. SIP Telephony Devices ......................................4
    2.2. DNS and ENUM Support .......................................5
    2.3. SIP Device Resident Telephony Features .....................5
    2.4. Support for SIP Services ...................................8
    2.5. Basic Telephony and Presence Information Support ...........9
    2.6. Emergency and Resource Priority Support ....................9
    2.7. Multi-Line Requirements ...................................10
    2.8. User Mobility .............................................11
    2.9. Interactive Text Support ..................................11

Sinnreich, et al. Informational [Page 1] RFC 4504 SIP Telephony Device Requirements May 2006

    2.10. Other Related Protocols ..................................12
    2.11. SIP Device Security Requirements .........................13
    2.12. Quality of Service .......................................13
    2.13. Media Requirements .......................................14
    2.14. Voice Codecs .............................................14
    2.15. Telephony Sound Requirements .............................15
    2.16. International Requirements ...............................15
    2.17. Support for Related Applications .........................16
    2.18. Web-Based Feature Management .............................16
    2.19. Firewall and NAT Traversal ...............................16
    2.20. Device Interfaces ........................................17
 3. Glossary and Usage for the Configuration Settings ..............18
    3.1. Device ID .................................................18
    3.2. Signaling Port ............................................19
    3.3. RTP Port Range ............................................19
    3.4. Quality of Service ........................................19
    3.5. Default Call Handling .....................................19
         3.5.1. Outbound Proxy .....................................19
         3.5.2. Default Outbound Proxy .............................20
         3.5.3. SIP Session Timer ..................................20
    3.6. Telephone Dialing Functions ...............................20
         3.6.1. Phone Number Representations .......................20
         3.6.2. Digit Maps and/or the Dial/OK Key ..................20
         3.6.3. Default Digit Map ..................................21
    3.7. SIP Timer Settings ........................................21
    3.8. Audio Codecs ..............................................21
    3.9. DTMF Method ...............................................22
    3.10. Local and Regional Parameters ............................22
    3.11. Time Server ..............................................22
    3.12. Language .................................................23
    3.13. Inbound Authentication ...................................23
    3.14. Voice Message Settings ...................................23
    3.15. Phonebook and Call History ...............................24
    3.16. User-Related Settings and Mobility .......................24
    3.17. AOR-Related Settings .....................................25
    3.18. Maximum Connections ......................................25
    3.19. Automatic Configuration and Upgrade ......................25
    3.20. Security Configurations ..................................26
 4. Security Considerations ........................................26
    4.1. Threats and Problem Statement .............................26
    4.2. SIP Telephony Device Security .............................27
    4.3. Privacy ...................................................28
    4.4. Support for NAT and Firewall Traversal ....................28
 5. Acknowledgements ...............................................29
 6. Informative References .........................................31

Sinnreich, et al. Informational [Page 2] RFC 4504 SIP Telephony Device Requirements May 2006

1. Introduction

 This document has the objective of focusing the Internet
 communications community on requirements for telephony devices using
 SIP.
 We base this information from developing and using a large number of
 SIP telephony devices in carrier and private IP networks and on the
 Internet.  This deployment has shown the need for generic
 requirements for SIP telephony devices and also the need for some
 specifics that can be used in SIP interoperability testing.
 SIP telephony devices, also referred to as SIP User Agents (UAs), can
 be any type of IP networked computing user device enabled for SIP-
 based IP telephony.  SIP telephony user devices can be SIP phones,
 adaptors for analog phones and for fax machines, conference
 speakerphones, software packages (soft clients) running on PCs,
 laptops, wireless connected PDAs, 'Wi-Fi' SIP mobile phones, as well
 as other mobile and cordless phones that support SIP signaling for
 real-time communications.  SIP-PSTN gateways are not the object of
 this memo, since they are network elements and not end user devices.
 SIP telephony devices can also be instant messaging (IM) applications
 that have a telephony option.
 SIP devices MAY support various other media besides voice, such as
 text, video, games, and other Internet applications; however, the
 non-voice requirements are not specified in this document, except
 when providing enhanced telephony features.
 SIP telephony devices are highly complex IP endpoints that speak many
 Internet protocols, have audio and visual interfaces, and require
 functionality targeted at several constituencies: (1) end users, (2)
 service providers and network administrators, (3) manufacturers, and
 (4) system integrators.
 The objectives of the requirements are a well-defined set of
 interoperability and multi-vendor-supported core features, so as to
 enable similar ease of purchase, installation, and operation as found
 for standard PCs, analog feature phones, or mobile phones.  Given the
 cost of some feature-rich display phones may approach the cost of PCs
 and PDAs, similar or even better ease of use as compared to personal
 computers and networked PDAs is expected by both end users and
 network administrators.
 While some of the recommendations of this document go beyond what is
 currently mandated for SIP implementations within the IETF, this is
 believed necessary to support the specified operational objectives.

Sinnreich, et al. Informational [Page 3] RFC 4504 SIP Telephony Device Requirements May 2006

 However, it is also important to keep in mind that the SIP
 specifications are constantly evolving; thus, these recommendations
 need to be considered in the context of that change and evolution.
 Due to the evolution of IETF documents in the standards process, and
 the informational nature of this memo, the references are all
 informative.

1.1. Conventions used in this document

 This document is informational and therefore the key words "MUST",
 "SHOULD", "SHOULD NOT", and "MAY", in this document are not to be
 interpreted as described in RFC 2119 [1], but rather indicate the
 nature of the suggested requirement.

2. Generic Requirements

 We present here a minimal set of requirements that MUST be met by all
 SIP [2] telephony devices, except where SHOULD or MAY is specified.

2.1. SIP Telephony Devices

 This memo applies mainly to desktop phones and other special purpose
 SIP telephony hardware.  Some of the requirements in this section are
 not applicable to PC/laptop or PDA software phones (soft phones) and
 mobile phones.
 Req-1: SIP telephony devices MUST be able to acquire IP network
        settings by automatic configuration using Dynamic Host
        Configuration Protocol (DHCP) [3].
 Req-2: SIP telephony devices MUST be able to acquire IP network
        settings by manual entry of settings from the device.
 Req-3: SIP telephony devices SHOULD support IPv6.  Some newer
        wireless networks may mandate support for IPv6 and in such
        networks SIP telephony devices MUST support IPv6.
 Req-4: SIP telephony devices MUST support the Simple Network Time
        Protocol [4].
 Req-5: Desktop SIP phones and other special purpose SIP telephony
        devices MUST be able to upgrade their firmware to support
        additional features and the functionality.
 Req-6: Users SHOULD be able to upgrade the devices with no special
        applications or equipment; or a service provider SHOULD be
        able to push the upgrade down to the devices remotely.

Sinnreich, et al. Informational [Page 4] RFC 4504 SIP Telephony Device Requirements May 2006

2.2. DNS and ENUM Support

 Req-7: SIP telephony devices MUST support RFC 3263 [5] for locating a
        SIP server and selecting a transport protocol.
 Req-8: SIP telephony devices MUST incorporate DNS resolvers that are
        configurable with at least two entries for DNS servers for
        redundancy.  To provide efficient DNS resolution, SIP
        telephony devices SHOULD query responsive DNS servers and skip
        DNS servers that have been non-responsive to recent queries.
 Req-9: To provide efficient DNS resolution and to limit post-dial
        delay, SIP telephony devices MUST cache DNS responses based on
        the DNS time-to-live.
 Req-10: For DNS efficiency, SIP telephony devices SHOULD use the
         additional information section of the DNS response instead of
         generating additional DNS queries.
 Req-11: SIP telephony devices MAY support ENUM [6] in case the end
         users prefer to have control over the ENUM lookup.  Note: The
         ENUM resolver can also be placed in the outgoing SIP proxy to
         simplify the operation of the SIP telephony device.  The
         Extension Mechanisms for DNS (EDNSO) in RFC 2671 SHOULD also
         be supported.

2.3. SIP Device Resident Telephony Features

 Req-12: SIP telephony devices MUST support RFC 3261 [2].
 Req-13: SIP telephony devices SHOULD support the SIP Privacy header
         by populating headers with values that reflect the privacy
         requirements and preferences as described in "User Agent
         Behavior", Section 4 of RFC 3323 [7].
 Req-14: SIP telephony devices MUST be able to place an existing call
         on hold, and initiate or receive another call, as specified
         in RFC 3264 [8] and SHOULD NOT omit the sendrecv attribute.
 Req-15: SIP telephony devices MUST provide a call waiting indicator.
         When participating in a call, the user MUST be alerted
         audibly and/or visually of another incoming call.  The user
         MUST be able to enable/disable the call waiting indicator.
 Req-16: SIP telephony devices MUST support SIP message waiting [9]
         and the integration with message store platforms.

Sinnreich, et al. Informational [Page 5] RFC 4504 SIP Telephony Device Requirements May 2006

 Req-17: SIP telephony devices MAY support a local dial plan.  If a
         dial plan is supported, it MUST be able to match the user
         input to one of multiple pattern strings and transform the
         input to a URI, including an arbitrary scheme and URI
         parameters.
 Example: If a local dial plan is supported, it SHOULD be configurable
 to generate any of the following URIs when "5551234" is dialed:
 tel:+12125551234
 sip:+12125551234@example.net;user=phone
 sips:+12125551234@example.net;user=phone
 sip:5551234@example.net
 sips:5551234@example.net
 tel:5551234;phone-context=nyc1.example.net
 sip:5551234;phone-
 context=nyc1.example.net@example.net;user=phone
 sips:5551234;phone-
 context=nyc1.example.net@example.net;user=phone
 sip:5551234;phone-
 context=nyc1.example.net@example.net;user=dialstring
 sips:5551234;phone-
 context=nyc1.example.net@example.net;user=dialstring
 tel:5551234;phone-context=+1212
 sip:5551234;phone-context=+1212@example.net;user=phone
 sips:5551234;phone-context=+1212@example.net;user=phone
 sip:5551234;phone-context=+1212@example.net;user=dialstring
 sips:5551234;phone-context=+1212@example.net;user=dialstring
 If a local dial plan is not supported, the device SHOULD be
 configurable to generate any of the following URIs when "5551234" is
 dialed:
 sip:5551234@example.net
 sips:5551234@example.net
 sip:5551234;phone-
 context=nyc1.example.net@example.net;user=dialstring
 sips:5551234;phone-
 context=nyc1.example.net@example.net;user=dialstring
 sip:5551234;phone-context=+1212@example.net;user=dialstring
 sips:5551234;phone-context=+1212@example.net;user=dialstring"
 Req-18: SIP telephony devices MUST support URIs for telephone numbers
         as per RFC 3966 [10].  This includes the reception as well as
         the sending of requests.  The reception may be denied
         according to the configurable security policy of the device.
         It is a reasonable behavior to send a request to a
         preconfigured outbound proxy.

Sinnreich, et al. Informational [Page 6] RFC 4504 SIP Telephony Device Requirements May 2006

 Req-19: SIP telephony devices MUST support REFER and NOTIFY for call
         transfer [11], [12].  SIP telephony devices MUST support
         escaped Replaces-Header (RFC 3891) and SHOULD support other
         escaped headers in the Refer-To header.
 Req-20: SIP telephony devices MUST support the unattended call
         transfer flows as defined in [12].
 Req-21: SIP telephony devices MUST support the attended call transfer
         as defined in [12].
 Req-22: SIP telephony devices MAY support device-based 3-way calling
         by mixing the audio streams and displaying the interactive
         text of at least 2 separate calls.
 Req-23: SIP telephony devices MUST be able to send dual-tone multi-
         frequency (DTMF) named telephone events as specified by RFC
         2833 [13].
 Req-24: Payload type negotiation MUST comply with RFC 3264 [8] and
         with the registered MIME types for RTP payload formats in RFC
         3555 [14].
 Req-25: The dynamic payload type MUST remain constant throughout the
         session.  For example, if an endpoint decides to renegotiate
         codecs or put the call on hold, the payload type for the re-
         invite MUST be the same as the initial payload type.  SIP
         devices MAY support Flow Identification as defined in RFC
         3388 [15].
 Req-26: When acting as a User Agent Client (UAC), SIP telephony
         devices SHOULD support the gateway model of RFC 3960 [16].
         When acting as a User Agent Server (UAS), SIP telephony
         devices SHOULD NOT send early media.
 Req-27: SIP telephony devices MUST be able to handle multiple early
         dialogs in the context of request forking.  When a confirmed
         dialog has been established, it is an acceptable behavior to
         send a BYE request in response to additional 2xx responses
         that establish additional confirmed dialogs.
 Req-28: SIP devices with a suitable display SHOULD support the call-
         info header and depending on the display capabilities MAY,
         for example, display an icon or the image of the caller.

Sinnreich, et al. Informational [Page 7] RFC 4504 SIP Telephony Device Requirements May 2006

 Req-29: To provide additional information about call failures, SIP
         telephony devices with a suitable display MUST render the
         "Reason Phrase" of the SIP message or map the "Status Code"
         to custom or default messages.  This presumes the language
         for the reason phrase is the same as the negotiated language.
         The devices MAY use an internal "Status Code" table if there
         was a problem with the language negotiation.
 Req-30: SIP telephony devices MAY support music on hold, both in
         receive mode and locally generated.  See also "SIP Service
         Examples" for a call flow with music on hold [17].
 Req-31: SIP telephony devices MAY ring after a call has been on hold
         for a predetermined period of time, typically 3 minutes.

2.4. Support for SIP Services

 Req-32: SIP telephony devices MUST support the SIP Basic Call Flow
         Examples as per RFC 3665 [17].
 Req-33: SIP telephony devices MUST support the SIP-PSTN Service
         Examples as per RFC 3666 [18].
 Req-34: SIP telephony devices MUST support the Third Party Call
         Control model [19], in the sense that they may be the
         controlled device.
 Req-35: SIP telephony devices SHOULD support SIP call control and
         multi-party usage [20].
 Req-36: SIP telephony devices SHOULD support conferencing services
         for voice [21], [22] and interactive text [23] and if
         equipped with an adequate display MAY also support instant
         messaging (IM) and presence [24], [25].
 Req-37: SIP telephony devices SHOULD support the indication of the
         User Agent capabilities and MUST support the caller
         capabilities and preferences as per RFC 3840 [26].
 Req-38: SIP telephony devices MAY support service mobility: Devices
         MAY allow roaming users to input their identity so as to have
         access to their services and preferences from the home SIP
         server.  Examples of user data to be available for roaming
         users are: user service ID, dialing plan, personal directory,
         and caller preferences.

Sinnreich, et al. Informational [Page 8] RFC 4504 SIP Telephony Device Requirements May 2006

2.5. Basic Telephony and Presence Information Support

 The large color displays in some newer models make such SIP phones
 and applications attractive for a rich communication environment.
 This document is focused, however, only on telephony-specific
 features enabled by SIP Presence and SIP Events.
 SIP telephony devices can also support presence status, such as the
 traditional Do Not Disturb, new event state-based information, such
 as being in another call or being in a conference, typing a message,
 emoticons, etc.  Some SIP telephony User Agents can support, for
 example, a voice session and several IM sessions with different
 parties.
 Req-39: SIP telephony devices SHOULD support Presence information
         [24] and SHOULD support the Rich Presence Information Data
         Format [27] for the new IP communication services enabled by
         Presence.
 Req-40: Users MUST be able to set the state of the SIP telephony
         device to "Do Not Disturb", and this MAY be manifested as a
         Presence state across the network if the UA can support
         Presence information.
 Req-41: SIP telephony devices with "Do Not Disturb" enabled MUST
         respond to new sessions with "486 Busy Here".

2.6. Emergency and Resource Priority Support

 Req-42: Emergency calling: For emergency numbers (e.g., 911, SOS
         URL), SIP telephony devices SHOULD support the work of the
         ECRIT WG [28].
 Req-43: Priority header: SIP devices SHOULD support the setting by
         the user of the Priority header specified in RFC 3261 for
         such applications as emergency calls or for selective call
         acceptance.
 Req-44: Resource Priority header: SIP telephony devices that are used
         in environments that support emergency preparedness MUST also
         support the sending and receiving of the Resource-Priority
         header as specified in [29].  The Resource Priority header
         influences the behavior for message routing in SIP proxies
         and PSTN telephony gateways and is different from the SIP
         Priority header specified in RFC 3261.  Users of SIP
         telephony devices may want to be interrupted in their lower-
         priority communications activities if such an emergency
         communication request arrives.

Sinnreich, et al. Informational [Page 9] RFC 4504 SIP Telephony Device Requirements May 2006

 Note: As of this writing, we recommend that implementers follow the
 work of the Working Group on Emergency Context Resolution with
 Internet Technologies (ecrit) in the IETF.  The complete solution is
 for further study at this time.  There is also work on the
 requirements for location conveyance in the SIPPING WG, see [30].

2.7. Multi-Line Requirements

 A SIP telephony device can have multiple lines: One SIP telephony
 device can be registered simultaneously with different SIP registrars
 from different service providers, using different names and
 credentials for each line.  The different sets of names and
 credentials are also called 'SIP accounts'.  The "line" terminology
 has been borrowed from multi-line PSTN/PBX phones, except that for
 SIP telephony devices there can be different SIP registrars/proxies
 for each line, each of which may belong to a different service
 provider, whereas this would be an exceptional case for the PSTN and
 certainly not the case for PBX phones.  Multi-line SIP telephony
 devices resemble more closely e-mail clients that can support several
 e-mail accounts.
 Note: Each SIP account can usually support different Addresses of
 Record (AORs) with a different list of contact addresses (CAs), as
 may be convenient, for example, when having different SIP accounts
 for business and personal use.  However, some of the CAs in different
 SIP accounts may point to the same devices.
 Req-45: Multi-line SIP telephony devices MUST support a unique
         authentication username, authentication password, registrar,
         and identity to be provisioned for each line.  The
         authentication username MAY be identical with the user name
         of the AOR and the domain name MAY be identical with the host
         name of the registrar.
 Req-46: Multi-line SIP telephony devices MUST be able to support the
         state of the client to Do Not Disturb on a per line basis.
 Req-47: Multi-line SIP telephony devices MUST support multi-line call
         waiting indicators.  Devices MUST allow the call waiting
         indicator to be set on a per line basis.
 Req-48: Multi-line SIP telephony devices MUST be able to support a
         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.

Sinnreich, et al. Informational [Page 10] RFC 4504 SIP Telephony Device Requirements May 2006

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
 [24] 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, and thus is 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 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.
 Req-52: SIP telephony devices such as SIP display phones and IP-
         analog adapters SHOULD support the accessibility requirements
         for deaf, hard-of-hearing and speech-impaired individuals as
         per RFC 3351 [31] and also for interactive text conversation
         [23], [32].

Sinnreich, et al. Informational [Page 11] RFC 4504 SIP Telephony Device Requirements May 2006

 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 that include a display, or have a
         facility for connecting an external display, MUST include
         protocol support as described in RFC 4103 [23] for real-time
         interactive text.
 Req-56: There may be value in having RFC 4103 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 provides 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 4103 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.
 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 [33].  SIP devices
         SHOULD use RTCP Extended Reports for logging and reporting on
         network support for voice quality, RFC 3611 [34] and MAY also
         support the RTCP summary report delivery [35].

Sinnreich, et al. Informational [Page 12] RFC 4504 SIP Telephony Device Requirements May 2006

2.11. SIP Device Security Requirements

 Req-60: SIP telephony devices MUST support digest authentication as
         per RFC 3261.  In addition, SIP telephony devices MUST
         support Transport Layer Security (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 Simple Network Management Protocol (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 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 Differentiated Services
         Code Point (DSCP) field for RTP streams as per RFC 2597 [37].
         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).

Sinnreich, et al. Informational [Page 13] RFC 4504 SIP Telephony Device Requirements May 2006

 Req-68: SIP telephony devices MAY support Resource Reservation
         Protocol (RSVP) [38].

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.  For example, RFC 3551 [39] 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 Voice over IP (VoIP), and
 also codecs found in mobile networks for which the SIP UA is
 targeted.  An ordered short list of preferences may look as follows:
 Req-71: SIP telephony devices SHOULD support Audio/Video Transport
         (AVT) payload type 0 (G.711 uLaw) as in [40] and its Annexes
         1 and 2.
 Req-72: SIP telephony devices SHOULD support the Internet Low Bit
         Rate codec (iLBC) [41], [42].
 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 [43], or G.722
         for high-quality audio conferences.

Sinnreich, et al. Informational [Page 14] RFC 4504 SIP Telephony Device Requirements May 2006

 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.
         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 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
         [44], [45].
 Req-77: SIP telephony devices SHOULD comply with the stability or
         minimum loss defined in ITU-T G.177.
 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
         [46] using User Agent capabilities [26].
 Req-81: SIP telephony devices intended to be used in various language
         settings MUST support other languages for menus, help, and
         labels.

Sinnreich, et al. Informational [Page 15] RFC 4504 SIP Telephony Device Requirements May 2006

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 [24].
 Req-83: SIP telephony devices MAY support Lightweight Directory
         Access Protocol (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 and 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.
 Req-86: SIP telephony devices SHOULD be able to operate behind a
         static Network Address Translation/Port Address Translation
         (NAPT) 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 [47].

Sinnreich, et al. Informational [Page 16] RFC 4504 SIP Telephony Device Requirements May 2006

 Req-87: SIP telephony devices SHOULD support the Simple Traversal of
         UDP through NATs (STUN) protocol [48] for determining the
         NAPT public external address.  A classification of scenarios
         and NATs where STUN is effective is reported in [49].
         Detailed call flows for interactive connectivity
         establishment (ICE) [50] are given in [51].
         Note: Developers are strongly advised to follow the document
         on best current practices for NAT traversal for SIP [51].
 Req-88: SIP telephony devices MAY support UPnP (http://www.upnp.org/)
         for local NAPT traversal.  Note that UPnP does not help if
         there is NAPT in the network of the service 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 such as 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
         graphical user interface (GUI) found in PCs, PDAs, mobile
         phones, and cordless 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.

Sinnreich, et al. Informational [Page 17] RFC 4504 SIP Telephony Device Requirements May 2006

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 cannot
 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"

Sinnreich, et al. Informational [Page 18] RFC 4504 SIP Telephony Device Requirements May 2006

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 that 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 Quality of Service (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 in 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

Sinnreich, et al. Informational [Page 19] RFC 4504 SIP Telephony Device Requirements May 2006

 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 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 the following:
 1) A rule by which the endpoint 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 that 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
 that SHOULD pass before dialing if the digits entered by the user

Sinnreich, et al. Informational [Page 20] RFC 4504 SIP Telephony Device Requirements May 2006

 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, the UA SHOULD be prepared to receive a 484 Address
 Incomplete response.  In this case, the UA should accept more user
 input and try again to dial the number.
 An example digit map could use regular expressions like in DNS NAPTR
 (RFC 2915) 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

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 endpoint 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

Sinnreich, et al. Informational [Page 21] RFC 4504 SIP Telephony Device Requirements May 2006

 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.
 Example: Codecs="speex/8000;ptime=20;cng=on,gsm;ptime=30"
 The settings MUST include hints about privacy for audio using Secure
 Realtime Transport Protocol (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
 preferably with out-of-band RTP packets (RFC 2833 [13]).  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".

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 [52].
 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 in that time zone.
 Optional parameters like the UTC offset may provide additional
 information for UAs 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"

Sinnreich, et al. Informational [Page 22] RFC 4504 SIP Telephony Device Requirements May 2006

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 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 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 URIs for the
 service context as specified in RFC 3087 [53].
 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 [9].
 Example: MWISubscribe="sip:mailbox01@media.proxy.com"

Sinnreich, et al. Informational [Page 23] RFC 4504 SIP Telephony Device Requirements May 2006

 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

 The 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.

3.16. User-Related Settings and Mobility

 A device MAY specify the user that 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 AORs (e.g., one or more personal AORs 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 each of the AORs (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 that are out of the scope of this
 document.  However, the ability to uniquely identify the device and

Sinnreich, et al. Informational [Page 24] RFC 4504 SIP Telephony Device Requirements May 2006

 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 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 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 endpoint
 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 [54] and the guidelines for
 connection-oriented transport for SIP [55].

3.19. Automatic Configuration and Upgrade

 Automatic SIP telephony device configuration SHOULD use the processes
 and requirements described in [56].  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.

Sinnreich, et al. Informational [Page 25] RFC 4504 SIP Telephony Device Requirements May 2006

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.
 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 [57] that
 include but are not limited to fake identity of callers,
 telemarketing, spam in IM, hijacking of calls, eavesdropping, and
 learning of private information such as the personal phone directory,
 user accounts and passwords, and the personal calling history.
 Various denial of service (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.

Sinnreich, et al. Informational [Page 26] RFC 4504 SIP Telephony Device Requirements May 2006

 SIP security is a hard problem for several reasons:
    o Peers can communicate across domains without any pre-arranged
      trust relationship.
    o There may be many intermediaries in the signaling path.
    o Multiple endpoints can be involved in such telephony operations
      as forwarding, forking, transfer, or conferencing.
    o There are seemingly conflicting service requirements when
      supporting anonymity, legal intercept, call trace, and privacy.
    o 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 Virtual
 Private Network (VPN) access to the corporate network when working
 from home or while traveling.  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
 [58] and privacy services [7], is 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 to 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 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.

Sinnreich, et al. Informational [Page 27] RFC 4504 SIP Telephony Device Requirements May 2006

 Digest Authentication
       SIP telephony devices MUST support digest authentication to
       register with the outgoing SIP registrar.  This ensures 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 its 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 Public Key Infrastructure (PKI) [59]
       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 (CAs).
       Note the recent work in the IETF on certificate services that
       do not require the telephony devices to store certificates
       [60].
 End-to-End Security Using S/MIME
       S/MIME [61] 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 ensure 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) [62] 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 [51].  Most scenarios where there are no
 SIP-enabled network edge NAT/firewalls or gateways in the enterprise

Sinnreich, et al. Informational [Page 28] RFC 4504 SIP Telephony Device Requirements May 2006

 can be managed if there is a STUN 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 Traversal Using
 Relay NAT (TURN) protocol exchange 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 NATs in the network, so that only
 STUN can be used, where required.  Reference [63] 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) 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 Real Time Streaming
 Protocol (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 Identity Body (AIB) format [65], new S/MIME
       requirements, enhancements for the authenticated identity, and
       Certificate Management Services for SIP.  We recommend
       developers and network managers to follow this work as it will
       develop into IETF standards.

5. Acknowledgements

 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 of 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.

Sinnreich, et al. Informational [Page 29] RFC 4504 SIP Telephony Device Requirements May 2006

 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 on
 version 04 of the document.  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, 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.

Sinnreich, et al. Informational [Page 30] RFC 4504 SIP Telephony Device Requirements May 2006

6. Informative References

 [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
      Levels", BCP 14, RFC 2119, March 1997.
 [2]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
      Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
      Session Initiation Protocol", RFC 3261, June 2002.
 [3]  Lemon, T. and S. Cheshire, "Encoding Long Options in the Dynamic
      Host Configuration Protocol (DHCPv4)", RFC 3396, November 2002.
 [4]  Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for
      IPv4, IPv6 and OSI", RFC 4330, January 2006.
 [5]  Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
      (SIP): Locating SIP Servers", RFC 3263, June 2002.
 [6]  Peterson, J., "enumservice registration for Session Initiation
      Protocol (SIP) Addresses-of-Record", RFC 3764, April 2004.
 [7]  Peterson, J., "A Privacy Mechanism for the Session Initiation
      Protocol (SIP)", RFC 3323, November 2002.
 [8]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
      Session Description Protocol (SDP)", RFC 3264, June 2002.
 [9]  Mahy, R., "A Message Summary and Message Waiting Indication
      Event Package for the Session Initiation Protocol (SIP)", RFC
      3842, August 2004.
 [10] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966,
      December 2004.
 [11] Sparks, R., "The Session Initiation Protocol (SIP) Refer
      Method", RFC 3515, April 2003.
 [12] Johnston, A., "SIP Service Examples", Work in Progress, March
      2006.
 [13] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits,
      Telephony Tones and Telephony Signals", RFC 2833, May 2000.
 [14] Casner, S. and P. Hoschka, "MIME Type Registration of RTP
      Payload Formats", RFC 3555, July 2003.

Sinnreich, et al. Informational [Page 31] RFC 4504 SIP Telephony Device Requirements May 2006

 [15] Camarillo, G., Eriksson, G., Holler, J., and H. Schulzrinne,
      "Grouping of Media Lines in the Session Description Protocol
      (SDP)", RFC 3388, December 2002.
 [16] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing Tone
      Generation in the Session Initiation Protocol (SIP)", RFC 3960,
      December 2004.
 [17] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and K.
      Summers, "Session Initiation Protocol (SIP) Basic Call Flow
      Examples", BCP 75, RFC 3665, December 2003.
 [18] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and K.
      Summers, "Session Initiation Protocol (SIP) Public Switched
      Telephone Network (PSTN) Call Flows", BCP 76, RFC 3666, December
      2003.
 [19] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo,
      "Best Current Practices for Third Party Call Control (3pcc) in
      the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April
      2004.
 [20] Mahy, R., et al., "A Call Control and Multi-party usage
      framework for the Session Initiation Protocol (SIP)", Work in
      Progress, March 2006.
 [21] Johnston, A. and O. Levin, "Session Initiation Protocol Call
      Control - Conferencing for User Agents", Work in Progress,
      October 2005.
 [22] Even, R. and N. Ismail, "Conferencing Scenarios", Work in
      Progress, September 2005.
 [23] Hellstrom, G. and P. Jones, "RTP Payload for Text Conversation",
      RFC 4103, June 2005.
 [24] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and
      D. Gurle, "Session Initiation Protocol (SIP) Extension for
      Instant Messaging", RFC 3428, December 2002.
 [25] Rosenberg, J., "A Presence Event Package for the Session
      Initiation Protocol (SIP)", RFC 3856, August 2004.
 [26] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User
      Agent Capabilities in the Session Initiation Protocol (SIP)",
      RFC 3840, August 2004.

Sinnreich, et al. Informational [Page 32] RFC 4504 SIP Telephony Device Requirements May 2006

 [27] Schulzrinne, H., Gurbani, V., Kyzivat, P., and J. Rosenberg,
      "RPID: Rich Presence Extensions to the Presence Information Data
      Format (PIDF)", Work in Progress, September 2005.
 [28] See the Working Group on Emergency Context Resolution with
      Internet Technologies at
      http://www.ietf.org/html.charters/ecrit-charter.html
 [29] Schulzrinne, H. and J. Polk, "Communications Resource Priority
      for the Session Initiation Protocol (SIP)", RFC 4412, February
      2006.
 [30] Polk, J. and B. Rosen, "Session Initiation Protocol Location
      Conveyance", Work in Progress, July 2005.
 [31] Charlton, N., Gasson, M., Gybels, G., Spanner, M., and A. van
      Wijk, "User Requirements for the Session Initiation Protocol
      (SIP) in Support of Deaf, Hard of Hearing and Speech-impaired
      Individuals", RFC 3351, August 2002.
 [32] van Wijk, A., "Framework of requirements for real-time text
      conversation using SIP", Work in Progress, September 2005.
 [33] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
      "RTP: A Transport Protocol for Real-Time Applications", STD 64,
      RFC 3550, July 2003.
 [34] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol
      Extended Reports (RTCP XR)", RFC 3611, November 2003.
 [35] Pendleton, A., "SIP Package for Quality Reporting Event", Work
      in Progress, February 2006.
 [36] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
      2246, January 1999.
 [37] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured
      Forwarding PHB Group", RFC 2597, June 1999.
 [38] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin,
      "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
      Specification", RFC 2205, September 1997.
 [39] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
      Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
 [40] ITU-T Recommendation G.711, available online at
      http://www.itu.int.

Sinnreich, et al. Informational [Page 33] RFC 4504 SIP Telephony Device Requirements May 2006

 [41] Andersen, S., Duric, A., Astrom, H., Hagen, R., Kleijn, W., and
      J. Linden, "Internet Low Bit Rate Codec (iLBC)", RFC 3951,
      December 2004.
 [42] Duric, A. and S. Andersen, "Real-time Transport Protocol (RTP)
      Payload Format for internet Low Bit Rate Codec (iLBC) Speech",
      RFC 3952, December 2004.
 [43] Herlein, G., et al., "RTP Payload Format for the Speex Codec",
      Work in Progress, October 2005.
 [44] TIA/EIA-810-A, "Transmission Requirements for Narrowband Voice
      over IP and Voice over PCM Digital Wireline Telephones", July
      2000.
 [45] TIA-EIA-IS-811, "Terminal Equipment - Performance and
      Interoperability Requirements for Voice-over-IP (VoIP) Feature
      Telephones", July 2000.
 [46] Alvestrand, H., "Tags for the Identification of Languages", BCP
      47, RFC 3066, January 2001.
 [47] Wing, D., "Symmetric RTP and RTCP Considered Helpful", Work in
      Progress, October 2004.
 [48] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN -
      Simple Traversal of User Datagram Protocol (UDP) Through Network
      Address Translators (NATs)", RFC 3489, March 2003.
 [49] Jennings, C., "NAT Classification Test Results", Work in
      Progress, July 2005.
 [50] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A
      Methodology for Network Address Translator (NAT) Traversal for
      Offer/Answer Protocols", Work in Progress, July 2005.
 [51] Boulton, C. and J. Rosenberg, "Best Current Practices for NAT
      Traversal for SIP", Work in Progress, October 2005.
 [52] P. Eggert, "Sources for time zone and daylight saving time
      data." Available at http://www.twinsun.com/tz/tz-link.htm.
 [53] Campbell, B. and R. Sparks, "Control of Service Context using
      SIP Request-URI", RFC 3087, April 2001.
 [54] Mahy, R., "Connection Reuse in the Session Initiation Protocol
      (SIP)", Work in Progress, February 2006.

Sinnreich, et al. Informational [Page 34] RFC 4504 SIP Telephony Device Requirements May 2006

 [55] Jennings, C. and R. Mahy, "Managing Client Initiated Connections
      in the Session Initiation Protocol", Work in Progress, March
      2006.
 [56] Petrie, D., "A Framework for SIP User Agent Profile Delivery",
      Work in Progress, July 2005.
 [57] Jennings, C., "SIP Tutorial: SIP Security", presented at the VON
      Spring 2004 conference, March 29, 2004, Santa Clara, CA.
 [58] Jennings, C., Peterson, J., and M. Watson, "Private Extensions
      to the Session Initiation Protocol (SIP) for Asserted Identity
      within Trusted Networks", RFC 3325, November 2002.
 [59] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. Wu,
      "Internet X.509 Public Key Infrastructure Certificate Policy and
      Certification Practices Framework", RFC 3647, November 2003.
 [60] Jennings, C. and J. Peterson, "Certificate Management Service
      for The Session Initiation Protocol (SIP)", Work in Progress,
      March 2006.
 [61] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
      (S/MIME) Version 3.1 Message Specification", RFC 3851, July
      2004.
 [62] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
      Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC
      3711, March 2004.
 [63] Audet, F. and C. Jennings, "NAT Behavioral Requirements for
      Unicast UDP", Work in Progress, September 2005.
 [64] Jennings, C., "Example call flows using SIP security
      mechanisms", Work in Progress, February 2006.
 [65] Peterson, J., "Session Initiation Protocol (SIP) Authenticated
      Identity Body (AIB) Format", RFC 3893, September 2004.

Sinnreich, et al. Informational [Page 35] RFC 4504 SIP Telephony Device Requirements May 2006

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
 Verizon
 1201 East Arapaho Road
 Richardson, TX 75081, USA
 EMail: steven.lass@verizonbusiness.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

Sinnreich, et al. Informational [Page 36] RFC 4504 SIP Telephony Device Requirements May 2006

Full Copyright Statement

 Copyright (C) The Internet Society (2006).
 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.

Intellectual Property

 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.

Acknowledgement

 Funding for the RFC Editor function is provided by the IETF
 Administrative Support Activity (IASA).

Sinnreich, et al. Informational [Page 37]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4504.txt · Last modified: 2006/05/23 23:02 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki