incoming calles

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

incoming calles

Postby zik » 11/14/2017

hi I have spa 2102 Linksys all was working fine for more than 5 years till one week ago incoming calls has no sound either way out going call work fine any idea ? no configuration was touched i r booted few time but the issue still there
zik
Quiet One
 
Posts: 38
Joined: 07/01/2009

Re: incoming calles

Postby Liptonbrisk » 11/15/2017

You've posted in the wrong forum. For future reference, Freephoneline forum can be found here: viewforum.php?f=8.

There are no current problems with FPL: http://status.fongo.com/.

1. What does the registration status in your ATA indicate?
Login to your ATA. Navigate to Voice-->Info-->Line (FPL)-->Registration State:

Registration is not required for outgoing calls. Only the correct SIP username and password are. Registration is required for incoming calls.

Your correct SIP username and password can be found after logging in at https://www.freephoneline.ca/showSipSettings.

2. The timers listed here are important:
https://support.freephoneline.ca/hc/en- ... redentials

a) Registration Interval: 3600 seconds (1 hour)

b) Registration Expiry: 3600 seconds (1 hour)

c) Failed Registration Re-Try Interval: 120 seconds


3. Click http://forums.redflagdeals.com/freephon ... #p26808549, and follow all the steps slowly and carefully. The instructions are the similar for your ATA.


i r booted few time


Proper device boot order is always Modem-->Router (wait for it to be fully up and running)-->ATA in that order
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: incoming calles

Postby zik » 11/15/2017

Thanks I'll try that when I get home
zik
Quiet One
 
Posts: 38
Joined: 07/01/2009

Re: incoming calles

Postby zik » 11/15/2017

Capture4.PNG
nothing worked this is my cofig incoming call ringes in but no voice on both side
Capture4.PNG (47.81 KiB) Viewed 13837 times
zik
Quiet One
 
Posts: 38
Joined: 07/01/2009

Re: incoming calles

Postby zik » 11/15/2017

Capture3.PNG
Capture3.PNG (56.14 KiB) Viewed 13837 times
zik
Quiet One
 
Posts: 38
Joined: 07/01/2009

Re: incoming calles

Postby zik » 11/15/2017

Capture2.PNG
Capture2.PNG (47.41 KiB) Viewed 13837 times
zik
Quiet One
 
Posts: 38
Joined: 07/01/2009

Re: incoming calles

Postby zik » 11/15/2017

Capture1.PNG
Capture1.PNG (60.89 KiB) Viewed 13837 times
zik
Quiet One
 
Posts: 38
Joined: 07/01/2009

Re: incoming calles

Postby zik » 11/15/2017

Capture.PNG
Capture.PNG (31.52 KiB) Viewed 13837 times
zik
Quiet One
 
Posts: 38
Joined: 07/01/2009

Re: incoming calles

Postby Liptonbrisk » 11/15/2017

What brand and model router are you using?

You haven't followed the instructions from 3 to 13 at the bottom of the post I linked to earlier.

A cursory glance at your settings suggests several things that could be addressed.
You should change SIP Port (should not be 5061). Your NAT Support Parameters should be changed.

Also, your Reg Retry Intvl should be 120 (under SIP Timer Values). That value is missing from the PDF guide.
That has nothing to do with your incoming call problem though.


I could go through everything, but I suggest a factory reset instead.
Then start here: viewtopic.php?f=15&t=16160#p63970. Check your settings against that guide.
Again, Reg Retry Intvl should be 120s (under SIP Timer Values).

Then after using the above linked guide, follow the steps below as well (especially steps 3 and 4).



What I'm quoting below also applies to your ATA.


"1.Before beginning the steps below make sure whatever modem/router combo your ISP gave you is in bridge mode if you are using your own router. Call/contact your ISP if you have to. For Bell Hubs, visit http://forums.redflagdeals.com/please-s ... r-1993629/

