[jdev] voicechat again

[Richard Dobson]

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

Sure course, the only problem I see is that all NAT's ive ever used have all
been symmetic NAT's are there many NAT's that will work with STUN even out
there?.

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

Sure, but in that case STUN wouldnt help you either would it? If you are in
this situation then you are pretty mcuh stuffed, anyone in this situation
should really consider moving ISP's.

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

Sure thats just an implementation issue, even if it does hang up and re-dial
in the background it doesnt have to get the user to do that, it can be as
seemless as the implementor designs it.

Richard