Constant repeated registration well below the registration timeout #570
Comments
|
From your logs, linphone doesn't try to register while doze mode is active ([Platform Helper] Device idle mode: true logs). There are indeed a lot of REGISTER sent but most of them are retransmissions because it wasn't acknowledged by the proxy. I know you don't want to hear about how UDP is bad but you might want to either check if your router doesn't have a SIP ALG enabled or switch to a more reliable protocol... The other REGISTER are triggered by network changes, in this case we have to send a new REGISTER with the correct contact information. |
|
Yes, they are re-transmissions because the application is not allowed to use the network. I can see this by sniffing right on the wireless AP that the phone is connected to. This is not a UDP or ALG problem. The packets don't get even that far. The AP does not even receive the packets because Android is not allowing them to be sent out because the phone is in Doze mode, where the network-allowed time is ~53 minutes after the top of very hour. But none of that answers the question of why linphone is even trying to register so frequently when it's been configured to use and is using (as evidenced by the "Expires: 172800" in the SIP transactions) a 48hr expiry. |
|
As I said, some of the REGISTER sent are trigger because the network you are connected to changes: |
|
Some other REGISTER are triggered because the LEAVE the doze mode, but there aren't any one sent while doze mode is enabled. |
|
The logging of Device idle mode (and Doze) in the linphone logs cannot be accurate. In the log I attached the most recent report of Doze mode is: There is no way that is the last time my phone entered Doze mode. It sat plugged in all night last night (2019-04-14 ~21:00:00 - 2019-04-15 ~06:00:00) completely untouched/unmoved/etc. It should have been Dozing most of that whole time.
The last occurrence of that in the log was: Followed by a successful registration: And yet there were another ~1870 So again, why so much registration? The one above at 2019-04-14 12:53:06:841 should have been all that was required for 48hrs after it. Why did this registration: only an hour later need to be done? |
|
What is this: That seems to be what prompted this attempted registration: that was unanswered because the phone was presumably in Doze mode and did not allow linphone to use the network. The above is followed by a storm of retries. |
|
We register a callback to the Android OS to be notified when the doze mode changes. |
|
I still don't think that is explaining why the frequent REGISTERs. What about the one in this comment above? It seems to have been triggered by: What is that message reporting? |
|
I asked around the office, it seems it is normal: the channel hasn't received data for a while, it goes to disconnect state that creates a new channel a does a register. |
|
But clearly that message (or rather the state that it's reporting) is what is causing linphone to re-REGISTER so frequently and particularly when it is in Doze mode causing it to continually re-transmit the REGISTERs. Surely as an app using belle-sip you need to understand what it means and how it affects the performance of a linphone port working on a device that has restrictions such as Android does. Hrm. I was going to go ask on belle-sip but I see they have disabled the issue tracker. What is the best means of communicating with them about this issue? |
|
@Viish You have previously reported that your linphone instances use a very small single digit of battery or less. Can you post a log of one of these so that I can see how a properly behaving linphone looks? |
|
@Viish It seems that this belle-sip timeout is this: which is accessed and set by this: Should linphone-android be setting this timeout equal to the Expiry? I would still be very interested in seeing the log of a linphone instance that uses small percentage of CPU to see how it functions in comparison to my device. |
|
@Viish So is that simply no, you won't post a log of a phone that runs linphone at a very few percentage of battery use? Can you comment on the above identified timeout? Surely given that you are all in the same GitHub organisation, there is somebody you can talk to that works on belle-sip about how you can influence the value of that timeout, yes? Particularly since I am getting zero response from the mailing list that they invite people to use to inquire about the SDK. |
|
@brianjmurrell Me not replying simply means I don't have time at the moment to handle your request. |
If you don't have time, but do intend to follow-through when you do have time saying as much would be helpful. But surely in the time it took to write a reply, surely you could have pressed Send Log in linphone and pasted the URL, no?
Would high battery use when using sip.linphone.org attract any more attention to the issue being described in this ticket? Because I don't believe this issue is particular to the use of a particular SIP server. The issue is with the app (including the stack it's built upon of course) itself and assumptions it is making about it's operating environment. Assumptions that may be valid when working on an always-connected (both power and network) "desktop" type devices but are not valid on frequently disconnected mobile, power-saving devices. But if using sip.linphone.org is the only way to prove that the issue is with linphone, I would be happy to do that. I just want to be sure before I go to that effort though, that the results will be looked at and acted upon. |
|
If you can provide logs that show an issue between linphone and our flexisip on sip.linphone.org, yes it will looked at and fixed. |
Wait! The logs that linphone-android uploads to the log server when (you request someone to send logs and) someone clicks About->Send Logs has private messages in them? Surely you can see the problem when you don't want to use a log-send facility that you expect others to use because you don't want your private messages uploaded, yes? Shouldn't the log-send functionality sanitise the log (or better yet the logging facilities not even log content/data) at least to the point where you would use it freely without concern? |
When you don't use end-to-end encryption, yes messages are transmitted in plain text, and are logged the same way.
Log upload isn't enabled by default, the server to which they are uploaded is configurable, and once you do upload them you are supposed to know what you do. Besides our company is the only people that have access to it.
This really isn't easy to do, and for some debug cases we need this information. |
Is E2E encryption relevant here? I think the issue is the inclusion of the message payloads in the logs that are being uploaded to the log server isn't it? How does E2E impact that one way or another?
Yes, understood, But it is as soon as you ask for a log because of a ticket for example.
I missed that configuration option. Where is it? But really, how many people are going to stand up their own server to cleanse the logs when they report a bug and are asked for logs from the About screen?
That you know of. ;-) Seriously though, why store data that you don't need to that puts you at risk of disclosing people's private information?
Some debug cases need access to message contents? I would thing that would be very rare, particularly where a randomised replacement (i.e. preserve the message length, etc. by randomly replacing characters in it with substitute characters) was done. Anyway, "Send Log" really ought to disclose to people that they are sending private message content to the server and for how long it will be stored there, etc. |
Yes it is. If you enable E2E encryption, the content of the messages will never appear anywhere, just an ecrypted blob will be visible. That's kinda the point.
In chat options, sharing server setting.
We don't store anything. We merely provide a sharing feature. Each uploaded file is deleted after a week. |
But given that linphone is one of the ends, it's not infeasible that the message contents were in the log before they got encrypted. Good to know that that is not the case.
Ahhh. I never really ventured very far into chat settings since my primary use-case is voice. But I see it now. It's not obvious though that Sharing server in Chat options is also where the debug log goes.
Yes you do...
That's storing, even if it's just for a week it' still being stored (i.e. at rest, probably unencrypted) and as such is at risk for that week. |
|
Will a linphone-android built from current master work with sip.linphone.org's push or do I need to use an APK built by you/linphone.org? |
|
Either one of them have push available |
Here's a log showing linphone spending a lot of battery on constantly trying to re-register even though though the expiry from an existing registration is nowhere near expired.
The problem with this is that while constantly trying to register, it seems that only one of them, every hour seems to make it onto the network. In the above log, it seem to be 53 minutes after every hour, Android allows access to the network to complete "house keeping".
In between those allowed network periods linphone spins trying to re-register, chewing up a lot of battery.
So this raises two issues. Why is linphone trying to do stuff outside of the Doze allotted housekeeping periods and why is it trying to register so frequently inside of a 172800s expiry period. It really has no reason to register so frequently when it knows that it's last registration is good for 48hrs.
The text was updated successfully, but these errors were encountered: