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

Versions: 00

   SIPPING WG                                  Venkatesh Venkataramanan
   Internet Draft                                     Sharath Rajasekar
  draft-sharath-sipb-requirements-00.txt
                                                        Sylantro Systems
   July 2003
   Expires: Jan 2004



                      SIP-B: SIP for Business Phones
     Requirements for Implementing Business Telephony Features on SIP
                                 Endpoints


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.


   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.


Abstract

   This informational internet draft describes the requirements for a
   standard business telephone based on the Session Initiation Protocol
   (SIP). The objective of this document is to provide a minimum set of
   requirements for implementing business features on SIP endpoints.

   This draft is intended to serve as a requirements document for
   vendors    implementing    business    features    on    SIP    based
   devices/entities. Details of how each capability or feature is best
   implemented in SIP, is beyond the scope of this document and may be
   tracked through the working group draft submissions.








   Venkatesh                                                         1
Internet-Draft                  SIP-B                       June 2003


Terminology

   Business Telephone: A device that is used to send and receive calls
   in a business environment.

   Feature: A function that facilitates a specified behavior.

   Feature  key:  A  button  on  a  phone  that  implements  locally  or
   indicates to the network a particular feature.

   SIP User Agent (UA): A SIP entity that can make and accept calls
   through SIP.

   Directory Number (DN): A telephone number or a SIP-URL identifying a
   business set.

   Line Key/Appearance: A button on a phone faceplate that handles
   incoming call to a phone.

   Bridged Line Appearance: A DN that is appears on more than one users
   phone.

   Line Appearance: A business telephone usually comprises of multiple
   keys that may be mapped to either DNÆs or for invoking a specific
   feature. Keys that are mapped to DNÆs are termed ææLine KeysÆÆ or
   ææLine AppearancesÆÆ.

   Primary Appearance: A user or a telephone that ææownsÆÆ a particular
   DN.


Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in RFC-2119 [1] and
   indicate requirement levels for compliant mechanisms.


Table of Contents

   1. Introduction....................................................3
   2. SIP Business Phone Capabilities.................................4
     2.1 Device Capabilities..........................................4
       2.1.1 Requirements for supporting Device Capabilities:.........4
     2.2 Line Capabilities............................................5
       2.2.1 Requirements for supporting Line Capabilities............5
     2.3 Audio / Visual Capabilities..................................6
       2.3.1 Requirements for supporting Audio and Visual Capabilities6
     2.4 Business Application Capabilities............................7
       2.4.1 Requirements for supporting Application Capabilities:....7

   Venkatesh                                                         2
Internet-Draft                  SIP-B                       June 2003


   3. SIP Business Phone Services.....................................8
     3.1 Dial Services................................................8
       3.1.1 Redial...................................................8
       3.1.2 Last call return.........................................8
       3.1.3 Call Hold................................................8
       3.1.4 Call UnHold..............................................9
       3.1.5 Do Not Disturb (DND).....................................9
       3.1.6 Call Transfer............................................9
       3.1.7 Speed Dial...............................................9
       3.1.8 Unconditional Call Forwarding............................9
       3.1.9 Conferencing.............................................9
       3.1.10 Hotline................................................10
       3.1.11 Warmline...............................................10
       3.1.12 Auto Off Hook..........................................10
       3.1.13 Call Park..............................................10
       3.1.14 Call Pickup (Picking up a parked call).................10
       3.1.15 Directed Call Pickup...................................10
       3.1.16 Group Call Pickup......................................10
       3.1.17 Camp On................................................10
       3.1.18 Bridged Line Appearances (BLA).........................10
     3.2 Audio/Visual Indication Services............................11
       3.2.1 Calling Name/Number Display.............................11
       3.2.2 Message Waiting Indication..............................12
       3.2.3 Call Waiting Indication.................................12
       3.2.4 Distinctive ringing.....................................12
       3.2.5 Intercom................................................12
       3.2.6 Barge...................................................12
       3.2.7 Paging..................................................12
     3.3 Digit Collection Services...................................12
       3.3.1 Authorization/Billing Codes.............................12
       3.3.2 Overlap Dialing.........................................13
     3.4 User Interface Services.....................................13
     3.5 Advanced Applications.......................................13
   4. Security Considerations........................................13
   5. Acknowledgements...............................................13
   References........................................................14
   Authors Addresses.................................................16
   Full Copyright Statement..........................................16


