This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Options attribute is missing for createAnswer [1]. As per RFC 3264 section 6.1 [2], Answerer should have provision to respond with the preferred option. 1. recvonly or inactive if the offered stream is sendonly. 2. sendonly or inactive if the offered stream is recvonly. 3. sendrecv or recvonly or sendonly or inactive if the offered stream is sendrecv. "If a stream is offered as sendonly, the corresponding stream MUST be marked as recvonly or inactive in the answer. If a media stream is listed as recvonly in the offer, the answer MUST be marked as sendonly or inactive in the answer. If an offered media stream is listed as sendrecv (or if there is no direction attribute at the media or session level, in which case the stream is sendrecv by default), the corresponding stream in the answer MAY be marked as sendonly, recvonly, sendrecv, or inactive. If an offered media stream is listed as inactive, it MUST be marked as inactive in the answer" [1] http://dev.w3.org/2011/webrtc/editor/webrtc.html#interface-definition [2] http://tools.ietf.org/html/rfc3264#page-9
The options to CreateAnswer are the wrong place for this. To reject the offered stream, this is done by .stop()ing the MST that was offered, or by setting the .active property to false on the created RTPReceiver object.
I hope, we have to wait for discussing on this until doohickeys are specified in document.
The only identified need for this options parameter is setting VoiceActivityDetection. We should add the AnswerOptions to CreateAnswer, with only the VAD member (for now). (but not try to give it a common base with OfferOptions; the previous stuff was too convoluted.)
WebRTC API bugs have been moved to github issues: https://github.com/w3c/webrtc-pc/issues Please subscribe to the issues you want to keep watching.