Vodia PBX

You can use the final stage. Just point it to an auto attendant.

Yea that is a real problem. We need to (finally) address this in one of the next versions. I guess the best way to do this is to call the extension that parked the call and say something like "hey there is a parked call that has not been touched for so and so". Alternatively, we could give the caller the option to press a key and go back to the operator. Maybe even automatically after a timeout. Then at least they have a better option that just hang up.

Do you have a log that you can attach here?

Whow. Probably 2.0 solves that problem because it only offers the SRTP key when TLS is being used.

By default it uses u-law.

Static is generally a sign that there is something wrong with the SRTP encryption. Yes, you should try the latest firmware. 2.0 allows SRTP only if the TLS transport layer is being used.

He is probably talking about http://wiki.pbxnsip.com/index.php/Auto_Att...ct_Destinations

The SuSE 10 image is now also available.

There were a few problems that have been fixed in 2.0.1. First, the 2.0.1 fixes an important bug when deleting non-extensions. And it fixes another bug where the extensions count could be ignored. And last, there were keys which simply mixed the "accounts" and "extensions" up. So all in all, the 1624 build should fix all known license problems, and you might need to check your license key. You might use this link to check what is in your license key: http://www.opinionatedgeek.com/dotnet/tools/Base64Decode.

You can use SNMP to see how many registrations the PBX has. See http://wiki.pbxnsip.com/index.php/SNMP. If you want to find out if a specific user is registered, the only thing that comes to my mind would be using curl to pull the information off the web interface of the PBX.

Well, well, it turned out there is really a bug in the licensing part. When deleting a account (except Extension and CO-Line), the license count was not decreased. Workaround: Manually delete the corresponding file from the file system and restart the service. Well, that is not really an option. Therefore we made a new version 2.0.1.1624 what should fix this problem.

AFAIK many ATA implement hold by using the hook flash. Transfer can be done using the transfer star code. If that does not help, we must have a more flexible way of controlling a line with DTMF keys. We saw that problem already with the recording.

We have put version 2.0.1 on the download page (http://www.pbxnsip.com/downloads.php). The release notes can be found at http://wiki.pbxnsip.com/index.php/Release_Notes_2.0.1. Upgrades: We believe that the 2.0.1 fixes several important issues that we found in the 2.0.0 release. If you don't experience problems with the 2.0.0 release, there is no need update. However, if there should be open issues with the 2.0.0 installation, we recommend to move to 2.0.1. We recommend to backup the working directory and the pbxctrl.exe executable before performing the upgrade.

Well, that might be the problem. I guess this should be "extensions". Otherwise the total amount of all accounts will be 10, but you shoould be ablt to have more. I guess you will receive a new license key shortly...

I would definitevely upgrade to 1.5.2.7 (see http://www.pbxnsip.com/downloads.php). This is a relatively painless upgrade, because all you need is to replace the executable. You can still keep the old executable, and also move back without pain. The whole redundancy thing depends on the error code that is returned. There is a setting for this in the trunk. Did you try that? What error code is being returned?

Do you have a server on public IP where we can try this out? Maybe sent the address privately to support@pbxnsip. Being able to repruduce this problem will speed this up.

Maybe there is a problem with your license. For example, if you created the attendant with the demo license, and then later got a "smaller" license, the PBX will probably allow the deleting (sic!), but not creating a new one. There is a little trick that shows you what the license actually contains. For example, you can use the following link: http://www.opinionatedgeek.com/dotnet/tools/Base64Decode, enter the license code there. Then you can see how many of each type this license contains. If the problem persists, please send the license back to sales and ask them to give you a new one.

The administrator is password is stored in the global configuration file (see http://wiki.pbxnsip.com/index.php/Global_Configuration_File). Typically that's pbx.xml. You can edit this file with a regular text editor. There is a setting called "pw_pass" which contains a hash value. If you delete that hash value, save the file and restart the service the password will be empty again.

Let me try to understand this 100 %. So lets say the PBX receives an incoming request from 2121231234 to 9781231234 - which belongs to "Company A". The receptioning is registered at extension 123. The packet going to the phone would look like this: INVITE sip:123@192.168.1.2;line=123 SIP/2.0 From: "2121231234" <sip:2121231234@localhost> To: "Company A" <sip:9781231234@localhost> P-Asserted-Identity: "2121231234" <sip:2121231234@localhost> The phone's job is then to display the "Company A", so that the receiptionist is able to say "welcome to company A - how can I help you"? The way to do this is to use the address book. The PBX changes the display name according to what is in the address book, also for the To-header. I just saw that this is a bit difficult if you are using the 2.0.0 version (thought not impossible!). In 2.0.1 this will be the default behavior.

Ok, lets clarify this: For outgoing requests coming from a trunk, the PBX is able to answer BYE challenges. For incoming requests that are sent to a trunk, the PBX does not challenge BYE requests.

I don't get it... If the gateway wants to hang up, of course it should send a BYE. Where is the problem?

Trunks can answer challenges, also for BYE request. You need to set up the username and password in the trunk for that. However, challenging BYE has the big problem that is might not be possible to hang up a call. That is very dangerous. The PBX does not challenge BYE. The Call-ID is the "token" for the call. If you want to protect others to send a BYE (DoS), use TLS transport layer.

Not neccessarily. If your provider properly handles the line parameter in the registration, the PBX can tell which domain the incoming request is using. You probably have to use the "To" header for routing purposes. If you use "!(.*)!\1!t!" (which says: use the To-header to identify the extension) in the Extensions of the trunk, the PBX should route the call correctly by the DID.

Sorry, we did not do that ourselfs, but the one who was using somehow was able to do it. At the moment the only option seems to be to turn provisonal responses (100 Trying) off. An Ethereal/Wireshark trace would still be helpful to solve this problem.

oh no... I guess the "100 Trying" is the problem. We already had problems with that and they should be solved, but it is something that raises eyebrows. There was an option in IIS to turn those messages off, maybe that solves the problem. But we also have to take a look into those provisional responses again.