astanlofter wrote: 05/28/2026
Just conducted an experiment: disconnected my ATA for 1h 25min, the status at that link remains "SIP Status: connected"
That is not what I observed previously when I reported a SIP status issue involving Obihai devices to Fongo admin in 2023. At that time, after the next registration interval passed without a new registration attempt, the portal eventually showed "disconnected" (as expected). In this case, the portal status appears not to have updated yet. In other words, that's not normal and may be more indicative of problems related to the data centre outage than anything else.
In any event, your observation supports the broader point that the portal is not a real-time indicator of whether the ATA is currently reachable. SIP registration is soft state (state that expires unless it is periodically refreshed), so the server can retain a stored registration binding after the ATA has gone offline. That is, the portal may continue to display stale registration information, which is why the ATA's current status is the better indicator.
Also, the way I understand the protocol, from ATA's box perspective, when the connection is lost, it marks the registrar as unavailable
That is not how standard SIP works; it is not a rule in RFC 3261. The ATA does not automatically know that the registrar is unavailable the instant the network path drops. It learns that something is wrong when it sends a SIP transaction, such as a scheduled REGISTER refresh or a keep-alive packet, and that transaction fails or times out. If the ATA is idle during the outage, it has no new SIP-level evidence that the registrar is unavailable, so it will not immediately treat the registrar as down.
The ATA may detect the failure later, but it does not necessarily mark the registrar unavailable at the moment the connection is lost. Moreover, during a network disconnection, the ATA cannot send a REGISTER to refresh the binding because no communication path exists to exchange SIP messages with the remote server.
and when the connection is restored, it will redo the entire registration sequence immediately (will send a fresh REGISTER request to the SIP proxy/registrar) without waiting for 1h expiration
RFC 3261 does not require immediate re-registration the moment connectivity returns. It says the User Agent (UA) refreshes its bindings before they expire, and it also says that if a REGISTER request times out, the client should not immediately re-attempt registration to the same registrar, but should wait a reasonable interval. That is not the same as instant re-registration on link restoration. With Freephoneline, keep-alive timing and failed-registration retry timing are separate settings. A missed keep-alive does not by itself establish that an immediate fresh REGISTER will be sent, because RFC 3261 does not require it and Freephoneline’s own interval settings treat those two mechanisms independently.
In other words, RFC 3261 does not mandate that a SIP User Agent be link-state aware. Tying the network interface's physical status (cable plugged/unplugged) to the SIP stack to force an immediate REGISTER request would be a custom firmware design choice by the manufacturer to improve user experience. It is not a SIP requirement. The Thomson TG784 is an integrated router/ATA, and while it is possible that some firmware version could implement link-up-triggered re-registration as an internal recovery mechanism, I don’t see authoritative documentation or public analysis showing that the TG784 does that. Frankly, I would be surprised.
Otherwise it will not be receiving incoming calls.
Registration is required for incoming calls, but failed incoming calls do not by themselves prove that the registrar has already removed the ATA’s registration. They only show that inbound service was not functioning properly at that time. In other words, “incoming calls fail” and “portal still says connected” can both be true at the same time.
On Obihai devices, X_KeepAliveMsgType="options" or "notify" sends active SIP keep-alive probes. According to Obihai’s documentation, a missing response to those probes can trigger proxy failover, but only if proxy redundancy is enabled. Without redundancy configured, the documentation does not establish that a failed OPTIONS or NOTIFY keep-alive forces immediate re-registration. The device continues to rely on its normal REGISTER refresh and retry timers. Any re-registration behaviour observed in that scenario would be a recovery choice made by the endpoint or SIP client, instead of a requirement of the SIP protocol.
PS. My service got restored (by just reconnecting the cable). But the incident on their status page is still open.
That shows service resumed after connectivity was restored, but by itself it does not establish the exact SIP sequence that occurred afterwards. Restoring the cable allowed service to resume, but it does not follow that the ATA sent an immediate fresh REGISTER as soon as the link came back. A packet capture may confirm the sequence, and ATA logs, if available or obtainable, might also show whether a new REGISTER was sent when the cable was reconnected.
Your service could have been restored because reconnecting the cable allowed the ATA’s next scheduled registration request or retry timer to successfully transmit. That may have re-established the NAT mapping in your router and refreshed the SIP binding without requiring an out-of-cycle re-registration, which is consistent with the service resuming once connectivity returned.
