Vodia PBX

Ooops try this !(AMERICAN|NEW)!211!nf !([0-9]{10})$!\1!t!3000 The 2nd pattern will look at the to header instead of the from header. All powerful stuff is cryptic.

Ein SIP-Trace mit der entsprechenden INFO Nachricht (einfach Telefonnummer ändern) würde hier erst mal reichen um zu sehen ob wir über das gleiche reden. Es wäre natürlich absolut super wenn wir das auch mal "live" testen können, ja dafür bräuchten wir dann ein Konto bei diesem Betreiber.

If there is a default destination, the PBX will send the call there and not continue processing. So take the first 3000 out, then the system will consider the NEW pattern if there was no match on the AMERICAN. Also if you want to try if the caller ID matches one of your DID, you can do that as well with another pattern. For example !AMERICAN!211!nf !NEW!211!nf !([0-9]{10})$!\1!f!3000 could be worth a try. Which would be equivalent to !(AMERICAN|NEW)!211!nf !([0-9]{10})$!\1!f!3000

Ja, theoretisch wird das unterstützt -- allerdings haben wir noch keinen Trunk gesehen der das unterstützt. Die PBX kann die Daten aber intern generieren, die werden dann auf dem Telefon-Display dargestellt.

Without the space, it will also work in much older versions. You can add multiple expressions by listing them, separated by a space character. That is the reason why it was a problem to have a space in the pattern itself! Not sure what you mean with the last post; but if you want to make more than one rule that is absolutely possible. Just use spaces to separate them. The computer is going from rule to rule and evaluates them. But in that case you should not include the default destination; that will stop the processing.

Ja das kann man derzeit nur auf Domänen-Ebene kontrollieren. Wir haben manche Einstellungen auch auf der Nebenstelle verfügbar gemacht; bei dieser Einstellung könnte es aber nicht ganz klar sein ob die Einstellung vom Anrufer oder vom Angerufenen gelten soll.

Hmm not sure how this exactly works in Windows, maybe you have to click on "Advanced" but there must be a way to lock the directory down also in Windows.

Just change the directory extlog to read-only.

There are actually many XML files in the working directory of the PBX. This is how the PBX stores most of its configuration data and system logging. When someone changes a parameter in the extension, the PBX keeps track of it. This is because many support tickets from users can be resolved quickly looking at what they have change.

It does not matter. The scheme is the text before the colon, and the content is what is behind it; however the system strips leading slashes.

There is a global setting for that, the default is one hour. When you use the key, the session timeout gets reset, just like it happens in the web interface.

This was a fallout from the changes around the check-sync logic, we have already rolled that back for the next version.

We were sending an event check-sync;reboot=true which was kind of working fine everywhere, until we were urged to take the reboot=true out for a customer. Seems that was a bad idea; we have already rolled it back; the next builds will use the good old style to do this.

Oops, looks like this is a standard object and not an array. Next version will have this as array.

We will roll back that unfortunate change. IMHO users that use that firmware version from Polycom should just upgrade their phones.

This is because one of our customers demanded that we must not include the reboot=true flag because that does not work with certain Polycom phones firmware.

We did not remove the API; however for new designs we recommend to go for the JSON-based REST API. We are working on a API web page where all the available calls are available. In the meantime, you can use your browser in "inspect" mode to see what is going back and forth between the browser and the PBX, and that will be the same with you application then.

For that one I would choose a PC server with a good dual core CPU, 8 GB RAM and SSD.

Oh ok I think that makes is clear. Actually, it should be possible. In the trunk (see https://vodia.com/doc/trunk_inbound_routing in the ERE section) you can specify where the PBX should look at, in this case it would be the from header (flag f) and you want to look at the CNAM (flag n). There is one complication here, the name contains a space. As for now the workaround would be to use only a part of the CNAM, e.g. "AMERICAN": !AMERICAN!200!nf!300 That would send calls that contain the string "AMERICAN" in the CNAM (upper case) to 200, and if there is no match it would send everything else to 300. The space in "THE AMERICAN" can currently not be expressed. Next version (57.3) will URL-decode the pattern, so if you use "THE+AMERICAN" then you can do an exact match: !THE+AMERICAN!200!nf!300

That would be no problem for the PBX because the cell phone numbers end up in a table that is index and efficient. But maybe you can elaborate a little bit more what the stores should hear when they call into the number. Is the private virtual assistant appropriate? Or do you just want to send the call to another auto attendant? We currently have a flag that (binary) controls if the PVA should be offered or not; we could extend that logic to send the call to a predefined destination.

MAX_INT (2147483647), though you would have to press a lot of buttons to get there

Well you can do it in the trunk routing part, though 500 entries will be pretty long and the PBX will spend some time to go through the list (see https://vodia.com/doc/trunk_inbound_routing). The question is if you can leverage the cell phone logic. When the PBX receives a call from a number that was listed as cell phone, it considers that this call comes from one of her users. What exactly should happen when the PBX detects that the call came from an office?

So you mean the caller-ID has a "Display" part where you put the name (e.g. "XYZ") and a part with the "Number", e.g. +12121234567? Then routing can be done easily based on the "Number" part, even though the VoIP phone might not show it (e.g. because it has a small display). If you call from a cell phone that is listed as an extension cell phone, the PBX will detect that and route the call differently anyway.

We are already working on the next version...

That is already in the latest & greatest.