It may be, as the streams we tried this on were indeed recvonly, but this raises the question why the same works with a recvonly stream on a PeerConnection that does support rtcp-mux instead. I guess that, since for the non-rtcp-mux PeerConnection the RTCP connection has the CreatePermission correctly sent (maybe because, unlike RTP, RTCP packets are also sent and not only received?) the same "saves" the muxed PeerConnection as a whole as well.
When I left the lab my colleagues were starting doing some tests with sendrecv and non-rtcp-mux, but I haven't asked for some up-to-date feedback yet. I'll let you know if it works there. Lorenzo Il giorno martedì 4 novembre 2014 20:08:05 UTC+1, Byron Campen ha scritto: > Might be this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=935806 > > Best regards, > Byron Campen > > On 11/4/14 7:50 AM, Lorenzo Miniero wrote: > > Hi, > > > > we encountered a weird issue with both Firefox stable and Firefox Nightly > > in our setup. Specifically, some sessions involving TURN seem to stop > > working after 5 minutes: this is consistent with what is specified in > > RFC5766 with respect to permissions, and in fact we can confirm that, for > > the streams where it happens, there's no CreatePermission refresh before > > the 5 minutes timeout, which results in the TURN server to stop relaying > > data to the client. > > > > By digging a bit deeper in the issue, we noticed a couple of things: > > > > 1) it did always happen when calling Asterisk, which does NOT support > > rtcp-mux: using Wireshark we managed to see that the CreatePermission is > > indeed sent for the RTCP channel, but NOT for the RTP one, and in fact > > audio stops working after 5 minutes; > > > > 2) it seems NOT to happen with peers that DO support rtcp-mux (e.g., > > our WebRTC gateway); one of our engineers allegedly met the same issue in a > > few scenarios there as well yesterday, but we couldn't replicate it today > > so I'd rule this out. > > > > For all of the tests we used the popular rfc-5766-turn-server > > implementation, and the issue does not occur on Chrome which apparently > > excludes configuration issues there. > > > > What may be going wrong? Is this indeed a bug in the TURN implementation in > > Firefox, or should I look into something different? Is there any > > information I can share to help you understand what's the issue? > > > > Thanks, > > Lorenzo > > _______________________________________________ > > dev-media mailing list > > [email protected] > > https://lists.mozilla.org/listinfo/dev-media _______________________________________________ dev-media mailing list [email protected] https://lists.mozilla.org/listinfo/dev-media
