CSipSimple and pjsip usability

297 views
Skip to first unread message

agr...@gmail.com

unread,
Jun 3, 2011, 5:17:04 PM6/3/11
to CSipSimple Development
Hi Guys,

I tried to get CSipSimple up and running within my company, observing
my own and my colleagues' patterns as kind of a usability test. Here's
our results:

1. Please enable DNS SRV by default. The point of URIs is to enable
them using sip:m...@mydomain.com like mailto:m...@mydomain.com eventually,
where the former points to something like voip.mydomain.com using DNS
SRV, whereas the latter points to email.mydomain.com using DNS MX.
Nobody argues about the latter, but the former seems to be still a
controversial task - please just do an SRV lookup, because if there is
such a record, it's there for a good reason. I'm not even talking
about rfc3263 :)

2. Use clear field names. We all over here use localized versions in
German, but they are "username" and "server" in the minimal wizard.
This is pretty misleading, because a colleague (being a clever guy
knowing it all better :) ) used "h...@mydomain.com" as username and
"voip.mydomain.com" as "server", because the server is actually
running on "voip.mydomain.com", whereas there's a dns srv record
pointing to it using "mydomain.com". So this leads to some
misunderstanding. Probably it's really better to just use the names
"username" and "domain"? Probably it's also a translation issue, I
don't know.

3. PJSIP outbound-proxy handling. This has been there forever, I guess
(I've spotted it in openwengo and similar clients already). I first
tried to work around the DNS SRV thing (because I couldn't find the
option at first glance) by setting the "Proxy" value in the advanced
wizard. This makes pjsip to add a header "Route:
<sip:voip.mydomain.com>", which will (again IMHO) fail with most of
the properly configured servers, because what it does is resolving
voip.mydomain.com using an A record lookup, sending it there, and
still putting the Route header into the message. Now in my case it
will hit my server, who considers voip.mydomain.com as non-local
(because I've configured my domain as mydomain.com), and it will thus
refuse to loose-route this request, because it's an initial one, and
the server would therefore act as open relay.

4. There's an interoperability issue between the contact change
handling in pjsip upon registration and Kamailio in certain scenarios
(one being our sip:provider CE, which is constructed as proxy/
registrar kamailio instance behind a load-balancer kamailio-instance,
using the Path header). Not much CSipSimple can do about this, except
as a user going into expert mode and disabling this feature. Still
troubleshooting with Daniel Mierla from Kamailio go get this resolved.

Anyways, after all we went with Counterpath Bria at least internally
for our company for now, because that worked out-of-the-box. We're
still pushing #4 forward to get that resolved and hope that you are
willing to discuss WHY you do the other 3 things the way you do it,
and probably we can - together - find a way to make it more user-
friendly. In the end, it would be cool to be able to suggest
CSipSimple to any Android Market user, and she'd be able to configure
it with just a few tabs.

Hope you take this points as anchor points for further discussions
instead of offensive criticisms, cause that's not what it's supposed
to be :)

Regards,
Andreas

Eric tamme

unread,
Jun 3, 2011, 6:00:53 PM6/3/11
to csipsim...@googlegroups.com

1. create a profile template witge whatever settings you want.  not every one uses srv records.

2. field names are always subject to interpetation.  i personally think they are fine.

3. outbound proxy works fine.  if you have an srv that points to a different domain, enable srv so that the route will match the actual proxy ... then it wont fail on preloaded route checking.  this is what i do.

4. you can disable contact rewrite.

personally i like the full configurability of csipsimple.  i dont like it when clients assume to much about how i want to use them.

if you are trying to have a preconfigured client that you can configure quickly for your service, create a provider wizard.  you can set default config options, even change field names.

-Eric

Francisco Guerreiro

unread,
Jun 3, 2011, 6:09:03 PM6/3/11
to csipsim...@googlegroups.com
how do you create a profile template?

agr...@gmail.com

unread,
Jun 3, 2011, 6:23:16 PM6/3/11
to CSipSimple Development
On Jun 4, 12:00 am, Eric tamme <eta...@gmail.com> wrote:
> 1. create a profile template witge whatever settings you want.  not every
> one uses srv records.

That's right, and a simple SRV lookup will reveal that. Doing such a
lookup will not harm anyone not using SRV records, but will improve UX
for people who (often not-knowingly) will.

> 2. field names are always subject to interpetation.  i personally think they
> are fine.

What about quick sanity checks, like preventing a user to enter
"m...@myserver.com@voip.myserver.com"? I mean, if it happens to one of
us, it will happen to someone else as well!?

> 3. outbound proxy works fine.  if you have an srv that points to a different
> domain, enable srv so that the route will match the actual proxy ... then it
> wont fail on preloaded route checking.  this is what i do.

The point is that Jon Doe (or my Mum) doesn't know about SRV. Why
would he/she enable it (especially taking into account that CSipSimple
has SRV disabled by default)?

> 4. you can disable contact rewrite.

Yes, in the expert mode. I already mentioned that we're working with
Kamailio guys to get this solved, so it'll work out-of-the-box with
pjsip based clients.

> personally i like the full configurability of csipsimple.  i dont like it
> when clients assume to much about how i want to use them.
>
> if you are trying to have a preconfigured client that you can configure
> quickly for your service, create a provider wizard.  you can set default
> config options, even change field names.

There might not be a difference between clients assuming (proper)
default configurations and clients allowing you to override things.
It's all about choosing sane default values. The points I've
mentioned, if configured properly, shouldn't even make you notice
there's a change in behavior. So why are you complaining upfront?

Andreas

Régis Montoya

unread,
Jun 4, 2011, 5:28:50 AM6/4/11
to csipsim...@googlegroups.com, agr...@gmail.com
I completely agree Eric analysis :

As for point 1 :
SRV lookup considerably slow down registration process. Besides, it
means that the application (CSipSimple) has to lookup DNS server in
android settings. This operation is hightly unsafe cause not all device
reflect DNS servers in android settings immediately after a change.
That's why DNS SRV has been disabled by default (it was enabled by
default some time, but due to users feedback, has been disabled). Trust
me that's better like that.
Besides as said by Eric, the wizard approach is there to address this
kind of issue.

