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

[Paul Kyzivat <[e-mail]>]

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?

	Thanks,
	Paul