Sanjivkumarroshan / csipsimple

Automatically exported from code.google.com/p/csipsimple
0 stars 0 forks source link

When receiving incoming calls, both native phone app and csipsimple pop up #2201

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Use CSipSimple with integration
2.Receive incoming call

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

I expected only CSipSimple's incoming call window to pop up but instead I get:

1. CSipSimple's window
2. After about 2 seconds the native incoming call window pops up on top of 
CSipSimple's

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

I'm using the latest version in the play store (looks like 0.04-04 r1916).
Android 4.2.1
Nexus 4

Please provide any additional information below.

I tried a lot of settings and filters and nothing seems to work.

- checking "mobile phone integration - force" didn't help
- adding filter to "use mobile" of "stop processing" - "all" did not work either

(Note: I do have Google Voice set to forward calls to my mobile number but I 
need that in case GV or CSipSimple go down from lack of data connection. But I 
want to be able to turn off/on the native answering manually)

How do I prevent the normal phone from working at all?

Original issue reported on code.google.com by donrhum...@gmail.com on 28 Jan 2013 at 6:31

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
I have the same setup, and I also would prefer to be able to optionally disable 
native incoming calls.

A workaround I've found is to turn on airplane mode, and then connect to Wifi.  
When I leave the house I have to remember to turn off airplane mode.

Original comment by dfriber...@gmail.com on 1 Feb 2013 at 3:06

GoogleCodeExporter commented 9 years ago
bump

Original comment by Craig.D....@gmail.com on 19 Feb 2013 at 6:46

GoogleCodeExporter commented 9 years ago
I have the exact same GV setup and would like to see the feature to suppress 
incoming mobile call and use CSipSimple to take the call.

Original comment by diwakar....@gmail.com on 8 Mar 2013 at 4:06

GoogleCodeExporter commented 9 years ago
Not a problem in csipsimple but a configuration in GV.

CSipSimple obviously can't prevent an incoming gsm call (and that's pretty safe 
it can't ;) ).

The problem you have here is something with the service, not something with the 
client application.

If on your web browser (firefox/chrome/internet explorer), if you visit a 
website and see 2 popup on this website, will you open a bug on the web browser 
or try to see why the website you visit shows the two popups?
Here it's the same, csipsimple is like a browser of the sip protocol. It will 
ring if the configured server is calling. Your android GSM device is also like 
a browser of the gsm protocol, when somebody calls, the phone will ring.
So if Google Voice is configured to ring at the same time the sip device and 
the gsm device.... well the only thing you can expect is to have the gsm and 
the sip to ring at the same time.
And the culprit is Google Voice and the configuration done that make both sip 
and gsm ring at the same time.

For the record, the other settings you mention aim is to "filter" *outgoing 
calls made from the native dialer*. 
So will have no impact on incoming calls and even less impact on incoming gsm 
call ;). 
In the filters, there is just one option to have impact on incoming sip calls 
and allow auto-reply/auto-hangup of sip calls (but not gsm calls).

Original comment by r3gis...@gmail.com on 10 Mar 2013 at 12:35

GoogleCodeExporter commented 9 years ago
> CSipSimple obviously can't prevent an incoming gsm call (and that's pretty 
safe it can't ;) ).

Au Contraire -- 
http://stackoverflow.com/questions/7357372/how-to-disable-gsm-connection-in-andr
oid-programmatically

Although this isn't really a bug, as you say.  This should be reclassified as a 
feature request to turn on airplane mode for the GSM when a wifi connection is 
detected.

Original comment by dfriber...@gmail.com on 10 Mar 2013 at 1:56

GoogleCodeExporter commented 9 years ago
I didn't say it's not technically possible. I say CSipSimple has not the role 
to prevent gsm calls.

It's the role of another app to change settings according to phone context.

On android apps are not monolithic and each app should focus one feature and 
provide api to other apps so that the behavior is tweaked by dedicated apps.

It applies to how to prevent gsm calls, it applies to how to enable/disable a 
sip account depending on the WiFi hotspot, of the time range in the day, on how 
the weather looks like.
there is currently existing apps doing that such as tasker and locale.I've also 
developed one that I plan to release as open source. But due to the time 
CSipSimple support take to me I've not enough free time to release it in short 
term.

Original comment by r3gis...@gmail.com on 10 Mar 2013 at 10:13

GoogleCodeExporter commented 9 years ago
Actually, Sipdroid has implemented this feature already. When google voice 
rings both the SIP account and the Mobile number, Sipdroid suppresses the 
Mobile call and the SIP call is given priority.

Original comment by diwakar....@gmail.com on 12 Mar 2013 at 6:16

GoogleCodeExporter commented 9 years ago
Sipdroid doesn't actually suppress the call. It just pushes its intent back on 
top of the native dialer. You will notice this because the ringtone restarts 
part way through (when the native dialer shows up).

I disagree with r3gis and I believe that CSipSimple does in fact play a role in 
GSM call management. Like he(she?) said it is difficult to do it right, but I 
believe that it should do what sipdroid does(attempts) and suppress the 
incoming call if the number from GSM is already being handled by CSipSimple 
(This is what I want it to do anyways... If it should or not is a different 
question). 

