Vodia PBX

Looks like something was screwed up with the way the service flag was stored. Will be fixed in the next build.

Ok looks like the EXP43 Module is for T43U, T46U and T48U. We'll add it to the next build.

The emails directory stores the emails that are supposed to go out ASAP. Because its multi tenant, each domain can have their own email server, thus the list of servers in the web interface. Its a primitive way to look at the internal structures for the email client objects. If you want to troubleshoot email issues, you can also turn the log level for email to 9 (and the others to 0). If there are problems with TLS, you can also turn on the log level for TLS. Certificates are the main problem with emails and TLS. You can turn the validation off, which is at least a good first step to see if that is the problem. If there are problems with certificates, you might have to take a look at the list of Root CA on the system, and potentially (for older installations) reset the CA list. The next version will actually come with a refreshed Root CA list.

... and that is just the beginning. Vodia is working on a even better way to control this. This will be available in a few weeks.

The LAN provisioning set up a temporary registration to make the phone believe that it is provisioned. When the admin assigns the MAC to an extension, the PBX sends a sync request to the phone which will start the provisioning process again from the start with the real config information. If nothing unforeseen happens, this saves a lot of time for doing the manual steps. If the registration gets lost for whatever reason, that sync request will obviously fail and the phone will just sit there. All in all, the LAN provisioning is more like a time saver, but whoever is installing the phone should still be able to log into the phone web interface and manually set the provisioning URL if anything goes wrong.

Auf FB-Sicht ist die PBX ein VoIP-Telefon. Aus PBX-Sicht ist die FB ein SIP-Trunk Anbieter. Das ist ganz normal und funktioniert sehr gut. Die FB kümmert sich selbst darum wie die Verbindung mit dem Festnetz aussieht. Grundsätzlich könnte das nicht nur über SIP, sondern auch über ISDN oder sonst was laufen. Daher ist der Transport nicht wichtig. Da die meisten VoIP-Telefone immer nicht UDP verwenden ist das die einfachste Lösung.

Well we could do something Yealink specific and post-process the file. We could remove all extra lines except certain lines that are supposed to occur multiple times. It would clearly be a hack, but it would for sure solve the problem.

I would point the NTP server to an IP address where you can run Wireshark. Then you'll see if and what NTP packet arrives there. A failing PSU is a sign that this device might be seeing its last day soon... Vodia IOP is a worthy successor. If you can backup the configuration, you should be able to import it to the new system.

(07*) means in ERE "0" and then 0, 1, 2 or more "7" characters. I guess you wanted to use ^(07[0-9]*) instead? You should actually use the ^ at the beginning to require that the string starts with 07 and not just random match somewhere in the middle (It becomes clear why we need the simple patterns). The simple match magic is that is just tries to make sense of the pattern as a simple pattern, and if that fails it uses the ERE logic. IMHO this should be a simple case where all you need to do is use the simple 07* and then on the trunk make sure you present the number as "rest of world".

Die Ports auf der PBX in dem Screenshot beziehen sich nicht nur auf den SIP Trunk, sondern die gesamte Telefonanlage—also alle SIP Trunks, VoIP-Telefone und was da sonst noch so registriert wird. Daran würde ich nichts ändern. Die FritzBox kommt mit dem UDP Port 5060 gut klar. Auch sollte UDP in LAN kein Problem sein, da dort keine Pakete verloren gehen. Wenn der Trunk "200 Ok" anzeigt ist das eigentlich ein gutes Zeichen. Was ist denn mit dem neuen Setup das Problem? Dass die Registrierung nur 24 Stunden hält?

Thats a common problem with many providers, I would not consider this to be specific to the easybell trunk. Because most providers charge CLIP no screening for extra $$$ or €€€ its off by default. There is no need to change the trunk headers. I would not change the header, instead the "Regular ANI rule". By default it is "acd-ani ext-ani trunk-prefix dom-ani trunk-ani from". If you change it to "trunk:from acd-ani ext-ani trunk-prefix dom-ani trunk-ani from" it should take the caller-ID from the inbound call if the call came in from a trunk.

Generally, the idea is that when you put a ACD on the BLF, it is for picking up the next call in line. A blinking BLF light is a promise that the user can pick up a call. That being said that promise is sometimes hard to keep with the various understanding of BLF and the dialog state behind it (it was not designed for this by the RFC authors). The "Enable call pickup from extension BLF" means that you can pick up a call from the BLF for that extension. After the motto, I can hear the phone ringing, why does the PBX not start blinking for that extensions BLF? By default it is off, because when you pick it up, usually you would expect someone to call the extension and not a group. Picking up a group call instead might be confusing for the one who picks up the call ("who did you call, who do you want to talk to").

