25893 2014-05-27 11:39:58 +0000 Offer Answer options should supported sendOnly and inactive media states. 2014-10-31 18:02:49 +0000 1 1 1 Unclassified WebRTC Working Group WebRTC API unspecified All All RESOLVED WONTFIX P2 normal --- 1 kiran.guduru public-webrtc harald juberti martin.thomson public-webrtc oldest_to_newest 106840 0 kiran.guduru 2014-05-27 11:39:58 +0000 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 106849 1 martin.thomson 2014-05-27 18:18:59 +0000 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. 106980 2 kiran.guduru 2014-05-29 13:19:18 +0000 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. 106987 3 martin.thomson 2014-05-29 16:29:16 +0000 (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. 106996 4 juberti 2014-05-29 19:12:19 +0000 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). 114380 5 harald 2014-10-31 18:02:49 +0000 This should not be controlled by this control surface. Closing as WONTFIX. (correct surface is via RTPSender/RTPReceiver).