Pjsip anonymous

Slight correction, the linked ticket does not make a recommendation, and I have since reworded it to make it clear that it’s contemplating a change to the default setting for allow sip guests to no.

It absolutely is. By turning off SIP guests, PJSIP rejects INVITES from anything that’s not a defined endpoint. (Note: different from how chan_sip works!)

You admitted in another thread that you have never successfully used PJSIP, so I do not believe you have the right experience to make these assertions.

Allow SIP Guests is independent of chan_sip and PJSIP.

When you allow SIP Guests, unauthenticated calls will be directed to the “default” context. That’s the same whether you have a chan_sip or a PJSIP trunk. The default context used to play a disconnect recording. I don’t know what it does now. If you don’t allow them, Asterisk reject the invite.

A better result is to have your system completely ignore the invite. If you allow SIP guests, allow anonymous inbound SIP calls, and then route to terminate calls:hang-up, I believe that your system will ignore the invite completely. No response.

Rejecting invites is NOT more secure. What is more secure is ignoring them.

There used to be a detailed explainer in the Wiki on this issue (not written by me). Again, the Community Manager removed it. It’s a shame, as these kinds of mistakes could all be avoided if we had a good wiki with good instructions.

BTW- I have gottten pjsip to work. But, it’s still buggy, especially when handling NAT. That’s probably one of the reasons we have all these people forwarding friggin’ ports and allowing their systems to get hacked.

Link to bug tickets please. PJSIP is the standard now and the only driver enabled by default in FreePBX 16.

You’re still getting it wrong. Without Allow SIP Guest, FreePBX won’t create the anonymous endpoint and thus won’t accept unknown invites at all. It has nothing to do with a default context.

You don’t know it, but you’re saying the same thing that I said.

The way that FreePBX chooses to send unauthenticated calls to the default context in PJSIP is by creating the anonymous endpoint. It accomplishes the same thing with chan_sip by a different mechanism (I think that it is ALLOW_SIP_ANON, but I’m not sure and don’t want to look it up right now).

Either way, the result is the same: With Allow SIP Guests OFF, Asterisk REJECTS the invite. As I said before, rejecting the invite is a security risk. It alerts the sender that there is a system on the other end to continue probing. The safer way to handle it is to ignore the invite altogether.

Of course, the better approach is to keep unwanted traffic completely out of your system using a firewall and NAT Router…

http://nerdvittles.com/avoiding-the-100000-phone-bill-a-primer-on-asterisk-security/

1 Like

Joe Roper wrote an excellent article about this very subject back in 2011. I’m pretty sure that it made it to the Wiki here, but he also posted it over at PIAF. (Joe was also a pretty staunch advocate of keeping systems behind a NAT Router):

I cannot find a link to the original, but you can find his advice here:

ALERT - please report hacks | Page 4 | The VoIP-info Forum. Here’s what he had to say:

Hi

This is inevitable with an open system.

Consider finding out the IP address ranges of your families ISP’s and restrict incoming connections to that range, which will reduce the possibility for attack.

Secondly,

“…I have Allow Anonymous Inbound SIP Calls set to NO”

Change it back to yes, add a catchall destination of _. in inbound routes, and pass this to hangup. This will save a "ss-not in service message, and won’t ID your platform as FreePBX.

Make sure you have valid and precise entries for all other incoming DID.

Joe

You want me to link to every PJSIP bug reported on Asterisk that isn’t yet addressed? Or do you mean all the unaddressed bug reports on the PJSIP module at FreePBX?

I was testing an older machine (about a year old) a few days ago and found the force_rport entry on the FreePBX PJSIP module did not create an appropriate entry for the trunk. I see that several people have addressed that issue over the last five years, but it seems to have regressed (at least at some point).

There’s a implied covenant between devs and users: If I report a bug, you will fix it. If you don’t address the bugs I report, I don’t report future bugs. Sangoma and I have reached this last stage. Not only have you not addressed bugs that I’ve reported, you’ve devoted substantial resources to making the GUI more time consuming to use, and so I also don’t spin up new systems every month like I used to either.

Feel free to open a ticket on the force_rport bug if it’s still there now. For now, I just worked around it by adding a _custom.conf entry.

All of our PJSIP systems are behind NAT (most of them are behind a Sonicwall firewall, which is known to be a PITA when it comes to SIP) we have NEVER had to add anything to any pjsip custom.conf file.

I am very curious what was missing and what you needed to add.

Hi Pitzkey,

First, again, let me reiterate that I was doing this on a machine that is about a year old. It is possible that these bugs have been fixed.

Second, I identified two issues.

  1. FreePBX has a place for the force_report entry in the PJSIP trunk configuration. But, it doesn’t matter what you fill-in there, because that entry doesn’t get populated in the .conf files. I worked around that by adding it to the custom file. This was a FreePBX problem, not an Asterisk problem.

  2. Asterisk PJSIP seemed to have trouble when both media points are behind separate NAT Routers and the ITSP routes media directly to and from them. Handling that situation is complicated, but it’s not insurmountable: In fact, chan_sip has no problems with it.

For example, a softphone behind a NAT registers to a Callcentric account as x. 101. A PBX behind a NAT registers to the same Callcentric account as x. 102. Both are behind NAT routers that assign local IPs in the same subnet: This is very common b/c most routers use 192.168.1.0/24 for their subnet.

The softphone (x102) initiates a call to the PBX (101). Assume the PBX has the inbound routes to handle the call. The appropriate phones on the PBX Ring. But, when they are answered there is no audio. The PJSIP trunk otherwise works great: Calls to/from PSTN, and even calls TO the softphone FROM the PBX all work no problem.

And if you change from a PJSIP trunk to a Chan_SIP trunk, the inbound calls from the softphone work just fine as well.

These kinds of NAT issues plagued Chan_SIP early in its development. But, now that its a mature, stable platform, they’re all worked out. Eventually, they will be worked out with PJSIP as well. They may well be now - again, I was using a machine that was about a year old.

But, since chan_sip is a mature, stable, platform that works, why bother?

I’d suggest your real problem is that you haven’t specified public addresses. chan_pjsip can handle that for two different addresses, but chan_sip can’t. force rport seems to do more than is documented, in that it seems to set rport on requests, as well as assuming it on responses. It is possible that, for some configurations that might work round the lack of public addresses, but force rport always has been a work around for inadequate support for NAT (normally in a peer that is behind NAT, though, rather than your case, where it is Asterisk that is behind NAT.

Also your problem is described as lack of media, but force rport doesn’t affect media. The option to work around the lack of the proper use of public addresses on media is comedia. Also, in your scenario, the media address on the soft phone is only relevant to Asterisk if Callcentric are setting up the session of direct media… That is going to break with other people they call, even if specifying comedia solves it with your PBX; the soft phone needs to be configured to know that it is behind NAT and how to find its own public address.

rport set to Yes:

[root@yplab ~]# asterisk -x"pjsip show endpoint TestTrunk" | grep force_rport
 force_rport                        : true

rport set to No:

[root@yplab ~]# asterisk -x"pjsip show endpoint TestTrunk" | grep force_rport
 force_rport                        : false

ETA - This is on FreePBX14

1 Like

I have specified the public addresses both for chan_sip and PJSIP.

In the case that I described, both machines were behind a NAT.

That is precisely why I said that these were two separate issues. the force_rport is a FreePBX PJSIP module issue. The RTP is a PJSIP/Asterisk issue.

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