Not really to vent anger, but to make it visible that there is a strong need for such a functionality. If not built-in then at least 3rd party. I guess that some developers browse this forum and hopefully one of them finds it worthwhile to do it. Or even just fix one of the existing applications like phonehook, whose source code is publicly available and apparently doesn’t require much more than adjusting it to Sailjail-related restrictions and a few recent OS changes (like the nemo → defaultuser modification of hardcoded paths) causing that it lost access to contacts and communications history.
4 Likes
This forum is the only way for a user to give feedback and the only chance for vendor-customer communication. So, what else should we do but write here or in another thread if there are some needs or problems???
As it was pointed out in one of the above posts, this feature was requested over eight years ago and many times since. I would like it too.
However, if it is that easy to implement, and Jolla has still decided not to implement it despite many requests over a period of eight years, then obviously Jolla had never thought it was worth doing for whatever reason. Probably a waste of time to keep asking.
2 Likes
If I remember correctly @slava once wrote that he implemented ofono in a way that it’s possible to write a plugin for blocking unwanted connections. So if you find someone willing to implement it, it will be faster than waiting for Jolla.
4 Likes
Jolla, another telemarketing operator was just sent to f**k out because of this missing feature.
Save an operator a bad word. Do this quick.
1 Like
From phonehook sources I can see that it doesn’t take anything special. It’s actually as easy as listening for incoming calls, like
QDBusInterface voiceCallIf("org.nemomobile.voicecall",
"/calls/active",
"org.nemomobile.voicecall.VoiceCall",
QDBusConnection::sessionBus());
if(!voiceCallIf.property("isIncoming").toBool()) {
qDebug() << "ignore outgoing call";
return;
}
comparing their numbers with user’s blacklist, and if there’s a match simply doing
m = QDBusMessage::createMethodCall("org.nemomobile.voicecall",
"/calls/active",
"org.nemomobile.voicecall.VoiceCall",
"hangup");
QDBusConnection::sessionBus().call(m);
I think I will do it myself when I manage to find some spare time for it.
12 Likes
P.S. It looks that hangup takes some time, enough for half-a-second of ringtone to be heard in some cases. So muting the ringtone first turns out to be helpful:
QDBusMessage m = QDBusMessage::createMethodCall("org.nemomobile.voicecall",
"/calls/active",
"org.nemomobile.voicecall.VoiceCall",
"silenceRingtone");
QDBusConnection::sessionBus().call(m);
7 Likes
Great work. I think one should be able to write some kind of daemon that monitors DBUS for the right signals and fires the appropriate method calls if the numbers match certain criteria.
If I remember it right there is also some kind of “new SMS received” DBUS signal but when I played around with it some years ago I’ve never been able to prevent the SMS tone from being played. Would be nice to have a solution for that, too 
2 Likes
It needs some further investigation. I’ve been playing with it and there’s a strange phenomenon that an incoming call seems to be nicely and silently rejected, a notification is shown on the screen that the call has ended, and so far so good, but it turns out that the actual connection doesn’t really get rejected and after a few seconds the incoming call is reported once again 
It gets rejected, too, but this time it takes longer, enough for the call UI to be shown for a short while and ringtone to be heard for a fraction of second. Only after this second time the actual connection gets rejected.
I’ll take some testing to find out why is it so and how to avoid it.
BTW. It looks that one can also use
QDBusMessage m = QDBusMessage::createMethodCall("org.ofono",
"/ril_0",
"org.ofono.VoiceCallManager",
"HangupAll");
QDBusConnection::systemBus().call(m);
to hangup a call, but with the same result.
1 Like
There is a strange bug with hanging up a call, both methods, no matter if I call HangupAll of org.ofono.VoiceCallManager or hangup of org.nemomobile.voicecall.VoiceCall.
Most of times, even though the UI on the phone behaves as if the call was ended (the call UI closes, there’s a system pop up that the call has ended, etc.) the actual connection remains active (on the other phone one can still hear the waiting tone) and after a few seconds the call comes in another time, and only this second time it really gets disconnected. The caller hears “beep beep beep” (as in case of a network error) and the connection just terminates.
Only very rarely, the call gets rejected right away, as it should. In such case the connection gets forwarded to voicemail, just as it happens if I manually reject a call with the red button.
So this leads me to a conclusion that there must be some bug in voice call management on SFOS, if it behaves differently in the same conditions. The telephony system must be sending to the network some different messages, if the call sometimes gets forwarded to voicemail (as it should with my call forwarding settings) whereas most of times it remains active even though SFOS shows it as disconnected, then it starts ringing again and only this second time it gets terminated, but with a “beep beep beep” tone like in case of a network error, without being forwarded to voice mail.
I’m not sure if I should report it as a bug by filling the bug report form?
Anyway, add to it that in most cases the reaction to HangupAll of org.ofono.VoiceCallManager or hangup of org.nemomobile.voicecall.VoiceCall is slow enough for some 0.5 - 1 second of ringtone to be heard before it gets silenced and rejected (and due to the aforementioned bug it often happens twice within a few seconds) and it turns out that in its current state it’s probably not possible to fully silently reject calls 
2 Likes
That’s not exactly encouraging. Still, thank you for the work done so far.
One possible way (although born out of pure desperation) to overcome this might be to keep the ringtone silenced all the time and only activate it when the daemon detects a negative match (i.e. the number/pattern is not on the blocklist) which, of course, comes with it’s own set of problems.
I reported it as a bug here because I realized that this strange behavior also happens when I try to reject incoming calls normally, via the UI, and not just programmatically. When I get an incoming call and press the red handset icon to reject it, everything looks as if the call got rejected, but the actual connection (with waiting tone) continues on the calling phone and after a few seconds it starts ringing again and the Phone app with incoming call screen pops up again. Only pressing the red handset button the second time hangs up the call.
Someone in the other thread reported that he tested it on a 10 II and couldn’t reproduce such problem. So maybe it’s XA2 unique (maybe something to do with its specific modem). Or maybe my system is broken (which would be strange as I flashed it less than a month ago and didn’t really mess with it too much).
It would be great if more people could test it, especially on XA2.
To test it, just please call to yourself from some other phone and reject the call the normal way via the UI, i.e. using the “red handset” icon/button of the Phone app UI. Please repeat a few times and see if the call always gets rejected correctly.
I’ve got an application to reject calls in a quite advanced state (with configurable white list, black list, etc.) so quite soon I could share it if this problem could be ironed out.
2 Likes
I tried 7 times on XA2 4.3 free but I couldn’t reproduce.
Great to know you are cooking something!
Then I really don’t know why it happens all the time on my XA2 Ultra. Is your XA2 Dual SIM?
Well, if no one else can reproduce it then I guess that reflashing the OS will be the only option left…
Tomorrow I will be able to test on an XA2 whit SFOS 4.3, one sim
Here’s a video showing this bizarre phenomenon (sorry for that heavy blur, but there were too many personal details to hide on both screens to do it in some other way):
Not only the call stays active after the first attempt to reject it even though SFOS behaves as if the call was terminated (see iPhone’s display on the right, the call is still waiting to be picked up as if nothing happened), but when the call magically comes back on SFOS, two different ringtones play simultaneously. I have no idea where that second ringtone comes from, maybe Android. What a cr*p. Now all those obtrusive telemarketers and frauds will annoy me twice more as I will be struggling with my Sailfish phone to hangup their calls.
I have experienced and reported back in TJC general slowness of the dialer UI. Specifically, if I press the hang button once it is almost certain that the call will not be hung up, and no feedback will be provided, be it visual, aural or haptical. When hanging up, I usually press the button several times in a row to be sure to succeed. Unfortunately, sometimes this causes me to press on the just appeared “Call again” button - which will let a call start before the hang up button can respond to my subsequent frenetic presses.
But this case is different. It is not lack of response from the UI, on the contrary, as you can see on the video, the UI does instantly respond to pressing the “red handset” button. There is no slowness or lag, it’s very responsive. After I press the Hangup button, the call window instantly closes and a system notification is displayed that the call has ended (with connection time 0:00:00), i.e. everything looks as it should. The Phone UI acts as if it normally rejected the call. But it doesn’t. It rejects the call only the second time, but even in that case some incorrect signal is sent to the mobile network because instead of being forwarded to voicemail (or busy tone being sent if there is no voicemail forwarding enabled) like it is with this SIM card in any other phone (or even in this same phone reflashed with Android), the caller hears “beep beep beep” connection error tone. Something is simply scr*wed up with modem handling by SFOS.
BTW. I’ve just entered Android settings, checked ringtone settings there and identified that this second ringtone being played simultaneously with my SFOS ringtone is the default Android ringtone. So maybe it is the Android support stuff doing all this mess.
1 Like
I just tested around 10 times, in my XA2, one sim, SFOS 4.3, with and without android support, and every time it worked right (finishing calling in the first reject)
I’ve tried to find a workaround in order to be able to finish my call rejecting app. The idea was that if the hangup method doesn’t work, then I’ll use the deflect method to forward unwanted calls to voicemail.
So I did this:
QDBusMessage m = QDBusMessage::createMethodCall("org.nemomobile.voicecall",
"/calls/active",
"org.nemomobile.voicecall.VoiceCall",
"deflect");
m << "+48602951000"; // voicemail phone number here
QDBusMessage response = QDBusConnection::sessionBus().call(m);
Result? “Problem with network” (“Problem z siecią” in Polish) notification is shown and the incoming call keeps ringing and doesn’t get deflected / forwarded.
Apparently, Sailfish OS’ telephony isn’t compatibile with Polish T-Mobile network.