Vodia PBX

The other option might be Microsoft Exchange 2007, which also supported at one point (?) fax to email. If they already have it, they might just need the installation service to get it going.

Thanks all for all helping us to test the various beta versions, this temendeously helped us testing the system out in all kinds of environments that we can never test in a lab environment. We feel that we can make the final turn for release. There are still issues open, some minor and some great ideas what we should add. However further holding back the release seems like a mistake to us. The current state provides with the best stability and feature set ever. Then after release we can continue working on new features and start the release cycle for version 5. We also have some 500 pages of documentation ready for this release. We will post the links seperately. Also, this time we have put the release notes into a PowerPoint presentation and we will also make this available shortly. Here are the links: Win32 - http://pbxnsip.com/download/pbxctrl-4.0.1.3475.exe Debian 4- http://pbxnsip.com/download/pbxctrl-debian4.0-4.0.1.3475 Centos - http://pbxnsip.com/download/pbxctrl-centos5-4.0.1.3475 FreeBSD - http://pbxnsip.com/download/pbxctrl-freebsd7.0-4.0.1.3475 SuSE10 - http://pbxnsip.com/download/pbxctrl-suse10-4.0.1.3475 CS410 - http://pbxnsip.com/cs410/update-4.0.1.3475.tgz

If the fax server uses the call-ID in the To-header, then it should be okay to use just one extension with 32 alias names. I think there was a French company offering fax to email. There was already a discussion in the fax forum some time ago. Fax is not a simple topic, it is not that we just do a quick hack over the weekend and have a stable fax solution.

But you hear the prompt that asks you to connect?? Does DTMF work otherwise when you call the cell phone? For example, when you have a mailbox message, the system calls the cell and then you can listen to your mailbox messages and delete them with DTMF?

*601 is the internal code and if the call (which is behind the code) is not there any moe then the code probably passed to the dial plan. Now we have to deal with the question what to do with this star code. Maybe we need another settings that controls weather star codes are passed to the dial plan or not (we could survive a couple of years without it). Or we have to introduce a list of star codes that are passed through.

You might use a analog gateway which generally have problems detecting when the call was really connected. Check if you FXO provider supports polarity detection, then the gateway has a chance to detect when the cell phone picked up. Then the PBX has a chance to start the playback at the right time. I guess with a PRI interface or SIP trunking this problem should disappear.

Well, if you are using RFC3325, then the PBX will keep the original caller-ID in the From header. No problem if your carrier can present this as the caller-ID. I think in the SS#7 world there are two caller-ID anyway, the one to display to the user and the one that should be used for billing. But AFAIK practically all cell phones only display the first one. If you are the carrier, you can do this relatively easy. The PBX even sends a (proprietary) header with a "Related-Call-ID" which indicates the original call leg for reference. But I guess that does not help you... The billing problem is probably that carriers generally love to bill twice for redirected calls. Double the revenue! From a legal point of view, an audible indication that the call eas redirected is already there. I am not a lawyer, but it might be enough to make the legal department happy.

This happens when the PBX is not interested in DTMF, for example when the call is established between two endpoints. Try to call the auto attendant and see if the DTMF still fails.

Yepp. The good old Kiwi still has it. Just in case we really turn it off one day: Get access to the file system of the PBX Edit the pbx.xml file and delete the hash in the pw_pass field Restart the service. Login without password. This also points out what the security relevant point of the systems are. I just heared from a friend a story that someone hacked his gateway running on public IP (not the PBX ) and produced a telephone bill about 50,000 dollars within one month. "Least cost routing" in a way for that hacker. So be sure to pick passwords that are not so easy to guess if you are running the stuff on public IP! This is serious.

The PBX never changes the gain; and there is no option to do that. You should fight gain problems at the root. Maybe that extension has the microphone volume completely out of range. Or even a bad microphone. If it is really a gain problem. A good way to compare gain is to have several phones in a conference room and let them speak one after each other (ideally having the same person on the different devices).

