Re: [rtcweb] #21: Section 4.1: max-ssrc

"rtcweb issue tracker" <> Mon, 26 August 2013 07:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4DCA511E816F for <>; Mon, 26 Aug 2013 00:10:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.599
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 90-Zb1VbMUHI for <>; Mon, 26 Aug 2013 00:10:47 -0700 (PDT)
Received: from ( [IPv6:2a01:3f0:1:2::30]) by (Postfix) with ESMTP id 1806611E8162 for <>; Mon, 26 Aug 2013 00:10:46 -0700 (PDT)
Received: from localhost ([]:40301 ident=www-data) by with esmtp (Exim 4.80) (envelope-from <>) id 1VDqwM-0007JF-QY; Mon, 26 Aug 2013 09:10:18 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: rtcweb issue tracker <>
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
X-Trac-Project: rtcweb
Date: Mon, 26 Aug 2013 07:10:18 -0000
Message-ID: <>
References: <>
X-Trac-Ticket-ID: 21
In-Reply-To: <>
X-SA-Exim-Scanned: No (on; SAEximRunCond expanded to false
Resent-Message-Id: <>
Resent-Date: Mon, 26 Aug 2013 00:10:46 -0700
Subject: Re: [rtcweb] #21: Section 4.1: max-ssrc
X-Mailman-Version: 2.1.12
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 26 Aug 2013 07:10:50 -0000

#21: Section 4.1: max-ssrc

Comment (by

 [Magnus Westerlund]

 I find this comment intriguing and I think important to understand for
 the usage of SVC in context of a single RTP session. So you are saying
 that you intended to use multi-stream transmission of SVC within a
 single RTP session. Could you please expand on the motivation for this
 as it will be a requirement effecting signalling requirements. I would
 note that SVC MST media streams with multiple media sources in a single
 RTP stream may have issues being correctly associated.

 Regarding Max-SSRC signalling:
 Okay, let me reformulate this question from SSRCs to media decoders.
 This as the max-ssrc is designed to be able to express limitations on
 number of simultaneous decoders for different codecs a receiver can
 handle through the usage of the SSRC and PT combination. Other designs
 for this type of signaling is possible.

 Are there interest in the WG to be able to indicate the limitations of a
 receiver in how many simultaneous media streams a receiver can decode
 and thus makes sense to transmit to it?

 [BA] Yes "multi-SSRC" transmission can be used within a single RTP
 session.  RFC 6190 uses the term "multi-session transmission", but does
 not require that multiple sessions be used.  There are several motivations
 for this, including: 1) not needing to rewrite sequence numbers or RTCP
 messages when RTP streams are dropped; 2) being able to use FEC only on
 some layers (e.g. base layer only).  Advantage 1) can translate into not
 needing to decrypt streams in the MANE in some circumstances, just forward
 and drop.  With respect to being associated, there is a need to signal
 this (e.g. a=ssrc-group:DDP) and also for an RTP extension (and maybe
 SDES, too).

 Yes, "max-decoders" is better than "max-ssrc".  Personally, I think this
 is worth working on (but probably in MMUSIC, not RTCWEB).

 Reporter:                           |       Owner:  draft-ietf-rtcweb-rtp-          |
     Type:  defect                   |      Status:  new
 Priority:  minor                    |   Milestone:  milestone1
Component:  rtp-usage                |     Version:  1.0
 Severity:  Active WG Document       |  Resolution:
 Keywords:                           |

Ticket URL: <>
rtcweb <>