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

Versions: 00 01 02

BLISS                                                   A. Johnston, Ed.
Internet-Draft                                                     Avaya
Expires: August 29, 2007                                 M. Soroushnejad
                                                       V. Venkataramanan
                                                   Sylantro Systems Corp
                                                               P. Pepper
                                                      Citel Technologies
                                                                A. Kumar
                                                              Yahoo Inc.
                                                       February 25, 2007

Requirements and Implementation Options for the Multiple Line Appearance
          Feature using the Session Initiation Protocol (SIP)

Status of this Memo

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

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

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

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on August 29, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).


   This document describes the requirements for implementation of a

Johnston, et al.         Expires August 29, 2007                [Page 1]

Internet-Draft              SIP Reqs for MLA               February 2007

   group telephony feature commonly known as Bridged Line Appearance
   (BLA) or Multiple Line Appearance, or Shared Call/Line Appearance
   (SCA).  When implemented using the Session Initiation Protocol (SIP),
   it is referred to as Multiple Appearances.  This feature is commonly
   offered in the IP Centrex services and IP-PBX offerings and is likely
   to be implemented on SIP IP telephones and SIP feature servers used
   in a business environment.  This document lists requirements and
   compares implementation options for this feature.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions used in this document  . . . . . . . . . . . . . .  3
   3.  Usage Scenarios  . . . . . . . . . . . . . . . . . . . . . . .  3
   4.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  5
   5.  Implementation Options . . . . . . . . . . . . . . . . . . . .  6
     5.1.  Appearance Implementation Options  . . . . . . . . . . . .  9
       5.1.1.  URI parameter Approach . . . . . . . . . . . . . . . .  9
       5.1.2.  Dialog Package Parameter . . . . . . . . . . . . . . . 10
       5.1.3.  Incoming Appearance Assignment . . . . . . . . . . . . 11
       5.1.4.  Appearance Contention Resolution . . . . . . . . . . . 12
     5.2.  Comparison . . . . . . . . . . . . . . . . . . . . . . . . 12
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   8.  Informative References . . . . . . . . . . . . . . . . . . . . 13
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
   Intellectual Property and Copyright Statements . . . . . . . . . . 16

Johnston, et al.         Expires August 29, 2007                [Page 2]

Internet-Draft              SIP Reqs for MLA               February 2007

1.  Introduction

   The feature and functionality requirements for SIP user agents (UAs)
   supporting business telephony applications differ vastly from basic
   SIP user agents, both in terms of services and end user experience.
   In addition to basic SIP support, many of the services in a business
   environment require the support for SIP extensions such as REFER [3],
   SUBSCRIBE/NOTIFY primitives [4], the SIP Replaces [5] and Join [9]
   header fields, etc.  Many of the popular business services have been
   documented in the SIP Service Examples [6].

   This specification details a method for implementing a group
   telephony feature known in telephony as Bridged Line Appearance (BLA)
   or Multiple Line Appearance, one of the more popular advanced
   features expected of SIP IP telephony devices in a business
   environment.  Another common name for the this feature is Shared
   Call/Line Appearance (SCA).

   This document looks at how this feature can be implemented using
   standard SIP RFC 3261 [2] in conjunction with RFC 3265 [4] for
   exchanging status among user agents, and the SIP dialog state event
   package [7] to exchange dialog state information to achieve the same.
   Different approaches will be discussed including the use of URI
   parameters, feature tags, and dialog package extensions along with
   the strengths and weaknesses of the various approaches.

   A call flow for Single Line Extension was formerly included in the
   SIP Service Examples [6].  However, the attempt to implement using
   standard SIP primitives ultimately failed, leading to its removal
   from that document.  It is the hope of the authors that SIP
   extensions to meet the requirements of this important class of
   features will soon be standardized.

2.  Conventions used in this document

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

3.  Usage Scenarios

   The following examples are common applications of the Multiple
   Appearances feature and are mentioned here as informative use cases:

   1.  Executive/Assistant arrangement: The executive may appear as an

Johnston, et al.         Expires August 29, 2007                [Page 3]