1. Introduction
   The next generation voice market has seen the introduction of User
   Agents  that  are  equipped  with  powerful  processors,  rich  user
   interfaces, and the ability to provide end user features well beyond
   that of their predecessors.




   Venkatesh                                                         3
Internet-Draft                  SIP-B                       June 2003


   This draft is intended to serve as a requirements document for
   vendors    implementing    business    features    on    SIP    based
   devices/entities. Details of how each feature is best implemented in
   SIP, is beyond the scope of this document and may be tracked through
   the working group draft submissions.

   In order to illustrate certain features, this draft makes use of the
   terms æætelephoneÆÆ, ææphoneÆÆ or ææbusiness phoneÆÆ. It is not a literal
   interpretation of a device or its capabilities but rather a term
   used to describe the functional attributes of a business endpoint.
   This in no way limits the scope and applicability of this document
   to physical devices available in the marketplace. The requirements
   specified in this document may be applied to any SIP user agent, SIP
   enabled device or soft phone in a business context.

   This document first describes the various capabilities that are
   required on a SIP business phone and then lists the required
   services that need to be supported on the phone.


2. SIP Business Phone Capabilities
   In order to function in a business context, a SIP business phone
   needs to have a base set of capabilities. This section defines the
   requirements  for  supporting  these  capabilities  in  four  general
   categories:

     . Device Capabilities.

     . Line Capabilities.

     . Display and Alerting Capabilities.

     . Business Application Capabilities.

2.1 Device Capabilities
   Device  capabilities  are  a  set  of  capabilities  needed  for  the
   business phone to send and receive SIP signaling and media. In order
   to configure a SIP business phone and authenticate it within a
   domain,  a  set  of  configuration  capabilities  is  needed.  These
   configuration options are part of the device capabilities, which
   determine how the phone is configured and integrated into the
   network.

 2.1.1 Requirements for supporting Device Capabilities:

   DC-1: A SIP business phone MUST have a network connection on which
   SIP signaling messages may be received and sent.

   DC-2: The SIP business phone MUST be addressable by an IP Address
   either through automatic configuration (DHCP) or through manual
   configuration.



   Venkatesh                                                         4
Internet-Draft                  SIP-B                       June 2003


   DC-3: A SIP business phone MUST support handset and hands-free mode.
   It MUST have an option to toggle between handset mode and hands-free
   mode.

   DC-3: A SIP business phone MUST receive and send media (RTP).

   DC-4: A SIP business phone MUST support the G.711 Codec for media.
   Additionally, the phones MAY support additional codecs like G.729.

   DC-5: A SIP business phone MUST support RFC 2833 [20] for the
   transport of DTMF digits in RTP.

   DC-6: The phone MUST support SIP REGISTER semantics per RFC 3261 [2]
   for registering with a registrar.

   DC-7: SIP business phones MUST allow for direct registrations where,
   the phone sends a REGISTER to the registrar and gets authenticated
   [2].

   DC-8: SIP business phones SHOULD allow for third party registrations
   where the phone may be registered by the operator/user through some
   external interface (without an explicit REGISTER message).

   DC-9: SIP business phones MUST have a configuration option for its
   outbound proxy or feature server. This is the address where it will
   register.

   DC-10: SIP business phones SHOULD support HTTP.


