are you sure its not your provider placing this limit on you?
also do you have QoS setup on yoru router?
when you say ‘cant handle’, what happens? does the call not go through or do you get an error message when you dial?
I wouldn’t recommend DSL as my experience with it did not lead to the best conclusive results. Cable carries more bandwidth anyday. But before you commit to that you might want to prioritize voice ports/protocols/ports on your router and see how it pans out. Also try a different codec. Depending on your results i.e. if there is no difference in call quality, you can then move on to cable internet connection which is ahigher speed connection than DSL and less disconnection/synchronization headaches.
ive had no problem with asterisk over DSL at my house, though I almost never have more than 1 concurrent call at any given time. D-link makes a stream engine product they call a voip accelerator that will automatically identify voice streams and give them priority over your other traffic. I put one between my shorewall firewall and my dsl modem. I am using ulaw and thats about the heaviest of all codecs on bandwidth and still have clean audio quality. When running tests at www.testyourvoip.com I always get perfect scores of 4.4, which is the max for g711.
I have the * box connected to a dedicated router and cable modem. I dropped a speed test tool onto the * box and it regsiterd:
Download Speed: 65351 kbps (8168.9 KB/sec transfer rate)
Upload Speed: 39988 kbps (4998.5 KB/sec transfer rate)
At the time when the calls are choppy there is nothing else running. Here’s what else I have done:
Switched from Voicepulse to Vitelity.net.
Re-encoded (to be sure) everything to gsm.
Disallow=all, allow=gsm in all conf files (confirmed all calls are going out gsm).
Now by doing this I have been able to sustain about 3 perfect outgoing concurrent calls. However if I up this to 5 the last two calls start breaking up. No errors. Just stuttering etc.
Someone else mentioned that ISPs somtimes throttle the bandwidth for iax/sip connections versus regular http/ftp – is this right? If not, then with the upload speed I have available I should be easily running 10 concurrent calls with gsm and if I switch to g729 even more.
[quote=“mrloofer”]I have the * box connected to a dedicated router and cable modem. I dropped a speed test tool onto the * box and it regsiterd:
Download Speed: 65351 kbps (8168.9 KB/sec transfer rate)
Upload Speed: 39988 kbps (4998.5 KB/sec transfer rate)
[/quote]
ok those numbers do not jive with a cable modem. A full t-1 has an upload of 1544 kbps, are you sure you did a speed test across the wan? Or did you put a k in there on accident and the number is actually bps? I really doubt you have a 40 megabit upload on a cable modem. The device has a theoretical limit of 10 megabit and you wuold have to be within 1000 feet of the main concentrator. A DS-3 has a limitation of 45 megabit and costs around 5k to 10k US per month to run.
Made some progress tonight. I decided to switch the * box over to my dsl router and modem. I was able to process 6 calls before they started breaking up. I switched it back to the cable modem router and changed the MTU to 1492 and enabled multicast streams (dont know what this is). After a reboot and network restart I was able to process 7 calls, 8+ resulted in serious choppy calls.
I should easily be processing 10 calls on a 400kb upload connection using GSM. Could it be my router at fault? I’m using a regular DLink DI-524. Do I gain anything by adding a QOS router or DI-102 on a connection that should not be shared by anything else?
not only IP overhead but Ethernet overhead too. DSL modems and cable modems are more or less bridged ethernet. I couldnt find a bandwidth calculator for GSM 13.3k but I used g.728 which is a 16k codec. Every call path will consume 47.2kbps of ethernet bandwidth. So your results are right on that after your eigth call you would start getting breakup. And thats with absolutely no other traffic going. If you use IAX trunking you should be able to reduce the overhead for subsequent calls, but this requires a timing source (either zap hardware or ztdummy) and the use of trunktimestamps so that you dont geek the jitter buffer out. In theory each additional call would only cost 14.7 kbps. That could, in theory, produce up to 25 calls on a 400k upload.
I havent yet had enough good results on trunking to use in a production environment.