[Resolved] SIP connected, can call out, cannot receive calls

[jenom]

thank you Liptonbrisk for his long & detailed instructions
My problem was the same-- no incoming calls received, with SIP ATA device behind a router, and FPL website showed REGISTERED status.
At first, I assigned a static IP address address to SIP ATA device , put it's address into router's DMZ, and port forwarded wide ranges of UDP ports for both SIP and RTP..............this worked intermittently only !
My router is an RT-N66U , with Asuswrt-Merlin-john9527 firmware, so I was able to change timeout settings to recommended 15 for UDP Unreplied Timeout and 115 for UDP Assured Timeout..........and incoming calls are now working !

[Liptonbrisk]

I split the thread because I'm not sure whether the other user is dealing with the exact same issue since it appears different devices are being used.

hank you Liptonbrisk for his long & detailed instructions

You're welcome.

My problem was the same-- no incoming calls received, with SIP ATA device

What brand and model? I can provide specific settings for you to double check just in case, if you would like, but I need to know what you're using first.

At first, I assigned a static IP address address to SIP ATA device

That's fine.

put it's address into router's DMZ, and port forwarded wide ranges of UDP ports

That's a really huge security risk. Don't use DMZ, and don't port forward unless you have no other choice.

My router is an RT-N66U , with Asuswrt-Merlin-john9527 firmware

Do not use "+NAT Helper", which is the ALG, for SIP Passthrough in Merlin.
This can cause problems. See here: viewtopic.php?f=8&t=20182#p78916.

The SIP Passthrough setting in Asus routers is SIP ALG.


Login to Merlin.
Navigate to Advanced Settings-->WAN-->NAT Passthrough-->SIP Passthrough

Change to "Disabled".
("Enabled" works for me as well, but I do not use "Enabled + NAT Helper").


+NAT Helper is a security risk.

https://www.snbforums.com/threads/vulne ... ost-657216

The NAT Slipstream attack is the one that uses ALGs helpers to potentially compromise clients. I recommend making sure none of the settings on the NAT Passthrough page is set to "Enabled + NAT Helper", they should be either "Enabled" or "Disabled". I haven't tested this, but I would expect that ensuring NAT helpers are disabled to be enough to prevent this attack vector.

Those ALG are generally not needed by modern clients. For instance, I have both an ATA (for my home phone) and a direct IP phone (for work) here, both work fine without the need for an ALG helper.

Click "Apply"

[jenom]

My SIP device is an open VDV21, using an XML file to provision.....I could copy/paste it here, maybe something needs to be changed?
tried to run WINMTR for all 3 FPL server, and got these results, all 3 of them has some large slowdown a the same location:
voip.
ip-50.51.99.216.dsl-cust.ca.inter.net - 0 | 82 | 82 | 15 | 41 | 460 | 24
voip2
ip-50.51.99.216.dsl-cust.ca.inter.net - 0 | 69 | 69 | 15 | 108 | 896 | 217 |
voip4
ip-50.51.99.216.dsl-cust.ca.inter.net - 0 | 64 | 64 | 12 | 46 | 299 | 111 |

That IP address belongs to Fibernetics, Cambridge, Ontario , correct ?

[Liptonbrisk]

My SIP device is an open VDV21

Oh, it's an unlocked Vonage device? I'm not familiar with it. I would need to see a manual with the description of the settings available, and I not finding anything online quickly.
In general, I'm not familiar with formerly locked ITSP devices.

Anyway, I would make sure SIP Passthrough doesn't indicate "Enabled + NAT Helper" in Merlin.
"Enabled+NAT Helper" was causing problems for some people with incoming calls not being received from Rogers network (including Fido).

That IP address belongs to Fibernetics, Cambridge, Ontario , correct ?

Yes, and Fibernetics is the parent company of Freephoneline and Fongo. Your average ping isn't horrible. However, the worst one indicates bad jitter or a ping spike at the very least involving that very specific IP.
I would pay more attention to the very last line or hop in WinMTR, unless that is your last line, which it shouldn't be. If the last line is also bad, then start looking backwards up the list. What you pointed out may be where the problem begins for you. However, a ping spike can also be due an issue on your LAN. Sometimes QoS helps. If the last line doesn't indicate a problem, I would be less inclined to worry.

If you do notice you're getting large ping spikes to the last hop, then while that's occurring, incoming calls may not be received, or they may drop.