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

From: "rtcweb issue tracker" <[email-masked]>
Date: Sun, 25 Aug 2013 22:20:33 -0000

#21: Section 4.1: max-ssrc

 (tbd: is draft-westerlund-mmusic-max-ssrc-01 needed?)

 [BA] I am not a fan of max-ssrc.  Within layered coding it is possible to
 send multiple layers either with the same SSRC or with different SSRCs.
 In such a case the maximum number of layers that can be sent or received,
 and the number of maximum number of SRCNAMEs, is more relevant that the
 maximum number of SSRCs.  Therefore I would prefer not to see max-ssrc
 used in WebRTC (or anything else, for that matter).

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

Ticket URL: <http://tools.ietf.org/wg/rtcweb/trac/ticket/21>
rtcweb <http://tools.ietf.org/rtcweb/>

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 26 Aug 2013 08:20:01 +0200

>  used in WebRTC (or anything else, for that matter).

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?

cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: "rtcweb issue tracker" <[email-masked]>
Date: Mon, 26 Aug 2013 07:10:18 -0000

Comment (by [email-masked]):

 [Magnus Westerlund]

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

 Severity:  Active WG Document       |  Resolution:
 Keywords:                           |

Ticket URL: <http://trac.tools.ietf.org/wg/rtcweb/trac/ticket/21#comment:1>
rtcweb <http://tools.ietf.org/rtcweb/>