No voice on incoming calls

Have a question or problem with your Fongo application? This forum is the place to get help from both staff and fellow community members.
Fongo recommends Fongo Home Phone for a fully supported Home Phone system for only $4.95/mo

No voice on incoming calls

Postby eugenem » 01/07/2019

Hi All,
Couple of days ago I've started to experience no voice on incoming calls - then calling to home number i no longer can hear caller, they can hear me Ok.
I'm with Rogers (Ignite 500) and using Grandstream HT701 1.0.10.3 connected directly to Rogers router/modem. SIP and Firewall on the router are disabled, i've also switched Primary SIP Server to voip4.freephoneline.ca:6060 but still can not hear caller voice. I would appreciate any help
eugenem
Just Passing Thru
 
Posts: 3
Joined: 01/07/2019
SIP Device Name: Grandstream HT701
Firmware Version: 1.0.10.3
ISP Name: Rogers
Computer OS: Windows 10
Router: Hitron CODA-4582

Re: No voice on incoming calls

Postby Liptonbrisk » 01/07/2019

eugenem wrote:SIP


SIP ALG should be disabled.


and Firewall on the router are disabled


Using no firewall is a security risk.


Follow the steps below, carefully, in the order they're presented:

1. Use this PDF guide to ensure your ATA is configured properly: viewtopic.php?f=15&t=18839#p74000.
Check all settings, especially

a. Enable SIP Options Keep Alive: Yes
b. SIP OPTIONS Keep Alive Interval: 20
c. SIP REGISTER Contact Header Use: WAN Address
d. Use Random SIP Port: Yes
e. Register Expiration: 60 minutes (default)
f. SIP Registration Failure Retry Wait Time: 120 seconds


2. Proper device reboot order is always modem-->router (wait for Wi-Fi SSIDs to populate first)-->ATA (in that order). Reboot your devices now in that order and test with an incoming call from a regular (non-VoIP) cellphone or landline service.

3. If that doesn't work, you can try specifying an RTP port in the ATA and port forwarding that port to the ATA.
a. Disable "use Random RTP port" in the ATA.
b. Take note of the RTP port specified for "Local RTP Port" in the ATA.
c. Login into your router and port forward the RTP port (it's always UDP--and not TCP) to your ATA.
If you need your ATA's LAN IP address ,dial *** followed by 02. Take note of the IP address that you hear.

Refer to your router's manual, and contact your ISP if you need help with port forwarding.

Note that port forwarding is also a security risk--but not really as horrible as completely dropping your firewall or using DMZ. Port forwarding and, especially, disabling your firewall, should not be done unless all else fails. If you ever have to drop your firewall to get a SIP service working, it's time to get a new router.


4. If you still have problems, open a support ticket at https://support.fongo.com/hc/en-us/requests/new.
When creating a ticket, for the issue type select "VoIP Unlock Key-->My account inquiry". Ask for a "forced registration."
If no responds to your support ticket, provide the ticket number in a private message to Fongo Support after registering and logging into the forums: ucp.php?i=pm&mode=compose&u=7852



#6 is less likely related to your issue if your phone actually rings on incoming calls.

By the way, modem/router combos or gateways that ISPs issue are predominately bad choices for use with SIP services. Especially refer to #D in the second post below


5. 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) < SIP OPTIONS 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, 17, and the NAT (SIP Options) 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, SIP OPTIONS Keep Alive Interval 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 (I would avoid any model below/less powerful than an RT-AC68U), third party firmware for Asus routers, does offer easy access to these two settings, which are found under General–>Tools-->Other settings. 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. Note that I will not be held accountable any damage resulting from failed firmware updates. Apparently, Mikrotik routers also allow users to change both Assured and Unreplied UDP timeout settings as well: https://forums.redflagdeals.com/recomme ... 2115672/2/

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

Unfortunately, the Hitron CODA modem/router combo or gateway doesn't let you adjust UDP timeouts.


6. https://community.freepbx.org/t/trunk-s ... ca/22479/8
"As May 2013, our servers will rate limit REGISTER requests to a maximum of 10 requests per 5 minutes. Each authentication round usually consumes 2 requests (digest auth), so it is a fair number given our guidelines. Also, it does not affect INVITES (which are also authenticated)…

This rate limit is applied per IP address as our service is tailored to residential Canadian users (ADSL/Cable)."

That's why the registration interval of 3600 seconds and failed retry timer of 120s in the ATA are important.