2.2 Line Capabilities
   Line capabilities are a set of capabilities needed for basic call
   processing,  and  enable  basic  telephony  services.  This  set  of
   capabilities enable users to place calls, receive calls and perform
   basic call control operations. Line capabilities provide the ability
   to select between multiple lines or choose to monitor the state of
   another phone line.

 2.2.1 Requirements for supporting Line Capabilities

   LC-1: A SIP business phone MUST support RFC 3261 [2]

   LC-2: A SIP business phone MUST support RFC 2782 [22] and query DNS
   SRV for resolving hostnames.

   LC-3: SIP business phones MUST support SDP media negotiation RFC
   2327 [23] and RFC 3264[7].

   LC-4: SIP business phones MUST support RFC 3262 [20] for ensuring
   that  provisional  responses  to  all  SIP  requests  are  delivered



   Venkatesh                                                         5
Internet-Draft                  SIP-B                       June 2003


   reliably  end-to-end  independent  of  the  underlying  transport
   mechanism.

   LC-5: SIP business phones MUST support RFC 3515 [19] for support of
   the SIP REFER method.

   LC-6: SIP business phones MUST support RFC 3326 [24] so that parties
   in a SIP session can send out detailed information about the actual
   reason for a call disconnect.

   LC-7: SIP business phones MUST support RFC 3325 [25] to enable a
   network of trusted servers to assert the identity of authenticated
   users.

   LC-8: SIP business phones MUST support RFC 3265 [26] so that
   notifications may be received from remote endpoints indicating that
   certain events have occurred.

   LC-9: SIP business phones MUST support RFC 3265 [26] for sending
   SUBSCRIBE   messages   to   subscribe   to   the   state   of   other
   lines/endpoints and accept NOTIFY messages that indicate any change
   in state of the remote device/line.

   LC-10: SIP business phones SHOULD SUBSCRIBE to the dialog state
   event [10] and Message Waiting Indication (MWI) event [27]. These
   subscriptions must be available on a per line basis. Phones MAY
   additionally SUBSCRIBE to other event packages based on the features
   served.

   LC-11: SIP business phones MUST be able to decode and interpret the
   text/xml MIME type.

   LC-11: A SIP business phone MUST support at least two or more calls.
   The phone must be able to initiate another call by placing the
   current call on hold.

   LC-12: A business phone SHOULD support two or more lines each
   identified by a separate address or single address.


2.3 Audio / Visual Capabilities
   These capabilities define the audio/visual, display and alerting
   capabilities of a SIP business phone.

 2.3.1 Requirements for supporting Audio and Visual Capabilities

   AVC-1: The business phone SHOULD provide a visual indicator that
   informs the user whether some invoked phone feature is active or
   inactive.

   AVC-2: SIP Business phones SHOULD provide a means to visually
   indicate media state during the invocation of a particular feature.

   Venkatesh                                                         6
Internet-Draft                  SIP-B                       June 2003


   For example the visual indication MAY be a flashing icon to indicate
   media state on HOLD, or MAY be a steady icon to indicate that media
   state is two way.

   AVC-3: SIP Business phones SHOULD have the capability to provide
   different alerting capabilities (like playing different wav files or
   providing a dialog box based on information provided by a network
   element) to the end user.

   AVC-4: SIP Business phones SHOULD allow a network element OR phone
   based configuration option to specify whether the alert mechanism is
   visual or audio or both.

   AVC-5: SIP Business phones SHOULD have a display that MAY be used
   for enabling a variety of features, such as indicating incoming
   calling name and number.

   AVC-6: The display SHOULD support context sensitive soft keys. Soft
   Keys are specialized feature keys that are not associated with a
   particular feature. Rather, the feature may be defined either on the
   UA or in the network, and assigned to a soft key using a label on
   the screen.


