Re: Issue 140: mid vs. receiverId

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.

(Also, pink)

Emil

On Fri, Aug 1, 2014 at 9:08 PM, Peter Thatcher <pthatcher@google.com> wrote:
> 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.
>



-- 
https://jitsi.org

Received on Friday, 1 August 2014 20:33:05 UTC