And I have not heard anything in the mailing list so far that says why enabling 'leaving subscriptions active for a specific response code' to the presence event framework is not a workable solution? Like I said earlier, 3261 by default requires UA's to keep sessions active for non 2xx responses for "mid call requests". SUBSCRIBE establishes a dialog and NOTIFY's is a "in dialog" request under the circumstances.
Venkatesh On Thu, Mar 20, 2008 at 5:34 PM, Venkatesh <[EMAIL PROTECTED]> 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