The "adding themselves" works only for the primary agents. Instead of adding themselves, the admin should add them and then they control if they want to be logged in or not. Then it does not matter where in the ACD they have been added.

Hmm Yealink used to take the first occurrence for a parameter, I hope that has not changed. Actually most vendors take the last occurrence. Of course editing the template will work, however that should be one the last resort to avoid problems with updates of the template from Vodia.

Yes that is fine. When there is no match the system indeed goes back to the system management address as a "last resort" to find a name.

Well it should tag it as T43U. If not, you can manually change it in the domain/VoIP phones section. What kind of extension board are you using with the T43U?

If you are using a valid certificate as the default certificate well then IMHO the Yealink should take it. But I am not very sure. It seems LDAPS is not a mainstream feature with Yealink. On a side note, this is why the PBX generates a separate password for LDAP, so that when an insecure protocol is used and someone gets it, the damage is limited to the address book.

Well the dial plan is a very old feature and that is where the extended regular expressions are from. They are powerful, but at times hard to understand. The "simplified" rules used to be sugar coating for the ERE until we gave up on that and made the simplified rules a separate feature in the dial plan. So much about the history. For debugging dial lans the best is to turn on logging for trunks on level 9 and just try. Then you can see how the system runs the rules. Another thing to keep in mind is what the PBX feeds into the dial plan rules. By default it is using the domains country code representation, but you can also choose different presentations now. This is to abstract from what the user has entered, so that there is no need for separate rules for +12121234567, 12121234567 or 2121234567 or even 1234567 if the area code is 212.

The problem is that the LDAP client does not use the SNI extension for TLS. We have raised the issue with Yealink and they have added a setting for SIP, but not for LDAP. Wondering if anybody is using TLS with SIP?! Anyway until that flag is also available for LDAP, there is no reliable way to have LDAPS in a multi tenant environment.

We will soon release a way to send FAX from the PBX, though not through email but through the user front end.

Looking at https://www.vtiger.com/docs/phone-calls-api-usage it seems they have a call interface that seems pretty straightforward. Is there a test system somewhere internet that we can use for integrating this?

The PBX considers this a user (or admin) phone number input field and applies the reformatting magic to it. This means that 617-399-8147 becomes (if the country code is 1) +16173998147. For alphanumeric input, the PBX does process it like a email/SIP user name, which is case insensitive and because of that gets transformed into the canonical lower-case format. I believe that generally makes sense because SMS sender addresses are phone numbers. Does the receiver of the SMS even see the number anywhere? If not and this is just for accounting purposes, a pragmatic approach could be just to keep it lowercase or even give it virtual phone numbers.

SIP/2.0/udp ist wirklich sehr seltsam. Das wäre tatsächlich ein nahezu unglaublicher Bug, vielleicht war es aber auch einfach nur ein Copy & Paste Problem. Aber die FW der FB war wirklich schon etwas älter. Gerade bei IPv6 und SIP hat sich eine Menge getan und AVM hat eine sehr schön Weboberfläche wo ein SW-Update eine wahre Freude ist!

Hmm I guess this is because it all comes from email addresses, which is what SIP addresses practically are, which the PBX uses for phone numbers as well. Are you able to control what Twilio assigns as numbers? Then the answer would be to use only lower case for now.

Interessant... Grundsätzlich ist es der PBX egal ob IPv4 oder IPv6 verwendet wird. Es ist z.B. auch möglich die Signalisieren über IPv4 zu machen und dann das RTP über IPv6 zu schicken. Praktisch ist das Problem natürlich dass die Unterstützung von IPv6 bei den SIP Trunk Providern eher gemischt ist. Ich würde zur FritzBox aber kein IPv6 verwenden. Da ist es vollkommen okay IPv4 zu verwenden. Ich denke die FritzBox kann dann ggf. auch von IPv4 auf IPv6 umsetzen. Im Trace sehe ich ein paar Schwächen, z.B. wird da "SIP/2.0/udp" angegeben was nicht RFC3261-konform ist?! Die FritzBox scheint eine Version von Aug 1 2019 zu haben, die würde ich auf jeden Fall mal auf den neuesten Stand bringen. Und auch bei der PBX haben wir neuere Versionen, ich würde hier die 66.0.7 nehmen.