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

[Harald Alvestrand <[e-mail]>]

On 11/07/2013 07:19 AM, Paul Kyzivat wrote:
> On 11/6/13 12:59 PM, Harald Alvestrand wrote:
>> On 11/06/2013 09:36 PM, Paul Kyzivat wrote:
>>> On 11/3/13 11:09 PM, Justin Uberti wrote:
>>>>
>>>> On Fri, Nov 1, 2013 at 2:45 PM, Paul Kyzivat <[e-mail]
>>>> <mailto:[e-mail]>> wrote:
>>> ...
>>>>      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.
>>>>
>>>> Yes. The text should state that more clearly.
>>>>
>>>>      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?
>>>>
>>>>
>>>> The m= section will still have completed ICE negotiation, despite
>>>> being
>>>> marked as inactive. So the address/port information should already be
>>>> present.
>>>
>>> *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.
>>
>> 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.
>
> Isn't that container the PeerConnection? Or are you thinking that the
> PeerConnection contains one of these containers for each distinct
> RTP-Session?

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.