Re: ReplaceTrack and track.id (Re: ReplaceTrack - need to evaluate alternatives)

On Thu, Apr 16, 2015 at 2:10 AM, Harald Alvestrand <harald@alvestrand.no>
wrote:

>  On 04/16/2015 12:19 AM, Peter Thatcher wrote:
>
>  Well it's already there via SDP munging :).
>
>  And te question isn't whether to allow the JS to choose the MID.  It's
> whether to have two IDs/labels (MID + something else), or just one (MID).
> If one will work, I prefer one.
>
>
> The two concepts have different lifetimes; a track can be created before a
> PeerConnection.
>
> I like to support the model of "you are sending a track over a
> PeerConnection; it appears the same on the other side" as much as possible.
> Having an ID on the track is part of that model.
>

​I agree on the "you are sending something; it appears the same on the
other side", but I think it should be the RtpSender/RtpReceiver that should
have the same ID/label on each side, not the track.  That ID of the track
really doesn't matter.

Further, I think there is some value in letting the app ​choose the
label/ID, just like for data channels.



>
> From my perspective, MID is part of the adaptations we do in order to make
> SDP work for us.
> Having rules from SDP spill over into the track model seems like
> tail-wags-dog to me.
>
>
​That's a fair point.  If too  much spills over, I think I'd also be OK
with some kind of "a=RtpSender" SDP attribute.  However, that would also
have SDP rules spill over, I think, like special characters and such,
unless we do something like base64 encode it.​