Request - internal call and SMS blocklist

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.

1 Like

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.

1 Like

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.

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.

9 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);
6 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 :slight_smile:

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 :open_mouth: 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 :frowning: