Random audio loss after browsers update about rtpengine HOT 7 CLOSED

The assumption that Chrome mobile has a bug, remains. The audio is lost between 1:30 and 2:30 minutes of call duration, always. With FF mobile, it works.

from rtpengine.

Anything visible in the logs when this happens?

from rtpengine.

Could this be related to #47 and fixed by szcom's patch?

from rtpengine.

Absolutely nothing Richard. The only clue the log gives is that the "STUN binding" message stops when the bug hits.

I will give the patch a try.

Thank you for your help.

from rtpengine.

Hi Richard, Carlos!
I wonder what was the cause of the discussed issue, cos it is closed, and I do not completely understand how it has finished.

I'm asking, because currently have similar issue with chrome on android
(not to open new thread, I'll ask here, it seems not rtpengine problem, but I would appreciate any idea what could be wrong, as well I'm preparing bug request to chromium list now):

Setup:
UA-A sipjs based client running on chrome mobile (M48stable/M49dev) - 10.100.7.101
UA-B - sip phone
sip server - kamailio+rtpengine+asterisk - 10.100.1.85

Call script:
UA-A call UA-B
media exchange succesful, in some random moment of time both-way audio stops

in rtpengine log (debug 7) I see, that after log "Processing incoming DTLS packet", ICE stop working, media stops as well. The complete log here: https://gist.github.com/vance-od/a8539a03122f925dd550

In Chrome (chrome://webrtc-internals), when problem occurred I see (seems as Chrome for some reasons closed connection):

• stop
• IceConnectionStateChanged -> IceConnectionStateClosed
• signallingStateChanged -> SignalingStateClosed

The dump for the call here (done on the server's side) (there are only related packets, complete dump could be sent privately)
in trace I see everything is as common till receiving from Chrome "DTLSv1.0 Encrypted Alert"

When problem appear, there is no changes in signalling.

Any idea, with such issue?

from rtpengine.

"Encrypted alert" is a TLS message usually used to signal the closing of the connection. So this is expected when Chrome closes the connection. There's nothing in the log or the dump that would explain why it would do that.

from rtpengine.

as turned out, the problem is in android device, after screen off it stops media after 1 minute
It's a known issue under discussion, https://code.google.com/p/chromium/issues/detail?id=513633.

just for info, if anyone else will read this thread.

from rtpengine.