Vodia PBX

Please wait one day/night. It could be that the last report is more than one day ago, and that would explain the strange availability times. Was the starting time for Shel 16:38?

Is that Polycom 500 or 501? Is there a version 2.2.2 available for those phones? Maybe there is something wrong with the settings generated from hte PBX, which are based on firmware 2.2.2. The fallback solution is to edit the PnP files manually and put them into the tftp directory. Then the PBX is just a plain TFTP file server.

I have the same problem. But I just can't find what the insecure object is...

Works for me... Do you have multiple domains? Maybe you need to use user@domain to login.

Well, there is currently no single "right" way to set this up. I simply depends... As a rule of thumb: If you register trunks, you have to do that in every domain. If you can use a gateway mode, then you should have one trunk in a dummy domain. Then you can share that trunk amongst the different domains.

You can do that. Just specify a ActionURL on the phone that points to the application server.

That looks unhealty. After the "to" there should be a number, not the "empty" string. Maybe the redirection number is something funny like a space character?

Ehhhh... I have difficulties understanding what the problem is. Can you make an example?

A beta is already available. What OS do you prefer?

Well, counterpath is strict with the certificates. As a rule of thumb, your Web browser must be able to go to the web server of the PBX (using https), without complaining. You can do that by importing e.g. the cacert.org root certificate into the Internet Explorer. I did that some time ago and then the counterpath softphone worked fine.

Instead of tel:alias you should use the ANI fields in the extensions in version 3. The + sign may come because you selected a PnP scheme for ROW. If you don't need it, you may turn this off. Or just turn the flag off "Interpret SIP URI always as telephone number".

The L&G is http://pbxnsip.com/cs410/update-3.1.0.3032.tgz. maybe give that one a shot. It contains also a first version of the hangup detection performed by the PBX as a trunk setting.

It does that - if they are registered to the same extension. If you want to monitor other extensions, you (currently) need to use the monitor extension (extended) mode. However the phones don't display that yet.

No just *86. The other star in the beginning is not neccessary because the input is empty in the beginning and does not have to be cleared. Maybe just give it a shot.

The topic of sending one call from one domain to another is a compliated one. You really need to use a trunk that goes out from the PBX and another trunk that comes into the PBX. I would setup two trunks, both of them with the outbound proxy sip:127.0.0.1 (or sip:[::1] for IPv6), one of then for "inbound" and the other one for "outbound". The inbound should be a global trunk, so that you can send the call to the right domain from there. The tricky part is to find out if the destination is local or not. You can do that in the dialplan, if you have just a few numbers. For example, if you have a central secretary service you can bypass PSTN and send the call directly back to the PBX. If you have a lot of numbers that you want to route directly between the PBX, you probably have to employ DNS to resolve the final destination. If you run your own DNS server and you are able to set up ENUM entries (which is easier than it sounds), you can first use a trunk that performs a ENUM lookup and perform a failover to the next trunk in the dialplan if the entry does not exist. If you get that working then you are in the seventh heaven of hosted PBX and you can scale that endlessly.

Oh. Setting the time on Linux has only limited effect. The PBX actually does it's own NTP and calculates the drift from the OS. Changing the time on the OS screws up the callbacks. When you have a phone call and set the time on the OS, there will be a major RTP hickup. That's why we accept that the clock drifts and calculate the "real" time with this trick.

Interesting idea... AFAIK that should be no problem, because the animation is the job of the GIF and the PBX does not have to be aware about it.

I guess the tricky part is this: [5] 20080101000705: Trunk PSTN1 s Seems then something really fatal happened before the library was able to flush the remaining characters to the flash. Are you doing anything strange?

Try http://pbxnsip.com/protect/pbxctrl-rhes4-3.1.0.3031. Is has a global setting called "send_recording", if you set it to "true" it will treat recordings like voicemail. Maybe a workaround until we found a better solution.

What OS do you run? We can provide a test image.

That was supposed to be a feature... The recordings are now available from the web interface and are shown as such. The motivation behind this was that you might want to receive voicemails as emails, but not recordings. Maybe we need another flag that tells the user what to do with the recordings, just like with new voice mails.

It seems that the phone turns the MWI on even if there are "new" saved messages...

Agree. Will be part of 3.1 and is currently under test!

Agree. We have plans to take advantage of the upcoming multiple-core processors, so that we can e.g. run 14 RTP processes on a 16-core CPU. That would make it possible to perform around 1500 transcoding sessions using G.729A. That should make the discussion about media-relay superfluous.

Did you check the 2nd tab in the auto attendant? Check out http://wiki.pbxnsip.com/index.php/Auto_Attendant, it has just been updated!