Very disappointed about FPL service

[fpl123]

I got my config file back in Nov, it worked fine for me with my Linksys PAP2 until yesterday (or probably 2 days ago). In my pap2, it shows "cannot login to server".

I didn't realize it until this morning. (we have 3 lines at home, one from Teksavvy, one from vbuzzer and one from FPL. vbuzzer and FPL are VOIP so they share the pap2, teksavvy line is a regular non-voip line, that is why I didn't realize the problem until this morning).

So, I called FPL in the morning, I was told that FPL had some issues a few days back, I was asked to retype in all my information in pap2, the problem should be gone. Well it didn't.

Then, I called again, second CSR told me to reboot everything (modem/router/pap2), which I already did many many times, so i did it one more time... no go.

I thought I should gave it some time, so I went to work and when I came back home at 6pm, still no go, no dial tone. Then, I called 3rd time around 7:20pm, spoke to another CSR, he was very nice to me, worked me through the config etc, and rebooted pap2, still same thing. Then he said he couldn't see my device on his side, and he concluded that the problem is on my side, and told me there is nothing he could do. I told him that the vbuzzer line on the same pap2 works, so he suggested to switch the config with vbuzzer and see if it works. So i hung up with him and gave it a try. Same result. vbuzzer works on both lines, but FPL won't work on both lines.

OK, I firmly believe that the problem is at FPL, I called in 4th time around 8:30pm. After I confirmed with the fourth CSR, I was told I couldn't get any support from FPL because I am using my own device (pap2), and I didn't use FPL's device. WTF? I wanted to talk to a different CSR, tried 2 more times, unfortunately, I always got him, same person!

So am I stuck? What I do?

Please help, FPL!

[FONGO_steve]

We are not experiencing any sort of service interruptions on the day(s) referenced in your post.

As a provider, we are responsible for ensuring that we are delivering service but we can not be responsible for any device or network configurations on the user side which may interfere with their ability to receive the service. It was actually very kind of our rep to help you configure your PAP2T as we aren't obligated to provide any support for third party hardware (unless the PAP was bought directly from us).

I'll leave it open to the community here to provide some further troubleshooting on your setup. Off the top of my head I'd suggest trying with the PAP2 connected directly to your modem - more often than not it's something with the router blocking or filtering the SIP traffic.

[Jake]

Something I would try is to download a free softphone and plug my details into that and see if I am able to connect. Not the FPL softphone, although that probably would be worth doing as well, but something like x-lite. This will double check to see if your settings are all working or not. If you go to the sip details page on your FPL admin pages you should see the agent you are logged in with which can help fault finding.

Another thing to try would be to ask a friend to put your details into his ATA and see if they can connect.

Ping voip.freephoneline.ca and see if you get something like this

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.

C:\Users\Jake>ping voip.freephoneline.ca

Pinging voip.freephoneline.ca [208.65.240.165] with 32 bytes of data:
Reply from 208.65.240.165: bytes=32 time=19ms TTL=61
Reply from 208.65.240.165: bytes=32 time=17ms TTL=61
Reply from 208.65.240.165: bytes=32 time=18ms TTL=61
Reply from 208.65.240.165: bytes=32 time=18ms TTL=61

Ping statistics for 208.65.240.165:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 17ms, Maximum = 19ms, Average = 18ms

C:\Users\Jake>

That will tell you if you can actual see the voip server from where you are.

When you power cycle the modem/router/ata make sure it is powered down for a good 20 minutes. I know it is a pain but sometimes the wait can flush any gremlins waiting in the pipes.

[fpl123]

Yes, I can ping:

Code: Select all

Microsoft Windows [Version 6.1.7600]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

C:\Users\default>ping voip.freephoneline.ca

Pinging voip.freephoneline.ca [208.65.240.165] with 32 bytes of data:
Reply from 208.65.240.165: bytes=32 time=95ms TTL=58
Reply from 208.65.240.165: bytes=32 time=156ms TTL=58
Reply from 208.65.240.165: bytes=32 time=184ms TTL=58
Reply from 208.65.240.165: bytes=32 time=222ms TTL=58

Ping statistics for 208.65.240.165:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 95ms, Maximum = 222ms, Average = 164ms

C:\Users\defaut>

I firmly believed that the problem is on FPL side, because pap2 has two lines, I have one line configured to vbuzzer, and it works for vbuzzer on any line of my pap2.

I will give the softphone a try

[dibsmft]

Vbuzzer uses port 80 UDP (non standard but often not blocked because of it connection to port 80 TCP used for the internet and browsing). Fongo uses the sip standard 5060 UDP for sip and that is probably what is not getting through you NAT to the ATA .... that is what port forwarding looks after.
Your ping times look like mine so I guess you may be quite a long way from TO.

