Vodia PBX

Well, first of all, set the log level to 9 and then you see what ERE the system is generating from the dial plan. That makes things usually much easier. When doing ERE, please remember that the pbx must match a string like user@domain, not just the user part. That means a ERE like "50([0-9]{2})" is not complete, you need something like "50([0-9]{2})@.*". Using 50xx might be a problem because then you will reference the whole match in the replacement. If you can use 50* (variable length) then things are simple.

You mean you expect the reverse logic? The service flag should have a function like "office hours", that means you specify when the cell should to be included in the call. That means if you say e.g. 9AM-6PM then you will hear the cell phone ringing. IMHO most people would like to specify when they are available on the cell phone. Our first experience was that we got calls at 3 AM in the night on the cell phone, and it became clear that we need to specify the operation hours when redirection should be allowed.

2.0.3.1715 was a great release. Yes, we are running 2.1.6.2448 in several locations in real life. For us it works, of course. But that is not the problem. We created a 2.2 branch for new features. 2.1 will be only used for fixes to make sure that we have a sock-solid build again. We did run millions of calls through the 2.1 branch, but the environment is not changing much during the tests. The real life is different, and we will see in the next couple of days and weeks if there is anything else that we need to address.

I would then switch to SuSE10. The Wiki should point you to the most important things, but it does not replace a substantial know-how about Linux and SuSE. If you are not familiar with Linux, then consider moving to Windows Web Edition. It is surprisingly affordable!

You mean after hanging up the PBX shows that there is a call going on? Is that in the light on the CS410 (front panel) or on the phone? If the call is disconnected, the PSTN should just remain in idle state. Maybe there is something strange happening after hangup, maybe the 2400 sends some additional information after hanging up?

2448 fixes a license problem that occurred with the 2446 version. 2448 is available as tgz that you can apply from the web interface on the cs410. So I would say this is the best and easiest version for the cs410.

We were thinking if we should start another project that plays MP3 files and convers them to linear, then streams then via RTP to a local MoH port. But maybe it makes sense to search if such a project already exists and just properly document how to use it. Unfortunately, MP3 players seem to assume they run for a few hours maximum, so they don't have to take care about memory leaks.

Dirty workaround... Lets take it as temporary solution. Maybe later we come up with a nice idea that does solve this problem automatically - without side effects that we don't want.

Well if the PBX receives a RFC2833 packet and is not already in a RFC2833 stream, well then it assumes the key has been pressed. It does not care that another system already chopped off the first part. No, the call should first go the the IVR node and just don't do anything (no not react to DTMF at all). Then after 1 second or so the call gets redirected into the "real" auto attendant.

Okay, the PBX does it for following way. Chapter A: TFTP 1. When using TFTP, the PBX first checks if the requested file is available in the tftp directory. It it exists, then it sends it out. 2. If the file matches a regular expression in the pnp.xml file, it will send the file referenced in the pnp.xml file from the html directory. Chapter B: HTTP 1. If the requested file is starting with "tftp", then the PBX checks if that file exists and it that is the case it sends it. This is similar like step A.1, but the filename must contain "tftp". 2. If the requested file is starting with "provisioning", then the PBX takes the rest of the filename and matches it against the regular expressions in the pnp.xml file. If there is a match, it will send the file referenced in the pnp.xml file from the html directory - just like in A.2 for tftp.

It does not matter if you do T.38 or video - for the PBX it is all the same "transparent" data running through the PBX. The important limitation (at least , today) is that first you need to have a regular audio session before you can re-negotiate the session.

So you mean the problem is that the call gets redirected and because everything goes so fast, the tone is still active and when the call arrives at the other system, the system hears the ongoing DTMF and says "whow this guy is quick" and collects the first digit already? A quick and dirty workaround could be to use a IVR node, put one second of silence there and redirect the call after the timeout to the auto attendant.

Did you use one trunk for the four lines? If you change the trunk after the buttons, then you should press save on the buttons again. There are internal references that point to the account, and it can get screwed up if you change something afterwards.

If you use the buttons, then you can put the agent login/logout on one of the LED buttons and then the LED will show if the agent is logged in or logged out. See http://wiki.pbxnsip.com/index.php/Assigning_Buttons for more information.

That combination probably does not work. I would suggest to turn SRTP off or to move to 7.1.30 and version 2.

Is the registration stable? Maybe turn on email logging for registrations, just to see if the phone becomes unavailable from time to time. The other guess would be SRTP. Maybe turn it off on that specific phone just to see if that could be the problem.

Oh oh. You are right, here comes the fix: http://www.pbxnsip.com/download/pbx2.1.6.2447.exe (complete InstallShield) http://www.pbxnsip.com/download/pbxctrl-2.1.6.2447.exe (bare executable) http://www.pbxnsip.com/download/pbxctrl-cs410-2.1.6.24467 (CS410) http://www.pbxnsip.com/download/pbxctrl-debian4.0-2.1.6.2447 (Debian 4.0) http://www.pbxnsip.com/download/pbxctrl-rhes4-2.1.6.2447 (Redhat ES4) http://www.pbxnsip.com/download/pbxctrl-suse10-2.1.6.2447 (SuSE10)

Well you would have to list the extensions or other accounts that should send the daily CDR to the admin. It would essentially be the same email as the daily email CDR, but filtered for that account. That means if you put "123 124 125" in the list, that admin will receive three more emails at night with the CDR where 123 124 and 125 were involved in calls.

The problem is that every vendor does it differently. That's why we want to deal with this by having a XML file (no C++!). Office phones are not like cell phones, where every phone needs to have a "personal touch" (crying monkeys, screaming animals, etc), so usually users are already happy if they can tell by the tone if the call is directly to the extension of part of a group call.

Okay, would it solve the problem to introduce a settings that contains a list of the extensions that should be reported? E.g. "101 102 103 119" would send the daily CDR for those 4 accounts?

The latest version at least has the option to include the FXO gateway log in the PBX log. Maybe it makes sense to write those messages also to the file system (embedded system, so be careful!), they should include FXO messages.

There are two ways to detect hangup. Impedance change (which seems to be used in the USA) and polarity change. Detecting the first is easy, the second is detected when the first time there is a polarity change. There is no setting (neccessary) for that. Unfortunately, in the analog world, things are sometimes instable. In our office, we have had Verizon lines which must have been very very long. After switching to Comcast "Digital" (which is also FXO, but only a few feet long) things looked much better and there was no more problem with DTMF, hangup and so on.

If you use plug and play, then the PBX will provision a action URL that retrieves the address book in XML when you press the address book button.

On the CS410, we have the nice problem that the input is analog - that means in addition to the DTMF tone, we have a reduced signal and added noise. That makes DTMF detection not easier. Maybe try 1024 and 2048... The error rate will probably also increase. I guess you can imagine that I am not a big fan of analog lines... Especially if they are long!

I get one email per call now, that does the job for me. Outlook does the job or sorting the emails into the right folder. The beauty of this solution is that is always up-to-date (no need to wait until midnight) and it is very easy for the PBX (no huge emails at midnight).