integration of pjsip jni

[GoogleCodeExporter]

hi..
  Thanks for your fast response I just want to know that can we import the pjsip jni for android in csipsimple project means that at present time the csipsimple project takes reference from web . Is it possible to remove that link because  if any one is using csipsimple at that time the server is down at that time the csipsimple working will stop ?

thanks a lot for your support.

Original issue reported on code.google.com by ankush.m...@gmail.com on 20 Sep 2010 at 11:03

• Merged into: #223

[GoogleCodeExporter]

No no, as I said there is no reference from web. CSipSimple source code already 
ship my modified version of pjsip-jni. Once you have checked out svn trunk you 
have everything you need (except some resource from the android ndk).

You can browse csipsimple pjsip-jni copy here :
http://code.google.com/p/csipsimple/source/browse/trunk/pjsip_android/apps/pjsip
/project/jni/pjsua_wrap.cpp

And here :
http://code.google.com/p/csipsimple/source/browse/#svn/trunk/CSipSimple/src/org/
pjsip/pjsua

You just need that.

See the wiki page about how to build,
http://code.google.com/p/csipsimple/wiki/HowToBuild
You'll see that you don't need to download anything from pjsip-jni. I think 
that you are confusing the native library with pjsip-jni project. The .so file 
pjsipjni.so is really much more than pjsip-jni it's pjsip_android available 
here on google code. (pjsip + parts of pjsip-jni + my android port of pjsip).

PS : Plz - continue to reply on the same issue. Don't worry I'll be notified 
even if the issue is not active anymore.

Original comment by r3gis...@gmail.com on 20 Sep 2010 at 11:13

• Changed state: Duplicate

[GoogleCodeExporter]

I noticed your license for pjsip_android is the Apache License. But isn't 
pjsip_android based off of pjsip-jni, which is GPL? Would this make 
pjsip_android therefore a derivative of pjsip-jni and restrict it to GPL too? 

Just want to make sure if I use any code, I use it with a legit license. Thanks!

Original comment by halsh...@gmail.com on 5 Mar 2011 at 3:31

[GoogleCodeExporter]

Only *my* pjsip_android files are licensed under Apache license !!! *Only* 
these files. Be really careful with it. Read the Licensing wiki page carefully.

