[Solved]LAN IP change/Cannet CGN3+OBi100+STUN=15 minute drop

[sincere]

Thanks for your patience. I thought the software FPL is different from the hard FPL. The fact that the soft phone can work on computer doesn't mean the hard phone with the ATA will work, right?

They should be connecting to the same servers (voip.freephoneline.ca or voip4.freephoneline.ca:6060). My experience has been, with one or two exceptions, that if the FPL desktop app works, an ATA should just as easily on the user's LAN. In fact, the FPL desktop app is generally used to test whether the service will work before the customer pays for a VoIP unlock key. Usually, the FPL desktop app is more difficult to get working properly because its SIP settings are less customizable than an ATA's.

When you use voip4.freephoneline.ca:6060 and make a test call to 416-342-9562 (http://thetestcall.blogspot.com/), can you hear anything? I'm wondering if the problem involves all phone calls or just a single number.

The software phone of FPLworks on computer, but it doesn't need my bought VOIP unlock key, so it works differently, I think.

Yes, I can call that number (416-342-9562 (http://thetestcall.blogspot.com/) ) and hear voices or my recording. But when I call my cell phone, I can't hear anything or when I get a call from others, I can't hear them though they can hear me.

[Liptonbrisk]

The software phone of FPLworks on computer, but it doesn't need my bought VOIP unlock key, so it works differently, I think.

They are the exact same service. The purpose of the VoIP unlock key is to allow you to configure the service on any device you want instead of being limited to a PC or Mac.

Yes, I can call that number (416-342-9562 (http://thetestcall.blogspot.com/) ) and hear voices or my recording. But when I call my cell phone, I can't hear anything or when I get a call from others, I can't hear them though they can hear me.

If you call 519-649-0844 do you hear the greeting from Shoppers Drug Mart?
If you call 1-800-465-2422 do hear the CIBC greeting?

Anyway, I would get in contact with Cannet to get your CGN3 in bridge mode to test further.

[sincere]

The software phone of FPLworks on computer, but it doesn't need my bought VOIP unlock key, so it works differently, I think.

They are the exact same service. The purpose of the VoIP unlock key is to allow you to configure the service on any device you want instead of being limited to a PC or Mac.

Yes, I can call that number (416-342-9562 (http://thetestcall.blogspot.com/) ) and hear voices or my recording. But when I call my cell phone, I can't hear anything or when I get a call from others, I can't hear them though they can hear me.

If you call 519-649-0844 do you hear the greeting from Shoppers Drug Mart?
If you call 1-800-465-2422 do hear the CIBC greeting?

Anyway, I would get in contact with Cannet to get your CGN3 in bridge mode to test further.

No, I can't hear either of the above SDM or CIBC when I call them, strange, though I can hear when I call that test number 416 3429562. Thanks.

[Liptonbrisk]

http://thetestcall.blogspot.com/ is using a SIP/VoIP service, whereas the other two aren't.

[sincere]

http://thetestcall.blogspot.com/ is using a SIP/VoIP service, whereas the other two aren't.

Then what is the difference? Strange I can hear the latter, not the previous 2.

[Liptonbrisk]

Other than getting your CGN3 into bridge mode, or, afterwards, port forwarding the RTP Port range to your ATA, I’m out of suggestions.

[Liptonbrisk]

I tried to bridge based on your that Roges link, but I couldn't even log onto the CGN modem's interface.

By the way, this begs the question how you managed to look for SIP ALG in it if you can't even log in.

tried your suggestion, but can't find "SIP ALG" under the "Basic" tab.

Anyway, it's time for you to contact Cannet and ask about disabling SIP ALG, in addition to enabling bridge mode, in their CGN3.

[sincere]

I tried to bridge based on your that Roges link, but I couldn't even log onto the CGN modem's interface.

By the way, this begs the questions how you managed to look for SIP ALG in it if you can't even log in.

tried your suggestion, but can't find "SIP ALG" under the "Basic" tab.

There is no choice in that tab for SIP ALG. I just did what your site gave me to disable the residential gateway, but then I can't even get into the modem interface.

[Liptonbrisk]

I just did what your site gave me to disable the residential gateway, but then I can't even get into the modem interface.

Does 192.168.100.1 work after enabling bridge mode?

192.168.0.1 is for accessing the device when gateway mode is enabled. The local IP of the device changes when it's put into bridge mode.

For reference, look at https://communityforums.rogers.com/t5/I ... 808#M25181
(I have no clue what firmware Cannet is using; it's definitely not the same firmware as Rogers because Rogers' users can now disable SIP ALG in their CGN3s).

But I do know at least one firmware version (possibly there is only one version) Cannet was using for CGN3 hides SIP ALG from the user. SIP ALG is forced on in gateway mode, which is undesirable.

Regardless, not being able to log in due to the local IP changing means that you've likely enabled bridge mode. After enabling bridge mode, connect the ATA directly to the modem and test, briefly. Keep in mind while the modem is in bridge mode you are not protected by a firewall. So test. And then switch back to gateway mode after testing. Or better still, if enabling bridge mode fixes the problem, keep the CGN3 in bridge mode, connect the CGN3 to your own router (disable SIP ALG in it if the problem returns), and connect your ATA to your router. Keep in mind that while in bridge mode, the CGN3's firewall is being bypassed. Your router has its own firewall, which can protect devices connected to it. But nothing connected directly to the CGN3 will be protected while it's in bridge mode.

It doesn't matter if you can't log in to your modem after enabling bridge mode, provided the modem is obtaining a WAN IP address and working fine.

If the incoming audio problem disappears while CGN3 is in bridge mode but returns when your router is connected, I will need to know the brand and model of your router.

[sincere]

Does 192.168.100.1 work after enabling bridge mode?

192.168.0.1 is for accessing the device when gateway mode is enabled. The local IP of the device changes when it's put into bridge mode.

It doesn't matter if you can't log in to your modem after enabling bridge mode, provided the modem is obtaining a WAN IP address and working fine.

If the incoming audio problem disappears while CGN3 is in bridge mode but returns when your router is connected, I will need to know the brand and model of your router.

Even the 192.168.100.1 doesn't work either.

I tried anohter time to bridge, but can't work out. The ATA was plugged to the modem before the bridging, but remains so after bridging, but the VOIP doesn't work. I have to reset the modem. Yes, still can't hear a caller. Seems the modem CGN3 may not allow me to hear the caller, nor have I received any feedback from the ISP. Ok, wasted too much time, and have to call it quit. Thanks.

[Liptonbrisk]

Even the 192.168.100.1 doesn't work either.

Okay, either Cannet is using firmware that doesn't allow the user to access the modem after bridging (I strongly suspect this is the case), or there's a different local IP address for you to use (need to ask Cannet).

I tried anohter time to bridge, but can't work out. The ATA was plugged to the modem before the bridging, but remains so after bridging, but the VOIP doesn't work. I have to reset the modem. Yes, still can't hear a caller. Seems the modem CGN3 may not allow me to hear the caller

It may not be an issue with the CGN3, in particular since you tested using bridge mode, but, unfortunately, I'm at a loss for the reason why this is happening. Also the fact that the FPL desktop app works fine for you makes me think the issue isn't with the CGN3.

I could try to look up how to port forward RTP ports for you using CGN3 (I would have to search for a manual online, and then read it, which won't be fun), but I'm not even sure RTP packets are reaching your CGN3 when using your ATA (making port forwarding from the router to the ATA pointless).

Bridge mode eliminates the possibility of a SIP ALG or firewall issue. All router features should be bypassed in bridge mode.

Your phone is fine. The ATA appears to work.

So, I'm left (the only other thing I can think of) with a problem involving SIP headers. Possibly, after migration, something new is being done at FPL's switch that's making malformed SIP headers from your ATA direct RTP traffic to the LAN IP (192.xxx.x.x or into outer space) of your ATA instead of your public WAN IP. If that's the case, I'm doubtful I can do anything. You'd have to hope FPL pays attention to your ticket.

You could try asking for further advice at https://www.dslreports.com/forum/voip since I'm out of ideas at the moment (other than trying a factory reset of the ATA and reconfiguring it).


The reason I find this situation puzzling is because there's another OBi100 Freephoneline user that's not having problems anymore, but I have no idea what ISP or router is being used: http://forum.fongo.com/viewtopic.php?f=8&t=19782#p77392.

[sincere]

Thanks. Why can I hear things when calling that machine number, but can't hear when calling a real business number?

It was ok several months ago, not sure what happened recent months. YOu mentioned FPL has server migration?

[Liptonbrisk]

Thanks. Why can I hear things when calling that machine number, but can't hear when calling a real business number?

If I knew the answer to this, I would be better able to troubleshoot your issue. However, the VoIP to PSTN calls may take a different route and travel through a PSTN gateway than the VoIP to VoIP call. The call routing may be different. The test call number is a VoIP number provided by Acrovoice. The Shoppers Drug Mart and CIBC phone numbers aren't. The one-way audio issue you're having calling PSTN and Mobility numbers only (and not with other VoIP/SIP services) is information you should include in your ticket to Freephoneline support.

I can’t come close to seeing what’s going on without a syslog at least (and probably a firewall log as well), so I’d just be guessing, and my having to parse them would eat up too much of my time. Again, you might want to ask at https://www.dslreports.com/forum/voip for further advice.

One cause of one-way audio issues might be a codec mismatch, but unless you changed codec settings in your ATA, that's unlikely.
While a call is taking place, if you navigate to status-->Call status-->Audio codec in your ATA, you'll be able to see the Audio codec being used during the call.
It should be G.711u.

In your ATA's call status information (during a call), you should also be able to see the RTP media server used by FPL, which is typically 208.85.218.146 or 208.85.218.147 with a random UDP port.
The Local RTP address should be the LAN IP of the ATA followed by a random UDP port number in the range that's defined by (navigating to ITSP Profile (FPL)--->RTP) LocalPortMin (16600) and LocalPortMax (16798).

So, RTP packets must travel from 208.85.218.146 or 208.85.218.147 (RTP packets are travelling through its UDP port) through the UDP port specified (random UDP port between LocalPortMin and LocalPortMax) to your ATA's local (LAN) IP address.

The audio path to you needs to be
1. Media server (WAN IP 208.85.218.14x)----->2. Your WAN IP Cannet public address--->3. CGN3 (path switches to LAN here, 192.168.0.1) ---->4. the LAN IP (192.168.x.x) of your ATA

If RTP audio from the media server (1) is being sent directly to the LAN IP of your ATA (4) instead of your public WAN IP (2), then RTP audio never gets the chance to reach your ATA at all. RTP packets would be sent to oblivion (the wrong address). You will not be able to reach your ATA from a library computer, for example, by typing 192.168.0.23 (or whatever the LAN IP is of your ATA) into a web browser. This problem (where the media server is trying to send packets to a local LAN IP address) might happen if SIP headers being produced are malformed. One potential cause is SIP ALG, but you're using voip4.freephoneline.ca:6060 and also a non-standard X_Useragentport (local sip port that is not 5060). SIP ALG in the CGN3 should be bypassed. SIP ALG monitors traffic on UDP port 5060 (and sometimes 5061 as well).

If RTP audio is reaching your CGN3, and if your CGN3 is blocking (due to its firewall) RTP packets to your ATA, then your ATA will never receive audio either. If the CGN3 is in bridge mode, the firewall isn't being used, and so the firewall shouldn't be a problem. In bridge mode, at least, in theory (unless Cannet's CGN3 firmware is a buggy mess), SIP ALG should also be disabled in bridge mode. You connected your ATA to the CGN3 while it was in bridge mode, and the problem persisted. So, I think I can rule out SIP ALG being the problem. I think I can also rule out the NAT firewall in the CGN3 as being the issue.

It was ok several months ago, not sure what happened recent months. YOu mentioned FPL has server migration?

Yes: the first sentence from http://forum.fongo.com/viewtopic.php?f= ... 702#p76878 mentions migration.
I don’t work for Fibernetics (the parent company of Freephoneline and Fongo), Freephoneline, or Fongo, so I am not privy to specific details.

Given the desktop app works on your computer, and although I'm uncertain the issue will be fixed, it might be worth factory resetting your ATA (https://www.obitalk.com/info/faq/Troubl ... tory-Reset step 2.) and re-configuring it: http://forum.fongo.com/viewtopic.php?f=15&t=16196. Don't forget this step if you do:
Navigate to Voice Services-->SP(number that you're using for FPL) Service-->X_UserAgentPort
Change this local SIP (UDP) port to something random between 30000 and 60000. Just pick a number in that range.

It does not make any sense to me that the desktop app works. The ATA should work provided the CGN3 is in the bridge mode, so performing a factory reset and re-configuring the ATA might help (retest with CGN3 in bridge mode afterwards).

Other FPL users with Obihai ATAs are not reporting problems to me that I haven’t been able to resolve.
I am unable to reproduce your issue.

I am out of further ideas at the moment.

[sincere]

I am out of further ideas at the moment.

As you deserve a detailed feedback after your so many suggestions, I spent several days and nights trying all means again and again, and accidently solved the problem for now at least, though not sure how long it will last as things seems to change often.

1) Contacted my ISP Cannet for the SIP AIG not showing and for why I can't put it in the bridge mode, but they didn't help.
2) Wrote to the FPL for your suggested "force registration", but never got a reply after so many days. I don't really understand what "force registration" means, though.
3) Tried the "bridge mode", but still can't even use the modem or have signal. Have to quit.
4) Tried to understand your "port forwarding", but still can't figure it out.
5) I try to reset the ATA, and did all from scratch again, and again. I tried to change some parameters. When two things were done, I accidently succeeded:

a) I used to set STUNEnable and set stunserver in the General setting as per another expert's adv, but now disabled it
b) Uncheck the X_DiscoverPublicAddress as you suggested.
After the combination of these two changes, things are back to normal, though I don't really understand why. Strange. If you know, can you make a reasonable guess or educate me what Stun Server is, and why need to disable X_DiscoverPublicAddress to hear the other side? What do they mean?

It tooks me so many days and even whole Friday night to this morning, like an experiment. Things are ok now. Thanks.

[Liptonbrisk]

If you know, can you make a reasonable guess or educate me what Stun Server is, and why need to disable X_DiscoverPublicAddress to hear the other side? What do they mean?

The purpose of STUN is to let your ATA, situated behind a NAT firewall, know what your WAN (public) IP address is (and port being used). X_DiscoverPublicAddress in an Obihai ATA, also attempts to discover the WAN IP and uses the WAN IP (and port it finds) in its SIP contact header. Using both STUN and X_DiscoverPublicAddress is redundant, provided they both work. X_DiscoverPublicAddress doesn't appear to be producing a proper SIP contact header with your CGN3 in gateway mode. Of the two options, using STUN is less desirable.

If using STUN worked then for some reason your ATA, when used in conjunction with Cannet's CGN3, is producing SIP headers that are malformed with the wrong IP address (probably the LAN IP), and so, the RTP audio stream was probably being sent to the ATA's (private) LAN IP address and not to the (public) WAN IP. Acrovoice's network (the VoIP number you called) may have been able to handle the malformed SIP headers properly anyway. It appears FPL's desktop app was able to discover and use your correct WAN IP address in its SIP headers.

The problem with using a STUN server is that it introduces an additional point of failure. That is, in the event the (third party) STUN server goes down, FPL won't work for you. For that reason, I almost never recommend using STUN; it should be used in a last ditch effort. In other words, STUN is a kludge. But in this case it was good idea that someone else suggested using it since there appears to be no other choice for you. As for why you're having to use STUN suddenly, I suspect the FPL server migration did change something at the switch (or there's something else occurring on your LAN or with your CGN3 that I'm not privy to).

Tried the "bridge mode", but still can't even use the modem or have signal. Have to quit.

Either you weren't able to properly enable bridge mode, or there's something very wrong with Cannet's CGN3 bridge mode. If the device is truly in bridge mode, it should be impossible for an Obihai ATA not to properly determine your WAN IP address and port. With respect to troubleshooting, that situation is misleading.


WIthout a syslog produced from the ATA and a firewall log (to see a lack of RTP packets reaching your CGN3), I would probably never to have been able to figure out what was going on.

Thank you for reporting back.

Contacted my ISP Cannet for the SIP AIG not showing and for why I can't put it in the bridge mode, but they didn't help.

Quite frankly, that would be enough to make me leave that ISP (obviously, I don't care if you choose to stay; I can only speak for myself). Someone there, who is competent, should know SIP ALG is on with no way for the customer to disable it in the CGN3 firmware you're using while the device is in gateway mode. And if they can't figure out how to put the device in bridge mode, that's inexcusable, in my opinion.

[sincere]

Thank you for reporting back.

Quite frankly, that would be enough to make me leave that ISP (obviously, I don't care if you choose to stay; I can only speak for myself). Someone there, who is competent, should know SIP ALG is on with no way for the customer to disable it in the CGN3 firmware you're using while the device is in gateway mode. And if they can't figure out how to put the device in bridge mode, that's inexcusable, in my opinion.

Thanks for your knowledgeable reply. The price of Cannet is good, only over $30/month, perhaps the best I can get. and I am ok with 75M download speed. If you have any other good ISP to recommend, I'd like to listen too. Now that I have solved the problem, perhaps ok to go with them, though their modem isn't the best.

[Liptonbrisk]

Thanks for your knowledgeable reply. The price of Cannet is good, only over $30/month, perhaps the best I can get. and I am ok with 75M download speed. If you have any other good ISP to recommend, I'd like to listen too. Now that I have solved the problem, perhaps ok to go with them, though their modem isn't the best.

If you’re happy with what you’re using, then that’s fine. I can only speak for myself, and I’ve already stated my opinion. My recommending specific ISPs probably wouldn’t be welcome here given Fongo appears to sell a residential internet service (which I’ve not had any experience with). Take care

[sincere]

If you’re happy with what you’re using, then that’s fine. I can only speak for myself, and I’ve already stated my opinion. My recommending specific ISPs probably wouldn’t be welcome here given Fongo appears to sell a residential internet service (which I’ve not had any experience with). Take care

A new problem, sir. My phone connection is cut off about every 15 minutes, why? That must have something to do with setting. Any idea? Thanks again.

[Liptonbrisk]

1) Are you using *67? Ensure you're not.

2) In your ATA, navigate to Voice Services-->SP(whatever you're using for FPL) Service-->
a)X_KeepAliveEnable should be checked (enabled)
b)X_KeepAliveExpires should be 20
c) X_KeepAliveMsgType should be STUN

3) Are you using voip4.freephoneline.ca:6060 for ProxyServer? If not, please ensure you are.

