I've been contemplating Daniel's earlier question about using the CAcert certificates with Lumicall
sip5060.net should already accept mutual authentication from other Kamailio instances running with a CAcert certificate
However, the Lumicall dialer itself will only connect to servers that are using a cert signed by a root CA trusted within Android. This applies to both the SIP and STUN over TLS support.
It may be possible for me to embed the CACert root in the Lumicall package and create a custom trust manager - allowing Lumicall to work with any server using CAcert TLS certificates. Does anyone have any strong feelings about not doing something like that?
On 09/02/12 01:41, Daniel Pocock wrote:
I've been contemplating Daniel's earlier question about using the CAcert certificates with Lumicall
sip5060.net should already accept mutual authentication from other Kamailio instances running with a CAcert certificate
However, the Lumicall dialer itself will only connect to servers that are using a cert signed by a root CA trusted within Android. This applies to both the SIP and STUN over TLS support.
CAcert.org now supported...
Installing Lumicall does not change the trusted CAs for all apps on the phone. It only adds the CACert (class 1 root) for the SIP TLS transport within the app. This means you can use a CAcert.org cert on a Kamailio server, and Lumicall will trust it.
On a side note, I've noticed that CAcert.org is allowing subjectAltName (DNSName) within the certs it issues: this is another good reason to use the CAcert.org certs, other CAs are quite awkward (or expensive) for subjectAltName, and it is really useful for running multiple/virtual hosted domains on a single SIP server.
I would be interested in any feedback about this, either for the Lumicall app, or the interconnect to/from sip5060.net over TLS
Hello,
On 2/9/12 5:21 PM, Daniel Pocock wrote:
On 09/02/12 01:41, Daniel Pocock wrote:
I've been contemplating Daniel's earlier question about using the CAcert certificates with Lumicall
sip5060.net should already accept mutual authentication from other Kamailio instances running with a CAcert certificate
However, the Lumicall dialer itself will only connect to servers that are using a cert signed by a root CA trusted within Android. This applies to both the SIP and STUN over TLS support.
CAcert.org now supported...
nice...
Installing Lumicall does not change the trusted CAs for all apps on the phone. It only adds the CACert (class 1 root) for the SIP TLS transport within the app. This means you can use a CAcert.org cert on a Kamailio server, and Lumicall will trust it.
On a side note, I've noticed that CAcert.org is allowing subjectAltName (DNSName) within the certs it issues: this is another good reason to use the CAcert.org certs, other CAs are quite awkward (or expensive) for subjectAltName, and it is really useful for running multiple/virtual hosted domains on a single SIP server.
I would be interested in any feedback about this, either for the Lumicall app, or the interconnect to/from sip5060.net over TLS
is it available for download out of the android market? I have an android phone (I guess it is 2.2), but haven't connected it to the market -- I guess I can just use my gmail account for that, still I would take the direct download alternative first, if available (the phone has a settings that allow installation of "untrusted source" applications).
I can try it with my kamailio over tls, not sure when exactly I will have the time for it in the next days.
Cheers, Daniel
On 09/02/12 21:49, Daniel-Constantin Mierla wrote:
Hello,
On 2/9/12 5:21 PM, Daniel Pocock wrote:
On 09/02/12 01:41, Daniel Pocock wrote:
I've been contemplating Daniel's earlier question about using the CAcert certificates with Lumicall
sip5060.net should already accept mutual authentication from other Kamailio instances running with a CAcert certificate
However, the Lumicall dialer itself will only connect to servers that are using a cert signed by a root CA trusted within Android. This applies to both the SIP and STUN over TLS support.
CAcert.org now supported...
nice...
Installing Lumicall does not change the trusted CAs for all apps on the phone. It only adds the CACert (class 1 root) for the SIP TLS transport within the app. This means you can use a CAcert.org cert on a Kamailio server, and Lumicall will trust it.
On a side note, I've noticed that CAcert.org is allowing subjectAltName (DNSName) within the certs it issues: this is another good reason to use the CAcert.org certs, other CAs are quite awkward (or expensive) for subjectAltName, and it is really useful for running multiple/virtual hosted domains on a single SIP server.
I would be interested in any feedback about this, either for the Lumicall app, or the interconnect to/from sip5060.net over TLS
is it available for download out of the android market? I have an android phone (I guess it is 2.2), but haven't connected it to the market -- I guess I can just use my gmail account for that, still I would take the direct download alternative first, if available (the phone has a settings that allow installation of "untrusted source" applications).
I've put it on the site for you to download:
http://www.lumicall.org/download
Android 2.2 is probably the minimum version supported
I can try it with my kamailio over tls, not sure when exactly I will have the time for it in the next days.
If you don't want to register for the SIP5060 service, you can just put dummy values in the registration form, it will then let you get to the menu and add your own SIP details
Hello,
On 2/9/12 11:52 PM, Daniel Pocock wrote:
On 09/02/12 21:49, Daniel-Constantin Mierla wrote:
Hello,
On 2/9/12 5:21 PM, Daniel Pocock wrote:
On 09/02/12 01:41, Daniel Pocock wrote:
I've been contemplating Daniel's earlier question about using the CAcert certificates with Lumicall
sip5060.net should already accept mutual authentication from other Kamailio instances running with a CAcert certificate
However, the Lumicall dialer itself will only connect to servers that are using a cert signed by a root CA trusted within Android. This applies to both the SIP and STUN over TLS support.
CAcert.org now supported...
nice...
Installing Lumicall does not change the trusted CAs for all apps on the phone. It only adds the CACert (class 1 root) for the SIP TLS transport within the app. This means you can use a CAcert.org cert on a Kamailio server, and Lumicall will trust it.
On a side note, I've noticed that CAcert.org is allowing subjectAltName (DNSName) within the certs it issues: this is another good reason to use the CAcert.org certs, other CAs are quite awkward (or expensive) for subjectAltName, and it is really useful for running multiple/virtual hosted domains on a single SIP server.
I would be interested in any feedback about this, either for the Lumicall app, or the interconnect to/from sip5060.net over TLS
is it available for download out of the android market? I have an android phone (I guess it is 2.2), but haven't connected it to the market -- I guess I can just use my gmail account for that, still I would take the direct download alternative first, if available (the phone has a settings that allow installation of "untrusted source" applications).
I've put it on the site for you to download:
http://www.lumicall.org/download
Android 2.2 is probably the minimum version supported
I can try it with my kamailio over tls, not sure when exactly I will have the time for it in the next days.
If you don't want to register for the SIP5060 service, you can just put dummy values in the registration form, it will then let you get to the menu and add your own SIP details
I installed it from the download page, worked fine on android 2.2 -- had no time to test it yet, but I noticed some "warning" messages during installation. Not sure if it is specific for each android phone type or for android in general, but I was alerted that I will allow the application do to a lot of "nasty" things, like taking my gps position, making calls that can cost me money, etc... Being open source and people like myself a devel could check and be safe about if they have a doubt, but I wonder if "usual" people will not become afraid of installing it.
Is it so only when installing from untrusted sources, or also when getting it from the android market? Are all these accesses to various resources and actions needed?
Cheers, Daniel
I installed it from the download page, worked fine on android 2.2 -- had no time to test it yet, but I noticed some "warning" messages during installation. Not sure if it is specific for each android phone type or for android in general, but I was alerted that I will allow the application do to a lot of "nasty" things, like taking my gps position, making calls that can cost me money, etc... Being open source and people
The warnings are a common problem for Android apps
There is no opportunity for the developer to annotate the warning screen or make the warnings more specific
E.g. permission to modify SD card: the Lumicall app only needs permissions to export a backup of the SIP settings, it does not, for example, need to delete pictures and movies. But Android doesn't allow that distinction. As a developer, I have to choose: - give user backup feature with nasty warnings - give user no backup feature
However, I have been reflecting on this, and I think I am going to remove some features (e.g. the backup function) so that users will be less intimidated.
Another strategy is to modularise the app: e.g. divide Lumicall into 3 apps, each with less permissions, and they collaborate using inter-process communication (IPC)
like myself a devel could check and be safe about if they have a doubt, but I wonder if "usual" people will not become afraid of installing it.
The source code is an important issue for me too: I have now implemented SRTP, and almost finished implementing ZRTP. I really believe that such source code should be open so that people can have proof that it is secure (no back doors for someone to monitor calls and sell juicy rumors to British newspapers)
Rather than putting the code on Sourceforge, I'm setting up a site, opentelecoms.org (which is also the Java namespace for the library code) - but I'm trying to choose between running it with a monolithic solution like FusionForge, or separate systems like MoinMoin, Bugzilla, gitosis - I'd be interested in any suggestions about that, as I want the site go beyond the basic goal of distributing source code, and make it a useful resource to the wider VoIP community.
Hello,
On 2/14/12 1:56 PM, Daniel Pocock wrote:
I installed it from the download page, worked fine on android 2.2 -- had no time to test it yet, but I noticed some "warning" messages during installation. Not sure if it is specific for each android phone type or for android in general, but I was alerted that I will allow the application do to a lot of "nasty" things, like taking my gps position, making calls that can cost me money, etc... Being open source and people
The warnings are a common problem for Android apps
There is no opportunity for the developer to annotate the warning screen or make the warnings more specific
ok, just wanted to know about, my best mobile device is the laptop :-) ...
E.g. permission to modify SD card: the Lumicall app only needs permissions to export a backup of the SIP settings, it does not, for example, need to delete pictures and movies. But Android doesn't allow that distinction. As a developer, I have to choose:
- give user backup feature with nasty warnings
- give user no backup feature
However, I have been reflecting on this, and I think I am going to remove some features (e.g. the backup function) so that users will be less intimidated.
Another strategy is to modularise the app: e.g. divide Lumicall into 3 apps, each with less permissions, and they collaborate using inter-process communication (IPC)
Not sure it will help much, from my point of view -- having too many apps to install for getting a proper user experience is not good.
Maybe making configurable options to enable/disable some features is better, explaining what everyone does and accesses.
I started the app and requires to fill some data and do a missed-call. Can you add an option to skip the step and go to setting up details for using a custom SIP service?
like myself a devel could check and be safe about if they have a doubt, but I wonder if "usual" people will not become afraid of installing it.
The source code is an important issue for me too: I have now implemented SRTP, and almost finished implementing ZRTP. I really believe that such source code should be open so that people can have proof that it is secure (no back doors for someone to monitor calls and sell juicy rumors to British newspapers)
:-)
Rather than putting the code on Sourceforge, I'm setting up a site, opentelecoms.org (which is also the Java namespace for the library code)
- but I'm trying to choose between running it with a monolithic solution
like FusionForge, or separate systems like MoinMoin, Bugzilla, gitosis - I'd be interested in any suggestions about that, as I want the site go beyond the basic goal of distributing source code, and make it a useful resource to the wider VoIP community.
It would be useful, but I guess it will take some maintenance time. Maybe you can host the project somewhere that provides all needed tools (bug tracker, mailing lists/forums, scm, a.s.o.).
Cheers, Daniel
Another strategy is to modularise the app: e.g. divide Lumicall into 3 apps, each with less permissions, and they collaborate using inter-process communication (IPC)
Not sure it will help much, from my point of view -- having too many apps to install for getting a proper user experience is not good.
I agree - it is not convenient
On the other hand, it is recommended that developers `modularise', e.g. if someone wants to add SIP support to an app, then instead of making the app bigger with SIP code, they are supposed to just use the Android OS to find existing apps that support `sip:' URIs
This is an approach that makes apps smaller by eliminating duplication - but as there is no automatic download of dependencies, it just makes it inconvenient for the user.
Maybe making configurable options to enable/disable some features is better, explaining what everyone does and accesses.
I agree - but Android doesn't work like that. It is all or nothing. Those are the rules from Google.
I started the app and requires to fill some data and do a missed-call. Can you add an option to skip the step and go to setting up details for using a custom SIP service?
Done - the new version is 1.1.2, it is at http://www.lumicall.org/download or in the market
It also adds - ZRTP and SRTP - a config option to try and not use the IPv6 stack (which is buggy on some phones) - various bug fixes in the dialer, making it slightly more efficient and reliable
What SIP stack does this use?
Is it open source?
Thanks.
On 2/16/12 6:22 PM, Daniel Pocock wrote:
Another strategy is to modularise the app: e.g. divide Lumicall into 3 apps, each with less permissions, and they collaborate using inter-process communication (IPC)
Not sure it will help much, from my point of view -- having too many apps to install for getting a proper user experience is not good.
I agree - it is not convenient
On the other hand, it is recommended that developers `modularise', e.g. if someone wants to add SIP support to an app, then instead of making the app bigger with SIP code, they are supposed to just use the Android OS to find existing apps that support `sip:' URIs
This is an approach that makes apps smaller by eliminating duplication - but as there is no automatic download of dependencies, it just makes it inconvenient for the user.
Maybe making configurable options to enable/disable some features is better, explaining what everyone does and accesses.
I agree - but Android doesn't work like that. It is all or nothing. Those are the rules from Google.
I started the app and requires to fill some data and do a missed-call. Can you add an option to skip the step and go to setting up details for using a custom SIP service?
Done - the new version is 1.1.2, it is at http://www.lumicall.org/download or in the market
It also adds
- ZRTP and SRTP
- a config option to try and not use the IPv6 stack (which is buggy on
some phones)
- various bug fixes in the dialer, making it slightly more efficient and
reliable
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
On 17/02/12 00:40, David wrote:
What SIP stack does this use?
It is based on the MJSIP SIP stack (same stack that is used in Sipdroid)
Is it open source?
I've made some fixes to the stack, I've tried to contact the developers about contributing the code back, but I've had no response. If they are not accepted, I'll create a fork of MJSIP and publish the improved code as part of that.
-
Daniel Pocock -
Daniel-Constantin Mierla -
David