Vodia PBX

Okay, personal firewall is off. That means there must be a packet going out of the computer (even if it is virtual). You should be able to capture the traffic with Wireshark, the TSP sends regular SIP traffic out. You must definitevely see SUBSCRIBE packets, that feature of the TSP was working from day 1.

We had a few examples on the old Wiki (now kiwi.pbxnsip.com). Maybe it is woth adding a few more there.

Usually when it gets very slow, this is a sign that there is something going on with the box that takes a lot of CPU resources. It could be that the web server gets stressed (for example, someone trying automatically to log on all the time; we had such a case) or something internal like the file system gets fully and the kernel needs to collect the empty pieces on the Flash. The CS410 is a very small system, it easily gets to its limits.

Divide and conquer is always a good idea to solve a problem... Did you try something crazy high? For example, 1000? Then we can be sure that the counter is not the problem. Also, for safety restart the PBX service after chenging the value, maybe there was something going wrong with the writing of the setting into the system. And please verify the settings makes it into the pbx.xml file.

Yea I like helpers because they are not so critical regarding stability. Actually we already have seen such a helper running on PERL I believe, if you can run that you could be "all set" already (need to PM me because I need to establish the contact).

First, the PBX receives a redirection request: And then: According to SIP, the server should return only one response. The second response confuses the PBX. It is probably because the two call legs must have the same Call-ID (otherwise Exchange would not accept it). This is causing the confusion. We probably need to make sure that we ignore reponses that are outdated looking at the CSEQ number. Do you see this in the log? "Response does not correspond to open request" should be on log level 8. If you see it we can try to drop the response in this case and ignore it.

Well, there were still a couple if issues open... For example, if the TCP connection breaks for whatever reason, the PBX did not restart the connection. Then the authentication part was a mess. If you want to talk to mySQL, you probably have only very little choice but to use their library. It might also be a license issue (even if it is open source it does not mean you can do whatever you like with it). The biggest problem remains that people are coming and say they want support for the other databases as well (SQLServer, Oracle, ...) and then we still have to start from scratch. And the other problem is that the libraries that are available for talking to those DB are writting for temporary usage. That means the process start sup, works for a few seconds, then the OS cleans everything up again. The PBX has to work for potentially years without the OS cleaning up. Linking libraries into the PBX executable will make that very difficult, and therefore IMHO it is better to keep it outside where it can do no harm.

We also saw that. Seems that waiting just for one seconds is not enough any more. I now usually wait one minute. I still believe that is is progress if we can be sure there is no other process (not even another pbxnsip executable) running on the same socket. Question is how do we tell the OS that we dont want to use the socket any more? Ideally, there would be something that we can call from the shell that cleans up the dangling socket.

Check this out: http://forum.pbxnsip.com/index.php?showtopic=658

In order to avoid endless loops the PBX needs to count how many times a call has been redirected. The global variable (see pbx.xml) with the name "max_loop" does that. The default is 10, you probably need to set it to a higher value here. See https://www.pbxnsipsupport.com/index.php?_m...kbarticleid=413 on how to set a global parameter from the web interface.

What is the value for max_call_duration in the pbx.xml (global configuragion) file after hitting the save button?

Yea, we changed the way the PBX binds to the port. In 4, it requires that no other application is listening on port 80. Same for 443, 5060 and 5061 (or cource, the numbers can be changed in the settings). This is because sharing the port with another application results in absolutely unpredictable behavior ("Voodo"). You can start the application with "--no-check-ports", then it will start up no matter if it can bind to the port or not.

Probably it is not SRTCP, it is just RTCP. It is not very critical as long as you dont need the RTCP statistics. A software upgrade of the phones should fix the problem (consider the pro and cons of a upgrade).

Well, the jitter might come from allocating the 7 MB; not from reading hte file (that happens in the background). Usually, the jitter should be pretty small. Especially on a PC. A embedded platform with 128 MB and no swap space might be more jitter to the level you can notice.

Anyway, we'll change the behavior so that empty passwords will not be accepted any more. The thread is just so big, it is not worth it.

You can use email2db to get this done today. I am sure there are other tools out there that also support IMAP and can feed stuff into the database, especially in Linux where scripting is bread and butter business!

So I tried it here on Windows 7 with the latest version of the PBX. "Works for me"... Do you have a personal firewall on the system that could mess things up?

Also check the settings for the Windows firewall. Maybe it is allowed to accept connections, but not allowed to connect to the outside world. Also, sometimes the virus scanner puts itself into the loop and fishes out the email traffic. Try to disable the scanner for a minute and see if that does any change.

It seems something got broken. It also does not work here. We have to investigate and fix it.

No it should be okay to check out the LOG. But turn the logging of the SIP messages on.

Maybe try Outlook first. The way the applications use TAPI might differ. If Outlook does not work, then we have a problem. Also, only outbound calls are supported with TAPI. Inbound calls were supposed to come later, but then CSTA entered the scene as a replacement technology.

Check out http://www.wireshark.org.

Do you see the TAPI registration in the registration tab of the extension? The type must be something like x-tapi. If not, then there is a problem with the subscription to the PBX. Maybe just something like a wrong password or wrong address for the PBX.

There must be something wrong with the ports or the accepting of connections. Maybe quickly run Wireshark and see what is going on.

I think that is the problem. Where does the 487 come from? Maybe there is a problem with the Call-ID, it could be that the redirected call is using the same Call-ID as the original call and then the PBX has problems matching the response to the right request. A SIP trace will show this.