IETF Logo Mail Archive

Re: [rtcweb] Plan A, respun

Colin Perkins <csp@csperkins.org> Wed, 08 May 2013 11:37 UTC

Return-Path: <csp@csperkins.org>
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 EF35A21F90B9 for <rtcweb@ietfa.amsl.com>; Wed, 8 May 2013 04:37:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.499
X-Spam-Level:
X-Spam-Status: No, score=-106.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 nbRBppPkvPwn for <rtcweb@ietfa.amsl.com>; Wed, 8 May 2013 04:37:29 -0700 (PDT)
Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [93.93.131.52]) by ietfa.amsl.com (Postfix) with ESMTP id BB85721F8E56 for <rtcweb@ietf.org>; Wed, 8 May 2013 04:37:29 -0700 (PDT)
Received: from [130.209.247.112] (port=63011 helo=mangole.dcs.gla.ac.uk) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from <csp@csperkins.org>) id 1Ua2gT-0008DQ-Lq; Wed, 08 May 2013 12:37:28 +0100
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset="iso-8859-1"
From: Colin Perkins <csp@csperkins.org>
In-Reply-To: <BLU169-W68E037F391A6422062CD7293BA0@phx.gbl>
Date: Wed, 08 May 2013 12:37:20 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <A2C69C32-90EC-40BF-A8D1-FB128B0FEEBF@csperkins.org>
References: <51894846.3090102@nostrum.com>, <518955FE.9000801@alum.mit.edu> <51895D71.3090000@nostrum.com>, <51896D91.9070004@alum.mit.edu>, <00c201ce4b70$986ffee0$c94ffca0$@gmail.com> <BLU169-W68E037F391A6422062CD7293BA0@phx.gbl>
To: Bernard Aboba <Bernard_Aboba@hotmail.com>
X-Mailer: Apple Mail (2.1283)
X-BlackCat-Spam-Score: -28
X-Mythic-Debug: Threshold = On =
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Plan A, respun
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: Wed, 08 May 2013 11:37:35 -0000

On 7 May 2013, at 23:33, Bernard Aboba wrote:
> Roni said: 
> 
>> I think that this mode can work in plan B as an additional case, multiple RTP streams in an m-line but the SSRC or mapping to media capture is done via RTP header extension. 
>> 
> [BA] Support for RTP extensions is supposed to be optional.  So if the RTP extension is there to help the receiver deal with the anonymous SSRC until an SDP Answer or RTP SDES packet shows up to clarify things, I can live with it.  But if supporting the RTP extension is necessary to process every RTP packet I would not be favorably inclined toward this approach. 

Agree: if we define an RTP header extension for this, it should only be used to speed-up acquisition of the relevant information that's sent in an RTCP SDES item (much like we did with RFC 6051). 

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

v2.23.0 | Report a Bug | By Email