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

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

SIPPING WG                               H. Sinnreich/pulver.com, editor
Internet Draft                                               S. Lass/MCI
                                                       C. Stredicke/snom
                                                           June 12, 2005

          SIP Telephony Device Requirements and Configuration
                   draft-sinnreich-sipdev-req-07.txt

Status of this Memo

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

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

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

   The list of current Internet-Drafts can be accessed at
   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 December 9, 2005.

Abstract

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

   We present a glossary of the most common settings and some of the
   more widely used values for some settings.


Sinnreich, et al        Expires December 11, 2005               [Page 1]

Internet-Draft   Device Requirements and Configuration         June 2005


Conventions used in this document

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

Table of Contents

   1.  Introduction....................................................3
   2.  Generic Requirements............................................4
      2.1.  SIP Telephony Devices......................................4
      2.2.  DNS and ENUM Support.......................................5
      2.3.  SIP Device Resident Telephony Features.....................5
      2.4.  Support for SIP Services...................................8
      2.5.  Basic Telephony and Presence Information Support...........8
      2.6.  Emergency and Resource Priority Support....................9
      2.7.  Multi-Line Requirements...................................10
      2.8.  User Mobility.............................................10
      2.9.  Interactive Text Support..................................11
      2.10. Other Related Protocols...................................12
      2.11. SIP Device Security Requirements..........................12
      2.12. Quality of Service........................................13
      2.13. Media Requirements........................................13
      2.14. Voice Codecs..............................................13
      2.15. Telephony Sound Requirements..............................14
      2.16. International Requirements................................15
      2.17. Support for Related Applications..........................15
      2.18. Web Based Feature Management..............................15
      2.19. Firewall and NAT Traversal................................15
      2.20. Device Interfaces.........................................16
   3.  Glossary and Usage for the Configuration Settings..............17
      3.1.  Device ID.................................................17
      3.2.  Signaling Port............................................18
      3.3.  RTP Port Range............................................18
      3.4.  Quality of Service........................................18
      3.5.  Default Call Handling.....................................18
         3.5.1.  Outbound Proxy.......................................18
         3.5.2.  Default Outbound Proxy...............................19
         3.5.3.  SIP Session Timer....................................19
      3.6.  Telephone Dialing Functions...............................19
         3.6.1.  Phone Number Representations.........................19
         3.6.2.  Digit Maps and/or the Dial/OK Key....................19
         3.6.3.  Default Digit Map....................................20
      3.7.  SIP Timer Settings........................................20
      3.8.  Audio Codecs..............................................21
      3.9.  DTMF Method...............................................21
      3.10. Local and Regional Parameters.............................21
      3.11. Time Server...............................................22


Sinnreich, et al        Expires December 11, 2005               [Page 2]

Internet-Draft   Device Requirements and Configuration         June 2005


      3.12. Language..................................................22
      3.13. Inbound Authentication....................................22
      3.14. Voice Message Settings....................................23
      3.15. Phonebook and Call History................................23
      3.16. User Related Settings and Mobility........................23
      3.17. AOR Related Settings......................................24
      3.18. Maximum Connections.......................................24
      3.19. Automatic Configuration and Upgrade.......................25
      3.20. Security Configurations...................................25
   4.  Security Considerations........................................25
      4.1.  Threats and Problem Statement.............................25
      4.2.  SIP Telephony Device Security.............................26
      4.3.  Privacy...................................................27
      4.4.  Support for NAT and Firewall Traversal....................28
   5.  IANA Considerations............................................28
   6.  Acknowledgments................................................29
   7.  Changes from Previous Versions.................................29
   8.  References.....................................................31
   9.  Author's Addresses.............................................36
   10. Copyright Notice...............................................36

1. Introduction

   This document has the objective of focusing the Internet
   communications community on requirements for telephony devices using
   SIP.

   We base this information from developing and using a large number of
   SIP telephony devices in carrier and private IP networks and on the
   Internet.  This deployment has shown the need for generic
   requirements for SIP telephony devices and also the need for some
   specifics that can be used in SIP interoperability testing.

   SIP telephony devices, also referred to as SIP User Agents (UAs) can
   be any type of IP networked computing user device enabled for SIP
   based IP telephony.  SIP telephony user devices can be SIP phones,
   adaptors for analog phones and for fax machines, conference
   speakerphones, software packages (soft clients) running on PCs,
   laptops, wireless connected PDAs, 'Wi-Fi' SIP mobile phones, as well
   as other mobile and cordless phones that support SIP signaling for
   real time communications.  SIP-PSTN gateways are not the object of
   this memo, since they are network elements and not end user devices.

   SIP telephony devices can also be instant messaging (IM) applications
   that have a telephony option.

   SIP devices MAY support various other media besides voice, such as
   text, video, games and other Internet applications; however the



Sinnreich, et al        Expires December 11, 2005               [Page 3]

Internet-Draft   Device Requirements and Configuration         June 2005


   non-voice requirements are not specified in this document, except
   when providing enhanced telephony features.

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

   The objectives of the requirements are a well defined set of
   interoperability and multi-vendor supported core features, so as to
   enable similar ease of purchase, installation and operation as found
   for standard PCs, analog feature phones or mobile phones.  Given the
   cost of some feature rich display phones may approach the cost of PCs
   and PDAs, similar or even better ease of use as compared to personal
   computers and networked PDAs is expected by both end users and
   network administrators.

   While the recommendations of this document go beyond what is
   currently mandated for SIP implementations within the IETF, this is
   believed necessary to support the specified operational objectives.
   However, it is also important to keep in mind that the SIP
   specifications are constantly being evolved, thus these
   recommendations need to be considered in the context of that change
   and evolution.

2. Generic Requirements

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

2.1. SIP Telephony Devices

   This memo applies mainly to desktop phones and other special purpose
   SIP telephony hardware.  Some of the requirements in this section are
   not applicable to PC/laptop or PDA software phones (soft phones) and
   mobile phones.

   Req-1:  SIP telephony devices MUST be able to acquire IP network
           settings by automatic configuration using 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.




Sinnreich, et al        Expires December 11, 2005               [Page 4]

Internet-Draft   Device Requirements and Configuration         June 2005


   Req-4:  SIP telephony devices MUST support the Simple Network Time
           Protocol [5].

   Req-5:  Desktop SIP phones and other special purpose SIP telephony
           devices MUST be able to upgrade their firmware to support
           additional features and the functionality.

   Req-6:  Users SHOULD be able to upgrade the devices with no special
           applications or equipment; or a service provider SHOULD be
           able to push the upgrade down to the devices remotely.

2.2. DNS and ENUM Support

   Req-7:  SIP telephony devices MUST support RFC 3263 [6] for locating
           a SIP Server and selecting a transport protocol.

   Req-8:  SIP telephony devices MUST incorporate DNS resolvers that are
           configurable with at least two entries for DNS servers for
           redundancy.  To provide efficient DNS resolution, SIP
           telephony devices SHOULD query responsive DNS servers and
           skip DNS servers that have been non-responsive to recent
           queries.

   Req-9:  To provide efficient DNS resolution and to limit post- dial
           delay, SIP telephony devices MUST cache DNS responses based
           on the DNS time-to-live.

   Req-10: For DNS efficiency, SIP telephony devices SHOULD use the
           additional information section of the DNS response instead of
           generating additional DNS queries.

   Req-11: SIP telephony devices MAY support ENUM [7] in case the end
           users prefer to have control over the ENUM lookup.  Note: The
           ENUM resolver can also be placed in the outgoing SIP proxy to
           simplify the operation of the SIP telephony device.

2.3. SIP Device Resident Telephony Features

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

   Req-13: SIP telephony devices SHOULD support the SIP Privacy header
           by populating headers with values that reflect the privacy
           requirements and preferences as described in "Section 4 User
           Agent Behavior" in RFC 3323 [8].

   Req-14: SIP telephony devices MUST be able to place an existing call
           on hold, and initiate or receive another call, as specified
           in RFC 3264 [12] and SHOULD NOT omit the sendrecv attribute.



