Subject: [rtcweb] inactive m-lines in draft-ietf-rtcweb-jsep-05

From: Paul Kyzivat <[email-masked]>
Date: Tue, 29 Oct 2013 11:05:37 -0400

Scattered through this draft are references to inserting m-lines with 
a=inactive or a=recvonly, without the presence of a corresponding 
MediaStreamTrack. I don't understand how this is intended to work.

Once an offer/answer exchange has been done with that, ICE will be done, 
and after that there is an obligation to proceed with RTCP. In the case 
of recvonly there is also an expectation that packets will be arriving, 
and something needs to be done with them.

How is this expected to work? Is the browser supposed to do this in the 
absence of a MediaStreamTrack?

	Thanks,
	Paul

---

From: Martin Thomson <[email-masked]>
Date: Tue, 29 Oct 2013 11:27:34 -0700

> absence of a MediaStreamTrack?

As I understand it, and my understanding is probably imperfect [22],
the idea is that at all points where an offer or answer is
constructed, the using application has access to MediaStreamTrack
objects that relate to the various m-lines.  Mostly.

That is, prior to creating an offer, you have the MediaStreamTrack
instances that relate to what you are sending.  And Prior to creating
an answer, you have both the tracks you want to send and the ones that
you want to receive.  Adam has proposed [2] that enabling or disabling
these tracks causes the appropriate a=sendonly/etc. attribute to be
set.

The only case that is a little strange is the one relating to the
received streams when creating an initial offer, where you use the
OfferToReceiveAudio or OfferToReceiveVideo constraint in order to
indirectly control the send/recv attributes.

[22] by which I do not offer as a failing on my part, ...
[2] http://lists.w3.org/Archives/Public/public-webrtc/2013Oct/0058.html

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 29 Oct 2013 14:53:22 -0400

> objects that relate to the various m-lines.  Mostly.

My question only pertains to those cases where it doesn't.

> these tracks causes the appropriate a=sendonly/etc. attribute to be

This confuses me a little, probably because I am not well informed about 
JSEP. The above implies that for a sendrecv m-line there will be two 
MediaStreamTracks, one for sending and one for receiving. But section 
5.3.1 of JSEP seems inconsistent with that:

    For each non-rejected m= section of a given media type, if there is a
    local MediaStreamTrack of the specified type which has been added to
    the PeerConnection via addStream and not yet associated with a m=
    section, the MediaStreamTrack is associated with the m= section at
    this time.  If there are more m= sections of a certain type than
    MediaStreamTracks, some m= sections will not have an associated
    MediaStreamTrack.  If there are more MediaStreamTracks of a certain
    type than m= sections, only the first N MediaStreamTracks will be
    able to be associated in the constructed answer.  The remainder will
    need to be associated in a subsequent offer.

This maps each MediaStreamTracks of a given type to a different m-line. 
I *thought* the use of "specified type" above meant audio/video. Am I 
missing something?

> indirectly control the send/recv attributes.

I know that is one way of creating the situation I was wondering about. 
It isn't clear to me if that is the only way.

	Thanks,
	Paul

---

From: Martin Thomson <[email-masked]>
Date: Tue, 29 Oct 2013 12:07:42 -0700

On 29 October 2013 11:53, Paul Kyzivat <[email-masked]> wrote:
> This maps each MediaStreamTracks of a given type to a different m-line. I
> *thought* the use of "specified type" above meant audio/video. Am I missing
> something?

Yes.  sort of, though I'd expand "type" to encompass the concept of
compatibility.  Obviously a source with an H.264 encoder can't be
bound to an m= section that only has VP8 negotiated.

1. RTCPeerConnection binds tracks to m= sections
2. For sending tracks, that binding is tentatively made when an offer
or answer is constructed
3. Sending tracks are bound when setLocalDescription is called
4. For receiving tracks, that binding is made when the track is made,
which is when setRemoteDescription is called

When generating offers or answers, the set of bindings (including
tentative ones) - plus the enabled state of the track - determines
what of the send/recv attributes is attached to that m= section.