Gstreamer and WebRTC Packet Loss Calculation

I was looking at some calls that take place between an Android WebRTC stack and a Gstreamer WebRTCBin stack. I noticed packet loss metrics seems to be skewed on both sides.

On the Gstreamer side, packet loss is very often negative:

[ -154, -697, -1234, -1764, -2288, -2823, -3350, -3869, -4409, -4988, -5533,
  -6065, -6592, -7123, -7672, -8237, -8831, -9383, -9949, -10527, -11036,
  -11581, -12136, -12721 ]

From the docs:

gstreamer.freedesktop.org/documentation/rtpmanager/RTPSource.html?gi-language=c#RTPSource:stats

For fields indicating packet loss, note that late packets are not considered lost, 
and duplicates are not taken into account. Hence, the loss may be negative if there 
are duplicates.

That seems all good and dandy, except I’m not sure how to interpret packet loss here. It seems like the corresponding Android WebRTC stack doesn’t know how either as the values showing up occasionally look like:

"packetsLost": 16777215

This makes me think the stacks are having a hard time with packet loss calculations among one another. It seems (as far as I know) to affect all calls between Android WebRTC and Gstreamer’s WebRTC implementation.

Is this a common problem? How am I to interpret this data : /