I'd be interested to know how many FreePBX users are actually using PJSIP rather than Chan SIP. A couple days ago I tried setting up a new install of FreePBX using the instructions at https://wiki.freepbx.org/display/FOP/Installing+FreePBX+14+on+Debian+8.8 in part to try PJSIP. My initial impression is that it is not the easiest thing to set up; things that are easy in Chan SIP become much more difficult (if not impossible) in PJSIP, at least initially.
I tried configuring a PJSIP extension and at first it did not work at all. I wound up tweaking several settings under Asterisk SIP Settings and I am not sure exactly which worked, but this is what I wound up with:
General SIP Settings
Security Settings
Allow Anonymous Inbound SIP Calls - No
Allow SIP Guests - No
Default TLS Port Assignment - unset
Chan SIP PJSip
NAT Settings (used detected network settings which are correct)
RTP Settings
RTP Port Ranges = Start: 10000 - End: 20000
RTP Checksums - Yes
Strict RTP - Yes
RTP Timeout - 600
RTP Hold Timeout - 900
RTP Keep Alive - 20
Media Transport Settings (all blank)
ICE Blacklist (all blank)
ICE Host Candidates (all blank)
WebRTC Settings (all blank)
Audio Codecs
T38 Pass-Through - No (for now, wondering what best setting is)
Codecs
ulaw
alaw
gsm
g726
g722
Video Codecs
Video Support - Disabled
Chan PJSIP Settings
Misc PJSip Settings
Allow Reload - Yes
Show Advanced Settings - Yes
TLS/SSL/SRTP Settings (left at defaults/unset)
Transports
udp
udp - 0.0.0.0 - All - No
udp - xx.xx.xx.xx - eth0 -Yes
tcp
tcp - 0.0.0.0 - All - No
tcp - xx.xx.xx.xx - eth0 - No
tls
tls - 0.0.0.0 - All - No
tls - xx.xx.xx.xx - eth0 - No
ws
ws - 0.0.0.0 - All - No
ws - xx.xx.xx.xx - eth0 - No
wss
wss - 0.0.0.0 - All - No
wss - xx.xx.xx.xx - eth0 - No
xx.xx.xx.xx (udp)
Port to Listen On - 5060 (BE SURE TO SET THIS, IT IS NOT SET BY DEFAULT)
Domain the transport comes from - left blank
External IP Address - left blank
Local network - left blank
Note that xx.xx.xx.xx is the server's IP address, also the client I was using was on a different IP address block behind a NAT router (if that's the correct terminology). In the Chan SIP extension setup, I would always have to use NAT Mode - Yes (force_rport,comedia) to get two-way audio in this situation. In this case, when setting up the PJSIP extension, I found I could pretty much leave all the settings at the defaults.
Also note that until I set Show Advanced Settings - Yes in the PJSIP settings, I could not see the options that included the specific IP address of the server. I think setting this may have helped. But the biggest thing that seemed to help resolve issues was restarting Asterisk, or in one case, completely rebooting the system. For some reason, even if you set the Allow Reload - Yes option, just applying the configuration alone sometimes seems to leave the system in a weird state where things don't work as expected.
Where everything went to hell was when I tried to set up a PJSIP trunk to a remote FreePBX system (that uses Chan SIP only) at the same external IP address as my test extension. After a lot of messing around I finally got it to sort of work, but the minute I did then my test extension could no longer connect. Does PJSIP not like two separate things trying to connect from the same IP address? But then again, I really was not sure what trunk settings to use in the first place. If anyone know any tricks for making a PJSIP trunk on a newer system talk to a Chan SIP trunk on an older one, that would be useful information.
Honestly I'm not sure why I'm even messing with PJSIP, since Chan SIP has always worked well for me, but to me it does not seem like PJSIP is fully baked yet. I found a couple of other weird things that worked fine with a Chan SIP extension, but not with a PJSIP one. Right now I am just poking at this trying to see if I can get it to work. The PJSIP test extension does seem to work fine now, as long as I don't try make a PJSIP trunk to the Asterisk server at the same IP (making a Chan SIP trunk is fine, though). I do find it interesting that a PJSIP extension doesn't seem to need specific NAT settings, once you finally get it working.
↧