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

Versions: 00 01 02 03 04

   SIPPING WG                                      Mohsen Soroushnejad
   Internet Draft                                             (Editor)
   Expires: December 15, 2006                 Venkatesh Venkataramanan
   Category: Informational                            Sylantro Systems
                                                            Paul Pepper
                                                     Citel Technologies
                                                             Anil Kumar
                                                             Yahoo Inc.
                                                          June 15, 2006


              Implementing Bridged Line Appearances (BLA)
                 Using Session Initiation Protocol (SIP)
                     draft-anil-sipping-bla-03.txt


   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-
   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/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet Draft will expire on December 15, 2006.

   Copyright Notice

      Copyright (C) The Internet Society (2006).

   Abstract
   This document describes the implementation of Bridged Line
   Appearance (BLA) feature based on Session Initiation Protocol (SIP).
   The BLA feature is commonly offered in the IP Centrex services and
   IP-PBX offerings. This feature is likely to be implemented on SIP IP
   telephones and SIP feature servers used in a business environment.


                           Table of Contents
   1. Introduction....................................................3
   Soroushnejad, et al.                                       [Page 1]


Internet-Draft         Bridged Line Appearance           June 15 2006

   2. Terminology.....................................................3
   3. Conventions used in this document...............................3
   4. Feature Description.............................................3
   4.1 Usage Scenarios................................................4
   5. Overview of Operation...........................................4
   5.1 Line Appearance Resources......................................6
   5.2 Bridged Line Appearance Resource Allocation....................7
   6 Example Message Flows............................................8
   6.1 Registration and Subscription Flows............................8
   6.1.1 Alice Registration and Subscription Flow.....................8
   6.1.2 Bob Registration and Subscription Flow......................13
   6.2 Call Originated by a UA in a BLA group........................18
   6.3 Call Offered to a BLA Group...................................28
   7. New Event Package Parameter....................................32
   8. State and Error Recovery.......................................33
   8.1 Line Seize (Refresh Subscription).............................33
   8.2 Line Seize (Notifier Failure).................................34
   8.3 Line Seize (Race Condition)...................................35
   9. Security Considerations........................................35
   10. References....................................................36
   11. Acknowledgements..............................................36
   12. Author’s Contact Information..................................36
   13. Full Copyright Statement......................................37
   14. Intellectual Property Statement...............................37
   Soroushnejad, et al.                                       [Page 2]


Internet-Draft         Bridged Line Appearance           June 15 2006



1. Introduction

   The feature and functionality requirements for SIP user agents
   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 in [2], many of the services in a
   business environment require the support for SIP extensions such as
   REFER [3], SUBSCRIBE/NOTIFY primitives [4], SIP Replaces header [5],
   etc. Many of the popular business services have been documented in
   the SIPPING service-examples draft [6]. In the same spirit, this
   document details a proposal for implementing Bridged Line Appearance
   (BLA), one of the more advanced popular features expected of SIP IP
   telephony devices in a business environment. Another common name for
   the BLA feature is Shared Call/Line Appearance (SCA).
   The proposal for the most part uses standard SIP RFC 3261 [2], in
   conjunction with RFC 3265 [4] for exchanging presence status among
   user agents, and the dialog state draft [7] to exchange dialog state
   information to achieve the same.

2. Terminology

   Directory Address (DA): An Address Of Record that is assigned to a
   user and typically bounded to the user’s SIP device.

   Line Appearance: A logical object that supports a single SIP session
   or call. On SIP telephony devices, a line appearance is typically
   realized as a hard or soft button to place outgoing calls or receive
   incoming calls. It may also provide visual indications for the
   status of the line appearance.

   Primary Appearance: A DA that can be used as a primary identifier of
   a user and the associated user agent.

   Bridged Line Appearance (BLA): A DA that is bounded onto multiple
   SIP user agents.

   BLA group: All users that share a BLA on their SIP devices are
   referred to as belonging to a BLA group. In a BLA group, the users
   may have a primary appearance in addition to the BLA DA.
   Furthermore, the BLA DA may be a primary appearance of another user
   in the group.

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

4. Feature Description

   BLA allows an Address Of Record (AOR) to be assigned onto different
   line appearances of group of SIP user agents (e.g., SIP IP telephony
   Soroushnejad, et al.                                       [Page 3]


Internet-Draft         Bridged Line Appearance           June 15 2006

   clients). When a call is made to this DA, the call is offered to all
   user agents that have mapping to this DA. Users may choose via local
   settings to use distinctive alerting for incoming calls to the BLA
   address or use a standard alerting for all incoming calls.
   Regardless, one user among the BLA group may answer the call. Once
   the call is answered, all other devices reflect the current state of
   the call (mark the appropriate line appearance as in use). The
   feature allows other users that belong to this BLA group to pick
   this call based on the state of the call. Typically, the feature
   allows users to pick a call only when the dialog is placed on hold.
   Visual indications may be provided to the user to indicate that the
   call is being held and can be picked up on a line appearance
   associated with the BLA DA.
   Similarly, when a user places an outgoing call using such an
   appearance, all members that belong to the BLA group are notified of
   this usage, and are blocked from using this line appearance until
   the line appearance goes back to Idle state or if the call is placed
   on hold. User agents can be configured with the multiple instances
   of the BLA line appearance of same DA in order to support multiple
   calls or dialogs on the same DA.

4.1 Usage Scenarios

   The following examples are common applications of the BLA feature
   and are mentioned here as an infomative use cases:

   1. Executive/Assistant arrangement: The executive DA may appear as a
   BLA 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.
   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.
   3. Virtual BLA: Allows a DA, 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 BLA 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.

5. Overview of Operation

   This proposal uses the following components to enable this feature:
   - SIP Registrar
   - SIP Forking Proxy
   - State Agent (SA)

   The following figure illustrates the SIP components involved in
   supporting the BLA feature as described in this document.

   +----------------------------+                            +----+
   |                            |                            |    |
   |        State Agent         |                            | UA |
   |                            |                            |    |
   Soroushnejad, et al.                                       [Page 4]


Internet-Draft         Bridged Line Appearance           June 15 2006

   +----------------------------+                            +----+
       A A |1)SUBSCRIBE  A  A    4)NOTIFY            INVITE     |
       | | |(Event:reg)  |  |   registration  alice@example.com |
       | | V             |  |     events                        V
       | | +--------------------+        +----------+7)Query+--------+
       | | |    (example.com)   |        |          |<===== |        |
       | | |                    |3) Store| Location |       | Proxy  |
       | | |     Registrar      |=======>|  Service |       |        |
       | | |                    |        |          |=====> |        |
       | | +--------------------+        +----------+8)Resp +--------+
       | |     A       A                                       |  |
       | |     |       |  2) REGISTER (alice)                  |  |
       | |     |       |                                       |  |
       | |   +----+ +----+                                     |  |
       | |   |    | |    |                                     |  |
       | |   |UA1 | |UA2 |                                     |  |
       | |   |    | |    |                                     |  |
       | |   +----+ +----+                                     |  |
       | |    A  A    A A                                      |  |
       | |    |  |    | |                                      |  |
       | +----+  |    | |                                      |  |
       |         |    | +--------------------------------------+  |
       |         +----+-------------------------------------------+
       |              |              8) INVITE
       +--------------+            alice@example.com
       5-7) SUBSCRIBE
            (Event:dialog)

   1. The State Agent SUBSCRIBES to the registration event package as
   outlined in [8] for contacts registered to BLA AOR. Thus, it has
   knowledge of all User Agents registered to BLA AOR at any point of
   time.
   2. User Agents (UA1 and UA2 in above figure) belong to a BLA group
   and REGISTER for the same address-of-record (e.g.,
   alice@example.com). If a given UA has a primary appearance different
   from the BLA AOR, it registers the BLA AOR using the SIP third-party
   registration mechanism [2].
   3. Each registration is recorded.
   4. The registrar notifies the State Agent of successful registration
   at each UA.
   5. The State Agent SUBSCRIBE to User Agents for the state of all
   dialogs associated with the BLA Contact URI, as defined in [7].

   All User Agents that belong to the BLA group MUST support the dialog
   state package as outlined in [7] to NOTIFY other User Agents of the
   dialog-state. Further, they SHOULD understand and support the (sla)
   event parameter outlined in this draft. Section 7 of this draft
   outlines how this parameter is to be interpreted by the UA. The
   local session description MUST be included in the dialog payload,
   when the local user has placed a call on hold. The element should
   indicate that the call that is the subject of the dialog is being
   held (use of a=inactive or a=sendonly is RECOMMENDED [9]).

   Soroushnejad, et al.                                       [Page 5]


Internet-Draft         Bridged Line Appearance           June 15 2006

   6. The User Agents SUBSCRIBE to State Agent for the state of all
   dialogs as defined in [7] using the contact information it received
   in the incoming subscription from the state agent.

   7. The User Agents act as the notifier for the dialog state events
   as defined in [7].

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

   The State Agent sends a NOTIFY of dialog state events to all the
   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 helps in managing large groups better. Further, the
   State Agent MAY filter dialog state events and NOTIFY User Agents of
   the dialog state events which are required for the application or
   feature. The State Agent MAY 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 BLA group.

