[rtcweb] Proposal to break the ICE impasse

[Adam Roach <[e-mail]>]

Based on conversations in MMUSIC, as well as several offline 
conversations with interested parties, I've put together a proposed 
change to JSEP that, if accepted, will allow publication of the Cluster 
238 documents to move forward.

Note that this new text has no impact on existing implementations (at 
least, as far as I am able to discern), which do not currently have the 
capability of producing media sections consisting of exclusively TCP 
candidates. From that perspective, the change makes existing 
implementations no less compliant with JSEP than they were before.

What this change does provide is both on-paper and in-the-future 
compatibility between WebRTC implementations once they finalize TCP 
candidate handling (and candidate handling in general for mid-session 
offers).

   https://github.com/rtcweb-wg/jsep/pull/862/files

The key insight here is that JSEP's use of ICE completely discards any 
meaning associated with the transport parameter, while SIP's use of ICE 
does not. The trivial change that I propose, which bears only on future 
WebRTC implementations -- that is, which has no as-built specification 
to point to -- allows JSEP to continue to ignore the value of the 
transport parameter, while specifying that it says the right thing for 
SIP implementations to function properly.

/a