Re: [rtcweb] Processing multiple remote offers

[Taylor Brandstetter <[e-mail]>]

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.

On Tue, Oct 17, 2017 at 7:50 AM, Harald Alvestrand <[e-mail]>
wrote:

> 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?
> >
> > Of course, another solution would be to say "this isn't supported, do a
> > rollback if you need this."
>
> 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/rtcweb
> >
>
>