W3C home > Mailing lists > Public > public-webrtc@w3.org > September 2014

Re: Clarification regarding msid, label, mslabel and cname SDP attributes

From: Harald Alvestrand <harald@alvestrand.no>
Date: Tue, 16 Sep 2014 15:20:14 +0200
Message-ID: <5418390E.1040705@alvestrand.no>
To: public-webrtc@w3.org
On 09/15/2014 10:53 PM, IƱaki Baz Castillo wrote:
> Hi,
>
> Those are the per SSRC attributes Chrome currently adds (I set custom values):
>
> m=video [...]
> a=mid=videoX
> a=ssrc:66621 cname:some_cname_value
> a=ssrc:66621 msid:1234 video666
> a=ssrc:66621 mslabel:1234
> a=ssrc:66621 label:video666;
>
>
> AFAIU the only standard SSRC related attributes defined for WebRTC are:
>
> - msid: which includes the MediaStream.id and MediaStreamTrack.id, and
>    it is defined in https://tools.ietf.org/html/draft-ietf-mmusic-msid.
>
> - cname: which is the SDES for this SSRC.
>
> By reading the archive I understand that mslabel (which seems to point
> to the MediaStream.id) and label (which seems to point to the
> MediaStreamTrack.id) are deprecated.
>
> Am I right?
>
>
> Said that, I also understand that msid values depend on the
> application, which in the case of WebRTC requires the usage of a
> global "a=msid-semantic: WMS 1234" in order to announce that "1234" is
> the id of a JavaScript MediaStream.
>
> And I also understand that the a=mid attribute is not intended for the
> application but just for the SDP parser (so it can indicate stuff like
> which tracks share the same transport / RTPsession by using Bundle).
>
>
> Question: must two tracks within the same MediaStream (let's say audio
> and video) share the same cname attribute?

Yes.

 From draft-ietf-rtcweb-rtp-usage-17 section 4.9:

    Taking the discussion in Section 11 into account, a WebRTC end-point
    MUST NOT use more than one RTCP CNAME in the RTP sessions belonging
    to single RTCPeerConnection (that is, an RTCPeerConnection forms a
    synchronisation context).

So an RTCWEB endpoint MUST use the same CNAME for *all* its 
MediaStreamTracks.

>
>
> Thanks a lot.
>
>
Received on Tuesday, 16 September 2014 13:20:49 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:41 UTC