Subject: Re: [rtcweb] draft-ietf-rtcweb-jsep-05 - Recycling m-lines

From: Paul Kyzivat <[email-masked]>
Date: Fri, 01 Nov 2013 14:45:35 -0700

Section 5.2.2 (Subsequent Offers) says:

    o  If a m= section was rejected, i.e. has had its port set to zero in
       either the local or remote description, it MUST remain rejected
       and have a zero port in the new offer, as indicated in RFC3264,
       Section 5.1.

That 3264 reference is to a section about the initial offer, and so is 
irrelevant to the case. The relevant section is:

    8.1 Adding a Media Stream

    New media streams are created by new additional media descriptions
    below the existing ones, or by reusing the "slot" used by an old
    media stream which had been disabled by setting its port to zero.

IOW, previously rejected m-lines may be recycled.

Later in 5.2.2:

    o  If a m= section exists in the current local description, but has
       its state set to inactive or recvonly, and a new MediaStreamTrack
       is added, the previously existing m= section MUST be recycled
       instead of creating a new m= section.  [OPEN ISSUE: Nail down
       exactly what this means.  Should the codecs remain the same?
       (No.)  Should ICE restart?  (No.)  Can the "a=mid" attribute be
       changed?  (Yes?)]

This seems to assume that there is no existing MediaStreamTrack for 
these m-lines.

If there is, then
- the m-line shouldn't be recycled.
If there isn't, then
- where do its address and port come from?
- what is managing the RTCP?

	Thanks,
	Paul

---

From: Justin Uberti <[email-masked]>
Date: Sun, 3 Nov 2013 23:09:10 -0800

> IOW, previously rejected m-lines may be recycled.

Right you are.

> This seems to assume that there is no existing MediaStreamTrack for these
> m-lines.
>
> Yes. The text should state that more clearly.

> - what is managing the RTCP?

The m= section will still have completed ICE negotiation, despite being
marked as inactive. So the address/port information should already be
present.

I don't follow your question about who is managing RTCP.

>
>         Thanks,
>         Paul
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 06 Nov 2013 12:36:32 -0800

On 11/3/13 11:09 PM, Justin Uberti wrote:
>
> On Fri, Nov 1, 2013 at 2:45 PM, Paul Kyzivat <[email-masked]
> <mailto:[email-masked]>> wrote:
...
> marked as inactive. So the address/port information should already be

*Why* would you do this if there is no MediaStreamTrack and hence no 
possibility of using the port?

IOW, why not use port zero in these cases?

> I don't follow your question about who is managing RTCP.

It may be a misunderstanding on my part.

My thinking is that the MediaStreamTrack is a surrogate for the resource 
that manages the RTP/RTCP for that track. If so, then no track -> no RTCP.

Of course, with bundling, that resource gets spread across multiple 
MediaStreamTracks.

	Thanks,
	Paul

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 06 Nov 2013 21:59:13 +0100

On 11/06/2013 09:36 PM, Paul Kyzivat wrote:
> My thinking is that the MediaStreamTrack is a surrogate for the
> resource that manages the RTP/RTCP for that track. If so, then no
> track -> no RTCP.
>

That's why thinking of it in the way you suggest is likely to lead to
misunderstandings and confusion all around.

I've had greater success thinking of a MediaStreamTrack as an SSRC; the
resource that manages the RTP/RTCP is then a container that contains MSTs.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 06 Nov 2013 22:19:53 -0800

> resource that manages the RTP/RTCP is then a container that contains MSTs.

Isn't that container the PeerConnection? Or are you thinking that the 
PeerConnection contains one of these containers for each distinct 
RTP-Session?

	Thanks,
	Paul

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 07 Nov 2013 07:34:04 +0100

> PeerConnection contains one of these containers for each distinct

The latter.

In other contexts, I've tentatively labelled the container "RTP
Transport", since the word "RTP Session" encompasses all the endpoints
that participate in a session. "RTP Endpoint" might be accurate, too;
it's been a few days since I last looked at the terminology docs.