[Freephonline won't work with Rogers 5G/CGNAT Home Internet] Nokia Fastmile 5G gateway 12

[Liptonbrisk]

"Server" parameter with x.y.w.z, and "Port" parameter ppppp – if different than default (514).
Note that ppppp must be in the range 1 - 65535.
Where do I get these parameters? Sorry I don't understand

Login to Obihai ATA. Navigate to System Management-->Device Admin-->Syslog

Server should be the LAN IP of the PC where you're going to run syslog. ex. 192.168.50.55 (you need to find the LAN IP of your PC).
In Windows, press the windows key, type cmd, hit Enter, then type ipconfig, and press Enter; your LAN IP is the IPv4 Address (e.g., 192.168.x.x).
Or go to Settings-> Network & Internet--> Properties (on your active Wi‑Fi/Ethernet)--> look for IPv4 address

Port can be the default, 514.

[domptg]

"Server" parameter with x.y.w.z, and "Port" parameter ppppp – if different than default (514).
Note that ppppp must be in the range 1 - 65535.
Where do I get these parameters? Sorry I don't understand

Login to Obihai ATA. Navigate to System Management-->Device Admin-->Syslog

Server should be the LAN IP of the PC where you're going to run syslog. ex. 192.168.50.55 (you need to find the LAN IP of your PC).
In Windows, press the windows key, type cmd, hit Enter, then type ipconfig, and press Enter; your LAN IP is the IPv4 Address (e.g., 192.168.x.x).
Or go to Settings-> Network & Internet--> Properties (on your active Wi‑Fi/Ethernet)--> look for IPv4 address

Port can be the default, 514.

Okay I did it. What should I do the next to get the logs? Sorry I never done it before.

[Liptonbrisk]

Okay I did it. What should I do the next to get the logs? Sorry I never done it before.

You need to follow the steps written here: viewtopic.php?p=80667#p80667

1) You need the syslogd executable

2) Enable logging of SIP Messages for the SP that's being used for Freephoneline.
From the OBi ATA's webUI, navigate to the SP1 Service (or SP2, SP3, or SP4 Service) setting that's being used for Freephoneline.
Change the "X_SipDebugOption" parameter to "Log All Messages."

3) From an elevated (admin) command/dos prompt where the syslogd.exe file is located, run "syslogd -nl -s=all" without the quotation marks.

Open the Start Menu: Click the Windows Start button or press the Windows key.
Type "cmd": This will initiate a search for the command prompt application.
Right-click Command Prompt: Locate "Command Prompt" or "Command Prompt (Admin)" in the search results.
You want Command Prompt (Admin).
Otherwise, right-click on it.
Run as administrator: Select "Run as administrator" from the context menu.
Confirm UAC prompt: if prompted by User Account Control (UAC), click "Yes" to allow the application to make changes.

You may not need an elevated command prompt. I can't remember. I always use one by default.

4) Reboot the ATA. Receive an incoming call. After the call ends, exit syslog. You should find a text file with the contents of the log.

The problem is if RTP packets are never received, and if everything is basically being dropped due to CGNAT, I doubt the log file is going to be terribly useful. It's not always easy to analyze what you can't see. "Oh hey, look: you're not receiving stuff you need to receive." I already knew that (unless you are receiving data and the ATA is borderline wrecked). It's possible something useful will be shown. I'm just a little skeptical.

[Liptonbrisk]

