PJSIP Transport Reload Fun

When PJSIP support in Asterisk was being developed one of the critical areas of development was transports. These are for the most part provided by PJSIP and are what allow the flow of SIP signaling. PJSIP provides UDP, TCP, and TLS transports and we provide one for Websockets for WebRTC. Naturally we needed to allow configuration of this and the “transport” configuration type came into existence. This allows you to specify what to bind on, certificates, and more.

The transport type never originally supported reload because PJSIP itself did not allow reload. It expected the entirety of the PJSIP environment to be recreated from scratch in order to create new transports, versus reloading new configuration.

Later on preliminary reload support was added to the transport type by explicitly destroying a transport, waiting some time, and creating a new one. This was not reliable and thus was hidden behind an “allow_reload” configuration option. As destruction of a transport is asynchronous it was possible for it to take a period of time such that when the attempt to create a new one occurred it could fail as the old one could still be around.

This remains the state of things today, but there may be change in the future.

In recent versions of PJSIP there exists the ability to restart transports. This could allow better support for reloading of transports in Asterisk, so I urge you to stay tuned to future releases if this is something you are interested in!

About the Author

What can we help you find?