Using NetMeeting and the H.323 Gatekeeper as a HelpDesk tool

 

Using NetMeeting and the H.323 Gatekeeper as a HelpDesk tool

By Stefaan Pouseele
October 2002

Last Update: 09/08/2003

1. Summary

To remotely support a lot of customers with a wide variety of Windows versions (95, 98, Me, NT, 2K, XP) you have not so many options to do it without extra software on every workstation and server. Recently, we have put together a helpdesk solution for our customer base and used NetMeeting at the customer site in combination with NetMeeting and the H.323 Gateway/Gatekeeper on ISA at the support site. I thought it would be a good idea to share that information, thus providing you an excellent example as a baseline for your own helpdesk solution.

In this article we will look at the following issues:

  • What are the requirements

  • About NetMeeting and the H.323 standard

  • Selecting the right configuration options

  • Implementation and pitfalls

  • What’s in the Firewall log

Note that in this article we will include some Ethereal Network Monitor traces. Ethereal is a free Network Monitor and has a decoder for the Remote Winsock Protocol used by the ISA Firewall client. Moreover, there is a plugin available for decoding the H.323 protocol used by NetMeeting and the ISA H.323 Gateway/Gatekeeper.

If you are interested in getting Ethereal and the H.323 plugin, check out the following links:

2. What are the requirements

2.1. Network configuration

To better understand our environment, the following figure gives you a highly simplified but general overview of how the customers are connected to our network to access the different services:

At the central site we have different security zones (i.e. DMZ, Extranet and Intranet) and some external connections (i.e. Private Network and Internet). The Extranet network houses the servers who are only reachable through the Private Network. So, the customers who are subscribed to the Extranet services, must have a connection to the Private Network. It is for this customers we have built the helpdesk solution discussed in this article. The Intranet network contains our own internal network and is protected by an ISA server. 
It is worth to note that the network Extranet, and the ISA server external interface both uses public routable IP addresses. On the other hand, the Private Network uses the private IP address range 10.0.0.0/8 exclusively. Each customer is allocated a class C (/24) subnetwork out of this private IP address range.

The customers are connected to the Private Network through a router or a firewall. In the latter case they might have further external connections on their own, such as to the Internet. Note however that the firewall is not necessary an ISA server at the customer site. In the case that the customers network is too big to fit in the allocated class C subnetwork, the router or the firewall is doing the necessary Network Address Translation (N:1 NAT or PAT). So, the Private Network is primarily designed for communications initiated from the customer sites to the central site. This has to be taken into account when designing the helpdesk solution. Therefore, the used protocols must be NAT/PAT and firewall friendly.

2.2. Additional considerations

One of the primary  reason we are not satisfied with the classic Remote Control products such as ControlIt ( Computer Associates) and PcAnywhere ( Symantec) is that, apart from being relatively costly, they use the concept of a guest and host. The guest part is used by the support people and the host part is installed on the customer systems. Moreover, it is the guest who must connect to the host first. So, from the customers point of view these are inbound connections. However, if you look at NetMeeting you will see that the communication partner can play his role as a guest or a host, whether the connection was initiated by himself or not. This means you can design a solution where at the customer site only outbound connections are required. In other words,  the majority of the configuration complexity is put on the central support site where it belongs.

Although not all servers at the customer sites are running Windows NT or 2K as operating system, the great majority do. Moreover, we may state that all desktop PC’s actually run at least Windows 95. So, it should be obvious that the helpdesk solution must support the Windows OS’s 95, 98, Me, NT, 2K and XP. To remotely support other types of servers (primarily Unix) and devices (such as routers, hubs and switches), you can first take ‘ownership’ of a local workstation and perform the necessary helpdesk tasks from there. It would be great if the selected helpdesk tool could also be used for pure local helpdesk functions without extra costs.

3. About NetMeeting and the H.323 standard

NetMeeting is a powerful tool that allows real-time communication and collaboration over the Internet or corporate intranet/extranet. NetMeeting supports the international communication standards for audio, video, and data conferencing. More specifically, NetMeeting is built around the H.323 standard. H.323 is an umbrella standard which references many other ITU-T (Telecommunications Standards Sector) recommendations. A simplified overview of the H.323 Packet-based multimedia communications systems can be found in the following figure:

H.323 provides the system and component descriptions, call model descriptions, and call signaling procedures. H.225.0 describes the media (audio and video) stream packetisation, media stream synchronization, control stream packetization, and control message formats. H.245 describes the messages and procedures used for opening and closing logical channels for audio, video, and data, capability exchange, mode requests, control, and indications. These are the recommendations that govern the operation of H.323 equipment and the communications between H.323 endpoints. Other recommendations are referenced for audio and video coding. For audio coding, G.711 is mandatory, while other G.7xx specifications are optional. For video coding, H.261 QCIF mode is mandatory, while other H.26x modes are optional.  H.323 is based on the Real-Time Protocol/Control Protocol (RTP/RTCP) of the Internet Engineering Task Force (IETF). Extensions were provided for call signaling and additional audio and video coding algorithms.

