Reviews:
 ·voip.ms
| [Voip.ms] Issue with Bria softphone failing to stay registered - Okay before I open a trouble ticket with VoIP.ms on this one, I wanted to see if anyone here has the setup I do and has run into (and solved) the issue I'm having.
The problem:
I run the Bria softphone on both my iPhone4 and my iPad (3rd gen) I have run into an issue recently where the iPhone4 seems to drop registration without any indication from the Bria software that this is happening, meaning that calls go to voicemail.
When I check on the Voip.ms website when this is happening, it says that the main account on the iPhone is unregistered, but if I use the phone (say *97 and then refresh the website) I'm noted as registered again and calls will ring to it for some time until it (again) silently unregisters and will not register itself again until I use the Bria software to make contact with the voiup.ms account.
Meanwhile, the iPad which is the sub account stays registered as long as it has a wifi signal and will properly re-register if it goes out of and then comes back in range of an accessible wifi signal.
Both the main and sub accounts are registered to the montreal2 server.
I went to the voip.ms wiki and the entry for the Bria softphone only mentions the Android version of the software all references to the settings for iOS are gone.
Any suggestions?
NefCanuck |
|
|
|
decxPremium
join:2002-06-07
Vancouver, BC | Re: [Voip.ms] Issue with Bria softphone failing to stay register Is the iPhone/iPad dropping the connection while it's in standby? If so it's expected behaviour from iOS as apps running in background aren't allowed to continue sending network traffic at sufficient intervals to keep the softphone registered. Also iOS does not wake on receipt of UDP traffic so incoming calls would not wake the device.
The only two options to get SIP working properly on iOS at this point is to either get a softphone that supports push notification like the two Acrobits softphones (you need to provide the third party with your SIP credentials) or use one that can force itself to run continuously in the background like Zoiper (which will shorten battery life dramatically reducing it to just a few hours). Neither options are perfect but Apple's restrictive rules doesn't leave much options. |
|
 crazyk4952Premium
join:2002-02-04
united state
kudos:1
 ·Charter
