Bug 180842 – srflx and relay ICE candidates lack raddr (rel-addr) and rport (rel-port) attributes if getUserMedia access has not been granted

• Status: RESOLVED
• Resolution: FIXED
• Component: WebRTC

[Mark Roberts]

Reproduction Steps:

1. Create an RTCPeerConnection with STUN (and/or TURN) servers
2. Negotiate (doesn't matter if Safari offers or answers first)
3. Wait for ICE candidates

You can execute these steps using the following JSFiddle: https://jsfiddle.net/Lm7Lebz4/

Expected Result:

srflx and relay candidates include the raddr (rel-addr) and rport (rel-port) attributes required by RFC 5245, Section 15.1: https://tools.ietf.org/html/rfc5245#section-15.1

Actual Result:

srflx and relay candidates lack raddr and rport.

***

If you call `getUserMedia` before executing Steps 1–3 above, you will get a different result! raddr and rport will be present. These two cases are represented in the JSFiddle by the two buttons. Note: you may wish to simply copy the JavaScript from the JSFiddle, paste it into the browser console, and invoke `test(true)` or `test(false)` yourself, since calling `getUserMedia` first will trigger

> NotAllowedError (DOM Exception 35): The request is not allowed by the user agent or the platform in the current context, possibly because the user denied permission.

when invoked from JSFiddle.

***

Other notes: I'm investigating ICE failures between Safari and Firefox when Safari is not sharing any media. I'm not sure if this is the cause of the failure or a symptom of some other issue. This issue also resembles this WebRTC Issue 1202: https://bugs.chromium.org/p/webrtc/issues/detail?id=1202

[youenn fablet]

Hi Mark, thanks for the report.
host candidates are filtered out for privacy reasons and so are raddr/rport information on reflexive and relay candidates.

I would be interested to know whether this causes any actual issue.

[Mark Roberts]

Hi Youenn,

Thanks for the quick response.

> host candidates are filtered out for privacy reasons

Yes, this is what I expected. I think I remember you mentioning this at Kranky Geek. IMO, there should be no problem there.

> and so are raddr/rport information on reflexive and relay candidates.

However, this seems to be the source of the interop problem with Firefox. If I write a little function to patch these up before sending them out:

  function patchIceCandidate(candidate) {
    var candidateStr = candidate.candidate;                                          
    var type = candidateStr.match(/typ ([^ ]*)/)[1];                                 
    switch (type) {                                                                  
      case 'srflx':                                                                  
      case 'prflx':                                                                  
      case 'relay':                                                                  
        var raddr = candidateStr.match(/raddr ([^ ]*)/);                             
        var rport = candidateStr.match(/rport ([^ ]*)/);                             
        if (!raddr || !rport) {                                                      
          console.warn(type + ' ICE candidate lacks raddr and/or rport: ' + candidateStr);
          if (!raddr) {                                                              
            candidateStr = candidateStr.replace('generation', 'raddr 0.0.0.0 generation');
          }                                                                          
          if (!rport) {                                                              
            candidateStr = candidateStr.replace('generation', 'rport 0 generation');
          }                                                                          
          candidate = new RTCIceCandidate({                                          
            candidate: candidateStr,                                                 
            sdpMid: candidate.sdpMid,                                                
            sdpMLineIndex: candidate.sdpMLineIndex                                   
          });                                                                        
        }                                                                            
      default:                                                                       
        break;                                                                       
    }
    return candidate;
  }

Then there are no more ICE failures in Firefox.

I can understand filtering the raddr and rport attributes if they include sensitive information; however, I suppose Firefox may be a bit stricter in its parsing of ICE candidates (since technically raddr and rport are required). Strangely, though, it doesn't raise an error. I will probably open an issue with them next.

Also, I can understand filtering the raddr and rport attributes if they includes sensitive information; however, in the test I shared, I see they are just set to 0.0.0.0 and 0 _if `getUserMedia` was previously called_ (note that it doesn't matter if the resulting MediaStreamTracks are added to any RTCPeerConnections or not). So maybe instead of filtering, Safari could use these dummy values?

Thanks!
Mark

[Mark Roberts]

Here is an example error in Firefox's about:webrtc under "Connection Log" when such an ICE candidate is provided by Safari:

> ICE(PC:1513292453729479 (id=2147483657 url=https://simpler-signaling.appspot.com/?iceTransportPolicy=relay)): Error parsing attribute: candidate:1735000762 1 udp 33562623 34.203.251.116 58685 typ relay generation 0 ufrag 4S1R network-cost 50

[youenn fablet]

Created attachment 329409 [details]
Patch

[WebKit Commit Bot]

Comment on attachment 329409 [details]
Patch

Clearing flags on attachment: 329409

Committed r225955: <https://trac.webkit.org/changeset/225955>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Radar WebKit Bug Importer]

<rdar://problem/36064667>