Subject: Re: [Sipping] Comments on BLA draft

From: Venkatesh <[email-masked]>
Date: Tue, 26 Jul 2005 06:34:56 -0700

Dale:

Thank you very much for all your comments. We shall address all of the 
formatting issues in our next revision.
Replies inline...

 On 7/25/05, Dale Worley <[email-masked]> wrote: 
> 
> Comments on "Implementing Bridged Line Appearances",
> draft-anil-sipping-bla-02.txt.
> 
> I'm having some difficulty determining whether the draft is
> overlooking some details, or whether these have been discussed
> thoroughly in some other forum. In any case, it would probably help
> if the I-D was more explicit about some of the mechanisms it uses.
> 
> Overall presentation
> 
> 1. There are important elements of the proposal that are "defined by
> example" in section 6 alone, with no description in section 5. This
> seems to be a significant deficiency, as it makes it difficult to
> envision all of the complications that might arise. (I would be
> willing to write some additions to section 5 if that would be useful.)

 [VV]: Will take you up on the offer :-). 

2. Throughout the examples, there is a habit of using a name
> (particularly "Alice") to designate a Directory Address (AOR) with
> BLA, a user agent with an appearance of the BLA, and the person who is
> the primary operator of that UA. While conflating the last two
> meanings is not much of a problem, conflating them with the first
> meaning makes the discussion more difficult to follow. (E.g., it is
> hard to say that "the INVITE to [DA] Alice is forwarded to [UA]
> Alice.") It would help if the DAs and the names of UAs/users were
> drawn from different namespaces.

 [VV]: Agreed.

3. It seems to be the intention that in dialog event packages, the
> <target> element of the <local> element conveys the value of the
> Contact: header as sent by the UA (usually with an absolute IP address
> as the host part of the URI), and the <identity> element of the
> <local> element is intended to convey the AOR being used to establish
> the dialog (the To: or From: header, as appropriate). But the
> examples generally do not provide a contact as the local-identity
> element, but instead use an AOR in a local-target element,
> contributing to the confusion I've described in (2). (If a real UA
> does this, it makes it difficult to use the local-target element as a
> URI to contact the UA for call-control operations.)

 [VV]: Agreed. Will make the change.

4. Section 4.1 mentions a number of common ways to use BLA. I think
> it would help the reader to also say that these cases can all be
> handled uniformly by the mechanisms being discussed. Given the
> confusion (2), it would help to remind the user that none of the
> details of the cases in 4.1 are relevant to understanding the BLA
> mechanism itself.

 [VV]: The idea was to provide some use case examples of the feature.
We shall provide clarification to that effect. 

5. Section 8 makes much of reducing the expiration time for the
> subscription from the State Agent to the UA. But the expiration time
> itself isn't important, what is important is that the State Agent
> refresh the subscription frequently, which can be done without
> reducing the specified expiration time in the SUBSCRIBE messages.
> (Though reducing the expiration time might be a useful way to
> accomplish this in some implementations.)

 [VV]: Recovering from such error scenarios is quite important for 
satisfactory operation of this feature. That is one of the reasons for
mentioning the same in this draft. You are correct, the intent is for the
State Agent to attempt refreshing subscription at a lower interval. 

6. In the examples of outgoing calls, the Proxy does not perform any
> integral function, and so the call flow could be simplified by
> removing it. (Assuming that we have the Proxy perform line assignment
> for incoming calls, it cannot be removed from the incoming call
> examples.)

 [VV]: Shall remove the same for outbound calls. You are correct about 
needing
the proxy for incoming call examples.

Line IDs
> 
> 7. Section 5.1 discusses the use of the "x-line-id" parameter. We
> should probably consider calling it "line-id" now that it will be
> standardized.

 [VV]: Agreed.

8. The wording should be clarified to specify that the line-id is
> relative to the DA. Thus, a UA might use line-id's 0 and 1 for one
> DA, and also have line-id's 0 and 1 for another DA. (This being the
> only way to make it possible for a UA to share some, but not all, of
> its bridged DAs with other UAs.)

 [VV]: Shall provide clarifications to this effect.

9. We probably want to specify that line-id's for a DA are
> sequentially numbered 0, 1, 2, etc. up to whatever number of line
> appearances are supported. I expect that this is intended, but it
> should be made explicit.

 [VV]: Yes Shall clarify.

10. Section 5.1 discusses applying an x-line-id parameter to the
> Alert-Info: header, but does not discuss what agent places it there,
> or how it decides what value to use.

 [VV]: As indicated in your comment #14, for proper operation of this 
feature,
we needed the proxy to work in conjuction with the State Agent to fetch
a free line from it and use this information while offering the call to the 
group. Like you
comment in #14, this interaction between the proxy and the state agent could
use SIP or non-SIP means. We shall provide more clarification around this in 
section
5.1. 

Protocol operations
> 
> 11. Section 5 mentions the "sla" parameter of the event-name "dialog",
> but does not directly mention its primary effect: The subscription
> from the State Agent to the User Agent that has "Event: dialog;sla"
> tells the User Agent the contact point for making line reservations.

 [VV]: Section 7 provides this information.

12. Section 6.2 says "shall send out a NOTIFY with event 'trying'".
> But that is incorrect, and remarkably confusing to the reader, there
> being no such event. It should read "shall send out a dialog event
> NOTIFY with state 'trying'".

 [VV]: Will fix this.

13. Section 6.2 specifies that a successful vs. unsuccessful line
> reservation request is to be indicated by the response code to the
> NOTIFY. This seems like it might be difficult to implement, as it
> involves adding semantics to operations in the lower levels of the SIP
> stack.
> 
> Instead, it seems like a UA could request a line reservation with a
> simpler protocol that operates entirely at the application level:
> 
> A. Send a NOTIFY to the State Agent that includes a dialog in state
> "trying" for the requested line (which will be not in use in the
> latest NOTIFY received from the State Agent, otherwise the UA would
> not attempt to seize it).
> 
> B. Receive a 200 response as normal. (This ensures that the sending
> of the response to the State Agent is reliable.)
> 
> C. Wait for the State Agent to send a NOTIFY which shows the line
> id in use. The State Agent must of necessity return such a state
> change promptly, as the states reported to it for that line id
> have changed.
> 
> D. If the line id is shown in use by this UA (as evidenced by the
> local-target URI matching the Contact: URI used by this URI), the
> reservation was successful.
> 
> E. If the line is shown in use by another UA, the reservation was
> unsuccessful.

 [VV]: Guess this approach adds more delay in terms of call set up as seen
by the end user. This also adds a requirement on all UA's to inspect the 
local-target URI to decide how to use the dialog state information provided 
to
them (so ignore in cases where the dialog state information is from them but
use it in cases where they are from someone else). Finally I am not sure if 
the
local-target URI is sufficient enough for the UA to ascertain if the request 
has
been accepted (for example should the UA be behind a SBC of some sort, the
local-target URI used could be different for the INVITE).

14. Section 6.3 shows a call incoming to a BLA group. As far as I can
> see, the proposal is that the UA that accepts the call is responsible
> for reserving the line id on which to display the call. But this
> leads to race conditions. For example:
> 
> An incoming call is sent to UAs A and B.
> 
> Users at UAs A and B accept the call simultaneously, both sending 200
> responses to the proxy.
> 
> UA A attempts to reserve line id 2, the last available line id for
> this DA.
> 
> UA B attempts to reserve line id 2 also.
> 
> The proxy or caller chooses the 200 from UA B to accept, and sends
> a BYE to UA A.
> 
> The State Agent accepts UA A's line reservation and rejects UA B's
> line reservation.
> 
> UA A receives the BYE and terminates its dialog, sending a line free
> to the State Agent.
> 
> UA B, receives the State Agent's rejection of its line reservation.
> 
> Requiring the UA to accept a call before reserving a line id makes it
> impossible to reject a call with 486 if no line id is available -- the
> UA may send a 200 response and only then discover that there is no
> line id that it can reserve.
> 
> Also, forwarding an INVITE to the UAs before assigning a line id makes
> it impossible to do one of the most common user BLA functions, namely
> shouting across the office, "Alice, can you answer line 4? It's Joe's
> Towing. I'll get line 5."
> 
> As far as I can see, the only way to make this situation work well is
> for the proxy to obtain a line reservation from the State Agent, and
> apply that information to the INVITEs it forwards to the UAs. (This
> seems to be implied in the paragraph about applying an x-line-id
> parameter to the Alert-Info: header, but is not discussed anywhere.)
> 
> Interestingly, it seems that the proxy can obtain line reservations
> from the State Agent in the same way that a UA does, by attempting to
> publish a dialog event with state "trying" and seeing if the State
> Agent incorporates that dialog into the combined dialog state. This
> communication can be done through (A) some non-SIP means, or (B)
> through a provisioned relationship with the State Agent that operates
> using a pair of subscriptions like those a UA would use, or (C) by
> registering a dummy contact for the DA, thus causing the State Agent
> to initiate a pair of subscriptions. (The Proxy has to arrange to
> recognize the dummy contact and never forward INVITEs to it, or for
> the dummy contact to respond 501 to all INVITEs.)
> 
> Unlike a UA, the Proxy automatically selects the line id that it tries
> to reserve, and should be intelligent enough that if its first
> reservation attempt fails, it will attempt to seize a different line
> id.
> 
> The critical difference between a Proxy's reservation and a UA's
> reservation is that the Proxy may be dialog-stateless, and so have
> difficulty ensuring that the reservation is released. Assuming that
> the Proxy does not want to maintain dialog state so that it can
> send a NOTIFY to release its reservation when the incoming dialog
> ends, it can use a policy of always releasing its reservations within
> a few seconds -- any incoming dialog will have caused some UA to
> progress to the ringing state within a few seconds, and so the UA will
> maintain the line reservation even if the Proxy abandons it.

 [VV]: Like I mentioned in my earlier comment, yes, the idea was
