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

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

                  SIP Telephony Device Requirements         June 2004
  
  
   SIPPING WG                                   H. Sinnreich/MCI,editor
   Internet Draft                                           S. Lass/MCI
                                                      C. Stredicke/snom
   Expires: February 2005                                     June 2004
  
  
            SIP Telephony Device Requirements and Configuration
                     draft-sinnreich-sipdev-req-04.txt
  
     Status of this Memo
  
   By submitting this Internet-Draft, we certify that any applicable
   patent or other IPR claims of which we are aware have been disclosed,
   or will be disclosed, and any of which we become aware will be
   disclosed, in accordance with RFC 3668.
  
   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 [1].
  
   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.
  
   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."
  
   The list of current Internet-Drafts can be accessed at
        http://www.ietf.org/ietf/1id-abstracts.txt
   The list of Internet-Draft Shadow Directories can be accessed at
        http://www.ietf.org/shadow.html.
  
   This Internet-Draft will expire on February 2005.
  
   Copyright Notice
  
      Copyright (C) The Internet Society (2004).  All Rights Reserved.
  
     Abstract
  
   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
   interoperability and multi-vendor supported core features, so as to
  
  
   Sinnreich et al.    Expires – February 2005               [Page 1]
  

                  SIP Telephony Device Requirements         June 2004
  
  
   enable similar ease of purchase, installation and operation as found
   for PCs, PDAs analog feature phones or mobile phones.
  
   We present a glossary of the most common settings and some of the
   more widely used values for some settings.
  
     Table of Contents
  
   1. Introduction...................................................3
   2. Conventions Used In This Document..............................4
   3. Generic Requirements...........................................4
      3.1 IP Host Requirements.......................................4
      3.2 DNS and ENUM Support.......................................5
      3.3 SIP Device Resident Telephony Features.....................5
      3.4 Support for SIP Services...................................7
      3.5 Basic Telephony and Presence Information Support...........8
      3.6 Emergency and Resource Priority Support....................9
      3.7 Multi-Line Requirements....................................9
      3.8 User Mobility.............................................10
      3.9 Interactive Text Support..................................11
      3.10 Other Related Protocols..................................12
      3.11 SIP Device Security Requirements.........................12
      3.12 Quality of Service.......................................13
      3.13 Media Requirements.......................................13
      3.14 Voice Codecs.............................................13
      3.15 Telephony Sound Requirements.............................14
      3.16 International Requirements...............................15
      3.17 Support for Applications.................................15
      3.18 Web Based Feature Management.............................15
      3.19 Firewall and NAT Traversal...............................16
      3.20 Device Interfaces........................................16
   4. Glossary and Usage for the Configuration Settings.............17
      4.1 Device ID.................................................18
      4.2 Signaling Port............................................18
      4.3 RTP Port Range............................................18
      4.4 Quality of Service........................................18
      4.5 Default Call Handling.....................................19
      4.6 Outbound Proxy............................................19
      4.7 Default Outbound Proxy....................................19
      4.8 SIP Session Timer.........................................19
      4.9 Telephone Dialing Functions...............................19
      4.10 Phone Number Representations.............................20
      4.11 Digit Maps and/or the Dial/OK Key........................20
      4.12 Default Digit Map........................................21
      4.13 SIP Timer Settings.......................................21
      4.14 Audio Codecs.............................................21
      4.15 DTMF Method..............................................21
      4.16 Local and Regional Parameters............................22
      4.17 Time Server..............................................22
  
  
   Sinnreich et al.    Expires – February 2005               [Page 2]
  

                  SIP Telephony Device Requirements         June 2004
  
  
      4.18 Language.................................................22
      4.19 Inbound Authentication...................................23
      4.20 Voice Message Settings...................................23
      4.21 Phonebook and Call History...............................23
      4.22 User Related Settings and Mobility.......................24
      4.23 AOR Related Settings.....................................24
      4.24 Maximum Connections......................................25
      4.25 Automatic Configuration and Upgrade......................25
      4.26 Security Configurations..................................25
   5. Security Considerations.......................................26
      5.1 Threats and Problem Statement.............................26
      5.2 SIP Telephony Device Security.............................27
   6. IANA Considerations...........................................29
   7. Changes from draft-sinnreich-sipdev-req-03....................30
   8. References....................................................30
      8.1 Normative References......................................30
      8.2 Informative References....................................33
   9. Acknowledgments...............................................35
   10. Author's Addresses...........................................36
   11. Intellectual Property and Validity Statement.................36
  
     1. Introduction
  
   This informational I-D 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 device enabled for SIP based IP
   telephony. SIP telephony 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 telephony devices can also be instant messaging (IM) applications
   that have a telephony option.
  
   SIP devices MAY also 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, as will be shown.
  
  
  
   Sinnreich et al.    Expires – February 2005               [Page 3]
  

                  SIP Telephony Device Requirements         June 2004
  
  
   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. 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.
  
     3. Generic Requirements
  
   We present here a minimal set of requirements that MUST be met by all
   SIP [3] telephony devices, except where SHOULD or MAY is specified.
  
     3.1 IP Host Requirements
  
   This section applies mainly to desktop phones and other special
   purpose SIP hardware. Some of the requirements in this section are
   not applicable to PC/laptop or PDA software phones (soft phones) and
   mobile phones.
  
  REQ-1: SIP telephony devices MUST be able to acquire IP network
          settings by automatic configuration using DHCP [4].
  
  REQ-2: SIP telephony devices MUST be able to acquire IP network
          settings by manual entry of settings from the device.
  
  REQ-3: SIP telephony devices SHOULD support IPv6. Some newer wireless
          networks may mandate support for IPv6 and in such networks SIP
          telephony devices MUST support IPv6.
  
  REQ-4: SIP telephony devices that display the time MUST support the
          Simple Network Time Protocol [5].
  
  
   Sinnreich et al.    Expires – February 2005               [Page 4]
  

                  SIP Telephony Device Requirements         June 2004
  
  
  REQ-5: Desktop SIP phones and other special purpose SIP telephony
          devices MUST be able to upgrade their firmware to support
          additional features and improved functionality.
  
  REQ-6: Users SHOULD be able to upgrade the devices with no special
          applications or equipment; or a service provider SHOULD be
          able to push the upgrades down to the devices remotely.
  
     3.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 support 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 SHOULD support ENUM [7].
  
     3.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
          [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 attribute.
  
  
  
  
   Sinnreich et al.    Expires – February 2005               [Page 5]
  

                  SIP Telephony Device Requirements         June 2004
  
  
  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.  The dial
          plan MUST consist of a pattern string to match dial digits,
          and the ability to strip and also append prefix digits, and
          also append suffix digits.
  
  REQ-18: SIP telephony devices MUST support the URLs for Telephone
          numbers [9]. See also the amended version [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.
  
  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
  
  
   Sinnreich et al.    Expires – February 2005               [Page 6]
  

                  SIP Telephony Device Requirements         June 2004
  
  
          devices SHOULD support Flow Identification as defined in RFC
          3388 [11].
  
  REQ-26: SIP telephony devices MUST generate local ringing and MUST
          ignore any early RTP media when a “180 Ringing” response is
          received.
  
  REQ-27: SIP telephony devices MUST play the first RTP stream and
          ignore any other RTP media streams when a “183 Session
          Progress” response is received.
  
  REQ-28: SIP telephony devices MUST 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-29: SIP devices with a display MUST support the call-info header
          and depending on the display capabilities MAY for example
          display an icon or the image of the caller.
  
  REQ-30: To provide additional information about call failures, SIP
          telephony devices MUST display the “Reason Phrase” of the SIP
          message instead of mapping the “Status-Code” to custom or
          default messages.  The devices MAY use an internal “Status
          Code” table if there was a problem with the language
          negotiation.
  
  REQ-31: SIP telephony devices MUST support music on hold as shown in
          "SIP Service Examples" [46].
  
  REQ-32: SIP telephony devices MAY ring after a call has been on hold
          for a predetermined period of time, typically 3 minutes.
  
     3.4 Support for SIP Services
  
  REQ-33: SIP telephony devices MUST support the SIP Basic Call Flow
          Examples [47].
  
  
  
  
  
   Sinnreich et al.    Expires – February 2005               [Page 7]
  

                  SIP Telephony Device Requirements         June 2004
  
  
  REQ-34: SIP telephony devices MUST support the SIP-PSTN Service
          Examples [16].
  
  REQ-35: SIP telephony devices MUST support the Third Party Call
          Control model [17].
  
  REQ-36: SIP telephony devices SHOULD support other SIP call control
          and multiparty usage [43].
  
  REQ-37: SIP telephony devices SHOULD support conferencing services for
          voice and IM [48], [49].
  
  REQ-38: SIP telephony devices MUST support caller and called party
          preferences [52].
  
  REQ-39: 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/called party preferences.
  
     3.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 states,
   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 devices can
   support for example a voice session and several IM sessions with
   different parties.
  
  REQ-40: 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.
  
  
  
  
  
   Sinnreich et al.    Expires – February 2005               [Page 8]
  

                  SIP Telephony Device Requirements         June 2004
  
  
  REQ-41: Users MUST be able to set the state of the SIP telephony
          device to “Do Not Disturb”, manifested as a Presence state
          across the network.
  
  REQ-42: SIP telephony devices with “Do Not Disturb” enabled MUST
          respond to new sessions with “486 Busy Here”.
  
     3.6         Emergency and Resource Priority Support
  
  REQ-43: Emergency calling: For emergency numbers (e.g. 911, SOS URL)
          the client MUST send the location information acquired by
          various means as detailed in [53]. SIP telephony devices MUST
          be provisioned with a URL or phone number of the emergency
          call center and MUST support the SOS URL [54].
  
  REQ-44: 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-45: 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.
  
     3.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
  
  
  
   Sinnreich et al.    Expires – February 2005               [Page 9]
  

                  SIP Telephony Device Requirements         June 2004
  
  
   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-46: 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-47: 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-48: 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-49: Multi-line SIP telephony devices MUST be able to provision a
          different ring tone for each line.
  
     3.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-50: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-51: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.
  
  
  
   Sinnreich et al.    Expires – February 2005              [Page 10]
  

                  SIP Telephony Device Requirements         June 2004
  
  
   REQ-52:User mobility enabled SIP telephony devices for the desktop
          MUST use the local static location data associated with the
          device for emergency calls.
  
     3.9 Interactive Text Support
  
  REQ-53: 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.
  
  REQ-54: 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-55: SIP telephony devices SHOULD provide an external standard
          wired or wireless link to connect external input (keyboard,
          mouse) and display devices.
  
  REQ-56: SIP-33: 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-57: 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-58: SIP telephony devices MAY provide analog adaptor functionality
          through an RJ-11 FXO port to support FXS devices.  If an RJ-11
  
  
   Sinnreich et al.    Expires – February 2005              [Page 11]
  

                  SIP Telephony Device Requirements         June 2004
  
  
          (FXO) port is provided, then it MAY support a gateway function
          from all text-telephone protocols according to ITU-T
          Recommendation V.18 to RFC 2793 text conversation (in fact
          this is encouraged in the near term during the transition to
          widespread use of SIP telephony devices). If this gateway
          function is not included or fails, the device MUST pass-
          through all text-telephone protocols according to ITU-T
          Recommendation V.18, November 2000, in a transparent fashion.
  
  REQ-59: SIP telephony devices MAY provide a 2.5 mm audio port, in
          portable SIP devices, such as PDA’s and various wireless SIP
          phones.
  
     3.10 Other Related Protocols
  
  REQ-60: 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 [21] and MAY also support the
          RTCP summary report delivery [57].
  
     3.11 SIP Device Security Requirements
  
   This paragraph is focused on the requirements for SIP device security
   only. Section 4 on Security Consideration deals with some wider
   security issues.
  
  REQ-61: 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-62: SIP telephony devices MUST be able to password protect
          configuration information and administrative functions.
  
  REQ-63: SIP telephony devices MUST NOT display the password to the
          user or administrator after it has been entered.
  
  REQ-64: 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.
  
  
   Sinnreich et al.    Expires – February 2005              [Page 12]
  

                  SIP Telephony Device Requirements         June 2004
  
  
  REQ-65: 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 AOR.  This provides
          protection against war-dialer attacks.  The setting to
          accept/reject MUST be configurable.
  
  REQ-66: 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.
  
     3.12 Quality of Service
  
  REQ-67: SIP devices MUST support the IPv4 DSCP field for RTP streams
          as per RFC 2597 [22] that supersedes the Type of Service (ToS)
          bits described in RFC 791. The DSCP setting MUST be
          configurable to complement the local network policy.
  
  REQ-68: 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-69: SIP telephony devices MAY support RSVP [23].
  
     3.13 Media Requirements
  
  REQ-70: 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.
  
  REQ-71: To reduce overall bandwidth, SIP telephony devices MAY support
          active voice detection and comfort noise generation.
  
     3.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
  
  
   Sinnreich et al.    Expires – February 2005              [Page 13]
  

                  SIP Telephony Device Requirements         June 2004
  
  
   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 five
   codecs used in wireline VoIP, besides various codecs found in mobile
   phones.
  
  REQ-72: SIP telephony devices SHOULD support AVT payload type 0 (G.711
          uLaw) as the default codec [25] and its Annexes 1 and 2.
  
  REQ-73: SIP telephony devices MUST support the Internet Low Bit Rate
          codec (iLBC) [26], [27].
  
  REQ-74: SIP telephony devices SHOULD support GSM codecs found in
          various 3G wireless phones.
  
  REQ-75: SIP telephony devices MAY support G.723.1, where low bandwidth
          is needed.
  
  REQ-76: SIP telephony devices MAY support G.729 and its annexes.
  
   Note: 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] 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.
  
          The authors believe the Internet Low Bit Rate codec (iLBC)
          should be the default codec for Internet telephony.
  
     3.15 Telephony Sound Requirements
  
  REQ-77: SIP telephony devices SHOULD comply with the handset receive
          comfort noise requirements outlined in the ANSI standards
          [29], [30].
  
  REQ-78: SIP telephony devices SHOULD comply with the stability or
          minimum loss defined in ITU-T G.177 [31].
  
  
  
  
   Sinnreich et al.    Expires – February 2005              [Page 14]
  

                  SIP Telephony Device Requirements         June 2004
  
  
  REQ-79: 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-80: SIP telephony device MAY support different ring-tones based on
          the caller identity.
  
   3.16          International Requirements
  
  REQ-81: SIP telephony devices SHOULD indicate the preferred language
          [34] using Caller Preferences [52].
  
  REQ-82: SIP telephony devices intended to be used in various language
          settings [34], MUST support other languages for menus, help,
          and labels.
  
     3.17 Support for Applications
  
   The following requirements apply to functions placed in the SIP
   telephony device.
  
  REQ-83: SIP telephony devices that have a large display and support
           presence SHOULD display a buddy list [50].
  
  REQ-84: SIP telephony devices MAY support LDAP for client-based
           directory lookup.
  
  REQ-85: SIP telephony devices MAY support a phone setup where a URL
           is automatically dialed when the phone goes off-hook.
  
     3.18 Web Based Feature Management
  
  REQ-86: SIP telephony devices SHOULD support an internal web server
           to allow users to manually configure the phone and to set up
           personal phone services such as the address book, speed-
           dial, ringer 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 SHOULD NOT require special client
  
  
   Sinnreich et al.    Expires – February 2005              [Page 15]
  

                  SIP Telephony Device Requirements         June 2004
  
  
           software on the PC or require a dedicated management
           console. SIP telephony devices SHOULD support https
           transport for this purpose.
  
     3.19 Firewall and NAT Traversal
  
   The following requirements allow SIP clients to properly function
   behind various firewall architectures.
  
  REQ-87: 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.
  
  REQ-88: 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
          devices.
  
  REQ-89: SIP telephony devices SHOULD support UPnP
          (http://www.upnp.org/) for NAPT device traversal.
  
  REQ-90: SIP telephony devices MUST be able to limit the ports used for
          RTP to a provisioned range.
  
     3.20 Device Interfaces
  
   SIP telephony devices MAY have various types of interfaces, such as
   resembling a desktop phone, cordless phone, mobile phone, handheld
   computer, laptop computer and MAY have various interface models, such
   as for phones, IM GUI or other. Given the variety of possible
   interfaces, only the generic requirements can be listed here.
  
  REQ-91: SIP telephony devices MUST have two types of interface
           capabilities, for both phone numbers and URLs, both
           accessible to the end user.
  
  
  
  
   Sinnreich et al.    Expires – February 2005              [Page 16]
  

                  SIP Telephony Device Requirements         June 2004
  
  
  REQ-92: 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-93: 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-94: SIP telephony devices should allow phone number entry in
           human friendly fashion, with the usual separators and
           brackets between digits and digit groups.
  
     4. 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.
  
  
   Sinnreich et al.    Expires – February 2005              [Page 17]
  

                  SIP Telephony Device Requirements         June 2004
  
  
  
  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.
  
   4.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”
  
     4.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”
  
     4.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”
  
     4.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
  
  
   Sinnreich et al.    Expires – February 2005              [Page 18]
  
                  SIP Telephony Device Requirements         June 2004
  
  
          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”
  
     4.5 Default Call Handling
  
          All of the call handling settings defined below can be defined
          here as default behaviors.
  
     4.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”
  
     4.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”
  
     4.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
          provided.
  
          Example: SessionTimer=”600;unit=seconds”
  
     4.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
  
  
  

   Sinnreich et al.    Expires – February 2005              [Page 19]
  

                  SIP Telephony Device Requirements         June 2004
  
  
          the rule by which digits are transformed into a URL (usually
          SIP URL or TEL URL).
  
     4.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”.
  
     4.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
          define:
  
          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
          optionally
          3) An outbound proxy to be used in routing the SIP INVITE.
  
          A critical timer MAY be provided which determines how long the
          device SHOULD wait before dialing if a dial plan contains a T
          (Timer) character. It MAY also provide a timer for the maximum
          elapsed time which SHOULD pass before dialing if the digits
          entered by the user match no dial plan. If the UA has a Dial
          or Ok key, pressing this key will override the timer setting.
  
          SIP telephony devices SHOULD have a Dial/OK key.
  
          After sending a request, UA SHOULD be prepared to receive a
          484 Address Incomplete response. In this case, the user agent
          should accept more user input and try again to dial the
          number.
  
          An example digit map could use regular expressions like in DNS
          NAPTR (RFC2915) to translate user input into a SIP URL.
          Additional replacement patterns like “d” could insert the
          domain name of the used AOR. Additional parameters could be
          inserted in the flags portion of the substitution expression.
          A list of those patterns would make up the dial plan:
  
          |^([0-9]*)#$|sip:\1@\d;user=phone|outbound=proxy.com
  
  
   Sinnreich et al.    Expires – February 2005              [Page 20]
  

                  SIP Telephony Device Requirements         June 2004
  
  
          |^([a-zA-Z0-9&=+\$,;?\-_.!~*'()%]+@.+)|sip:\1|
          |^([a-zA-Z0-9&=+\$,;?\-_.!~*'()%]+)$|sip:\1@\d|
          |^(.*)$|sip:\1@\d|timeout=5
  
     4.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.
  
     4.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.
  
     4.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 MUST be configurable along with the order of
          preference. Service providers MUST 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”
  
     4.15 DTMF Method
  
  
  
   Sinnreich et al.    Expires – February 2005              [Page 21]
  

                  SIP Telephony Device Requirements         June 2004
  
  
          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].
  
     4.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”
  
     4.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=”12.34.5.2;protocol=NTP”
  
     4.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”
  
  
   Sinnreich et al.    Expires – February 2005              [Page 22]
  

                  SIP Telephony Device Requirements         June 2004
  
  
  
          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.
  
     4.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
          initiation.
  
     4.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].
  
          Example: MWISubscribe=”sip:mailbox01@media.proxy.com”
  
          User Agents SHOULD accept MWI notifications without prior
          subscription. This way the setup of voice message settings can
          be avoided.
  
     4.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
  
  
   Sinnreich et al.    Expires – February 2005              [Page 23]
  

                  SIP Telephony Device Requirements         June 2004
  
  
          that keeps the information even after restarting the device or
          save the information in an external database that permanently
          stores the information.
  
     4.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 a 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.
  
     4.23 AOR Related Settings
  
  
  
  
   Sinnreich et al.    Expires – February 2005              [Page 24]
  

                  SIP Telephony Device Requirements         June 2004
  
  
          SIP telephony devices MUST use the 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.
  
     4.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”
  
     4.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.
  
     4.26 Security Configurations
  
  
  
   Sinnreich et al.    Expires – February 2005              [Page 25]
  

                  SIP Telephony Device Requirements         June 2004
  
  
          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 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.
  
     5. Security Considerations
  
     5.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 in other parts of SIP enabled networks
   may reside.
  
   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,
  
  
   Sinnreich et al.    Expires – February 2005              [Page 26]
  

                  SIP Telephony Device Requirements         June 2004
  
  
     . There are seemingly conflicting service requirements when
        supporting anonymity, legal intercept, call trace and privacy,
     . Complications arise from the need to traverse NATs and firewalls.
  
   There are a large number of deployment scenarios in enterprise
   networks, using residential networks and employees using VPN access
   to the corporate network when working from home or on travel. There
   are different security scenarios for each. The 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.
  
     5.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’
          header.
  
  
   Sinnreich et al.    Expires – February 2005              [Page 27]
  

                  SIP Telephony Device Requirements         June 2004
  
  
  
   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).
  
   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.
  
   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.
  
   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 NAT’s in the network, so that only STUN can
          be used, where required.
  
          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
  
  
  
   Sinnreich et al.    Expires – February 2005              [Page 28]
  

                  SIP Telephony Device Requirements         June 2004
  
  
          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
          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 [69]. We recommend developers and
          network managers to follow this work as it will develop into
          IETF standards.
  
     6. IANA Considerations
  
  SIP Event Package Registration for Configuration
  
  Package name: SIP Telephony Device Configuration
  
  Type: package
  
  Contact: [Christian Stredicke]
  
  Published Specification: This document.
  
  MIME Registration for Application
  
  The MIME Registration for application/sip-endpoint-configuration is:
  
  MIME media type name: application
  
  MIME subtype name: sip-endpoint-configuration
  
  Required parameters: none.
  
  Optional parameters: none.
  
  Encoding considerations: See SIP [3] message header definition.
  
  Security considerations: See the "Security Considerations" in
  Section 8 n this document.
  
  Interoperability considerations: none
  
  Published specification: This document.
  
  
  
   Sinnreich et al.    Expires – February 2005              [Page 29]
  

                  SIP Telephony Device Requirements         June 2004
  
  
  Applications which use this media: SIP configuration server and
  clients subscribing to these servers.
  
  Additional information:
  
    1. Magic number(s): N/A
    2. File extension(s): N/A
    3. Macintosh file type code: N/A.
  
  
     7. Changes from draft-sinnreich-sipdev-req-03
  
     . This version (0.5) of the memo is focused more narrowly on SIP
        telephony device requirements and configuration only.
     . Automatic configuration over the network has been ommitted since
        it is addressed separately in [60].
     . The section with the example with XML based configuration data
        has been omitted, since such data formats are different topic
        altogether.
     . The section on security considerations has been re-written from
        scratch so as to keep up with recent work on SIP security, and
        such items as user identity, certificates, S/MIME and the SIP
        Authenticated Body (AIB) format.
  
   Changes to -02 since draft-sinnreich-sipdev-req-01
  
     . Re-edited the section on Interactive text support for hearing or
        speech disabled users.
     . Shortened the sections on phonebook, call history and line
        related settings.
     . Deleted the section on ringer behavior.
     . Updated and added references.
  
        8. References
  
        8.1 Normative References
  
   [1] RFC2026: "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 et al.    Expires – February 2005              [Page 30]
  

                  SIP Telephony Device Requirements         June 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.3
  
   [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 2003.
  
   [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 et al.    Expires – February 2005              [Page 31]
  

                  SIP Telephony Device Requirements         June 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 et al.    Expires – February 2005              [Page 32]
  

                  SIP Telephony Device Requirements         June 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.
  
        8.2 Informative References
  
   [42] Mahy, R. et al: "A Call Control and Multi-party usage framework
   for the Session Initiation  Protocol (SIP)", draft-ietf-sipping-cc-
   framework-04. October 2003.
  
   [43] R. Mahy: “A Message Summary and Message Waiting Indication Event
   Package for the Session Initiation Protocol (SIP)”, draft-ietf-
   sipping-mwi-04.txt, IETF, December 2003, work in progress.
  
   [44] H. Schulzrinne: “The tel URI for Telephone Numbers”, draft-ietf-
   iptel-rfc2806bis-07, IETF April 2004, work in progress.
  
   [45] S. Olson and O. Levin: “Extended-REFER framework and other REFER
   extensions”,draft-olson-sipping-refer-extensions-01,IETF February
   2004, work in progress.
  
  
   [46] A. Johnston: “SIP Service Examples”, draft-ietf-sipping-service-
   examples-06, IETF February 2004. Work in progress.
  
   [47] RFC 3666: “Public Switched Telephone Network (PSTN) Call Flows”
   by A. Johsnton et al. IETF, December 2003.
  
   [48] A. Johnston and O. Levin: “Session Initiation Protocol Call
   Control - Conferencing for User
   Agents”, IETF, February 2004, work in progress.
  
  
  
   Sinnreich et al.    Expires – February 2005              [Page 33]
  

                  SIP Telephony Device Requirements         June 2004
  
  
  
   [49] R. Even and N. Ismail: “Conferencing Scenarios” draft-ietf-xcon-
   conference-scenarios-00.txt, IETF, November 2003, work in progress.
  
   [50] Rosenberg, J.,"SIP Extensions for Presence", draft-ietf-simple-
   presence-10 (work in progress), January 2003.
  
   [51] H. Schulzrinne et al.: “RPID: Rich Presence Extensions to the
   Presence Information Data                              Format
   (PIDF)”, draft-ietf-simple-rpid-03,IETF, September 2003.
  
   [52] J. Rosenberg et al: “Caller Preferences for the Session
   Initiation Protocol (SIP)”, draft-ietf-sip-callerprefs, IETF, October
   2003, work in progress.
  
   [53] H. Schulzrinne and B. Rosen: “Emergency Services for Internet
   Telephony Systems”, draft-schulzrinne-sipping-emergency-arch, IETF,
   February 2004. Work in prgress.
  
   [54] H. Schulzrinne: “Emergency Services URI for the Session
   Initiation Protocol”, draft-ietf-sipping-sos-00. IETF, February 2004.
   Work in progress.
  
   [55] H. Schulzrinne and J. Polk: “Communications Resource Priority
   for the Session Initiation Protocol”, IETF, draft-ietf-sip-resource-
   priority-03, March 2004.
  
   [56] G. Hellström et al.: “Framework of requirements for real-time
   text conversation using SIP”. IETF, February 2004.
  
   [57] A. Johnston: “RTCP Summary Report Delivery to Third Parties”,
   draft-johnston-sipping-rtcp-summary-02, IETF, February 2004. Work in
   progress.
  
   [58] C. Jennings: “NAT Classification Results using STUN”, draft-
   jennings-midcom-stun-results-00, IETF, February 2004. Work in
   progress.
  
   [59] R. Mahy: “A Message Summary and Message Waiting Indication Event
   Package for the Session Initiation Protocol (SIP)”, draft-ietf-
   sipping-mwi-04.txt, IETF, December 2003.
  
   [60] D. Petrie: “A Framework for SIP User Agent Profile Delivery”,
   draft-ietf-sipping-config-framework-03.txt, IETF, May 2004.
  
   [61] C. Jennings: “SIP Tutorial: SIP Security” presented at the VON
   Spring 2004 conference, March 29, 2004, Santa Clara, CA.
  
  
  
  
   Sinnreich et al.    Expires – February 2005              [Page 34]
  

                  SIP Telephony Device Requirements         June 2004
  
  
   [62] J. Rosenberg et al.: “Traversal Using Relay NAT (TURN)”, IETF,
   Feb. 2004, work in progress.
  
   [63] J. Rosenberg: “Interactive Connectivity Establishment (ICE): A
   Methodology for Network Address Translator (NAT) Traversal for
   Multimedia Session Establishment Protocols”, IETF, February 2004,
   work in progress.
  
   [64] C. Jennings: “Example call flows using SIP security mechanisms”,
   draft-jennings-sip-sec-flows-01, IETF, February 2004, work in
   progress.
  
   [65] J. Rosenberg et al.: “Caller Preferences for the Session
   Initiation Protocol (SIP)”, draft-ietf-sip-callerprefs-10, IETF
   October 2003. Work in progress.
  
   [66] J. Peterson: “SIP Authenticated Identity Body (AIB) Format”,
   draft-ietf-sip-authid-body, IETF, May 2003.
  
   [67] J. Peterson: “S/MIME AES Requirements for SIP” draft-ietf-sip-
   smime-aes, IETF, June 2003, work in progress.
  
   [68] J. Peterson and C. Jennings: “Enhancements for Authenticated
   Identity Management in the Session Initiation Protocol (SIP)”, draft-
   ietf-sip-identity, May 2004, work in progress.
  
   [69] J. Peterson and C. Jennings: “Certificate Management Services
   for SIP”, draft-jennings-sipping-certs, May 2004.
  
   [70] RFC 2793bis: "RTP Payload for Text Conversation" by H. Hellstrom
   and P. Jones. Internet Draft, work in progress. IETF, June 2004.
  
     9. 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. 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 Internet Draft: Henning
   Schulzrinne, Jörgen Björkner, Jay Batson, Eric Tremblay, Gunnar
  
  
   Sinnreich et al.    Expires – February 2005              [Page 35]
  

                  SIP Telephony Device Requirements         June 2004
  
  
   Hellström, 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 parts of this
   Internet Draft. 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.
  
     10. Author's Addresses
  
     Henry Sinnreich
     MCI
     400 International Parkway
     Richardson, TX  75081, USA
     Email: henry.sinnreich@mci.com
     Phone : +1-972-729-4983
  
     Steven Lass
     MCI
     400 International Parkway
     Richardson, TX 75081, USA
     Email: steven.lass@mci.com
     Phone: +1 972 729 4469
  
     Christian Stredicke
     snom technology AG
     Pascalstrasse 10e
     10587 Berlin, Germany
     Email: cs@snom.de
     Phone: +49(30)39833-0
  
     11. Intellectual Property and Validity 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
  
  
   Sinnreich et al.    Expires – February 2005              [Page 36]
  

                  SIP Telephony Device Requirements         June 2004
  
  
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.
  
   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.
  
   Disclaimer of Validity
  
   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
  
   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.
  
   Acknowledgment
  
   Funding for the RFC Editor function is currently provided by the
   Internet Society.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
   Sinnreich et al.    Expires – February 2005              [Page 37]
  

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