SIP ISP becomes UNREACHABLE

Asterisk Asterisk Support
1

Hello,

I am debugging one of my Asterisk deployment, the only one that I am not completely happy with: my home :unamused:

Well, it is also the only setup that is assembling the following parameters:

  • very light x86 box (Alix, WinThinClient,ā€¦) running Debian Testing.
  • Dynamic IP, thus dyndns.org
  • pfSense as Firewall
  • 3stars as SIP provider
  • different LAN for the VoIP (dedicated interface on the pfSense Box)
  • up to 7 SIPphones in the house (4 on PoE)
  • a very poor DSL line (3.3M/128k)

The thing is that suddenly (I really canā€™t give a timing and/or a specific event), ā€˜sip show peersā€™ tells me that my SIP provider becomes ā€œUNREACHABLEā€.
Of course it remains pingable, of course my dyndns is still up-to-date and of course all intern call/tests are running fine. I tried creating/removing any rule related to SIP/RIP in my pfSense FireWall.
I tried changing the machine, reinstalling Debian/Asterisk, using a fresh untouched config and adding minimum of my stuff, and/or stripping the default config to the minimal and have only the bare minimum (modules, config files,ā€¦) for my setup. :cry:

Could you help me tracking the events that could/should lead to such a situation?
Is there a magic command/test/debug line that could tell me more? :question:

[Something that I do not really relate to this, is that asterisk happen sometimes to use 100% of the CPU load, even on an advanced Pentium box. I said I think it is not related to the issue mentioned above because these events are not (always) happening simultaneously]

Thank you for any hintā€¦ :bulb:

Cheers,
Ben

2

The dyndns settings should not change, during any single internet connection. ! If they do, which is unfortunately possible, particularly on consumer grade connections, you can expect bad things to happen.

If you are getting 100% CPU, you need to create a debug build and follow the procedures that should be findable by googling ā€œasterisk wiki backtraceā€ to get a backtrace of all the threads, and work out which one is hogging the CPU.