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

Christer Holmberg <> Fri, 14 February 2014 18:42 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 710371A0214 for <>; Fri, 14 Feb 2014 10:42:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.851
X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8BqKl4YTuSid for <>; Fri, 14 Feb 2014 10:42:01 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 70B181A02E3 for <>; Fri, 14 Feb 2014 10:41:59 -0800 (PST)
X-AuditID: c1b4fb25-b7f038e000005d01-63-52fe6375be16
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 59.0C.23809.5736EF25; Fri, 14 Feb 2014 19:41:57 +0100 (CET)
Received: from ([]) by ([]) with mapi id 14.02.0387.000; Fri, 14 Feb 2014 19:41:56 +0100
From: Christer Holmberg <>
To: Harald Alvestrand <>, "" <>
Thread-Topic: [rtcweb] Stream control: [MMUSIC] msid-04 submitted
Thread-Index: AQHPKVPuF/VJzX0Fb0yVt/Xv3TzOfJq0+6GAgAAXm1Q=
Date: Fri, 14 Feb 2014 18:41:55 +0000
Message-ID: <>
References: <>,<>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLLMWRmVeSWpSXmKPExsUyM+JvjW5p8r8gg4uzRC2O9XWxWaz9187u wORxZcIVVo8lS34yBTBFcdmkpOZklqUW6dslcGVc//eeteCvSEXzjrnsDYz/BboYOTkkBEwk Xm+9ww5hi0lcuLeerYuRi0NI4BCjxM7bC1ghnMWMEot27AKq4uBgE7CQ6P6nDdIgIhAs0fv8 PSNIWFjAQeLIYz6IsKPEnK3LmSBsK4nX2ztZQWwWAVWJXdsugk3hFfCVeHe/CCQsJOAtsflT IyOIzSmgLbF431Owckagc76fWgM2hllAXOLWk/lMEGcKSCzZc54ZwhaVePn4HyvISAkBJYlp W9MgynUkFuz+xAZha0ssW/garJxXQFDi5MwnLBMYRWchmToLScssJC2zkLQsYGRZxciem5iZ k15utIkRGAUHt/xW3cF455zIIUZpDhYlcd4Pb52DhATSE0tSs1NTC1KL4otKc1KLDzEycXBK NTBOjc9unC+X9ydRPvKy7dyq+uOb9mSu5zubJ/MprkGGc9rXX+pxrU/YS4z2/Vw5f1/R640i p3U5FvD2sggbHt/h9UFGYn7iYkvxPs9pdV82Fey4ksY7P7pA8hD3mVMb4z+L1V+xs45+5mk8 t4kxQOey0TGfI/tePmua/8PSM+/N78QjnznkuByVWIozEg21mIuKEwGWV9foUAIAAA==
Subject: Re: [rtcweb] Stream control: [MMUSIC] msid-04 submitted
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 14 Feb 2014 18:42:03 -0000

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

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.

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?

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)?


From: rtcweb [] on behalf of Harald Alvestrand []
Sent: Friday, 14 February 2014 8:06 PM
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.


-------- Original Message --------
Subject:        [MMUSIC] msid-04 submitted
Date:   Fri, 14 Feb 2014 08:10:54 +0100
From:   Harald Alvestrand <><>
To:     mmusic <><>

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.


Surveillance is pervasive. Go Dark.

mmusic mailing list<>