A single reported write error results in dead UDP transport

NEW
Unassigned

Status

()

Core
WebRTC: Networking
P3
normal
9 months ago
2 months ago

People

(Reporter: drno, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(firefox55 affected)

Details

(Reporter)

Description

9 months ago
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.
Priority: P2 → P3
You need to log in before you can comment on or make changes to this bug.