Vodia PBX

We fixed one thing and another one popped up. One step forward, one back. However, it seems that we now made two steps forward and only one back.

Not an easy topic... The best way to do this is to build on CSTA. There are more proprietary interfaces (e.g. used by the WAC), but they are likely to change without notice and you dont want to change your code all the time. CSTA is standardized and gives you a documented API.

Whatever the name of the forum is, we will not throw it away. The wiki got a little bit rusty anyway and the plan is to dust it off and come up with a new one.

We had this problem already with BlackBerry phones... Seems like the cell phones dont like the GSM WAV files. Unfortunately, there are different GSM formats so maybe this requires some tweaking. Do you have an email that works (using GSM)? Or should we just "compress" it to u-law? We need an email with a WAV attachment that works (ideally both on Android and BlackBerry).

If you like send an email to support for the latest build. Maybe the problem is solved now.

yes, dear... yes, dear... yes, dear... yes, dear... yes, dear... yes, dear... yes, dear... You can change the parameter, it's name is "timeout_connected" (this is a global setting, change it in the pbx.xml file or through the web interface). The other problem is that many firewall close the ports if there was no activity from the inside. VAD is not such a good idea anyway.

Yes, this is a know problem with the Aastra phones. They register using SUBSCRIBE, and then when the PBX restarts it sends a SUBSCRIBE again as if nothing happened. The PBX then sends NOTIFY with "fresh" CSeq numbers which are really out of order from the device perspective. We'll try to send a 410 Gone code when we receive a "fresh" (as from the PBX point of view) subscription. That should solve the problem; hopefully it does not break anything with other devices...

No. We don't like this way of configuring the PBX, as it interrupts the service for a pretty long time. Think about reloading the config when you have 100000 CDR in the tables! It is better to use the SOAP interface if you must write something in to the internal database.

Hmm. When the program receives a signal, it usually performs the default action. In other words when it crashes, it does not delete the PID file... Maybe we have to define what signal should be used to shut the service down and then the pidfile can be deleted in a controlled way.

Oh you mean when you initiate a phone call from the PBX (e.g. click to dial), then you see the wrong Call-ID? Yea, that is a tricky problem, I thought we had a version that turns it around the right way by now.

Hmm. Not possible just using a dropdown list I guess... XML could be the answer. The button essentially gets a XML document from the PBX what lists the options. Then each of them uses the right star code for the action that should be performed.

Let me try to understand this... So you want to press two buttons? First the action and then the destination?

If the gateway is able to send the right DID in the To-header or the Request-URI it should be indeed simple. Then all you need to do is set up a alias name for the extension and it should work. There is a lot more treaking that you can do (see inbound routing on trunks), but if you just want to send the call to the right account the alias should be enough.

That has a lot of limitations. Everything that is stateful will get lost. For example mailbox messages won't make it. Though it is still better than having no service at all.

If you use Linux, you need to know what you are doing. There is some help available on http://kiwi.pbxnsip.com/index.php/Installing_in_Linux, but this does not replace the know-how of a root admin. If you just want to try the product, I would just use Windows. Apart from the installation, the different OS versions are pretty much the same.

I would definitevely also check out VMware and Hyper-V. We have installations that perform failover using VMware and I guess also Hyper-V (setting this up right now in our lab). I heared only good stuff about it, it can failover within the call even if the caller is for example in the ACD. The failover time when using a small VM is in the ~1000 ms area. It sounds like a hickup, but the conversation can go on.

You can as well just move the CDR directories to another location and then restart the service (should be very quick then).

This is actually easier than it might look. Just make a backup of the working directory of the PBX and you are all set. If you want to restore this version later, just put it into it's old place. The web interface is intended for systems that cannot provide file system access; but if you are using a PC you should be able to copy the files. It does not crash on the first registration? What do you mean by "crash"? Does the service manager say something? 30 minutes are very very long. What processor are you using? Where is the file system? You mean IVR? For recording, you need a recording license, maybe that is the problem here. Any more input on your setup? We have cases where it does work.

Did you consider virtualization for failover? This solves a lot of problems, including the one you described in this topic.

Yes, pretty much in the SIP world. You want to avoid blind spots while re-registering.

This would be NAPTR records. Anyway, I would not use it. When using the PBX NAPTR and SRV don't make too much sense anyway, because the PBX always uses a standard IP address for addressing. IMHO SIP is "overengineered" here.

The registrar sets the registration inverval. If the PBX trunk registers, is just makes a proposal for the registration time; the registrar (ITSP) finally makes the decision about the registration time.

Ehhhh, ... You mean in the web interface or on the phone?

Well at least in the CQDR you can see it and also the max MOS is defined by the codec. That means in the MOS image on the status screen you can see if there were calls with "low quality" codecs.