VDSat: Nomadic Satellite-Based VoIP Infrastructure Dorgham Sisalem, Marius Corici, Sven Ehlert, Radu Popescu-Zeletin Fraunhofer Institute Fokus Berlin, Germany {sisalem, corici, ehlert, zeletin}@fokus.fraunhofer.de Abstract In this paper we provide the description of a VoIP architecture that is optimized to offer VoIP services in various scenarios such as catastrophe areas. The system offers multiple users VoIP services over a local access technology such as wireless LAN. The users are then connected to the Internet and ISDN over a satellite link. To be able to offer such a solution in a smooth and transparent manner, the system was designed to deal with NAT traversal, QoS control, user management and VoIP protocols optimized for the communication over satellite links. I. MOTIVATION Various real-life scenarios require the rapid establishment of a communication infrastructure to enable local users to communicate with each other and with remote users as well. Such an infrastructure has often to be established in a selfsufficient manner, as it cannot depend on support from local infrastructures such as power, data or phone access. These scenarios include catastrophe and war situations, expeditions to deserts or mountains or construction projects in remote areas such as deep forests or mountains. Taking the example of catastrophe situations, emergency workers arriving at the scene would need to be able to communicate and exchange information among each other as well as with their base stations and coordination points that might be a few thousand kilometers away. This will have to be realized even though the communication and electricity infrastructure has been destroyed. In general, the only means for enabling such a communication infrastructure was the usage of satellite phones. Such equipment does usually only allow data or speech and commonly on one or two speech lines. Figure 1 VDSat usage scenario To remedy this situation, we have developed a mobile communication infrastructure supporting the exchange of data and voice over satellite (VDSat) using IP technology and acting as a local PBX. This solution is designed to offer a number of users with the ability to communicate with each other as well as with remote users. As shown in Figure 1, VDSat offers local users the ability to exchange information over a local wireless LAN technology and the means to communicate with other remote parties using a satellite link. II. GENERAL DESIGN REQUIREMENTS For VDSat to be of general use and applicable to various usage scenarios, we aimed at fulfilling the following conditions: Flexibility: The hardware and software architecture of VDSat was designed to allow the addition and configuration of various features. This includes changing of the supported access technology, different satellite links and user-provisioning model. Thereby, the system can be extended to support access over Ethernet, local wireless LAN or WiMAX technology. Self-Sufficiency: As the system might be used in scenarios with no supporting infrastructure at all, VDSat was designed to run on battery for several hours. To achieve an optimal balance between size and weight of the system on the one hand and battery lifetime on the other hand, only power saving hardware components were used. To still achieve a high performant system, the used software components were optimized in terms of needed CPU power and memory space. Ease of configuration: To enable a short set-up time VDSat was designed to provide the users with Data and VoIP services with minimum of configuration overhead at the users end devices as well as at VDSat itself. Prioritized VoIP: VDSat is designed to offer both voice and data services. Data sessions can be very greedy in terms of bandwidth consumption. To ensure the high quality of voice communication, VDSat was designed to distinguish between voice and data and to prioritize voice traffic at the cost of data traffic. Portability: As the system is to be used in catastrophe scenarios and remote locations it must be easily transportable. Therefore the core components of the system including the CPU, memory, battery, and local access technology are to be integrated into a shockproof box. III. GENERAL ARCHITECTURE To fulfill the requirements and conditions put on the VDSat system, utmost care was needed in choosing the appropriate hardware components and implementing the software parts. We provide a brief look at the hardware components and provide an overview of the different software modules.
A. Hardware System The system is being built on top of a Trizeps III module [1] with an ARM processor running at 400MHz with 32MB Flash RAM, 64MB Main RAM and SD-Cards with up to 1GB. The system supports Bluetooth und wireless LAN (WLAN) as well as Ethernet und USB. To connect the system to remote users, a satellite modem is to be added. The exact parameters of the hardware and especially of the satellite modem depend very much on the usage scenario, the targeted costs of the system and requirements on portability and bandwidth. User Registration VoIP Proxy SIP Processing Media Control User Profile components of the system architecture as depicted in Figure 2. A. VoIP Proxy The VoIP proxy is responsible for processing incoming VoIP requests and forwarding them to the appropriate location. We chose for this part to use the SIP Express Router (SER) [3], an open-source SIP server, published under the GNU Public License. SER s architecture [4] has been designed for high scalability to serve thousands of calls per seconds, and flexibility due to a modular plug-in-approach and a highly configurable routing language. SER was already thoroughly tested for ARM processor architectures. The SIP Express Router was designed in a highly modular manner as depicted in Figure 3. SER consists of a highly efficient core that is responsible for receiving, parsing and forwarding SIP messages. SER Core M odules QoS Handling NAT-Traversal Parsing Handler M axfwd RR MySQL Jabber Figure 2: VoIP System Architecture B. General Software System In order to support voice and data communication, VDSat implements the following modules: Routing module: This is the routing component responsible for routing traffic between the local access and the satellite link. User management: To ensure that only authorized users can utilize the services of a VDSat station, VDSat offers a user configuration interface over which a user can be authenticated and receive the needed authorization to transmit data over the satellite link. In this sense VDSat would act as the admission control gateway in a hot-spot. System configuration: This interface allows the administrator of the system to configure the parameters of the system such as used address ranges, enabled interfaces and usage policies. Address allocation: The VDSat system will provide local users with a local network and will hence act as a gateway to the Internet. VDSat will thus act as a Network Address Translator (NAT) and allocate private addresses to the local users over DHCP. IV. VOIP SYSTEM In order to fulfill the requirements put on the VDSat, the VoIP system is based on the low level software provided by the open source Linux operating system, which has some highly configurable but also fast speed and low memory consuming features related to traffic control and routing using the TCP/IP stack. We use the SIP standard [2], as the VoIP signaling protocol. We will provide a short description for each of the Script Interpreter SL Usrloc Registrar Figure 3: General Architecture of SER Authentication SIP/SMS CPL The core is also responsible for invoking certain procedures that are provided as extension modules. These modules are dedicated to providing certain features. Such modules include: Transaction management: when acting in a stateful mode SER must maintain per transaction state, generate replies, match replies to requests and deal with forking. SIP handling: While the core deals with the message processing, the transaction management deals with state handling and taking the appropriate SIP actions, this type of modules deals with additional processing logic such as handling of record-route headers, or loop detection. Application modules: These modules provide some application level services such as SIP to Jabber translation. Application programming modules: To enable external programmers to use the features of functionalities of this class of modules, SER provides a clear and simple to use interface that allows the separation between SER and application code. Each module exports a set of functional procedures and utilizes procedures exported by other modules. The integration between the different modules and the core is realized through a configuration language. The SER configuration language (SCL) is a rich and flexible scripting language.
B. VDSat Extensions For processing incoming SIP requests, the VDSat software contains a SER application module. This component extracts the most relevant parameters of an incoming request, for example the bandwidth of the media flow or the address of the two parties involved in the conversation. This data is then communicated to the NAT-Traversal module, which takes the decision to create a new NAT entry for the voice stream and replies with some new parameters of the call. The SER module also communicates with the QoS module in order to have the bandwidth of the conversation reserved. The feedback from both the NAT and QoS module plus the incoming SIP request message is forwarded and processed in the Media Control module, which is responsible for checking that all needed conditions for the best voice stream are achieved. This part of the module is also highly configurable giving the possibility to fine tune the VDSat System to different usage scenarios. Using the decision of the Media Control the module is also capable, to change on demand the source address and port of the request in order to overpass the NAT and to be recognized in the public internet address space and then to forward the message to the appropriate location. C. User registration With SIP a user needs to register himself with a SIP registrar of his VoIP provider in order to be reachable by other users. In order to allow the users to utilize the services of a VoIP provider located in the Internet, the local proxy would have to forward all incoming registrations over the satellite link to the VoIP provider of the user. Registration messages are sent periodically by the user. In order to reduce this signaling overload on the satellite link, VDSat caches incoming registrations. Instead of sending each registration to the external VoIP provider, VDSat only sends the first one and sets the lifetime of the registration to a high number, e.g., one day. Follow-up registrations that only refresh the first one are not forwarded as it is depicted from Figure 4. Figure 4: SIP Register Scenario The user registration is also implemented as a SER module communicating with the SIP proxy module. This registration allows the VDSat software to manage the internal private network users, and thus hiding details of the network to the public. D. VoIP Prioritization To ensure that the voice traffic receives an adequate share of the bandwidth VDSat uses prioritized buffer scheduling mechanisms [5], as the Class Based Queuing (CBQ) [6] and Stochastic Fairness Queuing (SFQ) [7] algorithms. Traffic shaping is based on a set of queues having different priorities and different behaviour. The messages are sent in the order of their arrival to one of these queues using a mechanism of filtering. When there is space on the interface the first nonempty queue is asked in order of priority to send its first message to the line. The queues and the filters altogether are called queuing disciplines. Each of these disciplines can have a tree of sub-disciplines for a more accurate shaping of traffic giving the possibility for a very strict control and also for adding dynamically some new levels of filtering and shaping. One of the most appropriate queuing disciplines for our purpose is the Class Based Queuing. It is a classful discipline that implements a rich link sharing hierarchy of classes. It contains shaping elements as well as prioritizing capabilities. Shaping is performed using link idle time calculations based on an exponential weighted moving average for the bandwidth, which considers recent packages to be exponentially more important than the passed ones; the same algorithm used by UNIX to compute the load average. When enqueueing a packet, CBQ starts at the root and uses various methods to determine which class should receive the data., thus in each node of the tree the CBQ looks for instructions and chooses the class the instruction refers to. If the class found is a leaf-node without children, the packet is enqueued here. If there is a leaf node the process is repeated starting from that node. Using this property the traffic can be easily classified using some simple filters based on the source and destination IP address and also on the sending and receiving port, making the discipline ideal for strict traffic control. When dequeueing for sending to the network device, CBQ decides which of the classes is allowed to send using a Weighted Round Robin process in which each class with packets gets the possibility to send in turn. The algorithm starts by asking the root class for packages and will continue to do so until there is no more data to send, in which case the process continues for the children classes. This ensures the actual prioritization of the packets. Using CBQ no package is lost not even when the structure of the shaping is changed, which makes it ideal for dynamic traffic control. SFQ is a classless queueing discipline that does not shape traffic, instead it schedules traffic based on the flows. The goal is to ensure fairness so each flow is able to send data in turn, therby preventing any single flow from drowning out the rest. This is particular effective for traffic using the same bandwidth as it is the case with SIP. It ensures that the traffic on a lower priority level will not be denied network access in favour of the high priority one. The Linux operating system has an advanced system for bandwidth provisioning that supports various methods for classifying, prioritizing, sharing and limiting both inbound and outbound traffic [8], including the CBQ and SFQ algorithms.
This system was successfully ported and optimized for ARM based machines. It is available at the kernel level for the advantage of a greater processing speed of the forwarded messages. The traffic shaper can give a router: A granular control of the network services, which in our case is important for the media packets and for the SIP requests. More efficient use of the limited resources of the satellite connection. Guaranteed quality of service, especially for the media flows. It is possible to dynamically control the traffic disciplines to manage in real time the traffic sent out from the router using the Linux tc application. To realize VDSat traffic control the VoIP proxy is extended with a QoS handling module. At the start of the proxy, this module creates the root CBQ discipline with an attached filter for classifying the traffic into the three priorities as it can be seen on Figure 5: the media traffic with highest priority, followed by SIP traffic and data traffic with the lowest priority. For each of these classes an amount of bandwidth is allocated, in case one queue is empty the others share the empty traffic space in order of the priorities. The SIP traffic and the data traffic are then split up equally between the existing flows. When a new data connection is required, the module checks whether there is still enough bandwidth on the outgoing link to cover the needs of the voice session. If the requirements are met, it instructs the QoS module of the kernel to handle the voice traffic with the highest priority. It creates a CBQ queue in the media traffic in order to limit a possible incorrect or malicious quantity of traffic and also to ensure that all the existing media sessions can use the requested traffic space. The SIP requests have a lower priority. For this type of messages a SFQ queue is called to ensure a bandwidth-equity. In this way, the VDSat is able to respond to all SIP requests, hence decreasing the risk of re-sending the packages. The same queueing discipline is also used for the data traffic because when the bandwidth is fully loaded with media traffic and with SIP messages the remaining bandwidth may not honor all the remaining connections some with small messages and high importance, like ARP requests. With this mechanism, the system ensures that the voice traffic is always dealt with a higher priority than data traffic and also that there is no neglected connection. E. NAT-Traversal Local VDSat users receive private IP addresses, which are not routable in the Internet. Additionally, SIP carries the addresses of the end systems between which a voice session is to be established inside the signaling messages. Thereby, some mechanism is needed at the VDSat gateway to translate between the private and public IP addresses. VDSat implements an application level gateway (ALG) [9], on top of the IP-tables of Linux to achieve this translation. Further, the VoIP proxy is extended to communicate with the ALG module so as to get the translation results and modify the SIP messages accordingly. Netfilter and iptables [10] are building blocks of a framework inside the Linux kernel. This framework enables packet filtering, network address translation (NAT) and other packet mangling. Figure 5: VDSat - Traffic Shaper Disciplines Netfilter [11] is a set of hooks inside the Linux kernel that allows kernel modules to register callback functions with the network stack. A registered callback function is then called back for every packet that traverses the respective hook within the network stack. It has also included a connection-tracking module, which enables the packages that come on a NAT connection to be passed modified without passing through the NAT set of rules. This decreases the latency of messages passing through kernel when they are forwarded. Netfilter as a kernel module has a user-space access point through the libiptc library, which allows a control of the rules dynamically [12]. Using libiptc, new chains and rules can be created without influencing the existing traffic when they are required by the application. Doing so, the VDSat creates its own NAT tables for the voice sessions. At the startup of the system, the iptables module registers new chains in both in the NAT and the forwarding chain in order to let the administrative s firewall based on iptables continue to exist for the rest of the data traffic. The firewall cannot influence the voice communication because of the order in which the iptables rules are processed. For each new voice session a set of two rules are created: one is part of the NAT for media traffic and the other is for measuring the traffic on the forward chain. At the end of the session these rules are removed without influencing the rest of the conversations. In this way, for the scenario described in Figure 6, the phone from the local private wireless network sends the data stream to the outside phone s public IP over the satellite link. All the messages are source NATted with the public address of the VDSat and a port received from the Media Control. The messages sent by this method do not carry anymore as source address the address of the phone, but the public address of the VDSat. Because of this, the public phone does not know the real address of the phone, but sends the data stream to the port indicated on the public address of the VDSat where the message is NATted to be sent to the private phone. Using this method all the traffic going through the satellite link can be observed and classified and it also gives extra security to the
phones. Linux user-space into the kernel. This enhancement will increase the number of clients that VDSat can serve and also reduce the load on the system. The new design both of the hardware and software of the VDSat is aimed to answer to the problem of telephony in areas with no infrastructure. The efficient low consuming approach and the transparent software to the communicating parties and also the easy-to-configure interface makes VDSat a suitable solution for low cost IP audio communication. Figure 6: NAT Traversal Scenario This solution offers three major advantages in term of message processing on forwarding. There is no need to introduce a NAT software on the system, as the VoIP proxy takes care of the translation from private to public address. Secondly, the packages never leave Linux kernel space, increasing the speed of routing. Also it completely takes out the time necessary to modify packages in the user-space as it was in the prior solutions of NAT traversing for SIP. The last important advantage is that the SIP-NAT problem is solved without creating any additional costly traffic on the IP interfaces, to e.g a STUN server. This is solved trough local communication between the VoIP proxy and the IP-tables module. A NAT rule is created when the SIP proxy announces the address and the port on which it wants to receive the media traffic so there is no need for extra communication with another system, e. g. a STUN server to find out the location where the messages are sent after passing trough the NAT device. REFERENCES [1] Keith-Koep Co. Trizeps III Hardware Specification http://www.keithkoep.com/produkte_trizeps3 [2] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Spark, M. Handley, E. Schooler, Session Initiation Protocol, RFC 3261. [3] SER Web Page, http://www.iptel.org/ser [4] Rebahi Y., Sisalem, D., Kuthan, J., Pelinescu-Oncicul, A., Iancu, B., Janak, J., Mierla, D.C.: The SIP Express Router An Open Source SIP Platform, Evolute Workshop 2003, Guildford, UK [5] Floyd, S., and Jacobson, V., Link-sharing and Resource Management Models for Packet. IEEE/ACM Transactions on Networking, Vol. 3 No. 4, pp. 365-386, August 1995 [6] Floyd S. Notes on CBQ and Guarantee Service, IEEE/ACM Transactions on Networking, Vol. 3 No. 5, pp. 282-313, August 1995. [7] Paul E. McKenney Stochastic Fairness Queueing, IEEE INFOCOMM 90 Proceedings, San Francisco, 1990. [8] Linux Advanced Routing and Traffic Control, http://lartc.org/ [9] P. Srisuresh, M. Holdrege, IP Network Address Translator (NAT) Terminology and Considerations, RFC 2663 [10] IPtables tutorial http://iptables-tutorial.frozentux.net/iptablestutorial.html [11] R. Russel Linux Netfilter Howto http://www.netfilter.org/documentation [12] L. Balliache Querying libptc Howto http://www.tldp.org/howto V. CONCLUSIONS In this paper we have introduced an architecture of a VoIP proxy software that is independent from any local infrastructure. It is based on features of the Linux operating system, providing QoS handling and NAT traversal. We use low level Linux modules that are bound directly to the message-processing TCP/IP stack so that they don t interfere with the voice streams thus allowing an efficient and strict control of the traffic. This design property reduces the consumption of resources necessary otherwise for higher-level approaches and increases the speed rate of package processing, making it an appropriate solution for satellite communications using an ARM processor system. The system is to be tested in real-life scenarios, using real satellite connections. Some new improvements will be then taken in consideration, like the bandwidth delay problem for media streams. The software is highly modularized and can be easily enriched with new capacities related to traffic management. For furthermore reducing any redundant processing of the media control messages, the software can be more strictly adapted to system particularities. This will allow the highly used components of the VoIP proxy to be transferred from the