Bill et al,
Our market research has shown that the "shout across the room for line
X" (aka: park and page) is still common in the SMB market, especially
for "non-office" (e.g. retail, warehouse) installations.
"Office-centric" businesses are more inclined to transfer calls directly
to the recipients (rather than "shout").
One possible solution to the Line Seizure contention is a full
client/server implementation, where the server "owns" the Line
Appearances. The UAs (or clients) SUBSCRIBE to the server for event
notification of the status of the lines. The server tracks the line
statuses internally and allocates them to UAs as
first-come-first-served.
The key difference is that the outbound Line Siezure case is handled by
having the UA place a SIP call to the server:
1) User presses line key 1.
2) UA places a "seizure" call (INVITE to the line identifier) to the
server.
3) If line 1 is "in use", server returns 486 Busy and terminates call.
4) If line 1 is available, server tags it as in use, and notifies the
subscribed UAs.
5) If a destination number is not included in the INVITE (line seizure
case), the server:
- accepts the call
- plays dialtone
- collects DTMF digits against a dialplan.
- uses 3pcc to connect the UA call to the service provider using
the collected digits as the dialed number.
6) If a destination number is included in the INVITE, the server
proxies the request to the service provider.
The inbound call is handled in a similar manner:
1) The server tags the line as "ringing" and notifies the subscribed
UAs.
2) User presses line key to answer the inbound call. This sends an
INVITE (with no SDP) to the server requesting the line.
3) The server receives the INVITE from the UA and uses 3pcc to connect
the inbound line call to the UA call.
4) The server tags the line as "in use" and notifies the subscribed
UAs.
The majority of the work is in developing the server. It needs to be a
UA for the line-seizure calls, and handle 3pcc negotiations as a
stateful proxy. It also needs to track the status and access lists for a
given number of lines.
This helps alleviate the issues with Req-8 (appearance contention) in
the draft, but but probably hinders Req-5 (scaling for large numbers).
Regards,
-Jay
Jay Grzenda
Principal Engineer - Allworx Corp
www.allworx.com
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Bill Mitchell
Sent: Thursday, March 20, 2008 3:12 AM
To: [email protected]
Subject: Re: [BLISS] MLA with Floor Control
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
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
