Subject: RE: [midcom] Re: More than one NAT in Network-friendlier Midcom

From: "Christian Huitema" <[email-masked]>
Date: Thu, 6 Dec 2001 09:07:05 -0800

> Unfortunately, by definition when someone has a non-routable
> address they aren't directly reachable and some sort of proxy
> or gatekeeper or ALG is going to be required for initial contact.
> NATs bring us back to an age where we had the problem of
> getting traffic between BITNET, uucp, CSNET, etc.

Which is why we should be deploying IPv6 ASAP...

> So, when the proxy receives the first INVITE (I'm not a SIP
> person, so please forgive any gross stupidity here) it's going
> to know where to forward it because the endpoint is registered
> with it.  It forwards on the INVITE, and the endpoint can then
> use midcom to pick up the correct public address.  I'm really
> interested in working on identifying failure modes, so please
> let me know as you find stuff (and you certainly will).

Yes, this is the normal SIP assumption: the initial exchange is through
a proxy that is globally reachable. Many other application have the same
structure, using an IM server, a lobby, a rendezvous server, etc.

-- Christian Huitema

_______________________________________________
midcom mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/midcom

---

From: "Mark Pietras" <[email-masked]>
Date: Thu, 6 Dec 2001 12:14:02 -0600

This whole global routing problem is clearly a serious issue.  On the
surface, it seems to be above our problem space, but it really isn't.  The
solution we choose is highly dependent on how the global routing problem is
solved for a service.  If we're simply trying to enable "grass-roots"
traffic (that is, not enabling a telephony service provider), who is going
to solve this routing problem?  Or more specifically, who is going to pay
for it?  Data service providers who's customers are complaining that their
own NATs are blocking their traffic?  Answering these questions might help
us answer how our problem should be best solved.

That aside, if we focus on the technologies, today, one of the ways Class 4
tandem networks solve the global routing problem in H.323 land is with a
hierarchical deployment of Directory Gatekeepers.  Directory Gatekeepers are
stateless devices that simply forward location requests (LRQs) to other
Gatekeepers that can potentially satisfy the route request (or know what
devices can).  This is fine because the telephony service provider manages
all the devices.  It's not fine for our problem space though, because
there's no way for originating endpoints with resulting routing information
to traverse firewall/NATs protecting destination endpoints (not to mention
getting through their own firewall/NATs).  I suppose you could parallel the
current proposals and have a permanent TCP connection (or UDP with
keep-alives connection) from the endpoints in an address realm to their
parent Gatekeeper in global routing space, but then the Gatekeeper would
have to be in Gatekeeper Routed mode (that is, it proxies the signaling) so
it's solved in the same way.

Interestingly, I think logically the ENUM routing architecture parallels
this Directory Gatekeeper architecture (except using a more standard DNS
system) and will suffer the same address realm setback.  Anyone know
differently?

Anyway, sounds to me like the current proposals are doing just that,
proxying the signaling (and even the media in some circumstances!).  Hence,
decentralized devices must be deployed to keep active sessions open to
clients, be it with TCP or with UDP using keep-alives, such that inbound
connection requests can reach them... this not a terribly attractive
mechanism because it doesn't scale well, and brings me back to the business
case question.  But it appears technically to be our best shot so far...

Input on these issues is desired...

Mark.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Christian Huitema
Sent: Thursday, December 06, 2001 11:07 AM
To: Melinda Shore; Bob Penfield
Cc: midcom
Subject: RE: [midcom] Re: More than one NAT in Network-friendlier Midcom

-- Christian Huitema