It's important to test whether there's voltage running through the phone jacks before plugging your ATA back into a phone jack that potentially has voltage running through it (that's dangerous for ATAs), and the lack of a change doesn't rule out whether the ATA has been damaged in some manner from voltage running through phone jacks. If possible, you might want to bring it to a home that has SIP ALG disabled and isn't using CGNAT to confirm.

One of the biggest time wasters, in my opinion, is troubleshooting damaged hardware. So, if possible, please try to rule that out. Absolutely do not plug in the ATA to existing phone jack wiring until you ensure there is no power going through it.

[Liptonbrisk]

I don't see evidence in your log that X_UsePublicAddressInVia is enabled. Seems weird that your ATA's LAN IP is being used in it. Is X_UsePublicAddressInVia enabled as I requested previously?

Seeing a private/LAN IP (e.g., 192.168.x.x) in the Via header means the ATA did not place its public/WAN IP in Via, which is exactly what X_UsePublicAddressInVia should have done if enabled. Enable it, and keep it enabled. That's in step 6f (in bold) from viewtopic.php?p=82562#p82562

Also I don't see any evidence of an incoming call--just keep-alive packets.

At least one header correctly has your WAN IP in it.

[domptg]

Very sorry I did enable X_UsePublicAddressInVia now. For some reason I did not save it before and was not changed.

[Liptonbrisk]

The log that was sent to me does not capture what happened when rebooting the ATA. There is no registration request. Also no call capture exists. All I see are keep-alive/Notify interactions, presumably ever 20 seconds (because I don't see time stamps).

run "syslogd -nl -s=all" (without the quotation marks)

Reboot/power cycle (off/on) ATA. Wait for successful registration.

Call your FPL number.

Try to answer the call with phone connected on the back, directly to ATA.

When the call ends, stop syslog (exit).

[domptg]

The log that was sent to me does not capture what happened when rebooting the ATA. There is no registration request. Also no call capture exists. All I see are keep-alive/Notify interactions, presumably ever 20 seconds (because I don't see time stamps).

run "syslogd -nl -s=all"

Reboot ATA.

Call your FPL number.

Try to answer the call.

When the call ends, stop syslog (exit).

What do I do wrong?

[Liptonbrisk]

What do I do wrong?

Rather, I did something wrong. I forgot to tell you to ensure syslog Level is set to 7 (debug) in the ATA.

1) Dial ***1. Enter the IP address you hear into a web browser. Login to your ATA's webui. Navigate to System Management-->Device Admin-->Syslog-->Level--> (uncheck the default box). There's a dropdown box. Change Level to 7. Then scroll down and click "submit".

2) Navigate to ITSP Profile (used for Freephoneline) -> SIP -> X_SipDebugOption. Ensure that's set to Log All Messages. Submit/save settings.

3) Enter "syslogd -nl -s=all" (without the quotation marks) at an elevated command prompt.

C:\>syslogd -nl -s=all (for example)


4) Reboot/power cycle (off/on) ATA. Wait for successful registration.

5) Call your FPL number.

6) Try to answer the call with a single phone connected on the back, directly to ATA's phone port. Do not connect the ATA to existing home, phone jacks on walls.

7) When the call ends, stop syslog (exit the dos/command window). A log text file should be in the folder path where syslogd.exe exists that contains the captured log. That text file is what you need. Alternatively, you can copy and paste the log entry as you did previously.

[Liptonbrisk]

Very sorry I did enable X_UsePublicAddressInVia now. For some reason I did not save it before and was not changed.

Oh, wait. Now do incoming calls work with a phone connected directly to the back of the ATA's phone port (let's avoid house phone jacks for now), after rebooting the ATA?

After rebooting the ATA ensure that X_UsePublicAddressInVia (Navigate to Service Providers-->ITSP Profile used for FreePhoneLine-->SIP) is still enabled for Freephoneline.

[domptg]

Can we go on Quick Assist so you can view my desktop on your PC? Let me know I'll send you PM with the code

[Liptonbrisk]

I balk at doing live tech support. I'm not being paid, and I don't work for Fongo. I try to help out when I can on the forums. This is best I can do, and I prefer that others can read here and interact/help (or potentially learn).

Did I explain something poorly, maybe? Should I provide a clearer explanation about something I stated?
Is there a step that I need to explain in more detail?

Regardless, if an OBi200's phone (FXS) port was ever tied into live PSTN house/home wiring, permanent damage is a real possibility, and a direct‑handset/phone test that still fails to connect after ringing does not mean the ATA isn't wrecked. Connecting your OBi200's phone port to your home's telephone jacks, which can still be energized by the phone company's line voltage, can cause permanent damage. Old phone lines carry idle power that can partially fry the internal component (SLIC) responsible for detecting when you pick up the phone. That possibility can explain why the phone rings but fails to connect the call when answered. The ATA itself could be wrecked and may need to be replaced, while the preventative measure for a new device would be to physically disconnect the outside phone line at the demarcation point before using in-home wiring.

Outbound calls working while inbound calls ring but fail to connect when answered can be an indicator that the ATA is partially fried.


--
A.I. analysis follows:



Here’s a breakdown of why this happens:

### Partial Damage vs. Complete Failure

Think of the ATA's phone port (the SLIC chip) not as a simple on/off switch, but as a component with several different jobs. A voltage spike from the telephone line doesn't always destroy the entire chip; it can damage one function while leaving others intact.

* **Outbound Calls (The Simpler Job):** When you pick up the phone to make a call, the ATA only needs to do one simple thing: detect that a circuit has been completed (this is called "loop current detection"). If this part of the chip is undamaged, you will get a dial tone and can make calls.