to have the proxy use the State Agent to find out what line an incoming
call was to be offered to. This interface could use SIP or non-SIP means.
We left out discussions about how an implementation could perform
this interaction to suit the convenience of an implementation. For
the purposes of this draft I am inclined to provide more clarifications 
around
the usage of the line-id parameter in the INVITE and leave the interface 
between the proxy and the state-agent to the implementation. 

15. It would be helpful if the subscription structure were laid out in
> more detail:
> 
> A. The State Agent sends a subscription to the Registrar for
> registration events for the DA <sip:[email-masked]>.
> 
> B. The User Agent sends a registration to the Registrar for the DA
> <sip:[email-masked]>.
> 
> C. The State Agent sends a subscription to the contact URI registered
> in B for dialogs involving that URI.
> 
> D. The User Agent sends a subscription to the Contact: URI from
> SUBSCRIBE C for dialogs involving the DA. The User Agent knows the
> corresponding DA, because SUBSCRIBE C had as its request-URI the
> contact URI registered by the User Agent for the DA in step B.
> 
> E. For NOTIFYs sent for the subscriptions C and D, the BLA DA to
> which they apply is implied by the subscriptions they are for.
> 
> Similarly, when the UA receives an incoming call, it can discern the
> appropriate DA based on the contact URI to which the INVITE was
> directed, and the line id can be obtained from the Alert-Info: header.
> 
> >From this it is clear that as long as the UA registers distinct
> contact URIs for distinct DAs, it can have BLA appearances for
> multiple DAs, even if those DAs have the same user-names (of
> necessity, in different domains), or if those DAs are in different
> domains that are served by different State Agents.

 [VV]: Except for (A) the rest of the message flows are covered in the 
draft.
Not sure if you were intending more wordings around the message flow.

16. Do we really want the proxy, when assigning incoming calls to line
> id's, to use Alert-Info to carry the line id? If so, we need to fix
> some convention on how to represent an Alert-Info value that carries
> line id information but nothing else. This requires at least some
> work, since according to RFC 3261, any Alert-Info value must contain a
> URI.

 [VV]: On second thoughts I am inclined to provide this information as a
request-uri parameter in the INVITE rather than using the Alert-Info header.

17. There probably should be some detailed discussion of how the State
> Agent consolidates state information from the UAs, an activity which
> is more complex than it might first appear, and may require
> maintaining state information that is not manifest in the outgoing
> state event notifications.
> 
> For example, if a call rings on two UAs and both users answer it
> simultaneously (only one winning the race), both UAs send to the State
> Agent the sequence of states "early - committed - terminated". (For
> one UA, the committed phase is very short, only until the proxy or
> caller sends a BYE to the "extra dialog".) But when the first dialog
> transitions to "terminated", the State Agent must remember that the
> second dialog is still committed, and make sure that its consolidated
> dialog state still shows the line id as being "committed" (though
> perhaps with a different dialog than before), with no period of being
> "terminated" in between.

 [VV]: I understand the State-Agent having to do some level of dialog
