W3C home > Mailing lists > Public > public-webrtc@w3.org > April 2015

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

From: Peter Thatcher <pthatcher@google.com>
Date: Thu, 16 Apr 2015 07:31:56 -0700
Message-ID: <CAJrXDUFSVz_zD0oJ3koi3nxiesOFZYYX6b-bWm=U0_wESEVSmg@mail.gmail.com>
To: Harald Alvestrand <harald@alvestrand.no>
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
On Thu, Apr 16, 2015 at 2:10 AM, Harald Alvestrand <harald@alvestrand.no>

>  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.​
Received on Thursday, 16 April 2015 14:33:07 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:43 UTC