Vodia PBX

It is a regular version, no feature excluded. The limitatons are the memory, for example call recording will be difficult. But the good news is that it comes with a great PSTN gateway.

We try to make only bugfixes in the 2.1 branch. New features (even if some people don't like it) go to the head branch (we will probably call it 3.0 then).

Probably the Cisco did not like the http in the alert info. Can you give the attached ringback.xml a try? You need to restart the service for that or load it through the special web interface page (Reload Configuration Files in admin/configuration). ringtones.xml

Oh, but there is a setting for the VLAN in the PnP settings (admin/settings). Maybe you just need to specify the VLAN there.

Okay, that makes sense, but then maybe the solution would be to have some kind of timeout with the callback (e.g. one hour).

Whow you mean it could be that the WAN is still on DHCP while the startup script is already running and the watchdog timer kicks in?

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.