Sangoma A400 analog card + FreePBX in a virtualized environment

Hi all, I’m looking for some advice here.

I’ve set up a FreePBX system in an ESXi 6.5 virtual machine. I have an A400 to connect analog PSTN lines, and I’m using ESXi’s hardware passthrough to expose it to the VM. It seems to be working fine, but now I’ve been reading that this is not a good thing to do because the card is very timing-critical regarding interrupts, etc.

The server is probably considered a bit ancient by now, it’s a Dell R710 with 4 cores and 32 GB RAM. We use it just for a handful of less resource-intensive VMs and it’s been very solid. When I make and receive test calls with the A400, all seems well. No issues at all, but I don’t know if any may arise in the future due to this configuration.

We are not live with this new phone system yet, but will be in the next month or so. Would it be wise to not use an analog card with a VM like this? I most definitely want FreePBX virtualized, due to all the inherent benefits that go along with that.

Should I just move forward with what I have, or should I do something like move the A400 to a dedicated bare metal box running another FreePBX install that just exposes the analog lines as a SIP trunk to the main PBX over over the LAN?

Dahdi is distributed with a dynamic ethernet driver, this is a layer 2 (ethernet) driver, so install just dahdi on the host machine and dahdi and asterisk on the vm, cross connect the channels on the host to channels on the virtual machine(s).

Best to set up a private ethernet between the host and vm to isolate the traffic.

That’s not a functionality that’s tested / advertised with the cards. If someone chooses that route, they’re venturing out alone.

Now that’s interesting, I didn’t know that. But is it possible to even install dahdi on an ESXi host? It runs vmkernel, not Linux. Or did you mean use a separate bare metal box running Linux, and were referring to that as the host?

Do you think hardware passthrough is a bad idea in the long term, even if it’s working fine now?

I know, I totally understand this is unsupported. :slight_smile:

I can’t speak for ESXi but it worked fine on A10n and A400 series boards on KVM/ProxMox and earlier Xen based servers. (always compiled from source and at 2.n level)

Ok, yeah I’ll probably have to go with a separate machine running Linux then. ESXi’s kernel will likely make it a no-go since it’s not Linux at all. Which is fine, I don’t mind running two systems. There are spare ports on the VM host, so I can still do a private network.

You know, now that I think about it I do get occasional clicks on those analog lines and I bet they are actually due to timing issues with the VM. They’re infrequent and aren’t really a bother, but I want to maximize call quality. I’ll see if they go away with the card in a dedicated machine.

Thanks for the tip, TDMoE sounds like a cool feature.

Well true it’s not linux but you surely can compile c code on it (and dahdi is pure c ) and if just fxo/fxs just the tdm bits, no libpri or other dependencies needed and the /dev/* nodes added, but that would be a project for a lazy sunday afternoon.

Yeah, it’s very Linux-like. I was assuming dahdi used some Linux-specific functions for its driver hooks, but maybe not. Could work right out of the box, but either way honestly I’d rather not risk breaking something on the hypervisor. There is one VM on there that is pretty mission-critical and I wouldn’t want any extended downtime on it. It would be easiest to throw the card in a Linux box.

I might play with it on my home lab this weekend because now I’m wondering what would happen. :slight_smile:

I am also intrigued as to what will happen . . . :slight_smile:

As to an earlier question, the PCI pass-through would pass the whole card through, I wanted the eight PRI’s on the A108’s going to eight different VM’s , True the PRI’s have all gone now and the VM’s have all floated off to the cloud.

Sounds perfect for that use case!

I also just discovered dahdi_test. After 48 passes in the VM:
Best: 99.998% – Worst: 99.758% – Average: 99.955705%
Cumulative Accuracy (not per pass): 99.985

What would be considered “good” with dahdi? I’m still a newbie with telephony and PBXes, but I’ve been learning a lot fast.

Is this the same system with the Charter MTA referenced in your earlier thread about echo?

If so, unless Charter is giving you a helluva deal, or you are stuck in a contract with them, ditch the analog interface and get a SIP trunk. In the short term, get a temporary DID and forward your Charter number to it. Once you’re comfortable, port the number.

Compared to the analog interface, the SIP trunk will give you better voice quality, fewer issues with DTMF talkoff, better doubletalk performance, faster call setup (don’t have to wait for dialtone and send DTMF), faster incoming (don’t have to wait for first ring to read caller ID) and control over outbound caller ID.

1 Like

Marginal , but quite normal

have you also discovered fxotune , it also helps with echo reduction ?

It is the same. Regarding the echo, that was a really dumb mistake on my part which is now fixed. No more echo, at least none that oslec can’t fix quickly.

And we are going to go with SIP trunking for sure later in the year. That’s the plan. One step at a time though, we’ll get into SIP trunks maybe in the fall or winter. Just want to make sure the users have good call quality until then.

I read about fxotune, but found it doesn’t work with Sangoma cards. Regardless, the echo problem is resolved. I had done something really stupid, it wasn’t even a problem with the Charter MTA. I forgot that I had a MagicJack plugged into the FXO port when I thought I still had it connected to a Charter jack. Yeah, I’m serious. Whoops!

In fact, maybe a mod should even delete that whole thread.

The Charter MTA works great with it.

Yep my bad on the fxotune , I am a little rusty on dahdi :wink:

As you should be. Everyone should be using SIP! :slight_smile:

By the way, I just remembered that I can control latency sensitivity of VMs in ESXi. Just changed it to high, now the cumulative accuracy is a healthy 99.999% in dahdi_test! I’m not even hearing the occasional click now. I’m pretty happy with this, I don’t think I’ll even bother to stop using passthrough. Especially since this is only going to be used for a few months until we do go SIP.

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.