Sinnreich, et al        Expires December 11, 2005               [Page 5]

Internet-Draft   Device Requirements and Configuration         June 2005


   Req-15: SIP telephony devices MUST provide a call waiting indicator.
           When participating in a call, the user MUST be alerted
           audibly and/or visually of another incoming call.  The user
           MUST be able to enable/disable the call waiting indicator.

   Req-16: SIP telephony devices MUST support SIP message waiting [43]
           and the integration with message store platforms.

   Req-17: SIP telephony devices MAY support a local dial plan.  If a
           dial plan is supported, it MUST be able to match the user
           input to one of multiple pattern strings and transform the
           input to a URI, including an arbitrary scheme and URI
           parameters.

   Example: If a local dial plan is supported, it SHOULD be configurable
   to generate any of the following URIs when "5551234" is dialed:

   tel:+12125551234
   sip:+12125551234@ietf.org;user=phone
   sips:+12125551234@ietf.org;user=phone
   sip:5551234@ietf.org
   sips:5551234@ietf.org
   tel:5551234;phone-context=l1.ietf.org
   sip:5551234;phone-context=l1.ietf.org@ietf.org;user=phone
   sips:5551234;phone-context=l1.ietf.org@ietf.org;user=phone
   sip:5551234;phone-context=l1.ietf.org@ietf.org;user=dialstring
   sips:5551234;phone-context=l1.ietf.org@ietf.org;user=dialstring
   tel:5551234;phone-context=+1212
   sip:5551234;phone-context=+1212@ietf.org;user=phone
   sips:5551234;phone-context=+1212@ietf.org;user=phone
   sip:5551234;phone-context=+1212@ietf.org;user=dialstring
   sips:5551234;phone-context=+1212@ietf.org;user=dialstring

   If a local dial plan is not supported, the device SHOULD be
   configurable to generate any of the following URIs when "5551234" is
   dialed:

   sip:5551234@ietf.org
   sips:5551234@ietf.org
   sip:5551234;phone-context=l1.ietf.org@ietf.org;user=dialstring
   sips:5551234;phone-context=l1.ietf.org@ietf.org;user=dialstring
   sip:5551234;phone-context=+1212@ietf.org;user=dialstring
   sips:5551234;phone-context=+1212@ietf.org;user=dialstring

   Req-18: SIP telephony devices MUST support URIs for telephone numbers
           as per RFC 3966 [9].  This includes the reception as well as
           the sending of requests.  The reception may be denied
           according to the configurable security policy of the device.



Sinnreich, et al        Expires December 11, 2005               [Page 6]

Internet-Draft   Device Requirements and Configuration         June 2005


           It is a reasonable behavior to send a request to a
           preconfigured outbound proxy.

   Req-19: SIP telephony devices MUST support REFER and NOTIFY for call
           transfer [45], [46].  SIP telephony devices MUST support
           escaped Replaces-Header (RFC 3891) and SHOULD support other
           escaped headers in the Refer-To header.

   Req-20: SIP telephony devices MUST support the unattended call
           transfer flows as defined in [46].

   Req-21: SIP telephony devices MUST support the attended call transfer
           as defined in [46].

   Req-22: SIP telephony devices MAY support device based 3-way calling
           by mixing the audio streams and displaying the interactive
           text of at least 2 separate calls.

   Req-23: SIP telephony devices MUST be able to send DTMF named
           telephone events as specified by RFC 2833 [11].

   Req-24: Payload type negotiation MUST comply with RFC 3264 [12] and
           with the registered MIME types for RTP payload formats in RFC
           3555 [13].

   Req-25: The dynamic payload type MUST remain constant throughout the
           session.  For example, if an endpoint decides to renegotiate
           codecs or put the call on hold, the payload type for the
           re-invite MUST be the same as the initial payload type.  SIP
           devices MAY support Flow Identification as defined in RFC
           3388 [14].

   Req-26: When acting as a UAC, SIP telephony devices SHOULD support
           the gateway model of RFC 3960 [71].  When acting as a UAS,
           SIP telephony devices SHOULD NOT send early media.

   Req-27: SIP telephony devices MUST be able to handle multiple early
           dialogs in the context of request forking.  When a confirmed
           dialog has been established, it is an acceptable behavior to
           send a BYE request in response to additional 2xx responses
           that establish additional confirmed dialogs.

   Req-28: SIP devices with a suitable display SHOULD support the
           call-info header and depending on the display capabilities
           MAY for example display an icon or the image of the caller.

   Req-29: To provide additional information about call failures, SIP
           telephony devices with a suitable display MUST render the
           "Reason Phrase" of the SIP message or map the "Status-Code"


Sinnreich, et al        Expires December 11, 2005               [Page 7]

Internet-Draft   Device Requirements and Configuration         June 2005


           to custom or default messages.  This presumes the language
           for the reason phrase is the same as the negotiated language.
           The devices MAY use an internal "Status Code" table if there
           was a problem with the language negotiation.

   Req-30: SIP telephony devices MAY support music on hold, both in
           receive mode or locally generated.  See also "SIP Service
           Examples" for a call flow with music on hold [46].

   Req-31: SIP telephony devices MAY ring after a call has been on hold
           for a predetermined period of time, typically 3 minutes.

2.4. Support for SIP Services

   Req-32: SIP telephony devices MUST support the SIP Basic Call Flow
           Examples [47].

   Req-33: SIP telephony devices MUST support the SIP-PSTN Service
           Examples as per RFC 3666 [16].

   Req-34: SIP telephony devices MUST support the Third Party Call
           Control model [17], in the sense that they may be the
           controlled device.

   Req-35: SIP telephony devices SHOULD support SIP call control and
           multiparty usage [42].

   Req-36: SIP telephony devices SHOULD support conferencing services
           for voice [48], [49] and interactive text [56] and if
           equipped with an adequate display MAY also support instant
           messaging (IM) and presence [50], [59].

   Req-37: SIP telephony devices SHOULD support the indication of the
           User Agent Capabilities and MUST support the caller
           capabilities and preferences as per RFC 3840 [52].

   Req-38: SIP telephony devices MAY support service mobility: Devices
           MAY allow roaming users to input their identity so as to have
           access to their services and preferences from the home SIP
           server.  Examples of user data to be available for roaming
           users are: User service ID, the dialing plan, personal
           directory and caller preferences.

2.5. Basic Telephony and Presence Information Support

   The large color displays in some newer models make such SIP phones
   and applications attractive for a rich communication environment.
   This document is focused however only on telephony specific features
   enabled by SIP Presence and SIP Events.


Sinnreich, et al        Expires December 11, 2005               [Page 8]

Internet-Draft   Device Requirements and Configuration         June 2005


   SIP telephony devices can also support for example presence status,
   such as the traditional Do Not Disturb, new event state based
   information, such as being in another call or being in a conference,
   typing a message, emoticons, etc.  Some SIP telephony User Agents can
   support for example a voice session and several IM sessions with
   different parties.

   Req-39: SIP telephony devices SHOULD support Presence information
           [50] and SHOULD support the Rich Presence Information Data
           Format [51] for the new IP communication services enabled by
           Presence.

   Req-40: Users MUST be able to set the state of the SIP telephony
           device to "Do Not Disturb", and this MAY be manifested as a
           Presence state across the network if the UA can support
           Presence information.

   Req-41: SIP telephony devices with "Do Not Disturb" enabled MUST
          respond to new sessions with "486 Busy Here".

2.6. Emergency and Resource Priority Support

   Req-42: Emergency calling: For emergency numbers (e.g.  911, SOS
           URL), SIP telephony devices SHOULD support the work of the
           ECRIT WG [54].

   Req-43: Priority header: SIP devices SHOULD support the setting by
           the user of the Priority header specified in RFC 3261 for
           such applications as emergency calls or for selective call
           acceptance.

   Req-44: Resource Priority header: SIP telephony devices that are used
           in environments that support emergency preparedness MUST also
           support the sending and receiving of the Resource-Priority
           header as specified in [55].  The Resource Priority header
           influences the behavior for message routing in SIP proxies
           and PSTN telephony gateways and is different from the SIP
           Priority header specified in RFC 3261.  Users of SIP
           telephony devices may want to be interrupted in their
           lower-priority communications activities if such an emergency
           communication request arrives.

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




