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
