Clarify offerToReceiveAudio and offerToReceiveVideo in renegotiation

[fluffy]

Not clear if setting RTCOfferOptions changes what happens in renegotation or can this only be used in an initial offer.

[stefhak]

There is indeed no such info. However, it is said that
When this is given a non-false value, no outgoing track of type "audio" is attached to the PeerConnection, and the existing localDescription (if any) doesn't contain any sendrecv or recv audio media sections, createOffer() will behave as if addTransceiver("audio") had been called once prior to the createOffer() call.
which I read as this would happen every time createOffer() is called.
Is this the way it should work in your opinion?

[stefhak]

Related to #1383

[ekr]

My question is: what existing software depends on the creation of the transceiver at this time as opposed to (say) at setLocal()

[taylor-b]

It's not that software depends on it, it's that JSEP does. JSEP says "here's how you create an offer given a set of transceivers". So without actually adding a transceiver, how can we say "create an offer according to JSEP"? We'd need to say "create an offer according to JSEP, acting as if these extra transceivers exist if offerToReceiveX was true". And we'd need to specify how setLocalDescription creates transceivers.

This PR is just much simpler than any other alternative, and solves most of the backwards compatibility use cases, which is what offerToReceive exists for in the first place. I don't think we should introduce extra complexity just so that the legacy API matches the object model perfectly; the legacy API only exists for practical reasons, so it makes sense to design it according to practical reasons.

[aboba]

createOffer uses knowledge of how many transceivers there are in creating the offer. Sources of that information include addTransceiver as well as transceiver.stop. offerToReceiveAudio/offerToReceiveVideo is another source. So the question here is how many transceivers createOffer should assume if RTCPeerConnection has no unstopped "sendrecv" or "recvonly" audio/video transceivers. Presumably if offerToReceiveAudio is not false then there is a desire to have an audio m-line, and if offerToReceiveVideo is not false there is a desire to have a video m-line.

createOffer could perhaps act as though the transceiver existed without creating it, with creation waiting until later (e.g. when SLD is called). However, that would imply that the developer would need to call createOffer and setLocalDescription before being able to call transceiver-based methods such setParameters, setCodecPreferences`, etc. That seems convoluted.

[stefhak]

Going back to @fluffy's original comment #1361 (comment): I think the proposed solution (#1430) is pretty clear: offerToReceive* applies also for re-offers.

[fluffy]

I think that JSEP has moved to make an Re-Offer as close as possible to an initial offer and we should do the same here.

[stefhak]

I think #1430 does precisely that regarding offerToReceive*. The same should be true for voiceActivityDetection. For iceRestart I'm not sure what that would mean in an initial offer.

[stefhak]

#1430 has been merged, and my reading is that we with that can close this Issue.