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

From: Ted Hardie <[email-masked]>
Date: Fri, 8 Feb 2019 10:42:58 -0800

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

---

From: Roman Shpount <[email-masked]>
Date: Fri, 8 Feb 2019 14:14:36 -0500

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 <[email-masked]> wrote:

> The chairs are already aware of the objection of Eric Rescorla on the
> basis of complexity, and will factor it into the review.
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Justin Uberti <[email-masked]>
Date: Fri, 8 Feb 2019 11:20:25 -0800

> 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.

> in the future specification or mmusic-ice-sip-sdp.

This should probably also be fixed in 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.
>>

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 9 Feb 2019 09:12:43 +0000

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 <[email-masked]> on behalf of Justin Uberti <juberti=[email-masked]>
Date: Friday, 8 February 2019 at 20.21
To: Roman Shpount <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [rtcweb] Call for consensus on ICE transport parameter issue (February 15).

On Fri, Feb 8, 2019 at 11:15 AM Roman Shpount <[email-masked]<mailto:[email-masked]>> 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.

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.

Regards,
_____________
Roman Shpount

On Fri, Feb 8, 2019 at 1:43 PM Ted Hardie <[email-masked]<mailto:[email-masked]>> 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:

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.

* 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.

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.

regards,

_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb
_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 10 Feb 2019 16:07:08 -0800

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 <
[email-masked]> wrote:

> 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 <[email-masked]> on behalf of Justin Uberti
> <juberti=[email-masked]>
> *Date: *Friday, 8 February 2019 at 20.21
> *To: *Roman Shpount <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *Subject: *Re: [rtcweb] Call for consensus on ICE transport parameter
> issue (February 15).
>
>
>
>
>
>
>

---

From: Ted Hardie <[email-masked]>
Date: Wed, 13 Feb 2019 10:52:49 -0800

As an individual, I support this change.  While I agree that the benefit is
currently theoretical, I think having the breadcrumbs for what to do when
it ceases to be theoretical is worth the effort.

Ted

---

From: Justin Uberti <[email-masked]>
Date: Wed, 13 Feb 2019 11:38:23 -0800

I support this change, solely to avoid confusion for implementers caused by
different guidance from JSEP and ice-sip-sdp.

On Wed, Feb 13, 2019 at 10:53 AM Ted Hardie <[email-masked]> wrote:

> As an individual, I support this change.  While I agree that the benefit
> is currently theoretical, I think having the breadcrumbs for what to do
> when it ceases to be theoretical is worth the effort.
>
> Ted
>