[sip-comm-dev] jUnit tests for RSS - _very_ preliminary version


#1

Hello everybody,
I'm working for some time on the test package for the RSS protocol.
Right now it's in a _very_ eraly stage, meaning that there are only
four, simple test cases implemented (very similar to those in the
Gibberish SLICK) and a very simple server that can/will be used later
on.
Right now testing some of the features of the current implementation
isn't quite problems as the protocol still has some holes in it
(namely online/offline switching/detection for both remote contacts
(aka feeds) and user account).
It's the first time I write unit tests, so any suggestion is more than
welcome. I won't be able to check my mail for a week or so, but I look
forward for your impressions.

Thanks in advance for your time,
Mihai

PS: To actually get to run the test one should also alter the
testing.properties file and add RssProtocolProviderServiceLick to the
list of tests.

rssSlick.zip (19.9 KB)


#2

Hi Mihai,

Thanks for your patch.

I have skimmed all your test code and compared it with the one found in Gibberish,
as a base. You have done a good work and (of course) all tests (6) passed.

This said, I have some remarks.

    1 - In TestAccountInstallation, as you have used an accountProperties, you might
use the following code :
    rssProviderFactory.installAccount(
                accountProperties.get(ProtocolProviderFactory.USER_ID),
                accountProperties);
instead of
    rssProviderFactory.installAccount("RSS", accountProperties);

    Another thing I noticed is that the rssaccregwizz accepts to install only one
RSS account. Is that limitation enforced by the protocol provider ? In other words,
if we try to install two (different) RSS accounts will it always fails ?

    2 - For which kind of tests do you plan to use the feed server/factory (rather than using online
feeds) ?

    3 - I noticed that a few method lacks of javadoc comments, but since you haven't finished,
I guess it is temporary :wink:

As you stated that this patch is a preview version, I won't commit it, waiting for your latest
version, in case you plan to bring substantial modifications soon. This said, the accomplished work is
very good and if upcoming tests are written in the same way, I think we could use your test code verbatim.

Thanks for the time.

Regards
    Sympho

Mihai Balan a �crit :

···

Hello everybody,
I'm working for some time on the test package for the RSS protocol.
Right now it's in a _very_ eraly stage, meaning that there are only
four, simple test cases implemented (very similar to those in the
Gibberish SLICK) and a very simple server that can/will be used later
on.
Right now testing some of the features of the current implementation
isn't quite problems as the protocol still has some holes in it
(namely online/offline switching/detection for both remote contacts
(aka feeds) and user account).
It's the first time I write unit tests, so any suggestion is more than
welcome. I won't be able to check my mail for a week or so, but I look
forward for your impressions.

Thanks in advance for your time,
Mihai

PS: To actually get to run the test one should also alter the
testing.properties file and add RssProtocolProviderServiceLick to the
list of tests.
------------------------------------------------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#3

Hi Mihai,

I've reviewed and commited your Rss tests proposal and it's a really good job: your code is very clean, structurated, consistent and efficient.
In three words, very nice work :slight_smile:

As every big patchs, there are some little remarks and questions (which absolutely don't mean anything on the overall quality of your code)

- As minor esthetic changes I added the licence header on some of the files, corrected some tabulation miss, correct characters inside the dead zone (aka after 80 characters on a line), corrected some javadoc problems

- In RssProtocolProviderServiceLick.start(...), why have you written "logger.setLevelAll()" ? I don't know exactly what does this method but it seems overwriting the default logger settings, is it really needed ?

- I corrected many "RSS" with a new entry in the ProtocolNames interface

- In the TestingServer constructor, your bind the server with "127.0.0.7" however the default IPv4 loopback address is 127.0.0.1 and this static string is a little bit mind-distrubing for me as I'm not really sure that this works with IPv6-only net interfaces so I replaced this string with null which is explicitly associated with the loopback interface in the javadoc.

- I changed the value of your constants INVALID, VALID, VALID_NEW and so on... because first the hexadecimal notation is here not needed and may appear terrible for some people :slight_smile: and more seriously because you previously gave a power of two value for these constants. I perhaps have a not normal brain but when I see these values I immediately think at some binary or-able (constants that you can combine with the binary or operator) flags which is not the case here so I simply gave them new values (0, 1, 2, 3)

- don't you think that using the 8080 port as a default value may cause some problem to the users who are already using this port for doing something else ? Isn't it a perfect choice for an account parameter in the account.properties file ?

- in TestingServer.start you got this:
        //only allow one "instance" of the server to be running at a given time
        if (serverActive)
            return;
               //create new thread and launch
        runner = new TestingServerThread(this, server);
        serverActive = true;
It is a good idea to avoid having two server launched in the same time but your code isn't thread safe here: it is possible to create two servers if the method is called by two concurrent threads. Did you envisage this case ? Is it grave ? This can be corrected easily with a little "synchronize" :slight_smile:

- and last, in TestingServerThread.run you got:
        if (launcher.isActive())
before doing anything. Why did you write this test ? Do you know that if the launcher didn't end its initialization phase, the server may never start ? Moreover, is this test really useful ?

And that's all :wink:

As you said in your mail, for the moment the tests are limited and the rss functionalities aren't really tested but the server is ready and it's a very good point: it should now not be so difficult to implement some more Rss specific tests :slight_smile:

Most of these remarks are very minors one, so as I previously said, very good job Mihai and thanks for your contribution !

Cheers,
Ben

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#4

Hi! I got following exception when trying with java 1.6. It seems an
incompatibility between Java 1.6 (or 1.5) and the JMF on Windows. It there
any possibility for a workaround or do I have to use java 1.4.2?

Regards, thomas

16:20:05.859 SCHWERWIEGEND:
impl.media.CallSessionImpl.controllerUpdate().1836 The following error was
reported while starting a
playerjavax.media.ResourceUnavailableEvent[source=com.sun.media.content.unkn
own.Handler@1c30dfa,message=Failed to realize: input media not supported:
h263/rtp video]
Exception in thread "JMF thread: com.sun.media.PlaybackEngine@a7563d (
prefetchThread)" java.lang.IllegalArgumentException: Requested value
7.9588003 exceeds allowable maximum value 6.0206.
  at javax.sound.sampled.FloatControl.setValue(FloatControl.java:178)
  at
com.sun.media.sound.DirectAudioDevice$DirectDL$Gain.setValue(DirectAudioDevi
ce.java:833)
  at
com.sun.media.renderer.audio.device.JavaSoundOutput.setGain(JavaSoundOutput.
java:157)
  at
com.sun.media.renderer.audio.AudioRenderer.initDevice(AudioRenderer.java:294
)
  at
com.sun.media.renderer.audio.JavaSoundRenderer.initDevice(JavaSoundRenderer.
java:125)
  at
com.sun.media.renderer.audio.JavaSoundRenderer.open(JavaSoundRenderer.java:9
1)
  at
com.sun.media.BasicRendererModule.doPrefetch(BasicRendererModule.java:157)
  at
com.sun.media.BasicTrackControl.prefetchTrack(BasicTrackControl.java:98)
  at com.sun.media.PlaybackEngine.doPrefetch1(PlaybackEngine.java:592)
  at com.sun.media.PlaybackEngine.doPrefetch(PlaybackEngine.java:547)
  at
com.sun.media.PrefetchWorkThread.process(BasicController.java:1430)
  at
com.sun.media.StateTransitionWorkThread.run(BasicController.java:1339)

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#5

Hi!
When I try to communicate with other clients, or, in this case with a
softswitch gateway to POTS, the voice quality is terrible. There is a lot of
echo and a damaged audio stream. The guys from the softswitch said, that it
seems, that SC ignores the "packetization time", which is set by the
softswitch. It works with the other tested softphones like Xlite or Wengo,
so this seems an SC issure, or one of the used stack. It this known, is
there a workaround?

Regards, thomas

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#6

Hello Thomas,

This sounds indeed like a JMF issue indeed. The problem is that we
probably won't be able to do anything about it until we switch to FMJ.

We are already working on the FMJ integration but I guess it would take
a while before we are ready. I hope we'll have a first version with FMJ
for alpha3 (February/March 2008)

Cheers
Emil

Thomas Hofer wrote:

···

Hi!
When I try to communicate with other clients, or, in this case with a
softswitch gateway to POTS, the voice quality is terrible. There is a lot of
echo and a damaged audio stream. The guys from the softswitch said, that it
seems, that SC ignores the "packetization time", which is set by the
softswitch. It works with the other tested softphones like Xlite or Wengo,
so this seems an SC issure, or one of the used stack. It this known, is
there a workaround?

Regards, thomas

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#7

I got a similar problem, and I am using JDK1.5. Infact, I have not even
tried using JDK1.4.x to run SIP Communicator. My logs are a bit differed to
Thomas' because I am not using video media.

     [java] 12:01:52.928 FINE: impl.media.CallSessionImpl.update().1650
received a new incoming stream.
javax.media.rtp.event.NewReceiveStreamEvent[source = RTPManager
     [java] SSRCCache com.sun.media.rtp.SSRCCache@133f6dd
     [java] Dataport 5000
     [java] Controlport 5001
     [java] Address 0.0.0.0
     [java] RTPForwarder com.sun.media.rtp.util.PacketForwarder@944dbd
     [java] RTPDemux com.sun.media.rtp.RTPDemultiplexer@7bd46a]
     [java] 12:01:52.928 FINE: impl.media.CallSessionImpl.update().1660