Internet-Draft              SIP Reqs for MLA               February 2007

   appearance on the assistant SIP telephony device.  Assistant may
   answer incoming calls to executive and then place the call on hold
   for the executive to pick it up.  The assistant can always see the
   call state of the executive.

   2.  BLA Call Group: Users with similar business needs or tasks can be
   assigned to specific groups and share the line appearances of each
   other on each others SIP telephony devices.  For example, an IT
   department staff of five might answer a help line which has three
   appearances on each phone in the IT work area.  A call answered on
   one phone can be put on hold and picked up on another phone.  A shout
   or an IM to another staff member can result in them taking over a
   call on a particular appearance.

   3.  Virtual BLA: Allows a AOR, not assigned as a primary appearance
   to any user, to be set up as a BLA on a given set of user devices.

   All the example usages above can be supported by the Multiple
   Appearances feature described in this document, however the details
   of setup and usage of the above examples are not relevant to
   understanding of the BLA mechanism itself.

   Note that in this service, the AOR is commonly referred to as a
   Directory Address (DA).

   In traditional telephony, the line is physical.  A common scenario is
   for a number of business telephones to share a single or a small
   number of lines.  The appearance number relates to the user interface
   for the telephone - typically each appearance has a visual display
   (lamp that can change color or blink) and a button (used to select
   the appearance).  In SIP terms, the line is virtual.  However, the
   concept of appearance is still relevant to SIP due to the user
   interface considerations.  It is important to keep the appearance
   number construct because:

   1.  Human users are used to the concept and will expect it in
   replacement systems (e.g. an overhead page announcement says "Joe
   pickup line 3")

   2.  It is a useful structure for user interface representation

   3.  There are cases where for bandwidth or gateway limitations, it is
   useful to limit the number of concurrent sessions.

   In this document, we will use the term "appearance" as a stand-in for
   "line appearance".  Note that this does not mean that a conventional
   telephony user interface (lamps and buttons) must be used -
   implementations may use another metaphor as long as the appearance

Johnston, et al.         Expires August 29, 2007                [Page 4]

Internet-Draft              SIP Reqs for MLA               February 2007

   number is readily apparent to the user.

4.  Requirements

   The basic requirements of the multiple appearance feature can be
   summarized as follows:

   REQ-1 Incoming calls to the AOR must be offered to a group of UAs and
   can be answered by any of them.

   REQ-2 Each UA in the group must be able to learn the call status of
   the others in the group for the purpose of rendering this information
   to the user.

   REQ-3 Calls can be joined (also called bridged or conferenced
   together) or can be picked up (taken) by another UA in the group in a
   secure way.

   REQ-4 The mechanism should require the minimal amount of
   configuration.  UAs registering against the group AOR should be able
   to learn about each other and join the appearance group.

   REQ-5 The mechanism must scale for large numbers of appearances, n,
   and large numbers of UAs, N, without introducing excessive messaging

   REQ-6 Each call or session (incoming or outgoing) must be assigned a
   common "appearance" number from a managed pool administered for the
   AOR group.  Once the session has terminated, the appearance number is
   released back into the pool and can be reused by another incoming or
   outgoing session.

   REQ-7 Each UA in the group must be able to learn the line appearance
   status of the the group.

   REQ-8 There must be mechanisms to resolve appearance contention among
   the UAs in the group.

   REQ-9 The mechanism must allow all UAs receiving an incoming session
   request to select the same appearance number at the time of alerting.

   REQ-10 The mechanism must have a way of reconstructing appearance
   state after an outage that does not result in excessive traffic and

   REQ-11 The mechanism must have backwards compatibility such that a UA
   which is unaware of the feature can still register against the group

Johnston, et al.         Expires August 29, 2007                [Page 5]

Internet-Draft              SIP Reqs for MLA               February 2007

   AOR and make and receive calls.

   REQ-12 The mechanism must not allow UAs outside the group to select
   or manipulate appearance numbers.

   REQ-13 For privacy reasons, there must be a mechanism so that
   appearance information is not leaked outside the group of UAs. (e.g.
   "So who do you have on line 1?")

5.  Implementation Options

   Many of the requirements for this service can be met using standard
   SIP mechanisms such as:

   - A SIP Forking Proxy and Registrar/Location Service meets REQ-1.

   - The SIP Dialog Package meets REQ-2.

   - The SIP Replaces and Join header fields meets REQ-3.

   - The SIP Registration Package meets REQ-4.

   - The use of a State Agent for the Dialog Package meets REQ-5.

   REQ-6 suggests the need for an entity which manages the appearance
   resource.  Just as conferencing systems commonly have a single point
   of control, known as a focus, a Multiple Appearance group has a
   single point of control of the appearance shared resource.  This is
   defined as an Appearance Agent for a group.  While an Appearance
   Agent can be part of a centralized server, it could also be co-
   resident in a member User Agent who has taken on this functionality
   for a group.  The Appearance Agent learns the group state either by
   subscribing to the dialog state of each member UA individually or by
   dialog state publications from members.

   While the appearance resource could be managed co-operatively by a
   group of UAs without any central control, this is not discussed in
   this draft, but instead is left as a research project for future
   standardization.  It is also possible that the Appearance Agent logic
   could be distributed in all UAs in the group.  For example, rules
   that govern assigning appearance numbers for incoming requests (e.g.
   lowest available appearance number) and rules for contention handling
   (e.g. when two UAs request the use of the same appearance number,
   hash dialog identifiers and compare with the lowest hash winning)
   would need to be defined and implemented.

   REQs 6-13 can be implemented using a number of approaches, as

Johnston, et al.         Expires August 29, 2007                [Page 6]

Internet-Draft              SIP Reqs for MLA               February 2007

   discussed in the following sections.

   Figure 1 illustrates the SIP components involved in supporting these
   common requirements of the Multiple Appearance using standard SIP

   +----------------------------+                            +----+
   |                            |                            |    |
   |     Appearance Agent       |                            | UA |
   |                            |                            |    |
   +----------------------------+                            +----+
       ^ ^ |1)SUBSCRIBE  ^  ^    4)NOTIFY            INVITE     |
       | | |(Event:reg)  |  | registration sip:alice@example.com|
       | | V             |  |     events                        V
       | | +--------------------+        +----------+7)Query+--------+
       | | |    (example.com)   |        |          |<===== |        |
       | | |                    |3) Store| Location |       | Proxy  |
       | | |     Registrar      |=======>|  Service |       |        |
       | | |                    |        |          |=====> |        |
       | | +--------------------+        +----------+8)Resp +--------+
       | |     ^       ^                                       |  |
       | |     |       |  2) REGISTER (alice)                  |  |
       | |     |       |                                       |  |
       | |   +----+ +----+                                     |  |
       | |   |    | |    |                                     |  |
       | |   |UA1 | |UA2 |                                     |  |
       | |   |    | |    |                                     |  |
       | |   +----+ +----+                                     |  |
       | |    ^  ^    ^ ^                                      |  |
       | |    |  |    | |                                      |  |
       | +----+  |    | |                                      |  |
       |         |    | +--------------------------------------+  |
       |         +----+-------------------------------------------+
       |              |              8) INVITE
       +--------------+            sip:alice@example.com
       5-7) SUBSCRIBE and/or PUBLISH

   Figure 1.

   The next section discusses normal SIP operations used to implement
   parts of the multiple appearance feature.

   1.  The Appearance Agent SUBSCRIBES to the registration event package
   as outlined in [8] for contacts registered to the group AOR.  Thus,
   it has knowledge of all User Agents registered against the AOR at any
   point of time.

