Re: [rtcweb] Call for consensus on ICE transport parameter issue (February 15).

I am not in favor of this change for the reasons I already laid out.

-Ekr

On Sat, Feb 9, 2019 at 1:13 AM Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

> Hi,
>
>
>
> I also support this change.
>
>
>
> I share Roman’s issue in this note #1, but since Justin seems to be fine
> removing the associated text it should be solved.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
> *From: *rtcweb <rtcweb-bounces@ietf.org> on behalf of Justin Uberti
> <juberti=40google.com@dmarc.ietf.org>
> *Date: *Friday, 8 February 2019 at 20.21
> *To: *Roman Shpount <roman@telurix.com>
> *Cc: *"rtcweb@ietf.org" <rtcweb@ietf.org>
> *Subject: *Re: [rtcweb] Call for consensus on ICE transport parameter
> issue (February 15).
>
>
>
>
>
>
>
> On Fri, Feb 8, 2019 at 11:15 AM Roman Shpount <roman@telurix.com> wrote:
>
> I am, obviously for this change. As far as I know additional complexity is
> minimal if not completely non-existent. JSEP already requires m= and c=
> line updates based on the default candidate. I do not think there is a lot
> of extra effort in updating the same line based on the same input in two
> places vs one place.
>
>
>
> I would also like to note that:
>
>
>
> 1.  JSEP requires browsers to update the m= line more often then
> mmusic-ice-sip-sdp or RFC 5245. For offers sent during ICE nomination
> process, JSEP asks to set m= and c= line to the last used ICE candidate
> pair. RFC 5245 asks in this case to set this to the default candidate pair,
> which changes a lot less often. It is unclear what is the benefit of
> additional JSEP requirement. It looks like some sort of left over logic
> from re-nomination. This being said, it should not create any interop
> issues and will simply creates additional complexity.
>
>
>
> I agree that this should probably be removed from JSEP and codified in
> sip-sdp instead; as previously discussed, JSEP doesn't actually use this
> info.
>
>
>
> 2. JSEP can produce the answer where default candidate protocol does not
> match the m= line protocol. This is an old RFC 5245 issue and can be fixed
> in the future specification or mmusic-ice-sip-sdp.
>
>
>
> This should probably also be fixed in sip-sdp.
>
>
>
> Regards,
>
> _____________
> Roman Shpount
>
>
>
>
>
> On Fri, Feb 8, 2019 at 1:43 PM Ted Hardie <ted.ietf@gmail.com> wrote:
>
> Over the the past few weeks, the working group has discussed whether to
> adopt a change to JSEP which would adjust how the ICE proto line transport
> parameters are populated in certain mid-session offers where the final
> candidate is a TCP candidate.  Outside of the extensive working group
> discussion on the mailing list, participants may also wish to review the
> follow issue:
>
>
>
> https://github.com/rtcweb-wg/jsep/issues/854
>
>
>
> and the conversations related to these two pull requests:
>
>
>
> https://github.com/rtcweb-wg/jsep/pull/862
>
> and
>
> https://github.com/rtcweb-wg/jsep/pull/863
>
>
>
> The chairs believe that there is technical consensus that this proposed
> change would not materially affect JSEP-only exchanges, since this
> parameter is ignored in those.
>
>
>
> The remaining technical issues are:
>
>
>
> * whether making one of these changes would improve interoperability
> between WebRTC and non-WebRTC clients which use SIP/SDP.
>
>
>
> * whether the additional complexity in tracking the use of UDP vs. TCP and
> populating the parameter accordingly is onerous or unwarranted for WebRTC
> implementations.
>
>
>
> After reviewing the discussion to date, the chairs believe that there is
> rough consensus for the first point, though there is also broad agreement
> that the benefit of this change is currently theoretical, since no existing
> WebRTC browser implementation has relevant code.
>
>
>
> On the second point, the chairs believe that there is no consensus yet
> demonstrated.  Because we believe that this is in part because the actual
> proposal has not been entirely clear, and the complexity is therefore
> somewhat hard to gauge, the chairs wish to make a specific call for
> consensus.
>
>
>
> Does the working group approve the change in the following PR:
>
>
>
> https://github.com/rtcweb-wg/jsep/pull/863 ?
>
>
>
> Working group participants who have objections to the change are asked to
> specify whether they believe it has a technical fault, whether they object
> on the basis of its complexity, or whether they have other issues related
> to the change they need to raise.
>
>
>
> The chairs are already aware of the objection of Eric Rescorla on the
> basis of complexity, and will factor it into the review.
>
>
>
> Please send comments by February 15th, 2019.
>
>
>
> regards,
>
>
>
> Ted Hardie and Sean Turner
>
>
>
>
>
> _______________________________________________
> 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
>