Ports, and the endless confusion they cause

FreePBX Tips and Tricks
1

Let’s write a helpful forum thread for people confounded by port settings.

Where to start?

SIP

When I am working in the Asterisk SIP Settings menu, I am specifying the ports that I am listening on. Those are the ports where people connect to me.

When I am working in Trunks and see a “port” field, that refers to the port the SIP provider is listening on. USUALLY I leave this blank or default. The SIP provider will tell me if he is using an alternate port, or it will be part of a SRV record so that I don’t even have to worry about it.

If I have both chan_sip and pjsip enabled, then they are listening on different ports on my PBX. (Look in the Asterisk SIP Settings module) For my phones and any SIP providers that connect directly to me without using registration, I need to know which port they should connect to and I need to tell them that. The typical way to tell someone else how to connect to me on a certain port is to specify it as IPADDRESS:PORT, for example: 8.8.8.8:5160

If my phones have a “SIP Port” field in their configuration, it almost never means “the port for connecting to the PBX.” You normally specify IP:port for connecting to the PBX as mentioned just above.

RTP

My RTP range (Asterisk default 10000-20000) is the range of ports where I (PBX) am listening for incoming audio packets. You (SIP provider, phones) can use any range you want and it does not matter to me. I will send audio packets to you on the ports you tell me in our SIP handshake (SDP), and you will send audio packets to me on the ports where I am listening.

Tips

Use only PJSIP and disable chan_sip (in Advanced Settings - SIP channel driver). It will reduce opportunities for confusion.

Use the default ports until you really understand how ports work. This is not SIP, it’s networking. @dicko is going to come along and say to change the ports so that ne’er-do-wells don’t scan your PBX, as he often does. His advice is good but don’t go making changes to your port settings until you full understand this networking feature.

Please add to this and make corrections. Let’s develop a solid thread.

4 Likes
2

Generally good advice for beginners, but I would word this differently:

I don’t like the idea of recommending that pjsip be disabled for any reason at this point, regardless of the complications that might arise with having both drivers enabled.

2 Likes
3

https://issues.freepbx.org/browse/FREEPBX-21061

1 Like
4

I updated my post with a more bold suggestion. Hope no one objects. :slight_smile:

5

I’ll take the bait . . . .

If you implement FreePBX anywhere, before you provision anything, I suggest you run

sngrep

for a few hours.

If you get just one hit you should know you are “under investigation”
If you find any of these connections to use anything but UDP:5060 I will be surprised
If you are listening on UDP:5060 , immediately and before provisioning anything you are under seige, (and by default you WILL be listening on UDP:5060 .)

If this thread also explains now simplistic it is to arrange for all your extensions to use !UDP and !5060 then I would less often have to toot that UDP:5060 horn, which is by any measure the absolutely biggest half open door you will have and absolutely can be shutdown with two lines of config.

So, how hard is it to only allow domain based SIP connections only on a non standard port using TLS (or TCP if your not ready for TLS yet) for all your Extensions ? ( a clue, it is trivial the result is no more bogus connection attempts to armor against, The reluctance/refusal to even attempt/explore this is for me truly perplexing , go figure . . .)

2 Likes
6

i propose making a single channel driver on 5060 the default in freepbx 16 ! boom … relegate dual channel to an advanced setting only with 16 and perhaps dropping it with 17 altogether … boom boom boom

it causes so much confusion and with the advent of fwconsole convert2pjsip there’s no good reason not to push it from being a default and eventually remove it

1 Like
7

Look I’m all for completely getting rid of Chan_SIP but honestly that can’t be done until Chan_PJSIP is fully RFC4235 compliant. Until then Chan_PJSIP doesn’t support the full XML schema needed for proper BLF monitoring. That is honestly the only reason I still use Chan_SIP at this time. Users that need full BLF functionality, Chan_PJSIP can’t give it.

8

What’s the issue specifically? Is there a ticket open for it? That seems like a big problem.

9

It is ASTERISK-24601[1] which has a patch attached, but noone has taken it through code review for inclusion as of yet.

[1] https://issues.asterisk.org/jira/browse/ASTERISK-24601

2 Likes
10

Assign it to Javert!

11

What exactly is the problem with the chan_PJSIP BLF full XML schema?

The bug “ASTERISK-24601” says it is a “MAJOR issue, which makes 13.0.0 unusable with snom phones.”, however I’ve been using almost exclusively snom phones with FreePBX and chan_PJSIP for multiple years with a lot of BLF usage and have never noticed something problematic with regarding BLF…

12

Do you use it for direct call pickups? On other phones like Polycom and Yealink there have been problems. When because the XML is missing data, like the user you need to pick up, the phone can’t append that data to the directed call pickup prefix you set in the phone. So you can’t pick up the calls.

Being able to see the state of the user is not an issue. It’s when you use more enhanced BLF functions that expect certain data in a certain format in the XML schema.

13

Yes I’m using directed call pickup. I’ve defined my BLF buttons like this:
<sip:[email protected];user=phone>;user=phone|**
and it has always been working fine.

Perhaps newer Snom firmware is more tolerant? Never had BLF problems with old firmware though, but the bug was created in 2014: I probably did not start using PJSIP until 2017 (?) and I tend to update my phone firmware quite regulary.

14

Anything is trivial to someone who has done it often and has full confidence in their ability to make it work. To those who have struggled to get even a basic configuration working, it is not trivial at all. The reluctance you see is because people fear breaking a working system and then not being able to fix it. There is an old axiom, “If the damn thing works, leave it alone!”

That said it would be really helpful if you would create some kind of document explaining exactly how to do this, making sure sll steps are covered and leaving nothing out. Don’t assume any prior knowledge beyond that the user knows what FreePBX is and can log into the web interface. If possible, make a video showing the steps - people like videos because by their very nature they tend to show all the steps involved, even ones that the creator of the video might not think important enough to mention because they assume that everyone knows that already.

Finally, it should be noted that some systems have endpoints where making even a small change like a port number can mean a long and costly trip because no one at the location of the endpoint feels competent to open a web browser and click where instructed and type a few numbers in the correct text field. Not all remote endpoints are remotely provisioned, especially on very small systems. That alone could explain the reluctance/refusal that perplexes you.

1 Like
15

For UDP and TCP , to change the port to listen on (I suggest that port NNNNN > 20000 < 60000 are good choices) :-

GUI -> Asterisk SIP settings -> sip settings (presumable chan_pjsip nowadays) -> Port To Listen on

To change the Phone to that , use the same number in the Register Port field or in that field’s absence add “:NNNNN” to the registrar address.

If you can use TLS (good idea) just stay with 5061 and get your certs in a row,

A well prepared virgin will have arranged for remote provisioning over https then you can just make the changes and have them unplug/plug if necessary or at least drop ship pre-prepped hardware, working with folks that can’t use a browser or follow instructions will always remain a problem, sorry can’t help you there :wink:

16

I’ve been trying to get my head around adding password protection for remote provisioning and I can’t quite see how this could work without some manual config on all the devices. As-is we either don’t allow it, or have access to the config files limited to known external IPs.

17

If using https what would a rogue user see that concerns you? , the device needs to go the the domain URL presenting a mac address that is pre existing, if your firewall has portscanning protection ( you need that) then you are quite secure

18

The config files with the SIP registration info. They’d have to brute force part of the URL, but the MAC range on Sangoma phones is well known and not exactly enormous.

19

As I say any decent firewall will have conntrack process watching for brute force attacks, do you have that?

20

The firewalls of which I’m aware, including those that we deploy, have no way of discerning between valid and invalid HTTPS request to an endpoint behind the firewall. So I guess the answer is “no”.