consolidation but am not sure that it needs to do a whole lot for 
satisfactory operation of this feature. In the example you have outlined
above, all dialog state advertised by UA1 and UA2 would be sent out
by the State-Agent transparently to other members in the group (as they
would have different dialog "ids"). As long as the receiving UA's and the 
State-Agent keep track of the dialog states of the various "ids" they would
render the correct information?

Indeed, any states presented by different UAs for the same line id are
> compatible, except that creating a dialog with "trying" state
> (attempted line seizure) is incompatible with the existence of a
> dialog in any state other than "terminated".
> 
> Wording
> 
> 18. In section 5, item 1, the wording could be improved: "for users
> belonging to a BLA group" would better be "for contacts registered for
> the BLA DA", and "all users registered to a BLA group" would better be
> "all UAs registered for the BLA DA".

 [VV]: Will fix this.

19. In section 5, item 5, it should read "for the state of all dialogs
> involving the BLA contact URI", as there is no mechanism to subscribe
> for the state of all dialogs at a UA (as far as I know).

 [VV]: Will fix this.

Formatting matters

 [VV] Sorry about this. We will address all of the below....

20. There are a considerable number of non-ASCII characters in the I-D.
> Since this is by no means the first I-D I've seen that has this
> problem, I wonder what typesetting program people are using that
> produces non-ASCII characters.
> 
> 21. The examples give many dialog event packages, which are in XML.
> These would be more readable if they were indented according to the
> logical structure of the XML.
> 
> 22. There are a number of sections where blank lines do not appear
> between paragraphs or items in a list, whereas inserting such blank
> lines seems to be the standard format.
> 
> 23. In a number of example messages, the typesetting program has broken
> lines in a way that is not compatible with RFC 3261.
> 
> 24. In section 6.1.1, message F5, the From: header seems to have an
> unlikely value. Wouldn't it be more likely to be "From:
> <sip:[email-masked]>"?

 [VV]: It should be <sip:[email-masked]>.

Dale
> 
> 
> _______________________________________________
> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP
>
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Mon, 1 Aug 2005 23:50:50 +0200

Venkatesh,

In response to Dale's suggestions (below): What about looking at this from a slightly different perspective: each outgoing lines is represented by a shared virtual button at the state agent. Each UAC has a button with state (requested / not requested) for each line. When the user wants to place an outgoing call, the UAC PUBLISHes (instead of NOTIFY) the 'requested' state of the pressed button. When it receives a NOTIFY stating that it has succesfully grabbed the line, it sends out the INVITE.

So instead of defining it in terms of dialog state, define it as shared button state (like it is)