* **Inbound Calls (The More Complex Job):** This is a two-step process that is more delicate and involves higher voltages.
1. The ATA sends a high-voltage AC signal to make the phone ring.
2. When you answer, the ATA must **instantly stop the ringing voltage** and **simultaneously detect the switch to the off-hook state**. This "ring trip" function is a common point of failure.

It is very plausible that the part of the circuit responsible for the delicate ring trip process was damaged by the external voltage, while the more basic circuit for detecting an off-hook condition for outbound calls survived.

### The Two Possibilities: Hardware vs. Network

At this point, you have two equally likely culprits that produce the exact same symptoms:

1. **Damaged Hardware:** The ATA's phone port is partially fried, and the "ring trip" function is broken.
2. **Network Signaling Failure:** The ATA is working perfectly, but your router or internet service is blocking the final "ACK" signal that must arrive from the provider to confirm the call is answered. This is a very common problem with SIP (VoIP) traffic.

### The Definitive Test to Know for Sure

Since the symptoms are identical, you need a final test to tell the difference. The easiest way is to eliminate one of the variables.

**Test the ATA on a different network.** Take your OBi200 and a phone to a friend's house or your workplace [my edit: the other place should not also be using an internet service with CGNAT and also must not have SIP ALG enabled]. If the exact same problem happens there—outbound calls work, but inbound calls ring and fail to connect—you have **100% confirmed the ATA has a hardware fault** and needs to be replaced. If it works perfectly on another network, the problem lies with your home network configuration.
--

I've already stated that previously (take the ATA where SIP ALG and CG-NAT do not exist and test), but if you want A.I. confirmation, there it is.


There is a similar problem in another thread with outbound calls working and inbound calls not working--because the ATA is wrecked from being plugged into phone jacks that still have voltage from the telephone company running through them--which is a key piece of information that was not provided initially during the troubleshooting process: viewtopic.php?t=20370.

The possibility of the problem being a hardware issue makes observations about rings after setting changes appear coincidental, or a result of a slowly dying/partially wrecked ATA, rather than being a direct result of setting changes.

The other possibility is a combination of CGNAT/SIP ALG (in conjunction with not using the settings I mentioned in my initial reply in this thread), but I would try to rule out a wrecked ATA first.

[Liptonbrisk]

Also, I'm seeing "resolving root.pnn.obihai.com" frequently in the tiny log you sent. There is no reason for the ATA to attempt to reach or resolve root.pnn.obihai.com anymore. Obitalk service and Obihai are basically gone (although Poly 4xx series ATAs are being sold and are owned by HP; Poly 4xx series ATAs are the updated models to OBi2xx ATAs, except Poly 4xx ATAs do not support consumer Google Voice).

I recommend doing the following (but this has no bearing on your incoming call problem):

To ensure Obihai and a ITSP provider can't (or some third party), without your permission, update your device's
firmware remotely, you must do the following (all three steps).

1. Dial ***1, and enter the IP address you're told into your web browser

2. Navigate to System Management-->Auto Provisioning
a) For Auto Firmware Update ---> ensure method is disabled

b) For ITSP Provisioning ---> change method to disabled (uncheck default box)

c) For OBiTalk Provisioning--->change method to disabled (uncheck default box)
Keep in mind changes made in Obitalk.com web portal will no longer transfer to your device
after this change is made. Obitalk no longer works anyway.

(submit)

3. Navigate to Voice Services-->OBiTALK Service-->Obitalk service Settings

a) uncheck enable and uncheck the default box
You will not be able to call other Obihai devices using their respective Obitalk numbers after
disabling ObiTALK Service. Also the OBi Echo test will no longer work if you disable OBiTALK
Service. If you email or send a support request to Obihai, Obihai Support will note that your ATA
appears to be offline, and that they can’t make adjustments to help you.

Obitalk service no longer works anyway.

(submit/reboot)

--
Lastly, again, A.I. states, "You are correct to ask about inactive telephone line service scenarios. Here's the updated, accurate information specifically for Ontario, Canada:

**Voltage Levels That Can Cause Damage **

Standard Canadian POTS voltages that match exactly with your original figures:
- **−48V DC** (idle/on-hook) - Present constantly from central office battery
- **90-100V AC** (ringing voltage at ~20Hz) - Present during incoming calls
- **Up to 600V spikes** during lightning or fault conditions

**Critical Point About "No Active Service"**

Even with **no active telephone service**, the copper pairs at your demarc can still carry the full −48V DC battery voltage. This happens because:

