All Activity

Is V68 still getting updates? V69 just seems to have too many issues and the ext. cost changes will not make it a straight forward upgrade for us.

We will simply add the case that numbers can start with 1 and then the PBX will present it as 130012345. We are currently making 69.2.5.beta builds of you want to try it.

Thats what I thought this setting was meant to be for, the "Don't rewrite" under the Number presentation in dial plan, however it has no effect in stopping it. The doco talks as if this would indicate that it would stop it manipulating it, however it doesn't. "Number presentation in dial plan: This parameter determines how numbers are fed into the dial plan. By default, the system reformats the number that a user has entered into a unique presentation, for example it does not make a different if a user dials 16173998147, 6173998147 or +16173998147. "

I have had a few random ones do this as well, but I can't re-create the issue myself. I did not have access to do diagnostics for them, they ended up using the web browser instead of the app for now.

Bonjour, Sur certains postes Windows, le logiciel Vodia installé depuis le store Microsoft affiche une erreur JavaScript au démarrage (voir pièce jointe). Cela arrive sur 2 postes différents, java a été réinstallé Quelqu'un aurait déjà rencontré ce problème et y a t-il une solution ? Merci d'avance,

is it not possible to just return what the dial plan tells you to return. After all the dial plan is meant to manage number manipulation. If I write a dial plan that converts a users 1300xxxxxx to 611300xxxxxx then that is what you should return This is actually a show-stopper for us because we need to bill call to 1300 numbers and this bug conflicts with issues in the rate table. When adding a prefix in the rate table - it always adds a + so we cant match on 1300, we can only match on +611300 which the pabx will never send.

The issue is still occurring We are on Vodia pbx 69.2.4 Windows app 6.2.1 Once the call is answered somewhere else the App notification should go away (it used to!!)

the replacement side would just be * or leave blank? isn't that what you have set? Or did you mean +234802* ? Are you dialling an international dial code as part of the pattern - try that instead of the +?

It should work, I think you just need either side as below. 1; +234802* | +234802* 2; +234* | +234* 3 +* | +* Are users actually dialling with + but? probably not. So maybe. Assuming your carrier accepts the + 1; 234802* | +234802* 2; 234* | +234* 3 * | +*

Hello, we raised this ticket with the support but no workable solution and I like to throw this open to the community for help. we have 2 different trunks for the same destinations, currently, trunk NGN_Global operator should only route the prefix +234 except calls to +234802* , we like to direct all calls matching +234802* to route to another SIP trunk provider VOIP_trunk as against the primary trunk. But we noticed that calls attempt made to the +234 prefix were still going through the NGN_Global trunks. How do we set the trunk priority with a prefix? Sample Dial Plan see attachment Most switches can A-Z terminations with the Least cost routing (LCR) I am not sure if Vodia supports LCR

So in the email CDR email that is already sent there is not way to add Total number of inbound calls Total number of outbound calls?

Hi Team is it possible to allow entering numbers from active call on keyboard - instead of clicking numbers directly. This is when you get connected to IVR and you need to press one of the options or enter extension number. Currently you need to click the numpad in the app and then click each number with mouse.

On iOS the phone will start ringing as soon as Apple wakes the app up. So as long as the PBX sends the HTTP client request to the push server they should wake up. I would dive into the logs, maybe the users have set work times and then PBX is skipping the mobile apps. The other things that might be a problem is if the apps are still registered through TCP with the PBX but that connection somehow has become invalid, the PBX might want to call the app through websocket and that does not make it.

Well the email sent by the PBX have a narrow focus, essentially what you see in the email is what is available as variable. If you want to expand it, you'll need to look into something external. However take a look at the queue emails which contain a lot more than e.g. the ones for the extension. The whole reporting topic is quite complex.

Thanks, I backup daily and recordings weekly. I also now created an offline backup of the PBX folder to sftp weekly. The individual domains can be handy if I want to move a tenant to another server or restore a tenant for any reason, but agreed not a frequent process. I think I am more in the habit of manually downloading the domains, a select all would be handy but not a game changer ....

Never personally used the Microsoft login option, but if it's a login into the web app, did you make sure that the extension is given the necessary group permissions to login/use the web app?

Can you please open a ticket, so that we can share a screen to find the problem. Thanks.

No luck, it just takes me back to the main login page after I authenticate with Microsoft.

Perhaps it would help to know what kind of device/platform you are using to receive these calls so support would be better equipped to help you. On desk phones these settings work as intended and the information gets masked without any issues. In this case you would simply modify the Ring Group/ Attendant with the necessary From-Header setting and the phones receive the information the PBX is sending them. The only caveat is that the full information is present in the CDR's. But if customer has no access to the phone system then this shouldn't be an issue. On the web app, none of the above happens so the user receives the full list of information every single call. You would either have to ask your inbound provider to overwrite the CID before the call reaches your system or you'd have to severely cut the template to remove elements that display any information related to calls. The latter might be more difficult, perhaps the inbound provider can create a rule/overwrite CID before routing the call to your system. That way you dont' really need to modify the template.

The CDR contains information only about the callers DTMF (outside caller), not from an agent/calee (extension user). Would there be a way to send the DTMF info during the call as opposed to after?

Any setting that I tried shows incoming caller ID. My PBX version even has anonymous as a choice in ring group, but still no cigar. I am wondering if I need to contact our trunk provider for this specific customer. I do not follow the suggestion from the administrator about changing web page template? The requirement is simple, the incoming caller ID should not be displayed or registered due to the privacy issues.

The CDR contains DTMF, e.g. when you use webcdr it will be part of the JSON packet that is sent after call. Maybe just try that and turn on the web client logging to see the content in the log?

Hello, Currently working with a client to see how feasible it would be to create a CMS reporting tool on agent call pickup. I'm not sure how much development you'd need to allocate for this but i will try to detail it out as much as possible. Currently they have a client list and they call into a dedicated agent portal, when an agent picks up a call they dial their agent pin/number in order to verify identity and that the task/call is assigned to them. Client then reviews at the end of the month which agents took which logged calls. Where does Vodia come in? Currently i've been trying to capture the Calee's DTMF from the PBX and i've not been able to find any level of logs or API that does perform this function, right now the only work around is to use a local Syslog to try and capture the DTMF traffic from the Calee. Based on viewing the logs it's apparent that Vodia does capture the DTMF from both Caller AND Calee, but does not display the Calee DTMF inputs. If we review the features from the extension Redirection page we know the PBX is capable of understanding and receiving Calee DTMF inputs, specifically the setting for "Offer special menu when call is answered on cell phone" which requires the Calee to press 1 to connect the call. The PBX however does not disclose or write this information into any of it's logs or API's even when filtering for lowest level. Basically the feature request is for the PBX to provide information about the Calee DTMF inputs and not just Caller DTMF inputs.

So there is not a list of {ssi variable total_calls} {ssi variable total_duration} {ssi start inline true} variables/commands anywhere?

Maybe you need to use the device.set="1" in the "Polycom General" parameter (see Poly Documentation).