Hello FS team, I'm just writing thie short email to congratulate you guys for the amazing work you're doing with FS since the very beginning. As some of you may know, some time ago I developed the FreeSWITC-Billing platform on top of FreeSWITCH (although it's been some time since I updated it). Some of my customers have been using it for 2 years now and have good traffic running on it. Long story short, I was called by 2 of my customers who were in turn called by a couple of their providers asking to please, please, pretty please slow doen the rate with which my customers were sending calls to them or to limit the channels, because my customers were bringing their soft-switches DOWN... I don't know the other switch's brand , but I know one is a Quintum. So, like I said: KUDOS! Cheers to all and Happy New Year!! David Villasmil https://github.com/davidcsi/FreeSWITCH-Billing
This has a whole lot more to do with interconnect agreements than how many CAPS one solution can send versus another. Frankly any old piece of SIP gear has the potential to send more CAPS than your average provider would expect to receive. Many telcos, especially tier one's will establish an upper limit on the number of attempts per second that any interconnect can initiate, for example BT in the UK limit it to one CAPS per 30 channels approximately. It's not fair to allow one customer to use the whole available capacity at the expense of other customers. We're forever clamping customers because their rubbish dialler software has no understanding of a 503 with Retry-After response and have gone to lengths to automate this to protect our network, as even FS can get crippled by a device which relentlessly initiates call after call (in some cases we've seen well over 100 CAPS from a single device). So when we detect a killer trunk we'll raise a critical event in the FS logs and use Fail2Ban to ignore requests from the customer's IP. -- View this message in context: http://freeswitch-users.2379917.n2.nabble.com/Kudos-to-the-FreSWITCH-team-tp... Sent from the freeswitch-users mailing list archive at Nabble.com.
503 w/ Retry-After lol... Dialers ignore that one? Really? They would never do such a thing... The problem with Retry-after is how its implemented across the board... Not everyone interprets it the same way... Sofia for instance by default if it gets a 503 Retry After will HOLD that call for retry-after timeout, then send it again to the same destination, it does not however prevent new calls from going to the same gateway... (I found this little tid bit by accident trying to figure out why certain calls were not route advancing... And this is not something the FS developers did, but it was down deep in sofia) K On 1/3/13 9:55 AM, "peely" <freeswitch@peely.com> wrote:
This has a whole lot more to do with interconnect agreements than how many CAPS one solution can send versus another. Frankly any old piece of SIP gear has the potential to send more CAPS than your average provider would expect to receive.
Many telcos, especially tier one's will establish an upper limit on the number of attempts per second that any interconnect can initiate, for example BT in the UK limit it to one CAPS per 30 channels approximately. It's not fair to allow one customer to use the whole available capacity at the expense of other customers.
We're forever clamping customers because their rubbish dialler software has no understanding of a 503 with Retry-After response and have gone to lengths to automate this to protect our network, as even FS can get crippled by a device which relentlessly initiates call after call (in some cases we've seen well over 100 CAPS from a single device). So when we detect a killer trunk we'll raise a critical event in the FS logs and use Fail2Ban to ignore requests from the customer's IP.
-- View this message in context: http://freeswitch-users.2379917.n2.nabble.com/Kudos-to-the-FreSWITCH-team-tp... 85975p7586031.html Sent from the freeswitch-users mailing list archive at Nabble.com.
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Ken http://www.FreeSWITCH.org http://www.ClueCon.com http://www.OSTAG.org irc.freenode.net #freeswitch
"A client (proxy or UAC) receiving a 503 (Service Unavailable) SHOULD attempt to forward the request to an alternate server. It SHOULD NOT forward any other requests to that server for the duration specified in the Retry-After header field, if present." But hey, if everyone stuck to the spec' then things would be really dull. -- View this message in context: http://freeswitch-users.2379917.n2.nabble.com/Kudos-to-the-FreSWITCH-team-tp... Sent from the freeswitch-users mailing list archive at Nabble.com.
I didn't say it was correct application on the spec, just pointing out how things actually work in real life... And for the commenter who said most soft switches can handle way more volume then they are allowed to, that's only true in certain situations... Look at some of the gear out there that's supposed to be good gear... They cant handle more then 25 to 50 calls per second... Not to mention over sell ratios on the end offices... How common is it to see 30+ to 1 oversells? On 1/3/13 10:29 AM, "peely" <freeswitch@peely.com> wrote:
"A client (proxy or UAC) receiving a 503 (Service Unavailable) SHOULD attempt to forward the request to an alternate server. It SHOULD NOT forward any other requests to that server for the duration specified in the Retry-After header field, if present."
But hey, if everyone stuck to the spec' then things would be really dull.
-- View this message in context: http://freeswitch-users.2379917.n2.nabble.com/Kudos-to-the-FreSWITCH-team-tp... 85975p7586035.html Sent from the freeswitch-users mailing list archive at Nabble.com.
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Ken http://www.FreeSWITCH.org http://www.ClueCon.com http://www.OSTAG.org irc.freenode.net #freeswitch
Hello guys, Thanks for the commets, but like I said: "The SWITCH is coming down"... Anyway, Thanks to FS-Team! David On Thu, Jan 3, 2013 at 5:38 PM, Ken Rice <krice@freeswitch.org> wrote:
I didn't say it was correct application on the spec, just pointing out how things actually work in real life...
And for the commenter who said most soft switches can handle way more volume then they are allowed to, that's only true in certain situations... Look at some of the gear out there that's supposed to be good gear... They cant handle more then 25 to 50 calls per second... Not to mention over sell ratios on the end offices... How common is it to see 30+ to 1 oversells?
On 1/3/13 10:29 AM, "peely" <freeswitch@peely.com> wrote:
"A client (proxy or UAC) receiving a 503 (Service Unavailable) SHOULD attempt to forward the request to an alternate server. It SHOULD NOT forward any other requests to that server for the duration specified in the Retry-After header field, if present."
But hey, if everyone stuck to the spec' then things would be really dull.
-- View this message in context:
http://freeswitch-users.2379917.n2.nabble.com/Kudos-to-the-FreSWITCH-team-tp...
85975p7586035.html Sent from the freeswitch-users mailing list archive at Nabble.com.
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Ken http://www.FreeSWITCH.org http://www.ClueCon.com http://www.OSTAG.org irc.freenode.net #freeswitch
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
On Thu, Jan 3, 2013 at 9:25 PM, peely <freeswitch@peely.com> wrote:
This has a whole lot more to do with interconnect agreements than how many CAPS one solution can send versus another.
This is true, most of the time its the CPS limit agreement with their upstream that forces providers to slow down the traffic way below than what any softswitch can blast out. -- Godson Gera IPPBX Solutions <http://lintelindia.com>
participants (4)
-
David Villasmil
-
Godson Gera
-
Ken Rice
-
peely