If the ATA loses registration for any reason, incoming calls won't work on it. Note that only one registration per FPL account is allowed at any time. When there are multiple devices/softphones using the same account, only the most recent registration is valid. The previous device will lose registration. This is especially important to consider if someone else is using your SIP credentials (username and password) that are found after logging in at https://www.freephoneline.ca/showSipSettings (or if you're trying to register your FPL account with a smartphone SIP app or with another device). Registration is required for incoming calls. It is not required for outgoing calls. If you simply want to make outgoing calls using your FPL number, configure, but don't register the account, on the SIP app being used. This is also important to consider if you're using Freephoneline's desktop application (don't have it running while using your ATA with the same FPL account). Additionally, keep in mind that if someone else is also attempting to register the same SIP credentials on another device where you live, too many registration attempts can result in a temporary IP ban. Always check registration status in the IP Phone and also your SIP status after logging in at https://www.freephoneline.ca/showSipSettings. If you see a device listed under SIP User Agent that you don't recognize, you've either been hacked or someone else is using your Freephoneline SIP username and SIP Password.

Always check registration status both in your ATA first and at https://www.freephoneline.ca/showSipSettings if incoming calls aren't being received.
Please do not send me emails; I do not work for nor represent Freephoneline or Fongo. Post questions on the forums so that others may learn from responses or assist you. Thank you. If you have an issue with your account or have a billing issue, submit a ticket here: https://support.fongo.com/hc/en-us/requests/new. Visit http://status.fongo.com/ to check FPL/Fongo service status. Freephoneline setup guides can be found at viewforum.php?f=15.
User avatar
Liptonbrisk
Technical Support
 
Posts: 2763
Joined: 04/26/2010
SIP Device Name: Obihai 202/2182, Groundwire
Firmware Version: various
ISP Name: FTTH
Computer OS: Windows 64 bit
Router: Asuswrt-Merlin & others

Re: No voice on incoming calls

Postby Liptonbrisk » 01/07/2019

(Generic info)
Typically, for VoIP SIP services, especially for freephoneline, you want

A) a router that does not have a full cone NAT,

Visit https://www.think-like-a-computer.com/2 ... es-of-nat/.
Mango from the Obitalk.com forums writes,
“Use a restricted cone NAT router, and do not use port forwarding or DMZ. Restricted cone NAT will only permit
inbound traffic from the service provider you're registered to. If you have a full cone NAT router, it will allow traffic
from any source. This is probably not what you intend.
If you have a Windows computer, you can test your router using the utility here:
http://www.dslreports.com/forum/remark,22292023. To run it, use stun stun.ekiga.net from a command prompt.”
Essentially, you download the stun-test.zip file; extract the stun.exe file from within the zip file to an easily
accessible location; use an elevated command prompt (visit
http://www.thewindowsclub.com/how-to-ru ... inistrator); change directory (cd) to the
directory or location where you extracted stun.exe (visit
http://www.digitalcitizen.life/command- ... c-commands); and type “stun stun.ekiga.net” without
the quotation marks followed by the enter/return button on your keyboard.
Asus routers, at the time of this writing, produce port restricted cone NAT routers, for example and are fine,
provided you’re using one with Asuswrt-Merlin, third party firmware installed.

B) a router that lets you disable SIP ALG if it's buggy,

To understand why SIP ALG often causes horrible problems, please visit
http://www.voip-info.org/wiki/view/Routers+SIP+ALG (scroll down to the section on SIP ALG problems).

If you're dealing with a modem/router combo issued by an ISP or a router with SIP ALG forced on, you may have
to use voip4.freephoneline.ca:6060 for the Proxy Server. The purpose of voip4.freephoneline.ca:6060 is to circumvent
faulty SIP ALG features in routers.

C) a router that allows you to set QoS or assign highest priority to your ATA or IP Phone over all other devices on your LAN (local area network),

For a very general description of what QoS can do for you, visit https://www.voipmechanic.com/qos-for-voip.htm.
The basic idea is if you're torrenting or have a bunch of other computers, smartphones, tablets, etc. downloading and uploading (hogging all your available bandwidth), you don't want
your ATA not to have access to enough bandwidth to make or receive calls properly. So QoS or a Bandwidth Monitor feature (which is just another form of QoS) is a really good idea for VoIP users.

I often get an occasional relative complaining to me, "Hey my calls sound choppy." And then when I go visit, some kids are playing MMOs on a computer, while another person is downloading a huge file,
and another person is backing up files to a cloud service all at the same time someone else is trying to talk on the phone. All those devices, without QoS enabled, are fighting over available bandwidth along with the ATA.

and D) A router that lets you adjust both Unreplied and Assured UDP timeouts.

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) < SIP OPTIONS 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, 17, 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_Keepalives expires is supposed to be 20 with FPL.

