Mark, I believe it will end up in the product as well at some point.
Logically I think the solution belongs at the network layer. Really only the network knows whether it should admit more calls or not. The communications system doesn't know that just as the file server doesn't know how fast it should pump data out the network adapter. And, is it good customer service to reject a call if there is plenty of bandwidth to let it happen, or should we just live with artificial limits that a system designer decided were adequate. What about when a data link fails and a backup route is taken, how does the communications system deal with that? That being said, I think it will be a while before the data systems catch up with the communications world and supply some sort of Call Admission Control (CAC). The problem has been with sipXecs / openUC that it is a stateless proxy. As such it relies on end devices such as gateways to limit calling based on their available communications capabilities. Your example of Asterisk is like comparing apples and oranges because it is easier with Asterisk sitting in the middle of the call as a B2BUA. That being said, we are implementing some new features that allow us better information about call state. This opens up the possibility of adding CAC into the product. There have been some patches submitted that also do this but we have been concerned about implementing them and adding more load onto the system. Thanks, Mike On Wed, Jul 25, 2012 at 6:59 AM, Mark Dutton <repl...@datamerge.com.au>wrote: > > > As someone who has not programmed in many a year I am sure > it is a mission. However, I think it is a crucial > requirement in any IP phone system that will use low speed > inter site links. > > Asterisk has a concurrent call limit on its trunks which go > some way towards making it usable. > > In commercial world all products we use have quite well > developed admission control. > > The thing is, when you create QoS queues in your routers, > you are creating guaranteed throughput from your PBX onto > the WAN, but your PBX has to know that it has X bandwidth, > or only can make X calls (based on your calculations in turn > based on codec choices) so that it will never try to over > commit the link. > > For us it would be a deal breaker not being able to use get > admission control. Does the commercial version have > admission control? > > I remember when I looked at SipXpbx about 4 years ago, it > had no SBC, gateways were virtually unusable and there were > so many rough edges I left it alone. Now it is polished and > for the most part working wonderfully well. I am confident > this key feature will end up in SipXecs. > -- > Regards > > Mark Dutton > > _______________________________________________ > sipx-users mailing list > sipx-users@list.sipfoundry.org > List Archive: http://list.sipfoundry.org/archive/sipx-users/ > -- Michael Picher, Director of Technical Services eZuce, Inc. 300 Brickstone Square**** Suite 201**** Andover, MA. 01810 O.978-296-1005 X2015 M.207-956-0262 @mpicher <http://twitter.com/mpicher> linkedin <http://www.linkedin.com/profile/view?id=35504760&trk=tab_pro> www.ezuce.com ------------------------------------------------------------------------------------------------------------ There are 10 kinds of people in the world, those who understand binary and those who don't.
_______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users/
