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
