Had two long calls today and I got calls during them that caused the current call to freeze and I didn’t get any way to answer or reject the incoming call. Is there any workarounds for this? This is a major issue.
2 Likes
Here is an open issue about something similar:
4 Likes
I’ve experienced this when running postmarketOS on librem5. Recently I switched to PureOS and this issue went away. I think this was temporarily fixed by automatically rejecting incoming calls (or appearing as busy for incoming calls) during active call.
If you are already using PureOS, I’d suggest to check whether it is on byzantium version and fully updated. If it is, maybe there is some residual config that is causing the mentioned workaround not being active.
I think I’ve found the comment that is mentioning the temporary fix:
5 Likes
“Call waiting” is an important feature that is slated for the L5, but requires more funding to implement within Purism’s current developer resources.
2 Likes
This drives me nuts too, but I keep going on the Purism sponsor your app thing, and donating a tenner when I can, and putting “calls, calls, calls, calls” on the app vote. Hopefully they’ll sort it one day.
2 Likes
Thanks so much for donating! Please don’t hold me personally to this (I’m just a messenger and community advocate in this case) but Purism is planning to do more project-driven funding/development starting in February. It would be really nice to have little benchmark figures for each app (somewhat similar to simplified crowdfunding tiers) so that the community can visualize the impact of their contributions. Of course, this feature would require more front-end development, which would delay other projects, and so on…
But Todd himself has mentioned “call waiting” in a meeting, so you can rest assured that it’s a development priority.
7 Likes
Good because calls are a top priority thing. You can’t have a phone that doesn’t reliably make and receive calls.
3 Likes
100% agree that call reliability is paramount. But generically saying that “the phone doesn’t send or receive calls” is difficult to constructively address or explain. My L5, for example, is my daily driver reliably sends and receives calls every day. More specific arguments are helpful to validate and develop improvements where possible.
5 Likes
With the most respect I can muster, Todd saying things means very little to those of us that have seen that Todd is very good at getting hyped up and saying things that are not true and is more marketing hype man than peddler of truth. Also in the context of this message, there is no context provided around what he said… he could have said anything from “I want this to be the highest priority and resolved as soon as possible” to “I’ve never had a problem with this”.
1 Like
Understandable. I honestly don’t remember much of the context other than it being a known limitation, very important for L5 development, and that it’s awaiting funding.
IMHO, anyone’s words can be taken at face value or interpreted to exhaustion. I promised the community when I started volunteering that I would advocate for them and be as transparent as possible without throwing anyone under the bus, and that’s what I’m setting out to do. To ease things moving forward, I’m trying hard to work with the team to construct policies and procedures which should improve messaging consistency and project management; there’s some growing pains with a transition like this and results aren’t immediately apparent, but I think it’s a step in the right direction. Time will tell if I’m right or if it’s worth it, but my past work experience had shown changes like these to be useful.
7 Likes
You’re lucky.
I think what is needed here is that Purism needs to do some drive testing in other markets. It’s one thing to have a phone that works great in California but doesn’t work in Ontario or Germany or Australia. I get that all this requires money to send engineers to these places to do testing but that’s what the carriers do to test a multitude of handsets on the network before a new technology get’s released, for example 5G. Seeing as carriers are not carrying the L5 in their lineup this testing needs to be done by Purism or else you’re just destined to sell expensive paperweights around the world.
Understanding that this costs money that Purism doesn’t have, would it make sense to engage the disciples of this product like us to do some of this testing? I’ve tried doing this but it’s very informal and not live by any means, just giving a description of what happens and then sending in logs to support. I’d be happy to donate some of my time to do some live drive testing of the phone (with someone else driving of course and me on another phone). I’ve sent logs after the fact but it’s hard to show an engineer what the phone is actually doing visually when these problems arise and also could instruct the drive tester in real time to try different things while testing which would bear more fruit in troubleshooting.
5 Likes
Thanks for this feedback! You bring up many good points and it would be great to hear about your testing scenarios, issue descriptions and log messages. I’m passing this along to the engineering dept lead to find the best way to get you involved where your testing efforts can be most effectively directed.
4 Likes
I’m totally game to try things (once I get my phone back from support) just need some sort of structured way to do this testing that will yield the best data for them.
EDIT: Maybe if live support time isn’t feasible, they could write some sort of script that captures everything they would need, and then provide the drive testers with what we call a UAT (User Acceptance Testing) script for us to execute to basically run the phone through it’s paces. Our technicians actually do a UAT when we install our SIP based business phone solution for our customers so they know that the phone will work in all possible calling scenarios.
6 Likes
What happens if the phone works after the phone comes back? 
Good problem to have?
I’ve already made posts detailing my issues and attempts to work around them. Keep in mind this is a 800 to almost 2000 dollar device.
On a note of being more constructive in this thread, for everyone who has this problem, could you perhaps talk to the devlopers on our behalf and ask how to add (or read) the workaround that rejects a incoming call when you’re in one already so it doesnt freeze your call audio?
Edit: I apologize. I missed the workaround that was shared. I’ve not been sleeping well and it seems I am not paying attention. I’ll look into adding a comment on the bug report.
Is there by chance a guide that details the proper way to gather bug report logs for the developers?
1 Like
Thank you very much! I’ll give that a try. I scrolled right past that command the other day. I’ve not been sleeping well.
Sounds like a great workaround until call waiting is implemented.
Lol…yes, but even when it was working there were many quirks related to calls that definitely still need a lot of attention.
I appreciate your optimism.
1 Like
Quite possibly so. The distinction to be made is between problems that are unique to one foreign carrier (which can be difficult for Purism to troubleshoot) and quirks that occur globally (hence easier for Purism to work on).
1 Like
Totally get that, it must be a nightmare to try and troubleshoot this because of all the variables, that’s why I think it would be good if they developed a testing procedure like I outlined to use us to gather information. Crowd source the troubleshooting.
2 Likes