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
