Feature request: Admission control

[Mark Dutton]

Hi all

I know this has been asked for before, but a really
desirable (I would say necessary) feature for SIP trunks, is
some form of admission control. Ideally this would be in
Kb/s, so the switch can figure out how many calls it can
push down a trunk based on codec negotiation, but even max
number of calls would be nice. It is impossible to maintain
QoS if the PBX can not be limited in the number of calls
egressing its trunks.

[Douglas Hubler]

Post by Mark Dutton
I know this has been asked for before, but a really
desirable (I would say necessary) feature for SIP trunks, is
some form of admission control. Ideally this would be in
Kb/s, so the switch can figure out how many calls it can
push down a trunk based on codec negotiation, but even max
number of calls would be nice. It is impossible to maintain
QoS if the PBX can not be limited in the number of calls
egressing its trunks.

Option #1: There's now an event bus "Network Queue" that we hope to
use for apps that want to monitor current call state. Fed info back
to a proxy plugin to reject calls after a certain threshold is hit.

Option #2: If you can come up with an iptables rule i'm sure that
could be integrated very easily.

[Mark Dutton]

I think it would have to be in the sip stack so option 1.

Thinking about typical deployments. Home phones coming in
via the SBC, site to site links, etc. These all could be
measured via the SBC, but then what about private WAN/VPN?
They will use direct media connections. The proxy is the
only common component that can track the calls.

Could the sipxproxy maintain the call list and arbitrate?
Even though it is essentially stateless, every call should
have a BYE to end it and if not, a session TIMER could clear
down stale calls. Perhaps it could be mandatory to use the
session timer if admission control is enabled, or a
configurable timer that clears out calls that have gone over
a long period, say 4 hours from the last INVITE/REINVITE.

Just thinking aloud.

Sorry if this is the wrong forum for these comments. I am
evaluating open source PBX options. We have been installing
commercial IP PBX products (Zultys, Shoretel) for years. I
set out evaluating the Asterisk distis, but I came back to
sipX after looking at it several times in the past and I was
blown away by how good it is. Just need to do the due
diligence before we commit and I am eagerly following the
4.6 development.

[Tony Graziano]

I think it needs to the in the sip stack.

I think using ip tables might have an unintended consequence of blocking
other legitimate traffic that is sip based like mwi, registrations and
perhaps resource list stuff.

Putting this in the sip stack also means it needs to be determined whether
or not the call mission control plug in monitors every type of call (
internal, external, service/ivr ). Or any vpn connected remote users other
difficult to classify connections this might prove to be very difficult
indeed.

Post by Mark Dutton
I think it would have to be in the sip stack so option 1.
Thinking about typical deployments. Home phones coming in
via the SBC, site to site links, etc. These all could be
measured via the SBC, but then what about private WAN/VPN?
They will use direct media connections. The proxy is the
only common component that can track the calls.
Could the sipxproxy maintain the call list and arbitrate?
Even though it is essentially stateless, every call should
have a BYE to end it and if not, a session TIMER could clear
down stale calls. Perhaps it could be mandatory to use the
session timer if admission control is enabled, or a
configurable timer that clears out calls that have gone over
a long period, say 4 hours from the last INVITE/REINVITE.
Just thinking aloud.
Sorry if this is the wrong forum for these comments. I am
evaluating open source PBX options. We have been installing
commercial IP PBX products (Zultys, Shoretel) for years. I
set out evaluating the Asterisk distis, but I came back to
sipX after looking at it several times in the past and I was
blown away by how good it is. Just need to do the due
diligence before we commit and I am eagerly following the
4.6 development.
--
Regards
Mark Dutton
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/

[Mark Dutton]

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.

[Michael Picher]

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

Post by Mark Dutton
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
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.

[Tony Graziano]

Admission control only works if fully thought out. If you have a remote
user and that user makes a call via the pstn it has to be properly
accounted for. Simply putting a limit on the trunk handles only part of a
wide area network telephony system. While the trunk call is accounted for
what about the remote user and where the call is anchored and which network
segment.

I think the network queue might be the defining place though.

It was never a part of the stated project to develop an SBC until 4.0 came
along.

Gateways were always use able since its open source release. Not sure
picking on this gets the admission control any further along.

Glad you like where the project is. Stick around to see what is next.

Post by Mark Dutton
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
List Archive: http://list.sipfoundry.org/archive/sipx-users/

[Mark Dutton]

Tony and Michael

Thanks for the replies.

I can see both of your viewpoints and in they both make
sense.

In an imperfect world we make compromises and it sounds like
you are on the way to making one that will do the job. Even
if just the SBC gets admission control now that would help
us engineer a solution that would give us the control we
want.

I am not sure if you guys have seen the Zultys IP PBX. It is
similar to the Sipx in that it has an embedded SBC and a
stateless proxy. There is a powerful policy engine that
allows you to run either stateless, or stateful depending on
a matrix of source/destination addresses/subnets. Even when
your calls are stateless, it still keeps track of the calls
and the bandwidth to each destination. It allows you to set
a bandwidth limit on every SIP trunk and remote site (you
can define sites by subnet).

You can still come unstuck when all your remote users and
remote trunks are through a single WAN link and the only way
to guarantee you won't over commit the link is to make sure
the sum of all your sites and servers don't exceed your link
commit. This is not perfect, but I personally think it is
better to have less capacity but perfect audio over the
other way around.

I will stick around and watch what is going on. The beauty
of Virtualisation means I can keep all the systems running
at once.

[Todd Hodgen]

There is another method of controlling this a well. With your ITSP, you can
control the number of Concurrent Call Sessions they allow. Most charge for
CCS, although some don't. This won't take into account remote workers, etc.
but that can be easily handled by an SBC.

