Midterm Evaluation - Integration of FMJ's RTP stack

Hey this is really great news! This means one more package
to the fmj4sc
jar and one less in jmf. Excellent! Thanks for your efforts
Chris, and
Ken, thanks for helping!

Cheers
Emil

Chris wrote:
> Hi everybody,
>  
> Just a little mail to inform you that Ken and I have
been discussing
> off-list for the last days, and he helped me really a
lot so that we
> managed to have a first transmission test working this
afternoon (btw,
> Ken is the winner of the big "ugly bug" hunt,
so he'll get a good fresh
> beer from Heineken when we meet :-P). I've done some
tests calling the
> echo service on an Asterisk server and everything works
fine. I'm trying
> to get rid of another problem of transmission in the
RTP stack which
> makes the test with AVTransmit2 fail (the data sent by
AVTransmit2
> creates an error on the receiving end). So now the
customized jmf.jar
> works with almost every tests (the SimpleTransmit test
was successful too).
>  
> The latest jmf.jar can be downloaded at:
> http://uid0.fre
e.fr/downloads/jmf.jar
>  
> Thanks again to Ken for his great help.
>  
> Cheers,
> Chris.
>  
> 
>     ----- Original Message -----
>     *From Chris
<mailto:sipcomcyberspace7.net>
>     *To devsip-communicator.dev.java.net
>     <mailto:devsip-communicator.dev.java.net>
>     *Sent Friday,
July 13, 2007 12:10 AM
>     *Subject
[sip-comm-dev] Midterm Evaluation - Integration of FMJ's
>     RTP stack
> 
>     Hi guys,
>      
>     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:
>     http://uid0.f
ree.fr/downloads/tests.rar
>      
>     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
>     SettingsKuduruBureautestFMJgulp.wav"
225.0.0.1 -t
>     java -jar IntegrationTestCustom.jar
"C:Documents and
>     SettingsKuduruBureautestFMJgulp.wav"
225.0.0.1 -r
>      
>     (yeah, I know, don't shoot me, I'm forced to use
this OS against my
>     will at the moment....)
>      
>     Another warnings:
>     . 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 :P
>     . 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 :
>     http://uid
0.free.fr/downloads/fmj_snap.rar
>     htt
p://uid0.free.fr/downloads/integrationTest.rar
>      
>      
>     If you have any questions or need anything else,
feel free to
>     contact me.
>      
>     Cheers,
>     Chris.

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net