[sip-comm-dev] Patch for FMJ RTP processing


#1

All,

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
   new targets.

- 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 :slight_smile: .

Two notes:
- 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?

Regards,
Werner

fmj-rtp.patch (15.7 KB)