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

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

        SIPPING WG                      H. Sinnreich/pulver.com, editor
        Internet Draft                  S. Lass/MCI
                                        C. Stredicke/snom
                                        May 2005
              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.
        By submitting this Internet-Draft, each author represents that
        any applicable patent or other IPR claims of which he or she
        is aware have been or will be disclosed, and any of which he
        or she becomes aware will be disclosed, in accordance with
        Section 6 of BCP 79.
        Internet-Drafts are working documents of the Internet
        Engineering Task Force (IETF), its areas, and its working
        groups. Note that other groups may also distribute working
        documents as Internet-Drafts.
        Internet-Drafts are draft documents valid for a maximum of six
        months and may be updated, replaced, or obsoleted by other
        documents at any time. It is inappropriate to use Internet-
        Drafts as reference material or to cite them other than as
        "work in progress."
        The list of current Internet-Drafts can be accessed at
        The list of Internet-Draft Shadow Directories can be accessed
        at http://www.ietf.org/shadow.html
        This Internet-Draft will expire on November 13, 2005.
        This document describes the requirements for SIP telephony
        devices, based on the deployment experience of large numbers
        of SIP phones and PC clients using different implementations
        in various networks. The objectives of the requirements are a
        well defined set of
        interoperability and multi-vendor supported core features, so
        as to enable similar ease of purchase, installation and
        operation as found for PCs, PDAs analog feature phones or
        mobile phones.
        We present a glossary of the most common settings and some of
        the more widely used values for some settings.
                              Expires November 2005           [Page 1]

         draft-sinnreich-sipdev-req-06.txt               November 2005
        Conventions used in this document
        This document is informational and therefore the key words
        "MUST", "SHOULD", "SHOULD NOT", "MAY", in this document are
        not to be interpreted as described in RFC 2119 [2], but rather
        indicate the nature of the suggested requirement.
     Table of Contents
        1. Introduction...............................................3
        2. Generic Requirements.......................................4
           2.1. SIP Telephony Devices.................................4
           2.2. DNS and ENUM Support..................................4
           2.3. SIP Device Resident Telephony Features................5
           2.4. Support for SIP Services..............................8
           2.5. Basic Telephony and Presence Information Support......8
           2.6. Emergency and Resource Priority Support...............9
           2.7. Multi-Line Requirements..............................10
           2.8. User Mobility........................................11
           2.9. Interactive Text Support.............................11
           2.10. Other Related Protocols.............................13
           2.11. SIP Device Security Requirements....................13
           2.12. Quality of Service..................................14
           2.13. Media Requirements..................................14
           2.14. Voice Codecs........................................14
           2.15. Telephony Sound Requirements........................15
           2.16. International Requirements..........................16
           2.17. Support for Related Applications....................16
           2.18. Web Based Feature Management........................16
           2.19. Firewall and NAT Traversal..........................17
           2.20. Device Interfaces...................................18
        3. Glossary and Usage for the Configuration Settings.........18
           3.1. Device ID............................................19
           3.2. Signaling Port.......................................19
           3.3. RTP Port Range.......................................19
           3.4. Quality of Service...................................20
           3.5. Default Call Handling................................20
              3.5.1. Outbound Proxy..................................20
              3.5.2. Default Outbound Proxy..........................20
              3.5.3. SIP Session Timer...............................20
           3.6. Telephone Dialing Functions..........................21
              3.6.1. Phone Number Representations....................21
              3.6.2. Digit Maps and/or the Dial/OK Key...............21
              3.6.3. Default Digit Map...............................22
           3.7. SIP Timer Settings...................................22
           3.8. Audio Codecs.........................................22
           3.9. DTMF Method..........................................23
           3.10. Local and Regional Parameters.......................23
           3.11. Time Server.........................................23
        Expires November 13, 2005                              [Page 2]

         draft-sinnreich-sipdev-req-06.txt               November 2005
           3.12. Language............................................23
           3.13. Inbound Authentication..............................24
           3.14. Voice Message Settings..............................24
           3.15. Phonebook and Call History..........................24
           3.16. User Related Settings and Mobility..................25
           3.17. AOR Related Settings................................25
           3.18. Maximum Connections.................................26
           3.19. Automatic Configuration and Upgrade.................26
           3.20. Security Configurations.............................26
        4. Security Considerations...................................27
           4.1. Threats and Problem Statement........................27
           4.2. SIP Telephony Device Security........................28
           4.3. Privacy..............................................29
           4.4. Support for NAT and Firewall Traversal...............29
        5. IANA Considerations.......................................30
        6. Acknowledgments...........................................30
        7. Changes from Previous Versions............................31
        8. References................................................32
        9. Author's Addresses........................................38
        10. Copyright Notice.........................................38
     1. Introduction
        This document has the objective of focusing the Internet
        communications community on requirements for telephony devices
        using SIP.
        We base this information from developing and using a large
        number of SIP telephony devices in carrier and private IP
        networks and on the Internet. This deployment has shown the
        need for generic requirements for SIP telephony devices and
        also the need for some specifics that can be used in SIP
        interoperability testing.
        SIP telephony devices, also referred to as SIP User Agents
        (UAs) can be any type of IP networked computing user device
        enabled for SIP based IP telephony. SIP telephony user devices
        can be SIP phones, adaptors for analog phones and for fax
        machines, conference speakerphones, software packages (soft
        clients) running on PCs, laptops, wireless connected PDAs, 'Wi-
        Fi' SIP mobile phones, as well as other mobile and cordless
        phones that support SIP signaling for real time communications.
        SIP-PSTN gateways are not the object of this memo, since they
        are network elements and not end user devices.
        SIP telephony devices can also be instant messaging (IM)
        applications that have a telephony option.
        Expires November 13, 2005                              [Page 3]

         draft-sinnreich-sipdev-req-06.txt               November 2005
        SIP devices MAY support various other media besides voice, such
        as text, video, games and other Internet applications; however
        the non-voice requirements are not specified in this document,
        except when providing enhanced telephony features.
        SIP telephony devices are highly complex IP endpoints that
        speak many Internet protocols, have audio and visual interfaces
        and require functionality targeted at several constituencies:
        (1) End users, (2) service providers and network administrators
        and (3) manufacturers, as well as (4) system integrators.
        The objectives of the requirements are a well defined set of
        interoperability and multi-vendor supported core features, so
        as to enable similar ease of purchase, installation and
        operation as found for standard PCs, analog feature phones or
        mobile phones. Given the cost of some feature rich display
        phones may approach the cost of PCs and PDAs, similar or even
        better ease of use as compared to personal computers and
        networked PDAs is expected by both end users and network
        While the recommendations of this document go beyond what is
        currently mandated for SIP implementations within the IETF,
        this is believed necessary to support the specified operational
        objectives.  However, it is also important to keep in mind that
        the SIP specifications are constantly being evolved, thus these
        recommendations need to be considered in the context of that
        change and evolution.
     2. Generic Requirements
        We present here a minimal set of requirements that MUST be met
        by all SIP [3] telephony devices, except where SHOULD or MAY is
     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
        Expires November 13, 2005                              [Page 4]

         draft-sinnreich-sipdev-req-06.txt               November 2005
       Req-8: SIP telephony devices MUST incorporate DNS resolvers
               that are configurable with at least two entries for DNS
               servers for redundancy. To provide efficient DNS
               resolution, SIP telephony devices SHOULD query
               responsive DNS servers and skip DNS servers that have
               been non-responsive to recent queries.
       Req-9: To provide efficient DNS resolution and to limit post-
               dial delay, SIP telephony devices MUST cache DNS
               responses based on the DNS time-to-live.
       Req-10: For DNS efficiency, SIP telephony devices SHOULD use
               the additional information section of the DNS response
               instead of generating additional DNS queries.
       Req-11: SIP telephony devices MAY support ENUM [7] in case the
               end users prefer to have control over the ENUM lookup.
               Note: The ENUM resolver can also be placed in the
               outgoing SIP proxy to simplify the operation of the SIP
               telephony device.
     2.3. SIP Device Resident Telephony Features
       Req-12: SIP telephony devices MUST support RFC 3261 [3].
       Req-13: SIP telephony devices SHOULD support the SIP Privacy
               header by populating headers with values that reflect
               the privacy requirements and preferences as described in
               "Section 4 User Agent Behavior" in RFC 3323 [8].
       Req-14: SIP telephony devices MUST be able to place an existing
               call on hold, and initiate or receive another call, as
               specified in RFC 3264 [12] and SHOULD NOT omit the
               sendrecv attribute.
       Req-15: SIP telephony devices MUST provide a call waiting
               indicator. When participating in a call, the user MUST
               be alerted audibly and/or visually of another incoming
               call. The user MUST be able to enable/disable the call
               waiting indicator.
        Expires November 13, 2005                              [Page 5]

         draft-sinnreich-sipdev-req-06.txt               November 2005
       Req-16: SIP telephony devices MUST support SIP message waiting
               [43] and the integration with message store platforms.
       Req-17: SIP telephony devices MAY support a local dial plan. If
               a dial plan is supported, it MUST consist of a pattern
               string to match dial digits, and the ability to strip
               and also append prefix digits, and also append suffix
       Req-18: SIP telephony devices MUST support the URIs for
               Telephone numbers as per RFC 3966 [9].
       Req-19: SIP telephony devices MUST support REFER and NOTIFY as
               required to support call transfer [45], [46]. SIP
               telephony devices MUST support escaped headers in the
               Refer-To header.
       Req-20: SIP telephony devices MUST support the unattended call
               transfer flows as defined in [46].
       Req-21: SIP telephony devices MUST support attended call
               transfer as defined in [46].
       Req-22: SIP telephony devices MAY support device based 3-way
               calling by mixing the audio streams and displaying the
               interactive text of at least 2 separate calls.
       Req-23: SIP telephony devices MUST be able to send DTMF named
               telephone events as specified by RFC 2833 [11].
       Req-24: Payload type negotiation MUST comply with RFC 3264 [12]
               and with the registered MIME types for RTP payload
               formats in RFC 3555 [13].
       Req-25: The dynamic payload type MUST remain constant
               throughout the session. For example, if an endpoint
               decides to renegotiate codecs or put the call on hold,
               the payload type for the re-invite MUST be the same as
               the initial payload type. SIP devices MAY support Flow
               Identification as defined in RFC 3388 [14].
        Expires November 13, 2005                              [Page 6]

         draft-sinnreich-sipdev-req-06.txt               November 2005
       Req-26: SIP telephony devices MUST generate local ringing and
               SHOULD ignore any early RTP media when a "180 Ringing"
               response is received. Any received media that is not
               early media (i.e., not received within the context of an
               early session, as specified in [71] should be rendered
               as soon as it arrives in order to avoid speech clipping.
               SIP telephony devices MUST play the RTP stream for the
               established dialog and ignore any other RTP media
               streams when a "183 Session Progress" response is
       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
       Req-31: SIP telephony devices MAY ring after a call has been on
               hold for a predetermined period of time, typically 3
        Expires November 13, 2005                              [Page 7]

         draft-sinnreich-sipdev-req-06.txt               November 2005
     2.4. Support for SIP Services
       Req-32: SIP telephony devices MUST support the SIP Basic Call
               Flow Examples [47].
       Req-33: SIP telephony devices MUST support the SIP-PSTN Service
               Examples as per RFC 3666 [16].
       Req-34: SIP telephony devices MUST support the Third Party Call
               Control model [17], in the sense that they may be the
               controlled device.
       Req-35: SIP telephony devices SHOULD support SIP call control
               and multiparty usage [42].
       Req-36: SIP telephony devices SHOULD support conferencing
               services for voice [48], [49] and interactive text [56]
               and if equipped with an adequate display MAY also
               support instant messaging (IM) and presence [50], [59].
       Req-37: SIP telephony devices SHOULD support the indication of
               the User Agent Capabilities and MUST support the caller
               capabilities and preferences as per RFC 3840 [52].
       Req-38: SIP telephony devices MAY support service mobility:
               Devices MAY allow roaming users to input their identity
               so as to have access to their services and preferences
               from the home SIP server. Examples of user data to be
               available for roaming users are: User service ID, the
               dialing plan, personal directory and caller preferences.
     2.5. Basic Telephony and Presence Information Support
        The large color displays in some newer models make such SIP
        phones and applications attractive for a rich communication
        environment. This document is focused however only on telephony
        specific features enabled by SIP Presence and SIP Events.
        SIP telephony devices can also support for example presence
        status, such as the traditional Do Not Disturb, new event state
        based information, such as being in another call or being in a
        conference, typing a message, emoticons, etc. Some SIP
        Expires November 13, 2005                              [Page 8]

         draft-sinnreich-sipdev-req-06.txt               November 2005
        telephony User Agents can support for example a voice session
        and several IM sessions with different parties.
       Req-39: SIP telephony devices SHOULD support Presence
               information [50] and SHOULD support the Rich Presence
               Information Data Format [51] for the new IP
               communication services enabled by Presence.
       Req-40: Users MUST be able to set the state of the SIP
               telephony device to "Do Not Disturb", and this MAY be
               manifested as a Presence state across the network if the
               UA can support Presence information
       Req-41: SIP telephony devices with "Do Not Disturb" enabled
               MUST respond to new sessions with "486 Busy Here".
     2.6. Emergency and Resource Priority Support
       Req-42: Emergency calling: For emergency numbers (e.g. 911, SOS
               URL), SIP telephony devices SHOULD support the work of
               the ECRIT WG [54].
       Req-43: Priority header: SIP devices SHOULD support the setting
               by the user of the Priority header specified in RFC 3261
               for such applications as emergency calls or for
               selective call acceptance.
       Req-44: Resource Priority header: SIP telephony devices that
               are used in environments that support emergency
               preparedness MUST also support the sending and receiving
               of the Resource-Priority header as specified in [55].
               The Resource Priority header influences the behavior for
               message routing in SIP proxies and PSTN telephony
               gateways and is different from the SIP Priority header
               specified in RFC 3261. Users of SIP telephony devices
               may want to be interrupted in their lower-priority
               communications activities if such an emergency
               communication request arrives.
       Note: As of this writing we recommend implementers to follow
       the work of the Working Group on Emergency Context Resolution
        Expires November 13, 2005                              [Page 9]

         draft-sinnreich-sipdev-req-06.txt               November 2005
       with Internet Technologies (ecrit) in the IETF. The complete
       solution is for further study at this time. There is also work
       on the requirements for location conveyance in the SIPPING WG,
       see [77].
     2.7. Multi-Line Requirements
        A SIP telephony device can have multiple lines: One SIP
        telephony device can be registered simultaneously with
        different SIP registrars from different service providers,
        using different names and credentials for each line. The
        different sets of names and credentials are also called 'SIP
        accounts'. The "line" terminology has been borrowed from multi-
        line PSTN/PBX phones, except that for SIP telephony devices
        there can be different SIP registrar/proxies for each line,
        each of which may belong to a different service provider,
        whereas this would be an exceptional case for the PSTN and
        certainly not the case for PBX phones. Multi-line SIP telephony
        devices resemble more closely e-mail clients that can support
        several e-mail accounts.
        Note: Each SIP account can usually support different Addresses
        of Record (AOR) with a different list of contact addresses
        (CA), as may be convenient for example when having different
        SIP accounts for business and for the private life.
        Some of the CAs in different SIP accounts may though point to
        the same devices.
       Req-45: Multi-line SIP telephony devices MUST support a unique
               authentication username, authentication password,
               registrar, and identity to be provisioned for each line.
               The authentication username MAY be identical with the
               user name of the AOR and the domain name MAY be
               identical with the host name of the registrar.
       Req-46: Multi-line SIP telephony devices MUST be able to
               support the state of the client to Do Not Disturb on a
               per line basis.
       Req-47: Multi-line SIP telephony devices MUST support multi-
               line call waiting indicators. Devices MUST allow the
               call waiting indicator to be set on a per "line" basis.
       Req-48: Multi-line SIP telephony devices MUST be able to
               support a few different ring tones for different lines.
       Expires November 13, 2005                              [Page 10]

         draft-sinnreich-sipdev-req-06.txt               November 2005
               We specify here "a few", since provisioning different
               tones for all lines may be difficult for phones with
               many lines.
     2.8.  User Mobility
       The following requirements allow users with a set of
       credentials to use any SIP telephony device that can support
       personal credentials from several users, distinct from the
       identity of the device.
       Req-49: User mobility enabled SIP telephony devices MUST store
               static credentials associated with the device in non-
               volatile memory. This static profile is used during the
               power up sequence.
       Req-50: User mobility enabled SIP telephony devices SHOULD
               allow a user to walk up to a device and input their
               personal credentials. All user features and settings
               stored in SIP proxy and the associated policy server
               SHOULD be available to the user.
       Req-51: User mobility enabled SIP telephony devices registered
               as fixed desktop with network administrator MUST use the
               local static location data associated with the device
               for emergency calls.
      2.9. Interactive Text Support
        SIP telephony devices supporting Instant Messaging based on
        SIMPLE [50] support text conversation based on blocks of text.
        However, continuous interactive text conversation may be
        sometimes preferred as a parallel to voice, due to its
        interactive and more streaming-like nature, thus more
        appropriate for real time conversation. It also allows for text
        captioning of voice for noisy environments and those who cannot
        hear well or cannot hear at all.
        Finally continuous, character by character text is what is
        preferred by emergency and public safety programs (e.g. 112 and
        911) because of its immediacy, efficiency, lack of crossed
        messages problem, better ability to interact with a confused
        person, and the additional information that can be observed
        from watching the message as it is composed.
       Expires November 13, 2005                              [Page 11]

         draft-sinnreich-sipdev-req-06.txt               November 2005
        Req-52: SIP telephony devices such as SIP display phones and
               IP-analog adapters SHOULD support the accessibility for
               user requirements for the deaf, hard of hearing and
               speech impaired individuals as per RCF 3351 [18] and
               also for interactive text conversation [56], [70].
        Req-53: SIP telephony devices SHOULD provide a way to input
               text and to display text through any reasonable method.
               Built-in user interfaces, standard wired or wireless
               interfaces, and/or support for text through a web
               interface are all considered reasonable mechanisms.
        Req-54: SIP telephony devices SHOULD provide an external
               standard wired or wireless link to connect external
               input (keyboard, mouse) and display devices.
        Req-55: SIP telephony devices which include a display, or have
               a facility for connecting an external display, MUST
               include protocol support as described in RFC 2793 for
               real-time interactive text.
        Req-56: There may be value of having RFC 2793 support in a
               terminal also without a visual display. A synthetic
               voice output for the text conversation may be of value
               for all who can hear, and thereby having the opportunity
               to have a text conversation with other users.
        Req-57: SIP telephony devices MAY provide analog adaptor
               functionality through an RJ-11 FXO port to support FXS
               devices. If an RJ-11 (FXO) port is provided, then it MAY
               support a gateway function from all text-telephone
               protocols according to ITU-T Recommendation V.18 to RFC
               2793 text conversation (in fact this is encouraged in
               the near term during the transition to widespread use of
               SIP telephony devices). If this gateway function is not
               included or fails, the device MUST pass-through all
               text-telephone protocols according to ITU-T
               Recommendation V.18, November 2000, in a transparent
       Expires November 13, 2005                              [Page 12]

         draft-sinnreich-sipdev-req-06.txt               November 2005
        Req-58: SIP telephony devices MAY provide a 2.5 mm audio port,
               in portable SIP devices, such as PDA"s and various
               wireless SIP phones.
     2.10. Other Related Protocols
       Req-59: SIP telephony devices MUST support the Real-Time
               Protocol and the Real-Time Control Protocol, RFC 3550
               [20]. SIP devices SHOULD use RTCP Extended Reports for
               logging and reporting on network support for voice
               quality, RFC 2611 [21] and MAY also support the RTCP
               summary report delivery [57].
     2.11. SIP Device Security Requirements
       Req-60: SIP telephony devices MUST support digest
               authentication as per RFC3261. In addition, SIP
               telephony devices MUST support TLS for secure transport
               [36] for scenarios where the SIP registrar is located
               outside the secure, private IP network in which the SIP
               UA may reside. Note: TLS need not be used in every call
       Req-61: SIP telephony devices MUST be able to password protect
               configuration information and administrative functions.
       Req-62: SIP telephony devices MUST NOT display the password to
               the user or administrator after it has been entered.
       Req-63: SIP clients MUST be able to disable remote access, i.e.
               block incoming SNMP (where this is supported), HTTP, and
               other services not necessary for basic operation.
       Req-64: SIP telephony devices MUST support the option to reject
               an incoming INVITE where the user-portion of the SIP
               request URI is blank or does not match a provisioned
               contact. This provides protection against war-dialer
               attacks, unwanted telemarketing and spam. The setting to
               accept/reject MUST be configurable.
       Expires November 13, 2005                              [Page 13]

         draft-sinnreich-sipdev-req-06.txt               November 2005
       Req-65: When TLS is not used, SIP telephony devices MUST be
               able to reject an incoming INVITE when the message does
               not come from the proxy or proxies where the client is
               registered. This prevents callers from bypassing
               terminating call features on the proxy. For DNS SRV
               specified proxy addresses, the client must accept an
               INVITE from all of the resolved proxy IP addresses.
     2.12. Quality of Service
       Req-66: SIP devices MUST support the IPv4 DSCP field for RTP
               streams as per RFC 2597 [22]. The DSCP setting MUST be
               configurable to conform with the local network policy.
       Req-67: If not specifically provisioned, SIP telephony devices
               SHOULD mark RTP packets with the recommended DSCP for
               expedited forwarding (codepoint 101110); and mark SIP
               packets with DSCP AF31 (codepoint 011010).
       Req-68: SIP telephony devices MAY support RSVP [23].
     2.13. Media Requirements
       Req-69: To simplify the interoperability issues, SIP telephony
               devices MUST use the first matching codec listed by the
               receiver if the requested codec is available in the
               called device. See the offer/answer model in RFC 3261.
       Req-70: To reduce overall bandwidth, SIP telephony devices MAY
               support active voice detection and comfort noise
     2.14. Voice Codecs
        Internet telephony devices face the problem of supporting
        multiple codecs due to various historic reasons, on how telecom
        industry players have approached codec implementations and the
        serious intellectual property and licensing problems associated
        with most codec types.
        RFC 3551 [24] lists 17 registered MIME subtypes for audio
        codecs. This memo however requires the support of a minimal
        number of codecs used in wireline VoIP, and also codecs found
        in mobile phones.
       Expires November 13, 2005                              [Page 14]

         draft-sinnreich-sipdev-req-06.txt               November 2005
       Req-71: SIP telephony devices SHOULD support AVT payload type 0
               (G.711 uLaw) as in reference [25] and its Annexes 1 and
       Req-72: SIP telephony devices SHOULD support the Internet Low
               Bit Rate codec (iLBC) [26], [27].
       Req-73: Mobile SIP telephony devices MAY support codecs found
               in various 3G wireless mobile phones. This can avoid
               codec conversion in network based intermediaries.
       Req-74: SIP telephony devices MAY support a small set of
               special purpose codecs, such as G.723.1, where low
               bandwidth is needed (for dial-up Internet access) or
               G.722 for high quality audio conferences.
       Req-75: SIP telephony devices MAY support G.729 and its
               Note: The authors believe the Internet Low Bit Rate
               codec (iLBC) should be the default codec for Internet
              A summary count reveals up to 25 and more voice codec
               types currently in use. The authors believe there is
               also a need for a single multi-rate Internet codec, such
               as Speex [28] or similar that can effectively be
               substituted for all of the multiple legacy G.7xx codec
               types, such as G. 711, G.729, G.723.1, G.722, etc. for
               various data rates, thus avoiding the complexity and
               cost to implementers and service providers alike who are
               burdened by supporting so many codec types, besides the
               burden of the additional licensing costs.
     2.15. Telephony Sound Requirements
       Req-76: SIP telephony devices SHOULD comply with the handset
               receive comfort noise requirements outlined in the ANSI
               standards [29], [30].
       Req-77: SIP telephony devices SHOULD comply with the stability
               or minimum loss defined in ITU-T G.177 [31].
       Expires November 13, 2005                              [Page 15]

         draft-sinnreich-sipdev-req-06.txt               November 2005
       Req-78: SIP telephony devices MAY provide a full-duplex
               speakerphone with echo and side tone cancellation. The
               design of high quality side tone cancellation for
               desktop IP phones, laptop computers and PDAs is outside
               the scope of this memo.
       Req-79: SIP telephony device MAY support different ring-tones
               based on the caller identity.
     2.16. International Requirements
       Req-80: SIP telephony devices SHOULD indicate the preferred
               language [34] using User Agent Capabilities [52].
       Req-81: SIP telephony devices intended to be used in various
               language settings [34], MUST support other languages for
               menus, help, and labels.
     2.17. Support for Related Applications
        The following requirements apply to functions placed in the SIP
        telephony device.
       Req-82: SIP telephony devices that have a large display and
                support presence SHOULD display a buddy list [50].
       Req-83: SIP telephony devices MAY support LDAP for client-based
                directory lookup.
       Req-84: SIP telephony devices MAY support a phone setup where a
                URL is automatically dialed when the phone goes off-
     2.18. Web Based Feature Management
       Req-85: SIP telephony devices SHOULD support an internal web
                server to allow users the option to manually configure
                the phone and to set up personal phone applications
                such as the address book, speed-dial, ring tones, and
                last but not least the call handling options for the
                various lines, aliases, in a user friendly fashion. Web
                pages to manage the SIP telephony device SHOULD be
       Expires November 13, 2005                              [Page 16]

         draft-sinnreich-sipdev-req-06.txt               November 2005
                supported by the individual device, or MAY be supported
                in managed networks from centralized web servers.
                Managing SIP telephony devices SHOULD NOT require
                special client software on the PC or require a
                dedicated management console. SIP telephony devices
                SHOULD support https transport for this purpose.
                In addition to the Web Based Feature Management
                Requirement the device MAY have an SNMP interface for
                monitoring and management purposes.
     2.19. Firewall and NAT Traversal
        The following requirements allow SIP clients to properly
        function behind various firewall architectures.
       Req-86: SIP telephony devices SHOULD be able to operate behind
               a static NAPT (Network Address Translation/Port Address
               Translation) device. This implies the SIP telephony
               device SHOULD be able to 1) populate SIP messages with
               the public, external address of the NAPT device, 2) use
               symmetric UDP or TCP for signaling, and 3) Use symmetric
               RTP [72].
       Req-87: SIP telephony devices SHOULD support the STUN protocol
               [32] for determining the NAPT public external address. A
               classification of scenarios and NATs where STUN is
               effective is reported in [58]. Detailed call flows for
               interactive connectivity establishment (ICE) are given
               in [76].
               Note: Developers are strongly advised to follow the
               document on best current practices for NAT traversal for
               SIP [63].
       Req-88: SIP telephony devices MAY support UPnP
               (http://www.upnp.org/) for local NAPT traversal. Note
               that UPnP does not help if there are NAPT in the network
               of the services provider.
       Req-89: SIP telephony devices MUST be able to limit the ports
               used for RTP to a provisioned range.
       Expires November 13, 2005                              [Page 17]

         draft-sinnreich-sipdev-req-06.txt               November 2005
     2.20. Device Interfaces
       Req-90: SIP telephony devices MUST have two types of interface
                capabilities, for both phone numbers and URIs, both
                accessible to the end user.
       Req-91: SIP telephony devices MUST have a telephony-like dial-
                pad and MAY have telephony style buttons like mute,
                redial, transfer, conference, hold, etc. The
                traditional telephony dial-pad interface MAY appear as
                an option in large screen telephony devices using other
                interface models, such as Push-To-Talk in mobile phones
                and the Presence and IM GUI found in PC"s, PDA"s and
                mobile phones and wireless phones.
       Req-92: SIP telephony devices MUST have a convenient way for
                entering SIP URIs and phone numbers. This includes all
                alphanumeric characters allowed in legal SIP URIs.
                Possible approaches include using a web page, display
                and keyboard entry, type-ahead or graffiti for PDAs.
       Req-93: SIP telephony devices should allow phone number entry
                in human friendly fashion, with the usual separators
                and brackets between digits and digit groups.
     3. Glossary and Usage for the Configuration Settings
       SIP telephony devices are quite complex and their configuration
       is made more difficult by the widely diverse use of technical
       terms for the settings. We present here a glossary of the most
       common settings and some of the more widely used values for
       some settings.
       Settings are the information on a SIP UA that it needs so as to
       be a functional SIP endpoint. The settings defined in this
       document are not intended to be a complete listing of all
       possible settings. It MUST be possible to add vendor specific
       The list of available settings includes settings that MUST,
       SHOULD or MAY be used by all devices (when present) and that
       make up the common denominator that is used and understood by
       all devices. However, the list is open to vendor specific
       extensions that support additional settings, which enable a
       rich and valuable set of features.
       Expires November 13, 2005                              [Page 18]

         draft-sinnreich-sipdev-req-06.txt               November 2005
       Settings MAY be read-only on the device. This avoids the
       misconfiguration of important settings by inexperienced users
       generating service cost for operators. The settings
       provisioning process SHOULD indicate which settings can be
       changed by the end-user and which settings should be protected.
       In order to achieve wide adoption of any settings format it is
       important that it should not be excessive in size for modest
       devices to use it. Any format SHOULD be structured enough to
       allow flexible extensions to it by vendors.
       Settings may belong to the device or to a SIP service provider
       and the address of record (AOR) registered there. When the
       device acts in the context of an AOR, it will first try to look
       up a setting in the AOR context. If the setting can not be
       found in that context, the device will try to find the setting
       in the device context. If that also fails, the device MAY use a
       default value for the setting.
       The examples shown here are just of informational nature. Other
       documents may specify the syntax and semantics for the
       respective settings.
     3.1. Device ID
               A device setting MAY include some unique identifier for
               the device it represents. This MAY be an arbitrary
               device name chosen by the user, the MAC address, some
               manufacturer serial number or some other unique piece of
               data. The Device ID SHOULD also indicate the ID type.
               Example: DeviceId="000413100A10;type=MAC"
     3.2. Signaling Port
               The port that MUST be used for a specific transport
               protocol for SIP MUST be indicated with the SIP ports
               setting. If this setting is omitted, the device MAY
               choose any port. For UDP, the port must also be used for
               sending requests so that NAT devices will be able to
               route the responses back to the UA.
               Example: SIPPort="5060;transport=UDP"
     3.3. RTP Port Range
               A range of port numbers MUST be used by a device for the
               consecutive pairs of ports which MUST be used to receive
               audio and control information (RTP and RTCP) for each
               concurrent connection. Sometimes this is required to
               support firewall traversal and it helps network
               operators to identify voice packets.
               Example: RTPPorts="50000-51000"
       Expires November 13, 2005                              [Page 19]

         draft-sinnreich-sipdev-req-06.txt               November 2005
     3.4. Quality of Service
               The QoS settings for outbound packets SHOULD be
               configurable for network packets associated with call
               signaling (SIP) and media transport (RTP/RTCP). These
               settings help network operators identifying voice
               packets in their network and allow them to transport
               them with the required QoS. The settings are
               independently configurable for the different transport
               layers and signaling, media or administration. The QoS
               settings SHOULD also include the QoS mechanism.
               For both categories of network traffic, the device
               SHOULD permit configuration of the type of service
               settings for both layer 3 (IP DiffServ) and layer 2 (for
               example IEEE 802.1D/Q) of the network protocol stack.
               Example: RTPQoS="0xA0;type=DiffSrv,
     3.5. Default Call Handling
               All of the call handling settings defined below can be
               defined here as default behaviors.
     3.5.1. Outbound Proxy
               The outbound proxy for a device MAY be set. The setting
               MAY require that all signaling packets MUST be sent to
               the outbound proxy or that only in the case when no
               route has been received the outbound proxy MUST be used.
               This ensures that application layer gateways are in the
               signaling path. The second requirement allows the
               optimization of the routing by the outbound proxy.
               Example: OutboundProxy="sip:nat.proxy.com"
     3.5.2. Default Outbound Proxy
               The default outbound proxy SHOULD be a global setting
               (not related to a specific line).
               Example: DefaultProxy="sip:123@proxy.com"
     3.5.3. SIP Session Timer
               The re-invite timer allows user agents to detect broken
               sessions caused by network failures. A value indicating
               the number of seconds for the next re-invite SHOULD be
               used if provided.
               Example: SessionTimer="600;unit=seconds"
       Expires November 13, 2005                              [Page 20]

         draft-sinnreich-sipdev-req-06.txt               November 2005
     3.6. Telephone Dialing Functions
               As most telephone users are used to dialing digits to
               indicate the address of the destination, there is a need
               for specifying the rule by which digits are transformed
               into a URI (usually SIP URI or TEL URI).
     3.6.1. Phone Number Representations
               SIP phones need to understand entries in the phone book
               of the most common separators used between dialed
               digits, such as spaces, angle and round brackets, dashes
               and dots.
               Example: A phonebook entry of "+49(30)398.33-401" should
               be translated into "+493039833401".
     3.6.2. Digit Maps and/or the Dial/OK Key
               A SIP UA needs to translate user input before it can
               generate a valid request. Digit maps are settings that
               describe the parameters of this process.
               If present, digit maps define patterns that when matched
               1) A rule by which the end point can judge that the user
               has completed dialing, and
               2) A rule to construct a URI from the dialed digits, and
               3) An outbound proxy to be used in routing the SIP
               A critical timer MAY be provided which determines how
               long the device SHOULD wait before dialing if a dial
               plan contains a T (Timer) character. It MAY also provide
               a timer for the maximum elapsed time which SHOULD pass
               before dialing if the digits entered by the user match
               no dial plan. If the UA has a Dial or Ok key, pressing
               this key will override the timer setting.
               SIP telephony devices SHOULD have a Dial/OK key.
               After sending a request, UA SHOULD be prepared to
               receive a 484 Address Incomplete response. In this case,
               the user agent should accept more user input and try
               again to dial the number.
               An example digit map could use regular expressions like
               in DNS NAPTR (RFC2915) to translate user input into a
               SIP URL. Additional replacement patterns like "d" could
               insert the domain name of the used AOR. Additional
               parameters could be inserted in the flags portion of the
       Expires November 13, 2005                              [Page 21]

         draft-sinnreich-sipdev-req-06.txt               November 2005
               substitution expression. A list of those patterns would
               make up the dial plan:
     3.6.3. Default Digit Map
               The SIP telephony device SHOULD support the
               configuration of a default digit map. If the SIP
               telephony device does not support digit maps, it SHOULD
               at least support a default digit map rule to construct a
               URI from digits. If the end point does support digit
               maps, this rule applies if none of the digit maps match.
               For example, when a user enters "12345", the UA might
               send the request to "sip:12345@proxy.com;user=phone"
               after the user presses the OK key.
     3.7. SIP Timer Settings
               The parameters for SIP (like timer T1) and other related
               settings MAY be indicated. An example of usage would be
               the reduction of the DNS SRV failover time.
               Example: SIPTimer="t1=100;unit=ms"
               Note: The timer settings can be included in the digit
     3.8. Audio Codecs
               In some cases operators want to control which codecs MAY
               be used in their network. The desired subset of codecs
               supported by the device SHOULD be configurable along
               with the order of preference. Service providers SHOULD
               have the possibility of plugging in their own codecs of
               choice. The codec settings MAY include the packet length
               and other parameters like silence suppression or comfort
               noise generation.
               The set of available codecs will be used in the codec
               negotiation according to RFC 3264 [12].
               Example: Codecs="speex/8000;ptime=20;cng=on,
               The settings MUST include hints about privacy for audio
               using SRTP that either mandate or encourage the usage of
               secure RTP.
               Example: SRTP="mandatory"
       Expires November 13, 2005                              [Page 22]

         draft-sinnreich-sipdev-req-06.txt               November 2005
     3.9. DTMF Method
               Keyboard interaction can be indicated with in-band tones
               or preferable with out-of-band RTP packets (RFC 2833)
               [11]. The method for sending these events SHOULD be
               configurable with the order of precedence. Settings MAY
               include additional parameters like the content-type that
               should be used.
               Example: DTMFMethod="INFO;type=application/dtmf,
               RFC2833", [11].
     3.10. Local and Regional Parameters
               Certain settings are dependent upon the regional
               location for the daylight saving time rules and for the
               time zone.
               Time Zone and UTC Offset: A time zone MAY be specified
               for the user. Where one is specified; it SHOULD use the
               schema used by the Olson Time One database [33].
               Examples of the database naming scheme are Asia/Dubai or
               America/Los Angeles where the first part of the name is
               the continent or ocean and the second part is normally
               the largest city on that time-zone. Optional parameters
               like the UTC offset may provide additional information
               for UA that are not able to map the time zone
               information to a internal database.
               Example: TimeZone="Asia/Dubai;offset=7200"
     3.11. Time Server
               A time server SHOULD be used. DHCP is the preferred way
               to provide this setting. Optional parameters may
               indicate the protocol that SHOULD be used for
               determining the time. If present, the DHCP time server
               setting has higher precedence than the time server
               Example: TimeServer=";protocol=NTP"
     3.12. Language
               Setting the correct language is important for simple
               installation around the globe.
               A language Setting SHOULD be specified for the whole
               device. Where it is specified it MUST use the codes
               defined in RFC 3066 [34] to provide some predictability.
               Example: Language="de"
               It is recommended to set the Language as writable, so
               that the user MAY change this. This setting SHOULD NOT
               be AOR related.
       Expires November 13, 2005                              [Page 23]

         draft-sinnreich-sipdev-req-06.txt               November 2005
               A SIP UA MUST be able to parse and accept requests
               containing international characters encoded as UTF-8
               even if it cannot display those characters in the user
     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
               A device SHOULD support the setting as to whether
               authentication (on the device) is required and what type
               of authentication is required.
               Example: InboundAuthentication="digest;pattern=*"
               If inbound authentication is enabled then a list of
               allowed users and credentials to call this device MAY be
               used by the device. The credentials MAY contain the same
               data as the credentials for an AOR (i.e. URL, user,
               password digest and domain). This applies to SIP control
               signaling as well as call initiation.
     3.14. Voice Message Settings
               Various voice message settings require the use of URI's
               as specified in RFC 3087 [35].
               The message waiting indicator (MWI) address setting
               controls where the client SHOULD SUBSCRIBE to a voice
               message server and what MWI summaries MAY be displayed
               Example: MWISubscribe="sip:mailbox01@media.proxy.com"
               User Agents SHOULD accept MWI information carried by SIP
               MESSAGE without prior subscription. This way the setup
               of voice message settings can be avoided.
     3.15. Phonebook and Call History
               UA SHOULD have a phonebook and keep a history of recent
               calls. The phonebook SHOULD save the information in
               permanent memory that keeps the information even after
               restarting the device or save the information in an
               external database that permanently stores the
       Expires November 13, 2005                              [Page 24]

         draft-sinnreich-sipdev-req-06.txt               November 2005
     3.16. User Related Settings and Mobility
               A device MAY specify the user which is currently
               registered on the device. This SHOULD be an address-of-
               record URL specified in an AOR definition.
               The purpose of specifying which user is currently
               assigned to this device is to provide the device with
               the identity of the user whose settings are defined in
               the user section. This is primarily interesting with
               regards to user roaming. Devices MAY allow users to
               sign-on to them and then request that their particular
               settings be retrieved. Likewise a user MAY stop using a
               device and want to disable their AOR while not present.
               For the device to understand what to do it MUST have
               some way of identifying users and knowing which user is
               currently using it. By separating the user and device
               properties it becomes clear what the user wishes to
               enable or to disable.
               Providing an identifier in the configuration for the
               user gives an explicit handle for the user. For this to
               work the device MUST have some way of identifying users
               and knowing which user is currently assigned to it.
               One possible scenario for roaming is an agent who has
               definitions for several AOR (e.g. one or more personal
               AOR and one for each executive for whom the
               administrator takes calls) that they are registered for.
               If the agent goes to the copy room they would sign-on to
               a device in that room and their user settings including
               their AOR would roam with them. The alternative to this
               is to require the agent to individually configure all of
               the AORs individually (this would be particularly
               irksome using standard telephone button entry).
               The management of user profiles, aggregation of user or
               device AOR and profile information from multiple
               management sources are configuration server concerns
               which are out of the scope of this document. However the
               ability to uniquely identify the device and user within
               the configuration data enables easier server based as
               well as local (i.e. on the device) configuration
               management of the configuration data.
     3.17. AOR Related Settings
               SIP telephony devices MUST use the Address of Record
               (AOR) related settings, as specified here.
               There are many properties which MAY be associated with
               or SHOULD be applied to the AOR or signaling addressed
               to or from the AOR. AORs MAY be defined for a device or
               a user of the device. At least one AOR MUST be defined
       Expires November 13, 2005                              [Page 25]

         draft-sinnreich-sipdev-req-06.txt               November 2005
               in the settings, this MAY pertain to either the device
               itself or the user.
               Example: AOR="sip:12345@proxy.com"
               It MUST be possible to specify at least one set of
               domain, user name and authentication credentials for
               each AOR. The user name and authentication credentials
               are used for authentication challenges.
     3.18. Maximum Connections
               A setting defining the maximum number of simultaneous
               connections that a device can support MUST be used by
               the device. The end point might have some maximum limit,
               most likely determined by the media handling capability.
               The number of simultaneous connections may be also
               limited by the access bandwidth, such as of DSL, cable
               and wireless users. Other optional settings MAY include
               the enabling or disabling of call waiting indication.
               A SIP telephony device MAY support at least two
               connections for three-way conference calls that are
               locally hosted.
               Example: MaximumConnections="2;cwi=false;bw=128". See
               the recent work on connection reuse [74] and the
               guidelines for connection oriented transport for SIP
     3.19. Automatic Configuration and Upgrade
               Automatic SIP telephony device configuration SHOULD use
               the processes and requirements described in [60].
               The user name or the realm in the domain name SHOULD be
               used by the configuration server to automatically
               configure the device for individual or group specific
               settings, without any settings by the user.
               Image and service data upgrades SHOULD also not require
               any settings by the user.
     3.20. Security Configurations
               The device configuration usually contains sensitive
               information that MUST be protected. Examples include
               authentication information, private address books and
               call history entries. Because of this, it is RECOMMENDED
               to use an encrypted transport mechanism for
               configuration data. Where devices use HTTP this could be
               TLS [36].
               For devices which use FTP or TFTP for content delivery
               this can be achieved using symmetric key encryption.
               Access to retrieving configuration information is also
               an important issue. A configuration server SHOULD
       Expires November 13, 2005                              [Page 26]

         draft-sinnreich-sipdev-req-06.txt               November 2005
               challenge a subscriber before sending configuration
               The configuration server SHOULD NOT include passwords
               through the automatic configuration process. Users
               SHOULD enter the passwords locally.
     4. Security Considerations
     4.1. Threats and Problem Statement
        While section 2.11  states the minimal security requirements
        and NAT/firewall traversal that have to be met respectively by
        SIP telephony devices, developers and network managers have to
        be aware of the larger context of security for IP telephony,
        especially for those scenarios where security may reside in
        other parts of SIP enabled networks.
        Users of SIP telephony devices are exposed to many threats [61]
        that include but are not limited to fake identity of callers,
        telemarketing, spam in IM, hijacking of calls, eavesdropping,
        learning of private information such as the personal phone
        directory, user accounts and passwords and the personal calling
        history. Various DOS attacks are possible, such as hanging up
        on other people"s conversations or contributing to DOS attacks
        of others.
        Service providers are also exposed to many types of attacks
        that include but are not limited to theft of service by users
        with fake identities, DOS attacks and the liabilities due to
        theft of private customer data and eavesdropping in which
        poorly secured SIP telephony devices or especially
        intermediaries such as stateful back-to-back user agents with
        media (B2BUA) may be implicated.
        SIP security is a hard problem for several reasons:
          . Peers can communicate across domains without any pre-
             arranged trust relationship,
          . There may be many intermediaries in the signaling path,
          . Multiple endpoints can be involved in such telephony
             operations as forwarding, forking, transfer or
          . There are seemingly conflicting service requirements when
             supporting anonymity, legal intercept, call trace and
          . 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 to the corporate network when working from home or on
        travel. There are different security scenarios for each. The
       Expires November 13, 2005                              [Page 27]

         draft-sinnreich-sipdev-req-06.txt               November 2005
        security expectations are also very different, say within an
        enterprise network or when using a laptop in a public wireless
        hotspot and it is beyond the scope of this memo to describe all
        possible scenarios in detail.
        The authors believe that adequate security for SIP telephony
        devices can be best implemented within protected networks, be
        they private IP networks or service provider SIP enabled
        networks where a large part of the security threats listed here
        are dealt with in the protected network. A more general
        security discussion that includes network based security
        features, such as network based assertion of identity [37] and
        privacy services [38] are outside the scope of this memo, but
        must be well understood by developers, network managers and
        service providers.
        In the following some basic security considerations as
        specified in RFC 3261 are discussed as they apply for SIP
        telephony devices.
     4.2. SIP Telephony Device Security
        Transport Level Security
               SIP telephony devices that operate outside the perimeter
               of secure private IP networks (this includes
               telecommuters and roaming users) MUST use TLS [36] to
               the outgoing SIP proxy for protection on the first hop.
               SIP telephony devices that use TLS must support SIPS in
               the SIP headers.
               Supporting large numbers of TLS channels to endpoints is
               quite a burden for service providers and may therefore
               constitute a premium service feature.
        Digest Authentication
               SIP telephony devices MUST support digest authentication
               to register with the outgoing SIP registrar. This
               assures proper identity credentials that can be conveyed
               by the network to the called party. It is assumed that
               the service provider that operates the outgoing SIP
               registrar has an adequate trust relationship with their
               users and knows its customers well enough (identity,
               address, billing relationship, etc.). The exceptions are
               users of prepaid service. SIP telephony devices that
               accept prepaid calls MUST place "unknown" in the "From"
        End User Certificates
               SIP telephony devices MAY store personal end user
               certificates that are part of some PKI [39] service for
               high security identification to the outgoing SIP
               registrar as well as for end to end authentication. SIP
       Expires November 13, 2005                              [Page 28]

         draft-sinnreich-sipdev-req-06.txt               November 2005
               telephony devices equipped for certificate based
               authentication MUST also store a key ring of
               certificates from public certificate authorities (CA"s).
               Note the recent work in the IETF on certificate services
               that do not require the telephony devices to store
               certificates [69].
        End-to-End Security Using S/MIME
               S/MIME [40] MUST be supported by SIP telephony devices
               to sign and encrypt portions of the SIP message that are
               not strictly required for routing by intermediaries.
               S/MIME protects private information in the SIP bodies
               and in some SIP headers from intermediaries. The end
               user certificates required for S/MIME assure the
               identity of the parties to each other. Note: S/MIME need
               not be used though in every call.
     4.3. Privacy
        Media Encryption
               Secure RTP (SRTP) [41] MAY be used for the encryption of
               media such as audio, text and video, after the keying
               information has been passed by SIP signaling.
               Instant messaging MAY be protected end-to-end using
     4.4. Support for NAT and Firewall Traversal
               The various NAT and firewall traversal scenarios require
               support in telephony SIP devices. The best current
               practices for NAT traversal for SIP are reviewed in
               [63]. Most scenarios where there are no SIP enabled
               network edge NAT/firewalls or gateways in the enterprise
               can be managed if there is a STUN [32] client in the SIP
               telephony device and a STUN server on the Internet,
               maintained by a service provider. In some exceptional
               cases (legacy symmetric NAT) an external media relay
               must also be provided that can support the TURN protocol
               exchange [62] with SIP telephony devices. Media relays
               such as TURN come at a high bandwidth cost to the
               service provider, since the bandwidth for many active
               SIP telephony devices must be supported. Media relays
               may also introduce longer paths with additional delays
               for voice.
               Due to these disadvantages of media relays, it is
               preferable to avoid symmetric and non-deterministic
               NAT"s in the network, so that only STUN can be used,
               where required. Reference [73] deals in more detail how
               NAT has to 'behave'.
       Expires November 13, 2005                              [Page 29]

         draft-sinnreich-sipdev-req-06.txt               November 2005
               It is not always obvious to determine the specific NAT
               and firewall scenario under which a SIP telephony device
               may operate.
               For this reason, the support for Interactive
               Connectivity Establishment (ICE) [76] has been defined
               to be deployed in all devices that required end-to-end
               connectivity for SIP signaling and RTP media streams, as
               well as for streaming media using RTSP. ICE makes use of
               existing protocols, such as STUN and TURN.
        Call flows using SIP security mechanisms
               The high level security aspects described here are best
               illustrated by inspecting the detailed call flows using
               SIP security, such as in [64].
       Security enhancements, certificates and identity management
               As of this writing, recent work in the IETF deals with
               the SIP authenticated body (AIB) format [66], new S/MIME
               requirements [67] enhancements for the authenticated
               identity [68], and Certificate Management Services for
               SIP [69]. We recommend developers and network managers
               to follow this work as it will develop into IETF
     5. IANA Considerations
        This document has no actions for IANA.
     6. Acknowledgments
        Mary Barnes has kindly made a very detailed review on version
        04 that has contributed to significantly improving the
        document. Useful comments on version 05 have also been made by
        Ted Hardie, David Kessens, Russ Housley and Harald Alvestrand
        that are reflected in this version of the document.
        We would like to thank Jon Peterson for very detailed comments
        on the previous version 0.3 that has prompted the rewriting of
        much of this document. John Elwell has contributed with many
        detailed comments to version of the 04 of the draft. Rohan Mahy
        has contributed several clarifications to the document and
        leadership in the discussions on support for the hearing
        disabled. These discussions have been concluded during the BOF
        on SIP Devices held during the 57th IETF and the conclusions
        are reflected in the section on interactive text support for
        hearing or speech disabled users.
        Arnoud van Wijk and Guido Gybels have been instrumental in
        driving the specification for support of the hearing disabled.
        The authors would also like to thank numerous persons for
        contributions and comments to this work: Henning Schulzrinne,
       Expires November 13, 2005                              [Page 30]

         draft-sinnreich-sipdev-req-06.txt               November 2005
        Jorgen Bjorkner, Jay Batson, Eric Tremblay, Gunnar Hellstrom,
        David Oran and Denise Caballero McCann, Brian Rosen, Jean
        Brierre, Kai Miao, Adrian Lewis and Franz Edler. Jonathan
        Knight has contributed significantly to earlier versions of the
        requirements for SIP phones. Peter Baker has also provided
        valuable pointers to TIA/EIA IS 811 requirements to IP phones
        that are referenced here.
        Last but not least, the co-authors of the previous versions,
        Daniel Petrie and Ian Butcher have provided support and
        guidance all along in the development of these requirements.
        Their contributions are now the focus of separate documents.
     7. Changes from Previous Versions
        Changes from draft raft-sinnreich-sipdev-req-05
        Updated the references and made edits as suggested by Mary
        Barnes and from comments by Russ Housley, David Kessen and Ted
        Changes from draft-sinnreich-sipdev-req-05
          . Added edits on text over IP has suggested by Gunnar
             Hellstrom and Jon Peterson.
        Changes from draft-sinnreich-sipdev-req-04
          . Removed the section on IANA Considerations that was meant
             to register the event package for automatic configuration,
             since this topic is now dealt elsewhere in [60].
          . Removed the reference to RFC 791, since that is implied by
             referencing the DiffServ code points in RFC 2597 [22].
          . Reviewed and tightened the language based on comments by
             John Elwell.
        Changes from draft-sinnreich-sipdev-req-03
           . Version 03 of the memo is focused more narrowly on SIP
           telephony device requirements and configuration only.
           . Automatic configuration over the network has been ommitted
           since it is addressed separately in [60].
           . The section with the example with XML based configuration
           data has been omitted, since such data formats are different
           topic altogether.
       Expires November 13, 2005                              [Page 31]

         draft-sinnreich-sipdev-req-06.txt               November 2005
           . The section on security considerations has been re-written
           from scratch so as to keep up with recent work on SIP
           security, and such items as user identity, certificates,
           S/MIME and the SIP Authenticated Body (AIB) format.
        Changes to -02 since draft-sinnreich-sipdev-req-01
           . Re-edited the section on Interactive text support for
           hearing or speech disabled users.
           . Shortened the sections on phonebook, call history and line
           related settings.
           . Deleted the section on ringer behavior.
           . Updated and added references.
     8. References
        Note: The references provided here should be considered
        informative, since this is an informational memo. Also, as of
        this writing, some references are work in progress at the IETF.
        As a result the version number on some key draft may be
        obsolete at the time of reading this memo and other Internet
        Drafts are advanced to RFC status.
        [1] Scott Bradner: "The Internet Standards Process, Revision
        3", RFC 2026. IETF, October 1996.
        [2] Scott Bradner: "Key words for use in RFCs to Indicate
        Requirement Levels", RFC 2119, IETF, 1997.
        [3] J. Rosenberg et. al: "SIP: Session Initiation Protocol",
        RFC 3261. IETF, June 2002.
        [4] R. Droms:: "Dynamic Host Configuration Protocol", RFC 2131.
        IETF, March 1997.
        [5] D. Mills: "Simple Network Time Protocol (SNTP) Version 4
        for IPv4 and IPv6 and OSI" RFC 2030. IETF, October 1996.
        [6] J. Rosenberg and H. Schulzrinne: "Session Initiation
        Protocol (SIP): Locating SIP Servers", RFC 3263. IETF, June
        [7] J.Peterson "ENUM Service Registration for Session
        Initiation Protocol (SIP) Address of Record", RFC 3764. IETF,
        April 2004.
       Expires November 13, 2005                              [Page 32]

         draft-sinnreich-sipdev-req-06.txt               November 2005
        [8] R J. Peterson: "A Privacy Mechanism for the Session
        Initiation Protocol", RFC 3323. IETF, November 2002.
        [9] H. Schulzrinne: "The tel URI for Telephone Numbers", RFC
        3966. IETF, December 2004.
        [10] R. Sparks: "The Session Initiation Protocol (SIP) Refer
        Method", RFC 3515. IETF, April 2003.
        [11] H. Schulzrinne and S. Petrack: RTP Payload for DTM Digits,
        Telephony Tones and Telephony Signals", RFC 2833. IETF, May
        [12] J. Rosenberg and H. Schulzrinne: "An Offer/Answer Model
        with the Session Description Protocol (SDP)", RFC 3264. IETF,
        June 2002.
        [13] S. Casner and P. Hoschka: S. "MIME Type Registration of
        RTP Payload Formats", RFC 3555. IETF, July 2003.
        [15] A. Johnston et al: "Session Initiation Protocol (SIP)
        Basic Call Flow Examples", RFC 3665. IETF, December 2003.
        [14] G. Camarillo et al: "Grouping ,of Media Lines in the
        Session Description Protocol (SDP)" RFC 3388. IETF, December
        [16] A. Johnston: "Session Initiation Protocol (SIP) Public
        Switched Telephone Network (PSTN) Call Flows", RFC 3666. IETF,
        December 2003.
        [17] J. Rosenberg et al: "Best Current Practices for Third
        Party Call Control (3pcc) in the Session Initiation Protocol
        (SIP)", RFC 3725. IETF, April 2004.
        [18] N. Charlton et al: "User Requirements for the Session
        Initiation Protocol (SIP) in Support of Deaf, Hard of Hearing
        and Speech-impaired Individuals". RFC 3351. IETF, August 2002.
        [19] M. Handley and V. Jacobson: "SDP: Session Description
        Protocol", RFC 2327. IETF, April 1998.
        [20] H. Schulzrinne et al: "RTP: A Transport Protocol for Real-
        Time Applications", RFC 3550. IETF, July 2003.
        [21] T. Friedman et al: "RTP Control Protocol Extended Reports
        (RTCP XR)", RFC 2611. IETF, November 2003.
       Expires November 13, 2005                              [Page 33]

         draft-sinnreich-sipdev-req-06.txt               November 2005
        [22] J. Heinanen et al: "Assured Forwarding PHB Group", RFC
        2597. IETF, June 1999.
        [23] R. Braden et al: "Resource ReSerVation Protocol (RSVP)-
        Version 1 Functional Specification", RFC 2205. IETF, September
        [24] H. Schulzrinne and S. Casner: "RTP Profile for Audio and
        Video Conferences with Minimal Control", RFC 3551. IETF, July
        [25] ITU-T Recommendation G.711 available online from the ITU
        bookstore at http://www.itu.int.
        [26] S.V. Anderson et al: "Internet Low Bit Rate Codec", RFC
        3951. IETF, December 2004.
        [27] R A. Duric: "RTP Payload Format for iLBC Speech", RFC
        3952. IETF, December 2004.
        [28] G. Herlein et al.: "RTP Payload Format for the Speex
        Codec", draft-herlein-avt-rtp-speex-00.txt, IETF, March 2003.
        [29] TIA/EIA-810-A, "Transmission Requirements for Narrowband
        Voice over IP and Voice over PCM Digital Wireline Telephones",
        July 2000.
        [30] TIA-EIA-IS-811, "Terminal Equipment - Performance and
        Interoperability Requirements for Voice-over-IP (VoIP) Feature
        Telephones", July 2000.
        [31] ITU-T Recommendation G.177 available online from the ITU
        bookstore at http://www.itu.int
        [32] J. Rosenberg et al: "STUN - Simple Traversal of User
        Datagram Protocol (UDP) Through Network Address Translators
        (NATs)" RFC 3489. IETF, March 2003.
        [33] P. Eggert, "Sources for time zone and daylight saving time
        data." Available at http://www.twinsun.com/tz/tz-link.htm
        [34] H. Alvestrand: "Tags for the Identification of Languages"
        RFC 3066. IETF, January 2001.
        [35] B. Campbell and R. Sparks: "Control of Service Context
        using SIP Request-URI" RFC 3087. IETF, April 2001.
        [36] T. Dierks: "The TLS protocol Version 1.0" RFC 2246. IETF,
        January 1999.
       Expires November 13, 2005                              [Page 34]

         draft-sinnreich-sipdev-req-06.txt               November 2005
        [37] C. Jennings et al: "Private Extensions to the Session
        Initiation Protocol (SIP) for Asserted Identity within Trusted
        Networks ", RFC 3325. IETF, November 2002.
        [38] J. Peterson: "A Privacy Mechanism for the Session
        Initiation Protocol (SIP)", RFC 3323. IETF, Nov. 2002.
        [39] S. Chokhani et al: "Internet X.509 Public Key
        Infrastructure, Certificate Policy and Certification Practices
        Framework" RFC 3647. IETF, Nov. 2003.
        [40] B. Ramsdell: "S/MIME Version 3 Message Specification" RFC
        2633. IETF, June 1999.
        [41] M. Baugher et al: "The Secure Real-time Transport Protocol
        (SRTP)", RFC 3711. IETF March 2004.
        [42] Mahy, R. et al: "A Call Control and Multi-party usage
        framework for the Session Initiation  Protocol (SIP)", draft-
        ietf-sipping-cc-framework-02. March 2003.
        [43] R. Mahy: "A Message Summary and Message Waiting Indication
        Event Package for the Session Initiation Protocol (SIP)", RFC
        3842. IETF, August 2004.
        [44] J. Peterson: "Telephone Number Mapping (ENUM) Service
        Registration for Presence Services". RFC 3953. IETF, January
        [45] S. Olson and O. Levin: "REFER extensions",draft-olson-
        sipping-refer-extensions-02,IETF July 2004.
        [46] A. Johnston: "SIP Service Examples", draft-ietf-sipping-
        service-examples-07, IETF July 2004. Work in progress.
        [47] A. Johnston et al: "Session Initiation Protocol (SIP)
        Basic Call Flow Examples" RFC 3665. IETF, December 2003.
        [48] A. Johnston and O. Levin: "Session Initiation Protocol
        Call Control - Conferencing for User Agents", draft-ietf-
        sipping-cc-conferencing-06.txt, IETF, November 2004, work in
        [49] R. Even and N. Ismail: "Conferencing Scenarios" draft-
        ietf-xcon-conference-scenarios-02.txt, IETF, June 2004.
       Expires November 13, 2005                              [Page 35]

         draft-sinnreich-sipdev-req-06.txt               November 2005
        [50] J. Rosenberg et al: "Session Initiation Protocol (SIP)
        Extension for Instant Messaging", RFC 3428. IETF, December
        [51] H. Schulzrinne et al.: "RPID: Rich Presence Extensions to
        the Presence Information Data Format (PIDF)", draft-ietf-
        simple-rpid-04, IETF, October 2004.
        [52] J. Rosenberg et al: "Indicating User Agent Capabilities in
        the Session Initiation Protocol (SIP)" RFC 3840. IETF, August
        [53] H. Schulzrinne and B. Rosen: "Emergency Services for
        Internet Telephony Systems", draft-schulzrinne-sipping-
        emergency-arch-02, IETF, October 2004. Work in progress.
        [54] See the Working Group on Emergency Context Resolution with
        Internet Technologies at
        [55] H. Schulzrinne and J. Polk: "Communications Resource
        Priority for the Session Initiation Protocol", IETF, draft-
        ietf-sip-resource-priority-05, October 2004.
        [56] G. Hellstrom and P. Jones: "RTP Payload for Text
        Conversation", draft-ietf-avt-rfc2793bis-09.txt, IETF, August
        2004, work in progress.
        [57] A. Johnston: "A Performance Report Event Package For SIP",
        draft-johnston-sipping-rtcp-summary-04, IETF, October 2004.
        Work in progress.
        [58] C. Jennings: "NAT Classification Results using STUN",
        draft-jennings-midcom-stun-results-02, IETF, October 2004. Work
        in progress.
        [59] J. Rosenberg: "A Presence Event Package for the Session
        Initiation Protocol (SIP)", RFC 3856. IETF, October 2004.
        [60] D. Petrie: "A Framework for SIP User Agent Profile
        Delivery", draft-ietf-sipping-config-framework-05.txt, IETF,
        October 2004.
        [61] C. Jennings: "SIP Tutorial: SIP Security" presented at the
        VON Spring 2004 conference, March 29, 2004, Santa Clara, CA.
        [62] J. Rosenberg et al.: "Traversal Using Relay NAT (TURN)",
        draft-rosenberg-midcom-turn-06.txt, IETF, October. 2004, work
        in progress.
       Expires November 13, 2005                              [Page 36]

         draft-sinnreich-sipdev-req-06.txt               November 2005
        [63] C. Boulton and J. Rosenberg: "Best Current Practices for
        NAT Traversal for SIP", IETF, October 2004, work in progress.
        [64] C. Jennings: "Example call flows using SIP security
        mechanisms", draft-jennings-sip-sec-flows-01, IETF, February
        [65] J. Rosenberg et al: "Caller Preferences for the Session
        Initiation Protocol (SIP)", RFC 3841. IETF, August 2004.
        [66] J. Peterson: "Session Initiation Protocol (SIP)
        Authenticated Identity Body (AIB) Format", RFC 3893. IETF,
        September 2004.
        [67] J. Peterson: "S/MIME AES Requirements for SIP" draft-ietf-
        sip-smime-aes, IETF, June 2003.
        [68] J. Peterson and C. Jennings: "Enhancements for
        Authenticated Identity Management in the Session Initiation
        Protocol (SIP)", draft-ietf-sip-identity, May 2004.
        [69] J. Peterson and C. Jennings: "Certificate Management
        Services for SIP", draft-sipping-certs, October 2004.
        [70] G. Hellstrom and P. Jones: "RTP Payload for Text
        Conversation", RFC 2793bis. Internet Draft. Work in progress.
        draft-ietf-avt-rfc2793bis-09.txt, IETF, August 2004.
        [71] G. Camarillo: "The Early Session Disposition Type for the
        Session Initiation Protocol (SIP)", RFC 3959. IETF, December
        [72] "D. Wing: "Symmetric RTP and RTCP Considered Helpful".
        IETF, October 2004, work in progress.
        [73] F. Audet and C. Jennings: "NAT Behavioral Requirements for
        Unicast UDP". IETF, January 2005, work in progress.
        [74] R. Mahy: "Connection Reuse in the Session Initiation
        Protocol (SIP)". IETF, October 2004. Work in progress.
        [75] C. Boulton et al: "Guidelines for implementers using
        connection-oriented transports in the Session Initiation
        Protocol (SIP)". IETF, February 2005. Work in progress.
        [76] J. Rosenberg: "Interactive Connectivity Establishment
        (ICE): A Methodology for Network Address Translator (NAT)
       Expires November 13, 2005                              [Page 37]

         draft-sinnreich-sipdev-req-06.txt               November 2005
        Traversal for Multimedia Session Establishment Protocols".
        Internet Draft, IETF, October 2004. Work in progress.
        [77] J. Polk: "Requirements for Session Initiation Protocol
        Location Conveyance". Internet Draft. October 2004. Work in
     9. Author's Addresses
          Henry Sinnreich
          115 Broadhollow Road
          Melville, NY 11747, USA
          Email: henry@pulver.com
          Phone : +1-631-961-8950
          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
          Gradestrasse, 46
          D-12347 Berlin, Germany
          Email: cs@snom.de
          Phone: +49(30)39833-0
     10. Copyright Notice
        Copyright (C) The Internet Society (2005).  This document is
        subject to the rights, licenses and restrictions contained in
        BCP 78, and except as set forth therein, the authors retain
        all their rights.
        This document and the information contained herein are
        provided on an "AS IS" basis and THE CONTRIBUTOR, THE
        The IETF takes no position regarding the validity or scope of
        any Intellectual Property Rights or other rights that might be
       Expires November 13, 2005                              [Page 38]

         draft-sinnreich-sipdev-req-06.txt               November 2005
        claimed to pertain to the implementation or use of the
        technology described in this document or the extent to which
        any license under such rights might or might not be available;
        nor does it represent that it has made any independent effort
        to identify any such rights.  Information on the procedures
        with respect to rights in RFC documents can be found in BCP 78
        and BCP 79.
              Copies of IPR disclosures made to the IETF Secretariat
        and any assurances of licenses to be made available, or the
        result of an attempt made to obtain a general license or
        permission for the use of such proprietary rights by
        implementers or users of this specification can be obtained
        from the IETF on-line IPR repository at
              The IETF invites any interested party to bring to its
        attention any copyrights, patents or patent applications, or
        other proprietary rights that may cover technology that may be
        required to implement this standard.  Please address the
        information to the IETF at ietf-ipr@ietf.org.
       Expires November 13, 2005                              [Page 39]

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