I finally gave up chan_sip for chan_pjsip and it was fine

[billsimon]

@jcolp

If after testing it works as expected for you I’ll update the wiki page!

Confirmed; rtp_ipv6 does not need to be set.

[jcolp (Joshua Colp)]

I’ve gone ahead and updated the wiki page to state nothing additional is required for RTP.

[reraikes (RonR)]

@lgaetz

For those relying on the Match field for pjsip trunks, know that the Firewall module does not whitelist these IPs automatically as is done for the SIP Server . I have an open feature request for this: https://issues.freepbx.org/browse/FREEPBX-18741

There’s also a problem in FreePBX that results in the PJSIP Match option being ignored when Registration = Receive: [FREEPBX-18559] PJSIP Match Option Ignored when Registration = Receive - Sangoma Issue Tracker

Why do issues like these remain open for 11 months with no action?

[billsimon]

I’m curious what the use case is there. If you are expecting the endpoint to register to Asterisk, that means you don’t know its IP address. So why would you use the Match field in this situation?

[reraikes (RonR)]

I use an OBi202 paired to my iPhone as a GSM trunk. The OBi registers to Asterisk. Without manually adding a type=identify section in pjsip_custom_post.conf containing a match=w.x.y.z, Asterisk fails to recognize the endpoint (unless ‘Allow Anonymous Inbound SIP Calls’ is enabled to catch it).

[billsimon]

Seems strange that Asterisk would not recognize a registered endpoint.

At the same time, if you know the IP of the device (which you must if you are putting a match=IP) then why register. Just set it up as a static IP trunk and be done.

[reraikes (RonR)]

@billsimon

At the same time, if you know the IP of the device (which you must if you are putting a match=IP) then why register. Just set it up as a static IP trunk and be done.

It’s a static DHCP assignment, so I could, but I’m a fan of registered trunk connections where possible. Nevertheless, it’s clearly a bug that’s trivial to fix yet it’s sat unassigned for 11 months.

[avayax (Johann Zurner)]

@reraikes

Without manually adding a type=identify section in pjsip_custom_post.conf containing a match=w.x.y.

You don’t need to do that.
You can set match inbound authentication to Auth Username in your pjsip trunk advanced setting and it’ll work with registration receive.

That being said, the only purpose of registration is to let Asterisk know the IP address of the endpoint. If it’s static you don’t need it and can just use qualify if you want to know if the endpoint is reachable.

[reraikes (RonR)]

I think the point of my bug report is being missed. (I solved the immediate problem with a manual entry in pjsip custom conf, but this shouldn’t have been necessary.)

Regardless of whether there are alternative ways to get an endpoint to work in this particular case, FreePBX is totally ignoring the value being placed in the ‘Match (Permit)’ option and is not generating a ‘type=identify’ block as it should. If it had, we wouldn’t be having this discussion.

[avayax (Johann Zurner)]

@reraikes

I think the point of my bug report is being missed

Not creating the identify section on registration receive is not really a bug as the identify section is not a requirement.
In fact if you don’t have an identify section defined Asterisk by default will identify inbound traffic by pulling the user from the “From:” SIP header in the packet.
https://wiki.asterisk.org/wiki/display/AST/PJSIP+Configuration+Sections+and+Relationships

This is where it breaks but you can change the way Asterisk identifies the packet via the Match Inbound Authentication option under PJSIP trunk advanced settings.

[BlazeStudios (Tom Ray)]

@reraikes

If it had, we wouldn’t be having this discussion

I hate to be that guy but if you understood how PJSIP handles authentication, we wouldn’t be having this conversation.

The default identify_by= is username, ip, auth_name, header. Order matters because the first match wins everything. That would mean the following:

→ Setting the Auth Type to “Receive” means you want to auth via user/pass. So that would be username so that would be ordered first.
→ Wanting to use the Match against IP(s) auth would make the ip auth method ordered first.

So FreePBX logic looks at it as Receive = Wanting to use user/pass to auth with because you don’t know the IP of the other side (could be dynamic) or None = Match by the Match field, be it IP or FQDN. It’s not both because once one of those method matchs the following are ignored.

Basically by adding your addition to the custom conf files, you’ve bypassed the username auth entirely and made it moot.

EDIT: If you want to use both user/pass AND restrict it to specific IP(s) then you need to use the Permit/Deny ACLs in PJSIP. Which at that point, would be a feature request as I don’t think those are supported in the GUI anywhere.

[billsimon]

@billsimon

Also, old endpoints seem to have a really hard time negotiating with modern TLS and even though I worked at it for a long time, I couldn’t come up with a TLS configuration on FreePBX that was acceptable to an Obi 110.

UPDATE - On Debian, there is a global OS-level setting that specifies the minimum TLS version, found in /etc/ssl/openssl.cnf. (openvpn - How do I manage the error "OpenSSL v1.1.1 ssl_choose_client_version unsupported protocol"? - Stack Overflow) In Debian 10, the minimum is set at TLSv1.2. As a result, no matter how you set the TLS version in Asterisk SIP Settings - pjsip section, the system will require TLSv1.2. Unfortunately for old Obi 110, it can only do TLSv1. I also tested a Grandstream HT-502, and it’s only able to do TLSv1.1. (Latest firmware on both)

If you have older endpoints that can’t do TLSv1.2, and you’re not super concerned about the security issues of older TLS versions, you can update the global OS setting and the PJSIP setting to get your old devices working again on TLS transport.

[BlazeStudios (Tom Ray)]

@billsimon

If you have older endpoints that can’t do TLSv1.2, and you’re not super concerned about the security issues of older TLS versions, you can update the global OS setting and the PJSIP setting to get your old devices working again on TLS transport.

Doesn’t this defeat the purpose? If security is that much of a concern that you’re deploying a TLS based setup, be it for provisioning or calls, wouldn’t using a known bad version of TLS negate that? It’s not secure. It can be hacked. The exploits are well known.

To me, if security is that much of a concern that you’re deploying TLS for your VoIP setup then you should be using devices that can support modern and standard TLS versions.

[billsimon]

I agree with your statement of caution.

I am presenting my findings as information, not as recommendation. Everyone should decide on whatever security level is most suitable.

For the PBX I am currently working on, it is enough to keep the casual snoop from seeing plaintext SIP traffic. I do not require any higher grade of security than that.

[BlazeStudios (Tom Ray)]

@billsimon

it is enough to keep the casual snoop from seeing plaintext SIP traffic

I’m not sure what they are going to snoop in plaintext over your SIP traffic. While the user/domain might be there the password is never sent in a SIP message, the nonce is unique and has a very sparse lifespan and can’t be reused.

Now the provisioning traffic, that’s a different beast because then your account details could be exposed in plaintext.

But seriously, the amount of work it would take to snoop your SIP traffic would mean that you had something worth snooping. The average user isn’t getting snooped on.