H.320 gateways a MEGACO / ITU

Flemming Andreasen fandreas at TELCORDIA.COM
Wed Mar 31 13:33:47 EST 1999

No disagreement on the applicability of IPSEC, however let's not equate
IPSEC, firewalls and a certain policy associated with deployment of a
firewall in given environment. In any case, Intel once produced an
excellent paper on the H.323 firewall topic which interested parties can
access at




Matt Holdrege <matt at ascend.com> on 03/31/99 01:06:17 PM

To:   Flemming Andreasen <fandreas at TELCORDIA.COM>
cc:   ITU-SG16 at mailbag.cps.intel.com (bcc: Flemming Andreasen/Bellcore)
Subject:  Re: H.320 gateways a MEGACO / ITU

I don't believe that is the case, especially with MEGACO/H.GCP or SIGTRAN.
The main reason for using Firewalls in these architectures is to make sure
that unauthorized sources do not send info through the firewall. Also to
make sure that even the authorized sources only send the proper information
through the firewall.

As has been discussed on the MEGACO list, the best way to authenticate and
authorize is to use IPsec. This has absolutely nothing to do with
inspecting the internal payload of the packet.

The only functions that can fully inspect the internals of the packet are
the MG and MGC. Not the firewall.

At 11:38 AM 3/31/99 -0500, Flemming Andreasen wrote:
>It really depends on the type of firewall and the policies associated with
>it. However, in general, whenever you deal with protocols that include
>information about one stream in another stream (e.g. RTP in H.245 or SDP,
>or H.245 in H.225.0) you have a need to peak inside the stream (and
>be able to decode it) to determine what to let through and not.
>          Flemming Andreasen
>Matt Holdrege <matt at ASCEND.COM> on 03/31/99 10:57:14 AM
>Please respond to Mailing list for parties associated with ITU-T Study
>      Group 16 <ITU-SG16 at mailbag.cps.intel.com>
>To:   ITU-SG16 at mailbag.cps.intel.com
>cc:    (bcc: Flemming Andreasen/Bellcore)
>Subject:  Re: H.320 gateways a MEGACO / ITU
>Such as?
>In it's simplest form, a firewall is simply a filter. You can add on IPsec
>functionality and other things, but that wouldn't affect a stream of PER
>At 10:50 AM 3/31/99 -0500, Melinda Shore wrote:
>>Well, it depends.  You've still got the problem of picking up
>>any dynamically-assigned/allocated information, NAT or no.
>>At 07:31 AM 3/31/99 -0800, Matt Holdrege wrote:
>>>To be more accurate, PER may not work fine through a NAT function. If
>>>firewall doesn't do NAT, then PER should have no problems.
>>Melinda Shore
>>Member of the Scientific Staff
>>Nokia IP Telephony
>>127 West State Street
>>Ithaca, New York  14850
>>+1 607 273 0724 x81 (office)
>>+1 607 275 3610 (fax)
>>+1 607 280 0010 (mobile)
>>shore at ithaca-viennasys.com

More information about the sg16-avd mailing list