Received new RTP stream: ilbc/rtp, 8000.0 Hz, Mono
     [java] 12:01:52.938 FINE:
impl.media.CallSessionImpl.controllerUpdate().1734 Received a
ControllerEvent:
javax.media.TransitionEvent[source=com.sun.media.content.unknown.Handler@1fb
7565,previous=Unrealized,current=Realizing,target=Realized]
     [java] 12:01:52.988 FINE:
impl.media.CallSessionImpl.controllerUpdate().1734 Received a
ControllerEvent:
javax.media.RealizeCompleteEvent[source=com.sun.media.content.unknown.Handle
r@1fb7565,previous=Realizing,current=Realized,target=Realized]
     [java] 12:01:52.988 FINE:
impl.media.CallSessionImpl.controllerUpdate().1767 Setting volume to max
     [java] 12:01:52.988 FINE:
impl.media.CallSessionImpl.controllerUpdate().1774 A player was realized and
will be started.
     [java] 12:01:52.988 FINE:
impl.media.CallSessionImpl.controllerUpdate().1734 Received a
ControllerEvent:
javax.media.TransitionEvent[source=com.sun.media.content.unknown.Handler@1fb
7565,previous=Realized,current=Prefetching,target=Started]
     [java] Exception in thread "JMF thread:
com.sun.media.PlaybackEngine@eddac ( prefetchThread)"
java.lang.IllegalArgumentException: Requested value 7.9588003 exceeds
allowable maximum value 6.0206.
     [java] at
javax.sound.sampled.FloatControl.setValue(FloatControl.java:178)
     [java] at
com.sun.media.sound.DirectAudioDevice$DirectDL$Gain.setValue(DirectAudioDevi
ce.java:850)
     [java] at
com.sun.media.renderer.audio.device.JavaSoundOutput.setGain(JavaSoundOutput.
java:157)
     [java] at
com.sun.media.renderer.audio.AudioRenderer.initDevice(AudioRenderer.java:294
)
     [java] at
com.sun.media.renderer.audio.JavaSoundRenderer.initDevice(JavaSoundRenderer.
java:125)
     [java] at
com.sun.media.renderer.audio.JavaSoundRenderer.open(JavaSoundRenderer.java:9
1)
     [java] at
com.sun.media.BasicRendererModule.doPrefetch(BasicRendererModule.java:157)
     [java] at
com.sun.media.BasicTrackControl.prefetchTrack(BasicTrackControl.java:98)
     [java] at
com.sun.media.PlaybackEngine.doPrefetch1(PlaybackEngine.java:592)
     [java] at
com.sun.media.PlaybackEngine.doPrefetch(PlaybackEngine.java:547)
     [java] at
com.sun.media.PrefetchWorkThread.process(BasicController.java:1430)
     [java] at
com.sun.media.StateTransitionWorkThread.run(BasicController.java:1339)

Kind Regards,
Asad Nasir
Software Engineer
IST Networks

···

-----Original Message-----

From: Thomas Hofer [mailto:mailinglisten@familie-hofer.net]

Sent: Monday, 10 September 2007 10:24 PM
To: dev@sip-communicator.dev.java.net
Subject: [sip-comm-dev] Exception with Java 1.6

Hi! I got following exception when trying with java 1.6. It seems an
incompatibility between Java 1.6 (or 1.5) and the JMF on Windows. It there
any possibility for a workaround or do I have to use java 1.4.2?

Regards, thomas

16:20:05.859 SCHWERWIEGEND:
impl.media.CallSessionImpl.controllerUpdate().1836 The following error was
reported while starting a
playerjavax.media.ResourceUnavailableEvent[source=com.sun.media.content.unkn
own.Handler@1c30dfa,message=Failed to realize: input media not supported:
h263/rtp video]
Exception in thread "JMF thread: com.sun.media.PlaybackEngine@a7563d (
prefetchThread)" java.lang.IllegalArgumentException: Requested value
7.9588003 exceeds allowable maximum value 6.0206.
  at javax.sound.sampled.FloatControl.setValue(FloatControl.java:178)
  at
com.sun.media.sound.DirectAudioDevice$DirectDL$Gain.setValue(DirectAudioDevi
ce.java:833)
  at
com.sun.media.renderer.audio.device.JavaSoundOutput.setGain(JavaSoundOutput.
java:157)
  at
com.sun.media.renderer.audio.AudioRenderer.initDevice(AudioRenderer.java:294
)
  at
com.sun.media.renderer.audio.JavaSoundRenderer.initDevice(JavaSoundRenderer.
java:125)
  at
com.sun.media.renderer.audio.JavaSoundRenderer.open(JavaSoundRenderer.java:9
1)
  at
