Re: [rtcweb] New Version Notification for draft-guduru-rtcweb-codec-preferences-01.txt

["Makaraju, Maridi Raju (Raju)" <[e-mail]>]

Kiran,
Please see my inline comments marked between <Raju2> and </Raju2>.


>This seems like a pretty big hammer to solve a fairly small problem. This proposal adds 6 new API points for the purpose of >changing the order of codecs in createOffer, which seems like a high cost-benefit ratio. And while the use cases listed here are >helpful, they seem somewhat contrived to me, since it seems unlikely that the application can make better choices about >bandwidth >or power consumption than the browser.



[Raju] Per my understanding, the main object of this draft can be achieved with no additional APIs and with just the proposed introduction of preferredAudioCodecs and preferredVideoCodecs options to RTCOfferAnswerOptions constraint of createOffer()/createAnswer().

So, IMO I don’t think getCodecPreferences()/setCodecPreferences() add much value, so can be delayed or dropped.



The need for getSupportedAudioCodecs()/getSupportedVideoCodecs() in 1.0 can be questionable as the application can specify codecs order per known codecs (or get the list via a dummy createOffer() call).

 [KIRAN] New API is added for this only because, it can be called on Peerconnection irrespective of its state and the order of parsing is also easy when compared to parsing of whole SDP returned through createOffer/Answer.

<Raju2> I agree that it is easy. But, I also agree with that Justin that given other must have work this may be lower priority; these small things do add up to delay webrtc 1.0 delivery.

</Raju2>



The draft talks about fulfilling A5 in [I-D.ietf-rtcweb-use-cases-and-requirements], but I do not see any explicit mention of how codecs can be removed? preferredAudio/VideoCodecs constraint only specifies the order of preference. Don’t you need another constraint to exclude specified codecs? It’s probably a bad design to have codecs not in the preferred list be removed automatically.



 [KIRAN] The removal of codecs is explained in section 6.

  "The offer / answer

   SHOULD NOT contain audio codecs other than those specified by

   JavaScript application and the order of preference SHOULD be with

   high priority for the codecs first in the sequence."



Perhaps this is in indirect way. I will modify the statement to directly point this. I don't want to increase the constraints just for removal, which can be achieved with this constraint. So I followed this design.

<Raju2> Sorry I missed that. But, the name “preferredCodecs” does not convey the “removal” part clearly as preference generally indicates reordering priority, but not removal. Such semantics may put additional burden on app to list all the codecs in preferredCodecs list where as user may just prefer a particular codec to be the 1st one and does not care about other codecs order, so they can keep their relative order but they are needed in the list. IMO, removal of codecs requires another separate constraint and not be mixed with preferredCodecs constraint. I am not wedded to having separate constraint for removal though, but I seek input from other members.



</Raju2>



BR

Raju





BR

Raju









[cid:[e-mail]7740]

[http://ext.samsung.net/mailcheck/SeenTimeChecker?do=f4fb70ba8b72c9ec54f455cfe522005d3ef988aa2daaa32d52ccaaa5e78d7917de6eee2be874e0523ecd3146ba1edb3ef4bcdeced46ed5ee08cece8541bc14eacf878f9a26ce15a0]