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
