[VOIPSEC] IPv6 and the demise (or not) ofNAT(wasRe: Interactive Connectivity Establishment (ICE))

[Hadriel Kaplan]

> -----Original Message-----
> From: Randell Jesup [mailto:rjesup at wgate.com]
>         There are "facilities" service providers (cable co's, telco's,
> etc)
> who can put SBC's in the access path, and where there's an implicit
> assumption that the ATA/etc is not mobile, and there are non-facility
> service providers like Vonage, Packet8, etc who can at best install SBC's
> moderately close to users, and quite possibly seriously far from users.
> (Do you plan to have an SBC at a random DSL CO in Outer Nowhere, Poland?
> Are you going to proxy all data through an SBC in the US if they're
> calling
> another VoIP subscriber travelling in Hungary?  Delay?  Loss?  Jitter?
> Even ignoring travel, lots of Vonage/etc customers use SIP devices far
> from any likely infrastructure.)

Yup, I was generalizing to telco carriers, because I think you used that
word and regarding their approach. (no?)  Many non-facility service
providers also use SBCs, and their strategy is different.  As I said, some
(most?) SBCs can release-media if they think they can.  The hard part is
NAT-traversal, but even then they can sometimes do it.  I won't get into the
heuristics of how they make such a decision, as it's probably
vendor-specific.  If the clients do STUN, then media release is even easier.
The goal, though, is usually to require no changes on the clients or NATs.
Thus carrier SBCs don't need STUN/TURN/ICE/NSIS/MIDCOM/UPnP/... to do NAT
traversal - they just use SIP.

If the client needs TURN, then an SBC already does that function logically -
much more cleanly than the TURN protocol.  And TURN also suffers the same
issue you raise - where to locate the TURN servers.  TURN takes hardware
(despite the RFC's apparent best efforts to make it difficult for hardware
to do), and so non-facility vendors have to handle that.  Even if only 1-5%
of NATs/FW are symmetric (and that percentage appears to be regionally
specific), that's enough for major support headaches if you can't fix it.


>         Right (though non-local SBCs cause significant pain/cost/scaling
> issues when relaying).  IF you can find a way to get through the NAT,
> then SBCs (and media proxies) become much less attractive unless you want
> to enforce a telco-like model.

For some reason this mailing list is fixated on SBCs purpose being for media
relay for home NAT traversal.  That's not even in the top 3 feature list.
(nor is their purpose to "enforce a telco-like model")  Any SBC vendor who
plans their long-term strategy on NAT traversal as their reason for
existence is in for a short ride.  Although at the rate the IETF is going
with churning new ICE drafts, and the complexity of it, it may be a longer
ride.

-hadriel