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

[Roman Shpount <[e-mail]>]

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.

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.

Regards,
_____________
Roman Shpount


On Fri, Feb 8, 2019 at 1:43 PM Ted Hardie <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>