·Callcentric
·Vitelity VOIP
·voip.ms
| reply to NefCanuck
Under the settings for your voip.ms account >> Account Advanced, what are the values for the following settings:
SIP Registration
-Incoming Calls (On/Off):
-Refresh Interval:
Keep Alive
-Wi-Fi Interval:
-Mobile Interval: |
|
crazyk4952Premium
join:2002-02-04
united state
kudos:1 | reply to NefCanuck
Also, verify the following settings are set under Preferences:
Mobile Data Network
-Use When Available: ON
General
-Run In Background: ON |
|
decxPremium
join:2002-06-07
Vancouver, BC | All those options force Bria to run continuously in the background and will run the battery dry. It works, but it means you'll need to plug in your iDevice often. |
|
crazyk4952Premium
join:2002-02-04
united state
kudos:1 Reviews:
·Charter
·Callcentric
·Vitelity VOIP
·voip.ms
| said by decx:All those options force Bria to run continuously in the background and will run the battery dry. It works, but it means you'll need to plug in your iDevice often.
Yes, but the OP wants to be able to receive incoming calls using the Bria app. Having it run in the background is the only way that I know of that will allow this. |
|
OZOPremium
join:2003-01-17
kudos:2 | reply to NefCanuck
When you're behind a NAT router, your phone sends REGISTER requests on a regular basis. Those UDP packets create a record in NAT table, that allows for a while to receive packets back. After some timeout (usually 3 min) those records in NAT router are removed. And if it happens, your phone may think it's still registered, your VoIP.ms server thinks the phone is still registered. But if a new call arrives and SIP server tries actually to send INVITE packets to your phone, NAT router silently drops those packets and our phone misses the call. Thus, it's important for your phone to send special small packets to SIP server (they usually call them "keep alive" packets) on a regular basis at interval, that is shorter then time NAT table keeps own its internal records.
Make sure that your phone does it.
--
Keep it simple, it'll become complex by itself... |
|
decxPremium
join:2002-06-07
Vancouver, BC | reply to crazyk4952
said by crazyk4952:said by decx:All those options force Bria to run continuously in the background and will run the battery dry. It works, but it means you'll need to plug in your iDevice often.
Yes, but the OP wants to be able to receive incoming calls using the Bria app. Having it run in the background is the only way that I know of that will allow this. Well yes, but from experience it's not practical. It did that for a few days a few months back and now I just set Voip.ms to forward my calls instead. The reason is that while I was able receive incoming VoIP calls, I also ended up missing calls as I ended up running out of juice in less than half a day. So while running the background does indeed let the OP do what he requested, unless he's always tethered, he'll be sacrificing everything else he does on his iDevice just to allow incoming VoIP calls to get through. |
|
Reviews:
·voip.ms
| reply to decx
said by decx:All those options force Bria to run continuously in the background and will run the battery dry. It works, but it means you'll need to plug in your iDevice often.
That's okay, I have the means to keep the iDevice charged during the day when I'm out (at work I just plug into a USB port, have a USB port in the car and have a backup solar battery I can hook to the iPhone as I need it.
Turns out that the SIP registration was set on the iPhone to 900 seconds. I knocked it down to 120 seconds (is that overly aggressive?) which has done the trick at the expense of battery life.
NefCanuck |
|
OZOPremium
join:2003-01-17
kudos:2 | What you're doing is using REGISTER requests to keep NAT hole alive. But that's why there are KA packets for. The difference is:
1. KA packets are small (usually 2 bytes, 66 bytes on wire)
2. Registration process requires at least 4 big packets to be exchanged between SIP server and client.
Keep in mind, that if you use small KA packet, it goes solo and only in one direction - from your client to SIP server, no response is required. And that makes the difference in your battery life. Using registration procedure to keep NAT hole alive, on the other hand, is less effective than sending KA packets, specifically designed to do that job...
I'd keep registration timeout unchanged and make sure that KA packets are sent every two minutes.
--
Keep it simple, it'll become complex by itself... |
|
Reviews:
·voip.ms
| said by OZO:What you're doing is using REGISTER requests to keep NAT hole alive. But that's why there are KA packets for. The difference is:
1. KA packets are small (usually 2 bytes, 66 bytes on wire)
2. Registration process requires at least 4 big packets to be exchanged between SIP server and client.
Keep in mind, that if you use small KA packet, it goes solo and only in one direction - from your client to SIP server, no response is required. And that makes the difference in your battery life. Using registration procedure to keep NAT hole alive, on the other hand, is less effective than sending KA packets, specifically designed to do that job...
I'd keep registration timeout unchanged and make sure that KA packets are sent every two minutes.
I had the KA packets set at 9 seconds and that wasn't doing the job, does that make sense?
NefCanuck |
|
OZOPremium
join:2003-01-17
kudos:2 | No. KA packets should go at time, just a bit less, then NAT closing hole timeout. For example if your NAT closes hole in 180 sec, KA should be sent, let say, every 150-160 sec.
--
Keep it simple, it'll become complex by itself... |
|
Reviews:
·voip.ms
| reply to NefCanuck
Here's an update and I don't understand the results.
Upgraded to an iPhone 5, did a restore from the last backup from the iPhone 4 and now the Bria softphone is staying registered while on wifi without issue and (so far) seems to be okay while out and about on 3G/LTE as well.
Can anyone explain this?
NefCanuck |
|
Reviews:
·Google Voice
·Junction Networks
·Callcentric
 ·T-Mobile US
 ·AT&T U-Verse
| reply to decx
Bria softphone is battery-hungry by design due to no APNS said by decx:said by crazyk4952:said by decx:All those options force Bria to run continuously in the background and will run the battery dry. It works, but it means you'll need to plug in your iDevice often.
Yes, but the OP wants to be able to receive incoming calls using the Bria app. Having it run in the background is the only way that I know of that will allow this. Well yes, but from experience it's not practical. It did that for a few days a few months back and now I just set Voip.ms to forward my calls instead. The reason is that while I was able receive incoming VoIP calls, I also ended up missing calls as I ended up running out of juice in less than half a day. So while running the background does indeed let the OP do what he requested, unless he's always tethered, he'll be sacrificing everything else he does on his iDevice just to allow incoming VoIP calls to get through. Any specific reason you're using Bria by CounterPath instead of Groundwire by Acrobits on your iOS?
Acrobits lets you use APNS; which basically means that the Acrobits server in Virginia (on Amazon EC2) registers with your SIP provider, and when you receive a call, it makes a push notification through APNS to Apple, and APNS delivers it to your phone and then your app, and the app doesn't even have to run in the background prior to you receiving this notification.
This means that battery life is literally unaffected at all, since APNS is always active and is already used by other services. Apple makes sure that APNS is working properly no matter whether you are on WiFi or 3G, or 2G, so you don't have to worry about any timeout numbers or values, or switcing between WiFi and 3G, or having WiFi during standby (APNS automatically disables WiFi during standby when 3G is available, conserving battery life, what about Bria?). Both Acrobits apps, Groundwire and Softphone, support APNS; CounterPath supposedly has the same thing implemented, but they don't provide it to individual customers in Bria — only to operators that want to have their own branded app by CounterPath.
I've been using Groundwire for more than a year, and I find it very reliable and offering a great battery life; although I do like Bria's design better (yellow and black are awesome colours, plus they're a Canadian company), Bria's dismal battery life just isn't worth it.
Don't waste more time on dead batteries or missed calls just to spare the price of a more competent softphone solution. iOS APNS makes a huge difference on battery life and has great reliability (plus starting an app from scratch on new iPhones is probably uber fast anyways, so, always running it in the background makes even less sense), and your phone will ALWAYS be registered (else, you could go and blame Apple!). |
|
Reviews:
·Google Voice
·Junction Networks
·Callcentric
·T-Mobile US
·AT&T U-Verse
| reply to OZO
UDP vs TCP in NAT traversal said by OZO:When you're behind a NAT router, your phone sends REGISTER requests on a regular basis. Those UDP packets create a record in NAT table, that allows for a while to receive packets back. After some timeout (usually 3 min) those records in NAT router are removed. It deserves to be pointed out that such entries are removed after about 3 minutes only in case of UDP; TCP entries are never removed so quickly. More details here (applies equally to iOS, plus iOS already has "future" that's called APNS, onto which apps can piggyback their keep-alive transmissions): » code.google.com/p/sipdroid/wiki/···echniqueLemme quote: said by »code.google.com/p/sipdroid/wiki/···raversal :
Protocol Timeout
UDP 40s to 300s
TCP 30min to 1440min
('Nuff said.) And here: » Providers that support [TCP] and multiple [SIP] regisrationsDo note that on iOS, APNS is still a solution superior to mere SIP/TCP, just as Sipdroid developers contemplate that in the future they would like to piggyback onto another reliable connection instead of keeping their own, thus saving even more on battery life. Out of generic (unlocked) SIP clients, I'm only aware of two apps, Groundwire and Softphone, both by Acrobits, that provide free APNS once you buy the app. I bought both Groundwire and Bria, and Groundwire with APNS works great for incoming calls, almost never use Bria nowadays. |
|
