Re: [asterisk-users] Dahdi start up under systemctl
'/etc/init.d/dahdi [status,start,stop,restart]' works under a systemd system, as stated in /etc/init.d/README: Note that traditional init scripts continue to function on a systemd system. An init script /etc/rc.d/init.d/foobar is implicitly mapped into a service unit foobar.service during system initialization. On Fri, Apr 8, 2022 at 3:43 AM Jerry Geis wrote: > What is the command to install dahdi on a systemctl type startup ? > > I just installed dahdi from git (so latest) and did : > > cd dahdi-linux-complete > ls shows > dahdi-linux and dahdi-tools > find . | grep service > shows nothing. > > in dahdi-tools there is the OLD dahdi.init file - but that is the OLD > init.d > > Thanks > > Jerry > -- > _ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > Check out the new Asterisk community forum at: > https://community.asterisk.org/ > > New to Asterisk? Start here: > https://wiki.asterisk.org/wiki/display/AST/Getting+Started > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: >http://lists.digium.com/mailman/listinfo/asterisk-users -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- Check out the new Asterisk community forum at: https://community.asterisk.org/ New to Asterisk? Start here: https://wiki.asterisk.org/wiki/display/AST/Getting+Started asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Hangup() not working for handsets using pls transport?
I was able to get on the UI of the Yealink T32G and fiddle with the setting. Here's the setting for TLS transport in /etc/asterisk/extensions.conf: [transport-tls] type = transport protocol = tls bind = 0.0.0.0:5061 ; ca_list_file = /etc/asterisk/keys/ca.crt ; cert_file = /etc/asterisk/keys/asterisk.crt ; priv_key_file = /etc/asterisk/keys/asterisk.key cert_file = /etc/asterisk/keys/fullchain.pem priv_key_file = /etc/asterisk/keys/privkey.pem method = tlsv1_2 allow_reload = true Using FQHN for sip server still results in the same error with the phone failing to registered: [Feb 12 16:55:33] WARNING[2080] pjproject:SSL SSL_ERROR_SSL (Handshake): Level: 0 err: <336027900> len: 0 peer: 128.171.77.34:45830 I tried to upload my cert.pem (by Letsencrypt) to the phone as one of the trusted certificates and check "accept only trusted certificates". It didn't help. Nor does unchecking "accept only trusted certificates''. There seem to be some reports in freepbx forum re trouble setting up yearlink phones with tls transport: https://community.freepbx.org/t/tls-freepbx-and-yealink/59174 Yealink's writeup re using security certificates was for certain models/firmware levels, and mine isn't among them. I guess I'll probably have to accept that the few Yealink T32G will not play nice with TLS transport and buy the "sanctioned" models when rolling out the new Asterisk 16.14 server. I may also try my luck with the Cisco 7940/7960 phones that populate most of our offices. Thanks, --Ruisheng On Fri, Feb 12, 2021 at 3:13 PM Ruisheng Peng wrote: > Thanks Joshua for the tip re using hostname rather than IP address when > configuring the phone. It worked nicely on the linphone on my macbookpro > at home. Dialplans are followed faithfully w/o the problems I experienced > earlier. I'll test using the hostname on the Yealink phone next time I'm > in office. > > Thanks, > > --Ruisheng > > On Fri, Feb 12, 2021 at 4:48 AM Joshua C. Colp wrote: > >> On Thu, Feb 11, 2021 at 9:01 PM Ruisheng Peng >> wrote: >> >>> Sorry, my bad. I failed to change the transport to tls on the provision >>> for the hardphone, nor did change the transport on the linphone setup. >>> However, after I do that, the hardphone (Yealink T32G) failed to register, >>> citing: >>> >>> [Feb 11 14:16:03] WARNING[24936]: pjproject: : >>> SSL SSL_ERROR_SSL (Handshake): Level: 0 err: <336027900> >> routines-SSL23_GET_CLIENT_HELLO-unknown protocol> len: 0 peer: >>> 128.171.77.34:30401 >>> >> >> This would be caused by the TLS transport configuration on Asterisk or >> the phone potentially. You'd need to provide the transport definition from >> pjsip.conf. Without that I can say the "method" option is likely needing >> changing. I'm not familiar with what is supported by Yealink. >> >> >>> on the linphone side, it also fails to register: >>> >>> 2021-02-11 13:26:32:637 [linphone/belle-sip] MESSAGE Trying to connect >>> to [TLS://:::128.171.77.23:5061] >>> >>> 2021-02-11 13:26:32:652 [linphone/belle-sip] MESSAGE Channel >>> [0x7fc8b800]: Connected at TCP level, now doing TLS handshake with >>> cname=128.171.77.23 >>> >>> 2021-02-11 13:26:32:654 [linphone/belle-sip] MESSAGE Channel >>> [0x7fc8b800]: SSL handshake in progress... >>> >>> 2021-02-11 13:26:32:674 [linphone/belle-sip] MESSAGE Found certificate >>> depth=[2], flags=[]: >>> >>> cert. version : 3 >>> >>> serial number : 44:AF:B0:80:D6:A3:27:BA:89:30:39:86:2E:F8:40:6B >>> >>> issuer name : O=Digital Signature Trust Co., CN=DST Root CA X3 >>> >>> subject name : O=Digital Signature Trust Co., CN=DST Root CA X3 >>> >>> issued on: 2000-09-30 21:12:19 >>> >>> expires on: 2021-09-30 14:01:15 >>> >>> signed using : RSA with SHA1 >>> >>> RSA key size : 2048 bits >>> >>> basic constraints : CA=true >>> >>> key usage : Key Cert Sign, CRL Sign >>> >>> >>> 2021-02-11 13:26:32:674 [linphone/belle-sip] MESSAGE Found certificate >>> depth=[1], flags=[]: >>> >>> cert. version : 3 >>> >>> serial number : 40:01:75:04:83:14:A4:C8:21:8C:84:A9:0C:16:CD:DF >>> >>> issuer name : O=Digital Signature Trust Co., CN=DST Root CA X3 >>> >>> subject name : C=US, O=Let's Encrypt, CN=R3 >>> >>> issued on: 2020-10-07 19:21:40 >&g
Re: [asterisk-users] Hangup() not working for handsets using pls transport?
Thanks Joshua for the tip re using hostname rather than IP address when configuring the phone. It worked nicely on the linphone on my macbookpro at home. Dialplans are followed faithfully w/o the problems I experienced earlier. I'll test using the hostname on the Yealink phone next time I'm in office. Thanks, --Ruisheng On Fri, Feb 12, 2021 at 4:48 AM Joshua C. Colp wrote: > On Thu, Feb 11, 2021 at 9:01 PM Ruisheng Peng > wrote: > >> Sorry, my bad. I failed to change the transport to tls on the provision >> for the hardphone, nor did change the transport on the linphone setup. >> However, after I do that, the hardphone (Yealink T32G) failed to register, >> citing: >> >> [Feb 11 14:16:03] WARNING[24936]: pjproject: :SSL >> SSL_ERROR_SSL (Handshake): Level: 0 err: <336027900> > routines-SSL23_GET_CLIENT_HELLO-unknown protocol> len: 0 peer: >> 128.171.77.34:30401 >> > > This would be caused by the TLS transport configuration on Asterisk or the > phone potentially. You'd need to provide the transport definition from > pjsip.conf. Without that I can say the "method" option is likely needing > changing. I'm not familiar with what is supported by Yealink. > > >> on the linphone side, it also fails to register: >> >> 2021-02-11 13:26:32:637 [linphone/belle-sip] MESSAGE Trying to connect to >> [TLS://:::128.171.77.23:5061] >> >> 2021-02-11 13:26:32:652 [linphone/belle-sip] MESSAGE Channel >> [0x7fc8b800]: Connected at TCP level, now doing TLS handshake with >> cname=128.171.77.23 >> >> 2021-02-11 13:26:32:654 [linphone/belle-sip] MESSAGE Channel >> [0x7fc8b800]: SSL handshake in progress... >> >> 2021-02-11 13:26:32:674 [linphone/belle-sip] MESSAGE Found certificate >> depth=[2], flags=[]: >> >> cert. version : 3 >> >> serial number : 44:AF:B0:80:D6:A3:27:BA:89:30:39:86:2E:F8:40:6B >> >> issuer name : O=Digital Signature Trust Co., CN=DST Root CA X3 >> >> subject name : O=Digital Signature Trust Co., CN=DST Root CA X3 >> >> issued on: 2000-09-30 21:12:19 >> >> expires on: 2021-09-30 14:01:15 >> >> signed using : RSA with SHA1 >> >> RSA key size : 2048 bits >> >> basic constraints : CA=true >> >> key usage : Key Cert Sign, CRL Sign >> >> >> 2021-02-11 13:26:32:674 [linphone/belle-sip] MESSAGE Found certificate >> depth=[1], flags=[]: >> >> cert. version : 3 >> >> serial number : 40:01:75:04:83:14:A4:C8:21:8C:84:A9:0C:16:CD:DF >> >> issuer name : O=Digital Signature Trust Co., CN=DST Root CA X3 >> >> subject name : C=US, O=Let's Encrypt, CN=R3 >> >> issued on: 2020-10-07 19:21:40 >> >> expires on: 2021-09-29 19:21:40 >> >> signed using : RSA with SHA-256 >> >> RSA key size : 2048 bits >> >> basic constraints : CA=true, max_pathlen=0 >> >> key usage : Digital Signature, Key Cert Sign, CRL Sign >> >> ext key usage : TLS Web Server Authentication, TLS Web Client >> Authentication >> >> >> 2021-02-11 13:26:32:674 [linphone/belle-sip] MESSAGE Found certificate >> depth=[0], flags=[CN-mismatch ]: >> >> cert. version : 3 >> >> serial number : 03:F0:83:3C:5D:41:76:BC:4E:B2:E6:AB:60:8C:F9:5E:27:86 >> >> issuer name : C=US, O=Let's Encrypt, CN=R3 >> >> subject name : CN=voip1.ifa.hawaii.edu >> >> issued on: 2020-12-30 02:56:29 >> >> expires on: 2021-03-30 02:56:29 >> >> signed using : RSA with SHA-256 >> >> RSA key size : 2048 bits >> >> basic constraints : CA=false >> >> subject alt name : voip1.ifa.hawaii.edu >> >> key usage : Digital Signature, Key Encipherment >> >> ext key usage : TLS Web Server Authentication, TLS Web Client >> Authentication >> >> >> 2021-02-11 13:26:32:674 [linphone/belle-sip] ERROR Channel >> [0x7fc8b800]: SSL handshake failed : X509 - Certificate verification >> failed, e.g. CRL, CA or signature check failed >> >> 2021-02-11 13:26:32:674 [linphone/belle-sip] ERROR Cannot connect to >> [TLS://128.171.77.23:5061] >> > > I don't use linphone or have any experience so can only provide general > comments. Either the certificate chain is incomplete and the client can't > verify, or the client doesn't have the certificate authority root > certificat
Re: [asterisk-users] Hangup() not working for handsets using pls transport?
Sorry, my bad. I failed to change the transport to tls on the provision for the hardphone, nor did change the transport on the linphone setup. However, after I do that, the hardphone (Yealink T32G) failed to register, citing: [Feb 11 14:16:03] WARNING[24936]: pjproject: :SSL SSL_ERROR_SSL (Handshake): Level: 0 err: <336027900> len: 0 peer: 128.171.77.34:30401 on the linphone side, it also fails to register: 2021-02-11 13:26:32:637 [linphone/belle-sip] MESSAGE Trying to connect to [TLS://:::128.171.77.23:5061] 2021-02-11 13:26:32:652 [linphone/belle-sip] MESSAGE Channel [0x7fc8b800]: Connected at TCP level, now doing TLS handshake with cname=128.171.77.23 2021-02-11 13:26:32:654 [linphone/belle-sip] MESSAGE Channel [0x7fc8b800]: SSL handshake in progress... 2021-02-11 13:26:32:674 [linphone/belle-sip] MESSAGE Found certificate depth=[2], flags=[]: cert. version : 3 serial number : 44:AF:B0:80:D6:A3:27:BA:89:30:39:86:2E:F8:40:6B issuer name : O=Digital Signature Trust Co., CN=DST Root CA X3 subject name : O=Digital Signature Trust Co., CN=DST Root CA X3 issued on: 2000-09-30 21:12:19 expires on: 2021-09-30 14:01:15 signed using : RSA with SHA1 RSA key size : 2048 bits basic constraints : CA=true key usage : Key Cert Sign, CRL Sign 2021-02-11 13:26:32:674 [linphone/belle-sip] MESSAGE Found certificate depth=[1], flags=[]: cert. version : 3 serial number : 40:01:75:04:83:14:A4:C8:21:8C:84:A9:0C:16:CD:DF issuer name : O=Digital Signature Trust Co., CN=DST Root CA X3 subject name : C=US, O=Let's Encrypt, CN=R3 issued on: 2020-10-07 19:21:40 expires on: 2021-09-29 19:21:40 signed using : RSA with SHA-256 RSA key size : 2048 bits basic constraints : CA=true, max_pathlen=0 key usage : Digital Signature, Key Cert Sign, CRL Sign ext key usage : TLS Web Server Authentication, TLS Web Client Authentication 2021-02-11 13:26:32:674 [linphone/belle-sip] MESSAGE Found certificate depth=[0], flags=[CN-mismatch ]: cert. version : 3 serial number : 03:F0:83:3C:5D:41:76:BC:4E:B2:E6:AB:60:8C:F9:5E:27:86 issuer name : C=US, O=Let's Encrypt, CN=R3 subject name : CN=voip1.ifa.hawaii.edu issued on: 2020-12-30 02:56:29 expires on: 2021-03-30 02:56:29 signed using : RSA with SHA-256 RSA key size : 2048 bits basic constraints : CA=false subject alt name : voip1.ifa.hawaii.edu key usage : Digital Signature, Key Encipherment ext key usage : TLS Web Server Authentication, TLS Web Client Authentication 2021-02-11 13:26:32:674 [linphone/belle-sip] ERROR Channel [0x7fc8b800]: SSL handshake failed : X509 - Certificate verification failed, e.g. CRL, CA or signature check failed 2021-02-11 13:26:32:674 [linphone/belle-sip] ERROR Cannot connect to [TLS:// 128.171.77.23:5061] On Mon, Feb 8, 2021 at 12:27 PM Joshua C. Colp wrote: > On Mon, Feb 8, 2021 at 6:14 PM Ruisheng Peng wrote: > >> Thanks Jashua for the suggestion. To find out if the issue was only >> limited to the softphone that was using tls transport (SOFTPHONE_B on ext >> 103, a linphone running off my MBP), I also turned one of the hard phone >> (f30A0A01 on ext 100, a Yealink T32G) into using tls transport. It >> behaves similarly to the linphone in that the Hangup() call in dialplan is >> silently ignored, and the handsets would alway appear as busy/unavilable. >> > > Have you configured the devices, on them or using their provisioning, to > use TLS? It does not appear so as they are using UDP, while you're forcing > a TLS transport in Asterisk. This would not work. > > -- > Joshua C. Colp > Asterisk Technical Lead > Sangoma Technologies > Check us out at www.sangoma.com and www.asterisk.org > -- > _ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > Check out the new Asterisk community forum at: > https://community.asterisk.org/ > > New to Asterisk? Start here: > https://wiki.asterisk.org/wiki/display/AST/Getting+Started > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: >http://lists.digium.com/mailman/listinfo/asterisk-users -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- Check out the new Asterisk community forum at: https://community.asterisk.org/ New to Asterisk? Start here: https://wiki.asterisk.org/wiki/display/AST/Getting+Started asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Hangup() not working for handsets using pls transport?
quot;
vm-nobodyavail") in new stack
<--- Transmitting SIP response (847 bytes) to UDP:128.171.77.48:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 128.171.77.48:5060
;received=128.171.77.48;branch=z9hG4bK6781e064
Call-ID: 00075083-381f0006-5e26f0de-139ba68a@128.171.77.48
From: "Ciscophone_325" ;tag=00075083381f5e4813be2318-77037fde
To: ;tag=b96a041f-35c1-406f-8cd5-7029dfaad3f4
CSeq: 102 INVITE
Server: Asterisk PBX 16.14.0
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE,
CANCEL, UPDATE, PRACK, MESSAGE, REFER
Contact:
Supported: 100rel, timer, replaces, norefersub
Content-Type: application/sdp
Content-Length: 225
v=0
o=- 25302 2 IN IP4 128.171.77.23
s=Asterisk
c=IN IP4 128.171.77.23
t=0 0
m=audio 17122 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv
> 0x7f0fa80057f0 -- Strict RTP switching to RTP target address
128.171.77.48:25298 as source
-- Playing 'vm-nobodyavail.slin'
(language 'en')
<--- Received SIP request (834 bytes) from UDP:128.171.77.48:50906 --->
ACK sip:128.171.77.23:5060 SIP/2.0
Via: SIP/2.0/UDP 128.171.77.48:5060;branch=z9hG4bK309268b1
From: "Ciscophone_325" ;tag=00075083381f5e4813be2318-77037fde
To: ;tag=b96a041f-35c1-406f-8cd5-7029dfaad3f4
Call-ID: 00075083-381f0006-5e26f0de-139ba68a@128.171.77.48
Max-Forwards: 70
Date: Sat, 06 Feb 2021 01:18:55 GMT
CSeq: 102 ACK
User-Agent: Cisco-CP7940G/8.0
Authorization: Digest username="f30B0B02",realm="asterisk",uri="
sip:100@128.171.77.23
",response="e4805ed40663b1345932a634488941b4",nonce="1612574334/f3c178b654f33965ce8a5aa89a50bcd0",opaque="654d62cc2c5bb89c",cnonce="28e5aea2",qop=auth,nc=0001,algorithm=md5
Remote-Party-ID: "Ciscophone_325" ;party=calling;id-type=subscriber;privacy=off;screen=yes
Content-Length: 0
-- Executing [100@sets:3] Hangup("PJSIP/f30B0B02-0016", "") in
new stack
== Spawn extension (sets, 100, 3) exited non-zero on
'PJSIP/f30B0B02-0016'
<--- Transmitting SIP request (499 bytes) to UDP:128.171.77.48:5060 --->
BYE sip:f30B0B02@128.171.77.48:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 128.171.77.23:5060
;rport;branch=z9hG4bKPje24627f6-0b3b-4b65-ab88-935a16a1100c
From: ;tag=b96a041f-35c1-406f-8cd5-7029dfaad3f4
To: "Ciscophone_325" ;tag=00075083381f5e4813be2318-77037fde
Call-ID: 00075083-381f0006-5e26f0de-139ba68a@128.171.77.48
CSeq: 29223 BYE
Reason: Q.850;cause=34
Max-Forwards: 70
User-Agent: Asterisk PBX 16.14.0
Content-Length: 0
<--- Received SIP response (439 bytes) from UDP:128.171.77.48:50906 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 128.171.77.23:5060
;rport;branch=z9hG4bKPje24627f6-0b3b-4b65-ab88-935a16a1100c
From: ;tag=b96a041f-35c1-406f-8cd5-7029dfaad3f4
To: "Ciscophone_325" ;tag=00075083381f5e4813be2318-77037fde
Call-ID: 00075083-381f0006-5e26f0de-139ba68a@128.171.77.48
Date: Sat, 06 Feb 2021 01:18:58 GMT
CSeq: 29223 BYE
Server: Cisco-CP7940G/8.0
Content-Length: 0
Thanks,
--Ruisheng
On Wed, Feb 3, 2021 at 11:44 PM Joshua C. Colp wrote:
> On Wed, Feb 3, 2021 at 11:02 PM Ruisheng Peng
> wrote:
>
>
>
> When using handsets with udp or tcp transports to dial ext 100, it'd
>> hangup after the no-one-arround message. However, when using the handset
>> with tls transport, it doesn't hang up on its own if ext 100 is not
>> answered. I have to click the hangup button to accomplish that. Here's
>> what asterisk log shows:
>>
>> == Setting global variable 'SIPDOMAIN' to '128.171.77.23'
>>
>> -- Executing [100@sets:1] Dial("PJSIP/SOFTPHONE_B-0007", "
>> PJSIP/f30A0A01,10,m") in new stack
>>
>> -- Called PJSIP/f30A0A01
>>
>> -- Started music on hold, class 'default', on channel
>> 'PJSIP/SOFTPHONE_B-0007'
>>
>>> 0x7f0fa801ede0 -- Strict RTP learning after remote address set
>> to: 128.171.168.233:7078
>>
>> -- PJSIP/f30A0A01-0008 is ringing
>>
>> -- PJSIP/f30A0A01-0008 is ringing
>>
>>> 0x7f0fa801ede0 -- Strict RTP switching to RTP target address
>> 128.171.168.233:7078 as source
>>
>>> 0x7f0fa801ede0 -- Strict RTP learning complete - Locking on
>> source address 128.171.168.233:7078
>>
>> -- Nobody picked up in 1 ms
>>
>> -- Stopped music on hold on PJSIP/SOFTPHONE_B-0007
>>
>> -- Executing [100@sets:2] Playback("PJSIP/SOFTPHONE_B-0007", "
>> vm-nobodyavail") in new stack
>>
>> -- Playing 'vm-nobodyavail.slin'
>> (language 'en')
>>
>> -- Executi
[asterisk-users] Hangup() not working for handsets using pls transport?
Hi all,
I managed to get tls transport going with asterisk 16.14.0, and set one
handset (SOFTPHONE_B) to use the transport. I have set up a few other
handsets (both soft and hard) to use udp and tcp transports:
voip1*CLI> pjsip show endpoints
Endpoint:
I/OAuth:
Aor:
Contact:
Transport:
Identify:
Match:
Channel:
Exten: CLCID:
==
Endpoint: f30A0A01 Not in
use0 of inf
InAuth: f30A0A01/f30A0A01
Aor: f30A0A01 1
Contact: f30A0A01/sip:f30A0A01@128.171.77.1 4800418965
NonQual nan
Transport: transport-udp udp 0 0 0.0.0.0:5060
Endpoint: f30B0B02 Not in
use0 of inf
InAuth: f30B0B02/f30B0B02
Aor: f30B0B02 1
Contact: f30B0B02/sip:f30B0B02@128.171.77.4 615cc2a2c6
NonQual nan
Transport: transport-udp udp 0 0 0.0.0.0:5060
Endpoint: SOFTPHONE_A
Unavailable 0 of inf
InAuth: SOFTPHONE_A/SOFTPHONE_A
Aor: SOFTPHONE_A2
Transport: transport-tcp tcp 0 0 0.0.0.0:5060
Endpoint: SOFTPHONE_B Not in
use0 of inf
InAuth: SOFTPHONE_B/SOFTPHONE_B
Aor: SOFTPHONE_B2
Contact: SOFTPHONE_B/sip:SOFTPHONE_B@128.171.168.23 78257ab30a
NonQual nan
Transport: transport-tls tls 0 0 0.0.0.0:5061
Objects found: 4
voip1*CLI>
For testing, I have the following in /etc/asterisk/extensions.conf:
[globals]
; General internal dialing options used in context Dial-Users.
; Only the timeout is defined here. See the Dial app documentation for
; additional options.
INTERNAL_DIAL_OPT=,30
RP_Yealink = PJSIP/f30A0A01
RP_Cisco = PJSIP/f30B0B02
RP_HMBP = PJSIP/SOFTPHONE_A
RP_OMBP = PJSIP/SOFTPHONE_B
[sets]
exten => 100,1,Dial(${RP_Yealink},10,m)
same => n,Playback(vm-nobodyavail)
same => n,Hangup()
exten => 101,1,Dial(${RP_Cisco},10)
same => n,Playback(vm-nobodyavail)
same => n,Hangup()
exten => 102,1,Dial(${RP_HMBP})
exten => 103,1,Dial(${RP_OMBP},10)
same => n,Playback(vm-nobodyavail)
same => n,Hangup()
When using handsets with udp or tcp transports to dial ext 100, it'd hangup
after the no-one-arround message. However, when using the handset with tls
transport, it doesn't hang up on its own if ext 100 is not answered. I
have to click the hangup button to accomplish that. Here's what asterisk
log shows:
== Setting global variable 'SIPDOMAIN' to '128.171.77.23'
-- Executing [100@sets:1] Dial("PJSIP/SOFTPHONE_B-0007", "
PJSIP/f30A0A01,10,m") in new stack
-- Called PJSIP/f30A0A01
-- Started music on hold, class 'default', on channel
'PJSIP/SOFTPHONE_B-0007'
> 0x7f0fa801ede0 -- Strict RTP learning after remote address set to:
128.171.168.233:7078
-- PJSIP/f30A0A01-0008 is ringing
-- PJSIP/f30A0A01-0008 is ringing
> 0x7f0fa801ede0 -- Strict RTP switching to RTP target address
128.171.168.233:7078 as source
> 0x7f0fa801ede0 -- Strict RTP learning complete - Locking on source
address 128.171.168.233:7078
-- Nobody picked up in 1 ms
-- Stopped music on hold on PJSIP/SOFTPHONE_B-0007
-- Executing [100@sets:2] Playback("PJSIP/SOFTPHONE_B-0007", "
vm-nobodyavail") in new stack
-- Playing 'vm-nobodyavail.slin' (language
'en')
-- Executing [100@sets:3] Hangup("PJSIP/SOFTPHONE_B-0007", "") in
new stack
== Spawn extension (sets, 100, 3) exited non-zero on
'PJSIP/SOFTPHONE_B-0007'
voip1*CLI>
Another quirk is when I use a phone with udp transport (RP_Yealink) to
call a phone with tls transport (RP_OMBP) it immediately jumps
the no-one-around message w/o ringing, then hang up. The tls phone is
shown available but asterisk sees it busy:
== Setting global variable 'SIPDOMAIN' to '128.171.77.23'
-- Executing [103@sets:1] Dial("PJSIP/f30A0A01-000d", "
PJSIP/SOFTPHONE_B,10") in new stack
-- Called PJSIP/SOFTPHONE_B
== Everyone is busy/congested at this time (1:0/1/0)
-- Executing [103@sets:2] Playback("PJSIP/f30A0A01-000d", "
vm-nobodyavail") in new stack
> 0x7f0fa000c330 -- Strict RTP learning after remote address set to:
128.171.77.118:11790
> 0x7f0fa000c330 -- Strict RTP switching to RTP target address
128.171.77.118:11790 as source
-- Playing 'vm-nobodyavail.slin'
(language 'en')
-- Executing [103@sets:3] Hangup("PJSIP/f30A0A01-000d", "") in
new stack
== Spawn extension (sets, 103, 3)
Re: [asterisk-users] Asterisk 16.14.0 pjsip transport-tls cert parsing error
Thanks Sean for the note. It does look Selinux might have a hand in the pot. I did try with selinux permission set to permissive and it made no difference though. Keeping configuration related stuff under /etc/asterisk seems to help. --Ruisheng On Mon, Feb 1, 2021 at 8:09 AM Sean Bright wrote: > Hi, > > On 1/26/2021 3:12 PM, Ruisheng Peng wrote: > > Transport: transport-tls: cert_file /home/asterisk/certs/asterisk.crt is > either missing or not readable > > > This error means that the file either does not exist or that Asterisk is > not able to open it for reading. In your case it looks like the file exists > so the Asterisk process was not able to read the file (this could be > permissions or SELinux or whatever other reason). It never gets to actually > trying to parse it as a certificate. > > The subsequent message mentioning "at line 24 of" is just a bug in the > configuration framework, it is not referring to line 24 of the certificate > file. > > Kind regards, > Sean > -- > _ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > Check out the new Asterisk community forum at: > https://community.asterisk.org/ > > New to Asterisk? Start here: > https://wiki.asterisk.org/wiki/display/AST/Getting+Started > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: >http://lists.digium.com/mailman/listinfo/asterisk-users -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- Check out the new Asterisk community forum at: https://community.asterisk.org/ New to Asterisk? Start here: https://wiki.asterisk.org/wiki/display/AST/Getting+Started asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Asterisk 16.14.0 pjsip transport-tls cert parsing error
Michael,
There weren't any open or openat actions on the cert files (located under
/home/asterisk/certs). The same is true for cert files located under
/etc/asterisk/keys:
24138 stat("/etc/asterisk/keys/fullchain.pem", {st_mode=S_IFREG|0640,
st_size=34
44, ...}) = 0
24138 geteuid() = 1002
24138 getegid() = 1002
24138 getuid() = 1002
24138 getgid() = 1002
24138 access("/etc/asterisk/keys/fullchain.pem", R_OK) = 0
24138 stat("/etc/asterisk/keys/privkey.pem", {st_mode=S_IFREG|0640,
st_size=1704
, ...}) = 0
24138 geteuid() = 1002
24138 getegid() = 1002
24138 getuid() = 1002
24138 getgid() = 1002
24138 access("/etc/asterisk/keys/privkey.pem", R_OK) = 0
24138 socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 16
24138 setsockopt(16, SOL_SOCKET, 0x /* SO_??? */, [1], 4) = -1
ENOPROTOOPT (
Protocol not available)
24138 setsockopt(16, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
24138 setsockopt(16, SOL_TCP, TCP_NODELAY, [1], 4) = 0
24138 bind(16, {sa_family=AF_INET, sin_port=htons(5061),
sin_addr=inet_addr("0.0
.0.0")}, 16) = 0
24138 listen(16, 5) = 0
24138 ioctl(16, FIONBIO, [1]) = 0
24138 getsockopt(16, SOL_SOCKET, SO_TYPE, [1], [4]) = 0
24138 epoll_ctl(11, EPOLL_CTL_ADD, 16, {EPOLLIN|EPOLLERR, {u32=23894976,
u64=238
94976}}) = 0
24138 accept(16, 0x1a765c0, [28]) = -1 EAGAIN (Resource temporarily
unavai
lable)
24138 getsockname(16, {sa_family=AF_INET, sin_port=htons(5061),
sin_addr=inet_ad
dr("0.0.0.0")}, [16]) = 0
In the latter case transport-tls was successfully established.
On Fri, Jan 29, 2021 at 9:42 PM Michael Maier wrote:
>
> On 29.01.21 at 22:33 Ruisheng Peng wrote:
> > Thanks for the detailed explanation Michael.
> >
> > I stop the current asterisk process (started by systemd), and restart it
> as
> > asterisk:
> >
> > [asterisk@voip1 ~]$ strace -f -o /home/asterisk/strace.log asterisk -fmq
> > -vvv -C /etc/asterisk/asterisk.conf
> >
> >
> > from the log there was no attempt to even open the cert file. I edited
> > /etc/asterisk/pjsip.conf to add a "method = tlsv1" line to the
> > transport-tls section. Rerun the strace command, and here the part re
> cert
> > files:
> >
> > 8189 stat("/home/asterisk/certs/asterisk.crt", {st_mode=S_IFREG|0640,
> > st_size=1
> >
> > 212, ...}) = 0
> >
> > 8189 geteuid() = 1002
> >
> > 8189 getegid() = 1002
> >
> > 8189 getuid() = 1002
> >
> > 8189 getgid() = 1002
> >
> > 8189 access("/home/asterisk/certs/asterisk.crt", R_OK) = 0
> >
> > 8189 stat("/home/asterisk/certs/asterisk.key", {st_mode=S_IFREG|0640,
> > st_size=8
> >
> > 91, ...}) = 0
> >
> > 8189 geteuid() = 1002
> >
> > 8189 getegid() = 1002
> >
> > 8189 getuid() = 1002
> >
> > 8189 getgid() = 1002
> >
> > 8189 access("/home/asterisk/certs/asterisk.key", R_OK) = 0
> >
> > 8189 socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 16
> >
> > 8189 setsockopt(16, SOL_SOCKET, 0x /* SO_??? */, [1], 4) = -1
> > ENOPROTOOPT (
>
> I'm missing the "open" (or "openat") and the following "read" call -
> weren't there
> any or didn't you post them? These are the important calls! They will
> show, if the
> file is used at all or not (and possibly the reason, why it is not used -
> EACCESS
> e.g.).
>
>
> Thanks
> Michael
>
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> Check out the new Asterisk community forum at:
> https://community.asterisk.org/
>
> New to Asterisk? Start here:
> https://wiki.asterisk.org/wiki/display/AST/Getting+Started
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-users
>
>
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
Check out the new Asterisk community forum at: https://community.asterisk.org/
New to Asterisk? Start here:
https://wiki.asterisk.org/wiki/display/AST/Getting+Started
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Asterisk 16.14.0 pjsip transport-tls cert parsing error
beating around bushes, and finally seem to stomp on something that worked!
Simply move the cert file locations from /home/asterisk/certs to
/etc/asterisk/keys
[root@voip1 asterisk]# ls -l keys
total 36
-rw-r-. 1 asterisk asterisk 1212 Jan 29 14:18 asterisk.crt
-rw-r-. 1 asterisk asterisk 578 Jan 29 14:18 asterisk.csr
-rw-r-. 1 asterisk asterisk 891 Jan 29 14:18 asterisk.key
-rw-r-. 1 asterisk asterisk 2103 Jan 29 14:18 asterisk.pem
-rw-r-. 1 asterisk asterisk 1749 Jan 29 14:18 ca.crt
-rw-r-. 1 asterisk asterisk 3311 Jan 29 14:18 ca.key
-rw-r-. 1 asterisk asterisk 1923 Jan 29 14:18 cert.pem
-rw-r-. 1 asterisk asterisk 3570 Jan 29 14:18 fullchain.pem
-rw-r-. 1 asterisk asterisk 1704 Jan 29 14:18 privkey.pem
and tls was established. With self-sign cert, I'd need to add ca_list_file
in the transport-tls section in /etc/pjsip.conf for it to fly.
[transport-tls]
type = transport
protocol = tls
bind = 0.0.0.0:5061
; ca_list_file = /etc/asterisk/keys/ca.crt
; cert_file = /etc/asterisk/keys/asterisk.crt
; priv_key_file = /etc/asterisk/keys/asterisk.key
cert_file = /etc/asterisk/keys/fullchain.pem
priv_key_file = /etc/asterisk/keys/privkey.pem
method = tlsv1_2
allow_reload = true
Not sure what was the nature of the problem. Maybe Selinux? There was no
complaint from that department though.
Thanks for the help and suggestions,
--Ruisheng
On Fri, Jan 29, 2021 at 11:33 AM Ruisheng Peng wrote:
> Thanks for the detailed explanation Michael.
>
> I stop the current asterisk process (started by systemd), and restart it
> as asterisk:
>
> [asterisk@voip1 ~]$ strace -f -o /home/asterisk/strace.log asterisk -fmq
> -vvv -C /etc/asterisk/asterisk.conf
>
>
> from the log there was no attempt to even open the cert file. I edited
> /etc/asterisk/pjsip.conf to add a "method = tlsv1" line to the
> transport-tls section. Rerun the strace command, and here the part re cert
> files:
>
> 8189 stat("/home/asterisk/certs/asterisk.crt", {st_mode=S_IFREG|0640,
> st_size=1
>
> 212, ...}) = 0
>
> 8189 geteuid() = 1002
>
> 8189 getegid() = 1002
>
> 8189 getuid() = 1002
>
> 8189 getgid() = 1002
>
> 8189 access("/home/asterisk/certs/asterisk.crt", R_OK) = 0
>
> 8189 stat("/home/asterisk/certs/asterisk.key", {st_mode=S_IFREG|0640,
> st_size=8
>
> 91, ...}) = 0
>
> 8189 geteuid() = 1002
>
> 8189 getegid() = 1002
>
> 8189 getuid() = 1002
>
> 8189 getgid() = 1002
>
> 8189 access("/home/asterisk/certs/asterisk.key", R_OK) = 0
>
> 8189 socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 16
>
> 8189 setsockopt(16, SOL_SOCKET, 0x /* SO_??? */, [1], 4) = -1
> ENOPROTOOPT (
>
> Protocol not available)
>
> 8189 setsockopt(16, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
>
> 8189 setsockopt(16, SOL_TCP, TCP_NODELAY, [1], 4) = 0
>
> The tls transport is not established in the end. Only the two hard phones
> using udp transport and a softphone using tcp transport are registered.
>
>
> Thanks,
>
> --Ruisheng
>
>
> On Thu, Jan 28, 2021 at 7:42 PM Michael Maier
> wrote:
>
>>
>> On 27.01.21 at 22:57 Ruisheng Peng wrote:
>> > Thanks Michael for the suggestion! I've installed strace and assigned
>> one
>> > of the endpoints (SOFTPHONE_B) to use transport-tls. Then run strace (as
>> > user asterisk):
>> >
>> > [asterisk@voip1 ~]$ strace asterisk -rx "module reload res_pjsip.so"
>>
>> You should use strace like this as root and from the very beginning of
>> the start
>> of asterisk:
>>
>> strace -f -o /tmp/strace.log asterisk -vvv -mqf -C
>> /etc/asterisk/asterisk.conf
>>
>> -f means, to follow even forked processes, ... (see man page)
>> -o writes all the output to a file. You can search afterwards pretty
>> easily for
>> the file (or the open call).
>>
>> You shouldn't do this in production but in the test environment!
>>
>> You have to run it as long as the error has happened.
>>
>>
>> Thanks
>> Michael
>>
>> --
>> _
>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>
>> Check out the new Asterisk community forum at:
>> https://community.asterisk.org/
>>
>> New to Asterisk? Start here:
>> https://wiki.asterisk.org/wiki/display/AST/Getting+Started
>>
>> asterisk-users mai
Re: [asterisk-users] Asterisk 16.14.0 pjsip transport-tls cert parsing error
Thanks for the detailed explanation Michael.
I stop the current asterisk process (started by systemd), and restart it as
asterisk:
[asterisk@voip1 ~]$ strace -f -o /home/asterisk/strace.log asterisk -fmq
-vvv -C /etc/asterisk/asterisk.conf
from the log there was no attempt to even open the cert file. I edited
/etc/asterisk/pjsip.conf to add a "method = tlsv1" line to the
transport-tls section. Rerun the strace command, and here the part re cert
files:
8189 stat("/home/asterisk/certs/asterisk.crt", {st_mode=S_IFREG|0640,
st_size=1
212, ...}) = 0
8189 geteuid() = 1002
8189 getegid() = 1002
8189 getuid() = 1002
8189 getgid() = 1002
8189 access("/home/asterisk/certs/asterisk.crt", R_OK) = 0
8189 stat("/home/asterisk/certs/asterisk.key", {st_mode=S_IFREG|0640,
st_size=8
91, ...}) = 0
8189 geteuid() = 1002
8189 getegid() = 1002
8189 getuid() = 1002
8189 getgid() = 1002
8189 access("/home/asterisk/certs/asterisk.key", R_OK) = 0
8189 socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 16
8189 setsockopt(16, SOL_SOCKET, 0x /* SO_??? */, [1], 4) = -1
ENOPROTOOPT (
Protocol not available)
8189 setsockopt(16, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
8189 setsockopt(16, SOL_TCP, TCP_NODELAY, [1], 4) = 0
The tls transport is not established in the end. Only the two hard phones
using udp transport and a softphone using tcp transport are registered.
Thanks,
--Ruisheng
On Thu, Jan 28, 2021 at 7:42 PM Michael Maier wrote:
>
> On 27.01.21 at 22:57 Ruisheng Peng wrote:
> > Thanks Michael for the suggestion! I've installed strace and assigned
> one
> > of the endpoints (SOFTPHONE_B) to use transport-tls. Then run strace (as
> > user asterisk):
> >
> > [asterisk@voip1 ~]$ strace asterisk -rx "module reload res_pjsip.so"
>
> You should use strace like this as root and from the very beginning of the
> start
> of asterisk:
>
> strace -f -o /tmp/strace.log asterisk -vvv -mqf -C
> /etc/asterisk/asterisk.conf
>
> -f means, to follow even forked processes, ... (see man page)
> -o writes all the output to a file. You can search afterwards pretty
> easily for
> the file (or the open call).
>
> You shouldn't do this in production but in the test environment!
>
> You have to run it as long as the error has happened.
>
>
> Thanks
> Michael
>
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> Check out the new Asterisk community forum at:
> https://community.asterisk.org/
>
> New to Asterisk? Start here:
> https://wiki.asterisk.org/wiki/display/AST/Getting+Started
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-users
>
>
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
Check out the new Asterisk community forum at: https://community.asterisk.org/
New to Asterisk? Start here:
https://wiki.asterisk.org/wiki/display/AST/Getting+Started
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Asterisk 16.14.0 pjsip transport-tls cert parsing error
Thanks Stefan for the pointer. There isn't a /etc/ssl/openssl.cnf on the Centos7 box. There is a /etc/pki/tls/openssl.cnf, but there's no MinProtocol or CipherString defined there. I installed corebot (for Letsencrypt auto renewal) thru snap. The openssl.cnf that comes with snap (under /var/lib/snapd/snap/core/current/etc/ssl) is pretty similar to the one under /etc/pki/tls, in both lacking MinProtocol and CipherString definitions. [root@voip1 ~]# openssl version OpenSSL 1.0.2k-fips 26 Jan 2017 if it helps with anything. Thanks, --Ruisheng On Fri, Jan 29, 2021 at 5:55 AM Stefan Tichy wrote: > On Tue, Jan 26, 2021 at 10:12:22AM -1000, Ruisheng Peng wrote: > > > The self-sign asterisk.crt: > > I saved that file in "x.crt". > > openssl x509 -in x.crt -noout -text > > >RSA Public-Key: (1024 bit) > > > > > > and Letsencrypt cert.pem: > > I saved that file in "y.crt". > > openssl x509 -in y.crt -noout -enddate > notAfter=Jan 29 01:24:25 2021 GMT > > > > There were a few mentions of this problem on the web, and one said > changing > > the security mode of the certs to 755 fixed his problem. > > That makes no sense. > > > > Which version of openssl ist used on that CentOS7 box ? > > In "/etc/ssl/openssl.cnf" you find something like this: > > MinProtocol = TLSv1.2 > CipherString = DEFAULT@SECLEVEL=2 > > You could set the level to "1" or even to "0" and restart Asterisk. > > > -- > Stefan Tichy > > -- > _ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > Check out the new Asterisk community forum at: > https://community.asterisk.org/ > > New to Asterisk? Start here: > https://wiki.asterisk.org/wiki/display/AST/Getting+Started > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: >http://lists.digium.com/mailman/listinfo/asterisk-users > > -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- Check out the new Asterisk community forum at: https://community.asterisk.org/ New to Asterisk? Start here: https://wiki.asterisk.org/wiki/display/AST/Getting+Started asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Asterisk 16.14.0 pjsip transport-tls cert parsing error
close(3)= 0
stat("/etc/asterisk/asterisk.conf", {st_mode=S_IFREG|0644, st_size=814,
...}) = 0
open("/etc/asterisk/asterisk.conf", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=814, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f4802804000
read(3, "[directories](!)\nastetcdir => /e"..., 4096) = 814
read(3, "", 4096) = 0
close(3)= 0
munmap(0x7f4802804000, 4096)= 0
getrlimit(RLIMIT_NOFILE, {rlim_cur=1024, rlim_max=4*1024}) = 0
rt_sigaction(SIGCHLD, {sa_handler=0x4571a0, sa_mask=[],
sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7f47ffd29630}, NULL, 8) = 0
mkdir("/var/run/asterisk", 0755)= -1 EEXIST (File exists)
geteuid() = 1002
getcwd("/home/asterisk", 4096) = 15
stat("/home/asterisk", {st_mode=S_IFDIR|0770, st_size=4096, ...}) = 0
geteuid() = 1002
getegid() = 1002
getuid()= 1002
getgid()= 1002
access("/home/asterisk", R_OK|X_OK) = 0
socket(AF_UNIX, SOCK_STREAM, 0) = 3
connect(3, {sa_family=AF_UNIX, sun_path="/var/run/asterisk/asterisk.ctl"},
110) = 0
rt_sigaction(SIGINT, {sa_handler=0x456b00, sa_mask=[INT],
sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7f47feffa400},
{sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
rt_sigaction(SIGTERM, {sa_handler=0x456b00, sa_mask=[TERM],
sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7f47feffa400},
{sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
rt_sigaction(SIGHUP, {sa_handler=0x456b00, sa_mask=[HUP],
sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7f47feffa400},
{sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
read(3, "voip1.ifa.hawaii.edu/30632/16.14"..., 255) = 35
write(3, "cli quit after module reload res"..., 42) = 42
poll([{fd=3, events=POLLIN}], 1, 6) = 1 ([{fd=3, revents=POLLIN}])
read(3, "Module 'res_pjsip.so' reloaded s"..., 511) = 45
write(1, "Module 'res_pjsip.so' reloaded s"..., 45Module 'res_pjsip.so'
reloaded successfully.
) = 45
poll([{fd=3, events=POLLIN}], 1, 6) = 1 ([{fd=3,
revents=POLLIN|POLLHUP}])
read(3, "", 511)= 0
futex(0x8f4830, FUTEX_WAKE_PRIVATE, 2147483647) = 0
futex(0x8f45c0, FUTEX_WAKE_PRIVATE, 2147483647) = 0
access("/etc/localtime", R_OK) = 0
open("/etc/localtime", O_RDONLY)= 4
read(4, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\5\0\0\0\5\0\0\0\0"...,
41992) = 312
close(4)= 0
open("/usr/share/zoneinfo/posixrules", O_RDONLY) = 4
read(4, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0\0"...,
41992) = 3519
close(4)= 0
gettid()= 7163
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f4802804000
write(1, "Asterisk ending (0).\n", 21Asterisk ending (0).
) = 21
close(3)= 0
exit_group(0) = ?
+++ exited with 0 +++
Curiously, no mention of the certificates defined in /etc/pjsip.conf:
[transport-tls]
type = transport
protocol = tls
bind = 0.0.0.0
;cert_file = /home/asterisk/certs/cert.pem
;cert_file = /home/asterisk/certs/fullchain.pem
;priv_key_file = /home/asterisk/certs/privkey.pem
cert_file = /home/asterisk/certs/asterisk.crt
priv_key_file = /home/asterisk/certs/asterisk.key
allow_reload = true
In the end the tls transport was still not installed for SOFTPHONE_B:
Endpoint: f30A0A01 Not in
use0 of inf
InAuth: f30A0A01/f30A0A01
Aor: f30A0A01 1
Contact: f30A0A01/sip:f30A0A01@128.171.77.1 4800418965
NonQual nan
Transport: transport-udp udp 0 0 0.0.0.0:5060
Endpoint: f30B0B02 Not in
use0 of inf
InAuth: f30B0B02/f30B0B02
Aor: f30B0B02 1
Contact: f30B0B02/sip:f30B0B02@128.171.77.4 615cc2a2c6
NonQual nan
Transport: transport-udp udp 0 0 0.0.0.0:5060
Endpoint: SOFTPHONE_A
Unavailable 0 of inf
InAuth: SOFTPHONE_A/SOFTPHONE_A
Aor: SOFTPHONE_A2
Transport: transport-tcp tcp 0 0 0.0.0.0:5060
Endpoint: SOFTPHONE_B
Unavailable 0 of inf
InAuth: SOFTPHONE_B/SOFTPHONE_B
Aor: SOFTPHONE_B
[asterisk-users] Asterisk 16.14.0 pjsip transport-tls cert parsing error
Hi, I'm experimenting with Asterisk-16.14.0 on a CentOS7 box, and run into problems loading the SSL certificate to establish transport-tls. Tried self-signed certificate generated with ast_tls_cert under contrib/scripts and the one issued by Letsencrypt, both would bomb out with a parsing error: [Dec 3 15:47:50] ERROR[11233] res_pjsip/config_transport.c: Transport: transport-tls: cert_file /home/asterisk/certs/asterisk.crt is either missing or not readable [Dec 3 15:47:50] ERROR[11233] config_options.c: Error parsing cert_file=/home/asterisk/certs/asterisk.crt at line 24 of What's interesting is that the self-signed asterisk.crt only has 20 lines. For letsencrypt certificate (both cert.pem and fullchain.pem), it'd bomb out at line 22. Here's the transport section of my /etc/asterisk/pjsip.conf: [transport-udp] type = transport protocol = udp bind = 0.0.0.0 [transport-tls] type = transport protocol = tls bind = 0.0.0.0 ;cert_file = /home/asterisk/certs/cert.pem ;cert_file = /home/asterisk/certs/fullchain.pem ;priv_key_file = /home/asterisk/certs/privkey.pem cert_file = /home/asterisk/certs/asterisk.crt priv_key_file = /home/asterisk/certs/asterisk.key allow_reload = true And a full listing of /home/asterisk/certs: -rw-r-. 1 asterisk asterisk 1212 Dec 2 17:19 asterisk.crt -rw-r-. 1 asterisk asterisk 578 Dec 2 17:18 asterisk.csr -rw-r-. 1 asterisk asterisk 891 Dec 2 17:18 asterisk.key -rw-r-. 1 asterisk asterisk 2103 Dec 2 17:19 asterisk.pem -rw-r-. 1 asterisk asterisk 1749 Dec 2 17:18 ca.crt -rw-r-. 1 asterisk asterisk 3311 Dec 2 17:18 ca.key -rw-r-. 1 asterisk asterisk 1923 Nov 13 16:29 cert.pem -rw-r-. 1 asterisk asterisk 3570 Nov 13 15:11 fullchain.pem -rw-r-. 1 asterisk asterisk 1704 Nov 13 15:12 privkey.pem The self-sign asterisk.crt: -BEGIN CERTIFICATE- MIIDUzCCATsCAQEwDQYJKoZIhvcNAQELBQAwMTEcMBoGA1UEAwwTQXN0ZXJpc2sg UHJpdmF0ZSBDQTERMA8GA1UECgwIQXN0ZXJpc2swHhcNMjAxMjAzMDMxOTA2WhcN MjExMjAzMDMxOTA2WjAyMR0wGwYDVQQDDBR2b2lwMS5pZmEuaGF3YWlpLmVkdTER MA8GA1UECgwIQXN0ZXJpc2swgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOIn CVUjv8qsDGdv8VJMEtmiMMK2HAdMnkUAv0BgEU6v0lB49xDQfHheb54MBVmyCArB 7CCwcqej3QtGVOUnLO/kGUd0YkFvFfpY+esnxCIeA5JVat15fo5d+gOYGMdfTlGQ gPfYwagCvL94fOIrqEm/LU0vmUi487LSFJOrrcEfAgMBAAEwDQYJKoZIhvcNAQEL BQADggIBANRCkcl1KTN3/Ez2j7VR0ZisGQVVqwfwLJlM4TtT44ukZPNKWc/BhMH4 XtXA71Np+0ePERcQDpj0gPEQyW0PfGAZT/AsClUmphBoGWTnM5NB23BDDwawm9Ym aAddCm94aEe1gMwWJRaPqdWhkub9BS7KWWCkhdLwITryo+I0hSdD9ReXXODRPPyH ybL8CtNRJjCHU8shyvxtrpinZJFHJj3GSWYVB15uUotAUWlpF6H8+Q41UJgJYeGO 11FlpCMrB4uI/V2c1GJP2RUtZIzzofeEGnsZD2egBt/z/oVPJq9aG7BKV5/19jwK CW1fZ7V9FfBOVlXgB81cvwMKAE2SzBspcdefOTGzRJuPPPOeqxGz4lUVU2jeBdvn NQWc//WeuOiAaRd65o5gtP9+3ghkbEUqT//tgt1kD26a2mmFNZr90eVhk59HpH5d U4fIVANO6sINHlwRetdjxRNG43PhKgu+QSrvMba7mxsEINts+UP2pkQOXM1ft2V5 TaIl72dNZr4qni+nTa3GlMweLyIIhaYATl+kLE5kmPK0x32W57FE2j5elbKknOCj s6oMBfBavq+yevFJD2gEmO/KSNYHes+6D6FjGFA9kBPInqg5Bf1rEnaRmGmxp1gZ xPdN2lPLES+Z7aj57j6a+HnFRgRToGGovThd7IxczPxLhc6zL0f8 -END CERTIFICATE- and Letsencrypt cert.pem: -BEGIN CERTIFICATE- MIIFYDCCBEigAwIBAgISA8qPXDAnBCnnOVm3CI9Z1H3WMA0GCSqGSIb3DQEBCwUA MEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD ExpMZXQncyBFbmNyeXB0IEF1dGhvcml0eSBYMzAeFw0yMDEwMzEwMTI0MjVaFw0y MTAxMjkwMTI0MjVaMB8xHTAbBgNVBAMTFHZvaXAxLmlmYS5oYXdhaWkuZWR1MIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAplxKSuYMpBWVAEJbDt+GRGSD Q+XVswCQtw+QBOBPUYNEQtuJIdH9th8mdqf5ftCnQAbXeLiZLfI6S3kVtpPYRwHc r9sK1SfUr2roRwIhED+7X0JKgbBcNCghsfzleWTDoRoJr9KF/OyIoMeuQC3fwI14 Tioto0SLMQIbqZFNEKiJeMv2BZmXJK0qPf2Ru/lFWH721vX8iwOc6ocXNw4+0OUB lWbnFLXk9Nw2oW7OtDCQS9zqRALLUG3XvcIsAzcIw/SFoo4lCMdGESsUuILeUBkx 3TUHLtdJgCoahNANZwarXI/KWRNF1U9A8tX6iJwN+AXKJvoMgtBDYJ0noamOHwID AQABo4ICaTCCAmUwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMB BggrBgEFBQcDAjAMBgNVHRMBAf8EAjAAMB0GA1UdDgQWBBQspfZL9VjojblP2hSu GVtZfD5JUDAfBgNVHSMEGDAWgBSoSmpjBH3duubRObemRWXv86jsoTBvBggrBgEF BQcBAQRjMGEwLgYIKwYBBQUHMAGGImh0dHA6Ly9vY3NwLmludC14My5sZXRzZW5j cnlwdC5vcmcwLwYIKwYBBQUHMAKGI2h0dHA6Ly9jZXJ0LmludC14My5sZXRzZW5j cnlwdC5vcmcvMB8GA1UdEQQYMBaCFHZvaXAxLmlmYS5oYXdhaWkuZWR1MEwGA1Ud IARFMEMwCAYGZ4EMAQIBMDcGCysGAQQBgt8TAQEBMCgwJgYIKwYBBQUHAgEWGmh0 dHA6Ly9jcHMubGV0c2VuY3J5cHQub3JnMIIBBAYKKwYBBAHWeQIEAgSB9QSB8gDw AHYAXNxDkv7mq0VEsV6a1FbmEDf71fpH3KFzlLJe5vbHDsoAAAF1fHhh9AAABAMA RzBFAiEAxpI+NiPBW+f+oXRfZTTuHXpTW4tZh1RG2BJ6MBNRM9UCIBtu031bmL21 +aeb/P7nVpBFXUuZHmlThW1Sg46Q/tBmAHYA9lyUL9F3MCIUVBgIMJRWjuNNExkz v98MLyALzE7xZOMAAAF1fHhh8gAABAMARzBFAiEA2Yaf0MEdUJRyYOdr1otw6LWT 3cgyitLcK/5UEgqfjf0CIBcQA9GK9LMqvUWEwDRl4uSISzE7bbjVbsJu563q5UGL MA0GCSqGSIb3DQEBCwUAA4IBAQAMFj4dBp+qJ7mrM4wV9znnDliMQZnIA/2QH1tP dJZskP17uvPY1p6vAw5Z9zELiSBmd3ONYFcoZbXCSzG71AqRGPiQBI7wEyEto7so QYpVDKD1zScASl+ZWorcM9GDizqby3v8jUYAKKwUPKFq6qXxtjDLjfjSymghkJsR Cpf60tu8VXRBtMliryVWMQXk3z2yicYHIHuSPxstsJrGtVhFDq2OedwvVGMSvCgh BniswjtAJ3oB21eB+XB5KMIAQK848E8YML4G8urCLMy9OmnLqnoUgdCju/S7/fkc
[asterisk-users] Fwd: Asterisk 16.14.0 pjsip transport-tls cert parsing error
Hi, I'm experimenting with Asterisk-16.14.0 on a CentOS7 box, and run into problems loading the SSL certificate to establish transport-tls. Tried self-signed certificate generated with ast_tls_cert under contrib/scripts and the one issued by Letsencrypt, both would bomb out with a parsing error: [Dec 3 15:47:50] ERROR[11233] res_pjsip/config_transport.c: Transport: transport-tls: cert_file /home/asterisk/certs/asterisk.crt is either missing or not readable [Dec 3 15:47:50] ERROR[11233] config_options.c: Error parsing cert_file=/home/asterisk/certs/asterisk.crt at line 24 of What's interesting is that the self-signed asterisk.crt only has 20 lines. For letsencrypt certificate (both cert.pem and fullchain.pem), it'd bomb out at line 22. Here's the transport section of my /etc/asterisk/pjsip.conf: [transport-udp] type = transport protocol = udp bind = 0.0.0.0 [transport-tls] type = transport protocol = tls bind = 0.0.0.0 ;cert_file = /home/asterisk/certs/cert.pem ;cert_file = /home/asterisk/certs/fullchain.pem ;priv_key_file = /home/asterisk/certs/privkey.pem cert_file = /home/asterisk/certs/asterisk.crt priv_key_file = /home/asterisk/certs/asterisk.key allow_reload = true And a full listing of /home/asterisk/certs: -rw-r-. 1 asterisk asterisk 1212 Dec 2 17:19 asterisk.crt -rw-r-. 1 asterisk asterisk 578 Dec 2 17:18 asterisk.csr -rw-r-. 1 asterisk asterisk 891 Dec 2 17:18 asterisk.key -rw-r-. 1 asterisk asterisk 2103 Dec 2 17:19 asterisk.pem -rw-r-. 1 asterisk asterisk 1749 Dec 2 17:18 ca.crt -rw-r-. 1 asterisk asterisk 3311 Dec 2 17:18 ca.key -rw-r-. 1 asterisk asterisk 1923 Nov 13 16:29 cert.pem -rw-r-. 1 asterisk asterisk 3570 Nov 13 15:11 fullchain.pem -rw-r-. 1 asterisk asterisk 1704 Nov 13 15:12 privkey.pem The self-sign asterisk.crt: -BEGIN CERTIFICATE- MIIDUzCCATsCAQEwDQYJKoZIhvcNAQELBQAwMTEcMBoGA1UEAwwTQXN0ZXJpc2sg UHJpdmF0ZSBDQTERMA8GA1UECgwIQXN0ZXJpc2swHhcNMjAxMjAzMDMxOTA2WhcN MjExMjAzMDMxOTA2WjAyMR0wGwYDVQQDDBR2b2lwMS5pZmEuaGF3YWlpLmVkdTER MA8GA1UECgwIQXN0ZXJpc2swgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOIn CVUjv8qsDGdv8VJMEtmiMMK2HAdMnkUAv0BgEU6v0lB49xDQfHheb54MBVmyCArB 7CCwcqej3QtGVOUnLO/kGUd0YkFvFfpY+esnxCIeA5JVat15fo5d+gOYGMdfTlGQ gPfYwagCvL94fOIrqEm/LU0vmUi487LSFJOrrcEfAgMBAAEwDQYJKoZIhvcNAQEL BQADggIBANRCkcl1KTN3/Ez2j7VR0ZisGQVVqwfwLJlM4TtT44ukZPNKWc/BhMH4 XtXA71Np+0ePERcQDpj0gPEQyW0PfGAZT/AsClUmphBoGWTnM5NB23BDDwawm9Ym aAddCm94aEe1gMwWJRaPqdWhkub9BS7KWWCkhdLwITryo+I0hSdD9ReXXODRPPyH ybL8CtNRJjCHU8shyvxtrpinZJFHJj3GSWYVB15uUotAUWlpF6H8+Q41UJgJYeGO 11FlpCMrB4uI/V2c1GJP2RUtZIzzofeEGnsZD2egBt/z/oVPJq9aG7BKV5/19jwK CW1fZ7V9FfBOVlXgB81cvwMKAE2SzBspcdefOTGzRJuPPPOeqxGz4lUVU2jeBdvn NQWc//WeuOiAaRd65o5gtP9+3ghkbEUqT//tgt1kD26a2mmFNZr90eVhk59HpH5d U4fIVANO6sINHlwRetdjxRNG43PhKgu+QSrvMba7mxsEINts+UP2pkQOXM1ft2V5 TaIl72dNZr4qni+nTa3GlMweLyIIhaYATl+kLE5kmPK0x32W57FE2j5elbKknOCj s6oMBfBavq+yevFJD2gEmO/KSNYHes+6D6FjGFA9kBPInqg5Bf1rEnaRmGmxp1gZ xPdN2lPLES+Z7aj57j6a+HnFRgRToGGovThd7IxczPxLhc6zL0f8 -END CERTIFICATE- and Letsencrypt cert.pem: -BEGIN CERTIFICATE- MIIFYDCCBEigAwIBAgISA8qPXDAnBCnnOVm3CI9Z1H3WMA0GCSqGSIb3DQEBCwUA MEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD ExpMZXQncyBFbmNyeXB0IEF1dGhvcml0eSBYMzAeFw0yMDEwMzEwMTI0MjVaFw0y MTAxMjkwMTI0MjVaMB8xHTAbBgNVBAMTFHZvaXAxLmlmYS5oYXdhaWkuZWR1MIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAplxKSuYMpBWVAEJbDt+GRGSD Q+XVswCQtw+QBOBPUYNEQtuJIdH9th8mdqf5ftCnQAbXeLiZLfI6S3kVtpPYRwHc r9sK1SfUr2roRwIhED+7X0JKgbBcNCghsfzleWTDoRoJr9KF/OyIoMeuQC3fwI14 Tioto0SLMQIbqZFNEKiJeMv2BZmXJK0qPf2Ru/lFWH721vX8iwOc6ocXNw4+0OUB lWbnFLXk9Nw2oW7OtDCQS9zqRALLUG3XvcIsAzcIw/SFoo4lCMdGESsUuILeUBkx 3TUHLtdJgCoahNANZwarXI/KWRNF1U9A8tX6iJwN+AXKJvoMgtBDYJ0noamOHwID AQABo4ICaTCCAmUwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMB BggrBgEFBQcDAjAMBgNVHRMBAf8EAjAAMB0GA1UdDgQWBBQspfZL9VjojblP2hSu GVtZfD5JUDAfBgNVHSMEGDAWgBSoSmpjBH3duubRObemRWXv86jsoTBvBggrBgEF BQcBAQRjMGEwLgYIKwYBBQUHMAGGImh0dHA6Ly9vY3NwLmludC14My5sZXRzZW5j cnlwdC5vcmcwLwYIKwYBBQUHMAKGI2h0dHA6Ly9jZXJ0LmludC14My5sZXRzZW5j cnlwdC5vcmcvMB8GA1UdEQQYMBaCFHZvaXAxLmlmYS5oYXdhaWkuZWR1MEwGA1Ud IARFMEMwCAYGZ4EMAQIBMDcGCysGAQQBgt8TAQEBMCgwJgYIKwYBBQUHAgEWGmh0 dHA6Ly9jcHMubGV0c2VuY3J5cHQub3JnMIIBBAYKKwYBBAHWeQIEAgSB9QSB8gDw AHYAXNxDkv7mq0VEsV6a1FbmEDf71fpH3KFzlLJe5vbHDsoAAAF1fHhh9AAABAMA RzBFAiEAxpI+NiPBW+f+oXRfZTTuHXpTW4tZh1RG2BJ6MBNRM9UCIBtu031bmL21 +aeb/P7nVpBFXUuZHmlThW1Sg46Q/tBmAHYA9lyUL9F3MCIUVBgIMJRWjuNNExkz v98MLyALzE7xZOMAAAF1fHhh8gAABAMARzBFAiEA2Yaf0MEdUJRyYOdr1otw6LWT 3cgyitLcK/5UEgqfjf0CIBcQA9GK9LMqvUWEwDRl4uSISzE7bbjVbsJu563q5UGL MA0GCSqGSIb3DQEBCwUAA4IBAQAMFj4dBp+qJ7mrM4wV9znnDliMQZnIA/2QH1tP dJZskP17uvPY1p6vAw5Z9zELiSBmd3ONYFcoZbXCSzG71AqRGPiQBI7wEyEto7so QYpVDKD1zScASl+ZWorcM9GDizqby3v8jUYAKKwUPKFq6qXxtjDLjfjSymghkJsR Cpf60tu8VXRBtMliryVWMQXk3z2yicYHIHuSPxstsJrGtVhFDq2OedwvVGMSvCgh BniswjtAJ3oB21eB+XB5KMIAQK848E8YML4G8urCLMy9OmnLqnoUgdCju/S7/fkc
