Presence and IntComm WG

[Jiri Kuthan <>]

At 11:35 PM 4/8/2004, Candace Holman wrote:
>Thanks Jiri - yes, now I'm hooked on that noisy feedback :).  Does your post 
>mean that we should be able to configure SER to handle this problem on its 
>own?

Absolutely, SER can handle NATs (even if it breaks my e2e feelings).
The strategy is that ideally end-devices handle NAT traversal on
their own using STUN. If that fails, SER detects that based on
use of RFC1918 addresses, rewrites these with public IP addresses
and also (that's the most ugly part) relays media. There is no
better way around it -- so called symmetric NATs cannot be traversed 
in other way than with help of a media relay on the public 
Internet. (Let me know if you need more low-level SER details
on that.)

That's not very esthetic, it consumes bandwidth (up to 300+ kbps
per call with G.711) and introduces latency (long-haul call
Europe<->West Coast takes usually about 180 ms RTT). Bandwidth
impact is easier to deal with: you can configure devices to
prefer reasonable codecs (ILBC is a very good choice as 
opposed to G.711). Latency is harder. Except straight-forward
solutions such as increasing speed of light propagation ;),
we have thought of some "advisory" (as opposed to hard-wired)
linkage between VoIP applications and IP routing.

Non-technological means of improving the situation make sense
too. ISPs begin to tell NAT vendors "we don't buy symmetric
NATs" and that will improve the situation too.

-jiri