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 http://downloads.freepbxdistro.org/ISO/FreePBX-64bit-10.13.66.iso
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?