The T.120 series of recommendations is used for data applications. It is also an umbrella standard. The most important application protocols are Whiteboard (T.126 – Multipoint still image and annotation protocol), File Transfer (T.127 – Multipoint binary file transfer protocol) en Application Sharing (T.128 – Multipoint application sharing). It must be noted that the T.120 series of recommendations can be used independent of the H.323 standard.

The gatekeeper is an optional component in a H.323 system and uses the Registration/Admission/Status (RAS) protocol. The primary function of the gatekeeper component is to provide address translation services. This function converts external (telephone number) addresses and alias (name) addresses to network addresses, allowing users to maintain the same telephone numbers or alias addresses regardless of changes to their network addresses.

Note: you can learn more about the functionality and operation of the gatekeeper in a H.323 environment by reading the Cisco article Understanding H.323 Gatekeepers.

When you use NetMeeting to call other users, several TCP and UDP ports are required to establish the connection. The following table shows the used TCP/UDP port numbers and their functions:

Port TCP/UDP Type Protocol NetMeeting Use
389 TCP static LDAP Internet Locator Server (ILS)
522 TCP static ULP User Location Service (deprecated, use ILS)
1503 TCP static T.120 Data conferencing
1719 UDP static RAS

Gatekeeper

1720 TCP static H.225.0 H.323 call setup
1731 TCP static msiccp Audio call control
1024-65535 TCP dynamic H.245 H.323 call control
1024-65535 UDP dynamic RTP/RTCP H.323 streaming (Audio/Video)

It is important to note that the H.323 call setup protocol (TCP port 1720) dynamically negotiates a TCP port used by the H.323 call control protocol. Also, both the audio call control protocol (TCP port 1731) and the H.323 call setup protocol (TCP port 1720) dynamically negotiate UDP ports for use by the H.323 streaming protocol (RTP). Moreover, all TCP connections are outbound, viewed from the calling H.323 endpoint.

Note: more technical information how NetMeeting implements the H.323 standard can be found in the NetMeeting Resource Kit on the Microsoft NetMeeting web site.

4. Selecting the right configuration options

It must be obvious that the H.323 protocol is a rather complex protocol to pass through a firewall if it does not support it explicitely. Lucky for us the ISA server incorporates an intelligent H.323 Application Filter and a Gatekeeper/Gateway functionality to facilitate different H.323 calling scenarios. Let us now examine what configuration options should be used to best fit our goal, taking into account the above mentioned requirements. Also, keep in mind that neither the customers nor we have the hardware needed on the workstations to support the audio/video capabilities of NetMeeting.

4.1. NetMeeting

If you look thoroughly into the NetMeeting Resource Kit, you will find out that NetMeeting can easily be integrated into a Web page (Chapter 6: Using NetMeeting on Intranet Web Pages). Specifically by using a CallTo URL, the Web site creator can specify how users place calls. This is a very powerful method to adapt NetMeeting to your own taste without placing too much configuration burden on the end user. The CallTo URL is also very handy to quickly test different calling scenarios.

The general CallTo URL syntax is CallTo:CallToAddress+Parameter1=Value+…+ParameterN=Value. The following table lists the valid CallTo parameters:

Parameter Syntax Description
Type phone The CallToAddress is a phone number
ip The CallToAddress is an IP address
host The CallToAddress is a computer name
directory The CallToAddress is a directory server
Gateway string Specifies the name of the gateway, for example: +gateway=
myfavoritegateway
Secure true Specifies whether the requested call should be secure. All transmitted data is encrypted. The default value is determined by the setting for Outgoing Calls on the NetMeeting Security tab.
false
Password string Specifies the T.120 password for the call, for example: +password=redcar
This password is encrypted if the call is secure. The default is no password.
Conference string Specifies the name of the conference to join. When the user places a call to a NetMeeting node, by default the user joins any existing NetMeeting conference. When the user places a call to a Multipoint Control Unit (MCU), by default the user is queried about which conference to join.
Data true Specifies whether the call has T.120 data conferencing capabilities. The default value is true.
false
av true Specifies whether the call has audio and video capabilities. The default value is true.
false
H323 true Specifies whether to use the H.323 call model for all calls, including data conferencing calls. The default value is true.
false

Note: if you set a value of true for secure, you are designating a secure, data-only call. Therefore, data is automatically set to true and av is automatically set to false. If you attempt to set these parameters to a different value, the secure call will fail.

NetMeeting supports two calling models: H.323 (h323 = true) and T.120 (h323 = false). If you are only interested in the data conferencing capabilities and not in the audio and video capabilities, then you might choose the T.120 calling model. In that case NetMeeting makes only connections to TCP port 1503. No other protocols or ports are involved.

As an example, an Ethereal trace of a direct T.120 call between two NetMeeting hosts is shown below:

Note: the calling T.120 endpoint has the IP address 192.168.2.2. 

