Subject: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-rfc8829bis-00.txt

From: Justin Uberti <[email-masked]>
Date: Sat, 10 Jul 2021 18:10:51 -0700

As discussed at IETF 110. Diff from RFC8829:
https://tools.ietf.org/rfcdiff?url1=https://www.rfc-editor.org/rfc/rfc8829.txt&url2=https://www.ietf.org/archive/id/draft-uberti-rtcweb-rfc8829bis-00.txt

---------- Forwarded message ---------
From: <[email-masked]>
Date: Sat, Jul 10, 2021 at 6:03 PM
Subject: New Version Notification for draft-uberti-rtcweb-rfc8829bis-00.txt
To: Cullen Jennings <[email-masked]>, Eric Rescorla <[email-masked]>, Justin
Uberti <[email-masked]>

A new version of I-D, draft-uberti-rtcweb-rfc8829bis-00.txt
has been successfully submitted by Justin Uberti and posted to the
IETF repository.

Name:           draft-uberti-rtcweb-rfc8829bis
Revision:       00
Title:          JavaScript Session Establishment Protocol (JSEP)
Document date:  2021-07-10
Group:          Individual Submission
Pages:          106
URL:
https://www.ietf.org/archive/id/draft-uberti-rtcweb-rfc8829bis-00.txt
Status:
https://datatracker.ietf.org/doc/draft-uberti-rtcweb-rfc8829bis/
Html:
https://www.ietf.org/archive/id/draft-uberti-rtcweb-rfc8829bis-00.html
Htmlized:
https://datatracker.ietf.org/doc/html/draft-uberti-rtcweb-rfc8829bis

Abstract:
   This document describes the mechanisms for allowing a JavaScript
   application to control the signaling plane of a multimedia session
   via the interface specified in the W3C RTCPeerConnection API and
   discusses how this relates to existing signaling protocols.

   This specification obsoletes RFC 8829.

The IETF Secretariat

---

From: Roman Shpount <[email-masked]>
Date: Sat, 10 Jul 2021 22:17:08 -0400

I have a question regarding max-compat in subsequent offers with iceRestart:

Should new candidates be gathered for all m= lines or only for the m=lines
which are not bundled after the previous offer/answer exchange?

I would suggest that new candidates should be gathered for all m=lines to
be compatible with 3PCC.

Thank You,
_____________
Roman Shpount

On Sat, Jul 10, 2021 at 9:11 PM Justin Uberti <[email-masked]> wrote:

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

---

From: Justin Uberti <[email-masked]>
Date: Sat, 10 Jul 2021 23:33:29 -0400

Section 3.5.1 makes clear that only sections that are restarting are
affected:

   Note that gathering phases only gather the candidates needed by
   new/recycled/restarting "m=" sections; other "m=" sections continue
   to use their existing candidates.  Also, if an "m=" section is
   bundled (either by a successful bundle negotiation or by being marked
   as bundle-only), then candidates will be gathered and exchanged for
   that "m=" section if and only if its MID item is a BUNDLE-tag, as
   described in [RFC8843 <https://datatracker.ietf.org/doc/html/rfc8843>].

On Sat, Jul 10, 2021 at 7:17 PM Roman Shpount <[email-masked]> wrote:

>> To: Cullen Jennings <[email-masked]>, Eric Rescorla <[email-masked]>,
>> Justin Uberti <[email-masked]>
>>
>>
>>

---

From: Justin Uberti <[email-masked]>
Date: Sat, 10 Jul 2021 23:35:37 -0400

(To be clear, m= sections that are bundled will continue to be bundled and
will not participate in the restart.)

On Sat, Jul 10, 2021 at 8:33 PM Justin Uberti <[email-masked]> wrote:

>> Should new candidates be gathered for all m= lines or only for the
>> m=lines which are not bundled after the previous offer/answer exchange?
>>

---

From: Roman Shpount <[email-masked]>
Date: Sat, 10 Jul 2021 23:45:26 -0400

> will not participate in the restart.)

This is what I thought.

