attached a patch file to fix the RTP socket problems in FMJ. I used
eclipse to create the patch against FMJ's CVS repository.
The basic principle behind this patch:
- The RTPManager (aka RTPSessionMgr in FMJ) maintains _one_ internal
RTPConnector (aka RTPSocketAdapter in FMJ) if the RTPManager was
initialized with a SessionAddress.
If the RTPManager was initialized with another connector, for example
SRTP or (upcoming ZRTP) connector, no further changes because these
connectors maintain their own connections.
- The RTPSocketAdapater got new methods to maintain targets. The RTPSessionMgr
calls these methods to add/remove targets. No additional socket is created for
- The RTPSocketAdapter maintains its output and input streams, both using
the same real socket (aka EncryptedRTPSocket in FMJ).
- The SocketOutputStream class was enhanced to manage and use several
targets. The RTPSocketAdapater uses these new methods to add and remove
targets. The SocketOutputStream usually sends RTP and RTCP packets to
all known targets.
- The mangement of removeTarget(...)/removeTargets(...) in RTPSessionMgr
was adapted accordingly to send RTCP packets.
I've tested the modifications using test programms that use JMF to send
and receive data from/to test programs that use FMJ. In addition the same
test was done using test programms that use the GNU ccRTP stack. The tests
were successful so far. However, additional testing would not do any harm .
- it seems that the RTCP handling is not compliant betweem JMF/FMJ yet. The
test programs got different events for the same reasons depending if
they are using FMJ or JMF. Needs to be evaluated - but seems not to be a
real show-stopper for now.
- The EncryptedRTPSocket classes inherit from MulticastSocket. This class
automatically set SO_REUSEADDR thus several sockets can use the same
address. This is necessary in case of multicast, but not in case of unicast.
Could this do any harm in unicast use cases? Any ideas?
fmj-rtp.patch (15.7 KB)