Opened 5 years ago

Last modified 5 years ago

#16188 new patch

Jabber capabilities not updated properly when new presence recieved

Reported by: wpettersson Owned by: deryni
Milestone: Patches Needing Review Component: XMPP
Version: 2.10.9 Keywords: voice video
Cc:

Description (last modified by Robby)

I am running Pidgin 2.10.9 (and libpurple 2.10.9) on a Gentoo box.

I have an XMPP account, and a Google account. The XMPP logs in via Pidgin, and the Google account uses GMail (webpage on my PC).

If I open up the GMail web page, and then start up pidgin, I can use voice and video calling both ways. I can call GMail from pidgin, and I can call pidgin from GMail. If I then close GMail, I go offline. All seems to be working fine so far.

If I re-open GMail (without restarting pidgin), however, the "Audio Call" and "Audio/Video? Call" options do not return. I do appear online once again. IMs get sent fine. If I try to initiate a voice or video call from GMail, it starts calling from GMail but pidgin does not show anything (not even in Debug Window). Restarting pidgin always fixes the issue.

I've tried to debug this myself. Lines (roughly) 3475 to 3511 of jabber.c outline a chunk of code that checks various jabber resource capabilities. When things are working, the capabilities NS_GOOGLE_VOICE and NS_GOOGLE_VIDEO are found. After closing and opening GMail, neither of these capabilities are found. I checked this by adding a purple_debug_info() call to show what capabilities are found.

I've also checked the <presence> that gets sent by Google. There seems to be a difference here for some reason. The first presence Pidgin receives (after restarting pidgin) has some extra characters after my name+domain. Any further presence drops these. I thought it might be pidgin doing something differently, but it's being logged as Recv (ssl), which if I read the code right means that this is the raw decrypted stream.

Here's an example of the "first" presence received after restarting pidgin:

(22:42:09) jabber: Recv (ssl)(410): <presence to='william@…/65cfec59-3424-4043-b694-b84092c8f77d' from='william.pettersson@…/gmail.2F775F64'><status/><priority>24</priority><c ver='1.1' ext='pmuc-v1 sms-v1 camera-v1 video-v1 voice-v1' node='http://mail.google.com/xmpp/client/caps' xmlns='http://jabber.org/protocol/caps'/><x xmlns='vcard-temp:x:update'><photo>cc6559d138bb41aab333a60c4e580228f72281ea</photo></x></presence>

And here's an example of the "second":

(22:43:42) jabber: Recv (ssl)(373): <presence to='william@…' from='william.pettersson@…/gmail.2F775F64'><status/><priority>24</priority><c ver='1.1' ext='pmuc-v1 sms-v1 camera-v1 video-v1 voice-v1' node='http://mail.google.com/xmpp/client/caps' xmlns='http://jabber.org/protocol/caps'/><x xmlns='vcard-temp:x:update'><photo>cc6559d138bb41aab333a60c4e580228f72281ea</photo></x></presence>

I have no idea if this is in any way related to my issue. I've spent a few hours reading code and adding purple_debug_info() calls but I can't find any hints as to why capabilities aren't found so if anyone has any other tips on what to try next please let me know.

Attachments (1)

libpurple-16188-jabber-caps-update.patch (842 bytes) - added by wpettersson 5 years ago.
Update known but disabled capabilities on presence updates

Download all attachments as: .zip

Change History (3)

Changed 5 years ago by wpettersson

Update known but disabled capabilities on presence updates

comment:1 Changed 5 years ago by wpettersson

Problem was down to a difference between jabber_caps_exts_known (which determines whether to update capabilities) and jabber_resource_has_capability. It seems JabberCapsNodeExts? stores, for each capability, a GList in the GHashTable *exts (caps.h:65). jabber_resource_has_capability only "finds" a capability if there is a corresponding GList in the hash table, and if the GList contains the string representation of the capability. However, jabber_caps_exts_known only checks for the entry in the hash table, it doesn't check whether the string is in the corresponding GList.

As a result, if you ever got to a situation where a capability has an entry in the hash table, but the capability does not exist in the corresponding GList then for any new presence jabber_caps_exts_known will say "We already know about that, and won't update but jabber_resource_has_capability will always say "No, don't have that capability".

I've attached a patch which fixes the problem for me by adding the extra check to jabber_caps_exts_known.

A few notes, though.

caps.h:61 warns against using the hash table. Seeing as it was used previously, I wasn't sure if my change was ok. Instead of using "jabber_caps_exts_known" to check for whether a capability is known, we could just use jabbeer_resource_has_capability on line 1052 of presence.c, but then there's that hack mentioned on line 360 of caps.c so I don't know how those two would cooperate.

comment:2 Changed 5 years ago by Robby

  • Description modified (diff)
  • Milestone set to Patches Needing Review
  • Type changed from defect to patch
Note: See TracTickets for help on using tickets.
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!