ID10T Operator HeadSpace - Switching Extension Device Driver From PJSIP to CHAN_SIP, Advanced tab's Port is 5060 - Unable to Register

Well this is my second post here so I thought I’d try and bring something worthwhile to the community. I did not want to post this as a bug in the issues site without first putting it here for some review. I have read too many bug reports that just seem like they need more vetting and clarity before actually reporting as a bug.

I have searched the community for others reporting the problem and I kind of pieced the puzzle together from several posts from 2014 and two from 2015. I have seen the strangest behavior and cannot reproduce it 100%, but the over arching issue can be reproduced.

VMware ESXi 6 - fully patched and updated running a VMware hardware version 8 VM for FreePBX was setup.

ISO downloaded from

FreePBX 10.13.66 with Asterisk 13 - Full Install option was selected.

Went through the installation, basic configuration stuff after installing (activate, trunks, etc.) then created an extension and noticed the PJSIP using 5060 instead of SIP (CHAN_SIP). OK fine. Zoiper registered and test calls went off without a hitch.

When I change the driver to CHAN_SIP (submit and then apply config from FreePBX UI) and in Zoiper add :5061 to point to the client to the IP address of the server AND a specific port…registration is unsuccessful.
I open the asterisk CLI via rasterisk and then issue core set verbose 9 and sip set debug ip x.x.x.x where x.x.x.x is the IP of the client running Zoiper on the same network subnet as the server behind a physical firewall.

As I attempt a registration I notice in the CLI that the connection is unauthorized and that the reason is the password is wrong. Well that can’t be right, I did not change the password, just the driver (and thereby connection port).

In the advanced tab for the extension, when you change from PJSIP to CHAN_SIP, the port remains at 5060. the moment I change that to 5061, submit, and apply config. I can register.
If I change the port to any real possibility, submit, apply config, and unregister my client, I can re-register the client again over port 5061 (i.e. changed the host, but not the client). I think this is because there is an active TCP/UDP connection to the server that has not timed out (re-registration is likely occurring over the established connection). I come back the next day and I cannot register until that port in the advanced tab is set to match the driver’s listening port.

The bug I believe I am seeing is simply this:
When changing from a PJSIP device to a CHAN_SIP device, the port listed on the advanced tab is not updating along with the driver.

While the device remained configured as CHAN_SIP, I changed the port to 9999, submit, and then apply config. After that I change the device’s technology to PJSIP and there is no port specification listed on the advanced tab for PJSIP (fine unless you need/want to use another port maybe???) Change the driver back to CHAN_SIP, submit, apply config…and the advanced tab shows port 5060 again. It appears just PJSIP to CHAN_SIP changes do not update the port appropriately since PJSIP does not list a port specification.

Too much detail? Not enough of the right detail? Anything else needed to make this a better and more helpful post?

That “port” you are talking about (per extension) is NOT a binding port. You shouldn’t even be setting it let alone changing it unless you know what you are doing. It’s not saying “register here”. It’s saying “talk to the remote device (your phone) at this port”. Effectively you are telling Asterisk to talk to your phone on port 5060 or 5061.

This is not a bug because that port is not what you change when you want PJSIP or Chan SIP on a different port. You have to change the binding address for the entire driver in SIP Settings.

That is because PJSIP doesn’t support the port setting (again per extension and not what you think it does).

You need to change the binding ports in SIP Settings

This thread is also a rehash from this:

For now we can chalk this up to lack of sleep and possibly not being used to the GUI. I am used to 100% CLI Asterisk, CentOS, Digium, and Dahdi systems 100% CLI and no X-Windows or GUI of any kind.

I appreciate your taking the time to respond pointedly. I have scoured the community and feel for you having to answer the same thing over and over again and did my best to make sure I did not add to that burden :slight_smile:

Thanks again!

1 Like