Nokia Fastmile 5G gateway 12

[domptg]

My Obi200 worked for few days on this modem/router and then stopped.
Obi200 connected by wire directly to LAN on Nokia Fastmile. I have green lights on obi200 and line is showing as registered. I tried everything inc. rebooting and port forwarding.

[Liptonbrisk]

Don't port forward unless all else fails first. If you’re going to do it, you need to port forward the RTP (UDP) port range 16660-16798 from your router (Nokia gateway) to your Obihai device. For reference, that range can be found in your ATA's webUI under ITSP Profile (used for Freephoneline)-->RTP. Then look at LocalPortMin and LocalPortMax. RTP packets need to reach your SIP device (OBi200) in order for you get incoming audio. RTP packets are not reaching your Obihai device. Port forwarding is a potential security risk. I am doubtful port forwarding is going to help you because I suspect the the problem is CGNAT.

Freephoneline uses UDP transport only.

Port forwarding generally does not work with carrier-grade NAT (CGNAT). CGNAT assigns private IP addresses to customer equipment and translates all inbound traffic at the network edge, preventing external devices from initiating connections directly to devices behind the NAT, which severely limits the ability to forward ports and host inbound services. Traditional port forwarding does not work with CGNAT. Carrier-Grade NAT (CGNAT) fundamentally breaks traditional port forwarding because your home router does not receive a unique public (WAN) IP address. Instead, multiple customers share a single public IP address.


So, what's the problem, exactly? No audio?

1. Do you get a delay with incoming calls for approximately 10 seconds before they are directed to Freephoneline's voicemail system? If so, the delay before calls are redirected to voicemail indicates the ATA is registered but fails to maintain an inbound path due to CGNAT-related, UDP port mapping timeouts.

Rogers’ own community support confirms that its 5G Home Internet service on the Nokia FastMile gateway runs over an IPv6-only core and uses 464XLAT to carry IPv4 traffic. If that's true, because there is no public-IPv4 address pool available to customer premises equipment, all IPv4 connections are NAT-translated at Rogers’ network edge—i.e. carrier-grade NAT (or CGNAT). CGNAT means you do not get a unique public (WAN) IP address; instead, you share one with other users. Some CGNAT implementations can interfere with the SIP protocol used by VoIP services, such as Freephoneline, making SIP signalling fail.

https://communityforums.rogers.com/t5/M ... rue#M11380

https://www.reddit.com/r/Rogers/comment ... _5g_modem/

Obi200 connected by wire directly to LAN on Nokia Fastmile

2. So your OBi200 is not connected to your T-LINK DECO M4, right?


Follow these steps, step by step, carefully down the list:

3. Pages 65 and 66 show a way to disable SIP ALG in the older Nokia Fastmile 5G 3.2 gateway (even if the UI is different in this model, the SIP ALG setting might be available): https://www.nokia.com/sites/default/fil ... -guide.pdf


a) Browse to 192.168.1.1.
b) Click Login.
c) Flip the device over.
d) Use the default Username and Password on the bottom of the Nokia Fast Mile Gateway to access settings.

e) From the main menu on the left side of the screen, click on Security.
f) In the sub-menu that appears, click on DMZ/ALG.

g) The Nokia Fastmile 5G 3.2 user guide states that the DMZ/ALG screen is where you can "configure Application-Level Gateway (ALG)". On this screen, you will find the toggle to disable SIP.

h) Disable SIP ALG, if the option to do so is available. If the option to disable SIP ALG isn't available, Rogers firmware likely hides the related menu from users. That doesn't mean SIP ALG is disabled. It could be on with no way for you to disable it. To understand why SIP ALG often causes horrible problems, please visit
https://www.voip-info.org/routers-sip-alg/ (scroll down to the section on SIP ALG problems).

i) Save changes if you were able to disable SIP ALG.

4. Now go to the phone attached to the OBi200. Dial ***1. Enter the IP address you hear into a web browser. Login. Default username and password is "admin" (without the quotation marks).

5. Navigate to Voice Services-->SP used for FPL Service-->X_UserAgentPort

a) X_UserAgentPort should be a random UDP port number between 30000 and 60000. Just pick a port number in that range (ex. 32887). If you already have a random number in that range, simply enter a new one in that range.
By using a high random port you help to thwart SIP scanners/hackers, and it may also help to circumvent SIP ALG.