Ehh... Not sure about the licenses. The SipJack technically can do it, and AFAIK you can run any kind of license there. In any case the "3 minute key" ha sall options in it, so can try anything out. If you just want to play a prompt consider using a IVR node. That is easier than trying to get an auto attendant quiet. Yea, we were trying to improve the startup behavior. When you have a lot of CDR and rates, the startup would take so long that the service manager would believe the service did not make it and kills the service. Hopefully now that problem is fixed. The PBX sends busy only if the system is overloaded. That might be a problem if the virtual machine does not get enough CPU horsepower. Anyway for testing the VM might be okay.

3xx codes usually treated as pure error respones from carriers, which makes a lot of sense. There are huge billing problems with 3xx-codes, imagine redirection to cuba. There is no authentication of 3xx responses, for starters. The other problem is that 3xx responses can have more than one contact, meaning that the carrier would have to support forking. The other technical problem is that the call is often already connected (the initial INVITE has been answered with a 2xx class response already). Then most carriers will ignore 3xx-responses. In this case the PBX would have to send REFER, which has the similar problems as 3xx, and which also most carriers don't accept. The way to indicate redirection is today probably History-Info (RFC4244). Even if the PBX would use this header, I doubt that the cell phone provider would do anything useful with this. Last not least, both with 3xx and REFER you cannot fork the call to the desktop phone and the cell phone. If you use this method, we are always talknig about a simple and dumb redirection to the cell phone. For example, you will definitely loose the "1" feature for connecting the call. That is why we simply play back the caller-ID when the user picks up the call on the cell phone and decided to use the "1" feature to connect the call. I know from a user perspective, these answers are not very satisfying. In the end, only the cell phone provider can change the picture.

No, that is not a bug. Groups don't record the name, this is just not practical. And the recording can never depend on which agent picks the call up. The point about a group is that several extensions may pick the call up and the decision is made based on the caller-ID in the display. If the agent has to permission to make a decision if the call should be picked up or not!

The other alternative would be to use a agent group instead of a hunt group, because there you can play MoH while the callers are waiting; and you have more control about the audio playback part and when the call is considered "connected".

Oh because you heared ringback in the hunt group?

That should be coming on log level 6 in the media part.

Well for the cell phone forking the "1" is there. But for desktop phones the PBX offers that feature only if someone calls the extension directly through the auto attendant, not through a group (which would be kind of difficult anyway). But desktop phones always display the right caller ID as the call does not get redirected. Make sure you use the version 4 for this. There the cell phone forking is available for hunt and agent groups (ACD).

Strange. Do you have a failover set on the trunk? Maybe it is too short. Otherwise, it would be interesting to see the INVITE that is sent on the trunk and the response from the service provider.

It needs to be able to resolve pool.ntp.org to a IP address that runs a NTP server . You can also make this happen in the LAN, if you have access to the DNS server...

I remember we used to put a "R:" in front of the display name. Not sure what happened to this one.

Ringtones: Difficult topic, but possible. For example, see http://forum.pbxnsip.com/index.php?showtopic=3321. Image: Also possible, but then you really need to start editing the provisioning files.

Did you see http://provisioning.snom.com/download/fw/s....2.29-SIP-f.bin? Seems that is a much better firmware.

Where does the call go? To another PBX? Maybe you assigned the wrong dial plan to the hunt group. When the PBX forks the call to the cell phone, it does that using the dial plan of the extension; while other redirections out of the hunt group are being made with the dial plan of the hunt group.

I don't get that part. You mean that the phone should ring, then then the user picks up he should hear an IVR asking him to press 1? The other parts seem to be clear and no big problem (maybe just get a demo code and try it out).

Well, did you try to use the *98 to record the call? if you use *98*1 you can record the greeting 1, if you use *98*2 you can record the greeting 2, and so on. You can have up to 5 greetings.