2.4 Business Application Capabilities
   Application capabilities are those capabilities that enable one or
   more business features to be loaded, removed or invoked on a
   business phone.

 2.4.1 Requirements for supporting Application Capabilities:

   BAC-1: SIP Business phones SHOULD support a toolkit approach to
   implementing features on the phone. Rather than negotiate each
   feature variant, this document suggests using a æætool kitÆÆ approach,
   wherein all SIP UAÆs provide and understand a generic set of
   services that can be used as building blocks to provide advanced
   business features.

   BAC-2: SIP Business phones SHOULD provide an end user with the
   capability to update or add new applications at any time.

   BAC-3: Application capabilities MAY be implemented locally on the
   user agent, or the user agent MAY have the capability to request
   services from the network upon invocation of a particular feature.
   SIP business phones SHOULD have a configuration option to indicate
   which features are implemented directly on the phone and which
   features require signaling with a feature server.

   BAC-4: The feature assigned to a particular soft key SHOULD be
   programmable (along with the label on the screen).




   Venkatesh                                                         7
Internet-Draft                  SIP-B                       June 2003


3. SIP Business Phone Services
   This section lists the services that need to be implemented on a SIP
   business phone. Business phone services are those features that are
   required on a business telephone based on the desired functionality
   of the end user in a business environment. Based on the variety of
   features that are required for business communications, we have
   classified the services under one of the following five categories:

     . Dial Services.

     . Audio/Visual Indication Services.

     . Digit collection Services.

     . User Interface Services.

     . Advanced Applications.


3.1 Dial Services
   All business telephony features that require a phone to accept a URL
   from an external application or use a pre-configured URL, and send
   out an INVITE towards its configured proxy are classified under this
   category of features.

   DS-1: This draft requires the origination of calls through the
   business phone on invocation of a specific feature. Configuration of
   auto-origination  of  calls  for  dial  services  is  left  to  the
   implementation of the phone. The user MAY be prompted to go off hook
   to originate the call. Alternatively, the user MAY request the phone
   to auto-originate the call through some prompt or configuration
   option.

 3.1.1 Redial
   DS-2: A SIP business phone MUST support redial operation. The last
   dialed URL / address must be cached on the phone and when the redial
   button is pressed (or activated by some other means) the phone
   should send the INVITE to the cached address. The cached redial
   URL/address SHOULD persist across phone reboots.

 3.1.2 Last call return
   DS-3: A SIP business phone MUST be able to call the last incoming
   unanswered call. The topmost via address of the last unanswered
   incoming call must be cached on the phone and when the last call
   return feature is invoked, the phone should send an INVITE to the
   cached address. The cached last call return URL/address SHOULD
   persist across phone reboots.

 3.1.3 Call Hold
   DS-4: All SIP business phones MUST support Call Hold. The user must
   be able to place an answered call on hold (by press a hold button or
   through some other means). Phones MUST support negotiating no-media


   Venkatesh                                                         8
Internet-Draft                  SIP-B                       June 2003


   during call hold. Phones MAY stream music to the caller during call
   hold.

 3.1.4 Call UnHold
   DS-5: All SIP business phones MUST support taking the call off hold.
   The caller (listening to silence/music) must be reconnected to the
   called party.

 3.1.5 Do Not Disturb (DND)
   DS-6: All SIP business phones MUST support DND. The DND feature,
   when activated, MUST reject any incoming call meant for the phone
   with a 486 Busy response code or MAY redirect the call to voice
   mail. If the user invokes the DND feature on an incoming call, the
   same behavior should apply for the incoming call. The DND feature
   may  be  programmed  directly  through  the  phone  or  through  some
   external interface.

 3.1.6 Call Transfer
   DS-7:  SIP  business  phones  MUST  support  blind  AND  consultative
   transfer. A user should be able to invoke a blind transfer and
   transfer the call to a specified address. The user must also have
   the flexibility of a consultative transfer where the current call is
   put on hold while a call is made to an address and some conversation
   ensues before the transfer is invoked.

 3.1.7 Speed Dial
   DS-8:  SIP  business  phones  MUST  support  speed  dials.  On  the
   invocation of the speed-dial feature, the phone MUST send out an
   INVITE to its configured proxy providing the number stored against
   this button (or the invoking key) in the Request URI. A detail of
   how  the  speed  dials  are  configured  is  left  to  the  phone
   implementation.

 3.1.8 Unconditional Call Forwarding
   DS-9: The SIP business phone MUST have a provision to specify an
   unconditional forwarding address. This setting would allow users or
   administrators  to  forward  all  incoming  calls  to  a  designated
   address.

   DS-10: The phone SHOULD allow the user or operator to manually
   configure the ring no answer (RNA) timeout associated with this
   forwarding. The phone must ring the existing destination for the
   specified number of seconds (RNA) before forwarding the call.

 3.1.9 Conferencing
   DS-11: SIP Business phones MAY support multi-way conferencing. The
   business phone MAY support local conferencing where the media mixing
   is performed directly on the device itself.

   DS-12: Conferencing through a centralized conference controller MAY
   be supported. In a centralized conference, the central conference
   controller handles the audio mixing.


   Venkatesh                                                         9
