Auto-Answer

[GoogleCodeExporter]

This is an enhancement request, with the intention of providing better Google 
Voice integration. Allow the SIP client to automatically answer phone calls 
from one (or more?) phone numbers when the screen is on. This will enable 
integration with apps like GV Dialer that allow your outgoing calls to ring 
back any phone # (including SIP ones!) on the Android device. Currently you 
have to answer the incoming callback manually.

I think this is fairly low priority, but it would be a nice feature to have.

Original issue reported on code.google.com by kni...@gmail.com on 6 Sep 2010 at 3:34

[GoogleCodeExporter]

There is already an API in the current app to provide this kind of stuff. 
I've already made another app for a POC that relies on CSipSimple and ask 
CSipSimple to autoanswer when a click is made in this app (this app call a 
webservice on a pbx that callback using SIP). 
However it relies on a non standard API (I quickly did it only for my proof of 
concept). AFAIK, there is no standard API for that. But I guess that we could, 
at least opensource project (csipsimple, sipdroid, linphone), agree on an 
"intent" (that's a sort of API) so that other apps could ask for auto-answer 
next call.

So this is the first part of the technical solution that can be provided.

There is another one, that can be added in CSipSimple. There is already a 
powerful rewriting / filter engine. It could be simple to add to this engine 
"auto-answer" rules. It should match this feature request too.

> So to sum up on this issue : 
1- Public api for auto-answer mode for next call that must be provided to other 
apps
2- Add auto-answer rules in "Filters" module.

Original comment by r3gis...@gmail.com on 6 Sep 2010 at 3:52

• Changed state: Accepted
• Added labels: Priority-Low, Type-Enhancement
• Removed labels: Priority-Medium, Type-Defect

[GoogleCodeExporter]

I know sipdroid has auto-answer functionality, though it does not filter by 
number. So you may be able to utilize that. There is actually a similar issue 
on sipdroid that provides a very hackish patch for filtering its auto-answer by 
number: http://code.google.com/p/sipdroid/issues/detail?id=189

Original comment by kni...@gmail.com on 6 Sep 2010 at 3:55

[GoogleCodeExporter]

Ok, but I think that integrated to filters module will be much more powerful 
than the sipdroid feature. All the more so as I have already quietly everything 
done and that's per account. Beside I've already the auto-answer mechanism 
since it works with an API for now. I've just to plug already existing filters 
into already existing auto-answer feature ;).

With the implementation I mentioned, you'll be able to auto-allow a domain, a 
specific user, or based on a custom regexp. 

Original comment by r3gis...@gmail.com on 6 Sep 2010 at 4:35

[GoogleCodeExporter]

Well, point 2 will be integrated in next build :). 
Was easy to do... so done on my dev branch. (just an icon to add to finalize it 
;) ). I'll try to push a build in a couple of hour. I'll keep you in touch to 
test the feature.

For now, it don't pop up the "in call" screen when auto-answer (it only show 
the notification of an ongoing call in the task bar... maybe I'll add an option 
to tweak this behavior). However, by clicking the entry in the notification bar 
you'll still access the "in call" screen.

Original comment by r3gis...@gmail.com on 6 Sep 2010 at 5:26

• Changed state: Started

[GoogleCodeExporter]

http://code.google.com/p/csipsimple/downloads/detail?name=CSipSimple_0.00-12-29.
apk include the auto answer feature included in filters rules.
To install follow wiki : HowToInstallDevVersion .

Then to test the feature : 
Menu > Accounts > Choose the account on which you want auto answer.
You are now on the account editor. Menu > Filters > Add a filter/rewriting rule.
You are now on the filter edition rule
On the first drop down select "Auto answer"
On the second drop down :

Assuming caller call you with <01112@domain.loc> 

