Vodia PBX

No it does not depend on the type. We have another case for the diversion header that we are looking at, who knows maybe the next SW update will have some improvements in that area.

There is a setting for the diversion header in the trunk, did you try that yet?

There is no specific SOAP request for this. You can mimic this by using DBSet requests on the tables. You can see how it works by looking at the changes in the file system when you perform the action from the web interface.

When the PBX invites participants into the conference room, it does not look at the redirection settings. This is similar to hunt groups and ACD calling extensions up; the redirection settings apply only if you call the extension explicitly. The reason for this is generally that redirection settings in group calls are confusing and may easily lead to loops, especially in large groups that are hard to figure out and frustrating. What you can do to achieve the same effect is to include the cell phone of the extension. There is a setting "Include cell phone for web callback" if you turn that on, the conference room will also include the (first) cell phone.

I searched the Internet a little, but could not find a "transfer tone". Looks like this would have to be done with a prompt. Also we would need a setting, so that people who don't like it can turn it off.

Hmm you mean for the attended transfer there should be another announcement tone? Has this been done before? I don't think there is much the handset can do; the PBX just sends a Re-INVITE with the changed Caller-ID (and the possibility to re-negotiate the coded), but the media stream just cuts over from one packet to another. The purpose of the consultation call is to make sure that C knows who he will talk to. We could say a "putting you through" before the media from A gets connected to C, but our impression so far was that B would say that anyway.

There is some chatter that Apple is going to adapt WebRTC - after Microsoft Edge, Mozilla and Chrome. Then the Apple iPad will also (using Safari) naively support that. So far you would have to install another browser. But apart from that detail we indeed bought a tablet and used it for a few weeks, just to see how practical it is. I mean everybody is talking about it, and we want to see if that is really practical. The answer is yes, but. The main problem is that this works only with Wifi which is a major stability problem still, at least in the environment that we had. We had to take a separate Wifi router in the 5 GHz band to give it better stability. And we needed a permanent power supply, and a good headset. Actually the headset turned out to be one of the biggest problems, as it just does sound different than an IP phone. But you can take the tablet (disconnect it from the USB power supply) and then really start walking around. Especially such things like transfer become a lot easier with all the real estate of a tablet screen, and the "BLF" also becomes a lot easier. For an attendant, it is becoming a real option. You don't have to be a visionary any more to see more of those devices deployed in 2017. Not sure what you mean with pick your device. The PBX will ring all of them, and you can pick up your call where you like.

That is not in our hands as far as I can tell... At least it seems to use some code point! where you can get a preview what we are going to release soon. Check out the video at

What is the exact path you are using? You can always check in the debug window of the browser how it should look like when you do the same thing in the web interface.

There are two ways to include the cell phone in the call. The first one is the classical redirection where the caller is aware about the redirection, through this voice prompt. The other way is the cell phone twinning where the PBX is hiding the fact that the call does not go to a "regular" office phone but to a cell phone instead. You can also delay the inclusion of the cell phone by 10 seconds, effectively giving you the same effect like the redirect after timeout. The desk phone will keep on ringing in this case, that is something that is hopefully not a problem here.

You are right, we need to keep the hierarchy experience also for this feature. Although in this case, we cannot do it on extension level as it would cause to much overhead.

We will do that on Monday

Good idea. However there would be the restriction that the global level overrules the domain level. In other words, even if the domain would want to keep it, but the system level wants to delete it, then the record would be deleted. Practically that would mean that the system admin has to set the maximum duration for the domains, and the domains can choose longer duration.

The next version will include a new WebRTC client in the user mode. It is not JSSIP compliant, and probably not even SIP compliant, but it uses websocket and the WebRTC API to make things happen. The end user does not care (as long as it works). The RFC is on our radar, and eventually we will "drift" in to that direction.

We don't have that today. MPLS is a great thing and I guess they are enjoying having a rock-solid connection! What they could do is to use the VoIP phone with multiple registrations or identities, bypassing the local PBX and subscribing to the remote PBX directly. Even though they would not use that line for making or receiving calls, it would show them the remote status.

We have already done that in 5.4.1a. What OS are you using?

You get into the cell phone menu when you call from your cell phone into the PBX, or you can also dial *54. There you can make calls, then park them with ##. You will hear the announcement to bring them into a conference.

In the cell phone menu, there is a way to bring everybody into a conference that is parked (not on hold). Would that solve the problem?

Ok, then we got that sorted out . Actually that was what I have in my mind anyway. Maybe we should not allow further barge in as it does not establish a two-way communication.

Maybe someone can just try out to barge in with three persons. As said before, I am not aware about any hard coded limit, so if three should work so will twenty (subject to CPU).

We had that question some time ago in another context. There is no easy answer. We found weird situations like the call dropped or all agents returned some 3xx code, but this reason should be a "minor" cause from a number perspective.

Hmm. While the original idea was that there would be only one caller barge in, there is no hard coded limit. So in theory everybody could barge in. Of course there are practical limits, and eventually the system will reject additional calls.

We had to clean up the snom files because the situation was getting out of hand with the new models coming out, with names including "D", "d" and "" in front of the device name. We do firmware upgrades only for snom phones; for other phones we thought about it but never did it. Provisionnig firmware upgrades has the advantage that this way new versions can easily fix problems with older versions without having to go to each phone; on the other hand, as you are experiencing, the old saying "never change a running system" might be the better answer when it comes to firmware. What you can do is change the XML files in the webfiles directory, with a good editor like emacs that does not change anything else. That might be a lot faster then going though each domain and do the changes there. In the next version, we will keep a copy of the original file in the webfiles folder, so that we can start working with diff tools to see if there were changes that could potentially merged in.

Whow, I would not have guessed that. Thanks for sharing.

Ok. How about the country code in the domain? Do they have the same country codes?