fred.bloggs Posted January 22, 2021 Report Share Posted January 22, 2021 2 hours ago, Support said: Under /reg_security.htm , for the "TLS max version" setting, can you try to set it to the highest version available and try this again on 66.0.7? Nope no success. We are on Version 66.0.7 and the "TLS max version" was already set to "highest availaible version". I also tried to set it manually to "TLS 1.2" and back again to "highest availaible version". No change, same Error "Certificate for speech.googleapis.com could not be verified". Link to comment Share on other sites More sharing options...
Vodia PBX Posted January 23, 2021 Report Share Posted January 23, 2021 I have the feeling that Google uses a different server setup in Europe than they do in the USA. You can easily check what they send by using the browser to https://speech.googleapis.com and then inspect the certificate (ignore the 404 not found): Link to comment Share on other sites More sharing options...
fred.bloggs Posted January 24, 2021 Report Share Posted January 24, 2021 Here is the cert as it shows form Germany. Could it be related to the ECC keys they use instead of the RSA? Link to comment Share on other sites More sharing options...
Vodia PBX Posted January 25, 2021 Report Share Posted January 25, 2021 Yes absolutely. The PBX (in recent versions) requests only RSA certificates, not sure why Google sends the ECC certificate. That should be the case for PBX versions built after November 19. What build date are you using? Link to comment Share on other sites More sharing options...
fred.bloggs Posted January 25, 2021 Report Share Posted January 25, 2021 It makes sense to use ECC keys for an API on google side, probably much better performance / less overhead. Link to comment Share on other sites More sharing options...
Vodia PBX Posted January 25, 2021 Report Share Posted January 25, 2021 Ok after some digging it seems that the problem is that the GlobalSign certificate which expires at the end of the year is not part of the standard certificate distribution any more. But it seems of you manually import it into the PBX, it will work: -----BEGIN CERTIFICATE----- MIIDujCCAqKgAwIBAgILBAAAAAABD4Ym5g0wDQYJKoZIhvcNAQEFBQAwTDEgMB4G A1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjIxEzARBgNVBAoTCkdsb2JhbFNp Z24xEzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDYxMjE1MDgwMDAwWhcNMjExMjE1 MDgwMDAwWjBMMSAwHgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMjETMBEG A1UEChMKR2xvYmFsU2lnbjETMBEGA1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAKbPJA6+Lm8omUVCxKs+IVSbC9N/hHD6ErPL v4dfxn+G07IwXNb9rfF73OX4YJYJkhD10FPe+3t+c4isUoh7SqbKSaZeqKeMWhG8 eoLrvozps6yWJQeXSpkqBy+0Hne/ig+1AnwblrjFuTosvNYSuetZfeLQBoZfXklq tTleiDTsvHgMCJiEbKjNS7SgfQx5TfC4LcshytVsW33hoCmEofnTlEnLJGKRILzd C9XZzPnqJworc5HGnRusyMvo4KD0L5CLTfuwNhv2GXqF4G3yYROIXJ/gkwpRl4pa zq+r1feqCapgvdzZX99yqWATXgAByUr6P6TqBwMhAo6CygPCm48CAwEAAaOBnDCB mTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUm+IH V2ccHsBqBt5ZtJot39wZhi4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5n bG9iYWxzaWduLm5ldC9yb290LXIyLmNybDAfBgNVHSMEGDAWgBSb4gdXZxwewGoG 3lm0mi3f3BmGLjANBgkqhkiG9w0BAQUFAAOCAQEAmYFThxxol4aR7OBKuEQLq4Gs J0/WwbgcQ3izDJr86iw8bmEbTUsp9Z8FHSbBuOmDAGJFtqkIk7mpM0sYmsL4h4hO 291xNBrBVNpGP+DTKqttVCL1OmLNIG+6KYnX3ZHu01yiPqFbQfXf5WRDLenVOavS ot+3i9DAgBkcRcAtjOj4LaR0VknFBbVPFd5uRHg5h6h+u/N5GJG79G+dwfCMNYxd AfvDbbnvRG15RjF+Cv6pgsH/76tuIMRQyV+dTZsXjAzlAcmgQWpzU/qlULRuJQ/7 TBj0/VLZjmmx6BEP3ojY+x1J96relc8geMJgEtslQIxq/H5COEBkEveegeGTLg== -----END CERTIFICATE----- Obviously, it is only a question of time until Google changes it. Hopefully they don't forget . Link to comment Share on other sites More sharing options...
fred.bloggs Posted January 26, 2021 Report Share Posted January 26, 2021 Ok, we are making progress After importing the certificate (settings > security > cretificates > trusted root ca for server auth) in version 66.0.7, build 25.1.2021 the error "unknown dsa hash" error is gone. BUT The voicemail transcription still does not work. No transcriptions are attached to voicemail notification mails. A attempt to access the google API is made by Vodia, we can see this in the google console api page. IPs are whitelisted, API key is valid as we can connect from the Vodia server via curl to the API with exact same credentials. This is from the google console: Anfragen = requests; Fehler = error Link to comment Share on other sites More sharing options...
Vodia PBX Posted January 27, 2021 Report Share Posted January 27, 2021 We actually made a new version that should handle the certificate situation better. You might have to delete all Root CA and reset them. Enabling the API is not very straightforward, we also needed to tinker with the Google console to get it working. The response in the PBX log for web client usually provides some useful tips from Google what needs to be done. Link to comment Share on other sites More sharing options...
fred.bloggs Posted January 31, 2021 Report Share Posted January 31, 2021 Info: scroll down to Update 3 - there is the solution, but it needs a change on Vodia side. We turned log for web client to log level 9: { "error": { "code": 400, "message": "Invalid recognition 'config': The phone_call model is currently not supported for language : de-DE.", "status": "INVALID_ARGUMENT" } } Update: I changed the system language settings to English, and what shall I say. Its working. But of cause it tires to use English pattern which results in a mess for German language If I recode the voicemail in English language it gets transcribed perfectly. Not a solution of course. German language is supported by the api: https://cloud.google.com/speech-to-text/docs/languages?hl=en The api calls look not too bad from Vodia, still with the en-US its working, with de-DE it is not: {"config":{"encoding":"LINEAR16","sampleRateHertz":8000,"languageCode":"en-US","maxAlternatives":1,"profanityFilter":true,"model":"phone_call","enableAutomaticPunctuation":true,"enableWordTimeOffsets":false},"audio":{"content":""} {"config":{"encoding":"LINEAR16","sampleRateHertz":8000,"languageCode":"de-DE","maxAlternatives":1,"profanityFilter":true,"model":"phone_call","enableAutomaticPunctuation":true,"enableWordTimeOffsets":false},"audio":{"content":""} Update 2: https://cloud.google.com/speech-to-text/docs/basics#select-model Looks like the api setting "model:phone_call" is not supported by all languages. I read in an old post on google mailing list, that German language and probably Italian is only supported with the "model: default". That was 2 years ago, but maybe the restrictions still apply. So maybe you can find out for which languages the restrictions by the google API apply and then just change the AI-algorithm within the API to "model:default". That should solve the problem. Update 3: Here you go: https://cloud.google.com/blog/products/ai-machine-learning/new-features-models-and-languages-for-speech-to-text as of March 2020: - US - UK - Russian - Spanish (US) Every other language needs the "model: default" profile. Looking forward to the next Vodia release Link to comment Share on other sites More sharing options...
Vodia PBX Posted February 1, 2021 Report Share Posted February 1, 2021 Thanks so much! If you like try the latest 66.0.7 build. Link to comment Share on other sites More sharing options...
fred.bloggs Posted February 1, 2021 Report Share Posted February 1, 2021 Yupp, it is working now. {"config":{"encoding":"LINEAR16","sampleRateHertz":8000,"languageCode":"de-DE","maxAlternatives":1,"profanityFilter":true,"model":"default","enableAutomaticPunctuation":true,"enableWordTimeOffsets":false},"audio":{"content":""} With German as "default web interface language" and Version 66.0.7 Build 31.01.2021, 20:30:30 it is working as expected. Now for German language settings the "model" in the API is set to "default", wich is correct as "phone_call" is not supported by google API yet. I also double checked with English, there it is still "phone_call" as expected, as this is supported for English language. THANK YOU - for your always astonishing fast replies and super fast bug fix releases. Highly appreciated. By the way: deleting the Root CAs through Web Interface and Resetting does not address the certificate issue; I still needed to import the certificate manually. I would try with a fresh installation, but I do not want to loose activations on the licence Link to comment Share on other sites More sharing options...
Recommended Posts