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