Internet-Draft                  SIP-B                       June 2003


 3.1.10 Hotline
   DS-13: The SIP business phone SHOULD support the hotline feature.
   When this feature is invoked, the phone must automatically make a
   call to a predesignated number/address.

 3.1.11 Warmline
   DS-14: The SIP business phone SHOULD support the warmline feature
   which is similar in operation to the hotline feature, except that on
   invocation, the phone waits for a predetermined time interval for
   the user to dial a number or url, after which time it automatically
   makes a call to a predesignated number/address.

 3.1.12 Auto Off Hook
   DS-15: SIP business phones MUST support auto offhook. The phone must
   be able to go offhook through some external instruction to the
   phone.

 3.1.13 Call Park
   DS-16: The SIP business phones MUST support call park. The phone
   should be able to park an incoming call at a specified extension
   number or address.

 3.1.14 Call Pickup (Picking up a parked call)
   DS-17: SIP business phones MUST support call pickup. The phone must
   be able to pick up a parked call from any number. By dialing out a
   specified address/URL the parked call should be picked up (thereby
   connected) to the phone.

 3.1.15 Directed Call Pickup
   DS-18: SIP business phones SHOULD support directed call pickup. This
   feature is a variant of regular call pickup. A user can pick up a
   call that is ææringingÆÆ at a SIP URL by dialing the SIP URL of the
   phone that is ringing. The phone should be able to pickup any
   incoming call to any business phone by invoking this feature.

 3.1.16 Group Call Pickup
   DS-19: SIP business phones SHOULD support group call pickup. This
   feature is a variant of regular call pickup. Any phone within a
   specified group should be able to pickup any incoming call to a
   business phone within the group. Methods of assigning phones to
   groups are outside the scope of this document.

 3.1.17 Camp On
   DS-20: SIP business phones SHOULD support Camp on. When a user
   receives a busy condition when making a call, may invoke the Camp on
   feature. Activation of this feature allows the user to hang up. The
   phone should continue calling the destination address until the call
   is answered at which time; it alerts the user that the call was
   successful.

 3.1.18 Bridged Line Appearances (BLA)
   DS-21: SIP business phones SHOULD support Bridged Line Appearances.
   The BLA feature allows a single DN to be monitored by multiple

   Venkatesh                                                        10
Internet-Draft                  SIP-B                       June 2003


   phones. When a call is offered to this DN, the call is offered to
   all phones that have a mapping to this DN.

   When a user answers the incoming call, the other users in the BLA
   group MUST be able to monitor the status of the call. When a call is
   in progress, other users in the BLA group MUST NOT be able to pick
   up that call.

   If a user places the call on hold, another member of the BLA group
   MAY pickup the call.

   Provisioning bridged line appearances and assignment of groups is
   left to the implementation of the phone.