As you can see in the above Ethereal trace, the calling T.120 endpoint sets up four connections to TCP port 1503. The first one (frame 1-2) is teared down after a short while (frame 12 – 15) and therefore I assume this one is used for some preliminary negotiations at the T.120 protocol level. After the setup of the second connection (frame 16 – 17), some further negotiations seems to happen before the third (frame 27 – 28) and fourth (frame 30 – 31) connection are established. It is worth to note that the last two connections are only made after the user at the called T.120 endpoint accepted the incoming NetMeeting call. Also, the last three connections stays open during the lifetime of the NetMeeting session.

It should be clear that the T.120 calling model would be an ideal solution for our helpdesk tool because the network requirements are very low (only one TCP port 1503). Unfortunately, when using the T.120 call model, ISA can’t assist you in routing the inbound T.120 connections to the proper internal workstation. This is only possible if you use the H.323 call model (h323 = true).

In a H.323 call model, the complexity at the communication level can be mitigated a lot if you disable the audio and video capabilities (av = false) and only use the data sharing capability (data = true) of NetMeeting. In that case the communication from the calling H.323 endpoint can be served with a policy of ‘allow all outbound TCP’ to the called H.323 endpoint. Moreover, as we are not interested in audio and video, we can use a secure connection. So, at this point we can already define the following parameters:

  • H323 = true
  • AV = false
  • Data = true
  • Secure = true

As an example, an Ethereal trace of a direct H.323 call between two NetMeeting hosts with the above parameters set is shown below:

Note: the calling H.323 endpoint has the IP address 192.168.2.2. 

As you can see in the above Ethereal trace, the calling H.323 endpoint starts with making a connection to TCP port 1720 (frame 1 – 2). This is the TCP port reserved for the H.323 call setup and it uses the H.225.0 protocol. Next, the H.323 call setup protocol dynamically negotiates a TCP port to be used by the H.323 call control protocol (frame 4 – 9). Then the H.323 call control protocol (H.245) connection is set up (frame 10 – 11) and after some negotiations between the H.323 endpoints (frame 13 – 26) the logical channels for the T.120 data conferencing are set up (frame 27 and following). Take note that the connection setups for the T.120 data conferencing follows exactly the same pattern as within the T.120 calling model.

4.2. ISA Server

As already mentioned before, the ISA server incorporates an intelligent H.323 Application Filter and a Gatekeeper/Gateway functionality. The H.323 Gatekeeper works together with the H.323 protocol filter to provide full communication capabilities to H.323 registered clients using applications that are compliant with H.323 Gatekeeper, such as NetMeeting 3.0 or later. The H.323 Gatekeeper provides registered clients with call routing and directory services and enables others to reach them using their well known aliases.

To learn more about this exciting piece of software and the various call routing scenarios, check out the ISA Help file and the following articles:

One of the main requirements, dictated by our network environment, is that the connections should be outbound viewed from the customer side. Moreover there might be a firewall or NAT/PAT device at the customer site who does not understand the H.323 protocol. Also, we like to use the same infrastructure for the internal helpdesk function. In other words, we can summarize the required call scenarios as follows:

  • only the central H.323 endpoint is behind an ISA Server (no H.323 support at the remote site).
  • both H.323 endpoints are behind the same ISA Server (local helpdesk function).
  • both H.323 endpoints or behind different ISA Servers (H.323 support at the remote site).

It must be obvious that at the central site we need the H.323 Gatekeeper function in order to route the incoming H.323 calls to the right internal workstation. Also, the first call scenario (no H.323 support at the remote site) requires that the remote H.323 endpoint uses the ISA server on the central site as H.323 Gateway. As a consequence, we need to use a Phone Number as H.323 well-known alias or identity for the NetMeeting clients. Let us now examine how using the H.323 Gatekeeper/Gateway on the ISA server changes the behaviour of NetMeeting at the communication level. Don’t worry how things should be configured for proper operation at this moment. We will cover that in the next section.

Communication between the calling NetMeeting and the ISA H.323 Gateway

As an example, an Ethereal trace of a H.323 call from a NetMeeting host using the ISA server as an H.323 Gateway is shown below:

 Note: the calling H.323 endpoint has the IP address 10.0.128.100. The H.323 Gateway has the IP address 193.75.143.3.

If you compare the above trace with the trace of a direct H.323 call between two NetMeeting hosts, you will not see many difference between them. All connections are outbound viewed from the calling NetMeeting host. First the H.323 call setup connection is established (frame 330 – 331). Then the H.323 call control protocol (H.245) connection is set up (frame 350 – 351) and after some negotiations the logical channels for the T.120 data conferencing are set up (frame 405 and following). However, take note that the connection setups for the T.120 data conferencing are not happening on the standard T.120 port (TCP port 1503) but on a dynamically negotiated port between the H.323 Gateway and the H.323 endpoint. This seems to be the only difference between both traces.

In the following figure you see a detailed decode of frame 403 who negotiates the port to be used for the T.120 data conferencing:

