Conclusion: ReplaceTrack vs RTPSender.track = new

It seems that among the people commenting, we have a consensus that 
ReplaceTrack is superior to track assignment, so I'm closing PR #196. 
The active proposal for track replacement is now PR #195.

Harald, chair hat on

On 04/16/2015 04:00 AM, Justin Uberti wrote:
> I was already convinced we want replaceTrack, but now I am doubly so.
>
> On Wed, Apr 15, 2015 at 1:55 PM, Peter Thatcher <pthatcher@google.com 
> <mailto:pthatcher@google.com>> wrote:
>
>     In the work in the ORTC CG, we chose to make it a method
>     (.setTrack(newTrack)) rather than a writable attribute (.track =
>     newTrack).  In fact, we choose to follow the .setFoo pattern
>     rather than the .foo= for all things, not just setTrack for the
>     following reasons:
>
>     1.  It allows return values, async and sync.  You might think you
>     don't want one now, but you might want to add one later.
>     2.  It allows async errors.
>     3.  It allows for adding additional parameters.  You might think
>     you don't want one now, but you might want to add one later.
>
>     For those reasons, I also prefer .replaceTrack over setting .track.
>
>
>     I also have thoughts over the rest of you error conditions and
>     what we should do about them, but I think that's secondary and
>     will leave that discussion for another time :).
>
>     On Wed, Apr 15, 2015 at 12:31 AM, Harald Alvestrand
>     <harald@alvestrand.no <mailto:harald@alvestrand.no>> wrote:
>
>         In mulling over this issue, I've been thinking about failure
>         cases, and about negotiated constraints.
>
>         Consider this case:
>
>         A negotiates with B to send video
>         The agreeed capabilities for B is 320x200 max (it's a
>         doorbell, I guess).
>         A sends a track to B with 320x200 format.
>
>         A does ReplaceTrack with a HD track (currently also being
>         displayed in HD somewhere else).
>
>         Three possibilities:
>
>         - A downsamples to 320x200 as (conceptuaully) an internal
>         function of the PeerConnection
>         - A treats B's restrictions as (new) constraints on the track,
>         and all other users switch to 320x200
>         - ReplaceTrack fails
>
>         Replay the same case where the source of the new track is a
>         VP8-only camera, and B says it can only take H.264 (I guess
>         it's a gateway).
>
>         Three possibilities:
>
>         - A transcodes the video internally to PeerConnection
>         - A inserts transcoding at the source
>         - ReplaceTrack fails
>
>         And of course the weird one:
>
>         A does ReplaceTrack, trying to replace an audio track with a
>         video track.
>
>         ANALYSIS:
>
>         If ReplaceTrack never fails, all possible scenarios must be
>         handled with successful outcomes. That seems like a tall order.
>
>         If ReplaceTrack can sometimes fail, and we can always report
>         the error synchronously in an exception (IllegalParameter for
>         the last one, I guess), the two solutions are equivalent.
>
>         If ReplaceTrack can sometimes fail, and we don't want
>         exceptions to be thrown (for instance, we might not be able to
>         instantly decide whether the replacement is possible or not),
>         ReplaceTrack() is superior.
>
>
>
>
>