Not all provider has same needs, nor same naming for things. That's why
wizard are there. Mainstream users should have a wizard for their service.
About how to create wizard, have a look to the code, that's really
really simple to do (see in wizard.impl package it's plenty of example,
and you can configure everything you want with that).
Besides another solution is to deploy by files with the save/restore
feature of CSipSimple and just provide your users a files to put on
sdcard. Then they just have to restore and that's it.

As for point 2 :
Again, user feedback. If you'd like to change translation for your
country you can go in launchpad and just contribute and improve the
translation if you think that does not fit exactly.
However two extremely important point :
Sip provider has always their own naming for things. The number of
feedback about username misunderstood is for now 2 people (you
including). The point I think is that you know about SIP ;). Besides in
wizard, things are usually more explicit like "phone number" or "login
name" or things like that.
Second very very important point. toto@domain IS NOT INVALID as
username. Some sip providers allow that as user part of username !!!! It
gives something like toto@domain@sipprovider.com. (with first @ encoded
properly obviously). So NO SANITY check on that cause that's just valid.
The only thing that could be done here is a more explicit label for guys
that knows about RFC (but if so, the expert wizard is there ;) ).

Point 3 :
pure wizard consideration. Again, the goal is to address mainstream
users. Not people that knows about RFC ;) . If some sip provider does
not works well with basic wizard, I create a wizard for this provider
(and even sometimes if it's not absolutely necessary).
With a wizard all this consideration are just useless. You have your
point of view based on how things are implemented on your network, but
keep in mind, SIP RFC are plenty of SHOULD and providers/impementors may
interprete things a very different way.
That's why I introduced this concept of wizard that solve all this kind
of problem. Mainstream users should never have to know about what is a
proxy. What they want and what they like in CSipSimple is the fact for
90% of them CSipSimple took 3 minutes to configure ! At least that what
I conclude from feedback I got ;)

Point 4 :
Wizard again :). The feature can be disabled from expert mode for geeks :).

To sum up the csipsimple approach is the following :
The goal is to address mainstream users. I want to keep things ultra
simple for these users.

* For expert users that knows about RFC, has their own SIP server or
want to spend long time on their SIP connection => the Expert wizard
* For other sip providers that are not yet in the list of available
sip providers, I just create a new wizard. That's extermely easy for me
and can be done in 5 minutes. Besides that's extremly tweakable. I can
create any field I want (even a server name field, some wizard has
that), name it as I'd like to name it, and set default option (even in
global options).
The goal is to allow users to not think about complex things. Just what
they use to be aware of : what the webinterface to admin their account
present. All other things are too much complicated and should never been
presented to a mainstream users.

Give me the settings you'd like to have automatically in your wizard,
and one day later, in the nightly build you'll have that in CSipSimple
and you'll see that it's much much more easier for your users to
configure using a wizard that any other complicated settings ;) (and
besides there is a fancy icon lol ;) ).

