Ok. I've read the articles here on isaserver.org. I've been through probably the entire msdn library. I have configured our ISA server's H.323 Gatekeeper following the instructions given, step by step. I'm still missing something. The H.323 protocol rules are set, the application rules are set, the Gatekeeper is installed, the internal clients can register with the gatekeeper and make outgoing connections, but external clients cannot connect. Can someone help me? Is there some trick that I don't know about?
Could be a permission problem. Did you see my article on "adventures with the H.323 gatekeeper"? I had a big problem until I turned off authentication and just recreated an "Allow all" rule. However, I believe if you create an H.323 Protocol Rule that allows anonymous access, that will work too.
Yes, actually, I have read your article. It was helpful, but it didn't solve my problem. I have the H.323 Protocol permissions set to allow everything. What's happening is when an external client attempts a connection to an internal client, the internal client gets the accept/reject ringing dialog, and when the user clicks "Accept," NetMeeting flashes with the two users, then drops the call, notifying the external client who placed the call the the user "has not accepted" the call.
Are there other protocols that need to be allowed? It seems like the call is being set up, then the media streams can't get through, and the call is torn down, all in a matter of seconds.
Or do the internal clients need to be SecureNAT? Currently, they are running the Firewall client, but we also had problems configuring the NAT.
Ok. Here's what's happening. External client with our ISA server's external IP as its gateway tries to connect to an internal client with our ISA server's internal IP as its gatekeeper. Netmeeting rings, ISA server shows connection in the active connections. Internal client selects "Accept" and for an instant, both clients show in conference on both machines. Then the call is dropped. Alerts show "IP Packet Dropped" at exactly the time the call was dropped. Help files say this error is because a packet had been blocked by the configuration.
IP Packet filtering is configured to allow everything through.
H.323 Protocol filter is configured to allow any client all access.
H.323 Application filter is configured to allow everything.
So, in short, The call seems to get through, but once the call is set up, something is blocking the stream from getting through.
Those are the exact same symptoms I had! What I did was create an "allow all" protocol rule for the NetMeeting client behind the ISA Server, and that seemed to get it to work. I don't recall if I had to create an "allow all" Site and Content Rule as well, though.
The client was both a Firewall and SecureNAT client. I wonder if the Firewall client only configuration is causing the problem for you?
I went back and reconfigured everything, step by step, the way the articles here at isaserver.org describe, and tried to connect from an external client to the internal client. The internal client flashed the connection, the dropped it. The external client showed success. I tried an experiment: with the external client showing success, I clicked the 'dial' button again. It connected! Obviously there's still something wrong here, and I need to figure out what it is. But it is connecting with this little slight-of-hand.
>What type of connection are you using on the >external interface?
>What type of ISA Server client type are you >using?
Firewall clients only.
>Are the clients registering OK with the >Gatekeeper?
>Are you using phone numbers to call the clients?
It actually takes 3 attempts... the first returns a message that the "Person you are trying to call is not able to use netmeeting," the second shows a connection on the external client and drops the connection on the internal client, and the third connects, showing 3 users in the meeting on the external client and 2 in the internal client. Both machines are running XP Pro, does that make a difference?
Ok. An update. Data-only (requiring security) calls get through. This will server the purposes my company NEEDS, though not what the powers that be WANT. So, here we go. I think that there must be another protocol that needs to be enabled/allowed for the audio/video conferencing abilities. How do I go about this?
IT WORKS! Not a clue how, but there you go. It seems that for some reason, the filters for the HTTP were blocking the media streams. I just started messing with EVERYTHING that was configured, and changing things one by one to allow for everything, and I came across one of the Site filters that was set to all authenticated users, and when I set it to Any request, it worked. I must need to study the H.323 protocol more, I don't remember anything about HTTP being needed for setup.
Anyway, Thanks for all your help. I greatly appreciate it.
I knew it must have been an authentication issue! It had to be either a Protocol Rule or a Site and Content Rule that required authentication that was causing the problem.
Remember that Site rules apply to ALL Protocols, not just HTTP sites. The Content Rules apply only to HTTP requests. Its sort of tricky that they combine Site and Content Rules into one interface, because Content is only for HTTP and tunneled FTP, but sites are for ALL protocols.