The capabilities implementation of gabble indicates that a contact is capable of video if it just has PRESENCE_CAP_JINGLE_DESCRIPTION_VIDEO and capable of audio if it has PRESENCE_CAP_GOOGLE_VOICE or PRESENCE_CAP_JINGLE_DESCRIPTION_AUDIO But when making a call using RequestStreams, a contact is only considered as being capable of audio if it has: PRESENCE_CAP_JINGLE | PRESENCE_CAP_JINGLE_DESCRIPTION_AUDIO | PRESENCE_CAP_GOOGLE_TRANSPORT_P2P; or PRESENCE_CAP_GOOGLE_VOICE and a similar situation exists for video. So why is PRESENCE_CAP_GOOGLE_TRANSPORT_P2P suddenly needed and why is PRESENCE_CAP_JINGLE suddenly needed?
The one in RequestStreams is correct. In real Jingle land, we need to know that the client has support for Jingle itself, the appropriate content description (audio or vidio), and a usable transport. Gabble only supports signalling the GTalk-P2P transport, because its Jingle implementation isn't that far removed from its original GTalk implementation. In GTalk land, having the Google voice capability is sufficient, because GTalk didn't used to have any concept of separate session, content and transport signalling. You either have Google voice capability (implying Google Session, and GTalk-P2P), or you don't. In future if we'd added support for signalling Jingle ICE and Jingle Raw UDP, then having one them would also make people callable, rather than requiring them to have GTalk-P2P (in practice, I expect only us would ever use GTalk-P2P as a transport with XEP-0166 Jingle). Although at this point, we should examine our own channel-specific capabilities, and only consider people with raw UDP callable if we have raw UDP available ourselves, for example.
Fixed in 0.7.6.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.