Re: [rtcweb] Plan A, respun

Adam Roach <adam@nostrum.com> Tue, 07 May 2013 20:00 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 4D3FE21F86DE for <rtcweb@ietfa.amsl.com>; Tue, 7 May 2013 13:00:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.3
X-Spam-Level:
X-Spam-Status: No, score=-102.3 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, 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 AMUkCQKVpjwh for <rtcweb@ietfa.amsl.com>; Tue, 7 May 2013 13:00:53 -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 199F721F86CB for <rtcweb@ietf.org>; Tue, 7 May 2013 13:00:53 -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 r47K0nGl021319 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 7 May 2013 15:00:50 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <51895D71.3090000@nostrum.com>
Date: Tue, 07 May 2013 15:00:49 -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: Paul Kyzivat <pkyzivat@alum.mit.edu>
References: <51894846.3090102@nostrum.com> <518955FE.9000801@alum.mit.edu>
In-Reply-To: <518955FE.9000801@alum.mit.edu>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
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 20:00:54 -0000

On 5/7/13 14:29, Paul Kyzivat wrote:
> If I bundle an m-line without a=ssrc, and with unique PTs, do you 
> consider it ok if there are multiple "anonymous" flows each complying 
> to the attributes of the m-line?

I presume, by "multiple anonymous flows," you mean multiple series of 
packets with the same PT, but with different SSRC values.

> Or do you assume that all packets with that PT are treated as one 
> flow, switching from one SSRC to another as they are received?

In the example you gave, all of those packets are defined to be 
associated with the same media line. 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. 
Admittedly, those semantics have never been crystal clear, but my 
experience is that most systems would use this approach to send multiple 
streams that are semantically the same "thing" and should be rendered as 
one "thing" (e.g., window, speaker, etc).

Specifically, we are *not* trying to allow the situation in which (1) 
the SDP has no SSRC for the m-lines in a bundle group; (2) the party who 
generated the SDP receives multiple streams (distinguished, presumably, 
by SSRC) with the same PT, and (3) the recipient then deduces that there 
should be two different rendering outputs (e.g., windows) as a result. 
That is specifically and intentionally one of the behaviors we removed 
from the Orlando proposal, since it severely dilutes the value of 
preserving existing SDP semantics.

Does that answer the question you're answering?

/a