PJSIP Transport Not Loading ('Unable to retrieve') due to Duplicate Configuration in VitalPBX 4.2

VitalPBX
1

Okay, here is the draft for the VitalPBX forum post, translated into English. Please remember to replace the bracketed placeholders (like [YOUR_ASTERISK_VERSION]) with your specific information and to attach the screenshot of your “Liberty” transport configuration in the GUI.

Subject: PJSIP Transport Not Loading (‘Unable to retrieve’) due to Duplicate Configuration in VitalPBX 4.2

Dear VitalPBX Community,

I’m experiencing a persistent issue with configuring a custom PJSIP transport in VitalPBX 4.2, which is preventing me from resolving an audio problem for one of my trunks. I would greatly appreciate your help in diagnosing and resolving the root cause.

System Context:

  • VitalPBX Version: 4.2
  • Asterisk Version: [Your Asterisk version, you can get it with asterisk -V in the CLI]
  • Network Scenario: My PBX is hosted in Azure. I have two SIP trunks with one provider that work perfectly using the PBX’s public IP. The issue is with a third trunk (provider “Liberty”) that communicates via a Site-to-Site VPN.
  • Initial Problem: The VPN trunk had audio issues (one-way audio or choppy audio). A SIP packet analysis (INVITE sent from the PBX to the provider over the VPN) revealed that the PBX (internal IP 10.142.0.5) was announcing its public IP (104.196.223.213) in the Via and Contact headers (104.196.223.213:5060), which is incorrect for internal communication over a VPN.

Desired “Liberty” Transport Configuration: To correct the NAT issue with the VPN trunk, I defined a custom PJSIP transport. The desired characteristics are:

  • Protocol: UDP
  • Bind Address: 10.142.0.5:5060 (PBX’s internal IP)
  • External Media Address: 10.142.0.5
  • External Signal Address: 10.142.0.5
  • Local Net: Including the VPN provider’s network ranges (10.192.46.48/29, 10.192.46.56/29, 10.192.46.64/29) and the PBX’s own internal network (10.142.0.0/20).
  • Symmetric Transport: Yes

Troubleshooting Steps Taken & Findings So Far:

  1. Transport Configuration in VitalPBX GUI:
  • I defined the “Liberty” transport (whose internal ID is transport-udp-baba6eebc6ae3c807695) in the VitalPBX GUI with the desired configuration (Bind Address, External Addresses, Local Net, Symmetric Transport).
  • I applied the changes in the GUI.
  1. Persistent Error in Asterisk CLI:
  • Despite configuring it in the GUI and applying changes, the Asterisk CLI continues to show the following error repeatedly: [2025-05-30 09:32:56] ERROR[XXXXXX]: res_pjsip.c:903 ast_sip_set_tpselector_from_transport_name: Unable to retrieve PJSIP transport 'transport-udp-baba6eebc6ae3c807695'
  1. Verification of Loaded Transports (pjsip show transports):
  • When running pjsip show transports in the Asterisk CLI, the transport-udp-baba6eebc6ae3c807695 transport does not appear in the list of loaded transports. Only the default UDP, TCP, TLS, WS, WSS transports (all configured with the public IP) are shown.
  1. Key Diagnosis: Duplicate Configuration File Loading (config list):
  • Upon running config list in the Asterisk CLI, I observed unusual behavior. Configuration files like pjsip__10-general.conf and pjsip__20-transport.conf appear listed multiple times, each with a different ID, for example: fcee0b3e-d902-4d1b-8 /etc/asterisk/vitalpbx/pjsip__10-general.conf a343135c-ce37-46b2-8 /etc/asterisk/vitalpbx/pjsip__10-general.conf ... 53f0ec63-1dac-4793-9 /etc/asterisk/vitalpbx/pjsip__20-transport.conf 83951ef7-a1e3-4e7a-8 /etc/asterisk/vitalpbx/pjsip__20-transport.conf ... (and many more repetitions of the same file)
  • This suggests that Asterisk is attempting to load the same PJSIP configurations repeatedly, which is the likely cause of the conflict preventing my “Liberty” transport from being recognized.
  1. Direct File Inspection and Restart Logs:
  • I have verified the /etc/asterisk/vitalpbx/pjsip__20-transport.conf file directly on the server after applying changes in the GUI, and the [transport-udp-baba6eebc6ae3c807695] section is present and syntactically correct with the desired configuration.
  • I have monitored Asterisk logs (tail -f /var/log/asterisk/full or journalctl -u asterisk -f) during a systemctl restart asterisk with high verbosity, and no explicit syntax errors were shown when loading the pjsip__20-transport.conf file or my transport section. The only error shown is the Unable to retrieve PJSIP transport error when the endpoint tries to use it.

Conclusion and Question:

The problem appears to be that, despite the configuration being correct in the VitalPBX GUI and the file generated by VitalPBX seemingly containing the definition, Asterisk is not loading this transport effectively. This is most likely due to the duplicate loading of PJSIP configuration files that I’m observing.

My VitalPBX version is 4.2, and I have not found an explicit “rebuild” or “regenerate” all configuration files option in the GUI.

Has anyone experienced this duplicate configuration file loading issue in VitalPBX 4.2? Is there a way to force a complete configuration rebuild, or is there any troubleshooting step I might be missing to get Asterisk to properly load this transport?

Any help or suggestions would be greatly appreciated!

Thank you