Sinnreich, et al        Expires December 11, 2005               [Page 9]

Internet-Draft   Device Requirements and Configuration         June 2005


2.7. Multi-Line Requirements

   A SIP telephony device can have multiple lines: One SIP telephony
   device can be registered simultaneously with different SIP registrars
   from different service providers, using different names and
   credentials for each line.  The different sets of names and
   credentials are also called 'SIP accounts'.  The "line" terminology
   has been borrowed from multi-line PSTN/PBX phones, except that for
   SIP telephony devices there can be different SIP registrar/proxies
   for each line, each of which may belong to a different service
   provider, whereas this would be an exceptional case for the PSTN and
   certainly not the case for PBX phones.  Multi-line SIP telephony
   devices resemble more closely e-mail clients that can support several
   e-mail accounts.

   Note: Each SIP account can usually support different Addresses of
   Record (AOR) with a different list of contact addresses (CA), as may
   be convenient for example when having different SIP accounts for
   business and for the private life.

   Some of the CAs in different SIP accounts may though point to the
   same devices.

   Req-45: Multi-line SIP telephony devices MUST support a unique
           authentication username, authentication password, registrar,
           and identity to be provisioned for each line.  The
           authentication username MAY be identical with the user name
           of the AOR and the domain name MAY be identical with the host
           name of the registrar.

   Req-46: Multi-line SIP telephony devices MUST be able to support the
           state of the client to Do Not Disturb on a per line basis.

   Req-47: Multi-line SIP telephony devices MUST support multi-line call
           waiting indicators.  Devices MUST allow the call waiting
           indicator to be set on a per line basis.

   Req-48: Multi-line SIP telephony devices MUST be able to support a
           few different ring tones for different lines.  We specify
           here "a few", since provisioning different tones for all
           lines may be difficult for phones with many lines.

2.8. User Mobility

   The following requirements allow users with a set of credentials to
   use any SIP telephony device that can support personal credentials
   from several users, distinct from the identity of the device.




Sinnreich, et al        Expires December 11, 2005              [Page 10]

Internet-Draft   Device Requirements and Configuration         June 2005


   Req-49: User mobility enabled SIP telephony devices MUST store static
           credentials associated with the device in non-volatile
           memory.  This static profile is used during the power up
           sequence.

   Req-50: User mobility enabled SIP telephony devices SHOULD allow a
           user to walk up to a device and input their personal
           credentials.  All user features and settings stored in SIP
           proxy and the associated policy server SHOULD be available to
           the user.

   Req-51: User mobility enabled SIP telephony devices registered as
           fixed desktop with network administrator MUST use the local
           static location data associated with the device for emergency
           calls.

 2.9. Interactive Text Support

   SIP telephony devices supporting Instant Messaging based on SIMPLE
   [50] support text conversation based on blocks of text.  However,
   continuous interactive text conversation may be sometimes preferred
   as a parallel to voice, due to its interactive and more
   streaming-like nature, thus more appropriate for real time
   conversation.  It also allows for text captioning of voice in noisy
   environments and for those who cannot hear well or cannot hear at
   all.

   Finally continuous, character by character text is what is preferred
   by emergency and public safety programs (e.g.  112 and 911) because
   of its immediacy, efficiency, lack of crossed messages problem,
   better ability to interact with a confused person, and the additional
   information that can be observed from watching the message as it is
   composed.

   Req-52: SIP telephony devices such as SIP display phones and
           IP-analog adapters SHOULD support the accessibility
           requirements for the deaf, hard of hearing and speech
           impaired individuals as per RCF 3351 [18] and also for
           interactive text conversation [56], [70].

   Req-53: SIP telephony devices SHOULD provide a way to input text and
           to display text through any reasonable method.  Built-in user
           interfaces, standard wired or wireless interfaces, and/or
           support for text through a web interface are all considered
           reasonable mechanisms.

   Req-54: SIP telephony devices SHOULD provide an external standard
           wired or wireless link to connect external input (keyboard,
           mouse) and display devices.


Sinnreich, et al        Expires December 11, 2005              [Page 11]

Internet-Draft   Device Requirements and Configuration         June 2005


   Req-55: SIP telephony devices which include a display, or have a
           facility for connecting an external display, MUST include
           protocol support as described in RFC 2793 for real-time
           interactive text.

   Req-56: There may be value of having RFC 2793 support in a terminal
           also without a visual display.  A synthetic voice output for
           the text conversation may be of value for all who can hear,
           and thereby having the opportunity to have a text
           conversation with other users.

   Req-57: SIP telephony devices MAY provide analog adaptor
           functionality through an RJ-11 FXO port to support FXS
           devices.  If an RJ-11 (FXO) port is provided, then it MAY
           support a gateway function from all text-telephone protocols
           according to ITU-T Recommendation V.18 to RFC 2793 text
           conversation (in fact this is encouraged in the near term
           during the transition to widespread use of SIP telephony
           devices).  If this gateway function is not included or fails,
           the device MUST pass-through all text-telephone protocols
           according to ITU-T Recommendation V.18, November 2000, in a
           transparent fashion.

   Req-58: SIP telephony devices MAY provide a 2.5 mm audio port, in
           portable SIP devices, such as PDA"s and various wireless SIP
           phones.

2.10. Other Related Protocols

   Req-59: SIP telephony devices MUST support the Real-Time Protocol and
           the Real-Time Control Protocol, RFC 3550 [20].  SIP devices
           SHOULD use RTCP Extended Reports for logging and reporting on
           network support for voice quality, RFC 2611 [21] and MAY also
           support the RTCP summary report delivery [57].

2.11. SIP Device Security Requirements

   Req-60: SIP telephony devices MUST support digest authentication as
           per RFC3261.  In addition, SIP telephony devices MUST support
           TLS for secure transport [36] for scenarios where the SIP
           registrar is located outside the secure, private IP network
           in which the SIP UA may reside.  Note: TLS need not be used
           in every call though.

   Req-61: SIP telephony devices MUST be able to password protect
           configuration information and administrative functions.

   Req-62: SIP telephony devices MUST NOT display the password to the
           user or administrator after it has been entered.


Sinnreich, et al        Expires December 11, 2005              [Page 12]

Internet-Draft   Device Requirements and Configuration         June 2005


   Req-63: SIP clients MUST be able to disable remote access, i.e.
           block incoming SNMP (where this is supported), HTTP, and
           other services not necessary for basic operation.

   Req-64: SIP telephony devices MUST support the option to reject an
           incoming INVITE where the user-portion of the SIP request URI
           is blank or does not match a provisioned contact.  This
           provides protection against war-dialer attacks, unwanted
           telemarketing and spam.  The setting to reject MUST be
           configurable.

   Req-65: When TLS is not used, SIP telephony devices MUST be able to
           reject an incoming INVITE when the message does not come from
           the proxy or proxies where the client is registered.  This
           prevents callers from bypassing terminating call features on
           the proxy.  For DNS SRV specified proxy addresses, the client
           must accept an INVITE from all of the resolved proxy IP
           addresses.

2.12. Quality of Service

   Req-66: SIP devices MUST support the IPv4 DSCP field for RTP streams
           as per RFC 2597 [22].  The DSCP setting MUST be configurable
           to conform with the local network policy.

   Req-67: If not specifically provisioned, SIP telephony devices SHOULD
           mark RTP packets with the recommended DSCP for expedited
           forwarding (codepoint 101110); and mark SIP packets with DSCP
           AF31 (codepoint 011010).

   Req-68: SIP telephony devices MAY support RSVP [23].

2.13. Media Requirements

   Req-69: To simplify the interoperability issues, SIP telephony
           devices MUST use the first matching codec listed by the
           receiver if the requested codec is available in the called
           device.  See the offer/answer model in RFC 3261.

   Req-70: To reduce overall bandwidth, SIP telephony devices MAY
           support active voice detection and comfort noise generation.