com.sun.media.BasicRendererModule.doPrefetch(BasicRendererModule.java:157)
  at
com.sun.media.BasicTrackControl.prefetchTrack(BasicTrackControl.java:98)
  at com.sun.media.PlaybackEngine.doPrefetch1(PlaybackEngine.java:592)
  at com.sun.media.PlaybackEngine.doPrefetch(PlaybackEngine.java:547)
  at
com.sun.media.PrefetchWorkThread.process(BasicController.java:1430)
  at
com.sun.media.StateTransitionWorkThread.run(BasicController.java:1339)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#8

I debugged the code, and it IS a JMF-issue combined with the issue, that the
packetization time is never set. I did not find out how to (re)set the
packetization time ( = buffer size), but I have found a workaround/hack, so
it works for me at least at the moment. The trick is to set the bufferlength
in the buffercontrol, if anyone is interested in the workaround and/or has a
similar problem.

Cheers. Thomas

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#9

Hi guys,

I've removed the reference to the gain control in CallSessionImpl.

Could you please try and let me know whether it changes something?

Emil

Asad Nasir wrote:

···

I got a similar problem, and I am using JDK1.5. Infact, I have not even
tried using JDK1.4.x to run SIP Communicator. My logs are a bit differed to
Thomas' because I am not using video media.

     [java] 12:01:52.928 FINE: impl.media.CallSessionImpl.update().1650
received a new incoming stream.
javax.media.rtp.event.NewReceiveStreamEvent[source = RTPManager
     [java] SSRCCache com.sun.media.rtp.SSRCCache@133f6dd
     [java] Dataport 5000
     [java] Controlport 5001
     [java] Address 0.0.0.0
     [java] RTPForwarder com.sun.media.rtp.util.PacketForwarder@944dbd
     [java] RTPDemux com.sun.media.rtp.RTPDemultiplexer@7bd46a]
     [java] 12:01:52.928 FINE: impl.media.CallSessionImpl.update().1660
Received new RTP stream: ilbc/rtp, 8000.0 Hz, Mono
     [java] 12:01:52.938 FINE:
impl.media.CallSessionImpl.controllerUpdate().1734 Received a
ControllerEvent:
javax.media.TransitionEvent[source=com.sun.media.content.unknown.Handler@1fb
7565,previous=Unrealized,current=Realizing,target=Realized]
     [java] 12:01:52.988 FINE:
impl.media.CallSessionImpl.controllerUpdate().1734 Received a
ControllerEvent:
javax.media.RealizeCompleteEvent[source=com.sun.media.content.unknown.Handle
r@1fb7565,previous=Realizing,current=Realized,target=Realized]
     [java] 12:01:52.988 FINE:
impl.media.CallSessionImpl.controllerUpdate().1767 Setting volume to max
     [java] 12:01:52.988 FINE:
impl.media.CallSessionImpl.controllerUpdate().1774 A player was realized and
will be started.
     [java] 12:01:52.988 FINE:
impl.media.CallSessionImpl.controllerUpdate().1734 Received a
ControllerEvent:
javax.media.TransitionEvent[source=com.sun.media.content.unknown.Handler@1fb
7565,previous=Realized,current=Prefetching,target=Started]
     [java] Exception in thread "JMF thread:
com.sun.media.PlaybackEngine@eddac ( prefetchThread)"
java.lang.IllegalArgumentException: Requested value 7.9588003 exceeds
allowable maximum value 6.0206.
     [java] at
javax.sound.sampled.FloatControl.setValue(FloatControl.java:178)
     [java] at
com.sun.media.sound.DirectAudioDevice$DirectDL$Gain.setValue(DirectAudioDevi
ce.java:850)
     [java] at
com.sun.media.renderer.audio.device.JavaSoundOutput.setGain(JavaSoundOutput.
java:157)
     [java] at
com.sun.media.renderer.audio.AudioRenderer.initDevice(AudioRenderer.java:294
)
     [java] at
com.sun.media.renderer.audio.JavaSoundRenderer.initDevice(JavaSoundRenderer.
java:125)
     [java] at
com.sun.media.renderer.audio.JavaSoundRenderer.open(JavaSoundRenderer.java:9
1)
     [java] at
com.sun.media.BasicRendererModule.doPrefetch(BasicRendererModule.java:157)
     [java] at
com.sun.media.BasicTrackControl.prefetchTrack(BasicTrackControl.java:98)
     [java] at
com.sun.media.PlaybackEngine.doPrefetch1(PlaybackEngine.java:592)
     [java] at
com.sun.media.PlaybackEngine.doPrefetch(PlaybackEngine.java:547)
     [java] at
com.sun.media.PrefetchWorkThread.process(BasicController.java:1430)
     [java] at
com.sun.media.StateTransitionWorkThread.run(BasicController.java:1339)

