We have used Bria, Zoiper, Acrobits and Media5 phones on both IOS and Android cell phones. The quality is always sub standard when compared to a standard VoIP adapter or phone.
When we test, both phones are connected to the same Asterisk server on the same LAN network but call quality on the hardcoded Grandstream or Linksys phone is perfect and call quality on the cell phone SIP client is sub par. The issue is not the SIP client as all above mentioned apps perform poorly if compared to the corded phone. Is it the cell phone CPU? Speaker, MIC? Any explanations?
Force the soft phone to use G722, and see if that fixes your issues.
are the phones using Wi-Fi or cellular data to connect? if Wi-Fi then there should be no difference. i have used most of the listed softphones and they work great over Wi-Fi in the office, and for the most part work great on cellular data (i use att and their LTE network is pretty good) if cellular data and the data speeds are slow then rob’s suggestion should help
how old are the phones?
@bksales. I am using wifi. It’s an iphone 6+ so it’s pretty new. I always get complaints when I am on the cell (VoIP) but no complaints when I use the grandstream phone in the same office no matter which VoIP client I use.
@xrobau. G722 is a great codec but it doesn’t fix the issue. I usually uese G711 on wifi and don’t think the codec is the problem.
Maybe the difference is the TCP protocol on the cell?
It’s likely the cellphone connection.
Normal desk phones are usually “directly” connected to the PBX, directly meaning maybe a couple on on premises switches and that’s about it.
Cell phones are wireless (duh), and so deal with on air traffic, signal quality, trunk bandwidth issues, the provider’s internal network, and then the internet, before touching your PBX. There are a lot more issues to deal with.
Changing the codec as mentioned with help in that the required bandwidth is reduced so packets transmit faster over the networks quicker.
if you are on Wi-Fi then you should look there first, especially if you are in the office. if you are at a starbucks or some such place, you might be better off with cellular data. you might also check the settings on the phone. i remember that once upon a time you could specify which type of connection (wifi or cellular) to use when making a call. perhaps the phone is using cellular when you think it is wi fi. if you have decent wifi then you should see no different. i don’t use the g722 codec and have not had the need on either wifi or cellular. you might start with some simple things like looking at the delay times between the cell phone and the pbx. i would also double check which codec you are using.
I use Bria and it works perfectly well over Wifi on my local network.
Two tests I suggest:
- Try the same software on an Android phone to rule out cellphone / cellphone OS related issues. I run Bria on an Android phone.
- Setup a wifi router just for your cellphone and see if VoIP works well using this wifi router. If it fixes your problems, then you probably have a bottleneck on your wifi routers (see “bufferbloat”). In that case either upgrade your wifi routers, setup QoS or setup an independent wifi network for that kind of traffic.
Also remember that at some offices, the Wifi network is on a separate Guest VLAN which is bandwidth limited. Maybe there is something to look there.
There’s one thing about this discussion that’s bothering me.
Cellular phones are a specific technology and protocol set, all the way down to Layer 1. They are designed to handle the things that we are talking about. They use ATM instead of IP to improve the likelihood that these problems will occur. Transit times are minimized because of traffic shaping and lots of other technological advantages that we’re not going to be able to do.
Expecting a WiFi connected device (phone or not) to work over VOIP is just not reasonable.
Sure - we can simulate the things that make cell service work. For example, we can set up a wireless router that handles nothing but VOIP traffic, but as soon as we walk out into the real-world, we’re subject to the vagaries of non-prioritized traffic, long transit times, IP routing delays, etc.
Also, while every phone provider on the planet will deny it, I’m of the opinion that they deliberately mess with VOIP traffic over their 4G networks. If you are anything less than 4G, it’s a pipe dream to hope that your 256kbps asymmetric data connection is going to give you crystal clear connectivity.
Your Wifi network is likely congested. Wifi likely has no mechanism to give the RTP media packets the priority that they need. If you really want to use Wifi, consider setting up a secondary network on a separate channel just for VOIP phones. Alternatively, try using a very low bitrate codec (like GSM or G729).
Better yet, just get some DECT phones and use them instead.
I have no clue what you are talking about.
If you are using wifi on the phone you are using the IP stack there is no encapsulation going on.
You are limited by the quality of the wifi network you are connect to. A properly designed wifi network can work fine for VoIP. In my house all it took was a Ubiquity AP mounted up at 24ft at the peak of my ceiling.
As far as 4G RAN’s, I am not aware of any carrier using ATM transport, and even if they were ATM is the first L2 protocol to have meaningful QoS and it still works great.
The radio side (which is L1 BTW) is part of the CDMA protocol and is decapped at the BSC (base station controller) at the MTSO and handed off to the carriers IP network.
20 years ago ATM was a common L2 protocol in carrier networks. That was abut the last time I have seen a Lightstream 1010 (Cisco’s groundbreaking Ethernet/ATM common backplane switch) I think it cam out in 96.