After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 565443 - The SIP endpoint uses the Opal::Bank from threads
The SIP endpoint uses the Opal::Bank from threads
Status: RESOLVED FIXED
Product: ekiga
Classification: Applications
Component: Account stack
GIT master
Other All
: Normal normal
: ---
Assigned To: Snark
Ekiga maintainers
Depends on:
Blocks:
 
 
Reported: 2008-12-23 10:41 UTC by Snark
Modified: 2009-06-22 18:46 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Snark 2008-12-23 10:41:40 UTC
The good news is that it just calls find_account which shouldn't be in that class in the first place : so find_account should just migrate to the opal bank, and the opal bank will be able protect itself from such access.
Comment 1 Snark 2008-12-23 20:20:25 UTC
Now it calls Opal::Bank for that -- but I didn't harden the method against thread use...

Re-titling from "The SIP endpoint uses the account core from threads" to "The SIP endpoint uses the Opal::Bank from threads" accordingly.
Comment 2 Snark 2009-03-31 19:37:54 UTC
There is still a place where the SIP endpoint uses the Opal::Bank -- and I'm not sure at all it is that useful... I left the question as a comment.
Comment 3 Snark 2009-06-22 11:06:11 UTC
This is the what the GetRegisteredPartyName method of the SIP endpoint does :

      /* FIXME: this is the only place where we use the bank in a thread
       * can't we just return GetDefaultDisplayName () ?
       */
      AccountPtr account = bank->find_account ("Ekiga.net");

      if (account)
        return SIPURL ("\"" + GetDefaultDisplayName () + "\" <" + PString(account->get_aor ()) + ">");

Which brings up several questions :
1) can't we just cache that aor somewhere thread-safe?
2) what if there are several ekiga.net accounts?
3) why do we make an ekiga.net account that magical?! What happens if I'm registered to foo.net (and only there) but still have a 'dead' ekiga.net still in my list of accounts?

Damien, what do you think?
Comment 4 Damien Sandras 2009-06-22 11:22:58 UTC
1) We could. Yes.
2) Any account could be used.
3) It should only use active accounts. If the account is disabled, but still considered as active, then it is a bug.

The idea behind this is to never call anyone with a From field like : sip:damien@172.30.201.76:5067;transport=udp

The correct algorithm should be :
1) Find a corresponding account for the destination ;
2) If not found and we have several possibilities, use the Ekiga.net account, because we are Ekiga.net and we should give the privilege to those accounts ;
3) If there is no possibilities, use GetDefaultRegisteredPartyName .
Comment 5 Snark 2009-06-22 12:15:22 UTC
1) Good ;
2) If it's any account, then choosing the first ekiga.net account may not make sense, especially it isn't active ;
3) There is no test to see if said account is active in the current code.

Now that I know a little more about the problem, I think I have a clue what to do to fix the issue.
Comment 6 Damien Sandras 2009-06-22 12:23:01 UTC
1) no comment ;
2) if you read me carefully, you will notice that I wrote "It should only use active accounts". I suppose any other behavior is wrong, except if no account is active at all.
3) that's bad.

Comment 7 Snark 2009-06-22 18:46:19 UTC
Done.