Again, that is fine with me.
It's the seizure control before the actual call that bothers me greatly.
________________________________
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ext
Venkatesh
Sent: Friday, March 21, 2008 13:56
To: Audet, Francois (SC100:3055)
Cc: [email protected]
Subject: Re: [BLISS] MLA with Floor Control
Section 6.2 of this RFC specifically provides for a UA to advertise
this state "prior" to sending the INVITE. I have cut and pasted the relevant
verbiage from 4235 for your perusal.
"The following example shows how a SIP telephone user agent can provide
detailed state information and also emulate a shared-line telephone system (the
phone "lies" about having a dialog while it is merely offhook).
The MLA draft pretty much uses the same.
Thanks
Venkatesh
On Fri, Mar 21, 2008 at 1:39 PM, Francois Audet <[EMAIL PROTECTED]>
wrote:
The trying state in RFC 4235 is ok (that's after the INVITE).
No ptoblems there.
It's the line seize BEFORE sending an INVITE that is a problem.
________________________________
From: Venkatesh [mailto:[EMAIL PROTECTED]
Sent: Friday, March 21, 2008 13:35
To: Audet, Francois (SC100:3055)
Cc: Bill Mitchell; [email protected]
Subject: Re: [BLISS] MLA with Floor Control
Francois:
The dialog state RFC 4325 specifically provides a
"trying" state to indicate a state where a call is about to be initiated. We
are simply using this state to indicate origination of a new call request.
Thanks
Venkatesh
On Fri, Mar 21, 2008 at 1:19 PM, Francois Audet <[EMAIL
PROTECTED]> wrote:
I really believe that this whole idea of "line
seizure" is completely out-of-line with the SIP model.
If we do something like that, we are completely
changing the nature of SIP and making it a stimulus control protocol like MGCP
(or the old proprietary Phone control protocols used by many vendors, including
my employer).
If we go in that direction, we would need to
redefine what "on the phone" means, so that instead of "in a session", it would
mean "off-hook". Every single INVITE would now be preceded by a PUBLISH of some
"off-hook" status. This would not only hamper significantly scalability of SIP,
but would make it a different protocol.
What's next? Cursor control? Bitmap screen
control?
If one wants a blast from the past with these
types of features, one should stick with protocols from the past.
I am completely opposed to changing SIP to be a
stimulus protocol.
________________________________
From: Bill Mitchell [mailto:[EMAIL
PROTECTED]
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
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