Johnston, et al.         Expires August 29, 2007                [Page 7]

Internet-Draft              SIP Reqs for MLA               February 2007

   2.  UAs (UA1 and UA2 in Figure 1) belong to the appearance group and
   REGISTER against the same AOR (e.g., sip:alice@example.com).

   3.  Each registration is stored in the Location Service.

   4.  The registrar notifies the Appearance Agent of successful
   registration at each UA.

   5.  UAs PUBLISH their dialog state to the State Agent in the
   Appearance Agent.  Alternatively, the Appearance Agent could
   SUBSCRIBE to the dialog state of each UA in the group.

   6.  The UAs SUBSCRIBE to the Appearance Agent for the state of all
   dialogs as defined in [7].  The Request-URI of the SUBSCRIBE could be
   either the AOR of the group, the Contact URI information it received
   in the incoming subscription from the Appearance Agent, or a
   provisioned URI.

   7.  The UAs PUBLISH their dialog information to the Appearance Agent
   every time their dialog state changes (i.e. receive an INVITE, enter
   alerting state, answer a call, terminate a call, generate an INVITE,
   etc.)  Note that alternatively the Appearance Agent could also
   SUBSCRIBE to the dialog state of each UA in the group.

   8.  Forking Proxy forks an incoming INVITE for the AOR address to the
   registered user agents.

   The User Agents in the group could SUBSCRIBE to each other and NOTIFY
   dialog state events, but in a large group the User Agents have to
   manage a larger number of SUBSCRIPTIONS and NOTIFICATIONS.  The State
   Agent in the Appearance Agent helps in managing large groups better.
   Further, the State Agent can filter dialog state events and NOTIFY
   User Agents of the dialog state events which are required for the
   application or feature.  The State Agent can also SUBSCRIBE to dialog
   state events with filters to reduce the number of NOTIFY messages
   exchanged between the State Agent and the user agents in the group.
   This allows a group of N UAs to each only establish a pair of dialog
   state subscriptions (one in each direction) to learn the dialog state
   of all other group members.  This results in 2N total subscriptions
   for the entire group.  A full mesh of subscriptions without a state
   agent would result in N(N-1) total subscriptions.

   The Appearance Agent can select the appearance number for an incoming
   call.  The appearance number is a non-negative integer: 0,1,2, etc.
   An Appearance agent can use the registration event package to learn
   how many UAs are part of the group.  The Appearance Agent sends a
   NOTIFY of dialog state events to all the User Agents.

