fred.bloggs
-
Posts
33 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Posts posted by fred.bloggs
-
-
Yes, you are right let me explain again:
I set up an extension and assigned a mobile number to that extension. When I call the extension with the assigned mobile number, the personal assistant takes the call. -> the way it should be
I now set up an ACD and assign that extension to the ACD. When I now use the very same mobile number to call that ACD, the call never gets routed. On the mobile you just hear music on hold but non of the assigned agents phones to the ACD rings. Infinite music.
I do not think that this is the desired behavior as we have an ACD on our main line and when one employee tries to call via a mobile phone he never gets through.
-
I switched back to 3.5.5 but mutli factor auth via Mail does still not work. It says the following without even asking for the 2nd factor:
Error: Login credentials are incorrect. Please try again or contact your system administratorIf I use the exact same login data on the web inteface it works perfectly with multi auth.
-
Hi,
we have enabled 2 factor auth. In our case via E-Mail. This is not supported by the windows app. Please add support.
Thanks.
-
Hi, on your manual pages you suggest coping the whole pbx folder for backup:
https://doc.vodia.com/docs/how-to-backup-the-pbx
/usr/local/pbxIs it required to stop the pbx service before backing up, to make sure we have consistent backups? Or is it supported to backup without stopping the service?
At the moment we stop the service though before making a backup every night with:
service pbx stopIf it is recommended to stop the service, an update to the documentation would be good.
-
Version: 67.0.6 (from 26.7.2021)
- Domain > General Setting > Trust Caller ID --> on
- Assign cell phone number to an account
- Assign account to agent group
- Log in to agent group with account
- call agent group from cell phone
--> call gets never put through and stays in queue forever, non assigned extensions to the agent group rings
Temporary solution: log out account from agent group or disable Trust Caller ID
How it should be:
- when calling the extension directly via mobile, the virtual personal assistant should answer
- when calling the agent group via mobile, the call should be routed to the queue as any other call would
-
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 ANIMay 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?
-
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?
-
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.
-
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.xmlRequest: 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.
-
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.
-
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
-
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.
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.
-
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 = 2346I 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 = 5parameters that do work
phone_setting.backlight_time = 60 phone_setting.inactive_backlight_level = 1Why is this? Is it possible to prioritize all custom parameters over the default ones?
-
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
-
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?
-
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
-
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.
-
With this fix
and starting with version 66.0.7, buid 31.1.2021 it should now also work for Italian language perfectly fine.
-
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
-
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.
-
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
-
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
-
Quote
If you like, try the latest 66.0.7 build this should include a new setup for easybell. You'll have to set up a new trunk though.
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
-
It makes sense to use ECC keys for an API on google side, probably much better performance / less overhead.
is it required to stop the pbx service before backing up?
in Linux-related Topics
Posted
Thank you for clarification. I was not sure if there are some databases used that would end up corrupted in the backup file when not stopping the service. If it is only "flat" files - sure no problems to expect when scheduling the backup in a less busy time at night.