I'm just throwing out there a real deployment scenario, not making a technical argument. Thanks for your reply. More below...
> -----Original Message----- > From: Rohan Mahy [mailto:[EMAIL PROTECTED] > Sent: Monday, March 24, 2008 6:24 PM > To: Fernando Lombardo > Cc: [email protected]; [EMAIL PROTECTED] > Subject: RE: [BLISS] MLA with Floor Control > > Hi Fernando, > > I do not find either of these arguments compelling. > > - TCP transport has been MANDATORY to implement since RFC > 3261 was published in June of 2002. If a vendor can't be > bothered to implement a mandatory feature of the core > protocol, I don't see why they would bother to follow the > recommendations of the BLISS WG. Easy to understand. Feature support like this one is what makes the sale, not which transport they use. > > - The phone will need to implement some new at the > application protocol layer. Whether this is a new SIP > extension or a simple orthogonal protocol should not be a > significant difference in terms of time to implement. > Certainly one of us could have implemented BFCP for this > purpose in the amount of time we have spent discussing this issue. Yes, something new within the SIP realm and not some binary protocol they never heard of. > > - While I would be surprised to find a business that has UDP > port 5060 open that would not allow outgoing TCP, you could > certainly configure BFCP to use port 443. Sure, this works if the enterprise is not doing packet inspection. > > thanks, > -rohan > > > Jumping in... > > Consider the following environment: An enterprise with a hosted PBX > > service that doesn't allow anything out of their network > but ports 80, > > 443 and 5060 (UDP). Everything else is disallowed. They are > heavy SCA > > users. Their endpoints only do UDP, no TCP (because they purchased > > them a while back and UDP was the norm). Furthermore, the endpoint > > already supports NOTIFY/PUBLISH/events. > > How can MLA using BFCP (for this particular REQ) work in this > > environment? > > > > -fernando > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf > > Of Rohan Mahy > > Sent: Friday, March 21, 2008 8:47 PM > > To: Venkatesh > > Cc: [EMAIL PROTECTED]; [email protected] > > Subject: Re: [BLISS] MLA with Floor Control > > > > Hi Venkatesh, > > > > Phone1, Phone2, and Phone3 all share a line using your > proposed scheme. > > Phone1 and Phone2 both try to seize at about the same time, > but Phone1 > > is slightly faster. > > > > Lets see what happens in two cases. First with a state agent: > > > > The NOTIFY from Phone1 is "accepted". > > > > The NOTIFY from Phone 2 is rejected, and according to RFC 3265, the > > dialog terminates. Oops. > > > > Now lets try this with a mesh of dialogs among the three > phones. This > > is even worse as you have no idea whether Phone3 will accept the > > dialog update from Phone1 or from Phone2. > > > > State agents aren't supposed to change the semantics of the event > > package and I think this demonstrates that the proposed > package does. > > > > thanks, > > -rohan > > > > > >> Francois: > >> > >> I am not sure about additional complexity with using SIP as the > >> mechanism and resulting in PUBLISH/NOTIFY flying all over > the place. > >> All the draft was proposing is that the UA send a NOTIFY > indicating > >> that it is going to place a call using a specific line *before* > >> sending out the actual INVITE. This NOTIFY would have > gotten sent by > >> the UA anyway post dialing. The draft is just moving the > position of > >> when the NOTIFY gets sent out. From an end user > perspective, when a > >> user dials a number, he/she would simply see that it is > 'attempting' > >> to use a specific line appearance when the call is placed. > If there > >> is > > > >> no contention for that specific line, call proceeds fine. If the > >> NOTIFY is rejected, the line goes busy and user is provided a fast > > busy. > >> > >> Thanks > >> Venkatesh > >> > >> On Fri, Mar 21, 2008 at 12:15 PM, Francois Audet <[EMAIL PROTECTED]> > > wrote: > >> > >>> 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 > > > > _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
