I’m trying to get some statistics/information on the network quality of incoming WebRTC streams, like packets/frames lost, retransmission count, anything that’s available would be helpful.
I’ve discovered (with IDE autocomplete magic) that there is a setLossNotifier method in the WebRTCSession but I couldn’t find any information on how it works or if it’s related to these kind of statistics at all.
Is there an API to gather this or related information?
I’ve just tried the RTPSession.getIOPerformanceCounter() method, to get some statistics. While the getMessagesInBytes() and getMessagesInCount() (and rates) works as expected in the performance counter, the getMessagesLossCount() and getMessagesLossBytes() methods (and rates) consistently return 0.
Once you have ‘enable webrtc queries’ enabled in Streaming Engine, these are the java method calls to query only webRTC streams. The query check box on engine manager allows you to send the queryAll message over the websocket to an application
List<RTPSession> getWebRTCSessions()
List<RTPSession> getWebRTCSessions(String streamName)
int getWebRTCSessionCount()
int getWebRTCSessionCount(String streamName)
Map<String, Integer> getWebRTCSessionCountsByName()
Once you have that info, you can make normal REST API queries to get stream stats as you were asking about:
This is not exactly what I’m looking for. The REST API linked (incomingstreams) only reports bytes in/out and byterate in/out. This information is also available from RTPSession.getIOPerformanceCounter() Java API, but what I’m looking for is some kind of quality feedback, like number of packages lost (NACK sent), frames missing, or similar.
We are having quality degradations on streams published at higher quality than resources allowed and we’d like to try and detect it. Detection on the publishing (browser) side is not totally reliable, although covers some of the cases. A network level quality feedback would be very useful for our current usecase.
I see and can understand the need for that. I did check with tech support to confirm for you and this is what I was told:
"There is this property (logPacketLoss)
How to capture that with the Java API, we do not have examples for them for this. They might need to set that logging and see if they can reverse engineer how it’s created. Or work with our ProServ Team to build out a solution for his packet loss handling needs."
I can add it as a feature request for you with the Engine team. We also have a very advanced group of webrtc developers from around the world in our slack channel if you want to ask in there if anyone has a way to capture that.
You can join here and it’s just the #webrtc channel
Looks like I’ve overlooked the logPacketLoss flag. So here is my evaluation result: setting logPacketLoss=true and useNack=true (with useNack=false nothing happens), I see some activity.
First there are WARN entries in the Wowza log:
WARN server comment - JitterBuffer.packetLoss[s/_definst_/publish-1c945e43-553f-4545-b79f-a1776e1a6336]: last sent sequence number:15819 current sequence number:15850, diff: 30
And also the lossNotification event (set be WebRTCSession.setLossNotifier() will get invoked. I also have to call the WebRTCSession.setLossNotifierInterval() which takes a long parameter, which is not milliseconds, but it is correlated with the frequency of the notifier being invoked - setting to 100 will gave a 1-6 sec time between notification, maybe it’s related to loss packet/byte count? (I’m simulating a 25% packet loss on the network for quick testing)
The interesting thing is the parameters of the IWebRTCLossNotifier.onLossNotification(long l, double v, WebRTCSession webRTCSession) method invoked: the l parameter is most likely the total diff in sequence numbers on the track with highest total diff (based on the diff fields in the log, see below), the v parameter is strange, I have no clue what it could be 
The interesting thing is that if I use the WebRTCSession.setLossNotifier() method, the RTPSession’s IOPerformanceCounter reports 0 for InBytes and InCount metrics. The LossCount and LossBytes metrics are always zero, even with logPacketLoss set to true and no loss notifier set.
Here is a log excerpt, on what i see:
WARN server comment - JitterBuffer.packetLoss[s/_definst_/publish-1c945e43-553f-4545-b79f-a1776e1a6336]: last sent sequence number:34617 current sequence number:34641, diff: 23
WARN server comment - JitterBuffer.packetLoss[s/_definst_/publish-1c945e43-553f-4545-b79f-a1776e1a6336]: last sent sequence number:34641 current sequence number:34658, diff: 16
WARN server comment - JitterBuffer.packetLoss[s/_definst_/publish-1c945e43-553f-4545-b79f-a1776e1a6336]: last sent sequence number:15193 current sequence number:15195, diff: 1
2021-06-05 09:59:51 (INFO) onLossNotification l=39 v=164375.0
WARN server comment - JitterBuffer.packetLoss[s/_definst_/publish-1c945e43-553f-4545-b79f-a1776e1a6336]: last sent sequence number:34864 current sequence number:35034, diff: 169
WARN server comment - JitterBuffer.packetLoss[s/_definst_/publish-1c945e43-553f-4545-b79f-a1776e1a6336]: last sent sequence number:15257 current sequence number:15324, diff: 66
2021-06-05 09:59:51 (INFO) onLossNotification l=169 v=167689.0
WARN server comment - JitterBuffer.packetLoss[s/_definst_/publish-1c945e43-553f-4545-b79f-a1776e1a6336]: last sent sequence number:35814 current sequence number:35911, diff: 96
WARN server comment - JitterBuffer.packetLoss[s/_definst_/publish-1c945e43-553f-4545-b79f-a1776e1a6336]: last sent sequence number:15558 current sequence number:15595, diff: 36
2021-06-05 09:59:57 (INFO) onLossNotification l=96 v=206233.0
WARN server comment - JitterBuffer.packetLoss[s/_definst_/publish-1c945e43-553f-4545-b79f-a1776e1a6336]: last sent sequence number:36635 current sequence number:36642, diff: 6
WARN server comment - JitterBuffer.packetLoss[s/_definst_/publish-1c945e43-553f-4545-b79f-a1776e1a6336]: last sent sequence number:36642 current sequence number:36790, diff: 147
WARN server comment - JitterBuffer.packetLoss[s/_definst_/publish-1c945e43-553f-4545-b79f-a1776e1a6336]: last sent sequence number:15819 current sequence number:15850, diff: 30
2021-06-05 10:00:03 (INFO) onLossNotification l=153 v=117893.0
Anyway, this is getting close to what I’m looking for, I practically have the number of lost packets, but knowing the total number of packets would also be important, but unfortunately it is lost, as soon as I set a loss notifier… I join the slack channel you suggested and try to pursue more information on the subject.
Best way to capture this is where it happens: in the browser. Using WebRTC’s getStats you can collect any metric you like, such as Nack count, packet loss, bitrate etc.
What we do is simply collect all of this during a stream and feed it into our logging/monitoring system.
During a WebRTC session, access in your Chrome browser: chrome://webrtc-internals
These are all the metrics available and you can capture this via the getStats() API in Javascript.
Thanks so much Remy. @robymus Remy is one of the webrtc experts I was referring to who is typically more available in our slack channel.
© 2007–2024 Wowza Media Systems™, LLC. All rights reserved. Security & Privacy PolicyLegalSystem Status