Jump to content

fred.bloggs

Members
  • Posts

    33
  • Joined

  • Last visited

Posts posted by fred.bloggs

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

  2. ---------------------------------------- Part 1: regarding your reply----------------------------------------

    Quote

     You can set the contact header explicitly for the trunk to the E164-formatted number—would that solve the problem in all cases (and set the number interpretation for the trunk to E164)?

    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.

    Quote

    The alternative would be to have the PBX look at the To-header, and not the Request-URI for an incoming call

    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.

     

     

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

     

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

  5. 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?

  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: 

    Quote

    Certificate for speech.googleapis.com could not be verified

    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.

×
×
  • Create New...