Hi everyone. I just discovered that Acrobits has had a forum of its own since October of 2016!
I recently made a post elsewhere, which clears up many common misconceptions about Groundwire, and I was asked by Acrobits to perhaps link to it from this forum too. But I thought I may as well copy the whole post over here instead! Here you go. :-)
This was in response to an old but prominent thread about Groundwire (and the ">>>" sections below are me quoting another poster):
https://forums.macrumors.com/threads/gr ... t-24352988
I hope this will be helpful to someone here too! :-)
Hey I'll just update this for 2017!
>>>Groundwire (version 1.4) is good:
>>>* the keypad interface is nice, looks good, and works good
>>>* many configuration options
True. It's the most advanced and configurable SIP client of them all. And even consumers should buy Acrobits Groundwire instead of Acrobits Softphone. The extra enterprise-grade features in Groundwire are worth it even to consumers. And you can trust that Groundwire will always be the better and more capable product of the two.
And it is the ONLY VoIP client for iOS which is built for reliable background push (the competition doesn't even have push at all because it requires extra infrastructure that others don't want to invest in). Their SIPIS PUSH system serves MILLIONS of customers with push-calls year in and year out, both consumers and enterprise users! Incredible.
>>>Groundwire is not so good:
>>>* the app doesn't automatically start when the iphone/ipod device starts
Not needed. Groundwire uses PUSH for all incoming calls, even if the app isn't running.
And you don't even need to constantly open the app to "keep your SIPIS PUSH registration alive", because they do that via periodic background pushes which just tells your iOS device to invisibly and briefly wake up Groundwire (even if it's shut down) so that it can answer the "are you still alive?" background-pushed "keepalive ping". That's how SIPIS knows if your phone is still alive and able to take calls, even if Groundwire itself is not running.
Their SIPIS server has a very long registration lease for every client, and it constantly renews them in the background via background push to check if your device still has Groundwire installed (I forgot the frequency but I think it's checked once every 10 days, and if your device doesn't answer that check, it starts sending them more and more frequently until the SIPIS registration expires). So people DON'T have to worry even if they don't open Groundwire for MONTHS. Their SIPIS PUSH server will stay registered and invisibly kept-alive to your number so that you'll still get an INSTANT push as soon as someone calls, as reliably as always! :)
The only way to become unregistered from SIPIS (and miss calls) is to literally uninstall Groundwire so that it no longer answers the background "keepalive" push checks from SIPIS. Alternatively, just disable Push in Groundwire, of course, which instantly clears you from SIPIS. But only a fool would want to unregister from SIPIS. ;-)
>>>* it misses roughly 30-60% of inbound calls (in double NAT enviroments)
There are zero missed calls for me. But push takes anywhere from 0.5 to 5 seconds before the phone rings. If Apple's push notifications have recently been used on the device it takes 0.5 seconds. If the device has been inactive in the pocket for a while Apple seems to go into "low power sleep mode" for push so it takes 5 seconds.
Also note that NAT issues are up to the provider to solve, not Groundwire. The app offers about 20 different options to configure to work perfectly with any provider. The servers on many providers aren't very well configured on the server-side, and won't understand when THEY should proxy audio and other things, but Groundwire has TONS of options to make it work even with badly configured providers!
Most providers work with the default options out of the box.
Some need you to set "NAT Traversal" to "STUN" instead of "Auto", if you only get one-way audio whenever someone calls you and the app is in the background/quit.
The proper settings to use in Groundwire to solve various common PROVIDER-CAUSED audio issues are here:
https://www.acrobits.net/hesk/knowledge ... ?article=6
>>>* there is no option to re-register accounts that have failures (you need to make a change in the settings to force a manual re-register command)
I have no idea what you mean here. But my Groundwire shows a green outline around the provider's name in the top left of the GUI when it's successfully registered. If it fails to register it shows a red outline AND retries automatically, over and over, until it succeeds.
Failures to register only happen when my VoIP provider is down, which is ultra rare and has nothing to do with Groundwire.
>>>* UPnP to open ports in NAT routers is not supported
And for good reason! Groundwire doesn't use support UPnP or NAT-PMP for automatic port mapping. Instead, the app relies on the provider detecting you as being behind NAT, so that the provider proxies (and optionally transcodes) all media streams. That way there’s no need to open any incoming ports whatsoever. That's the proper way to do it.
It gives the least amount of problems, and also means that your incoming and outgoing calls will support transcoding via the proxy which in turn means that your device can use ANY audio codec your provider supports - such as ultra-efficient ones like Opus / iLBC / GSM on 3G networks, instead of being forced to use the bandwidth-wasting G711 (which is a VERY heavy bandwidth, nearly uncompressed codec, but that's the only codec supported by MOST incoming PSTN trunks, so you NEED your provider to do proxying for you if you want incoming calls to use another more efficient audio codec!).
If you really want to do firewall port mapping, then your goal is obviously to appear like you aren't behind NAT. In that case, you will lose out on the ability to use anything except G711 for incoming calls. Because then the incoming PSTN trunk will be connecting directly to your phone and will only be able to negotiate audio codecs supported by the trunk. Usually that means ONLY G.711a/u and G.729.
If you truly want all the hassle and downsides and risks of the phone trunks connecting directly to your phone instead of properly proxying/transcoding via your VoIP provider, then sure, go ahead and manually open ports in your router. In that case I suggest opening at least 5 RTP ports in the 10000+ port range, as well as your SIP messaging port, setting a static IP for your phone in your router, setting Groundwire's advanced "Hacks" settings section to only use those ports, and setting "Push: Simulate NAT" to Off, and "NAT Traversal: Discover Global IP" to External (both of those settings relate to SIP messaging and how it appears to your VoIP provider). You may also need to enable STUN instead of Auto (STUN is a way of detecting your external IP when you are behind a router). This complicated setup will mean that your VoIP provider sees your SIP messaging as external internet traffic, and sees your registration and RTP audio ports using an external IP. And then, *IF* and only *IF* your provider *actually* allows non-proxied traffic (MOST will ALWAYS do proxying anyway), *THEN* you will get a direct incoming call from the PSTN trunk. But those direct calls don't support good audio codecs, and they have tons of risks of dropping the call or never connecting. It's MUCH better to let your VoIP provider proxy (and optionally transcode too) all audio.
So in short; No, you don't want Groundwire to open any firewall ports. And you shouldn't do that yourself either.
Let your provider do audio proxying, so that you don't have to open ANY incoming firewall ports. Most providers do that by default and you can't even get around it with most providers. Because proxying is the right choice for pretty much 100% of all people. Having a direct incoming connection from a PSTN trunk is just begging for tons of trouble.
>>>* when not using Push notifications and having stun enabled, having keepalives enabled, and keep the app always on, still a lot of calls are missed in NAT enviroments
As Steve Jobs would say: "You're holding it wrong". ;-) Read the above paragraph. It's a bad idea to let your phone be the SIP messager, because obviously it will miss calls then. Because iOS itself does **NOT** let "backgrounded" apps run 24/7. It slows them down. And the more inactive/backgrounded they become, the less frequently it can keep alive its network connection to the SIP protocol.
That's why PUSH is faaaar better. It lets a real 24/7 internet server handle all SIP protocol traffic (the "incoming call!" notifications). And your device just needs to be woken up by a simple, reliable, power-efficient push message, which all Apple devices support perfectly!
>>>* it lacks a private push server option (supplying sensitive data to third parties is not an option in many business environments)
Maybe that was true in 2010? It's not true since 2013.
Acrobits provides the SIPIS server binaries so that you can set it up on any server you want to. For a 100% private PUSH notification network for business environments.
But note that you need huge expertise to set that up (Linux nerds like myself), and you need to be hooked up to Apple's push notification system via your own API key from Apple.
Also note that Acrobits SIPIS, the default choice used for all PUSH in Groundwire when no custom server is used, has NEVER been hacked in all these years! I trust it with all of my numbers from multiple VoIP providers around the world! And so do TENS OF MILLIONS of other people!
>>>* G.729 needs an awkward in app store purchase, combinate groundwire + all codecs in bundle, to save business purchasers time and hassle
Idiotic idea. G.729 is a very expensive codec which would raise the price of the app by $10 permanently if it was to always be included.
Acrobits are not the ones deciding the price. They didn't arbitrarily say "hey, it would be fun to make customers pay for G.729 separately!". That's a price set by G.729's patent owners. They license the codec to you, the user.
ANY phone app that gives you G.729 bundled for FREE is committing piracy and a patent violation. So Groundwire cannot give it out for free, sorry.
It's also a terrible codec anyway. G.729 is ONLY meant to be a low-bandwidth codec and is meant for corporate intranets with perfectly reliable Ethernet traffic. It has terrible jitter and latency tolerance, and is NOT meant for unstable networks (such as mobile 3G/4G networks).
For 3G/4G, you need a codec built for unstable networks and their high packet loss/jitter/latency. The best codecs for that include Opus, SILK, iLBC, Speex, and GSM, in that order. The best of them all is Opus, but MOST providers only support GSM (which as the name implies unsurprisingly sounds like a cellphone call quality-wise).
Unfortunately, some providers only support G711a/u and G729, in which case you have no choice to use any better codecs. In that case, G729 is definitely better (than G711) since it needs lower bandwidth, which is always important on 3G/4G. But it's still a terrible codec on 3G. Ugh. It's one of the most misunderstood and misused codecs ever made.
>>>* account balance is not shown for most VoIP providers (among them Betamax/Dellmont)
That's 100% up to the VoIP provider to fix. Has NOTHING to do with Groundwire.
The provider is the one that MUST send a SIP message with "account balance" details in it. If the provider doesn't send that, Groundwire doesn't show anything. If the provider sends that, Groundwire shows it!
If your provider does NOT support account balance (like yours don't), you can still go into "Web Services" for your account in Groundwire and configure a URL for a "Custom Balance Checker", which you can point to a script on your own server, which uses an API/login to query your provider about your balance, if your provider itself doesn't support giving out balance to Groundwire over SIP messaging.
I did exactly that for a great provider whose SIP messaging server has NOTHING to do with their billing server and hence their SIP server has NO IDEA what my "balance" is. So I wrote a script and hosted it on my own server, which queries my provider's API to check my balance, and returns the answer in Acrobits format. Then I set that as my "Custom Balance Checker" URL in my account in Groundwire. And voila, I see my balance. All thanks to Groundwire. NOT thanks to my provider (which didn't provide that info via the standardized SIP method!).
Here's the documentation I used as reference when making my balance checker script. It explains the XML format that Groundwire needs your custom script to return: https://www.acrobits.net/hesk/knowledge ... article=70
Actually writing a script which retrieves the balance from your provider and outputs the result in that XML format is up to you. The method differs at all providers. Good ones have APIs that let you use an API key to query them. Then you just write a script (and host it somewhere) which queries your provider's API and outputs the proper XML for Groundwire.
>>>* removing old registration bugs: when changing settings and registrations fail, not all old registrations were removed. (Found this after receiving a maximum of 4 registrations per IP error message)
I have no idea what this is but it's definitely fixed by now because I've never seen it. Various small bugs have always been quickly fixed by Acrobits. I'm very happy with Groundwire. They've got an incredible work ethic and are very organized and constantly improve their product. If there's a problem, write to their helpdesk, and you'll get professional and detailed replies, and if it's a bug it will be quickly taken care of. They are fantastic! :)
>>>* no ability to sent the log file to yourself
I just press the "Copy All" button to copy the whole log file, and then I paste it in Apple Mail and send it to myself.
Overall, Groundwire is a marvel of engineering and is the most advanced VoIP softphone in the world. Its deep configurability, extensive features and perfect PUSH notifications puts it FAR above the competition. I love it! Any issues people experience are almost always due to your VoIP provider. For instance, mine required me to use STUN lookup to give my provider my external IP, otherwise I had no incoming audio.
Using softphones with VoIP providers is always a "you're on your own" territory only meant for people with some technical skill. There's often small quirks with each different provider and their personal server behaviors.
A layman may scream "Groundwire sucks!". But the truth is that MY provider is the one that "sucks". Their NAT detection of automatic media proxying is broken. But by enabling STUN in Groundwire to find my phone's external IP, my provider's poor system is finally able to detect that I am behind a NAT firewall and starts proxying audio for me. So that I get two-way audio. And that's all thanks to Groundwire offering both a free STUN server and the option to use it! If they hadn't offered that, I'd have to change to a BETTER VoIP provider which doesn't need such workarounds. Groundwire has tons of features that lets it solve 99% of all PROVIDER-caused problems! ;-)
The truth is that most providers are going to work with the default settings in Groundwire. If they don't, it's actually the provider's fault. But that's why Groundwire has developed TONS of settings over the years, to let you tweak it to work with badly configured providers too (and there are many of those, since VoIP servers are so complex to configure and not all providers do it right). :)
I've been through testing every free VoIP (SIP) client for iOS, and all noteworthy paid ones, and Groundwire is so far above the competition that I wouldn't recommend anything else to anyone. It's the most powerful and most configurable client of all, and I'm incredibly happy with it! They have even graciously added features that I needed, such as the ability to display the cost (rate) of calls in the Groundwire GUI (via its new "Custom Rate Checker" Web Service feature)! :)
Discussion on iOS topics, like integration with iOS native Phone app and history using CallKit, Push Notifications for incoming calls, address book integration etc.
1 post • Page 1 of 1