Note: the calling H.323 endpoint has the IP address 10.0.128.100. The H.323 Gateway has the IP address 193.75.143.3.

Communication between the called NetMeeting and the ISA H.323 Gatekeeper

As already said, the H.323 Gatekeeper works together with the H.323 protocol filter to provide full communication capabilities to H.323 registered clients. In the following Ethereal trace you see how the internal client registers with the H.323 Gatekeeper through the Registration/Admission/Status or RAS  protocol:

Note: the called H.323 endpoint has the IP address 172.16.16.19. The H.323 Gatekeeper has the IP address 172.31.0.1.

Remember that the RAS protocol runs on UDP port 1719. As seen in the above trace, we can roughly devide the protocol elements into three groups: Registration/Unregistration (frame 286, 287, 610, 611), Admission/Disengage (frame 319, 321, 594, 595) and InfoRequest (frame 455 – 573). When NetMeeting is configured to use a H.323 Gatekeeper, it will try to register with the Gatekeeper on startup. In the above detailed view of the RegistrationRequest you can clearly see with which aliases (terminalAlias H323_ID and E164) the client registers himself. If you exit NetMeeting, the client will first unregister himself with the Gatekeeper. The InfoRequest packets must be interpreted as a  keep-alive message. If the Gatekeeper doesn’t see those messages on a regular interval, it will assume that the H.323 client is no longer alive and will unregister the client automatically. The Admission/Disengage packets appears whenever an H.323 call is setup or teared down.

Note: if you look carefully at the above trace, you should see something very odd. The H.323 Gatekeeper has the IP address 172.31.0.1 but the packets sent by the Gatekeeper have as source IP 172.31.0.10. I’m not sure why this is happening, but the IP address 172.31.0.10 is in our case assigned to the virtual VPN interface of the ISA server. Probably the Gatekeeper was at that time also bound to the WAN (PPP/SLIP) interface. For more info, check out ‘5.1. Configure the ISA server’.

As an example, an Ethereal trace of an inbound H.323 call to a NetMeeting host using the ISA server as an H.323 Gatekeeper is shown below:

Note: the called H.323 endpoint has the IP address 172.16.16.19. The H.323 Gatekeeper has the IP address 172.31.0.1.

If you compare the above trace with the trace of a direct H.323 call between two NetMeeting hosts, you will not see many difference between them. The two most important differences are the IP address of the host initiating the connection and an additional RAS protocol negotiation. In the above trace you can clearly see that the IP address of the host initiating the connection is 172.31.0.1. This is the IP address assigned to the ISA internal interface and the one the H.323 Gatekeeper is listening on. So, the ISA server is effectively proxying the H.323 inbound calls. When the internal NetMeeting client receives the initial call on TCP port 1720, it will first contact the H.323 Gatekeeper with an AdmissionRequest RAS protocol element (frame 319) to check if it is allowed to accept the incoming H.323 call and which options it may use. After confirmation from the H.323 Gatekeeper (frame 321) it will proceed the H.323 negotiation as usual.

Communication between the calling NetMeeting and the ISA H.323 Gatekeeper

As a last example, an Ethereal trace of an H.323 call between two NetMeeting hosts, both using the same ISA server as an H.323 Gatekeeper is shown below:

 Note: the calling H.323 endpoint has the IP address 172.16.16.19. The H.323 Gatekeeper has the IP address 172.31.0.1.

Apart from the RAS Admission negotiation with the H.323 Gatekeeper, the above trace shows clearly that the sequence is identical as in the case of two NetMeetings calling each other directly. A detailed view of the RAS Admission negotiation is shown in the figure below:

 Note: the calling H.323 endpoint has the IP address 172.16.16.19. The H.323 Gatekeeper has the IP address 172.31.0.1.

The calling H.323 endpoint uses an E164 Alias (in NetMeeting terms a Phone Number) to locate the other party. The H.323 Gatekeeper returns in the RAS AdmissionConfirm protocol element the IP-address and port number of the corresponding host (destCallSignalAddress) and instructs the calling station to make a direct call (callModel).

5. Implementation and pitfalls

5.1. Configure the ISA server

With the above knowledge and assuming that the basic ISA configuration is well done, the necessary configuration steps are quite easy to perform. The first step is to configure the H.323 Application Filter. This Application Filter is enabled by default. However, if for some reason it becomes disabled, you will not be able to use the H.323 services.

At the central site we configure the H.323 Application Filter as shown in the figure below:

For the Gatekeeper location option, enable ‘Use this Gatekeeper’ and configure it with the IP Address or DNS name of the ISA Internal interface. Because we only want to accept H.323 calls for Data Conferencing, we only enable ‘Allow incoming calls’ in the Call Direction option and ‘Allow T.120 and application sharing’ in the Media Control option.

