PJSIP Transports

FreePBX Installation / Upgrade
1

Morning everyone.

Asterisk: 18.17.1

Yesterday I upgraded a FreePBX and in the process also converted the remainder of the extensions to PJSIP. ChanSIP was running on port 5060 and PJSIP on 5062.

Once all extensions and Trunks were converted, I changed PJSIP to run on 5060 and ChanSIP on 5064.

Then, I wanted all extensions that were already on PJSIP to continue to work on 5062 (until they reprovision and use 5060), so I copied the 0.0.0.0-udp transport and created another transport in pjsip.transports_custom.conf

[custom-pjsip-udp]
type=transport
protocol=udp
bind=0.0.0.0:5062
external_media_address=75.99.XXX.XX
external_signaling_address=75.99.XXX.XX
allow_reload=yes
tos=cs3
cos=3
local_net=192.168.1.0/24
local_net=10.10.14.0/24

I reloaded asterisk and pjsip show transports showed both UDP transports. PJSIP extensions were now able to register to both, 5060 and 5062.

However, I noticed that for phones who registered on 5060, for whatever reason, Asterisk was sending OPTIONS --at least for phones behind NAT from port 5062. The phones did not reply to that which resulted in Asterisk to mark the endpoint as unreachable.
In other words, even if a phone registered on 5060, Asterisk sent OPTIONS from 5062.

In Extensions → Extension → Advanced, you can set the transport, by default it is ‘auto’, which means that there is no value for the transport parameter:

[root@freepbx ~]# asterisk -x"pjsip show endpoint 8013" | grep transp
 transport                          :

So I set that it should use the 0.0.0.0-udp and it started sending OPTIONS from 5060 to this extension.

At this point, most of the phones had reprovisioned and were registering on 5060, so I decided to just delete the custom-pjsip-udp transport, hoping that all endpoints will now use the 0.0.0.0-udp transport.
However, after deleting and reloading, Asterisk still sent OPTIONS from 5062.

Only after a Asterisk restart is when Asterisk started to send OPTIONS from 5060.

Which brings me to ask the following questions:

  1. It seems that a “default” transport gets assigned to the endpoint if you don’t specify a transport. How can I define which transport should be the default?
  2. I was under the impression that when reloading Asterisk (core reload) it will reload the transports as well. How come this required a restart to correct this?

P.S. The PBX is fully functioning now, this is to learn so I can understand how to do better in the future. :slight_smile:

Thanks much

2

  1. There is no explicit default transport. It depends on load order and the system routing table. If you have a case where two are possible, then the only way to control it explicitly is to set it on the endpoint.

  2. It will reload PARTS of transports by default, and will try to reload more of transports if allow_reload is set. Ultimately for drastic transport changes like deleting one, a restart is required.

3

Hi Joshua, thanks for your response.

Do you mind elaborating on this?

If I understand correctly, the load order works similar to loading the dialplan? So if you have:

#cat pjsip.transports_custom.conf

[transport-a-udp]
type=transport
protocol=udp
bind=0.0.0.0:5062

[transport-b-udp]
type=transport
protocol=udp
bind=0.0.0.0:5060

Then transport-b will be the “default” since it was loaded after transport-a. Is that correct?

I sound like a novice… What is that?

Thinking… Changing the order of the transports in the conf file won’t make a difference?

Thanks again.

4

It’s… complicated. It’s dependent on the PJSIP internal implementation which may have changed since I last looked at it. Order in pjsip.conf may or may not matter. It’s basically undefined. It may work one way in one version, and another in another version. Determining what it is now and trying to depend on it is a recipe for disaster. Being explicit in configuration for each thing is reliable.

The system routing table determines how packets are routed on different interfaces. We try to take that into account when choosing a transport (of course if you bind to 0.0.0.0 with different ports we can’t do that).

5

Got it.

So I guess, in FreePBX, since you can only set one transport for each protocol in the GUI, then it was never really an issue not setting the transport on the endpoint.

I will consider submitting a patch [to FreePBX] to allow setting a “default” transport which will in return specify said transport in the endpoint config.

Much appreciated, Joshua!

6

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.