`Sending non-protected broadcast` - drop in audio


#1

Hello,

I have a periodic issue with the GSC3510 firmware 1.0.1.3 (and possibly in 1.0.1.5 but unconfirmed) where the audio on an active call is completely lost, and we lose contact with the phone until it finally re-registers a few minutes later. It looks like it probably has something to do with the Sending non-protected broadcast android.intent.action.ETHERNET_LINK_STATE_CHANGE logline in the logcat.

The log is here.

It might be worth mentioning, I see these errors even when a call is not in process and fairly regularly.

Could you help me diagnose what these logs mean? I suppose it could be a networking issue, but I’m not sure.

Thanks in advance.


#2

Hi,

Thank you for your logs. We will investigate the issue that you encountered. Also, if you can please try it on firmware v.1.0.1.5 as well. If you encountered the issue again, please send us the logcat and the syslog trace as well.

Thank you,


#3

I am still seeing this issue in various forms on the two different units I own where the audio drops unexpectedly. I’ve upgraded to v1.0.1.5 on both.

On the second unit, the problem occurs out of the blue at 19:01:41 https://gist.github.com/nickjackson/ff0196a6fd8cbf2157215eda658e3f19. This is a slightly different error than the first one I sent.

However, I’m seeing similar logs on the first unit still, even after upgrading.

I’m working on getting you the syslog, but I’m finding it difficult to catch the error at the moment. I will try and get this to you tomorrow.


#4

Hi,

We have the new Beta firmware v.1.0.1.6 that fixed some of the audio and multicast issue. Could you please test your issue on new firwmare v.1.0.1.6 and see if you can still reproduced it. Please capture the trace and have the syslog running during your testing so that way we can track down the cause of the issue.

You can find the latest Beta firmware v.1.0.1.6 right here:

Thank you,


#5

Thank you.

I have sent GS a support ticket (211831) with my 1.0.1.5 debug dump including syslog/pcap where the issue occurs. I will try and re-create with 1.0.1.6 today.

There is a chance that my SIP server is doing something that is causing the phones to crash, which the device logs aren’t revealing. Might there be a problem with using SIP Re-Invite at the minimum values with calls over an hour long? My goal here is to keep a call active as long as possible. In the event of a connection issue and the call fails, the device will drop the call when the session is up, allowing the server to re-establish a call with it ASAP.


#6

So far the new 1.0.1.6 firmware is holding up! I have managed to maintain a call for more than 2 hours now with no drops in audio.


#7

I spoke too soon! I’ve managed to hit this issue again with 1.0.1.6. It has happened on one of my units, on a call that was just over 5 hours long. I detected a drop in audio and at that time I can see network errors in the logcat. https://gist.github.com/nickjackson/e4fc3737fdf0a8cea0ffecd43cfbc364

At this time the syslog stops recording anything, and it appears some kind of reset happens.

After this, over the next 20 seconds, the syslog dumps tens of thousands of SIPStack::run: Active call dialogs (0): 1 debug/info lines where upon it looks like the device restarts again, where I can successfully re-establish a call to it.

I’ll update the ticket as well with the debug information.


#8

Hi,

Thank you for your feedback and syslog. We will notify our developers about this issue.