Need help converting to pjsip

Asterisk Asterisk SIP
1

Here are the errors I’m getting:

ERROR[29414]: res_pjsip.c:3483 ast_sip_set_tpselector_from_transport_name: Unable to retrieve PJSIP transport 'transport-tls'

WARNING[29414]: res_pjsip_outbound_registration.c:829 schedule_retry: No response received from 'sip:x.x.x.x:5061' on registration attempt to 'sip:xxx@x.x.x.x:5061', retrying in '20'

Here is my converted pjsip.conf, I used the python tool to convert my sip.conf to this:

[transport-udp]
type = transport
protocol = udp
bind = 0.0.0.0
external_media_address = x.x.x.x
external_signaling_address = x.x.x.236
local_net = 10.9.9.0/255.255.255.240
local_net = 10.5.5.0/255.255.255.0

[transport-tcp]
type = transport
protocol = tcp
bind = 0.0.0.0
external_media_address = x.x.x.236
external_signaling_address = x.x.x.236
local_net = 10.9.9.0/255.255.255.240
local_net = 10.5.5.0/255.255.255.0

[transport-tls]
type = transport
protocol = tls
bind = 10.9.9.13
external_media_address = x.x.x.236
external_signaling_address = x.x.x.236
local_net = 10.9.9.0/255.255.255.240
local_net = 10.5.5.0/255.255.255.0
cert_file = /etc/asterisk/keys/asterisk-10y.pem
cipher = ALL
ca_list_file = /etc/asterisk/keys/ca-10y.crt
verify_server = no
method = tlsv1

[reg_x.x.x.163]
type = registration
retry_interval = 20
max_retries = 10
expiration = 120
transport = transport-tls
outbound_auth = auth_reg_x.x.x.163
client_uri = sip:xxx@x.x.x.163:5061
server_uri = sip:x.x.x.163:5061

[auth_reg_x.x.x.163]
type = auth
password = xxx
username = xxx

[VoIPms]
type = aor
contact = sip:xxx@x.x.x.163

[VoIPms]
type = identify
endpoint = VoIPms
match = x.x.x.163

[VoIPms]
type = auth
username = VoIPms
password = xxx

[VoIPms]
type = endpoint
context = from-trunk
dtmf_mode = rfc4733
disallow = all
allow = ulaw
rtp_symmetric = yes
force_rport = yes
rewrite_contact = yes
disable_directed_media_on_nat = yes
direct_media = no
trust_id_inbound = yes
send_rpid = yes
media_encryption = sdes
auth = VoIPms
outbound_auth = VoIPms
aors = VoIPms

[301]
type = aor
max_contacts = 1

[301]
type = auth
username = 301
password = xxx

[301]
type = endpoint
context = internal-kids
dtmf_mode = rfc4733
disallow = all
allow = ulaw
rtp_symmetric = yes
force_rport = yes
rewrite_contact = yes
direct_media = no
callerid = 301
mailboxes = 303@internal
device_state_busy_at = 4
auth = 301
outbound_auth = 301
srtp_tag_32 = yes
aors = 301

[302]
type = aor
max_contacts = 1

[302]
type = auth
username = 302
password = xxx

[302]
type = endpoint
context = internal-home
dtmf_mode = rfc4733
disallow = all
allow = ulaw
rtp_symmetric = yes
force_rport = yes
rewrite_contact = yes
direct_media = no
callerid = 302
mailboxes = 302@internal
device_state_busy_at = 4
auth = 302
outbound_auth = 302
srtp_tag_32 = yes
aors = 302

[303]
type = aor
max_contacts = 1

[303]
type = auth
username = 303
password = xxx

[303]
type = endpoint
context = internal-work
dtmf_mode = rfc4733
disallow = all
allow = ulaw
rtp_symmetric = yes
force_rport = yes
rewrite_contact = yes
direct_media = no
callerid = 303
mailboxes = 301@internal
device_state_busy_at = 4
auth = 303
outbound_auth = 303
srtp_tag_32 = yes
aors = 303

[304]
type = aor
max_contacts = 1

[304]
type = auth
username = 304
password = xxx

[304]
type = endpoint
context = internal-home
dtmf_mode = rfc4733
disallow = all
allow = ulaw
rtp_symmetric = yes
force_rport = yes
rewrite_contact = yes
direct_media = no
callerid = 304
mailboxes = 304@internal
auth = 304
outbound_auth = 304
aors = 304