To that end I wrote a patch that performs true call suppression (I terminate 
the incoming call without interrupting the sip call (IFF numbers match)). I 
have no idea if it will work on any other devices or without root (you might 
even need to use Titanium App's to make it a system app). I wrote it to do what 
I needed it to do. If it does what you want, here you go.

My Device: Nexus4
Android: Rooted Stock 4.3

Aaand because I can't post patches here I will put them on my server.
http://www.lindeneau.com/csipsimple/prevent-native.patch
And a pre-compiled based off of latest trunk.
http://www.lindeneau.com/csipsimple/SipHome.apk

Original comment by slinden...@gmail.com on 15 Aug 2013 at 10:56

GoogleCodeExporter commented 9 years ago
@slindeneau :
Thanks for contributing that !

Indeed it will not work if you are not rooted and not able to change the app 
rights.
That's why a correct approach for this kind of stuff is definitely not to put 
that inside CSipSimple (and I maintain my position on that, it's not the role 
of CSipSimple app).

However, what you did is something that is totally feasible as a separate 
application !
Android OS is designed to be not monolitic !!! It's not iOS !! 
An app that automatically cut incoming GSM calls based on other condition is 
some role that totally makes sense. And that's almost what you did and what you 
need. My point is just that it's not a correct software design to put it 
*inside* csipsimple.

That's why I think the feature you added should be a *plugin* and distributed 
as a separate app. By this way, anyone with stock csipsimple (or any fork of 
it) could use your feature + It will not grant extra system permissions to the 
sip app. And better... it could benefit more apps than just csipsimple... maybe 
the thing you did could just also check presence of other sip apps like 
sipdroid/linphone/imsdroid and get number of incoming calls from these apps and 
cut gsm if they have incoming calls.

You did almost all the work to make this functional. And it's great! Now, IMHO, 
it's just about putting that in a different app and using the CSipSimple API 
(http://r3gis3r.github.com/SampleCSipSimpleApp/javadoc/) to know if there is 
calls incoming (note : the csipsimple api is already what you use in your 
patch, so it's just about binding the service).

Also, think about that : this *dedicated* app could also allow user to 
configure more stuff like : 
 * filtering what is the incoming gsm number to address more cases than GV.
 * let user configure with a widget (or inside the app) if he wants to always prefer gsm over sip or sip over gsm.
 * ... put here whatever other thing you might think/need in the future... 
Also think about the fact that if you create such a plugin, it will work with 
all future version of the app, and it will not be needed to do new full builds 
of CSipSimple each time it evolves.

My point was not to say the feature proposed here is silly. It's just to say 
it's not good idea to add it *inside* csipsimple because it's definitely not 
the role of csipsimple to provide this feature. The role of csipsimple is to 
provide SIP and to do that well (as good as possible ;) ). 
It's not to implement the galaxy of possible side features. 
Other side features should take place in *dedicated* apps that address 
specifically this side need. It should also do that well with dedicated options 
so that :
 - users that does not need it will not get lost with feature they do not understand
 - users that needs the feature will download the plugin and have more detailed control on what this feature does. In this particular case, they will also need to follow special instructions (root device, transform the plugin into a system app).

That's why I classified the issue as invalid for csipsimple and that's why your 
work on the topic is very welcome and that I advise you to change your approach 
to create a plugin instead so that it can benefit anyone easily and that your 
plugin can evolves to provide more feature to all users with this need.

Original comment by r3gis...@gmail.com on 15 Aug 2013 at 11:25

GoogleCodeExporter commented 9 years ago
I understand what you are saying. I will look into making it a tasker/locale 
plugin.

For this to work the sip apps would also need an option to simply ignore the 
fact that that the GSM dialer was being called, otherwise there is a hickup 
(like sipdroid's ringer being restarted.) In my version of the code (I left it 
out of the patch) I completely removed all of the onGSMCallIncoming() code 
within the pjservice because it breaks the unified user experience.

By the by, I did my work in CSipSimple because I found it to be the best sip 
app by far. From your post I can see why it is the best. Good Job.

Original comment by slinden...@gmail.com on 15 Aug 2013 at 5:08

GoogleCodeExporter commented 9 years ago
@slinden, thanks for the effort you are putting in to make this a tasker. do i 
follow this thread for updates or do i follow your effort elsewhere? thanks 
again.

Original comment by sriram.r...@gmail.com on 5 Sep 2013 at 1:02

GoogleCodeExporter commented 9 years ago
I've disabled using cSipSimple for incoming calls because of this problem.  My 
cellular service provider (CDMA in my case) provides a SIP gateway to 
make/receive calls using the same phone number as the cellular service.  So, 
when a call comes in while I'm under Wifi, while CSipSimple does start ringing 
first, as soon as the cellular radio gets the incoming call, cSipSimple is 
pushed to a task bar notification by the native ringer and I don't know how to 
get it back into the foreground quickly so I can pick up the call using SIP 
instead.  So there seems to be no point of trying to use cSipSimple for 
incoming calls.

NOTE: Even if you got this to work better, I also do not agree that SIP should 
always have precedence for taking an incoming call.  Rather, I would like to be 
able to configure how incoming calls are handled between the two services, 
including being presented with a service chooser on the native incoming ringer 
screen.  Sometimes, I might be driving and be temporarily covered by a public 
WIFI network, so I would not want to answer the call using SIP in that case 
like I would if I were stationary or at home, because as I understand it, there 
is no handshake to seemlessly transfer the call between cellular and SIP like 
cellular can usually do between towers and the call would get dropped really 
quickly if I answered using SIP.

Original comment by cpar...@gmail.com on 13 Feb 2015 at 4:37