Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by fred.bloggs

  1. Hi, I wanted to use service flags in dials plans, but this does not seem to work. I have a dial plan that allows the extensions to use a trunk, that supports clip no sreening and therefore using the extensions ANI. To this trunk I have added the service flag called "test". As a next trunk with higher pref, I added a second trunk that does not allow clip no screening and therefore setting the same outgoing number to all external calls: Main trunk = extension ANI 92.... = allways use the phone number with 92..... regardless of the extension ANI May expectation would be the following: When the service flag "test" is not active the extension ANI is set for outgoing calls, as the "main trunk" is used. When the service flag "test" is active the extension uses the second trunk and therefore the fixed number starting with 92... is used. But regardless of the state of the service flag "test", the first main trunk is always used and never set to disabled. It looks like the status of the service flag has no impact on the trunks. Maybe a bug?
  2. Yeah that would also be my expecation, but maybe I still get it wrong. So if I set an ACD on a BLF and have "Enable call pickup from extension BLF" active the BLF button should indicate an incomming call to that ACD and when I press the BLF button the call sould be transfered to that extension. But it does not work like this. The BLF button indicates the incomming call, but pressing the button does not pick the call but calling the ACD instead. Update: ok, when the extension is logged into the ACD, pressing the BFL button that is set to this specific ACD is indeed picking the call. I thought it was also possible, when the extension is not logged into the ACD. Obviously it is not. Is there a way to achive this?
  3. Yea. I do not want to touch templates, that is why I used the parameters "Advanced > Parameter > Yealink > Yealink General". I thought the settings in "Advanced > Parameter > Yealink > Yealink General" are of higher priority. But as I learned it is not. At least it may vary from parameter to parameter. So if this does not work and gets overwritten, your suggestion is to use the templates anyway? At least I want to prevent that Vodia resets manually changed settings with the next cycle of pushing configs to the phones. Otherwise I make manually changes to the phones to bypass Vodia defaults and after a day or so, they are gone due to Vodia regularly pushing standard configs out to the phones. The best way of cause would be one central place in Vodia where I can reliably overwrite default phone parameter settings.
  4. Ok, thank you. I got it working with the following settings 1. setting the trunk "regular ANI rule": 2. changing the easybell settings in the easybell web portal: https://login.easybell.de/phonesettings So as you suggested, I did not manipulate the from headers in the Vodia trunk settings: Important: for all that want to follow along, you need at least Vodia Version 66.0.7, buid date later than 5.2.2021 http://portal.vodia.com/downloads/pbx/version-66.0.7.xml Request: Form my point of view the Vodia easybell template needs the following minor updates in addition to the changes you already put in for version 66.0.7: add the "regualr ANI rule" as descibed above as default settings set the "rewrite global numbers" to E.164 as default settings add a comment somewhere, that on easybell web management portal the clip-no-screening options need to be changed to p-asserted-identity. That for sure would help others to get it working.
  5. Hi, I would like to have a BLF for an "agent group" that indicates callers in line and when pressing the BLF button, picking the next caller in line. What I could manage to do is the following: adding a BLF for the agent group -> it indicates when callers are in queue, but when pressing the button the callers are not picket; instead the extension calls the agent group adding a BLF that does a call pickup -> it picks up calls from queues but does not indicate via BLF when a caller is in queue. Our goal is to combine both settings. Within the agent group settings I found the option "Enable call pickup from extension BLF"; but I can not figure out how that works. Can you please tell me how to realize that? Thanks.
  6. This is also true for agents that are "allowed to add themselves". If they log in and out, they are added as "primary agents", which is of cause also not what you want
  7. Hi, as a follow up of this post, I think we need additional adjustments on Vodia side to the ones you already made in version 66.0.7, regarding the easybell trunk template: The inbound calls work perfectly and the numbers in Version 66.0.7 get presented in the correct way, but after your changes on the template, we lost the ability for clip-no-screening; that is using custom ANI set on the extensions. https://translate.google.com/translate?hl=&sl=de&tl=en&u=https%3A%2F%2Fwww.easybell.de%2Fhilfe%2Ftelefon-konfiguration%2Fip-telefonanlagen-fuer-unsere-sip-trunks%2Fantwort%2Fvodia-ip-pbx.html 1. In which field do you transmit the ANI? These are the settings I can choose form in the easybell trunk interface on easybell side; with the old Vodia trunk template "From-Display" was working fine. 2. Vodia easybell template settings Before the changes in Version 66.0.7 the following settings worked and enabled clip no screening; but no this does not work anymore: That is: "{ext-ani}" <sip:{trunk-account}@sip.easybell.de> and "{ext-ani}" <sip:{trunk-account}@secure.sip.easybell.de> for TLS If you need to hard code this to the template, please make both versions TLS and non TLS available (see different FQDNs) Thank you.
  8. Hi, I tried to change template paramters for yealink phones on domain level via Advanced > Paramer > Yealink > Yealink General. This does not work for all settings. For some it works, but especially the LDAP related settings are not applied correctly: ldap.tls_mode = 2 ldap.port = 2346 I guess the LDAP default settings from Vodia are applied at a later stage and therefore these settings get overwritten by the default ones. Update: parameters that also do not work local_time.date_format = 5 parameters that do work phone_setting.backlight_time = 60 phone_setting.inactive_backlight_level = 1 Why is this? Is it possible to prioritize all custom parameters over the default ones?
  9. Ok, thanks to your comment I got it working The trick is to set the "System management DNS address" on system level to the same name as the domain name. So you get two LE certificates. One for the domain using SNI and one for the system not unsing SNI. Because the DNS names are the same, it works. Hope this does not cause any side effects though
  10. We do have a valid LE certificate thanks to the support of DNS made easy But the Yealinks don't take it unfortunately. There should no SNI be involved - strange. Do you support XML phone book?
  11. Ok, thanks for your fast reply. We are using only one tenant, that is one domain and we have a dedicated IP. Is it possible to bypass SNI of the vodia web server some how? Btw. we are using TLS with SIP over the whole path right to the SIP Trunk provider
  12. Hi, we are trying to get our phones using the phone book via LDAP TLS. All of our phones are from yealink. Having the phones provisioned via Vodia 66.0.7 build (5.2.2021) works fine and also phonebook bia LDAP does work. But we have a hard time migrating to LDAP TLS. Here are the Vodia logs after changing from LDAP to LDAPS: [9] 10:00:22.600 LDAP xx.xx.xx.xx: Receive Client Hello(xxxxxxx)ⓘ [9] 10:00:22.600 LDAP xx.xx.xx.xx:123: No session ID in client helloⓘ [9] 10:00:22.600 LDAP xx.xx.xx.xx:123: Matched cipher suite RSA_WITH_AES_256_CBC_SHAⓘ [9] 10:00:22.614 LDAP xx.xx.xx.xx:123: Send Server Hello(xxxxxxx)ⓘ [9] 10:00:22.614 LDAP xx.xx.xx.xx:123: Send Certificate(xxxxxxx)ⓘ [9] 10:00:22.614 LDAP xx.xx.xx.xx:123: Send Hello Done()ⓘ [5] 10:00:22.648 LDAP xx.xx.xx.xx:123: Alert Fatal (2): Unknown CA (48)ⓘ So Vodia responds with "unkonwn ca". I also tried to use Thunderbird which is also able to connect to LDAPS phone books. It succesfully connects over TLS: [9] 10:03:08.585 LDAP xx.xx.xx.xx:123: Receive Client Hello(xxxxxxx)ⓘ [7] 10:03:08.585 LDAP xx.xx.xx.xx:123: TLS in domain pbx.somedomain.testⓘ [9] 10:03:08.585 Supported Versions 0403040303ⓘ [6] 10:03:08.585 LDAP xx.xx.xx.xx:123: Session xxxxxxx not foundⓘ [9] 10:03:08.585 LDAP xx.xx.xx.xx:123: Matched cipher suite ECDHE_RSA_WITH_AES_128_CBC_SHAⓘ [7] 10:03:08.585 LDAP xx.xx.xx.xx:123: Received client hello for pbx.somedomain.testⓘ [9] 10:03:08.585 LDAP xx.xx.xx.xx:123: Send Server Hello(xxxxxxx)ⓘ [9] 10:03:08.585 LDAP xx.xx.xx.xx:123: Send Certificate(xxxxxxx)ⓘ [9] 10:03:08.717 LDAP xx.xx.xx.xx:123: Send Server Key Exchange(xxxxxxx)ⓘ [9] 10:03:08.717 LDAP xx.xx.xx.xx:123: Send Hello Done()ⓘ [9] 10:03:08.747 LDAP xx.xx.xx.xx:123: Receive Client Key Exchange(xxxxxxx)ⓘ [9] 10:03:08.762 LDAP xx.xx.xx.xx:123: Pre Master Secret(xxxxxxx)ⓘ [9] 10:03:08.763 LDAP xx.xx.xx.xx:123: Client Random(xxxxxxx)ⓘ [9] 10:03:08.763 LDAP xx.xx.xx.xx:123: Server Random(6xxxxxxx)ⓘ [9] 10:03:08.763 LDAP xx.xx.xx.xx:123: Master Secret(xxxxxxx)ⓘ [9] 10:03:08.763 LDAP xx.xx.xx.xx:123: Receive Change Cipher Spec(01)ⓘ [9] 10:03:08.763 LDAP xx.xx.xx.xx:123: Send Change Cipher Spec(01)ⓘ [9] 10:03:08.763 LDAP xx.xx.xx.xx:123: Perform Change Cipher Spec(c013)ⓘ [9] 10:03:08.763 LDAP xx.xx.xx.xx:123: Key Block(xxxxxxx)ⓘ [9] 10:03:08.763 LDAP xx.xx.xx.xx:123: Client Write MAC Secret(xxxxxxx)ⓘ [9] 10:03:08.763 LDAP xx.xx.xx.xx:123: Server Write MAC Secret(xxxxxxx)ⓘ [9] 10:03:08.763 LDAP xx.xx.xx.xx:123: Client Write Key(xxxxxxx)ⓘ [9] 10:03:08.763 LDAP xx.xx.xx.xx:123: Server Write Key(xxxxxxx)ⓘ [9] 10:03:08.763 LDAP xx.xx.xx.xx:123: Receive Process Finished(xxxxxxx)ⓘ [9] 10:03:08.764 LDAP xx.xx.xx.xx:123: Send Finished(xxxxxxx)ⓘ [9] 10:03:08.787 Processing LDAP request type 0 (55 bytes)ⓘ [9] 10:03:08.787 Try to bind to username@pbx.somedomain.testⓘ [6] 10:03:08.787 Successfully bind to user pbx.somedomain.test\usernameⓘ [9] 10:03:08.813 Processing LDAP request type 3 (1129 bytes)ⓘ [7] 10:03:08.813 Search request (&((|(cn=*test*)(givenName=*test*)(sn=*test*)(mozillaNickname=*test*)(mail=*test*)(mozillaSecondEmail=*test*)((&(description=*test*)))(o=*test*)(ou=*test*)(title=*test*)(mozillaWorkUrl=*test*)(mozillaHomeUrl=*test*))))ⓘ [9] 10:03:08.813 Search local extensionsⓘ [9] 10:03:08.813 Search address book of userⓘ [9] 10:03:08.813 Search address book of domainⓘ [6] 10:03:08.814 Search came up with 2 resultsⓘ [8] 10:03:08.814 Returning result testⓘ [8] 10:03:08.814 Search doneⓘ Can you point me to some direction what needs to be done to make LDAP over TLS work on yealink? We have connecetd phones via direct internet access to the Vodia (no VPN), and I do not feel comfortable passing address book information and login data unencrypted via the internet. Thanks.
  13. With this fix and starting with version 66.0.7, buid 31.1.2021 it should now also work for Italian language perfectly fine.
  14. 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
  15. See this post for solution; almoondsllc was right. For non US / UK / Russian / Spanish language, Vodia uses the wrong API setting of the AI-model of the google API.
  16. 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
  17. 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
  18. Tested with version 66.0.7 build Jan 25 2021. Works perfectly, for both type of easybell trunks now! Thank you very much for your fast support
  19. It makes sense to use ECC keys for an API on google side, probably much better performance / less overhead.
  20. 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.
  21. ---------------------------------------- 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.
  22. Here is the cert as it shows form Germany. Could it be related to the ECC keys they use instead of the RSA?
  23. 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".
  24. 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.
  • Create New...