I’ve been using FreePBX with PIAF for many years now, and due to a near hardware failure, decided to colocate a new server. After setup, things seem to work fine - and when one call is connected, everything is great, no matter what codec I use.
However, when a second call comes in, the calls start to lag, get jitter, and are generally unusable. I’ve tinkered with NAT and codec settings, have updated everything to the newest available version, and no love.
The problem is, I’m not sure where to go from there. I’m running FreePBX 2.11.0.32, with Asterisk 10.12.1.
So, any pointers on where to look next? Happy to provide any settings, or config information, I’m not sure what’s relevant yet, and don’t want to flood the thread.
The server lived locally on my network for many years, and now I’m renting a server at a datacenter near me. it’s a fresh install so sadly I can’t compare install to install for settings.
The CPU average load barely gets above .01, and I just emailed the hosting support, the server is on a full duplex gigabit switch.
I’ve tested for packet loss, tests consistently come back as 0% with an 18ms average between the server and office.
I’ve been googling the issue like crazy for weeks, switching codecs around, and nothing seems to help. If anyone has a guide, or other settings to try, I would be grateful.
I’ve also experimented with the jitter buffer, but it appeared to make things worse - the delay between the end points got so bad, it seemed as if the call was disconnected - seconds of delay.
One of the problems with cloud servers is that you really don’t know what you are getting, If it is real hardware that shouldn’t be a problem as what you are doing runs fine on a $30 recycled box from the local thrift store, If you have a “virtualized” machine, then there is no control over what limitations are imposed on your machine, particularly kernel scheduling, so although it would fine for a webserver , the lack of performance of a “not so close to realtime kernel” can be disappointing if trying to stream rtp (asterisk). Maybe try another cloud service? , maybe plonk that $30 bucks down.
(ping is a particularly poor tool for seeing a network if that is waht you are relying on, even on your limping server,
Not sure what dicko expects you to see with RTP debug but it can’t hurt just don’t forget to turn it off.
I didn’t ask you what kind of switch server is connected to, I asked if it negotiated FD. Since I now know virtual less of an issue but just for S&G check the phy, I just verified tests run fine on a VM:
[root@Lightyear-VM ~]#
[root@Lightyear-VM ~]# mii-tool eth0
eth0: no autonegotiation, 100baseTx-FD flow-control, link ok
[root@Lightyear-VM ~]# mii-diag eth0
Basic registers of MII PHY #32: 1000 782d 0000 0000 05e1 05e1 0001 0000.
Basic mode control register 0x1000: Auto-negotiation enabled.
You have link beat, and everything is working OK.
Your link partner is generating 100baseTx link beat (no autonegotiation).
End of basic transceiver information.
[root@Lightyear-VM ~]#
Lastly, I asked you to do pings while two calls are up. Please follow our tips to the letter if you wish continued support (at least from me). It is not reasonable for Dicko and I to keep reminding you to follow directions.
(the time stamps and the proper sequence of in/out, but apart from that it’s quite hypnotic the discontinuities are really quite noticeable, see more than a very very few a second and something aint quite right )