Re: Issue 140: mid vs. receiverId

I just sent an overly-long email to the github thread.  I probably
should have put it here.  So here's a shorter version:

Yeah, trackId was a dumb idea.  Sorry for suggesting it.  I forgot
that a track can be plugged into multiple RtpSenders, so indeed
"RtpParameters.trackID" doesn't make sense.   It also doesn't make
sense since you can switch the track that's plugged into the RtpSender
while it's sending it.

I'd be happy with "receiveId", "senderId" or "muxId", but not so happy
with "mid".  When someone asks "what is an MID?", we'll have to go and
say "well, it's this poorly defined thing over in SDP....".  I'd
rather avoid that.

Currently, I feel like muxId > senderId > receiverId > mid.


On Fri, Aug 1, 2014 at 3:52 PM, Bernard Aboba
<Bernard.Aboba@microsoft.com> wrote:
> One concern about use of “trackId”. Within the Statistics API, there are
> several attributes with somewhat similar names:
>
> 1.    Section 13.4.1: RTCRtpStreamStats,mediaTrackId
>
> 2.    Section 13.4.4: RTCMediaStreamTrackStats.trackIdentifier
>
> 3.    Section 13.4.5: RTCMediaStreamStats.trackIds
>
> Do these all refer to  “track.id”?
>
>
>
> From: Bernard Aboba [mailto:Bernard.Aboba@microsoft.com]
> Sent: Friday, August 1, 2014 2:15 PM
> To: public-ortc@w3.org
> Cc: Peter Thatcher; Emil Ivov
> Subject: RE: Issue 140: mid vs. receiverId
>
>
>
> Peter Thatcher said:
>
> I'd also be happy with "trackId", with a note along the lines of "the IETF
> likes to call it MID, but it's 1:1 with a track."
>
>
>
> [BA] That seems like the best way to go.
>
>
>
> Emil Ivov said:
>
>
>
> “Bernard referred to it as a "track ID" earlier today and I thought
>
> this was very natural. If we are not going to be using IETF
>
> terminology then I don't really see receiver ID as that natural of a
>
> choice.”
>
>
>
> [BA] Overall, people seem to grasp the term “track ID” better than “mid”.
> Because ORTC is a track-oriented API that doesn’t depend on SDP, I couldn’t
> understand why a “mid” RTP extension would be helpful until Peter explained
> that in “Unified Plan” the “mid” functions like a “track ID”.  Then it made
> sense to me J.  As Peter suggested, we do need to make it clear that the
> “track ID” is transported in the “mid” RTP extension (still to be defined)
> but this seems like it would be easier to get across than if we call it a
> “mid” to begin with.
>
>
>
> My concern with continuing to use the term “receiverId” is that people might
> be confused as to whether this term was related to the RTP extension defined
> in draft-even-mmusic-application-token (which talks about the app-recvId).
>
>
>
>
>
>
>
>
>
>
>
> From: Bernard Aboba [mailto:Bernard.Aboba@microsoft.com]
> Sent: Friday, August 1, 2014 11:56 AM
> To: public-ortc@w3.org
> Subject: Issue 140: mid vs. receiverId
>
>
>
> Within the IETF 90 MMUSIC WG session, Christer Holmberg discussed the future
> of the "receiver-id" within the BUNDLE draft:
>
> http://www.ietf.org/proceedings/90/slides/slides-90-mmusic-0.pdf
>
>
>
> The recommendation (which appeared to have consensus) was to "Use existing
> SDP mid attribute value as receiver-id" within SDP, as well as to enable the
> mid to be sent within an RTP extension.
>
>
>
> My understanding (please correct me if this is wrong) is that within the
> context of "Unified Plan" the mid can function as a "trackID", enabling SVC
> layers (regardless of whether SST-SS or SST-MS is being used) to be steered
> to an RTCRtpReceiver object.   As a result, mid essentially takes the place
> of the "receiverId".
>
>
>
> If that is true, then it would appear to me that references to "receiverId"
> should be replaced by "mid" in the following places in the document:
>
>
>
> Section 8.4
>
> Section 9.1
>
> Section 9.5
>
>
>
> Also, the reference in  Section A.2 to [APPID] should be replaced by a
> reference in Section A.1 to an appropriate mid RTP extension draft.

Received on Monday, 4 August 2014 20:04:23 UTC