[sip-comm-dev] Blocking thread when hanging up a call


#1

All,

during the tests I discovered a problem that it is not possible to
do a re-call, for example after entering a SIP address and pressing
the call button this call is established. When terminating this first
call I cannot setup a second call by just pressing the call button
again. Even re-entering the SIP address doesn't help.

After a lengthly debug session I figured that the createOutgoingCall
method (it's a synchronized method) hangs. The first root cause is that
the hangup method (in the same object, also synchronized) never returns
and thus locks the object. The second root cause: during hangup
processing the media sources will be closed and here the I found the
real problem.

The class MutePushBufferDataSource disconnects its real data source
using the following method:

     public void disconnect()
     {
         System.out.println("before disconnect: " + dataSource);
         dataSource.disconnect();
         System.out.println("after disconnect");

     }

The "dataSource" is a JMF class "com.sun.media.protocol.javasound.DataSource"
and its disconnect() does not return. Thus the whole hangup processing
is blocked and in turn the telephony operators object. Is this a known
problem?

Because my system is a 64bit system, running 64 bit Java 1.5 it may happen
that JMF and the Linux specific JMF implementation do not run very well
on a 64 bit system. Do I need to do some specific setup for 64bit JMF?
Is there a pure Java JMF implementation? If yes how to use it in SC?
Another option would be to use FMJ - how to force SC to use FMJ instead
of JMF?

Regards,
Werner

···

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


#2

Hi,
I would say that this is not dependant on you system.I use win XP 32 bit and
I have faced similar problem, with hangup.
I didn't examine this problem in depth but it looks very similar.

best regards
Przemyslaw

···

2008/12/6 Werner Dittmann <Werner.Dittmann@t-online.de>

All,

during the tests I discovered a problem that it is not possible to
do a re-call, for example after entering a SIP address and pressing
the call button this call is established. When terminating this first
call I cannot setup a second call by just pressing the call button
again. Even re-entering the SIP address doesn't help.

After a lengthly debug session I figured that the createOutgoingCall
method (it's a synchronized method) hangs. The first root cause is that
the hangup method (in the same object, also synchronized) never returns
and thus locks the object. The second root cause: during hangup
processing the media sources will be closed and here the I found the
real problem.

The class MutePushBufferDataSource disconnects its real data source
using the following method:

   public void disconnect()
   {
       System.out.println("before disconnect: " + dataSource);
       dataSource.disconnect();
       System.out.println("after disconnect");

   }

The "dataSource" is a JMF class
"com.sun.media.protocol.javasound.DataSource"
and its disconnect() does not return. Thus the whole hangup processing
is blocked and in turn the telephony operators object. Is this a known
problem?

Because my system is a 64bit system, running 64 bit Java 1.5 it may happen
that JMF and the Linux specific JMF implementation do not run very well
on a 64 bit system. Do I need to do some specific setup for 64bit JMF?
Is there a pure Java JMF implementation? If yes how to use it in SC?
Another option would be to use FMJ - how to force SC to use FMJ instead
of JMF?

Regards,
Werner

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


#3

To use FMJ, set FMJConditionals.IS_FMJ to true, and make sure FMJ is in your classpath ahead of JMF.

However, if all you want to do is use the FMJ datasource for javasound (which has had some improvements recently), you can do this with JMF registry tricks as well, by making sure that net.sf.fmj.media is ahead of the sun ones in the paths it uses to search for handlers, etc.

Ken

Werner Dittmann wrote:

···

All,

during the tests I discovered a problem that it is not possible to
do a re-call, for example after entering a SIP address and pressing
the call button this call is established. When terminating this first
call I cannot setup a second call by just pressing the call button
again. Even re-entering the SIP address doesn't help.

After a lengthly debug session I figured that the createOutgoingCall
method (it's a synchronized method) hangs. The first root cause is that
the hangup method (in the same object, also synchronized) never returns
and thus locks the object. The second root cause: during hangup
processing the media sources will be closed and here the I found the
real problem.

The class MutePushBufferDataSource disconnects its real data source
using the following method:

    public void disconnect()
    {
        System.out.println("before disconnect: " + dataSource);
        dataSource.disconnect();
        System.out.println("after disconnect");

    }

The "dataSource" is a JMF class "com.sun.media.protocol.javasound.DataSource"
and its disconnect() does not return. Thus the whole hangup processing
is blocked and in turn the telephony operators object. Is this a known
problem?

Because my system is a 64bit system, running 64 bit Java 1.5 it may happen
that JMF and the Linux specific JMF implementation do not run very well
on a 64 bit system. Do I need to do some specific setup for 64bit JMF?
Is there a pure Java JMF implementation? If yes how to use it in SC?
Another option would be to use FMJ - how to force SC to use FMJ instead
of JMF?

Regards,
Werner

---------------------------------------------------------------------
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


#4

Hi,

after some more research and looking for similar error reports
I upgraded my system to Java 6. There were some reports that
state that the sound implementation has some problems and
several errors were fixed in Tiger (Java 6).

Using Java 6 I didn't face this hangup problem until now :slight_smile:

When upgrading to Java 6 don't forget to update the JCE unlimited
strength policy if you are using ZRTP - otherwise you cannot get
a secure connection.

Regards,
Werner

Przemysław Dudek schrieb:

···

Hi,
I would say that this is not dependant on you system.I use win XP 32 bit and
I have faced similar problem, with hangup.
I didn't examine this problem in depth but it looks very similar.

best regards
Przemyslaw

2008/12/6 Werner Dittmann <Werner.Dittmann@t-online.de>

All,

during the tests I discovered a problem that it is not possible to
do a re-call, for example after entering a SIP address and pressing
the call button this call is established. When terminating this first
call I cannot setup a second call by just pressing the call button
again. Even re-entering the SIP address doesn't help.

After a lengthly debug session I figured that the createOutgoingCall
method (it's a synchronized method) hangs. The first root cause is that
the hangup method (in the same object, also synchronized) never returns
and thus locks the object. The second root cause: during hangup
processing the media sources will be closed and here the I found the
real problem.

The class MutePushBufferDataSource disconnects its real data source
using the following method:

   public void disconnect()
   {
       System.out.println("before disconnect: " + dataSource);
       dataSource.disconnect();
       System.out.println("after disconnect");

   }

The "dataSource" is a JMF class
"com.sun.media.protocol.javasound.DataSource"
and its disconnect() does not return. Thus the whole hangup processing
is blocked and in turn the telephony operators object. Is this a known
problem?

Because my system is a 64bit system, running 64 bit Java 1.5 it may happen
that JMF and the Linux specific JMF implementation do not run very well
on a 64 bit system. Do I need to do some specific setup for 64bit JMF?
Is there a pure Java JMF implementation? If yes how to use it in SC?
Another option would be to use FMJ - how to force SC to use FMJ instead
of JMF?

Regards,
Werner

---------------------------------------------------------------------
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