Re: [rtcweb] New Version Notification for draft-alvestrand-rtcweb-msid-01.txt

[Colin Perkins <[e-mail]>]

On 29 Jan 2012, at 17:50, Harald Alvestrand wrote:
> On 01/29/2012 06:27 PM, Colin Perkins wrote:
>> 
>> Harald,
>> 
>> A couple of minor points on this draft:
> Thanks for the review!
>> 
>> - Section 2 lists an open issue on when the recipient should signal that a track is closed, suggesting either when the maid disappears from the description, when a BYE packet is received, or when a timeout passes with no media as options. The RTP rules for the latter two cases are defined by RFC 3550 sections 6.3.4 and 6.3.5, and it would be appropriate for this draft to follow, and reference, then, rather than trying to define something new.
> 
> Thanks for the pointers!
> 
> The phenomenon of MediaStreamTrack and the SSRC are not necessarily 100% aligned, but if I interpret you correctly, you think that a track should be signalled closed when its corresponding SSRC is removed from the senders list, and not in response to any changes in signalling?
> 
> Or do you think we should signal a MediaStreamTrack closed in all 3 cases?

I'm not sure I understand the definition of MediaStreamTrack well enough to answer that question, but if we do use RTCP BYE or RTP-level timeouts to signal that a track has been closed, it should be done following the RFC 3550 rules, rather than by inventing a different set of rules. 

> Do you think we should add an SSRC to the sender table when it is seen in an SDP configuration? If not,  MediaStreamTracks that never get any RTP packets never time out, which seems a bit odd.

Section 5 of RFC 5576 talks about this ("sources that are only known through SDP, for which neither RTP nor RTCP packets have been received, MUST NOT be counted for RTP group size estimation", etc.). I interpret that as saying that you mark an SSRC learnt about via SDP as reserved, so you don't pick it using random SSRC selection, but don't consider it as existing in the RTP session until you receive an RTP/RTCP packet with that SSRC. That is, sending an SDP with an "a=ssrc:" line says "I plan to use this SSRC", but the SSRC doesn't come into being until you send an RTP or RTCP packet using it. 

This may mean that MediaStreamTrack needs a "potential" state, as well as open and closed.

> (I assume that the "sender table" in 6.3.4 and the "sender list" in 6.3.5 are the same thing)

Yes.

>> - Section 3: is "a=ssrc:??? sending:off" is signalled, clarify whether RTCP is sent for that SSRC (yes, presumably, otherwise it'll time out in the RTP code).
> Being lazy, and because this is an "elsewhere" definition, I'd prefer to have that clarification made in section 2 of draft-lennox-mmusic-sdp-source-selection. But I agree, and would also think RTCP should be sent for muted streams.

Sure - I already sent a comment to Jonathan Lennox along those lines.

Colin


>> 
>> Colin
>> 
>> 
>> 
>> On 25 Jan 2012, at 14:17, Harald Alvestrand wrote:
>>> I have updated this draft with a proposal to add an identifier for the index of the mediastreamtrack inside a mediastream, and an inclusion-by-reference that is my proposal to solve the muting problem.
>>> 
>>> Comments appreciated.
>>> 
>>>                     Harald
>>> 
>>> -------- Original Message --------
>>> Subject:	New Version Notification for draft-alvestrand-rtcweb-msid-01.txt
>>> Date:	Wed, 25 Jan 2012 05:25:44 -0800
>>> From:	[e-mail]
>>> To:	[e-mail]
>>> CC:	[e-mail]
>>> 
>>> A new version of I-D, draft-alvestrand-rtcweb-msid-01.txt has been successfully submitted by Harald Alvestrand and posted to the IETF repository.
>>> 
>>> Filename:	 draft-alvestrand-rtcweb-msid
>>> Revision:	 01
>>> Title:		 Signalling Media Stream ID in the Session Description Protocol
>>> Creation date:	 2012-01-25
>>> WG ID:		 Individual Submission
>>> Number of pages: 9
>>> 
>>> Abstract:
>>>    This document specifies how the association between the RTP concept
>>>    of SSRC and the WebRTC concept of "media stream" / "media stream
>>>    track" is carried using SDP signalling.
>>> 
>>>    This document is an input document for discussion.  It should be
>>>    discussed in the RTCWEB WG list, [e-mail].
>>> 
>>> 
>>>                                                                                   
>>> 
>>> 
>>> The IETF Secretariat
>>> 
>>> _______________________________________________
>>> rtcweb mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>> 
>> 
>> 
>> -- 
>> Colin Perkins
>> http://csperkins.org/
>> 
>> 
>> 
> 
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb



-- 
Colin Perkins
http://csperkins.org/