When multiple nat traversal mechanisms are supported, the choice which one is used is not made when the channel is created, but when the new streams are (created for incoming streams, requested for outgoing streams). Currently nat-traversal is property of Channel, and it is assumed that it's known at channel creation time (e.g. for gabble it used to be only gtalk-p2p). One workaround is to change the property when the real data is known. If changed mid-flight when really selected mechanism is known, the clients might or might not pick up the change in time (assumed they're listening to property change signals) before they start initiating media stuff for stream that needs to have this information (e.g. creating a farsight stream as a response to StreamAdded), so this is very fragile. The other reason is that on some protocols (e.g. xmpp/jingle) it is possible (however unlikely) to have two different transport mechanisms for two different streams in a single channel. This cannot work at all with the current API.
Stealing this bug from Senko. I'm going to work on updating Senko's RelayInfo spec branch, which is related.
As a complement of information, the version of WLM that introduced the ICE-6-like NAT traversal is WLM 8.5. so we can have WLM85 and WLM2009 NAT traversal mecanisms.
Fixed in my relayinfo branch, which has been implemented in telepathy-gabble and telepathy-farsight but not yet merged. Awaiting review from the telepathy-spec cabal (please review everything since Will's last commit). http://git.collabora.co.uk/?p=user/smcv/telepathy-spec-smcv.git;a=shortlog;h=refs/heads/relayinfo
*** Bug 17840 has been marked as a duplicate of this bug. ***
Fixed in 0.17.22
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.