* you can for example choose "starts with" and enter "01112" in the field.
* you can also choose to auto respond to the domain, so choose "ends with" and 
write "domain.loc" in the field.
* you can also choose "exact" matching => Choose exact and write 
"01112@domain.loc"
(Note if the callee doesn't announce domain (for example "<test>" you should 
enter exactly "<test>" (note the < and > are important in this case !)
*If you want to configure this account to always auto answer, choose custom 
regexp and in the field enter ".*" (it's the regexp that match whatever caller 
is).

Original comment by r3gis...@gmail.com on 6 Sep 2010 at 8:04

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Alright, after some more testing it appears the auto-answer feature works when 
CSipSimple is actually running. It seems to de-register from PBXes every time I 
open it from either the ongoing notification menu or the app drawer.

When I could get it to work, it did not automatically switch to the SIP call 
screen. It called in the background, if you will. And of course clicking on the 
notification for call in progress takes you to the screen, but forces the 
program to re-register due to bug mentioned in the first paragraph.

Specs: rooted Droid Incredible running SkyRaider 2.5.2.

Original comment by kni...@gmail.com on 7 Sep 2010 at 1:19

[GoogleCodeExporter]

> When I could get it to work, it did not automatically switch to the SIP call 
screen. It called in the background, if you will

Indeed, see my comment 4 second paragraph I explain it.

For the other bug that's strange. BTW, re-registration itself not so important. 
I mean, it's painless. Would be more annoying if it restarts the sip stack... 
After you open the in call screen, are you still able to clear call? If so, 
it's just a simple re-registration and it has no real impact for the user.

Another question, what are your settings regarding connectivity :
Have you set CSipSimple :
If you used the "easy configuration" : is it the option "Always available"? 
"Available on Wifi" or Just for outgoing calls?
If you used the network configuration are wifi and 3G ticked for incoming and 
outgoing? and is Wifi lock ticked?

Original comment by r3gis...@gmail.com on 7 Sep 2010 at 2:18

[GoogleCodeExporter]

Ah yes, did not notice the part about the call screen. It appears to be 
restarting the entire SIP stack, as it's dropping the call when I switch to the 
call screen. It was over 3G using TCP to connect to PBXes. Wifi and 3G were 
enabled for both incoming and outgoing. Wifi lock is not set, but I do have the 
wifi sleep policy set to never. I don't connect to the wifi at work though, so 
all of this testing was entirely over 3G.

Original comment by kni...@gmail.com on 7 Sep 2010 at 2:28

[GoogleCodeExporter]

Ok so would be really interested by logs since I'm not able to test over 3G in 
France :(...

Original comment by r3gis...@gmail.com on 7 Sep 2010 at 2:48

[GoogleCodeExporter]

I will try to test it again later and then gather the logs. It seems the 
CSipSimple logs have disappeared out of the system log by this point.

Original comment by kni...@gmail.com on 7 Sep 2010 at 2:51

[GoogleCodeExporter]

http://code.google.com/p/csipsimple/wiki/HowToCollectLogs << follow this 
tutorial, there is a setting to set to activate logs.

Thanks !!

Original comment by r3gis...@gmail.com on 7 Sep 2010 at 3:10

[GoogleCodeExporter]

I sent the log to you in an email.

Original comment by kni...@gmail.com on 8 Sep 2010 at 12:35

[GoogleCodeExporter]

I should also note that after testing, this problem only seemed to occur on 3G, 
not WiFi.

Original comment by kni...@gmail.com on 9 Sep 2010 at 12:34

[GoogleCodeExporter]

Ok sorry I didn't reply, but thanks to your log I found something that is not 
clean when using 3G. In fact I restart the sip stack - which cut any call when 
there is a change in data connection.
For many reason it is needed... unless while in call. So, I'm modifying it and 
will provide you something to test soon.

Original comment by r3gis...@gmail.com on 9 Sep 2010 at 1:03

[GoogleCodeExporter]

Does the latest build (32) have any changes to the code that might fix the 3G 
problem?

Original comment by kni...@gmail.com on 16 Sep 2010 at 11:42

[GoogleCodeExporter]

If you're running 31 no changes about 3g. In 33 (I'll try to get time to push 
it today) there's something that should improve re-registration but not tested 
on 3g.

Original comment by r3gis...@gmail.com on 17 Sep 2010 at 3:52

[GoogleCodeExporter]

I have tested this on build 32 over 3G. Person on the other end said my voice 
was static-sounding, but that might be expected because of 3G. However, the 
call did not drop.

Original comment by kni...@gmail.com on 26 Sep 2010 at 5:36

[GoogleCodeExporter]

As for initial issue, fixed.
For static sound maybe last -13-02 helps - or it's maybe because network 
doesn't give enough bandwidth.

Original comment by r3gis...@gmail.com on 3 Oct 2010 at 9:25

• Changed state: Fixed