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
