That's a good point about needing more detail in #271. I have updated it with more detail about .track being null and what details should be filled in when the track isn't there. Please take a look and let me know what more improvements can be made. Specific text is welcome. On Tue, Aug 25, 2015 at 6:36 PM, Martin Thomson <martin.thomson@gmail.com> wrote: > On 25 August 2015 at 17:52, Justin Uberti <juberti@google.com> wrote: > > Having reviewed both PRs, I agree with Adam and Peter. createRtpSender is > > simple and intuitive. > > > That sounds reasonable to me. I don't think that #271 has enough > detail (it need to specify that the .track property of the sender is > null. It also need to describe the consequences for session > negotiation: namely that a "default" profile for the specified kind > will be used. > > Also, I assume that we aren't required to make any sorts of promises > about hardware codecs; in other words, that browsers will not include > hardware codecs in any generated session description unless hardware > codecs are the only possible option. Hmm, the more I think about > this, the more that I think that we need to be careful to work out > what the right approach is - we could leave this up to implementer > discretion, but that would be sloppy. >
Received on Wednesday, 26 August 2015 18:06:12 UTC