Vodia PBX

The transfer heavily depends on the phone that you use. At the end of the day, from the PBX perspective, the phone sends a REFER with or without a replacement info which is needed for the attended transfer. We were looking for a "prefix" button for a long time, so that pushing a button changes the "dial" function into a "transfer" function, but we are not aware about firmware changes that allow that yet.

You need to keep in mind that in contrast to a web server, the PBX needs to calculate what IP address it needs to advertise to the outside world. There is an article about this at https://vodia.com/doc/server_behind_nat that may serve as a starting point for solving your problem. In a nutshell, you need to tell the PBX what IP address it will present to the phone when going back through the firewall.

I would try to change the setup, for example try to run this from the home network instead of the office network. There are a lot of different router models out there, and lots of them are making trouble with SIP. For example, the FiOS router for Verizon has a "application layer gateway" built in that cannot be turned off and creates a lot of trouble. There is a good chance that you have a similar problem; the easiest way to find out is to change the setup and see where it makes a difference.

You can install them through the software update feature, see https://vodia.com/doc/lang_installation you probably need the "Music and Tones".

Well the INVITE from OHV gets cancelled (BYE) after 478 ms. That does not leave much time for the PBX to answer. There is a Q.850 reason, something from the PSTN network. What you can try to do is to back up the working directory of the PBX, upgrade to 5.5.0 demo license and see if the problem disappears.

This is a general problem of the SIP protocol. With the snoms we were using a "hack" that is not using any RFC. What you could do is monitor how stable the registration is, e.g. send an email out every time the registration changes with the phone. There is a setting for that in the extension registration tab. You can also see in the domain how long the phones are registered; those registrations should in theory be the uptime of the PBX or the time since the phone booted last time. If they are shorter, there is a problem. You can compare the times of the Grandstream phones with the snom phones or other phones. For example, we were not able to keep a Yealink phone registered on TCP for more than 24 hours even in the LAN, until they fixed something in their firmware and now it seems to be rock solid.

The overall problem with the buttons is that it (today) is based on "dialog state", a RFC that originally designed for SIP proxy activity detection. It is subscription-based, and if that subscription gets shaky for example because of registration instability, so does the LED. There have been numerous RFC being written over the past ten years for all sorts of existing and non-existing problems. Maybe we have overlooked the RFC that addresses the simple problem of turning a LED on or off, but just can't find it.

32 seconds sounds a lot like a problem with the SIP routing, the ACK does not seem to make it. I would also think that it is a problem with the SIP router and/or firewall; maybe just a simple NAT problem: If a HTTP server works, it does not mean that the SIP server works as well... I would make a PCAP trace for the call and take a look at it.

The question is if you want to automatically provision the phone or manually configure it. What the PBX automatically provisions for the phone does not go that far; however if you can manually configure the phone you might be able to get those things done. If you get it done, we could take a look what we can include in the standard provisioning file.

well you are using the snom ONE which had the goal to sell more snom phones (not Yealink phones). Full Yealink support was not a top priority at that time! You should upgrade your system to Vodia PBX 5.5.0, which has now a great Yealink support.

Well, I believe you. We just need to power our Mac on and take a look. Or is Safari also available on other OS?! Seems like the Windows version has been discontinued: http://apple.stackexchange.com/questions/68836/where-can-i-download-safari-for-windows

We had that button for the snom phones back when we did not care about RFCs and just did a "hack" to get this working. However, it was causing some confusion when the button was turned off before the office hours were over; the main problem remained how to handle staying longer. People forgot to turn the extended hours off when rushing out of the office. The conclusion was to handle only the state transition, e.g. from on to off: If it is already off then don't change it. Now we are just hijacking the dialog state which shows when calls are on and off. It is difficult terrain, e.g. some phones believe that no call can last longer than two hours! I would recommend users to call into the new feature and use the IVR to program changes to the opening hours.

Well the dial plan presentation is a very old piece of the PBX. The PBX actually produces hard coded HTML to the web interface... Today we would probably use the table using JavaScript. What you can do is to work on the CSS and vary the size of the input elements (maybe this is what actually happened). The overall problem is that the dial plan entries have so much information that it barely fits into one line anyway.

For upgrading versions, I would just install a 2nd system and copy all files over. Doing this domain by domain can be indeed tedious. And those things that have a scope beyond the domain are indeed a problem. The trunks are usually stored by their numbers. This is necessary to make it possible to rename trunks (we don't do that everywhere like in the hunt groups, but in principle it is a good thing to keep ID instead of names). In the text view, that is different where the trunk name is stored. Therefore, the text view is a good workaround when using global trunks. When you hit the save button, it will attempt to find the trunk and in you case that seems to work fine. When you move the domain to another system where the global trunk has a different ID and even a different name, that will obviously not work. The text mode for the dial plans make a lot of sense when you want to bulk transport then. See the input element-based dial plan only as a pretty way to enter the lines if you are not familiar with the editor. At first glance I don't see why the dial plan text import would not work. What you could do is to compare the text view during import and after import. In theory they should be the same. If there is a difference, well then that is something that should be checked.

We are really trying to make the turn for 5.6.0 (we might just call it 56, it sounds more fancy). We want to make this really, really stable and still finding small things here and there. 5.5.5 is IMHO pretty good already, we are running it in several places so far with no problems.

Ok we have just made a 5.5.5 for Debian64, please try again.

I think that one was already found. If possible, move straight to 5.5.5.

We have revisited the snom DECT solution, the M300 should also be available in the next version with a revised provisioning method.

Thanks, will be fixed in the next version (problem in the HTML).

We have made some changes in the service flag area so that the user can call and reschedule the service flag for that day using IVR. Did you see/try that already? For that, we also have new US-English prompts.

Please try the 5.5.5 version where we have made a few changes for ActiveSync.

There was a bug in the web interface, please use 5.5.5 for this (available for CentOS64 and snom ONE mini at this point): http://vodia.com/downloads/pbx/version-5.5.5.xml

This is for generating Freshbooks invoices. If you are not generating invoices there you can safely ignoring this.

There is a setting in the domain for that, did you try to flip the switch yet? Regarding the SIP headers, there are a lot of variables at https://vodia.com/doc/trunk_custom_headers that you can use to present what you need to present to your provider. You can use the if tags with disa, so to make conditional content in the headers. It might be a little bit of tinkering, but you should be able to get that working properly.

I remember from the old days that there could be a problem with a race condition internally when notifying that the file is there (but the thread which is writing it did not do it yet). You might hit that problem. I would says if you cannot move to version 5 your best shot is to back up and try upgrade to 4.5.1.