Closed GoogleCodeExporter closed 9 years ago
[deleted comment]
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
bump
Original comment by Craig.D....@gmail.com
on 19 Feb 2013 at 6:46
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
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
> 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
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
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
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
@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
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
@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
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
Original issue reported on code.google.com by
donrhum...@gmail.com
on 28 Jan 2013 at 6:31