cannot find and initiate first call to another registered ring user, only receive calls

[star-buck]

• when i try to find starbuck1, it does add it to the timeline, but calling doesnt work
• when i try to find testest7 from android starbuck1 user, it does work and i can call, then another entry gets added called starbuck1, which i then call also call from ring-kde see image: the upper starbuck1 is the one that sucessfully found testest7 and called from android-ring. the lower starbuck1 entry is from trying to search starbuck1 from ring-kde, but couldnt establish a connection nor send message successfull:

[star-buck]

when quitting and restaring ring-kde, the former starbuck1 ring-id account now is "Unkown" and a Warning message is displayed next to the ring_id_number:

[Elv13]

I fixed a bunch of mini issue since Friday of last week to make this more robust but after testing there is still a couple. The good news is that it's a false positive where it could work, but Ring-KDE thinks it wont. The bad news is that it hides the call button because it anticipates a failure. That particular one is, but the "Unknown" one is only partially fixed. It involves merging and synchronizing contact details and I want to make sure it's better tested before tagging this "ready for testing".

Here's 3 screenshot of new error handling that was implemented to reduce the confusion when there is real issues like high packet loss or no internet:

While not perfect UX, it will help make the user less confused when there is real problems (again, the one above turned out to be a false positive due to a race condition and a missing NOTIFY QObject property that caused outdated values to propagate all the way to up the GUI, I could reproduce)

[Elv13]

Update on this. While the specific issue you experienced was most likely fixed last week, I spent a couple days trying to fix as many live media issues as I could find and done heavy testing. It's in a branch right now, so it's a bit pointless to push today's nightly. Here the list of case that were previously not handled as well as they could but are now correctly diagnosed and reflected in the UX:

• Better handle when an account goes down
  • Ensure the client is updated when it comes back
  • Add a message in the peers timeline to manually reload the account
  • Add a message in the peers timeline when all accounts have been manually disabled
  • Add a message in the peers timeline when all accounts have been deleted
  • The call/video/screen sharing buttons were not updated
  • Make sure the daemon really tracks the contact correctly before assuming the presence information is valid.
• Better handle when a person has multiple phone numbers using multiple accounts
  • The bookmark "star" was using the most recently used number instead of the state of the aggregate
  • Clicking on the call / video / screen sharing button used a ranrom phone number
  • The media buttons were not visible if there was a problem in the most recently used phone number instead of tracking all phone numbers
    • A more extreme version of this bug when you have multiple phone numbers, multiple accounts, used a deleted account in the past and the accounts have different tracking settings is left untouched. If someone ever hit this corner case and report it, it's a troll. I have no clue how the GUI should behave on this one.
  • Correctly filter the phone number by availability when given the user a choice.
  • Correctly select the most recently used phone number by default because that's the correct one 99% of the time.
• Better handle other case where the media button got confused
  • When the person was known to be offline, the call button was there
  • When a person has
  • Make sure the header and live media buttons always match
  • When the account was deleted but a new equivalent one was created
  • When the account goes down and up again
  • When the account is manually disabled
  • When the "enable video when supported" checkbox is manually changed
• Better handle the case where the state change while the window is iconified (aka: move everything to the C++ backend because QML is unreliable when iconified)
• Better handle live media failed [IN PROGRESS]
  • When the peer isn't online, say so
  • When the peer is supposed to be online, but cannot be found, say so
  • When the peer declined to enable video, say so
  • When "connecting" takes more than 20 seconds, offer to restart the call
  • When the video failed due to codec or fireall, say so
  • Let the user know he/she/it can try to tweak various settings when specific aspects of the handshake failed
    • UPnP (then eventually open ports in the router)
    • There is a codec mismatch
      • Patch libring to disclose the peer codec list
      • Add a button to enable some codecs and renegotiate the call
      • Know when the peer voluntarily disabled video
• Better handle acccidentally mistyped ringId/phone-numbers/accounts
  • Allow to set the default account when editing phone numbers / RingID
  • Allow to delete mistyped entries so they don't pollute "find someone"
  • Make sure the registered name have priority over the URI/RingID in the phone number list (when editing too)
  • Make sure adding and deleting phone numbers from a person really, really works...
  • When the registered name is only confirmed later (due to a lack of network or high latency), make sure it doesn't impact anything.
  • Make sure the shared pointer don't explode when the value is regenerated
• Better handle deleted accounts side effects
  • Make sure entries in the timeline are not lost
  • Make sure calling entries that used a deleted account reasign them to a new one.
• Extend the existing media button warning and errors with "Fix it" buttons
  • Sending text messages can only happen during an audio call in SIP accounts
    • Make a call
  • This account doesn't support all media
    • Enable video
    • Make a new account
  • Video isn't available because it's disabled for this account
    • Enable video
  • There is no account capable of reaching this person
    • Make a new account
  • All video codecs are disabled, video call isn't possible
    • Select codecs to enable
  • All accounts capable of reaching this person are currently unavailable
    • Reload the account
    • Enable new accounts
  • Ring-KDE is experiencing a network issue, please try later
    • Reload the account
    • Select network interface
• Handle generic call state with better messages than "the call has ended"
  • When the line is "busy"
    • Add the option to call back
  • When the contact hang up manually
  • When the call is on hold
  • The call was hung up before being answered
    • Add the option to call back
• Handle known issues during a (working) live media
  • Restart video when it suddently stops, offers different ways
    • 1: Mute/unmute the video (too much packet loss)
    • 2: Hold/Unhold (the SIP session imploded)
    • 3: Hangup and call again (TLS/DTLS/ICE/STUN/TURN socket issues)
    • Keep track of the RTCP diagnostic data to detect jammed network
    • There more than 15 lost packet per report
    • There is more and more packet less in each report
    • The latency is non-optimal
    • The latency is increasing
    • Try to detect if access to the DHT isn't available
    • When the video stops, don't display the last still frame forever, say "[ No Video ]"
    • When the call is on hold (from out side) and fails to be removed from hold after 5 seconds, say so

Once those possible failure case are diagnosed earlier, it will be less mysterious when things fail. Note that no other Ring client handle any of those at all. I could reproduce every single of these bugs with the Android and Gnome clients.

I will do very heavy testing on the branch before merging it because this touches a lot of code and is therefor a little regression prone and I really want to avoid regressions on master to meet your release deadline.