Do not use the same X_UserAgentPort for any other SP. Pick a different X_UserAgentPort in the same range for other SPs if you're using other SIP services.

Never use UDP 5060 for X_UserAgentPort.

b) Save/Submit Changes


6. Navigate to Service Providers-->ITSP Profile used for FPL-->SIP->

a) change ProxyServer to voip4.freephoneline.ca
b) change ProxyServerPort to 6060

This can also help to circumvent SIP ALG.

c) Save/Submit changes.

d) Ensure RegistrationPeriod is 3600 seconds. GIven that your ATA is registered, I'm sure this is what the value is already.

e) Ensure X_DiscoverPublicAddress is enabled (it is by default)

f) Enable X_UsePublicAddressInVia (you will have to uncheck default box).

g) Submit/save changes


Absolutely ensure you've done this:

7. Navigate to Voice Services-->SP used for Freephoneline

i) X_KeepAliveEnable should be Checked/enabled
ii) X_KeepAliveExpires should be 20 seconds
iii) X_KeepAliveMsgType should be "notify"

submit/save settings


8. Reboot (or power cycle/power off and then on) Nokia 5G gateway. Double check to ensure SIP ALG is disabled afterwards, if you did manage to disable it. Wait for Nokia 5G gateway to be fully up and running first.

9. Then reboot OBi200.

10. Check that telephone cord is connected securely to the Obihai ATA.

11. Test with incoming calls.

If that doesn't work, I have no further suggestions except, perhaps, to request that your ISP remove you from CGNAT, if you're on it. If you are, they probably can't remove you from CGNAT, but I would ask anyway for potential options.

I try to avoid CGNAT as much as possible.




A. CGNAT should be avoided, if possible, for Freephoneline. I'm not 100% sure you are dealing with CGNAT, but it's plausible that you are. Contact your ISP. If the level 1 (first person you call) doesn't know what CGNAT is, ask for level 2 support (supervisors sometimes). Step 7 (above) is extremely important, but if following the above steps in the order presented don't work I don't have any other suggestions. Trying to connect the ATA to a VPN might work, if CGNAT is the problem, but I won't be supporting third party VPN services on these forums.

B. Try to have SIP ALG disabled in the modem/router combo device your ISP provides you (SIP ALG is a router feature). Contact your ISP if necessary. Even if the option to disable SIP ALG is not available to you, that does not necessarily mean that SIP ALG is not enabled in the device. The combination of steps 5 and 6 help to avoid SIP ALG, which can break SIP signalling in the event step 3 doesn't work (that is, if the option to disable SIP ALG isn't available). I would do steps 5 and 6, regardless.

[Liptonbrisk]

I chatted with a Rogers technical support rep.

"Yes, Rogers 5G Home Internet uses Carrier-grade NAT (CGNAT)." -- Rogers rep

While I don't trust what all reps tell me, again, it's plausible that CGNAT is being used. The rep's comments reinforced what I think.


Anyway, I suspect there are 3 factors contributing to the core problem:

1. Shared public IP (CGNAT)

Rogers 5G Home Internet service places your Nokia Fastmile 5G 12 behind Carrier-Grade NAT. This means you do not get a unique public IPv4 WAN IP; instead, you share one with other users.

2. Brief, dynamic port assignments

To manage the limited pool of 65,535 available ports on a single shared IP, the CGNAT system assigns ports to users dynamically and for very brief periods. When your device sends a UDP packet, the CGNAT opens a temporary pin-hole or NAT binding. If no traffic passes through this pin-hole for a short time (often 30-120 seconds), the CGNAT device closes it to reclaim the port for another user.



3. Long SIP registration expiry

Freephoneline's servers require your device to register with a 3600 second (1-hour) expiry time. This is a server-side rule to manage resources.


What Causes the Problem? Timer conflicts


There's a race between the long timer set by the SIP service provider (Freephoneline) and the short timer set by your ISP's network hardware.



If I'm right, here is the sequence of events that causes calls to fail:

a. Successful registration

Your OBi200 sends a REGISTER packet to Freephoneline. The Rogers CGNAT intercepts this, opens a temporary port (ex. PublicIP:12345), and forwards the packet. Freephoneline's server records that it can reach you at PublicIP:12345 for the next hour.

b. The idle period

