Re: [rtcweb] SDP and ssrc-group,

["Makaraju, Maridi Raju (Raju)" <[e-mail]>]

> Sergio Garcia Murillo wrote:
> > BTW, please, please, please, let's use the sssrc-group:FEC and send the
> > FEC in its own ssrc stream, so we don't have to use RED anymore..
> 
> That may be fine for video, but the added header overhead for audio is
> substantial (and there are a number of other problems that RED solves
> there, as discussed at the last meeting).

<Raju>
I am not sure if red+ulpfec is used for audio codecs in webrtc context (in general it can be used for alternate encodings even for audio); OPUS does have a built-in FEC so no need for red+ulpfec.

For video, the RTP header overhead added by ssrc multiplexing is considerable (not significant, but can't be ignored) especially for the non-key frames and in mobile environments.
Also, there is an additional problem with ssrc multiplexing for FEC.
Use of red+ulpfec makes it easy for an SDP answerer to reject it by excluding red+ulpfec payloads if it does not support FEC. But use of a=ssrc-group:FEC makes it hard to reject the FEC part as the semantics are not supported by http://tools.ietf.org/html/rfc5576#section-8
This issue is being discussed at http://www.ietf.org/mail-archive/web/rtcweb/current/msg13249.html

While Chrome supports red+ulpfec Firefox does not (yet!). If we use a=ssrc-group:FEC then we will have an interop issue if Firefox rejects the entire video offer to strictly comply to RFC 5576 section 8.

I wish the draft-ietf-rtcweb-rtp-usage (draft-ietf-rtcweb-audio or draft-ietf-rtcweb-video) says one way or other about how to convey FEC encoding (redundant encoding or ssrc multiplexing) 

</Raju>

BR
raju