Re: [rtcweb] Proposal to break the ICE impasse

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
>