Opened 8 years ago

Last modified 8 years ago

#21 new defect

Section 4.1: max-ssrc

Reported by: bernard_aboba@… Owned by: draft-ietf-rtcweb-rtp-usage@…
Priority: minor Milestone: milestone1
Component: rtp-usage Version: 1.0
Severity: Active WG Document Keywords:
Cc:

Description

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

Change History (1)

comment:1 Changed 8 years ago by bernard_aboba@…

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

Note: See TracTickets for help on using tickets.