Vodia PBX

That is scheduled for the next major release--make it possible to customize everything per domain and extension. But in V4 we did not include this any more.

The latest & greatest should fix it. At least we found a bug that makes it difficult to transfer to another account...

Really a good question... The question is what we want to achieve with the call recording. Supervising a person (then we would have to record if the picking up extension has recording set) or supervising an extension/function (then we would have to record the original destination). I would lean to the latter. Supervising persons is something for the police; I think we are more function oriented. For this approach also speaks that we want to continue with the recording after a transfer.

This issue should be fixed now in the latest V4 4.0.1.3440 or higher.

Well, I think overall this is a problem with the firewall... I guess the registration that the PBX gets from the service provider is valid for something like an hour. Then the PBX will attempt to register after 30 minutes, meaning that you have 30 - 8 = 22 minutes no coverage. Actually many service providers try to keep the connection alive by sending traffic from their SBC to the PBX. The problem with that is that some firewalls don't accept outside traffic as keep-alive traffic. Maybe you ran into such a combination here. It works better with the phones because the PBX registers the phones for a relatively short time.

We also had that idea... The problem is that it is not so easy to perform such a restart. Restarting the whole system is easier, in Linux as well as Windows. The only thing that we could do is just terminate the PBX process and hope that some external service manager will automatically restart it eventually. But I am not sure if we are creating trouble tickets with that and potentially even serious problems of people shutting critical services down on purpose.

Ouch. See why I have a problem with firewalls?

Yea, we could skip more than 2000 major release versions! Marketing departments would take man-years for such a suggestion...

You mean in the web interface? That sounds like trouble with the JavaScript that tries to verify if the user input makes sense. But AFAIK the feature itself has not been removed.

We had that problem in some early beta versions, but should be fixed now... Do you still have some old files in the HTML folder? Or do you have JavaScript disabled? The web page needs Javascript for this job, because we want to verify if both fields are the same and only populate it when they are.

Is that really a good idea? It will make the parsing more difficult. We could link it to the time zone for the domain--or do we have to add a new setting for the domain telling weather to use 12 or 24 h format...

I remember we had this problem before, not sure if there is a post in the Polycom section (will try to find it later). There is actually a setting on the Polycom for that. Some kind of alert tone definition for BLF. The default is to actually make some noise which confuses a lot of people.

You might really have an endless loop. Or at least a lot of redirections. There is a settings in the pbx.xml file called "max_loop" which you might want to increase. It is not directly accessible from the web interface, you might have to edit it in the file itself (restart required unless you do a trick through the web browser).

Check this out: http://pbxnsipsupport.com/index.php?_m=kno...kbarticleid=393 That might do the job for you or at least tell you how to build something in PHP for you.

Take a look at the ANI for the extension. That might already do the job for you.

It is general problem when the media starts with 200 Ok that it takes some time to establish the session. This is the reaon why the PBX always (well almost always) uses 183 with SDP to establish the media channel ASAP. However, many SIP devices don't do it this way. I would say all VoIP phones don't send media while ringing. But usually that should be no problem. The other thing that you can check is if there is a firewall in between. These things are always a source for trouble of this kind. In the end, only a Wireshark trace will tell you what the problem is.

Well, there are a few messages that should not be there ("Writing to row that does not exist, ignoring request"). Can you attach a screenshot of the IVR node settings? Are you using SOAP? This is a beta and the IVR node did not get too much attention yet, so it could be that there is still something buggy...

Would getting a flatrate solve the problems? There are many ITSP that offer flatrates within the US.

You first have to establish a voice session, then you can turn video on. That's the way it is in 4.0.

Is that a trunk that is either inbound or inbound/outbound? When you are using the outbound proxy and don't use the field "Explicitly list addresses for inbound traffic" then the transport layer does matter. The best would be if you put "127.0.0.1" into the "Explicitly list addresses for inbound traffic" setting of the trunk and make it "inbound". Of course, use 127.0.0.1 only of the packet is actually received over the loopback device. Maybe just add the IP address of the server there as well, e.g. "127.0.0.1 10.1.1.110" if "10.1.1.110" if the IP address of the PBX which is used for sending the request out. If you are using a SIP proxy, put the address of the SIP proxy there. Whereever the looped request is coming from"

How did it send the CDR? By email? or SOAP?

We plan to make it editable in the next major release. For version 4, you could put it into the html directory and restart the service.

The PBX gets the timezones from its own file. Using the OS does not really help, it will essentially just the time in the current time zone. Linux has a kind of database for this, but that does not help you if you want to offer the same service in Windows. Plus every phone wants it in a different way. So we started our own little timezone collection. At least it is stored in a XML file and changes are easy.

Yes, you are right! Maybe this is another way of blocking the caller-ID? I remember from FXO that this was done in a similar way. Maybe we should embrace this and make it a way of indicating anonymous calls. Are there other feature codes that should be passed on call-by-call basis?

You will definitevely see it in the CDR which are sent out by the PBX. The simple reason why we don't show it is because we usually got a line break in the list of the calls, which make it hard to read.