Vodia PBX

Yes after changing XML files you always need to restart the PBX service.

Yes, sorry admins folder!

User 216 is a problem. Obviously there is a agent listed that does not exist. It is not fatal, though. The log about the hunt group is not serious. 4 is fine. We had cases where the hunt group needed to add 10 or 20 agents, which would be a problem. This would create a packet storm to invite a lot of devices into the call.

Yes there was progress. One the one hand, there were situations when the PBX was reporting a "false alarm" when then trunk was still registered but the PBX already indicated 408. But there were also improvements regarding the actual behavior. We have recently investigated a case with Wireshark where the PBX was sending out REGISTER, but intermittently the service provider really did not answer. We also had cases where the problem was not SIP; but DNS. If the DNS server does not answer, the fail-over to a secondary DNS server may take significant time, and it can also happen that a request times out because of that. Unfortunately, the SIP RFC requires a lot of DNS queries (DNS NAPTR, SRV for TCP, TLS and UDP, AAAA and A), just to send out one REGISTER request. If the TTL is very short, that is a major problem.

It seems that the call comes from a number that is an extension on the PBX. This has a higher priority that identifying a trunk. Change the number of the extension and then it should work.

You mean you can call internal extensions, but not outside numbers? Then you have a problem with the trunk--the password is not correct or the device/service provider expects the SIP headers in a different format.

ACK. We have found that problem already. The next build will include the fix. Workaround until then is to edit the XML file in the domains directory and set the password there (encrypted="false").

In the previous versions, this HTML content was largely generated by the PBX core itself. We are changing that to use JavaScript in the browser instead. It sometimes seems like a step back; however now it is a lot easier to make changes to the appearance. Newer versions will eventually go beyond what has been done before.

Yes the blacklisting is a pain in the neck that needs to be addressed in one of he next builds.

You need to disable call waiting.

When someone is on the phone, it does not mean that he cannot have another call. This is called "call waiting". If you don't want that, you can disable it ("Enable Call Waiting") on extension level. The other feature is "camp on". You can also turn it off on domain level if you don't want to use it.

Fortunately, webrtc always uses TCP or TLS. No UDP madness.

Yes, pretty much. The GXP14xx have no BLF buttons, which makes it easy to provision them. A model with buttons is on the way. We were trying to use the multicast method, but could not get that to work. But at least the phones can set the provisioning server through the phone user interface (keyboard), so that it is practical to roll out these devices using this method as well.

Yes, we don't publish your email conversations with our sales on this forum. Thank you for your understanding.

That is indeed very long. Is there any other process on port 80? In Linux it can take a long time until the ports are available for exclusive binding. The PBX then can get into a try again and again cycle to get the ports. Workaround is to stop the process, wait for 60 seconds and then start the service again. The duration is in the Linux network configuration (tcp wait linger timeout or so). We have solved that problem in 5.1 where the PBX tries to grab only the ports that have not been allocated successfully yet.

Yes I think I know what you mean. Of course if you invite a public audience you are also attracting people that are not welcome. Sooner or later there will be robots trying to make WebRTC calls, and I guess the few sites available today are their test bench. This will be a pain in the neck as we know it from email SPAM, jeopardizing the benefits of browser-based telephony. At the end of the day the question is how we can find out if the user use human or a robot. I see two possibilities here. First, we could send the call to the auto attendant, so that the user has to press a button after listening to a prompt. That is still possible for a robot, but difficult and whoever is operating the robot will find out that this does not lead to free international calls. What we could do here is randomly pick the button that needs to be pressed, so that the robot would have to really listen to the what is being said at the right time. So considering the time factor and the right button, you can reduce the risk of a SPAM call by factor 50-100 easily. The other possibility is to do the Captcha game: The system shows an image with a small riddle in it, one that is hard to solve by a robot. It does not have to be only that distorted text. It can also be more creative like telling what color an animal in the picture has. The disadvantage is that this will make the click to call feature inconvenient and people might prefer to use the traditional phone call.

Either you add a entry to the auto attendant that gives callers to leave a mailbox message, or in the hunt group you eventually after some time send the call into the mailbox in question. If you want a more closed used approach you can list the cell phone numbers of those who should be able to listen to the mailbox message; then when they call in they will hear a different menu (private virtual assistance) from where they can dial numbers in the system as if they were extensions.

You mean something like a captcha? There is already a trunk hash in the call setup, so those guys are a little bit more sophisticated than just trying WebRTC ports out.

Under "customize" in the admin mode there is a item "translation" that you can turn on. Then you can click on the "edit" links next to the translations.

You somehow need to make it to the mailbox. Then when you hear the prompt "please leave a message" start entering the PIN. Then you should be able to hear the messages.

Thanks for the update, interesting!

Dazu einfach eine email an support schicken mit dem Aktivierungs-Code und des Status-Screen (reg_status.htm) der PBX.

Okay if internal calls get disconnected yes we can exclude the sip service providers. Do you also have a log with the SIP messages included for the call? Also, set the log level to 9 on media, sip, and general so that we don't miss any important message. What operating system is this?

Service providers do change their setup from time to time. That does cause such effects. The "was erased forcefully" means that the call was already in disconnected state, and the PBX was waiting for the final handshake which did not come in. Anyway, I would look at the SIP log for the call. If you are getting emails for disconnected calls, they should be in the attachment. Otherwise set up the logging (filter by the service provider IP address). If you can share the messages for the INVITE transaction with us, we can probably see what the problem is.