CSipSimple is opensource. It's made of users feedback. And your feedback
is very valuable and if you give me infos about how should be configured
for your service it will be done quickly and it will improve the
software for all your users. Good reaction with an opensource project is
to feedback and I really appreciate your feedback.

Let me know for the wizard you'd like me to add. ;)

Regards,
R�gis


Le 04/06/2011 00:23, agr...@sipwise.com a �crit :

agr...@gmail.com

unread,
Jun 8, 2011, 1:26:48 PM6/8/11
to CSipSimple Development
Hi Régis,

On Jun 4, 11:28 am, "Régis Montoya" <r3gis...@gmail.com> wrote:
> SRV lookup considerably slow down registration process. Besides, it
> means that the application (CSipSimple) has to lookup DNS server in
> android settings. This operation is hightly unsafe cause not all device
> reflect DNS servers in android settings immediately after a change.

Don't you need to use DNS for A lookups in 99% of the cases anyways? I
mean, you usually have SIP credentials like us...@domain.com, not
us...@1.2.3.4 - and CSipSimple already does an A lookup with the fqdn
you provide in the SIP server field. Probably a naive question, but
what's the difference from Androids security point of view whether
it's just an A lookup or an SRV followed by an A lookup?

> That's why DNS SRV has been disabled by default (it was enabled by
> default some time, but due to users feedback, has been disabled). Trust
> me that's better like that.

I remember an older version of CSipSimple I tried months ago where DNS
SRV was enabled by default, right, and I really appreciated it, so I
was a bit disappointed to have to go figure where to enable it again,
beside the fact that I needed to dig into SIP traces to find out that
the outbound proxy was being put into the initial Route header, which
is (at least in my case, but I guess in lots of others as well)
breaking initial loose-routing checks when the outbound proxy is
different from the domain.

I was already prepared to argue about DNS SRV when bringing this point
up, so I was mentioning the comparison with Email and DNS MX, where
nobody would even think about arguing about that. Just out of
curiosity: what was it that people complained about having SRV enabled
by default? If a record is there, then it's there for good reason. If
it's not there, just do the A lookup as usual.

> Besides as said by Eric, the wizard approach is there to address this
> kind of issue.

If this is the policy, then fine with me. I was just really curious
about WHY this has been changed.

> Sip provider has always their own naming for things. The number of
> feedback about username misunderstood is for now 2 people (you
> including). The point I think is that you know about SIP ;). Besides in
> wizard, things are usually more explicit like "phone number" or "login
> name" or things like that.

It's three now, had to hold a colleagues hand today in order to walk
him through the settings, he fell into the same trap. Probably it's
really just a naming issue and we might name things differently over
here and thus get confused. Going to look into this wizard for that
also. My only concern is that if every vendor and - probably on top -
also every provider creates its own profile, doesn't it get messy then
for the user to find the right one? A cool thing would be to be able
to point CSipSimple to an http(s) address where it fetches its profile
from. Is this something you've considered so far? Because e.g. with
latest kamailio, you've the xhttp module where you can - inside your
sip proxy config - define the handling for http(s) requests, where you
could even authenticate the provisioning request with the SIP
credentials out-of-the-box. So you don't even need a separate web
service for that, you just serve the settings (which would otherwise
go into the wizard profile) statically from within your sip proxy.

> Second very very important point. toto@domain IS NOT INVALID as
> username. Some sip providers allow that as user part of username !!!! It
> gives something like toto@dom...@sipprovider.com. (with first @ encoded
> properly obviously). So NO SANITY check on that cause that's just valid.
> The only thing that could be done here is a more explicit label for guys
> that knows about RFC (but if so, the expert wizard is there ;) ).

Got that point. The dangerous thing which caused this issue is that we
were using the basic wizard, knowing that our sip service was running
on sip.mydomain.com, whereas the AoR for the subscriber was
us...@mydomain.com. Not knowing about DNS SRV (I mean, who really knows
except VoIP engineers?) probably leads to this usability issue then.

Point 4 has been addressed as a bug fix in Kamailio in the meanwhile
btw., so at least for me and all the other Kamailio users out there,
it's no more considered as a problem when running the latest version.

> Give me the settings you'd like to have automatically in your wizard,
> and one day later, in the nightly build you'll have that in CSipSimple
> and you'll see that it's much much more easier for your users to
> configure using a wizard that any other complicated settings ;) (and
> besides there is a fancy icon lol ;) ).

Great, I gonna send you the details off-list. If you consider at some
point implementing a remote-provisioning feature also, I'd be happy to
assist on the server side.