pjsip is licensed under GPL so if you want to use it for your project you must 
acquire the right to use it under another license than the GPL one. Ask teluu 
company for that part (http://www.teluu.com/). 
I released my part to make leave teluu free to reuse my code to sublicense 
something based on pjsip with android. 

It's also based on the work of pjsip-jni guys but is now far from it : 
pjsip-jni is "just" the swig export of pjsip. So it's not really relevant to 
consider the license of the files produced by a SWIG export.

You should also read licensing page on pjsip project.

Besides CSipSimple (the java part) is ONLY GPL licensed. No commercial license 
available.

So if you want to use it for a commercial product : => you *MUST* acquire the 
teluu license and you'll be able to use ONLY the pjsip_android lib.
It is NOT allowed to reuse code from CSipSimple in your project unless you 
release under GPL ! CSipSimple is entierly GPL and will remain only under this 
license.

Last point, if you are doing a project for android I'd advise you to have a 
completely different approach : Android is a powerful OS and allows apps to 
inter-operate.
CSipSimple provide a way to be distributed in a "plugin mode". In this mode it 
becomes a service available on the android OS that provide SIP capabilities to 
the rest of the OS. (Just like the android 2.3 stock SIP api).
As consequence, you can easily imagine redistribute this plugin mode (under 
GPL) + your application that use this plugin (under the license you want).
Using this approach you'll benefit every improvements made in CSipSimple, 
you'll don't bother with all android glue which is really hard to do (and you 
can't copy my code to do so since my code in CSipSimple is ONLY GPL). You'll 
also be able to contribute the opensource project CSipSimple and improve it so 
that it will benefit the rest of the world without preventing you to distribute 
something with hidden features.

Also really think about that, most of the time you have absolutely no benefit 
to close your source. OpenSource things, work with the rest of the world for 
*USERS* .

Be really careful with licensing. Opensource does not mean you can do anything 
with it.

My personal goal is to make the app benefit users.
As consequence :
- I released my part of the *pjsip* port under Apache so that the company 
behind pjsip can benefit my work and promote/support this part in the future.
- I released the java part under GPL so that everybody that want to reuse it 
*MUST* redistribute it work to the community and so make it available for all 
users.

Hope that's more clear.

Original comment by r3gis...@gmail.com on 5 Mar 2011 at 4:23

[GoogleCodeExporter]

Ok, thanks for the explanation. Can you point me to more info on how to use 
CSipSimple in plugin mode? I would love to use it in that capacity if possible, 
and hopefully contribute to it. I see you did mention something about this mode 
in the licensing page, but I couldn't find the list of APIs or how this plugin 
mode works.

Thanks!

Original comment by halsh...@gmail.com on 5 Mar 2011 at 4:48

[GoogleCodeExporter]

Have a look to this directory :

http://code.google.com/p/csipsimple/source/browse/#svn%2Ftrunk%2FCSipSimple%2Fsr
c%2Fcom%2Fcsipsimple%2Fapi

It contains all source code you have to import in your java application project.

You import it, then you bind the service (read 
http://developer.android.com/guide/developing/tools/aidl.html the "Calling an 
IPC Method" part).
It explains how apps can communicate.

The services available in csipsimple are SipManager.INTENT_SIP_SERVICE and 
SipManager.INTENT_SIP_CONFIGURATION . Bind with bindService(new 
Intent(SipManager.INTENT_SIP_CONFIGURATION), mConnection, 
Context.BIND_AUTO_CREATE);

Then once you have the ISipService object (or ISipConfiguration object), you 
can call all method defined in the .aidl. :) If you need more methods than the 
one available it can be enriched. For now I try to use this approach even 
internally to CSipSimple. For example the InCallScreen only talk with the 
service through the aidl API.

Original comment by r3gis...@gmail.com on 5 Mar 2011 at 5:01

[GoogleCodeExporter]

Awesome thanks! So this allows me to use the CSipSimple's functionality behind 
the scenes while building my own UI right? 

This looks like it'll work. And I love how you encapsulated everything and 
provide a choice of using either PJSIP or Google's SIP. Will be looking into 
this further, thanks!

Original comment by halsh...@gmail.com on 5 Mar 2011 at 5:20

[GoogleCodeExporter]

There is not yet the implementation for the official google sip stack, but I'll 
do that soon :). Also I hope that I'll be able to integrate other stack in the 
future. (For example doubango which is really interesting).

The only weird side of this approach is that you have to distribute 2 
applications (the voip plugin (csipsimple) and your app). 

Then yes, you can do anything you want in your app. Have a look to Voxofon app 
on the market. They use this approach. Which is cool is that their app also 
allow their users to use CSipSimple or their distribution of the plugin if one 
is available and if none they open the android market to propose user to 
download their plugin.

Last point, you have in your app to add permissions to use the sip service. In 
CSipSimple there is two permissions names : one is exactly the same than the 
stock android 2.3 permission and the other is one specifically for sip 
configuration.
(Read the wiki page about PermissionsUse, last part explain what are permission 
third party apps can use) (
        <uses-permission android:name="android.permission.USE_SIP" />
        <uses-permission android:name="android.permission.CONFIGURE_SIP" />
)

Original comment by r3gis...@gmail.com on 5 Mar 2011 at 5:44

[GoogleCodeExporter]

Another point, if you want to override the InCall screen it is also possible by 
registering the correct intent (and removing it from your distribution of 
CSipSimple - in fact in your distribution of CSipSimple, you may only need to 
change the manifest file )

Original comment by r3gis...@gmail.com on 5 Mar 2011 at 5:46

[GoogleCodeExporter]

Thanks. Is there a way to download the CSipSimple plugin behind the scenes or 
include it in the binary without the user having to do that extra step of going 
to Android market and downloading the plugin in addition to our app? 

I was going to say why not then license CSipSimple under LGPL, but then I 
remembered you're using PJSIP which is GPL..

Hisham

Original comment by halsh...@gmail.com on 6 Mar 2011 at 12:03

[GoogleCodeExporter]

No you can't do that. It would break the GPL.

GPL is a distribution license. If you distribute something with GPL inside it 
mean that all your software is GPL. That's why I choose GPL.

I could have choose LGPL for my code, but that does not fit what I want for the 
software and my goals with it.
In fact when you develop something you own the copyright on it. Then you can 
choose which license you put on this copyright. You can choose the license you 
want. 
When you want to distribute the software you have to worry about licenses.
When you distribute you have to be careful with the fact all your license are 
compatible together so that you can ship something with the good license.
I distribute CSipSimple under GPL which is constraint by the fact CSipSimple 
itself is GPL and pjsip is GPL too.
But it also contains code released under Apache and other license that are 
compatible with GPL (see the FSF website). That's fine cause GPL terms are are 
those with the most important constraint. So if I distribute CSipSimple or if 
anybody brand it he must redistribute it under GPL cause I choose to release 
under GPL CSipSimple. Even if he buy the pjsip commercial distribution license 
for the native library part.

My goals are different from the one of pjsip guys (teluu). They do a GPL 
library but they have a dual commercial license for companies that does not 
want to release their software under GPL.
It's clever for a library. Cause the aim of a library is to be embedded 
somewhere else. 
CSipSimple is a complete program, besides my goal is *NOT* to make money with 
it. My goal is to make it benefit users. As consequence in my case, the only 
way I have to protect the software from companies that reuse it without ethic 
is to release it under GPL. Btw, I ensure that nobody will use it without 
redistributing improvements to the community. That's really important to keep 
in mind that my work aim is to benefit users, not you that will reuse the app.

I allow by releasing the "api" and making efforts to make it easy for third 
party to reuse the apps and redistribute it 'UNDER GPL'. The goal here is the 
same. You have to release the plugin part under GPL as consequence if you find 
bugs, if you need improvements in the csipsimple part, you have to release 
source code on it. As consequence finally by providing you a way using it like 
this, I make the users benefit the fact you reuse the app. But the way you can 
reuse it is limited due to the fact you don't want your part of the app benefit 
all users cause you don't want to release it under GPL. 
That's fine as far as you make benefit all users the CSipSimple part.

The choose of GPL is really relevant and I know exactly what I do by releasing 
under GPL. I really know about free software licenses and I know that GPL is 
the one that fit what I want for the CSipSimple software. And that's also the 
reason why the little part about the pjsip_android code I wrote is released 
under Apache license so that Teluu company can reuse it. I know their goals 
with their library and as consequence I did my license compliant with their 
part of the work (it was not required at all but I wanted to allow them to make 
more money with my work if some third party company want to reuse *only* 
pjsip_android. That's the less I can do for they great job.

You should read about licenses. That's really interesting and learn about that 
may make you change your point of view about "opensources" licenses. There is 
many opensource license and all are different and suit a specific use case. 
When something is released under a certain license, the author/contributors of 
the software really know what they do.

Original comment by r3gis...@gmail.com on 6 Mar 2011 at 12:41

[GoogleCodeExporter]

Hi, I took CSipSimple code and modified such that it is just a SIP UA without 
any UI with it. It is a service that any other application can call through 
interfaces defined in IDL. It was a very interesting exercise and had good 
results. 
Based on your comment above on using CSipSimple in plug-in mode, does this new 
code base qualify to be a plug-in mode in a commercial product and does it 
violate any licensing?
Your response really appreciated! 

Original comment by perry.lu...@gmail.com on 31 Mar 2011 at 5:07

[GoogleCodeExporter]

Actually if you use the "plugin mode" you must distribute two distinct 
application.

One will be the plugin (CSipSimple with a different .manifest file) and must be 
distributed under GPL license terms. This is not hurting. I guess (I hope) that 
to get CSipSimple running just as a SIP UA you only modified the .manifest 
file... if not, you probably do extra uneeded things ;). Cause actually if you 
try on the android market voxofon or mytunu, (that redistribute csipsimple as a 
branded plugin, the only thing they modify to not get it registering in the 
launcher, to not get it launching when click on notification is done and 
potentially to not get it registering when there is an active call is the 
.manifest file. I did everything to allow to do that simply ;).

The other application will be your application that you can be distributed 
under license terms you want since it's independant of the "plugin" 
(CSipSimple).

It's an independant software cause virtually CSipSimple (or your branded GPL 
redistirbution of it) can virtually be replaced by another plugin for VoIP that 
use the same interface. Actually that's not so virtual cause you probably 
noticed that the existing interfaces really look like the stock android 2.3 SIP 
features ;). 

