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

Otherwise, I don’t have any other suggestions at this time, particularly if nothing has changed except Rogers’ 5G gateway for working incoming calls.