Vodia PBX

Copy a file from generated/{MAC}/file to tftp/file. The {MAC} should go away, so that the file is directly in the tftp directory.

Well, we need at least one file with the MAC address in it. Otherwise it is really difficult to find out what account should be used for the device...

Well, you can't do that through the web interface. But you can take the files out of the "generated/{MAC}" directory and put them into the "tftp" directory and edit them there.

IMHO it should be a clear improvement.

Ehh - somehow the provisioning file got lost (we don't even find it any more...). Would be great if you can give us access to the file that you have ...

As long as there is no overlap with an internal extension than that should be possible. For example, use the pattern "1xx" in the dialplan if you want to route 3-digit numbers starting with "1" to a specific trunk.

I would try to upgrade to version 2933 (http://www.pbxnsip.com/cs410/update-2933.tgz). The version that you are using has a bug in the setting of the gain (it sets some other gain that actually can easily cause distortion). Also, you should check the phones audio level again. Usually, users increase the volume of their phone when the gain is too low, and after changing the gain back to normal the phones are too lound and generate echo.

Well, well. The service manager has its own ways... I remember uninstalling in 1.5 required not only one reboots, but a couple of them. Plus manually editing the registry. But I must say, I also don't have much experience uninstalling it . "In theory" it should work automatically by the installation tool. But at least you can be sure it is not being started by accident and blocking ports 5060 & 5061.

Well, global names of course have a special meaning in restoring domains. If there is already another tel:alias with the same name, we are in trouble. But it seems that all alias names are not restored. Looking into this right now.

This is only important in environments with multiple CPU cores. If you have several cores, it means that the OS might shift the PBX process around between the CPUs - every shift meaning that during that time, there is no RTP. We had cases where this meant a lot of jitter and playout problems. I assume you are using Linux?

The presence of a DID number tells the FXO driver that this line should be tried for outgoing calls. And you can also use the DID number to perform inbound routing based on the DID. That problem should be solved by settings the busy tone detection. I think there some other posts on this topic - is it stipp open?

Yes. That is actually the reason why there are two ports. In contrast to other products in the market, the PBX can deal with many IP addresses. You don't have to worry about the RTP flow and the address translations. One common problem is the default gateway - you must make sure that you have only one. When you get the IP address by DHCP on LAN and WAN, then usually you have two default gateways and that screws things up in Linux. Therefore on the latest and greatest we put some JavaScript in the web interface that presents a warning in the dangerous cases.

Good question... I think that tone 1 and tone 2 apply to the busy tone, and that the dial tone is always continuous (we need to verify that). That is because there is a seperate flag for dialtone. I would suggest turning only busy tone detection on, set the tone 1 on/off correctly and give it a try. Then if that does not work turn dial tone detection on as well.

That should have been fixed in 2.1.3 (see http://wiki.pbxnsip.com/index.php/Release_Notes_2.1.3). What version are you on?

Go to System/PSTN Gateway. There you find settings for Tone 1 (Busy) and Tone 2 (Dialtone). Check if the dial tone settings there match the local behavior in Kuwait. Usually it should be enough to turn Busy tone detection on. After saving, you need to restart the system.

Well, the PBX is just running the standard dhclient3 that comes with the debian distribution. If you can can, try to use a Ethernet hub (or do port mirroring on a managed Ethernet switch) and get a Wireshark trace. Then we can see what is the problem...

I was talking about dialling the flag. You can set the restrictions in the web interface. Maybe just set up a flag with a 5-minute service duration and try things out...

That can be done. The FXO gateway has four DID numbers that will be in the To-Header that identify the line being used. You can use the rule in http://wiki.pbxnsip.com/index.php/Inbound_Calls_on_Trunk to route the inbound call then.

The PBX just accepts manual state changes also for automatic flags. Then when the automatic transition kicks in, it keeps the state if the desired state is already present. In other words: If the secretary shows up early in the morning before the flag is actually active, she can dial the flag number and then the day mode is on already. Later when the automatic flag change would fire, the flag stays where it is. Things are a little bit more complicated in the evening. If she decides to stay later, she has to wait until the flag goes to night mode, then dial the number to change it back to day mode. Before she goes home, she needs to set the flag to night mode manually again.

What did you put in there? Just one extension?

You got any SIP traffic for the update that does not work?

I tend to agree. Plus an attended transfer into a conference that has a PIN really makes sense. You can call an external party, then dial into the conference and perform the attended transfer into the conference. I guess we have to put this on the feature list.

Well, if you have something working now you can start doing your own changes. Now you can take the SPA documentation and drill deeper from there.

The "SIP/2.0 500 Internal Server Error" is for the NOTIFY and usually it has to do with subscriptions that are still in the server but already expired on the phone. After a reboot this is normal if the phone comes up within the subscription duration and there is no reason for concern. The reason why the call gets rejected is "SIP/2.0 488 Not Acceptable Here". In the INVITE you can see that the PBX obviously does not offer any codec to the phone, which makes that understandable. Check your codec settings for the system, it seems the problem is there.

So far there was no need to have attended transfer into a mailbox. Are you sure those phones don't have blind transfer any more (check the more button)? I can't imagine Cisco took such a basic feature out. Workaround would be to use the *77 transfer code, but that would make the phones really look extremly basic.