Re: H.320 gateways a MEGACO / ITU
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 thereby be able to decode it) to determine what to let through and not.
Regards
Flemming Andreasen
Matt Holdrege matt@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@mailbag.cps.intel.com
To: ITU-SG16@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 data.
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.
Melinda
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
your
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@ithaca-viennasys.com
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 thereby be able to decode it) to determine what to let through and not.
Regards
Flemming AndreasenMatt Holdrege matt@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@mailbag.cps.intel.com
To: ITU-SG16@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 data.
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.
Melinda
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
your
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@ithaca-viennasys.com
I absolutely agree, but we're finding that the reality is that network operators are using firewalls to provide host protection, not data protection, per se.
Melinda
At 10:06 AM 3/31/99 -0800, Matt Holdrege wrote:
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.
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@ithaca-viennasys.com
Yes, but protection does not mean using NAT. Saying that we shouldn't use PER because it won't work well with NAT is a red herring. Service providers do not need to use NAT and should not be encouraged to use NAT.
Please check out http://www.ietf.org/html.charters/nat-charter.html to find out more about NAT.
At 01:53 PM 3/31/99 -0500, Melinda Shore wrote:
I absolutely agree, but we're finding that the reality is that network operators are using firewalls to provide host protection, not data protection, per se.
Melinda
At 10:06 AM 3/31/99 -0800, Matt Holdrege wrote:
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.
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@ithaca-viennasys.com
Hello? I wasn't talking about NAT in particular, I was talking about firewalling/packet filtering in general.
Melinda
At 12:58 PM 3/31/99 -0800, Matt Holdrege wrote:
Yes, but protection does not mean using NAT. Saying that we shouldn't use PER because it won't work well with NAT is a red herring. Service providers do not need to use NAT and should not be encouraged to use NAT.
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@ithaca-viennasys.com
So why specifically does PER have a problem with firewalling/packet filtering?
At 04:12 PM 3/31/99 -0500, Melinda Shore wrote:
Hello? I wasn't talking about NAT in particular, I was talking about firewalling/packet filtering in general.
Melinda
At 12:58 PM 3/31/99 -0800, Matt Holdrege wrote:
Yes, but protection does not mean using NAT. Saying that we shouldn't use PER because it won't work well with NAT is a red herring. Service providers do not need to use NAT and should not be encouraged to use NAT.
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@ithaca-viennasys.com
There's a problem in that it makes the signaling channel sufficiently complicated to parse that you end up having to put a proxy, or something that looks an awful lot like a proxy, on the firewall in order to pick up dynamically-allocated address/port tuples. This has somewhat negative architectural implications in that in a multi-firewall environment (which is, alas, the norm when traversing multiple administrative domains) you end up with tandemed signaling loops.
The short answer is that IP is supposed to be end-to-end and that firewalls create a big disconnect between the IP network and the IP telephony application-layer network.
Melinda
At 01:26 PM 3/31/99 -0800, Matt Holdrege wrote:
So why specifically does PER have a problem with firewalling/packet filtering?
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@ithaca-viennasys.com
I think we have a terminology problem here. I'll try again.
A firewall does NOT affect the end-to-end nature of IP. NAT DOES affect the end-to-end nature of IP. When you add a NAT function to a firewall it WILL cause problems for PER. A firewall that does not use NAT will NOT cause problems for PER.
A service provider that wants to protect their internal hosts or networks does NOT need to use NAT. Therefore this whole discussion is pointless. :)
At 04:45 PM 3/31/99 -0500, Melinda Shore wrote:
There's a problem in that it makes the signaling channel sufficiently complicated to parse that you end up having to put a proxy, or something that looks an awful lot like a proxy, on the firewall in order to pick up dynamically-allocated address/port tuples. This has somewhat negative architectural implications in that in a multi-firewall environment (which is, alas, the norm when traversing multiple administrative domains) you end up with tandemed signaling loops.
The short answer is that IP is supposed to be end-to-end and that firewalls create a big disconnect between the IP network and the IP telephony application-layer network.
Melinda
At 01:26 PM 3/31/99 -0800, Matt Holdrege wrote:
So why specifically does PER have a problem with firewalling/packet
filtering?
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@ithaca-viennasys.com
This problem is independent of the type of encoding being used (PER or text). The problem that you describe is related more to the use of dynamic ports which prevents simple packet filtering. An h.323 proxy must parse the call signalling and H.245 messages to find the dynamic ip address/port pair assignments. The h.323 proxy will be required whether the encoding is asn.1 or text or anything else.
Gary
------------------------ From: Melinda Shore shore@ITHACA-VIENNASYS.COM Subject: Re: H.320 gateways a MEGACO / ITU Date: Wed, 31 Mar 1999 16:45:05 -0500 To: ITU-SG16@MAILBAG.INTEL.COM
There's a problem in that it makes the signaling channel sufficiently complicated to parse that you end up having to put a proxy, or something that looks an awful lot like a proxy, on the firewall in order to pick up dynamically-allocated address/port tuples. This has somewhat negative architectural implications in that in a multi-firewall environment (which is, alas, the norm when traversing multiple administrative domains) you end up with tandemed signaling loops.
The short answer is that IP is supposed to be end-to-end and that firewalls create a big disconnect between the IP network and the IP telephony application-layer network.
Melinda
------------------------------------------------------ Name : Gary A. Thom Company: Delta Information Systems, Inc. Address: 300 Welsh Rd., Bldg 3 Horsham, PA 19044 USA Phone : +1-215-657-5270 Fax : +1-215-657-5273 E-mail : gthom@delta-info.com ------------------------------------------------------
Yes. Going back to my original point about IPsec, if you use AH then you shouldn't need to do port-based filtering. If you don't use port-based filtering and you don't need NAT, then you don't need proxies, right?
And I don't think anything in MEGACO (yet) uses dynamic ports anyway, right?
At 05:08 PM 3/31/99 -0800, Gary A. Thom wrote:
This problem is independent of the type of encoding being used (PER or
text). The problem that
you describe is related more to the use of dynamic ports which prevents
simple packet filtering.
An h.323 proxy must parse the call signalling and H.245 messages to find
the dynamic ip
address/port pair assignments. The h.323 proxy will be required whether
the encoding is asn.1 or
text or anything else.
Gary
From: Melinda Shore shore@ITHACA-VIENNASYS.COM Subject: Re: H.320 gateways a MEGACO / ITU Date: Wed, 31 Mar 1999 16:45:05 -0500 To: ITU-SG16@MAILBAG.INTEL.COM
There's a problem in that it makes the signaling channel sufficiently complicated to parse that you end up having to put a proxy, or something that looks an awful lot like a proxy, on the firewall in order to pick up dynamically-allocated address/port tuples. This has somewhat negative architectural implications in that in a multi-firewall environment (which is, alas, the norm when traversing multiple administrative domains) you end up with tandemed signaling loops.
The short answer is that IP is supposed to be end-to-end and that firewalls create a big disconnect between the IP network and the IP telephony application-layer network.
Melinda
Name : Gary A. Thom Company: Delta Information Systems, Inc. Address: 300 Welsh Rd., Bldg 3 Horsham, PA 19044 USA Phone : +1-215-657-5270 Fax : +1-215-657-5273 E-mail : gthom@delta-info.com
There seems to be a discussion on firewalls, without a common thread.
The problems are several, but relate to the ability of a firewall to identify the address/port pairs in protocol messages. There is also the additional requirement that it understand what they are for, and know what to do with them.
Simply being able to recognize something that looks like an IP address, and possible port number is not enough to do a good job of firewalling. If it means that the firewall is simply going to open every address it sees in data flowing through it, then it is not a very good protection mechanism.
Whether the firewall is prevented from seeing the address information because it is PER-encoded, or because it is triple-DES encrypted, is not particularly material. IP addresses in non-standard or vendor-extension fields will cause the same problems.
While Matt seems to be focused on NAT translating those addresses, I think that Melinda is fixed on firewalls that block everything, but open up for IP addresses in data streams.
Can somebody please explain to this poor old boy, confused by firewalls, how either NAT or firewalls opening dynamic ports work (and especially) when the data stream is encrypted? That is, without opening up the possibility of man-in-the-middle attacks?
Douglas
At 14:36 1999-03-31 -0800, Matt Holdrege wrote:
Yes. Going back to my original point about IPsec, if you use AH then you shouldn't need to do port-based filtering. If you don't use port-based filtering and you don't need NAT, then you don't need proxies, right?
And I don't think anything in MEGACO (yet) uses dynamic ports anyway, right?
At 05:08 PM 3/31/99 -0800, Gary A. Thom wrote:
This problem is independent of the type of encoding being used (PER or
text). The problem that
you describe is related more to the use of dynamic ports which prevents
simple packet filtering.
An h.323 proxy must parse the call signalling and H.245 messages to find
the dynamic ip
address/port pair assignments. The h.323 proxy will be required whether
the encoding is asn.1 or
text or anything else.
Gary
From: Melinda Shore shore@ITHACA-VIENNASYS.COM Subject: Re: H.320 gateways a MEGACO / ITU Date: Wed, 31 Mar 1999 16:45:05 -0500 To: ITU-SG16@MAILBAG.INTEL.COM
There's a problem in that it makes the signaling channel sufficiently complicated to parse that you end up having to put a proxy, or something that looks an awful lot like a proxy, on the firewall in order to pick up dynamically-allocated address/port tuples. This has somewhat negative architectural implications in that in a multi-firewall environment (which is, alas, the norm when traversing multiple administrative domains) you end up with tandemed signaling loops.
The short answer is that IP is supposed to be end-to-end and that firewalls create a big disconnect between the IP network and the IP telephony application-layer network.
Melinda
Name : Gary A. Thom Company: Delta Information Systems, Inc. Address: 300 Welsh Rd., Bldg 3 Horsham, PA 19044 USA Phone : +1-215-657-5270 Fax : +1-215-657-5273 E-mail : gthom@delta-info.com
You can read RFC 2401 & 2402 to find out about IPsec and AH. And this discussion is about MEGACO/H.GCP which is not the same as H.323.
At 09:31 AM 4/1/99 +1000, Douglas Clowes wrote:
There seems to be a discussion on firewalls, without a common thread.
The problems are several, but relate to the ability of a firewall to identify the address/port pairs in protocol messages. There is also the additional requirement that it understand what they are for, and know what to do with them.
Simply being able to recognize something that looks like an IP address, and possible port number is not enough to do a good job of firewalling. If it means that the firewall is simply going to open every address it sees in data flowing through it, then it is not a very good protection mechanism.
Whether the firewall is prevented from seeing the address information because it is PER-encoded, or because it is triple-DES encrypted, is not particularly material. IP addresses in non-standard or vendor-extension fields will cause the same problems.
While Matt seems to be focused on NAT translating those addresses, I think that Melinda is fixed on firewalls that block everything, but open up for IP addresses in data streams.
Can somebody please explain to this poor old boy, confused by firewalls, how either NAT or firewalls opening dynamic ports work (and especially) when the data stream is encrypted? That is, without opening up the possibility of man-in-the-middle attacks?
Douglas
At 14:36 1999-03-31 -0800, Matt Holdrege wrote:
Yes. Going back to my original point about IPsec, if you use AH then you shouldn't need to do port-based filtering. If you don't use port-based filtering and you don't need NAT, then you don't need proxies, right?
And I don't think anything in MEGACO (yet) uses dynamic ports anyway, right?
At 05:08 PM 3/31/99 -0800, Gary A. Thom wrote:
This problem is independent of the type of encoding being used (PER or
text). The problem that
you describe is related more to the use of dynamic ports which prevents
simple packet filtering.
An h.323 proxy must parse the call signalling and H.245 messages to find
the dynamic ip
address/port pair assignments. The h.323 proxy will be required whether
the encoding is asn.1 or
text or anything else.
Gary
From: Melinda Shore shore@ITHACA-VIENNASYS.COM Subject: Re: H.320 gateways a MEGACO / ITU Date: Wed, 31 Mar 1999 16:45:05 -0500 To: ITU-SG16@MAILBAG.INTEL.COM
There's a problem in that it makes the signaling channel sufficiently complicated to parse that you end up having to put a proxy, or something that looks an awful lot like a proxy, on the firewall in order to pick up dynamically-allocated address/port tuples. This has somewhat negative architectural implications in that in a multi-firewall environment (which is, alas, the norm when traversing multiple administrative domains) you end up with tandemed signaling loops.
The short answer is that IP is supposed to be end-to-end and that firewalls create a big disconnect between the IP network and the IP telephony application-layer network.
Melinda
Name : Gary A. Thom Company: Delta Information Systems, Inc. Address: 300 Welsh Rd., Bldg 3 Horsham, PA 19044 USA Phone : +1-215-657-5270 Fax : +1-215-657-5273 E-mail : gthom@delta-info.com
Hi Matt,
I've read 2401 (IPsec), 2402 (AH), and 2406 (ESP) before. I've also skimmed, but probably not understood, the ones on IKE and ISAKMP and OAKLEY too. I've just re-skimmed 2401/2/6 and still don't have the answer.
Re-reading the postings, they're about H.323 proxies, call signalling, and H.245 - some people are talking about H.323 rather than megaco/H.gcp, and that's part of the problem: different threads by different people.
My points are several, and relate to firewalls (as noted by the subject change).
In a mode 3 security association:
- neither endpoint is the same -- The inner and outer tunnels could each be either AH or ESP.
Host 1 --- Security ---- Internet -- Security --- Host 2 | Gwy 1 Gwy 2 | | | | | | --Security Assoc 1 (tunnel)- | | | -----------Security Association 2 (tunnel)-----------
where Security Association 2 is ESP, how is SG1 or SG2 going to do packet filtering and port opening?
Or, if SG1/SG2 is a single entity, as in Case 4:
====================================================== | | |============================== | || | | || ---|----------------------|--- || | | | | H1* ----- (Internet) ------| SG2* ---- (Local ----- H2* | ^ | Intranet) | | ------------------------------ could be dialup admin. boundary (optional) to PPP/ARA server
or SG2, here, is "just" a firewall, instead of a Signalling Gateway.
Assuming that the SA between H1 and H2 involves payload encryption, such as ESP, and is call signalling or H.245, how does SG2 cope with finding the IP/port pairs, even in a text based protocol?
My interest extends beyond megaco/H.gcp, and includes Annex G. How do we handle this in the more general case?
Douglas
At 16:05 1999-03-31 -0800, Matt Holdrege wrote:
You can read RFC 2401 & 2402 to find out about IPsec and AH. And this discussion is about MEGACO/H.GCP which is not the same as H.323.
If you are using ESP, there are no worries. The endpoints unwrap the original packet and process it as normal. The firewall doesn't know or care about the original internal packet.
But if we are talking about MEGACO and I originally thought we were, you don't need to use ESP if you don't want to. For security's sake, you may wish to use AH in which case the firewall will simply authenticate the packet and pass it through without any worries.
The only worries are if you are using NAT.
At 11:14 AM 4/1/99 +1000, Douglas Clowes wrote:
Hi Matt,
I've read 2401 (IPsec), 2402 (AH), and 2406 (ESP) before. I've also skimmed, but probably not understood, the ones on IKE and ISAKMP and OAKLEY too. I've just re-skimmed 2401/2/6 and still don't have the answer.
Re-reading the postings, they're about H.323 proxies, call signalling, and H.245 - some people are talking about H.323 rather than megaco/H.gcp, and that's part of the problem: different threads by different people.
My points are several, and relate to firewalls (as noted by the subject change).
In a mode 3 security association:
- neither endpoint is the same -- The inner and outer tunnels could each be either AH or ESP.
Host 1 --- Security ---- Internet -- Security --- Host 2 | Gwy 1 Gwy 2 | | | | | | --Security Assoc 1 (tunnel)- | | | -----------Security Association 2 (tunnel)-----------
where Security Association 2 is ESP, how is SG1 or SG2 going to do packet filtering and port opening?
Or, if SG1/SG2 is a single entity, as in Case 4:
====================================================== | | |============================== | || | | || ---|----------------------|--- || | | | | H1* ----- (Internet) ------| SG2* ---- (Local ----- H2* | ^ | Intranet) | | ------------------------------ could be dialup admin. boundary (optional) to PPP/ARA server
or SG2, here, is "just" a firewall, instead of a Signalling Gateway.
Assuming that the SA between H1 and H2 involves payload encryption, such as ESP, and is call signalling or H.245, how does SG2 cope with finding the IP/port pairs, even in a text based protocol?
My interest extends beyond megaco/H.gcp, and includes Annex G. How do we handle this in the more general case?
Douglas
At 16:05 1999-03-31 -0800, Matt Holdrege wrote:
You can read RFC 2401 & 2402 to find out about IPsec and AH. And this discussion is about MEGACO/H.GCP which is not the same as H.323.
At 19:03 1999-03-31 -0800, Matt Holdrege wrote:
If you are using ESP, there are no worries. The endpoints unwrap the original packet and process it as normal. The firewall doesn't know or care about the original internal packet.
In Melinda's case, and I think it applies to the megaco messages as well, if that pdu contains protocol addresses, and the firewall wants/needs to unblock them (but not translate them), it certainly does care. I think we are talking about firewalls that filter/block all but a few configured ports, and open others when genuine needs are detected.
But if we are talking about MEGACO and I originally thought we were, you don't need to use ESP if you don't want to. For security's sake, you may wish to use AH in which case the firewall will simply authenticate the packet and pass it through without any worries.
Assume for the moment that the MG lives behind a firewall, and the MGC is "out there", communicating on the well known and open port allocated to megaco. An RTP session needs to be opened, on a dynamically allocated port that the firewall is blocking. The session is to be made from another dynamically allocated port, on a different MG, somewhere "out there".
For security reasons, the megaco protocol exchanges between the MGC and MG are encrypted, according to a security association between themselves. The firewall is seeing encrypted pdu's that it cannot examine for addresses. How will media flow to these blocked ports?
I think that the other questions were similar, but the messages were Q.931 setup, or H.245 OLC and the firewall problem was the PER coding. It's worse with ESP/TLS than with PER, but it's still the same-ish problem.
Using AH does not provide privacy. An eavesdropper can snoop dial strings, which can be sensitive. An eavesdropper can spot IP/port pairs, which it knows are going to be opened by the firewall, for targeting denial of service attacks. It would not be impossible to find ESP being used on megaco.
The only worries are if you are using NAT.
And yes, the problem also arises with NAT, where the firewall also wants to _change_ the pdu.
See: http://www.ietf.org/internet-drafts/draft-ietf-nat-protocol-complications-00 .txt :-)
At 11:14 AM 4/1/99 +1000, Douglas Clowes wrote:
Hi Matt,
I've read 2401 (IPsec), 2402 (AH), and 2406 (ESP) before. I've also skimmed, but probably not understood, the ones on IKE and ISAKMP and OAKLEY too. I've just re-skimmed 2401/2/6 and still don't have the answer.
Re-reading the postings, they're about H.323 proxies, call signalling, and H.245 - some people are talking about H.323 rather than megaco/H.gcp, and that's part of the problem: different threads by different people.
My points are several, and relate to firewalls (as noted by the subject change).
In a mode 3 security association:
- neither endpoint is the same -- The inner and outer tunnels could each be either AH or ESP.
Host 1 --- Security ---- Internet -- Security --- Host 2 | Gwy 1 Gwy 2 | | | | | | --Security Assoc 1 (tunnel)- | | | -----------Security Association 2 (tunnel)-----------
where Security Association 2 is ESP, how is SG1 or SG2 going to do packet filtering and port opening?
Or, if SG1/SG2 is a single entity, as in Case 4:
====================================================== | | |============================== | || | | || ---|----------------------|--- || | | | | H1* ----- (Internet) ------| SG2* ---- (Local ----- H2* | ^ | Intranet) | | ------------------------------ could be dialup admin. boundary (optional) to PPP/ARA server
or SG2, here, is "just" a firewall, instead of a Signalling Gateway.
Assuming that the SA between H1 and H2 involves payload encryption, such as ESP, and is call signalling or H.245, how does SG2 cope with finding the IP/port pairs, even in a text based protocol?
My interest extends beyond megaco/H.gcp, and includes Annex G. How do we handle this in the more general case?
Douglas
At 16:05 1999-03-31 -0800, Matt Holdrege wrote:
You can read RFC 2401 & 2402 to find out about IPsec and AH. And this discussion is about MEGACO/H.GCP which is not the same as H.323.
participants (5)
-
Douglas Clowes -
Flemming Andreasen -
Gary A. Thom -
Matt Holdrege -
Melinda Shore