Legacy SIP and PJSIP port usage

FreePBX Configuration
1

When supporting both protocols what port numbers are most commonly used? For example, I see some posts using 5060 for SIP and 5061 for PJSIP but I also see 5060 for SIP and 5061 for SIP/TLS. So in the latter case what would PJSIP/TLS use?

Thanks,
Diego

2

Use whatever you want to use according to your requirements.

First question I would ask is, do you need to support both chan_sip and pjsip? Switching entirely to pjsip is generally a good move.

Second question is, do you need to support all transports on both SIP drivers? I reconfigured a system yesterday where it had been configured for chan_sip with a bunch of extensions. With more time, I’d move all those to pjsip, but chose to leave them alone. We needed to bring up a trunk with TLS. So he now has chan_sip servicing UDP port 5060 for his extensions and existing trunks and pjsip servicing TLS 5061 for the new trunk.

3

Agree with Mr. Bill, port numbering is arbitrary. If you are very disciplined and comfortable with all your port numbers, and you have need to expose to untrusted SIP traffic, I would (and do) set port numbers randomly in the 60k range. It does make it difficult to remember, but fail2ban kicks in a few times a year instead of a few times a minute.

2 Likes
4

I don’t have a specific setup yet because we have not finalized what SIP provider we will be using yet but I did come up with two “pre-requisites” for lack of a better term that I am planning for:

  1. Make PSTN SIP trunk as compatible as possible in order to have the greatest amount of provider options/flexibility. Sort of lowest common denominator type of thing. For me this means using legacy SIP/TLS 5060/5061 and using IP ACL.

  2. Since I have complete control of phones, use PJSIP with custom port (say 5666?) for both internal and remote phones which use dynamic IPs and also provide some level relief from SIP hackers.

So at that point I realized, OK, what happens with PJSIP TLS port? Maybe just not use it?

Thanks,
Diego

5

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.

6

Dave,

Thank you for taking the time to give me so much detail. It is much appreciated and I will certainly try to go with your recommendation to stick to PJ-SIP all around. However there is still something I would like to do that you did not touch upon. Is it possible to use one channel driver (PJ-SIP) to listen on multiple ports? Let me explain why.

I really do not want to mess with VPN and I am comfortable that I can setup a relatively secure system without doing so. All the SIP providers that I have in mind can provide source IP blocks for me to use in an ACL but I am not sure they want to mess with using non-default ports.

I would still like to use 5060/5061 with IP based ACLs for providers and use a random port for remote phone clients. The phones will of course have dynamic IPs that are no feasible to try to whitelist.

So basically I would like to try to do with one channel driver what I am currently doing with two. That is have 5060/5061 listening with IP whitelist and have, say 5888 listening for phones and relying on strong password and fail2ban for protection. Thoughts?

Thanks,
Diego

7

trunks can be set ‘hard wired’ as necessary , you can ‘listen’ on any port you want for your external endpoints, but only on one port per chan driver, sip/pjsip/tls/webrtc

1 Like
8

That might be possible, but my experience tells me it won’t work the way you hope. There’s no reason why your provider can’t send new calls to the same obfuscated address as the rest of your phones. The ACL process in the Integrated Firewall for your provider’s will work seamlessly with the Adaptive Firewall for your phones.

The “normal” way to listen on two ports is to use two channel drivers (PJ-SIP and Chan-SIP) but that’s a path to confusion and a lot of work that could break at any moment. The problems with Chan-SIP are here to stay until the channel driver is fully deprecated.

Having said all of that, it is your system and you can try to set it up any way that makes you happy. @dicko and I have given you a workable path forward to success.

9

Understood. Thank both of you gentlemen for your advice!

Rgds,
Diego

1 Like
10

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.