3.2 Audio/Visual Indication Services
   All business telephony features that require a phone to provide
   various types of alert indications, be it visual or audible, require
   the  phone  to  automatically  accept  an  incoming  request,  are
   classified under this category of services.

   There are a number of business telephony services that rely upon the
   ability to generate different ring cadences based on the type of
   incoming call that is being offered to a telephone. Examples include
   providing ringing cadences based on incoming caller groups, incoming
   call types, incoming calling number.

   There  may  be  other  features  where-by  an  incoming  call  simply
   provides visual notification as against providing an audible ring
   tone. An example where such a capability is required is in a boss-
   secretary arrangement where by the secretaryÆs phone is the one that
   normally  rings,  where  as  the  bosses  phone  has  simply  visual
   indication.

   A third set of features requires that a specific tone be played
   before automatically answering an incoming call. Examples where such
   capabilities are desired include features like attendant barge-in,
   intercom, and group paging.

   The base SIP specification [2] enables supporting this feature by
   means of the Alert-Info header.

 3.2.1 Calling Name/Number Display
   AV-1: A SIP business phone MUST display the calling name OR calling
   number OR both for an incoming call. Additionally, phones may
   translate the incoming number into a name (or ænicknameÆ) based on a
   directory search. In case, the calling number/name is blocked, the
   phone MUST display ææAnonymousÆÆ OR ææUnknownÆÆ to denote that the
   incoming call has calling number or name blocked.





   Venkatesh                                                        11
Internet-Draft                  SIP-B                       June 2003


 3.2.2 Message Waiting Indication
   AV-2: SIP business phones MUST support message-waiting indication
   (MWI). This is typically a visual indication that alerts the user
   that there is a voice message that has not been read.

 3.2.3 Call Waiting Indication
   AV-3: SIP business phones MUST support call-waiting indication. When
   a call is in progress if another call comes to the user, a visual
   indication that shows the call waiting ID or audible beep MUST be
   implemented so that the user may place the existing call on hold and
   pickup the incoming call.

 3.2.4 Distinctive ringing
   AV-4: SIP business phones MUST support distinctive ringing. The user
   or operator should have the ability to apply different ring tones to
   different call types. Assignment of ring tones may be based on type
   of call (local, international etc) or based on the caller (friend,
   family, coworker etc). Assignment of ring tones and basis for
   choosing ring types are left to the phone implementation.

 3.2.5 Intercom
   AV-5: All SIP business phones SHOULD support the intercom feature.
   By invoking this feature, the destination phone should automatically
   go off hook and accept the incoming call. When an intercom session
   is in progress, the phone MUST display a visual indication for the
   length of the session.

 3.2.6 Barge
   AV-6: SIP phones SHOULD support the barge or executive override
   feature. When a call is in progress between two phones, another
   phone must be able to invoke the barge feature and ææbarge-inÆÆ to the
   existing  conversation  or  silently  monitor  the  conversation.
   Additionally, the operator SHOULD have the flexibility to ææwhisperÆÆ
   to one of the call participants. This feature is typically used in
   emergency management situations.

 3.2.7 Paging
   AV-7: SIP business phones SHOULD support paging or group paging. A
   phone within a group must be able to invoke this feature whereby
   calls are made all the phones (within a group) and the phones
   automatically understand that this is a paging feature and thereby
   answer the phone so that the operator invoking the paging feature
   may relay a message.


3.3 Digit Collection Services
   All business telephony features require that a phone support digit
   collection at various phases of a call set up. These services
   constitute the digit collection services.

   3.3.1 Authorization/Billing Codes
   DIGC-1: SIP business phones MUST support inputting authorization or
   billing codes. When the user dials a URL where the call is to be

   Venkatesh                                                        12
Internet-Draft                  SIP-B                       June 2003


   placed, one of the downstream feature proxies may decide that the
   user has mandatory billing codes enabled. It thus rejects the
   request with a 407 response providing the realm and domain where in
   the user needs to be authorized before letting the call through.

   3.3.2 Overlap Dialing
   DIGC-2: SIP Business phones MUST support overlap dialing where the
   user is prompted for more digits before completing the call.


