Add option to apply filterings rules to csipsimple dialer

[GoogleCodeExporter]

What steps will reproduce the problem?

SIP account CWU 
Filter: Can't Call; Has exactly N digit; 1 
Dialer: CWU selected; dial '1' ; call proceeds to SIP provider 
Call Log: <sip:1@sip.callwithus.com> 2 mins ago

I've tried everything - Custom Regex, matching the SIP address instead of the 
number, etc etc. 

What is the expected output? What do you see instead?

Ideally, I'd like the filter rewrite rules to rewrite something.  ;-)

What version of the product are you using? On what operating system?

Versions tried: 0.3.0, 0.3.1, nightly r1157 

Please provide any additional information below.

Of course blocking calls to single-digit numbers was not my intention.  It was 
just the simplest proof of failure I could provide.

None of the following modify 1234567 or 2501234567 and
replace it with 12501234567, as expected, (hoped, or prayed)

Rewrite; Custom RegExp; ^[0-9]{7}$ ; Prefix by 1250

Rewrite; Starts with; 250; Replace match by; 1250

Rewrite; Stars with; <sip:250; Replace match by; <sip:1250

Rewrite; Stars with; sip:250; Replace match by; sip:1250

Also this doesn't prevent calling 1234567 - the dialer
happily proceeds with the "filtered" SIP account.

Filter: Can't Call; Has exactly N digit; 7 

What I find amazing is that there are many people reporting
other problems with the filter system other than failure to
match / rewrite numbers... so the evidence would say that
other users are actually getting this to work somehow, though
how that is has me completely baffled...?

Original issue reported on code.google.com by w.bar...@gmail.com on 21 Dec 2011 at 8:33

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Are you using csipsimple dialer?
If so what you observe is just absolutely normal.

Filters are about what comes from outside. If you use csipsimple dialer, you 
know what you are doing and there is no reason why the app should rewrite or 
prevent you from making a call.

The filters are about numbers that comes from outside : from contacts or from 
an outgoing call from stock phone dialer.

So if you make a call from *stock* dialer, you'll see the effect of 
filters/rewriting rules.

I always advise to use your phone as you used to do previously and to not use 
csipsimple dialer unless you want to place a manual sip call or bypass 
filtering rules.

I did a big effort on android integration so that you can still use the android 
dialer and contact app. Filters are here to improve this integration, and 
automatically add rules when you place a call from these apps. It does not 
actually make sense to rewrite phone number if you dial from csipsimple cause 
you are in the context to do a sip call, so you know what you are typing and 
you know what you'd like the app to dial. Filtering/rewriting rules are only 
useful if there is a potential clever choice to be done by the application and 
if the application consider that where you dialed you didn't yet know what you 
want to use to make the call.

Original comment by r3gis...@gmail.com on 21 Dec 2011 at 9:38

• Changed state: Invalid

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Aha, and at last now I think I understand what you mean by "outside"

Okay, so the filtering rules ONLY affect the Mobile dialer.  If I want to use 
filtering against numbers in the CSipSimple Call Log I am out of luck, and if I 
want to use the CSipSimple dialer as the default dialer I am out of luck.  
That's a shame, because it's so much better than the LG-Supplied dialer.

Original comment by w.bar...@gmail.com on 21 Dec 2011 at 10:21

[GoogleCodeExporter]

Yes :)

For now the feature to rewrite in call logs is not available. You can track 
this issue : http://code.google.com/p/csipsimple/issues/detail?id=184
It's a very old issue :). I would like to have this rules deduced automatically 
from rules you write for the outgoing way. But that's not so simple because 
there is not necessarily a bijection in a rewriting rule.

For the point to use csipsimple dialer as main dialer, the way to use it is 
slightly different than the way to use your mobile dialer.
In fact there is no extra step in this case. What you type is what will be 
dialed. You can notice that on csipsimple dialer you have a little button on 
the right. This button allow you to choose the account you want to use for this 
call. So when you type a phone number you should be aware of the account you 
will use for this call and so apply by yourself the rewriting rule. 
The problem if I apply filtering rules here is that you will not be able to 
force a call using a sip account if there is filtering rules that goes against 
what you are trying to do. You should consider the csipsimple dialer as 
something to "force" a sip call. In this case you force the sip number (or sip 
text uri) you want to call.

You can notice that if you switch to text dialer (the little buddy icon on the 
left) you'll see the list of the contact. If you select one user and press one 
phone number from this user, you'll see that in this case, the phone number 
will be modified if there is a rewriting rule, but it will not directly make 
the call, it will allow you to review the phone number.

The idea of csipsimple dialer is to allow you to make "raw" sip calls : at this 
point you should not expect some clever thing. 
The idea of the mobile dialer is to allow you to make calls... at this point 
you can expect csipsimple to be clever and to propose to rewrite or force call 
path to use some pre-defined sip account.

