Vodia PBX

Yes, if you want try 3.3.1.3173 (builds are available in the download directory, but not linked yet). There will be another build coming out as we still found some issues in the recording area.

Hmm. The log looks okay. Does that behavior change if you are using another phone? Maybe there is a interop problem on RFC2833/4733 level. Can you turn out of band off on the phone? Then we can check if at least inband works.

We need to take a look at the new Aastra firmware version. It seems so many things have changed, probably not all of it works exactly the same way like before.

What does your dial plan look like?! Too many entries are not good anyway... Check out the regular expressions, they can make your life easier. Also, did you try the prefix? If there is no trunk ANI and also no extension ANI, the PBX will put the prefix in front of the user name. For example, if you are calling from username 123 and the prefix is 123456, then the PBX will make 123456123 out of it.

I would use SNMP to check if the service is still up and responsive. For Linux, we have written a script that takes care about failover, especially hardware failover. It periodically checks if the service is still there and restarts it if that should not be the case (in Windows, that's the job of the service manager). In Windows, we would need to have a little script that checks after booting up if the virtual IP is configured and if not, grab it and start the service. Probably also no rocket science.

SIP trunks are great! They treat signalling seperate from the audio, and the other side does not have to guess what the call state is. There are some carriers sending "Your call has been disconnected. Please hang up... Your call has been disconnected. Please hang up... Your call has been disconnected. Please hang up...". How would the PBX know that it should hang up? No kidding.

Hmm. During the login session we are allowing certain extensions to be loaded ("jpg css gif js"). "ico" was not on that list. I guess that was the mistake. We add that to the list, next version will have it.

Are you sure the calls are running in that domain? Maybe be accident they are happening in another domain. Do you see the calls in the active calls in the web interface?

What is the current time on the server? The web page itself does not re-load automatically. You need to load the page again.

It is part of the "PSTN" trunk in the domain. The PBX tone detection is automatic, just looks for a beep beep beep pattern, then disconnects.

Lets put it this way: in manual mode it is clear what is going to happen. The problem with the mix of manual and automatic is that nobody understands what exactly is going on. Maybe you can combine two flags (or more). For example, one manual and another one automatic. Check the manual flag first, otherwise then check the automatic. This way you have additional flexibility, and it is still understandable. See http://wiki.pbxnsip.com/index.php/Auto_Att...t#Night_Service on how multiple service flags can be mixed.

Check if the flag is in manual mode. The sounds are not very convincing (will be better in the next version), the beep is currently the way to tell if the flag is active or inactive. There are actually two beeps, check the audio_moh directory.

I would turn polarity change off, this is usually just an unneccessary source of problems. So you mean, when the call comes in on FXO, the PBX calls an extension, but when you hang up on the FXO side, the call keeps ringing? Do you have "Requires busy tone detection" set to "yes" in the PSTN trunk in the domain? Looks like the carrier sends a busy tone, but the PBX does not recognize it.

Ehhh that is true. Did you try something like this in the dial plan replacement: sip:1234\1@\r;user=phone;other-arg=lalala The "\1" is the match from the pattern, the \r is the domain name. This will go into the Request-URI of the request. Is that okay? The To-Header should usually not be used for routing purposes according to the SIP RFC.

You can put your own into the html directory (call it "favicon.ico"). But beware - the browser stays with the old one, even if you press F5. At least IE seems to keep it for a long long time.

Oh, did you check out ICID (RFC 3455)? This is a simple method of tagging the request for outbound calls so that the upstream provider can tell where the call came from. The prefix could also be a way for you. However, you must use ANI. However, I would rather use common prefix in the ANI to have the same effect. Like the "area code" in the DID number.

The problem is this line: It means the PBX sends the Re-INVITE to the gateway (repeatedly), but does not receive any response. The gateway should send anything, even if it does not like the Re-INVITE. Do you see something in the log of the gateway? Maybe it tries to send something, but to another address (not the PBX)? Maybe there is a newer version available. It could be the gateway does not like the port 0 in the SDP (the PBX just relays that information).

No. Let us check what is the problem.

Should be possible. When you call from a cell phone into an auto attendant, you should have the option to make an internal call - which can also be a service flag. I am not 100 % sure if it will work (did not try it out), but that is worth a try. If you are not calling from a cell phone (just any inbound call), you could send the call to a calling card account, from which you can make an internal call. Same story.

Makes sense. Even the transfer could be possible, as soon as the called party presses 3 the call forking can stop and the PBX patiently waits until the extension has been entered. Will be a 4.0 version feature, though!

If you can register the trunk then inbound trunk identification is very easy for the PBX. It just uses the "line" parameter with a trunk identifier in it. If not things indeed get tricky. Of course the IP address of the PBX is a very poor indicator where the call should go. We found that using a DID number is the most natural way of finding out where the call should go. This is something that almost everybody understands "naturally", as it reflects the way people are calling resources in the telephone world. Even if it is a dummy DID (which cannot called from old grandma's phone) it still serves its purpose (note that there are more telephone numbers in North America than IP addresses in the world!). By adding the "ANI" for outbound presentation, and by having the telephone number as alias name of the account for inbound search, this is a easy way to do inbound and outbound mapping. You can even setup a global trunk that takes care about sending the call into the right domain. In 3.3 we also added the possibility to have a global dial plan - which makes it more convenient to set up complex dial plans only once.

The PBX does not support that. We leave that job to the PSTN gateway, some of them support two-stage dialling.

If the other side uses only G.729 without and out of band DTMF (RFC2833/4733), DTMF is not possible as G.729 distorts the tones, so that the detection becomes impossible.

Talk to sales of pbxnsip, chances are you get a replacement with a black box.

In 3.3, there is a change in the way you need to provision snom phones. The new link must be in the form http://ip:port/provisioning/snom300.htm (where the snom300 needs to be replaced with the actual phone model). We'll update the Wiki as soon as 3.3 is publically available.