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

From: Harald Alvestrand <[email-masked]>
Date: Fri, 14 Feb 2014 19:06:47 +0100

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 <[email-masked]>
To: 	mmusic <[email-masked]>

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
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 14 Feb 2014 18:41:55 +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)?

Regards,

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

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 <[email-masked]><mailto:[email-masked]>
To:     mmusic <[email-masked]><mailto:[email-masked]>

Comments are welcome.

          Harald

_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 14 Feb 2014 21:44:44 +0100

> 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: 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…

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

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 19 Feb 2014 00:35:47 +0100

One thing I did not add in my previous reply:

If an offerer sets the direction of an m-line to sendrecv, and the
answerer sets the direction to sendonly, the offerer will have no
indication of whether the answerer intended the suspension of traffic to
be temporary (msid-control: disable) or permanent (msid-control: reject
or msid-control: stop).

That was actually the main concern that drove the desire for a new
mechanism.
Once the new mechanism was in place, it seemed logical to be explicit
about the other possible actions too, rather than relying on the
sendrecv/sendonly/recvonly parameter.

          Harald

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 19 Feb 2014 08:19:00 +0000

Hi,

If the indication is “permanent”, rather than using a new msid-control attribute, could it be indicated by NOT including some information in the Answer?

Regards,

Christer

Sent from Windows Mail

From: 'Harald Alvestrand'<mailto:[email-masked]>
Sent: ‎Wednesday‎, ‎February‎ ‎19‎, ‎2014 ‎1‎:‎35‎ ‎AM
To: Hans-Christer Holmberg<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>

          Harald

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 19 Feb 2014 19:12:35 +0100

On 02/19/2014 09:19 AM, Christer Holmberg wrote:
> Hi,
>
> If the indication is “permanent”, rather than using a new msid-control
> attribute, could it be indicated by NOT including some information in
> the Answer?

Certainly, but then you have to include some information in the answer
when the indication is not permanent.

Which information were you thinking of utilizing as a signal?

>
> Regards,
>
> Christer
>
> Sent from Windows Mail
>
> *From:* 'Harald Alvestrand' <mailto:[email-masked]>
> *Sent:* ‎Wednesday‎, ‎February‎ ‎19‎, ‎2014 ‎1‎:‎35‎ ‎AM
> *To:* Hans-Christer Holmberg <mailto:[email-masked]>,
> [email-masked] <mailto:[email-masked]>
>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 19 Feb 2014 20:50:35 +0000

Hi,

If the indication is NOT permanent, can't we use the existing direction attributes (sendrecv, sendonly etc)?

Regards,

Christer

Sent from my Sony Ericsson Xperia arc S

Harald Alvestrand <[email-masked]> wrote:

Certainly, but then you have to include some information in the answer when the indication is not permanent.

Regards,

Christer

Sent from Windows Mail

          Harald

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 20 Feb 2014 01:22:39 +0100

> If the indication is NOT permanent, can't we use the existing direction attributes (sendrecv, sendonly etc)?

We could - but how would we then indicate "permanent"?

Omitting the direction attribute means the same as "sendrecv", if I'm
not mistaken. So you can't have meant omitting that.

So what were you suggesting?

>> If the indication is “permanent”, rather than using a new
>> msid-control attribute, could it be indicated by NOT including some
>> information in the Answer?
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 20 Feb 2014 20:31:22 +0000

Hi,

My suggestion was to omit something else. But, at the moment I don’t have the drafts in front of me, so I can’t suggest anything specific.

Regards,

Christer

Sent from Windows Mail

From: 'Harald Alvestrand'<mailto:[email-masked]>
Sent: ‎Thursday‎, ‎February‎ ‎20‎, ‎2014 ‎2‎:‎22‎ ‎AM
To: Hans-Christer Holmberg<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>

Hi,

Omitting the direction attribute means the same as "sendrecv", if I'm not mistaken. So you can't have meant omitting that.

Regards,

Christer

Harald Alvestrand <[email-masked]><mailto:[email-masked]> wrote:

Regards,

Christer

Sent from Windows Mail

          Harald