Vodia PBX

Eh? It is "read" right now. Not sure if "read-only" is the right way to say it.

G.723 is not supported by pbxnsip. This codec is not worth it in a PBX environment: Bad audio quality (well, what can you expect from 5.3 kbit/s?) High CPU load (big problem for central network equipment that does support MoH and call barge in, recording) Show-stopper license terms (lots of patents, unclear situation who will take us to court us if we support it) And don't forget that 5.3 kbit/s does not mean that a RTP session takes 5.3 kbit/s. The RTP packet overhead is somewhere in the 12-24 kbit/s area, depending on the packet size. Yepp, that's 3 times higher than the compressed audio information itself. Making G.723 even more pointless.

I would try turning polarity detection off and busy tone detection off. There must be something that makes the FXO subsystem believe the call is disconnected.

Well in the previous version the thread that did the SIP processing also assembled the email including the WAV. Because that WAV has to be base64-encoded, this could take some time. That is why we did not send long WAV files. Now the picture changed. Because there is the email thread which can work on this for minutes there is practically no more limit for the length for WAV files and sending out the recording of a two-hour conference becomes an option.

Unfortunately, no. But what we can see is that the PBX does disconnect the call (sending BYE, not receiving). We added a log message for the *9 disconnect. Maybe that is easier than trying to figure out what the problem was. What OS are you on and what version? Maybe you can try a build that includes the log message and we figure it out.

What OS are you on? Maybe want to try it out?

I V2 I would not recommend to play with IP tables. The PBX uses /proc/route to figure out what it's IP address is when sending requests out and iptables can very easily screw that up. In V3 it is a little bit more relaxed, because the PBX asks the OS for the routing tables through a system call. And as in general with iptables, you really really really have to know what you are doing here. This stuff is not for beginners.

Well we proposed a MIB, but nobody responded - http://forum.pbxnsip.com/index.php?showtopic=112.

I am really thinking if we need to change the busy tone detection strategy. As with DTMF, maybe we cannot rely on the PSTN gateway to perform this job. And the PBX has one benefit - it knows when a real user is taking to the PBX and in that case it can leave it up to the extension to disconnect the call. Otherwise if the call is connected to say the auto attendant, it is clear that a busy tone is no valid input and a clear signal to disconnect the call. Just thinking. Any opinions out there?

Just put in a administrator PIN in there that the user does not know and choose a HTTP password that the user does not know. Then accessing the phones should be pretty difficult.

One that we finally release 3.0 we'll also get the CS410 image out.

Maybe your browser has a problem with WAV files? Maybe just try to "save as" to the PC and play it from there?

Well, you can record all calls (that's a domain setting) and then later decide which of them you want to throw away. The big question is how to tell the PBX, so that the selection process can be done automatically.

Well, you probably have a problem with the keep-alive. The PBX expects that the client closes the connection. That is standard HTTP stuff, and there is a lot of information in the search engine of your choice. curl is not a must. You can use anything that behaves like a HTTP client.

For us, it would be very useful to see a working example on how the PBX writes a CDR to the CRM. Then we can relatively easily add this to the PBX.

No, that's the way it should work. Do you have a conference wav file in the recordings directory? How large is it?

Make sure that you are using the latest build which includes the settings for impendance and the tone timers (should be at least update-2987.tgz). Also, not every carrier has the same settings.

That is included in the 3.0 build.

Try using ^9(.*), then the match will start at the beginning.

Hmm. At the moment not. But it makes sense. What about this: If you press star when the input is empty, than that star is being used. Condition for this is that the number is only two digits, so that you can dial *12. But if the input gets longer than two digits, the first star is removed again. This is to make it possible to press the star symbol twice to reset the input no matter where you are. We would put that into 3.0.

You can let the PBX send out an email when the trunk registration status changes. This way we reminded our ITSP that the service was not available for five minutes at 3 AM... Pretty impressive.

Yea, we made some progress... The emails with WAV attachments are now assembled in the (low prio) email thread. That makes it possible to send out pretty long recordings as well, so that we can start dreaming about sending out every conversation recording out by email and get if off the file system.

When I hear dropped calls in a conference three things come to my mind: 1. Does the moderator press *9? That would actually be a feature. 2. Are those who are disconected speaking from time to time? Or could the PBX think that they are dropped out already. 3. What about the CPU load? Could it be that the system is running out of juice?

Your wish has been fulfilled. It is included in the next 3.0 release. Though it is sooo flexible the documentation will not be easy. And the account index shows the real account names now. No more searching for accounts.

In SuSE10 if you install the service the firewall will block everything by default. Maybe RedHat now does the same. The crazy thing is that you see the packets in wireshark, but the firewall won't forward them the the PBX. It took us days to figure that out. This is not a PBX-specific problem. There must be something about this problem in the RedHat documentation.