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