Andreas

Régis Montoya

unread,
Jun 8, 2011, 3:18:16 PM6/8/11
to csipsim...@googlegroups.com, agr...@gmail.com
Hi,

Le 08/06/2011 19:26, agr...@sipwise.com a �crit :
> Hi R�gis,


>
>
> Don't you need to use DNS for A lookups in 99% of the cases anyways? I
> mean, you usually have SIP credentials like us...@domain.com, not
> us...@1.2.3.4 - and CSipSimple already does an A lookup with the fqdn
> you provide in the SIP server field. Probably a naive question, but
> what's the difference from Androids security point of view whether
> it's just an A lookup or an SRV followed by an A lookup?

In fact I was meaning unsafe in terms of reliablity not in terms of
security ;). (Sorry my english is far to be perfect yet ;) ).
But the point is that the A lookup is done using a C api. It is very
reliable and does not require to be aware of the DNS server IP. (the
resolution is made by the C api).
To do resolution of SRV records, the pjsip stack need to know the IP of
the DNS servers and will build and send DNS request by its own (opening
a socket and so on).
In fact this is the unreliable point. To know about the DNS servers each
platform portage need to provide pjsip the DNS servers IP. In the
android portage, the way to do so is to use android "props" (the getprop
tool). The problem of this tool is that on some device it is
unfortunately not stable enough to be reliable. On recent device that's
fine, but it broke completly things for users that have an incompatible
device.
In this kind of case I try to choose the thing that impact less most users.
Since the wizard approach allow to solve case where DNS SRV resolution
is required (which is as far as I can tell not the biggest part of the
current state). The choose was made to disable DNS SRV by default and
activate it in wizard when required.
Besides SRV resolution slow down the registration at startup of the app
(on android 1.5 it is very significant).
And since CSipSimple integrate seamlessly to the stock dialer and try to
register to check whether current connection can reach server, speed of
startup and registration is a critical point.

However, I agree with the fact a sip client should have that enabled by
default if the feature does not impact users usage. But for android
target for now it's probably not a good idea. But maybe in the future
when 2.3 and 3.0 will be used by most people, it is probably something
to reconsider.

>> That's why DNS SRV has been disabled by default (it was enabled by
>> default some time, but due to users feedback, has been disabled). Trust
>> me that's better like that.
> I remember an older version of CSipSimple I tried months ago where DNS
> SRV was enabled by default, right, and I really appreciated it, so I
> was a bit disappointed to have to go figure where to enable it again,
> beside the fact that I needed to dig into SIP traces to find out that
> the outbound proxy was being put into the initial Route header, which
> is (at least in my case, but I guess in lots of others as well)
> breaking initial loose-routing checks when the outbound proxy is
> different from the domain.
>
> I was already prepared to argue about DNS SRV when bringing this point
> up, so I was mentioning the comparison with Email and DNS MX, where
> nobody would even think about arguing about that. Just out of
> curiosity: what was it that people complained about having SRV enabled
> by default? If a record is there, then it's there for good reason. If
> it's not there, just do the A lookup as usual.

Yeah I agree, with that. I try to have a pragmatic approach on that point.
That's a little bit the opposite of the spirit of pjsip that usually try
to force compliance with RFC and with the clean way ;). As I said, we
will probably reconsider that point later when will be sure that android
manage correctly DNS entries in android props. Besides another point
that could make default setting change is the fact that more providers
adopt that. (if so - I mean with a DNS SRV entry - pjsip will even
resolve quicker than stock DNS resolution ;) ). But for now from what I
can see, that's a little bit like SRV entries for XMPP servers... it
exists but few providers has the feature :S


> If this is the policy, then fine with me. I was just really curious
> about WHY this has been changed.

Ok, I understand :). All the more if you tested a version with DNS SRV
resolution enabled by default ;). I understand that you where
disappointed then. In this case, do not hesitate to feedback.
And yes the wizard is the solution I use to choose for this case of
case. Default settings are always a source of headache for me. And this
topic is not the more complicated (audio settings are worse ;) ).

>> Sip provider has always their own naming for things. The number of
>> feedback about username misunderstood is for now 2 people (you
>> including). The point I think is that you know about SIP ;). Besides in
>> wizard, things are usually more explicit like "phone number" or "login
>> name" or things like that.
> It's three now, had to hold a colleagues hand today in order to walk
> him through the settings, he fell into the same trap. Probably it's
> really just a naming issue and we might name things differently over
> here and thus get confused. Going to look into this wizard for that
> also. My only concern is that if every vendor and - probably on top -
> also every provider creates its own profile, doesn't it get messy then
> for the user to find the right one?

