Open isuruanu opened 9 years ago
Well, the main assumption of the rtpproxy is that we always have a separate port for each individual stream, so that we can do proper de-NATing. Therefore, adding some functionality to do de-muxing based on ssrc would directly break that key assumption and most likely hinder our key functionality. That being said, actual mix/demux code is probably not very difficult to implement, all ingredients to parse rtp are already in there, so it should not be too difficult or too prohibitively expensive to implent and maintain that code in a separate fork.
This is more of a suggestion.
My main concern related to firewall rules to allow multiple UDP ports to connect from internet. Firewall will allow maximum 3,4 port for rtpproxy to allow rtp entity to stream.
I have went through https://tools.ietf.org/html/draft-peterson-rosenberg-avt-rtp-ssrc-demux-00#page-4
There is a suggested way to multiplex multiple rtp session to (I only need RTP voice) two ports rtp-voice, and rtcp-voice ports. This is RTP SSRC multiplexing approach.
Can rtpproxy comply with this. ?