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