- Telephone companies' central office equipment often leaves "battery" (−48V DC) connected to inactive pairs for testing and maintenance purposes
- Copper line retirement in Ontario is ongoing, but many pairs remain energized until physically disconnected at the central office
- The voltage exists whether or not there's dial tone or billing

**Likelihood of Damage Remains High (70-90%)**

The damage risk is the same regardless of active service status because:
- **FXS port damage**: The OBi200's phone port provides +30-52V DC; external −48V DC creates a voltage conflict
- **Ring detection circuit failure**: Any external AC voltage (even from testing/maintenance) can damage the internal ring-trip circuitry
- **SLIC component stress**: The subscriber line interface circuit isn't designed to handle reverse polarity or external voltages

**Your Symptoms Still Match Hardware Damage**

- Phone rings but won't connect when answered = classic ring-trip circuit failure
- Outbound calls work = basic off-hook detection still functional
- Intermittent behavior = partially damaged analog circuitry

The voltage figures are accurate for Ontario, and inactive service doesn't eliminate the damage risk—the copper pairs can still be energized with central office battery voltage.


### 1. Idle, Ringing & Surge Voltages
* North-American POTS (including Ontario) uses a nominal −48 V DC battery when the line is on-hook and super-imposes 90-100 V AC at ≈20 Hz for ringing. Lightning- or fault-induced surges can reach several-hundred volts. These figures line up with carrier specifications and field measurements.

### 2. Voltage on “Inactive” Lines
* A copper pair can stay tied to CO battery even after billing is removed: technicians need power for remote testing and it costs the carrier nothing to leave the battery connected. Community reports and telco procedure docs confirm that a supposedly “dead” line can still read −48 V DC until physically cut at the office or demarc.

### 3. Damage Mechanism for an OBi200
* The PHONE port is an FXS interface that **outputs** its own +30-52 V DC and 55-85 V AC ring. Feeding an external −48 V DC/90 V AC into that port forces two power sources to collide. Datasheets for the OBi200 (and for generic SLIC chips) warn that foreign voltage can over-stress the ring-trip and loop-current sense circuits, exactly the functions implicated by symptoms such as “rings but won’t connect”.

### 4. Symptoms Match Partial SLIC Failure
* Ringing heard, but no connection on answer, while outbound still works, is consistent with a damaged ring-trip stage: loop-current detection (needed for outbound) survives, ring-trip (needed for inbound) does not. That failure pattern is well documented in service notes and forums dealing with ATAs exposed to live PSTN voltage.

### 5. Risk Level Even Without Active Service
* Because the −48 V DC battery can remain on idle pairs, the likelihood of damage (an estimated 70-90% figure) is still high whenever the ATA is bridged onto house wiring that hasn’t been isolated at the demarc.
***


Again, the other possibility is a combination of CGNAT/SIP ALG (in conjunction with not using the settings I mentioned in my initial reply in this thread), but I would try to rule out a wrecked ATA first.

[domptg]

Performed some more testing with LinksysPAP2 ATA. This ATA was never connected to phone plug on the wall.
PAP2 ATA reacting exactly same way as Obi200. Phone rings but won't connect when answered and showing no line on my phone. Outbound calls work.
Hardware is not a issue then

[Liptonbrisk]

Hardware is not a issue then

Unless the Linksys ATA’s settings are not configured based on viewtopic.php?t=20532, specifically steps 12, 13, 14, 15, and 17, which should be followed

Otherwise, the cause is most likely not a hardware failure, yes.

While dealing with/troubleshooting this problem, if you have another number you can use, possibly forwarding to it might be useful: https://support.freephoneline.ca/hc/art ... -Follow-Me

Without a full syslog starting from ATA reboot and ending after an incoming call attempt (and even then, I doubt the log will be useful) I have no further suggestions for now, particularly if the only change since incoming calls last worked is the Rogers 5G gateway. I would not plug your ATAs into phone jacks until you can confirm their wiring has been disconnected from telephone company wiring at the demarc.

[domptg]

I'm planning to buy Poly IEEE 802.11ac Wi-Fi Adapter - USB for my Obi200 and see if this will help me with my incoming calls problem.

[Liptonbrisk]

I'm planning to buy Poly IEEE 802.11ac Wi-Fi Adapter - USB for my Obi200 and see if this will help me with my incoming calls problem.

If you mean the discontinued OBiWIfi adapter, I have one, and that's not going to solve your problem.
The only difference is your OBi200 will now be connecting using WiFi (which can increase latency) instead of an ethernet cable. The underlying problem still exists. Wi-Fi doesn't bypass CGNAT, SIP ALG, or a firewall. I'm pretty sure the problem is related to CGNAT.



