Calls Dropping

[qdi40]

I have recently been forced by my ISP (Rogers) to change my modem, since doing so I seem to be intermittently dropping calls. I had to change my service as my old plan is no longer offered, but I have more than enough bandwidth.
I did not have an issue prior to changing the modem and plan.
Seems to happen mainly with outgoing calls.

I have reached out to Rogers and they say all is good from their end.


Anyone experience similar issues/have any suggestions?

[Liptonbrisk]

Carefully follow the steps below, step by step.


1. Disable SIP ALG in the modem/router combo that Rogers gave you

Hitron CGN series gateway modem/router combos (from Rogers, Shaw, or another ISP) or any modem/router combo from any ISP with SIP ALG forced on

If you don’t have your own router, and if you can’t get someone from Rogers or your ISP to disable SIP ALG for you in their modem/router combo, your ATA may need to register with voip4.freephoneline.ca:6060. The purpose of voip4.freephoneline.ca:6060 is to help circumvent faulty SIP ALG features in routers. So, if you’re experiencing one-way audio issues as a result of SIP ALG, this is the SIP server to try. Check to ensure that you can’t disable SIP ALG yourself (refer to point E below).

Hitron CGN3ACSMR and CODA-4582 series gateway modem/router combos from Rogers (and possibly other ISPs)
Open your web browser, and login at 192.168.0.1. Default username is cusadmin.
Select the “Basic” tab and disable “SIP ALG.” Click the “save changes” button.

2. Reboot modem-->router (wait for it to be fully up and running)-->ATA in that order

This is always the proper device reboot order.

3. Visit https://www.voipmechanic.com/droppedcalls.htm, and see whether anything there applies to you. However, never use DMZ (and don't port forward). Ignore whatever that site says about DMZ. Huge security risk.


4. If jitter or packet loss is bad enough, calls will drop. Consequently, what's written below about QoS applies.

The following is taken from https://forums.redflagdeals.com/newegg- ... #p28508733:

Generally speaking it's best to have a decent router for VoIP (your own--as opposed to one issued by your ISP) with strong QoS features.
Stick your ISP's modem in bridge mode, use your own router, and properly enable QoS for your ATA.
Refer to your router's manual.

I'm not a big fan of this site, but for a general QoS description, visit http://www.voipmechanic.com/qos-for-voip.htm (avoid anything it says about G729 codec).

I'm suggesting Toronto below, because FPL's SIP servers are in Ontario. When you test, pick the location that is closest to your VoIP service provider's server location.

Have been using freephoneline with obihai 202 behind Asus RT N66U router. Often time people complain that my voice very choppy on their end, yet I seem to hear them fine. Is there setting that I should tweak on ATA set up or on router? Thanks very much

That's usually related to upload jitter/packet loss.

a) The typical reaction would be to try enabling QoS properly in your router for your ATA. Refer to your router's manual.

Probably in the traffic manager area, use a drop down box to select "User Defined Rules". Then create a rule giving traffic highest priority to your ATA's MAC address.

b) Another possibility is you're dealing with congestion during prime time (8p.m. to midnight, especially on Sundays). That's an ISP issue (possibly oversold its service in your area).

Try running Running http://vac.visualware.com/index.html at 8p.m. (especially on Sunday).

Pick the test location that's closest to where your VoIP server is situated.
A MOS score below 4.0 is bad news. It means call quality will not be good.
The advanced (+) tab provides interesting info.

You should also try the winmtr test I mention over here around 8 p.m. to FPL's servers:
http://forums.redflagdeals.com/newegg-o ... #p27515963

Anything over 200ms is unacceptable.

What you don't want to see is 40, 45, 50, 35, 500, 40, 30, 45, 700. That's bad jitter.
You want relatively consistent pings without a lot of variation.

One reason why jitter can occur is due to other devices on your LAN (local area network) using bandwidth. That’s why properly enabling QoS in your router for your ATA is always a good idea. Refer to point 4 in the Preamble.

Bad jitter can produce broken up audio or choppiness during phone calls. Severe jitter can cause calls to drop. Ping affects delay.

If the problem only occurs during prime time (as opposed to weekday mornings), then I would probably start thinking your ISP is to blame.

The Internet is 100down/10up.

Down doesn't matter. What people hear from you is upload.

No other devices are being used at time of bad voice quality.

A lot of people say that without realizing other devices and/or programs may actually be using bandwidth in the background. It's really not a good idea, in general, to be using a router that doesn't have a good QoS feature for VoIP.

But if what you wrote is really true, then you may be dealing the possibility of congestion during prime time (8p.m. to midnight, especially on Sundays). That's an ISP issue (possibly oversold its service in your area).

Try running http://vac.visualware.com/index.html at 8p.m. (or between 8 p.m. and 11 p.m.)

Select a test server location that's located close to the SIP server you're using.
A MOS score below 4.0 is bad news. It means call quality will not be good.