How would one unbundle them if an offer needs to be generated for 3PCC
(like an offer in response to an empty INVITE)? There is the iceRestart
option for ICE to do this. Is there a need for something similar for the
bundle to do the same thing? Please see draft-ietf-mmusic-rfc8843bis-04
section 7.6 (
https://www.ietf.org/archive/id/draft-ietf-mmusic-rfc8843bis-04.html#section-7.6)
for more details.

Please note that in the case of 3PCC an offer within an existing session
for one call leg would be the initial offer for another call leg. After the
latest change, an offer within the existing session is no longer a valid
initial offer.

Thank You,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 12 Jul 2021 09:26:05 +0000

Hi,

I will take a closer look later, but I guess the BUNDLE reference shall also be updated.

Regards,

Christer

From: rtcweb <[email-masked]> On Behalf Of Justin Uberti
Sent: sunnuntai 11. heinäkuuta 2021 4.11
To: RTCWeb IETF <[email-masked]>
Subject: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-rfc8829bis-00.txt

As discussed at IETF 110. Diff from RFC8829: https://tools.ietf.org/rfcdiff?url1=https://www.rfc-editor.org/rfc/rfc8829.txt&url2=https://www.ietf.org/archive/id/draft-uberti-rtcweb-rfc8829bis-00.txt

---------- Forwarded message ---------
From: <[email-masked]<mailto:[email-masked]>>
Date: Sat, Jul 10, 2021 at 6:03 PM
Subject: New Version Notification for draft-uberti-rtcweb-rfc8829bis-00.txt
To: Cullen Jennings <[email-masked]<mailto:[email-masked]>>, Eric Rescorla <[email-masked]<mailto:[email-masked]>>, Justin Uberti <[email-masked]<mailto:[email-masked]>>

Name:           draft-uberti-rtcweb-rfc8829bis
Revision:       00
Title:          JavaScript Session Establishment Protocol (JSEP)
Document date:  2021-07-10
Group:          Individual Submission
Pages:          106
URL:            https://www.ietf.org/archive/id/draft-uberti-rtcweb-rfc8829bis-00.txt
Status:         https://datatracker.ietf.org/doc/draft-uberti-rtcweb-rfc8829bis/
Html:           https://www.ietf.org/archive/id/draft-uberti-rtcweb-rfc8829bis-00.html
Htmlized:       https://datatracker.ietf.org/doc/html/draft-uberti-rtcweb-rfc8829bis

Abstract:

The IETF Secretariat

---

From: Justin Uberti <[email-masked]>
Date: Tue, 13 Jul 2021 10:43:21 -0700

Roman,

I see what you are getting at. I suppose that was one benefit of the other
BUNDLE syntax, i.e., that all offers (not just the first) are always
understandable by a non-BUNDLE endpoint.

That said, given the adoption of BUNDLE I tend to think that 3PCC to a
non-BUNDLE endpoint is increasingly a corner case, so it may not be worth
going to the trouble of trying to fix the SDP syntax and allowing for
mid-call unbundling.

Note also that it is not clear to me how rtcp-mux would work in a similar
situation, i.e., when doing 3PCC to a non-rtcp-mux endpoint.

Justin

On Sat, Jul 10, 2021 at 8:45 PM Roman Shpount <[email-masked]> wrote:

>> (To be clear, m= sections that are bundled will continue to be bundled
>> and will not participate in the restart.)
>>
>
> This is what I thought.
>

---

From: Roman Shpount <[email-masked]>
Date: Tue, 13 Jul 2021 13:54:56 -0400

Justin,

Part of the new BUNDLE syntax problem is that the offer generated during
the session is not a valid initial offer, even for the endpoints that do
support BUNDLE. There are m= lines with no candidates and no bundle-only
tags. Even if we are not going to support unbundling in 3PCC scenarios, we
should generate valid initial offers for BUNDLE-enabled endpoints.

At the very least, my suggestion would be, when a new offer is generated
after ICE restart is initiated (either due to the iceRestart option or ICE
configuration changes), to set a bundle-only tag on the bundled m= lines.

Best Regards,
_____________
Roman Shpount

---

From: Justin Uberti <[email-masked]>
Date: Tue, 13 Jul 2021 11:21:14 -0700

The problem though is that if you are setting bundle-only you also need to
zero the port, which opens up the whole can of worms with deployed
applications that we were hoping to avoid. Limiting it to IceRestart would
reduce the risk but not eliminate it.

It would be good to hear of at least one example of this causing an actual
problem before spending substantial energy here, I think. Note also that
this would be a change to BUNDLE, not to JSEP.

On Tue, Jul 13, 2021 at 10:55 AM Roman Shpount <[email-masked]> wrote:

>> I see what you are getting at. I suppose that was one benefit of the
>> other BUNDLE syntax, i.e., that all offers (not just the first) are always

---

From: Roman Shpount <[email-masked]>
Date: Tue, 13 Jul 2021 14:56:27 -0400

> reduce the risk but not eliminate it.

Anything BUNDLE compliant should be able to handle m= lines with port 0 and
a=bundle-only, but it can be an issue for some existing implementations.

> this would be a change to BUNDLE, not to JSEP.

BUNDLE was already modified to handle this: draft-ietf-mmusic-rfc8843bis-04
section 7.6 (
https://www.ietf.org/archive/id/draft-ietf-mmusic-rfc8843bis-04.html#section-7.6
)

I guess, if someone really needs this, they can munge the SDP.
_____________
Roman Shpount

---

From: Justin Uberti <[email-masked]>
Date: Thu, 29 Jul 2021 13:10:34 -0700

I thought about this a bit more and came to the same conclusion. Noted
accordingly in the slides for today's session.

On Tue, Jul 13, 2021 at 11:56 AM Roman Shpount <[email-masked]> wrote:

>> The problem though is that if you are setting bundle-only you also need
>> to zero the port, which opens up the whole can of worms with deployed
> Anything BUNDLE compliant should be able to handle m= lines with port 0
> and a=bundle-only, but it can be an issue for some existing
> implementations.
>
>
>> It would be good to hear of at least one example of this causing an
>> actual problem before spending substantial energy here, I think. Note also
>> that this would be a change to BUNDLE, not to JSEP.
>>
>
> BUNDLE was already modified to handle this:
> draft-ietf-mmusic-rfc8843bis-04 section 7.6 (