W3C home > Mailing lists > Public > public-webrtc@w3.org > June 2014

Re: [Bug 25893] Offer Answer options should supported sendOnly and inactive media states.

From: Harald Alvestrand <harald@alvestrand.no>
Date: Mon, 02 Jun 2014 09:03:06 +0200
Message-ID: <538C21AA.7080406@alvestrand.no>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:59 UTC