FXO Gateway Pilot — Analog FTTH Line → Cloud Asterisk¶

What this solves¶

Convert an existing analog telephone line (typically delivered on the FXS/RJ-11 port of an FTTH ONT) into a SIP endpoint on the Astradial cloud Asterisk. The customer's existing number — provided by their ISP via the FTTH service — becomes a SIP-routable DID without the ISP needing to change anything.

This is for customers where:

• The ISP delivers voice over the analog port of the ONT (no SIP credentials available, or asking for them was refused).
• The customer wants their phone number bridged into a PBX / IVR / queue on our platform.
• Tata or another upstream trunk is not the source — the source is whatever carrier their FTTH ISP fronts.

Hardware¶

Network topology¶

Stage 1 — Pilot (single site, learning)¶

Customer site                                  Internet                 Cloud
─────────────────────────                      ────────                 ──────────────────

ISP fiber ─→ ONT  (RJ-11 FXS, gives dial tone)                          
              │                                                         
              ▼ RJ-11                                                   
            HT813                                                       
              │ FXO port: takes the ONT line, presents as SIP           
              │                                                         
              │ Ethernet                                                
              ▼                                                          ↓
            Site LAN router ────── SIP/UDP 5060 ───► 89.116.31.109:5060
                                                       │
                                                       ▼
                                                     Cloud Asterisk
                                                       endpoint: ht813_<site>
                                                       context: from-customer-<org>

Auth in Stage 1: per-endpoint username + secret (cheaper than TLS to set up, secure enough with fail2ban + a non-trivial password). SIP over UDP. Public internet, but fail2ban (already running) blocks brute-force attempts.

Stage 2 — Production (after pilot works)¶

Move signalling and media inside a per-site WireGuard tunnel, same model as the NUC:

Site LAN ── WG tunnel ──► Cloud WG endpoint (10.10.10.X)
                                              │
                                              ▼ inside the tunnel
                                            Cloud Asterisk

Pros: SIP/RTP no longer touches the public internet, harder to attack, no SBC/fail2ban exposure for these endpoints. Cons: each site needs a WG client — either on the customer's router (if they're cooperative), or on a tiny Pi sitting next to the HT813 doing WG → bridge to the HT813's SIP.

Defer Stage 2 until Stage 1 is verified.

Cloud Asterisk configuration (manual, until multi-carrier admin UI lands)¶

PJSIP endpoint (one per HT813 device, not per site)¶

File: /etc/asterisk/pjsip_<org_prefix>.conf — generated by configDeploymentService per-org.

[ht813_<site_name>]
type=endpoint
transport=transport-udp
context=from-customer-<org_prefix>
disallow=all
allow=alaw
allow=ulaw
aors=ht813_<site_name>_aor
auth=ht813_<site_name>_auth
direct_media=no
rtp_symmetric=yes
rewrite_contact=yes
force_rport=yes

[ht813_<site_name>_aor]
type=aor
max_contacts=1
qualify_frequency=60

[ht813_<site_name>_auth]
type=auth
auth_type=userpass
username=ht813_<site_name>
password=<generated 32-char random>

force_rport + rewrite_contact + rtp_symmetric are mandatory because the HT813 will be behind NAT (its public IP changes / it sees a private IP locally, but Asterisk needs to send media back to whatever public IP:port the registration actually came from).

Dialplan — inbound (call lands on Asterisk from the FXO line)¶

In from-customer-<org_prefix>:

