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.