(the above settings are making reference to those in Obihai ATAs)

Getting access to both UDP Unreplied Timeout and UDP Assured Timeout settings in consumer routers may be difficult, if not impossible. Asuswrt-Merlin (I would avoid any model below/less powerful than an RT-AC68U), third party firmware for Asus routers, does offer easy access to these two settings, which are found under General–>Tools-->Other settings. 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. Note that I will not be held accountable any damage resulting from failed firmware updates. Apparently, Mikrotik routers also allow users to change both Assured and Unreplied UDP timeout settings as well: https://forums.redflagdeals.com/recomme ... 2115672/2/

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



ISPs do not issue customers routers that can do all four things I just listed. Typically it's far better to have your own router with strong QoS functions and a restricted cone NAT firewall,
disable whatever SIP ALG feature is enabled in the router, and stick whatever modem/router combo your ISP gives you into bridge mode. For Bell Hubs, visit http://forums.redflagdeals.com/please-s ... r-1993629/. For Rogers, visit https://www.rogers.com/customer/support ... ridgemodem.
Please do not send me emails; I do not work for nor represent Freephoneline or Fongo. Post questions on the forums so that others may learn from responses or assist you. Thank you. If you have an issue with your account or have a billing issue, submit a ticket here: https://support.fongo.com/hc/en-us/requests/new. Visit http://status.fongo.com/ to check FPL/Fongo service status. Freephoneline setup guides can be found at viewforum.php?f=15.
User avatar
Liptonbrisk
Technical Support
 
Posts: 2763
Joined: 04/26/2010
SIP Device Name: Obihai 202/2182, Groundwire
Firmware Version: various
ISP Name: FTTH
Computer OS: Windows 64 bit
Router: Asuswrt-Merlin & others

Re: No voice on incoming calls

Postby eugenem » 01/08/2019

Well, i've disabled SIP ALG, checked the settings again - all looks good according to the config document, changed Primary SIP server to voip4.freephoneline.ca:6060 - still not hearing callers on incoming calls... Will appreciate any other suggestions.
eugenem
Just Passing Thru
 
Posts: 3
Joined: 01/07/2019
SIP Device Name: Grandstream HT701
Firmware Version: 1.0.10.3
ISP Name: Rogers
Computer OS: Windows 10
Router: Hitron CODA-4582

Re: No voice on incoming calls

Postby Liptonbrisk » 01/08/2019

eugenem wrote:Well, i've disabled SIP ALG, checked the settings again - all looks good according to the config document, changed Primary SIP server to voip4.freephoneline.ca:6060 - still not hearing callers on incoming calls... Will appreciate any other suggestions.


And you have
SIP REGISTER Contact Header Use set to WAN Address, correct? And you're testing with a regular (non-VoIP) cellphone or landline service for the incoming call, correct?

