[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/