[from-customer-<org_prefix>]
exten => _X.,1,NoOp(FXO inbound from HT813: ${EXTEN} CID ${CALLERID(all)})
 same => n,Set(__CALLED_DID=<org's ISP DID, configured per device>)
 same => n,Goto(<org_prefix>_incoming,${CALLED_DID},1)

The HT813 sends ${EXTEN} as whatever the phone dialed — but on an inbound FXO call, the caller didn't dial anything; the line just rang. We set the called DID statically per device.

Dialplan — outbound (org's extension dials a PSTN number, routed via FXO)¶

Outbound through the FXO is only worth doing if the ISP charges per minute for incoming-only and the FTTH calls are free/cheap. Most pilots will route outbound via the existing Tata trunk (more reliable, billed). Add FXO outbound only on explicit request.

If needed:

exten => _X.,1,Dial(PJSIP/${EXTEN}@ht813_<site_name>,60)

The HT813's dialplan template needs Dial Plan = { x+ } or similar so the FXO seizes the line and dials.

HT813 device configuration¶

Provisioning will eventually be automated via a config server. For the pilot, manual via the HT813 web UI (default 192.168.2.1, admin/admin).

Key settings (FXO Port tab — the side facing the ONT):

FXS port (the side facing an optional local handset): same auth pattern, separate SIP user ht813_<site_name>_fxs. Routes calls through cloud just like a normal extension would.

Pilot rollout checklist¶

• [ ] HT813 in hand.
• [ ] Confirm with the pilot site they have: working FTTH analog line on ONT, free RJ-11 port, ethernet port near the ONT, 12V power.
• [ ] Confirm with the ISP: does the line tolerate an FXO device? (Some ISPs deliver via a softswitch that gets confused by extra DTMF, off-hook timing, etc. Rare but documented.)
• [ ] Generate auth credentials for the device. Store in pgpass / vault / however we manage secrets today.
• [ ] Add the PJSIP block manually to /etc/asterisk/pjsip_<org>.conf on cloud + dialplan reload + module reload res_pjsip.so. (Once multi-carrier admin UI lands, this becomes a form fill — see #230.)
• [ ] Install HT813 at the site. Connect cables. Configure via web UI.
• [ ] Smoke tests:
• [ ] HT813's "Account Status" page shows Registered against the cloud.
• [ ] On cloud: pjsip show endpoint ht813_<site> → Avail, contact present.
• [ ] Call the ISP-provided number from a mobile → should ring whatever the cloud dialplan routes to.
• [ ] From the optional analog handset on FXS, dial an extension → reaches the cloud.
• [ ] Hang-up detection works (no zombie channels in core show channels after hangup).
• [ ] Two-way audio (talk both directions, no one-way audio bug — usually a NAT/RTP fix if it breaks).
• [ ] Document any ISP-specific quirks (echo, DTMF dropping, hangup detection timeout) on this page.

Known pitfalls (read before pilot)¶

1. NAT / one-way audio. The HT813 will be behind a customer's router doing NAT. rtp_symmetric=yes, force_rport=yes, and rewrite_contact=yes on the PJSIP endpoint cover the common cases. If audio is one-way, check that the customer's router doesn't have an "SIP ALG" feature mangling the messages — disable it.
2. Hangup detection on FXO. ISPs in India use varying disconnect signalling — silence detection, loop drop, polarity reversal, busy tone. HT813's auto-detect catches most; some need manual tuning of "FXO Termination" and "On-hook Threshold". Plan a 30-min tuning session per site.
3. Echo. Analog FXO ↔ SIP can introduce echo. HT813 has an echo canceller; enable it. If echo persists, adjust gain (HT813 RX/TX Gain).
4. Caller ID format. Indian ISPs deliver caller ID as either DTMF-after-first-ring or FSK-Bell202. HT813 supports both — choose whichever the line gives.
5. Power loss at the site. When the HT813 loses power, the FXS-side analog phone also loses dial tone. The FXO line (incoming) is unaffected on the ISP side but our cloud loses the registration. If the site needs zero-downtime, add a small UPS for the HT813 (~₹2,000 for a 30-min runtime).
6. Public SIP exposure (Stage 1). Until we move to WireGuard (Stage 2), the cloud's port 5060 is reachable from the HT813's WAN IP. fail2ban already protects against brute-force on cloud — confirm pjsip filter is enabled there. No DID enumeration is possible because endpoints are identify_by=username and unauthenticated INVITEs get 401.

Future / out-of-scope¶

• Multi-port FXO sites. If a customer needs more than 1 line, use Grandstream GXW4108 (8 FXO) or GXW4216 (16 FXO) — same Asterisk-side config pattern, just more endpoints.
• Auto-provisioning. Grandstream supports HTTP-based provisioning (cfg<MAC>.xml). For >5 deployed devices, set up a config server that templates the per-device XML from the DB. Skip for the pilot.
• Stage 2 WireGuard. Documented above; revisit after Stage 1 is stable for ≥1 month.

Related work¶

• First option to always try: ask the ISP for SIP credentials directly. If they say yes, none of this hardware is needed.
• internal-docs/docs/architecture/multi-carrier-trunks.md — once the multi-carrier admin UI lands (#230), HT813 devices become rows in carrier_trunks (or a per-org peers table) configurable from the UI, not hand-edited Asterisk files.
• internal-docs/docs/customers/v7-setup.md — V7 uses the same SIP-registration pattern (their UCM6301 ↔ cloud), just bigger device. Re-read for NAT / codec / registration-loss gotchas.