PLI behavior

[Bryan]

I'm seeing PLI response times increase the longer that a sender has been sending.

PLI response with a key frame is normally instant when a sender is within the first 32k packets, but goes way up at some point after that.

Chrome seems to use PLI like a FIR, that is, when a new receiver begins receiving an established video stream, it will send a PLI, although I would expect to see a FIR in that case.  

PLI is supposed to be sensitive to congestion control while FIR is not, but it seems to be a problem if a sender delays sending a key frame when there is no congestion, as in my test where both endpoints are on the same machine.

In the cases where my middlebox generates a PLI, I could change it to a FIR, and hopefully avoid the latency, however, there are cases where the receiver(s) are sending PLI and getting no response, like when they start receiving an established stream.  

I'm testing on Version 27.0.1453.15 beta / Linux 

Is there any difference in Chrome's handling of PLI and FIR?

Is this behavior of an increasing PLI key frame response time known / by design?  

[Bryan]

I think that I disovered the problem about why PLIs were not being processed by the sender.

Per Justin's guidance, I thought that it was enough that the STUN reverse bind was completed when the PeerConnection was initially set up, and after that, it was enough to send a bind success without a reverse bind.

However, based on chrome_debug.log output referring to non-STUN packet from unreadable connection, I guessed that the reverse binds must be the problem, and reverted to sending one reverse bind for each forward bind.  

I think now that the connection will not be treated as unreadable, and PLIs will be processed as expected, but I still have to do more testing to be sure.

[Justin Uberti]

Thanks for following up.

Note that the STUN "reverse bind" is required RFC 5245 behavior, namely a 4-way handshake is required to establish a valid candidate pair (unless you are using ICE Lite).

--
 
---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Bryan]

Sure, I understand that.  ICE completed with the 4-way handshake.  And the sender was continuously sending afterward.  But at some point, the sender stopped accepting RTCP (PLI) packets unless it was fed a steady stream of reverse binds.

[Justin Uberti]

Bryan, were you using ICE or GICE? GICE requires continuous reverse binds, but not ICE.

On Tue, Apr 9, 2013 at 7:18 PM, Bryan <bryand...@gmail.com> wrote:

Sure, I understand that.  ICE completed with the 4-way handshake.  And the sender was continuously sending afterward.  But at some point, the sender stopped accepting RTCP (PLI) packets unless it was fed a steady stream of reverse binds.

--

[Bryan]

I was using ICE, not G-ICE, with rtcp-mux and BUNDLE

My logic was to send reverse binds for the first 2 seconds after the initial bind, and then not afterward.  Always reversing fixed the PLI problem.  I must have hit some timeout since I was not sending any other RTCP to the sender.

While debugging that, I observed that chrome emits a keyframe every 100 seconds.  That timed keyframe confused me at first into thinking that there was a variable delay in responding to PLIs.