Subject: [rtcweb] Clarification on JSEP addTrack algorithm change

From: Justin Uberti <[email-masked]>
Date: Fri, 7 Oct 2016 10:11:38 -0700

At IETF 96, we discussed a modification
<https://docs.google.com/presentation/d/1Ay80ztS2eMtnKWcUA7Q91uai9ICQTgrfMbZsjquQpN8/edit#slide=id.g155b90bad5_0_101>
to how addTrack would match new MSTs to m= sections (details at the link).

At the time, I proposed the following text:
*If the PeerConnection is in the have-remote-offer state, the track will be
attached to the first compatible transceiver that was created by
setRemoteDescription and does not have a local track. Otherwise, a new
transceiver will be created.*

The intent here was to only perform automatic track matching on m= sections
that were added by a newly received offer/reoffer (and not on existing
a=recvonly m= sections). However, Peter Thatcher pointed out that this text
was somewhat ambiguous and would allow an existing a=recvonly m= section to
be matched during a reoffer.

To address this, Peter and I have agreed on the following revised text:
*If the PeerConnection is in the have-remote-offer state, the track will be
attached to the first compatible transceiver that was created by the most
recent setRemoteDescription and does not have a local track. Otherwise, a
new transceiver will be created.*

This is being tracked in JSEP issue 288
<https://github.com/rtcweb-wg/jsep/issues/288>.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 7 Oct 2016 10:52:54 -0700

This is fine with me, but I think we should modify the *text* to make clear
what the intent is.

Perhaps something like this:
"For example, if a PeerConnection receives an offer with an m= section that
is send-recv
a call to addTrack() prior to calling createAnswer() can attach a track to
that transceiver.
However, after createAnswer() and setLocalDescription() have been called,
any call
to addTrack() will create a new transceiver even if the new track would
otherwise be compatible"

On Fri, Oct 7, 2016 at 10:11 AM, Justin Uberti <[email-masked]> wrote:

> *If the PeerConnection is in the have-remote-offer state, the track will
> be attached to the first compatible transceiver that was created by
> The intent here was to only perform automatic track matching on m=
> sections that were added by a newly received offer/reoffer (and not on
> existing a=recvonly m= sections). However, Peter Thatcher pointed out that
> this text was somewhat ambiguous and would allow an existing a=recvonly m=
> section to be matched during a reoffer.
>
> *If the PeerConnection is in the have-remote-offer state, the track will
> be attached to the first compatible transceiver that was created by the
> most recent setRemoteDescription and does not have a local track.
> Otherwise, a new transceiver will be created.*
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 7 Oct 2016 11:53:23 -0700

Upon reflection I think this is clear enough

On Fri, Oct 7, 2016 at 10:52 AM, Eric Rescorla <[email-masked]> wrote:

> This is fine with me, but I think we should modify the *text* to make
> clear what the intent is.
>
> "For example, if a PeerConnection receives an offer with an m= section
> that is send-recv