Vodia PBX

Technically that is a problem of the phone now. The "dial plan" of the PBX has nothing to do with that. So the first source is to check the phone vendor documentation. For a few phones, the PBX automatically generates a phone dial plan (e.g. snom). The generation of this plan depends on the domains "Default PnP Dialplan Scheme". "User must press enter" means that there is no dialplan for the phone, the North America (NANPA) styles generate a dial plan for internal calls and eleven-digit calls.

You probably selected a dial plan scheme for the domain and then provisioned the phone through the PBX. Select "user must press enter" as scheme and reboot the phone. The other thing is that you don't have to dial 7100, you probably should just try 8100. Then the PBX will realize the call should go to the mailbox, and then it says "hey there is a redirection to 7xxx" for the mailbox. The point here is that the PBX includes a redirection header in SIP that Exchange needs to work properly. No don't rollback, the latest and greatest has the best support for Exchange.

5000? That sounds like a really huge family to me. Anyway, then lets say we accept up to four digits.

That really sounds like a lucky number! And a few important bugs have been fixed. Check out the downloads at http://www.pbxnsip.com/software.

Give http://www.pbxnsip.com/download/pbxctrl-centos5-3.0.0.2991 a shot!

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.