-----Original Message-----
From: sipx-users-***@list.sipfoundry.org
[mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of Mark Dutton
Sent: Wednesday, July 25, 2012 4:00 AM
To: sipx-***@list.sipfoundry.org
Subject: Re: [sipx-users] Feature request: Admission control



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

[Mark Dutton]

These are all good points, but it doesn't help when you are
not using a gateway device with limited resources, or an
ITSP who blocks the nth call. What about when you have multi
site setup where you have handsets in the field? What about
where you have a multi-site sipXecs deployment with a
sipXecs proxy at each site and they new to communicate
between each other. In both of those scenarios, you have the
potential to flood your link.

The only way you could get a firewall to create control of
this would be if it was a layer 7 firewall that intercepted
the SIP requests and sent back a 4xx failure to the calling
end. I don't see this happening any time soon and it would
lead to a raft of compatibility issues and finger pointing
when there were interop problems.

[Todd Hodgen]

Ah, but that is why we have Mike. Those complicated systems need a top
notch Engineer, Author and just all around fast driver to show them how to
correctly engineer the goezinda' and goezoutta' of the network. What's
that line - we don't need no stinkin' CAC, we got Mike to watch our BACK.

I agree, Nirvana is always great, and I'm sure the developers would love to
have someone create the solution and donate it to the project. In the
meantime, we cobble together with what we have like everyone else, and make
fun of good ol' Mike.

Cheers!

-----Original Message-----
From: sipx-users-***@list.sipfoundry.org
[mailto:sipx-users-***@list.sipfoundry.org] On Behalf Of Mark Dutton
Sent: Thursday, July 26, 2012 12:18 AM
To: sipx-***@list.sipfoundry.org
Subject: Re: [sipx-users] Feature request: Admission control



These are all good points, but it doesn't help when you are not using a
gateway device with limited resources, or an ITSP who blocks the nth call.
What about when you have multi site setup where you have handsets in the
field? What about where you have a multi-site sipXecs deployment with a
sipXecs proxy at each site and they new to communicate between each other.
In both of those scenarios, you have the potential to flood your link.

The only way you could get a firewall to create control of this would be if
it was a layer 7 firewall that intercepted the SIP requests and sent back a
4xx failure to the calling end. I don't see this happening any time soon and
it would lead to a raft of compatibility issues and finger pointing when
there were interop problems.
--
Regards

Mark Dutton

[Michael Picher]

Cisco had done some work on this but I'm not sure it's current state in
their routers (
http://www.cisco.com/en/US/docs/ios/solutions_docs/voip_solutions/CAC
.html#wp941119).

There's also a RFC that's being worked on around this.
http://tools.ietf.org/search/rfc5865

Some day... some day...

Todd can keep tweaking me in the mean time :-)

Mike

Post by Todd Hodgen
Ah, but that is why we have Mike. Those complicated systems need a top
notch Engineer, Author and just all around fast driver to show them how to
correctly engineer the goezinda' and goezoutta' of the network. What's
that line - we don't need no stinkin' CAC, we got Mike to watch our BACK.
I agree, Nirvana is always great, and I'm sure the developers would love to
have someone create the solution and donate it to the project. In the
meantime, we cobble together with what we have like everyone else, and make
fun of good ol' Mike.
Cheers!
-----Original Message-----
Sent: Thursday, July 26, 2012 12:18 AM
Subject: Re: [sipx-users] Feature request: Admission control
These are all good points, but it doesn't help when you are not using a
gateway device with limited resources, or an ITSP who blocks the nth call.
What about when you have multi site setup where you have handsets in the
field? What about where you have a multi-site sipXecs deployment with a
sipXecs proxy at each site and they new to communicate between each other.
In both of those scenarios, you have the potential to flood your link.
The only way you could get a firewall to create control of this would be if
it was a layer 7 firewall that intercepted the SIP requests and sent back a
4xx failure to the calling end. I don't see this happening any time soon and
it would lead to a raft of compatibility issues and finger pointing when
there were interop problems.
--
Regards
Mark Dutton
_______________________________________________
sipx-users mailing list
List Archive: http://list.sipfoundry.org/archive/sipx-users/
_______________________________________________
sipx-users mailing list
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.

[Joe Micciche]

Post by Todd Hodgen
These are all good points, but it doesn't help when you are not
using a gateway device with limited resources, or an ITSP who
blocks the nth call. What about when you have multi site setup
where you have handsets in the field? What about where you have a
multi-site sipXecs deployment with a sipXecs proxy at each site and
they new to communicate between each other. In both of those
scenarios, you have the potential to flood your link.

Great explanation why CAC is not in sipXecs right now. :) Once you add
CAC, you need a host of other tools and options such as alternate
routing, overrides for emergency calls, etc etc.

While CAC superficially seems "nice", it's incredibly complex beyond
just "I have x bandwidth for y calls". This is not to say it shouldn't
be discussed or worked on, but by no means is it trivial.

Post by Todd Hodgen
The only way you could get a firewall to create control of this
would be if it was a layer 7 firewall that intercepted the SIP
requests and sent back a 4xx failure to the calling end. I don't
see this happening any time soon and it would lead to a raft of
compatibility issues and finger pointing when there were interop
problems.

I wonder about using an sbc and/or gatekeeper to achieve this. I'm not
familiar with Karoo, but perhaps something like Kamailio / openSER /
openSIPS could be used?

- --
==================================================================
Joe Micciche ***@redhat.com
Red Hat, Inc. http://www.redhat.com
Senior Communications Engineer X (81) 44554
+1.919.754.4554 Key: 65F90FE1
==================================================================