You don't make or receive a call. No traffic passes through that specific NAT pin-hole.

c. The NAT timeout

After just 30 to 120 seconds of inactivity, the Rogers CGNAT device determines the connection is stale and closes the pin-hole (PublicIP:12345) to free up the port for another customer. Your path from the internet to your ATA is now gone, but Freephoneline's server doesn't know this yet.

d. (Inbound) Call Fails

Someone calls your number minutes later. Freephoneline's server sends the call (a SIP INVITE packet) to PublicIP:12345 as instructed. The packet arrives at Rogers' network edge, but the CGNAT device has no memory of that mapping, so the device has no idea where to send the traffic. It's simply discarded.

The result is that the call eventually fails over to Freephoneline's voicemail system. That's why sending a frequent keep-alive packet (every 20 seconds) is essential. The (keep-alive) notify packets constantly send traffic through the pin-hole, resetting the CGNAT's idle timer and forcing it to keep the port open for the full 3600-second registration period, theoretically.


Also, SIP ALG being on (with no way to disable it) may compound the problem as well by mangling SIP headers: https://www.voip-info.org/routers-sip-alg/ (scroll down to the section on SIP ALG problems), which is why steps 5 and 6 from the previous post are important.

If your ISP's implementation of CGNAT is blocking ports, then I don't have other suggestions besides what I mentioned previously (possibly connecting to the ATA to a VPN will work, but I'm not supporting VPNs here). I try to avoid CGNAT.

[domptg]

Thank you Liptonbrisk for all your help.
I did all suggested changes and the difference is that now if someone calling me after one signal the call is taken over by my voice mail. My phone doesn't ring at all.
Before the changes if someone called me I pickup the phone but nothing happens. My phone still rings and after 5 rings is taken over by voice mail.
Calling out seems okay.

[Liptonbrisk]

Have you checked to ensure that you have not accidentally enabled "Do Not Disturb"?

a) Click viewtopic.php?t=20534, and follow step 11.

Also, dialing *79 usually disables Do Not Disturb. Accidentally dialing *78 enables it, which you don't want.

Also, try dialing dialing *73 to disable unconditional call forwarding.

b) Login at https://www.freephoneline.ca/voicemailSettings
Ensure "Rings Before Voicemail" is greater than 1.

(I doubt these are the causes, but check anyway).

[Liptonbrisk]

c) Navigate to Voice Services-->SP (used for Freephoneline) Service-->X_InboundCallRoute

Copy and paste what you have for X_InboundCallRoute here.

I still suspect the issue is CGNAT (ISP), but you might as well check other things first.

[Liptonbrisk]

d) If you’re going to port forward, you need to port forward the RTP (UDP) port range 16660-16798 from your router (Nokia gateway) to your OBi200. For reference, that range can be found in your ATA's webUI under ITSP Profile (used for Freephoneline)-->RTP. Then look at LocalPortMin and LocalPortMax. RTP packets need to reach your SIP device (OBi200) in order for you get incoming audio. The RTP (UDP) port range is for the audio stream. Port forwarding is a potential security risk.

I am doubtful port forwarding is going to help you because I suspect the the problem is CGNAT, but possibly you can ask your ISP for port forwarding help.

[Liptonbrisk]

d) If you’re going to port forward, you need to port forward the RTP (UDP) port range 16660-16798 from your router (Nokia gateway) to your OBi200. For reference, that range can be found in your ATA's webUI under ITSP Profile (used for Freephoneline)-->RTP. Then look at LocalPortMin and LocalPortMax. RTP packets need to reach your SIP device (OBi200) in order for you get incoming audio. The RTP (UDP) port range is for the audio stream. Port forwarding is a potential security risk.

I am doubtful port forwarding is going to help you because I suspect the the problem is CGNAT, but possibly you can ask your ISP for port forwarding help.

If you discover that the only option that fixes this problem is to also port forward the port defined by X_UserAgentPort (UDP), I would be nervous. Anyone who gains access to that port can potentially gain access to your service or worse.

Anyway, for incoming calls, I suspect packets from Freephoneline get lost or blocked/dropped trying to navigate in through Rogers' CGNAT, in your case.

[domptg]

After talking to 8 Rogers agents and patiently explaining my phone voip connections problems. They finally decided to send me new modem which is Vantiva Cobra modem. Hopefully I have better luck with the new modem and my voip phone will work.

