Vodia PBX

Until the attempt counter for that message reaches the number of 50. Or you manually delete the message.

You mean the redirect button mode? This is similar to DND, but instead of setting an extension on DND it toggles the call redirection to the specified target. When the redirection is engaged, the light will be on.

No physical SIP gateway; just the "gateway" mode on the trunk. You can also use username/password on a SIP gateway trunk for authentication.

We'll make that default for version 4.

Do you have the audio_moh files? The beep is there.

Arghh. That looks like trouble with the file system (flash). What color has the box?

If you are using the built-in FXO gateway, you may want to check that the hangup detection on the trunk is enganged. The gateway itself has a hard time detecting the hangup tone sometimes. Therefore we added this to the trunk setting.

For pbxnsip, "intercom" means extension calling without having the other party picking up the call. That means the call immediately gets connected, it is two-way audio. Typical scenario is the James Bond ordering the 3 PM tea from Mrs. Monneypenny. "Monneypenny, where is my tea?" - "Immediately, Mr. Bond". It depends a little bit on the handset type if that works or not. Not all SIP phones support this.

Try to talk to whoever sold it to you to swap it out. Maybe you really got a bad one. And make a backup...

Those warnings are okay. I remember I also had them and it did not matter. Check if the script and the PBX executable can be executed. Use "chmod a+rx" if they are not.

The PBX generates ringback tone only if it receives a 18x message without media. The SIP standard is pretty clear on this. Only when the gateway changes it's mind, it can send another 18x with SDP and then the PBX will play back whatever it receives.

Try this: sip.to.user == "9787897899"

In one way or another this will work. I remember some early CD players had the headset output that you could easily loop back. Otherwise the media player has to do that job and you have to hope that the media player does not crash the system. We had a case where the MP3 player was consuming all memory of the system and also the PBX went south after some time...

Are you using the inband detection of the PBX? Or is the carrier supposed to do that job?

Is this a white box?

Cool. Thanks!

In the SIP world, STUN today is used essentially for outbound and ICE. In the old times, vendors believed that STUN would help overcome the problems with NAT. But it soon became clear that it makes support very difficult. There are so many different NAT implementations out there that a vendor better assums the worst case, where STUN must be sent to the exact address and port of the SIP server. That is exactly what outbound is doing. That does solve the issues with the SIP signalling traffic. For media, ICE is useful if you want to establish a direct path between the communication endpoints. Because the PBX is a media-aware application there is no point for ICE on the PBX (at least not for calls from extensions). ICE might become interesting for trunks, when OCS-based installations are mainstream.

That is the service which writes to the flash file system. There are limits to this embedded system. The Linux kernel has a hard time writing all those changed files to the file system. This was before they came out with SSD and the know-how to use NAND flash efficiently.

There are several ways to do failover. One way is surprisingly simple. Use a virtual machine and make sure that the PBX is the only VM on the physical host. This way you get the QoS you need. You can let the VM then handle the failover in a "virtual" way. The PBX will not even know that the virtual machine has just been moved to another physical host. Disadvantage: You need some serious virtualalization software for that (not sure if the free VM do this job). The other way is to have two machines that share a virtual IP address. This is a "classic" setup and you can use tools like rsync or heartbeat to keep those server in sync. When one server fails, the other one starts the PBX process and takes over. This approach will take a minute or so before the failover happens. This is not very fast, but at least faster than you can do this manually.

More than a second delay cannot be explained by having the PBX in the media path. The speed of light (and information) is 186.000 miles per second). That would make it possible to send the call around the world a couple of times. There must be something else going on. Sometimes the problem is that the bandwidth gets to the edge, and the packets somehow make it, but very slow. The other situation that we have seen is that packets were run over a cellular data network, where the carrier seems to slow the packet down (to make it unusable for VoIP I would guess).

Well the point of the listen mode is that the parties are *not* notified about this. This is really pure stealth. That is essentially the difference between barge in and listen in! You can control with the permissions who has the right to listen to which calls. This way you can make sure that the execs are not being tapped.

We are currently testing the latest beta. There were a lot of "under the hood" changes and we simply need to test them. It does not make sense to give out a beta that will just have simple bugs. 3.4 is a great version; we don't see the immedate pressure to release/hand out something instable...

It is a little bit a question of taste. Having the media session established before the user picks up has the advantage that the first word ("hello?") will make it in time. But it is a little bit tricky, especially if the server supports call forking. 180 is of course a lot less effort and it also uses less bandwidth. Again, all in all a taste question and that is why we have th option.

No. AFAIK google does not use SIP. We only support SIP as the standard of choice.

If you get the phone call from a trunk, try send "Message 180" instead of media. Some service providers cannot deal with media ringback. This is because practically all softphones just return message 180 and don't generate their own ringback signal. The message that the PBX wants to add so and so many members is just for information. In small embedded systems, adding a lot of members can choke the CPU. For a PC, that should be no problem.