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