Johnston, et al.         Expires August 29, 2007                [Page 8]

Internet-Draft              SIP Reqs for MLA               February 2007

5.1.  Appearance Implementation Options

   This section discusses and compares multiple methods of implementing,
   conveying, and selecting appearances in SIP while meeting the
   requirements of Section 4.  These approaches are a URI parameter and
   a SIP dialog package extension parameter.  All the approaches here
   assume the common elements and operations of Figure 1.  In addition,
   this section discusses approaches for incoming appearance indication,
   REQ-9, and appearance contention, REQ-8.  These approaches will be
   discussed for an example appearance group of N phones each with n
   line appearances.  The usage of the word phone does not imply that
   this feature is limited to telephony devices.

5.1.1.  URI parameter Approach

   Some implementations of this feature utilize a URI parameter such as
   "line=3" on the Contact URI.  Each appearance is effectively a
   logical UA, so each line appearance requires a separate registration.
   The number of line appearances needs to be provisioned on each phone.
   Each appearance also requires a separate dialog package subscription.
   Even using a State Agent for the dialog package, each phone must
   maintain n subscriptions to the dialog package.

   This results in 2nN total subscriptions and nN registrations for this

   Since Contact URI parameters will be conveyed by the dialog package,
   REQ-7 is met.

   REQ-10 can be met by having the Appearance Agent send a SUBSCRIBE to
   each UA and line number to obtain the current dialog state - this
   will result in nN SUBSCRIBEs and NOTIFYs.

   It is not obvious how to meet REQ-11 with this approach.  A UA
   registering against the AOR but does not implement the appearance URI
   parameter will not include a line appearance number in Contact URIs
   and dialog package NOTIFYs.  The Appearance Agent will have no way of
   indicating to the other UAs the appearance number being used by this
   UA, as adding a parameter to the Contact URI would cause call control
   operations such as Replaces and Join to fail.

   REQs 12 and 13 are difficult to meet with this approach as the line
   appearance number will be present in the Request-URI of incoming
   requests and the Contact URI in INVITE and 200 OK messages.  This
   approach will require integrity protection of all dialog creating
   requests and responses, and privacy mechanisms to hide the Contact
   URI from other UAs.

Johnston, et al.         Expires August 29, 2007                [Page 9]

Internet-Draft              SIP Reqs for MLA               February 2007

   Also, this approach will require mechanisms to protect against
   another UA sending an INVITE directly to a group member with the line
   appearance number already set.

5.1.2.  Dialog Package Parameter

   Instead of the URI parameter approach, consider an extension
   parameter "appearance" to the SIP dialog package as defined in
   [draft-anil-sipping-bla-04], e.g.:

   <?xml version="1.0"?>
   <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
       <dialog id="id3d4f9c83" direction="initiator">
               <target uri="sip:bob@example.com">
                   <param pname="appearance" pvalue="0"/>

   In this approach, the appearance number is never carried in a
   Request-URI or Contact URI.  Instead, it is only present in dialog
   package NOTIFY and PUBLISH messages.  As a result, only a single
   registration per AOR is required.  Also, only a single dialog package
   subscription in each direction per AOR.

   This results in 2N total subscriptions and N registrations for this

   If the dialog package is extended to carry the appearance number,
   then REQ-7 is met.

   REQ-10 can be met by having the Appearance Agent send a SUBSCRIBE to
   each UA and line number to obtain the current dialog state - this
   will result in N SUBSCRIBEs and NOTIFYs.

   REQ-11 can be met by this approach.  Even though a UA does not
   provide an appearance number in dialog package NOTIFYs, the
   Appearance Agent can assign one and include it in NOTIFYs to the
   other UAs.  This parameter would simply be ignored by the UAs that
   did not understand the parameter, and have no impact on call control

