On Mar 20, 2008, at 10:24 PM, Venkatesh wrote: > Rohan: > > I am talking about a hosted deployment model where all the phones > in an enterprise (or business phone service for an employee that > has a home office) are controlled by a application in the service > provider. I am not sure your argument about all phones being on the > same subnet is valid in this set up. I am also not sure about your > comparison of STUN with BFCP. I assume one would have to implement > RFC 4583 in order to use this with SIP
No. there is no reason you would want/need to do this at all. Each of the phones are configured to contact the BFCP server completely orthogonal of when SIP signaling is exchanged. thanks, -rohan > and this needs all intermediate network elements requiring to > implement this capability where as basic STUN is UA centric (of > course uses a STUN server somewhere in the cloud but this message > is not even seen by any intermediate SIP entity) but again has > nothing to do with core SIP. > > The whole discussion about using 'an' approach for line seizure > assumes that there is enough interest in providing such a > mechanism. If the BLISS WG so decides this is unimportant, this > whole discussion is not required. > > Finally, I am not sure that the NOTIFY based approach suffers from > the same semantic issues as those outlined for the PUBLISH based > approach. I did a superficial search on the web for the limitations > but couldn't find any. I assume there have been discussions in the > IETF meetings and would appreciate any pointers to such a discussion. > > Thanks > Venkatesh > > On Thu, Mar 20, 2008 at 9:47 PM, Rohan Mahy <[EMAIL PROTECTED]> wrote: > 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