[Liptonbrisk]

It doesn’t seem to work with Ooma (at least it didn’t at default settings): https://communityforums.rogers.com/t5/M ... d-p/543692

Ooma also uses SIP protocol.

Rogers 5G home internet uses CGNAT, regardless of the modem/router combo they issue, as far as I know. So the underlying problem remains the same. I don’t know how to possibly escape CGNAT on Rogers 5G home internet without cancelling Rogers 5G home internet service, unfortunately.

I hope switching devices helps, but I’d be surprised. However, I think I heard about someone having success with the older Nokia Fastmile 3.2 model gateway, so maybe you have a chance.

[domptg]

It was me. I had Nokia Fastmile Gateway 3.2 the barrel one and voip was working with no issues. I cross my fingers that Vantiva is going to work as well. If not I might try to buy the Nokia 3.2 modem somewhere on Amazon or Bestbay.

[Liptonbrisk]

Oh, I see. I hope everything works out.

[domptg]

Oh, I see. I hope everything works out.

Few days now on Vantiva Cobra 5G modem. I would say is a little better, but doing same thing. Obi200 ATA connected to WAN/LAN port. When friend is calling my phone still rings when i pick up the line. My Obi200 doesn't recognize the call. Sometimes when I pickup quick enough I get connect it.
I talked to Rogers tech support for few times already and seems like some of them don't know anything and never heard about CGNAT. Some of them acting like I'm asking about something extra and say no. I don't know how to get to next tier of tech support and talk to more competent people.
I might do the complaint to Consumers Telecom Complaint Agency (CCTS), but this could be a waste of time.

[Liptonbrisk]

You can request to speak to level 2 support, which are supervisors. I used to do that all the time when I was with Rogers (not 5G Home internet) for Internet service. I would try speaking to their (non-wireless) Internet tech support reps, especially level 2.

I can’t easily confirm that Rogers 5G home internet is using CGNAT, but one of their reps told me that they are over chat, and if you go to Google.ca and search, “Does rogers use cgnat for its 5g home internet, which can affect sip protocol?”, the A.I. response is this:

“Yes, Rogers 5G Home Internet does utilize Carrier Grade NAT (CGNAT). This means that multiple users share a single public IP address, which can lead to issues with certain applications, including SIP (Session Initiation Protocol) used for Voice over IP (VoIP).


CGNAT Explained:
CGNAT is a networking technique where a large number of users are assigned private IP addresses within the provider's network, and these private addresses are translated to a smaller number of public IP addresses when communicating with the external internet.

SIP Protocol Impact:
SIP relies on direct communication between devices, and CGNAT can make it challenging for SIP traffic to traverse the network. Since multiple users share the same public IP, incoming SIP requests may not reach the correct device, leading to connection problems.

Rogers 5G Home Internet:
Rogers 5G Home Internet delivers internet service over the Rogers mobile network, and like many mobile networks, it uses CGNAT to manage its IP address space efficiently.

Potential Problems:
This can result in issues with VoIP calls, online gaming, and other applications that require a direct connection between your device and the outside world.”

Again, I don’t necessarily trust what random Rogers reps tell me or what A.I. tells me, but they’re both telling me that their 5G home internet service uses CGNAT.

I was also told you can’t get bridge mode using Rogers 5G home internet.

[Liptonbrisk]

Sometimes when I pickup quick enough I get connect it.

That's interesting. Have you tried a different phone? I also wonder whether the phone port on the OBi200 is dying.

You aren't connecting the OBi200 directly to phone jacks in your home, right?

My Obi200 doesn't recognize the call.

So, you don't see the incoming call at Status-->Call History in the ATA's webUI? If not, then it's not a phone or physical phone port problem.

If the ATA's phone port were failing, it should fail to provide a dial tone just as often as it fails to connect an inbound call. The physical action of lifting the handset is the same, and you stated outbound calls work fine earlier. I think the fact outbound calls work is likely to rule out physical hardware issues.

[Liptonbrisk]

I ran this problem through A.I. just now, and it's suggesting trying to send keep-alive packets more frequently than 20 seconds, which seems crazy to me because CGNAT port mappings should not be rewritten in less than 20 seconds.


i) X_KeepAliveEnable should be Checked/enabled
ii) X_KeepAliveExpires should be 20 seconds

