7 thoughts on - Hangup() Not Working For Handsets Using Pls Transport?

• When using handsets with udp or tcp transports to dial ext 100, it’d hangup

  I’d suggest looking at the actual SIP signaling to see what is going on using “pjsip set logger on” and also providing configuration. This would allow better insight into what exactly is going on.

• 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
  (0000f30A0A01 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.

  Here’re the relevant part of my /etc/asterisk/extensions.conf:

  [globals]

  ; General internal dialing options used in context Dial-Users.

  ;

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

• 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://::ffff:128.171.77.23:5061]

  2021-02-11 13:26:32:652 [linphone/belle-sip] MESSAGE Channel
  [0x7fc8b8000000]: Connected at TCP level, now doing TLS handshake with cname8.171.77.23

  2021-02-11 13:26:32:654 [linphone/belle-sip] MESSAGE Channel
  [0x7fc8b8000000]: 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

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

  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 certificate as trusted. As well if you aren’t doing so you have to connect to the hostname – you can’t specify the IP address.

• 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

• 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