If you don't like the LG supplied dialer, you should consider install another 
dialer. CSipSimple will integrate as well in this third party dialer. And maybe 
this dialer will be even better than csipsimple's one :). But the goal of 
csipsimple is not to be a dialer, but to allow you to place sip calls. So I do 
not target in making a perfect dialer. I just target in making some great 
integration in the android OS and as a fallback use csipsimple dialer if you 
want to explicitely do a sip call.
By the way, if there is some perfect third party dialer or something that you 
just prefer as an alternate dialer, you will still be allowed ot use csipsimple.
I think that an application should focus of what is its own purpose and not try 
to add features that are out of its scope. In our case I think that android os 
has a good conception to allow applications to interoperate (that's not the 
case of iPhone for example). So if some thing can be delegated to another 
application it should be. 
First releases of csipsimple didn't included contact list because I considered 
that this is not the role of csipsimple to list contacts. The android app is 
much better for this point and it evolves at each android release and 
manufacturers sometimes add features. 
I did the addition because there were some use cases where the contact list is 
needed (if you don't want the app to integrate mobile dialer for example).
But for rewriting rules, this is only something how the stock mobile / contact 
app will provide phone number to the sip application.

So my point is that if lg dialer is not good enough to make regular calls you 
should search for another third party dialer. There is very good ones that 
autocomplete with your contacts based on T9 for example. If I start to say that 
csipsimple dialer should be used to replace your mobile dialer or any other 
dialer, it would mean that I should accept all features request about all 
android manufacturers dialer. And that's not what I should focus on. I should 
focus on having a great integration with third party application (the stock 
mobile dialer, but also other third party dialer), and in making sip feature 
great ;).

However, about the fact fitlering rules does not work on call logs, I 
completely agree that's a bug on csipsimple side and is part of the features 
that should be managed by csipsimple and issue 184 is about this point. It's a 
little bit complicated to manage but that's something that should be done 
allowed in csipsimple. Maybe at least for basic rewriting rules such as start 
with, or maybe as aditional rules "revert rewriting" for example.

I hope it clarify my position on this feature of rewriting rule. 
I agree that it ~could~ be integrated to csipsimple dialer (all the more so as 
it should not be too hard), but making coffee could also be ;). Well, maybe it 
could be added as an option not activated by default and that users that really 
want to use csipsimple dialer as main dialer could use (and also I should put a 
warning about the fact you'll not be able to place raw sip calls bypassing 
rules then).

Original comment by r3gis...@gmail.com on 21 Dec 2011 at 10:48

[GoogleCodeExporter]

Aha, I read all of this and I can say I have a simple solution at least for 
power users... and that is...

Add a config option in Expert Mode
(o) Enable Filtering in CSipSimple Dialer [ Default off ]

Because I can overcome any and all problems with the RegExp features if I can 
only use it!  ;-)

Original comment by w.bar...@gmail.com on 21 Dec 2011 at 10:57

[GoogleCodeExporter]

BTW, the CSipSimple Dialer beats every dialer I have seen, I love it, for all 
the reasons you have outlined above.  The only thing that it misses is the 
filtering, and if someone is crazy enough to write a filter rule which prevents 
them from typing a standard SIP address, I say let them suffer with it!

After all they can set up their same SIP account twice - once with the rules 
and once without, and have 2 SIP provider icons for the same account, lol.  
Yes, I know, that is very evil indeed...

Original comment by w.bar...@gmail.com on 21 Dec 2011 at 11:00

[GoogleCodeExporter]

:) Well accepted as enhancement issue so.

Original comment by r3gis...@gmail.com on 21 Dec 2011 at 11:57

• Changed title: Add option to apply filterings rules to csipsimple dialer
• Changed state: Accepted
• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Gracias!

After 3 days with your dialer in text mode I couldn't go back to anything 
else... dialing plan or not. :)

Original comment by w.bar...@gmail.com on 21 Dec 2011 at 12:54

[GoogleCodeExporter]

Glad I found this issue. I was pulling out my hair as well, trying to get a 
rewrite rule to work with the CSS dialer. [SIP provider CallWithUs doesn't 
support NA 10 digit dialing - my first few call attempts ended up in Malaysia 
instead of Vancouver :-)]

You can count me as someone else who would really appreciate this enhancement.

Original comment by jbr...@gmail.com on 16 Feb 2012 at 11:27

[GoogleCodeExporter]

Issue 2041 has been merged into this issue.

Original comment by r3gis...@gmail.com on 28 Oct 2012 at 2:26

[GoogleCodeExporter]

I would like to add my voice for adding this as a feature.

It is a real shame that filtering isn't working with the css dialer. I have 
tried to use it to "auto-answer" calls for one of my sip accounts (select 
"AutoAnswer" on "All" incoming calls), but it doesn't work at all.