[fpl123]

Tried x-lite 4.0, it works. Now what i do?

I did not have port forwarding configured before and it worked before.

Anyway, I manually set to forward 5060 (TCP/UDP) to my pap2, still the same.

tried another pap2 (I have 3 at home), it doesn't work either. So the problem is not pap2 I am using, also router should work because x-lite works. So what else?

thanks

[fpl123]

also port forwarding shouldn't be required because I enabled NAT mapping and keep alive on my FPL line

[bridonca]

You need a good router with stable firmware to get stable SIP VOIP over NAT. (Any router that can be flashed to DD-WRT is strongly recommended) I would guess half the routers out there do not fit that criteria. A good Internet connection is also needed.

To get a stable connection, you need to forward RTP port(s) the ATA has set up from you router to the ATA. The SIP port does not need to be forwarded. Keep alives are not standardized, and thus can be flaky, especially with a crappy router.

[fpl123]

No, I don't have crappy router, it is Netgear WNDR3700, with latest firmware. What are the RTP port(s)?

[dibsmft]

"ried another pap2 (I have 3 at home), it doesn't work either. So the problem is not pap2 I am using, also router should work because x-lite works."
That proves that either the second PAP2 does not work (or both) or the results that you observed with the first PAP2 were correct. If you don't
want to forward ports and configure the PAP2 then try running STUN ( using and stun server eg. stun.ideasip.com ) it may solve the problem.
Your router should be OK as you say that it worked earlier.

[fpl123]

Problem solved!!!
need to "Disable SIP ALG " on my router. it was enabled before and no problem with FPL, now I have to disable it. Must be some changes from FPL (fongo?) broke it, now I have to disable it.

Thanks everyone for helping me out!

[dibsmft]

If you had told us your router model at the start we could probably have told you that. The SIP ALG problem is
well known and been around for quite a while. The original intention was that sip alg should make it easy
to set up SIP services but exactly the opposite happened due to poor implementation on many routers. Sip alg
apparently works OK on some of the more recent routers.
Turning off sip alg may still not cure your problem in the long term unless you have correctly forwarded ports
and configured the ATA (and I speak from experience).

[fpl123]

Thanks dibsmft!

If you had told us your router model at the start we could probably have told you that. The SIP ALG problem is
well known and been around for quite a while. The original intention was that sip alg should make it easy
to set up SIP services but exactly the opposite happened due to poor implementation on many routers. Sip alg
apparently works OK on some of the more recent routers.
Turning off sip alg may still not cure your problem in the long term unless you have correctly forwarded ports
and configured the ATA (and I speak from experience).

[TheHardy]

Tried x-lite 4.0, it works. Now what i do?

THAT being the case, it is most definitely NOT an FPL problem.... you have proven that outright. The error exists SOMEWHERE in your configuration, unfortunately. I don't have an ATA setup, so I cannot be of further assistance. Likely, neither can FPL/Fongo customer service. Hopefully a forum member has the answer for you!!

[TheHardy]

Problem solved!!!
need to "Disable SIP ALG " on my router. it was enabled before and no problem with FPL, now I have to disable it. Must be some changes from FPL (fongo?) broke it, now I have to disable it.

Thanks everyone for helping me out!

User-side config error. I do not think that FPL/Fongo changed anything WRT this.

[dibsmft]

I don't think one should blame the user here. The blame could more fairly go to the router manufacturers that included SIP ALG in their firmware, it would seem, without sufficient testing and did not seem in a hurry to fix the problems. I some cases it is not even possible to turn off SIP ALG so the router is very difficult to get working with SIP. There is some information here
http://www.voip-info.org/wiki/view/Routers+SIP+ALG

[TheHardy]

I don't think one should blame the user here. The blame could more fairly go to the router manufacturers that included SIP ALG in their firmware, it would seem, without sufficient testing and did not seem in a hurry to fix the problems. I some cases it is not even possible to turn off SIP ALG so the router is very difficult to get working with SIP. There is some information here
http://www.voip-info.org/wiki/view/Routers+SIP+ALG

Fair enough -- Not an ATA owner. Bad firmware/router is not a Fongo/FPL problem either though. Maybe a more correct statement on my point would have been "User-side error" rather than adding CONFIGURATION to it ... as that would cover USER SUPPLIED hardware.

In any case, I think we are in agreement that FPL/Fongo is not the culprit for BREAKING service here.

THAT is the point I was attempting to make -- the thread title seems to lay the blame at the feet of FPL, and THAT is unfair in this case! Agreed on that point?