Vodia PBX

Actually a good question, I doubt it. I am not the big expert to know if there are any issues running 32-bit code in a 64-bit environment that would explain such a crash. So far we did not hear about crashed from other sources, so yea maybe there is a issue.

In version 4, that is correct--right now. We received news that this might be a problem. Seems like Windows locks all threads when moving one thread from one core to another. This would be very bad news because then we cannot allow some threads to run on free-floating cores. In Linux, we did not complaints to far about such an issue.

Oh. Maybe you can let the PBX generate the PnP files for another extension and then take a look at the master file on how it should look like. Then you can change the 0004..cfg accordingly.

Yea, thats when such ideas get tricky. We probably need some kind of score that include the number of free agents and the time the callback is waiting. Meaning if the duration is longer than so and so or the number of agents is less than so and so then the callback gets started and the caller is being put at the top of the queue.

So are you using a 64-bit build? Or a 32-bit build? Not sure if that can cause an issue.

We still have a issue with the clock subsystem on the MAC... Pretty basic stuff, I wonder how we ever got this working before. Anyway, in version 4 we want a clean solution for this simple problem.

Why CentOS? I thought Hyper-V would be a Microsoft thing? Wouldn't it make more sense to run Windows server 2008 on it? Just out of curiosity

This version performs the delayed loading of the CDR records. That might be the reason why it behaves a little stange. The other thing is that the 32-bit versions have a limitation regarding the number of open TCP connections (HTTP or SIP). Once you get over 250 connections, you might run out of virtual memory. For that we are preparing the 64-bit versions right now. Apart from that, if you can get a core dump it would help to see where it was causing a problem.

Right now the whole ACD has a priority. This priority compares to other ACD, but not within the callers of one ACD.

I guess on the trunk you need to choose the mode "No Indication" where the RFC3325 is the default. Your service provider is probably not able to deal with RFC3325 indications. We also added a Related-Call-ID header which might be used by the service provider to verify that this is a redirected call and no caller-ID spoofing. But of course almost nobody supports it.

I remember the following: ACD may now have a priority. That means a ACD with higher priority will always get the agent before a ACD with lower priority. This makes it possible to have "first", "business" and "cattle" class services just like we know it from the airlines. Connect message: When an agent picks the call up, the PBX can quickly send an email with the connection data. The point here is that this can be used for linking the ACD to the CRM system by embedding handcrafted URL where the agent just has to click on in the email program. The agent login and logout time reporting has been changed, hopefully improved. Now it should be possible to see when the agent logged in in the morning and when they logged out in the evening (so you can see the total time in the company) and then also see the breaks in between. Call recording on ACD should now also survice transfers. Integration with PAC and WAC. CSTA integration for monitoring the ACD from third-party tools.

I hope not!

Did you try "No Indication" or "RFC3325, but dont hide"? Those modes might be okay for this. Also you can try putting a ANI into the trunk setting with these two modes and see if it shows up in the From header where you want it.

Where? In the master file in the generated directory?

Maybe we can solve this problem with an additional parameter that instructs the PBX to also call the cell phone.

This is a good idea. However, to make it interesting for the PBX operator, I would say the callback should be started when the ACD gets idle (whatever that means, possibly when the number of callers in the ACD fall below a certain value).

The following things are available in the replacement: "\r" is the registrar name (the domain name) of the trunk "\a" s the ANI on this trunk "\x", "\y", "\z" are parameters 1, 2 and 3.

Should be fixed in the latest and greatest (4.0.1.3445).

This happens out outbound trunk calls, right? Seems when calling an extension it works. There is still a gremlin hiding in there.

So far we did not pay too much attention to TAPI in V4. The good old code is still in there, so it might just work.

Ouch. That is convincing.

No as long as V4 is not released we don't keep release notes.

http://www.pbxnsip.com/download-software/software.php

Well, that's clear... My question was more like what happens to the guys that select EDT and live in Sounth America.

Oh what version are you using? We actually had a early beta that such a 8-minute bug for TCP/TLS. This happens for example when both parties agree on outbound, but then the refresh does not make it. But there was only a few days when this version was available (and I remember it was not even public). But this problem should be gone with all subsequent versions. What is your refresh time for registrations? Does it make a difference if you are using TCP/TLS or UDP?