I finally gave up chan_sip for chan_pjsip and it was fine

I just say things. Sometimes people listen, sometimes people do things.

1 Like

Today I found that the WebRTC phone doesn’t work over IPv6, but does work over IPv4. Investigating. I’m mentioning it in this thread because the error generated is:

[2019-10-04 10:01:46] ERROR[29983]: res_pjsip.c:3662 ast_sip_create_dialog_uas: Could not create dialog with endpoint 991101. Invalid URI (PJSIP_EINVALIDURI)

May be due to this issue[1] which has had a fix merged in recently[2].

[1] https://issues.asterisk.org/jira/browse/ASTERISK-28544
[2] https://gerrit.asterisk.org/c/asterisk/+/12986

Might be the same or a fresh new bug:

[2019-10-04 10:33:14] DEBUG[32275]: res_pjsip_transport_websocket.c:448 websocket_on_rx_msg: Request msg INVITE/cseq=9908 (rdata0x7fae503937b8) re-writing Contact URI from ibef549gpid8.invalid:0;transport=wss to [2601:xxx:xxx:xxx:xxx:xxx:xxx:yyy]:55257;transport=ws

I’m suspicious of how ;transport=wss becomes ;transport=ws

That should be okay. That logic is updating the received Contact to enforce connection reuse, and due to the way things work internally being "ws’ is pefectly fine. If it were “wss” it wouldn’t actually work. The spec also states that the transport parameter should be “ws” for URIs[1]. WSS is only valid in the Via header.

[1] https://tools.ietf.org/html/rfc7118#page-6

1 Like

Confirmed; rtp_ipv6 does not need to be set.

1 Like

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

There’s also a problem in FreePBX that results in the PJSIP Match option being ignored when Registration = Receive: https://issues.freepbx.org/browse/FREEPBX-18559

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

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?

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).

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.

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.

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.


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.

1 Like

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.

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.

1 Like

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.

1 Like

UPDATE - On Debian, there is a global OS-level setting that specifies the minimum TLS version, found in /etc/ssl/openssl.cnf. (https://stackoverflow.com/a/53065682) 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.

1 Like

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.

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.

1 Like

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.