Re: [rtcweb] Plan A, respun

Adam Roach <adam@nostrum.com> Tue, 07 May 2013 22:55 UTC

Return-Path: <adam@nostrum.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 EE4B221F912C for <rtcweb@ietfa.amsl.com>; Tue, 7 May 2013 15:55:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.479
X-Spam-Level:
X-Spam-Status: No, score=-102.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-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 fdE+r1Hdkhe0 for <rtcweb@ietfa.amsl.com>; Tue, 7 May 2013 15:55:20 -0700 (PDT)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5246A21F90CC for <rtcweb@ietf.org>; Tue, 7 May 2013 15:55:20 -0700 (PDT)
Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r47MtFO1040863 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 7 May 2013 17:55:15 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <51898653.1010907@nostrum.com>
Date: Tue, 07 May 2013 17:55:15 -0500
From: Adam Roach <adam@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: Roni Even <ron.even.tlv@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>
In-Reply-To: <00c201ce4b70$986ffee0$c94ffca0$@gmail.com>
Content-Type: multipart/alternative; boundary="------------090609070405040708090501"
Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism)
Cc: 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:55:21 -0000

On 5/7/13 17:16, Roni Even wrote:
> For plan A it works only if it will allow multiple RTP streams based on the same m-line.

I want to re-iterate the most important part of my answer to Paul, since 
it allows anyone who can apply apply critical thinking skills to arrive 
at the correct conclusion about what we are proposing. Here is the crux 
of my answer again, from which the remainder of my answer was derived:

    Looking at basic principles, the intention here is that the
    semantics would be identical to non-webrtc, non-bundle clients
    receiving multiple SSRCs on the same port.

So if you're going to define an extension that makes it explicit that 
multiple SSRCs in non-bundled media is intended to represent multiple 
independent streams, then you've defined that extension and it works 
just fine with Plan A.

/a