Hi Venkatesh, I doubt that any of these SBCs are going to handle the non-backwards compatible changes needed to RFC 3265 either.
There is no need to signal the BFCP in the SDP, just configure it. The far end is not interested in a session of audio + BFCP. BFCP is just used among phones. Phones which implement this seizure feature are exactly the ones who are likely to have all their phones on the same subnet. Therefore there is no need for ICE. There is no need for the SBCs to see what is going on with the BFCP as the floor control arbitration happens completely on a local subnet and really has nothing to do with SIP. There are many people on the BLISS mailing list who don't even think we should be spending time defining a way to implement this MLA w/ seizure feature. While I certainly don't encourage vendors to go out and implement this user experience, I understand that there is some demand in the market and that one solution to the seizure problem is better than 10. I think it is appropriate to describe a recommended way to implement this feature in BLISS. 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 On Mar 20, 2008, at 5:34 PM, Venkatesh wrote: > Rohan: > > It is not just the simplicity of the implementation on the UA. From > a solution perspective (especially hosted), we would need to work > with many network elements (SIP aware Firewalls in the enterprise > edge, SBC's and such) to understand the new SDP attributes, pass > thru' these messages across a TCP connection correctly and such. > This is where reusing existing protocols helps quite a bit. I am > sure when you get into the implementation details one will have to > worry about handling error conditions for yet another protocol and > such..... > > We have had enough grief going thru' this process even with things > like REFER and/or Replaces that I am hesitant to simply write off > this as an insignificant effort. > > Thanks > Venkatesh > > at 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
