Vodia PBX

The problem is that the replacement of IP addresses was not envisioned so far... We'll add it to the next 69 build. As a workaround you'll have to "hardcode" the actual WAN address there for now.

Well it is in the 69.0.3 build. However, the Fanvil model list has grown to a whopping number of 90 models. We will need some time to settle the dust for all those models, especially the automatic detection of the model.

Impossible is not a word in our dictionary.

It's really hard to tell if a person is available for a call, e.g. the PBX would wake up the mobile app anyway. An indicator would not have much value. We tried a few years ago when the company was still called pbxnsip to establish a simple standard for setting BLF lights, but it failed (sadly). As of today, when it comes to interoperability the "dialog-state" can set on, off and blinking and it is up to the phone to render it somehow. We try to use "blinking" as the promise that a call can be picked up, and "on" meaning that there is something like a call going on or at least the extension is otherwise busy (DND). For real information, the only way is to use the browser, where anything is possible.

The PBX uses some variables to insert the IP address pre-flight. This is because a SIP packet source address depends on the actual route which takes, so that you can use e.g. private IP addresses, VLAN IP addresses, VPN addresses, public addresses, IPv4 and IPv6 addresses all on the same server (many simple SIP servers don't do that). Anyhow as for the SIP trunk, there are other variables available, but they are not the same. As for trunk headers, the documentation shows what variables are available, but you can also see them listed on TRUNK log level 9 when you try this out.

... on a side note, we have introduced a setting for mobile client codecs in 69, so that a desktop phone can be on G711 and the mobile device on OPUS. Its all optional, but in most cases this makes sense.

We are watching a few 69 systems that are already in production and 69.0.4 should be ready in a matter of days. It would be much easier to do the service flags through the new user front end instead of trying to back-port it to 68.

For VoIP phones being registered should be irrelevant unless there are problems with registration stability. For the user, the question is if a chat message would make it (which is still the exception for most users today sadly), thus the app availability.

Well the whole topic when to terminate the number and not is a messy topic. There is no industry standard about it, and there are pro and cons for it. So far we have stayed with however it is right now and have the user listen to the prompt or just wait—and if nothing happens—try the pound key. Some PBX systems require that the extension number length is always the same, which makes this one easier, but takes out a lot of the flexibility having mixed numbers.

The new version 69 login brings a couple of major features like the ability to use passkeys. That required a redesign of the form, which is causing problems when the welcome.htm was changed in version 68. What we have learned so far: If you have problems logging in to 69, try the rawlogin.htm page which used the good old primitive username and password to log you in. Don't put garbage into the "System management DNS address", version 69 uses it to fend off robots that don't even know the address of the system. Instead either leave it empty or put a DNS address there that resolves to the PBX. Make sure that you don't have customized the welcome.htm, and possibly reset the customization of the page. Consider just changing the welcome.css instead of the welcome.htm. There are beautiful possibilities in CSS if you just want to change the image that you see at the login. If it all fails, don't edit the pbx.xml file. Instead in 69, you can use the --admin-username and --admin-password option for manually starting the PBX (make sure you stop it first). Using HTTPS for any form that requires a password is becoming a requirement in many browsers, consider using a DNS address and use a certificate.

The redirect header is mostly about the {rfc} tag, meaning to follow the RFC. We allowed also other tags from the trunk header section (does not hurt), but usually there should be no need to do anything else than follow the RFC.

We are actually working on HID devices in the front end. Unfortunately there is no such thing as a common standard for different devices. That is why things like PTT on a headset will remain difficult for the foreseeable future. It seems that Bluetooth is going a different direction, especially on Apple devices PTT is defined outside of the apps anyway. Foe Android devices bluetooth is now in the hands of the Google calls library, a step forward compared to before especially compared to the disconnect behavior but still lagging behind with what can be done on HID compatible USB devices. Anyhow, try the latest 69.0.3 if you want to see where we are today.

It might be easier to just wait for the next build where the CSS can easily be changed through the web interface.

Yes there is a jitter buffer. Most of the quality issues are because G711 sounds very bad when there is packet loss. In environments where there is no packet loss, G711 sounds best, simple because transcoding can never make audio sound better (unless there is some AI magic at play). But if there is packet loss, OPUS behaves dramatically better. So in a nutshell, if you have packet loss on the app, set the extension to OPUS.

Entering something there makes only sense for example if the vendor adds more MAC addresses

Well if you previously have changed the setting, the software upgrade will not add the new MAC range. You can just leave that field actually empty (reg_pnp_settings.htm), and then the PBX will use the default MAC addresses for Yealink.

There are several places where the MAC is being used, e.g. for detecting which RPS server to use. Where do you experience the problem?

The front end Javascript code checks the locale of the browser, not the setting on the PBX. So if you are a US user in NSW—you will get US format.

The latest 69.0.3 has it for the browser, Windows and MacOS.

It should be css/reg_recording.css. If that's nor properly linked, you can also change the reg_recording.htm and insert a <style> section there with the CSS.

Hmm this should work. As usual, you should make a backup before such an upgrade so that if it does not work you can easily revert. Anyhow, when you log in please make sure that you are really on HTTPS so that the browser does not interfere with sending the credentials. You could also take a peek at the browser inspector network traffic if anything is being blocked, e.g. by CORS policy. Also another common problem with the login after the 69 upgrade are customized welcome.htm pages which don't work in 69. In that case, you can login through in through the rawlogin and revert the welcome.htm page.

Is this from the app or from the desktop phone? Do you see the DTMF key in the log, so that we don't have a problem on media level?

Ok so in a nutshell the problem is that the redirection number somehow gets to the caller. Would there be any way to see that in the SIP packets between the caller and the PBX? I am puzzled how that number would even transpire...

Okay its an older post, but anyhow... On the desktop phone the easiest is to assign a recording button (works on snom and Yealink at least), otherwise you need to use DTMF codes which are the recording codes. On the app, there should be a recording button when you are in a call.