An alternative could be to use the state agent as proxy for outgoing calls. The user can then request a line using some convention (e.g. a URI parameter, P-Preferred-Identity, other), and the proxy can honor it (and forward the request) or disallow it (and return 503 Service(line) Not available, I think that's better than 500 Internal Server Error). Seems simpler than the reservation approach

Another question I have: what about contact hiding? I can imagine an enterprise would want to avoid sending out the Contact address of individual UACs, as people could use this to bypass the shared line appearance thus defeating its purpose. Also for this case I could imagine using the state agent as a (record-routing) proxy with some identity hiding capabilities?

Regards,

Jeroen

  [VV]: Guess this approach adds more delay in terms of call set up as seen
  by the end user. This also adds a requirement on all UA's to inspect the 
  local-target URI to decide how to use the dialog state information provided to
  them (so ignore in cases where the dialog state information is from them but
  use it in cases where they are from someone else). Finally I am not sure if the
  local-target URI is sufficient enough for the UA to ascertain if the request has
  been accepted (for example should the UA be behind a SBC of some sort, the
  local-target URI used could be different for the INVITE).

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Tue, 2 Aug 2005 07:31:38 +0200

On second thought: isn't it kind of silly to impose an artificial limit on simultaneous outgoing calls using the same line ID? In current systems there is a finite number of outgoing lines, but in SIP there is no such thing. Am I missing something here? What would go wrong if multiple UACs would use the same line ID simultaneously for making an outgoing call?

Also, would a 'helpdesk' perhaps be a good example for a use case?

Regards,

jeroen
  ----- Original Message ----- 
  From: Jeroen van Bemmel 
  To: Venkatesh ; Dale Worley 
  Cc: Sipping (E-mail) 
  Sent: Monday, August 01, 2005 11:50 PM
  Subject: Re: [Sipping] Comments on BLA draft

  Venkatesh,

  Regards,

  Jeroen

------------------------------------------------------------------------------

---

From: Venkatesh <[email-masked]>
Date: Tue, 2 Aug 2005 07:11:26 -0700

As the name suggests, the feature is all about 'sharing' a resource/line 
across multiple users. The draft does not impose any limit on the number of 
simultaneous outgoing calls a UA can place. It only proposes to associate 
each of these calls with a unique line id. There is a section in the draft 
that talks about multiple UAC's trying to use the same line ID 
simultaneously and how the same could be resolved. Dale's suggestion is an 
alternate approach to solve the same. 
 Regarding your other suggestion of using PUBLISH, I am not sure this is any 
better or has any advantages than what is currently proposed. i.e. using a 
NOTIFY and how it addresses the problem better.

Thanks
Venkatesh

 On 8/1/05, Jeroen van Bemmel <[email-masked]> wrote: 
> 
> On second thought: isn't it kind of silly to impose an artificial limit on 
> simultaneous outgoing calls using the same line ID? In current systems there 
> is a finite number of outgoing lines, but in SIP there is no such thing. Am 
> I missing something here? What would go wrong if multiple UACs would use the 
> same line ID simultaneously for making an outgoing call?
> *From:* Jeroen van Bemmel <[email-masked]> 
> *To:* Venkatesh <[email-masked]> ; Dale Worley <[email-masked]> 
> *Cc:* Sipping (E-mail) <[email-masked]> 
> *Sent:* Monday, August 01, 2005 11:50 PM
> *Subject:* Re: [Sipping] Comments on BLA draft
> 
>  Venkatesh,
>  In response to Dale's suggestions (below): What about looking at this 
> from a slightly different perspective: each outgoing lines is represented by 
> a shared virtual button at the state agent. Each UAC has a button with state 
> (requested / not requested) for each line. When the user wants to place an 
> outgoing call, the UAC PUBLISHes (instead of NOTIFY) the 'requested' state 
> of the pressed button. When it receives a NOTIFY stating that it has 
> succesfully grabbed the line, it sends out the INVITE.
>  An alternative could be to use the state agent as proxy for outgoing 
> calls. The user can then request a line using some convention (e.g. a URI 
> parameter, P-Preferred-Identity, other), and the proxy can honor it (and 
> forward the request) or disallow it (and return 503 Service(line) Not 
> available, I think that's better than 500 Internal Server Error). Seems 
> simpler than the reservation approach
>  Another question I have: what about contact hiding? I can imagine an 
> enterprise would want to avoid sending out the Contact address of individual 
> UACs, as people could use this to bypass the shared line appearance thus 
> defeating its purpose. Also for this case I could imagine using the state 
> agent as a (record-routing) proxy with some identity hiding capabilities?
>  Regards,
>  Jeroen
>  
> 
>  ------------------------------
>

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Tue, 2 Aug 2005 21:19:09 +0200

Venkatesh,

I understand that the draft is about sharing a single resource. However, as I read the draft this resource is virtual / logical, it does not (necessarily) represent a single physical resource. So the restriction to associate each of the calls with a unique line id is artificial, not mandated by anything besides the requirement in the draft. I can understand where the idea comes from, you are emulating a telephone system with a fixed (limited) number of physical lines. But why emulate the restrictions of such a system if there is no need for it?

Imagine a helpdesk (assuming for the moment this is an appropriate use case, if not please correct me). Customers can reach this helpdesk by calling [email-masked]'; internally the call is routed to an available attendant (of which there are several, we're talking a busy helpdesk here). Basically some light starts blinking on all registered UACs who are not busy in a call, and the first attendant to press the button 'wins' and gets the call.

The above scenario is for incoming calls, and I can see how your draft solves that.

Now consider a helpdesk attendant who has to initiate a call to a customer, to follow up on some issue. He wants to do this assuming the identity of the helpdesk (customers need not be bothered with the internal organization of the helpdesk) so he uses [email-masked]' as a From address. Then, following your draft, he should request usage of this shared line appearance using NOTIFY, and wait for permission. So the attendant may have to wait to make his call, because of an artificial restriction. This seems strange to me, especially in a business environment where time is money.

I guess what I am saying is that I see the use case for incoming calls, but don't really see it for outgoing calls (at least in the above scenario). The outgoing call here could be made without asking permission, the only feature that the attendant would loose is the ability to put the call on hold for someone else to pick it up. But that could be arranged using other mechanisms as well, if it is really desired.

On the other hand, perhaps a scenario in which a secretary is preparing a call on behalf of her boss would need such synchronization (i.e. to check that the boss is not already in a call). I guess that a few examples like I am describing here would clarify this, at least for me

----

As for the use of PUBLISH: my thoughts were that the UACs, state agent and registrar are all part of a pretty 'entangled' dance. The state agent has a subscription with the registrar for each UAC, and a subscription with each UAC for its dialog states; each UAC has a subscription with the state agent for all 'dialogs' (shared lines). For N UACs, that's 3N SUBSCRIBES + 3N NOTIFIES (2N of each at the state agent, 1N at all UACs).

If instead the state agent represents M lines, one for each shared line appearance. UACs can SUBSCRIBE to each line (one subscription for each AOR they are configured to bridge), and use PUBLISH to convey the fact that they have picked up a call (instead of message F17 in section 6.3) or to request permission to initiate a call on the line (instead of message F1 in section 6.2). This architecture would have N*M SUBSCRIBES + N*M NOTIFIES ( M SUBSCRIBES at each UAC, N*M NOTIFIES at the state agent). When using event filtering this could even be reduced by letting each UAC do 1 SUBSCRIBE to register for a subset of those M lines, reducing it to N SUBSCRIBES and N NOTIFIES (each with an associated filter expression, internally the state agent would probably construct a watcher set for each line with each entry pointing to the corresponding NOTIFY state).

The call flows would be pretty much the same, replacing 'NOTIFY' with 'PUBLISH' when sent from a UAC. You wouldn't be using the dialog state event package, but a custom state definition matching the concept of a virtual shared line.

Just my thoughts....

Best regards,

Jeroen

----- Original Message ----- 
  From: Venkatesh 
  To: Jeroen van Bemmel 
  Cc: Dale Worley ; Sipping (E-mail) 
  Sent: Tuesday, August 02, 2005 4:11 PM
  Subject: Re: [Sipping] Comments on BLA draft

  As the name suggests, the feature is all about 'sharing' a resource/line across multiple users. The draft does not impose any limit on the number of simultaneous outgoing calls a UA can place. It only proposes to associate each of these calls with a unique line id. There is a section in the draft that talks about multiple UAC's trying to use the same line ID simultaneously and how the same could be resolved. Dale's suggestion is an alternate approach to solve the same. 

  Regarding your other suggestion of using PUBLISH, I am not sure this is any better or has any advantages than what is currently proposed. i.e. using a NOTIFY and how it addresses the problem better.

  Thanks
  Venkatesh

    Regards,

    jeroen
      ----- Original Message ----- 
      From: Jeroen van Bemmel 
      To: Venkatesh ; Dale Worley 
      Cc: Sipping (E-mail) 
      Sent: Monday, August 01, 2005 11:50 PM
      Subject: Re: [Sipping] Comments on BLA draft

      Venkatesh,

      Regards,

      Jeroen

--------------------------------------------------------------------------

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 03 Aug 2005 04:14:12 -0400

Venkatesh wrote:
> across multiple users. The draft does not impose any limit on the number 
> of simultaneous outgoing calls a UA can place. It only proposes to 
> associate each of these calls with a unique line id. There is a section 
> in the draft that talks about multiple UAC's trying to use the same line 
> ID simultaneously and how the same could be resolved. Dale's suggestion 
> is an alternate approach to solve the same.

Why is it necessary to have a line id at all? As long as existing calls 
in progress can be seen from different devices the concept of a line 
seems unnecessary. Then there is no reason to seize a line. The existing 
calls can be mapped onto the UI of each device in any way that works for 
the capabilities of the device.

	Paul

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Fri, 5 Aug 2005 00:41:45 +0200

Question on "Implementing Bridged Line Appearances", 
draft-anil-sipping-bla-02.txt.

>From earlier discussions it seems that the intention is to emulate the way a 
current PBX system works. In such a system, is the caller aware of the 
number of phones at the BLA side?

The call flows in section 6.3 show that all Ringing responses are received 
by the caller, which makes him aware of the size of the BLA group. A caller 
could also get 2 or more dialogs, is that desirable?

Regards,

jeroen