So, I think I have the answer to my initial question. For this environment now it is required: -for endpoints to support tcp -for endpoints and core network elements to support bfcp (by some accounts easily done, but another thing to troubleshoot in the network) -for endpoints and core network elements to support tls so that port 443 can be used by the enterprise. -not to mention the SIP changes required to follow the recommendations of the BLISS WG's MLA document.
Thanks, -fernando > -----Original Message----- > From: Rohan Mahy [mailto:[EMAIL PROTECTED] > Sent: Tuesday, March 25, 2008 10:12 AM > To: Fernando Lombardo > Cc: Rohan Mahy; [email protected] > Subject: Re: [BLISS] MLA with Floor Control > > > On Mar 25, 2008, at 6:03 AM, Fernando Lombardo wrote: > > > 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. > Nearly every protocol contains features which may not be > needed in every deployment. The point is that there are > sufficient good reasons to implement all the mandatory > features of the protocol--in this case mainly > interoperability and being able to reliably send and receive > larger messages. > > >> - 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. > Whether someone has heard of it or not is not the point. If > I sit down an average developer with the BFCP spec, and a few > minutes on a whiteboard, he or she can implement this spec > very quickly. > > >> - 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. > Packet inspection does not work over TLS encrypted links. > > thanks, > -rohan > > >> 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
