Re: [rtcweb] Proposal to break the ICE impasse

I agree with Eric, but in the interest of moving forward, I am willing to
live with the relatively straightforward solution of using TCP in the m=
line when the default candidate is a TCP candidate.

On Sat, Jan 26, 2019 at 9:23 AM Eric Rescorla <ekr@rtfm.com> wrote:

> I'm not yet persuaded this is needed. The alleged need here is that there
> are some ICE-implementing endpoints which will choke if they see a profile
> that doesn't match any actual candidate. I recognize that this is required
> by 5245, but that doesn't mean anyone ever did it. Can you please point me
> to a client which would interoperate with a WebRTC endpoint with this
> change that would not if you just always sent the same profile as JSEP
> currently requires.
>
> -Ekr
>
>
>
> On Thu, Jan 24, 2019 at 11:12 AM Adam Roach <adam@nostrum.com> wrote:
>
>> 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
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>