2.14. Voice Codecs

   Internet telephony devices face the problem of supporting multiple
   codecs due to various historic reasons, on how telecom industry
   players have approached codec implementations and the serious
   intellectual property and licensing problems associated with most
   codec types.  RFC 3551 [24] lists 17 registered MIME subtypes for


Sinnreich, et al        Expires December 11, 2005              [Page 13]

Internet-Draft   Device Requirements and Configuration         June 2005


   audio codecs.  This memo however requires the support of a minimal
   number of codecs used in wireline VoIP, and also codecs found in
   mobile phones.

   Req-71: SIP telephony devices SHOULD support AVT payload type 0
           (G.711 uLaw) as in reference [25] and its Annexes 1 and 2.

   Req-72: SIP telephony devices SHOULD support the Internet Low Bit
           Rate codec (iLBC) [26], [27].

   Req-73: Mobile SIP telephony devices MAY support codecs found in
           various 3G wireless mobile phones.  This can avoid codec
           conversion in network based intermediaries.

   Req-74: SIP telephony devices MAY support a small set of special
           purpose codecs, such as G.723.1, where low bandwidth is
           needed (for dial-up Internet access) or G.722 for high
           quality audio conferences.

   Req-75: SIP telephony devices MAY support G.729 and its
           annexes.

   Note: The authors believe the Internet Low Bit Rate codec (iLBC)
   should be the default codec for Internet telephony.

   A summary count reveals up to 25 and more voice codec types currently
   in use.  The authors believe there is also a need for a single
   multi-rate Internet codec, such as Speex [28] or similar that can
   effectively be substituted for all of the multiple legacy G.7xx codec
   types, such as G.  711, G.729, G.723.1, G.722, etc.  for various data
   rates, thus avoiding the complexity and cost to implementers and
   service providers alike who are burdened by supporting so many codec
   types, besides the burden of the additional licensing costs.

2.15. Telephony Sound Requirements

   Req-76: SIP telephony devices SHOULD comply with the handset receive
           comfort noise requirements outlined in the ANSI standards
           [29], [30].

   Req-77: SIP telephony devices SHOULD comply with the stability or
           minimum loss defined in ITU-T G.177 [31].

   Req-78: SIP telephony devices MAY provide a full-duplex speakerphone
           with echo and side tone cancellation.  The design of high
           quality side tone cancellation for desktop IP phones, laptop
           computers and PDAs is outside the scope of this memo.




Sinnreich, et al        Expires December 11, 2005              [Page 14]

Internet-Draft   Device Requirements and Configuration         June 2005


   Req-79: SIP telephony device MAY support different ring-tones based
           on the caller identity.

2.16. International Requirements

   Req-80: SIP telephony devices SHOULD indicate the preferred language
           [34] using User Agent Capabilities [52].

   Req-81: SIP telephony devices intended to be used in various language
           settings [34], MUST support other languages for menus, help,
           and labels.

2.17. Support for Related Applications

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

   Req-82: SIP telephony devices that have a large display and support
           presence SHOULD display a buddy list [50].

   Req-83: SIP telephony devices MAY support LDAP for client-based
           directory lookup.

   Req-84: SIP telephony devices MAY support a phone setup where a URL
           is automatically dialed when the phone goes off-hook.

2.18. Web Based Feature Management

   Req-85: SIP telephony devices SHOULD support an internal web server
           to allow users the option to manually configure the phone and
           to set up personal phone applications such as the address
           book, speed-dial, ring tones, and last but not least the call
           handling options for the various lines, aliases, in a user
           friendly fashion.  Web pages to manage the SIP telephony
           device SHOULD be supported by the individual device, or MAY
           be supported in managed networks from centralized web
           servers.  Managing SIP telephony devices SHOULD NOT require
           special client software on the PC or require a dedicated
           management console.  SIP telephony devices SHOULD support
           https transport for this purpose.

           In addition to the Web Based Feature Management Requirement
           the device MAY have an SNMP interface for monitoring and
           management purposes.

2.19. Firewall and NAT Traversal

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


Sinnreich, et al        Expires December 11, 2005              [Page 15]

Internet-Draft   Device Requirements and Configuration         June 2005


   Req-86: SIP telephony devices SHOULD be able to operate behind a
           static NAPT (Network Address Translation/Port Address
           Translation) device.  This implies the SIP telephony device
           SHOULD be able to 1) populate SIP messages with the public,
           external address of the NAPT device, 2) use symmetric UDP or
           TCP for signaling, and 3) Use symmetric RTP [72].

   Req-87: SIP telephony devices SHOULD support the STUN protocol [32]
           for determining the NAPT public external address.  A
           classification of scenarios and NATs where STUN is effective
           is reported in [58].  Detailed call flows for interactive
           connectivity establishment (ICE) are given in [76].

   Note: Developers are strongly advised to follow the document on best
   current practices for NAT traversal for SIP [63].

   Req-88: SIP telephony devices MAY support UPnP (http://www.upnp.org/)
           for local NAPT traversal.  Note that UPnP does not help if
           there are NAPT in the network of the services provider.

   Req-89: SIP telephony devices MUST be able to limit the ports used
           for RTP to a provisioned range.

2.20. Device Interfaces

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

   Req-91: SIP telephony devices MUST have a telephony-like dial-pad and
           MAY have telephony style buttons like mute, redial, transfer,
           conference, hold, etc.  The traditional telephony dial-pad
           interface MAY appear as an option in large screen telephony
           devices using other interface models, such as Push-To-Talk in
           mobile phones and the Presence and IM GUI found in PCs, PDAs,
           in mobile phones and in cordless phones.

   Req-92: SIP telephony devices MUST have a convenient way for entering
           SIP URIs and phone numbers.  This includes all alphanumeric
           characters allowed in legal SIP URIs.  Possible approaches
           include using a web page, display and keyboard entry,
           type-ahead or graffiti for PDAs.

   Req-93: SIP telephony devices should allow phone number entry in
           human friendly fashion, with the usual separators and
           brackets between digits and digit groups.





Sinnreich, et al        Expires December 11, 2005              [Page 16]

Internet-Draft   Device Requirements and Configuration         June 2005


3. Glossary and Usage for the Configuration Settings

   SIP telephony devices are quite complex and their configuration is
   made more difficult by the widely diverse use of technical terms for
   the settings.  We present here a glossary of the most common settings
   and some of the more widely used values for some settings.

   Settings are the information on a SIP UA that it needs so as to be a
   functional SIP endpoint.  The settings defined in this document are
   not intended to be a complete listing of all possible settings.  It
   MUST be possible to add vendor specific settings.

   The list of available settings includes settings that MUST, SHOULD or
   MAY be used by all devices (when present) and that make up the common
   denominator that is used and understood by all devices.  However, the
   list is open to vendor specific extensions that support additional
   settings, which enable a rich and valuable set of features.

   Settings MAY be read-only on the device.  This avoids the
   misconfiguration of important settings by inexperienced users
   generating service cost for operators.  The settings provisioning
   process SHOULD indicate which settings can be changed by the end-user
   and which settings should be protected.

   In order to achieve wide adoption of any settings format it is
   important that it should not be excessive in size for modest devices
   to use it.  Any format SHOULD be structured enough to allow flexible
   extensions to it by vendors.  Settings may belong to the device or to
   a SIP service provider and the address of record (AOR) registered
   there.  When the device acts in the context of an AOR, it will first
   try to look up a setting in the AOR context.  If the setting can not
   be found in that context, the device will try to find the setting in
   the device context.  If that also fails, the device MAY use a default
   value for the setting.

   The examples shown here are just of informational nature.  Other
   documents may specify the syntax and semantics for the respective
   settings.

3.1. Device ID

   A device setting MAY include some unique identifier for the device it
   represents.  This MAY be an arbitrary device name chosen by the user,
   the MAC address, some manufacturer serial number or some other unique
   piece of data.  The Device ID SHOULD also indicate the ID type.

   Example: DeviceId="000413100A10;type=MAC"




Sinnreich, et al        Expires December 11, 2005              [Page 17]

Internet-Draft   Device Requirements and Configuration         June 2005


3.2. Signaling Port

   The port that MUST be used for a specific transport protocol for SIP
   MUST be indicated with the SIP ports setting.  If this setting is
   omitted, the device MAY choose any port.  For UDP, the port must also
   be used for sending requests so that NAT devices will be able to
   route the responses back to the UA.

   Example: SIPPort="5060;transport=UDP"

3.3. RTP Port Range

   A range of port numbers MUST be used by a device for the consecutive
   pairs of ports which MUST be used to receive audio and control
   information (RTP and RTCP) for each concurrent connection.  Sometimes
   this is required to support firewall traversal and it helps network
   operators to identify voice packets.

   Example: RTPPorts="50000-51000"

3.4. Quality of Service

   The QoS settings for outbound packets SHOULD be configurable for
   network packets associated with call signaling (SIP) and media
   transport (RTP/RTCP).  These settings help network operators
   identifying voice packets in their network and allow them to
   transport them with the required QoS.  The settings are independently
   configurable for the different transport layers and signaling, media
   or administration.  The QoS settings SHOULD also include the QoS
   mechanism.

   For both categories of network traffic, the device SHOULD permit
   configuration of the type of service settings for both layer 3 (IP
   DiffServ) and layer 2 (for example IEEE 802.1D/Q) of the network
   protocol stack.

   Example: RTPQoS="0xA0;type=DiffSrv, 5;type=802.1DQ;vlan=324"

3.5. Default Call Handling

   All of the call handling settings defined below can be defined here
   as default behaviors.

3.5.1. Outbound Proxy

   The outbound proxy for a device MAY be set.  The setting MAY require
   that all signaling packets MUST be sent to the outbound proxy or that
   only in the case when no route has been received the outbound proxy
   MUST be used.  This ensures that application layer gateways are in


Sinnreich, et al        Expires December 11, 2005              [Page 18]

Internet-Draft   Device Requirements and Configuration         June 2005


   the signaling path.  The second requirement allows the optimization
   of the routing by the outbound proxy.

   Example: OutboundProxy="sip:nat.proxy.com"

3.5.2. Default Outbound Proxy

   The default outbound proxy SHOULD be a global setting (not related to
   a specific line).

   Example: DefaultProxy="sip:123@proxy.com"

3.5.3. SIP Session Timer

   The re-invite timer allows user agents to detect broken sessions
   caused by network failures.  A value indicating the number of seconds
   for the next re-invite SHOULD be used if provided.

   Example: SessionTimer="600;unit=seconds"

3.6. Telephone Dialing Functions

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

3.6.1. Phone Number Representations

   SIP phones need to understand entries in the phone book of the most
   common separators used between dialed digits, such as spaces, angle
   and round brackets, dashes and dots.

   Example: A phonebook entry of "+49(30)398.33-401" should be
   translated into "+493039833401".

3.6.2. Digit Maps and/or the Dial/OK Key

   A SIP UA needs to translate user input before it can generate a valid
   request.  Digit maps are settings that describe the parameters of
   this process.

   If present, digit maps define patterns that when matched define:

      1) A rule by which the end point can judge that the user has
         completed dialing, and

      2) a rule to construct a URI from the dialed digits, and
         optionally