2. Disable DMZ and all port forwarding in your router. Port forwarding is a security risk.

(also, try a different phone; check all cables and cords)


3. In your ATA, Navigate to Line 1 (or whatever you're using for FPL)-->SIP settings, change SIP Port to a random number between 30000 and 60000.

4. In your ATA, 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

5. Retest
When I say Retest, retest always includes the following: A. Turn off both router and ATA. B. Turn on router. Wait for router to be fully up and transmitting data. C. Turn on ATA.

Then retest by calling your FPL phone number. If the problem is solved, don't continue.

6. If there are still problems, try disabling the SIP ALG feature in whatever router or modem/router combo it is that you're using:
http://www.obihai.com/faq/sip-alg/calling-out
I'm of the opinion Apple routers don't offer this feature, but you might as well check. If you manage to disable SIP ALG in the router, then retest.

DLINK router users may need to log into the admin page of their router, click the "Advanced" tab and then "Firewall Settings",
navigate to "Application Level Gateway (ALG) Configuration", and uncheck SIP: http://www.support.dlink.com/emulators/dir615_revC/310NA/adv_dmz.htm

If you received a modem/router combo, from your ISP ask your ISP. It is typically better to stick the modem/router combo from your ISP in bridge mode and use an external router.

See here for an example on how to disable SIP ALG in a router: http://www.obihai.com/faq/sip-alg/disable-alg

Image

Save settings.
Turn off both router and ATA. Turn on router. Wait for router to be fully up and transmitting data. Turn on ATA.
Then retest by calling your FPL phone number. If the problem is solved, don't continue.

7. Try Proxy voip4.freephoneline.ca:6060


Retest. When I say Retest, retest always includes the following: A. Turn off both router and ATA. B. Turn on router. Wait for router to be fully up and transmitting data. C. Turn on ATA.

Then retest by calling your FPL phone number. If the problem is solved, don't continue.

voip4.freephoneline.ca:6060 is a SIP server whose purpose is to help those with SIP ALG issues (can't disable it in the user's router, for example).



8. Retest. When I say Retest, retest always includes the following: A. Turn off both router and ATA. B. Turn on router. Wait for router to be fully up and transmitting data. C. Turn on ATA.

Then retest by calling your FPL phone number.

9. If none of that helps, then, unfortunately, you're pretty much stuck with port forwarding your RTP (UDP) port range 16384-16482 from your router to your ATA. For reference, that range can be found under SIP-->RTP Parameters-->RTP Port Min and RTP Port Max. You're going to want to double check those numbers in your ATA. RTP packets need to reach your ATA in order for you get incoming audio. Quite often, when the one way audio issue occurs, this is the problem. RTP packets are not reaching your ATA. Ideally, one should not have to port forward in order to achieve proper two-way audio, since port forwarding does create security issues. Port forwarding should only be done when everything else fails.

Refer to the port forwarding section of your router manual to learn how to port forward to your ATA. If a router was given to you by your ISP, call your ISP.

10. Retest. When I say Retest, retest always includes the following: A. Turn off both router and ATA. B. Turn on router. Wait for router to be fully up and transmitting data. C. Turn on ATA.


Then retest by calling your FPL phone number.


11. 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 < UDP Assured Timeout (in your router) < SIP Registration Failure Retry Wait Time (Reg Retry Intvl)

“<“ means less than.

A 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, NAT 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, third party firmware for Asus routers, does offer easy access to these two
settings, which are found under General–>Tools-->Other settings. In part, for this reason, I tend to use Asus routers
that work with Asuswrt-Merlin. 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 (Reg Retry Intvl setting in your ATA) is 120. I use 10 for UDP
Unreplied Timeout and 117 for UDP Assured Timeout.


12. If all else fails, open a support ticket at https://support.fongo.com/anonymous_requests/new. For the issue type, select VoIP Unlock Key–>My Account Inquiry. In addition to explaining your issue, request a “forced registration.”
If no responds to your support ticket, provide the ticket number in a private message to Fongo Support: http://forum.fongo.com/ucp.php?i=pm&mode=compose&u=7852

When I say Retest, retest always includes the following: A. Turn off both router and ATA. B. Turn on router. Wait for router to be fully up and transmitting data. C. Turn on ATA."


These steps don't mean you can try just one thing and stop. Go down the list in the order that they were presented.
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: incoming calles

Postby zik » 11/16/2017

thank you liptonbrisk for your time to help .....7. Try Proxy voip4.freephoneline.ca:6060 ...... this what solve my issue thanks a million
zik
Quiet One
 
Posts: 38
Joined: 07/01/2009

Re: incoming calles

Postby Liptonbrisk » 11/16/2017

zik wrote:thank you liptonbrisk for your time to help .....7. Try Proxy voip4.freephoneline.ca:6060 ...... this what solve my issue thanks a million


I'm glad your issue is resolved.


If you're interested, the purpose of voip4.freephoneline.ca:6060 is to circumvent faulty SIP ALG features in routers. SIP ALG monitors and alters packets passing through UDP port 5060, which is what proxy servers voip.freephoneline.ca and voip2.freephoneline.ca use. voip4.freephoneline.ca is using UDP port 6060.


"Typically it's far better to have your own router with strong QoS functions and a restricted (or port 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. These router combos issued by ISPs frequently have faulty (and hidden) SIP ALG/SPI features enabled with no way for the customer to disable them without getting a technical representative from his or her ISP to turn this feature off. Quite frequently, the first representative you speak to will have no idea how to accomplish this, much less know what SIP ALG is. Someone may try to enable DMZ in your modem/router combo or port forward; doing either is a huge security risk. Be aware if you reset your modem or when your ISP pushes a new firmware update to your modem/router combo, SIP ALG may be enabled again by default (and, therefore, it’s simply better to have your own router with SIP ALG disabled in it)."




To understand why SIP ALG often (but not in all routers; for example the SIP Passthrough feature in Asuswrt-Merlin works fine) causes horrible problems, please visit http://www.voip-info.org/wiki/view/Routers+SIP+ALG.

“SIP ALG problems
The main problem is the poor implementation at SIP protocol level of most commercial routers and the fact that this technology is just useful for outgoing calls, but not for incoming calls.

Lack of incoming calls
When a UA is switched on, it sends a REGISTER to the proxy in order to be localizable and receive incoming calls. This REGISTER is modified by the ALG feature (if not, the user wouldn't be reachable by the proxy since it indicated a private IP in REGISTER "Contact" header). Common routers just maintain the UDP "connection" open for a while (30-60 seconds) so after that time the port forwarding is ended, and incoming packets are discarded by the router. Many SIP proxies mantain the UDP keepalive by sending OPTIONS or NOTIFY messages to the UA, but they just do it when the UA has been detected as NATted during the registration. A SIP ALG router rewrites the REGISTER request so the proxy doesn't detect the NAT and doesn't maintain the keepalive (so incoming calls will be not possible).

Breaking SIP signalling
Many of the actual common routers with inbuilt SIP ALG modify SIP headers and the SDP body incorrectly, breaking SIP and making communication just impossible. Some of them do a whole replacing by searching a private address in all SIP headers and body and replace them with the router public mapped address (for example, replacing the private address if it appears in "Call-ID" header, which makes no sense at all). Many SIP ALG routers corrupt the SIP message when modifying it (i.e. missed semi-colon ";" in header parameters). Writing incorrect port values greater than 65536 is also common in many of these routers.

Disallows server side solutions
Even if you don't need a client side NAT solution (your SIP proxy gives you a server NAT solution), if your router has a SIP ALG function that is enabled and breaks SIP signalling, SIP ALG will make communication with your proxy impossible.”
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: No registered users and 18 guests