The second step is to install and configure the H.323 Gatekeeper. As the H.323 Gatekeeper service is an add-in to the base ISA Server installation, you can install it at the same time with the core ISA Server components, or you can install it afterwards. Once installed, there isn’t too much configuration to be done. Just make sure that you configure the Gatekeeper service to listen only on the real internal interface of your ISA Server. In our case, the Gatekeeper is bound to the ISA internal interface (172.31.0.1) as shown in the figure below:

Note 1: in our case we installed the Gatekeeper afterwards. When we restarted the ISA server, the ISA services won’t startup again. In the Event log we got the following errors:

  • Application log: Microsoft ISA server, EventID 14192, Service Control Manager EventID 7024: Microsoft ISA Server Control Service failed to start because the operating system service Routing and Remote Access is already running. To fix this problem use ISA Server setup to reinstall ISA.
  • System log: Service Control Manager, EventID 7024, The Microsoft ISA Server Control service terminated with service-specific error 278540.

If you run into that problem, you should grab the RRAS_Fix.vbs script and run it on the ISA server. It will give RRAS back the ISA Control Service dependency it lacks.

Note 2: after solving the above problem, we started testing the registration of a local NetMeeting to the Gatekeeper service on ISA. We were very surprised it did not work as expected. The client was configured as Web Proxy, Firewall and SecureNAT client. It turns out that in our case the RAS registration protocol was intercepted by the Firewall client and redirected to the ISA Firewall service. This shouldn’t happen because the Gatekeeper is the ISA internal interface and is contained in the LAT. 
The solution was to change the Firewall client properties on ISA to always resolve DNS names locally: add entry [Common Configuration] with parameter NameResolution=L. This is very well explained in the article ISA Clients – Part 3: The Firewall Client by Jim Harrison. However, I can’t explain why it resolved the problem.

Note 3: you might get the following errors in the Event Application log:

  • Microsoft H.323, ID 21056: An error has been returned by the API. API error code: 00002751H. API error text: A socket operation was attempted to an unreachable host.
  • Microsoft H.323, ID 21075: Failed to create a RAS context for the IP address 172.31.1.10. Please insure that no other application or service is using the H.225 RAS ports (1719 and 1718). Context status code: 00002751H Context status text: A socket operation was attempted to an unreachable host.

To solve that problem, go to the H.323 Gatekeepers node in the MMC. Right click on your ISA server and chose properties. In the Network tab, uncheck the WAN (PPP/SLIP) interface. In other words, make sure the Gatekeeper is only bound to the real internal interface.

If the customers also have an ISA server, it should also be configured properly. Although you could install the Gatekeeper services on their ISA server too and configure H.323 routing rules, this is not strictly necessary because we only need outbound H.323 calls for Data Conferencing. So, here we will only outline the minimal configuration steps you should perform.

At the customer site we configure the H.323 Application Filter as shown in the figure below:

For the Gatekeeper location option, don’t enable ‘Use this Gatekeeper’. Because we only want to place H.323 calls for Data Conferencing, we only enable ‘Allow outgoing calls’ in the Call Direction option and ‘Allow T.120 and application sharing’ in the Media Control option.

Next, you have to enable the H.323 protocol in a protocol rule and make sure there is a site&content rule who allows access to the central ISA server. Remember that with this configuration, the ISA server at the central location plays the role of H.323 Gateway for the customer sites.

5.2. Configure the NetMeeting clients

After the H.323 infrastructure was in place, we could start using NetMeeting as a helpdesk tool. However, there are more than three thousand possible NetMeeting clients at the remote sites and we want to place nearly all the NetMeeting configuration burden on the central site. Moreover, at the central site we do want to protect ourself as much as possible from unsolicited incoming H.323 calls. This turned out to be a real challenge, but we succeeded with the help of the NetMeeting Resource Kit, a static web page and a HTML application with some VB scripting.

To prevent unsolicited incoming H.323 calls at the central site, we must make the H.323 Aliases (in NetMeeting terms account name and phone number) dynamic. Normally, you define once the account name and phone number in the Advanced Calling Options tab in NetMeeting. In a short while we will see how we solved that problem. At this moment all you need to know is how we built the account name and phone number.
For the whole central site we defined a prefix that equals the telephone number of our company. Each user at the central site has been assigned an unique three digit number called conference_ID and an initials (letters). The NetMeeting phone number is constructed by concatenating the prefix, conference_ID and a five digit random number called pincode. The NetMeeting account name is built by the string conference_ID-pincode-initials.

For the customers we created a static web page and added the NetMeeting ActiveX control to it. The result can be seen in the figure below:

The upper part of the web page holds a form where the customer enters the necessary connection parameters. First he must select the proper connection type (field labeled as Verbindingstype). He has the choice between H.323 Gateway or H.323 Gatekeeper, both in two flavours: secure and unsecure. Next he must fill in the fields Conference ID (labeled as Conferentie ID) and Pincode (labeled as Pincode).
In the lower part of the web page you’ll find the embedded NetMeeting view in DataOnly mode with three buttons: Place a Call (labeled as Conferentie Starten), End a Call (labeled as Conferentie Stoppen) and Undock NetMeeting (labeled as Open in Nieuw Venster).

