Vodia PBX

Can you copy your Linux config to another directory and the the redhat-image on this: http://www.pbxnsip.com/protect/pbxctrl-rhes4-3.0.0.2905.

You can try to put the attached file into the html directory. usr_status.htm

Hmm. Did you check the "generated" directory for files? You should see a directory with the name 0004f2060b0a, check out what files are in there. Maybe you need to iron the configuration of the phone again. I remember I had to do this a couple of times before things worked fine.

Is there a update.tgz in the /pbx directory? If yes, delete it. Maybe also rename the /etc/init.d/pbxnsip to something else.

If you can make it into your mailbox, there you can dial a star code (terminate it with the # sign).

2.1.9 is available. Upgrade makes sense if you have problems with T.38 and devices that are strict with the branches in the ACK header. Otherwise, there is no need to move to this version. Release Notes as usual under http://wiki.pbxnsip.com/index.php/Release_Notes.

Did you drop the firmware files in the tftp directory of the PBX? Also, is there at least one extension with a * in the MAC address (in the registrations tab)? Another common pitfall is that the PBX does not (by default) provision the password. Check the admin/settings/ports section on the password policy. You can check what has been generated in the directory "generated". There you should also be able to see if the password has been provisioned. Some more information at http://wiki.pbxnsip.com/index.php/Polycom.

I would kill 269 (bash with pbxnsip start)

Hmm. That more looks like a problem with the startup - maybe file system full or something going wrong with the firmware update? Maybe a problem with the watchdog timer? In any case, it is worth to try to SSH in and use the few seconds alive to kill the last bash process. That should hopefully stop the madness and give you time to look around what the problem is.

Okay, not beautiful, but it seems that you have an Extension name which is not numeric... Don't ask me why, but that is what is in the code! Can you pick a Extension that is a number? [*blush*]

Oh it seems you are using an old version of the PAC. This version had a bug with the parsing of the responses, and was not able to safely locate the attachments (sic!). Try this link: http://www.pbxnsip.com/pac/setup.exe, that should get you the latest and greatest.

The PBX could get into en endless (deadly) loop in 2.1.6, that's why we recommend to disable the camp on in this build. 2.1.8 fixes it.

Very strange. We need to keep this on the radar...

This is a long long discussion. IMHO everyone should follow RFC3325 and we are all set. Until then, all you can do is playing around with the different methods in the trunk and see what works best. But many ITSP today do not support sending redirected caller-ID (e.g. for a redirected call from an incoming trunk to the cell phone).

No, don't use that. The parking there has not much to do with the parking on the PBX. Better use the buttons package, there it should be working fine (see http://wiki.pbxnsip.com/index.php/Assigning_Buttons).

Hmm. We can send either Alert-Info or Call-Info header, I don't recall how the Cisco 7960 likes it. BTW what version are you running?

Is that call being redirected somewhere? Does the final transferred call show up in the CDR?

You can handle timeouts in IVR nodes: http://wiki.pbxnsip.com/index.php/IVR_Node (just updated). So - just enter a timeout value and use the pattern "!T!123!" in the DTMF Match List if you want to redirect the call to 123.

Hmm. Progress, but still I don't get it 100 %. When the PBX performs the T.38 switch over, it must choose another set of ports. That is because T.38 is "image", not "audio". That has also the consequence, that the ITSP must learn a new NAT binding for the T.38 ports. When the PBX learns the T.38 destination, it should write something like "Passthrough: Changing destination to ..." (Media, log level 8). Do you see something like that in the log? One little problem with T.38 is that there is no RTP header. That means the PBX will turn it's head around for any kind of junk hitting the port (if the transmission stalls for more that 100 ms). But I don't think that this is the problem here.

Did you set up a button group for the extension that your register with?

Can Metropolis show information like waiting time and that this call was a ACD call? How should it look like?

The bind() message should not be the problem (we already took it out in a later build). The PBX just tries to get a port, and if that port is not available, it tries another one. Of course, make sure that you have a large RTP port range, so that you are not running out of RTP ports. I still don't clearly understand what makes the difference between the failed call and the successful call. Do you say that is depends on what port it chooses? If that is the case, can you double-check the firewall port range? Other potential reasons for such behavior are usually race conditions, e.g. the answer comes earlier or later. Is there anything in this direction?

Hmm. Maybe you can call the mailbox or some other IVR which has "digital" audio quality (e.g. the conference room without anyone in it). If the problem persists, then maybe there is some parameter on the conference phone wrong? Maybe the echo of the room generates a loop or something like that.

You really should get them every day. We do get them every day (and it has become a valuable morning lecture for me). In the beginning they were often classified as SPAM, but once that we told the email system it is not SPAM it works quiet stable.

Well, there are two things. First, there are two places for settings the SMTP server. One is on admin level, and there is another one on domain level. The other thing is that once that emails are being put into the spool directory, the email server is fixed. That means, you might have to manually delete the emails from the spool directory to get them out of the system.