[305]
type = aor
max_contacts = 1

[305]
type = auth
username = 305
password = xxx

[305]
type = endpoint
context = internal-work
dtmf_mode = rfc4733
disallow = all
allow = ulaw
rtp_symmetric = yes
force_rport = yes
rewrite_contact = yes
direct_media = no
callerid = 305
mailboxes = 305@internal
device_state_busy_at = 4
auth = 305
outbound_auth = 305
srtp_tag_32 = yes
aors = 305

[306]
type = aor
max_contacts = 1

[306]
type = auth
username = 306
password = xxx

[306]
type = endpoint
context = internal-home
dtmf_mode = rfc4733
disallow = all
allow = ulaw
rtp_symmetric = yes
force_rport = yes
rewrite_contact = yes
direct_media = no
callerid = 306
mailboxes = 306@internal
device_state_busy_at = 4
auth = 306
outbound_auth = 306
srtp_tag_32 = yes
aors = 306

[307]
type = aor
max_contacts = 1

[307]
type = auth
username = 307
password = xxx

[307]
type = endpoint
context = internal-home
dtmf_mode = rfc4733
disallow = all
allow = ulaw
rtp_symmetric = yes
force_rport = yes
rewrite_contact = yes
direct_media = no
callerid = 307
mailboxes = 307@internal
auth = 307
outbound_auth = 307
aors = 307

If anyone else notices something off please let me know. Struggling with PJSIP. :frowning:

2

Check the console at startup to see why the TLS transport could not be created.

3

I’ve made some progress, but this is killing it right now:

[Jul 26 16:28:23] WARNING[41646]: pjproject: <?>:                          SSL SSL_ERROR_SSL (Handshake): Level: 0 err: <336151568> <SSL routines-ssl3_read_bytes-sslv3 alert handshake failure> len: 0 peer: x.x.x.163:5061

[Jul 26 16:28:23] WARNING[41647]: res_pjsip_outbound_registration.c:829 schedule_retry: No response received from 'sip:x.voip.ms:5061' on registration attempt to 'sip:xxx@x.voip.ms:5061', retrying in '20'

Is that something with my cert? Cipher?

4

I’d expect it to be your cipher or method. If you set the method to tlsv1_2 does it change?

1 Like
5

Why is your bind not 0.0.0.0 as with the other transports?
Do you have the original sip.conf? I wonder what was not converted correctly.

And, please, could someone edit the Wiki entry about SIP-over-TLS? cipher = ALL and method = tlsv1 are a drama (simply leave them away, and good defaults are used) which was in the original sip.conf already, I guess.

6

OMG, the method to tlsv1_2 got it! THANK YOU!!!

7

The wiki page has been updated and method removed for PJSIP.

8

From CentOS 8 and Debian 10, default openssl configuration accept only tlsv1_2

En Debian 10 you can change this behavior modifying this parameter:

MinProtocol = TLSv1.2

on this file:

/etc/ssl/openssl.cnf

Regards

9

Yeah my old Asterisk 13/chan_sip was CentOS7 and on this VM it’s CentOS8 and Asterisk 16/pj_sip, so makes sense.

10

For chan_pjsip, please, use
method=sslv23

For an explanation, please, see my comment in the conversion script itself.

Mhm. Actually, I was about chan_sip which was the cause for this confusion here. For chan_sip, that Wiki page shows tlsclientmethod=tlsv1. That disables not only SSL 3 but TLS 1.2, too. In chan_sip, the solution is: Do not specify tlsclientmethod at all, then a ‘good’ default is used. It gets the default of the platform, the platform OpenSSL configuration. Without tlsclientmethod, then, the conversion script creates a ‘good’ default for chan_pjsip: method=sslv23.

In chan_pjsip, the default value of method is empty which disables all TLS versions. Just because of a side-effect, on a OpenSSL 1.1 based system, this disables all TLS versions except TLS 1.3 because TLS 1.3 cannot be disabled the way the PJProject does it right now.

And there is another issue: On a recent Debian based system like Debian 10 (Buster) or Ubuntu 20.04 LTS, the default OpenSSL Security Level is 2 (see page 4 table i). Previous Debian/Ubuntu versions lowered the level from 2 to zero but not anymore. Additionally, Debian (via the patch Set-systemwide-default-settings-for-libssl-users.patch) and Canonical (via the patch tls1.2-min-seclevel2.patch) require TLS 1.2 in Security Level 2 already. Consequently, on recent Debian based systems, not only SSL 3 but also TLS 1.0 and TLS 1.1 are disabled on default.