When a customer is invited to participate in a helpdesk session, he must browse to the well known helpdesk web page. This will automatically start NetMeeting at the customers workstation. He will receive by telephone the Conference ID and Pincode. After selecting the right connection type (I assume here H.323 Gateway Secure) and entering the information, he just needs to push the button Place a Call. By doing this, a CallTo URL is launched with as CallToAddress the concatenation of the prefix (hardcoded in the web page), conference_id (content of the field Conference ID) and pincode (content of the field Pincode), followed by the parameters “+Type=phone+gateway=DNS_name_gateway+H323 = true+AV = false+Data = true+Secure = true”.

Note 1: you probably wonder why we give the customer the option between a secure and an unsecure H.323 data call. We have found quit a number of NetMeeting installations where the NetMeeting certificate is not properly created. Therefore those customers can not place a secure NetMeeting Data call. Until all those NetMeeting installations are fixed (and we have not yet found a quick way of doing it), the customer may place an unsecure NetMeeting Data call.

Note 2: if NetMeeting is configured for using a Gatekeeper and the CallTo URL contains the parameter ‘gateway’, NetMeeting seems to ignore this parameter. As a consequence we can probably drop the entries for H.323 Gatekeeper in the connection type selection box.

For the central site we created a HTML application and added the NetMeeting ActiveX control to it. The result can be seen in the figure below:

As you can see, the layout is very simular to the static web page used by the customers. However, there is happening much more behind the scenes and that is exactly the reason why we use a HTML application (HTA) instead of a regular web page. Moreover, this application not only can be used as a helpdesk tool for our customers and internal users, but also to remotely control internal Windows NT4 servers with NetMeeting installed in Remote Desktop Sharing mode.

At the central site we have a Windows 2000 network with Active Directory and nearly all workstations are running Windows 2000 Professional or higher. The basic idea is to add the user specific information for NetMeeting (conference_ID and initials) to the properties of the user in the Active Directory. In that way we can manage centrally all the information about a certain user. More specifically, we are interested in the following information of each user to automatically configure the NetMeeting for that user: first name, last name, initials, E-mail and IP phone. We populate the field IP phone with the assigned conference_ID for that user.

The HTML application performs the following tasks:

  • On startup, check if NetMeeting is already running. If that’s the case, the user is instructed to exit the current NetMeeting session.
  • Determine the local computer name and user name of the currently logged in user.
  • Read the information first name, last name, initials, E-mail and IP phone out of the Active Directory for the currently logged in user.
  • Generate a random 5 digit pincode.
  • Reconfigure NetMeeting with the help of the above gathered information.
  • Write the HTML page and activate the NetMeeting ActiveX control.

As a result, each time NetMeeting is launched through the HTML application, it will register himself with a different phone number and account name to the Gatekeeper running on ISA server. Because ISA is used as H.323 Gateway for the external users, we use only phone based routing rules. Therefore, in the upper part of the web page we added a third column to display the dynamically assigned Conference ID and Pincode to the internal user.

To make the above possible, the VB scripting part uses the Windows Management Instrumentation (WMI) scripting API. You can find some very nice and useful scripting examples at the Microsoft Scripting Center. WMI is included when you install Windows 2000, Windows XP, or Windows Millennium Edition (Me). For those running Windows 95 OSR 2, Windows 98 or Windows NT 4.0, a WMI installation package can be downloaded from Microsoft MSDN which offers similar functionality as WMI in Windows 2000, Windows XP, and Windows Me.

Note: the NetMeeting configuration settings are stored in the registry at the locations
HKEY_CURRENT_USER\Software\Microsoft\Conferencing and
HKEY_CURRENT_USER\Software\Microsoft\User Location Service\Client.

Let us now walk through the three possible scenarios supported by the HTML application:

  • Invite a customer to participate in a helpdesk session
    The helpdesk user starts up the HTML application. Next, he gives the displayed Conference ID and Pincode to the customer by telephone. Note that the customer can also be another internal user. The customer fills in the form and pushes the button for placing a call. Normally, the helpdesk user should get now the standard NetMeeting popup for an incoming call. After accepting the call, he can start his work.
  • Be invited to participate in a helpdesk session
    In this scenario the internal user is the customer. So, he fills in the form with the Conference ID and Pincode he has received by telephone and pushes the button for placing a call.
  • Remotely control an internal Windows NT4 server
    To make this possible, we added a new entry T.120 Remote Desktop Sharing to the connection type selection box. If this entry is selected, the user should enter the DNS name of the internal server into the Conference ID or Pincode field and pushes the button for placing a call. In that case a CallTo URL is launched with as CallToAddress the concatenation of the conference_id (content of the field Conference ID) and pincode (content of the field Pincode), followed by the parameters “+type=host+secure=true+h323=false+av=false”.

