2034159 - We should probably let it slide when an ICE check has an XOR-MAPPED-ADDRESS that does not match the XOR-RELAYED-ADDRESS of the TURN allocation

Status: RESOLVED FIXED

(Core :: WebRTC: Networking, enhancement, P2)

Description

[Byron Campen [:bwc]]

There isn't really anything we can (or should) do when there's something doing port-mapping between the TURN server and the remote endpoint. It does not really make sense to create a prflx in this case I think, we should simply let the pair succeed. Otherwise, we'd have to do a non-standard prflx creation that scopes it to a specific TURN allocation.

Comment 1

[Byron Campen [:bwc]]

Attachment: Bug 2034159: Test cases where XOR-RELAYED-ADDRESS is not what we expect. r?dbaker

Also a little bit of DRY fixup.

Comment 2

[Byron Campen [:bwc]]

Attachment: Bug 2034159: Let XOR-RELAYED-ADDRESS mismatch slide. r?dbaker

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/6c78956fa236
https://hg.mozilla.org/integration/autoland/rev/7c757cd55268
Test cases where XOR-RELAYED-ADDRESS is not what we expect. r=dbaker

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/2080490e21fb
https://hg.mozilla.org/integration/autoland/rev/abec9d953e38
Revert "Bug 2034159: Test cases where XOR-RELAYED-ADDRESS is not what we expect. r=dbaker" for causing mda failures @ test_peerConnection_turnRelayedAddrMismatch.html

Comment 5

[Sandor Molnar[:smolnar]]

Backed out for causing mda failures @ test_peerConnection_turnRelayedAddrMismatch.html

Backout link: https://hg.mozilla.org/integration/autoland/rev/abec9d953e38d9e154f4e3d3a742b02ff4fd7b01

Push with failures

Failures log ->TEST-UNEXPECTED-FAIL | dom/media/webrtc/tests/mochitests/test_peerConnection_turnRelayedAddrMismatch.html

Comment 6

[Byron Campen [:bwc]]

Pilot error, only queued landing for tests. Trying to land both now.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/0697411a1265
https://hg.mozilla.org/integration/autoland/rev/fac87c9dd537
Test cases where XOR-RELAYED-ADDRESS is not what we expect. r=dbaker
https://github.com/mozilla-firefox/firefox/commit/6daed03d6955
https://hg.mozilla.org/integration/autoland/rev/b34910ebc6fc
Let XOR-RELAYED-ADDRESS mismatch slide. r=dbaker

Comment 8

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/fac87c9dd537
https://hg.mozilla.org/mozilla-central/rev/b34910ebc6fc

Comment 9

[Mike Kaply [:mkaply]]

What would a user friendly message about this be for enterprise release notes?

Do we know if this would affect other TURN issues (Jitsi?)

Comment 10

[Byron Campen [:bwc]]

Hmm... this is a pretty weird corner case, and one that only became apparent by careful inspection of a packet capture. "Support TURN deployments where NAT is applied to traffic forwarded by the TURN server." is about as short and sweet as I can come up with, but even someone knowledgeable scanning that sentence will need to do a double-take to realize that we're talking about NAT that is applied in the opposite direction it normally is.

I have no idea whether Jitsi has run into this problem. If you have some TURN issue reports from Jitsi (or others) and we can get a packet capture, I could determine whether this issue has popped up elsewhere.