Vodia PBX

The provisioning is based on the MAC address, and that works well for VoIP phones. For DECT, there is another identifier (the IMEI if I am correct) which is 12-digit hex code. Because we still need the MAC for the base station provisioning, the DECT handset ID was placed into the general purpose parameter, that is a "hack" — although just a small one.

When you click on the call log (at least in the tenant view), you can see more details of the call. It includes also information about the codecs, and you can play the recordings from right there.

Well most of the users get their FAX through email, so the new status is not that important for them... That would explain why the pressure was bearable on this so far. Plus there is no way to know if they have received and opened their email, so the "new" status is kind of useless. But it looks like we need to mark the message as read when someone downloads it from the front end.

The frontend would look at your browser setting and then automatically use MM/DD/YYYY (US) DD/MM/YYYY (UK) or DD.MM.YYYY (ROW) format. Internally it should be converted into YYYYMMDD format, and this should end up on the file system that way.

Well in the later versions you can always use service flags inverted or not inverted. This is because the original idea was to define something like "office hours" and redirect when a call was out of the office hours. However there are other occasions when you e.g. want to call a cell phone during office hours, thus the need to invert. As for the queues, because it is a digital system, ultimately there is no such thing as erratic behavior, though it might be hard to understand for the humans. What is currently a thing that makes it harder to understand how the PBX includes agents is because the system does that in steps, which are done every so-and-so seconds (there is a setting for that). If a Tim was specified that falls between those times, then there is no action until the next step is happening. That can be very confusing, especially if you lets say schedule each stage for example every 60 seconds. We do have the plan to rewrite that, but as of now, that's not done yet. Until then our recommendation is to keep the stage duration reasonable short and turn logging up for better understanding why decisions are made in the queue.

One of the "hacks" is that you can put the IMEI (the ID for the DECT handsets) into parameter 1 for the extension. Then the handset should be automatically be assigned to the base. Not sure if the firmware update is supposed to happen automatically... Did you try to trigger the update from the handset?

Well you have to make sure that the authentication is okay, either through a session or through Basic authentication (which must be enabled in the later versions). However if authentication is the problem you would see a 403 response. You can use curl -vvv to see more details on what went wrong on HTTP level.

If there are multiple trunks, then the idea to use the TCP connection itself as trunk identifier does not work (that was expected). Also the identification by IP address does not work because they are all the same. The only way the trunk identification can work is by using the line parameter which is set to a random value during the registration. Can you see if this parameter is set when the trunk provider calls the PBX? Maybe just attach the INVITE here?

If you are talking about the API documentation, the site is incomplete. The easiest way to get things done it to look into the inspector and see what the browser sends to the PBX, and in most cases it is obvious what API requests are being used.

Well there are many ways to deal with this. One idea would be to first send the call to an auto attendant where you can play an announcement and then after a timeout redirect into the queue. In the queue, you can add agents in stages, probably just random, until eventually someone picks up. If the caller knows he extension number, she can enter it in the auto attendant without having to wait for the queue. The other idea would be send the call straight to the queue and use the prompt 0 (which is always played). You could also use a IVR node before the queue, but you probably don't need that complexity.

The PBX should tag the TCP connection with a trunk name, if there is one. I assume it is the same TCP connection like the registration? And the PBX is the TCP client? Then this should work like a charm without the need to guess what trunk this is. This is used for Teams where this seems to work fine. Are you using more than one SIP trunk for the same TCP address? Then it will indeed get tricky to figure out which trunk it is, though even that should be working if the trunk provider passed the line parameter along that was used for the registration.

There was a glitch with the LDAP configuration. The message is a little misleading, because it actually does work. Anyhow the 68.0.23.beta has it already fixed.

Here we go with 68.0.22. We found a place that can consume a lot of memory over time, and also added something to delay updates for BLF when there are too many messages going out. There are a few other updates, as usual see the release notes at https://doc.vodia.com/docs/en/releasenotes680. If you decide to update, take the opportunity to make a backup or automate backups. It is always good to have it and disk space is so cheap these days.

Yes Vodia PBX is clearly not a FAX server . We'll have to look into ECM though.

We'll update the release notes, as usual.

Totally agree. We want managers do that job without giving them tenant admin permissions. The "manage queue" permission does that — all we need now is to put that into the front end. A new version is in the making we somehow need to put that on the do-to-list.

IMHO SIP should have never used UDP, and providers should stay away from it like the plaque. Microsoft actually did that and they are not unsuccessful with it.

68.0.22 will fix something in that area anyway — the PBX would not forget the addresses unless there is actually something blocked. Plus there was an issue with net masks that could also have played a role there.

FAX-wise there was only the change with the paper format which is not related to transmission. IMHO that would not explain any difference. We had looked into ECM, however as far as I remember it had to be manually enabled on our test FAX machine and we believed that it would be one of those lesser used (million) FAX features that has no practical relevance.

In that trace the PBX is not involved in the actually FAX decoding, it just shuffles the FAX packets back and forth. My guess is that something on the provider side must have changed (the ATA has probably still the same software). At first glance the trace looks fine. We are now around 68.0.20 and soon 68.0.22, it might be an opportunity to make a backup and upgrade to a newer version.

Yes it is a reality that in the world of perfect PDF and encrypted email we still have lots of FAX messages, usually not encrypted and low resolution. And unreliable transmission... V.34 is a great thing, however today the FAX speed is not so much the point any more like it used to be. As long as it eventually arrives everybody is happy. Pushing it to 33600 baud is making things difficult, considering that G711 has just 64 kBit for encoding everything. If T.38 is used, the transmission should be able to deal with small packet losses. Would it be an option to switch to T.38? That would dramatically increase the probability of getting the page across. The alternative would be to look into why packet loss is happening, and as a side effect the overall voice quality could actually be better which would not hurt either.

That is already a reality. However it depends on what SMS provider (or better, what MMS provider) you are using.

It usually means that the PBX is not able to come up with a https URL. Instead of frustrating the user the PBX prefers to frustrate the admin...

Good old FAX... If you can get a PCAP (which should work beautifully in 68.0.20) and attach it to a ticket, maybe we are able to see why they are grey.

The problem is that some devices will try immediately to reconnect when the TCP connection gets closed, which results in an own-device-DoS. That is why the PBX must wait for some time before closing the connection. Because of the way TCP/IP works the PBX needs to accept the connection before it can get the remote address. That does take some CPU. Firewall manufacturers will not go out of business anytime soon. Why we have two records remains a little mystery though.