You wonder probably why we use for the last scenario the T.120 calling method. There is a good reason for that. To place a H.323 call to another internal host, this host must be registered with the H.323 Gatekeeper. Now, when NetMeeting runs in Remote Desktop Sharing mode, it can’t register with the H.323 Gatekeeper. Although it is possible to make a static registration for this hosts in the H.323 Gatekeeper, this is not a good idea from a security point of view. If you do that, it will work but this means also that any external user can make a H.323 call to this internal host without any intervention from an internal user. It must be obvious that this is far from being recommended.

6. What’s in the Firewall log

If something isn’t working as expected, you should consult the ISA logfiles. They are your primary resource for debugging. To get the most information out of the logfiles, I strongly recommend to enable the logging of all fields. In the MMC, go to the node Monitoring Configuration, then select Logs. In the details pane, right-click the applicable service and then click Properties. On the Fields tab, click Select All.
A lot of people seem to have problems with interpreting the logfiles. It isn’t that difficult, but you should first understand what is logged. In the ISA helpfile there is a section called Firewall and Web Proxy log fields, a must read. Additional information can be found in the following articles:

It is always useful if you have some examples of Firewall log entries at hand as a reference. So, let us now show you some excerpts from the Firewall log for a successful outbound and inbound NetMeeting connection. The scenario used is that both H.323 endpoints or behind different ISA Servers. At the customer site, the ISA server is configured with just the H.323 Application filter. At the central site, the ISA server is configured as H.323 Gatekeeper for the local NetMeeting client and used as H.323 Gateway by the remote NetMeeting client. Take note that both excerpts are from the same NetMeeting session.

6.1. Communication between the calling NetMeeting and the ISA H.323 Gateway

As an example, an excerpt from the Firewall log at the customer site is shown below. The calling NetMeeting host has the IP address 10.0.129.21. The H.323 Gateway has the IP address 193.75.143.3:

       c-ip     time         r-ip r-port cs-prot cs-trans  s-oper sc-stat rule#1  rule#2  sessid connid
10.0.129.21 14:16:48 193.75.143.3 1720 1720 TCP Connect 0 H.323 INTERNT 12 45
10.0.129.21 14:16:49 193.75.143.3 7381 7381 TCP Connect 0 H.323 INTERNT 12 46
10.0.129.21 14:16:49 193.75.143.3 7384 7384 TCP Connect 0 H.323 INTERNT 12 47
10.0.129.21 14:16:50 193.75.143.3 7384 7384 TCP Connect 0 H.323 INTERNT 12 48
10.0.129.21 14:17:00 193.75.143.3 7384 7384 TCP Connect 0 H.323 INTERNT 12 49
10.0.129.21 14:17:00 193.75.143.3 7384 7384 TCP Connect 0 H.323 INTERNT 12 50
10.0.129.21 14:17:25 193.75.143.3 7384 7384 TCP Connect 20000 H.323 INTERNT 12 47
10.0.129.21 14:25:25 193.75.143.3 1720 1720 TCP Connect 20000 H.323 INTERNT 12 45
10.0.129.21 14:25:25 193.75.143.3 7384 7384 TCP Connect 20000 H.323 INTERNT 12 49
10.0.129.21 14:25:25 193.75.143.3 7381 7381 TCP Connect 20000 H.323 INTERNT 12 46
10.0.129.21 14:25:25 193.75.143.3 7384 7384 TCP Connect 20000 H.323 INTERNT 12 50
10.0.129.21 14:25:25 193.75.143.3 7384 7384 TCP Connect 20000 H.323 INTERNT 12 48

Note: for better readability, I removed the less important fields and abbreviated some of the remaining field names.

If you compare the above Firewall log with a previous shown Ethereal trace of a H.323 call from a NetMeeting host using the ISA server as an H.323 Gateway, you should find exactly the same sequence of connections. All connections are outbound viewed from the calling NetMeeting host. First the H.323 call setup connection is established (connection id = 45) on the wellknown TCP port 1720. Then the H.323 call control protocol (H.245) connection is set up (connection id = 46) on a dynamically negotiated TCP port (in this case 7381) and after some negotiations the logical channels for the T.120 data conferencing are set up (connection id = 47, 48, 49 and 50). As already mentioned previously, the connection setups for the T.120 data conferencing are not happening on the standard T.120 port (TCP port 1503) but on a dynamically negotiated TCP port between the H.323 Gateway and the H.323 endpoint (in this case TCP port 7384).

6.2. Communication between the called NetMeeting and the ISA H.323 Gatekeeper

As an example, an excerpt from the Firewall log at the central site is shown below. The called NetMeeting host has the IP address 172.16.16.19. The ISA server at the customer site has the IP address = 10.0.128.100:

        c-ip     time         r-ip r-port cs-prot cs-trans  s-oper sc-stat rule#1  rule#2 sessid connid
