Enhanced UDP packet reflector for unfriendly environments

CESNET technical report number 16/2001
also available in PDF, PostScript, and XML formats.

Zdenek Salvet (salvet@ics.muni.cz)
2001-12-11

1   Abstract

This report describes the enhanced UDP packet reflector we developed as a tool enabling us to use MBone videoconferencing tools across restrictive firewalls.

2   Introduction

MBone videoconferencing tools ([rat], [vic], etc.) were designed for use with network which supports IP multicast. Unfortunately, IP multicast service is not universally available and reasonably reliable in many networks yet. To avoid the dependency on the presence of multicast service, simpler form of the many-to-many transport technology - replication by packet reflector - can be used. In course of practical videoconferencing activities, we discovered another common roadblock hampering the use of conferencing tools - lock of basic unicast connectivity. Even in many academic networks, RTP/UDP traffic is blocked by overly restrictive firewalls. We have got over the problem by writing enhanced UDP packet reflector that is able connect to the higher level reflector from the inside of firewalled network using TCP connection with any chosen port number or using SSH client. It is usually possible to penetrate the firewalls that do not touch application layer data this way. The use of TCP connection makes the reflector also work across port-translating NAT gateways. This enhancement also enables us to create hierarchies of reflectors where needed to reduce the bandwidth requirements of central reflector of large conferencing sessions.

3   Implementation

Our enhancement is based on the UDP packet reflector implementation [rum] we currently have in routine use for MetaCenter and DataGrid project videoconferencing meetings. In original implementation, RTP packets could be transported only in UDP encapsulation with fixed UDP port number for all client connections (the port number used by end-user tools). We have implemented additional method of encapsulation using TCP connection. New reflector implementation has three additional program parameters:

• choice between "client" mode (initiating TCP connection to the main reflector) and "server" mode (listening for incoming connection)
• hostname or IP address of main reflector (used only in client mode)
• TCP port number (both client and server mode)

In client mode, in addition to forwarding RTP/UDP packets between clients communicating directly to the reflector like the original implementation did, the new reflector initiates TCP connection the desired address and port number of main reflector outside the firewall. The main reflector - outside of the firewall - runs in masters mode and accepts the incoming TCP connection, in addition to forwarding RTP/UDP packets. RTP packets are sent through the TCP connection with minimal additional header prepended. The header consists of two 4 byte numbers, one carries the RTP packet length and the other flag distinguishing RTP data packets from RTCP packets (RTCP packets use port number one higher then RTP data packets in UDP encapsulation).

In TCP, when outstanding data has not yet been acknowledged, small amounts of output are gathered to be sent in a single packet once an acknowledgment is received (the Nagle algorithm). This algorithm may cause significant delays for RTP packets stream without flow control like the ones generated by MBone videoconferencing tools. Therefore, the new reflector uses TCP_NODELAY socket option on the TCP connection to disable the Nagle algorithm in both directions.

4   Conclusions

The modified packet reflector was tested relatively successfully with voice communication in challenging environment (two wireless LAN hops and application layer firewall) between ICN'01 conference in Colmar, France, and Masaryk University in Brno, Czech Republic. We are currently working on new and more complicated encapsulation methods (e.g. IPv6, HTTP over proxy, SSL) and the cleanup and modularization of the packet reflector, so that new encapsulation methods can be easily plugged in using common API and dynamically loadable modules.

References