GregV
-
Posts
40 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Posts posted by GregV
-
-
Thanks, thats worked!!
-
Perfect, that will work well however where do I put this URL?
-
Hi Vodia, how did your testing go on this?
Greg -
I use an SMS gateway that expects to receive a HTTP GET request like;
http://[serveraddress]:[port]/v1/sms/send/?phone=[destnumber]&message=[message]
Where can I enter these parameters in Vodia PBX Version 67.0.6?
When I select HTTP GET I am asked for Username or account & Application secret.
-
Thank you.
What I'm actually trying to achieve is a visual indicator on the IP handsets so clients can see how many calls are waiting to be answered.
It doesn't matter to me how the system is holding the calls, as long as the client can see how busy the system is with calls waiting.
I know this can be achieved via the web interface, however for users that do not use this I would like to have a bank of BLFs that light up red or flash when there is a call waiting in the system to be answered.
To achieve this it would be nice if calls could be sent to Park Orbit and wait there until answered but the system won't send calls to Park Orbit unless the users does it.
So I'm exploring other options to have a call queue where the people in the queue is visually apparent on the handsets.
Using cascading Agent Groups with a Max of one call per group actually works, the only problem is you cannot pickup the call by pressing the BLF, you need to do *87 Call pickup.
Another thought is it might be nice if the Label of the Agent Group BLF could be auto updated with the current number of calls in an Agent Group waiting.
If you have any suggestions as to how I can achieve a handset visual indication of how many calls are waiting to be answered, that would be great.
I realize a lot of this is not possible at this time, but maybe you could take some of it as a product improvement suggestion if you think it worthwhile and for the greater benefit of all users.
Thank you for your support.
Greg
-
Vodia Support,
When using the Vodia App to Transfer a call to another extension, the domain's Transfer Reminder doesn't activate.
Scenario would be, while on a call in the App, tap Transfer, then Extensions, then the extension to transfer to, then transfer.
You lose the call immediately from the App and it starts ringing the other extension as is expected with a Blind Transfer, however the domains Transfer Reminder doesn't initiate after the allotted time.
Transfer Reminder does works for blind transfers from an IP Handset, just not from the Vodia App.
Also transferring to an external number fails. Constantly getting complaints from clients on this one.
Scenario would be, while on a call using the App, tap Transfer, then "Dial Number", then dial the number, then tap orange right arrow.
Call is lost and caller hung up on.
I have been advising clients to place the call on Hold, then dial the number using "Dialpad", then transfer the call to Held call where the call is waiting. This works but is the long way around.
Also the App suffers from a white screen problem I have customers complaining about frequently.
If the App wakes up to receive an incoming call, but you don't answer the call, the screen goes white and you can't get back into the App until you close it down and reopen it.
PM me for a video I recorded of this occurring.
This relates to Android, unsure if problem also exists on iOS.
PBX is 67.0.6 (Jul 26 2021 17:24:39)
App version I'm using is 4.0.13
Apart from these minor issues the App is a great addition to the Vodia platform.Thank you,
Greg
-
Hi Daniel,
I too had the same problem and with T54W as well.
As Vodia have suggested, putting the transfer.dsskey_deal_type in the yealink_common.txt file worked a treat.
I set it to 4 to give the user the option of what type of transfer they wanted.
I found the user can still do a consultative transfer though if they wish, as they could press transfer before the call is answered which is seen as consultative, so for that scenario I created an AA that plays a message saying "Your call is being forwarded to reception" then rings the reception ring group... I then set all extensions call forward no answer to go to AA after 20 seconds. The Transfer Reminder is 15 seconds so it will kick in first if its a blind transfer. Works well.
You can even use a {if model == "t54w"} so it only applies to t54w.
The problem I have now, which I will open another discussion on, is the Transfer Reminder doesn't seem to work when using the Vodia App to transfer a call even though it is a blind transfer you're doing.
Greg
-
Thank you for testing this for me.
I tested with a snom also, and have found as you have suggested, when a call is in an Agent Group, but there is no Agent ringing, the BLF for the Agent Group does not flash.
This is a problem if all agents are busy. It means that another handset can't collect the call if they wished to.
By star code workaround, I assume you mean Group Pickup *87? This does work to collect the call even if the Agent Group BLF is not blinking, but if you're to do this, you're having to effectively double up on BLFs for each agent group. One to show you if there is a call waiting in the group and another to pickup the call.
Is there a work around to force the BLF to blink wherever a call is in the Agent Group regardless if there is an Agent ringing? -
Vodia Support,
I'm having trouble retrieving a call from an Agent group using a BLF key.
Agent group is 702.
Handset is a Yealink T43U
BLF is configured using Buttons and the Button is selected as Type = Agent Group, Parameter = 702.
The BLF key assigned to the Agent group 702 glows red indicating there is a call in the agent group.
Pressing the red BLF should enable me to retrieve the call however instead it initiates a new call to the agent group and the handsets is placed in the agent group in the queue as another call.
Dialing *87702 works to retrieve the call, however if this is programmed in as a BLF as the parameter, then the light will not glow red when a call is in the Agent Group.
I have turned on "Enable call pickup from extension BLF" within Agent Group 702
I would like to be able to retrieve the call from the Agent group, when the BLF is showing red, by pressing the BLF key.
The handset is not ringing at the time.
Greg -
I've upgraded to 4gb memory and have not seen the problem return.
Thank you both for your assistance.
Greg
-
1 minute ago, DanielA said:
1gig seems a bit on the low side - we we're running with 4GB and it currently sits around 1.4gb
First time it happened to us, the Azure VM just restarted itself and everything came back online.
Second time we had to manually intervene.
Since upgrading we haven't had an issue (still keeping an eye on it though)
I'd suggest opening a support ticket - support.vodia.comthe memory requirements are relative like anything... given under normal circumstances the instance runs at only 330mb max memory and average 10% CPU, at this point the resources are adequate. In anycase, every-time this occurs its the pbxctrl that is the process at fault and the OS kicks in and kills it. then it restarts and all is good once again.
Thanks Daniel, I'll open a ticket with Vodia, I haven't done that yet.
-
7 minutes ago, DanielA said:
We encountered this issue a few weeks back - what version are you running?
Upgraded to 67.0.6 and haven't encountered the issue again.Hi Daniel,
Running 67.0.6
Was running 67.0.5 and has same problem.Still occurring on 67.0.6.
Greg
-
Here is another process restart I just had this morning in addition to the one above.
-
Vodia Support,
I have the Vodia PBX running on AWS t2.mirco (1gb memory) on Ubuntu.
Four to five times a week the AWS instance hits 100% CPU utilization and a console message reports Out of memory;
The OS kills the pbxctrl process and it restarts the process and everything returns to normal after about 15 minutes.
When this occurs, all active calls are killed and all extensions lose registration. Most handsets take up to 1 hour to re-register unless the users restart their IP Phones.
You can see in the above screenshot the memory is full as well. Memory utilization generally is 300 to 340mb.
Software version: 67.0.6 (Debian64)
Build date: Jul 21 2021 18:01:40The PBX has 5 active domains with approx 45 registered extensions.
The PBX has only Vodia PBX installed.
During the day the PBX runs at under 10% CPU utilization as shown below.
The spike you see in the screenshot below is when the CPU utilization hits 100% and the OS kicks in the terminates the Vodia PBX process.
Can you please assist me in solving this problem?
Thank you.
Greg
-
Thank you, doing a Reset within /reg_certificate.htm has resolved the problem, now RPS with Yealink is working.
I appreciate your assistance with this.
Greg
-
For some reason the communication between my Vodia PBX AWS Instance and Yealink is failing and I don't know why.
I have the correct API key and secret in place, and the API path is default "https://api-dm.yealink.com:8443/xmlrpc"
I have also added the public IP of my server to the Allow list in Yealink DM.
But every time the Vodia PBX needs to contact Yealink to update I get failures;
"Problems with adding Yealink server http://xxx.xx.xxxx.com.au/prov/yealink.cfg?rps=1 and name d635e03fd52be8585876
"Add Yealink MAC 805EC0CDD185 to server undefined"
"RPS failed"
It retires 4 times and stops.
I've tried this with new PBX domains and old ones, new MAC addresses and old ones, they all fail now.
This use to work well, but since the upgrade to 67.0.5 its stopped working.
Can you suggest what I might be able to do to troubleshoot this further? -
Thank you, how did you go with this testing?
-
Recently upgraded to 67.0.5.
Communication with Yealink RPS seems to be broken.
Enabled logging 9 and seeing RPS failed messages when the Vodia PBX tries to communicate with Yealink RPS.
" Problems with adding Yealink server http://xxx.xxx/prov/yealink.cfg?rps=1 and name e320536db9415xxxxxx" "Add Yealink MAC 805E0C0Axxxx to server undefined"
"RPS failed"
Tried regenerating the API key and Secret, no change.
Checked my servers IP is in the allowed list on the Yealink RPS.
This was working perfectly before the upgrade.
Is there a know issue?
P.S. SNOM RPS working fine
-
3 hours ago, Vodia PBX said:
In the next version we will use spaces. This is what pretty much the whole world is using today to make phone numbers readable. Except for USA, the area code also seems to be without parenthesis (and actually it often shown even if you are in the area). We'll have this "marinate" in the 67.1 build for some time and then we will eventually make this version 68.
Thank you. Even just an option to specify the delimiter or just leave out the spaces / hyphens would be ideal too.
-
3 hours ago, Vodia PBX said:
You can use CO-lines with the trunk and set them to inbound and outbound only. That will limit the number of calls. That being said we have every intention to get rid of the CO lines because this is concept of the last century. It might make sense to add a setting to the trunk that just lists how many inbound and outbound calls are allowed. On domain level, we already have a limitation on how many calls can be on a trunk, however this now does not differentiate between inbound and outbound.
Thank you, I tried using CO-Lines but wasn't successful, and its good to know you are looking at retiring this option, as I don't want to build a setup around it if its going to disappear in future versions.
The Domain level simultaneous call restriction is helpful when you wish to restrict a domain's total simultaneous calls, but not helpful if you want the Vodia PBX to move to the next option in the dial plan.
It would be great to see an option to specify how many calls a trunk can handle at the trunk level in future releases of the product.
In the meantime, might it be possible to have the Vodia PBX override the early media with ring tone so the caller hears ringtone instead of the carriers "All channels are busy" message? -
6 hours ago, Support said:
Currently, there are no ways of achieving that from under the trunk level itself, because that seems like trunk has higher authority on calling this in.
But aren't there any settings on the trunk / carrier itself that will prevent this from happening? If the trunk / carrier stops playing the early media, will the error code be sent sooner in that case?
Thank you for advising.
Getting a carrier to change their ways is not easy, plus the ability to limit the number of calls in a trunk seems like a function that should be controllable at both the carrier and PBX level. -
To my understanding, on outgoing calls, the Vodia PBX waits for the carrier to either error the outgoing call or timeout before moving to the next dial plan option, if you have set Failover behavior to On all error codes.
Some carriers play early media when call limits are reached on a trunk before sending the trunk an error code, thus the caller hears a message such as "All channels in use" before the PBX moves to the next option in the dial plan. This is confusing for the caller.
It would be nice if we could set the number of concurrent calls that a trunk is allowed and thus if the maximum allowed calls is reached, the PBX should go straight for the next dial plan option and not try to send the call out via that trunk.If this can be achieved in the current version, please advise how. If not, please consider this as a product improvement.
-
You can uncross your fingers Lyndon, I can advise that for me this worked
... its only just a little confusing that this Failover behavior option is located within Routing/Redirection section of the trunk which is predominantly to do with incoming call handling, though this is a routing thing so I guess it makes sense for it top be there
Error codes from the carrier would generally be generated on outgoing calls which is what I wanted it for. i.e. when Vodia attempts to send a call out via a trunk and it cannot.
Setting the parameter to "On all error codes" caused the system to move to the next option in the dial plan, which is exactly what I want it to do.thank you Support!
-
On 4/16/2021 at 8:36 PM, Vodia PBX said:
Thanks for that detailed overview. The reason why the PBX is using hyphens is because spaces are used in many forms in the web front end to separate list entries, including the forms for the DID numbers. In the USA, phone numbers are often written like
(617) 399 8147which is even "worse" than Australia! Other countries like Germany also prefer spaces, and they also include extra characters for the area code, e.g.(030) 55578992or(030) 5557 8992depending who you ask.One way of solving the problem would be a different presentation in the user front end and the administrator web interface. OTOH there are only a few places where there are multiple phone numbers in a form field, and we could as well JavaScript that form element to present and accept the human readable format as well. Then we don't have to do any assumption on what characters may be used and format the number in the best human readable form.
Another problem is that users actually really dial those strings as phone numbers, maybe because of copy and paste or maybe because they like to enter them that way. However we already have a PBX settings that defines what characters are removed from the dialed string. That setting should already be compatible with all human readable formats.
The display of the numbers via the Vodia Web Interface does appear to be a final stage presentation, as even if the number is 0400-999-777 you can still search in the search criteria for 977 as an example and the call / recording will show. This is great and as expected. How Vodia does this presentation appears to be driven by the country code you enter, in my case, 61.
It also may allude to the fact that the storage of the numbers in Vodia's database is without localization, which is also good. Localization is an end step process as expected.
I do like how the Vodia PBX will replace the 61 with a 0 at the beginning of numbers IN and OUT as this is how Australians are use to seeing their numbers.
I just wish there was a way to request the Vodia system to not include the hyphen in the numbers.Granted some people may like this, others may not. To me, having been in the industry for over 20 years, hyphens are not a standard display format in Australia. Spaces are more common, though as you stated could cause problems, so the next option is no spaces. Last option would be hyphenated.
Please accept this as a suggestion, its not a problem, just would be a nicety to have that flexibility in the display of numbers.
Domain calls show on Users login even when feature is disabled in their profile
in Web Interface
Posted
Vodia Support,
Running Version 67.0.6
User portal Version 3.5.3
There is an option under a users permission to "Can see calls of the domain".
However even when this is disabled, the user can still see Calls in the Domain to the lower right of their screen when logged into as a user.
Can you take a look into this for me and advise how I can remove this from a users screen?
What would be preferable is if the system only displayed calls relating to that users Department or Building so as to separate branch offices.
Greg