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 :).  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.