Yes, I guess I'll need some 3rd guy in the middle to allow the two peers to connect to each other (and then, hopefully, communicate directly). But how to you go from a NiceCandidate struct of a peer (which contains several other structs and unions) to, say, a string? Such string could be sent to the 3rd-party and forwarded to the other peer, which would parse it and recreate the NiceCandidate struct, for each received remote candidate... The thing is that I want different platforms to communicate, so there should be some "protocol" to send the candidates info... <div class="gmail_quote">On Fri, Jan 13, 2012 at 8:49 PM, Youness Alaoui <<a href="mailto:youness.alaoui@collabora.co.uk">youness.alaoui@collabora.co.uk</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Hi, Thanks Tiago for taking over while I was asleep! Nice to see all this activity and to have Eduardo's tests successful! :) Having a nat friendly retwork as one of the peers guarantees success, if you have two nat-hostile networks, then it depends on the type of NATs involved, if both are symmetric NATs, then it will fail, if at least one of them is not a symmetric NAT, then it should succeed (c.f. <a href="http://en.wikipedia.org/wiki/Network_address_translation#Methods_of_Port_translation" target="_blank">http://en.wikipedia.org/wiki/Network_address_translation#Methods_of_Port_translation</a> ) libnice does not provide any serialization method, you will still always need a third party server to do the candidate exchange and that will depend on the protocol used by this server, could be XMPP, could be SIP, could be custom, it really all depends on what your needs are and what the server supports/accepts. Youness.</blockquote></div>