Jump to content


  • Posts

  • Joined

  • Last visited

1 Follower

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

fred.bloggs's Achievements


Newbie (1/14)



  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.
  • Create New...