Re: [rtcweb] Plan A, respun

Bernard Aboba <bernard_aboba@hotmail.com> Tue, 07 May 2013 22:33 UTC

Return-Path: <bernard_aboba@hotmail.com>
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 2D34621F8FDD for <rtcweb@ietfa.amsl.com>; Tue, 7 May 2013 15:33:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.523
X-Spam-Level:
X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 imfMRCu12err for <rtcweb@ietfa.amsl.com>; Tue, 7 May 2013 15:33:41 -0700 (PDT)
Received: from blu0-omc2-s26.blu0.hotmail.com (blu0-omc2-s26.blu0.hotmail.com [65.55.111.101]) by ietfa.amsl.com (Postfix) with ESMTP id 400EB21F8F0C for <rtcweb@ietf.org>; Tue, 7 May 2013 15:33:41 -0700 (PDT)
Received: from BLU169-W68 ([65.55.111.71]) by blu0-omc2-s26.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 7 May 2013 15:33:40 -0700
X-EIP: [KFl3oumTelNyCq+B1DcLC/nqXNu3RZcyyRfiLRn+L78=]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: <BLU169-W68E037F391A6422062CD7293BA0@phx.gbl>
Content-Type: multipart/alternative; boundary="_7b5f5020-72bf-4ee1-8871-65ab776e578f_"
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: Roni Even <ron.even.tlv@gmail.com>
Date: Tue, 07 May 2013 15:33:40 -0700
Importance: Normal
In-Reply-To: <00c201ce4b70$986ffee0$c94ffca0$@gmail.com>
References: <51894846.3090102@nostrum.com>, <518955FE.9000801@alum.mit.edu> <51895D71.3090000@nostrum.com>, <51896D91.9070004@alum.mit.edu>, <00c201ce4b70$986ffee0$c94ffca0$@gmail.com>
MIME-Version: 1.0
X-OriginalArrivalTime: 07 May 2013 22:33:40.0972 (UTC) FILETIME=[ECB14AC0:01CE4B72]
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: Tue, 07 May 2013 22:33:47 -0000

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.