Another way to approach this (but it's a huge security risk) is to stick the CODA-4582 in bridge mode and connect the ATA directly to the CODA only for a very short period of time for testing purposes: Do not connect anything else to the CODA-4582. Visit https://www.rogers.com/customer/support ... e-coda4582. Remember that when rebooting devices, your CODA should be rebooted first (wait for it to be fully up and running) followed by your ATA. If the problem disappears (test with an incoming call), you know the issue involves the router portion (or router features) of the CODA-4582. After testing, enable Residential Gateway Function. After the CODA reboots and is up and running, reboot the ATA as well. Please ensure that your ATA is registered with FPL while testing. If it's not, incoming calls won't be received at all.


Then you can move on to step 3, followed by step 4 from my original reply (if sticking the CODA in bridge mode works, step #4 probably won't help).
The only ports being used are those defined by the local SIP port and the RTP port (if it's random, it's hard to forward, and I wouldn't want to forward a huge UDP port range for security reasons). RTP is for the audio stream, so the RTP port is the important one here. If RTP packets can't reach the ATA, you will not get audio. So you just want to start by forwarding the RTP Port. But port forwarding is a security risk, and if you had a good router to use (viewtopic.php?f=8&t=19515&p=76207#p76198), there would be no need to port forward. Unfortunately, you're using the CODA-4582 as a router instead.





You can also try another phone just to see whether there's a problem with the existing one.
Please do not send me emails; I do not work for nor represent Freephoneline or Fongo. Post questions on the forums so that others may learn from responses or assist you. Thank you. If you have an issue with your account or have a billing issue, submit a ticket here: https://support.fongo.com/hc/en-us/requests/new. Visit http://status.fongo.com/ to check FPL/Fongo service status. Freephoneline setup guides can be found at viewforum.php?f=15.
User avatar
Liptonbrisk
Technical Support
 
Posts: 2763
Joined: 04/26/2010
SIP Device Name: Obihai 202/2182, Groundwire
Firmware Version: various
ISP Name: FTTH
Computer OS: Windows 64 bit
Router: Asuswrt-Merlin & others

Re: No voice on incoming calls

Postby eugenem » 01/09/2019

Yes, correct SIP REGISTER Contact Header Use set to WAN. Tried to forward ports - still the same problem. I'll try to run router in bridged mode later and will update. Weird thing - this is not a new router , and it was working just fine before for almost year and a half....
eugenem
Just Passing Thru
 
Posts: 3
Joined: 01/07/2019
SIP Device Name: Grandstream HT701
Firmware Version: 1.0.10.3
ISP Name: Rogers
Computer OS: Windows 10
Router: Hitron CODA-4582

Re: No voice on incoming calls

Postby Liptonbrisk » 01/09/2019

eugenem wrote:Yes, correct SIP REGISTER Contact Header Use set to WAN. Tried to forward ports - still the same problem. I'll try to run router in bridged mode later and will update. Weird thing - this is not a new router , and it was working just fine before for almost year and a half....


If you forward the RTP port, it needs to not be set to random in the ATA.

Corrupted NAT associations in routers can develop without the user doing anything. Also, refer to #5 in my original response or point D in the second reply. Unfortunately, no Rogers modem/router combo or gateway allows users to adjust UDP timeouts. In fact, no ISP I know of issues modem/router combos or gateways that are truly suitable for SIP services.

What you're describing is more typically associated with a traditional NAT router/SIP ALG issue. The facts that SIP ALG is off, voip4.freephoneline.ca:6060 is being used, and that you've tried port forwarding RTP, strongly suggest it's not a buggy SIP ALG problem. From time to time Rogers does push new firmware to their devices. It's possible they've introduced a bug, but that's less likely than a corrupted NAT association developing on its own. Having the modem/router combo in bridge mode should eliminate whether something involving the router portion of the device is causing a problem. Remember to disconnect all other devices from the CODA-4582 and reboot the ATA after the CODA-4582 reboots.

If nothing changes in bridge mode, then the problem is more likely to reside between the ATA and the phone itself (try a different phone; check all phone cords). It's far more likely to involve something with the ATA at that point.

One way audio issues almost always involve the router, provided RTP packets are reaching it.
The first step is RTP packets must reach the router. If they're not, you need to figure out why.
Given that you claim you've had no issues in the past, chances are submitting a ticket and requesting a
"forced registration" will not help RTP packets reach the router. For those that have never had two-way audio with FPL, making that ticket request may help.
Chances are RTP packets are reaching the router, but you would need to do some form of packet inspection on your LAN in order to confirm because I doubt CODA-4582u
logs useful traffic for troubleshooting this type of issue. I don't have enough spare time to start tutorials on packet inspection, unfortunately.
The RTP packets should be coming from 208.65.240.1xx.

Then RTP stream/packets must reach the ATA. If they reach the router but not the ATA, the problem involves the router.
And I do think that's the most likely scenario. One way audio issues almost always involve a NAT or SIP ALG problem.
There are tons of examples where NAT corruption in a router develops without any intervention by the user.

Sometimes one-way audio could also be due an audio codec mismatch. Freephoneline only supports g711-u (uLAW) and g729: https://support.freephoneline.ca/hc/en- ... redentials.
I doubt a codec mismatch is the issue, provided you're testing from a regular mobility service (not VoIP) or a regular landline.

And then your ATA's phone jack needs to work and so does the phone and all cables attached to it.

If the problem is only occurring with a specific phone number, it could be a carrier issue. Also, ensure that you're testing with a regular, non-VoIP, cellphone or landline service for the incoming call because the problem can be on the other end.
Please do not send me emails; I do not work for nor represent Freephoneline or Fongo. Post questions on the forums so that others may learn from responses or assist you. Thank you. If you have an issue with your account or have a billing issue, submit a ticket here: https://support.fongo.com/hc/en-us/requests/new. Visit http://status.fongo.com/ to check FPL/Fongo service status. Freephoneline setup guides can be found at viewforum.php?f=15.
User avatar
Liptonbrisk
Technical Support
 
Posts: 2763
Joined: 04/26/2010
SIP Device Name: Obihai 202/2182, Groundwire
Firmware Version: various
ISP Name: FTTH
Computer OS: Windows 64 bit
Router: Asuswrt-Merlin & others


Return to Community Support

Who is online

Users browsing this forum: Google [Bot] and 27 guests