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

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

   Internet Engineering Task Force        I. Butcher/Pingtel
   Internet Draft                         S. Lass/MCI
   draft-sinnreich-sipdev-req-02.txt      D. Petrie/Pingtel
   October 2003                           H. Sinnreich/MCI - editor
                                          C. Stredicke/snom

         SIP Telephony Device Requirements, Configuration and Data


   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-

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   The list of Internet-Draft Shadow Directories can be accessed at


   This 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. The document
   reviews the generic requirements for SIP telephony devices, the
   automatic device configuration process, device configuration data
   and examples for XML configuration data formats.

   SIP telephony devices are highly complex IP endpoints that speak
   many Internet protocols, have text, audio and visual interfaces,
   various input modes, and require functionality targeted at several
   constituencies: (1) End users, (2) service providers and network
   administrators and (3) manufacturers and system integrators.

   The objectives of the requirements are a minimum set of
   interoperability and multi-vendor supported core features, so as to

   Henry Sinnreich             Page 1                      10/15/2003

                  SIP Telephony Device Requirements         July 2003

   enable similar ease of purchase, installation and operation as found
   for standard PCs, analog feature phones or mobile phones.

   Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC-2119 [2].

   Table of Contents

   1. Introduction...................................................1
   2. Generic Requirements...........................................1
      2.1 Link Layer Requirements....................................1
      2.2 IP Requirements............................................1
      2.3 SIP Transport Requirements.................................1
      2.4 SIP User Agent Services....................................1
      2.5 Support for SIP Services...................................1
      2.6 SIP and Other Related Protocols............................1
      2.7 SIP Security...............................................1
      2.8 Voice Codecs...............................................1
      2.9 Voice-Telephony Requirements...............................1
      2.10 International Requirements................................1
      2.11 Support for Applications..................................1
      2.12 Web-based Feature Management..............................1
      2.13 Firmware Update...........................................1
      2.14 Firewall/NAT Traversal....................................1
      2.15 Device Interfaces.........................................1
   3. Automatic Configuration........................................1
   4. Configuration Settings.........................................1
      4.1 Device ID..................................................1
      4.2 Network Related Settings...................................1
      4.3 Address Completion.........................................1
      4.4 Audio......................................................1
      4.5 Local and Regional Parameters..............................1
      4.6 Inbound authentication.....................................1
      4.7 Voice mail settings........................................1
      4.8 Phonebook and Call History.................................1
      4.9 User Related Settings and Roaming..........................1
      4.10 Line Related Settings.....................................1
      4.11 Line Identification.......................................1
      4.12 Maximum connections.......................................1
   5. Examples of Configuration Data.................................1
      5.1. Requirements for Configuration Data Representation........1
      5.2 Configuration Data Format..................................1

        H. Sinnreich          Informational                    [Page 2]

                  SIP Telephony Device Requirements         July 2003

      5.3 Format Definition..........................................1
      5.4 Handling of Unrecognized Element Names.....................1
      5.5 XML Configuration Data.....................................1
      5.6 Device settings............................................1
      5.7 User settings..............................................1
   6. IANA Considerations............................................1
   7. Configuration Security.........................................1
   8. Changes........................................................1
      8.1 Changes since draft-sinnreich-sipdev-req-01................1
   9. Acknowledgements...............................................1
   10. Authors Addresses.............................................1
   11. References....................................................1
   11. Full Copyright Statement......................................1

   1. Introduction

   This informational I-D has the objective of focusing the Internet
   communications community on requirements for telephony devices using
   SIP [3].
   We base this information from developing and using a large number of
   SIP telephony device types and on the experience gained from large
   scale deployments 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

   SIP devices MAY also support various other media besides voice, such
   as text, video, games and also possibly other Internet applications;
   however the non-voice requirements are not specified in this
   document, except when providing enhanced telephony features, as will
   be shown.

   The objectives of the requirements are a minimum set of
   interoperability and multi-vendor supported core features, so as to

        H. Sinnreich          Informational                    [Page 3]

                  SIP Telephony Device Requirements         July 2003

   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, and the larger number of phones compared to PCs,
   similar or even better ease of use as compared to personal computers
   and networked PDAs is expected by both end users and network

   As will be seen from the following, 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 system

   The high complexity of SIP telephony devices is a normal consequence
   of placing Internet services in the endpoints.

   2. Generic Requirements

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

   2.1 Link Layer Requirements

   SIP devices MUST support either:

   Link-1: Wired Ethernet IEEE 802.3 10Base-T 10 Mb/s Half Duplex, or

   Link-2: Wireless Ethernet 802.11a/b/g

   SIP devices MAY also support other link layer protocols, such as

   Link-3: IEEE 802.3 10Base-T Full Duplex

   Link-4: IEEE 802.3 100Base-T Half Duplex

   Link-5: IEEE 802.3u 10/100Mb Auto-sensing

   Link-6: SIP devices MAY support VLAN tagging as per IEEE 802.1q

   Link layers used in 3rd generation mobile phone networks are out of
   the scope for this document.

        H. Sinnreich          Informational                    [Page 4]

                  SIP Telephony Device Requirements         July 2003

      Power over Ethernet

   Power-1: SIP telephony devices intended for desktop use MAY support
   in-line power over Ethernet as specified in IEEE 802.3af.

      Integrated Switch/Hub

   SIP devices designed for wired Ethernet SHOULD have an uplink port
   such that another IP device, such as a personal computer, MAY share
   the network connection. SIP clients MUST prioritize the transmission
   of the RTP traffic over the shared network connection.

   2.2 IP Requirements

   IP-1: SIP telephony devices MUST be able to acquire an IP address
         Automatic IP address configuration using DHCP, or
         Manual IP address entry from the device.

   IP-2: SIP devices MUST support multiple DNS entries. If the primary
   DNS server does not respond to a DNS request, a secondary DNS server
   MUST be queried.

   IP-3: SIP devices MUST support IPv4 DSCP field for RTP streams that
   supercedes the TOS bits described in RFC 791. The DSCP bit setting
   MUST be possible to be configured by either the user or
   automatically by the downloaded configuration data. The Assured
   Forwarding DSCP value Low Drop Precedence for RTP voice packets MUST
   be 100010 [4].

   IP-5: SIP devices SHOULD support IP version 6.

   2.3 SIP Transport Requirements

   Transport-1: SIP devices MUST support UDP transport of SIP messages.

   Transport-2: SIP devices MUST support TCP transport of SIP messages.

   Transport-3: SIP devices MAY support RSVP (RFC 2205).

   2.4 SIP User Agent Services

        H. Sinnreich          Informational                    [Page 5]

                  SIP Telephony Device Requirements         July 2003

   The requirements listed in this section may be used for device
   testing. To verify correct functionality for specific services, the
   support for the requirements in the next section should be tested.

   SIP telephony devices MUST support the guidelines for the
   distributed model of multi-party call control for SIP [5].

   The various call features listed here are also described in detail
   in the SIP Service Examples [6].

   SIP-1: SIP telephony devices MUST support RFC 3261 [3].

   2.4.1 DNS Lookup and ENUM Support

   SIP-2, DNS SRV: SIP devices MUST support RFC 3263 [7] for locating a
   SIP Server and select a transport protocol using NAPTR. When making
   a SRV query, the client MUST use the additional information in the
   response that contains the IP addresses for the A records.

   If the DNS additional information is not present, the client MUST
   make DNS A record queries to resolve the host names.

   If the destination SIP device is specified as an IP address, the SIP
   client MUST not attempt to resolve the address with DNS as specified
   in RFC 3263.

   If the destination SIP device is a string value, the SIP client MUST
   make normal DNS SRV and A record queries as specified in RFC 3263.

   Clients SHOULD support ENUM lookup as specified in the update to RFC
   2916 [8]

   2.4.2 Basic Telephony

   SIP-3, do not disturb: Users MUST be able to set the state of the
   device to do not disturb (DND).

   The change of the DND state SHOULD be communicated in a NOTIFY
   message with a tuple for this device to a configured presence

   Re-invite: Clients MUST respond to new INVITES with a ô486 Busy
   Hereö. Clients MUST respond to re-INVITES on existing dialogs as
   normal behavior.

        H. Sinnreich          Informational                    [Page 6]

                  SIP Telephony Device Requirements         July 2003

   SIP-4, call hold resume: SIP clients MUST follow RFC 3264 [9] when
   placing a call on hold. More specifically, the a=sendonly attribute
   MUST be used. The SDP answer of SIP clients that are being placed on
   hold MUST NOT contain "held" SDP, unless the user session was
   originally on hold.

   SIP-5, multiple calls: SIP clients that support call on hold MUST be
   able to support at least two or more calls.  By placing the current
   call ôon holdö, the client MUST be able to initiate or receive
   another call.

   SIP-6, call waiting indicator: SIP clients MUST support a call
   waiting indicator.  When already 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 call waiting.

   SIP-7, message waiting indicator: SIP clients MUST support SIP
   message waiting [10] and the integration with voicemail platforms.

   SIP-8, local dial plan: SIP clients MAY support a local dial plan.
   The dial plan MUST consist of a pattern string to match dial digits,
   and the ability to strip, append prefix digits, and/or append suffix
   digits and send messages directly to another SIP device, bypassing
   the proxy.

   Note: Mobile SIP phones or PCs may not need a dial plan.
   When using URL's and calling in the local domain, the local domain
   (@domain) MAY be appended to facilitate calling.

   SIP-9, transfer: SIP devices MUST support REFER and NOTIFY as
   required to support the transfer [11]. SIP clients MUST support
   escaped headers in the Refer-To: header.

   SIP-10, unattended transfer: SIP devices MUST support an unattended
   transfer. SIP clients MUST support escaped headers in the Refer-To:

   SIP-11, attended call transfer: SIP devices MUST support attended
   call transfer. SIP clients MUST support escaped headers in the
   Refer-To: header.

   SIP-12, device based conferencing: SIP devices MAY be able to
   support device based conferencing. A SIP client MAY be able to
   initiate and mix the audio streams of at least 2 separate calls
   (i.e. 3 way conference calling).

        H. Sinnreich          Informational                    [Page 7]

                  SIP Telephony Device Requirements         July 2003

   SIP-13, DMTF in-band mixing: SIP devices MUST generate in-band DTMF
   tones for use with the G.711 codec.

   SIP-14, DTMF RTP payload: SIP clients MUST be able to send DTMF
   specified by RFC 2833 [12].

   RFC 2833 negotiation must behave as follows: Receiving endpoint must
   reply with payload type sent by initiator. For example, if the
   initiating client sends payload type 101, receiving endpoint must
   reply with payload type 101.

   Payload type negotiation MUST comply with RFC 3264 and with the
   registered MIME types for RTP payload formats in RFC 3555.

   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
   initial payload type. SIP devices SHOULD support Flow Identification
   (FID) as defined in RFC 3388 [13].

   SIP-15, 180 ignores earlier media: SIP devices MUST generate local
   ringing and MUST ignore any early RTP media when a ô180 Ringingö
   response is received.

   SIP-16, play single early media stream: SIP devices MUST play the
   first RTP stream and ignore any other RTP media streams when a ô183
   Session Progressö response is received.

   SIP-17, use the last 18x message received: SIP 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.

   SIP-18, call-info: SIP devices with a display MUST support the call-
   info header and depending on the display capabilities MAY for
   example to display an icon or the image of the caller.

   SIP-19, error-info support: SIP devices MUST support the Error-Info

        H. Sinnreich          Informational                    [Page 8]

                  SIP Telephony Device Requirements         July 2003

   SIP-20, reason phrase display: If the SIP device displays prior
   messages, the client MUST use the ôReason Phraseö of the   response

   The client MAY use an internal ôStatus Codeö table if there was a
   problem with the language negotiation.

   SIP-21: SIP devices MUST support music on hold as shown in "SIP
   Service Examples" [5].

   SIP-22: SIP devices SHOULD support the OPTION method as per RFC

   SIP-23, fax support: SIP adapter devices (for analog phone lines)
   MUST support the ITU-T T.38 standard [14] using UDPTL [15]. SIP
   devices MUST fallback to G.711 if T.38 fails.

   2.4.3 Multi-line Requirements

   SIP-24, multi-line support: Multi-line SIP devices MUST register
   using more than one set of credentials.

   SIP-25, multi-line do not disturb: SIP multi-line devices MUST be
   able to set the state of the client to do not disturb on a per line
   Clients MUST respond to new INVITES with a ô486 Busy Hereö. Clients
   MUST respond to re-INVITES on existing dialogs as normal.

   SIP-26, multi-line call waiting indicator: Multi-line SIP devices
   MUST support multi-line call waiting indicators.  When already
   participating in a call, the user MUST be alerted audibly and/or
   visually of another incoming call. This setting MUST be provisioned
   by the user.

   SIP devices with multiple identities (ie. registrations/lines) MUST
   allow the call waiting indicator to be set on a per identity basis.
   If the call waiting is set for an identity, the client MUST respond
   with ô486 Busy Hereö when an incoming call to that identity is
   received and the client has an existing call with any of the

   SIP-27, multi-line ring tones: SIP devices MUST be able to provision
   a different ring tone for each line (i.e. registration or static

        H. Sinnreich          Informational                    [Page 9]

                  SIP Telephony Device Requirements         July 2003

   2.4.4 User Mobility

   SIP-28, dynamic login/logout for user mobility: SIP devices SHOULD
   support user mobility.  SIP clients MAY store a static profile in
   non-volatile memory so that this information is available during the
   power up sequence. SIP clients MAY allow a user to walk up to a
   client, login, and be able to send and receive calls with his/her
   profile information.

   2.4.5 Emergency Features

   SIP-29, For emergency numbers (e.g. 911, SOS URL) the client MUST
   send the credentials (username and password) of the static profile.

   SIP-30, Priority header: SIP devices SHOULD support the Priority
   header for such applications as emergency calls or for selective
   call acceptance.

   SIP-31: SIP telephony devices that are used in environments that
   support emergency preparedness SHOULD also support the sending and
   receiving of the Resource-Priority header as specified in [16]. 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 communications
   requests arrives.

   2.4.6 Interactive text support

   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
   described in RFC 3351 [17] and also for interactive text [18]

   Note: SIP telephony devices supporting Instant Messaging based on
   the SIMPLE standard allow text conversation based on blocks of text.
   However, interactive text conversation is due to its streaming-like

        H. Sinnreich          Informational                   [Page 10]

                  SIP Telephony Device Requirements         July 2003

   SIP-32: 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. In addition, SIP telephony devices SHOULD provide an
   external standard wired or wireless interface or interfaces to
   connect external input and display devices.

   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.

   There may be value of having RFC2793 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.

   SIP-34: A SIP telephony device MAY provide analog adaptor
   functionality through an RJ-11 (FXS) port. A 2.5 mm audio port MAY
   also be provided, especially for portable SIP devices, such as PDAs
   and 'Wi-Fi' SIP mobile phones.

   If an RJ-11 (FXS) port is provided, then it MAY support a gateway
   function from all text-telephone protocols according to ITU-T
   Recommendation V.18 to RFC 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.

   2.5 Support for SIP Services

   SIP devices used for enterprise communications SHOULD support the
   call flows for the basic and enhanced SIP services. The list here
   MAY be used for system integration testing to support specific
   commercial services.

   The schema for uploading the identity from a PDA is outside the
   scope of these requirements.

        H. Sinnreich          Informational                   [Page 11]

                  SIP Telephony Device Requirements         July 2003

   The call flows illustrated in the references shown below assure not
   only minimal support for SIP phones, as required for PSTN-style
   consumer services, but also for the most widely used Centrex-style
   and PBX-style services.

   All services shown here are compliant with the multiparty party call
   control framework for SIP [5].

   The following IETF references for rich presence, instant messaging,
   caller preferences and service mobility specify SIP specific
   services that go beyond the capability of PSTN and PBX based
   services and can be best supported by SIP telephony devices.

   Srv-1: SIP Call Flow Examples [19],

   Srv-2: SIP Service Examples [20],

   Srv-3: SIP PSTN call flows [21],

   Srv-4: Third Party Call Control in SIP [22],

   Srv-5: Other SIP call control and multiparty features [5],

   Srv-6: SIP devices MAY support conferencing services [23] for voice
   and IM [24], so as to be able act as host for a 3-way conference at

   Srv-7: Rich Presence based services [25],

   Srv-8: Caller and called party preferences [26],

   Srv-9: Service mobility: SIP desk 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.

   2.6 SIP and Other Related Protocols

   SDP: SIP devices MUST support Session Description Protocol, RFC 2327

   RTP/RTCP: SIP devices MUST support Real-Time Protocol and Real-Time
   Control Protocol, RFC 1889. SIP devices SHOULD use RTCP Extended

        H. Sinnreich          Informational                   [Page 12]

                  SIP Telephony Device Requirements         July 2003

   Reports for logging and reporting on network support for voice
   quality [28] and MAY also support [29].

   SIP clients MUST support the Simple Network Time Protocol (RFC2030),
   or use the Date: header of the 200 OK in response to a REGISTER

                            Network Management

   SNMP: SIP clients SHOULD support SNMP reporting.  SIP clients SHOULD
   support the RTP and RTCP MIBs to report jitter, delay, and packet

   2.7 SIP Security

   Sec-1: SIP devices MUST support digest authentication as per RFC

   Sec-2: SIP devices MUST be able to password protect configuration
   information and administrative functions.

   Sec-3: SIP devices MUST not display the password to the user or
   administrator after it has been entered.

   Sec-4: SIP clients MUST be able to disable remote access, i.e. block
   incoming SNMP, HTTP, and other services not necessary for basic

   Sec-5: SIP clients MUST be able to reject an incoming INVITE where
   the user-portion of the SIP request URI is blank or does not match a
   provisioned Contact. The setting to accept/reject MUST be

   Sec-6: SIP clients MUST be able to reject an incoming INVITE when
   the message does not come from the proxy or proxies where the client
   is registered.  For DNS SRV specified proxy addresses, the client
   must accept an INVITE from all of the resolved proxy IP addresses.

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

        H. Sinnreich          Informational                   [Page 13]

                  SIP Telephony Device Requirements         July 2003

   Many, but not all voice codec payload types are described in RFC
   3550 [30], while RFC 3555 lists 22 registered MIME subtypes for
   audio codecs.

   Codec-1: Three main classes of voice codecs MAY be supported by
   Internet telephony devices; (1) default G.711, (2) compressed and
   (3) wideband. At least two codecs, the default G.711 codec and one
   compressed codec listed below MUST be supported.

   1. SIP telephony devices MUST support AVT payload type 0 (G.711
   uLaw) as the default codec. The packet size MUST be 20 milliseconds.
   The matching ITU-T Appendix I and Appendix II decoders SHOULD also
   be supported.

   2. The compressed Internet Low Bit Rate codec (iLBC) [31], [32] MUST
   be supported.

   Other compressed codecs SHOULD be supported. Compressed Voice codecs
   used in 2nd and 3rd generation mobile phone systems, such as various
   GSM codecs are also found in various implementations and SHOULD be

   The narrow bandwidth codecs such as G.723.1 with such low speed as
   5.3 kb/s and 6.3 kb/s (without RTP/UDP/IP overhead) as to work well
   even on dial-up access MAY be supported.

   Compressed codecs such as G.729 derived from delta-PCM encoding,
   found in networks with frugal Internet access bandwidth using frame
   relay or DSL access MAY be supported.

   3. Wideband codecs using typically 16 kHz voice sampling for better-
   than-PSTN voice quality, such as G.722 and other MAY be supported.
   Such codecs are found in conferencing systems to increase the
   perceived quality of conferencing.

   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 [33] that can effectively be
   substituted for most of the multiple codec types listed here, except
   the Internet Low Bit Rate codec (iLBC) and avoid the complexity and
   cost implementers and service providers alike are faced by
   supporting so many codec types, including especially those that have
   not been developed specifically for Internet use.

        H. Sinnreich          Informational                   [Page 14]

                  SIP Telephony Device Requirements         July 2003

   Codec-2, codec negotiation: Endpoints MUST follow these guidelines
   in RFC 3264: Initiator specifies "preferred" codec and the receiver
   has "final" choice of codec selected.
   This includes the codec negotiations for the various G.723 and G.729
   codec types listed in RFC 3555.

   Both endpoints MUST use the first matching codec listed by the

   If an endpoint cannot dynamically switch between available codecs,
   it MUST offer a single codec and send a new INVITE with another
   codec if the original fails due to the SIP 488 "Media Unsupported"

   Codec-3, comfort noise: SIP devices MAY support comfort noise
   generated in the receiver, without using up end-to-end bandwidth. It
   is also RECOMMENDED that SIP clients comply with performance
   specified for the "handset receive comfort noise" requirements
   outlined in the ANSI/EIA/TIA-810-A-2000 standard.

   2.9 Voice-Telephony Requirements

   Voice-1, loudness: SIP telephony devices MUST conform to the
   electro- acoustical requirements for send loudness rating (SLR),
   receive loudness rating (RLR), weighted terminal coupling loss
   (TCLw), stability loss, etc.) of the TIA/EIA standards [34], and

   Stability loss is a measure of the contribution of the telephone set
   or terminal to the overall connection stability requirements.
   Stability loss is defined as the minimum loss from the terminal
   digital input (receive) to the terminal digital output (transmit),
   at any test frequency.

   Voice-2, stability loss: SIP device SHOULD meet the following
   stability loss requirements.

   The stability or minimum loss, per ITU-T G.177, TIA/EIA-810-A and
   TIA/EIA-579-A, at any voice-band frequency SHOULD be greater than 6
   dB, and preferably greater than 10 dB. Digital telephone sets or
   terminal equipment with adjustable receive level SHOULD maintain
   stability over the entire range of adjustable receive levels.

   Voice-3, speakerphone: SIP devices MAY provide a full-duplex
   speakerphone with echo and side-tone cancellation.

        H. Sinnreich          Informational                   [Page 15]

                  SIP Telephony Device Requirements         July 2003

   Voice-4, programmable ring-tones: SIP device MAY be able to use
   different ring-tones based on the caller identity (i.e. From:

   2.10 International Requirements

   International-1, language support: SIP devices SHOULD indicate the
   preferred language using SIP Caller Preferences. The setting for
   this header MUST be provisioned.

   International-2, international display support: SIP devices intended
   to be used in various language settings, MUST support other
   languages for menus, help, and labels.

   2.11 Support for Applications

   The following requirements apply to functions placed in the SIP
   telephony device.

   App-1, SIMPLE Integration: SIP devices that support presence MUST
   provide a buddy list and use SIP extensions to leverage presence

   App-2, address-book integration: SIP devices SHOULD allow a 3rd
   party to initiate a call for the client, such as using the address
   book in the PC to initiate a call.

   App-3, LDAP phonebook: SIP devices MAY support LDAP for client-based
   directory lookup.

   App-4, automatic ring-down: SIP devices MAY support a phone setup
   where a URL is automatically dialed when the client goes off-hook.

   App-5, hold ring-back: SIP devices MAY ring after a call has been on
   hold for a predetermined period of time, typically 3 minutes. This
   time value MUST be provisioned.

   2.12 Web-based Feature Management

   Web-1: SIP 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

        H. Sinnreich          Informational                   [Page 16]

                  SIP Telephony Device Requirements         July 2003

   telephony device SHOULD be supported by the individual device, or in
   managed networks from centralized web servers. Managing SIP
   telephony devices SHOULD NOT require special client software on the
   PC or on a management console.

   Web-2: The telephone settings MAY be accessible to authenticated
   users or operations personnel from remote locations.

   2.13 Firmware Update

   Firm-1: SIP devices MUST be able to upgrade their firmware as
   described in section 3.

   2.14 Firewall/NAT Traversal

   The following requirements allow SIP clients to properly function
   behind various firewall architectures.

   FW/NAT-1, outbound proxy support: SIP devices MUST support a default
   domain used for NAT traversal. SIP devices MUST have the capability
   to be configured so that the default domain and the outbound SIP
   proxy are different.

   The provisioned user identity on the device MUST include a full URL
   to be included in the SIP From: header or a provisioned domain name
   MUST be appended.

     Configuration Information

     Name: userA
     Proxy Address: sip.outbound.domain.com
     Domain: domain.com

     Example Message sent to sip.outbound.domain.com

     REGISTER sip:domain.com SIP/2.0
     To: sip:userA@domain.com
     From: sip:userA@domain.com
     Contact: sip:

   FW/NAT-2, NAT capable configuration: SIP devices MUST be able to
   operate behind a static NAT/PAT (Network Address Translation/Port
   Address Translation) device using the STUN protocol [37]. SIP
   clients MUST be able to populate SIP messages with the public,

        H. Sinnreich          Informational                   [Page 17]

                  SIP Telephony Device Requirements         July 2003

   external address of the NAT/PAT device and use specific port ranges
   for RTP.

   FW/NAT-3, UPnP capable configuration: SIP devices MAY be able to
   operate with a UPnP (http://www.upnp.org/) firewall device. UPnP
   will support the traversal of the local NAT/FW and is adequate on
   its own when no other NATs are placed in the service provider

   FW/NAT-4, STUN capable configuration: SIP telephony devices MUST be
   able to operate with a STUN server.

   2.15 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 personal organizer. Given the variety
   of possible interfaces, the generic requirements only can be listed

   Int-1: SIP telephony devices MUST have a telephony-like dial-pad and
   MAY have telephony style buttons like mute, redial, transfer,
   conference, hold, etc.

   Int-2: 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 or graffiti for PDAs.

   Phone number entry SHOULD be supported in human friendly fashion, by
   allowing the usual separators and brackets between digits and digit

   Int-3: SIP telephony devices MUST have two types of interface
   capabilities, for both phone numbers and URLs, both accessible to
   the end user.

   1. SIP device configuration and management interface:

   SIP telephony adapters and high end phones MAY support SNMP v.3 for
   managing the device. The required MIB is outside the scope of this

        H. Sinnreich          Informational                   [Page 18]

                  SIP Telephony Device Requirements         July 2003

   The access to the SIP device configuration interface MAY be blocked
   by the service provider so as not allow misconfiguration of the

   2. End user options interface: Such as personal address book, auto-
   forwarding, ringer tones, etc.

   Desktop and other phone-style SIP devices can meet the above
   requirements with a device web page. Device web pages may also
   facilitate remote device settings from a help desk, without user

   3. Automatic Configuration

   Automatic SIP telephony device configuration SHOULD use the
   processes and requirements described in [38] and [39].

   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

   Image and service data upgrades SHOULD also not require any settings
   by the user.

   4. Configuration Settings

   Besides network parameters, SIP telephony devices MAY also be
   configured with user data described here.

   Settings are the information on a client that it needs to be a
   functional SIP endpoint. It is an implementation choice whether the
   device stores the data across power cycles and hardware restarts or
   it reloads the data every time upon startup. The settings defined in
   this document are not intended to be all inclusive. It MUST be
   possible for vendor specific parameters to be added. Parameters
   which are not understood by an end point MUST be ignored.

   The list of available configuration 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.

        H. Sinnreich          Informational                   [Page 19]

                  SIP Telephony Device Requirements         July 2003

   Settings MAY be read-only on the device. This avoids the
   misconfiguration of important settings by inexperienced users
   generating service cost for operators. This draft describes how
   operator MAY protect some settings from end users.

   In order to achieve wide adoption of any configuration settings
   format it is important that it not be excessive in size so as to
   allow 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 line. When the endpoint
   acts in the context of a line, it will first try to look up a
   setting in the line 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 line concept allows configuration of phones in a user specific
   context. It simplifies unconstrained seating in offices, can support
   roaming users and allows users to subscribe to more than one service

   In principle, all settings MAY be present in line and in device
   context. For some settings (e.g. the MAC address of the device),
   devices MAY set restrictions on the availability of settings in
   either line or device context.

   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.

   4.2 Network Related Settings

   Network-1: SIP Ports. The port that MUST be used for a specific
   transport protocol MAY be indicated with the SIP ports setting. If
   this setting is omitted, the device MAY choose any port.

   Network-2: Quality of Service. The Quality of Service 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 necessary

        H. Sinnreich          Informational                   [Page 20]

                  SIP Telephony Device Requirements         July 2003

   quality. The settings are independently configurable for the
   different transport layers and signaling, media or administration.

   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 (IEEE 802.1D/Q) of the network protocol stack.

   Network-3: Network parameters. The parameters for SIP (like timer
   T1) and other network related settings MAY be indicated. An example
   of usage would be the reduction of the DNS SRV failover time.

   Network-4: 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 RCTP) for each
   concurrent connection. This is required to support firewall
   traversal. This again helps network operators to identify voice
   packets and makes it possible to configure port ranges on firewalls
   only for voice packets.

   Network-5: Registration period. A line definition MAY contain a
   period (in seconds) which once exceeded will cause the device to re-
   register its registration server(s). The default value is one hour.

   Network-6: Default Call Handling. All of the call handling settings
   defined below in section 5.3.2 can be defined here as default

   Network-7: Outbound Proxy. The outbound proxy for a line or for a
   device MUST be set. The address is encoded as SIP URI. The setting
   MAY contain alternative outbound proxies, which MAY be used in case
   of a server failure.

   Using this setting, private networks can control outbound traffic
   and send it through an application layer gateway.

   Network-8: Default Outbound Line. The default outbound line SHOULD
   be a global setting (not related to a specific line). This setting
   MUST not be used as part of a line definition.

   Network-9: 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. If there is no value provided, the device MAY use
   a default value (e.g. 3600 seconds).

        H. Sinnreich          Informational                   [Page 21]

                  SIP Telephony Device Requirements         July 2003

   4.3 Address Completion

   As most telephone users are used to dialing digits to indicate the
   address of the destination, there is a need for specifying the rule
   by which digits are transformed into a URL (usually SIP URL or TEL

   Dial-1: SIP phones need to understand entries into the phone book of
   the most common separators used between dialed digits, such as
   spaces, angle and round brackets, dash and dots.

   Dial-2: Dial Plan and/or Dial/OK key. A dial plan which defines the
   maximum expected length of a typical telephone number MAY be used.
   If no dial plan is used, the device MUST have a "Dial" or "OK" key,
   similar to mobile phones.

   Zero or more digit maps which map a dial plan and a SIP address to
   which phone numbers of that type SHOULD be routed to SHOULD be
   supported. The digit maps define numeric patterns that when matched

   1) A rule by which the end point can judge that the user has
   completed dialing, and
   2) A rule to construct a URL from the dialed digits, and 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
   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.

   Dial-3: Default Digit Map. The end point SHOULD support the
   configuration of a default digit map. If the end point 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.

   Dial-4: Overlap-Dial. Some operators support overlap dialing and
   MAY want to indicate to the SIP devices that this mode is to be
   used. This setting is Boolean and MAY be set to true or false.

        H. Sinnreich          Informational                   [Page 22]

                  SIP Telephony Device Requirements         July 2003

   4.4 Audio

   Audio-1: 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 range for parameters of the codecs MUST be adjustable. This
   includes the packet length (ms of audio), which is a function of
   the sample rate.
   However, the negotiation of the media for individual calls is being
   done on a per call basis.

   Audio-2: DTMF method. DTMF allows different ways of indicating that
   a key has been pressed as per RFC 2833. The method for sending these
   events SHOULD be configurable with the order of precedence.

   Audio-3: Silence suppression. It SHOULD be possible to disable
   silence suppression on the end point such that RTP audio packets are
   sent even if silence is detected.

   4.5 Local and Regional Parameters

   Certain settings are dependent upon the devices regional location,
   such as the daylight saving time rules and the time zone.

   Regional-1: Time Zone. A time zone MAY be specified for the user.
   Where one is specified; it SHOULD use the scheme used by the Olson
   Time One database [40]. 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.

   Regional-2: UTC Offset. An offset from Coordinated Universal Time
   (UTC) in seconds MAY be used.

   Different rules exist for when daylight saving time (DST) starts and
   ends. For example in North America begins on the first Sunday in
   April whereas in Western Europe is begins on the last Sunday in

   Regional-3: A DST rule MAY be used by the device.

        H. Sinnreich          Informational                   [Page 23]

                  SIP Telephony Device Requirements         July 2003

   The network addresses of SNTP (RFC 2030) time servers where the
   device can get a centrally defined time value MAY be used.

   Regional-4: The time server MAY be used. DHCP is the preferred way
   to provide this setting. Setting the correct language is important
   for simple installation around the globe.

   Language-1: Language settings MAY be deployed. A language MAY be
   specified for a device. Where it is specified it SHOULD use the
   codes defined in RFC3066 [41] to provide some predictability.

   Language-2: It is RECOMMENDED that servers set the Language as
   writable, so that the user MAY change this. This setting SHOULD NOT
   be line related.

   Language-3: A SIP UA MUST be able to parse and accept requests
   containing international characters encoded as UTF-8 even if it
   canÆt display those characters in the user interface.

   4.6 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

   In-Auth-1: A device SHOULD support the setting as to whether
   authentication (on the device) is required and what type of
   authentication is REQUIRED: NONE or DIGEST.

   In-Auth-2: 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 a line (i.e. URL, user, password digest and realm). This applies
   to SIP control signaling as well as call initiation. The list shows
   for example who is allowed to send a REFER or an INVITE with the
   Join or Replaces header.

   4.7 Voice mail settings

   VM-1: Various voice mail settings require the use of URL's as
   specified in [42].

   VM-2: The message waiting indicator (MWI) address setting controls
   where the client SHOULD SUBSCRIBE to a voice mail server and what
   MWI summaries MAY be displayed [43].

        H. Sinnreich          Informational                   [Page 24]

                  SIP Telephony Device Requirements         July 2003

   4.8 Phonebook and Call History

   IP Telephony devices MAY store locally a phonebook and also the
   history of recent calls.

   Phonebook-1: SIP telephony devices MAY store telephone book entries
   locally and/or MAY use a central LDAP directory.

   Call History-1: SIP telephony devices MAY store locally a recent
   (limited) call history. Devices that are not able to differentiate
   call history entries   between "tried" and "dialed" SHOULD use

   4.9 User Related Settings and Roaming

   A device MAY specify the user which is currently registered on the
   device. This SHOULD be an address-of-record URL specified in a line

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

   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 lines (e.g. one or more personal lines 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
   lines would roam with them.  The alternative to this is to require
   the agent to individually configure all of the lines individually

        H. Sinnreich          Informational                   [Page 25]

                  SIP Telephony Device Requirements         July 2003

   (this would be particularly irksome using standard telephone button

   The management of user profiles, aggregation of user or device lines
   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.

   UserID:  User ID MAY be specified. If the user ID is specified, the
   address-of-record URL MAY be specified for the line definition.

   4.10 Line Related Settings

   SIP telephony devices MUST use the line related settings, as
   specified here.

   4.11 Line Identification

   A line represents an address-of-record identified by a URL.
   There are many properties which MAY be associated with or SHOULD be
   applied to the line or signaling addressed to or from the line.
   Lines MAY be defined for a device or a user of the device. At least
   one line MUST be defined in the configuration settings, this MAY
   pertain to either the device itself or the user.

   A line MUST provide an address or record URL which both
   distinguishes the line and provides the URL which optionally will be
   registered for the line.

   It MUST be possible to specify at least one set of realm, user name
   and authentication credentials for each line. The user name and
   authentication credentials are used upon authentication challenges.

   4.12 Maximum connections

   A setting defining the maximum number of simultaneous connections
   that a device can support MUST be used by the device. Obviously the
   end point has 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.

        H. Sinnreich          Informational                   [Page 26]

                  SIP Telephony Device Requirements         July 2003

   MaxConn: A SIP telephony device MAY support at least two
   connections for three-way conference calls that are locally hosted.

   5. Examples of Configuration Data

   The section describes the requirements and format for an
   implementation of the settings described in section 4.

   5.1. Requirements for Configuration Data Representation

   From reading the preceding section 4, it is apparent that many of
   the settings are composite and related. As the number and complexity
   of the settings grows it is useful from an administration point of
   view to be able to easily relate settings.

   This document recognizes that as features multiply on devices, so
   will the amount of settings. Any format proposed SHOULD be readily
   and intuitively extensible.

   5.2 Configuration Data Format

   The choices for the configuration data formats are best left to the
   discretion of the implementers and service providers.

   Open Issue: The authors believe it would be useful to specify a
   grammar for the default name space.

   This document illustrates however using XML as the file format for
   the configuration settings primarily for the reasons stated above.
   XML naturally maps the settings defined in section 4.

   Note for potential grammar designers and implementers: The authors
   believe it is very useful to have CDATA sections in XML documents
   where the content itself may break XML syntax rules. This is the
   case of SIP URLs. An example of is given in Example E below.

   XML namespaces are a useful tool when processing documents which MAY
   contain elements from more than one source. The default namespace
   for any XML document using the definitions described in this
   document MUST define the default namespace in the root node with a
   Vendors MAY add their own content within the XML document but MUST
   provide qualified names with their own namespace.

        H. Sinnreich          Informational                   [Page 27]

                  SIP Telephony Device Requirements         July 2003

   The general format for the XML data is to have device and user
   elements as direct children of the root node. Those elements will
   contain all of the appropriate settings describe in section 3.

   An example of an extension to the time zone setting is show below.

      <settings xmlnshttp://someurl
                   <dstrule>NORTH AMERICA</dstrule>
                   <!-- vendor extension -->

   5.3 Format Definition

   The definitions of the elements and attributes will not be included
   in this version of the draft, given that only examples are shown
   here. The examples follow to only illustrate some concepts of the
   format. Section 4 defines the requirements from which the XML
   elements and attributes will be derived. The authors believe the
   data format definitions and grammar for SIP telephony device
   configuration data SHOULD be the object of separate documents.

   5.4 Handling of Unrecognized Element Names

   The default rule is that any element with an unrecognized name is
   ignored (i.e. having an unrecognized namespace URI, or an
   unrecognized local name within that namespace). This includes all of
   the element content, even if it appears to use recognized names.

   5.5 XML Configuration Data

   This section aims to provide some samples of the settings defined in
   section 4, using XML [44]. A complete grammar/schema definition is
   not provided here, since this serves as an example only.

        H. Sinnreich          Informational                   [Page 28]

                  SIP Telephony Device Requirements         July 2003

5.6 Device settings

      A.  Network Settings

                   <ethnetDuplex value="full"/>

      B. Address Completion

          <dialplan length="10"/>

      C. Audio

                     <codec priority="1">G711</codec>
                     <codec priority="2">iLBC</codec>
                     <codec priority="3">G722</codec>

        H. Sinnreich          Informational                   [Page 29]

                  SIP Telephony Device Requirements         July 2003


      D. Line default settings

                     <busy behavior=busy/>
                     <callWaiting behavior=busy/>

      E. Line definition for device

        <line aor-url=&lt;Extension 123&gt;sip:1234@Pingtel.com
                     <available behavior=•forward-no-answer•>

   In this example the outbound proxy and call handling settings
   defined in the line default settings example SHOULD be used in
   addition to the line definition.

   Note: The authors' preference for potentially long values in XML is
   to use an element rather than an attribute.  Added to which, in an
   element you can wrap values which would normally break the XML
   syntax in a CDATA.  This would allow SIP URLs to be formatted
   without having to escape them.


   <line register=öprovisionö>
   <aor-url><[!CDATA[ôExtension 123ö<sip:1234@Pingtel.com>]]</aor-url>

        H. Sinnreich          Informational                   [Page 30]

                  SIP Telephony Device Requirements         July 2003

  5.7 User settings

      F. Voice mail settings


      G. Line definition for user

          <id>&lt;Fred Bloggs&gt;sip:fbloggs@Pingtel.com</id>
          <line aor-url=&lt;Fred Bloggs&gt;sip:fbloggs@Pingtel.com
                          <available behavior=busy/>

   Credentials are supplied for two realms in this example.  In this
   example the outbound proxy and call handling settings defined in the
   line default settings example SHOULD be used in addition to the line

   6. IANA Considerations

   SIP Event Package Registration for Configuration

   Package name: SIP Telephony Device Configuration

   Type: package

        H. Sinnreich          Informational                   [Page 31]

                  SIP Telephony Device Requirements         July 2003

   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.

   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. Configuration Security

   Please see also the above section 2.7 on SIP Security.

   The device configuration MAY contain 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 [45].
   For devices which use FTP or TFTP for content delivery this can be
   achieved using symmetric key encryption.

        H. Sinnreich          Informational                   [Page 32]

                  SIP Telephony Device Requirements         July 2003

   Access to retrieving configuration information is also an important
   issue. A configuration server SHOULD challenge a subscriber before
   sending configuration information.

   8. Changes

   8.1 Changes 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.

   9. Acknowledgements

   We would like to thank Rohan Mahy for contributing several
   clarifications to this document and especially for the leadership
   provided 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 with help from Rohan Mahy 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
   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.

   10. Authors Addresses

     Ian Butcher
     Pingtel Corp.
     400 W. Cummings Park
     Suite 2200
     Woburn, MA 01801, USA
     Phone: +1 781 938 5306

        H. Sinnreich          Informational                   [Page 33]

                  SIP Telephony Device Requirements         July 2003

     Email: ibutcher@pingtel.com

     Steven Lass
     400 International Parkway
     Richardson, TX  75081, USA
     EMail: steven.lass@mci.com
     Phone: +1 972 729 4469

     Daniel G. Petrie
     Pingtel Corp.
     400 W. Cummings Park
     Suite 2200
     Woburn, MA 01801, USA
     Phone: +1 781 938 5306
     Email: dpetrie@pingtel.com

     Henry Sinnreich
     400 International Parkway
     Richardson, TX  75081, USA
     EMail: henry.sinnreich@mci.com

     Christian Stredicke
     snom technology AG
     Pascalstrasse 10e
     10587 Berlin, Germany
     Phone: +49(30)39833-0
     Email: cs@snom.de

   11. 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] J. Rosenberg et. al.: "SIP: Session Initiation Protocol, RFC
       3261, IETF, June 2002.

   [4] RFC 2597: "Assured Forwarding PHB Group" by Heinanen, J. et al.
       IETF, June 1999.

        H. Sinnreich          Informational                   [Page 34]

                  SIP Telephony Device Requirements         July 2003

   [5] Mahy, R.et al., "A Call Control and Multi-party usage framework
       for the Session Initiation Protocol (SIP)", work in progress,
       IETF, March 2003.

   [6] Johnston, A. et al.: "SIP Service Examples", work in progress,
       February 2003.

   [7] RFC 3263: "Session Initiation Protocol (SIP): Locating SIP
       Servers" by J. Rosenberg and H. Schulzrinne. IETF, June 2002.

   [8] RFC 2916 bis: "The E.164 to URI DDDS Application (ENUM)" by
       Falstom, P. and Mealling M. IETF, May 2003.

   [9] RFC 3264: "An Offer/Answer Model with Session Description
       Protocol (SDP)" by J. Rosenberg and H. Schulzrinne. IETF, June

   [10] Mahy, R.: "A Message Summary and Message Waiting Indication
       Event Package for SIP". Work in progress, IETF March 2003.

   [11] RFC 3515: "The SIP Refer Method" by R. Sparks, IETF, April

   [12] RFC 2833: "RTP Payload for DTMF Digits, Telephony Tones and
        Telephony Signals" by H. Schulzrinne and S. Petrack. IETF, May

   [13] RFC 3388: "Grouping of Media Lines in the Session Description
        Protocol (SDP)" by G. Camarillo et al. IETF, December 2002.

   [14] ITU-T Recommendation T.38.

   [15] Johnston, A. et al.: "Session Initiation Protocol Torture Test
        Messages". Work in progress, IETF, August, 2002.

   [16] Schulzrinne, H. and Polk, J.: Communications Resource Priority
        for SIP. IETF, March 2003. Work in progress.

   [17] RFC 3351: User Requirements for the Session Initiation Protocol
        (SIP) in Support of Deaf, Hard of Hearing and Speech-impaired
        Individuals by Charlton, et. al. IETF, August 2002.

   [18] Hellstr÷m, G. and Roy, R.R.: "Framework of requirements for
        real-time text conversation using SIP". IETF, October 2003.

        H. Sinnreich          Informational                   [Page 35]

                  SIP Telephony Device Requirements         July 2003

   [19] Johnston, A. et al.: "Session Initiation Protocol Basic Call
        Flow Examples". Work in progress, IETF, August 2003.

   [20] Johnston, A. et al.: "Session Initiation Protocol Service
        Examples", work in progress, IETF, February 2003.

   [21] Johnston, A. and Donovan S: "Session Initiation Protocol PSTN
        Call Flows". Work in progress, IETF, November 2003.

   [22] Rosenberg, J., et al., "Best Current Practices for Third Party
        Call Control in the Session Initiation Protocol", work in
        progress, March 2003

   [23] Johnston A. and Levin O.: "Session Initiation Protocol Call
        Control - Conferencing for User Agents", work in progress,
        IETF, April 2003.

   [24] Rosenberg, J. and Isomaki A.: "Requirements for Manipulation of
        Data Elements in Session Initiation Protocol (SIP) for Instant
        Messaging and Presence Leveraging Extensions(SIMPLE) Systems",
        work in progress, IETF, August 2003.

   [25] Rosenberg, J., et al., "Rich Presence Information Data Format
        for Presence Based on the Session Initiation Protocol (SIP)",
        work in progress, IETF, August 2003.

   [26] Rosenberg, J. et al.: "Caller Preferences and Callee
        Capabilities for the Session Initiation Protocol (SIP)", work
        in progress, IETF, September 2003.

   [27] RFC 2327: "SDP: Session Description Protocol" by M. Handley and
        V. Jacobson. IETF, April 1998.

   [28] T. Friedman et al: "RTP Control Protocol Extended Reports (RTCP
        XR)", work in progress, IETF, April 2003.

   [29] Johnston, A. at al: "RTCP Summary Report Delivery to SIP Third
        Parties", IETF, June 2003. Work in progress.

   [30] H. Schulzrinne et al.: "RTP Profile for Audio and Video
        Conferences with Minimal Control", RFC 1890, IETF, January

   [31] Andersen,S.V. et al.: "Internet Low Bit Rate Codec", work in
        progress, IETF March 2003.

        H. Sinnreich          Informational                   [Page 36]

                  SIP Telephony Device Requirements         July 2003

   [32] Duric A. et al.: "RTP Payload Format for iLBC Speech", work in
        progress. IETF March 2003.

   [33] Herlein, G: "RTP Payload Format for the Speex Codec", work in
        progress, IETF, February 2003.

   [34] TIA/EIA-810-A, "Transmission Requirements for Narrowband Voice
        over IP and Voice over PCM Digital Wireline Telephones", July

   [35] TIA-EIA-IS-811, "Terminal Equipment - Performance and
        Interoperability Requirements for Voice-over-IP (VoIP) Feature
        Telephones", July 2000.

   [36] Rosenberg, J.: "A Presence Event Package for the Session
        Initiation Protocol (SIP)", work in progress, IETF, January

   [37] Rosenberg, J. et al: "STUN - Simple Traversal of User Datagram
        Protocol (UDP) Through Network Address Translators (NATs)".
        IETF, March 2003.

   [38] Petrie, D.: "A Framework for SIP User Agent Configuration",
        work in progress. IETF, February 2003.

   [39] Petrie, D. and Jennings, C.: "Requirements for SIP User Agent
        Profile Delivery Framework", work in progress, IETF, February

   [40] P. Eggert, "Sources for time zone and daylight saving time
        data." Available at http://www.twinsun.com/tz/tz-link.htm

   [41] H. Alvestrand "Tags for the Identification of Languages", RFC
        3066, IETF, January 2001.

   [42] R. Mahy et al.: " A Multi-party Application Framework for SIP",
        Internet Draft, IETF, June 2002, work in progress.

   [43] Mahy, R.: "A Message Summary and Message Waiting Indication
        Event Package for SIP", work in progress, IETF, march 2003.

   [44] T. Bray, J. Paoli, C. Sperberg-McQueen and E. Maler,
        "Extensible Markup Language (XML) 1.0 (Second Edition)",   W3C

        H. Sinnreich          Informational                   [Page 37]

                  SIP Telephony Device Requirements         July 2003

        Recommendation, October 2000, http://www.w3.org/TR/2000/REC-

   [45] RFC 2818: "HTTP over TLS" by E. Rescorla. IETF, May 2000.

   11. Full Copyright Statement

   Copyright (c) The Internet Society (2001). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an

        H. Sinnreich          Informational                   [Page 38]

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