WebRTC Media Server: Managing long-lived peer connections

Question

I'm starting off with WebRTC and this is largely a design question. Looking for the pros and cons of two competing approaches.

Context

I'm creating a media server that will stream video to multiple clients. Each client can request one or more video streams to view in a browser page, then close those and request others, and so on. A single client may have a persistent connection for hours or days at a time, toggling different streams on and off at will.

Question

How do I manage the peer connections with clients?

Considered Approaches

1. Each (client, video stream) pair gets its own peer connection. So if a client is viewing 5 video streams, that webpage will have 5 peer connections. Each peer connection has a single track. This involves creating / destroying peer connections each time the client takes an action to view / close a video stream.
2. Each (client) gets a single peer connection. Based on client actions, we either add tracks or remove tracks from the peer connection. The single connection lives on as long as the client is on our webpage.

On the surface, Option 2 seems less "wasteful" in that there's a single connection, but reading up on WebRTC signaling, the act of adding / removing tracks triggers a new round of offer / answer, so I'm not sure its actually more efficient. Moreover, it seems like it would be harder to manage and implement since its more stateful, e.g., to make sure tracks are properly cleaned-up when no longer used.

Thanks.

Answer 1

Option 2 is certainly more efficient, in that it avoids making an ICE negotiation for each stream. It also avoids wasting UDP ports, which might be important if your server is very busy. (It also limits the amount of state in NAT boxes, which is probably no longer an issue nowadays.)

Option 1, however, might be more performant, since using a different transport stream for each media stream (a different UDP port) means that traffic shapers and AQMs will distinguish the different streams, and might give more throughpout to your application.

Perhaps more importantly, option 1 is much simpler to implement. There are complex rules about what can be done when renegotiating a Peer Connection, and they are easily broken, leading to difficult to debug failures.