sipxbridge crashing

[J.T. D]

cent7

24.01-20260204150225

Single server, no HA

After recently updating, I'm having issues with stability of sipxbridge.  Overnight/daily, I will lose registration with the carrier (VOIP.ms) and the debug log of sipxbridge.log will stop recording.  The last lines are:

"2026-03-01T21:37:09.467000Z":77323:JAVA:DEBUG:<sip server>:PipelineThread-0:00000000:sipxbridge:"Starting to parse."
"2026-03-01T21:37:09.467000Z":77324:sipXbridge:DEBUG:<sip server>:PipelineThread-0:00000000:sipxbridge:"Starting to parse."

Scrolling above doesn't reveal any significant issues except for one I caught which points to DNS, buuuut...

VOIP.ms shows loss of registration.  In sipxcom, if I select the SIP trunk statistics, it shows registration status as AUTHENTICATED, but when I click Refresh, I get the error screen.  The sipxconfig.log file captures an OutOfMemory exception when this happens.

The sipxbridge.log file recently captured a java exception that it was unable to resolve the domain (or the sip domain, which I setup as the same as network domain.)  

DNS is enabled on this instance, but I also have a network DNS server running on the router.  I have the router IP configured as a forwarder/primary external dns server in sipxcom.  I can ping/nslookup the sip domain from my workstation (which uses DNS on the router) and resolve to the IP of the sip server.  I cannot ping the sip domain from the sip server using the built-in DNS.  If sipxbridge is attempting to find itself, how can it?

/etc/hosts does not contain an entry for the sip domain.

The IP does exist as a forwarder in the named.conf DNS configuration, but will DNS requests forward if attempting to resolve on the same domain?

I added a custom A-record in sipxcom to add the sip domain and resolve to the sip server, but it still crashes.

Prior to this version, it ran flawlessly.  Possibly something committed in the two releases in February is misbehaving?  I am also seeing this behavior on another sipxcom instance I manage in another location.  It could very well be a misconfiguration on my part as I set both up nearly identical.

I don't think this DNS issue is the root cause, as calls were still made/received even after observing the errors in the log file.  But, nothing is showing in the log at the time it freezes/crashes to point to a problem.

Performing a 'service sipxbridge restart' or 'service sipxecs stop'/'service sipxecs start' fixes the immediate issue temporarily.

Any suggestions where I might look?  When my sip instance experiences this, I can keep it in that state to assist with troubleshooting.

Thanks in advance.

[Support]

Hello,

Check the STUN configuration under System - Settings - NAT Traversal is correct, either as a fixed public IP or a correct STUN server.

There was a change / fix there as sipxbridge did not always read the STUN configuration from web admin correctly. 

Otherwise, out of memory means out of memory, so it appears something could be leaking resources or RAM running on your server.

--
You received this message because you are subscribed to the Google Groups "sipxcom-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sipxcom-user...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/sipxcom-users/85dc17df-299c-4737-874c-0b6f4042f003n%40googlegroups.com.

[J.T. D]

My system is set to use STUN (with a google.com stun server.)  I see in the bridge log it does successfully grab my public facing IP.

Physically, I have 16gb of RAM.  According to 'free', I've got 12gb available.

I do see the java process running sipxbridge in 'top'.  It has a VIRT value of 14.8g currently.

[Support]

In the Rocky Linux 9 project we have done a lot of service and memory management work including restricting java processes from grabbing too much virtual memory. 

This has been a necessity in particular since the upgraded java 17 libraries for e.g. jetty, spring, elasticsearch, tapestry etc can be massive memory hogs if let loose.

Java 8 as used by 24.01 can also perform poorly when it comes to default memory management on some modern cloud images, but is not practical to move all the above changes back to CentOS7.

This can cause java processes to get kicked out when there is a spike in image memory usage, perhaps when you do some routine maintenance script or similar.

You can however control java memory limits in the various sipX startup scripts under /etc/init.d by restricting heap usage with the java -Xmx512m option for e.g. sipxbridge and sipxrelay.

Just make sure the script files are read only protected or similar from getting overwritten with later upgrades.

This command btw sorts the java processes by RAM usage:

> ps -eo pid,ppid,user,rss,vsize,command --sort=-rss | grep java

To view this discussion visit https://groups.google.com/d/msgid/sipxcom-users/71c21915-8018-49a4-bd3f-9576a0d95efcn%40googlegroups.com.