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

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

  SIP Telephony Device Requirements, Configuration and Data

   Internet Draft - Informational        S. Lass/WorldCom
   draft-sinnreich-sipdev-req-00.txt     D. Petrie/Pingtel
   Date: November 2002                   H. Sinnreich/WorldCom
   Expires: June 2003                    C. Stredicke/snom AG

      SIP Telephony Device Requirements, Configuration and Data

      Status of this Memo

   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, the 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
   enable similar ease of purchase, installation and operation as found
   for standard PCs, analog feature phones or mobile phones.

                   draft-somefolks-sipdevice-req-00           [Page 1]

  SIP Telephony Device Requirements, Configuration and Data

   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 [1].
  The syntax and semantics used here extend those defined in SIP, [2].

   Table of Contents

   1. Introduction...................................................3
   2. Generic Requirements...........................................3
   3. Configuration Processes.......................................12
   4. Configuration Settings and Data...............................17
      4.1 General Behavior..........................................17
      4.2 Device ID.................................................18
      4.3 Proxy and Registration Settings...........................18
      4.4 Network Related Settings..................................18
      4.5 Address Completion........................................20
      4.6 Audio.....................................................20
      4.7 Local and Regional Parameters.............................21
      4.8 Inbound authentication....................................21
      4.9 Voice mail settings.......................................22
      4.10 Phonebook and Call History...............................22
      4.11 Ringer Behavior..........................................23
      4.12 User Related Settings....................................23
      4.13 Line Related Settings....................................24
      4.14 Registration period......................................25
      4.15 Maximum connections......................................25
      4.16 Call handling............................................25
      4.17 Available Behavior.......................................25
      4.18 Busy Behavior............................................26
      4.19 Call Waiting Behavior....................................26
      4.20 Do Not Disturb...........................................27
   5. Configuration Data Representation.............................27
      5.1 Configuration Data Format - Examples......................27
      5.2 Format Definition.........................................28
      5.3 Handling of Unrecognized Element Names....................28
      5.4 Example XML Configuration Data............................29
   6. IANA Considerations...........................................31
   7. SIP Telephony Device Security.................................32
   8. Acknowledgements..............................................32
   9. Authors Addresses.............................................32
   10. References...................................................33

                     draft-somefolks-sipdevice-req-00           [Page 2]

  SIP Telephony Device Requirements, Configuration and Data

      1. Introduction

  This informational I-D has the objective of focusing the Internet
  communications community on requirements for SIP Telephony devices.
  We base this information on experience from developing and using a
  large number of SIP telephony devices types and on the experience
  gained from large scale deployments in private IP networks and on the
  Internet. This experience has shown the need for generic requirements
  for SIP telephony devices.

  SIP telephony devices, also referred to as SIP User Agents 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, conference speakerphones, and software packages (soft
  clients) running on PCs, laptops, wireless connected PDAs, as well as
  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, though we believe they need to be kept in mind. SIP
  telephony devices SHOULD meet the requirements in this document.

  The objectives of the requirements are a minimum set of
  interoperability and multi-vendor supported core features, so as to
  enable similar ease of purchase, installation and operation as found
  for standard PCs, analog feature phones or mobile phones.  Given the
  cost of some screen phones or enterprise phones may approach the cost
  of PCs and PDAs, and the larger number of phones compared to PCs,
  similar or 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
  (1) End users, (2) service providers and network administrators and
  (3) manufacturers and system integrators.

      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.

  Link Layer Requirements

  SIP devices MUST support either:

                   draft-somefolks-sipdevice-req-00           [Page 3]

  SIP Telephony Device Requirements, Configuration and Data

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

  Link-2: Wireless Ethernet 802.11b and or 802.11a,

  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

   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 RTP traffic over the shared network connection.

   IP Requirements

  IP-1: SIP telephony devices MUST be able to acquire an IP address by:
  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.

  IP-4: SIP clients MUST be able to set the IPv4 Precedence Field bits
  of the Type of Service (ToS) byte for media streams.  SIP clients
  SHOULD also be able to set the delay bit, the throughput bit, and the
  reliability bit.

   SIP User Agent Services

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

  SIP-2, DNS SRV: SIP clients MUST t support RFC2782 [3] and MAY
  support the SIP service examples [4] for basic PBX-like or Centrex-
  like functions.  SIP clients MUST support DNS SRV for locating a SIP
  Server. When making a SRV query, the client MUST t use the DNS

               draft-somefolks-sipdevice-req-00               [Page 4]

  SIP Telephony Device Requirements, Configuration and Data

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

  SIP-3, Do Not Disturb: SIP clients MUST be able to set the state of
  the client as Do Not Disturb.  Clients MUST respond to new INVITES
  with a ô486 Busy Hereö.  Clients MUST respond to re-INVITES on
  existing call legs as normal behavior [4].

  SIP-4, call hold resume: SIP clients MUST be able to place a call on
  hold/resume [4].

  SIP-5, multiple calls: SIP clients 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 [4].

  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  and an indicator for integration with voicemail
  platforms [5].

  SIP-8, local dial plan: SIP clients MUST 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.  If the destination SIP device is specified as an IP
  address, the SIP client MUST not attempt to resolve the address with
  DNS.  If the destination SIP device is a string value, the SIP client
  MUST make normal DNS SRV and A record queries.

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

  SIP-10, unattended transfer: SIP devices MUST support an unattended
  transfer [3], [4].  SIP clients MAY support escaped headers in the
  Refer-To: header.

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

  SIP-12, music on hold: SIP devices MUST support music on hold [4].

               draft-somefolks-sipdevice-req-00               [Page 5]

  SIP Telephony Device Requirements, Configuration and Data

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

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

  SIP-15: DTMF RTP payload: SIP clients MUST be able to send DTMF
  specified by RFC2833 [7].

  Payload type negotiation MUST comply with RFC 3264 [8].

  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-16, 180 ignores earlier media: SIP devices MUST generate local
  ringing and ingore any early RTP media when a ô180 Ringingö response
  is received.

  SIP-17, 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-18,  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-19, error-info support: SIP devices MUST support the Error-Info

  SIP-20, reason phrase display: If the ôReason Phraseö of a response
  message is displayed, the client MUST use ôReason Phraseö in the
  response packet.  The client MUST not use an internal ôStatus Codeö

  Another SIP device MAY respond with ô403 Forbiddenö, or various other

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

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

               draft-somefolks-sipdevice-req-00               [Page 6]

  SIP Telephony Device Requirements, Configuration and Data

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

  SIP-24, 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 Call Waiting Indicator to be set on a per identity basis.  If
  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 identities.

  SIP-25, Dynamic login/logout for user mobility: SIP devices MUST
  support user mobility.  SIP clients MUST store a static profile in
  non-volatile memory so that this information is available during the
  power up sequence.  SIP clients MUST allow a user to walk up to a
  client, login, and be able to send and receive calls with his profile
  For emergency numbers (e.g. 911) the client MUST send the credentials
  (username/password) of the static profile.

  SIP-26, multi-line ring tones: SIP devices MUST be able to provision
  a different ringtone for each line (ie. registration or static

   SIP Related Protocols

  SDP: SIP devices MUST support Session Description Protocol, RFC2327

  RTP/RTCP: SIP devices MUST support Real-Time Protocol and Real-Time
  Control Protocol, RFC1889 [12].

   SIP Security

  SIPsec-1, SIP Digest Authentication: SIP devices MUST support SIP
  Digest Authentication [2]

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

  SIPsec-3, disabling of remote services: SIP devices MUST be able to
  disable remote access, i.e. block incoming SNMP, HTTP, and other
  services not necessary for basic operation.

  SIPsec-4, INVITE user portion acceptance: SIP devices MAY be able to
  reject an incoming INVITE when the message does not come from the

               draft-somefolks-sipdevice-req-00               [Page 7]

  SIP Telephony Device Requirements, Configuration and Data

  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.

   Voice Codecs

  Internet telephony devices face the problem of supporting multiple
  codecs due to various historic reasons, on how industry players have
  approached codec implementations and the serious intellectual
  property and licensing problems associated with most codec types.
  Many, but not all voice codec payload types are described in RFC 1890
  [13] and other IETF MMUSIC WG [14] documents.

  Codec-1: Three main classes of voice codecs are supported by Internet
  telephony devices:

  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

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

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

  A compressed codec for Internet use without license fee is on the
  IETF standards track [15],  MUST be supported. Voice codecs used in
  2nd generation mobile phone systems, such as various GSM codecs are
  also found in various implementations and MAY be supported.

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

  Note: A summary count reveals up to and more than 15 voice codec
  types currently in use. The authors believe there is a need for a
  single multi-rate Internet codec that can effectively be substituted
  for all the multiple codec types listed here 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.

  Codec-2, codec negotiation: Endpoints MUST follow these guidelines in
  RFC 3264 :

  Initiator specifies "preferred" codec.

               draft-somefolks-sipdevice-req-00               [Page 8]

  SIP Telephony Device Requirements, Configuration and Data

  Receiver has "final" choice of codec selected.

  Both endpoints MUST use first codec listed by the receiver.

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

  Codec-3, comfort noise: SIP device MAY support comfort noise
  generation [16].  It is also RECOMMENDED that SIP clients comply with
  the "handset receive comfort noise" requirements outlined in the
  ANSI/EIA/TIA-810-A-2000 standard.

   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 TIA/EIA-810-A standard [17], [18].

  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 [17],
  [18 ] and TIA/EIA-579-A, at any voiceband 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.

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

   International Requirements

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

  International-2, international display support: SIP devices MAY
  support other languages for menus, help, and labels.

  Applications Requirements

               draft-somefolks-sipdevice-req-00               [Page 9]

  SIP Telephony Device Requirements, Configuration and Data

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

  App-1, automatic ring-down: SIP devices MAY support a ôbat phoneö
  setup where a URL is automatically dialed when the client goes off-

  App-2, 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.

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

  App-4, address-book integration: SIP devices MUST allow a 3rd party
  to initiate a call for the client. [20].

  App-5, SIMPLE Integration: SIP devices MUST provide a ôbuddy-
  list/addressbookö and use SIP extensions to leverage presence [21].

  Web-based Feature Management

  Web-1: SIP devices MUST support a web server to allow users to
  manually configure the phone and to setup phone services such as the
  address book, speed-dial, ringer tones, and last but not least the
  call handling options for the various lines, aliases, in a user
  friendly fashion. Web pages to manage the SIP telephony device MAY 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 MUST be accessible to authenticated
  users or operations personnel from remote locations.

  Firmware Update

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

   Firewall/NAT Traversal Requirements

  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.  SIP devices MUST have the capability to be configured so
  that the default domain and the 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

               draft-somefolks-sipdevice-req-00               [Page 10]

  SIP Telephony Device Requirements, Configuration and Data

  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 [x22].  SIP
  clients MUST be able to populate SIP messages with the public,
  external address of the NAT/PAT device and use specific port ranges
  for RTP.

  FW/NAT-3, UPnP capable configuration
  SIP devices MUST be able to operate with a UPnP
  (http://www.upnp.org/) firewall device.

   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 or with various interface models, such as
  for phones, IM or personal organizer. Given the variety of possible
  interfaces, the generic requirements only can be listed here.

  Int-1: SIP telephony devices MUST have a telephony-like dial-pad and
  MAY have telephony style buttons like mute, redial, 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 or graffiti for PDAs.

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

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

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

               draft-somefolks-sipdevice-req-00               [Page 11]

  SIP Telephony Device Requirements, Configuration and Data

  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 also facilitate
  remote device settings from a help desk, without user intervention.

   Multiple Line Appearances

  SIP telephony devices SHOULD support multiple SIP registrars and
  outgoing proxies with different user aliases.

  Lines-1: SIP telephony devices MAY support multiple lines.

  Lines-2: SIP telephony device line settings MAY support different SIP
  registrars, SIP proxy servers and different user names and password
  on each line, as well as different authentication mechanisms, such as
  password or SIP digest authentication.

      3. Configuration Processes

   Functional Configuration Groups

  The requirements for the configuration of a SIP user agent can be
  divided into the following high-level functions [23]:

  Profile Retrieval
  Change Notification
  Profile Upload
  Data Container.

  These functional groups are intended only to provide a means to think
  about and organize the requirements. They are NOT REQUIRED to be
  discrete steps, and they are not intended to dictate a specific

  Discovery is the means by which a new SIP user agent can
  automatically discover how and where to enroll and retrieve desired
  device and user profile(s).

  Enrollment is the means by which the user agent makes the profile
  server(s) aware of its presence and desire of specific users and/or
  device profiles.

  Profile Retrieval is the means by which the user agent gets the
  desired profiles(s).

               draft-somefolks-sipdevice-req-00               [Page 12]

  SIP Telephony Device Requirements, Configuration and Data

  Change Notification is the means by which the profile server tells
  the user agent that profiles of interest have changed.  Typically,
  the intention would be for the user agent to get those changes or the
  updated profiles.

  Profile Upload this is the means by which the user agent or other
  entities in the network can update or propagate changes to a profile
  on the server.

  The primary focus of security is on protecting the profiles from
  unauthorized access or change as well as integrity.

  Data Container is the container or object model for the profile data
  during transport to and from the server.  The primary issues are
  structure and hierarchy.

   Generic Configuration Requirements

  The SIP telephony device configuration requirements in this document
  are understood to be part of a configuration framework that includes
  both end devices and configuration servers.  The platforms (server
  and user agent) upon which this profile delivery framework MUST be
  deployed are very different in capability.  The user agents are
  largely embedded systems with limited resources for code and data
  size as well as CPU power (pure software based user agents are less
  constrained).  The profile server is likely to run on general purpose
  servers and therefore not
  as resource constrained.


  GenConf-1: The profile delivery framework MUST support the ability
  for profiles to roam.  That is, a user MAY go to another user agent
  within the server domain and with proper authorization, the user
  agent MUST be able to retrieve the user profile from the server and
  use the profile.

   Open and Extensible for Vendor Implementations

  OpenExt-1: The profile framework MUST allow vendor differentiation on
  both the server and user agent sides.
  This is largely an issue of how easy it is to make a more intelligent
  or active server or client without breaking the standard.

  OpenExt-2:   The profile framework MUST allow vendor differentiation
  on both the server and user agent sides.
  This is largely an issue of how easy it is to make a more intelligent
  or active server or client without breaking the standard.

   NAT/Firewall Support for Configuration

               draft-somefolks-sipdevice-req-00               [Page 13]

  SIP Telephony Device Requirements, Configuration and Data

  The primary issue relating to the profile delivery framework is the
  presence of NATs and/or firewalls between the profile server and the
  user agent.  It is assumed that if NATs or firewalls are present (in
  between) the user agents are on the inside and the profile server is
  effectively on the outside (e.g. public Internet).

  NAT/FW-Conf-1: The user agent MUST be able to reach the profile
  server through a NAT or firewall to perform all of the functions in
  the delivery framework.

  NAT/FW-Conf-2: The firewall or NAT SHOULD NOT require any additional
  configuration to enable the profile delivery framework to work.
  It is assumed that certain protocols are typically enabled on the NAT
  or firewall by default (e.g. HTTP access to servers outside).  It is
  assumed that SIP access in both directions is enabled or the user
  agent is not likely to be of much use.


  The purpose of discovery is to provide the means by which zero or
  minimal user interaction is required when plugging in a user agent
  for the first time in a specific profile server domain.  It is
  likely there is no single protocol solution for discovery due to the
  wide variety of typical network configurations including but not
  limited to networks:
  not connected to the Internet,
  with no DHCP server [24], [25]
  with no DNS SRV support,
  with a non-configurable DNS server.

  DIS-1: The user agent SHOULD be able to discover the profile server
  without human input.

  DIS-2: It MUST be possible to manually set the location of the
  profile server for a user agent.
  This is primarily a user agent implementation issue, not a protocol


  ENR-1: A user agent MUST be able to provide a unique identity to the
  profile server which does not change for the life of the UA.
  This allows user and device profiles to be associated with a
  particular user agent.

  ENR-2: A user agent requiring profiles SHOULD make itself known to
  the profile server.

  ENR-3: The user agent MUST identify profiles that it requires.

               draft-somefolks-sipdevice-req-00               [Page 14]

  SIP Telephony Device Requirements, Configuration and Data

  ENR-4: The profile server MAY be provisioned to know what profiles a
  user agent needs by default.
  There are a number of reasons for the above requirements.  In large
  scale deployments this MAY be important for load balancing purposes.
  This MAY be needed by the profile server so that it can understand
  which user agents are dependent upon which profiles.

  ENR-5: A user agent MAY request additional or different user profiles
  beyond the default provisioned for the user agent.
  This is primarily to support the notion of roaming.

  ENR-6: The user agent MUST provide specific information which MAY
  required by the server to customize the profile(s) for the user
  It MAY be necessary to provide different views of a profile based
  upon the specific configuration of the user agent. (for example,
  Vendor, Model number, Software or firmware version, serial number,
  MAC address, etc.).

  ENR-7: It SHOULD be possible for the profile server to deliver
  different views of a profile based upon characteristics of the user
  Though the objective is to provide a standardized profile that has
  the same content for all vendors user agents, in reality there are
  changes or differences to work around.  That is it MAY be desirable
  to put intelligence in the profile server to work around differences
  in user agent behavior or changes in the standardized profile content

  ENR-8: It MUST be possible to reassigned device-specific profiles,
  stored in the server, to a different user agent.
  This is to facilitate hardware swap out.

  ENR-9: It MUST be possible for the profile server, over time, to
  change the location(s) from which configuration data is retrieved.
  The intention is to allow server handoff as the result of failure,
  administration changes, load balancing, etc.

  ENR-10: The user agent SHOULD re-enroll periodically.
  The user agent basically SHOULD check in periodically with the
  profile server in case a network problem prevented change
  notification from getting to the user agent.

   Profile Retrieval

  RET-1: It MUST be possible for the user agent to retrieve the
  profile(s) it requires on demand.

  RET-2: It MUST be possible for the entire population of user agents
  to request and retrieve the required profiles in a short period of

               draft-somefolks-sipdevice-req-00               [Page 15]

  SIP Telephony Device Requirements, Configuration and Data

  This is a scalability requirement: e.g. during a power outage tens or
  hundreds of thousands of user agents MAY power up at once.

   Change Notification

  CN-1: The profile server MUST be able to notify dependent user agents
  of profile changes.

  CN-2: The user agent MUST be able to get the new updated profile.

  CN-3: The server MAY specify in advance that a configuration change
  is to occur.
  That is the profile server MAY schedule changes.

  CN-4:  The user agent MAY defer making profile changes effective
  until it is safe to do so.

  Some profile changes MAY disrupt the operation of the user agent.
  The user agent SHOULD alert the user and use discretion as to whether
  the change will disrupt critical operation (e.g. a call) of the user

   Profile Upload

  PU-1: A user agent MUST be able to upload changes to a profile on the
  profile server.
  This is to facilitate changes made either via a user interface on the
  user agent which are desired to be permanent as well as a means by
  which a external interface (e.g. a rich GUI on a general purpose
  computer)  MAY interface with the profile server.

  PU-2: The profile server SHOULD provide an access control mechanism
  to constrain who can read, write, delete, or be notified about change
  to profile data.


  User and device profiles MAY contain sensitive data such as passwords
  and identities.  It MUST be possible to protect the profiles and
  information about the profiles.

  SEC-1: The profile server SHOULD NOT provide access to profile data
  without authentication and authorization.

  SEC-2: The profile server MUST NOT allow a user agent to update
  profile data without authentication and authorization.

  SEC-3: The profile data, when transmitted over the network, SHOULD be
  protected against man in the middle attacks and snooping.

               draft-somefolks-sipdevice-req-00               [Page 16]

  SIP Telephony Device Requirements, Configuration and Data

  SEC-4: The profile server SHOULD NOT allow enrollment without
  authentication and authorization.

  SEC-5: The profile server SHOULD NOT provide change notification of
  profiles without authentication and authorization.

  SEC-6: The user agent SHOULD NOT interact with or trust any
  information from the profile server before authenticating the profile

  SEC-7: The information exchanged between the user agent and the
  profile server SHOULD be integrity protected.

  3.2.8. Data Container

  DA-1: The data container MUST support hierarchical and structured
  Note: for a better understanding of rational for this requirement see

  DA-2: It MUST be possible to define a standardized set of profile
  data that all user agents SHOULD support.

  DA-3: It MUST be possible for user agent vendors to add vendor
  specific data without breaking the standardized data set or requiring
  the creation of additional profiles.

  DAR-4: The data container MUST be flexible enough to contain
  additional data without breaking the profile server or the user
  agent, e.g. non-standard, vendor specific or standard updates.

  DAREQ-5: The user agent MUST be able to determine the differences
  when a profile has changed.
  Note: This can be determined either by getting only the added,
  removed or changed data or by calculating the difference between two

      4. Configuration Settings and Data

            4.1 General Behavior

  Configuration information related to the network identity of a device
  that can be discovered is described in the preceding chapter 4.
  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 end point. 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

               draft-somefolks-sipdevice-req-00               [Page 17]

  SIP Telephony Device Requirements, Configuration and Data

  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

  Settings MAY be read-only on the device. This avoids the miss-
  configuration of important settings by inexperienced users producing
  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 a setting up
  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 built-in value for the setting.

  The line concept allows configuration of phones in a user specific
  context. It simplifies unconstrained seating in offices and can
  support roaming users.

  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.2 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.3 Proxy and Registration Settings

  Server-1: 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 for the re-
  invite period SHOULD be used by the device.

            4.4 Network Related Settings

               draft-somefolks-sipdevice-req-00               [Page 18]

  SIP Telephony Device Requirements, Configuration and Data

  Network-1: SIP Ports.  The port that MUST be used for a specific
  transport protocol MAY be indicated with the SIP ports setting.

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

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

  Network-3: Network parameters. The parameters for SIP (like timer T1
  [9]) and other network related settings MAY be indicated.

  Network-4: RTP Port range. A range of port numbers MAY be used by a
  device for the consecutive pairs of ports which SHOULD be used to
  receive audio and control information (RTP and RCTP) for each
  concurrent connection.

  Network-5: External Network Address. A network address (such as an IP
  address) MAY be used by devices which make calls through a NAT. The
  device includes this IP address in the SIP messages and SDP it sends
  to other SIP user agents to indicate that this is the address to
  which SIP, RTP and RTCP packets SHOULD be send. This supports the
  case where the NAT is configured to statically map specific ports on
  the external interface to a specific end point inside the NAT. The
  end point in turn is configured to spoof other SIP entities into
  thinking it is the external interface on the NAT.

  The address consists of a host name plus an OPTIONAL port number,
  like sent-by in the Via header [2].

  Network-6: Outbound HTTP Proxy. An outbound HTTP proxy server IP
  address and port number MAY be used in cases where the device both
  supports an HTTP client and requires HTTP traffic to use a proxy

  Network-7: 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-8: Default Call Handling. All of the call handling settings
  defined below in section 5.3.2 can be defined here as default

  Network-9: Outbound Proxy. The outbound proxy [9] for a line or for a
  device MAY 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.

               draft-somefolks-sipdevice-req-00               [Page 19]

  SIP Telephony Device Requirements, Configuration and Data

  Network-10: 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.

            4.5 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 or TEL).

  Dial-1: Dial Plan. A dial plan which defines the maximum expected
  length of a typical telephone number SHOULD be used.

  Zero or more digit maps which map a dial plan and a SIP address to
  which phone numbers of that type SHOULD be routed 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
         3) an outbound proxy to 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

  Dial-2: Default Digit Map. The end point MUST support the
  configuration of a default digit map. If the end point does not
  support digit maps, it MUST 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-3: Overlap-Dial. Some operators support overlap dialing [2] 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.

            4.6 Audio

  Audio-1: Codecs. In many 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

  The range for parameters of the codecs MUST be adjustable. This
  includes the packet length (ms of audio), and the sample rate.
  However, the negotiation of the media for individual calls is being
  done on a per call basis.

               draft-somefolks-sipdevice-req-00               [Page 20]

  SIP Telephony Device Requirements, Configuration and Data

  Audio-2: DTMF method. DTMF allows different ways of indicating that a
  key has been pressed [30]. 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.7 Local and Regional Parameters

  Certain settings are dependant 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 Zone database [31]. 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.

  The network addresses of SNTP time servers where the device can get a
  centrally defined time MAY be used.

  Regional-4: The time server MAY be used.

  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 [32] 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.

            4.8 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

               draft-somefolks-sipdevice-req-00               [Page 21]

  SIP Telephony Device Requirements, Configuration and Data

  In-Auth-1: A device SHOULD the setting as to whether authentication
  (on the device) is required and what type of authentication is

  In-Auth-2: If inbound authentication is enabled then a list of
  allowed users and credentials to call this device SHOULD be used by
  the device. The credentials 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.9 Voice mail settings

  Various voice mail settings require the use of URL's as specified in

  VM-1: The MWI address setting controls where the client MAY SUBSCRIBE
  [8] to a voice mail server.

  VM-2: A retrieve address MAY be used by the device so it can get any
  voicemail messages it has.

  VM-3: A deposit address MAY be used to specify where voicemail
  messages SHOULD be left if the device is unable or unwilling to take
  a call.

            4.10 Phonebook and Call History

  IP Telephony devices can store locally a phonebook and also the
  history of recent calls. As an alternative, phonebook directory
  servers can provide a centralized store of phone numbers/addresses
  and potentially other information, such as provided by LDAP directory

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

  A record of the last calls made and received MAY also be stored
  locally or in a centralized location and referenced from devices.

  Call Hisytory-1: SIP telephony devices MAY store locally a recent
  (limited) call history or MAY make use of a central server for call

  If the phone maintains only one last dialed number, it SHOULD compare
  the incoming Last-Calls header against tried and dialed and store the
  newest entry.

               draft-somefolks-sipdevice-req-00               [Page 22]

  SIP Telephony Device Requirements, Configuration and Data

  Devices that are not able to differentiate call history entries
  between "tried" and "dialed" SHOULD use "dialed".

  A server MAY be used for storing the phonebook and call history.

  PhoneServers-1: Zero or more servers MAY be used for storing
  phonebook directories or call histories. If a server is defined and
  address such as a URL MUST be used and user name and credentials MAY
  be used for that server.

  The flush timeout MAY be specified for the server

  Users MAY wish to limit the number of data items that are returned to
  their device if a query is issued against one of the directory

            4.11 Ringer Behavior

  Simple SIP devices support only one identity. These devices SHOULD
  ignore all line related settings that do no affect the default
  outbound line settings they receive.

  The manner in which a user is alerted to an incoming call (visually,
  audibly or possibly both) MAY be used by the device. This includes
  the different volumes and MAY point to a file that contains the

  Ringer sound files MAY be specified for the following types of
  incoming calls normal, high priority, internal and external.
  Different ringer sound files MAY also be associated with different

            4.12 User Related Settings

  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

               draft-somefolks-sipdevice-req-00               [Page 23]

  SIP Telephony Device Requirements, Configuration and Data

  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 administrator 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 administrator 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 administrator to individually configure all of
  the lines individually (which would be particularly irksome using
  standard telephone button entry).

  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 (see [7]).  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-1:  User ID MAY be specified. If the user ID is specified, the
  address-of-record URL MAY be specified for the line definition.

            4.13 Line Related Settings

  Line Identification

  A line represents an address-of-record [9] 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 a address or record URL which both distinguishes
  the line and provides the URL which optionally will be registered for
  the line. A user friendly display name SHOULD be taken from the
  address-or-record URL for the line.

  A line definition MUST specify whether the line SHOULD automatically
  register with a registration server. 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 [9].

  A line definition MUST use call handling settings and the state of
  the phone to determine how to handle inbound calls. Inbound calls MAY
  be rejected, redirected, or accepted.

               draft-somefolks-sipdevice-req-00               [Page 24]

  SIP Telephony Device Requirements, Configuration and Data

            4.14 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 time is one hour.

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

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

            4.16 Call handling

  Call Handling settings define how the phone reacts to a new incoming
  call given different situations. In some cases, an end user MAY want
  to redirect calls to another party, rejected the call, or accepted
  the call and alert the end user. Some settings tend to be change
  irregularly like their voicemail forwarding address while others
  settings such as the do not disturb state MAY change often. Private
  networks and service provider networks MAY enable very sophisticated
  call handling options that MAY be supported more effectively on SIP
  servers, rather than in all SIP telephony devices. In such networks,
  call handling options in the SIP telephony device MUST be disabled to
  avoid feature interaction.

  CallOptions-1: Local call handling options like forwarding, such as
  to voice mail or other locations, available and busy behavior MUST
  have the option of being disabled locally, in case these services are
  provided by a SIP server.

            4.17 Available Behavior

  The Available Behavior defines how a new call is handled when the
  phone is not actively engaged in a call or when Call Waiting is
  enabled. Options include RING and FORWARD_ON_NO_ANSWER. A setting of
  RING alerts the user (as defined by the Ringer Behavior in 3.2.3) for
  a practical length of time before returning an error response to the
  caller if not answered.

  Available-1: All end points MUST use an available behavior setting.

  Available-2: FORWARD_ON_NO_ANSWER SHOULD alert the user for a
  configured amount of time (Forward on No Answer Timeout) and if not
  answered, forward to the Forward on No Answer address.

               draft-somefolks-sipdevice-req-00               [Page 25]

  SIP Telephony Device Requirements, Configuration and Data

  The Forward on No Answer setting identifies the address forwarded to
  after an alerting call exceeds the Forward On No Answer Timeout
  period. End points MUST use this parameter if the available behavior
  is set to FORWARD ON NO ANSWER and MAY define this parameter

  The Forward on No Answer Timeout defines the length of time that a
  user SHOULD be alerted for before the call is automatically redirect
  to the Forward on no answer SIP URL. This parameter is specified in
  seconds, where approximately 4 seconds is equivalent to a ring. End
  points MUST use this parameter if the available behavior is set to
  FORWARD ON NO ANSWER and MAY define this parameter otherwise.

            4.18 Busy Behavior

  The Busy Behavior defines how a new call is handled when the phone is
  engaged in an active call and call waiting is disabled or when the
  phone has reached the maximum number of connections.   Options
  include BUSY and FORWARD. A BUSY setting instructs the phone to
  respond with a 486/Busy here. A FORWARD setting redirects the caller
  to the Forward on Busy Address.

  Busy-1: All end points MUST use a busy behavior setting.

  The Forward on Busy SIP URL setting identifies the address forwarded
  to when the end point is busy. The end point is considered busy if a
  call is active and call waiting is disabled and when the phone has
  reached the maximum number of simultaneous connections. Since this
  parameter is dependent on the busy behavior, end points MUST define
  this setting if the BUSY behavior is set to FORWARD and MAY define
  this setting otherwise.

            4.19 Call Waiting Behavior

  Call Waiting controls the behavior of new calls when an existing call
  is already active and the device has not met the maximum number of
  connections. Options include ALERT and BUSY, where ALERT will alert
  the user as defined by the Ringing behavior and Available Behavior
  and BUSY will follow the busy behavior logic. All end points MUST use
  a call waiting behavior setting.

  Fwd-1, Unconditional Forwarding: The Unconditional Forwarding setting
  allows end users or administrators to forward all inbound calls to a
  designated Unconditional Forwarding SIP URL. This is useful if one
  wants to temporarily redirect all calls to another end point and
  administrative access to the directory servers is unavailable.
  Options include ENABLE and DISABLE, where ENABLE indicates that all
  inbound calls will be redirected and DISABLE indicates that all
  inbound calls will be treated as specified by the available, busy,
  and call waiting behaviors. All end points MUST use unconditional

               draft-somefolks-sipdevice-req-00               [Page 26]

  SIP Telephony Device Requirements, Configuration and Data

  The Unconditional Forwarding SIP URL identifies the address that
  inbound calls are redirected to if Unconditional Forwarding is
  enabled. All end points MUST use the unconditional forwarding
  address if unconditional forwarding is enabled, otherwise they MAY
  use it.

            4.20 Do Not Disturb

  The Do Not Disturb setting enables end users to quickly and easily
  enable and disable inbound calls for a particular line. Options
  include ENABLE and DISABLE, where ENABLE will handle a call as
  indicated by the Do Not Disturb Method and DISABLE allows normal call
  handling. This setting MUST be used by all end points.

  This setting MAY seem redundant to other the parameters defined
  within call handling, however, it addresses both an end user need
  along with administrative requirements. In some configurations, an
  end point MAY be configured to return a BUSY response to an inbound
  call so that a user agent within the network can try another party.
  The same results are required for Do Not Disturb.

  DND-1: Do Not Disturb Method MUST be able to support multiple methods
  of rejecting calls. Options include BUSY, FORWARD_ON_BUSY, and
  FORWARD_ON_NO_ANSWER. A setting of BUSY will return a BUSY response
  so that other network user agents can redirect the call as needed.
  FORWARD_ON_BUSY will redirect the call to the FORWARD_ON_BUSY SIP URL
  and FORWARD_ON_NO_ANSWER will for privacy reasons allow the caller to
  believe the call is alerting before forwarding to the Forward on No
  Answer SIP URL.

      5. Configuration Data Representation

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

  Requirements for Configuration Data Representation

  From reading 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 and administration point of view to be able
  to easily relate settings.

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

            5.1 Configuration Data Format - Examples

  The choice of the configuration data formats are best left to the
  discretion of the implementers and service providers. This document

               draft-somefolks-sipdevice-req-00               [Page 27]

  SIP Telephony Device Requirements, Configuration and Data

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

  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 URL.
  Vendors MAY add their own content within the XML document but MUST
  provide qualified names with their own namespace.

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

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

     <settings xmlnshttp://someurl
                  <dstrule>NORTH AMERICA</dstrule>
                  <!-- vendor extension -->
                  <acme:timezonedisplay>"PST"</acme:timezonedisplay >

            5.2 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 5 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.3 Handling of Unrecognized Element Names

  The default rule [34] 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.

               draft-somefolks-sipdevice-req-00               [Page 28]

  SIP Telephony Device Requirements, Configuration and Data

            5.4 Example XML Configuration Data

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

  Device settings

  A.  Network Settings

             <ethnetDuplex value="full"/>

  B. Address Completion

          <dialplan length="10"/>

  C. Audio

                  <codec priority="1">G729</codec>
                  <codec priority="3">G711</codec>
                  <codec priority="2">aLAW</codec>

               draft-somefolks-sipdevice-req-00               [Page 29]

  SIP Telephony Device Requirements, Configuration and Data


  D. Line default settings

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

  E. Line definition (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.

  User settings

  F. Voice mail settings


  G. Line definition (user)

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

               draft-somefolks-sipdevice-req-00               [Page 30]

  SIP Telephony Device Requirements, Configuration and Data

                          <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

  Contact: [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

               draft-somefolks-sipdevice-req-00               [Page 31]

  SIP Telephony Device Requirements, Configuration and Data

  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. SIP Telephony Device Security

  The device configuration MAY contain sensitive information that
  SHOULD 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
  achieve using symmetric key encryption.

  Access to retrieving configuration information is also an important
  issue. Both configuration server and clients SHOULD be able to do
  Digest authentication. A configuration server SHOULD challenge a
  subscriber before sending configuration information

      8. Acknowledgements

  Ian Butcher from Pingtel and Jonathan Knight from WorldCom have
  contributed significantly to earlier versions of parts of this
  Internet Draft. The authors would like to thank Prof. Henning
  Schulzrinne from Columbia University and Jay Batson from PingTel for
  detailed comments to the draft.  Peter Baker from Polycom has also
  provided valuable pointers to TIA/EIA IS 811 requirements to IP
  phones that are referenced here.

      9. Authors Addresses

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

  Daniel G. Petrie
  Pingtel Corp.
  400 W. Cummings Park
  Suite 2200
  Woburn, MA 01801, USA

               draft-somefolks-sipdevice-req-00               [Page 32]

  SIP Telephony Device Requirements, Configuration and Data

  Phone: +1 781 938 5306
  Email: dpetrie@pingtel.com

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

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

     10. References

  [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
  Levels", BCP 14, RFC 2119, March 1997

  [2] J. Rosenber et. al.:"SIP: Session Initiation Ptotocol, RFC 3261,
  IETF, June 2002.

  [3] A. Gulbrandsen et. al "A DNS RR for specifying the location of
  services (DNS SRV)" RFC 2782, February 2000.

  [4] A. Johnston et al. "SIP Service Examples", IETF, June 2002, work
  in progress.

  [5] R. Mahy: "A Message Summary and Message Waiting Indication Event
  Package for the Session Initiation Protocol (SIP)", IETF, October
  2002, work in progress.

  [6] R. Sparks: "SIP Call Control - Transfer", IETF, July 2001, work
  in progress.

  [7] H. Schulzrinne et al: "RTP Payload for DTMF Digits, Telephony
  Tones and Telephony Signals', RFC 2833, IETF, May 2000.

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

  [9] ITU-T Recommendation T.38, "Procedures for real-time Group 3
  facsimile communication over IP networks", June 1998.

  [10] A. Johnston et al.: "Session Initiation Protocol Torture Test
  Messages". IETF, Feb. 2002, work in progress.

               draft-somefolks-sipdevice-req-00               [Page 33]

  SIP Telephony Device Requirements, Configuration and Data

  [11] M. Handley et al.: "SDP: Session Initiation Protocol", RFC 2327.
  IETF, April 1998.

  [12] H. Schulzrinne et al.: " RTP: A Transport Protocol for Real-Time
  Applications", RFC 1889, IETF, January 1996.

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

  [14] The Multiparty Multimedia Session Control (mmusic) IETF working
  Group site, http://ietf.org/html.charters/mmusic-charter.html

  [15] Steven Andersen et. al.: "Internet Low Bit Rate Codec", IETF,
  September 2002, work in progress.

  [16] R. Zopf: "Real-time Transport Protocol (RTP) Payload for Comfort
  Noise (CN) ", RFC 3389, IETF, September 2002.

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

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

  [19] H. Schulzrinne et. al.: " Session Initiation Protocol (SIP)
  Caller Preferences and Callee Capabilities", IETF, July 2002, work in

  [20] J. Rosenberg et al.: " Best Current Practices for Third Party
  Call Control in the Session Initiation Protocol", IETF, June 2002,
  work in progress.

  [21] J. Rosenberg: " Session Initiation Protocol (SIP) Extensions for
  Presence", IETF, May 2002, work in progress.

  [22] J. Rosenberg et al. " STUN - Simple Traversal of UDP Through
  Network Address Translators", Internet Draft, IETF, April 2002, work
  in progress.

  [23] D. Petrie and C. Jennings: " Requirements for SIP User Agent
  Profile Delivery Framework", IETF, June 2002. Work in progress.

  [24] G.Nair, H.Schulzrinne , DHCP Option for SIP Servers, <draft-
  ietf-sip-dhcp-06.txt>, IETF; March 1, 2002, Work in progress.

               draft-somefolks-sipdevice-req-00               [Page 34]

  SIP Telephony Device Requirements, Configuration and Data

  [25] M. Mealling and R. Daniel, "The naming authority pointer (NAPTR)
  DNS resource record," Request for Comments 2915, Internet Engineering
  Task Force, Sept. 2000.

  [26] "SIP End Point Configuration Data Format" by C. Stredicke and
  Ian Butcher. Internet Draft, IETF, February 2002, work in progress.

  [27] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of
  the Differentiated Services Field (DS Field) in the IPv4 and IPv6
  Headers", RFC 2474, December 1998.

  [28] ISO/IEC 15802-3: 1998 ANSI/IEEE Std 802.1D, 1998 Edition,
  Information technology - Telecommunications and information exchange
  between systems - Local and metropolitan area networks - Common
  specifications - Part 3: Media Access Control (MAC) Bridges.

  [29] IEEE Std 802.1Q-1998, IEEE Standards for Local and Metropolitan
  Area Networks: Virtual Bridged Local Area Networks.

  [30] H. Schulzrinne, S. Petrack, RTP Payload for DTMF Digits,
  Telephony Tones and Telephony Signals, IETF, RFC 2833, May 2000.

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

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

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

  [34] H. Sugano et. al.: "Common Presence and Instant Messaging (CPIM)
  Presence Information Data Format". Internet Draft, IETF, October
  2002, work in progress.

  [35] T. Bray, J. Paoli, C. Sperberg-McQueen and E. Maler, "Extensible
  Markup Language (XML) 1.0 (Second Edition)",   W3C Recommendation,
  October 2000,   <http://www.w3.org/TR/2000/REC-xml-20001006>.

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

               draft-somefolks-sipdevice-req-00               [Page 35]

  SIP Telephony Device Requirements, Configuration and Data

Full Copyright Statement

  Copyright (C) The Internet Society (2002).  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

               draft-somefolks-sipdevice-req-00               [Page 36]

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