Vodia PBX

The setting is called "send_recording" and it is a global setting (see http://wiki.pbxnsip.com/index.php/Global_Configuration_File on how to change it).

For this, you should use the ANI field. You can set it in the extension, and anything else that is able to make a phone call. If you want to use the same ANI for all extensions, you can also set it from the trunk.

Multiple identies on one handset are always a headache. If you are using buttons, you can tell the phone what identity context to use for a button. The PBX usually stays out of this dangerous water; but in your case it might make sense to bind it to a specific identity.

Okay, this is what I did: I nuked the phone several times with a factory reset, and settings reset. After that, set it up for PnP with HTTP, and username/password set appropriately. It works. I did not try to downgrade the bootloader. Maybe the older bootloader has the problem that authentication is not supported yet.

So does it already go to the IVR node? Try using the auto attendant instead of the IVR node. Depending on your DTMF setup, the IVR node might not be able to detect the CNG tone. As you are going to the AA anyway, that should be no big change. Then you can use the "F" in the direct destinations.

We added a new header called "Related-Call-ID" that makes it possible for the service provider to check if the Caller-ID is a valid redirection or the caller tries to spoof a caller-ID. AFAIK CallCentric supports this header. A quick try will show this.

Well, we had some code in there already when we realized what the real problem will be - in most cases there will be a mailbox picking up or just no answer or busy. Then the next question is if the PBX should give up inviting that person or retry after a time. If it is about saving the participant the cost for the call a transfer into the conference is the better answer.

Maybe it is easier to use the click2dial feature that just uses a HTTP request. Maybe you can just start the web browser from the command line and provide it with the correct link to start the dial.

I believe this is because the PBX does not send RTCP. Seems like we finally have a reason to put this in.

I agree on the domain part. It would make life easier for moving domains around. The reason for the flat architecture is that relational databases use a integer as index. We would have to change that into a domain-context index. Not sure how much that would be a problem, but it is worth thinking about it. The logging is more difficult, as many log evens simply do not apply to a domain. Also IMHO the domain admin should not dig in the log; this is the job of the system admin.

Can we somehow get the address book do this?

You should change the PSTN gateway logging flag (admin->logging settings), set the log level fairly high (e.g. 9) and reboot the device. Then make an inbound call and check the log for information on what the gateway sees regarding caller-ID. Maybe Costa Rica is the next country that had it's own idea on how a caller-ID should be presented...

You should see in the log file of the phone what file it is trying to fetch.

3.3.1 is writing a syslog message when a admin logs in, including the IP address. This also goes into the web interface. Unfortunately, because syslog is crazy difficult in Windows, this works only in Linux. Brute-force attacks are slowed down significantly because an unsuccessful login takes several seconds and the PBX lets other requests wait before it accepts them.

The waiting time is the duration the caller spent listening to music and annoucement (no agent taking care about this call yet). The ring time is the duration while the caller heared ringback tone (agent's phone should be ringing here). The talk time is the duration the call was connected, including the duration the agent put this call on hold. The hold time explicity shows how long the call was on hold, the brackets around it indicate that this is part of the talk time.

Hmm. Really good question (I don't know). You can always check by base64-decoding the license key. If you see something with "call" and a number behind it, then that's the limit.

You could use the failover feature of the trunk to let the PBX try one trunk first and then move down the dial plan on another trunk if the first trunk fails. Having only a certain number of CO-lines will also help to limit the number of calls on a trunk; you might not need it if the gateway sends a 5xx code when all lines are in use already.

AFAIK Polycom has no way of explicitly turning a LED on or off. The PBX has to pretend that there is a call going on on the resource that they subscribe to ("BLF"). Did you try to monitor the flag the way you monitor an extension?

Yes, the concurrent calls are one limit. The CPU load should also make sure that there is not too much jitter coming up. If you want to keep the participant circle closed, you should invite the participants. Then only users that know the PIN can join the conference.

We made a fix that allows the admin to manually put files into a folder called "provisioning". That makes it possible to upgrade phones in the field. Obviously we want to push the responsibility for publically exposing passwords to the admin. So keep these files there not for too long. It also makes clear why we needed to do this. It is not that we got bored; there was simply a security hole that we needed to close. Unfortunately, it is not possible to do this fully backward compatible, as the phones out there simply are not able to authenticate themselves. The attachment can serve as template (however - untested, so a feedback would be great). snom_000413123456.xml snom300_000413123456.htm

Should be fixed in the 3.3.1 release.

Whow. Never stop learning!

This problem might go away with another fix that we needed to properly record DTMF during a conversation.

You have to use DTMF for this unless you want to record all calls. AFAIK Aastra does not support a magic record button that works without DTMF.

We will provide the possibility to provision the web client passwords. For this, you will have to put files into the html or tftp folder, this way the devices out there will get the password. This is again "safeby by MAC", but at least once the upgrade is over you can remove the files and continue normal operation. For new devices, you should make sure that the devices have the username/password already in the device and the customer knows how to put it into the phone after a factory reset.