After spending 10 hours I managed to get Twilio Elastic SIP working with the latest version of FreePBX I downloaded STABLE – 10.13.66, Release Date: 2015, FreePBX 13 • Linux 6.6 • Asterisk 13.
However, I am having issues with crackling voice quality when listening to the outside party; this happens in both incoming or outgoing calls. To rule out issues with the eyebeam client, I further tested this with leaving a voicemail at an extension, and the audio recorded of the outside party is horrible.
Right now I have the distro installed in a VMware machine with its internal IP placed on DMZ. All the ports are open from the firewall and the software firewall is enabled. I have even tried turning all the firewalls off and did not show improvement.
I have ulaw set as the only codec in Asterisk sip settings. I did have to switch ports for CHAN_SIP to 5060 and CHAN_PJSIP to 5061, otherwise I couldn’t get the twilio trunk to register as it doesn’t provide an option to specify a port number in Twilio’s online admin section.
NAT is enabled.
Here are the peer details for the outgoind trunk: host=somename.pstn.us1.twilio.com
username=freepbxhosting
secret=secret
type=peer
allow=ulaw
For incoming trunks I followed the directions provided by Twilio’s pdf file and have created 4 incoming trunks with the following user details:
host=54.172.60.0
type=peer
context=from-trunk
Any suggestions or ideas would be greatly appreciated.
Thank you for the reply jfinstrom. Here is the output I am getting. It does say ulaw. Is there something else I am missing? The other party can hear me fine.
Name : officelocation1
Description :
Secret :
MD5Secret :
Remote Secret:
Context : from-trunk-sip-officelocation1
Record On feature : automon
Record Off feature : automon
Subscr.Cont. :
Language : en
Tonezone :
AMA flags : Unknown
Transfer mode: open
CallingPres : Presentation Allowed, Not Screened
Callgroup :
Pickupgroup :
Named Callgr :
Nam. Pickupgr:
MOH Suggest :
Mailbox :
VM Extension : *97
LastMsgsSent : 0/0
Call limit : 0
Max forwards : 0
Dynamic : No
Callerid : “” <>
MaxCallBR : 384 kbps
Expire : -1
Insecure : no
Force rport : Yes
Symmetric RTP: Yes
ACL : No
DirectMedACL : No
T.38 support : No
T.38 EC mode : Unknown
T.38 MaxDtgrm: 4294967295
DirectMedia : No
PromiscRedir : No
User=Phone : No
Video Support: No
Text Support : No
Ign SDP ver : No
Trust RPID : No
Send RPID : No
Path support : No
Path : N/A
TrustIDOutbnd: Legacy
Subscriptions: Yes
Overlap dial : Yes
DTMFmode : rfc2833
Timer T1 : 500
Timer B : 32000
ToHost : hostname.pstn.us1.twilio.com
Addr->IP : 54.172.60.2:5060
Defaddr->IP : (null)
Prim.Transp. : UDP
Allowed.Trsp : UDP
Def. Username: freepbxhosting
SIP Options : (none)
Codecs : (ulaw)
Auto-Framing : No
Status : Unmonitored
Useragent :
Reg. Contact :
Qualify Freq : 60000 ms
Keepalive : 0 ms
Sess-Timers : Accept
Sess-Refresh : uas
Sess-Expires : 1800 secs
Min-Sess : 90 secs
RTP Engine : asterisk
Parkinglot :
Use Reason : No
Encryption : No
One solution, don’t use use vmware, there are much better virtualization solutions now available that are closer aware of your kernel and generally without that latency overhead that is killing you. Look at KVM . . .
Vmware can work absolutely fine with asterisk. Kernel timing needs to be configured correctly however and sometime very early on in virtualization, say a decade ago, we didn’t also get the clock on a virtual machine correct. Now, it shouldn’t be a problem on anything but the oldest hardware. If you are running into audio trouble, check your OS clock frequency in your VM, make sure you have low network latency and jitter. Beyond that, there is nothing credible behind saying you can’t use vmware for a pbx! I have done it successfully for almost a decade. I’m not saying it’s the best way to virtualize in evey scenario, but vmware is in a lot of environments and is more than capable of handling an ip pbx.
But apparently not working for @ray123 very well, generalizations are always just that, including mine, been there done that, won’t go there again, never had to look back . . … Glad it works for you though.
Well, a bad config is a bad config and it doesn’t matter if it is vmware, kvm, hyper-v, or bare metal. I have had garbled audio on bare metal and virtualized and had the same issue. Compiled asterisk from source, and the problems went away in both environments. So, anything from a bad binary to a bad install of OS or applications or configs can be the issue. Telling someone Not to use VMware is hardly helping them fix what is likely the real issue. Unfortunately, we probably don’t have enough information to solve the issue and what eliminating vmware could do from a troubleshooting perspective is eliminate the hypervisor or bugs in it as the issue. Barring that, the actual issues should be ironed out, and virtualization of some sort used for production.
It does sound to me like a timing issue. What is the physical hardware vmware is on? Is it ESXi or workstation? Server class hardware, pc class, or other questionable hardware? Perhaps following the tips here about kernel timing could help
I have hosted trixbox before in a ESX environment 5 years ago without issues.
Currently I am using vmware workstation 8 to test freepbx with Twilio. The hardware specs are top notch:
Dell precision laptop m4800
i7-4900mq 2.8GHZ
32 GB ram physical (4gb VM)
Win 7 professional 64bit Host (64bit Freepbx VM 10.13.66, Release Date: 2015)
Samsung 840 Pro SSD (40GB HDD space allocated to VM)
I’ve managed to fix the audio issues during a live call. It had to do with jitter and NAT. But I am still getting digitized voicemail that sound like they have been slowed down.
I am going to take at the timing issue right now, otherwise I will just test it on a physical machine.
The crackling is more of a network traffic quality issue such as jitter or dropped packets. Could be congestion or hardware (nic or driver) or timing related. If you enabled a jitter buffer and it helped solve the crackling that is good, but could mean other issues which leads me to… As for the garbled or slow sounding slow, if the timing of the VM CPU kernel is fast, it could cause packets to be received out of order (crackle) and voicemails to be recorded with a faster timing than they get played back with. Workstation 8 is pretty old and I wouldn’t be surprised if that was causing some of the grief here, but if you google around it should be possible to get it sorted out.
Another solution is to not host any virtualized solution on a windoze box, it still can’t walk and chew gum at the same time , why spoil a great solution with a big old expensive POS when you can use a slick host OS like linux? feel free to run winblows under KVM also if you feel the need, it works as good as it did on hardware, without getting in the way of cleverer stuff that needs a good un-hobbled network. It’s all just topology and priorities nowadays.
@ray123 would you post or share your settings since you have done all the heavy lifting already to figure it out? I would like to try this on a bare metal lab server I have handy and will provide feedback regarding quality.
If it helps… I’m running FreePBX13, Asterisk 13 and Ubuntu 14.04 on Microsoft Azure (EU LRS) using Twilio Elastic SIP and don’t get any issues at all. Not bragging…just thought it might help eliminate Twilio from the equation. I’ve not changed any of the default VM settings shipped by the Azure Ubuntu/VM image.
I’ve run the FreePBX Distro in ESXi for more than five years on a core i3 with 4gb of RAM without any issues, and even in VMWare Player (on Windows) intermittently when I was making changes to the ESXi server, and never had any issues whatsoever. I know someone else that ran FreePBX on VMWare Player 3.1 for over a year without issues. Whatever problem you’re having, it is not likely to be related to ESXi.
I also doubt that it is a configuration issue, though modifying configuration parameters (such as increasing the jitter buffer) may help mask the issue.
Have you tried registering your client directly to your ITSP and seeing if the problem persists? The easiest way to resolve this problem will be to remove one potential source of the issue at a time until it goes away. Take out the PBX by registering directly to a provider, then try another ITSP, then swap your router, then swap to another internet connection (use another location if you have to), etc., until you figure it out.
I vote for a networking issue. Do you have a Wifi transmitter or any other device that generates RF (cordless phones, etc) near any of your networking equipment (switches, router, modem, etc.)?? Those device can often interfere - especially with modems and routers and switches. Move them far away from those types of devices.
Based on my acquired knowledge over voip on VM’s for the last seven years or more, ANY form of virtualization relays totally on layers above the implementation of the software layer, be that VMWare or M$ or Zen or KVM, a measure of ability of the underlying OS and ultimately the hardware itself is critical to pass realtime traffic through to the network without hindrance. So starting at the top, you will NEED VTX and preferably VTD on your harware, you will need a very good kernel on your “cloud” servers or other things will break.
The kernel layer is provided by maybe Windoze, maybe linux, maybe Xen your choice. If your hardware/software layers above the VM are inadequate, then web servers et al will work just fine, VOIP not so much.
So while any one can say my “Y” based system works perfectly, that would depend on the underlying hardware. I haven’t used windoze for years, but IMHO any version of linux in the last few years support kernel based “extensions” (if you want) for very low level VM’s so although I think KVM/qemu outperforms any MS based stuff, that ALWAYS depends on your hardware.
The more layers of b.s. between the machine and the innertubes the less likely you will be satisfied. As I suggested before, use a modern linux and relegate your windows machine to a VM under that, use your lean and mean kernel on well chosen hardware and all your problems will be reduced, then you can trouble shoot any remaining network problems without having to get involved with “closed source” software.
So each VOIP machine would need 1G of memory, 10G of hard drive and an unimpeachable ethernet “bridge” to the underlying network hardware. Your MS virtual boxen a lot more .
Wanted to thank everyone for their input. The problem was related to the virtual environment indeed - credit goes to dicko in this case.
Although I have successfully used Trixbox in Vsphere, I couldn’t get freepbx to work happily under vmware 8 workstation.
Right now I am using a core2duo server, I am finding it generating a lot of noise an heat. Any recommendations on a power efficient server with low noise? I was thinking of using a raspberry PI 2 B but I need something with dual nics. There will be no more than 3 concurrent calls on this thing, it is for a small office.
.