As others already pointed out, I am not using the native dialler, so having 
this feature is very important. Are there any plans in reality that this will 
be added soon?

Original comment by mia.v...@googlemail.com on 11 Oct 2013 at 1:06

[GoogleCodeExporter]

@mia : auto answer should work. It does not depend of the dialer *at all* ! So 
it works for all SIP incoming calls :)

Regarding the post you sent on another issue you are building your own version 
of the app and there is something that you introduced manually by changing 
something in code that makes some features based on settings not working. 
Please, test the core app first, before reporting bug. And if you need help on 
your version do not hesitate to join and post csipsimple-dev google group which 
is the perfect place for the open community of csipsimple people interested in 
development :)

Then about the filtering integration in css dialer, it's indeed a good idea to 
add that. But that's not yet done (lack of time). Do not hesitate to contribute 
source code if you have something :)

Original comment by r3gis...@gmail.com on 11 Oct 2013 at 3:28

[GoogleCodeExporter]

@regis: unfortunately, the auto-answer filter does not work and it is why I 
added this comment above. It does not work even with the "vanilla" version. 
Don't know whether the message below is related or not, but this is what I get 
in when the phone rings (and auto-answer does not kick in):

I/ActivityManager(  564): Starting: Intent { 
act=com.csipsimple.phone.action.INCALL flg=0x30000000 
cmp=com.csipsimple/.ui.incall.InCallActivity (has extras) } from pid 2618
W/ActivityManager(  564): Activity pause timeout for HistoryRecord{404fcb80 
com.csipsimple/.ui.incall.InCallActivity}
E/dalvikvm( 2618): Could not find class 
'com.actionbarsherlock.internal.utils.Utility16', referenced from method 
com.actionbarsherlock.internal.utils.UtilityWrapper.getInstance
W/dalvikvm( 2618): VFY: unable to resolve new-instance 764 
(Lcom/actionbarsherlock/internal/utils/Utility16;) in 
Lcom/actionbarsherlock/internal/utils/UtilityWrapper;
D/dalvikvm( 2618): VFY: replacing opcode 0x22 at 0x000a
D/dalvikvm( 2618): VFY: dead code 0x000c-0010 in 
Lcom/actionbarsherlock/internal/utils/UtilityWrapper;.getInstance 
()Lcom/actionbarsherlock/internal/utils/UtilityWrapper;

Any ideas?

Original comment by mia.v...@googlemail.com on 12 Oct 2013 at 1:30

[GoogleCodeExporter]

Mmmmh the log is not normal.
By "vanilla" version do you mean one installed from : 
http://nightlies.csipsimple.com/trunk/CSipSimple-latest-trunk.apk ? or one 
built on your side from code checkout ? (my main concern is potentials problem 
with a code obfuscator like proguard that you might have enabled without taking 
care... would explain all problems you have too)

If the nightly build, can you collect logs as indicated here : 
http://code.google.com/p/csipsimple/wiki/HowToCollectLogs

Original comment by r3gis...@gmail.com on 12 Oct 2013 at 2:53

[GoogleCodeExporter]

First and foremost, this application is just great. I am very grateful for all 
your effort. Really appreciated. Now it's working almost fine, but for me the 
few quirks I've found do not reduce its value. They are just normal through a 
regular software development process. Will still check if they are already 
reported in other issues.

I also would like to add my voice for adding this as a feature.

Furthermore, I strongly suggest that the "UsingFilters" section is promptly 
updated with a very large, clear and appealing "warning", as a first paragraph 
on the Introduction section. And here is why.

I tried a lot of rewrite, config, reconfig, install, log, reproduce, and 
whatever to make rewrite rules work. In short, many days of trial and error.

After almost throwing my own phone through the window (the one inside my 
computer screen, I mean), trying to make this app work with rewrite rules, I 
found this nice but too discrete text:

"Filters are applied when the application's "outgoing call chooser" appears:"
Here: http://code.google.com/p/csipsimple/wiki/UsingFilters

The main point is: most likely, a new user WILL NOT read this thing and 
properly understand what it means. At least I could not grasp it after reading 
a few times. Then, accidentaly I've found the integration checkbox and 
everything worked just fine.

However, most users don't wait that long. They try some times, don't succeed 
and move on.

They just don't know the difference between the csipsimple dialer and the 
regular dialer. Just as me, a few hours ago. And come on, it would be a shame 
to loose users just because this minor detail is not clear for us.

Here is my suggestion for this warning. As sort, direct and clear as it can be.

"WARNING: currently, rewriting rules works ONLY for calls typed using the 
REGULAR PHONE DIALER. They WILL NOT WORK on the csipsimple dialer: this one is 
meant mainly for RAW SIP calls. If you want this as a feature, please check 
issue 1448."

