I've been working a lot to get rid of a last annoying bug before posting, but it's not solved at the moment. Indeed, I managed to have the reception work correctly, have the processor.setContentDescriptor() call work correctly, but even if I've done some progress with transmission (the output when using JMF or our customized JMF with FMJ's RTP stack are now completely the same, and everything gets initialized & runs without any error), there seems to be a bug between the processor used by JMF to handle the stream and FMJ's RTP stack. The processor never calls the transferData() callback method which is defined inside of the RTP part and is supposed to process the data and send them over the network.
To be more efficient in tracking down the problem, Ken & Emil suggested to fall back on something less tricky than SC. So I switched to some tests using FMJ's SimpleReceiver/SimpleTransmiter and Sun's AVReceive2/AVTransmit2. It was very useful to point out a few other problems in the RTP stack but wasn't that much helpful to track down the main transmission problem. Simple* worked fine with JMF, after some little modifications inside the RTP stack, with the complete FMJ too, and reception works fine with our customized JMF. AV* works fine with JMF (the contrary would be quite frightening :-P), after the modifications to the RTP stack, reception works fine with the complete FMJ and transmission should work soon (there's still a bug in the stack that I'm solving at the moment), and as expected, with our customized FMJ, reception works but not transmission (the annoying problem described at the beginning of the mail).
To sum up the actual state of the tests on the various libs:
. JMF : everything works
. FMJ (with patches) : everything works, except AVTransmit2 due to a bug in the RTP stack that I'm correcting at the moment
. customized JMF : reception always works (Simple*, AV* and SC), transmission initializes correctly but doesn't work due to the big ugly problem
To be able to test all this, Emil & I decided that the best thing for the midterm eval would be to send some test packages for everybody to be able to see what works and not (and maybe also find where the big ugly problem comes from ). So I've chosen to base the tests on AVReceive2/AVTransmit2 which are really extremely close to what SC does.
The archive containing the jars to perform the tests can be downloaded at:
It contains 3 jars (IntegrationTestFMJ, IntegrationTestJMF, IntegrationTestCustom) which launch the tests (ie AVTransmit2 and/or AVReceive2) using respectively the complete FMJ, JMF or our customized JMF containing JMF with FMJ's RTPstack and some other packages needed (cryptographic ones especially). Those libraries used are all in the "lib" folder among other libraries used by FMJ. I've also added a sample media file "gulp.wav" which can be carried by the RTP stack.
Here is the syntax of the commands:
java -jar IntegrationTest<FMJ|JMF|Custom>.jar <absolute_path_to_the_media_file> <IP_address> [-r|-t]
This will launch the test using the chosen library (FMJ, JMF or Customized) sending/receiving the content of the media file (gulp.wav for example) through the network to/from the IP specified address (on port 1234).
If no "-r" or "-t" switch is specified at the end of the command, both emission and reception will be launched (of course, you need to specify a multicast address in this case), else only resp. reception or emission will be launched.
I've done all the tests using a multicast address which is IMHO much easier (and the only reasonnable choice if running on a single machine like me).
The transmiter must be launched BEFORE the receiver, else it will yell about not being able to steal the port.
For example, to test the reception of our customized JMF, one should type in two different consoles (in this order!!):
java -jar IntegrationTestJMF.jar "C:\Documents and Settings\Kuduru\Bureau\testFMJ\gulp.wav" 22.214.171.124 -t
java -jar IntegrationTestCustom.jar "C:\Documents and Settings\Kuduru\Bureau\testFMJ\gulp.wav" 126.96.36.199 -r
(yeah, I know, don't shoot me, I'm forced to use this OS against my will at the moment....)
. to test FMJ, please use the library included (fmj.jar), because it includes some modifications to the RTP stack which might not be commited at the moment.
. "gulp.wav" is not very long, so hurry up to launch the receiver
. the program doesn't stop on its own, so just kill it
By the way, the RTP stack is very noisy because I've let all the inline printfs I used to trace the behaviour of the stack and track down some bugs, so don't mind them. I thought it might be better to let them there because they can be useful when debugging (even if they're probably not clear at all). What's more, it enables you to see that it's really FMJ's RTP stack running and not JMF's ;o) .
You can also perform other tests like using FMJ's SimpleReceiver/SimpleTransmiter (in fact, they're included in IntegrationTest but aren't activated), as well as directly inside SIP Communicator. To do this, just replace lib/os-specific/<OS>/installer-exclude/jmf.jar with the one extracted from the archive file (it's the customized jmf). I've been able to call an answermachine running on an Asterisk box and reception worked fine, I could even enjoy listening to an interesting new style of voodoo music ;). As said, transmission won't work, but it should be fixed soon.
Last but not least, I'd like to briefly explain what is composing the customized JMF. The base is the original jmf.jar, in which was added FMJ's RTP stack (now I've put it directly in com.sun.media.rtp, it was in net.sf.fmj.media.rtp previously) at the same place where JMF's RTP files are still (overwriting 2 common files among which the most important: RTPSessionMgr) because some other parts of JMF still need some of these files, and finally some other packages were also added to the archive (especially some cryptographic packages needed by FMJ's RTP stack like javax.crypto.*, memetic.crypto.*, etc).
Ok, for the few people who were brave enough to read this mail till the end without falling asleep, here's a little (bitter) candy, the URL where you can retrieve a snapshot of the RTP stack I'm using at the moment (in fact the complete FMJ package, keep in mind that even if I let the original files in net.sf.fmj.media.rtp, the files that I use and copy to jmf.jar are actually the ones in com.sun.media.rtp!!), as well as the few lines of code of the classes composing IntegrationTest :
If you have any questions or need anything else, feel free to contact me.