# Best architecture for stable RTSP camera streaming (LAN + WAN, no port forwarding)

**URL:** <https://discourse.gstreamer.org/t/best-architecture-for-stable-rtsp-camera-streaming-lan-wan-no-port-forwarding/5744>\
**Category:** General Discussion\
**Created:** [March 4, 2026, 12:17am UTC](https://discourse.gstreamer.org/t/best-architecture-for-stable-rtsp-camera-streaming-lan-wan-no-port-forwarding/5744 "2026-03-04T00:17:38Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![brian-cawling](https://discourse.gstreamer.org/letter_avatar_proxy/v4/letter/b/d78d45/32.png) [@brian-cawling](https://discourse.gstreamer.org/u/brian-cawling)\
**Post date:** [March 4, 2026, 12:17am UTC](https://discourse.gstreamer.org/t/best-architecture-for-stable-rtsp-camera-streaming-lan-wan-no-port-forwarding/5744/1 "2026-03-04T00:17:38Z")

</div>

Hi everyone,  
I’m trying to choose the most **stable** way to stream **RTSP (H.264) cameras** to users both **on the LAN and over WAN** , **without port forwarding** at the site.

**Current architecture**  
Cameras → RTSP  
Edge/server on the LAN pulls RTSP (GStreamer)

- Edge publishes via **WebRTC (LiveKit)** to a **cloud SFU (VPS)** using gstreamer.

- **React Native** app (mobile + Android TV) subscribes from the cloud SFU to view from anywhere

**Problem**  
Some streams are:

- choppy/jittery, and in some cases

- **black** or show **one frame then freeze** (varies by network/device)

**Question**  
Is **WebRTC → cloud SFU** the right default approach for maximum reliability here, or would you recommend a different pattern (e.g. **LL-HLS/HLS)**?

Thanks

---

<div class="post-metadata">

**Author:** ![AlexRyassky](https://discourse.gstreamer.org/user_avatar/discourse.gstreamer.org/alexryassky/32/1489_2.png) [@AlexRyassky](https://discourse.gstreamer.org/u/AlexRyassky)\
**Post date:** [March 4, 2026, 9:59pm UTC](https://discourse.gstreamer.org/t/best-architecture-for-stable-rtsp-camera-streaming-lan-wan-no-port-forwarding/5744/2 "2026-03-04T21:59:42Z")

</div>

WebRTC has an ability to adjust it’s quality depending on current “network weather”. Sometimes it can cause visible artifacts.  
Consider using HLS or MPEG-DASH with some buffering, if low-latency isn’t a rigid constraint.

---

<div class="post-metadata">

**Author:** ![brian-cawling](https://discourse.gstreamer.org/letter_avatar_proxy/v4/letter/b/d78d45/32.png) [@brian-cawling](https://discourse.gstreamer.org/u/brian-cawling)\
**Post date:** [March 4, 2026, 10:13pm UTC](https://discourse.gstreamer.org/t/best-architecture-for-stable-rtsp-camera-streaming-lan-wan-no-port-forwarding/5744/3 "2026-03-04T22:13:35Z")

</div>

Hi Alex. The issue I’m finding with WebRTC is that only 3-4 of my 6 streams show in my app. The others are black. I look at the logs and the frames arrive for those streams in the app but none are decoded even though they are being viewed. I put in a restart mechanism to unsub and sub to the black streams and after a few tries they eventually all load. So all connections are possible so it’s not a hardware issue.

I feel like it could be an IDR frame issue. Where the stream doesn’t get the IDR so it stays black and the unsub and sub essentially makes it try again until it has what is required to start the stream.

My cameras have a GOP = 1s, low bitrate, FPS, base profile. The gstreamer publishes to my cloud SFU using livekitwebrtcbin.

What do you think is the reason for the initial black streams?

---

<div class="post-metadata">

**Author:** ![jbb194](https://discourse.gstreamer.org/user_avatar/discourse.gstreamer.org/jbb194/32/1681_2.png) [@jbb194](https://discourse.gstreamer.org/u/jbb194)\
**Post date:** [April 16, 2026, 2:24am UTC](https://discourse.gstreamer.org/t/best-architecture-for-stable-rtsp-camera-streaming-lan-wan-no-port-forwarding/5744/4 "2026-04-16T02:24:04Z")

</div>

Do you have the ability to add an h264parse element just after the encoder and use this to set a 2 second config-interval? This might help since you don’t have a way to request a key frame.

> **[h264parse](https://gstreamer.freedesktop.org/documentation/videoparsersbad/h264parse.html?gi-language=c)**