- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Mon, 02 Jun 2014 09:03:06 +0200
- To: public-webrtc@w3.org
On 05/29/2014 03:19 PM, bugzilla@jessica.w3.org wrote: > https://www.w3.org/Bugs/Public/show_bug.cgi?id=25893 > > --- Comment #2 from Kiran <kiran.guduru@samsung.com> --- > 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. > Can't do that in general - you don't have an RTCRTPSender before you have done AddTrack, and the whole point of OfferTo* was to manipulate the number of M-lines without adding tracks. Similarly for RTCRTPReceiver - you don't have it before tracks have been added, therefore you can't use it to manipulate what happens before tracks are added. In general, I find that it helps me a lot to write code (even if just pseudocode in my mind) when I suggest API tweaks - if I find that an API tweak I'm suggesting requires that some object be available before it's normally present, I know that I either have to include the production of that object in my proposal or think of something else. (An even more rigorous requirement would be that anyone suggesting an API change supply an executable test for the API after their change - but that becomes a lot easier when we have a reasonable body of tests to copy from.)
Received on Monday, 2 June 2014 07:03:41 UTC