Inline. On Wed, Mar 19, 2008 at 5:22 PM, Francois Audet <[EMAIL PROTECTED]> wrote:
> This is getting interesting... > > Below. > > > -----Original Message----- > > From: Rohan Mahy [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, March 19, 2008 17:08 > > To: Audet, Francois (SC100:3055) > > Cc: Rohan Mahy; Venkatesh; Mohsen Soroushnejad; [email protected] > > Subject: Re: [BLISS] MLA with Floor Control > > > > Francois, > > > > Inline. > > > > On Mar 19, 2008, at 3:21 PM, Francois Audet wrote: > > > I don't think "let's replicate a 50-year old key-system > > design" is a > > > good approach. > > > > > > These systems worked like this because back then pressing on the > > > button would actually switch the physical line. It's increadibly > > > archaic. > > > > I agree. > > Cool. > > > > > If some manufacturer wants to sell a SIP phone that looks like a > > > 1960's desk phone, good luck to them. I'm okay with that. > > > > > > But I really think that it would not be the IETF's job to create an > > > arcane protocol to mimimic a 1960's phone behavior. Especially > > > iritating features. > I also worry that we are designed a protocol from an old user interface, rather than the operations we wish to support. I'm asking usability people what they think people *actually* need to do, and I encourage others to do the same. > > > > > Well, I thought that was part of the requirements identified > > for the BLISS MLA feature. If you are flexible about the > > user interface, I think you can deliver a better user > > experience and I don't think you need any new mechanism other > > than the core dialog package. I believe this also holds for > > "feature 1" as I described it below. > > Ok, looks like we are again in agreement. > > > > I believe the behavior your are looking for, including irritating > > > arcane "features" > > > (i.e., somebody "seizing" the line before the other one) can be > > > implemented without a new protocol such as BFCP or a gazillion > > > PUBLISH/NOTIFYs. > > > > The problem is when "seizing" the line to make outbound > > calls. This requires exclusive access to "the line". Note > > that exclusive access to "the line" is also needed before > > alerting as well, in case someone tries to get a dial tone > > and dial at the same moment that a proxy forwards a call to > > the UAs. This requires some new mechanism. > > I remember seeing on the radio a chef relating a story about his roastbeef > recipe where > he would cut the four corners of a roast beef before putting it in the > oven. Somebody > asked why he was shaving off the four corners. Does it improve the flavor? > The chef couldn't > give an answer. Since the chef had learned about cooking roastbeef from > his mother, > he asked the elderly women and he discovered the reason was because his > mother's > pot was oval and a normal roast wouldn't fit in it if the corners weren't > cut. > > This is the same thing. > > 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. Oddly, in MLA you do end up using the same line for outgoing calls; you just end up using different appearances. My assertion is that you don't need to know which appearance until the call is established(hand-waving away early media/forking) and that we can design a simple mechanism around this. There are reasons for different outgoing calls having different appearances; each call should be able to be "shout-controlled" independently. > > Of course, if a manufacturer wants to sell retro-feeling equipment, then > you could > monitor the dialog package or presence of the shared AOR, and just not > allow it to make > outgoing calls if the identity is in use. > _______________________________________________ > BLISS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/bliss >
_______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
