While testing for bug 1337810 I found out that a single error while trying to write the network gets reported to NrSocket here: http://searchfox.org/mozilla-central/rev/1bc7720a434af3c13b68b8d69f92078cae8890c4/media/mtransport/nr_socket_prsock.cpp#840 which then turns that into a generic R_IO_ERROR independent of the type of error encountered. If that write was for a DTLS packet from the data channel this get translated into a generic PR_IO_ERROR here: http://searchfox.org/mozilla-central/rev/1bc7720a434af3c13b68b8d69f92078cae8890c4/media/mtransport/transportlayerdtls.cpp#123 Which then results in an NSS error here: http://searchfox.org/mozilla-central/rev/1bc7720a434af3c13b68b8d69f92078cae8890c4/security/nss/lib/ssl/ssl3con.c#2858 Which eventually then results in the MediaPipeline closing the underlying transport silently (= JS does not get informed about this) here: http://searchfox.org/mozilla-central/rev/1bc7720a434af3c13b68b8d69f92078cae8890c4/media/webrtc/signaling/src/mediapipeline/MediaPipeline.cpp#910 If I'm not mistaken ICE consent still works at this point and keeps refreshing the consent, because it is not affected by the closing of the upper layers. Since we have ICE consent support now and this about an unreliable transport I think a single write error should not result in closing the transport. At least not if the connection was working before (during connection setup might be a different story). The question is where and how to turn this into a "try again" error instead.
Mass change P2->P3 to align with new Mozilla triage process.