5.1 Line Appearance Resources

   There are many user agents that support the concept of line
   appearances. On SIP telephony devices, a line appearance is
   typically realized as a hard or soft button to place outgoing calls
   or receive incoming calls. It may also provide visual indications
   for the status of the line appearance. Typically, the end users
   configure an AOR per line appearance offered with a user agent. In
   turn, the UA offers/sends the call to/from the specific line
   appearance when a call is placed or received for that AOR. It is
   possible to configure the same Address of Record for multiple line
   appearances on the same user agent. In such scenarios, the UA uses
   its own local resource management to offer the first incoming call
   to the first line, the second to the next idle line up to the
   maximum configured before it starts rejecting calls with a 486 Busy
   request. Such a configuration has some implications on how Bridged
   (Shared) Line Appearances operate. User agents that support such a
   concept MUST send only one REGISTER for the AOR instead of sending
   one per line appearance. Furthermore, in such scenarios, user agents
   MAY indicate which line appearance a call is being offered to or
   placed from in the NOTIFY payload.
   Generally, it is desirable, if more that one line appearance is
   configured for a given BLA DA, to map calls on the BLA line
   appearances so a call will appear on the same line appearance
   instance for every configured UA.  To do this, the "x-line-id"
   parameter is used in the examples in this document.

   When calls are presented to a UA, the Alert-Info header will contain
   an x-line-id parameter.  Alert-Info was selected over the request-
   URI because intermediate proxies are less likely to change the
   Alert-Info header.  The UA should use the number indicated to select
   a line appearance to present to the user.  For example:

   Soroushnejad, et al.                                       [Page 6]


Internet-Draft         Bridged Line Appearance           June 15 2006

   Alert-Info: <file://ring.pcm>;alert=normal;x-line-id=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 x-line-id parameter
   can be done at the proxy that forks the incoming request to all the
   registered UA's. 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 for the BLA DA to fetch the list
   of lines that are in use. Alternatively, it could act like a UA that
   is a part of the BLA group and SUBSCRIBE to the State-Agent like any
   other UA. This would ensure that the active dialog information is
   availabe without having to poll on a need basis. It could keep track
   of the list of active calls for the BLA AOR based on how many unique
   INVITE requests it has forked to or received from the BLA AOR. The
   actual mechanism is left to the implementation.

   When a UA indicates, via a dialog-info NOTIFY command, a state
   change on a dialog, the x-line-id parameter is placed in the
   parameters of the local target of the dialog-info.  For example:

   <?xml version="1.0"?>
   <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
                version="6"
                state="partial"
                entity="sip:alice@example.com">
       <dialog id="id3d4f9c83" direction="initiator">
           <state>trying</state>
           <local>
               <target uri="sip:bob@example.com">
                   <param pname="x-line-id" pvalue="0"/>
               </target>
           </local>
       </dialog>
   </dialog-info>
   ...

   The UA MUST send dialog-info in state "trying" with the appropriate
   x-line-id parameter present in the local target when it is
   attempting to 'seize' a line. It MUST do this before it sends out
   the INVITE request.

   It should be noted that the x-line-id parameter is relative to the
   DA. Thus a UA can support multiple DA's with each DA capable of
   supporting x-line-id's sequentially numbered from 0 through 'n'
   where 'n' is the number of lines the UA supports for each of the
   DA's.

5.2 Bridged Line Appearance Resource Allocation

   Even in trivial deployments of two BLA-enabled user agents, race
   conditions can exist when both user agents attempt to seize a shared
   line simultaneously (i.e. when the NOTIFY messages, that each user
   Soroushnejad, et al.                                       [Page 7]


Internet-Draft         Bridged Line Appearance           June 15 2006

   agent sends to the other, are active within the network during an
   overlapping time period). The SIP-specific event notification
   framework, described in [4], defines the use of state agents. State
   agents act on behalf of resources to publish state. The State Agent
   can use any policy deemed necessary to resolve races and ensure no
   two user agents obtain the same line seize during overlapping
   periods.
   It is also necessary to distinguish between a line seize for the
   purpose of initiating a call (i.e. as an initiator) and a line seize
   used to accept a call (i.e. as a recipient). Without this
   distinction we quickly run into problems. To illustrate the type of
   problems that can result, consider an incoming call on a BLA. If
   there were only one type of seize, and only one instance of a line
   seize per BLA, one of either the initiator or recipient must perform
   the seize operation or neither should seize the line. If the
   initiator seizes the line, then there is no way the recipient can
   seize the line to accept the call. Alternatively, if the recipient
   performs the seize operation, more than one call could be placed on
   the shared line before the recipient seizes the share line just
   prior to answering the call. Finally, if neither initiator nor
   recipient seizes the line, then it becomes possible for other user
   agents to place outbound calls on the shared line. By distinguishing
   between the initiator and recipient of a call we can ensure only one
   user is allowed to initiate a call on a shared line and ditto for
   receiving a call. A full lock on a shared line resource is only
   achieved when both its initiator and recipient locks have been
   issued. The use of the <direction> element (specified in [4]) on
   line seize operations suffices for this purpose. It is worth making
   a distinction between a shared line and the users of that shared
   line. A shared line will normally have an association with a number
   of users. However, distinguishing users from lines encourages
   thinking of the shared line as a resource on which calls can be
   initiated and received by an initiator and a recipient,
   respectively.


6 Example Message Flows
6.1 Registration and Subscription Flows

   Bob has bridged line appearance for Alice. Bob REGISTER for Alice’s
   AOR using contact sip:alice@ua2.example.com. Furthermore, Bob
   REGISTER his primary address with contact sip: bob@ua2.example.com.
   Alice REGISTER with contact sip:alice@ua1.example.com.
   The State Agent subscribes to dialog states of the BLA DA (i.e.,
   sip:alice@example.com) at the User Agents for Alice and Bob. Message
   exchange between the Registrar, State Agent, Alice, and Bob are
   shown below.
   The call flow examples below do not show challenging of
   subscriptions or notifications. It should be noted that for security
   purposes, all subscriptions MUST be authorized before the same is
   accepted.

6.1.1 Alice Registration and Subscription Flow

   Registrar        State Agent             Alice
   Soroushnejad, et al.                                       [Page 8]


Internet-Draft         Bridged Line Appearance           June 15 2006

   |                    |                    |
   |                    |                    |
   |<--------------------------- REGISTER F1<|
   |                    |                    |
   |>F2 401 Unauthorized ------------------->|
   |                    |                    |
   |<--------------------------- REGISTER F3<|
   |                    |                    |
   |>F4 200 OK ----------------------------->|
   |                    |                    |
   |                    |>F5 SUBSCRIBE ----->|
   |                    |                    |
   |                    |<-------- 200 OK F6<|
   |                    |                    |
   |                    |<-------- NOTIFY F7<|
   |                    |                    |
   |                    |>F8 200 OK -------->|
   |                    |                    |
   |                    |<----- SUBSCRIBE F9<|
   |                    |                    |
   |                    |>F10 202 Accepted ->|
   |                    |                    |
   |                    |>F11 NOTIFY ------->|
   |                    |                    |
   |                    |<------- OK 200 F12<|
   |                    |                    |


   F1-F4: Alice registers AOR with contact: <sip:alice@ua1.example.com>

   F1 Alice ----> Registrar

   REGISTER sip:registrar.example.com SIP/2.0
   Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bK527b54da8ACC7B09
   From: <sip:alice@example.com>;tag=CDF9A668-909E2BDD
   To: <sip:alice@example.com>
   CSeq: 1 REGISTER
   Call-ID: d3281184-518783de-cc23d6bb@ua1.example.com
   Contact: <sip:alice@ua1.example.com>
   User-Agent: ABC-UA/1.2.3
   Max-Forwards: 70
   Expires: 3600
   Content-Length: 0


   F2 Registrar ----> Alice

   SIP/2.0 401 Unauthorized
   Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bK527b54da8ACC7B09
   CSeq: 1 REGISTER
   Call-ID: d3281184-518783de-cc23d6bb@ua1.example.com
   From: <sip:alice@example.com>;tag=CDF9A668-909E2BDD
   To: <sip:alice@example.com>;tag=1026148581664839
   Soroushnejad, et al.                                       [Page 9]


Internet-Draft         Bridged Line Appearance           June 15 2006

   WWW-Authenticate: Digest
   realm="example.com",nonce="3281fad606d8b0fe89f60d9292b842fc",opaque=
   "",stale=FALSE,algorithm=MD5
   Content-Length: 0


   F3 Alice ----> Registrar

   REGISTER sip:registrar.example.com SIP/2.0
   Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKfbf176ef7F1D5FA2
   From: <sip:alice@example.com>;tag=CDF9A668-909E2BDD
   To: <sip:alice@example.com>
   CSeq: 2 REGISTER
   Call-ID: d3281184-518783de-cc23d6bb@ua1.example.com
   Contact: <sip:alice@ua1.example.com>
   User-Agent: ABC-UA/1.2.3
   Authorization: Digest username="alice", realm="example.com",
   nonce="3281fad606d8b0fe89f60d9292b842fc", opaque="",
   uri="sip:registrar.example.com",
   response="b90508e14cec5ae95d9d5aa878a4cb75", algorithm=MD5
   Max-Forwards: 70
   Expires: 3600
   Content-Length: 0

   F4 Registrar ----> Alice

   SIP/2.0 200 OK
   Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKfbf176ef7F1D5FA2
   CSeq: 2 REGISTER
   Call-ID: d3281184-518783de-cc23d6bb@ua1.example.com
   From: <sip:alice@example.com>;tag=CDF9A668-909E2BDD
   To: <sip:alice@example.com>;tag=1664573879820199
   Contact:  <sip:alice@ua1.example.com>
   Expires:  3600
   Content-Length: 0


   F5 to F8: Once Alice registers, State Agent subscribes to the events
   at the contact registered for Alice and Alice notifies the State
   Agent of its status.

   F5 State Agent ----> Alice

   SUBSCRIBE sip:alice@ua1.example.com SIP/2.0
   From: <sip:alice@example.com>;tag=110286377866002
   To: <sip:alice@example.com>
   Call-ID: 284-425690188@example.com
   CSeq: 2 SUBSCRIBE
   Via: SIP/2.0/UDP
   stateagent.example.com;branch=z9hG4bK1979345546866532
   Event: dialog;sla
   Expires: 3700
   Contact: <sip:sa@stateagent.example.com>
   Content-Length: 0

   Soroushnejad, et al.                                      [Page 10]


