Hello all!

I’m actually wondering about how to achieve fast fail handling for the pjsip transport if underlying WAN IP address changes.

Following scenario:
Asterisk runs on a device holding ppp0, which provides the interface for outbound registration to ISP trunks (transport acts as client) and therefore the WAN IP.

If WAN IP changes after restarting ppp0 (and ppp0 device completely disappeared for some time), it takes pretty long until the transport realizes, that the WAN IP
changed.

I tried dnsmanager to always provide correct external IP address in SIP requests like this

external_media_address : external.mydom.org external_signaling_address : external.mydom.org local_net : 192.168.0.0/255.255.0.0

and I can see, that after IP address change, the SIP requests (Register e.g.)
provide the correct WAN IP – but transport didn’t realize the change on low level.

NOTICE[4061] dnsmgr.c: dnssrv: host ‘external.mydom.org’ changed from 46.r.x.y:0
to 79.t.a.b:0

It takes quite some long time (~13 minutes), until pjsip / asterisk detects a timeout or a network unreachable.

tlsc0x7ffa800203a8 TLS transport destroyed with reason 120110: Connection timed out

After this point has been reached, the transport is destroyed and a new transport is generated – from now on, things are working fine again.

I added a global logging rule in iptables at first place in OUTPUT to see any packages which are handled – but I couldn’t see any – therefore I think things are breaking even earlier.

My question: is there any possibility to programmatically force the restart of a given transport (I don’t want to restart all transports)? This could be easily done in ppp up scripts. Or is there a configuration option to reduce the timeout until restart of the individual transport? Maybe in pjsip (connection timeout detection)?

Another idea would be to restart the relevant transports based on dnsmgr detecting new external IP.

Thanks Michael

—