[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sipping] Comments on BLA draft



Dale,

Just out of interested: how big are the BLA groups we're talking about? how many lines does a typical system support, and how many buttons does the interface have?

Does it mean that if one phone in the BLA group e.g. only has 4 buttons for lines, the whole group is restricted to at most 4 simultaneous calls, both incoming and outgoing? So in other words, if I want to set up a call center with 200 lines I'd need a different solution / draft ?

About the ability to 'grab a line' either before making a call or before needing to do a handover: this could easily be made configurable on the client, such that the system could do both, right? Just need to make sure then that the use case is also reflected in the BLA draft, and that the mechanisms used work either before or during a call

Regards,

Jeroen

----- Original Message ----- From: "Dale Worley" <dworley at pingtel.com>
To: "'Sipping (E-mail)'" <sipping at ietf.org>
Sent: Thursday, August 04, 2005 9:52 PM
Subject: RE: [Sipping] Comments on BLA draft



From: Christian Stredicke

I think the BLA draft is a pragmatic approach to solve this problem. We
should support it to get the foot into the door of those customers that
are willing to pay good money for a working SIP enterprise system.

From: Paul Kyzivat

I see some similarity here between this draft and the TISPAN
requirements draft. Namely that we go to a lot of trouble to emulate
behavior that is largely justified by historical legacy rather than
current utility.

It might be baggage, but then again, it might not. To be usable, systems
have to satisfy a lot of user needs, some of which aren't obvious until one
has tested a candidate system in the field. (Remember the adage "Never buy
version 1.0!") A system that has been used in the field for decades may be
suboptimal, but we know that it is *acceptable* to the users, wherease a
new, improved way of doing the same thing might have deficiencies that we
wouldn't spot until deployment.


In this case, it seems to me that the best strategy is to simulate the
legacy systems and allow evolution to improve the deployed solutions, rather
than assuming that we can guess what is better. (This really is a current
market need for small office PBXs.)


In regard to identifying and displaying call information, it would seem that
having the PBX assign small integers is less useful than displaying To/From
dialog information. But there have been perennial problems with "what data
items are needed to identify the dialog/subscription/fork", and there may be
pitfalls that would take some time to discover. And there is still the
convenience (and noise-resistance!) of shouting "Joe, pick up on line five!"


From: Jeroen van Bemmel

OK, so how about postponing the allocation of a line ID until the moment
that the user wants to put the call on hold? That way you don't
unnecessarily restrict the number of simultaneous outgoing calls, just the
number that can be put on hold simultaneously

Yes, I suppose we could do that. Though in practice, it seems that "running
out of lines" rarely happens, so it doesn't seem like all that much is
gained.


Actually, what I was "getting hung up on", is the idea that the user needs
to select the sub-line ID *before he can start making an outgoing call*.

But the *user* doesn't need to select the ID, only the UA.

Dale


_______________________________________________
Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP


_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP