> 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?
I can confirm it used to happen in Firefox 37, I'm not sure about Firefox 36 though (are old downloads available someplace?). The jump in video quality only seems to affect 38, though. > 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. The good news here is, FreeSWITCH is already working on a mass refactor of all their rtp/rtcp negotiation (https://freeswitch.org/jira/browse/FS-7499). Unfortunately this is occurring on a branch off master, so something that would be production-stable is probably a far way off. I'm working on getting a small patch together based on their refactor to get the pli's working. On Friday, May 15, 2015 at 10:21:43 AM UTC-4, 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. > > -- > Randell Jesup, Mozilla _______________________________________________ dev-media mailing list [email protected] https://lists.mozilla.org/listinfo/dev-media
