[rtcweb] #20: Section 12.2: Multiple Sources
"rtcweb issue tracker" <trac+rtcweb@trac.tools.ietf.org> Sat, 20 April 2013 01:56 UTC
Return-Path: <trac+rtcweb@trac.tools.ietf.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 27FA821F9298 for <rtcweb@ietfa.amsl.com>; Fri, 19 Apr 2013 18:56:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 hLTFjmUho9k7 for <rtcweb@ietfa.amsl.com>; Fri, 19 Apr 2013 18:56:40 -0700 (PDT)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 7934D21F9265 for <rtcweb@ietf.org>; Fri, 19 Apr 2013 18:56:40 -0700 (PDT)
Received: from localhost ([127.0.0.1]:37631 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from <trac+rtcweb@trac.tools.ietf.org>) id 1UTN2b-0002fi-IA; Sat, 20 Apr 2013 03:56:37 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: rtcweb issue tracker <trac+rtcweb@trac.tools.ietf.org>
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: draft-ietf-rtcweb-rtp-usage@tools.ietf.org, bernard_aboba@hotmail.com
X-Trac-Project: rtcweb
Date: Sat, 20 Apr 2013 01:56:37 -0000
X-URL: http://tools.ietf.org/rtcweb/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/rtcweb/trac/ticket/20
Message-ID: <066.c8aa32ad209e20e9da587ad635946918@trac.tools.ietf.org>
X-Trac-Ticket-ID: 20
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: draft-ietf-rtcweb-rtp-usage@tools.ietf.org, bernard_aboba@hotmail.com, rtcweb@ietf.org
X-SA-Exim-Mail-From: trac+rtcweb@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: csp@csperkins.org, jorg.ott@aalto.fi, magnus.westerlund@ericsson.com
Resent-Message-Id: <20130420015640.7934D21F9265@ietfa.amsl.com>
Resent-Date: Fri, 19 Apr 2013 18:56:40 -0700
Resent-From: trac+rtcweb@trac.tools.ietf.org
Cc: rtcweb@ietf.org
Subject: [rtcweb] #20: Section 12.2: Multiple Sources
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
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: Sat, 20 Apr 2013 01:56:41 -0000
#20: Section 12.2: Multiple Sources 12.2. Multiple Sources A WebRTC end-point might have multiple cameras, microphones or audio inputs and thus a single end-point can source multiple RTP media streams of the same media type concurrently. Even if an end-point does not have multiple media sources of the same media type it has to support transmission using multiple SSRCs concurrently in the same RTP session. This is due to the requirement on an WebRTC end-point to support multiple media types in one RTP session. For example, one audio and one video source can result in the end-point sending with two different SSRCs in the same RTP session. As multi-party conferences are supported, as discussed below in Section 12.3, a WebRTC end-point will need to be capable of receiving, decoding and play out multiple RTP media streams of the same type concurrently. tbd: Are any mechanism needed to signal limitations in the number of active SSRC that an end-point can handle? [BA] There are some additional nasty problems that come up here in the case where there are multiple sources that are each utilizing simulcast/layered coding. Among other things, there needs to be a way in RTP (not just SDP) to make it clear how the RTP streams relate. For example, imagine a mixer that is receiving simulcast/layered coding from multiple sources. What set of SSRCs issue from that mixer, and what is contained in the SDES packet that lets a receiver know that the multiple SSRCs represent layered coding from a single source? I presume the SRCNAME document was one attempt at handling this problem, but since that didn't become a WG work item, we're still left with an unfilled need. And no, this isn't handled in any of the GRUMBLE/FUMBLE/MUMBLE proposals. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-rtcweb-rtp- bernard_aboba@hotmail.com | usage@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: milestone1 Component: rtp-usage | Version: 1.0 Severity: Active WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: <http://trac.tools.ietf.org/wg/rtcweb/trac/ticket/20> rtcweb <http://tools.ietf.org/rtcweb/>
- [rtcweb] #20: Section 12.2: Multiple Sources rtcweb issue tracker