Internet-Draft         Bridged Line Appearance           June 15 2006


   F6 Alice ----> State Agent

   SIP/2.0 200 OK
   Via: SIP/2.0/UDP
   stateagent.example.com;branch=z9hG4bK1979345546866532
   From: <sip:alice@example.com>;tag=110286377866002
   To: <sip:alice@example.com>;tag=717A8C26-BA734CE3
   CSeq: 2 SUBSCRIBE
   Call-ID: 284-425690188@example.com
   Contact: <sip:alice@ua1.example.com>
   Event: dialog;sla
   User-Agent: ABC-UA/1.2.3
   Expires: 3700
   Content-Length: 0


   F7 Alice ----> State Agent

   NOTIFY sip:sa@stateagent.example.com SIP/2.0
   Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKa2269cc565A30870
   From: <sip:alice@example.com>;tag=717A8C26-BA734CE3
   To: <sip:alice@example.com>;tag=110286377866002
   CSeq: 1 NOTIFY
   Call-ID: 284-425690188@example.com
   Contact: <sip:alice@ua1.example.com>
   Event: dialog;sla
   User-Agent: ABC-UA/1.2.3
   Subscription-State: active;expires=3698
   Max-Forwards: 70
   Content-Type: application/dialog-info+xml
   Content-Length: 164

   <?xml version="1.0"?>
   <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
                version="0"
                state="full"
                entity="sip:alice@example.com">
   </dialog-info>

   F8 State Agent ----> Alice

   SIP/2.0 200 OK
   Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKa2269cc565A30870
   CSeq: 1 NOTIFY
   Call-ID: 284-425690188@example.com
   From: <sip:alice@example.com>;tag=717A8C26-BA734CE3
   To: <sip:alice@example.com>;tag=110286377866002
   Allow-Events: dialog;sla
   Contact: <sip:sa@stateagent.example.com>
   Content-Length: 0

   F9 to F12: Alice also subscribes to the events associated with the
   Alice AOR with State Agent. State Agent also notifies Alice of the
   status.
   Soroushnejad, et al.                                      [Page 11]


Internet-Draft         Bridged Line Appearance           June 15 2006


   F9 Alice ----> State Agent

   SUBSCRIBE sip:sa@stateagent.example.com SIP/2.0
   Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKf10fac97E7A76D6A
   From: <sip:alice@example.com>;tag=925A3CAD-CEBB276E
   To: <sip:sa@stateagent.example.com>
   CSeq: 1 SUBSCRIBE
   Call-ID: ef4704d9-bb68aa0b-474c9d94@ua1.example.com
   Contact: <sip:alice@ua1.example.com>
   Event: dialog;sla
   User-Agent: ABC-UA/1.2.3
   Accept: application/dialog-info+xml
   Max-Forwards: 70
   Expires: 3700
   Content-Length: 0


   F10 State Agent ----> Alice

   SIP/2.0 202 Accepted
   Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKf10fac97E7A76D6A
   CSeq: 1 SUBSCRIBE
   Call-ID: ef4704d9-bb68aa0b-474c9d94@ua1.example.com
   From: <sip:alice@example.com>;tag=925A3CAD-CEBB276E
   To: <sip:sa@stateagent.example.com>;tag=1636248422222257
   Allow-Events: dialog;sla
   Expires: 3700
   Contact: <sip:sa@stateagent.example.com>
   Content-Length: 0

   F11 State Agent ----> Alice

   NOTIFY sip:alice@ua1.example.com SIP/2.0
   From: <sip:sa@stateagent.example.com>;tag=1636248422222257
   To: <sip:alice@example.com>;tag=925A3CAD-CEBB276E
   Call-ID: ef4704d9-bb68aa0b-474c9d94@ua1.example.com
   CSeq: 2 NOTIFY
   Via: SIP/2.0/UDP
   stateagent.example.com;branch=z9hG4bK1846984327225734
   Max-Forwards: 70
   Content-Type: application/dialog-info+xml
   Event: dialog;sla
   Subscription-State: active
   Contact: <sip:sa@stateagent.example.com>
   Content-Length: 162

   <?xml version="1.0"?>
   <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
                version="40"
                state="full"
                entity="sip:alice@example.com">
   </dialog-info>

   F12 Alice ----> State Agent
   Soroushnejad, et al.                                      [Page 12]


Internet-Draft         Bridged Line Appearance           June 15 2006


   SIP/2.0 200 OK
   Via: SIP/2.0/UDP
   stateagent.example.com;branch=z9hG4bK1846984327225734
   From: <sip:sa@stateagent.example.com>;tag=1636248422222257
   To: <sip:alice@example.com>;tag=925A3CAD-CEBB276E
   CSeq: 2 NOTIFY
   Call-ID: ef4704d9-bb68aa0b-474c9d94@ua1.example.com
   Contact: <sip:alice@ua1.example.com>
   Event: dialog;sla
   User-Agent: ABC-UA/1.2.3
   Content-Length: 0


6.1.2 Bob Registration and Subscription Flow



   Registrar        State Agent             Bob
   |                    |                    |
   |                    |                    |
   |<--------------------------- REGISTER F1<|
   |                    |                    |
   |>F2 401 Unauthorized ------------------->|
   |                    |                    |
   |<--------------------------- REGISTER F3<|
   |                    |                    |
   |>F4 200 OK ----------------------------->|
   |                    |                    |
   |<--------------------------- REGISTER F5<|
   |                    |                    |
   |>F6 401 Unauthorized ------------------->|
   |                    |                    |
   |<--------------------------- REGISTER F7<|
   |                    |                    |
   |>F8 200 OK ----------------------------->|
   |                    |                    |
   |                    |>F9 SUBSCRIBE ----->|
   |                    |                    |
   |                    |<------- 200 OK F10<|
   |                    |                    |
   |                    |<------- NOTIFY F11<|
   |                    |                    |
   |                    |>F12 200 OK ------->|
   |                    |                    |
   |                    |<---- SUBSCRIBE F13<|
   |                    |                    |
   |                    |>F14 202 Accepted ->|
   |                    |                    |
   |                    |>F15 NOTIFY ------->|
   |                    |                    |
   |                    |<------- 200 OK F16<|
   |                    |                    |

   Soroushnejad, et al.                                      [Page 13]


Internet-Draft         Bridged Line Appearance           June 15 2006

   F1 to F4: Bob registers his (primary) AOR with contact
   sip:bob@ua2.example.com.

   F1 Bob ----> Registrar

   REGISTER sip:registrar.example.com SIP/2.0
   Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK41599ad63A2E521F
   From: <sip:bob@example.com>;tag=9F80647C-94355FE3
   To: <sip:bob@example.com>
   CSeq: 1 REGISTER
   Call-ID: e4a1e078-75ccf65a-1a4c1ee1@ua2.example.com
   Contact: <sip:bob@ua2.example.com>
   User-Agent: XYZ-UA/4.5.6
   Max-Forwards: 70
   Expires: 3600
   Content-Length: 0

   F2 Registrar ----> Bob

   SIP/2.0 401 Unauthorized
   Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK41599ad63A2E521F
   CSeq: 1 REGISTER
   Call-ID: e4a1e078-75ccf65a-1a4c1ee1@ua2.example.com
   From: <sip:bob@example.com>;tag=9F80647C-94355FE3
   To: <sip:bob@example.com>;tag=1370290862415334
   WWW-Authenticate: Digest
   realm="example.com",nonce="fbfa92fb954eb092de6b89433154f093",opaque=
   "",stale=FALSE,algorithm=MD5
   Content-Length: 0

   F3 Bob ----> Registrar

   REGISTER sip:registrar.example.com SIP/2.0
   Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK1b1c1d25FB82B2DE
   From: <sip:bob@example.com>;tag=9F80647C-94355FE3
   To: <sip:bob@example.com>
   CSeq: 2 REGISTER
   Call-ID: e4a1e078-75ccf65a-1a4c1ee1@ua2.example.com
   Contact: <sip:bob@ua2.example.com>
   User-Agent: XYZ-UA/4.5.6
   Authorization: Digest username="bob", realm="example.com",
   nonce="fbfa92fb954eb092de6b89433154f093", opaque="",
   uri="sip:registrar.example.com",
   response="59f805336b9b7e81470d3841f3d0016a", algorithm=MD5
   Max-Forwards: 70
   Expires: 3600
   Content-Length: 0

   F4 Registrar ----> Bob

   SIP/2.0 200 OK
   Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK1b1c1d25FB82B2DE
   CSeq: 2 REGISTER
   Call-ID: e4a1e078-75ccf65a-1a4c1ee1@ua2.example.com
   From: <sip:bob@example.com>;tag=9F80647C-94355FE3
   Soroushnejad, et al.                                      [Page 14]


