I’m finishing an integration demo with Kurento filters, where the architecture is as follows:
Browser >--(WebRTC)--> mediasoup >--(RTP)--> Kurento (applies a filter) | Browser <--(WebRTC)--< mediasoup <--(RTP)--<--
Obviously, here “Kurento” could be any external 3rd-party RTP tool such as a custom GStreamer pipeline or a FFmpeg processor. It could even be that the tool receiving RTP is different from the one sending it back to mediasoup.
This setup could be theoretically accomplished with a single PlainRtpTransport that had both a Consumer to send video out, and a Producer to receive video in. However, it won’t work if the external tool doesn’t implement symmetric RTP ports, i.e. the tool needs to send from the very same port that it uses to receive data, which is the port where the PlainRtpTransport has been
connect()ed. Or, in the case of two tools, they need to be coordinated to use the exact same port to receive and send data.
If this requirement is not satisfied, then the PlainRtpTransport will just drop the incoming data with the (debug) message
ignoring RTP packet from unknown IP:port. For the curious, this check is done in PlainRtpTransport.cpp:605.
My question is: why shouldn’t PlainRtpTransport just listen for incoming data on the IP:port it binds to, regardless of where it comes from? Why such a specific restriction on the source of the incoming packets?
Symmetric RTP is understandably required in 3rd-party endpoints for mechanisms such as COMEDIA to work properly; this is also warned about in Kurento documentation for users that wish to use the COMEDIA mode in there. But for general purpose RTP transmission, it doesn’t look like neccessary. WebRTC doesn’t use it either. Furthermore, this is not a technical limitation: I just tried commenting out that return, and everything works beautifully.
The easy way to avoid this problem was to just use 2 PlainRtpTransports, one to send and another to receive. It’s just that with a receive-only PlainRtpTransport, the semantics of the
connect() method are a bit strange (really you are just “
connecting” in order to “whitelist” a remote IP and port, to receive data from it).
I’m not saying you should change this, just would like some context to better understand the issue. Although if you see it fitting, then I’d propose removing that restriction