RRID support

[aboba]

The latest RID specification introduces the RRID for identification of redundancy streams: https://tools.ietf.org/html/draft-ietf-avtext-rid

The RRID is not yet supported in ORTC (or in the WebRTC 1.0 object model, for that matter).

[robin-raymond]

I'm still confused if RID is tagged on fec/rtx streams where different SSRCs are used. I hope they carry the same RID as it would be beneficial for coordination/routing without additional signalling pains.

[pthatcherg]

The same RID value should be on all RTP streams coming out of a given encoding. So, yes, FEC/RTX streams have the same RID as the Source RTP Stream they are redundant with. And, yes, they are beneficial in avoiding signalling. That's what designed it for.

I don't see any use case for the RRID, though. It's use case is purely theoretical and it was only introduced because one of the members of the IETF WG thought it would be useful someday in those theoretical use cases. In other words, I think we should not put RRID in ORTC until someone really wants to use it, which I think will be never.

On Tue, Mar 8, 2016 at 1:54 PM, Robin Raymond notifications@github.com wrote:

I'm still confused if RID is tagged on fec/rtx streams where different SSRCs are used. I hope they carry the same RID as it would be beneficial for coordination/routing without additional signalling pains.

— Reply to this email directly or view it on GitHub https://github.com/openpeer/ortc/issues/406#issuecomment-193984228.

[ibc]

It is funny. RRID draft says:

While approaches that use unique Payload Types (PTs) per stream have been used in some applications, this is a semantic overloading of that field, and one for which its size is inadequate: in moderately complex systems that use PT to uniquely identify every potential combination of codec configuration and unique stream, it is possible to simply run out of values.

This is 90% related to #407 in which I clarify that BUNDLE spec mandates "unique PT" for stream identification:

Multiple bundled "m=" lines might represent RTP based media. As all RTP based media associated with a BUNDLE group belong to the same RTP session, in order for a given payload type value to be used inside more than one bundled "m=" line, all codecs associated with the payload type number MUST share an identical codec configuration. This means that the codecs MUST share the same media type, encoding name, clock rate and any parameter that can affect the codec configuration and packetization. [I-D.ietf-mmusic-sdp-mux-attributes] lists SDP attributes, whose attribute values must be identical for all codecs that use the same payload type value.

So RRID will never take place in WebRTC, not while WebRTC still relies on legacy stream identification mechanisms.

[aboba]

@pthatcherg - can we push back on the RRID if no one is intending to implement it? Otherwise, am ecstatic to resolve this issue as "won't fix".

[pthatcherg]

I pushed back on it to the point where it's optional to use and introduces no overhead, which means we can ignore it if we choose.

If you want to push back further, then AVTEXT is the right place to do so.

I think we can mark this "won't fix" either way.

On Tue, Mar 8, 2016 at 6:23 PM, aboba notifications@github.com wrote:

@pthatcherg https://github.com/pthatcherg - can we push back on the RRID if no one is intending to implement it? Otherwise, am ecstatic to resolve this issue as "won't fix".

— Reply to this email directly or view it on GitHub https://github.com/openpeer/ortc/issues/406#issuecomment-194074689.

[robin-raymond]

I really never see a need to have a RRID vs a RID. RID seems to handle everything we need just fine as is...

FYI - I don't see the use case and ortc-lib will not implement this unless there's a really solid justification.