User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:48.0) Gecko/20100101 Firefox/48.0 Build ID: 20160325083832 Steps to reproduce: Using FireFOX to call FreeSWITCH when browser and FreeSWITCH are both on RFC1918 addresses inside the same VPN. Actual results: The media never establishes. FreeSWITCH is sending STUN to the browser but the browser never sends anything to FreeSWITCH. The logs below seem to indicate it has invalidated the candidate. Skipping SOURCE-ADDRESS Skipping CHANGED-ADDRESS Translating obsolete XOR-MAPPED-ADDRESS type STUN-CLIENT(srflx(IP4:10.0.1.244:62148/UDP|IP4:23.21.150.121:3478/UDP)): Received response; processing Skipping SOURCE-ADDRESS Skipping CHANGED-ADDRESS Translating obsolete XOR-MAPPED-ADDRESS type STUN-CLIENT(srflx(IP4:10.0.1.244:63570/UDP|IP4:23.21.150.121:3478/UDP)): Received response; processing Skipping SOURCE-ADDRESS Skipping CHANGED-ADDRESS Translating obsolete XOR-MAPPED-ADDRESS type STUN-CLIENT(srflx(IP4:10.0.1.244:51453/UDP|IP4:23.21.150.121:3478/UDP)): Received response; processing Skipping SOURCE-ADDRESS Skipping CHANGED-ADDRESS Translating obsolete XOR-MAPPED-ADDRESS type STUN-CLIENT(srflx(IP4:10.0.1.244:57682/UDP|IP4:23.21.150.121:3478/UDP)): Received response; processing ICE(PC:1458939387755144 (id=2147483652 url=https://tatooine.freeswitch.org/vc/#/incall)): peer (PC:1458939387755144 (id=2147483652 url=https://tatooine.freeswitch.org/vc/#/incall):default) no streams with non-empty check lists ICE(PC:1458939387755144 (id=2147483652 url=https://tatooine.freeswitch.org/vc/#/incall)): peer (PC:1458939387755144 (id=2147483652 url=https://tatooine.freeswitch.org/vc/#/incall):default) no streams with pre-answer requests ICE(PC:1458939387755144 (id=2147483652 url=https://tatooine.freeswitch.org/vc/#/incall)): peer (PC:1458939387755144 (id=2147483652 url=https://tatooine.freeswitch.org/vc/#/incall):default) no streams with pre-answer requests ICE(PC:1458939387755144 (id=2147483652 url=https://tatooine.freeswitch.org/vc/#/incall)): peer (PC:1458939387755144 (id=2147483652 url=https://tatooine.freeswitch.org/vc/#/incall):default) no checks to start +++++++ END ++++++++ SDP Local SDP v=0 o=mozilla...THIS_IS_SDPARTA-48.0a1 2759140803459984214 0 IN IP4 0.0.0.0 s=- t=0 0 a=sendrecv a=fingerprint:sha-256 43:9B:BD:21:E0:2D:87:BC:A3:00:9C:34:BB:5B:DE:70:ED:D5:F7:53:FC:39:CF:6C:C7:16:E7:02:E2:A9:51:36 a=group:BUNDLE sdparta_0 sdparta_1 a=ice-options:trickle a=msid-semantic:WMS * m=audio 22944 UDP/TLS/RTP/SAVPF 109 9 0 8 c=IN IP4 75.86.245.139 a=candidate:0 1 UDP 2122252543 10.0.1.244 62148 typ host a=candidate:0 2 UDP 2122252542 10.0.1.244 63570 typ host a=candidate:1 1 UDP 1686052863 75.86.245.139 22944 typ srflx raddr 10.0.1.244 rport 62148 a=candidate:1 2 UDP 1686052862 75.86.245.139 26838 typ srflx raddr 10.0.1.244 rport 63570 a=sendrecv a=end-of-candidates a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=fmtp:109 maxplaybackrate=48000;stereo=1 a=ice-pwd:206cdca731a7ca35c94709eb3855adb1 a=ice-ufrag:a88c943a a=mid:sdparta_0 a=msid:{9d24da37-5999-cc43-9e2f-0e7a1770ab07} {23e3f368-6445-b840-bb7f-5603ac1ef378} a=rtcp:26838 IN IP4 75.86.245.139 a=rtcp-mux a=rtpmap:109 opus/48000/2 a=rtpmap:9 G722/8000/1 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=setup:actpass a=ssrc:82831066 cname:{013d44ec-837e-6e4b-afdb-47afdba58223} m=video 8250 UDP/TLS/RTP/SAVPF 120 126 97 c=IN IP4 75.86.245.139 a=candidate:0 1 UDP 2122252543 10.0.1.244 51453 typ host a=candidate:0 2 UDP 2122252542 10.0.1.244 57682 typ host a=candidate:1 1 UDP 1686052863 75.86.245.139 8250 typ srflx raddr 10.0.1.244 rport 51453 a=candidate:1 2 UDP 1686052862 75.86.245.139 48262 typ srflx raddr 10.0.1.244 rport 57682 a=sendrecv a=end-of-candidates a=fmtp:126 profile-level-id=42e01f;level-asymmetry-allowed=1;packetization-mode=1 a=fmtp:97 profile-level-id=42e01f;level-asymmetry-allowed=1 a=fmtp:120 max-fs=12288;max-fr=60 a=ice-pwd:206cdca731a7ca35c94709eb3855adb1 a=ice-ufrag:a88c943a a=mid:sdparta_1 a=msid:{9d24da37-5999-cc43-9e2f-0e7a1770ab07} {3c01207e-4c21-9d40-96ad-caa919a7a7e6} a=rtcp:48262 IN IP4 75.86.245.139 a=rtcp-fb:120 nack a=rtcp-fb:120 nack pli a=rtcp-fb:120 ccm fir a=rtcp-fb:120 ccm tmmbr a=rtcp-fb:120 ccm tmmbr a=rtcp-fb:120 ccm tmmbr a=rtcp-fb:126 nack a=rtcp-fb:126 nack pli a=rtcp-fb:126 ccm fir a=rtcp-fb:126 ccm tmmbr a=rtcp-fb:126 ccm tmmbr a=rtcp-fb:126 ccm tmmbr a=rtcp-fb:97 nack a=rtcp-fb:97 nack pli a=rtcp-fb:97 ccm fir a=rtcp-fb:97 ccm tmmbr a=rtcp-fb:97 ccm tmmbr a=rtcp-fb:97 ccm tmmbr a=rtcp-mux a=rtpmap:120 VP8/90000 a=rtpmap:126 H264/90000 a=rtpmap:97 H264/90000 a=setup:actpass a=ssrc:3668731717 cname:{013d44ec-837e-6e4b-afdb-47afdba58223} Remote SDP v=0 o=FreeSWITCH 1458914567 1458914568 IN IP4 192.168.168.35 s=- t=0 0 a=sendrecv a=msid-semantic:WMS YPB1HGqQhIkJdHmABL2LbnwsplshOs7D m=audio 24972 UDP/TLS/RTP/SAVPF 109 c=IN IP4 192.168.168.35 a=candidate:5356027944 1 udp 659136 192.168.168.35 24972 typ host generation 0 a=sendrecv a=fingerprint:sha-256 FE:F6:03:7A:41:1E:D0:31:75:98:84:A3:53:32:D1:22:7E:CD:99:2F:23:B3:D2:37:B2:9B:20:C6:44:A2:A9:AC a=fmtp:109 maxplaybackrate=0;stereo=1 a=ice-pwd:D6ZyIbBTyd7t1LPriNS36B3A a=ice-ufrag:zH7AUtTaEchivfLt a=ptime:20 a=rtcp:24972 IN IP4 192.168.168.35 a=rtcp-mux a=rtpmap:109 opus/48000/2 a=setup:active a=ssrc:586798195 cname:8yuF4LmckxLo4YOw a=ssrc:586798195 msid:YPB1HGqQhIkJdHmABL2LbnwsplshOs7D a0 a=ssrc:586798195 mslabel:YPB1HGqQhIkJdHmABL2LbnwsplshOs7D a=ssrc:586798195 label:YPB1HGqQhIkJdHmABL2LbnwsplshOs7Da0 m=video 20688 UDP/TLS/RTP/SAVPF 120 c=IN IP4 192.168.168.35 b=AS:3540 a=candidate:9855561818 1 udp 659136 192.168.168.35 20688 typ host generation 0 a=sendrecv a=fingerprint:sha-256 FE:F6:03:7A:41:1E:D0:31:75:98:84:A3:53:32:D1:22:7E:CD:99:2F:23:B3:D2:37:B2:9B:20:C6:44:A2:A9:AC a=fmtp:120 max-fs=0;max-fr=0 a=ice-pwd:DambQcgTSe4mVwW5N3XSx7Xz a=ice-ufrag:jrg2eDjebSrlb8eM a=rtcp:20688 IN IP4 192.168.168.35 a=rtcp-fb:120 ccm fir a=rtcp-fb:120 ccm tmmbr a=rtcp-fb:120 nack a=rtcp-fb:120 nack pli a=rtcp-mux a=rtpmap:120 VP8/90000 a=setup:active a=ssrc:4152316601 cname:8yuF4LmckxLo4YOw a=ssrc:4152316601 msid:YPB1HGqQhIkJdHmABL2LbnwsplshOs7D v0 a=ssrc:4152316601 mslabel:YPB1HGqQhIkJdHmABL2LbnwsplshOs7D a=ssrc:4152316601 label:YPB1HGqQhIkJdHmABL2LbnwsplshOs7Dv0 RTP Stats inbound_rtp_audio_0 Local: 15:56:31 GMT-0500 (CDT) inboundrtp SSRC: 0 inbound_rtp_video_1 Local: 15:56:31 GMT-0500 (CDT) inboundrtp SSRC: 0 outbound_rtp_audio_0 Local: 15:56:31 GMT-0500 (CDT) outboundrtp SSRC: 82831066 outbound_rtp_video_1 Local: 15:56:31 GMT-0500 (CDT) outboundrtp SSRC: 3668731717 Expected results: When I use the same version calling when FreeSWITCH is on a public IP, it works. I an not positive that the private IP is the exact problem but its the most obvious difference I can find so far. This has worked in previous versions. I just periodically tried latest nightly and discovered it was not working anymore. It continues to work on my public server. This instance I was testing on is my dev box behind a VPN.

This is works as designed per bug 1219557.

After chatting on IRC, I had a suggestion to allow this behavior when there is only one remote candidate to choose from or maybe when 100% of the remote candidates are RFC1918.

That is actually a neat idea. The problem though is to know when trickle ICE is over. Even in the case where the ICE candidates come in via the SDP I'm pretty sure we don't know for sure if we have seen/received all candidates (I'm guessing that we pass the candidates from the SDP the same way as we do after getting them via the JS API). One idea I could see working is that if we get the end-of-trickle indicator, that then we could look at the received candidates and pair them one more time without the RFC1918 restriction if we hadn't paired anything yet. But that would only work for you if you would include end-of-trickle indicator into the FreeSwitch SDP.

How does that look? I can easily add that because we always send 100% of our candidates at once.

Found the draft and implemented the attribute based on this statement from section 9.3 of the draft: "When end-of-candidates is sent as part of an offer or an answer it can appear as a session-level attribute, which would be equivalent to having it appear in all m-lines." https://freeswitch.org/jira/browse/FS-8992

Nils: As part of comment #3, you mentioned about the following: One idea I could see working is that if we get the end-of-trickle indicator, that then we could look at the received candidates and pair them one more time without the RFC1918 restriction if we hadn't paired anything yet. But that would only work for you if you would include end-of-trickle indicator into the FreeSwitch SDP. Is this suggestion works with FF45 or is this a solution (that the other vendors should add to their webrtc peer side) for the fix that you are going to add in FF48? This is not clear to me. -KMurali

That is the idea for a potential solution to be implemented in Firefox. If I'm not mistaken we will have to implement support for an end-of-trickle indicator any way. But it turned out to be more effort then I thought. So currently I'm more leaning towards adding a user preference to turn off the RFC1918 pairing restriction.

My 2 cents, you already have 3 or so duplicates on this which probably represent people who had it working so its possible its more popular of a setup than anticipated. But either way, I have already implemented end of ice in FreeSWITCH explicitly just in case. So lack of a=trickle and presence of a=end-of-candidates and only 1 candidate should be overwhelming evidence to not enable this filter. I was basically trying to do some more interop with my FreeSWITCH stack against FF but I can't call my dev box anymore so I got distracted from it so however you want to fix it is ok with me.

Review commit: https://reviewboard.mozilla.org/r/46899/diff/#index_header See other reviews: https://reviewboard.mozilla.org/r/46899/

Michael, Byron: who ever gets to it first. Don't need two reviews :-) Anthony you are right. I'll simply disable this non-standard behavior for now. Which also makes it easier to uplift. And then we can come up with a better solution later.

Another possible solution (for a follow up bug - an alternative to the more involved approach from comment #3): we simply cheat when computing the priority for a pair which contains two RFC1918 addresses from different subnets and give such a pair the worst priority possible. Hopefully that should give server reflexive and relay pairs higher priority, but in case there are no such pairs we at least would still generate a pair. Martin what do you think?

That sounds reasonable. That there is a route from one 1918 range to another is surprising, but, as we discussed, only improbable. Giving those low priority should be OK. I wouldn't give them lower priority than relay pairs though. If there is a route, then we would want to use that over a relay. Maybe in the same class as server reflexive, or even just above.

Comment on attachment 8742015 [details] MozReview Request: Bug 1259842: allow RFC1918 pairing again https://reviewboard.mozilla.org/r/46899/#review43679 ::: media/mtransport/third_party/nICEr/src/ice/ice_component.c:994 (Diff revision 1) > /* local vs. remote matters here because we allow private -> public pairing, > * but discourage public -> private pairing. */ Does this comment apply now that the private_addr_range check is no longer done?

Comment on attachment 8742015 [details] MozReview Request: Bug 1259842: allow RFC1918 pairing again Review request updated; see interdiff: https://reviewboard.mozilla.org/r/46899/diff/1-2/

Comment on attachment 8742015 [details] MozReview Request: Bug 1259842: allow RFC1918 pairing again https://reviewboard.mozilla.org/r/46899/#review43791 Looks good to me!

Comment on attachment 8742015 [details] MozReview Request: Bug 1259842: allow RFC1918 pairing again Approval Request Comment [Feature/regressing bug #]: We introduced the problem in bug 1219557. [User impact if declined]: According to the bug reports 1259842, 1257052 and 1264803 WebRTC developers and some enterprise calling services are hindered or even blocked from their development or using their in-house calling service. [Describe test coverage new/current, TreeHerder]: As this patch is turning off the new behavior and reverts back to the old/previous behavior there are no new test coverage (new tests have been disabled). [Risks and why]: As the patch simply removes one new feature and thus reverts back to the previous behavior before bug 1219557 landed the risk is pretty low. [String/UUID change made/needed]: N/A

Nils: Based on the discussion for this issue, for me it looks like more and more vendors are going to hit this issue as some of their enterprise calling service is going to fail when they try with FF45. Still I see this reverting fix was committed to FF48. Is there is a chance of providing a patch for this in FF45 or fix for FF46 or FF47??? Or do you have or any suggestion that you can provide as a workaround for this issue before we receive the version with the fix. -KMurali

Comment on attachment 8742015 [details] MozReview Request: Bug 1259842: allow RFC1918 pairing again [Triage Comment] Reverting to previous behavior, please uplift to aurora, beta, m-r

This won't be in RC1 but if we do a 46 rc2 later in the week it can be included.

has problems to apply to aurora Tomcats-MacBook-Pro-2:mozilla-central Tomcat$ hg graft --edit -r cf48c9ea48e3 grafting 340365:cf48c9ea48e3 "Bug 1259842: allow RFC1918 pairing again r=mjf" merging media/mtransport/test/ice_unittest.cpp merging media/mtransport/third_party/nICEr/src/ice/ice_component.c warning: conflicts while merging media/mtransport/test/ice_unittest.cpp! (edit, then use 'hg resolve --mark') abort: unresolved conflicts, can't continue (use hg resolve and hg graft --continue)

Rebased patch for Fx 47

Working on patches for 46 and 45...

Rebase for Fx 46

So attachment 8742935 [details] [diff] [review] also applies cleanly to 45.

46 releases next Tuesday. So a patch for 45 doesn't seem useful. Let's land this for 46 asap.

https://hg.mozilla.org/releases/mozilla-release/rev/7de9de17ccde07357b8c3be144998a2c4c0e2a69 https://hg.mozilla.org/releases/mozilla-beta/rev/bbbd40c84bae41a1376fb95355d3147604b80ddf https://hg.mozilla.org/releases/mozilla-aurora/rev/9dec4e0f5080d9a614a427697e17dcd7515147d4