Internet-Draft         Bridged Line Appearance           June 15 2006

   To: <sip:bob@example.com>;tag=468305689550907
   Contact:  <sip:bob@ua2.example.com>
   Expires:  3600
   Content-Length: 0

   F5 to F8: Bob registers Alice AOR with his client using SIP third-
   party registration.

   F5 Bob ----> Registrar

   REGISTER sip:registrar.example.com SIP/2.0
   Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK5f3f2c694DF31062
   From: <sip:bob@example.com>;tag=81B52F2F-7EA64EE6
   To: <sip:alice@example.com>
   CSeq: 1 REGISTER
   Call-ID: 55d48e6b-a0598cad-9ab32f84@ua2.example.com
   Contact: <sip:alice@ua2.example.com>
   User-Agent: XYZ-UA/4.5.6
   Max-Forwards: 70
   Expires: 3600
   Content-Length: 0

   F6 Registrar ----> Bob

   SIP/2.0 401 Unauthorized
   Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK5f3f2c694DF31062
   CSeq: 1 REGISTER
   Call-ID: 55d48e6b-a0598cad-9ab32f84@ua2.example.com
   From: <sip:bob@example.com>;tag=81B52F2F-7EA64EE6
   To: <sip:alice@example.com>;tag=631889299347457
   WWW-Authenticate: Digest
   realm="example.com",nonce="04ff2106fd51729fb22d99b959787417",opaque=
   "",stale=FALSE,algorithm=MD5
   Content-Length: 0

   F7 Bob ----> Registrar

   REGISTER sip:registrar.example.com SIP/2.0
   Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKdf17f688391F7DF1
   From: <sip:bob@example.com>;tag=81B52F2F-7EA64EE6
   To: <sip:alice@example.com>
   CSeq: 2 REGISTER
   Call-ID: 55d48e6b-a0598cad-9ab32f84@ua2.example.com
   Contact: <sip:alice@ua2.example.com>
   User-Agent: XYZ-UA/4.5.6
   Authorization: Digest username="bob", realm="example.com",
   nonce="04ff2106fd51729fb22d99b959787417", opaque="",
   uri="sip:registrar.example.com",
   response="e87fbce1a68320cdc81353020f50f695", algorithm=MD5
   Max-Forwards: 70
   Expires: 3600
   Content-Length: 0

   F8 Registrar ----> Bob

   Soroushnejad, et al.                                      [Page 15]


Internet-Draft         Bridged Line Appearance           June 15 2006

   SIP/2.0 200 OK
   Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKdf17f688391F7DF1
   CSeq: 2 REGISTER
   Call-ID: 55d48e6b-a0598cad-9ab32f84@ua2.example.com
   From: <sip:bob@example.com>;tag=81B52F2F-7EA64EE6
   To: <sip:alice@example.com>;tag=773736136499990
   Contact:  <sip:alice@ua2.example.com>
   Expires:  3600
   Content-Length: 0


   F9 to F12: Once Bob registers with Alice AOR, State Agent subscribes
   to the events at the contact registered for Alice and Bob notifies
   the State Agent of its status.

   F9 State Agent ----> Bob

   SUBSCRIBE sip:alice@ua2.example.com SIP/2.0
   From: <sip:alice@example.com>;tag=1326816553546535
   To: <sip:bob@example.com>
   Call-ID: 285-1728540768@example.com
   CSeq: 2 SUBSCRIBE
   Via: SIP/2.0/UDP
   stateagent.example.com;branch=z9hG4bK1444292281547026
   Event: dialog;sla
   Expires: 3700
   Contact: <sip:sa@stateagent.example.com>
   Content-Length: 0

   F10 Bob ----> State Agent

   SIP/2.0 200 OK
   Via: SIP/2.0/UDP
   stateagent.example.com;branch=z9hG4bK1444292281547026
   From: <sip:alice@example.com>;tag=1326816553546535
   To: <sip:bob@example.com>;tag=9A4180F3-B934AE6A
   CSeq: 2 SUBSCRIBE
   Call-ID: 285-1728540768@example.com
   Contact: <sip:alice@ua2.example.com>
   Event: dialog;sla
   User-Agent: XYZ-UA/4.5.6
   Expires: 3700
   Content-Length: 0

   F11 Bob ----> State Agent

   NOTIFY sip:sa@stateagent.example.com SIP/2.0
   Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa07137bdB2E512F6
   From: <sip:bob@example.com>;tag=9A4180F3-B934AE6A
   To: <sip:alice@example.com>;tag=1326816553546535
   CSeq: 1 NOTIFY
   Call-ID: 285-1728540768@example.com
   Contact: <sip:alice@ua2.example.com>
   Event: dialog;sla
   User-Agent: XYZ-UA/4.5.6
   Soroushnejad, et al.                                      [Page 16]


Internet-Draft         Bridged Line Appearance           June 15 2006

   Subscription-State: active;expires=3698
   Max-Forwards: 70
   Content-Type: application/dialog-info+xml
   Content-Length: 164

   <?xml version="1.0"?>
   <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
                version="0"
                state="full"
                entity="sip:alice@example.com">
   </dialog-info>

   F12 Sate Agent ----> Bob

   SIP/2.0 200 OK
   Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa07137bdB2E512F6
   CSeq: 1 NOTIFY
   Call-ID: 285-1728540768@example.com
   From: <sip:bob@example.com>;tag=9A4180F3-B934AE6A
   To: <sip:alice@example.com>;tag=1326816553546535
   Allow: NOTIFY,SUBSCRIBE
   Allow-Events: dialog;sla
   Contact: <sip:sa@stateagent.example.com>
   Content-Length: 0


   F13 to F16: Bob also subscribes to the events associated with the
   Alice AOR with State Agent. State Agent also notifies Bob of the
   status.


   F13 Bob ----> State Agent

   SUBSCRIBE sip:sa@stateagent.example.com SIP/2.0
   Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa1371c3f65A21C98
   From: <sip:bob@example.com>;tag=410F7345-F7EBA89C
   To: <sip:alice@stateagent.example.com>
   CSeq: 1 SUBSCRIBE
   Call-ID: 42fed01-850cb203-de12767a@ua2.example.com
   Contact: <sip:alice@ua2.example.com>
   Event: dialog;sla
   User-Agent: XYZ-UA/4.5.6
   Accept: application/dialog-info+xml
   Max-Forwards: 70
   Expires: 3700
   Content-Length: 0

   F14 State Agent ----> Bob

   SIP/2.0 202 Accepted
   Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa1371c3f65A21C98
   CSeq: 1 SUBSCRIBE
   Call-ID: 42fed01-850cb203-de12767a@ua2.example.com
   From: <sip:bob@example.com>;tag=410F7345-F7EBA89C
   To: <sip:alice@stateagent.example.com>;tag=521018280364802
   Soroushnejad, et al.                                      [Page 17]


Internet-Draft         Bridged Line Appearance           June 15 2006

   Allow: NOTIFY,SUBSCRIBE
   Allow-Events: dialog;sla
   Expires: 3700
   Contact: <sip:sa@stateagent.example.com>
   Content-Length: 0

   F15 State Agent ----> Bob

   NOTIFY sip:alice@ua2.example.com SIP/2.0
   From: <sip:alice@stateagent.example.com>;tag=521018280364802
   To: "bob" <sip:bob@example.com>;tag=410F7345-F7EBA89C
   Call-ID: 42fed01-850cb203-de12767a@ua2.example.com
   CSeq: 2 NOTIFY
   Via: SIP/2.0/UDP
   stateagent.example.com;branch=z9hG4bK516254789368301
   Max-Forwards: 70
   Content-Type: application/dialog-info+xml
   Event: dialog;sla
   Subscription-State: active
   Contact: <sip:sa@stateagent.example.com>
   Content-Length: 162

   <?xml version="1.0"?>
   <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
                version="50"
                state="full"
                entity="sip:alice@example.com">
   </dialog-info>

   F16 Bob ----> State Agent

   SIP/2.0 200 OK
   Via: SIP/2.0/UDP
   stateagent.example.com;branch=z9hG4bK516254789368301
   From: <sip:alice@stateagent.example.com>;tag=521018280364802
   To: <sip:bob@example.com>;tag=410F7345-F7EBA89C
   CSeq: 2 NOTIFY
   Call-ID: 42fed01-850cb203-de12767a@ua2.example.com
   Contact: <sip:alice@ua2.example.com>
   Event: dialog;sla
   User-Agent: XYZ-UA/4.5.6
   Content-Length: 0


6.2 Call Originated by a UA in a BLA group

   In this scenario, the UA just before allowing the user to place a
   call, shall send out a dialog event NOTIFY with state (trying). The
   User Agent MUST wait for a 200 OK response from the State Agent,
   before it proceeds with sending out the INVITE to the address
   entered by the end user.
   In case a UA receives a 500 final response for the NOTIFY, it MUST
   inspect the Retry-After interval. If one is present, the UA must
   wait for this interval before it retries sending the NOTIFY. Further
   it should continue to delay sending out the INVITE. Should the UA
   Soroushnejad, et al.                                      [Page 18]


Internet-Draft         Bridged Line Appearance           June 15 2006

   receive a NOTIFY of (trying) from the State Agent before the expiry
   of this interval, it MUST honor the same by providing appropriate
   end user indication; cancel any timers it has started for retrying
   the NOTIFY request; and abandon reinitiating of the NOTIFY request.
   The UA MUST then abandon sending out INVITE to the address in such a
   scenario. It should be noted that this 500 response does not amount
   to a NOTIFY failure. Specifically, this response MUST not result in
   the UA terminating Subscriptions of the State Agent.
   This is needed to disallow use of the BLA line appearance once one
   of the users has chosen the same.
   Sending NOTIFY dialog state of (trying) before an INVITE is a
   departure from [7], but this MUST be implemented to resolve glare
   issues.
   Further, the dialog state definition [7] has no restrictions on the
   number of dialogs that MAY be conveyed in a single SIP NOTIFY
   message. However, since the NOTIFY for going off-hook can be
   rejected by the State Agent, such a NOTIFY MUST be presented to the
   State Agent as a single dialog payload in the NOTIFY.

   In the following call flow, Bob, as a member of the Alice BLA group,
   places an outgoing call to Carol using Alice line appearance. Bob
   then places Carol on hold. Alice subsequently picks up the held call
   and has a established session with Carol. Finally, Carol hangs up.
   The details of the notifications amongst the user agents and the
   state agent in updating the status of the BLA group members are
   shown below. For brevity, details of some of the messages are not
   included in the message flows.


   Carol        Proxy           Alice        State Agent           Bob
   |              |               |              |                  |
   |              |               |              |<------ NOTIFY F1<|
   |              |               |              |                  |
   |              |               |              |>F2 200 OK ------>|
   |              |               |              |                  |
   |              |               |<-- NOTIFY F3<|                  |
   |              |               |              |                  |
   |              |               |>F4 200 OK -->|                  |
   |              |               |              |                  |
   |              |<------------------------------------- INVITE F5<|
   |              |               |              |                  |
   |<-- INVITE F6<|               |              |                  |
   |              |               |              |                  |
   |>F7 180 Ring >|               |              |                  |
   |              |>F8 180 Ringing -------------------------------->|
   |>F9 200 OK -->|               |              |                  |
   |              |>F10 200 OK ------------------------------------>|
   |              |               |              |                  |
   |<------------------------------------------------------ ACK F11<|
   |              |               |              |                  |
   |<================= Both way RTP established ===================>|
   |              |               |              |                  |
   |              |               |              |<----- NOTIFY F12<|
   |              |               |              |                  |
   |              |               |              |>F13 200 OK ----->|
   Soroushnejad, et al.                                      [Page 19]