That has three implications for Ubuntu 20.04 LTS:

  1. If chan_sip had tlsclientmethod=tlsv1 and this is converted to method=tlsv1, chan_pjsip uses only TLS 1.3, making it incompatible with near to every phone and service on this earth.
  2. In chan_sip, the administrator was able to repair this by using tlscipher=DEFAULT@SECLEVEL=1 for example. In chan_pjsip, this is not possible because the PJProject converts the cipher string internally. The PJProject does not know about SECLEVEL and rejects a cipher string with a SECLEVEL appended.
  3. Instead, to re-enable TLS 1.0 which is still the maximum of many phones and services out there, the user has to change the system-wide configuration of OpenSSL.

No standard user of Digium Asterisk is going to understand all this. Joshua, can we discuss this via a different communication channel, preferable via phone, what to do, what can be done, and how to improve the user experience in this regard? Otherwise this will not only be an endless compatibility issue for users but also creates security related configuration errors.

Therefore, when it comes to that Wiki page, for chan_pjsip method=sslv23 and for chan_sip not specifying tlsclientmethod at all, that is my recommendation. Furthermore, tlscipher=ALL for chan_sip has to go for sure; the default is then used which is tlscipher=DEFAULT.

11

I have updated the wiki page with your recommendations. A complete overhaul of documentation in this regard is not something I can do right now or take on, I would suggest writing up your thoughts in an issue so it can actually go into the queue to be looked into. After that if verbal communication is needed then the individual working the issue can do so.

12

The problem is not only the documentation. The problem is the way PJProject proxies OpenSSL. I am not sure that is the correct path on the long term, and that the Asterisk team understands the implications already. This is not a software issue as you know it. This is about Usable Security. Can you please escalate these concerns to someone who queues you guys.

13

From a Sangoma perspective @lgaetz would be the individual who does that for the Asterisk team, but without an issue and explanation of concerns and what you believe I don’t know what he will do. I have linked him to this thread as well.

Having an issue and discussions is also part of being open within the Asterisk project. It’s not just Sangoma working on things, but there are other people who like to participate.

14

There are issues which are no issues. Those are non-functional requirements. Other way round: Let us take this complain here as issue report. The technical solution is to use sslv23 or tlsv12. Both are working for Zermus but not one is what he is going to achieve (workaround versus solution). That is the non-technical part. Furthermore, this issue is going to re-occur and re-occur (expensive support). I see that. The issue is already here, in front of you. And you do not see it. I love to explain things but I cannot catch everyone with text. I am limited as well. Therefore, one approach is to tackle this in a two-way conversation.

I can change all those issues for me personally, easily. Why should I invest time, catch your level of knowledge, and document something, which I fixed via the platform OpenSSL configuration in seconds? This has nothing to do with openness but with limits in the possibility to explain something in text. I can only offer my help here.

15

I have asked @lgaetz to take point on this, if technical level resources are required then he is able to schedule things.

16

Hello @traud

Lorne Gaetz here, I’m the PM for the Asterisk and FreePBX projects. As Josh said, if you want to discuss doc changes beyond trivial edits, it starts with a ticket so the team can review the suggestions properly. Please open a ticket at https://issues.asterisk.org/jira

17

I am not (only) about the documentation but the architecture (or use) of PJProject (and its use of OpenSSL). I do not have an issue personally. Therefore, I cannot open an issue. This is a so called Illity. This Illity is obvious from this complain here in this thread. I explained it to my very best. I cannot transform it further. If you do not see the Illity, I can offer (only) verbal communication to explain it. That might fail either, but that would be the one approach, I see. Beyond that, I do not know how to help. If you see the issue but do not transform it yourself to further steps, I cannot help either.

However, I am aware that Product Managers and Technical Engineers lack the sometimes required motivation to transform issues like in this thread. In such a case, I recommend to double-check with the Usable Security Engineer. If such a role is not available, double-check with both your local Security Engineer and local Usability Engineer within Sangoma.

I do not have any issue. I explained why the proposed workaround is a workaround, and which other alternatives might be better. I solved the problem for me by changing the system configuration of OpenSSL. The same way, Annus Fictus went (and everyone who has the same error message and then finds this thread and the possible workarounds).

18

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