Vodia PBX

Generally the PBX tries to avoid transcoding. It's mostly for non-G711 codecs that can stress the CPU significantly. A workaround is to force one codec. This is typically useful on the SIP trunk (which you could try), but you can also force a codec on the APP by setting the extension codec preference to that one specific codec. We had many cases where the trunk would negotiate asymmetric codecs but would not be able to actually handle it. The iOS app 1.17 should be able to handle it tough.

Clicking on the call forward button: It then opens the dialog for "Call Forwarding" where I can enter a number and save it. The same number is then in the tenant mode extension tab.

Well, there are several ways to report the CDR. The "simple" CDR might not be sufficient for your needs any more. If you are just interested in some calls for investigation purposes, you can just in the tenant CDR click on the CDR record where you can see more details about the call. If you want to collect the duration of each call leg, I would suggest that you take a look at the JSON-based call records which report each call leg with a lot more detail. That would require some external scripting, though.

Hmm so you are looking for the duration of the current state? Looks like that one must have dropped off the table in the versions between 57 and 68?

You can see and set those values in IP Access Control (/reg_access.htm).

In such cases I would first all all try to isolate problems. This can be done simply by calling into a mailbox from the app. In most cases the fact that you can hear voice (outbound RTP from PBX) and navigate with DTMF (inbound RTP) means that the app is probably okay. If you want you can record something then listen to it from the app (e.g. record own name or leave message in another mailbox then listen to it). If you have another extension, e.g. a VoIP phone that you know works fine, you can also call that one and see if you have two way audio. If yes, it is typically a trunk problem. If the app is the problem, I would turn PCAP recording on and look at it. The IP addresses in the SDP of the app are irrelevant (the PBX assumes that the phone is behind some kind of NAT anyway), but the addresses in the SDP coming from the PBX must be reachable from the app. If the address is not okay, e.g. because the PBX is on a private IP address, you can try to put public into the IP routing list (/reg_sipsettings.htm) to make the PBX present its public IP address. If you have the PBX in the LAN and the app also in the LAN things might get tricky because of the HTTPS requirement for the app. Of course if there is a firewall in the path it needs to be set up properly. For example, if your RTP port range on the PBX is not the same like on your firewall, that can lead to very frustrating random problems, depending on which RTP ports were chosen. IMHO it's important to understand what went wrong, and obviously to fix it, so that all calls work properly.

There are essentially three ways to do this. You can set up the trunk in the tenant and have the tenant see it and possibly also change it. It is simple, however has the risk that the tenant screws things up by pushing the wrong button. You can set up the trunk in the tenant but block the tenant from seeing and modifying it. This has the advantage that the tenant admin cannot access the trunk and damage anything but in some cases, tenants feel locked out and would prefer to have full control. You can set up "global" trunks in a separate tenant specifically for hosting all global trunks. Those trunks can be accessible in the tenant domain. If you have only only trunk for all tenants, then it would be okay if the tenant admin would see that trunk (give it a name like "SIP Trunk" or so). The PBX will rout inbound calls from that trunk automatically to the right tenant based on the DID number of the call. Some providers use only the IP address of the subscriber to identify the trunk. In that case, you would have to use the global trunk method to keep tenants separate. But trunk providers that support registration would automatically send the call to the right tenant.

I would do a PCAP trace and check what is in the RTP. If you can hear both sides, it must be something else like problems with the trunk or the PBX firewall.

So we did spend some time here testing this in the latest version. A pattern like 5/9/22;2P (US locale) does work like expected (holiday starting at 2:00 PM and ending on the same day). It takes the schedule from the holiday hours field, which is usually empty. What is important that this field is read like the other day fields, meaning that if you invert the flag, that means the flag is active during that time.

Hmm for those days it would make sense to use the holiday schedule. Workaround is to manually turn the service flag off for the day until the post-67 version is running.

I just tried that on 68.0.14... Clicked on the "redirect" button and got to the "Call Forwarding" screen. It did save my number... I tried with country code, without, both worked. Is this a problem for specific numbers? Or just any number? Does it matter which settings you are trying to save? Is this a limited extension type (e.g. hotel room)?

If you need time-based redirection, you should use a service flag. For example, you could put it on a BLF for simple control or make it time-based. The redirection in the trunk would not be able to do that, the call has to hit an account first. Queues, ring groups and also extensions are able to redirect calls based on service flags, so that should get you close to where you want to be.

This used to be a problem on older app versions, but this should be solved in the newer ones (at least three months ago). Transcoding between PCMU and PCMA is not a big deal, it is lossless and it does not take much CPU.

The main problem was that in the UK, dates are DD/MM while in the US it is MM/DD. That is why we had to redesign it, and the only way is to use the browser locale, which is consistent with the experience of the user in other pages. In most of the cases there is no need to specify the time, and the holiday hours are the right solution. There are only very few cases where a holiday starts in the middle of the day, I am not aware about holidays in the UK that would fall into that category?

There is always the expert mode for routing calls, based on a list of extended regular expressions. Set the "Destination for incoming calls" in the trunk to something like !6171234567!100!f 200 which would mean if the caller-ID (f flag to the rescue) matches 6171234567, route the call to 100, otherwise send everything to 200. Instead of routing based on the From-header you can also route based on the Request-URI (which is actually the default) or the To-header. This way you could break out special numbers. However you could as well just assign DID numbers to the accounts without the need to use extended regular expressions. Some devices, including Grandstream, intercept the star codes and to their own stuff with it. That might happen with the *71.

Well 67.0.5 is the last version where the frontend did not use the locale of the browser to present dates in the local format. We have updated the documentation link with more up-to-date information.

68.0.14 is ready — maybe you want to take a look. The link for the upgrade is http://portal.vodia.com/downloads/pbx/version-68.0.14.xml.

Maybe this has just been renamed to "IVR time"?

Can you check if the barge in works if the call is in a queue? Apart from that you can always just use the star code like you would do from the desktop phone.

Generally I would in such cases do a PCAP trace to make sure there is no problem with firewalls. Also double check if the IP address for that user might have been blacklisted. We are working on a new Android version that will solve the problems with the audio device and this should be available in the next few days.

It does not depend so much on the 3.5.5 version, it is more about the PBX version. What you can also check if the extension actually has the rights for the action, and possibly add the rights to a group where the extension is a member.

There were no groups in 67, and the PBX automatically generates groups during the upgrade. Maybe an automatically group has caused the snafu.

Did you assign "Don't show calls to other users" (privacy) in a group to the extensions that you cannot see?

I would turn on the logging for the web client to 9 and see if e.g. the content-type header contains what you would see in curl. Maybe there is no content type or the wrong content type and that is why the server is rejecting it.

There is a problem with Android 12, we have opened a ticket with Google but so far there is no solution.