# Detect network connectivity issues using RTCPeerConnection.getStats()

**URL:** <https://discourse.lynckia.com/t/detect-network-connectivity-issues-using-rtcpeerconnection-getstats/702>\
**Category:** Support\
**Created:** [January 20, 2018, 2:08pm UTC](https://discourse.lynckia.com/t/detect-network-connectivity-issues-using-rtcpeerconnection-getstats/702 "2018-01-20T14:08:15Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![mkh](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.lynckia.com/mkh/32/38_2.png) [@mkh](https://discourse.lynckia.com/u/mkh)\
**Post date:** [January 20, 2018, 2:08pm UTC](https://discourse.lynckia.com/t/detect-network-connectivity-issues-using-rtcpeerconnection-getstats/702/1 "2018-01-20T14:08:15Z")

</div>

I’m using `stream.pc.peerConnection.getStats()` in the client side to fetch and detect user connectivity issues. However when I impose packet loss on the publisher side, I see an increase of packet loss as well as NACK and PLI count in the subscriber side. Is this normal? If yes then I wonder how would it be possible to distinguish between publisher and subscriber connection issues using stats report?

The test in reverse is fine so when I simulate packet loss on the subscriber side it doesn’t affect the publisher stats report.

---

<div class="post-metadata">

**Author:** ![mkh](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.lynckia.com/mkh/32/38_2.png) [@mkh](https://discourse.lynckia.com/u/mkh)\
**Post date:** [January 25, 2018, 4:33am UTC](https://discourse.lynckia.com/t/detect-network-connectivity-issues-using-rtcpeerconnection-getstats/702/2 "2018-01-25T04:33:30Z")

</div>

The worst is it happens for RTT (round-trip time) in both scenarios and any latency in one peer, including publisher and subscriber, is just reported (forwarded) to other peers! This makes the `getStats()` completely useless for detecting peer connectivity problems.