While debugging a problem with SIP calls (see following post), I noticed that
there is no thread safety for the SIP telephony related classes
ProtocolProviderServiceSipImpl, OperationSetBasicTelephonySipImpl and
CallSessionImpl. Since I suspected that this was the cause of my problems, I
tried to improve the situation.
There are (AFAIK) three subsystems using these classes from different threads:
The GUI uses the OperationSetBasicTelephonySipImpl to initiate, answer and
close calls. This in turn invokes methods on the CallSessionImpl and causes
SIP events handled by the ProtocolProviderServiceSipImpl.
The SIP stack sends SIP events to the ProtocolProviderServiceSipImpl. These
are forwarded to the OperationSetBasicTelephonySipImpl, which invokes the
The JMF sends RTP and controller events to the CallSessionImpl. These events
modify objects which are also used by the other methods invoked by the other
In the attached patch I've gone for the simple approach and synchronized the
public methods dealing with GUI calls and event handling. This has a certain
risk for introducing deadlocks, but as far as I understand the code, no
synchronized method blocks and waits for some other synchronized method being
called from another thread. I also haven't seen any problems during my test
While I can't provide a simple reproducible test-case where this patch fixes a
failure, from my tests it seems that it does improve the handling when calls
are initiated and terminated in quick succession.
synchronize-sip-methods.patch (11.8 KB)