Kind Regards,
Asad Nasir
Software Engineer
IST Networks

-----Original Message-----
From: Thomas Hofer [mailto:mailinglisten@familie-hofer.net]
Sent: Monday, 10 September 2007 10:24 PM
To: dev@sip-communicator.dev.java.net
Subject: [sip-comm-dev] Exception with Java 1.6

Hi! I got following exception when trying with java 1.6. It seems an
incompatibility between Java 1.6 (or 1.5) and the JMF on Windows. It there
any possibility for a workaround or do I have to use java 1.4.2?

Regards, thomas

16:20:05.859 SCHWERWIEGEND:
impl.media.CallSessionImpl.controllerUpdate().1836 The following error was
reported while starting a
playerjavax.media.ResourceUnavailableEvent[source=com.sun.media.content.unkn
own.Handler@1c30dfa,message=Failed to realize: input media not supported:
h263/rtp video]
Exception in thread "JMF thread: com.sun.media.PlaybackEngine@a7563d (
prefetchThread)" java.lang.IllegalArgumentException: Requested value
7.9588003 exceeds allowable maximum value 6.0206.
  at javax.sound.sampled.FloatControl.setValue(FloatControl.java:178)
  at
com.sun.media.sound.DirectAudioDevice$DirectDL$Gain.setValue(DirectAudioDevi
ce.java:833)
  at
com.sun.media.renderer.audio.device.JavaSoundOutput.setGain(JavaSoundOutput.
java:157)
  at
com.sun.media.renderer.audio.AudioRenderer.initDevice(AudioRenderer.java:294
)
  at
com.sun.media.renderer.audio.JavaSoundRenderer.initDevice(JavaSoundRenderer.
java:125)
  at
com.sun.media.renderer.audio.JavaSoundRenderer.open(JavaSoundRenderer.java:9
1)
  at
com.sun.media.BasicRendererModule.doPrefetch(BasicRendererModule.java:157)
  at
com.sun.media.BasicTrackControl.prefetchTrack(BasicTrackControl.java:98)
  at com.sun.media.PlaybackEngine.doPrefetch1(PlaybackEngine.java:592)
  at com.sun.media.PlaybackEngine.doPrefetch(PlaybackEngine.java:547)
  at
com.sun.media.PrefetchWorkThread.process(BasicController.java:1430)
  at
com.sun.media.StateTransitionWorkThread.run(BasicController.java:1339)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#10

Hey Thomas,

Would you be interested in sending your patch over so that we could
integrate it in the main source tree?

Thanks
Emil

Thomas Hofer wrote:

···

I debugged the code, and it IS a JMF-issue combined with the issue, that the
packetization time is never set. I did not find out how to (re)set the
packetization time ( = buffer size), but I have found a workaround/hack, so
it works for me at least at the moment. The trick is to set the bufferlength
in the buffercontrol, if anyone is interested in the workaround and/or has a
similar problem.

Cheers. Thomas

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#11

Actually this is really a hack, not a fix. What I did is just to change the
buffersize of the incoming audio stream to the size, the outgoing stream is
expecting. The packetizer of the codec (we use Mu-Law) does not change this,
so it works in our environment. But I'm not sure, how this affects other
codecs. Therefore I'm trying to get the code of mulaw-codec (packetzier,
decoder, depacketizer and encoder) and build my own codec handler, such as
the alaw codec by Damian Minkov. Or find a way to access the codec and
(re-)set the packetsize - this would be the far better way. Can anyone give
me a hint, how to get the object of the packetizer, e.g. in the
mediacontrol, where the whole thing is initialized:

My workaround in Mediacontrol

            Control ctl = (Control)
                dataSource.getControl("javax.media.control.BufferControl");

            if(ctl != null)
            {
--> //30 is the packetization time of the softswitch
--> ((BufferControl)ctl).setBufferLength(30);
            }

···

-----Ursprüngliche Nachricht-----
Von: Emil Ivov [mailto:emcho@sip-communicator.org]
Gesendet: Dienstag, 11. September 2007 19:47
An: dev@sip-communicator.dev.java.net
Betreff: Re: AW: [sip-comm-dev] Packetization-Time ignored

Hey Thomas,

Would you be interested in sending your patch over so that we could
integrate it in the main source tree?

Thanks
Emil

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#12

Hi Emil
   
  Did notice a memory leak in the sip stack. ?
   
  Dennis
     
Emil Ivov <emcho@sip-communicator.org> a �crit :
  Hey Thomas,

Would you be interested in sending your patch over so that we could
integrate it in the main source tree?

Thanks
Emil

Thomas Hofer wrote:

···

