PipeTransports re-consuming/re-producing before connected. Possible?

I would love if I could createPipeTransport synchronously and immediately afterwards take both the broadcasts and viewers and pre-consume/produce before connection takes place.


  1. Broadcast produces stream to producer server
  2. Producer server on connected stream will announce audio/video/both for viewers
  3. Viewer will request access to broadcast but first if no connection, createPipeTransport is sent to both producer/consumer server selected.
  4. Second is the request to re-consume the broadcast on producer server to re-produce it on the consumer server.
  5. Viewer will consume the consumer’s re-produced copy of the broadcast
  6. Some where by now the server may connect its PipeTransport and the Broadcast/Viewer should be connected.

Above would be ideal but I understand if not possible. I currently await the PipeTransport before re-consuming/re-producing but this can require more error handling than above solution that would be able to pass along the streams in the future based on “trust” not promise.


Here’s a good scenario,

I’ll have 24 broadcasters needing re-piping often and I’ve almost guaranteed no failures but sometimes it gets hectic when we have a broadcaster connected to several pipes and their broadcast sent out hundreds of users gets closed rapidly; this queue gets over thrown with irrelevant details.

I’d almost like a pre-fire instance where things are prepared but not just yet in some cases and handled.

Feel free to suggest I get what I get, I just am thinking towards a higher level of many-to-many and efficiency.