You should also try the winmtr test (or if you're on a mac, maybe this helps: https://www.reddit.com/r/TagPro/comment ... tr_on_mac/) I mention over here around 8 p.m. to FPL's servers:
http://forums.redflagdeals.com/newegg-o ... #p27515963

If the problem only occurs during prime time (as opposed to weekday mornings), then I would probably start thinking your ISP is to blame.



5. I recommend reading the first four pages (the preamble) section of the OBi200/202 guide: http://forum.fongo.com/viewtopic.php?f= ... 805#p73839

[qdi40]

Okay so I did as suggested and disabled ALG, now I don't get any incoming calls. all incoming calls are going ringing on the callers end but I don't get anything on my side. I've tried rebooting everything again but nothing. My setup is Rogers modem, Router, ATA. nothing has changed on my router or ATA. it was just a modem swap from the ISP.
Any other ideas?

My ASA shows its Online and Registered, so its obviously getting a send/receive msg of some sort.

Any other ideas while I search the forums?

[Liptonbrisk]

Okay so I did as suggested and disabled ALG, now I don't get any incoming calls. all incoming calls are going ringing on the callers end but I don't get anything on my side. I've tried rebooting everything again but nothing. My setup is Rogers modem

What is the brand and model? Chances are that's not just a modem issued by Rogers. It's likely a modem/router combo, in which case, you haven't simply introduced a new modem into your setup; you've also introduced an additional router, which is an additional point of failure for troubleshooting purposes. If the Rogers device is a modem/router combo, you have a double NAT scenario since you're running two routers (which I didn't realize before).

Follow all 5 steps below in the order they're listed, slowly and carefully:

1. Try a different phone. Rule out potential handset/phone issues. Make sure you check any phone cords and ringer settings on the phone itself.

2. Stick what, I strongly suspect, is a Rogers Hitron modem/router combo into bridge mode, so that you're completely bypassing all router functions in the Rogers device, including its NAT firewall: click https://www.rogers.com/customer/support ... your-modem for instructions. CODA-4582 instructions are basically the same as CGN3.

3. Login to your PAP2T (I’m not positive what you’re using, but you have that ATA listed in your profile), Navigate to Line 1 (or whatever you're using for FPL)-->SIP settings, change SIP Port to a random number between 30000 and 60000. That's useful not only for security reasons, but also to help re-establish proper NAT associations, if a corrupted one previously existed.


4. In your PAP2T (I’m not sure what you’re using), navigate to the SIP tab-->NAT Support Parameters, and make sure that the following settings are enabled:

a)Handle VIA received-->yes
b)Handle VIA rport-->yes
c)Substitute VIA Addr-->yes

Those settings are important with respect to ensuring the RTP audio stream being sent from FPL's to you actually reaches your router.

5. Reboot the modem/router combo. Wait for it to be fully up and running. Reboot your router. Wait for it to be fully up and running. Finally, reboot your ATA. That's always the proper device boot order. Then test with an incoming call. If you still encounter issues, temporarily (and do this quickly, because the ATA will be unprotected due to a lack of any firewall) attach your ATA directly the the modem (you must, absolutely, ensure that it's in bridge mode). If incoming calls work then, we can conclude there's an issue involving your router (as opposed to Rogers' modem/router combo).

You can also try using voip4.freephoneline.ca:6060 as the proxy server in your ATA. However, its purpose is to bypass faulty SIP ALG functions in routers, and you've already disabled SIP ALG in the Rogers Hitron modem/router combo that was issued to you, and if you've followed these instructions properly SIP ALG is automatically disabled in the Hitron gateway (modem/router combo) when you enable bridge mode. Unless SIP ALG is causing problems in your own router, I'm not sure how useful trying voip4.freephoneline.ca:6060 would be.

If you still have problems, I would revisit steps 2 onwards in my original reply to you. And then I would visit (if you're still using the ATA in your profile) http://forums.redflagdeals.com/freephon ... #p26808549.

Router

What brand and model? Is your user profile still correct?

ATA

What brand and model?

nothing has changed on my router or ATA.

Unfortunately, intermittent call problems can arise without the user doing anything--and with the issue still being on the user's end when no immediate problem existed previously. I don't want you to bother pursing this at the moment, but here's an example:

Thanks to Mango, many of us now understand that in order for ATAs to remain registered and working properly with a VoIP SIP provider like Freephoneline, in particular after power failures, the following conditions must be met:

UDP Unreplied Timeout (in your router) < NAT Keep-alive Interval (in your ATA; for Obihai ATAs this is X_KeepAliveExpires) < UDP Assured Timeout (in your router) < SIP Registration Failure Retry Wait Time (or RegisterRetryInterval in Obihai ATAs)

“<“ means less than.

When a modem leases a new IP address, a problem can arise where prior associations using the old IP address are maintained in the router. When the ATA attempts to communicate using the old IP address, the response is unreplied, and then if the UDP Unreplied timeout is greater than the Keep Alive Interval (and UDP Unreplied timeout is often set to 30 by default in consumer routers) a problem arises where the corrupted connection persists. If UDP Unreplied timeout is, for example, 10, and the NAT Keep Alive Interval is 20, then the corrupted connection will timeout or close. A new connection will be created, and everything will work fine.

Another problem can occur when the Keep-Alive interval is greater than UDP Assured Timeout (often 180 by default in consumer routers): the NAT hole will close due to the ATA not communicating frequently enough with the SIP server. In turn, incoming calls may, intermittently, not reach the ATA. Again, X_KeepaliveExpires is supposed to be 20 with FPL.

Getting access to both UDP Unreplied Timeout and UDP Assured Timeout settings in consumer routers may be difficult, if not impossible. Asuswrt-Merlin, third party firmware for Asus routers, does offer easy access to these two settings, which are found under Tools-->Other settings. In part, for this reason, I tend to use Asus routers. However, my understanding is that third party Tomato firmware has these two settings as well. So if your router supports Tomato firmware, that may be another option.

The keep alive interval for FPL is 20. The SIP Registration Failure Retry Wait Time is 120. I use 15 for UDP Unreplied Timeout and 115 for UDP Assured Timeout.