Generally I'm trying to make a SIP bot that can receive and send voice messages. In order to do this I need some java library which can deal with all related protocols (SIP, SDP, RTP). As far as I can see SC is the best hi-level SIP implementation on java.
But SC isn't just a library. It's a multiprotocol client with GUI. In my case there is no need neither for other IM protocols nor for a GUI. In my case I need a few bundles like protocol-sip, neomedia and some their dependencies (plus some native libs).
The problem for me is to isolate SIP implementation bundles from others (ui-service, resourcemanager, etc.) For this purpose I extend (in my project) classes like ProtocolProviderServiceSipImpl, CallPeerMediaHandlerSipImpl by overriding some methods. For example initialize() in ProtocolProviderServiceSipImpl loads sip status icons via resourcemanager, but I can not see quite well why we need them in right protocol initialization, so I remove this in my overridden method.
SipStackSharing creates sip stack with custom SslNetworkLayer which depends on GUI model. In case of SipStackSharing "evil" is done in constructor without args, and I can not override it in descendant because parent's constructor would be called anyway. In previous letter I proposed the easiest way to correct that (you have to change almost nothing) and make sip stack customization possible. One more variant is to create sip stack in method like initialize() or start() instead of constructor, so it would be easy to override.
On Tue, 12 Oct 2010 12:51:09 +0400, Emil Ivov <email@example.com> wrote:
�� 09.10.10 14:28, Anton Nehaev ������:
I'm trying to use some Sip Communicator java bundles as a hi-level
jain-api implementation. Now it's not too easy to do, because existing
interfaces don't allow some extending and tuning.
For example, net.java.sip.communicator.impl.protocol.sip.SipStackSharing
has only one internal constructor which creates SipStackProperties
instance with predefined values inside. Then it creates sip stack using
these properties. It seems that there is no possibility to replace these
properties with my custom ones.
May be it would be better to add an alternative constructor receiving
Properties as argument?
Could you please tell us a bit more about your use case? Adding an extra
constructor to SipStackSharing won't make it any more usable by other
bundles since the class is not exported by the SIP implementation. Can
you tell us how you are using it?