I hope not :).
For now the wizard should address :
* SIP providers for mainstream users
* Type of SIP servers.
* Generic usage

As for SIP providers for mainstream users, each one has to choose
countries it applies to or worldwide. So it should reduce number of
wizard displayed per users by hidding those not relevant for the current
device locale.
As for type of SIP servers it is located in worldwide provider (or maybe
should be in Generic section ... it depends on number on worldwide section).

Besides, CSipSimple make things easier to rebrand the app (one file to
change and one refactor action in eclipse to do).
It allow third party to rebrand the app a very easy way (provided the
fact they respect the GPL license terms), and so solve the case of a sip
provider that would like to address only their users, and also your case.
I guess if you really want to provide / advise a sip app to your
customers, you should consider rebrand the app with different default
settings that suit better with servers you deploy. (You could even
provider your clients an automatic build of CSipSimple rebranded for
their need - and even better that you could host on your sip servers ;) ).

I have absolutely no problem with that provided the fact it remains
under GPL license.
Unlike other proprietary app my goal is users ! And as consequence I'm
open to this kind of redistribution of the app. (and even, that's not
necessarily the approach of some other opensource sip app on android ;) ).
I believe in the fact the most sip provider will rebrand and reuse the
app, the most likely they will contribute the project and ensure the
future of the app (always bad to only rely on few developpers that do
that only on their own time... even if I really take care of this
project for now).

The ultimate thing could be to have a binary of csipsimple automatically
generated with correct settings on opensource sip servers as an apk that
could be downloaded by users accessing http://sipserver.com/android/ for
example. Then users will only have to download the app and enter their
username and password as communicated by their IT.
But well, CSipSimple has to make a lot of progresses on stability before
thinking about that ;).

> A cool thing would be to be able
> to point CSipSimple to an http(s) address where it fetches its profile
> from. Is this something you've considered so far? Because e.g. with
> latest kamailio, you've the xhttp module where you can - inside your
> sip proxy config - define the handling for http(s) requests, where you
> could even authenticate the provisioning request with the SIP
> credentials out-of-the-box. So you don't even need a separate web
> service for that, you just serve the settings (which would otherwise
> go into the wizard profile) statically from within your sip proxy.

Yeah, that's also something I'm currently thinking about.
I don't know if you already had a look to the samurai API of Sipgate
(there is a complete API based on RPC https requests). I discovered that
two days ago. I think that I will implement that in csipsimple. I didn't
know about the fact kamalio also has it. That's a good news :).

I have to rework a little bit things to store different credentials than
the one required for pure SIP to allow that, but that's something that
will land soon in CSipSimple.
If you have some docs about the xhttp module it will be welcome (will
save me a google search ;) ).

The API of sipgate also allow to get credits and other interesting stuff
(I'll at least add balance feature in the sipgate wizard).

>> Second very very important point. toto@domain IS NOT INVALID as
>> username. Some sip providers allow that as user part of username !!!! It
>> gives something like toto@dom...@sipprovider.com. (with first @ encoded
>> properly obviously). So NO SANITY check on that cause that's just valid.
>> The only thing that could be done here is a more explicit label for guys
>> that knows about RFC (but if so, the expert wizard is there ;) ).
> Got that point. The dangerous thing which caused this issue is that we
> were using the basic wizard, knowing that our sip service was running
> on sip.mydomain.com, whereas the AoR for the subscriber was
> us...@mydomain.com. Not knowing about DNS SRV (I mean, who really knows
> except VoIP engineers?) probably leads to this usability issue then.

Yes. Probably the label (at least in dialog) should be more precise.
I've just changed that in the trunk. It will take a little bit time to
have it translated back from launchpad.

> Point 4 has been addressed as a bug fix in Kamailio in the meanwhile
> btw., so at least for me and all the other Kamailio users out there,
> it's no more considered as a problem when running the latest version.

Excellent news ! =)
I think that pjsip guys will be pleased with that too cause was
something really annoying when using pjsip with default settings.

>
>> Give me the settings you'd like to have automatically in your wizard,
>> and one day later, in the nightly build you'll have that in CSipSimple
>> and you'll see that it's much much more easier for your users to
>> configure using a wizard that any other complicated settings ;) (and
>> besides there is a fancy icon lol ;) ).
> Great, I gonna send you the details off-list. If you consider at some
> point implementing a remote-provisioning feature also, I'd be happy to
> assist on the server side.

Cool, thanks !


Reply all
Reply to author
Forward
0 new messages