Over the last several months I have been hard at work on a migration which has been in the works for several years.

The goal is to move video conferencing transmissions from ISDN 128kbps bonded calls to 384kbps IP calls, in order to improve the quality of the video and cut long-distance phone costs.

Over 20 hours a week classes are transmitted from a lecture hall in Fort Worth, Texas to 20 sites across the United States. The equipment in place is a Polycom VS-4000 video conferencing unit which has input from multiple cameras, an Accord MGC-100 video conferencing bridge and 2 PRI lines coming into the bridge.

Tandberg and Polycom 128 units at the remote site dial bonded 64Kbps channels to achieve a 128kbps call.

The original plan called for fractional T1 circuits at every remote site all furbished by a single ISP in order to be able to assure quality of service from point to point. A fractional 512kbps T1 would provide sufficient bandwidth for a 384kbps call plus the overhead and the bridge would be connected to a fractional DS3 circuit (around 12Mbps).

The scope of the project grew and for one reason or another the remote site circuits became a full T1 (1.544 Mbps) circuit and the host became a full DS3 (45Mbps) circuit.

To complicate things further wireless network/Internet access, routed back to the hosting site would be provided for all the remote sites for future exam taking.

Network wise the host site will have a Cisco 7204VXR with a channelized DS3 card and each site would have a Cisco 1841 with T1-DSU card and a 4-port Ethernet card.

Quality of service would prioritize h323, rtp, rtsp and sip traffic over any other and wireless access points (Aruba Network AP-65) are every site would tunnel encrypted traffic back to a Aruba Network MMC-6000 Controller.

H323 traffic has always been tricky with firewalls and I anticipated that the problems encountered would be in that area as years of experience had taught me. I was pleasantly surprised this wasn’t the case.

The Aruba Wireless controller at the host site builds IPSec tunnels to all the network access points at the remote sites, allowing students to access resources at the host site securely while at the same time preventing ad-hoc users from having access.

Technical challenges actually came from this area of the project were the site routers provided the access points with DHCP options 60 with the value “ArubaAP” and option 43 with the value of the IP address belonging to the Aruba Controller.

In order for this communication to take place, several ports needed to be allowed from the remote site to the host site. TFTP (UDP 69) for downloading configuration files, PAPI (UDP 8211) Aruba Management protocol, GRE for the IPSec tunnel, syslog (UDP 514) for sending logs, ntp (UDP 123) for keeping time and FTP (tcp 21) for downloading firmware.

Routing was carefully examined and firewall rules were put in place but nothing happened. The access points would not connect successfully with the controller so it was time to crack out the sniffer and start looking at the packets sequence from a successful connection between the controller and an on-site access point and what the packets looked like from a remote site.

Lots of cups of coffee later I found that the Aruba Wireless Controller was receiving packets from the Access Points looking for its configuration, but the controller was answering on a different IP address to the AP.

An additional rule on the firewall allowing traffic from that second IP address on the controller (not the management IP) to the network the wireless access point was at using PAPI (udp 8211) fixed the issue.

Success! A very satisfying feeling.

Enter quality of service management which I am sure will be the next opportunity to excel.