Something about jingle branch / upnp / bridge

I found stun resolver don’'t work at all. is it not finished?

after DiscoveryInfo retrieved in resover, public ip is not enough for both side. for best performance, NAT type should be send to other side, so two side may decide the best way to may connection.

btw, Is UPnP is planned to be supported by smack?

is there an auto bridge discover for symmetric NAT or firewall?

I can help NAT test if u guys need help.

Message was edited by: steeven

java uPnP api: UPNPLib

UPnP usage:

after jingle session created, the UDP connection may not be established to candidates.

some additional detects has to be done.

how about add some code to provide a valid UDP socket or some wrapper?

jingleAudio is the only example for jingle, it works on windows platform only.

how about add a “flush jingle service” to tell UDP speed for both side? it’'s usefull.


The Jingle code is definitely too early to test still. That will change over the next couple of weeks.

We plan to integrate STUN support as well as a media proxy for when NAT tunneling fails. UPnP has fallen out of favor lately as far as we can tell – it never got widespread adoption and is too complicated. ICE seems to be the best approach, which we’'re also working on.



for two user behind fire wall, a middle proxy is required, is there some plan about such case?

Jingle supports a relay or ‘‘middle proxy’’ as you call it. The roadmap indicates this will be supported by wildfire.

hello Steeven

If you use a RAW-UDP transport, you MUST send just one IP to other side. Otherwise if you use an ICE-Transport, you should send NAT details, and bridged candidates for example.

For Jive´s first Jingle API we will focus just in RAW-UDP and them add ICE-Trasport as soon as we can.