4) Ensure you're using the G.711u codec. While a call is taking place, if you navigate to status-->Call status-->Audio codec in your ATA, you'll be able to see the Audio codec being used during the call.
It should be G.711u.

5) Test again. Problem solved? Then don't do step 6.

6) Put your CGN3 in bridge mode. Test again. Re-enable gateway mode afterwards.

If none of that helps, then unfortunately, I am out of ideas. You can try asking for further advice at https://www.dslreports.com/forum/voip.

[sincere]

1) Are you using *76? Ensure you're not.

2) In your ATA, navigate to Voice Services-->SP(whatever you're using for FPL) Service-->
a)X_KeepAliveEnable should be checked (enabled)
b)X_KeepAliveExpires should be 20
c) X_KeepAliveMsgType should be STUN

3) Are you using voip4.freephoneline.ca:6060 for ProxyServer? If not, please ensure you are.

4) Ensure you're using the G.711u codec. While a call is taking place, if you navigate to status-->Call status-->Audio codec in your ATA, you'll be able to see the Audio codec being used during the call.
It should be G.711u.

5) Test again. Problem solved? Then don't do step 6.

6) Put your CGN3 in bridge mode. Test again. Re-enable gateway mode afterwards.

If none of that helps, then unfortunately, I am out of ideas. You can try asking for further advice at https://www.dslreports.com/forum/voip.

