# Does Gstreamer rtprtxqueue impact Mediasoup BWE negatively?

**URL:** <https://mediasoup.discourse.group/t/does-gstreamer-rtprtxqueue-impact-mediasoup-bwe-negatively/6023>\
**Category:** Integration\
**Created:** [May 2, 2024, 2:35am UTC](https://mediasoup.discourse.group/t/does-gstreamer-rtprtxqueue-impact-mediasoup-bwe-negatively/6023 "2024-05-02T02:35:08Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![ea167](https://yyz2.discourse-cdn.com/free1/user_avatar/mediasoup.discourse.group/ea167/32/404_2.png) [@ea167](https://mediasoup.discourse.group/u/ea167)\
**Post date:** [May 2, 2024, 2:35am UTC](https://mediasoup.discourse.group/t/does-gstreamer-rtprtxqueue-impact-mediasoup-bwe-negatively/6023/1 "2024-05-02T02:35:08Z")

</div>

Hello,

In every example I’ve found, notably including the amazing `mediasoupbin` plugin by @vpalmisano, the Gstreamer pipeline uses `rtprtxqueue` for nack retransmission (example [pipeline here](https://github.com/vpalmisano/mediasoupbin/blob/master/gst/plugins/python/lib/pipelines.py)).

The `rtprtxqueue` [documentation](https://gstreamer.freedesktop.org/documentation/rtpmanager/rtprtxqueue.html?gi-language=c) states that it is NOT RFC4588 compliant, as retransmitted packets have the _same ssrc_ and _payload type_ as the original stream, contrary to proper RTX `rtprtxsend`.

`rtprtxqueue` is simple to use within gst-launch pipeline, whereas `rtprtxsend` requires to be plugged to `rtx-aux-sender` signal, which can only be done in C or Python.

Would you have any idea whether the retransmitted packets may perturbate the BWE (BandWidth Estimation) on the client-side, as they might seem to arrive very late, and therefore cause some bandwidth drop?