Hi Byron, I just gave that a try, it's still adding the other rtcp-fb lines. I haven't built FF from source before, but I'm reasonably certain I did build it with your commit on top. I pulled the commit, checked the log to see that it was on top, then built and ran.
I guess the conversation can move over to that bug, so once I set up a bugzilla account I'll start debugging and let you know what comes up. Thanks, James On Friday, May 15, 2015 at 7:25:21 PM UTC-4, Byron Campen wrote: > I have a fix here: https://bugzilla.mozilla.org/show_bug.cgi?id=1165520 > > Best regards, > Byron Campen > > On 5/15/15 7:21 AM, Randell Jesup wrote: > > On 5/14/2015 2:23 PM, [email protected] wrote: > >> Hello, > >> > >> I've been doing a lot of research into this, but I figured I'd post > >> what I've discovered so far here to see if there's anybody who knows > >> more. > >> > >> I have a server that does not support rtcp pli (FreeSWITCH), that > >> ends up between two browser endpoints. When this server sends its > >> offer, the only rtcp-fb present is: > >> > >> a=rtcp-fb:99 ccm fir > >> > >> Firefox answers with: > >> > >> a=rtcp-fb:99 nack > >> a=rtcp-fb:99 nack pli > >> a=rtcp-fb:99 ccm fir > >> > >> > >> When Firefox generates the offer, a similar situation occurs, except > >> VP8 is listed under 120, instead of 99. In the case detailed above, > >> I'm not sure if the server is supposed to reply with an updated offer > >> to settle the disagreement, but even so, Firefox moves on as if the > >> other side did agree to those 3 parameters. > > > > Ok, if we're answering that way we're wrong: RFC 4585 4.2 > > > > When used in conjunction with the offer/answer model [8 > > <http://tools.ietf.org/html/rfc4585#ref-8>], the offerer > > MAY present a set of these AVPF attributes to its peer. The answerer > > MUST remove all attributes it does not understand as well as those it > > does not support in general or does not wish to use in this > > particular media session. The answerer MUST NOT add feedback > > parameters to the media description and MUST NOT alter values of such > > parameters. The answer is binding for the media session, and both > > offerer and answerer MUST only use feedback mechanisms negotiated in > > this way. Both offerer and answerer MAY independently decide to send > > RTCP FB messages of only a subset of the negotiated feedback > > mechanisms, but they SHOULD react properly to all types of the > > negotiated FB messages when received. > > > > > >> I have not taken traces to identify if this occurs in the other > >> direction as well (since the sdp is inconclusive about it), but it's > >> possible. > > > > Hmmm. We do look at the local SDP to set the recovery type, so if our > > answer has the wrong options, then we'll set up the channel using > > those. In WebrtcVideoConduit::ConfigureRecvMediaCodecs(): > > > > // Check for the keyframe request type: PLI is preferred over FIR, > > and FIR is preferred over none. > > if (codecConfigList[i]->RtcpFbNackIsSet("pli")) > > { > > kf_request = webrtc::kViEKeyFrameRequestPliRtcp; > > } else if(kf_request == webrtc::kViEKeyFrameRequestNone && > > codecConfigList[i]->RtcpFbCcmIsSet("fir")) > > { > > kf_request = webrtc::kViEKeyFrameRequestFirRtcp; > > } > > // Check whether NACK is requested > > if(codecConfigList[i]->RtcpFbNackIsSet("")) > > { > > use_nack_basic = true; > > } > > > > > >> Once the call is established between browsers, video deteriorates > >> until the keyframe refresh. This was not happening in Firefox 37, so > >> it appears a change may have occurred to make Firefox more reliant > >> upon the rtcp pli in version 38. In the same situation, Chrome only > >> responds with 'ccm fir' and video keeps good quality throughout. > > > > We did a major rewrite of the negotiation code in 37, and in 38 added > > multistream and bundle (and a lot of fixes for things); so it's > > certainly possible there was a regression in 38. Did 37 (or 36) > > answer in the same way to a "ccm fir"-only offer? > > > >> > >> There is (untested) code in FreeSWITCH for rtcp plis, but it was > >> commented out later when it caused other video issues (fast source > >> switches, as seen in conferences, would not work well). That was also > >> a Firefox only issue, because Firefox always sent rtcp pli requests, > >> where as Chrome could negotiate without it. The plis were, and still > >> are, just not responded to by FreeSWITCH, but I believe it is now > >> causing the deterioration. > > > >> I'm not sure if rtcp pli is a necessity for all WebRTC endpoints at > >> this point, and if so, I'll have to look into getting that working in > >> FreeSWITCH. In terms of Firefox, shouldn't it take the rtcp-fb params > >> of the offer into account when generating its answer? > > > > draft-ietf-rtcweb-rtp-usage-23: > > (http://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-23) says you > > really should support PLI: > > > > 5.1.1 > > ... WebRTC Endpoints that are sending media > > MUST understand and react to FIR feedback messages they receive, > > since this greatly improves the user experience when using > > centralised mixer-based conferencing. Support for sending FIR > > messages is OPTIONAL. > > > > 5.1.2 > > ... WebRTC Endpoints that are sending media MUST understand > > and react to PLI feedback messages as a loss tolerance mechanism. > > Receivers MAY send PLI messages. > > > > Note: those are separate from the issue of SDP & negotiation, but it > > implies you should not reject PLI and clearly must process them if > > received. It also implies you should agree to PLI in the SDP. > > _______________________________________________ dev-media mailing list [email protected] https://lists.mozilla.org/listinfo/dev-media
