Rohan: Replies Interspersed....
> My recommendation which I sketched out at the mic back at the San > Diego IETF goes like this: > Before a call is answered, a new call is composed, or a call is > picked up / unheld the phone requests the floor and does not do > anything with SIP signaling until it gets a floor response or times > out. If the phone gets the floor, it proceeds with appropriate SIP > signaling. If the phone is notified that another phone has the floor > or the floor request times out, it plays some appropriate error. > When the phone puts a call on hold, hangs up, or parks a call, it > releases the floor. When a phone receives a join request, the focus > keeps the floor. If the focus transfers to another endpoint, that > endpoint needs to take the floor. [Venkatesh]: Thanks for the summary. It helps understand your proposal better. > > I do not see anything productive that any of the phones or the floor > control server would do with the "intent". [Venkatesh]: I am inclined to agree that the intent is no longer useful in light of your detailed proposal. I had no idea on when you wanted the UA to request and release lines and thus assumed that the BFCP server would have to deduce the intent. > > > > 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. > > What you have described is a good thing. It shows that the system > operates correctly under an error situation. The error conditions > under a special event package are no better. Note that the BFCP > server can also insist that floor requests are refreshed periodically. [Venkatesh]: I would be very interested in knowing the result of the conversation where a developer sat down to explain "goodness" to a irate customer reporting inability to make calls... I didn't find anything in the BFCP RFC that stated how something to the effect can be achieved. Would appreciate if you can provide me pointers to the appropriate section. > > > > 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. > > Yes. However if any agent has knowledge that a call was > disconnected, it can administratively remove the floor as a floor chair. [Venkatesh]: Like I said, the intent of some of them were to point out to the fact that a deployable solution would have to implement much more than 3 messages. My point was also to indicate that things you got "for free" with the SIP means must be revisited when you go with this approach.... You just acknowledged my point by indicating the need of a third element to monitor such states and notify the BFCP server of such scenarios. > > > > 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). > > I would rather put the effort into making a robust simple server than > worry about reconstructing state at the server. The key systems this > feature is replacing were never even close to highly reliable and > certainly had no such protections. Thousands of these systems are > deployed, so clearly they are "deployable" without this complex feature. [Venkatesh]: I disagree.... You might want to talk to your "old" PBX friends about reliability of their "old" products.... Most of them had much better reliability numbers than current IP-PBX vendors.... Regardless, ability to recover from a module crash or a system reboot is in my opinion a *very* basic requirement for any solution. It doesn't take much to end up in such a condition. A solution robustness depends upon how seamlessly it can recover from such states. Given a lack of a response I assume that you concur that one would have to resort to schemes outlined above .... Again, my point in the above was to indicate the technical complexity and additional overhead one would have to implement to this solution as against using the SIP where by I get this with no additional work. > On a closing note, I would also like to state that thus far I have > not seen any "technical" limitations to the NOTIFY proposal. How about the objection that the state agent has to operate differently whether you are operating with or without seizure? [Venkatesh]: I am not sure I understand the objection? MLA is a new feature that requires new behavior. UA's that need this behavior will request this using the "sla" tag in their subscription request. UA's that don't need this will simply subscribe to dialog-state? > > > 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) > > I'm sorry, I must have missed that. Can you please repost this pointer? [Venkatesh]: Want to draw your attention to section 3.2.2 of RFC 3265... Specifically, the following that defines what a "failed" request is: "A NOTIFY request is considered failed if the response times out, or a non 200 class response code is received which has no Retry-After header and no implied further action which can be taken to retry the request". The MLA draft proposes rejecting the request with a non 2xx response BUT with a "Retry-After" header. Technically, per the above definition of RFC 3265, the request cannot be considered failed. > > > > 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. > > There is a definition of a state agent in RFC 3265 and in the dialog > event package. Changing the name of the thing will not help. If the > goal is to reuse SIP then the bliss WG is not in a position to define > a completely new role or new behavior that is out of the scope of an > event package. BLISS simply does not have the charter to do so. You > would have to take your requirements to SIPPING and then proceed with > a new mechanism in SIP. [Venkatesh]: I am not sure the draft is "defining" a completely new role. The function being performed is that of event aggregation. Like I pointed out, it is not doing anything that violates the RFC. I am not sure 3265 (or dialog state draft for that matter) specifically calls out against rejecting a request by a State Agent. The way I see it the State Agent in the proposal is doing the following: 1. Accept incoming NOTIFY's per dialog state RFC. 2. Respond with a non 2xx response to a NOTIFY should it be required to do glare resolution. 3. Expect UA's not to "terminate" subscription on receipt of the above response as the response contains a "Retry-After" header and thus is not a "failed" request. 4. Relay NOTIFY's to other MLA appearance should a NOTIFY be accepted. What is the "new role" here? > > > thanks, > -rohan > > > > 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
