Re: [rtcweb] Stream control: [MMUSIC] msid-04 submitted

On 02/14/2014 07:41 PM, Christer Holmberg wrote:
> Hi Harald,
>
> When reading the text, my take is that this is more than controlling a MS and MST.
>
> You are actaually OVERRIDING the rules for sending RTCP. The rules say that RTCP is always sent, as long as the m- line is enabled (non-zero port value).
Yep, I think I'm repeating that. The question is not if RTCP is sent,
it's if this SSID is included in the RTCP sender report or not - which
the rules for RTCP do *not* dictate.
>
> Regarding "msid-control: enable", I don't think this is needed at all. The DEFAULT is whatever is the value of the existing direction attributes.
I don't think it's needed either. I included it for completeness.
>
> Regarding "msid-control: disable", what is the difference compared to using "sendonly"?
>
> Regarding "msid-control: reject", what couldn't you use "msid-control: stop" instead? If the stream has never been enabled, doesn't stop and reject mean the same thing?
As I said in the draft, I wonder about that too. People have talked
about rejecting a track at the API level; if they come out with a
sensible proposal, this should not prevent them.
Personally, my API preference is a model where tracks occur, and if you
don't want them, you have to stop them; I don't see a need for "reject".

But others might.

>
> Regarding "msid-control: stop", the text says that one guarantees that the track will not be used again. But, I assume the m- line could still be used for sending media, for another track (assuming we allow associating an m- line with another track, that is)?

Do we allow that? I don't know, and that's a problem.

>
> Regards,
>
> Christer
> ________________________________________
> From: rtcweb [rtcweb-bounces@ietf.org] on behalf of Harald Alvestrand [harald@alvestrand.no]
> Sent: Friday, 14 February 2014 8:06 PM
> To: rtcweb@ietf.org
> Subject: [rtcweb] Stream control: [MMUSIC] msid-04 submitted
>
> I created a proposal for how one could signal the receiver's desires for handling of a MediaStream as an extension to the MSID proposal.
>
> The result is in draft-ietf-mmusic-msid-04 section 5.
>
> There will be discussion in MMUSIC; comments on whether the mechanism fits the RTCWEB need may be appropriate here.
>
>          Harald
>
> -------- Original Message --------
> Subject:        [MMUSIC] msid-04 submitted
> Date:   Fri, 14 Feb 2014 08:10:54 +0100
> From:   Harald Alvestrand <harald@alvestrand.no><mailto:harald@alvestrand.no>
> To:     mmusic <mmusic@ietf.org><mailto:mmusic@ietf.org>
>
>
>
> I have submitted a new version of the MSID draft, -04.
>
> It tries to make it crystal clear that the msid-semantic:wms is only
> intended for signalling MediaStreamTracks and MediaStreams.
>
> It also adds a new functionality: msid-control, which can be used by a
> receiver of MediaStreamTracks to signal the sender of a MediaStreamTrack
> what the receiver wishes with regard to that MediaStreamTrack; this need
> has been identified within the WebRTC and RTCWEB WGs.
>
> It seemed logical to extend this draft with that functionality, since it
> is closely allied functionality.
>
> Comments are welcome.
>
>           Harald
>
> --
> Surveillance is pervasive. Go Dark.
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org<mailto:mmusic@ietf.org>
> https://www.ietf.org/mailman/listinfo/mmusic
>
>
>

-- 
Surveillance is pervasive. Go Dark.