I have a periodic issue with the GSC3510 firmware 22.214.171.124 (and possibly in 126.96.36.199 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.
Thank you for your logs. We will investigate the issue that you encountered. Also, if you can please try it on firmware v.188.8.131.52 as well. If you encountered the issue again, please send us the logcat and the syslog trace as well.
We have the new Beta firmware v.184.108.40.206 that fixed some of the audio and multicast issue. Could you please test your issue on new firwmare v.220.127.116.11 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.18.104.22.168 right here:
I have sent GS a support ticket (211831) with my 22.214.171.124 debug dump including syslog/pcap where the issue occurs. I will try and re-create with 126.96.36.199 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.
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.