Here A.I. is suggesting 15 seconds or 10 seconds.

iii) X_KeepAliveMsgType should be "notify"

A.I. says,

"Short answer: using keep-alives a bit faster than 20s can help in some mobile CGNATs, but it’s not guaranteed to fix this specific Freephoneline case. Typical CGNAT UDP idle timeouts are around 30–120s, with 30s being a common default, so 20s already provides a safety margin; dropping to 10–15s only makes sense if testing shows mappings still expire between pings or if ALG is interfering with the keep-alives themselves.

Details:
- Standards guidance: IETF recommends NATs keep UDP mappings at least 2 minutes, with 5+ minutes as a sensible default; shorter timers are allowed only for specific well-known ports. In practice, many implementations set much shorter timeouts than the recommendation, especially in carrier/mobile networks.

- Real-world carrier/mobile behavior: Documented NAT idle timeouts commonly sit at ~30s for UDP on large providers (e.g., Google Cloud NAT defaults to 30s for UDP), which motivates ≤20–25s application keep-alives to be safe. Community and engineering notes around cellular networks routinely cite 20–30s keep-alives as a conservative baseline; some mobile environments report 60–120s, but the safe heuristic remains “keep-alive < NAT idle timeout,” often realized as ~20–25s.

- Implication: If the CGNAT’s UDP idle timeout is 30s, a 20s keep-alive should be sufficient; reducing to 10–15s adds extra cushion but also increases chatter, and it won’t solve issues caused by SIP ALG corrupting packets or RTP path problems during answer/ACK, which occur after the INVITE is delivered.

Recommendation:
- It's reasonable to test keep-alives below 20s (e.g., 10–15s) if there’s evidence that the NAT mapping still dies between heartbeats or you suspect jitter/packet loss is causing missed keep-alives. Measure whether inbound calls become consistently answerable after the change.
- However, if ringing occurs but calls fail on answer, the failure is likely in the 200 OK/ACK or RTP setup phase (ALG/mapping asymmetry), not in the registration mapping; faster keep-alives won’t fix that class of problem.

Why this stance:
- 30s UDP mapping defaults are well-documented; 20s keep-alives are a standard conservative practice and often sufficient.
- Cellular providers do use short timeouts, but credible reports place them ≥30s for UDP; sub‑20s NAT expiries are atypical, though not impossible, and 20s was chosen historically to be safe across unknown NATs."



However, I think needing to send notify packets more frequently than 20 seconds is unlikely to resolve this issue, but there's nothing stopping you from testing 15 seconds and 10 seconds, I suppose.

[Liptonbrisk]

For what it's worth, A.I. also states the following:

"What’s happening
- Your ATA (OBi200) is registered and gets incoming calls, so the SIP INVITE reaches it. That’s why the phone rings.
- When you pick up, the call often fails to connect unless you answer very quickly.
- Outbound calls work fine.

Why this happens
- Rogers 5G Home Internet puts you behind CG-NAT (many customers share one public IP). That setup is fine for traffic you start (outbound), but it’s tricky for traffic coming in.
- The 5G gateway (Vantiva Cobra/Nokia Fastmile 5G gateway 12) might also run SIP ALG, a “helper” that rewrites SIP packets. In practice, it often breaks them.
- Result: The first signal (INVITE = “someone’s calling”) gets to your ATA, but when you answer, your ATA’s “200 OK” and the follow-up handshake or the RTP (audio) setup gets altered or lost by SIP ALG/NAT. The provider never sees a clean “answer,” so the call fails.
- If you answer immediately, it sometimes succeeds because the temporary NAT mappings are still intact and the ALG’s state hasn’t gone sideways yet.

Key terms (brief)
- SIP: The protocol that handles call setup/teardown (ring, answer, hang up).
- RTP: The audio stream after the call is established.
- CG-NAT: Carrier-grade NAT; many users share one public IP. Great for outbound, unreliable for unsolicited inbound.
- SIP ALG: A router feature that tries to “fix” SIP but often corrupts it.

Why it’s not your phone or ATA jack
- Hardware issues would also mess with outbound dialing or dial tone. You can call out fine.
- The “works only if answered quickly” timing points to network state/NAT behaviour, not a flaky handset switch.

