Subject: [rtcweb] Processing multiple remote offers

From: Taylor Brandstetter <[email-masked]>
Date: Mon, 16 Oct 2017 16:12:57 -0700

JSEP allows a remote offer to be applied while in the "have-remote-offer"
state. Meaning that, in addition to supporting multiple answers (via
pr-answers), JSEP also supports multiple offers.

However, I don't see any text that calls out what (if anything) must be the
same between these offers. Should we assume that they can be
*completely* different?
Or do they at least need to contain the same m= sections (same type, MID
and order)? For example: is it legal to apply an audio-only remote offer,
then apply a video-only remote offer? Is it legal to apply an audio-only
offer, then an audio+video offer?

This affects WebRTC 1.0, because depending on which direction this goes, we
may need to address a situation where an RTCRtpTransceiver is created by
applying a remote offer, then invalidated by the next remote offer. Does it
go away or exist in limbo state?

Of course, another solution would be to say "this isn't supported, do a
rollback if you need this."

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 17 Oct 2017 16:50:50 +0200

Den 17. okt. 2017 01:12, skrev Taylor Brandstetter:
> JSEP allows a remote offer to be applied while in the
> "have-remote-offer" state. Meaning that, in addition to supporting
> multiple answers (via pr-answers), JSEP also supports multiple offers.
> 
> However, I don't see any text that calls out what (if anything) must be
> the same between these offers. Should we assume that they can be
> /completely/ different? Or do they at least need to contain the same m=
> sections (same type, MID and order)? For example: is it legal to apply
> an audio-only remote offer, then apply a video-only remote offer? Is it
> legal to apply an audio-only offer, then an audio+video offer?

Offhand, I can't think of a scenario where multiple offers in have-offer
state is useful. Most of these convolutions were justified by 3PCC
cases, which I don't understand fully.

A contrived one is where the remote party sends an audio-only offer,
adds a video track, and then wishes to re-offer with both audio and
video before the answerer picks up. This only makes sense if the
answerer is waiting for the human response before sending the answer.

> This affects WebRTC 1.0, because depending on which direction this goes,
> we may need to address a situation where an RTCRtpTransceiver is created
> by applying a remote offer, then invalidated by the next remote offer.
> Does it go away or exist in limbo state?
> 

Or we could specify the effect of applying a new remote offer as being
identical to rollback + apply the new offer. Is that the simplest spec
change we can make?

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

---

From: Taylor Brandstetter <[email-masked]>
Date: Tue, 17 Oct 2017 10:03:47 -0700

I think it would be simple to allow *adding* m= sections (transceivers);
that would satisfy the use case you describe. It's mostly removing them,
reordering them, or choosing different MIDs that would introduce
complexity. In short, anything that's impossible to do on the local side
(by calling createOffer again after setLocalDescription).

But specifying "apply new remote offer" as "do the steps of a rollback
followed by the steps of applying a fresh offer" would probably work. I
can't think of any potential problems at the moment.