Vodia PBX

That should not be neccessary. This field is only required if you want to send out multicast packets for paging. Oh and also, use version 3.3.1.3177. We want to be sure you don't hit a bug that has been fixed already...

Responses are sent from the socket which received the message. That part does not use the operating system's routing table. So what is the output from "route -A inet6"?

What does your routing table look like? The PBX typically insers a "0.0.0.0" in desperation because it cannot find a routing table entry. What OS are you on?

For that you need to have the recording license (part of the call center editions). Then the web interface will show the options to record calls.

Check this out: http://www.pbxnsip.com/snom/snom_user_manual_10.pdf, that also describes how to set snom phones up. Can you send me a private message with the server address and username/password so that we can try from here? Maybe the domain login would be useful as well, for a test domain.

Calls that go via the loopback interface should always use RFC3325 caller-ID representation. That means the "From" and "To" contain the original content, what ever that was. The calling (redirecting) party would be in the P-Asserted-Identity header. That might be misleading here. But as far as I can see it could be really a tricky case. We need to check if the ANI representation is correct for this kind of call. The problem is that there is no trunk here where we could define the ANI behavior.

No. Loopback detection does not differentiate between sources... Would it make any difference? For example, what if the PBX users really create a loop (a@domainb redirects to b@domaina and b@domaina redirects to a@domainb)?

"IMHO" it is pretty stable. But it is not released yet. We are still testing it. Release notes are also missing. If you use it, make sure that you have a backup and can move back any time.

Yes. That should do the trick.

The syntax is like in the dialog permission fields (see https://www.pbxnsipsupport.com/index.php?_m...kbarticleid=405).

Default is that the RTP thread uses core 0. IMHO there is no need to change this unless you want to run multiple instances of the PBX on the same host. As you know, if you are able to split the userbase into domains, you can always run multiple instances (processes) in different working directories on the same machine. This way, you can squeeze the last CPU clock out of the system. Version 10.0... We looked into this; this will have a lot of consequences and also a lot of interal overhead. There are some other things that we can do first in order to improve the performance of transcoding and that should bring us into the area of 200 calls on a modern CPU (including low rate codec transcoding). You need a pretty big domain to have 200 calls going on.

If you like, ask for a 3.4 build, which already fixes a couple of things.

Minutes or seconds? Try 4.0.0.3212 (send an email to support to get the latest snapshot).

4.0 will not be the last release... Our plan is to put some producivity tools into that release like the cell phone groups and maybe some renovation in the CDR area and have it stable. We also worked on the user interface and make it possible to provide professional services for the product. Then we can move on to 5.0.

Linux uses multiple cores for the HTTP processing, but not for media processing and SIP. So yes, you can use 6 core machines, but no 500 calls will not be realistic on that machine... At least you don't have to worry that the HTTP or HTTPS stuff is a showstopper for performance.

There are two new flags in the redirection settings for an extension that control if the hunt and agent group should include the cell phone. Did you turn them on? And the latest beta is 4.0.0.3211. Maybe you can ask for a latest build.

There is a setting in the registration tab of an extension.

In version 3, the Windows version would have a problem as all threads are bound to one CPU core. That will have a negative performance impact. In version 4 we made it possible that the Windows operating system also uses other cores for the HTTP threads. In Linux, it never made a difference. Version 3 already makes it possible that the operating system uses different cores for the process.

Eehhhmmm...

Yes. EPID is for a 911 call. It must be enabled in the trunk. But you can also use a ANI like this: "Trunk1:9781234567 9787462777", means when using Trunk1, use 9781234567 otherwise use 9787462777.

That feature is just a few hours old... It will be on *51 and *52. Unfortunately we need to enter the *5x area... To many features!!!

Yes. There are a couple of enhancements of the queue. BTW the ACD is now also able to ring an extension forever, it necessary the whole night. Another feature that I don't really understand, but a common requirement in the ACD area. Plus the "agent" can now be on one of his cell phones. IMHO that is a very cool thing. The other thing we want to have in the ACD is video. When someone calls from a video phone, the provider can play ads during the waiting time and provide information about the call. So that the caller can prepare for this call. This is for a carrier that wants his customers using video on the cell phone network. Large numbers here!

We are currently using Debian 4.0. We also have an image for 4.0 with Debian 4.0. So far only 32 bit. I believe it is 5.2. We have an image running on Suse10 with 64 bit, but we did not publish it yet. The only benefit I see so far is that log files can get bigger than 2 GB; that is an issue that we run into frequently when customer don't want to include the date in the log files and forget turning logging off or to reduce the log level. Yes, you stay away from trouble. IMHO 32 is still mainstream, not only for pbxnsip. The SheevaPlug seems to be running Debian 5 and there we had no problem getting it working and it seems to be pretty stable. So far we have only 64-bit SuSE. Never tried that. AFAIK 64bit Windows runs 32-bit applications with no problems?

We added that to 4.0. There is a new star code for that and also another star code for transfer to the cell phone. The codes can be put on a button, so that the Joe Dumb can switch between desktop phone and cell phone.

Whow. There are some rumors that there will be a newer kernel available for the Comcerto platform. The current one is already a few years old... Maybe a new kernel also helps stabilizing this. And it would also help getting IPv6 working on this system.