Re: PRs for either PC.createRtpSender or PC.addTrack(..., RtpSenderInit, ...)

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.
>