8 Feb
2012
8 Feb
'12
7:41 p.m.
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?
9 Feb
9 Feb
11:21 a.m.
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
3:49 p.m.
Hello,
On 2/9/12 5:21 PM, Daniel Pocock wrote:
On 09/02/12 01:41, Daniel Pocock wrote:
nice...
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
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
--
Daniel-Constantin Mierla -- http://www.asipto.com
http://linkedin.com/in/miconda -- http://twitter.com/miconda
5:52 p.m.
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:
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
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... 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
14 Feb
14 Feb
5:53 a.m.
Hello,
On 2/9/12 11:52 PM, Daniel Pocock wrote:
On 09/02/12 21:49, Daniel-Constantin Mierla 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
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
--
Daniel-Constantin Mierla -- http://www.asipto.com
http://linkedin.com/in/miconda -- http://twitter.com/miconda
Hello,
On 2/9/12 5:21 PM, Daniel Pocock wrote:
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
On 09/02/12 01:41, Daniel Pocock wrote:
nice...
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
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.
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
7:56 a.m.
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.
15 Feb
15 Feb
7:10 a.m.
Hello,
On 2/14/12 1:56 PM, Daniel Pocock wrote:
ok, just wanted to know about, my best mobile
device is the laptop :-) ...
:-)
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)
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
--
Daniel-Constantin Mierla -- http://www.asipto.com
http://linkedin.com/in/miconda -- http://twitter.com/miconda
16 Feb
16 Feb
6:22 p.m.
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 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
6:40 p.m.
What SIP stack does this use?
Is it open source?
Thanks.
On 2/16/12 6:22 PM, Daniel Pocock wrote:
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.
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 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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
17 Feb
17 Feb
7:05 a.m.
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?
http://www.mjsip.org/
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.
4697
days inactive
4705
days old
9 comments
3 participants
participants (3)
-
Daniel Pocock -
Daniel-Constantin Mierla -
David