By the way, a link to this issue on the last word of this warning would be nice.

Regards,
Paulo

Original comment by paulo.ab...@gmail.com on 28 Oct 2013 at 3:53

[GoogleCodeExporter]

@regis: Some good news and some not very good news! I think I found what is 
causing the filter I set up not to be triggered (the problem I described 
previously), but first, a bit of background.

I have numerous (over 6) accounts active at any one time - they are all a 
healthy mixture of TLS, TCP and UDP connectors. Now, when I have my phone 
"homed" (understand plugged in via usb to my PC at work), my private sip 
accounts go through a different route (not through the corporate network, but 
my own private vpn, which hooks up to my PC at home), while the rest still goes 
via the corporate net - in the clear so to speak.

Also, with this setup I experience no issues with 
connecting/registering/retrieving mail and so on on any of the accounts, 
whether "private" or otherwise (just in case you think that is a connectivity 
issue).

Now, when I set up a filter as I described in one of my previous posts on this 
thread (Autoanswer on "all") and I am called on one of my (test) private 
accounts (the one which goes via my private vpn), the filter is NOT triggered. 

That was very annoying until I realised what is actually happening - for some 
reason CSS is showing me that the call which was just received (the one which 
did not trigger the filter) was, apparently, destined to one of my *OTHER* 
accounts, which go via the corporate net (in the clear).

This is of course pure nonsense, because the number/address called was the one 
I placed my filter on and belongs to my private test account.

This is the reason why CSS is not triggering the filter - it thinks that the 
"ringing" is for another one of my accounts (which is also active at the time 
and which does not have such filter set up) and not the one actually called 
(which has the autoanswer filter set up).

Any ideas Regis - what could be the cause of this and how can I fix it?

Original comment by mia.v...@googlemail.com on 8 Nov 2013 at 11:56

[GoogleCodeExporter]

@mia : the sip stack could detect the incoming call as unknown account in some 
very valid case. 

The fact the sip server calls announces a target of the call ('to' sip header) 
as somebody not found in list accounts configured is usually due to some 
problem in the configuration. 
We can try to debug that outside of this thread if you send me logs of your 
situation (with an incoming call detected as coming from another account). But 
it's something that I've already seen numerous times. And was always a problem 
with a server sending an INVITE on something that could not be linked to an 
account configuration. (For example sip server adding in the 'to' prefix to the 
account username, a different domain, etc etc).

Original comment by r3gis...@gmail.com on 9 Nov 2013 at 1:53

[GoogleCodeExporter]

@regis: I couldn't figure out your email address, so I sent it to 
developers@csipsimple.com (the email address indicated on the main CSS page). 
Let me know if you need anything else from me.

Original comment by mia.v...@googlemail.com on 16 Nov 2013 at 5:05

[GoogleCodeExporter]

Hello,

just to add a good reason to have rewrite rules apply also to the csipsimple 
dialer. Or at least a way (maybe a checkbox?) to turn rules on/off specifically 
for the scipsimple dialer.

A few days ago I installed this application into a Motorola Xoom tablet. It is 
a hardware version without SIM card. Hence, it's a plain tablet, not a cell 
phone. There is absolutely no native dialer, because the device was *not* 
designed to make phone calls.

However, it's Android, has a microphone, speakers and wireless. Everything 
which was necessary for SIP/VOIP to work. And so it did. I'm glad, because 
csipsimple worked like a charm. I mean, my network has a huge delay, so the lag 
was awful. But that was not csipsimple fault.

Now, considering I don't have a native dialer, I just cannot take advantage of 
csipsimple rewriting rules. They became utterly useless, since this environment 
(xoom) has no way to kick them in, when I need to make a SIP call.

I understand the point about having a way to make plain SIP calls without 
rewriting. That is ok. But I do think that there are distinct users with 
different needs. Hence, we should be able to choose what we want.

Sounds reasonable? In case I can help (e.g. testing?), please let me know.

By the way, thanks again for such a great app.

Regards,
Paulo

Original comment by paulo.ab...@gmail.com on 16 Nov 2013 at 9:06

[GoogleCodeExporter]

Hi there,

CSipSimple is hands down the best Sip app that I have tried (and I have tried a 
lot!).

It is also one of the few/best: dial & text apps (all in one) out there.

I realize that CSipSimple was designed not to be the "main" dialer....but its 
the best one I found.

I as well request an option that allows me to filter directly from the 
CSipSimple Dialer.

BTW, the CSipSimple filtering works great with the 3rd part dialers.

Original comment by scop...@gmail.com on 23 Feb 2014 at 7:13

[GoogleCodeExporter]

This issue was closed by revision r2387.

Original comment by r3gis...@gmail.com on 30 Mar 2014 at 5:54

• Changed state: Fixed