RE: Issue 140: mid vs. receiverId

I agree with most of the below.  Only point which I may disagree with is whether an RTCRtpSender sending simulcast streams will always have the same value for the "mid" RTP extension for each outgoing simulcast stream.  IMHO, the "mid" RTP extension could be different for each outgoing simulcast stream (though it would be the same for each incoming simulcast stream).  For this reason I don't like the "senderId" term (since it is not necessarily the same for simulcast streams sent by an RTCRtpSender).  Could live with "muxId".    

Question:  Should "muxId" be removed from RTCRtpParameters and instead be in RTCRtpEncodingParameters?  If the "muxId" can be different with each outoing simulcast stream, this makes sense.

-----Original Message-----
From: Peter Thatcher [mailto:pthatcher@google.com] 
Sent: Monday, August 4, 2014 1:03 PM
To: Bernard Aboba
Cc: public-ortc@w3.org; Emil Ivov
Subject: 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:20:28 UTC