This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
RTCOfferAnswerOptions is currently supporting recvOnly state through offerToReceiveAudio, offerToReceiveVideo. It should also support options to enable "sendOnly" and "inactive" media formats. sendOnly and inactive of SDP are required, for example, in hold scenario as specified RFC 5359 [1] section 2.1 "Older UAs may set the connection address to 0.0.0.0 when initiating hold. However, this behavior has been deprecated in favor or using the a=inactive SDP attribute if no media is sent, or the a=sendonly attribute if media is still sent." [1] http://tools.ietf.org/html/rfc5359
I removed RTCOfferAnswerOptions, so it might need to be added back. But I'm not sure that this is the right place to include that information. RTCConfiguration might be more appropriate. (See OfferToReceiveAudio for example). We should definitely talk about providing widgets that allow a peer to say that they don't want reciprocal media.
OfferToReceiveAudio marks SDP mediaStreams to be recvOnly. I think, we can move SDP options like sendOnly, recvOnly, inactive corresponding to OfferToReceiveAudio, OfferToSendAudio, OfferToInactiveAudio (names may be changed) respectively to track level i.e., to RTCRTPSender/RTCRTPReceiver instead of moving to RTCConfiguration.
(In reply to Kiran from comment #2) > OfferToReceiveAudio marks SDP mediaStreams to be recvOnly. It depends on the value. if OfferToReceiveAudio < nAudioStreams, then some streams will be made sendonly.
sendOnly/inactive will be controlled via RTCRtpSender/Receiver controls. OfferToReceiveAudio simply adds additional recvonly m-lines to work around the SDP limitation that the answerer can't respond with more than what was offered. There's no need for createOffer to have controls on exactly which direction should be signalled. Regarding #3, streams are never made to be sendonly through use of OfferToReceiveAudio, although an answer to a recvonly stream will necessarily be sendonly (or less).
This should not be controlled by this control surface. Closing as WONTFIX. (correct surface is via RTPSender/RTPReceiver).