What will actually fix it (most effective first)
1) Use a VPN for the ATA’s traffic (via a VPN-capable router or tunnel to a VPS). This hides SIP from the gateway so SIP ALG can’t rewrite anything and gives a stable public endpoint. This is the most reliable fix.
2) If possible, have Rogers disable SIP ALG on your line/CPE, or move to a plan with a real public IPv4/static IP (often business) or a different ISP without CG-NAT.
3) Keep current mitigations:
- Stay on voip4.freephoneline.ca:6060 and a high random X_UserAgentPort.
- Keep 20-second keep-alives (you already do). If testing shows timeouts are shorter, try 10–15 seconds, but don’t spam the provider.
- Ensure your ATA’s RTP port range is consistent with any local rules (won’t beat CG-NAT, but avoids local conflicts).

Bottom line
The ring proves the INVITE gets in. The failure on answer is almost certainly SIP ALG/CG-NAT breaking the 200 OK/ACK or RTP setup. Bypassing the gateway’s meddling with a VPN (or getting a real public IP) is the practical, durable solution."



I did mention VPNs previously, but it does seem ridiculous to me to have to use one, and again, I'm not supporting VPNs.

[domptg]

Sometimes when I pickup quick enough I get connect it.

That's interesting. Have you tried a different phone? I also wonder whether the phone port on the OBi200 is dying.

You aren't connecting the OBi200 directly to phone jacks in your home, right?

My Obi200 doesn't recognize the call.

So, you don't see the incoming call at Status-->Call History in the ATA's webUI? If not, then it's not a phone or physical phone port problem.

If the ATA's phone port were failing, it should fail to provide a dial tone just as often as it fails to connect an inbound call. The physical action of lifting the handset is the same, and you stated outbound calls work fine earlier. I think that is likely to rule out physical hardware issues.

Yes my ATA is connected to phone jacks in my home. Under the phone history I see only Ringing-Call Connected. I think I didn't tell you that when I pickup ( the other party phone still calling ) my phone is showing no line. I tried on different phone with same results.

[Liptonbrisk]

Yes my ATA is connected to phone jacks in my home.

Don’t connect an ATA to any phone jacks in a home without first disconnecting the telephone company’s wiring at the demarc. Electricity from the telephone company’s wiring can fry the ATA and could be the problem here.

https://www.voipmyhouse.com/#thesolution
"Don't plug the VoIP device into a line that is still connected to the telephone company. That might fry your VoIP device."

If there's power running through phone jack house wiring from the telephone company, you run the risk of frying your ATA, and that could explain the problem you're experiencing.

Try with a phone connected directly to the back of the ATA instead.

[Liptonbrisk]

A.I.'s response to what I just stated is as follows (FXS port means OBi200's phone port):


You've identified a **critical safety and troubleshooting issue** that could completely explain the symptoms described.

## The Electrical Hazard

Connecting an ATA to existing house phone wiring **without first disconnecting the telephone company's line at the demarc** is extremely dangerous because:

- **Telephone company voltage** (typically 48V DC, up to 90V AC during ringing) can **permanently damage** the ATA's FXS port
- This voltage can cause **intermittent failures** where the ATA appears to work but behaves erratically
- The symptoms described - "phone rings but ATA doesn't recognize the call pickup" - could be caused by **electrical interference** or **partial damage** to the ATA's analog circuitry

## Why This Could Explain the Problem

The user's specific symptoms match what you'd expect from **electrical interference or partial ATA damage**:

- **Phone rings** = Digital SIP signaling still works (not affected by analog port issues)
- **Fails to connect on answer** = The analog FXS port isn't properly detecting off-hook state due to electrical interference/damage
- **Sometimes works if answered quickly** = Intermittent electrical interference that varies with timing
- **Outbound calls work** = The digital-to-analog conversion for outbound works differently than inbound off-hook detection

## The Essential Test

Before any further network troubleshooting, the user should:

1. **Disconnect a phone from the wall jack**
2. **Connect it directly to the ATA's phone port**
3. **Test inbound calls with the direct connection**

If this **fixes the problem immediately**, then all the CG-NAT/SIP ALG analysis was chasing the wrong issue entirely.

## Safety First

The user should also:
- **Locate the telephone demarc** (usually outside where phone line enters the house)
- **Disconnect the incoming telephone company line** before using house wiring with the ATA

