IETF Logo Mail Archive

Re: [rtcweb] Plan A, respun

Bernard Aboba <bernard_aboba@hotmail.com> Tue, 07 May 2013 21:45 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 CF7B021F91B0 for <rtcweb@ietfa.amsl.com>; Tue, 7 May 2013 14:45:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.598
X-Spam-Level:
X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[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 Lq-AjisTLCiP for <rtcweb@ietfa.amsl.com>; Tue, 7 May 2013 14:44:56 -0700 (PDT)
Received: from blu0-omc2-s14.blu0.hotmail.com (blu0-omc2-s14.blu0.hotmail.com [65.55.111.89]) by ietfa.amsl.com (Postfix) with ESMTP id 9584B21F912C for <rtcweb@ietf.org>; Tue, 7 May 2013 14:44:56 -0700 (PDT)
Received: from BLU169-W42 ([65.55.111.72]) by blu0-omc2-s14.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 7 May 2013 14:44:56 -0700
X-EIP: [SXuLA96QGEWTKw19I1/m+A4SjizflPTslu+z0h12QX8=]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: <BLU169-W4273890266755A522DB03A93BA0@phx.gbl>
Content-Type: multipart/alternative; boundary="_ec29dd5c-2a83-4cad-a492-86bbb5a84cf8_"
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: Adam Roach <adam@nostrum.com>
Date: Tue, 07 May 2013 14:44:55 -0700
Importance: Normal
In-Reply-To: <51896D91.9070004@alum.mit.edu>
References: <51894846.3090102@nostrum.com> <518955FE.9000801@alum.mit.edu>, <51895D71.3090000@nostrum.com>, <51896D91.9070004@alum.mit.edu>
MIME-Version: 1.0
X-OriginalArrivalTime: 07 May 2013 21:44:56.0270 (UTC) FILETIME=[1D6F2EE0:01CE4B6C]
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 21:45:03 -0000

Adam Roach said:

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

The "existing SDP semantics" have allowed multiplexing of RTP streams from multiple SSRCs on the 
same RTP session without explicit declaration since multicast days -- and this behavior is implemented within a number of shipping video implementations.  In fact, dealing with this is proposed as a MUST within the RTP Usage document. 

If an event is triggered for a newly encountered (but undeclared) SSRC, this can be handled by the web application which can take care of making sure that new RTP stream is appropriately rendered.  Applications (including open source ones, such as Jitsi) do this today.

v2.23.0 | Report a Bug | By Email