[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/>