Internet-Draft         Bridged Line Appearance           June 15 2006

   |              |               |<- NOTIFY F14<|                  |
   |              |               |              |                  |
   |              |               |>F15 200 OK ->|                  |
   |              |               |              |                  |
   |              |<------------------------------(hold) INVITE F16<|
   |<- INVITE F17<|               |              |                  |
   |              |               |              |                  |
   |>F18 200 OK ->|               |              |                  |
   |              |>F19 200 OK ------------------------------------>|
   |              |               |              |                  |
   |<------------------------------------------------------ ACK F20<|
   |              |               |              |                  |
   |              |               |              |<----- NOTIFY F21<|
   |              |               |              |                  |
   |              |               |              |>F22 200 OK ----->|
   |              |               |<- NOTIFY F23<|                  |
   |              |               |              |                  |
   |              |               |>F24 200 OK ->|                  |
   |              |<-- INVITE F25<|              |                  |
   |<- INVITE F26<|(w/ Replaces)  |              |                  |
   |( w/ Replaces)|               |              |                  |
   |>F27 200 OK ->|               |              |                  |
   |              |>F28 200 OK -->|              |                  |
   |              |               |              |                  |
   |<-------------------- ACK F29<|              |                  |
   |              |               |              |                  |
   |<= Both way RTP established =>|              |                  |
   |              |               |              |                  |
   |>F30 BYE ---->|               |              |                  |
   |              |>F31 BYE --------------------------------------->|
   |              |               |              |                  |
   |              |<------------------------------------ OK 200 F32<|
   |<- 200 OK F33<|               |              |                  |
   |              |               |              |                  |
   |              |               |              |<----- NOTIFY F34<|
   |              |               |              |                  |
   |              |               |              |>F35 200 OK ----->|
   |              |               |<- NOTIFY F36<|                  |
   |              |               |              |                  |
   |              |               |>F37 200 OK ->|                  |
   |              |               |              |                  |
   |              |               |>F38 NOTIFY ->|                  |
   |              |               |              |                  |
   |              |               |<- 200 OK F39<|                  |
   |              |               |              |>F40 NOTIFY ----->|
   |              |               |              |                  |
   |              |               |              |<----- 200 OK F41<|
   |>F42 BYE ---->|               |              |                  |
   |              |>F43 BYE ----->|              |                  |
   |              |               |              |                  |
   |              |<-- 200 OK F44<|              |                  |
   |<--200 OK F45<|               |              |                  |
   |              |               |>F46 NOTIFY ->|                  |
   |              |               |              |                  |
   |              |               |<- 200 OK F47<|                  |
   Soroushnejad, et al.                                      [Page 20]


Internet-Draft         Bridged Line Appearance           June 15 2006

   |              |               |              |>F48 NOTIFY ----->|
   |              |               |              |                  |
   |              |               |              |<----- OK 200 F49<|



   F1 to F4: Bob uses the BLA appearance of Alice on his UA to place an
   outgoing call (e.g., he goes off-hook). Before sending the outgoing
   INVITE request, Bob notifies the sate agent that Alice line
   appearance is in (trying) state. State Agent notifies Alice of the
   same event by forwarding the NOTIFY payload provided by Bob after
   appropriately changing the dialog id field in the XML payload to a
   unique value towards each of the entities it is forwarding to (Alice
   in this example).


   F1 Bob ----> State Agent

   NOTIFY sip:sa@stateagent.example.com SIP/2.0
   Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK61314d6446383E79
   From: <sip:bob@example.com>;tag=44150CC6-A7B7919D
   To: <sip:alice@example.com>;tag=428765950880801
   CSeq: 7 NOTIFY
   Call-ID: 144-1289338424@example.com
   Contact: <sip:alice@ua2.example.com>
   Event: dialog;sla
   User-Agent: XYZ-UA/4.5.6
   Subscription-State: active;expires=3347
   Max-Forwards: 70
   Content-Type: application/dialog-info+xml
   Content-Length: 365

   <?xml version="1.0"?>
   <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
                version="6"
                state="partial"
                entity="sip:alice@example.com">
       <dialog id="id3d4f9c83" direction="initiator">
           <state>trying</state>
           <local>
               <target uri="sip:bob@example.com">
                   <param pname="x-line-id" pvalue="0" />
               </target>
           </local>
       </dialog>
   </dialog-info>


   F2 State Agent ----> Bob

   SIP/2.0 200 OK
   Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK61314d6446383E79
   CSeq: 7 NOTIFY
   Call-ID: 144-1289338424@example.com
   From: <sip:bob@example.com>;tag=44150CC6-A7B7919D
   Soroushnejad, et al.                                      [Page 21]


Internet-Draft         Bridged Line Appearance           June 15 2006

   To: <sip:alice@example.com>;tag=428765950880801
   Allow-Events: dialog;sla
   Contact: <sip:sa@stateagent.example.com>
   Content-Length: 0


   F3 State Agent ----> Alice

   NOTIFY sip:alice@ua1.example.com SIP/2.0
   From: <sip:alice@example.com>;tag=497585728578386
   To: <sip:alice@example.com>;tag=633618CF-B9C2EDA4
   Call-ID: a7d559db-d6d7dcad-311c9e3a@ua1.example.com
   CSeq: 7 NOTIFY
   Via: SIP/2.0/UDP
   stateagent.example.com;branch=z9hG4bK1711759878512309
   Max-Forwards: 70
   Content-Type: application/dialog-info+xml
   Event: dialog;sla
   Subscription-State: active
   Contact: <sip:sa@stateagent.example.com>
   Content-Length: 402

   <?xml version="1.0"?>
   <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
                version="27"
                state="partial"
                entity="sip:alice@example.com">
       <dialog id="fa02538339df3ce597f9e3e3699e28fc"
               direction="initiator">
               <state>trying</state>
                <local>
                    <target uri="sip:bob@example.com">
                        <param pname="x-line-id" pvalue="0"/>
                    </target>
                </local>
        </dialog>
   </dialog-info>


   F4 Alice ----> State Agent

   SIP/2.0 200 OK
   Via: SIP/2.0/UDP
   stateagent.example.com;branch=z9hG4bK1711759878512309
   From: <sip:alice@example.com>;tag=497585728578386
   To: <sip:alice@example.com>;tag=633618CF-B9C2EDA4
   CSeq: 7 NOTIFY
   Call-ID: a7d559db-d6d7dcad-311c9e3a@ua1.example.com
   Contact: <sip:alice@ua1.example.com>
   Event: dialog;sla
   User-Agent: ABC-UA/1.2.3
   Content-Length: 0


   Soroushnejad, et al.                                      [Page 22]


Internet-Draft         Bridged Line Appearance           June 15 2006

   F5 to F11: Bob places a call to Carol by sending the INVITE request
   towards the Proxy. The INVITE (see F5 message below) includes a P-
   Preferred-Identity header [10] to designate the identity to be used
   as the calling party for this call (i.e., Alice instead of Bob).

   F5 Bob ----> Proxy

   INVITE sip:carol@example.com SIP/2.0
   Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK98c87c52123A08BF
   From: <sip:bob@example.com>;tag=15A3DE7C-9283203B
   To: <sip:carol@example.com>
   CSeq: 1 INVITE
   Call-ID: f3b3cbd0-a2c5775e-5df9f8d5@ua2.example.com
   Contact: <sip:alice@ua2.example.com>
   User-Agent: XYZ-UA/4.5.6
   P-Preferred-Identity: <sip:alice@example.com>
   Max-Forwards: 70
   Content-Type: application/sdp
   Content-Length: 223

   v=0
   o=- 1102980499 1102980499 IN IP4 ua2.example.com
   s=IP SIP UA
   c=IN IP4 ua2.example.com
   t=0 0
   a=sendrecv
   m=audio 2236 RTP/AVP 0 8 101
   a=rtpmap:0 PCMU/8000
   a=rtpmap:8 PCMA/8000
   a=rtpmap:101 telephone-event/8000



   F12 to F15: Bob notifies the state agent of the status of the dialog
   (i.e., confirmed). State agent notifies Alice of the same.

   F12 Bob ----> State Agent

   NOTIFY sip:sa@stateagent.example.com SIP/2.0
   Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa39d3f69D4E20602
   From: <sip:bob@example.com>;tag=44150CC6-A7B7919D
   To: <sip:alice@example.com>;tag=428765950880801
   CSeq: 9 NOTIFY
   Call-ID: 144-1289338424@example.com
   Contact: <sip:alice@ua2.example.com>
   Event: dialog;sla
   User-Agent: XYZ-UA/4.5.6
   Subscription-State: active;expires=3342
   Max-Forwards: 70
   Content-Type: application/dialog-info+xml
   Content-Length: 675

   <?xml version="1.0"?>
   <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
                version="8"
   Soroushnejad, et al.                                      [Page 23]


