There are two distinct issues here.
The first is the use of ports, and on your system the ports can be “standard” or “arbitrary”. Even if you choose “standard”, it’s important to understand that they are just the same arbitrary everyone agrees makes sense.
The second is the channel driver. Your choice of channel driver(s) is based on what you want to support. From your provider’s perspective, your choice of channel driver is irrelevant, since they are talking to you over the SIP Protocol.
So, your PSTN trunk shouldn’t care. Some providers say “we don’t support PJ-SIP”, but that means they don’t provide support on helping you set up PJ-SIP. The trunk itself is almost certainly completely oblivious to your choice of channel driver. The source of this confusion is that they remember several years ago when Chan-SIP was the ‘standard’ driver and they understood all of the weird systemic problems that came with that. An example: for about a year, PJ-SIP didn’t support IP Auth. That was six or seven years ago and it does now, but you will still hear that it doesn’t work from Tier 1 tech support people.
So, when you set up your system (and there’s a best-practices Wiki on this) there are a few things you’ll want to do:
- Set up your gateway to limit access to your system. Since you are going to be using extensions that connect from arbitrary networks, you might want to look at using a VPN for these remote systems. Your ‘static’ connections should be allowed by IP address. There are going to be some ports that seem reckless (like forwarding all of UDP 10000-20000 for RTP) but these actually improve security by making the choice of RTP port more random.
- Pick your local port number for PJ-SIP. This should be arbitrary and reasonably random. This stops the script kiddies and automated scanners. If you decide to enable Chan-SIP, only do it if PJ-SIP will not support what you are trying to do. There are a handful of weird edge cases where PJ-SIP just can’t handle these and almost all of them use specialized legacy hardware that is bound to specific errors in Chan-SIP. Think of it as the errors that are built into the telnet protocol. No one writes a new telnet protocol handler because the errors are baked into the protocol.
- Settle on PJ-SIP for everything. You will need to set up a trunk for each ITSP IP address (probably on port 5060) so that you have a primary and an alternate outbound path. Most providers give you these. On one of these, set up all of your inbound addresses and ranges in the “Permit” field in the Advanced PJ-SIP settings.
- Stepwise Refinement is your friend, as is the Wing Walker’s Rule. Get everything working on your basic PJ-SIP setup, then add your alternate outbound trunk, then set up the local extensions, then VPN phone support, then start adding dynamic address ingress, then TLS, then automated beer delivery, then … Make your improvements, test, and always have a way back to a working config. Nothing sucks worst than adding three features, messing up the system, and having to reload the entire system from scratch.
Don’t confuse the port number you choose with the port number your provider uses. When they send traffic to you, it will be to the port you pick (incoming calls) and configure for their end of the trunk but when you send traffic to them (outgoing calls) it will be on the port they choose. Many people think these need to be the same - it’s customary but (once again) the port choices in SIP are arbitrary.
Another note on this one: Many providers now send traffic to your machine from blocks of addresses. Some use several outbound IP addresses in a /32 configuration (like Voip Innovations) and others use /28 blocks of addresses. Both of these are well supported in PJ-SIP and not in Chan-SIP.
If you want to use TLS, the typical form for this is that the TLS port is one higher than the non-TLS port. There’s nothing magic about 5060/5061.