[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 RFC 4504

        SIPPING WG                                   H. Sinnreich/MCI,editor
        Internet Draft                                           S. Lass/MCI
                                                           C. Stredicke/snom
        Expires: February 2005                                 December 2004
                 SIP Telephony Device Requirements and Configuration
     Status of this Memo
        By submitting this Internet-Draft, I certify that any applicable
        patent or other IPR claims of which I am aware have been disclosed,
        and any of which I become aware will be disclosed, in accordance with
        RFC 3668.
        This document may not be modified, and derivative works of it may not
        be created, except to publish it as an RFC and to translate it into
        languages other than English.
        This document may not be modified, and derivative works of it may not
        be created.
        This document may only be posted in an Internet-Draft.
        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
        The list of Internet-Draft Shadow Directories can be accessed at
        This Internet-Draft will expire on June 16, 2005.
     Copyright Notice
           Copyright (C) The Internet Society (2004). All Rights Reserved.
        This informational I-D 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 minimum set of
     Sinnreich               Expires June 16, 2005                  [Page 1]

        draft-sinnreich-sipdev-req-05.txt                      December 2004
        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.
     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 Requirement............................................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..................................7
           2.5. Basic Telephony and Presence Information Support..........8
           2.6. Emergency and Resource Priority Support...................9
           2.7. Multi-Line Requirements...................................9
           2.8. User Mobility............................................10
           2.9. Interactive Text Support.................................11
           2.10. Other Related Protocols.................................12
           2.11. SIP Device Security Requirements........................12
           2.12. Quality of Service......................................13
           2.13. Media Requirements......................................13
           2.14. Voice Codecs............................................13
           2.15. Telephony Sound Requirements............................14
           2.16. International Requirements..............................15
           2.17. Support for Applications................................15
           2.18. Web Based Feature Management............................15
           2.19. Firewall and NAT Traversal..............................16
           2.20. Device Interfaces.......................................16
        3. Glossary and Usage for the Configuration Settings.............17
           3.1. Device ID................................................18
           3.2. Signaling Port...........................................18
           3.3. RTP Port Range...........................................18
           3.4. Quality of Service.......................................18
           3.5. Default Call Handling....................................19
           3.6. Outbound Proxy...........................................19
           3.7. Default Outbound Proxy...................................19
           3.8. SIP Session Timer........................................19
           3.9. Telephone Dialing Functions..............................19
           3.10. Phone Number Representations............................19
     Sinnreich               Expires June 16, 2005                  [Page 2]

        draft-sinnreich-sipdev-req-05.txt                      December 2004
           3.11. Digit Maps and/or the Dial/OK Key.......................20
           3.12. Default Digit Map.......................................20
           3.13. SIP Timer Settings......................................21
           3.14. Audio Codecs............................................21
           3.15. DTMF Method.............................................21
           3.16. Local and Regional Parameters...........................21
           3.17. Time Server.............................................22
           3.18. Language................................................22
           3.19. Inbound Authentication..................................22
           3.20. Voice Message Settings..................................22
           3.21. Phonebook and Call History..............................23
           3.22. User Related Settings and Mobility......................23
           3.23. AOR Related Settings....................................24
           3.24. Maximum Connections.....................................24
           3.25. Automatic Configuration and Upgrade.....................24
           3.26. Security Configurations.................................24
        4. Security Considerations.......................................25
           4.1. Threats and Problem Statement............................25
           4.2. SIP Telephony Device Security............................26
           4.3. Privacy..................................................27
           4.4. Support for NAT and Firewall Traversal...................27
        5. Acknowledgments...............................................28
        6. Changes From Previous Versions................................28
        7. References....................................................29
           7.1. Normative References.....................................29
           7.2. Informative References...................................32
        8. Author's Addresses............................................35
        Intellectual Property Statement..................................35
        Disclaimer of Validity...........................................36
        Copyright Statement..............................................36
     1. Introduction
        This informational I-D has the objective of focusing the Internet
        communications community on requirements for telephony devices using
        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
     Sinnreich               Expires June 16, 2005                  [Page 3]

        draft-sinnreich-sipdev-req-05.txt                      December 2004
        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 and (3) manufacturers,
        as well as (4) system integrators.
        The objectives of the requirements are a minimum 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.
     2. Generic Requirement
        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.
       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.
     Sinnreich               Expires June 16, 2005                  [Page 4]

        draft-sinnreich-sipdev-req-05.txt                      December 2004
       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 SHOULD 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
       Req-15: SIP telephony devices MUST provide a call waiting indicator.
               When participating in a call, the user MUST be alerted audibly
               and/or visually of another incoming call. The user MUST be
               able to enable/disable the call waiting indicator.
       Req-16: SIP telephony devices MUST support SIP message waiting [43]
               and the integration with message store platforms.
       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.
     Sinnreich               Expires June 16, 2005                  [Page 5]

        draft-sinnreich-sipdev-req-05.txt                      December 2004
       Req-18: SIP telephony devices MUST support the URLs for Telephone
               numbers as per RFC 2806 [9]. See also the amended version in
               RFC 2806bis [44].
       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 of at least 2 separate calls.
       SIP-23: SIP telephony devices MUST be able to send DTMF named
               telephone events as specified by RFC 2833 [11].
       SIP-24: Payload type negotiation MUST comply with RFC 3264 [12] and
               with the registered MIME types for RTP payload formats in RFC
               3555 [13].
       SIP-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
       SIP-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.
     Sinnreich               Expires June 16, 2005                  [Page 6]

        draft-sinnreich-sipdev-req-05.txt                      December 2004
       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.
     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].
     Sinnreich               Expires June 16, 2005                  [Page 7]

        draft-sinnreich-sipdev-req-05.txt                      December 2004
       Req-36: SIP telephony devices SHOULD support conferencing services
               for voice [48], [49] and if equipped with an adequate display
               MAY also support presence [50].
       Req-37: SIP telephony devices SHOULD support the indication of the
               User Agent Capabilities [71] and MUST support the caller
               preferences as per RFC 3840 [52].
       Req-38: SIP telephony devices MAY support service mobility: Devices
               MAY allow roaming users to upload their identity so as to have
               access to their services and preferences from the home SIP
               server. Examples of user data to be available for roaming
               users are: User service ID, the dialing plan, personal
               directory and 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 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
       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".
     Sinnreich               Expires June 16, 2005                  [Page 8]

        draft-sinnreich-sipdev-req-05.txt                      December 2004
     2.6. Emergency and Resource Priority Support
       Req-42: Emergency calling: For emergency numbers (e.g. 911, SOS URL)
               the client SHOULD send the location information acquired by
               various means as detailed in [53]. SIP telephony devices
               SHOULD support the emerging Emergency Services Architecture
               for Internet Telephony Systems [54].
       Req-43: Priority header: SIP devices MUST support 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.
     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.
     Sinnreich               Expires June 16, 2005                  [Page 9]

        draft-sinnreich-sipdev-req-05.txt                      December 2004
       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.
     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 for the desktop
               MUST use the local static location data associated with the
               device for emergency calls.
     Sinnreich               Expires June 16, 2005                 [Page 10]

        draft-sinnreich-sipdev-req-05.txt                      December 2004
     2.9. Interactive Text Support
       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].
               Note: SIP telephony devices supporting Instant Messaging based
               on SIMPLE [50] support text conversation based on blocks of
               text. However, interactive text conversation is often
               preferred here due to its interactive and more streaming-like
               nature, thus more appropriate for accessibility.
       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
     Sinnreich               Expires June 16, 2005                 [Page 11]

        draft-sinnreich-sipdev-req-05.txt                      December 2004
               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 PDA s and various wireless SIP
     2.10. Other Related Protocols
       Req-59: SIP telephony devices MUST support 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 SHOULD 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.
       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
     Sinnreich               Expires June 16, 2005                 [Page 12]

        draft-sinnreich-sipdev-req-05.txt                      December 2004
               telemarketing and spam. The setting to accept/reject MUST be
       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
     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
               complement 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) as in [22].
       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
       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.
     Sinnreich               Expires June 16, 2005                 [Page 13]

        draft-sinnreich-sipdev-req-05.txt                      December 2004
        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, besides the various codecs found in mobile
       Req-71: SIP telephony devices SHOULD support AVT payload type 0
               (G.711 uLaw) as the default codec [25] and its Annexes 1 and
       Req-72: SIP telephony devices SHOULD support the Internet Low Bit
               Rate codec (iLBC) [26], [27].
       Req-73: SIP telephony devices SHOULD support GSM codecs found in
               various 3G wireless phones.
       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
       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 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 narrow band compressed G.xx codec types, such
               as G. 711, G.729, G.723.1, G.722, etc., thus avoiding the
               complexity and cost to implementers and service providers
               alike who are burdened by supporting so many codec types,
               besides 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].
     Sinnreich               Expires June 16, 2005                 [Page 14]

        draft-sinnreich-sipdev-req-05.txt                      December 2004
       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 Caller Preferences [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 Applications
        The following requirements apply to functions placed in the SIP
        telephony device.
       Req-82: SIP telephony devices that have a large display and support
                presence SHOULD display a buddy list [50].
       Req-83: SIP telephony devices MAY support LDAP for client-based
                directory lookup.
       Req-84: SIP telephony devices MAY support a phone setup where a URL
                is automatically dialed when the phone goes off-hook.
     2.18. Web Based Feature Management
       Req-85: SIP telephony devices SHOULD support an internal web server
                to allow users the option to manually configure the phone
                and to set up personal phone applications such as the
                address book, speed-dial, ring tones, and last but not least
                the call handling options for the various lines, aliases, in
                a user friendly fashion. Web pages to manage the SIP
                telephony device SHOULD be supported by the individual
                device, or MAY be supported in managed networks from
                centralized web servers. Managing SIP telephony devices
     Sinnreich               Expires June 16, 2005                 [Page 15]

        draft-sinnreich-sipdev-req-05.txt                      December 2004
                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.
     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].
               Note: Developers are advised to follow the standards process
               for ICE [63] and eventually support ICE in SIP telephony
       Req-88: SIP telephony devices MAY support UPnP (http://www.upnp.org/)
               for local NAPT traversal. Note that UPnP does not help if
               there are NAPT in the network of the services provider.
       Req-89: SIP telephony devices MUST be able to limit the ports used
               for RTP to a provisioned range.
     2.20. Device Interfaces
       Req-90: SIP telephony devices MUST have two types of interface
                capabilities, for both phone numbers and URLs, 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
     Sinnreich               Expires June 16, 2005                 [Page 16]

        draft-sinnreich-sipdev-req-05.txt                      December 2004
                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 URLs and phone numbers. This includes all alphanumeric
                characters allowed in legal SIP URLs. Possible approaches
                include using a web page, display and keyboard entry, type-
                ahead or graffiti for PDAs.
       Req-93: SIP telephony devices should allow phone number entry in
                human friendly fashion, with the usual separators and
                brackets between digits and digit groups.
     3. Glossary and Usage for the Configuration Settings
       SIP telephony devices are quite complex and their configuration is
       made more difficult by the widely diverse use of technical terms for
       the settings. We present here a glossary of the most common settings
       and some of the more widely used values for some settings.
       Settings are the information on a SIP UA that it needs so as to be a
       functional SIP endpoint. The settings defined in this document are
       not intended to be a complete listing of all possible settings. It
       MUST be possible to add vendor specific settings.
       The list of available settings includes settings that MUST, SHOULD or
       MAY be used by all devices (when present) and that make up the common
       denominator that is used and understood by all devices. However, the
       list is open to vendor specific extensions that support additional
       settings, which enable a rich and valuable set of features.
       Settings MAY be read-only on the device. This avoids the
       misconfiguration of important settings by inexperienced users
       generating service cost for operators. The settings provisioning
       process SHOULD indicate which settings can be changed by the end-user
       and which settings should be protected.
       In order to achieve wide adoption of any settings format it is
       important that it should not be excessive in size for modest devices
       to use it. Any format SHOULD be structured enough to allow flexible
       extensions to it by vendors.
       Settings may belong to the device or to a SIP service provider and
       the address of record (AOR) registered there. When the device acts in
       the context of an AOR, it will first try to look up a setting in the
       AOR context. If the setting can not be found in that context, the
       device will try to find the setting in the device context. If that
       also fails, the device MAY use a default value for the setting.
     Sinnreich               Expires June 16, 2005                 [Page 17]

        draft-sinnreich-sipdev-req-05.txt                      December 2004
       The examples shown here are just of informational nature. Other
       documents may specify the syntax and semantics for the respective
     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 MAY 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
               Example: RTPPorts="50000-51000"
     3.4. Quality of Service
               The QoS settings for outbound packets SHOULD be configurable
               for network packets associated with call signaling (SIP) and
               media transport (RTP/RTCP). These settings help network
               operators identifying voice packets in their network and allow
               them to transport them with the required QoS. The settings are
               independently configurable for the different transport layers
               and signaling, media or administration. The QoS settings
               SHOULD also include the QoS mechanism.
               For both categories of network traffic, the device SHOULD
               permit configuration of the type of service 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"
     Sinnreich               Expires June 16, 2005                 [Page 18]

        draft-sinnreich-sipdev-req-05.txt                      December 2004
     3.5. Default Call Handling
               All of the call handling settings defined below can be defined
               here as default behaviors.
     3.6. 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
               NAT application layer gateways are always in the signaling
               path. The second requirement allows the optimization of the
               routing by the outbound proxy.
               Example: OutboundProxy="sip:nat.proxy.com"
     3.7. 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.8. 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
               Example: SessionTimer="600;unit=seconds"
     3.9. 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 URL (usually
               SIP URL or TEL URL).
     3.10. 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".
     Sinnreich               Expires June 16, 2005                 [Page 19]

        draft-sinnreich-sipdev-req-05.txt                      December 2004
     3.11. 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
               1) A rule by which the end point can judge that the user has
               completed dialing, and
               2) A rule to construct a URL from the dialed digits, and
               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
               An example digit map could use regular expressions like in DNS
               NAPTR (RFC2915) to translate user input into a SIP URL.
               Additional replacement patterns like "d" could insert the
               domain name of the used AOR. Additional parameters could be
               inserted in the flags portion of the substitution expression.
               A list of those patterns would make up the dial plan:
     3.12. 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 URL 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.
     Sinnreich               Expires June 16, 2005                 [Page 20]

        draft-sinnreich-sipdev-req-05.txt                      December 2004
     3.13. 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.14. 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 MAY include hints about privacy for audio using
               SRTP that either mandate or encourage the usage of secure RTP.
               Example: SRTP="mandatory"
     3.15. 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",
     3.16. 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"
     Sinnreich               Expires June 16, 2005                 [Page 21]

        draft-sinnreich-sipdev-req-05.txt                      December 2004
     3.17. 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=";protocol=NTP"
     3.18. Language
               Setting the correct language is important for simple
               installation around the globe.
               A language Setting SHOULD be specified for the whole device.
               Where it is specified it MUST use the codes defined in RFC
               3066 [34] to provide some predictability.
               Example: Language="de"
               It is recommended to set the Language as writable, so that the
               user MAY change this. This setting SHOULD NOT be AOR related.
               A SIP UA MUST be able to parse and accept requests containing
               international characters encoded as UTF-8 even if it cannot
               display those characters in the user interface.
     3.19. 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
     3.20. Voice Message Settings
               Various voice message settings require the use of URL'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].
     Sinnreich               Expires June 16, 2005                 [Page 22]

        draft-sinnreich-sipdev-req-05.txt                      December 2004
               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.21. 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.
     3.22. 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
     Sinnreich               Expires June 16, 2005                 [Page 23]

        draft-sinnreich-sipdev-req-05.txt                      December 2004
               server based as well as local (i.e. on the device)
               configuration management of the configuration data.
     3.23. AOR Related Settings
               SIP telephony devices MUST use the Address of Record (AOR)
               related settings, as specified here.
               AOR Identification
               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.24. 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"
     3.25. 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.26. Security Configurations
               The device configuration usually contains sensitive
               information that MUST be protected. Examples include
               authentication information, private address books and call
     Sinnreich               Expires June 16, 2005                 [Page 24]

        draft-sinnreich-sipdev-req-05.txt                      December 2004
               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 challenge a
               subscriber before sending configuration information.
               It is RECOMMENDED not to 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.12 and 2.20 state 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
        There are a large number of deployment scenarios in enterprise
        networks, using residential networks and employees using VPN access
     Sinnreich               Expires June 16, 2005                 [Page 25]

        draft-sinnreich-sipdev-req-05.txt                      December 2004
        to the corporate network when working from home or on travel. There
        are different security scenarios for each. The security expectations
        are also very different, say within an enterprise network or when
        using a laptop in a public wireless hotspot and it is beyond the
        scope of this memo to describe all possible scenarios in detail.
        The authors believe that adequate security for SIP telephony devices
        can be best implemented within protected networks, be they private IP
        networks or service provider SIP enabled networks where a large part
        of the security threats listed here are dealt with in the protected
        network. A more general security discussion that includes network
        based security features, such as network based assertion of identity
        [37] and privacy services [38] are outside the scope of this memo,
        but must be well understood by developers, network managers and
        service providers.
        In the following some basic security considerations as specified in
        RFC 3261 are discussed as they apply for SIP telephony devices.
     4.2. SIP Telephony Device Security
        Transport Level Security
               SIP telephony devices that operate outside the perimeter of
               secure private IP networks (this includes telecommuters and
               roaming users connected via a VPN channel to the private IP
               network) SHOULD 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
        End User Certificates
               SIP telephony devices MAY store personal end user certificates
               that are part of some PKI [39] service for high security
               identification to the outgoing SIP registrar as well as for
               end to end authentication. SIP telephony devices equipped for
               certificate based authentication MUST also store a key ring of
               certificates from public certificate authorities (CA s).
     Sinnreich               Expires June 16, 2005                 [Page 26]

        draft-sinnreich-sipdev-req-05.txt                      December 2004
               Note the recent work in the IETF on certificate services that
               do not require the telephony devices to store certificates
        End-to-End Security Using S/MIME
               S/MIME [40] MAY be used 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.
     4.3. Privacy
        Media Encryption
               Secure RTP (SRTP) [41] MAY be used for the encryption of media
               such as audio 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. 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 cases 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 all active SIP
               telephony devices must be supported. Media relays may also
               introduce longer paths with additional delays for voice.
               Due to these disadvantages of media relays, it is preferable
               to avoid symmetric and non-deterministic NAT s in the network,
               so that only STUN can be used, where required. Reference [73]
               deals in more detail how NAT has to 'behave'.
               It is not always obvious to determine the specific NAT and
               firewall scenario under which a SIP telephony device may
               operate. For this reason, the support for ICE [63] has been
               proposed 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 the
               STUN, TURN and RSIP protocols by using extensions to SDP.
        Call flows using SIP security mechanisms
     Sinnreich               Expires June 16, 2005                 [Page 27]

        draft-sinnreich-sipdev-req-05.txt                      December 2004
               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 [69]. We recommend developers
               and network managers to follow this work as it will develop
               into IETF standards.
     5. Acknowledgments
        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
        this last version 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, Jvrgen
        Bjvrkner, Jay Batson, Eric Tremblay, Gunnar Hellstrvm, 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. As mentioned, their
        contributions are now the focus of separate documents.
     6. Changes From Previous Versions
        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].
     Sinnreich               Expires June 16, 2005                 [Page 28]

        draft-sinnreich-sipdev-req-05.txt                      December 2004
          . Reviewed and tightened the language based on comments by John
        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
           . 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.
     7. References
     7.1. Normative References
        [1] RFC 2026: "The Internet Standards Process, Revision 3" by Scott
        Bradner, IETF, October 1996.
        [2] RFC 2119: "Key words for use in RFCs to Indicate Requirement
        Levels" by Scott Bradner, IETF, 1997.
        [3] RFC 3261: "SIP: Session Initiation Protocol" by J. Rosenberg et.
        al, IETF, June 2002.
        [4] RFC 2131: "Dynamic Host Configuration Protocol" by R. Droms,
        IETF, March 1997.
     Sinnreich               Expires June 16, 2005                 [Page 29]

        draft-sinnreich-sipdev-req-05.txt                      December 2004
        [5] RFC 2030: "Simple Network Time Protocol (SNTP) Version 4 for IPv4
        and IPv6 and OSI" by D. Mills, IETF, October 1996.
        [6] RFC 3263: "Session Initiation Protocol (SIP): Locating SIP
        Servers" by J. Rosenberg and H. Schulzrinne, IETF, June 2002.
        [7] RFC 3764: "ENUM Service Registration for Session Initiation
        Protocol (SIP) Address of Record" by J. Peterson, IETF, April 2004.
        [8] RFC 3323: "A Privacy Mechanism for the Session Initiation
        Protocol" by J. Peterson, IETF, November 2002.
        [9] RFC 2806: "URLs for Telephone Calls" by A. Vaha-Sipila, IETF,
        April 2000.
        [10] RFC 3515: "The Session Initiation Protocol (SIP) Refer Method"
        by R. Sparks. IETF, April 2003.
        [11] RFC 2833: "RTP Payload for DTMF Digits, Telephony Tones and
        Telephony Signals", by H. Schulzrinne and S. Petrack. IETF, May 2000.
        [12] RFC 3264: "An Offer/Answer Model with the Session Description
        Protocol (SDP)  by J. Rosenberg and H. Schulzrinne. IETF, June 2002.
        [13] RFC 3555: S. "MIME Type Registration of RTP Payload Formats" by
        S. Casner and P. Hoschka, IETF, July 2003.
        [15] RFC 3665: "Session Initiation Protocol (SIP) Basic Call Flow
        Examples" by A. Johnston et al., IETF, December 2003.
        [14] RFC 3388: "Grouping of Media Lines in the Session Description
        Protocol (SDP)" by G. Camarillo et al. IETF, December 2002.
        [16] RFC 3666: "Session Initiation Protocol (SIP) Public Switched
        Telephone Network (PSTN) Call Flows" by A. Johnston, IETF December
        [17] RFC 3725: "Best Current Practices for Third Party Call Control
        (3pcc) in the Session Initiation Protocol (SIP)" by J. Rosenberg et
        al. IETF, April 2004.
        [18] RFC 3351: "User Requirements for the Session Initiation Protocol
        (SIP) in Support of Deaf, Hard of Hearing and Speech-impaired
        Individuals". IETF, August 2002.
        [19] RFC 2327: "SDP: Session Description Protocol" by M. Handley and
        V. Jacobson. IETF, April 1998.
     Sinnreich               Expires June 16, 2005                 [Page 30]

        draft-sinnreich-sipdev-req-05.txt                      December 2004
        [20] RFC 3550: "RTP: A Transport Protocol for Real-Time Applications"
        by H. Schulzrinne et al. IETF, July 2003.
        [21] RFC 2611: "RTP Control Protocol Extended Reports (RTCP XR)" by
        T. Friedman et al. IETF, November 2003.
        [22] RFC 2597: "Assured Forwarding PHB Group" by Heinanen, J. et al.
        IETF, June 1999.
        [23] RFC 2205: "Resource ReSerVation Protocol (RSVP)- Version 1
        Functional Specification" by R. Braden et al. IETF, September 1997.
        [24] RFC 3551: "RTP Profile for Audio and Video Conferences with
        Minimal Control". 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", draft-
        ietf-avt-ilbc-codec-04.txt, IETF, November 2003.
        [27] A. Duric: "RTP Payload Format for iLBC Speech", draft-ietf-avt-
        rtp-ilbc-04.txt", IETF, November 2003.
        [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] RFC 3489: "STUN - Simple Traversal of User Datagram Protocol
        (UDP) Through Network Address Translators (NATs)" by J. Rosenberg et
        al. 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] RFC 3066: "Tags for the Identification of Languages" by H.
        Alvestrand. IETF, January 2001.
        [35] RFC 3087: "Control of Service Context using SIP Request-URI" by
        B. Campbell and R. Sparks. IETF, April 2001.
     Sinnreich               Expires June 16, 2005                 [Page 31]

        draft-sinnreich-sipdev-req-05.txt                      December 2004
        [36] RFC 2246: "The TLS protocol Version 1.0" by T. Dierks. IETF,
        January 1999.
        [37] RFC 3325: "Private Extensions to the Session Initiation Protocol
        (SIP) for Asserted Identity within Trusted Networks "C. Jennings et
        al., IETF, November 2002.
        [38] RFC 3323: "A Privacy Mechanism for the Session Initiation
        Protocol (SIP)", by J. Peterson, IETF, Nov. 2002.
        [39] RFC 3647: "Internet X.509 Public Key Infrastructure, Certificate
        Policy and Certification Practices Framework" by S. Chokhani et al.,
        IETF, Nov. 2003
        [40] RFC 2633: "S/MIME Version 3 Message Specification" by B.
        Ramsdell, IETF, June 1999.
        [41] RFC 3711: "The Secure Real-time Transport Protocol (SRTP)" by M.
        Baugher et al., IETF March 2004.
     7.2. Informative References
        Note: The distinction between normative and informative references
        depends to some degree on the evolution of the various pertinent IETF
        standards proposals. As some of the Internet Drafts listed here
        evolve along the standards track, they may be considered normative at
        some later date. We have also listed some Internet Drafts that have
        been abandoned for various reasons, but that we believe still to
        contain valuable ideas.
        [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-
        [43] RFC 3842: "A Message Summary and Message Waiting Indication
        Event Package for the Session Initiation Protocol (SIP)", IETF,
        August 2004.
        [44] H. Schulzrinne: "The tel URI for Telephone Numbers", draft-ietf-
        iptel-rfc2806bis-09, IETF June 2004, work in progress.
        [45] S. Olson and O. Levin: "REFER extensions",draft-olson-sipping-
        refer-extensions-02,IETF July 2004, work in progress.
        [46] A. Johnston: "SIP Service Examples", draft-ietf-sipping-service-
        examples-07, IETF July 2004. Work in progress.
     Sinnreich               Expires June 16, 2005                 [Page 32]

        draft-sinnreich-sipdev-req-05.txt                      December 2004
        [47] RFC 3666: "Public Switched Telephone Network (PSTN) Call Flows"
        by A. Johnston et al. 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, work in progress.
        [50] RFC 3856: "A Presence Event Package for the Session Initiation
        Protocol" by J. Rosenberg. IETF, August 2004.
        [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] RFC 3840: "Indicating User Agent Capabilities in the Session
        Initiation Protocol (SIP)" by J. Rosenberg et al. 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] H. Schulzrinne: "Emergency Services URI for the Session
        Initiation Protocol", draft-ietf-sipping-sos-00. IETF, February 2004.
        [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. Hellstrvm and P. Jones: "RTP Payload for Text Conversation",
        draft-ietf-avt-rfc2793bis-09.txt, IETF, August 2004, work in
        [57] A. Johnston: "A Performance Report Event Package For SIP",
        draft-johnston-sipping-rtcp-summary-04, IETF, October 2004. Work in
        [58] C. Jennings: "NAT Classification Results using STUN", draft-
        jennings-midcom-stun-results-02, IETF, October 2004.
        [59] RFC 3842: "A Message Summary and Message Waiting Indication
        Event Package for the Session Initiation Protocol (SIP)" by R. Mahy.
        IETF, August 2004.
     Sinnreich               Expires June 16, 2005                 [Page 33]

        draft-sinnreich-sipdev-req-05.txt                      December 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.
        [63] J. Rosenberg: "Interactive Connectivity Establishment (ICE): A
        Methodology for Network Address Translator (NAT) Traversal for
        Multimedia Session Establishment Protocols", draft-ietf-mmusic-ice-03
        ,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] RFC 3841: "Caller Preferences for the Session Initiation
        Protocol (SIP)" by J. Rosenberg et al. IETF, August 2004.
        [66] RFC 3893: "Session Initiation Protocol (SIP) Authenticated
        Identity Body (AIB) Format" by J. Peterson. 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] RFC 2793bis: "RTP Payload for Text Conversation"   by H.
        Hellstrom and P. Jones. Internet Draft, work in progress. draft-ietf-
        avt-rfc2793bis-09.txt, IETF, August 2004.
        [71]"The Early Session Disposition Type for the Session Initiation
        Protocol (SIP)" by G. Camarillo. draft-ietf-sipping-early-
        disposition-03.txt, IETF, June 2004, work in progress.
        [72]"Symmetric RTP and RTCP Considered Helpful" by D. Wing. IETF,
        October 2004, work in progress.
        [73] "NAT Behavioral Requirements for Unicast UDP" by F. Audet and C.
        Jennings. IETF, October 2004, work in progress.
     Sinnreich               Expires June 16, 2005                 [Page 34]

        draft-sinnreich-sipdev-req-05.txt                      December 2004
     8. Author's Addresses
          Henry Sinnreich
          400 International Parkway
          Richardson, TX  75081, USA
          Email: henry.sinnreich@mci.com
          Phone : +1-972-729-4983
          Steven Lass
          1201 East Arapaho Road
          Richardson, TX 75081, USA
          Email: steven.lass@mci.com
          Phone: +1-972-728-2363
          Christian Stredicke
          snom technology AG
          Pascalstrasse 10e
          10587 Berlin, Germany
          Email: cs@snom.de
          Phone: +49(30)39833-0
     Intellectual Property Statement
        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
        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. By submitting this Internet-Draft, I certify that
        any applicable patent or other IPR claims of which I am aware have
        been disclosed, and any of which I become aware will be disclosed, in
        accordance with RFC 3668.
     Sinnreich               Expires June 16, 2005                 [Page 35]

        draft-sinnreich-sipdev-req-05.txt                      December 2004
     Disclaimer of Validity
        This document and the information contained herein are provided on an
     Copyright Statement
        Copyright (C) The Internet Society (2004). 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.
        Funding for the RFC Editor function is currently provided by the
        Internet Society.
     Sinnreich               Expires June 16, 2005                 [Page 36]

Html markup produced by rfcmarkup 1.111, available from https://tools.ietf.org/tools/rfcmarkup/