Internet-Draft         Bridged Line Appearance           June 15 2006

                state="partial"
                entity="sip:alice@example.com">
       <dialog id="id3d4f9c83"
             call-id="f3b3cbd0-a2c5775e-5df9f8d5@ua2.example.com"
             local-tag="15A3DE7C-9283203B"
             remote-tag="65a98f7c-1dd2-11b2-88c6-b03162323164+65a98f7c"
             direction="initiator">
             <state>confirmed</state>
             <local>
               <target uri="sip:bob@example.com">
                 <param pname="x-line-id" pvalue="0" />
                 <param pname=”+sip.rendering” pvalue=”yes”/>
               </target>
             </local>
             <remote>
               <identity>sip:carol@example.com</identity>
                 <target uri="sip:carol@example.com;user=phone" />
             </remote>
       </dialog>
   </dialog-info>


   F16 to F20: Bob places Carol on hold.


   F22 to F24: Bob notifies state agent of the status of the dialog to
   indicate the held state. It indicates this by setting the
   sip.rendering parameter in the NOTIFY payload to (no). State agent
   notifies Alice of the same.

   F22 Bob ----> State Agent

   NOTIFY sip:sa@stateagent.example.com SIP/2.0
   Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK6c78a6c5CA00520E
   From: <sip:bob@example.com>;tag=44150CC6-A7B7919D
   To: <sip:alice@example.com>;tag=428765950880801
   CSeq: 10 NOTIFY
   Call-ID: 144-1289338424@example.com
   Contact: <sip:alice@ua2.example.com>
   Event: dialog;sla
   User-Agent: XYZ-UA/4.5.6
   Subscription-State: active;expires=3338
   Max-Forwards: 70
   Content-Type: application/dialog-info+xml
   Content-Length: 942

   <?xml version="1.0"?>
   <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
                version="9"
                state="partial"
                entity="sip:alice@example.com">
       <dialog id="id3d4f9c83"
          call-id="f3b3cbd0-a2c5775e-5df9f8d5@ua2.example.com"
          local-tag="15A3DE7C-9283203B"
          remote-tag="65a98f7c-1dd2-11b2-88c6-b03162323164+65a98f7c"
   Soroushnejad, et al.                                      [Page 24]


Internet-Draft         Bridged Line Appearance           June 15 2006

          direction="initiator">
          <state>confirmed</state>
          <local>
            <target uri="sip:bob@example.com">
              <param pname="x-line-id" pvalue="0" />
              <param pname=”+sip.rendering” pvalue=”no”/>
            </target>
          </local>
          <remote>
            <identity>sip:carol@example.com</identity>
              <target uri="sip:carol@example.com" />
           </remote>
       </dialog>
   </dialog-info>




   F26 to F34 : Alice picks up the held call by sending an INVITE with
   Replaces: header (F26). Session is established between Alice and
   Carol. The dialog between Carol and Bob is terminated.

   F26 Alice ----> Proxy

   INVITE sip:carol@example.com SIP/2.0
   Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bK4ea695b5B376A60C
   From: <sip:alice@example.com>;tag=8C4183CB-BCEAB710
   To: <sip:carol@example.com:5075>
   CSeq: 1 INVITE
   Call-ID: 3d57cd17-47deb849-dca8b6c6@ua1.example.com
   Contact: <sip:alice@ua1.example.com>
   User-Agent: ABC-UA/1.2.3
   P-Preferred-Identity: <sip:alice@example.com>
   Replaces: f3b3cbd0-a2c5775e-5df9f8d5@ua2.example.com;to-
   tag=65a98f7c-1dd2-11b2-88c6-b03162323164+65a98f7c;from-tag=15A3DE7C-
   9283203B
   Max-Forwards: 70
   Content-Type: application/sdp
   Content-Length: 223

   v=0
   o=- 1102980497 1102980497 IN IP4 ua1.example.com
   s=IP SIP UA
   c=IN IP4 ua1.example.com
   t=0 0
   a=sendrecv
   m=audio 2238 RTP/AVP 0 8 101
   a=rtpmap:0 PCMU/8000
   a=rtpmap:8 PCMA/8000
   a=rtpmap:101 telephone-event/8000

   F34 to F41: Bob notifies the state agent of the termination of
   dialog at his UA. Alice notifies the state agent of the confirmed
   state of the dialog at her UA.

   Soroushnejad, et al.                                      [Page 25]


Internet-Draft         Bridged Line Appearance           June 15 2006

   F34 Bob ----> State Agent

   NOTIFY sip:sa@stateagent.example.com SIP/2.0
   Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bKa5d6cf61F5FBC05A
   From: <sip:bob@example.com>;tag=44150CC6-A7B7919D
   To: "State_Agent" <sip:alice@example.com>;tag=428765950880801
   CSeq: 11 NOTIFY
   Call-ID: 144-1289338424@example.com
   Contact: <sip:alice@ua2.example.com>
   Event: dialog;sla
   User-Agent: XYZ-UA/4.5.6
   Subscription-State: active;expires=3334
   Max-Forwards: 70
   Content-Type: application/dialog-info+xml
   Content-Length: 677

   <?xml version="1.0"?>
   <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
                version="10"
                state="partial"
                entity="sip:alice@example.com:5060">
      <dialog id="id3d4f9c83"
            call-id="f3b3cbd0-a2c5775e-5df9f8d5@ua2.example.com"
            local-tag="15A3DE7C-9283203B"
            remote-tag="65a98f7c-1dd2-11b2-88c6-b03162323164+65a98f7c"
            direction="initiator">
            <state>terminated</state>
            <local>
              <target uri="sip:bob@example.comsip:bob@example.com">
                <param pname="x-line-id" pvalue="0" />
              </target>
            </local>
            <remote>
              <identity>sip:carol@example.com</identity>
              <target uri="sip:carol@example.com" />
            </remote>
       </dialog>
   </dialog-info>



   F38 Alice ----> State Agent

   NOTIFY sip:sa@stateagent.example.com SIP/2.0
   Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bK93f44af3518A1572
   From: <sip:alice@example.com>;tag=5861255C-14C04045
   To: "State_Agent" <sip:alice@example.com>;tag=920163082722420
   CSeq: 10 NOTIFY
   Call-ID: 143-1840952798@example.com
   Contact: <sip:alice@ua1.example.com>
   Event: dialog;sla
   User-Agent: ABC-UA/1.2.3
   Subscription-State: active;expires=3315
   Max-Forwards: 70
   Content-Type: application/dialog-info+xml
   Soroushnejad, et al.                                      [Page 26]


Internet-Draft         Bridged Line Appearance           June 15 2006

   Content-Length: 640

   <?xml version="1.0"?>
   <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
                version="9"
                state="partial"
                entity="sip:alice@example.com:5060">
       <dialog id="id402f024e"
           call-id="3d57cd17-47deb849-dca8b6c6@ua1.example.com"
           local-tag="8C4183CB-BCEAB710"
           remote-tag="65a98f7c-1dd2-11b2-88c6-b03162323164+65a98f7c"
           direction="initiator">
           <state>confirmed</state>
           <local>
             <target uri="sip:alice@example.com">
               <param pname="x-line-id" pvalue="0" />
               <param pname=”+sip.rendering” pvalue=”yes”/>
             </target>
           </local>
           <remote>
              <identity>sip:carol@example.com</identity>
              <target uri="sip:carol@example.com" />
           </remote>
       </dialog>
   </dialog-info>


   F42 to F59: Carol terminates the dialog with Alice. Alice notifies
   state agent of the dialog state (terminated). State agent notifies
   Bob of the same.

   F46 Alice ----> State Agent

   NOTIFY sip:sa@stateagent.example.com SIP/2.0
   Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKa46c2f85F29F839C
   From: <sip:alice@example.com>;tag=5861255C-14C04045
   To: "State_Agent" <sip:alice@example.com>;tag=920163082722420
   CSeq: 11 NOTIFY
   Call-ID: 143-1840952798@example.com
   Contact: <sip:alice@ua1.example.com>
   Event: dialog;sla
   User-Agent: ABC-UA/1.2.3
   Subscription-State: active;expires=3311
   Max-Forwards: 70
   Content-Type: application/dialog-info+xml
   Content-Length: 642

   <?xml version="1.0"?>
   <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
                version="10"
                state="partial"
                entity="sip:alice@example.com">
      <dialog id="id402f024e"
         call-id="3d57cd17-47deb849-dca8b6c6@ua1.example.com"
         local-tag="8C4183CB-BCEAB710"
   Soroushnejad, et al.                                      [Page 27]


Internet-Draft         Bridged Line Appearance           June 15 2006

         remote-tag="65a98f7c-1dd2-11b2-88c6-b03162323164+65a98f7c"
         direction="initiator">
         <state>terminated</state>
         <local>
           <target uri="sip:alice@example.com">
             <param pname="x-line-id" pvalue="0" />
           </target>
         </local>
         <remote>
           <identity>sip:carol@example.com</identity>
           <target uri="sip:carol@example.com" />
         </remote>
      </dialog>
   </dialog-info>