(And the good reason for that is that in a near future third party apps such as 
your will be able to choose a prefered backend : pjsip or stock SIP if 
available... and hopefully if there is contributions other sip stacks... why 
not doubago for example...).

Original comment by r3gis...@gmail.com on 31 Mar 2011 at 8:23

[GoogleCodeExporter]

Couple of things:
1. I did not modify CSipSimple Manifest file to achieve the plug-in mode. In 
fact, I stripped down all the DB access, any calls to UI etc and made all calls 
into service and callbacks. A truly SIP UA with no ties attached to UI/DB at 
all. 
2. As you suggested, I must distribute two distinct apps. Does it mean that the 
users will require to download two apps? Or can they be bundled into one app? 
Also, how does it work if my app (that depends on CSipSimple based SIP UA) is 
closed and SIP UA receives call. How do I wake it up?
3. Are there any other licensing terms that you allow to let me use that 
stripped down SIPUA "as part of" my app?

Once again, thanks for the good work and thanks for corresponding with me.

Original comment by perry.lu...@gmail.com on 31 Mar 2011 at 3:23

[GoogleCodeExporter]

As for point 1 : you should consider modifying only the Manifest file. 
Everything I did was done to manage this use case.
If you think there is something that can't be done through the manifest file, 
tell me. I should add that as an extensible way to use CSipSimple.

