Here’s the situation: We have several (read: many) customers on a certain satellite internet provider with Xceptionally poor service. These customers very obviously drop packets like they’re going out of style (you can hear it in a VOIP call - sometimes you can catch 1 word out of 2), their ping times are very high, the connection is generally highly unreliable and sometimes too slow to actually support voip at all.
The problem came where the upgrades began. We wanted to improve voice quality by leaps and bounds, so we moved from our old server running Asterisk 0.4 (CVS-HEAD-08/04/04-13:50:08) pre-alpha or some such, to Asterisk 1.4.18. Apparently though, this was a disservice to the satellite customers, since by some miracle their SIP logins were stable (which is to say, their Linksys PAP2s stayed logged in) on the old server, but not on the new server. Personally, I think this just illustrates in spades how astonishingly bad their internet service is, but they’re all whining “but it worked before!”. Mind you, they were all whining before the upgrade about how bad the service was, just not about this issue.
Is there any way to make it so they don’t have to restart their ATAs every 45 minutes to keep their connection going? We’ve already tried setting qualify=15000 (yes, 15 seconds… setting qualify=5000 is too short and kills the connection even more often, and qualify=no doesn’t do anything either, of course). Even if anyone could explain why this happened, I could tell my boss so he doesn’t think that it’s something I did.
I not used VOIP over satellite but I currently use a wireless connection (all I can get besides satellite is Telstra NextG) with ping times usually around 200ms I know it’s better than satellite but its heading in that direction.
It registers with our Brisbane Asterisk box running 1.4.14 I too could not find any qualify setting that would work. Currently I have the qualify set to no which works fine.
I am using Cisco 7940G handsets (very happy with them).
I hate to say it but you have answered you own question here;
[quote=“dufus”]I’d make sure that they’re using some form of QOS for their traffic.
If they’re browsing and getting email at the same time they’re trying to have a VOIP call, they’re just asking for trouble.
A QOS enabled router would go a long way to managing the traffic across the sat connection.[/quote]
That doesn’t really explain why their connection is getting dropped only after we moved from Asterisk $ARCHAIC_BETA_VER to Asterisk 1.4.18. Is there something in sip.conf where I can set “dontdrophorribleconnections=yes”?
What comes up in the CLI when the call is going bad ? Do you have rtptimeout= in sip.conf ? Also try changing the packetazation time in sip.conf.
allow=G729:20 or allow=g729:30 may help as well.
In general we have had very bad expiriences using sat. + voip.
I also remember a client of ours that was using us over sat. and their sat. internet provider would drop the call if there was not enough traffic goinf though (they didn’t want t cary the bandwidth if they didn’t have to).
I don’t have rtptimeout set in sip.conf (as it should be), but thanks for the tip on the G729 packetization, we’re giving that a try now.
These customers don’t get disconnected in the middle of a call… their ATA just drops its registration several times a day and doesn’t bother to pick it up again.
We’re still testing this theory, but we think that setting the ATA to use $PING instead of $NOTIFY for its NAT keepalive solves this problem. The problem is documented in a little more detail here: voipuser.org/forum_topic_10985.html
Maybe there is a hiccup in the line. I would set the registration to 180 seconds, use STUN and set the registry retry high. Also try some packet sniffing. It may give you a clue as to what is going on. The packetization time tends to help more with bandwidth.