Hi Venkatesh, As I stated before, I don't think the "burden" of implementing BFCP is especially large. It is not like I suggested you implement MSRP or an XCAP server or something like that. BFCP is a small binary protocol like STUN. A phone that wants seizure behavior just needs to send FloorRequest and FloorRelease messages and receive FloorStatus messages.
thanks, -rohan > John: > > The MLA call flow document accomplishes this by having the UA send out a > NOTIFY as against INVITE. This keeps the specifics of MLA in the State > Agent > rather than needing changes in a proxy for originating call legs. Glare > conditions were resolved by making the State Agent reject a NOTIFY with a > 4xx response. The main objection I've seen to the proposal has been that a > non 2xx response for a NOTIFY results in the UA terminating a subscription > per RFC 3265; where as we expect the subscription to continue for this > specific application. RFC 3261 allows a UA to 'reject' a mid-call request > *without* altering the state of an established session. I would like to > propose that we consider incorporating the capability in the event > notification framework as well? If not for *all* responses, providing this > capability for a specific response code (say 491) would do the job as > well.... It would also enable MLA application providers to use existing > mechanisms to provide bulk of the functionality *and* allow "archaic" > providers to satisfy "archaic" customer requirements with out adding the > burden of having to implement new protocols..... > > My 2 cents. > > Venkatesh > > On Thu, Mar 20, 2008 at 8:38 AM, Elwell, John <[EMAIL PROTECTED]> > wrote: > >> Catching up on this whole thread, it seems to me that the discussion >> revolves around two aspects: "shout-control" and "line seizure". >> >> For shout-control, I believe the proposal from Francois of using >> separate AoRs, rather than a single AoR with multiple appearances, can >> be made to work and can be mapped to current UI practices if that is >> desired. Shortened forms of the AoR can be used to make them more >> user-friendly. >> >> For line seizure, I have to ask why is the IETF worried about this? I >> just did an experiment on my desk SIP phone, and yes, I can obtain dial >> tone, but all the time I have had the phone I don't recall using that >> feature. I either select a number from my address book or pre-dial the >> digits, and then I hit "go" (the way people have been doing it on cell >> phones for the last decade or more). When I hit "go" my phone can choose >> an AoR that is free, and that then gives me the "appearance number" that >> I can shout across the room. There is, of course, a race condition, >> whereby two phones hit "go" at the same time and attempt to use the same >> AoR, or an incoming call arrives on that AoR at the same time as an >> outgoing call. If you have some agent at the proxy policing the >> one-call-per-AoR rule, it can reject an outgoing call request when the >> race condition occurs and the UA can try again on a different AoR. >> >> Defining new protocol just so that I can have this dial tone thing and >> anchor my call to an appearance before I actually dial does not seem a >> compelling feature to me. If it is really required, then what about an >> empty INVITE request that somehow gets put into some wait state until a >> complete INVITE request arrives? This would be rather like the horrible >> overlap sending work-around from the days we were doing PSTN >> interworking, but quite frankly dial tone is a PSTN thing. >> >> John >> >> > -----Original Message----- >> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >> > On Behalf Of Rohan Mahy >> > Sent: 20 March 2008 15:08 >> > To: Paul Kyzivat >> > Cc: Rohan Mahy; [email protected] >> > Subject: Re: [BLISS] MLA with Floor Control >> > >> > >> > On Mar 19, 2008, at 6:05 PM, Paul Kyzivat wrote: >> > >> > > kibitzing... >> > > >> > > Francois Audet wrote: >> > > >> > >> The reason why one wanted to "seize the line" for an >> > outgoing call >> > >> back then was >> > >> because it was a physical piece of wire. It was a physical >> > >> limitation of the >> > >> system. >> > >> Being able to have multiple people use the same line for an >> > >> outgoing call actually >> > >> seems like a feature to me, not a bug. Yet another reason why >> > >> ditching the old >> > >> key system is good. >> > > >> > > There is a tradeoff... >> > > >> > > If multiple extensions can place outgoing calls from the >> > same line, >> > > then the line doesn't have "binary" status, so it can't be >> > > indicated as active or not with a light. And you can't "conference >> > > in" by picking up on the same line. >> > > >> > > While I am not into it myself, I can see how someone can build a >> > > "business process" around the specific way in which lines are >> > > managed by the phones, and then be very upset if they can't get >> > > that same user experience. >> > >> > ...and that upset "someone" may not be the actual end user. >> > >> > > Now you can come up with some very nice UIs that provide better >> > > user experience, if you have a suitable display instead of just a >> > > bunch of lights. (E.g. an entry for the "number" (AOR that people >> > > call), and a variable length drop down list of active calls, >> > > showing the callerid of the caller, how long it has been active, >> > > and which extensions are currently connected to it.) But that is >> > > *different*, and requires a device with richer UI. >> > >> > my personal favorite UI for handling calls in the environment I >> > described in my mail to Francois is that when I receive an incoming >> > call for a specific person, I can single-step transfer the call to >> > the personal parking lot of the person who should take the call. >> > >> > thanks, >> > -rohan >> > >> > _______________________________________________ >> > BLISS mailing list >> > [email protected] >> > https://www.ietf.org/mailman/listinfo/bliss >> > >> _______________________________________________ >> BLISS mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/bliss >> > _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