2 -> Yes two apps, but it can be done cleanly. Have a look to voxofon or mytunu 
apps. They integrate CSipSimple as plugin mode a way it provide a good user 
experience.
You can't bundle the GPL app in your app. You must have really two different 
app so that your users can redistribute the "voip plugin".

As for the incoming call, I think you didn't know yet how powerful are manifest 
files. I think you stripped down a lot of things while that was not a good 
idea. You should have asked me before ;). 
In fact CSipSimple send "Intents" to launch UI. And...Intents are registered in 
manifest files !! :D ... 
So if you comment the registration of the in call screen in csipsimple manifest 
and register in your app.... magic, your app will be callback ! Nothing else to 
do. Have a look to my manifest. For the in call screen you'll see that there is 
already a commented interface (that is the 0.01 interface and will be changed 
in next release).

3. No there is no dual license on the app. The goal is to lead anybody that 
want to rely to csipsimple to contribute the project for SIPUA aspects. 
As you'll see when you'll have it really integrated as done by Mytunu or 
Voxofon, you'll see that's not a bad design. It will allow you to upgrade more 
easily the plugin, it will allow you to rely on csipsimple if installed on the 
phone and do not need to install your plugin if user has other sip providers.

Actually this kind of approach is the one used by the android OS everywhere. 
For example, the telephony application is something different than the 
contact/dialer application.

If you have a close look to list of installed apps on your phone, you'll see 
that there is many apps that are installed but not present in the launcher. 

Original comment by r3gis...@gmail.com on 31 Mar 2011 at 10:06

[GoogleCodeExporter]

