[Telepathy] [Bug 13159] New: support current Google Talk protocol

[bugzilla-daemon at freedesktop.org]

http://bugs.freedesktop.org/show_bug.cgi?id=13159

           Summary: support current Google Talk protocol
           Product: Telepathy
           Version: unspecified
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: high
         Component: telepathy-gabble
        AssignedTo: telepathy at lists.freedesktop.org
        ReportedBy: robert.mcqueen at collabora.co.uk


Some point last year, Google Talk made their protocol look a little bit more
like how Jingle looked at the time, by introducing some concept of
interchangable/negotiable transports (Jingle has subsequently changed further,
so it's actually just a differently incompatible non-standard protocol, but its
as much our fault as theirs :D).

In version of the protocol we implemented originally, all Google Sessions were
assumed to use Google P2P as a transport, so there was no negotiation of
transport namespaces at all, and libjingle candidates were just sent back and
forth with <session action="candidates"> messages.

In the new protocol, there are one or more <transport> nodes in the initial
<session action="initiate"> node that indicate which transports are supported
by the call initiator, and then the call recipient then sends
"transport-accept" to indicate which transport is preferred, and then
candidates are exchanged in "transport-info" messages.

The Windows GTalk client implements a fall-back behaviour where if it receives
any incoming "candidates" actions, then it will assume that a
"transport-accept" has been received for the Google P2P transport, and then
re-transmit any "transport-info" candidates that it has sent as "candidates",
allowing interoperability with old GTalk clients, and also with our
implementation.

This also has the odd side-effect that when we're talking to such a client,
some remote candidates are given twice to libjingle because we actually
correctly parse both the original "transport-info" and the subsequently re-sent
"candidates" messages, although this causes no real ill-effects.

It's possible that even other clients at Google, such as their Flash gadget,
and certainly almost all other 3rd party implementations of the GTalk protocol,
don't have support for receiving "candidates" messages, meaning either that at
best we'll get errors and the call will fail immediately, or at worst the
connection will never be established because they believe we never sent them
any candidates.

This harms interoperability and should be addressed by implementing the same
fall-back behaviour as the Windows GTalk client, and then confirming that calls
can still be established with it, and with older Gabble versions. Given that
Jingle doesn't have the concept of transport negotiation any more, and the
caller just selects a transport based on the recipient's capabilities, we
shouldn't implement any transport negotiation beyond including <transport
xmlns="gtalk-p2p"> in our google session offers, recognising when we're sent
<transport xmlns="gtalk-p2p"> in an offer, and replying with the appropriate
"transport-accept".

For further bonus points, the session mode (GTalk vs Jingle) should determine
which actions we consider valid - in current standard Jingle, we shouldn't use
"transport-accept" or "candidates" messages for example. This will help avoid
any confusion where our pretend gtalk transport negotiation is used when
actually talking to an old Jingle implementation, although it's not likely to
be a very common occurence.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.