Subject: Re: [BLISS] MLA with Floor Control

From: Alan Crosswell <[email-masked]>
Date: Fri, 21 Mar 2008 18:00:07 -0400

I've been lurking here.

We rely on this funtionalty as we migrate our 20,000 legacy PBX users  
to SIP. AFAIK this is standard Dialog event package. But maybe I've  
got it wrong. Anyway we are using Polycom UAs and OpenSER's PUA to  
implement basically the expired draft-anil-sipping-bla. I hope this  
group ends up doing the right thing for real users. I'm getting a  
little concerned based on recent email going back and forth.  Presence  
state of on/off hook to me seems to be a basic requirement as is call  
pickup using re-INVITE with Replaces header. The assistant needs to  
know when his boss is off-hook "dialing" in the 10 seconds prior to  
the INVITE to avoid interrupting her.

Scalability is a concern but reality dictates that only a small  
percentage of real users use MLA and for a small number of UAs for the  
same AOR.
/a

On Mar 21, 2008, at 4:55 PM, Venkatesh <[email-masked]> wrote:

> 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-masked]>  
> 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-masked]]
> Sent: Friday, March 21, 2008 13:35
> To: Audet, Francois (SC100:3055)
> Cc: Bill Mitchell; [email-masked]
>
> 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-masked]>  
> 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-masked]]
> Sent: Friday, March 21, 2008 12:55
>
> To: Audet, Francois (SC100:3055)
> Cc: [email-masked]
>
> 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-masked]]
> Sent: Friday, March 21, 2008 12:15 PM
> To: Bill Mitchell; DOLLY, MARTIN C, ATTLABS
> Cc: [email-masked]; [email-masked]
> 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-masked]]
> Sent: Friday, March 21, 2008 11:58
> To: DOLLY, MARTIN C, ATTLABS
> Cc: [email-masked]; Audet, Francois (SC100:3055); [email-masked]
> 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-masked] [mailto:[email-masked]] 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-masked]
> Subject: Re: [BLISS] MLA with Floor Control
>
>
>
> I agree, NO
>
>
>
> From: [email-masked] [mailto:[email-masked]] On  
> Behalf Of Francois Audet
> Sent: Friday, March 21, 2008 11:45 AM
> To: Venkatesh; Paul Kyzivat
> Cc: Rohan Mahy; [email-masked]
> 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-masked]]
> Sent: Thursday, March 20, 2008 21:49
> To: Paul Kyzivat
> Cc: Audet, Francois (SC100:3055); Rohan Mahy; [email-masked]
> 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-masked]>  
> 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-masked]
> https://www.ietf.org/mailman/listinfo/bliss
>
>
>
>
> _______________________________________________
> BLISS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bliss
>
>
>
> _______________________________________________
> BLISS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bliss
_______________________________________________
BLISS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/bliss