Vodia PBX

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.

Try http://192.168.32.30/provisioning/spa_phone_$MA.cfg. Then the HTTP server knows that this file is for PnP.

The builds for CS410 that are younger than one month have it. Documentation is still on 2.1.

Hmm. Maybe better forget about TFTP... Check out the attached files (you can also put them into the html directory, if it does not exist yet create it). There it says you should out http://192.168.1.2//spa$MA.cfg (if 192.168.1.2 is a PBX IP address) into the Profile Rule. I assume you have put a MAC address or just a star into one of your extensions? There is some general information at http://wiki.pbxnsip.com/index.php/Prepare_...r_Plug_and_Play. spa_1st.txt spa_phone.txt

Maybe the workaround is to stick to the "conference" string for clear identification it was a conference call. In 2.1.11 we'll change the type to 'v' because 't' was supposed to give the To-header. The extension is empty because the call does not go to a registered extension.

Just put the IP address in... Then the phone will automatically choose TFTP. The setting is called "Allow TFTP Password" - just set it to "always", then later when everything works you can lock this down.

Just point the tftp server to the PBX. It should work already... Also make sure that you do provision the passwords (Admin/Ports/TFTP). The problem is here that Linksys requires their own little secret algorithm for encrypting config files, which they won't gibt to use (the secret, not the program ). Also, it helps if you are using Option 66 on DHCP.

Check out http://www.dslreports.com/forum/r20408090-...wn-Since-Sunday, maybe the free service is just not available...