Sinnreich, et al        Expires December 11, 2005              [Page 19]

Internet-Draft   Device Requirements and Configuration         June 2005


      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
   |^([a-zA-Z0-9&=+\$,;?\-_.!~*'()%]+@.+)|sip:\1|
   |^([a-zA-Z0-9&=+\$,;?\-_.!~*'()%]+)$|sip:\1@\d|
   |^(.*)$|sip:\1@\d|timeout=5

3.6.3. Default Digit Map

   The SIP telephony device SHOULD support the configuration of a
   default digit map.  If the SIP telephony device does not support
   digit maps, it SHOULD at least support a default digit map rule to
   construct a URI from digits.  If the end point does support digit
   maps, this rule applies if none of the digit maps match.

   For example, when a user enters "12345", the UA might send the
   request to "sip:12345@proxy.com;user=phone" after the user presses
   the OK key.

3.7. SIP Timer Settings

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

   Example: SIPTimer="t1=100;unit=ms"

   Note: The timer settings can be included in the digit map.




Sinnreich, et al        Expires December 11, 2005              [Page 20]

Internet-Draft   Device Requirements and Configuration         June 2005


3.8. Audio Codecs

   In some cases operators want to control which codecs MAY be used in
   their network.  The desired subset of codecs supported by the device
   SHOULD be configurable along with the order of preference.  Service
   providers SHOULD have the possibility of plugging in their own codecs
   of choice.  The codec settings MAY include the packet length and
   other parameters like silence suppression or comfort noise
   generation.

   The set of available codecs will be used in the codec negotiation
   according to RFC 3264 [12].

   Example: Codecs="speex/8000;ptime=20;cng=on, gsm;ptime=30"

   The settings MUST include hints about privacy for audio using SRTP
   that either mandate or encourage the usage of secure RTP.

   Example: SRTP="mandatory"

3.9. DTMF Method

   Keyboard interaction can be indicated with in-band tones or
   preferable with out-of-band RTP packets (RFC 2833) [11].  The method
   for sending these events SHOULD be configurable with the order of
   precedence.  Settings MAY include additional parameters like the
   content-type that should be used.

   Example: DTMFMethod="INFO;type=application/dtmf, RFC2833", [11].

3.10. Local and Regional Parameters

   Certain settings are dependent upon the regional location for the
   daylight saving time rules and for the time zone.

   Time Zone and UTC Offset: A time zone MAY be specified for the user.
   Where one is specified; it SHOULD use the schema used by the Olson
   Time One database [33].

   Examples of the database naming scheme are Asia/Dubai or America/Los
   Angeles where the first part of the name is the continent or ocean
   and the second part is normally the largest city on that time-zone.
   Optional parameters like the UTC offset may provide additional
   information for UA that are not able to map the time zone information
   to a internal database.

   Example: TimeZone="Asia/Dubai;offset=7200"




Sinnreich, et al        Expires December 11, 2005              [Page 21]

Internet-Draft   Device Requirements and Configuration         June 2005


3.11. Time Server

   A time server SHOULD be used.  DHCP is the preferred way to provide
   this setting.  Optional parameters may indicate the protocol that
   SHOULD be used for determining the time.  If present, the DHCP time
   server setting has higher precedence than the time server Setting.

   Example: TimeServer="12.34.5.2;protocol=NTP"

3.12. Language

   Setting the correct language is important for simple installation
   around the globe.

   A language Setting SHOULD be specified for the whole device.  Where
   it is specified it MUST use the codes defined in RFC 3066 [34] to
   provide some predictability.

   Example: Language="de"

   It is recommended to set the Language as writable, so that the user
   MAY change this.  This setting SHOULD NOT be AOR related.

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

3.13. Inbound Authentication

   SIP allows a device to limit incoming signaling to those made by a
   predefined set of authorized users from a list and/or with valid
   passwords.  Note that the inbound proxy from most service providers
   may also support the screening of incoming calls, but in some cases
   users may want to have control in the SIP telephony device for the
   screening.

   A device SHOULD support the setting as to whether authentication (on
   the device) is required and what type of authentication is required.

   Example: InboundAuthentication="digest;pattern=*"

   If inbound authentication is enabled then a list of allowed users and
   credentials to call this device MAY be used by the device.  The
   credentials MAY contain the same data as the credentials for an AOR
   (i.e.  URL, user, password digest and domain).  This applies to SIP
   control signaling as well as call initiation.





Sinnreich, et al        Expires December 11, 2005              [Page 22]

Internet-Draft   Device Requirements and Configuration         June 2005


3.14. Voice Message Settings

   Various voice message settings require the use of URI's as specified
   in RFC 3087 [35].

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

   Example: MWISubscribe="sip:mailbox01@media.proxy.com"

   User Agents SHOULD accept MWI information carried by SIP MESSAGE
   without prior subscription.  This way the setup of voice message
   settings can be avoided.

3.15. Phonebook and Call History

   UA SHOULD have a phonebook and keep a history of recent calls.  The
   phonebook SHOULD save the information in permanent memory that keeps
   the information even after restarting the device or save the
   information in an external database that permanently stores the
   information.

3.16. User Related Settings and Mobility

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

   The purpose of specifying which user is currently assigned to this
   device is to provide the device with the identity of the user whose
   settings are defined in the user section.  This is primarily
   interesting with regards to user roaming.  Devices MAY allow users to
   sign-on to them and then request that their particular settings be
   retrieved.  Likewise a user MAY stop using a device and want to
   disable their AOR while not present.  For the device to understand
   what to do it MUST have some way of identifying users and knowing
   which user is currently using it.  By separating the user and device
   properties it becomes clear what the user wishes to enable or to
   disable.  Providing an identifier in the configuration for the user
   gives an explicit handle for the user.  For this to work the device
   MUST have some way of identifying users and knowing which user is
   currently assigned to it.

   One possible scenario for roaming is an agent who has definitions for
   several AOR (e.g. one or more personal AOR and one for each
   executive for whom the administrator takes calls) that they are
   registered for.  If the agent goes to the copy room they would
   sign-on to a device in that room and their user settings including


Sinnreich, et al        Expires December 11, 2005              [Page 23]

Internet-Draft   Device Requirements and Configuration         June 2005


   their AOR would roam with them.  The alternative to this is to
   require the agent to individually configure all of the AORs
   individually (this would be particularly irksome using standard
   telephone button entry).

   The management of user profiles, aggregation of user or device AOR
   and profile information from multiple management sources are
   configuration server concerns which are out of the scope of this
   document.  However the ability to uniquely identify the device and
   user within the configuration data enables easier server based as
   well as local (i.e.  on the device) configuration management of the
   configuration data.

3.17. AOR Related Settings

   SIP telephony devices MUST use the Address of Record (AOR) related
   settings, as specified here.

   There are many properties which MAY be associated with or SHOULD be
   applied to the AOR or signaling addressed to or from the AOR.  AORs
   MAY be defined for a device or a user of the device.  At least one
   AOR MUST be defined in the settings, this MAY pertain to either the
   device itself or the user.

   Example: AOR="sip:12345@proxy.com"

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

3.18. Maximum Connections

   A setting defining the maximum number of simultaneous connections
   that a device can support MUST be used by the device.  The end point
   might have some maximum limit, most likely determined by the media
   handling capability.  The number of simultaneous connections may be
   also limited by the access bandwidth, such as of DSL, cable and
   wireless users.  Other optional settings MAY include the enabling or
   disabling of call waiting indication.

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

   Example: MaximumConnections="2;cwi=false;bw=128".

   See the recent work on connection reuse [74] and the guidelines for
   connection oriented transport for SIP [75].




Sinnreich, et al        Expires December 11, 2005              [Page 24]

Internet-Draft   Device Requirements and Configuration         June 2005


3.19. Automatic Configuration and Upgrade

   Automatic SIP telephony device configuration SHOULD use the processes
   and requirements described in [60].  The user name or the realm in
   the domain name SHOULD be used by the configuration server to
   automatically configure the device for individual or group specific
   settings, without any settings by the user.  Image and service data
   upgrades SHOULD also not require any settings by the user.

3.20. Security Configurations

   The device configuration usually contains sensitive information that
   MUST be protected.  Examples include authentication information,
   private address books and call history entries.  Because of this, it
   is RECOMMENDED to use an encrypted transport mechanism for
   configuration data.  Where devices use HTTP this could be TLS [36].

   For devices which use FTP or TFTP for content delivery this can be
   achieved using symmetric key encryption.

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

   The configuration server SHOULD NOT include passwords through the
   automatic configuration process.  Users SHOULD enter the passwords
   locally.

4. Security Considerations

4.1. Threats and Problem Statement

   While section 2.11 states the minimal security requirements and
   NAT/firewall traversal that have to be met respectively by SIP
   telephony devices, developers and network managers have to be aware
   of the larger context of security for IP telephony, especially for
   those scenarios where security may reside in other parts of SIP
   enabled networks.

   Users of SIP telephony devices are exposed to many threats [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


Sinnreich, et al        Expires December 11, 2005              [Page 25]

Internet-Draft   Device Requirements and Configuration         June 2005


   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:

    o Peers can communicate across domains without any pre-arranged
      trust relationship,

    o There may be many intermediaries in the signaling path,

    o Multiple endpoints can be involved in such telephony operations as
      forwarding, forking, transfer or conferencing,

    o There are seemingly conflicting service requirements when
      supporting anonymity, legal intercept, call trace and privacy,

    o Complications arise from the need to traverse NATs and firewalls.

   There are a large number of deployment scenarios in enterprise
   networks, using residential networks and employees using 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.

4.2. SIP Telephony Device Security

   Transport Level Security

      SIP telephony devices that operate outside the perimeter of secure
      private IP networks (this includes telecommuters and roaming
      users) MUST use TLS [36] to the outgoing SIP proxy for protection



Sinnreich, et al        Expires December 11, 2005              [Page 26]

Internet-Draft   Device Requirements and Configuration         June 2005


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

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

      Note the recent work in the IETF on certificate services that do
      not require the telephony devices to store certificates [69].

   End-to-End Security Using S/MIME

      S/MIME [40] MUST be supported by SIP telephony devices to sign and
      encrypt portions of the SIP message that are not strictly required
      for routing by intermediaries.  S/MIME protects private
      information in the SIP bodies and in some SIP headers from
      intermediaries.  The end user certificates required for S/MIME
      assure the identity of the parties to each other.  Note: S/MIME
      need not be used though in every call.

4.3. Privacy

   Media Encryption

      Secure RTP (SRTP) [41] MAY be used for the encryption of media
      such as audio, text and video, after the keying information has
      been passed by SIP signaling.  Instant messaging MAY be protected
      end-to-end using S/MIME.


Sinnreich, et al        Expires December 11, 2005              [Page 27]

Internet-Draft   Device Requirements and Configuration         June 2005


4.4. Support for NAT and Firewall Traversal

   The various NAT and firewall traversal scenarios require support in
   telephony SIP devices.  The best current practices for NAT traversal
   for SIP are reviewed in [63].  Most scenarios where there are no SIP
   enabled network edge NAT/firewalls or gateways in the enterprise can
   be managed if there is a STUN [32] client in the SIP telephony device
   and a STUN server on the Internet, maintained by a service provider.
   In some exceptional cases (legacy symmetric NAT) an external media
   relay must also be provided that can support the TURN protocol
   exchange [62] with SIP telephony devices.  Media relays such as TURN
   come at a high bandwidth cost to the service provider, since the
   bandwidth for many active SIP telephony devices must be supported.
   Media relays may also introduce longer paths with additional delays
   for voice.

   Due to these disadvantages of media relays, it is preferable to avoid
   symmetric and non-deterministic NAT's in the network, so that only
   STUN can be used, where required.  Reference [73] deals in more
   detail how NAT has to 'behave'.

   It is not always obvious to determine the specific NAT and firewall
   scenario under which a SIP telephony device may operate.

   For this reason, the support for Interactive Connectivity
   Establishment (ICE) [76] has been defined to be deployed in all
   devices that required end-to-end connectivity for SIP signaling and
   RTP media streams, as well as for streaming media using RTSP.  ICE
   makes use of existing protocols, such as STUN and TURN.

   Call flows using SIP security mechanisms

      The high level security aspects described here are best
      illustrated by inspecting the detailed call flows using SIP
      security, such as in [64].

  Security enhancements, certificates and identity management

     As of this writing, recent work in the IETF deals with the SIP
     authenticated body (AIB) format [66], new S/MIME requirements [67]
     enhancements for the authenticated identity [68], and Certificate
     Management Services for SIP [69].  We recommend developers and
     network managers to follow this work as it will develop into IETF
     standards.

5. IANA Considerations

   This document has no actions for IANA.



Sinnreich, et al        Expires December 11, 2005              [Page 28]

Internet-Draft   Device Requirements and Configuration         June 2005


6. Acknowledgments

   Paul Kyzivat and Francois Audet have made useful comments how to
   support to the dial plan requirements in Req-17.  Mary Barnes has
   kindly made a very detailed review on version 04 that has contributed
   to significantly improving the document.  Useful comments on version
   05 have also been made by Ted Hardie, David Kessens, Russ Housley and
   Harald Alvestrand that are reflected in this version of the document.

   We would like to thank Jon Peterson for very detailed comments on the
   previous version 0.3 that has prompted the rewriting of much of this
   document.  John Elwell has contributed with many detailed comments to
   version of the 04 of the draft.  Rohan Mahy has contributed several
   clarifications to the document and leadership in the discussions on
   support for the hearing disabled.  These discussions have been
   concluded during the BOF on SIP Devices held during the 57th IETF and
   the conclusions are reflected in the section on interactive text
   support for hearing or speech disabled users.

   Arnoud van Wijk and Guido Gybels have been instrumental in driving
   the specification for support of the hearing disabled.

   The authors would also like to thank numerous persons for
   contributions and comments to this work: Henning Schulzrinne, Jorgen
   Bjorkner, Jay Batson, Eric Tremblay, Gunnar Hellstrom, David Oran and
   Denise Caballero McCann, Brian Rosen, Jean Brierre, Kai Miao, Adrian
   Lewis and Franz Edler.  Jonathan Knight has contributed significantly
   to earlier versions of the requirements for SIP phones.  Peter Baker
   has also provided valuable pointers to TIA/EIA IS 811 requirements to
   IP phones that are referenced here.  Last but not least, the
   co-authors of the previous versions, Daniel Petrie and Ian Butcher
   have provided support and guidance all along in the development of
   these requirements.  Their contributions are now the focus of
   separate documents.

7. Changes from Previous Versions

   Changes from draft-sinnreich-sipdev-req-06

   We have updated a number of requirements based on discussions on the
   SIPPING WG list (sipping.ietf.org) and helpful comments by Paul
   Kyzivat and Francois Audet.

     o Edited and added example for a dial plan in Req-17,

     o Edited Req-18, Req-19, Req-26, Req-27 and Req-64 so as to match
       recently issued RFCs that are quoted in the Reference.




Sinnreich, et al        Expires December 11, 2005              [Page 29]

Internet-Draft   Device Requirements and Configuration         June 2005


   Changes from draft-sinnreich-sipdev-req-05

   Updated the references and made edits as suggested by Mary Barnes and
   from comments by Russ Housley, David Kessen and Ted Hardie.

   Changes from draft-sinnreich-sipdev-req-05

     o Added edits on text over IP has suggested by Gunnar Hellstrom and
       Jon Peterson.

   Changes from draft-sinnreich-sipdev-req-04

     o Removed the section on IANA Considerations that was meant to
       register the event package for automatic configuration, since
       this topic is now dealt elsewhere in [60].

     o Removed the reference to RFC 791, since that is implied by
       referencing the DiffServ code points in RFC 2597 [22].

     o Reviewed and tightened the language based on comments by John
       Elwell.

   Changes from draft-sinnreich-sipdev-req-03

     o Version 03 of the memo is focused more narrowly on SIP telephony
       device requirements and configuration only.

     o Automatic configuration over the network has been ommitted since
       it is addressed separately in [60].

     o The section with the example with XML based configuration data
       has been omitted, since such data formats are different topic
       altogether.

     o 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

     o Re-edited the section on Interactive text support for hearing or
       speech disabled users.

     o Shortened the sections on phonebook, call history and line
       related settings.

     o Deleted the section on ringer behavior.



Sinnreich, et al        Expires December 11, 2005              [Page 30]

Internet-Draft   Device Requirements and Configuration         June 2005


     o Updated and added references.


8. References

   Note: The references provided here should be considered informative,
   since this is an informational memo.  Also, as of this writing, some
   references are work in progress at the IETF.  As a result the version
   number on some key draft may be obsolete at the time of reading this
   memo and other Internet Drafts are advanced to RFC status.

   [1] Scott Bradner: "The Internet Standards Process, Revision 3", RFC
   2026.  IETF, October 1996.

   [2] Scott Bradner: "Key words for use in RFCs to Indicate Requirement
   Levels", RFC 2119, IETF, 1997.

   [3] J.  Rosenberg et.  al: "SIP: Session Initiation Protocol", RFC
   3261.  IETF, June 2002.

   [4] R.  Droms:: "Dynamic Host Configuration Protocol", RFC 2131.
   IETF, March 1997.

   [5] D.  Mills: "Simple Network Time Protocol (SNTP) Version 4 for
   IPv4 and IPv6 and OSI" RFC 2030.  IETF, October 1996.

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

   [7] J.Peterson "ENUM Service Registration for Session Initiation
   Protocol (SIP) Address of Record", RFC 3764.  IETF, April 2004.

   [8] R J.  Peterson: "A Privacy Mechanism for the Session Initiation
   Protocol", RFC 3323.  IETF, November 2002.

   [9] H.  Schulzrinne: "The tel URI for Telephone Numbers", RFC 3966.
   IETF, December 2004.

   [10] R.  Sparks: "The Session Initiation Protocol (SIP) Refer
   Method", RFC 3515.  IETF, April 2003.

   [11] H.  Schulzrinne and S.  Petrack: RTP Payload for DTM Digits,
   Telephony Tones and Telephony Signals", RFC 2833.  IETF, May 2000.

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

   [13] S.  Casner and P.  Hoschka: S.  "MIME Type Registration of RTP
   Payload Formats", RFC 3555.  IETF, July 2003.


Sinnreich, et al        Expires December 11, 2005              [Page 31]

Internet-Draft   Device Requirements and Configuration         June 2005


   [15] A.  Johnston et al: "Session Initiation Protocol (SIP) Basic
   Call Flow Examples", RFC 3665.  IETF, December 2003.

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

   [16] A.  Johnston: "Session Initiation Protocol (SIP) Public Switched
   Telephone Network (PSTN) Call Flows", RFC 3666.  IETF, December 2003.

   [17] J.  Rosenberg et al: "Best Current Practices for Third Party
   Call Control (3pcc) in the Session Initiation Protocol (SIP)", RFC
   3725.  IETF, April 2004.

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

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

   [20] H.  Schulzrinne et al: "RTP: A Transport Protocol for Real-Time
   Applications", RFC 3550.  IETF, July 2003.

   [21] T.  Friedman et al: "RTP Control Protocol Extended Reports (RTCP
   XR)", RFC 2611.  IETF, November 2003.

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

   [23] R.  Braden et al: "Resource ReSerVation Protocol (RSVP)-Version
   1 Functional Specification", RFC 2205.  IETF, September 1997.

   [24] H.  Schulzrinne and S.  Casner: "RTP Profile for Audio and Video
   Conferences with Minimal Control", RFC 3551.  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", RFC 3951.
   IETF, December 2004.

   [27] R A.  Duric: "RTP Payload Format for iLBC Speech", RFC 3952.
   IETF, December 2004.

   [28] G.  Herlein et al.: "RTP Payload Format for the Speex Codec",
   draft-herlein-avt-rtp-speex-00.txt, IETF, March 2003.

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


Sinnreich, et al        Expires December 11, 2005              [Page 32]

Internet-Draft   Device Requirements and Configuration         June 2005


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

   [31] ITU-T Recommendation G.177 available online from the ITU
   bookstore at http://www.itu.int

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

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

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

   [35] B.  Campbell and R.  Sparks: "Control of Service Context using
   SIP Request-URI" RFC 3087.  IETF, April 2001.

   [36] T.  Dierks: "The TLS protocol Version 1.0" RFC 2246.  IETF,
   January 1999.

   [37] C.  Jennings et al: "Private Extensions to the Session
   Initiation Protocol (SIP) for Asserted Identity within Trusted
   Networks ", RFC 3325.  IETF, November 2002.

   [38] J.  Peterson: "A Privacy Mechanism for the Session Initiation
   Protocol (SIP)", RFC 3323.  IETF, Nov.  2002.

   [39] S.  Chokhani et al: "Internet X.509 Public Key Infrastructure,
   Certificate Policy and Certification Practices Framework" RFC 3647.
   IETF, Nov.  2003.

   [40] B.  Ramsdell: "S/MIME Version 3 Message Specification" RFC 2633.
   IETF, June 1999.

   [41] M.  Baugher et al: "The Secure Real-time Transport Protocol
   (SRTP)", RFC 3711.  IETF March 2004.

   [42] Mahy, R.  et al: "A Call Control and Multi-party usage framework
   for the Session Initiation Protocol (SIP)",
   draft-ietf-sipping-cc-framework-02.  March 2003.
   http://www.softarmor.com/wgdb/docs/draft-ietf-sipping-cc-
   framework-02.html

   [43] R.  Mahy: "A Message Summary and Message Waiting Indication
   Event Package for the Session Initiation Protocol (SIP)", RFC 3842.
   IETF, August 2004.


Sinnreich, et al        Expires December 11, 2005              [Page 33]

Internet-Draft   Device Requirements and Configuration         June 2005


   [44] J.  Peterson: "Telephone Number Mapping (ENUM) Service
   Registration for Presence Services".  RFC 3953.  IETF, January 2005.

   [45] S.  Olson and O.  Levin: "REFER extensions",draft-olson-
   sipping-refer-extensions-02,IETF July 2004.

   [46] A.  Johnston: "SIP Service Examples", draft-ietf-
   sipping-service-examples-07, IETF July 2004.  Work in progress.

   [47] A.  Johnston et al: "Session Initiation Protocol (SIP) Basic
   Call Flow Examples" RFC 3665.  IETF, December 2003.

   [48] A.  Johnston and O.  Levin: "Session Initiation Protocol Call
   Control - Conferencing for User Agents", draft-ietf-
   sipping-cc-conferencing-06.txt, IETF, November 2004, work in
   progress.

   [49] R.  Even and N.  Ismail: "Conferencing Scenarios" draft-
   ietf-xcon-conference-scenarios-02.txt, IETF, June 2004.

   [50] J.  Rosenberg et al: "Session Initiation Protocol (SIP)
   Extension for Instant Messaging", RFC 3428.  IETF, December 2002.

   [51] H.  Schulzrinne et al.: "RPID: Rich Presence Extensions to the
   Presence Information Data Format (PIDF)", draft-ietf-simple-rpid-04,
   IETF, October 2004.

   [52] J.  Rosenberg et al: "Indicating User Agent Capabilities in the
   Session Initiation Protocol (SIP)" RFC 3840.  IETF, August 2004.

   [53] H.  Schulzrinne and B.  Rosen: "Emergency Services for Internet
   Telephony Systems", draft-schulzrinne-sipping-emergency-arch-02,
   IETF, October 2004.  Work in progress.

   [54] See the Working Group on Emergency Context Resolution with
   Internet Technologies at
   http://www.ietf.org/html.charters/ecrit-charter.html

   [55] H.  Schulzrinne and J.  Polk: "Communications Resource Priority
   for the Session Initiation Protocol", IETF, draft-
   ietf-sip-resource-priority-05, October 2004.

   [56] G.  Hellstrom and P.  Jones: "RTP Payload for Text
   Conversation", draft-ietf-avt-rfc2793bis-09.txt, IETF, August 2004,
   work in progress.

   [57] A.  Johnston: "A Performance Report Event Package For SIP",
   draft-johnston-sipping-rtcp-summary-04, IETF, October 2004.  Work in
   progress.


Sinnreich, et al        Expires December 11, 2005              [Page 34]

Internet-Draft   Device Requirements and Configuration         June 2005


   [58] C.  Jennings: "NAT Classification Results using STUN",
   draft-jennings-midcom-stun-results-02, IETF, October 2004.  Work in
   progress.

   [59] J.  Rosenberg: "A Presence Event Package for the Session
   Initiation Protocol (SIP)", RFC 3856.  IETF, October 2004.

   [60] D.  Petrie: "A Framework for SIP User Agent Profile Delivery",
   draft-ietf-sipping-config-framework-05.txt, IETF, October 2004.

   [61] C.  Jennings: "SIP Tutorial: SIP Security" presented at the VON
   Spring 2004 conference, March 29, 2004, Santa Clara, CA.

   [62] J.  Rosenberg et al.: "Traversal Using Relay NAT (TURN)",
   draft-rosenberg-midcom-turn-06.txt, IETF, October.  2004, work in
   progress.

   [63] C.  Boulton and J.  Rosenberg: "Best Current Practices for NAT
   Traversal for SIP", IETF, October 2004, work in progress.

   [64] C.  Jennings: "Example call flows using SIP security
   mechanisms", draft-jennings-sip-sec-flows-01, IETF, February 2004.

   [65] J.  Rosenberg et al: "Caller Preferences for the Session
   Initiation Protocol (SIP)", RFC 3841.  IETF, August 2004.

   [66] J.  Peterson: "Session Initiation Protocol (SIP) Authenticated
   Identity Body (AIB) Format", RFC 3893.  IETF, September 2004.

   [67] J.  Peterson: "S/MIME AES Requirements for SIP" draft-
   ietf-sip-smime-aes, IETF, June 2003.

   [68] J.  Peterson and C.  Jennings: "Enhancements for Authenticated
   Identity Management in the Session Initiation Protocol (SIP)",
   draft-ietf-sip-identity, May 2004.

   [69] J.  Peterson and C.  Jennings: "Certificate Management Services
   for SIP", draft-sipping-certs, October 2004.

   [70] G.  Hellstrom and P.  Jones: "RTP Payload for Text
   Conversation", RFC 2793bis.  Internet Draft.  Work in progress.
   draft-ietf-avt-rfc2793bis-09.txt, IETF, August 2004.

   [71] G.  Camarillo and H.  Schulzrinne: "Early Media and Ringing Tone
   Generation in the Session Initiation Protocol (SIP)", RFC 3960.
   IETF, December 2004.

   [72] "D.  Wing: "Symmetric RTP and RTCP Considered Helpful".  IETF,
   October 2004, work in progress.


Sinnreich, et al        Expires December 11, 2005              [Page 35]

Internet-Draft   Device Requirements and Configuration         June 2005


   [73] F.  Audet and C.  Jennings: "NAT Behavioral Requirements for
   Unicast UDP".  IETF, January 2005, work in progress.

   [74] R.  Mahy: "Connection Reuse in the Session Initiation Protocol
   (SIP)".  IETF, October 2004.  Work in progress.

   [75] C.  Boulton et al: "Guidelines for implementers using
   connection-oriented transports in the Session Initiation Protocol
   (SIP)".  IETF, February 2005.  Work in progress.

   [76] J.  Rosenberg: "Interactive Connectivity Establishment (ICE): A
   Methodology for Network Address Translator (NAT) Traversal for
   Multimedia Session Establishment Protocols".  Internet Draft, IETF,
   October 2004.  Work in progress.

   [77] J.  Polk: "Requirements for Session Initiation Protocol Location
   Conveyance".  Internet Draft.  October 2004.  Work in progress.

9. Author's Addresses

   Henry Sinnreich
   Pulver.com
   115 Broadhollow Road
   Melville, NY 11747, USA
   Email: henry@pulver.com
   Phone : +1-631-961-8950

   Steven Lass
   MCI
   1201 East Arapaho Road
   Richardson, TX 75081, USA
   Email: steven.lass@mci.com
   Phone: +1-972-728-2363

   Christian Stredicke
   snom technology AG
   Gradestrasse, 46
   D-12347 Berlin, Germany
   Email: cs@snom.de
   Phone: +49(30)39833-0

10. Copyright Notice

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS


Sinnreich, et al        Expires December 11, 2005              [Page 36]

Internet-Draft   Device Requirements and Configuration         June 2005


   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.

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.
























Sinnreich, et al        Expires December 11, 2005              [Page 37]


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