6.3 Call Offered to a BLA Group

   In the call flow below Bob has bridged appearance of Alice. Carol
   places a call to Alice. Both Alice and Bob’s devices are alerted of
   the incoming call. Bob answers the call. He then places Carol on
   hold. Alice picks up the held call and has a established session
   with Carol. Finally, Carol terminates the session.
   All NOTIFY messages in the call flow below carry dialog events and
   only dialog states are mentioned for simplicity. For brevity, the
   details of some messages are not shown below.


   Carol     Forking Proxy  State Agent    Alice     Bob
   |            |             |             |         |
   |>F1 INVITE >|             |             |         |
   |            |>F2 INVITE ------------------------->|
   |            |             |             |         |
   |            |>F3 INVITE --------------->|         |
   |            |             |             |         |
   |<-100Try F4<|             |             |         |
   |            |             |             |         |
   |            |<-------------------- Ringing 180 F5<|
   |<180Ring F6<|             |             |         |
   |            |<---------- Ringing 180 F7<|         |
   |<180Ring F8<|             |             |         |
   |            |<------------------------- 200 OK F9<|
   |<-200OK F10<|             |             |         |
   |            |             |             |         |
   |            |>F11 CANCEL -------------->|         |
   |            |             |             |         |
   |            |<-------------- 200 OK F12<|         |
   |            |             |             |         |
   |            |<Request Cancelled 487 F13<|         |
   |            |             |             |         |
   |            |>F14 ACK ----------------->|         |
   |>F15 ACK -->|             |             |         |
   |            |>F16 ACK --------------------------->|
   |            |             |             |         |
   |<=============Both way RTP established===========>|
   Soroushnejad, et al.                                      [Page 28]


Internet-Draft         Bridged Line Appearance           June 15 2006

   |            |             |             |         |
   |            |             |<---------- NOTIFY F17<|
   |            |             |             |         |
   |            |             |>F18 200 OK ---------->|
   |            |             |             |         |
   |            |             |>F19 NOTIFY >|         |
   |            |             |             |         |
   |            |             |<- 200OK F20<|         |
   |            |             |             |         |
   |            |<----------------("Hold") INVITE F21<|
   |<INVITE F22<|             |             |         |
   |            |             |             |         |
   |>F23 200OK->|             |             |         |
   |            |>F24 200 OK ------------------------>|
   |            |             |             |         |
   |            |<--------------------------- ACK F25<|
   |<-- ACK F26<|             |             |         |
   |            |             |<---------- NOTIFY F27<|
   |            |             |             |         |
   |            |             |>F28 200 OK ---------->|
   |            |             |             |         |
   |            |             |>F29 NOTIFY >|         |
   |            |             |             |         |
   |            |             |<- 200OK F30<|         |
   |            |             |             |         |
   |            |< INVITE (w/ Replaces) F31<|         |
   |<INVITE F32<|             |             |         |
   |(w/Replaces)|             |             |         |
   |>F33 200 OK>|             |             |         |
   |            |>F34 200 OK -------------->|         |
   |            |             |             |         |
   |            |<----------------- ACK F35<|         |
   |<-- ACK F36<|             |             |         |
   |            |             |             |         |
   |<=======Both way RTP established=======>|         |
   |            |             |             |         |
   |>F37 BYE -->|             |             |         |
   |            |>F38 BYE --------------------------->|
   |            |             |             |         |
   |            |<------------------------ OK 200 F39<|
   |<-200OK F40<|             |             |         |
   |            |             |<---------- NOTIFY F41<|
   |            |             |             |         |
   |            |             |>F42 200 OK ---------->|
   |            |             |             |         |
   |            |             |>F43 NOTIFY >|         |
   |            |             |             |         |
   |            |             |<-200 OK F44<|         |
   |            |             |             |         |
   |            |             |<-NOTIFY F45<|         |
   |            |             |             |         |
   |            |             |>F46 200 OK->|         |
   |            |             |             |         |
   |            |             |>F47 NOTIFY ---------->|
   |            |             |             |         |
   Soroushnejad, et al.                                      [Page 29]


Internet-Draft         Bridged Line Appearance           June 15 2006

   |            |             |<---------- 200 OK F48<|
   |>49 BYE --->|             |             |         |
   |            |>F50 BYE ----------------->|         |
   |            |             |             |         |
   |            |<-------------- OK 200 F51<|         |
   |<-200OK F52<|             |             |         |
   |            |             |< NOTIFY F53<|         |
   |            |             |             |         |
   |            |             |>F54 200 OK >|         |
   |            |             |             |         |
   |            |             |>F55 NOTIFY ---------->|
   |            |             |             |         |
   |            |             |<---------- 200 OK F56<|
   |            |             |             |         |


   F1 to F16: An incoming call from Carol to Alice is forked to Bob and
   Alice. Both Alice and Bob indicate an incoming call (e.g., ringing)
   from Carol. Bob answers the call and two-way media is established
   between Carol and Bob.


   F17 - F20: Bob notifies the State Agent with dialog state payload
   indicating the dialog in confirmed state. State Agent notifies Alice
   of the status of the dialog at Bob.

   F17 Bob ----> State Agent

   NOTIFY sip:sa@stateagent.example.com SIP/2.0
   Via: SIP/2.0/UDP ua2.example.com;branch=z9hG4bK58a0dd68C2D63263
   From: <sip:bob@example.com>;tag=558C18F7-DB9DF7BC
   To: <sip:alice@example.com>;tag=1894685100249086
   CSeq: 14 NOTIFY
   Call-ID: 77-505889516@example.com
   Contact: <sip:alice@ua2.example.com>
   Event: dialog;sla
   User-Agent: XYZ-UA/4.5.6
   Subscription-State: active;expires=3427
   Max-Forwards: 70
   Content-Type: application/dialog-info+xml
   Content-Length: 575

   <?xml version="1.0"?>
   <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
          version="13"
          state="partial"
          entity="sip:alice@example.com">
      <dialog id="ida0f8dc17"
         call-id="14-1541707345@example.com"
         local-tag="44BAD75D-E3128D42"
         remote-tag="d3b06488-1dd1-11b2-88c5-b03162323164+d3e48f4c"
         direction="recipient">
         <state>confirmed</state>
         <local>
           <target uri="sip:alice@example.com">
   Soroushnejad, et al.                                      [Page 30]


Internet-Draft         Bridged Line Appearance           June 15 2006

             <param pname="x-line-id" pvalue="0" />
             <param pname=”+sip.rendering” pvalue=”yes”/>
           </target>
         </local>
         <remote>
           <identity>sip:carol@ua.example.com</identity>
         </remote>
      </dialog>
   </dialog-info>


   F19 State Agent ----> Alice

   NOTIFY sip:alice@ua1.example.com SIP/2.0
   From: <sip:alice@example.com>;tag=151702541050937
   To: <sip:alice@example.com>;tag=18433323-C3D237CE
   Call-ID: 1e361d2f-a9f51109-bafe31d4@ua1.example.com
   CSeq: 12 NOTIFY
   Via: SIP/2.0/UDP stateagent.example.com;branch=z9hG4bK14031499568413
   Max-Forwards: 70
   Content-Type: application/dialog-info+xml
   Event: dialog;sla
   Subscription-State: active
   Contact: <sip:sa@stateagent.example.com>
   Content-Length: 618

   <?xml version="1.0"?>
   <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
                version="13"
                state="partial"
                entity="sip:alice@example.com">
      <dialog id="2a7294823093f5274e3fd2ec54a2d76c"
         call-id="14-1541707345@example.com"
         local-tag="44BAD75D-E3128D42"
         remote-tag="d3b06488-1dd1-11b2-88c5-b03162323164+d3e48f4c"
         direction="recipient">
         <state>confirmed</state>
         <local>
           <target uri="sip:alice@example.com">
             <param pname="x-line-id" pvalue="0"/>
             <param pname=”+sip.rendering” pvalue=”yes”/>
           </target>
         </local>
         <remote>
           <identity>sip:carol@ua.example.com</identity>
         </remote>
      </dialog>
   </dialog-info>


   F21 to F26: Bob places Carol on hold.

   F27 to F30: Bob notifies the State Agent of the status of the dialog
   on hold with inclusion of the session description in the NOTIFY
   Soroushnejad, et al.                                      [Page 31]


Internet-Draft         Bridged Line Appearance           June 15 2006

   payload. Subsequently, State Agent notifies Alice of the status of
   dialog.

   F31 to F40: Alice picks up the held call by sending an INVITE with
   Replaces: header populated with the dialog data received in the
   NOTIFY from the State Agent. Carol establishes a session with Alice
   and terminates the dialog with Bob.

   F31 Alice ----> Proxy

   INVITE sip:carol@ua.example.com SIP/2.0
   Via: SIP/2.0/UDP ua1.example.com;branch=z9hG4bKcc9d727c2C29BE31
   From: <sip:alice@example.com>;tag=605AD957-1F6305C2
   To: <sip:carol@ua.example.com>
   CSeq: 2 INVITE
   Call-ID: dc95da63-60db1abd-d5a74b48@ua1.example.com
   Contact: <sip:alice@ua1.example.com>
   User-Agent: ABC-UA/1.2.3
   P-Preferred-Identity: <sip:alice@example.com>
   Replaces: 14-1541707345@example.com;to-tag=d3b06488-1dd1-11b2-88c5-
   b03162323164+d3e48f4c;from-tag=44BAD75D-E3128D42
   Max-Forwards: 70
   Content-Type: application/sdp
   Content-Length: 223

   v=0
   o=- 1103061265 1103061265 IN IP4 ua1.example.com
   s=IP SIP UA
   c=IN IP4 ua1.example.com
   t=0 0
   a=sendrecv
   m=audio 2236 RTP/AVP 0 8 101
   a=rtpmap:0 PCMU/8000
   a=rtpmap:8 PCMA/8000
   a=rtpmap:101 telephone-event/8000


   F41 to F48: Bob notifies the State Agent of the termination of the
   dialog and State Agent notifies the same to Alice. Alice notifies
   the State Agent of the confirmed state of dialog at Alice and State
   Agent informs Bob of the same.


   F49 to F52: Carol terminates dialog with Alice.

   F53 to F56: Alice notifies the State Agent of the termination of the
   dialog and State Agent notifies Bob of the same.