- **Consider the ATA potentially damaged** if it's been connected to live phone company wiring

This is an excellent catch - **electrical issues with house phone wiring** are a common but often overlooked cause of ATA problems that can completely mimic network connectivity issues."

Bold and underline emphasis are mine.

[Liptonbrisk]

A.I. changes its mind again (basically covering the two possibilities I've mentioned):

# Integrating both possibilities: SIP signaling/NAT issues and house-wiring voltage risk

Both categories can independently (or jointly) produce the “rings here, sometimes shows connected, caller still hears ringing/no line” behavior, so the diagnosis and fix should explicitly cover:

- Network/SIP path failures (CG‑NAT and/or SIP ALG on Rogers 5G gateways) that break the 200 OK/ACK exchange or early media.
- Analog side faults from backfeeding the OBi200’s FXS port into live house wiring (not isolated at the demarc), which can load or damage the FXS port and cause erratic off‑hook/ringing behavior.

## How each failure explains the symptoms

- SIP signaling/NAT failure:
- Classic pattern: callee “connects,” but caller keeps hearing ringback when the 200 OK from the ATA isn’t acknowledged (no ACK) or is misrouted/mangled by NAT/ALG, so the upstream switch never flips from ringing to connected; many PBX cases show 200 OK retransmits without ACK leading to ringback and drop around 30–32s.
- Root causes include SIP ALG rewriting SIP/SDP, NAT path asymmetry for the answer leg, or misrouted responses behind CG‑NAT.

- House wiring/FXS risk:
- An ATA’s PHONE port is an FXS interface designed to drive phones, not to be tied to an active telco line; backfeeding into house wiring that’s still connected at the demarc risks exposure to telco battery/ring voltage and can damage or confuse the FXS port, causing intermittent off‑hook detection and “no line” behavior.
- Even without live telco voltage, long/complex inside wiring, bridged devices, alarm panels, or excessive REN load can degrade the FXS loop and cause erratic behavior on answer.

## Triage: determine which (or both) applies

- Check CG‑NAT/public IP status:
- Compare the modem’s WAN IP to the public IP shown by an external check; mismatch (especially WAN in 100.64.0.0/10 or 10.0.0.0/8) indicates CG‑NAT, which can break inbound answer‑phase signaling unless mitigated.

- Verify SIP handshake:
- Capture signaling (pcap/syslog) during an inbound call; if the ATA sends 200 OK but never receives ACK (you’ll see repeated 200 OK retransmits), it’s the textbook NAT/ALG signaling failure producing “caller still hears ringing”.

- Isolate analog wiring:
- Temporarily disconnect the house wiring and plug a single corded phone directly into the OBi200’s PHONE port; if calls now answer cleanly, the issue is inside wiring/FXS loading or foreign voltage from the demarc.

## Concrete fixes that cover both angles

- If CG‑NAT and/or SIP ALG are in play:
- Disable SIP ALG on the gateway if possible; ALG is a known cause of missing ACK or mangled SDP during answer.
- If ALG can’t be disabled or CG‑NAT persists, route the ATA through a VPN/WireGuard tunnel to a stable public endpoint so SIP/SDP/ACK can’t be rewritten and NAT paths remain consistent.
- Keep using a non‑standard SIP port and alternate server as a heuristic, but recognize it may not fully prevent answer‑phase corruption.[

- If inside wiring/FXS is the issue (or to safely re‑use jacks):
- Open the demarc and physically disconnect the telco feed before backfeeding the ATA into house pairs to eliminate foreign voltage and protect the FXS port.
- Remove/bridge‑bypass alarm panels and half‑ringer/test modules, keep REN load within the ATA’s spec, and retest with minimal wiring; excessive load/length can destabilize ringing and off‑hook detection.

## Why the “connected here, still ringing there” symptom matters

That specific symptom is a strong indicator that the 200 OK/ACK handshake didn’t complete across the network—exactly the sort of failure caused by ALG/NAT rewriting or path asymmetry—leading the caller to continue hearing ringback while the callee endpoint shows connected. However, an impaired FXS port or miswired/loaded inside loop can also make local answer/off‑hook detection unreliable; isolating to a direct phone‑to‑ATA test separates the analog from the SIP layer cleanly.

In short: test both. Prove the SIP handshake with a capture (to catch broken ACK), and prove the analog side by isolating the house wiring. Fixes then target either (or both): disable/bypass SIP ALG and CG‑NAT on the network side, and fully isolate the demarc plus minimize REN/load on the analog side to protect and stabilize the OBi200’s FXS port

--

"## Short answer
Revision: the new detail that “sometimes it connects, but the caller still hears ringing” strongly points back to a SIP signaling/early media problem (200 OK/ACK/SDP or RTP cut‑through) rather than purely an analog/house‑wiring issue, although house wiring can still contribute.

## What “connected here, still ringing there” means
- If the ATA shows the call as connected but the remote party keeps hearing ringing, that typically happens when the 200 OK/SDP from the ATA isn’t received or acknowledged (no ACK) by the provider, or the provider doesn’t switch from ringback to connected audio because of signaling/RTP issues; this is a known SIP failure mode discussed in PBX communities where 200 OK and subsequent ACK get lost/mangled or race with 180/183 signaling.

- It can also occur when the call is “answered” locally (FXS side goes off‑hook) but the network dialog hasn’t been fully confirmed end‑to‑end, so the caller still gets ringback tone while the callee sees “connected”.

These scenarios align with:
- Lost or altered 200 OK/SDP or missing ACK (often due to ALG/NAT handling during answer). The PBX/provider side expects an ACK after 200 OK; if it doesn’t see it, it keeps the call in alerting state or drops it shortly after.
- Timing edge cases where 180 Ringing and 200 OK/SDP collide or are processed out of order by the upstream switch, leaving the remote side “ringing” despite local connect.

## Where house wiring still fits
- FXS/house‑wiring issues (live telco voltage on the inside wiring) can cause bad off‑hook detection and erratic analog behavior; best practice is to isolate the demarc and test with a phone directly on the ATA’s PHONE port. However, “remote still hears ringing after local shows connected” is more characteristic of a SIP dialog problem than analog voltage alone.

## Practical next steps (target the signaling path first)
- Capture signaling to confirm: look for ATA sending 200 OK and whether an ACK returns from the provider; repeated 200 OK retransmits without ACK is the classic signature.
- If the gateway has SIP ALG, disable it; ALG is known to rewrite SIP/SDP and break 200 OK/ACK sequences in exactly this way.
- If ALG cannot be disabled, route the ATA through a VPN/tunnel so SIP is not rewritten in transit; this stabilizes 200 OK/ACK and RTP setup.
- Keep using a non‑standard SIP port and the alternate server to reduce ALG heuristics, but recognize this may not fully prevent answer‑phase corruption.
- Separately, test the ATA with a phone directly connected (no house wiring) to rule out FXS off‑hook issues; then, only if clean, re‑introduce internal wiring after isolating the telco demarc to avoid foreign voltage on the ATA’s FXS port.

In summary: the “remote still hears ringing while local shows connected” is a hallmark of 200 OK/ACK or early‑media signaling not completing end‑to‑end—commonly caused by SIP ALG/NAT handling at answer time—so the diagnosis should be revised to prioritize SIP signaling integrity and ALG avoidance, while still sanity‑checking the analog side by testing the ATA directly off the house wiring first.

[Liptonbrisk]

Anyway, testing without using existing home/house phone jack wiring is simple enough. If that works, then you know where the problem lies.

If that doesn't work, and if you want to capture a syslog, you can follow the instructions here: viewtopic.php?p=80667#p80667

[domptg]

Okay I did connect my Obi directly to my phone , but no change. The calls still not getting thru. The incoming telephone comp line is disconnected properly so I'm pretty sure this is not the issue.

[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

[Liptonbrisk]

Okay I did connect my Obi directly to my phone , but no change.

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.

The calls still not getting thru. The incoming telephone comp line is disconnected properly so I'm pretty sure this is not the issue.

You can capture a syslog: viewtopic.php?p=80667#p80667
My only reluctance with doing that is that I doubt a syslog capture, where incoming packets are being dropped or not received due to CGNAT/NAT problems, is terribly useful, but it is a troubleshooting step. Then you could post it/upload it and private message me the link to it. I can take a look at it, but I can't promise I'll find anything useful.

The following are deal breakers for me with home internet service providers:

1) CGNAT and
2) being blocked from enabling bridge mode (or being blocked from gaining access to bridge mode or PPPoE passthrough)

But that's just me.