Digium Phones and the new Let's Encrypt Root Cert?

Sangoma Hardware Phones
1

I think Digium Phones are having a problem with the new Let’s Encrypt certificate.

This morning I had calls that 2 customer sites were down. My phones were down too.
They all use D60 and D65 phones.

I have no idea if my “old” cert was using the new root or not, but while troubleshooting, I deleted it and re-created the cert. I know the old cert still had ~48 days remaining. Anyways, the new cert is definitely using the new root. Also, strangely, when this all began, it wasn’t October 1st UTC. (It still isn’t).

After doing a bunch of digging through phone syslogs and troubleshooting, I think Digium might not trust the latest LE Root. (Let's Encrypt - Can't generate new cert, ACME v1 EOL per LE)

The phones are throwing errors when trying to access Apps as well as “Invalid SIP TLS Certificate, Error Code: 0x00000004” if they are using SIP-TLS.

He’s an example of the syslog from a D65 trying to make an outbound call:

Sep 30 19:58:43 192.168.42.133 phone:  VIEW EVENT: fn.dial
Sep 30 19:58:43 192.168.42.133 phone:  LogScreen::process_event: fn.dial
Sep 30 19:58:43 192.168.42.133 phone:  LogScreen::process_event() fn.dial new event: fn.dial.0.--redacted-phone-number--.0
Sep 30 19:58:43 192.168.42.133 phone:  _call_screen, cl_size:0, updated_call NULL status:0
Sep 30 19:58:43 192.168.42.133 phone:  rebuild_call_list, updated_call status: -1, handle: (null)
Sep 30 19:58:43 192.168.42.133 phone:  call_list resized to W:296 H:64
Sep 30 19:58:43 192.168.42.133 xyz:  KEY 40-[ ( ] 1
Sep 30 19:58:43 192.168.42.133 phone:  dbus_hide_idle_apps()
Sep 30 19:58:43 192.168.42.133 phone:  _set_top_label()
Sep 30 19:58:43 192.168.42.133 phone:  _softkeys()
Sep 30 19:58:43 192.168.42.133 phone:  keybuffer_cb() 
Sep 30 19:58:43 192.168.42.133 phone:  Indicator cb
Sep 30 19:58:43 192.168.42.133 phone:  Line 0 update
Sep 30 19:58:43 192.168.42.133 phone:  _call_screen, cl_size:0, updated_call NULL status:0
Sep 30 19:58:43 192.168.42.133 phone:  rebuild_call_list, updated_call status: -1, handle: (null)
Sep 30 19:58:43 192.168.42.133 phone:  call_list resized to W:296 H:64
Sep 30 19:58:43 192.168.42.133 core[988]:  core dbus_callback()
Sep 30 19:58:43 192.168.42.133 phone:  dbus_hide_idle_apps()
Sep 30 19:58:43 192.168.42.133 phone:  _set_top_label()
Sep 30 19:58:43 192.168.42.133 phone:  _softkeys()
Sep 30 19:58:43 192.168.42.133 phone:  keybuffer_cb() 
Sep 30 19:58:43 192.168.42.133 phone:  Indicator cb
Sep 30 19:58:43 192.168.42.133 phone:  Line 0 update
Sep 30 19:58:43 192.168.42.133 phone:  _call_screen, cl_size:0, updated_call NULL status:0
Sep 30 19:58:43 192.168.42.133 phone:  rebuild_call_list, updated_call status: -1, handle: (null)
Sep 30 19:58:43 192.168.42.133 phone:  call_list resized to W:296 H:64
Sep 30 19:58:43 192.168.42.133 phone:  dbus_hide_idle_apps()
Sep 30 19:58:43 192.168.42.133 phone:  _set_top_label()
Sep 30 19:58:43 192.168.42.133 phone:  _softkeys()
Sep 30 19:58:43 192.168.42.133 phone:  dbus_audio_mute(off)
Sep 30 19:58:43 192.168.42.133 phone:  new call subslot 0
Sep 30 19:58:43 192.168.42.133 phone:  Highest priority, 0 account
Sep 30 19:58:43 192.168.42.133 phone:  dbus_audio_set_volume(speakerphone, output, 50)
Sep 30 19:58:43 192.168.42.133 phone:  dbus_audio_wire(speakerphone)
Sep 30 19:58:43 192.168.42.133 phone:  dbus_make_call(0, --redacted-phone-number--, 0, 0) HANDLE: idle_dial_3
Sep 30 19:58:43 192.168.42.133 phone:  Subslot 0
Sep 30 19:58:43 192.168.42.133 core[988]:  core dbus_callback()
Sep 30 19:58:43 192.168.42.133 core[988]:  callbridge: dus_send_audio_mute_status
Sep 30 19:58:43 192.168.42.133 core[988]:  callbridge: dus_send_audio_volume_status
Sep 30 19:58:43 192.168.42.133 core[988]:  callbridge: aud_set_call_device speakerphone speakerphone
Sep 30 19:58:43 192.168.42.133 core[988]:  callbridge: Already on this device
Sep 30 19:58:43 192.168.42.133 core[988]:  callbridge: dus_send_audio_wire_status
Sep 30 19:58:43 192.168.42.133 phone:  @@@ new state: phone.idle
Sep 30 19:58:43 192.168.42.133 phone:  Indicator cb
Sep 30 19:58:43 192.168.42.133 phone:  Line 0 update
Sep 30 19:58:43 192.168.42.133 phone:  line_icon_update(0, 7)
Sep 30 19:58:43 192.168.42.133 phone:  ACTIVITY 8
Sep 30 19:58:43 192.168.42.133 phone:  _call_screen, cl_size:0, updated_call idle_dial_3 status:19
Sep 30 19:58:43 192.168.42.133 phone:  rebuild_call_list, updated_call status: 19, handle: idle_dial_3
Sep 30 19:58:43 192.168.42.133 phone:  call_list resized to W:296 H:64
Sep 30 19:58:43 192.168.42.133 phone:  _call_screen, updated_call idle_dial_3 status:19 number:--redacted-phone-number--
Sep 30 19:58:43 192.168.42.133 phone:  dbus_hide_idle_apps()
Sep 30 19:58:43 192.168.42.133 phone:  _set_top_label()
Sep 30 19:58:43 192.168.42.133 phone:  _softkeys()
Sep 30 19:58:43 192.168.42.133 phone:  check_status_data()
Sep 30 19:58:43 192.168.42.133 phone:  Loop status line 1
Sep 30 19:58:43 192.168.42.133 core[988]:  core dbus_callback()
Sep 30 19:58:43 192.168.42.133 core[988]:  callbridge: state_find_accountp_by_slot
Sep 30 19:58:43 192.168.42.133 core[988]:  callbridge: 12:58:43.518   pjsua_call.c !Making call with acc #1 to <sip:[email protected]:5061;transport=tls>
Sep 30 19:58:43 192.168.42.133 core[988]:  callbridge: 12:58:43.518 src/broadcom_p  .pjsua_set_snd_dev no-op
Sep 30 19:58:43 192.168.42.133 core[988]:  callbridge: 12:58:43.526   tlsc0x3ab0cc  .TLS client transport created
Sep 30 19:58:43 192.168.42.133 core[988]:  callbridge: 12:58:43.527   tlsc0x3ab0cc  .TLS transport 192.168.42.133:44114 is connecting to voice.--redacted--:5061...
Sep 30 19:58:43 192.168.42.133 core[988]:  callbridge: 12:58:43.537  pjsua_media.c  .Call 3: initializing media..
Sep 30 19:58:43 192.168.42.133 core[988]:  callbridge: 12:58:43.539  pjsua_media.c  ..RTP socket reachable at 192.168.42.133:4006
Sep 30 19:58:43 192.168.42.133 core[988]:  callbridge: 12:58:43.539  pjsua_media.c  ..RTCP socket reachable at 192.168.42.133:4007
Sep 30 19:58:43 192.168.42.133 core[988]:  callbridge: 12:58:43.540  pjsua_media.c  ..Media index 0 selected for audio call 3
Sep 30 19:58:43 192.168.42.133 core[988]:  callbridge: alt_codec_test_alloc media_id:3 next_id:4 call_cnt:0 name:PCMU
Sep 30 19:58:43 192.168.42.133 core[988]:  callbridge: alt_codec_test_alloc media_id:3 next_id:4 call_cnt:0 name:PCMA
Sep 30 19:58:43 192.168.42.133 core[988]:  callbridge: alt_codec_test_alloc media_id:3 next_id:4 call_cnt:0 name:G722
Sep 30 19:58:43 192.168.42.133 core[988]:  callbridge: alt_codec_test_alloc media_id:3 next_id:4 call_cnt:0 name:G726-32
Sep 30 19:58:43 192.168.42.133 core[988]:  callbridge: alt_codec_test_alloc media_id:3 next_id:4 call_cnt:0 name:L16
Sep 30 19:58:43 192.168.42.133 core[988]:  callbridge: alt_codec_test_alloc media_id:3 next_id:4 call_cnt:0 name:L16
Sep 30 19:58:43 192.168.42.133 core[988]:  callbridge: alt_codec_test_alloc media_id:3 next_id:4 call_cnt:0 name:L16-256
Sep 30 19:58:43 192.168.42.133 core[988]:  callbridge: 12:58:43.542 transport_srtp  .generate_crypto_attr_value ingressfullKey: EF9C7DB2
Sep 30 19:58:43 192.168.42.133 core[988]:  callbridge: 12:58:43.546   srtp0x29dc08  .SRTP uses keying method SDES
Sep 30 19:58:43 192.168.42.133 core[988]:  callbridge: 12:58:43.547  sip_resolve.c  ....DNS AAAA record resolution failed: No answer record in the DNS response (PJLIB_UTIL_EDNSNOANSWERREC)
Sep 30 19:58:43 192.168.42.133 core[988]:  callbridge: 12:58:43.548   pjsua_core.c  ....TX 1326 bytes Request msg INVITE/cseq=31097 (tdta0x37c69c) to TLS --redacted-server-ip--:5061:
Sep 30 19:58:43 192.168.42.133 core[988]:  callbridge: 12:58:43.548  on_call_state  .......Call 3 state=CALLING
Sep 30 19:58:43 192.168.42.133 core[988]:  callbridge: buildCallStatus
Sep 30 19:58:43 192.168.42.133 core[988]:  callbridge: state_get_call_disconnecting callid=3
Sep 30 19:58:43 192.168.42.133 core[988]:  callbridge: 12:58:43.549    src/state.c  .......flushing call state data for call_id 3
Sep 30 19:58:43 192.168.42.133 core[988]:  callbridge: state_get_call_disconnecting callid=3
Sep 30 19:58:43 192.168.42.133 core[988]:  callbridge: state_get_call_broadcom_session_info callid=3
Sep 30 19:58:43 192.168.42.133 core[988]:  callbridge: 12:58:43.550 src/broadcom_p  .......pjsua_call_get_stream_info: call_id:3 call_cnt:1, state:1
Sep 30 19:58:43 192.168.42.133 core[988]:  callbridge: state_set_call_ingress_key callid=3
Sep 30 19:58:43 192.168.42.133 core[988]:  callbridge: state_get_account_slot
Sep 30 19:58:43 192.168.42.133 core[988]:  callbridge: state_get_call_handle callid=3
Sep 30 19:58:43 192.168.42.133 core[988]:  callbridge: dus_send_call_status
Sep 30 19:58:43 192.168.42.133 core[988]:  callbridge: state_set_call_handle callid=3
Sep 30 19:58:43 192.168.42.133 core[988]:  callbridge: state_set_ringer_slot callid=3
Sep 30 19:58:43 192.168.42.133 core[988]:  callbridge: 12:58:43.807 ssl_sock_ossl. !set_cipher_list calling SSL_set_cipher_list using: ALL:!aNULL:!eNULL
Sep 30 19:58:43 192.168.42.133 phone:  *** State phone.idle, process event: idle_hidden
Sep 30 19:58:43 192.168.42.133 phone:  VIEW EVENT: idle_hidden
Sep 30 19:58:43 192.168.42.133 phone:  HomeScreen::process_event: idle_hidden
Sep 30 19:58:43 192.168.42.133 phone:  REMAP EVENT idle_hidden
Sep 30 19:58:43 192.168.42.133 phone:  ==== State phone.idle, process event idle_hidden: no matching transition
Sep 30 19:58:43 192.168.42.133 phone:  @@@ new state: phone.idle
Sep 30 19:58:43 192.168.42.133 phone:  *** State phone.idle, process event: idle_hidden
Sep 30 19:58:43 192.168.42.133 phone:  VIEW EVENT: idle_hidden
Sep 30 19:58:43 192.168.42.133 phone:  HomeScreen::process_event: idle_hidden
Sep 30 19:58:43 192.168.42.133 phone:  REMAP EVENT idle_hidden
Sep 30 19:58:43 192.168.42.133 phone:  ==== State phone.idle, process event idle_hidden: no matching transition
Sep 30 19:58:43 192.168.42.133 phone:  @@@ new state: phone.idle
Sep 30 19:58:43 192.168.42.133 phone:  *** State phone.idle, process event: audio_mute_status.off
Sep 30 19:58:43 192.168.42.133 phone:  VIEW EVENT: audio_mute_status.off
Sep 30 19:58:43 192.168.42.133 phone:  HomeScreen::process_event: audio_mute_status.off
Sep 30 19:58:43 192.168.42.133 phone:  REMAP EVENT audio_mute_status.off
Sep 30 19:58:43 192.168.42.133 phone:  _mute_cb value:0
Sep 30 19:58:43 192.168.42.133 phone:  @@@ new state: phone.idle
Sep 30 19:58:43 192.168.42.133 phone:  *** State phone.idle, process event: audio_volume_status.speakerphone.output.50
Sep 30 19:58:43 192.168.42.133 phone:  VIEW EVENT: audio_volume_status.speakerphone.output.50
Sep 30 19:58:43 192.168.42.133 phone:  HomeScreen::process_event: audio_volume_status.speakerphone.output.50
Sep 30 19:58:43 192.168.42.133 phone:  REMAP EVENT audio_volume_status.speakerphone.output.50
Sep 30 19:58:43 192.168.42.133 phone:  @@@ new state: phone.idle
Sep 30 19:58:43 192.168.42.133 phone:  *** State phone.idle, process event: audio_wire_status.speakerphone
Sep 30 19:58:43 192.168.42.133 phone:  VIEW EVENT: audio_wire_status.speakerphone
Sep 30 19:58:43 192.168.42.133 phone:  HomeScreen::process_event: audio_wire_status.speakerphone
Sep 30 19:58:43 192.168.42.133 phone:  REMAP EVENT audio_wire_status.speakerphone
Sep 30 19:58:43 192.168.42.133 phone:  ACTIVE 0 CHANNEL 1 AUDIO 1
Sep 30 19:58:43 192.168.42.133 phone:  @@@ new state: phone.idle
Sep 30 19:58:43 192.168.42.133 phone:  *** State phone.idle, process event: idle_hidden
Sep 30 19:58:43 192.168.42.133 phone:  VIEW EVENT: idle_hidden
Sep 30 19:58:43 192.168.42.133 phone:  HomeScreen::process_event: idle_hidden
Sep 30 19:58:43 192.168.42.133 phone:  REMAP EVENT idle_hidden
Sep 30 19:58:43 192.168.42.133 phone:  ==== State phone.idle, process event idle_hidden: no matching transition
Sep 30 19:58:43 192.168.42.133 phone:  @@@ new state: phone.idle
Sep 30 19:58:43 192.168.42.133 phone:  *** State phone.idle, process event: call_status.CALLING.0.idle_dial_3.<sip:--redacted-phone-number--@voice\.ctrl-alt-it\.com:5061;transport=tls>..0..none.role.caller.local_info."4701-Aaron C\. de Bruyn" <sip:4701@voice\.ctrl-alt-it\.com:5061;
Sep 30 19:58:43 192.168.42.133 phone:  VIEW EVENT: call_status.CALLING.0.idle_dial_3.<sip:--redacted-phone-number--@voice\.ctrl-alt-it\.com:5061;transport=tls>..0..none.role.caller.local_info."4701-Aaron C\. de Bruyn" <sip:4701@voice\.ctrl-alt-it\.com:5061;transport=tls>.local_cont
Sep 30 19:58:43 192.168.42.133 phone:  HomeScreen::process_event: call_status.CALLING.0.idle_dial_3.<sip:--redacted-phone-number--@voice\.ctrl-alt-it\.com:5061;transport=tls>..0..none.role.caller.local_info."4701-Aaron C\. de Bruyn" <sip:4701@voice\.ctrl-alt-it\.com:5061;transport=
Sep 30 19:58:43 192.168.42.133 phone:  REMAP EVENT call_status.CALLING.0.idle_dial_3.<sip:--redacted-phone-number--@voice\.ctrl-alt-it\.com:5061;transport=tls>..0..none.role.caller.local_info."4701-Aaron C\. de Bruyn" <sip:4701@voice\.ctrl-alt-it\.com:5061;transport=tls>.local_cont
Sep 30 19:58:43 192.168.42.133 phone:  PhoneModel: call_status.CALLING.0.idle_dial_3.<sip:--redacted-phone-number--@voice\.ctrl-alt-it\.com:5061;transport=tls>..0..none.role.caller.local_info."4701-Aaron C\. de Bruyn" <sip:4701@voice\.ctrl-alt-it\.com:5061;transport=tls>.local_cont
Sep 30 19:58:43 192.168.42.133 phone:  PhoneModel: NAME  NUMBER --redacted-phone-number--
Sep 30 19:58:43 192.168.42.133 phone:  Highest priority, 0 account
Sep 30 19:58:43 192.168.42.133 phone:  dbus_audio_wire(speakerphone)
Sep 30 19:58:43 192.168.42.133 phone:  ACTIVE 0 CHANNEL 1 AUDIO 1
Sep 30 19:58:43 192.168.42.133 phone:  dbus_audio_set_volume(speakerphone, output, 50)
Sep 30 19:58:43 192.168.42.133 phone:  ACTIVE 1 CHANNEL 1 AUDIO 1
Sep 30 19:58:43 192.168.42.133 phone:  AudioStreamManager::pauseStreaming
Sep 30 19:58:43 192.168.42.133 phone:  dbus_stop_tone(0)
Sep 30 19:58:43 192.168.42.133 phone:  dbus_stop_tone(1)
Sep 30 19:58:43 192.168.42.133 phone:  dbus_stop_file()
Sep 30 19:58:43 192.168.42.133 phone:  dbus_ehs_ring(0)
Sep 30 19:58:43 192.168.42.133 phone:  @@@ new state: phone.calling
Sep 30 19:58:43 192.168.42.133 phone:  Indicator cb
Sep 30 19:58:43 192.168.42.133 phone:  Line 0 update
Sep 30 19:58:43 192.168.42.133 phone:  ACTIVITY 8
Sep 30 19:58:43 192.168.42.133 phone:  _call_screen, cl_size:1, updated_call idle_dial_3 status:9
Sep 30 19:58:43 192.168.42.133 phone:  _call_screen, updated_call idle_dial_3 status:9 number:--redacted-phone-number--
Sep 30 19:58:43 192.168.42.133 core[988]:  core dbus_callback()
Sep 30 19:58:43 192.168.42.133 phone:  dbus_request_file url http://voice.--redacted--:82/image.php?token=445d5bd5112f79254c8fd94a61458854&did=--redacted-phone-number--
Sep 30 19:58:43 192.168.42.133 phone:  check_call_photo cURL url:http://voice.--redacted--:82/image.php?token=445d5bd5112f79254c8fd94a61458854&did=--redacted-phone-number-- file:/tmp/--redacted-phone-number--.png
Sep 30 19:58:43 192.168.42.133 phone:  dbus_hide_idle_apps()
Sep 30 19:58:43 192.168.42.133 core[988]:  callbridge: aud_set_call_device speakerphone speakerphone
Sep 30 19:58:43 192.168.42.133 core[988]:  callbridge: Already on this device
Sep 30 19:58:43 192.168.42.133 core[988]:  callbridge: dus_send_audio_wire_status
Sep 30 19:58:43 192.168.42.133 core[988]:  callbridge: dus_send_audio_volume_status
Sep 30 19:58:43 192.168.42.133 phone:  _set_top_label()
Sep 30 19:58:43 192.168.42.133 phone:  _softkeys()

I have verified the certificate being used on the application port is valid using openssl.

EPM is sending the correct cert to the phone when it downloads it’s config file.

One thing I did notice was a few examples in the forums of running “openssl s_client -connect server:5061” to check the cert. With the versions of openssl available on my various boxes, I get a protocol error and “no peer certificate available”. I’m not sure if openssl is capable of checking SIP-TLS certs or not due to also not knowing if SIP-TLS requires STARTTLS first (thereby requiring openssl to be able to speak -starttls sip, which it doesn’t).

Checking pjsip show transport 0.0.0.0-tls lists valid paths for all the certs, and I compared the cert against what’s being published in /tftpboot/whatever.cfg

I haven’t gone so far as to hack /tftpboot/whatever.cfg to see if I can include the entire chain yet, but I’m thinking Digium needs to update their cert store. Of course I have completely restarted asterisk.

Anyways, I’m continuing to troubleshoot and will let everyone know if I can track down the problem.

2

Probably tomorrow, there should be a more informative debug . . .

(TLS version offered and accepted and root certs acknowledged need to be copacetic between all endpoints )

3

Debugging on these phones is a major pain in the rear.
No SSH access, so all you get is the syslog debug output.
No way to run openssl s_client from the phone. No way to browse through the cert store, etc…

Anyways, I took the entire chain and tossed it into the /tftpboot config file. No dice.

I can see it making the connection using ssldump, negotiating TLS, and then the client drops.

I did notice something new in the log:
Sep 30 20:52:23 192.168.42.133 core[583]: middleman: cURL Error:60 Peer certificate cannot be authenticated with given CA certificates
Sep 30 20:52:23 192.168.42.133 core[583]: middleman: Response exceeds app space limits. cURL request aborted, 2147483647 remaining
Sep 30 20:52:23 192.168.42.133 core[583]: middleman: dbus_send_response() id:mmar543982103, type:cURL, out:curl_error, error:60
Sep 30 20:52:23 192.168.42.133 core[583]: Thread [0xb5287480] sending com.digium.middleman.resp.response onto the [1] queue

grumble

I want SSH access to my phone. :wink:

4

Oops–I put the wrong link in my first post:

https://community.freepbx.org/t/lets-encrypt-root-ca-cert-expiring-on-october-1st-2021/78233/18

5

Depending on ‘my phone’ termux can give you that ssh access.

6

Digium D-series phones only have http, sip, and sip-tls ports open. I am unaware of any way to access a shell.

7

I also forgot to mention–if you restart the phone and while it briefly displays the IP address you can tap a key, go into Network Settings and enable “Allow Dangerous Unsigned SSL Certificates”.

The phone will work fine until the next reboot or config update. Not the best solution, but it’s a quick-fix.

8

Off-topic, but I just found some Android-based devices (not Digium) that are failing TLS connectivity to LE cert. There’s nothing you can do about it on the server side – in my case it’s the Android version that is out of date and not going to be updated any time soon.

Solved with a $7.10 Comodo cert from namecheap. Hacking around due to LE is not worth it.

1 Like
9

And curl can interact with http with GET and PUT from a shell but android less than 7 might be a problem tomorrow

1 Like
10

You’re probably talking about the D70 with that horrible Android interface. I’m glad they EOL’d them. Only configurable using DPMA and not FTP or TFTP. The D60s and D65s can’t really install anything unless you want to get involved with writing a phone app in Node.

11

That takes all the fun out of troubleshooting the issue. :wink:

I reached out to a contact at Digium and let them know about it and how I duplicated it on a freshly installed test box. They are investigating my suspicions.

12

fwiw I tested just now with my p310 , tls / srtp working normally with the following

3.3.1 fw on phone , certman 16.0.18 , ca-certificates.noarch 2021.2.50-72.el7_9

1 Like
13

I see there’s an update this morning for ca-certificates to 2021.2.50…I can’t imagine that would fix anything on the phones (especially if you have client and server verification disabled for SSL/TLS/SRTP).

I have everything working at the moment using a non-letsencrypt cert. I’ll test switching back to LE this weekend.

EDIT: I’m running certman 15.0.47 which is listed as a version that has the fix for LE.

14

This is going to need a phone firmware update, which is in the works now. The current firmware has both certs installed.

I have reproduced this issue on a D65 using EPM and DPMA. Phone is running firmware 2_9_15 and as an immediate term work around, I have made the following basefile edit to the TOP section of the template I’m using for testing:

<setting id="allow_insecure_ssl"  value="1" />

image
image786×417 14.4 KB

The D65 will provision using the current certs, so pushing the change works as expected. I did not test with any other models but can if requested.

Once a firmware update is published that addresses this issue, you will want to revert this change, so it’s prob best to duplicate your existing template(s) and make the basefile edit. After which you can revert back to your stock template(s). This would also facilitate testing the change, where you can apply the edit to specific phones and test.

2 Likes
15

EPM Firmware bundle 1.39 for Digium phones was published overnight last night. I have a D65 a P310 and a D80 all on my desk now using TLS signaling with an LE cert. No issues.

1 Like
16

Thanks @lgaetz!

Just a heads-up, the changelog lists 2_9_15, but EPM shows 2_9_16 available.

https://wiki.asterisk.org/wiki/display/DIGIUM/Firmware

17

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