I'm also interested in whether people really use and/or need the "shout across 
the room for line X" capability.  I'll try to get some data points around any 
end-user "business practices" that depend on the key system behavior.  
Generally if a feature already exists, however archaic it may be, someone 
always seems to find creative uses.
 
 
The shout-control functionality does mandate seizure of an appearance before 
placing a call, and typically even before dialing.  Rohan mentioned an 
inbound-call-while-dialing example, but let me add the step by step details:
* User presses line key 1 on a phone and begins to dial digits. Assume phone 
doesn't seize an appearance.
* MLA AOR receives inbound call.  Server finds appearance 1 is free and 
allocates it to the call. 
* Server forks inbound call to all phones in the MLA group, with appearance 1 
indicated in the INVITE. 
* To maintain the shout-control functionality, the inbound call must map to the 
same line key on all the phones. Phones typically have a basic mapping like 
appearance 1 to line key 1.
* Now phone is overbooked on line key 1. 
>> Phone could support multiple calls per line key, or play line key hopscotch 
>> and move outbound call to a different line key. Neither option is ideal.
 
 
Regards,   -Bill
 
________________________________

From: [EMAIL PROTECTED] on behalf of Derek MacDonald
Sent: Wed 3/19/2008 6:07 PM
To: Francois Audet
Cc: Rohan Mahy; [email protected]
Subject: Re: [BLISS] MLA with Floor Control


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

Reply via email to