vicidial.org

I got an email from our voice provider that they are removing support for TLS 1.0 and TLS 1.1 and that services will no longer work, all applications must use TLS 1.2 or greater. According to the specs in my signature, am I able to continue to use our current system? I searched the admin and manager manuals for TLS, but didn't find much info - looks like 1.2 was published in 2008, so this should use it right?

I know we're running on a version outdated by a couple years but it has been quite reliable for us, we don't do anything too out of the box, so I don't want to update if it's not necessary.

its probably in reference to STIR/SHAKEN thats coming up.....

try installing these packages: ncurses-devel libxml2-devel sqlite-devel libsrtp-devel libuuid-devel openssl-devel

I believe I may need to upgrade my version of Vicidial to support TLS 1.2 if I want to keep the carrier I'm currently using (and presumably any reputable carrier moving forward).

I'm having a tough time finding what version of Asterisk started using TLS 1.2, does anyone know? So I can determine what version of Vicidial I need to upgrade to.

naw, vicibox 8 supports it, you just need to install those packages i mentioned above, have you tried it yet? if anything hit me up on skype, ill help guide you through it

Can't find a couple packages, these are the results when searching.

Is ghc-persistent correct? Which package for "openssl-devel"?

Code: Select all

zypper search -s sqlite-devel

S | Name                        | Type    | Version      | Arch   | Repository
--+-----------------------------+---------+--------------+--------+-----------------------
  | ghc-persistent-sqlite-devel | package | 2.6.0.1-1.11 | x86_64 | openSUSE-Leap-42.3-Oss


Code: Select all

zypper search -s openssl-devel

S | Name                          | Type    | Version       | Arch   | Repository
--+-------------------------------+---------+---------------+--------+--------------------------
  | ghc-HsOpenSSL-devel           | package | 0.11.4.4-1.11 | x86_64 | openSUSE-Leap-42.3-Oss
  | ghc-hopenssl-devel            | package | 1.7-1.11      | x86_64 | openSUSE-Leap-42.3-Oss
  | ghc-http-client-openssl-devel | package | 0.2.0.4-1.11  | x86_64 | openSUSE-Leap-42.3-Oss
  | libgnutls-openssl-devel       | package | 3.3.27-2.3.1  | x86_64 | openSUSE-Leap-42.3-Update
  | libgnutls-openssl-devel       | package | 3.3.27-1.5    | x86_64 | openSUSE-Leap-42.3-Oss
  | libopenssl-devel              | package | 1.0.2j-38.1   | x86_64 | openSUSE-Leap-42.3-Update
  | libopenssl-devel              | package | 1.0.2j-35.1   | x86_64 | openSUSE-Leap-42.3-Update
  | libopenssl-devel              | package | 1.0.2j-32.1   | x86_64 | openSUSE-Leap-42.3-Update
  | libopenssl-devel              | package | 1.0.2j-29.1   | x86_64 | openSUSE-Leap-42.3-Update
  | libopenssl-devel              | package | 1.0.2j-25.1   | x86_64 | openSUSE-Leap-42.3-Update
  | libopenssl-devel              | package | 1.0.2j-22.1   | x86_64 | openSUSE-Leap-42.3-Update
  | libopenssl-devel              | package | 1.0.2j-19.1   | x86_64 | openSUSE-Leap-42.3-Update
  | libopenssl-devel              | package | 1.0.2j-16.1   | x86_64 | openSUSE-Leap-42.3-Update
  | libopenssl-devel              | package | 1.0.2j-13.1   | x86_64 | openSUSE-Leap-42.3-Update
  | libopenssl-devel              | package | 1.0.2j-10.1   | x86_64 | openSUSE-Leap-42.3-Update
  | libopenssl-devel              | package | 1.0.2j-7.3    | x86_64 | openSUSE-Leap-42.3-Oss
  | libopenssl-devel-32bit        | package | 1.0.2j-38.1   | x86_64 | openSUSE-Leap-42.3-Update
  | libopenssl-devel-32bit        | package | 1.0.2j-35.1   | x86_64 | openSUSE-Leap-42.3-Update
  | libopenssl-devel-32bit        | package | 1.0.2j-32.1   | x86_64 | openSUSE-Leap-42.3-Update
  | libopenssl-devel-32bit        | package | 1.0.2j-29.1   | x86_64 | openSUSE-Leap-42.3-Update
  | libopenssl-devel-32bit        | package | 1.0.2j-25.1   | x86_64 | openSUSE-Leap-42.3-Update
  | libopenssl-devel-32bit        | package | 1.0.2j-22.1   | x86_64 | openSUSE-Leap-42.3-Update
  | libopenssl-devel-32bit        | package | 1.0.2j-19.1   | x86_64 | openSUSE-Leap-42.3-Update
  | libopenssl-devel-32bit        | package | 1.0.2j-16.1   | x86_64 | openSUSE-Leap-42.3-Update
  | libopenssl-devel-32bit        | package | 1.0.2j-13.1   | x86_64 | openSUSE-Leap-42.3-Update
  | libopenssl-devel-32bit        | package | 1.0.2j-10.1   | x86_64 | openSUSE-Leap-42.3-Update
  | libopenssl-devel-32bit        | package | 1.0.2j-7.3    | x86_64 | openSUSE-Leap-42.3-Oss
  | xmlsec1-openssl-devel         | package | 1.2.26-10.1   | x86_64 | openSUSE-Leap-42.3-Update
  | xmlsec1-openssl-devel         | package | 1.2.24-7.2    | x86_64 | openSUSE-Leap-42.3-Update
  | xmlsec1-openssl-devel         | package | 1.2.23-4.1    | x86_64 | openSUSE-Leap-42.3-Oss


im not sure with the sqlite, try to find sqlite3 perhaps and for the latter, use libopenssl-devel | package | 1.0.2j-38.1 | x86_64 | openSUSE-Leap-42.3-Update

Transport Layer Security (TLS) provides encryption for call signaling , if you wont encrypt your calls you don't need to worry about it

you have to with most carriers very soon.....STIR/SHAKEN

https://www.fcc.gov/call-authentication

carpenox wrote:you have to with most carriers very soon.....STIR/SHAKEN

https://www.fcc.gov/call-authentication

STIR/SHAKEN is only to avoid caller ID SPAM but this doesn't means will be necessarily needed in order the calls to work, also could be possible that carriers do the process between then and that the user agent client (UAC), in our case Asterisk wont need to make any special configuration. But in the hypothetic case if is needed to configure the STIR/SHAKEN Asterisk already have support for it, but it works with PJSIP and VICI trunk is based on chan_sip

https://www.asterisk.org/stir-shaken-in-asterisk/

yes this is true, it is in asterisk 16 but either way, carrier are going to all be required to use call token authentication(stir/shaken) to pass calls onto the main telcos such as att, tmobile, verizon, etc. and some have already made these changes that are to take place in June which is why calls have stopped going through as much and caller pickup ratios are way low around the globe.