Re: [rtcweb] SDP and ssrc-group,

Hi,

>Sounds like a reasonable idea to me, but don't you have to specify a strict pecking order? RTX before FEC doesn't sound right to me, but that's pure prejudice/bias (FEC is always present, and optional stuff his last)
>
>So how would you decide that order? A hat? PT value? Order of PT on the m line? Order of the fmtp attributes? Something else? Or can we simply fix the order, since there are only a small number of variations to consider?

Without commenting on this specific mechanism, in general we should NOT define solutions which assume a certain order of attributes (associated with a given m- line, or on session level) etc.

I have seen nodes, where the order of attributes has changed between the incoming- and outgoing SDP, due to the way the parser in the node is implemented.

I also don’t think we should change the semantics of the PT order in the m- line.

Regards,

Christer

On Oct 28, 2014 9:24 PM, "Justin Uberti" <juberti@google.com<mailto:juberti@google.com>> wrote:
So it's not clear to me that a=ssrc:X fmtp:Y is actually legal, without any fmtp parameters, or that it clearly indicates that only PT Y is to be sent on that SSRC. As such, I consider this solution to be wishful thinking.

I think it would be easier if we defined FEC/FID semantics such that the initial SSRC was to be used for the primary encoding, and any subsequent SSRCs were used for the secondary/tertiary streams. (e.g. RTX or FEC)

e.g. for a stream with 2 video codecs, RTX and 1d/2d FEC:

     m=video 30000 RTP/AVP 100 101 108 109 110 111
     c=IN IP4 233.252.0.1
     a=rtpmap:100 VP8/90000
     a=rtpmap:101 VP9/90000
     a=rtpmap:108 rtx/90000
     a=rtpmap:109 rtx/90000
     a=fmtp:108 apt=100
     a=fmtp:109 apt=101
     a=rtpmap:110 interleaved-parityfec/90000
     a=fmtp:110 L:5; D:10; ToP:2; repair-window:200000
     a=rtpmap:111 non-interleaved-parityfec/90000
     a=fmtp:111 L:5; D:10; ToP:2; repair-window:200000
     a=ssrc:1234
     a=ssrc:2345
     a=ssrc:3456
     a=ssrc:4567
     a=ssrc-group:FID 1234 2345
     a=ssrc-group:FEC-FR 1234 3456 4567

SSRC 1234 is the primary encoding (VP8 or VP9)
SSRC 2345 is RTX (either PT 108 or 109, as needed)
SSRC 3456 is FEC (either PT 110 or 111, depending on impl)
SSRC 4567 is FEC (either PT 110 or 111, depending on impl)

On Thu, Oct 23, 2014 at 12:29 PM, Makaraju, Maridi Raju (Raju) <Raju.Makaraju@alcatel-lucent.com<mailto:Raju.Makaraju@alcatel-lucent.com>> wrote:
>
> Makaraju, Maridi Raju (Raju) wrote:
> > OPUS does have a built-in FEC so no need for red+ulpfec.
>
> As discussed previously on this list [1] the built-in FEC only covers
> the SILK layer. Existing codec-agnostic mechanisms were perfectly
> adequate for protecting CELT-mode packets, so we didn't invent something
> new.
>
> [1] https://www.ietf.org/mail-archive/web/rtcweb/current/msg12353.html
[Raju] Thanks and appreciate the reference.

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org<mailto:rtcweb@ietf.org>
https://www.ietf.org/mailman/listinfo/rtcweb

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org<mailto:rtcweb@ietf.org>
https://www.ietf.org/mailman/listinfo/rtcweb