Problem 1: All of my VOIP providers use host-based authentication. Unless something’s changed in the last two weeks, PJ-SIP still doesn’t support that.
Problem 2: If I enable both PJ-SIP and Chan-SIP, I end up having them fight over the incoming connections, even when I specify the incoming connection point. For example, I have a customer that has an outward facing interface. With PJ-SIP enabled, it insists on talking to the port that I established for Chan-SIP (5065). PJ-SIP will end up throwing enough errors that Fail2Ban eventually shuts down the connection.
Problem 3: Random authentication problems are a problem. Phones will authenticate with it OK, but then fail, then reconnect, repeat. If I do the same process with Chan-SIP, everything is fine.
Honestly - Problem 1 is enough. I tried hanging with PJ-SIP for a while, but now my SIP provider is even telling customers that they won’t support Asterisk servers trying to use PJ-SIP.
I love Asterisk and it’s the cornerstone of every integration effort I do. You guys give me enough flexibility to do the things that let me do a good job for the non-profits I support. I have the capability to integrate it with a lot of other cool stuff (like Chan-SCCP-B, TimeTrex, VTiger, SugarCRM, and soon Chromis POS) so it’s really an enabling technology that makes the people I work with (some of whom are differently-abled) to accomplish a lot of cool things.
I know this is a weird reference, but it was like when the Air Force went from the Secure Telephone Unit (STU) II to the STU-III. People expected the new unit to do everything the old one did, but better. Twasn’t so. PJ-SIP is the STU-III in this scenario. I was expecting PJ-SIP to do “everything that Chan-SIP did”. Twasn’t so.