Re: Issue 140: mid vs. receiverId

I agree that we can switch to using the MID header extension from the
APPID header extension, but I'd prefer not to have "MID" in the ORTC
spec.  Can we keep calling it "receiverId"? It makes so much more
sense in the context of ORTC.  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."

On Fri, Aug 1, 2014 at 11:56 AM, Bernard Aboba
<Bernard.Aboba@microsoft.com> wrote:
> 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 Friday, 1 August 2014 19:09:49 UTC