Johnston, et al.         Expires August 29, 2007               [Page 10]

Internet-Draft              SIP Reqs for MLA               February 2007


   REQs 12 and 13 are met because the appearance number is only conveyed
   in dialog package NOTIFYs.  Integrity and privacy of NOTIFY bodies
   can be achieved using normal SIP mechanisms independent of the
   security mechanisms used for other requests.

   With this approach, the number of appearances is centrally managed
   and controlled by the Appearance Agent.  For UAs with soft keys or
   buttons, this gives a great deal of flexibility in system management.

5.1.3.  Incoming Appearance Assignment

   To best meet REQ-9, the appearance number for an incoming INVITE
   should be contained in the INVITE itself.

   For the URI parameter approach, REQ-9 is met since incoming requests
   will have the line appearance number in the Request-URI.  However,
   this requires the forking proxy know which line appearance number has
   been selected by the Appearance Agent and to fork the INVITE to only
   those Contact URIs.  This means that a simple forking proxy server
   can not be used with this implementation option.

   For the dialog package parameter approach, REQ-9 could be met in two
   ways.  When an incoming request is received, the Appearance Agent
   could send out a NOTIFY with state trying and include the appearance
   number to be used for this request.  Upon receipt of this NOTIFY, the
   UAs could being alerting using the appearance number selected.  This
   approach is sub-optimal since the UAs could receive the INVITE but be
   unable to begin alerting if the NOTIFY from the Appearance Agent is
   delayed or lost

   An alternative approach is to define an extension parameter is
   defined for the Alert-Info header field in RFC 3261 as in
   [draft-anil-sipping-bla-04], e.g.

   Alert-Info: <file://ring.pcm>;alert=normal;appearance=0

   This Alert-Info header would indicate to place the call on the first
   line appearance instance.

   The determination as to what value to use in the appearance parameter
   can be done at the proxy that forks the incoming request to all the
   registered UAs.  There are a variety of ways the proxy can use to
   determine what value it should use to populate this parameter.  For
   example, the proxy could fetch this information by initiating a
   SUBSCRIBE request with Expires: 0 to the Appearance Agent for the AOR
   to fetch the list of lines that are in use.  Alternatively, it could

Johnston, et al.         Expires August 29, 2007               [Page 11]

Internet-Draft              SIP Reqs for MLA               February 2007

   act like a UA that is a part of the appearance group and SUBSCRIBE to
   the State-Agent like any other UA.  This would ensure that the active
   dialog information is available without having to poll on a need
   basis.  It could keep track of the list of active calls for the
   appearance AOR based on how many unique INVITE requests it has forked
   to or received from the appearance AOR.

   The Appearance Agent needs to know about all incoming requests to the
   AOR in order to select the appearance number.  One way in which this
   could be done is for the Appearance Agent to register against the AOR
   with a higher q value.  This will result in the INVITE being sent to
   the Appearance Agent first, then being offered to the UAs in the

5.1.4.  Appearance Contention Resolution

   In the selection of an appearance for requests initiated by UAs in
   the group, there is the possibility of contention where more than one
   UA select the same appearance number.

   One way to solve this and meet REQ-8 is to require UAs to send a
   PUBLISH (trying) to the Appearance Agent indicating the appearance
   number to be used for the session.  The Appearance Agent would
   confirm the allocation of the appearance number in a NOTIFY sent to
   the group UAs.  Should the appearance number be unavailable or
   otherwise not allowed, there are two options:

   - The PUBLISH could be rejected with a 500 response and a Retry-After
   header field.  The Appearance Agent would send an immediate NOTIFY
   indicating that the appearance is unavailable.  If the NOTIFY is
   received before the expiration of the Retry-After time, the PUBLISHed
   state information would become out of date and would be discarded
   without resending.  The UA would select another appearance number and
   PUBLISH again.

   - The PUBLISH could be accepted but an immediate NOTIFY generated by
   the Appearance Agent indicating that the appearance is unavailable.
   The UA would then select another appearance number and PUBLISH again.

   UAs would wait for a notification from the Appearance Agent before
   sending the INVITE.

