Vodia PBX

Did you already check the Wiki? http://wiki.pbxnsip.com/index.php/Troubles..._Trunk_Problems

Cool

Well you still have the option to configure the device manually. And apart from that I would put the files that the phone downloads directly into the tftp directory. According to the above procedure that should send the neccessary information directly to the phone.

Whow that seems to be a common problem these days... Did you see http://forum.pbxnsip.com/index.php?showtopic=714 ?

The problem with 80xx is that it would put the whole xxxx number into the replacement. \1@.city1.domain.com seems to be buggy, there is a dot after the @ that seems to be incorrect to me. If you have only one domain on a PBX (which is good!) then I would always use the name localhost, at least in the alias list of names.

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?