I debugged the code, and it IS a JMF-issue combined with the issue, that the
packetization time is never set. I did not find out how to (re)set the
packetization time ( = buffer size), but I have found a workaround/hack, so
it works for me at least at the moment. The trick is to set the bufferlength
in the buffercontrol, if anyone is interested in the workaround and/or has a
similar problem.

Cheers. Thomas

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------
Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail


#13

Hi,

you can write your own codec and register it as the others are registered
but first you must remove the one that is used right now to be sure
that your packetizer will be used:

PlugInManager.removePlugIn("com.sun.media.codec.audio.ulaw.Packetizer",
PlugInManager.CODEC);

Of course everything is in MediaControl.registerCustomCodecs.

damencho

···

On 9/12/07, Thomas Hofer <mailinglisten@familie-hofer.net> wrote:

Actually this is really a hack, not a fix. What I did is just to change the
buffersize of the incoming audio stream to the size, the outgoing stream is
expecting. The packetizer of the codec (we use Mu-Law) does not change this,
so it works in our environment. But I'm not sure, how this affects other
codecs. Therefore I'm trying to get the code of mulaw-codec (packetzier,
decoder, depacketizer and encoder) and build my own codec handler, such as
the alaw codec by Damian Minkov. Or find a way to access the codec and
(re-)set the packetsize - this would be the far better way. Can anyone give
me a hint, how to get the object of the packetizer, e.g. in the
mediacontrol, where the whole thing is initialized:

My workaround in Mediacontrol

            Control ctl = (Control)
                dataSource.getControl("javax.media.control.BufferControl");

            if(ctl != null)
            {
--> //30 is the packetization time of the softswitch
--> ((BufferControl)ctl).setBufferLength(30);
            }

> -----Ursprüngliche Nachricht-----
> Von: Emil Ivov [mailto:emcho@sip-communicator.org]
> Gesendet: Dienstag, 11. September 2007 19:47
> An: dev@sip-communicator.dev.java.net
> Betreff: Re: AW: [sip-comm-dev] Packetization-Time ignored
>
> Hey Thomas,
>
> Would you be interested in sending your patch over so that we could
> integrate it in the main source tree?
>
> Thanks
> Emil

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#14

How can there be a memory leak in a Java app, unless it's triggering a
bug in the JVM? Or is the SIP stack in native code?

···

On Thu, 2007-09-13 at 22:32 +0200, D. Lazreg wrote:

Hi Emil

Did notice a memory leak in the sip stack. ?

Dennis
   
Emil Ivov <emcho@sip-communicator.org> a écrit :
        Hey Thomas,
        
        Would you be interested in sending your patch over so that we
        could
        integrate it in the main source tree?
        
        Thanks
        Emil
        
        Thomas Hofer wrote:
        > I debugged the code, and it IS a JMF-issue combined with the
        issue, that the
        > packetization time is never set. I did not find out how to
        (re)set the
        > packetization time ( = buffer size), but I have found a
        workaround/hack, so
        > it works for me at least at the moment. The trick is to set
        the bufferlength
        > in the buffercontrol, if anyone is interested in the
        workaround and/or has a
        > similar problem.
        >
        > Cheers. Thomas
        >
        >
        ---------------------------------------------------------------------
        > To unsubscribe, e-mail:
        dev-unsubscribe@sip-communicator.dev.java.net
        > For additional commands, e-mail:
        dev-help@sip-communicator.dev.java.net
        >
        >
        
        ---------------------------------------------------------------------
        To unsubscribe, e-mail:
        dev-unsubscribe@sip-communicator.dev.java.net
        For additional commands, e-mail:
        dev-help@sip-communicator.dev.java.net
        
______________________________________________________________________
Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers
Yahoo! Mail

--

(C) Matthew Rubenstein

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#15

Well, there can be a leak in long running applications that hold
references from Hashtables and such. If you notice a leak, I would
need a small self contained example to try to debug it.

···

On 9/13/07, Matthew Rubenstein <email@mattruby.com> wrote:

       How can there be a memory leak in a Java app, unless it's triggering a
bug in the JVM? Or is the SIP stack in native code?

On Thu, 2007-09-13 at 22:32 +0200, D. Lazreg wrote:
> Hi Emil
>
> Did notice a memory leak in the sip stack. ?
>
> Dennis
>
>
>
> Emil Ivov <emcho@sip-communicator.org> a écrit :
> Hey Thomas,
>
> Would you be interested in sending your patch over so that we
> could
> integrate it in the main source tree?
>
> Thanks
> Emil
>
> Thomas Hofer wrote:
> > I debugged the code, and it IS a JMF-issue combined with the
> issue, that the
> > packetization time is never set. I did not find out how to
> (re)set the
> > packetization time ( = buffer size), but I have found a
> workaround/hack, so
> > it works for me at least at the moment. The trick is to set
> the bufferlength
> > in the buffercontrol, if anyone is interested in the
> workaround and/or has a
> > similar problem.
> >
> > Cheers. Thomas
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> dev-unsubscribe@sip-communicator.dev.java.net
> > For additional commands, e-mail:
> dev-help@sip-communicator.dev.java.net
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> dev-unsubscribe@sip-communicator.dev.java.net
> For additional commands, e-mail:
> dev-help@sip-communicator.dev.java.net
>
>
>
>
>
> ______________________________________________________________________
> Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers
> Yahoo! Mail
--

