Is there a clean way to tell if a PipeTransport has lagged out or isn’t capable of carrying the load? Spent a bit of time sorting a clean way for restarting ice but hadn’t seen much for PipeTransports. I am a bit tired and my homework is now leading here.
Appreciate any tips, or if there’s any improvements that can come this way. RTX seems to do wonders in these scenarios thus far.
Pipe transport uses plain RTP, not WebRTC, hence no ICE restarts.
If networking is not great (RTP uses UDP) then RTX might help to re-transmit lost packets.
Yeah haha,
I am currently not within a localized network to keep it 100%; and with random drops of pipetransports it can affect my weight system going on. I had turned on RTX and that works great for smoothening out the video-freezing (made the mistake early days :D)
Wondering if it’d be possible to implement with ease a keep-alive for them.
The issue here is the main signaling server can account for loss of network with these servers with simple ping relay, if the connection between the media servers is jeopardized and broker has no idea that’s when issues and errors occur.
Luckily not an often occurrence but one I’d like to tackle soon. It’d prevent the need for reboots and will have more time to explore if it’s not a bad idea.
Yes. Use them in combination with DirectTransports and build a ping-pong mechanism based on DataChannel messages.
Wow… I feel out of it, I hope that’s not too obvious of an answer you gave me! HAHA.
Thanks again you two and IBC, nice catch that will save me a lot of time with setting up too! I assume it should be easy enough now can hopefully avoid that annoying bug in my back-end lol 
I think I derped a bit, or features don’t work this way?
I’ve tried creating a DirectTransport after I connect the PipeTransports and sharing the producerdata id forward upon creation. It appears the ID does not exist and router reports no datachannels.
I saw in the pipetransport however I could open a datachannel it’s just done a bit differently, but long story short. It still failed to find the producer ID.
Is this normal behavior? My PipeTransports are not on the same machine, and locally I’d have no issues using the data channel but it might seem like I’m doing something wrong or it’s not implemented for remote?
I noticed I could just enable SCTP for the PipeTransport; does this keep a ping mechanism to it that’d report the sctpchange over networked pipetransports.
I assumed when my PipeTransports were created/connected anything produced/consumed on one router is shown on the second router.
e.g. 10.0.0.1 → 10.0.0.6
Both generally get the IDs but not seeing that at all with DirectTransports or even when I do similar through the pipetransport errors out saying that producerdata id doesn’t exist. (If this wording is more technical)
Update:
So going through code and all sorts, it’s not possible yet. I would like to request that there’s some type of active emit on connectionstatechange for connecting pipetransports over wide area network. Not sure how difficult that’d be, but for most reliable detection and proper fail-safe/closing of the pipetransports across servers this is necessary.
I am truthfully hopeful that something could be figured out. Cheers and if I’m the only one reporting this, I wonder how others are handling remoteIP <> remoteIP mediaservers if they go down.
No progress so far, I don’t think it’s me, but maybe it is. Would love for that knowledge or new feature. 