Again, you can do shout control without "reporting" pressing a key.
You just shout "take the line" and the guy answers the phone (or retrieve the
parked call).
It's the changing of the SIP model to introduce a pre-call seizing that bothers
me greatly.
________________________________
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ext Bill
Mitchell
Sent: Friday, March 21, 2008 12:55
To: Audet, Francois (SC100:3055)
Cc: [email protected]
Subject: Re: [BLISS] MLA with Floor Control
Completely agree that line seizure upon line-key-selection is complex,
but the idea behind line seizure over SIP was to minimize complexity. We've
heard that customers want the functionality for shout control. And issues like
line key hogging can be addressed with a proper implementation.
My terminology wasn't quite right. I should have said "Line seizure
post-line-key-selection" is not worthwhile. If the client is going to render a
UI based on the line #, for purposes of shout-control, then "Line Key Hopping"
will occur. When a user has selected a line key and is dialing, an Inbound call
will force a change in line key usage, as will an outbound call placed from a
different phone. I see this as unacceptable to most users.
________________________________
From: Francois Audet [mailto:[EMAIL PROTECTED]
Sent: Friday, March 21, 2008 12:15 PM
To: Bill Mitchell; DOLLY, MARTIN C, ATTLABS
Cc: [email protected]; [EMAIL PROTECTED]
Subject: RE: [BLISS] MLA with Floor Control
It's not POST call-setup. It's AT call setup.
It's the difference between:
Line seisure by pressing key
* User press Line appearance. This is reported to Presence/Dialog
server. PUBLISH or BFCP.
* Presence/dialog for that line goes "busy" right away, for
anybody that sees it
* Nobody can use that line regardless of how long it takes the
user to dial
Line seisure at call setup
* User press Line appearance. This is local: no reporting
anywhere.
* Nothing changes anywhere
* Line is "seized" when the call is actually made
* In the interim between pressing the key, somebody else could
also press the key and make a call. If he's faster, he'll be able to seize the
line before the first guy.
Besides the mind-numbing complexity of doing the first approach, there
are also advantages to the second approach. It avoids the problem of having
somebody "hogging" the line by pressing on the key and not dialling anybody.
And frankly, the SIP mechanism to "arbitrate" the
line-seisure-by-pressing-an-appearance will by definition be very complicated
and generate lots of traffic. I don't be believe it will be simpler than BFCP.
Furthermore, there will be lots of potential for race condidtions
(while the NOTIFYs and PUBLISH are flying all over the place). This will result
in very poor user experience. Basically, pressing on the button will often "not
work". (I have a vision of pissed-off users repeatedly pressing the key that
doesn't want to turn on, and banging on their sets).
The second option, with line seisure at call setup does not suffer from
this problem. The expectation is that the line is "taken" when you actually
make the call, not when you press the button.
I will point out that PBXs (as opposed to key systems) often work the
second way, not the first way.
This is all very similar to arbitrating between making an outgoing call
and receiving an incoming one while dialing.
________________________________
From: Bill Mitchell [mailto:[EMAIL PROTECTED]
Sent: Friday, March 21, 2008 11:58
To: DOLLY, MARTIN C, ATTLABS
Cc: [email protected]; Audet, Francois (SC100:3055); [EMAIL
PROTECTED]
Subject: RE: [BLISS] MLA with Floor Control
My answer is YES. Line seizing before call setup is
worthwhile, because it enables shout control with a **reasonable end-user
experience**.
Line seizing post-call-setup is NOT worthwhile. It only adds
confusion with potential mid or post-dial line key hopping.
Pre-call-setup line seizure can be optional.
BFCP has the right primitives, but I firmly agree with
Venkatesh that it adds significant network complexity and would be a large
barrier for implementation. I'll add my vote for a SIP-based mechanism to
communicate line seize requests and responses.
-Bill
________________________________
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
DOLLY, MARTIN C, ATTLABS
Sent: Friday, March 21, 2008 9:09 AM
To: Francois Audet; Venkatesh; Paul Kyzivat
Cc: Rohan Mahy; [email protected]
Subject: Re: [BLISS] MLA with Floor Control
I agree, NO
________________________________
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Francois Audet
Sent: Friday, March 21, 2008 11:45 AM
To: Venkatesh; Paul Kyzivat
Cc: Rohan Mahy; [email protected]
Subject: Re: [BLISS] MLA with Floor Control
The real question is "should we do line seizing before call
setup" as a worthwile feature.
I think "No".
If the group feels "Yes", then we could look at BFCP. I really
think we should not be stupid enough to make this mandatory.
________________________________
From: Venkatesh [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 20, 2008 21:49
To: Paul Kyzivat
Cc: Audet, Francois (SC100:3055); Rohan Mahy;
[email protected]
Subject: Re: [BLISS] MLA with Floor Control
I don't disagree with your argument. However, I also
think, should a particular approach unduly complicate implementation of a
feature (especially require support from multiple network elements for a
feature to work), vendors are going to resort to non standard ways to implement
the feature as well......
Venkatesh
On Thu, Mar 20, 2008 at 9:15 PM, Paul Kyzivat <[EMAIL
PROTECTED]> wrote:
I'm not promoting one way or the other. Ultimately
people building
products will build the functionality they think they
need to sell their
products. If people feel this is important then they
will want a way to
do it. If it isn't standard then it will be nonstandard.
Paul
Francois Audet wrote:
>
>
>> 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.
>
> Yeah, sure, it's doable. I do not believe that adding
the concept
> of a Line number to do this is required to do this,
or even
> desireable.
>
>> 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.
>
> Agreed.
>
> My point is that we shouldn't bastardize the protocol
with all this
> complex extra protocol (Line numbers, BFCP,
NOTIFY/PUBLISH-storms, etc.)
> just do do this.
>
> The basic "single-lamp" based approach is doable
without any of this.
>
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
