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. - 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. - 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. 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