3.4 User Interface Services
   The user interface services per this classification deals with
   providing a user interface for end users to use a particular
   feature. It is expected that the phone implement a user-friendly
   interface that clearly denotes the feature that is being invoked and
   the action expected from the user. The mechanics provided to allow
   the end user update phone configuration or settings are left to the
   individual vendor implementing these features and are outside the
   scope of this draft.


3.5 Advanced Applications
   Phone vendors may choose to implement advanced applications like
   stock quotes, calendar, match scores etc, over and above those
   listed  in  this  document.  These  applications  may  be  specially
   tailored to meet the business requirements for a specific usage.
   These applications may also serve to differentiate phones offered by
   different vendors. The definition of these applications and services
   is beyond the scope of this document.


4. Security Considerations
   SC-1: The requirements specified in this document mandates that SIP
   business phones MUST support all the security measures defined in
   RFC 3261 [2].

   SC-2: Adequate security measures need to be taken while implementing
   the  auto-offhook  feature,  which  can  be  easily  misused.  It  is
   recommended that a configuration option SHOULD be specified so that
   the user or operator may enable or disable this feature by logging
   into the phone or some external interface.

   SC-3: SIP business phones MUST have a way by which its configuration
   options on the phone or external interface are accessible only after
   authentication (through a logging in mechanism).

5. Acknowledgements

   Thanks to Kent Fritz, Sylantro Systems for his valuable comments and
   suggestions. The authors would also like to thank the following for
   being patient listeners, as well as for their valuable comments and
   suggestions: Cullen Jennings, Rohan Mahy, Dan Wing and Denise McCann
   from Cisco Systems, Paul Pepper and Steve Towlson of Citel, Anne

   Venkatesh                                                        13
Internet-Draft                  SIP-B                       June 2003


   Coulombe, John Albert, Jerry Yin and David Brown of Mitel, Rob
   Harder and Hong Chen of Polycom, Peter Kozdon and Stefan Karapetkov
   from Siemens.



References


   [1] S. Bradner, "Key words for use in RFCs to indicate requirement
   levels," Request for Comments 2119, Internet Engineering Task Force,
   Mar. 1997.

   [2] J. Rosenberg, H. Schulzrinne, et al., "SIP: Session initiation
   protocol," Request for Comments 3261, Internet Engineering Task
   Force, June 2002.

   [3] J. Rosenberg, "The SIP UPDATE Method," Internet Draft, Internet
   Engineering Task Force, Mar. 2002.  Work in progress.

   [4] J. Ott, C. Perkins, "SDPng Transition," Internet Draft, Internet
   Engineering Task Force, Feb. 2002.  Work in progress.

   [5] J. Rosenberg, et al., "Third Party Call Control in SIP,"
   Internet Draft, Internet Engineering Task Force, Nov. 2001.  Work
   in progress.

   [6] Mahy, Campbell, Johnston, et al., ææA Multi-party Application
   Framework for SIP,ÆÆ Internet Draft, Internet Engineering Task Force,
   June 2002. Work in progress.

   [7] J. Rosenberg, H.Schulzrinne, ææAn Offer/Answer Model with Session
   Description  Protocol,ÆÆ  Request  for  Comments  3264,  Internet
   Engineering Task Force, June 2002.

   [8] A.B. Roach, ææSession Initiation Protocol (SIP)-Specific Event
   NotificationÆÆ, Request for Comments 3265, Internet Engineering Task
   Force, June 2002

   [9] R. Sparks, ææThe SIP Refer MethodÆÆ, Request for Comments, RFC
   3515, Internet Engineering Task Force, March 2003.

   [10] J. Rosenberg, H. Schulzrinne, ææA Session Initiation Protocol
   (SIP) Event Package for Dialog StateÆÆ, Internet Draft, Internet
   Engineering Task Force, June 2002.

   [11] J. Rosenberg, H. Schulzrinne, ææA Session Initiation Protocol
   (SIP) Event Package for Conference StateÆÆ, Internet Draft, Internet
   Engineering Task Force, June 2002.

   [12] R. Mahy, D. Petrie, ææThe Session Initiation Protocol (SIP) Join
   HeaderÆÆ, Internet Draft, Internet Engineering Task Force, Oct 2002.


   Venkatesh                                                        14