7. New Event Package Parameter

   The dialog state package defined in [7] defines the set of messages
   that MAY be provided by a UA to publish state information of
   dialogs. For satisfactory operation of this feature, the flows
   require that the UA SUBSCRIBE to the dialog-event package on receipt
   Soroushnejad, et al.                                      [Page 32]


Internet-Draft         Bridged Line Appearance           June 15 2006

   of a SUBSRIBE request. It MUST use the contact in this SUBSCRIBE for
   making 'line reservations' when placing calls from the AOR. Also, as
   seen in the above example message flows, not all of these messages
   need to be published by a UA to effectively participate in a BLA
   group. In order to indicate this preference, this draft proposes a
   new Event parameter for the dialog package called (sla). User Agents
   that understand this parameter will only provide dialog state
   information as detailed in this draft.

8. State and Error Recovery

   A critical aspect for reliable operation of this feature is the
   ability for all user agents in the BLA group to recover from network
   failures caused at a single UA. For example, one of the user agents
   in the BLA group may have answered an incoming call, notified the
   dialog state to other members and then experiences a network outage.
   The calling UA could have detected the same (using RTP or some other
   means) and could have hung up. However, none of the other user
   agents in the BLA group gets notification of this change in dialog
   state and their BLA appearances could stay out of sync for a long
   time; depending on when the network is restored, or when the State
   Agent attempts to refresh its dialog-state subscription with this
   UA. To recover from such a failure, the State Agent MUST SUBSCRIBE
   with a shorter expiration (expiration interval not smaller than 300
   seconds is RECOMMENDED) following the notification of a “confirmed”
   dialog or when a Event Agent honors a “trying” for call origination,
   with the user agents that notified it of this information.

   Alternatively, while a user agent is acquiring, or holds a line
   seize, the dialog subscriptions to it act as BLA status indicators
   to the subscriber. If subscription refresh requests to the user
   agent are not honored, then it must be determined that the user
   agent’s capacity to maintain line seize has been lost. For this
   reason, during the period a user agent is acquiring or holds a line
   seize, the remaining expiry period of subscriptions to it MAY be
   reduced by the user agent to minimize the outage problem (expiration
   interval not smaller than 300 seconds is RECOMMENDED). This can be
   accomplished by setting the Expires parameter in the Subscription-
   State header in the NOTIFY message sent out by the UA.

8.1 Line Seize (Refresh Subscription)

   UA - Called       State Agent          UA - Calling
   |                    |                    |
   |                    | F1: NOTIFY (trying)|
   |                    |<-------------------|
   |                    |  F2: 200 OK        |
   |                    |------------------->|
   | F3: INVITE/180 Ring/200 OK/ACK          |
   |<-------------------+--------------------|
   |                    | F4: SUBSCRIBE      |
   |                    |------------------->|
   |                    | F5: 200 OK         |
   |                    |<-------------------|
   |                    | F6: NOTIFY(confirm)|
   Soroushnejad, et al.                                      [Page 33]


Internet-Draft         Bridged Line Appearance           June 15 2006

   |                    |<-------------------|
   |                    | F7: 200 OK         |
   |                    |------------------->|
   |                    |                    |

   This figure shows UA seizing a bridged line (F1 and F2) from the
   state agent. State agent refreshes its subscription to UA (F4-F7)
   ensuring continuity of service (whilst also verifying User agents
   shared line service). UA should maintain a policy of shortened
   expires periods so long as it holds a line seize (throughout the
   period of a call). Subscription refreshes will therefore continue to
   use a shortened expires period. Although UA will determine the
   expiration period of subscriptions to it, the state agent may choose
   to refresh subscriptions on a more regular basis as an extra means
   of ensuring continuity of shared line service.


8.2 Line Seize (Notifier Failure)

      UA           State Agent         UA1              UA2
      |                |                |                |
      |                | F1: NOTIFY (trying)             |
      |                |<---------------|                |
      |                | F2: 200 OK     |                |
      |                |--------------->|                |
      |                | F3: NOTIFY (trying)             |
      |                |----------------+--------------->|
      |                | F4: 200 OK     |                |
      |                |<---------------+----------------|
      | F5: INVITE     |                |                |
      |<--------------------------------|                |
      | F6: 180 Ringing|                |                |
      |-------------------------------->|                |
      |                |                |                |
      |                |               End               |
      |                |                                 |
      |                |                                 |
      |                | F7: SUBSCRIBE x 6 retries       |
      |                |--------------->                 |
      |                |                                 |
      |                | F8: NOTIFY (terminated)         |
      |                |-------------------------------->|
      |                | F9: 200 OK                      |
      |                |<--------------------------------|
      |                |                                 |


   The flow shown in this figure illustrates the failure of a user
   agent after it has obtained a line seize (F1-F2). Messages used to
   refresh the subscription from State Agent to UA1 are shown at F7.
   The discontinuation of the bridged line service within user agent
   UA1 is shown by the abrupt termination of the UA1 vertical time
   line. When the state agent attempts to refresh its subscription and
   no response is received, indicating the shared line service
   maintained by UA1 has failed. State agent should at this point free
   Soroushnejad, et al.                                      [Page 34]


Internet-Draft         Bridged Line Appearance           June 15 2006

   the seize lock held by UA1 and issue NOTIFY messages (F8) indicating
   the termination of the dialog associated with the shared line.


8.3 Line Seize (Race Condition)

      UA           State Agent         UA1              UA2
      |                |                |                |
      |                | F1: NOTIFY (trying)             |
      |                |<---------------|                |
      |                | F2: NOTIFY (trying)             |
      |                |<---------------+----------------|
      |                | F03: 200 OK    |                |
      |                |--------------->|                |
      |                | F4: 500        |                |
      |                |----------------+--------------->|
      |                | F5 : NOTIFY (trying)            |
      |                |----------------+--------------->|
      |                | F6: 200 OK     |                |
      |                |<---------------+----------------|
      | F09: INVITE    |                |                |
      |<---------------+----------------|                |
      |                |                |                |

   This figure illustrates two user agents, UA1 and UA2, attempting to
   seize the same bridged line simultaneously. This type of race
   condition is often referred as a glare condition. State agent
   provides only one of UA1 and UA2 with the initiator’s line seize
   (UA1 in this case) and may choose any policy deemed appropriate to
   resolve the race.

9. Security Considerations

   Since many of these 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 a BLA 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.
   Soroushnejad, et al.                                      [Page 35]


Internet-Draft         Bridged Line Appearance           June 15 2006


10. References


   [1] S. Bradner, Key words for use in RFCs to indicate requirement
   levels, RFC 2119, Internet Engineering Task Force,
   Mar. 1997.
   [2] J. Rosenberg, H. Schulzrinne, et al., SIP: Session initiation
   protocol, RFC 3261, Internet Engineering Task Force, June 2002.
   [3] R. Sparks, The Session Initiation Protocol (SIP) Refer Method,
   RFC 3515, Internet Engineering Task Force, April 2003.
   [4] A.B. Roach, Session Initiation Protocol (SIP)-Specific Event
   Notification, RFC 3265, Internet Engineering Task Force, June 2002.
   [5] R. Mahy, et al., Session Initiation Protocol (SIP) Replaces
   Header, RFC 3891, Internet Engineering Task Force, September 2004.
   [6] A. Johnston, et al., Session Initiation Protocol Service
   Examples, draft-ietf-sipping-service-examples-10, (work in progress)
   March 16, 2006.
   [7] J. Rosenberg, et al, An INVITE Initiated Dialog Event Package
   for Session Initiation Protocol (SIP), RFC 4235, November 2005.
   [8] J. Rosenberg, A Session Initiation Protocol (SIP) Event Package
   for Registrations, RFC 3680, Internet Engineering Task Force, April
   2003.
   [9] J. Rosenberg, H.Schulzrinne, An Offer/Answer Model with Session
   Description Protocol, RFC 3264, Internet Engineering Task Force,
   June 2002.
   [10] C. Jennings, et al., Private Extensions to the Session
   Initiation Protocol (SIP) for Asserted Identity within Trusted
   Networks, RFC 3325, Internet Engineering Task Force, November 2002.

11. Acknowledgements
   The authors would like to thank Kent Fritz, John Weald, and Sunil
   Veluvali of Sylantro Systems, Steve Towlsen, and Michael Procter of
   Citel Technologies, Rob Harder and Hong Chen of Polycom Inc, John
   Elwell, J D Smith of Siemens Communications, Dale R. Worley of
   Pingtel, and Graeme Dollar of Yahoo Inc, for their numerous
   corrections, comments and suggestions during authoring of this
   draft.



12. Author’s Contact Information


   Mohsen Soroushnejad         Email: mohsen.soroush@sylantro.com
                               (408) 626 3028
   Sylantro Systems Corp.
   910 E Hamilton Ave,
   Campbell,CA 95008

   Venkatesh Venkataramanan    Email: venkatar@sylantro.com
                               (408) 626 3025
   Sylantro Systems Corp.
   910 E Hamilton Ave,
   Campbell,CA 95008
   Soroushnejad, et al.                                      [Page 36]


Internet-Draft         Bridged Line Appearance           June 15 2006

   Paul Pepper                 Email: paul.pepper@citel.com
   Citel Technologies
   1420 Fifth Avenue,
   22nd Floor,
   Seattle WA 98101

   Anil Kumar                  Email: anil@yahoo-inc.com
   Yahoo Inc.
   701 First Avenue
   Sunnyvale, CA 94089

13. Full Copyright Statement

   "Copyright (C) The Internet Society (2006).

   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 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
   INTERNET ENGINEERING TASK FORCE DISCLAIM 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."

14. Intellectual Property Statement

   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 http://www.ietf.org/ipr.

   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
   ietf-ipr@ietf.org.

   Soroushnejad, et al.                                      [Page 37]


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