Vodia PBX

You can do a factory reset via tftp, that should reset everything. http://wiki.snom.com/FAQ/How_can_I_set_the_phone_back_to_admin_mode_or_factory_defaults_respectively

The PBX needs to know which extension needs to be "charged" for the call. It does so by looking at the From header. There it finds the extension "sip". If that extension does not exist, the call will fail. You probably have to put the extension number some where into the device. If you really wanted to use the extension number "sip" please make sure that you have a dial plan in the domain and that the extension uses it.

Yes, however you need to either bind the PBX instances to different ports or IP addresses. If you bind to different IP addresses I would say it is easier to run multiple VM instances.

You could set up four trunks and then define the prefix for each trunk. Also if you set up one CO line per trunk, the PBX will automatically allocate the next available line for you.

It could be that the DNS server becomes available after the PBX service is already running. But the PBX should try again to get the DNS servers when there is nothing available. Last resort would be to try to restart the service, not the whole server. You can also check with ipconfig /all if the DNS servers are looking like you would expect it.

Well after all it is a mailbox! I quite don't understand why you just want to play a message? Something like "I am on a long holiday, so please don't leave me any message as I would not get it anyway"?

You can do this using an auto attendant. The trick is to have the call hit the user, wait until the mailbox picks up and then enter the PIN. It is not so nice like calling the VM directly, but should solve the problem for now. But it would be a good idea to have that action also on the drop-down "When an extension is dialed, perform the following action", maybe the next version will have that.

There are two things that you can do when the maximum number of calls has been reached: Reject the call or play an audio message. The message itself is "hard wired", but it reads the file pb_busy_callback.wav from the audio directory; so if you want to do your own you can just overwrite that file with your own message. It would affect all ACD though and cannot be done individually per ACD. http://www.vodia.com/documentation/agentgroups just updated.

For now you can use the web browser on the iPhone. Having voice on a iPhone is an entirely different story anyway. Android pushes and embraces WebRTC while I have the feeling that Apple sees this a lot more critical. It is not an option for Vodia to develop the whole RTP/SRTP/DTLS stack for a free iPhone app. So we must build on something that already exists. There are some rumors in the market that Apple will integrate WebRTC on Safari and then it makes sense to look into this again.

Really port 443 or did you want to use 5061?

Really hard to say from the PBX perspective. There must be some kind of log on the gateway that talks about the why and when, and that can give you a clue.

Ok but then you have a general problem with your SIP trunk. Did you use one of the drop down providers?

If you log to the file system (including the $ placeholder for the date), you would have a 3 day log history where you could try to dig out details. And if you receive emails on important events you might see that someone was blacklisted because of too many unauthorized attempts, containing more information. I would suggest that you at least set up the email reporting, because this is a cheap, focused reporting on important events and if you set up a rule in your email program then you can move it into the right folder for potential later follow-up.

We are talking about "Specify time when system calls the cell phone"? Works for me...

If there is no domain, you cannot provision any device. You need to create a domain first.

In the modern PBX, you don't need prefixes any more. They come from ancient PBX where people had first to reserve a physical cable to make an outbound call (called seizing a line). Today it is much easier to tell the users to just dial the number like they dial a number on their cell phone: Enter the number and then press the dial button. Having prefixes makes callback and address book entries difficult and confusing.

Yes by default the PBX generates a pretty random password. If the account got hacked, it would be highly unlikely that this was because the passwords were too weak. Maybe they were a left over from an old installation where passwords were like 40/40 and so on, which is pretty easy to hack. We strongly suggest to set the medium password policy; then you will be able to see what accounts have weak passwords and ask them to change it.

Click on domains/list and then click on the domain that you want to use (you need to get into the domain). Then there you find the "settings".

You can as well try to use the DTMF keys in the call to check if the media path is "alive". We have had another case where the audio quality was just terrible (but there was audio coming from the microphone). It can always be that there is a hardware failure with the microphone, especially if scratching the microphone does generate some kind of noise. What you can also try before shipping the device is to go back to a much older firmware, maybe the DSP software is different.

For WebRTC, you need to upgrade your system anyway. The 5.1.3 version did not support it if I remember correctly, or at least did not support everything that you need for WebRTC today. After you upgraded http://www.vodia.com/documentation/admin_swupdate you need to hit the "apply" button again on the license page and then you should be all set.

No the password is in the domain settings (at the bottom). You will also find that password later in the "generated" folder unless you turn that off for security reasons.

If you can "ping" each server without problems we can exclude NAT and firewall problems. Make sure that both trunks are gateway trunks and their outbound proxy is the address of the other PBX. You might want to specify the IP addresses of the other PBX in the "explicitly specify..." so that there is no mistake where packets are coming from (this makes it hard to register phones from the remote site in case that is an issue). If the call gets dropped after 2 minutes check what IP address the PBX puts into the 200 Ok message for the INVITE. Maybe it puts the wrong IP address there and then the ACK does not make it. Also check who terminates the call. Is there a BYE message being sent? Maybe check the log. Who knows, maybe you have limited the call duration on the trunk or something.

Looks okay, except that there are only two RTP packets in the trace. There are two things that are unusual, first the provider sends a 183 followed by a 180 but that should not be a problem. The other thing is that the codec is G722, which could be an issue because that is not a typical carrier codec. I would try to take the G722 codec out in the trunk (offer only G711 u-law and G711 alaw) and see if that helps.

sipgate is not a constant. They are also taking care about their software and their infrastructure (which is a good thing!). If you are running the PBX for a couple of years without problems, I would assume that something on the sipgate has changed recently. The other thing you can check if anything on your firewall has changed. We are also using sipgate for out termination into Germany, and so far had pretty good results. We have even added sipgate to the SIP provider drop-down for easy trunk setup. The best way to get an idea what is going on is to generate a PCAP for the trunk call. Then you can see what is going wrong.

WebRTC is not SIP, it uses different ports (HTTP or HTTPS). You need to make sure that the PBX can also present a routable HTTP and HTTPS address. The PBX is a server that uses UDP for audio (and sometimes also SIP signalling) and TCP for SIP and HTTP. At the end of the day, you need to make sure that the PBX can represent itself to any device that should be able to route a packet to the presented address (usually called "public IP address", but I prefer "routable address" even though it causes my spell checker to protest). It is a complex topic unfortunately, even with IPv6 things will remain complex. You should take a look at http://www.vodia.com/documentation/server_behind_nat to understand how to operate the PBX behind a firewall; this will also apply to the WebRTC script. I would guess if you have a good router you should put the PBX into a DMZ then things should be working pretty well.