[jdev] voicechat again

[Michael Brown]

> 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.

Michael.