[sip-comm-dev] Midterm Evaluation - Integration of FMJ's RTP stack


#1

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 :wink: ). 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.free.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 Settings\Kuduru\Bureau\testFMJ\gulp.wav" 225.0.0.1 -t
java -jar IntegrationTestCustom.jar "C:\Documents and Settings\Kuduru\Bureau\testFMJ\gulp.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 :stuck_out_tongue:
. 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://uid0.free.fr/downloads/fmj_snap.rar
http://uid0.free.fr/downloads/integrationTest.rar

If you have any questions or need anything else, feel free to contact me.

Cheers,
Chris.


#2

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.free.fr/downloads/jmf.jar

Thanks again to Ken for his great help.

Cheers,
Chris.

···

----- Original Message -----
  From: Chris
  To: dev@sip-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 :wink: ). 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.free.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 Settings\Kuduru\Bureau\testFMJ\gulp.wav" 225.0.0.1 -t
  java -jar IntegrationTestCustom.jar "C:\Documents and Settings\Kuduru\Bureau\testFMJ\gulp.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 :stuck_out_tongue:
  . 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://uid0.free.fr/downloads/fmj_snap.rar
  http://uid0.free.fr/downloads/integrationTest.rar

  If you have any questions or need anything else, feel free to contact me.

  Cheers,
  Chris.


#3

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.free.fr/downloads/jmf.jar

Thanks again to Ken for his great help.

Cheers,
Chris.

    ----- Original Message -----
    *From:* Chris <mailto:sipcom@cyberspace7.net>
    *To:* dev@sip-communicator.dev.java.net
    <mailto:dev@sip-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 :wink: ). 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.free.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
    Settings\Kuduru\Bureau\testFMJ\gulp.wav" 225.0.0.1 -t
    java -jar IntegrationTestCustom.jar "C:\Documents and
    Settings\Kuduru\Bureau\testFMJ\gulp.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 :stuck_out_tongue:
    . 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://uid0.free.fr/downloads/fmj_snap.rar
    http://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-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net