Re: [rtcweb] Proposal to break the ICE impasse

This looks good to me.
_____________
Roman Shpount

On Mon, Jan 28, 2019 at 5:51 PM Justin Uberti <juberti=
40google.com@dmarc.ietf.org> wrote:

> Posted https://github.com/rtcweb-wg/jsep/pull/863 as a stab at a
> consensus. This basically says that the offerer fills in either UDP/TLS/foo
> or TCP/DTLS/foo based on the current default or selected candidate, in
> accordance with sip-sdp. As Adam mentioned before, this shouldn't have any
> impact on JSEP functionality.
>
> If this looks good, I'll polish it up.
>
> On Sun, Jan 27, 2019 at 3:22 AM Christer Holmberg <
> christer.holmberg@ericsson.com> wrote:
>
>> Hi,
>>
>>
>> > 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.
>>
>> I don't think it is ok to *specify* that discarding a MUST is ok as long
>> as nobody can show an implementation that would break by doing so.
>>
>> Having said that, in order to prevent an RTCWEB shutdown I am generally
>> ok with Adam's approach. I would like my pull request comments to be
>> addressed, though, that is related to separation between the JSEP API and
>> an application using it: an application should be allowed to act according
>> to 5245/draft-ice-sdp and update the c/m line if it wishes to, but due to
>> the way the JSEP API works such applications might sometimes always include
>> the same value in the c/m- line.
>>
>> I also think it shall be explicitly written that JSEP does not update
>> 5245/draft-ice-sdp, but rather deviates when it comes to the c/m- line.
>>
>> Regards,
>>
>> Christer
>>
>>
>>
>>
>> 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
>>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>