(C) Matthew Rubenstein

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

--
M. Ranganathan
"There are two ways to write error-free programs; only the third one
works." -- Alan Perlis
http://www.animenewsnetwork.com/encyclopedia/anime.php?id=1052

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#16

Hello!

As a matter of fact, I've recently found some memory leaks in the SIP
protocol handling of SIP Communicator. I meant to send the patches earlier,
but had too much to do.

MediaServiceImpl keeps a reference to every CallSessionImpl which is ever
created. There's a TODO comment to remove closed calls :wink: The patch goes
the simplest route and simply comments out the line which adds the newly
created callSession to the list of activeCallSessions, which can be done
because activeCallSessions is not used. Perhaps activeCallSessions coud be
removed completely until the time it is needed?

The second patch deallocates and closes the players created during a
CallSession, which are currently only stopped.

The third patch decreases the impact of a memory leak in the SUN JMF
implementation, which stores custom codec formats in a static Vector and
thus never releases them even if the RTP manager on which the format is
registered is released.

I've found the patch by setting the JVM startup parameter
-XX:+HeapDumpOnOutOfMemoryError and then using Abbot (http://abbot.sf.net/)
to repeatedly start and end calls until I got an OutOfMemory error. I
analyzed the resulting heap dump with jhat, which is part of the JDK 1.6
(see http://java.sun.com/javase/6/docs/technotes/tools/share/jhat.html).
Unfortunately, the Abbot scripts which I've used won't work with the plain
SIP Communicator, since I've been testing with our in-house application,
which merely calls out to the SIP Communicator SIP module.

Regards
Michael Koch

memleak-MediaServiceImpl.patch (725 Bytes)

memleak-CallSessionImpl-1.patch (559 Bytes)

memleak-CallSessionImpl-2.patch (1.91 KB)

···

-----Ursprüngliche Nachricht-----
Von: M. (Neo-Ranga) Ranganathan [mailto:mranga@gmail.com]
Gesendet: Donnerstag, 13. September 2007 23:50
An: dev@sip-communicator.dev.java.net
Cc: D. Lazreg
Betreff: Re: [sip-comm-dev] Memory Leak in Sip Stack

Well, there can be a leak in long running applications that hold
references from Hashtables and such. If you notice a leak, I would
need a small self contained example to try to debug it.

On 9/13/07, Matthew Rubenstein <email@mattruby.com> wrote:
> How can there be a memory leak in a Java app, unless
it's triggering a
> bug in the JVM? Or is the SIP stack in native code?
>
>
> On Thu, 2007-09-13 at 22:32 +0200, D. Lazreg wrote:
> > Hi Emil
> >
> > Did notice a memory leak in the sip stack. ?
> >
> > Dennis


#17

I should point out that FMJ has a ulaw packetizer you can use.

net.sf.fmj.media.codec.audio.ulaw.Packetizer
As well as DePacketizer, Encoder, and Decoder.

Maybe this can be of help.

Ken

Damian Minkov wrote:

···

Hi,

you can write your own codec and register it as the others are registered
but first you must remove the one that is used right now to be sure
that your packetizer will be used:

PlugInManager.removePlugIn("com.sun.media.codec.audio.ulaw.Packetizer",
PlugInManager.CODEC);

Of course everything is in MediaControl.registerCustomCodecs.

damencho

On 9/12/07, Thomas Hofer <mailinglisten@familie-hofer.net> wrote:
  

Actually this is really a hack, not a fix. What I did is just to change the
buffersize of the incoming audio stream to the size, the outgoing stream is
expecting. The packetizer of the codec (we use Mu-Law) does not change this,
so it works in our environment. But I'm not sure, how this affects other
codecs. Therefore I'm trying to get the code of mulaw-codec (packetzier,
decoder, depacketizer and encoder) and build my own codec handler, such as
the alaw codec by Damian Minkov. Or find a way to access the codec and
(re-)set the packetsize - this would be the far better way. Can anyone give
me a hint, how to get the object of the packetizer, e.g. in the
mediacontrol, where the whole thing is initialized:

My workaround in Mediacontrol

            Control ctl = (Control)
                dataSource.getControl("javax.media.control.BufferControl");

            if(ctl != null)
            {
--> //30 is the packetization time of the softswitch
--> ((BufferControl)ctl).setBufferLength(30);
            }

-----Urspr�ngliche Nachricht-----
Von: Emil Ivov [mailto:emcho@sip-communicator.org]
Gesendet: Dienstag, 11. September 2007 19:47
An: dev@sip-communicator.dev.java.net
Betreff: Re: AW: [sip-comm-dev] Packetization-Time ignored

Hey Thomas,

Would you be interested in sending your patch over so that we could
integrate it in the main source tree?

Thanks
Emil
      

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#18

oh, thanks! I think, that was the hint I needed....

cheers, thomas

···

-----Ursprüngliche Nachricht-----
Von: Damian Minkov [mailto:damencho@damencho.com]
Gesendet: Mittwoch, 12. September 2007 10:02
you can write your own codec and register it as the others are
registered
but first you must remove the one that is used right now to be sure
that your packetizer will be used:

PlugInManager.removePlugIn("com.sun.media.codec.audio.ulaw.Packetizer",
PlugInManager.CODEC);

Of course everything is in MediaControl.registerCustomCodecs.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#19

Thanks to your help I finally got the point!

I just unregistered the Mulaw-Packetizer in the register custom codecs and
registered my own, which subclasses the original one. The only change is the
packetsize of 240 (original was 480).

Additionally I changed the input buffer size in Mediacontrol to 30 (but also
values from 10-60 work fine), 130 seems to be a very long time for input
packets for voice communication.

The comment says, that the default value of 125ms does not work on MacOS. Is
it a problem with exact that value, or can it be less, e.g. 30? I've no mac
here to test that behavior.

If anyone is interested, I attached the files.

Cheers, thomas

MediaControl.java (40.3 KB)

Packetizer.java (811 Bytes)


#20

Dennis,

Saying that JProfiler shows a leak is not enough information. I need
a small, self contained test program where I can look at the entire
program and tell that there is no leak in the program. Take a look at
test/load/concurrency I can run 10,000 call setup / teardown without
trouble. Can you reproduce your problem using test/load/concurrency?

As for the leak below, thats not coming from the SIP stack but it
appears to be other data structures that SIP communicator is holding
on to.

Regards,

Ranga

···

On 9/14/07, Koch Michael <MKoch@rowa.de> wrote:

Hello!

As a matter of fact, I've recently found some memory leaks in the SIP
protocol handling of SIP Communicator. I meant to send the patches earlier,
but had too much to do.

MediaServiceImpl keeps a reference to every CallSessionImpl which is ever
created. There's a TODO comment to remove closed calls :wink: The patch goes
the simplest route and simply comments out the line which adds the newly
created callSession to the list of activeCallSessions, which can be done
because activeCallSessions is not used. Perhaps activeCallSessions coud be
removed completely until the time it is needed?

The second patch deallocates and closes the players created during a
CallSession, which are currently only stopped.

The third patch decreases the impact of a memory leak in the SUN JMF
implementation, which stores custom codec formats in a static Vector and
thus never releases them even if the RTP manager on which the format is
registered is released.

I've found the patch by setting the JVM startup parameter
-XX:+HeapDumpOnOutOfMemoryError and then using Abbot (http://abbot.sf.net/)
to repeatedly start and end calls until I got an OutOfMemory error. I
analyzed the resulting heap dump with jhat, which is part of the JDK 1.6
(see http://java.sun.com/javase/6/docs/technotes/tools/share/jhat.html).
Unfortunately, the Abbot scripts which I've used won't work with the plain
SIP Communicator, since I've been testing with our in-house application,
which merely calls out to the SIP Communicator SIP module.

Regards
Michael Koch

> -----Ursprüngliche Nachricht-----
> Von: M. (Neo-Ranga) Ranganathan [mailto:mranga@gmail.com]
> Gesendet: Donnerstag, 13. September 2007 23:50
> An: dev@sip-communicator.dev.java.net
> Cc: D. Lazreg
> Betreff: Re: [sip-comm-dev] Memory Leak in Sip Stack
>
> Well, there can be a leak in long running applications that hold
> references from Hashtables and such. If you notice a leak, I would
> need a small self contained example to try to debug it.
>
> On 9/13/07, Matthew Rubenstein <email@mattruby.com> wrote:
> > How can there be a memory leak in a Java app, unless
> it's triggering a
> > bug in the JVM? Or is the SIP stack in native code?
> >
> >
> > On Thu, 2007-09-13 at 22:32 +0200, D. Lazreg wrote:
> > > Hi Emil
> > >
> > > Did notice a memory leak in the sip stack. ?
> > >
> > > Dennis

--
M. Ranganathan
"There are two ways to write error-free programs; only the third one
works." -- Alan Perlis
http://www.animenewsnetwork.com/encyclopedia/anime.php?id=1052

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net