172.16.16.19 14:18:06 - 1720 1720 TCP Bind 0 - - 16627 131326
172.16.16.19 14:18:06 - 0 1720 TCP Listen 0 - - 16627 131326
172.16.16.19 14:18:06 10.0.128.100 25962 1720 TCP Accept 0 - - 16627 131326
172.16.16.19 14:18:06 - 1720 1720 TCP Bind 20000 - - 16627 131326
172.16.16.19 14:18:06 - 0 0 TCP Bind 0 SPECIAL - 16627 131328
172.16.16.19 14:18:06 - 7381 0 TCP Listen 0 - - 16627 131328
172.16.16.19 14:18:06 10.0.128.100 25968 0 TCP Accept 0 SPECIAL - 16627 131328
172.16.16.19 14:18:07 - 0 0 TCP Bind 0 SPECIAL - 16627 131329
172.16.16.19 14:18:07 - 7383 0 TCP Listen 0 - - 16627 131329
172.16.16.19 14:18:07 - 0 0 TCP Bind 0 SPECIAL - 16627 131330
172.16.16.19 14:18:07 - 7384 0 TCP Listen 0 - - 16627 131330
172.16.16.19 14:18:07 - 0 0 TCP Bind 20000 SPECIAL - 16627 131329
172.16.16.19 14:18:07 10.0.128.100 25966 0 TCP Accept 0 SPECIAL - 16627 131330
172.16.16.19 14:18:08 10.0.128.100 25966 0 TCP Accept 20000 SPECIAL - 16627 131330
172.16.16.19 14:18:08 10.0.128.100 25964 0 TCP Accept 0 SPECIAL - 16627 131330
172.16.16.19 14:18:17 10.0.128.100 25960 0 TCP Accept 0 SPECIAL - 16627 131330
172.16.16.19 14:18:17 10.0.128.100 25958 0 TCP Accept 0 SPECIAL - 16627 131330
172.16.16.19 14:26:15 10.0.128.100 25964 0 TCP Accept 20000 SPECIAL - 16627 131330
172.16.16.19 14:26:15 10.0.128.100 25960 0 TCP Accept 20000 SPECIAL - 16627 131330
172.16.16.19 14:26:15 10.0.128.100 25958 0 TCP Accept 20000 SPECIAL - 16627 131330
172.16.16.19 14:26:15 10.0.128.100 25968 0 TCP Accept 20000 SPECIAL - 16627 131328
172.16.16.19 14:26:15 10.0.128.100 25962 1720 TCP Accept 20000 - - 16627 131326
172.16.16.19 14:26:15 - 0 0 TCP Bind 20000 SPECIAL - 16627 131330

Note: for better readability, I removed the less important fields and abbreviated some of the remaining field names.

If you compare the above Firewall log with a previous shown Ethereal trace of an inbound H.323 call to a NetMeeting host using the ISA server as an H.323 Gatekeeper, you should find exactly the same sequence of connections. All connections are inbound viewed from the called NetMeeting host. First the H.323 call setup connection is established (connection id = 131326) on the well known TCP port 1720. Then the H.323 call control protocol (H.245) connection is set up (connection id = 131328) on a dynamically negotiated TCP port (in this case 7381). Next, two listeners are set up (connection id = 131329 and 131330) on the TCP ports 7383 and 7384. Shortly thereafter, one of them is closed down (connection id = 131329). I’m not sure why this is happening, but I assume it has something to do with the fact that during the H.245 negotiations both parties try to open a logical channel and only one is accepted. In any case, the one staying open (connection id = 131330) is used as listener for setting up the logical channels for the T.120 data conferencing (r-ip = 10.0.128.100; r-port = 25958, 25960, 25964 and 25966). Remember that the connection setups for the T.120 data conferencing are not happening on the standard T.120 port (TCP port 1503) but on a dynamically negotiated TCP port between the H.323 Gateway and the H.323 endpoint (in this case TCP port 7384).

7. Conclusion

This helpdesk solution works very well for us and our customers. The most time consuming part of the design was coming up with a solution to automate as much as possible the configuration of the NetMeeting clients at the central and the customer sites. I hope that this article gives you sufficient information to let you learn as much as I have done about some aspects of the NetMeeting client and the H.323 support provided by the ISA server.

As a last note, I would like to comment on the new feature Remote Assistance in Windows XP and dot Net. The feature Remote Assistance delivers the same functionality as Netmeeting for the purpose of setting up a helpdesk, but it is based on the RDP protocol (Terminal Service protocol). This means that at the protocol level a single TCP connection on port 3389 is all what is needed. However, to my knowledge there is still the problem how to route those incoming connections in a safe way in a NATted environment. In other words, some sort of a secure RDP Gateway/Gatekeeper support in the ISA server would be more than helpful.

I hope you enjoyed this article and found something in it that you can apply to your own network. If you have any questions on anything I discussed in this article, head on over to http://forums.isaserver.org/ultimatebb.cgi?ubb=get_topic;f=17;t=000091 and post a message. I’ll be informed of your post and will answer your questions ASAP. Thanks!  – Stefaan.

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top