Hi Rohan: Since you seem to be really interested in BFCP and wanted to know technical limitations if any existed with BFCP for line seizure, I made time to cursorily read up on BFCP (must confess I am not yet fully familiar with it and so would appreciate if you can clarify any incorrect understanding on my part). Secondly, I am not fully aware of your proposal beyond what was mentioned in Alan's original email. It may have helped if you had summarized your thinking (for example Alan's initial email indicated using RFC 4583 which from discussions in this thread seems incorrect).
Having said that, below are a list of concerns I have with this approach. Some of them are technical and others are things that you will need to add to make the solution really deployable. You can definitely come with proposals to address these concerns but I just wanted us to be aware that it is not simply implementing FloorRequest, FloorRelease and FloorRequestStatus at the UA like you state in your emails. 1. To begin with, there is no simple way for the BFCP server to accept or reject a FloorRequest message accurately. A UA that is part of a MLA may request a line for any one of the following among other things: - Make a new call - Resume a Held Call (calls comes to a MLA group, answered by secretary, put on Hold, picked up by boss) - Join an existing conversation. The "intent" decides whether a line seizure request can be accepted or rejected and thus is important for the discussion. The floor control server should do line seizure arbitration when an attempt is being made for a new call. All other requests are more of a "notification" to the floor control server that the line is being used and should not be allocated for "new" calls should it receive a request. We can discuss a scheme where by a UA that "gets" floor control keeps track of all such transitions and releases it at the very end but that it can lead to un-usable scenarios should the UA go offline/reboots during this process. Anyway assuming we will need this capability for now, as far as I could understand, there is nothing in BFCP (apart from the PARTICIPANT_PROVIDED_INFO) where by the "intent" of why a FloorRequest is being issued can be provided. Even the type under consideration is text meant to be rendered to a "human" and not for an "automata" like we want to use. Ofcourse, like any other RFC, BFCP allows for "extension headers" and could be proposed as a means of accomplishing the same..... Even if I were to assume that we do come up with a scheme to provide this information, it is still impossible for the floor control server to accept or reject a FloorRequest message as it does not know the state of the dialog. And in scenarios like join, there may be two UA's that "own" the line for a period of time (duration of join) and reduce to one UA should one of the parties that "joined" the call drops off...... 2. Decoupling the protocol for "line seizure" from the protocol used to "advertise" status of lines can cause some interesting category of race conditions. For example, assume a UA in a MLA group issues a "FloorRequest" and obtains access to the line. Before it can issue a NOTIFY to provide any dialog state, it crashes or the PC thru' which this phone is connected reboots. None of the other UA's in the group "know" this line has been seized as they haven't received anything from the State Agent. However, any attempts by them to use the line will be rejected by the BFCP server. BFCP relies on TCP connection close to determine error conditions and under such circumstances figuring out the TCP connection is gone probably going to take longer than the time it would take for the customer to call the service provider complaining they are unable to place calls. This point brings into light into a category of issues that revolve around recovery from error conditions that this approach has to deal with that I have outlined in the next couple of items. 3. BFCP also RECOMMENDS that a Floor Control Server do not relinquish any floor control requests granted to a UA should it detect a TCP connection failure to the UA to which it granted the floor. This may cause unacceptable end user experience especially in scenarios where the UA reboots or is offline for an extended period of time where by the State-Agent cleans up a dialog state due to lack of responses for a SUBSCRIBE refresh from the UA that made/answered a call. To avoid the same, we may have to recommend implementing something contrary to the recommendation. 4. I could not find anything obvious in BFCP that allows a floor control server to reconstruct the state of the all the floors. This may be important in situations where by the box on which the floor control server is running reboots or the floor control server restarts for some reason. Inability to reconstruct this information could lead to periods of time where by the floor control server is unable to act upon incoming FloorRequest messages as the floor control server is now completely under the mercy of when all UA's in the MLA group reconnect with the floor control server (Well we can have the UA's now implement two more "simple" methods to detect liveliness of the floor control server and recover sooner from this state). We can also propose having the floor control server talk to the State Agent to fetch dialog information but this is additional work and does not amount to simply implementing 3 messages. You probably are also looking at persisting data such as transaction idenfiers in a database so that on restore, you can correlate the Transaction Identifier in a FloorRelease to the appropriate resource...... Or alternatively look at implementing some of the other BFCP semantics..... With the SIP approach, you get 'reconstruction' automatically as you SUBSCRIBE at start up (something you have to do anyways and is no overhead). It may be that there are other situations you will have to worry about when you actually sit down to implement a "deployable" solution that I have probably not hit upon as yet..... On a closing note, I would also like to state that thus far I have not seen any "technical" limitations to the NOTIFY proposal. Main objections have been around stating SIP is not for such advertsing hook states and providing granular control. I believe those concerns should have been raised when the dialog state draft proposed advertising such states and not when building an application using a behavior outlined in an RFC IMO. Others I have only heard revolve around subscriptions terminating upon receipt of a non 2xx response terminating a NOTIFY (to which I have provided pointers to relevant sections in 3265 that indicates contrary to the belief) and a third being that of invalid behavior of a State Agent. If it will help, I don't have a problem with calling the State Agent as a MLA Event Manager or something else. May be there are others that was discussed in the IETF meetings and would appreciate somebody summarizing the same for the benefits of those that did not attend. Thanks, Venkatesh On Thu, Mar 20, 2008 at 9:47 PM, Rohan Mahy <[EMAIL PROTECTED]> wrote: > Hi Venkatesh, > > I have described a way to implement this feature that uses existing > mechanisms, which is what BLISS should really be about (how to use > existing mechanism). Nobody has (yet) provided any technical > argument that my proposed method will not work. The barrier for > implementing BFCP as I described is no worse than implementing STUN, > which many, many vendors have implemented. Several people on the > mailing list have pointed out technical flaws with the intended > semantics of the PUBLISH-based approach. You have an opportunity to > just go implement something that will work. I don't get it. > > thanks, > -rohan > >
_______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
