Vodia PBX

Oh. In theory they should be the same. In 2.1 there is more logging, but that should not have any side effects.

Now we have "follow what has been set in the list of agents" and least recent. Ringall can be done by increasing the number of agents called in one cycle.

It is already fixed in head, possibly we can port it back into 2.1.8.

That is a tricky topic. Of course the intention was to keep the CS410 on the same path as all other software - but we simply have the problem that we need the settings for CPC duration, polarity change and busy detection which does not exist in 2.1. There are no "dangerous" changes in the 3.0 version yet, IMHO so far is it safe to use it. The release notes include everything between 2.1.6 and 2.1.7.

I think if the device is not registered it does not consider redirect after timeout. Then only the "redirect all" applies. Not very satisfying... But redirect after timeout is also not the answer. Maybe redirect on busy would be a solution in this case.

Hmm. If you use the auto attendant, you can block certain extensions (typically executive). On the trunk level, you can also send calls to certain extensions to other extensions. From a button you can turn day/night mode on, so that you can route calls at night to another auto attendant, which does allow calling those certain extensions.

You mean http://wiki.pbxnsip.com/index.php/Outbound...Remote-Party-ID?

Strange. Looks like the saving confuses the list of current agents which seems to trigger the panic reaction to clear the statistics. Probably a good idea.

How long is the device unplugged? If the PBX thinks there is still a registered device, things will get tricky. After the registration expires, it should not try to call the device and immediately redirect the call (not even after the timeout).

Just watching is not possible - if you are using SOAP then the external server needs to route the call. Which should be simple if the rule is static. If there is no response, the PBX will wait and wait wait...

Usually these strange effects happen when that user 260 should be called (for whatever strage reason) and either that extension is not registered any more or the number of available lines to that extension is exhausted. That strange reason could be a re-INVITE with a changed from/to-tag, so that is technically is another dialog and treated as such by the PBX.

The statistics are in the web interface a snapshot of the current day. They are reset on midnight, just after the email has been sent out (if enabled). Who pickup up the call cannot be seen in the web interface. However the CDR contain that information, it is in the "tuser" field.

We released 2.1.7, release notes as usual to be found on http://wiki.pbxnsip.com/index.php/Release_Notes_2.1.7. This update is recommended for users that are running 2.1.6, it only fixes problems that were found in 2.1.6 and does not have any new features. For the CS410 we recommend to use the 3.0 build, as it includes important flags for the FXO subsystem.

Unfortunately, that is not a simple problem. When the user presses pound the message technically exists and is new. Until the caller deletes it, the user can go into the mailbox and listen to it. What we need to do is set the message to state "temporarily" and ignore these messages in counting messages. We fix that in head, then we can see if we port it back into the 2.1 branch.

2. will be added in the next release.

What was the "native" OS on the MAC mini again? Something with BSD?

Looks like you have a DNS problem. Simple workaround: Use the IP address in the outbound proxy. What OS are you on? Maybe there is something strange with the DNS configuration.

I would be concerned. Especially about the "voice kernel" - what is that? Is the kernel aware that there is voice flowing through the network? Apart from that, the errors seem to happen every few seconds. This will make it impossible to receive FAX, but having a normal audio conversation is still no problem. Maybe something simple like a bad cable.

There is a softphone that supports T.38 (kapanga, http://www.kapanga.net), that might be a workaround.

You can remove it from the domain settings, but then you loose the ability to call someone's mailbox directly. Better arrange the extensions so that you stay in the range 4xx..6xx. Then you can use 7xx for stuff like conference server, and you don't conflict with direct destinations in the auto attendant in the range 0..3.

I would try turning the SIP awareness off and see of that module is the problem. Then we can drill deeper from there. If that does not help a SIP trace from both sides of the firewall. Then we can see if the packet gets changed or even rejected.

Removes the number? You mean from that input field in the web interface?! Well, it should be on that Wiki page, but it is hard to write something down that covers all cases clearly..... So it is good to have a (public) forum, so that people can also search for such cases and get more hands-on examples.

Then the tel:-alias should be the right thing for you. Don't forget to clear that "Send call to extension" field. If the carrier put the destination into the To-header, then you need to put the destination out of the to header. You can do this with the following string in "Send call to extension" (assuming that 123 is the default, which could be your auto attendant): !(.*)!\1!t! 123

2.1.7 will be available this week and fixes the # problem. Maybe that's easier.

Did you see http://wiki.pbxnsip.com/index.php/Inbound_Calls_on_Trunk? You can just put auto attendant number into the setting "Send call to extension".