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
