[jdev] voicechat again
michael at aurora.gen.nz
Wed Mar 3 06:22:36 CST 2004
> Doesnt STUN have serious problems with symmetric NAT's? (i.e. NATs
> where the port you use on the client is different to the one the
> NAT assigns to you publicly).
Yes (as I understand it) Well, when you say "serious problems" I assume
you mean it can't traverse a symmetric NAT. I guess that is serious if
you have a symmetric NAT, but the fact that it can help with 3 out of the
4 (?) NAT types does seem helpful on the whole. I'm not sure there is any
solution out that that will traverse a symmetric NAT is there? That might
be a case of falling back to P2P or "bad luck, buy a new router".
> As I suggested previously, the most likely to work automatic NAT
> traversal technology will likely be UPnP certainly for home
> ADSL users as it is being built into most ADSL routers, its also
> built into some software NATs like WinXP ICS and Winroute.
Yes - this is true (to a point). But it doesn't have to be an either/or I
think. Those with UPnP enabled routers can use UPnP, those with non-uPnP
routers could use STUN.
Where UPnP falls down (I am told) is where you have cascading NAT's - if
your ISP has NAT'ed your connection at their end (to save IP addresses
etc), your UPnP ADSL router won't help you much.
> Yep this is the point I tried to get across last time this was
> discussed, glad to see other people agree that we should first
> work on P2P voice between two users as I agree that it is the
> most likely use case, and anything more complex like multiuser
> voice chat can always be solved by a different spec just like
> we do with standard chat and MUC.
Yes - although thinking of my phone usage patterns at work, it is quite
common to be in a 1-to-1 conversation, and then have the need to
conference someone in. If it is fairly seamless to change protocols that
is fine, but it would be a pain to have to "hang up" and then "re-dial" to
add the third person.
More information about the JDev