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

Harald Alvestrand <harald@alvestrand.no> Sun, 29 January 2012 17:50 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E290521F859B for <rtcweb@ietfa.amsl.com>; Sun, 29 Jan 2012 09:50:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.598
X-Spam-Level:
X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PM5Wk2WIn5Dt for <rtcweb@ietfa.amsl.com>; Sun, 29 Jan 2012 09:50:54 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id A12C221F858F for <rtcweb@ietf.org>; Sun, 29 Jan 2012 09:50:53 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8AB4639E0F0; Sun, 29 Jan 2012 18:50:52 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FIxeSaB-wUyR; Sun, 29 Jan 2012 18:50:51 +0100 (CET)
Received: from [172.28.88.252] (unknown [74.125.122.49]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 42A1C39E03A; Sun, 29 Jan 2012 18:50:51 +0100 (CET)
Message-ID: <4F2586FA.3050606@alvestrand.no>
Date: Sun, 29 Jan 2012 18:50:50 +0100
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16
MIME-Version: 1.0
To: Colin Perkins <csp@csperkins.org>
References: <4F200F03.6090309@alvestrand.no> <76E2B8FF-A670-4632-AC8F-CCDE8A8433F0@csperkins.org>
In-Reply-To: <76E2B8FF-A670-4632-AC8F-CCDE8A8433F0@csperkins.org>
Content-Type: multipart/alternative; boundary="------------050901050408010609080600"
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] New Version Notification for draft-alvestrand-rtcweb-msid-01.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 29 Jan 2012 17:51:02 -0000

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?

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.

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

>
> - 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.

>
> 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: 	internet-drafts@ietf.org
>> To: 	harald@alvestrand.no
>> CC: 	harald@alvestrand.no
>>
>>
>>
>> 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&quot;media stream&quot; /&quot;media stream
>>     track&quot; is carried using SDP signalling.
>>
>>     This document is an input document for discussion.  It should be
>>     discussed in the RTCWEB WG list,rtcweb@ietf.org.
>>
>>
>>
>>
>>
>> The IETF Secretariat
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org <mailto:rtcweb@ietf.org>
>> https://www.ietf.org/mailman/listinfo/rtcweb
>
>
>
> -- 
> Colin Perkins
> http://csperkins.org/
>
>
>