🚀 go-pugleaf

In article <MPG.17d04343f28c6eb8989909@news.charter.net>,
Dave Phelps  <tippenring@deadspam.com> wrote:
>I see. So if I fired up a server instead of my IP phone using a 
>predetermined port number, how would I receive phone calls? I would be 
>taking my phone out of service, because all requests would go to the 
>server instead of my phone.

You'd establish a relationship with the server and agree
upon a port/address pair to which incoming call signaling
streams would be forwarded.

>Alternatively, all calls can relay thru the call manager, and the 
>firewall will allow inbound H.323 traffic to reach the call manager 
>only, which prevents me from making a server public using that security 
>hole (maybe bad design would be a better term than "security hole")
>altogether.

At some point, somebody somewhere has to have a routable
address.  One of the things that I don't like about H.323 
is its overreliance on centralized call signaling (the
gatekeeper, specifically), but it is a device that one
can reasonably expect to have a public address and to be 
a trusted entity within the network.  Endpoints register
with it and that registration can (and should) be authenticated.
There are several different ways of dealing with the firewall
and/or NAT, but even if you don't have the gatekeeper 
making requests directly of the firewall at least you've 
moved the policy point back within the network.  An awful
lot of the complexity comes from a really bad security
model ("put up a firewall, NAT the endpoints, and run
everything through a VPN").
>
>Notably, without NAT, the same problem still exists. Even if I have an 
>organization that uses exclusively public IP's, I still have to open the 
>firewall for the H.323 traffic, where someone could potentially install 
>a server instead of taking their phone calls.
>
>-- 
>Dave Phelps
>Phone Masters Ltd.
>deadspam=tippenring


-- 
     Melinda Shore - Software longa, hardware brevis - shore@panix.com
          If you send me harassing email, I'll probably post it