GNOME Bugzilla – Bug 645397
Ekiga shouldn't respond to calls for the wrong user
Last modified: 2020-06-06 16:30:24 UTC
If I'm running Ekiga on a machine with an IP address of 192.168.7.22 with user Michael and user Janice, I can make a call from another instance of ekiga (on a different machine) to the SIP URI of Janice@192.168.7.22, and the instance of Ekiga running on 192.168.7.22 will ring. This is wonderful, and, sadly, I haven't found this behavior extraordinarily common among SIP clients in my limited testing. My issue is that if Ekiga is running under the Michael account, then a call to Janice@192.168.7.22 shouldn't cause it to ring.
Do you have two concurrent users on the same machine? Are they connected to the shared machine through ssh? Or they use the same keyboard, and they change X session when they want to work? Finally, is it on Windows or Linux?
Two concurrent users on the same machine. Not two concurrent users of Ekiga (yet). It was noticed as a problem when one user was using Ekiga for her desk phone, and the other user was using a SIP hardphone (different SIP extension, etc). Ekiga user was away while the other user logged into their own desktop session. A call came in for the Ekiga user, which caused the workstation to emit a ring sound, confusing the non-Ekiga user (who didn't know or care that Ekiga was running under a different user's profile). This was on Win7 Ultimate 64-bit. For the analogous scenario on Linux, it would be as "Or they use the same keyboard, and they change X session when they want to work?"
In my opinion, account name cannot be inside the SIP address. It probably gets removed upon calling. So the issue is that when Ekiga is started by a user, and that user's profile is closed and another user logs in, then Ekiga should not ring upon an incoming call. Otherwise said, Ekiga should not ring when user's profile/session is not current. Is that right? Does someone know how a program can know if the profile/session is not current?
The user's profile wasn't closed, it just wasn't the one occupying the screen. I don't have time to test, but I know that I _must_ supply Ekiga with a user@ component of a SIP address, even when dialing a machine directly. My own user account shows up as the user@ component in the 'call is from: ' dialog on the recipient side. I'll supply anonymized logs when I have the time. Which probably won't be for a week or two. I really want to get Ekiga stabilized on our workstations, as it's much cheaper, more convenient and more comfortable than our hardphones. It is, however, an 'unfunded unmandate.' I don't know how you'd solve the problem of two clients on the same machine, though; I'm pretty sure they'd both want to listen on the same UDP ports.
Ekiga is not under active development anymore: https://gitlab.gnome.org/Infrastructure/Infrastructure/-/issues/273 Ekiga saw its last release 7 years ago. The last code commits were 4 years ago. Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Please feel free to reopen this ticket (and transfer the project to GNOME Gitlab, as GNOME Bugzilla is deprecated) if anyone takes the responsibility for active Ekiga development again in the future.