Vodia PBX

I believe it would be too complicated to get recording on this device. There are two things that come to my mind. First, you could mount a NFS partition and record on that partition. Second, you could use the monitoring feature of the PBX to send all calls for call recording to an external destination (as a SIP call). In both cases, you need a recording license and enough CPU power. For serious recording operation, I would recommend to switch to a server/PC and do it there.

Good point. In the 3.3 build (3.3.1.3177) we had to change this. You must use the username that should be provisioned; but you may use the password of the provisioning settings for the domain. This has the benefit that the user may change his or her password and still reboot the phone and get the provisioning data. Important: Make sure that you have the domain provisioning data setup. There were versions that generated a default password, which is easy to guess and with that an outside attacker can easily get the password of the domain's accounts.

LOL. That could be "scary cool" - then the caller hears the voicemail annoucement he probably adds a comment nobody is supposed to hear! Maybe during that time the caller should be muted ...

Provisioning Cisco phones remains a tricky topic. You make one little mistake, then the whole config gets rejected. We have templates for the 7960 and the 7961 built-in; however did not work on them over the past few versions.

Did you try the "Explicitly specify pickup preference" in the extension setting?

The list size is always 25, you cannot change that right now.

No they are really deleted immediately. We have another issue with the shared mailboxes that is related to that problem. When a message arrives at a shared mailbox, the PBX better copies that (with the link to the file) into all other mailboxes - and then when one of the recipients deletes it, all other messages must also be deleted. We better this this problem as well, catching several birds with one stone...

Hmm. Maybe try 3.3.1.3173 instead?

Okay. However, after some time the caller should hear the prompt to enter the number?

Yes, this is on the list for the remake of the mailbox. So far if you choose to delete it, it is deleted immediately. Best way to avoid the loss is to send it out as email. Then you can decide what to do with it in your email client.

So far the state is that the PBX does record, although the direction sometimes gets screwed up. 3.3 is still not out, still some issues that we don't want to release.

If you call that extension again the callback will be canceled.

Yes, ## should work in version 3.3.

Yes, there is a callback function like that. In the calling card account, check the "callback" button. There is one catch with the hotel room: In many hotels, there is no DID number for the hotel room. This is a interesting fact, because there are more DID numbers in this world slash in the USA than IPv4 addresses (10^10 > 2^32). For that you would probably need that recording asking that nice lady at the front desk to put the call through to the room that you have just recorded. Not sure if you can trick all hotels with that, but at least some of them. The other thing that would have to be added would be entering DTMF digits after the call got connected. This is to get through auto attendants. Version 4!

* generally means "clean up the input". So when you press it, the PBX thinks that you know what you are doing an stops talking to you. # is usually "enter". If there is no input, there is nothing to enter. Okay, obviously in that case the user does obviously not know what he is exactly doing so the PBX should be talking something. If you want to really call a star code, you can do that from the mailbox main menu. There you are "logged in" as your extension and there is no authentication problem.

The "Try Loopback" is a kind of hack to deal with the situation that many installations realls just have one server and don't want to add anything to the installation. Once you are running multiple servers, you need to have something external that redirects trunk calls to other domains on other servers anyway. You need to disable Loopback Detection (admin->settings) and you must have IP addres 127.0.0.1 on that server (which is no problem if you are running IPv4).

3.2 is pretty stable. If you don't need the L&G this is very reasonable.

Did you set the country code to 49? If yes, then check the dial plan again. The patterns in entries there should *not* have prefixes. You can add prefixes in the replacement, but the PBX internally puts everything into a global format, which starts with 00CCAA (CC=country code, AA=area code) or 0AA or just the local number (the way you would write a number down on paper). For example, you could use pattern 0033*, and replacement 00033* if you want to put a zero before the number if you want to have a rule for France.

The snom PnP is still a little bit work in progresss, I think we have to come out with a 3.3.2 build that seems to clean all the problems with the snom PnP up (and also some smaller issues we found with Polycom and Linksys). If you can hold it for one or two more days, hopefully then we have a version that makes plug and play a positive experience.

The example 9[911|411] uses "simple" expressions, while 9(911|411)@.* would be a ERE expression. Both are bad examples, because in version 3 there should be no more 9 prefix for outbound calls (this just creates a mess with the address book). Thinking about a version 4 dial plan I see more the problem that customers want to define by the number prefix which trunk the call should take. I have seem long long dial plans that scare me. Maybe we can just have something like a CSV list that defines which prefix gets routed on what trunk. Just thinking aloud here.

Out of band-DTMF is problematic as the PBX just passes it through without converting it into inband. The direction problem is because the PBX has problems determining if this is a inbound-outbound (redirected) call or not. We probably have to change the recording model so that we define the point where the recording takes place. For example, it would make sense to define that the recording always takes place on the trunk call leg. At the moment the model is not very clear and that leads to difficulties understanding why something is inbound or outbound.

You can combile different service flags. When you list them, they are processed in a sequence until there is a "service active" (see http://wiki.pbxnsip.com/index.php/Auto_Att...t#Night_Service). Also, the AA has the possibility to play back different annoucements for different times (IVR tab). That should make it possible to cover most cases.

Well that should work... I saw examles for 411 and they did work fine.

Are you provisioning the VLAN tags? What version of the PBX are you using? If you do that, you'll need DHCP servers in both VLANs (VLAN 0 and whatever VLAN you are using) and the PBX needs to be present in both VLAN for the provisioning.

Yes. But if the way we are doing it would also work with version 3 it probably also does not hurt.