No, one needs to recompile. In 4.3, the patch has to be applied in sailfishos/ofono, but in 4.4, the code has been out sourced and moved to a dedicated package : mer-hybris/ofono-ril-plugin. I can provide the package if needed. No problem.
@dcaliste Then I’ll be extremely grateful if you could share it compiled for 4.4…
Due to enormous amounts of unwanted calls I fully rely on ability to block such calls (I’ve made an application for it which I’ll make available soon). For that single reason I kept using BB Passport until now and refrained from switching to SFOS as daily driver. Your patch made me fully switch to SFOS yesterday. So when 4.4 comes out, this patch will be the very first thing for me to apply…
Thank you!
1 Like
@dcaliste Sorry, one last question. As my Jolla 1 (SFOS 3.4) also suffers from this problem, is it OK to install the patch supplied by you on it, or does it also need a version compiled specifically for OS 3.4?
No it would be better with a dedicated version. I’ll see to compile one in the coming days.
1 Like
That’s fantastic, thank you very much Damien.
Here are the Ofono packages with the patch for armv7hl devices:
-
for Jolla1 at version 3.4.0.24 with
ofono-1.23+git19. -
for other armv7hl devices at version 4.3.0.12 with
ofono-1.23+git35(the above link has been removed, I messed up a bit with names).
1 Like
Thank you Damien! Now my Jolla1 is fixed as well!
BTW. I’ve just applied the 4.3.0.15 OS update. It complained about possible issues with ofono, so I reverted it to the default version. The update went smoothly and then I reinstalled your ofono patch. All without any problems. Once again, thanks a lot!
1 Like
I tested it on my XA2 running 4.3 with Vodafone Germany. You’ll hate me for that and maybe someone will feel obliged again to call me an idiot.
It just works as expected.
Do you mean without the patch ?
That’s expected. It’s dependant on the operator of the number calling you, not even your own operator. For me, the bug is triggered when calling from my work land line (not RTC one, it’s VoIP actually) but it is not when calling the same phone with the same mobile operator from my home landline (not RTC neither, another VoIP one).
As far as I understand, it’s a bug (or not ?) on the operator side that can be mitigated by using the REQUEST_HANGUP_WAITING_OR_BACKGROUND instead of a plain REQUEST_HANGUP. From the knowledge gathered by Mozilla on FirefoxOS, it seems that Android is always using the WAITING_BLA_BLA version instead of the plain HANGUP for incoming calls. The patch is actually doing this also.
Thanks. I just tested again. SF on Vodafone Mobile.
- Telefonica Mobile
- Telecom Mobile
- Vodafone Landline (VOIP)
Rejection and Mailbox work. No patches installed. XA2, 4.3, Germany
Actually, based on my tests it seems to be even more complicated than that.
Without the patch applied, if I call my XA2/SFOS 4.3 (or Jolla1 OS 3.4) from the iPhone 6s (both phones with Polish T-Mobile SIM cards), the call never gets rejected and always comes back and rings again after a few seconds, and only if I reject it another time it eventually terminates with “quick busy” error tone.
But if I call my XA2 (or Jolla1, both still without the patch) from Nokia Lumia 920 (Windows Phone 8.1, also with T-Mobile SIM card, i.e. same operator as above) then the call DOES get rejected right away, but still with that “quick busy” tone rather than being forwarded to voicemail as it should. I tested it literally dozens of times, always with same results.
So it is not only the network/operator, but additionally also different phone models react differently.
Anyway, with the patch applied, no matter what network and what calling phone model, the call ALWAYS gets hung up and transferred to voice mail, just like it should. So the patch is a 100% fix and I guess that it’ll be useful for everyone and should be officially included in the OS, it’s just that some people haven’t yet had an opportunity to try to reject a call originating from a specific operator and phone model (i.e. that specific combination that trigger this bug) and that’s why they haven’t reproduced this problem yet. But one day they will.
Can´t be reproduced here with Sony X Compact. Sailfish OS 4.3 with german Blau.de-Carrier.
For completeness of information, please always also mention the operator and brand/model of the calling phone, as these seem to be what triggers this bug. In other words, this issue seems to occur only on calls from specific operators (specific network configurations) and the behavior differs (either no hangup, ringing again and the need to reject another time, or just a “quick busy” error tone) depending on model of the calling phone…
The Calling Phone was Snom M25 over LAN (VoIP). Operator is Deutsche Telekom.
@dcaliste did you make any changes between the first build of the patch you provided a week ago and the recent ones you shared 3 days ago?
Because the first build (the one you already removed) works perfectly fine, while the new build DOESN’T WORK.
After upgrading the OS to 4.3.0.15 on my XA2 Ultra I reinstalled the first build and it worked fine. Yesterday I decided to replace it with the newer build you shared, and it turned out that it DOESN’T WORK (it behaves like without the patch, calls don’t get rejected and ring again). Going back to the first build of your patch made it work 100% again…
Sorry, I may have done a mistake when applying patches for the various versions and recompiling . I actually remember messing up with version, checkouting again… I’m now in the mountain for one week with very limited Internet connection . I’ll check and recompile next week.
@dcaliste, no problem at all! The first build works just fine, and that’s actually all I need 
I just thought that you might have done some further changes in the newer build, and that it’d be useful for you to know that it stopped working.
Have a nice stay in the mountains!
Hello @wetab73, I’ve updated the file for version 4.3.0 armv7hl. The above link is still available, but the file it points to should be with the patch now. Tell me if you have any trouble with it.
1 Like
Somebody who can reproduce the problem please take an ofono log (with Ofono Logger) and send the tarball to me or someone else at Jolla.