![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
Hi Phillip,
~Snip~
Most application protocols work just fine behind NAT.I agree. I am playing games for a really long time and I rarely had ever problems with NATs.
FTP works with an ugly work-around. The main protocol that breaks down is SIP.
Not with the work that was done on NAT traversal.
I am mighty unimpressed by the fact that when I plug the VOIP connector made by vendor X into the wirless/NAT box made by vendor X that I have to muck about entering port forwarding controls by hand. And even less impressed by the fact that a good 50% of the anti-NAT sentiment on this list comes >from employees of vendor X.
STUN does not appear to me to be an architecturally principled approach, it is a work around.
I wonder why you think so. What's the problem with STUN?
The way to fix this situation in my view is to make the NAT box SIP aware by building a SIP proxy capability into the NAT box. The designers of NAT boxes go to great efforts to try to work around applications. Leave approaches such as STUN to the case where you are dealing with a legacy box.
I think that's a really horrible solution.
Ciao Hannes
_______________________________________________ Ietf mailing list Ietf at ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.