Discrepancy with Acceptable Packet Loss Threshold

[jflayhart]

There seems to be a discrepancy involving acceptable packet loss ratio between what's in the code (for both iOS and Android) and what's in the "acceptable threshold" table you have listed in the ReadMe of this project.

For example, you show in the table that an acceptable packet loss ratio for video is 0.3% or 0.003, yet you turn around in the code and claim 3%, NOT 0.3%: https://github.com/opentok/opentok-network-test/blob/master/iOS-Sample/Hello-World/OTNetworkTest.m#L244

Which is it? This is a considerable difference for us understanding if a call had good or bad video quality.

Furthermore, there are discrepancies in the Android and iOS versions when initializing packet loss ratio. I noticed for iOS you initialize with video_pl_ratio = -1 yet in Android it's private double mVideoPLRatio = 0.0. This matters because if iOS ever has an issue retrieving pack loss stats (it does at times), then our analytics will just show an array of [-1,-1,-1,-1] whereas Android will correctly show 0s. -1 Is difficult to use as a packet loss variable since it is a negative integer, so can you please explain why iOS is initialized that way versus the Android version? Should we use 0 instead of -1? What is recommended here?

Thanks!

[bsrao]

The reason for iOS using -1 is to differentiate the case between "no stats received with in the time window so don't know about packet loss" vs "stats received but no loss with in the time window"