Generally, CG‑NAT is an IPv4 address-sharing model that can impair multiple classes of applications, particularly those that benefit from stable inbound reachability. This can also affect inbound self-hosting and some online gaming scenarios, and Fongo Home and Freephoneline users aren't the only ones negatively affected.

Some people may respond with, “I’m on CG‑NAT, and it works for me” (in fact, I think I read that online somewhere while searching). However, impacts are workload-, timeout-, and CPE-dependent. RFC 7021 notes that varying combinations of home routers and client devices can produce reduced or variable user experience. Anecdotal counterexamples do not invalidate the general limitations described in the documents cited below, which I've provided in case others are interested.

I. Technical basis in standards

A. RFC 6888 states that because subscribers do not receive unique IPv4 addresses, Carrier-Grade NATs “introduce substantial limitations in communications between subscribers and with the rest of the Internet” (RFC 6888, https://datatracker.ietf.org/doc/html/rfc6888).

II. Documented impacts in multi-operator testing

A. RFC 7021 reports testing of NAT444 and Dual-Stack Lite impacts on common applications by CableLabs, Time Warner Cable, and Rogers Communications, and it identifies areas where adding a second layer of NAT disrupts common Internet applications (RFC 7021, https://www.rfc-editor.org/rfc/rfc7021.html).

B. RFC 7021’s scope includes peer-to-peer applications, online gaming, FTP, and SIP calls, which is relevant to both home hosting use cases and real-time communications (RFC 7021, https://www.rfc-editor.org/rfc/rfc7021.html).

III. Examples of user-facing problems that can follow from CG-NAT

A. VoIP and real-time communications

NAT traversal for UDP-based flows can be sensitive to mapping timeouts and address sharing, which can present as unreliable media paths, such as one-way or missing audio in some environments.

B. Home server hosting

RFC 7021 states that “FTP sessions to servers located inside the home (ex. behind two layers of NAT) failed," and that connectivity succeeded when the CGN was bypassed, which illustrates why inbound hosting and self-hosted services can be unreliable under CG-NAT/NAT444 (RFC 7021, https://www.rfc-editor.org/rfc/rfc7021.html).

C. Online and peer-to-peer gaming

RFC 7021 reports that “peer-to-peer gaming using Xbox . . . failed in both the NAT444 and Dual-Stack Lite environments”, and it describes a failure mode in which two users shared an outside IP address and attempted to connect to the same port (RFC 7021, https://www.rfc-editor.org/rfc/rfc7021.html).

The Xbox example from RFC 7021 isn't isolated. Similar NAT444/CG‑NAT constraints can also affect other gaming platforms (https://steamcommunity.com/app/1203620/ ... 695567175/), depending on the title’s networking model. The inability to forward or open ports may also prove challenging.

D. Shared-IP collateral effects

Cloudflare notes that because many users can share a single public IP under CG-NAT, IP-based security controls can inadvertently rate-limit or block legitimate users due to the behaviour of other users behind the same shared address (Cloudflare, https://blog.cloudflare.com/detecting-c ... al-damage/). Secondary reporting on Cloudflare’s work discusses similar collateral throttling effects for users behind CG-NAT (The Register, https://www.theregister.com/2025/11/03/ ... _research/).



It may be possible in some cases to mitigate CG-NAT limitations by obtaining a public (relatively static) IPv4 address, using IPv6 end-to-end where available (and it's not currently with Fongo Home Phone and Freephoneline), or tunnelling traffic through a VPN or VPS that provides public IPv4 egress. One general example of working around CG-NAT using a VPS and WireGuard is here (not specific to Fongo Home Phone): https://www.reddit.com/r/unRAID/comment ... nat_using/.

Basically,
1. rent a VPS with a public IPv4 address,
2. install WireGuard on the VPS,
3. set up WireGuard at home on a router or server, and
4. configure policy routing or split tunnelling so that only the HT-801 ATA routes through the WireGuard tunnel.

Again, that's just an example and may not work.

VPN and VPS configurations add cost and operational complexity and may also introduce increased latency and jitter. I will not be supporting VPN or VPS tunnelling configurations here, as supporting tunnelling runs outside the scope of these user-to-user forums (as does supporting other products and services than those offered by Fongo). Also, if the tunnel drops, then so does your Fongo Home Phone (or Freephoneline) service. Consequently, it's much simpler to say Rogers 5G Home Internet/w CG-NAT doesn't work with Fongo Home Phone and Freephoneline.

Personally, I try to avoid any internet service that forces CG-NAT upon me.