TLS disconnect triggers immediate re-register, ignoring 120s backoff

[mikaelwills]

It looks like the sdk, seeing a ConnectionTerminated is forcing a refresh and ignoring the backoff?
Im seeing a spam of my logs where its retrying instantly over and over

  142952.728 - Registration error 606... retrying in 120 seconds.
  142952.728 - ConnectionTerminated seen for flow...
  142952.728 - forceRefresh connTerminated:1 expires:0 netSwitch:0
  142952.728 - requesting refresh of ClientRegistration
  142952.728 - TX 'Req REGISTER/cseq=2091'  ← Immediate retry, ignoring 120s backoff

I think thats happening is:

1. Avaya sends 606 response
2. Avaya closes TLS connection (server behavior)
3. Siprix sees ConnectionTerminated event
4. UserAgent.cxx:533 processes it with refresh:1
5. UserAgentRegistration.cxx:82 calls forceRefresh with connTerminated:1
6. ClientRegistration.cxx:343 immediately requesting refresh - bypassing the 120 second timer
7. Loop repeats ~every 500ms

IwSip.log

[mikaelwills]

The reason for the 606 is i had tailscale on and it was using the tailscale IP in the via header.
But i think it might be good for it not to bypas the 120s timer

[siprix]

sdk, seeing a ConnectionTerminated is forcing a refresh and ignoring the backoff?
The reason for the 606 is i had tailscale

Good catch!
Reason of this issue is TCP/TLS specific code, which attempts to update registration when detected 'ConnectionTerminated',
but it doesn't take into account that registration failed.

Here is updated build, which addresses this case (skips reg refresh when connection terminated).
siprix_ios_20260108.zip

[mikaelwills]

@siprix great thats working!

[mikaelwills]

@siprix actually could it be a good idea to expose the Acc_SetTranspBindAddr in the Flutter SDK?

So I could have tailscale on and siprix would continue to work just fine?

It's already in SiprixCpp.h:445 - just needs the Dart binding and platform channel wiring.

[siprix]

expose the Acc_SetTranspBindAddr in the Flutter SDK?

It's easy to add, but not sure that understand how this option can help.
In this case:

• app makes outgoing TCP connection and sends REGISTER request
• server answers 606 and closes connection
• SDK reacts on connection close, re-connect and sends REGISTER again

[mikaelwills]

Hm ok, overall what id like to be able to do is have Tailscale turned on, but still be able to register with the designated server and not have Siprix try to use the tailscale IP when ive already given it a sip URI with a PBX ip address.

From the logs attached below I think I can see:

Line 75 - Network monitor sees BOTH interfaces:
IPv4:pdp_ip0-10.161.130.75; en0-192.168.1.122;

Line 87-89 - But DetermineSourceInterface picks the WRONG one:
determine src for target: [192.168.1.109:5061 TLS targetDomain=192.168.1.109]
Success: [100.106.56.21:0 TLS targetDomain=192.168.1.109] ← Tailscale IP!

Line 91 - REGISTER sent with Tailscale IP:
TX 'Req REGISTER/cseq=9657' via [100.106.56.21:41347 TLS]

Line 105-107 - Avaya rejects with 606:
RX 'Resp 606/cseq=9658/REGISTER' from: [192.168.1.109:5061 TLS]
Registration error 606... retrying in 120 seconds.

DetermineSourceInterface appears to query the OS routing table to find which interface can reach 192.168.1.109. When Tailscale is active, its routing rules can take precedence even for local subnet traffic, causing it to select the Tailscale interface instead of en0 (WiFi).

If we exposed Acc_SetTranspBindAddr - would this let me explicitly bind to 192.168.1.122, bypassing the routing table lookup entirely?

Or maybe we could prefer same-subnet interface - If DetermineSourceInterface checked whether an interface is on the same subnet as the target (192.168.1.x), it could prefer that over a VPN interface.

siprix.log

[siprix]

DetermineSourceInterface appears to query the OS routing table to find which interface can reach 192.168.1.109
Line 87-89 - But DetermineSourceInterface picks the WRONG one:

Yes, correct, this mechanism uses OS routing table, but doesn't have any impact on the establish SIP signalling connections.
On low level transport uses bind (binds to specified port on all interfaces) + connect (system decides route based on remote IP:port), on higher level is required to generate SIP message and put IP:port data into Via/Contact headers.

It appears like connection established properly, but wrong IP:port put into the generated REGISTER request (you can see it completely when enable debug log level).
Is it possible, that reason of 606 error is wrong IP in the Via/Contact headers?

If we exposed Acc_SetTranspBindAddr - would this let me explicitly bind to 192.168.1.122, bypassing the routing table lookup entirely?

Most probably it should help, as source IP will by selected based on network interface.
We can expose this method in next update.
But this approach is quite complicated as app should manually detect preferred network interface and update it when required.

It's possible to add alternative option - fixedTransportInterface, as hint which source interface to use.

[mikaelwills]

It appears like connection established properly, but wrong IP:port put into the generated REGISTER request (you can see it completely when enable debug log level). Is it possible, that reason of 606 error is wrong IP in the Via/Contact headers?

Yea its putting the tailscale IP into the VIA header.

It's possible to add alternative option - fixedTransportInterface, as hint which source interface to use.

Yea this sounds good

[mikaelwills]

@siprix regarding just the ConnectionTerminated forcing refresh fix that you gave me, when will that be in a siprix release?

[siprix]

Recently published 1.0.34 contains that fix.