Gstreamer is not the right tool for the job since it is a media-handling library. In the scope of WebRTC, Gstreamer would be responsible for decoding the media stream to eventually do something with that, say for instance display a video or play an audio. It would work more or less in the following fashion:
# Real Time Protocol socket (WebRTC over the network)
[peer A > rtp (udp) stream > peer B]
# Network layer from peer B to media layer in peer B machine
[peer B > rtp stream (local pipe/udp) > Gstreamer pipeline]
# GStreamer pipeline
[src (e.g. udpsrc, appsrc) > rtpdepay (e.g. rtph264depay, rtpopusdepay) > rtp payload filter > decode (e.g. avdec_h264, opusdec) > ... > sink (e.g. autovideosink, autoaudiosink)]
What you are trying to is just bypass the data, so since you are not planning to do any sort of handling with the data, Gstreamer is not really required for your workflow.
# Real Time Protocol socket (WebRTC over the network)
[peer A > rtp (udp) stream > peer B.1]
# Bypass
[peer B.1 > rtp stream (local pipe/udp) > peer B.2]
# Real Time Protocol socket (WebRTC over the network)
[peer B.2 > rtp (udp) stream > peer C]
That said, it looks very much like you're relaying the peer connection, which is what TURN servers are meant for. Maybe it is work to have a look at that as well.