Bug 38352 - Work around bugs in GMail's standard Jingle implementation
Summary: Work around bugs in GMail's standard Jingle implementation
Status: NEW
Alias: None
Product: Telepathy
Classification: Unclassified
Component: gabble (show other bugs)
Version: git master
Hardware: Other All
: medium normal
Assignee: Telepathy bugs list
QA Contact: Telepathy bugs list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-06-15 10:13 UTC by Will Thompson
Modified: 2013-06-03 10:34 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Will Thompson 2011-06-15 10:13:47 UTC
Hello.

Here is a branch which works around these three issues with GMail's brand new Jingle implementation:

• it omits creator='' on contents
• it names the video components video_rtp and video_rtcp
• it can't upgrade/downgrade

While writing this I decided my approach to the second is not ideal: it really should only do this if we're using the gtalk p2p transport. But this works for now at least.
Comment 1 Sjoerd Simons 2011-06-15 10:27:26 UTC
Looks good. You don't address the issue where non-google clients that may implement the google transport (as the barrier to entry for a client that already does jingle is quite low now) will probably pick the google component names instead of ours though.

But let's get this in first :)
Comment 2 Olivier Crête 2011-06-15 17:06:23 UTC
I think for the video_rtp/video_rtcp, we're going at it the wrong way. We should standardize on what Google defined (it's their transport after all) and add a quirk for old Gabble. I expect everyone else will be Google compatible, not Telepathy compatible. We must have some way of recognizing older gabbles ?
Comment 3 Will Thompson 2011-06-16 08:38:13 UTC
I forgot to set ImmutableStreams for GMail contacts in ContactCaps. Whoops.
Comment 4 Will Thompson 2011-06-16 09:23:32 UTC
I'm releasing gabble 0.12.2 and 0.13.whatever it will be with this branch as it stands; I'll leave the bug open for flipping the quirks around, the other ImmutableStreams thing and a bit more clean-up.
Comment 5 Will Thompson 2012-02-14 06:18:49 UTC
I did a bit more testing the other day. Currently we use Gingle when calling Google Mail, because our hardcoded feature lists for their bundles don't include xep-0166/-0177.

Using Jingle for outgoing calls failed because their implementation always assumes the audio component is called "audio", and we use "Audio" (case-sensitive), so reject their candidates. I let Google know; it's fixed, and they'll roll out the fix in the next few weeks.

(I worked around this in my checkout, and audio calls otherwise basically work; video is untested because Empathy kept exploding.)
Comment 6 Simon McVittie 2013-06-03 10:34:18 UTC
Does GMail exclusively mean the GMail web UI, for the purposes of this bug?

(In reply to comment #5)
> I did a bit more testing the other day. Currently we use Gingle when calling
> Google Mail, because our hardcoded feature lists for their bundles don't
> include xep-0166/-0177.

I have a branch for this, because I thought it might help with interop (Bug #65131). (It didn't.) In fact, even if we actually disco the web UI, it doesn't report these caps.

I made them conditional on the "is Google webmail" quirk && voice-v1 (or video-v1, as appropriate), in order to avoid also trying to call the old desktop UI, Android apps or whatever using Jingle-1, and avoid making browsers that lack the plugin callable.

(In reply to comment #4)
> I'll leave the bug open for flipping the quirks around, the other
> ImmutableStreams thing and a bit more clean-up.

What remains to be done? Is it basically two things, this:

(In reply to comment #2)
> I think for the video_rtp/video_rtcp, we're going at it the wrong way. We
> should standardize on what Google defined (it's their transport after all)
> and add a quirk for old Gabble.

and this?

(In reply to comment #3)
> I forgot to set ImmutableStreams for GMail contacts in ContactCaps. Whoops.


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.