fred.bloggs

Ok thank you, the prefix search is the way we already do it. Its' just in the system mails (e.g. voice mail) the users see the wrong formated numbers. But if you are going to modify it with a trunk template update, that is highly apreciated! Thank you. Are there any ETAs for the update? I can also test it upfront, if needed.

---------------------------------------- Part 1: regarding your reply---------------------------------------- I know how to change the number interpretation for the trunk ("rewrite global numbers"). But I do not know how I can set the contact header explicitly to E164 format. Can you please advice how to do that? If this would be a setting we have to change on the easybell side, that is not possible, as there is no corresponindg setting on theire side. I tried to set "contact header value" to "{to}" on the trunk settings. But that did not help. Please also advice how to do that. ---------------------------------------- Part 2: general ---------------------------------------- In the easybell trunk I configured "rewrite global numbers" to "E.164 (without leading +)". The TO is correct "0711-xxxxxxx" but now the FROM is wrong "00-0153xxxxxx". If I change it to "Use + symbol at beginning" or "For Row", the TO is wrong "0711-49711xxxx" but now the FROM is correct "01538-123xxxx". So depending of the trunk setting, one is always correct but the corresponding other value is always wrong. I can not manage to get both numbers recognized correctly by Vodia. As in my previous post, here is how easybell announces the call on a Trunk that has multiple numbers: INVITE sip:49711xxxx@yy.yy.yy.yy:49326;transport=tls;line=xxxx SIP/2.0 Via: SIP/2.0/TLS zz.zz.zz.zz:5061;branch=xxxx;rport From: <sip:0153xxxx@sip.easybell.de>;tag=xxxxx To: <sip:49711xxxx@sip.easybell.de> CSeq: xxxx INVITE Call-ID: xxxxx Max-Forwards: 68 Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,PRACK Supported: histinfo,from-change Content-Type: application/sdp Content-Length: 555 Contact: <sip:2D7xxx-xxxx-xxxx@yy.yy.yyy.yy:5061;transport=tls> BUT a Trunk that has only one number assigned from easybell (also a trunk but other product) is announced like that: SIP/2.0 183 Session Progress Via: SIP/2.0/UDP yy.yy.yy.yy;branch=xxxx;rport=5060 From: <sip:0153xxxx@sip.easybell.de>;tag=xxxxx To: <sip:0049711xxxx@sip.easybell.de>;tag=xxxx Call-ID: xxxxx CSeq: 157 INVITE Contact: <sip:0049711xxx@4yy.yy.yy.yy:5060;transport=udp> Supported: 100rel, replaces, norefersub Allow: INVITE, ACK, CANCEL, BYE, REFER, PRACK, INFO, UPDATE Allow-Events: refer Accept: application/sdp User-Agent: Vodia-PBX/66.0.7 Content-Type: application/sdp Content-Length: 204 In this case however both the TO and FROM are recognized correctly by Vodia with the current trunk template. Note how easybell formats the TO in a different way. So I would appreciate, if you could modify the template in a way that both variants (trunk with multipe numbers and trunk with single number) would work, as we have different trunks form easybell (multi- and single numbers). If you need any other information to modify the template, feel free to ask. I am happy to help.

Here is the cert as it shows form Germany. Could it be related to the ECC keys they use instead of the RSA?

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

The provider is called easybell. You already have a template for that, but maybe they have changed the way they format numbers. https://translate.google.com/translate?sl=auto&tl=en&u=https://www.easybell.de/hilfe/fragen/fragen-zum-telefonanschluss/antwort/rufnummernformat-bei-eingehenden-anrufen.html They even have some if else: 1. If it is only a single number or the root number of a trunk it is international format 0049xxxxx 2. If it is an extension number of the trunk it is E.164 (49xxxxx) So maybe you can script it that both options would work.

We did:

Our SIP Provider does really strange things on inbound trunk calls: From: <sip:035xxxxxx@sip.xxxx.de> To: <sip:4935xxxxxx@sip.xxxx.de> They format the FROM with a leading 0 and the TO with E164 format. So when I change the Rewrite global numbers setting either the FROM number or the TO number is formatted correctly but the other one is always wrong. So I really would like to see the possibility to also manipulate inbound trunk IDs... Is there any chance to achieve this with the current version 66.0.6?

Hi, we have the same issue. Complete new installation on Ubuntu Server 20.04. We are comming form version 66.0.6 and I also tried with version 66.0.7. Same error: On google cloud console we only see a cryptic "compute" error when the vodia tries to access the API. With level 9 we get this log: [7] 21:05:50.673 https:speech.googleapis.com:443: DNS A returned 216.58.210.10ⓘ [7] 21:05:50.673 https:speech.googleapis.com:443: Connect to 216.58.210.10ⓘ [9] 21:05:50.677 https:speech.googleapis.com:443: Send request (158710 bytes)ⓘ POST https://speech.googleapis.com/v1/speech:recognize?key=xxxxxxxxxxxx HTTP/1.1 Host: speech.googleapis.com Content-Type: application/json; charset=utf-8" Content-Length: 158527 {"config":{"encoding":"LINEAR16","sampleRateHertz":8000,"languageCode":"de-DE","maxAlternatives":1,"profanityFilter":true,"model":"phone_call","enableAutomaticPunctuation":true,"enableWordTimeOffsets":false},"audio":{"content":"xxxxxx} [9] 21:05:50.677 Initialize TLS connectionⓘ [9] 21:05:50.677 HTTP 216.58.210.10: Send Client Hello(03036009..00020017)ⓘ [9] 21:05:50.690 HTTP 216.58.210.10: Receive Server Hello(03036009..00020100)ⓘ [9] 21:05:50.690 HTTP 216.58.210.10: Receive Certificate(000B7500..9D9CF5CA)ⓘ [9] 21:05:50.690 HTTP 216.58.210.10: Received chain with 2 certificatesⓘ [4] 21:05:50.690 Unknown DSA hash algorithm 2A864886F70D01010Bⓘ [5] 21:05:50.690 HTTP 216.58.210.10: Certificate for speech.googleapis.com could not be verifiedⓘ [9] 21:05:50.690 HTTP 216.58.210.10: Send Alert(022e)ⓘ [7] 21:05:50.694 https:speech.googleapis.com:443: TCP disconnectⓘ [7] 21:05:50.694 https:speech.googleapis.com:443: Return code 500ⓘ [8] 21:05:50.694 https:speech.googleapis.com:443: Return content (0 bytes)ⓘ [7] 21:05:50.694 Transscript for 7s failed with code 500ⓘ [7] 21:05:50.696 Closing connection https:speech.googleapis.com:443ⓘ From the console (CURL) we can communicate with the API without an issue. Looks like google implemented ECC certificates and Vodia can't handle the new encyption algorithms of curves.