Thanks for the response and very appreciated your healthy discussion here. 
I think your design is very good and I do understand the power it could bring 
in. A couple of things I did not like are as follows:
1. UI layer is not fully independent of SIP UA. For example, 
notifyRegisteredAccounts gets called from PjSip layer and refers to Intents. I 
think it would be a better idea to just pass either return codes or objects 
back and forth through AIDL. Hope I am understanding everything correctly. If 
not, pardon my comments. 

2. DB layer is embedded too deep. In other words, I might chose to not save 
account information at all in DB and would want to manage call logs etc on my 
own. I could do that as long as i get proper AIDL interfaces to make calls upon 
service and callback on SIP activities. 

I hope I am making sense to you. If not, please pardon my ignorance as I might 
not have understood your design 100%. 

My idea is, SIP UA is for call control and media and can be kept independent of 
everything else. It is easy to develop and debug independently. I developed the 
entire UA without having a second screen. Then designed a dialer and 
integrated. 

So on and so forth....

Original comment by perry.lu...@gmail.com on 1 Apr 2011 at 4:00

[GoogleCodeExporter]

Also, if you did it that way where people can slap the choice of their UI on 
top of this slick SIP UA as a service, there will be a better adoption for that 
SIP UA and that way more contributors as well. And you can open source it with 
GPL V2 if you like and just ask for support contracts for any bug fixes. 

Original comment by perry.lu...@gmail.com on 1 Apr 2011 at 3:18

[GoogleCodeExporter]

Ok I'll try to reply point by point to what you where expecting :

Globally, CSipSimple is more than just an UA. The UA is provided by 
pjsip/pjsua. It also provide the integration with the android OS. Again, 
Android OS is much much much more powerful and extensible than all other mobile 
OS (and even desktop OS). It is designed to allow apps to interact through 
these powerful intents, binders and content provider approach.

Then,
For point 1 : Indeed it refer to intents, and actually it's a very good idea 
when you understand how to use intents ;). You have probably noticed that each 
notification has a pending intent. This pending intent can be de-registered 
from the CSipSimple.manifest, and registered to *YOUR* application. 
So that, when you'll click the notification about the fact you are registered 
to a sip service... it will open YOUR application !! Not CSipSimple UI anymore 
!! Just by commenting out two lines in csipsimple manifest and adding one in 
your app !! 

2 . DB layer is deep because it's not only the UA. Again, the UA is pjsua. 
CSipSimple provides facilities to manage everything related to SIP in the 
android context. For example... call logs. CSipSimple directly put call logs 
into Android OS call logs. The DB you see is an internal DB. If required I can 
provide a content provider so that an external app can access it. But that's 
the good way to do. Content providers are the way an app can provide other apps 
it's content. And then you'll not have to bother anymore with storing call logs 
in your app. Even in CSipSimple it's virtually useless cause most users will 
choose to merge with the stock app call logs.

If you only need a SIP UA, you should probably only have a look to 
pjsip_android part. This is only the UI... but you'll redevelop a lot of 
useless things. Cause CSipSimple is hookable everywhere.... 

As for comment #16 : 
Just please, try to install either Mytunu  (uninstall csipsimple before) (you 
can also try Voxofon). 
You'll see what is possible and you'll maybe understand that android allow apps 
to interact such a way that it's useless to redevelop the "Service" twice. 

You'll see that it is absolutely possible just modifying .manifest file to 
remove *ALL* CSipSimple UI (except the outgoing call chooser and the widget 
manager).

Then you'll be able anywhere in your app to re-bind any CSipSimple UI if you 
need it. (for example the configuration screen). But alternatively, everything 
can be done programmatically inside your app !

Original comment by r3gis...@gmail.com on 1 Apr 2011 at 4:32

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Thanks for the response. I will install Mytunu or Voxofon and see the apps in 
action. 
As I mentioned, I might be completely off base on this need more understanding 
of your architecture a bit better and I am also sure you are developing it for 
the same reason that everyone can use it as a service. Let me dig it more. 

BTW, I tried to compile libpjsipjni.so on linux by using your instructions but 
CSipSimple failed to find JNI references. Any clue?

Original comment by perry.lu...@gmail.com on 1 Apr 2011 at 5:04