5.2.  Comparison

   In comparing the URI parameter and the dialog package parameter,
   there are clear differences in the number of registrations and
   subscriptions, with the dialog package approach requiring n times
   fewer in both cases.

Johnston, et al.         Expires August 29, 2007               [Page 12]

Internet-Draft              SIP Reqs for MLA               February 2007

   The security model for the dialog package parameter approach is much
   cleaner, since only NOTIFYs need integrity and privacy.  The security
   model for the URI parameter approach would likely require a B2BUA
   which introduces many undesirable properties.

   The dialog package parameter approach has better backwards
   compatibility than the URI parameter approach.

   In summary, the dialog package parameter approach better meets REQs
   5, 10, 11, 12, and 13 while the URI parameter approach better meets
   REQ-9.  However, the combined dialog package parameter approach and
   the Alert-Info parameter approach meets REQ-9.

6.  IANA Considerations


7.  Security Considerations

   Since multiple line appearance features are implemented using
   semantics provided by RFC 3261 [2], Event Package for Dialog State as
   define in [7], and Event Notification [4], security considerations in
   these documents apply to this draft as well.

   Specifically, since dialog state information and the dialog
   identifiers are supplied by UA's in an appearance group to other
   members, the same is prone to "call hijacks".  For example, a rogue
   UA could snoop for these identifiers and send an INVITE with Replaces
   header containing these call details to take over the call.  As such
   INVITES with Replaces header MUST be authenticated using the standard
   mechanism (like Digest or S/MIME) described in RFC 3261 [2] before it
   is accepted.  NOTIFY message bodies that provide the dialog state
   information and the dialog identifiers MAY be encrypted end-to-end
   using the standard mechanics.  All SUBSCRIBES between the UA's and
   the Event Agent MUST be authenticated.

8.  Informative References

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

   [2]   Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
         Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
         Session Initiation Protocol", RFC 3261, June 2002.

Johnston, et al.         Expires August 29, 2007               [Page 13]

Internet-Draft              SIP Reqs for MLA               February 2007

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

   [4]   Roach, A., "Session Initiation Protocol (SIP)-Specific Event
         Notification", RFC 3265, June 2002.

   [5]   Mahy, R., Biggs, B., and R. Dean, "The Session Initiation
         Protocol (SIP) "Replaces" Header", RFC 3891, September 2004.

   [6]   Johnston, A., "Session Initiation Protocol Service Examples",
         draft-ietf-sipping-service-examples-12 (work in progress),
         January 2007.

   [7]   Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE-
         Initiated Dialog Event Package for the Session Initiation
         Protocol (SIP)", RFC 4235, November 2005.

   [8]   Rosenberg, J., "A Session Initiation Protocol (SIP) Event
         Package for Registrations", RFC 3680, March 2004.

   [9]   Mahy, R. and D. Petrie, "The Session Initiation Protocol (SIP)
         "Join" Header", RFC 3911, October 2004.

   [10]  Kumar, A., "Implementing Bridged Line Appearances (BLA) Using
         Session Initiation  Protocol (SIP)", draft-anil-sipping-bla-03
         (work in progress), June 2006.

   [11]  Niemi, A., "Session Initiation Protocol (SIP) Extension for
         Event State Publication", RFC 3903, October 2004.

Authors' Addresses

   Alan Johnston (editor)
   St. Louis, MO  63124

   Email: alan@sipstation.com

   Mohsen Soroushnejad
   Sylantro Systems Corp

   Email: mohsen.soroush@sylantro.com

Johnston, et al.         Expires August 29, 2007               [Page 14]

Internet-Draft              SIP Reqs for MLA               February 2007

   Venkatesh Venkataramanan
   Sylantro Systems Corp

   Email: venkatar@sylantro.com

   Paul Pepper
   Citel Technologies

   Email: paul.pepper@citel.com

   Anil Kumar
   Yahoo Inc.

   Email: anil@yahoo-inc.com

Johnston, et al.         Expires August 29, 2007               [Page 15]

Internet-Draft              SIP Reqs for MLA               February 2007

Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an

Intellectual Property

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

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

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


   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Johnston, et al.         Expires August 29, 2007               [Page 16]

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