!) What is that *67? I don't understand. WHere can I find that *67 there? Tks.
2) a) Yes. b) What does 20 mean? Minutes? THen isn't it better to set it longer, say 60? c) Ok. I will try. I used keepalive as default before.
3) Yes.
4) Yes, though don't understand.
5) Trying
6) I couldn't set it in bridge mode before.
THanks.

[Liptonbrisk]

!) What is that *67? I don't understand. WHere can I find that *67 there? Tks.

https://www.obitalk.com/info/documents/ ... rCodes.pdf

Don't dial *67.

b) What does 20 mean? Minutes?

No, seconds

THen isn't it better to set it longer, say 60?

No, not for NAT keep-alive

https://support.freephoneline.ca/hc/en- ... /212430746
"Keep Alive Interval: 20 seconds"

I used keepalive as default before

You have STUN configured in your ATA.

[sincere]

!) What is that *67? I don't understand. WHere can I find that *67 there? Tks.

https://www.obitalk.com/info/documents/ ... rCodes.pdf

Don't dial *67.

b) What does 20 mean? Minutes?

No, seconds

THen isn't it better to set it longer, say 60?

No, not for NAT keep-alive

https://support.freephoneline.ca/hc/en- ... /212430746
"Keep Alive Interval: 20 seconds"

