2017-03-22 15:19 GMT+01:00 Bo Xu <
boxus...@gmail.com>:
> I just have a question about webRTC Congestion Control: there are several
> advanced algorithms like Pre-filtering/arrive-time filter/over-use detector
> are using in webRTC , my question is: if I do P2P video from chrome to my
> own terminal(supporting H.264+DTLS+ICE), does my own terminal also need to
> implement those webRTC Congestion Control algorithms using by chrome? if my
> own terminal doesn't support them, can it still do P2P video to chrome
> correctly? or there will be a problem there?
Your endpoint needs to implement whichever it announces in its SDP
regarding a=rctp-fb lines.
Currently Chrome implements REMB and Transport-CC as congestion
control protocols:
https://tools.ietf.org/html/draft-alvestrand-rmcat-remb-03
https://tools.ietf.org/html/draft-holmer-rmcat-transport-wide-cc-extensions-01
Those are announced into the SDP via "goog-remb" and "transport-cc" in
a=rtcp-fb lines.
> the reason I ask this question is: when my own terminal does P2P video to a
> chrome, the video connection will stopped after about 2 minutes, so I just
> wonder if I need to implement more algorithms based on RTCP message.
Even without a congestion protocol, and endpoint should "adapt" its
sending bitrate based on the packetloss indicated in received RTCP
ReceiverReports. It may also do it if it receives lot of NACKs and
PLI/FIR messages.
You may want to check whether your endpoint implements NACK and
PLI/FIR for sending and receiving.
--
Iñaki Baz Castillo
<
i...@aliax.net>