Internet-Draft                  SIP-B                       June 2003


   [13] R. Mahy, ææUsing SIP for Peer-to-Peer Third-Party Call ControlÆÆ,
   Internet Draft, Internet Engineering Task Force, Nov 2000.

   [14] R. Mahy, B. Biggs, R. Dean, ææThe Session Initiation Protocol
   (SIP) Replaces headerÆÆ, Internet Draft, Internet Engineering Task
   Force, April 2002.

   [15] Lennox, Schulzrinne, ææCPL: A Language for User Control of
   Internet Telephony ServicesÆÆ, Internet Draft, Internet Engineering
   Task Force, January 2002.

   [16] J Lennox, H. Schulzrinne, ææCall Processing Language Framework
   and RequirementsÆÆ, Request For Comments 2824, Internet Engineering
   Task Force, May 2000.

   [17] A Johnston, R Sparks, ææSession Initiation Protocol Service
   ExamplesÆÆ, Internet Draft, Internet Engineering Task Force, August
   2003.

   [18] H Sugano, S Fujimoto, et al ææCommon Presence and Instant
   Messaging (CPIM) Presence Information Data FormatÆÆ, Internet Draft,
   Internet Engineering Task Force, June 2003.

   [19] Robert Sparks, ææThe Session Initiation Protocol (SIP) REFER
   MethodÆÆ, Request For Comments 3515, Internet Engineering Task Force,
   April 2003.

   [20] J. Rosenberg, H. Schulzrinne, ææReliability of Provisional
   ResponsesÆÆ, Request for Comments 3262, Internet Engineering Task
   Force, June 2002.

   [21] H. Schulzrinne, S. Petrack, ææRTP Payload for DTML digits,
   Telephony Tones and Telephony SignalsÆÆ, Request for Comments 2833,
   Internet Engineering Task Force, May 2000.

   [22] A. Gulbrandsen, P. Vixie, L. Esibov, ææA DNS RR for specifying
   the location of services (DNS SRV)ÆÆ, Request for Comments 2782,
   Internet Engineering Task Force, February 2000.

   [23] M Handley, V. Jacobson, ææSDP: Session Description ProtocolÆÆ,
   Request for Comments 2327, Internet Engineering Task Force, April
   1999.

   [24] H. Schulzrinne, D. Oran, G. Camarillo, ææThe Reason Header Field
   for the Session Initiation Protocol (SIP)ÆÆ, Request for Comments
   3326, Internet Engineering Task Force, December 2002.

   [25] C. Jennings, J. Peterson, M. Watson, ææPrivate Extensions to the
   Session  Initiation  Protocol  (SIP)  for  Asserted  Identity  within
   Trusted NetworksÆÆ, Request for Comments 3325, Internet Engineering
   Task Force, November 2002.



   Venkatesh                                                        15
Internet-Draft                  SIP-B                       June 2003


   [26] A. B. Roach, ææSession Initiation Protocol (SIP) Specific Event
   NotificationÆÆ, Request for Comments 3265, Internet Engineering Task
   Force, June 2002.

   [27] R. Mahy, ææA Message summary and Message Waiting Indication
   Event Package for the Session Initiation Protocol (SIP)ÆÆ, Internet
   Draft, Internet Engineering Task Force, March 2003.


Authors Addresses

   Venkatesh Venkataramanan
   Sylantro Systems Corp
   Campbell, CA
   Email: venkatar@sylantro.com
   sip:venkatar@sip.sylantro.com
   +1 408 626 3025

   Sharath Rajasekar
   Sylantro Systems Corp
   Campbell, CA
   Email: sharath@sylantro.com
   sip:sharath@sip.sylantro.com
   +1 408 626 2338



Full Copyright Statement
   Copyright (C) The Internet Society (2003).  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
   English.

   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
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.


   Venkatesh                                                        16


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