Increasing that is the worst thing you could do, especially for FPL.

I used keepalive as default before

You have STUN configured in your ATA.

No, I never dialed that *67.
Ok. The dafault for "Keep Alive Interval" was 15, now in fact, I wud increase it to 20
Yes, I set it to stun now, though what does it mean? I thought the original "keepalive" made more sense though.
Once again, just to confirm, in the General - SIP setting, I should leave the RegistrarServer and RegistrarServer Port both blank, right?
ProxyServer voip4.freephoneline.ca
ProxyServerPort 6060
ProxyServerTransport UDP
RegistrarServer (blank)
RegistrarServerPort (blank)

[Liptonbrisk]

Yes, I set it to stun now, though what does it mean? I thought the original "keepalive" made more sense though.

https://www.obitalk.com/info/documents/ ... nGuide.pdf (page 95)

"NAT Traversal Considerations

If the device sits behind a NAT (typically the case), it can discover the mapped external address corresponding to its local SIP contact address as seen by the server in one of the following ways:

[snip]

-From the response to a STUN binding request the device sent to a STUN server. This method is used by enabling X_KeepAliveEnable and setting the X_KeepAliveMsgType parameter to “stun”. In that case, the STUN server is taken from the X_KeepAliveServer parameter, if it is specified. Otherwise, the keep-alive messages are sent to the same server where a REGISTER request would be sent to. The latter is the most effective way of using STUN to discover the mapped external contact address.

The device always uses the mapped external contact address in all outbound SIP requests instead of its local contact address if one is discovered by [the] method discovered above"

If you need further information, I suggest asking someone else because I simply don't have the time: https://www.dslreports.com/forum/voip.

Once again, just to confirm, in the General - SIP setting, I should leave the RegistrarServer and RegistrarServer Port both blank, right?
ProxyServer voip4.freephoneline.ca
ProxyServerPort 6060
ProxyServerTransport UDP
RegistrarServer (blank)

yes

Outboundproxy should be blank as well.

I'm not sure why you're asking this. You should be using this PDF guide that I've told you to use previously: http://forum.fongo.com/download/file.php?id=1704.
It also indicates X_KeepAliveExpires should be 20.
However, it's missing that Service Providers-->ITSP Profile (FPL)-->SIP-->RegisterRetryInterval should be 120 seconds

[sincere]

Yes, it seems ok now. Thanks.

[Liptonbrisk]

Thank you for letting me know.