This section first briefly sketches some implementation details about our novel TransferHTTP extension and CAS SIP B2BUA component; and then, it presents experimental results aimed to evaluate the cost of the proposed session mobility management solution.
TransferHTTP browser extension
TransferHTTP has been realized as an extension for Mozilla Firefox Web browser. The services available in the TransferHTTP extension include not only content sharing and session transfer, originally presented in this paper, but also VoIP (“Make a call”), and multimedia content sharing (“Stream Media to Call”).
Our session mobility facility consists of two main parts: a SIP stack and our TransferHTTP extension. The SIP stack used in this implementation is the PJSIP [12], which is an Open Source project and small footprint multimedia communication libraries written in C. We created a shared library (1.7 MB in size) from the SIP stack and the shared library interacts with the TransferHTTP extension via a Cross Platform Component Object Model (XPCOM). In particular, we added our extension as a new XPCOM with the contract id “@ngportal.com/SIPStack/SIPStackInit;1” into the existing XPCOMs in the browser [13].
As regards our TransferHTTP extension, it has been realized atop built-in interfaces in Mozilla Firefox version 2.0–3.5 that include nsIPref, nsICookie/nsICookieManager/nsICookieManager2, nsIThread, nsIPasswordManager/nsILoginManager, nsIIOService, nsIPromptService, nsITimer, nsIObserver; in addition, it makes available a new interface, named “ImyStack” to exposes TransferHTTP functions. The underlying implementation, written in C++, is scriptable and developers can use JavaScript to invoke its functions. In particular, TransferHTTP API exposes signaling functions, typically available in telecommunications frameworks, to create innovative applications at the client side. For instance, our API makes it possible to create applications that can use the instant messaging and presence features in SIP [14]. The TransferHTTP client API currently exposes the SIP REGISTER method so that a browser can register with a SIP network. It also exposes the SIP MESSAGE method to send messages or chat and the SIP INVITE method to make calls between two browsers. Using the TransferHTTP API, it was easy to implement the HTTP session mobility service presented in this paper. Other services, such as Stream Media to Call to broadcast media are also based on the same APIs.
Our extension also offers a graphical user interface, shown in Fig. 4. In particular, TransferHTTP adds a new menu to the menu bar in the browser and a “Preferences” submenu to let users edit configuration parameters. The settings include the SIP proxy address/port number and the SIP username. Figure 4 shows the new menu and all available options in the status bar. The “Make a call” option enables a user to make a VoIP call to another, and the “Stream Media to Call” one enables a user to stream media to another user. Other options, namely “Register Client”, “De-register Client”, and “Accept Session,” are used to register to a SIP Registrar, de-register the client and accept a Web session transfer request sent to the browser, once controlled and forwarded by CAS. To enjoy the full potential of TransferHTTP, developers are advised to develop XML User Interface Language (XUL)-based applications. XUL was the language used to develop the Mozilla Firefox user interface. Hence, a XUL-based application developed by any interested user will be able to use the APIs in the Web browser and our extension.
Various versions of TransferHTTP extension are available. Version 1.2 was meant for Peer-to-Peer interaction, version 1.3 worked in a client–server environment, and current version 1.4 supports also VoIP and our novel the Stream Media to Call service. The browser extension, developed for the Mozilla Firefox open source browser, is publicly available under the Mozilla Public License (MPL). We hope Web 2.0 and SIP research practitioners will continue to extend the API and creating more innovative user-generated services [13].
CAS SIP B2BUA component
The Mobicents Communications Platform was used to implement CAS [5]. Mobicents is an open Java-based platform that enables creation, deployment and management of services and applications that integrate voice, video and data across a range of Internet Protocol (IP) and communications network by multiple devices. It implements and delivers both competing and interoperable programming models—Java APIs for integrated networks (JAIN) service logic execution environment (SLEE), and SIP servlets—to develop Web and VoIP applications that work together.
CAS implements Web session blocking and forwarding. Although applications could be developed using either JAIN SLEE or SIP servlets in the Mobicents Platform, the current implementation is based on the Mobicents SIP servlets programming model [15]. When the proxy receives a SIP request, the application router (AR), a standard component part of the SIP servlets model, is called by the Mobicents container. When a request addressed to CAS arrives, AR selects our SIP servlet application—implementing CAS session control logic for incoming SIP REGISTER and MESSAGE requests—to process it.
CAS offers also a Web user interface (not shown here) with three main pages. The “Session Tracking and Pickup” page logs all session transfer requests, call setup requests, and actions taken on them. For each session transfer, it provides the source SIP address, the destination SIP address, the SIP method, date, action taken (also known as status) and the referred URL in the case of a session transfer request. The “My Account” page enables a user to set access policies; information available here includes SIP URIs with their log-in details and policies. Using this page, it is possible to instruct CAS about how to handle content sharing and session transfer requests. Finally, the “Buddy List” page contains a list of his contacts; users can add new contacts and check their Buddy List page to see if their contacts are online or offline.
Performance results
We have thoroughly tested and evaluated the performance of our SIP-based session mobility solution by deploying it in a real-world testbed: TransferHTTP extension runs at several Linux client laptops equipped with Mozilla Firefox and the shared library developed from PJSIP [12], while CAS SIP servlets execute on a standard Windows XP box with 3 GHz Pentium 4 processors and 1,024 MB RAM. As outlined in Sect. 5.1, the integration of the SIP stack into the Mozilla Firefox browser was achieved in a loosely-coupled approach via XPCOM [13].
Reported experimental results focus on session blocking/forwarding functions needed to enable both our content sharing and session transfer use cases. The reported evaluation is aimed both to confirm the feasibility of the proposed approach and to inspect the effectiveness and the efficiency of CAS, that is the core and the most loaded session control component, and of TransferHTTP, that executes at the client side and thus has to be also carefully assessed. We have collected four main performance results: (1) preliminary results about additional delay due to CAS interposition in the browser-to-browser path; (2) CAS memory consumption and processing delay under different load conditions; (3) CAS performances under system overload; (4) TransferHTTP memory consumption at the client side.
The first set of experiments was aimed to preliminarily assess the latency introduced by CAS. We measured it for both send/forward and block/forbid requests and we focused on the delay of MESSAGE requests without considering TransferHTTP registration time because the registration phase occurs only once (at user login) and does not affect user-perceived delays at runtime. In addition, we repeated our experiment under two different deployments: in the local deployment, the two clients (browsers) and CAS have been all deployed within a local Intranet (a 100Mbps Ethernet); in the Internet deployment, we deployed the two clients at the University of Bologna (Italy) and the CAS at the University of Cape Town (South Africa). The results for this first test have been collected far from overload conditions. In the local deployment, the latency introduced by CAS to block/forbid the request is always less than one second (approx. 0.017 s), while it takes longer time for CAS to process a send/forward request (approx. 0.128 s). In the Internet deployment, instead, we measured a delay of about 0.512 s to block/forbid a request and 0.655 s to sent/forward a request due to both increased network latency and relatively frequent SIP request re-transmissions caused by packet losses along the path. All above measurements have exhibited a limited variance, under 5% for more than one hundred runs. However, the performance of the system could significantly improve with a faster Internet connection, especially given the relatively bad conditions of the network trunks throughout Africa.
The second set of experiments focuses on CAS during normal load conditions. Table 1 reports number of forbidden and timed-out responses, total number of responses (forbidden plus timed-out responses), memory utilization, CPU usage, and average time of a request, for different incremental loads, going from 20 messages to 600 messages sent at a constant rate of 1 message-per-second (mps). To collect these performance results we used the SIPp traffic generator, by focusing mainly on block/forbid requests because, in a real deployment, we expect they are the most numerous ones [16]. We repeated the experiment several times for each number of requests: in Table 1 we report mean values and, for each value, its variance in brackets; as reported, all results show a limited variance. Starting from CPU usage, CAS execution imposes a limited CPU load, always below 25% even for the highest number of requests (600 requests). As for the memory, it also showed good performances; at the constant rate, the memory needed to fulfill the increasing number of requests is always below 1.2 MB.
Table 1 CAS performance under normal load conditions
As for forbidden and timed-out responses, also for sake of comparison with our third set of experiments, we plot the number of (correctly) fulfilled forbidden responses (dashed-and-dotted line and y-axis on the left in Fig. 5) and the number of timed-out responses (solid line and y-axis on the right) against the total number of requests (see Fig. 5). Forbidden responses graph is linear and that demonstrates that CAS is able to correctly fulfill (almost) all received block/forbid requests, while the few time-outs that sporadically occur are independent of the number of requests (see Fig. 5).
Finally, let us stress that the results presented here are based on the technical specifications of the Windows XP boxes CAS was deployed on; in particular, to demonstrate the wide feasibility of our solution, we tested CAS in a standard deployment scenario with not-so-powerful hardware and by using standard and non-optimized configurations both for host background services and for the Mobicents server. We observed that the total time required, memory consumption, and CPU usage significantly dropped when CAS was deployed and tested on a high performance PC (a Core 2 Duo PC).
The third set of experiments points out the CAS scalability and correctness under heavy-load condition. To stress CAS, in each test run we generated and sent to CAS several non-authorized session mobility requests to be blocked. In particular, we heavily loaded CAS by using the pjsip-perf SIP traffic generator as the performance measurement tool. Pjsip-perf executed at the client host, sends bursts of SIP MESSAGE messages, going from 20 to 600 messages-per-burst, at the very high and challenging frequency rate of 677 mps [17].
The resulting average response time of CAS varied from 10,558 to 48,557 ms, and the average number of SIP response messages was more than the average number of SIP requests. For example, when 250 SIP MESSAGE requests were sent, the number of SIP responses was 276. The reason why the number of responses is higher than the number of requests is that SIP supports multiple responses to a request. The responses were SIP 403 Forbidden and SIP 408 Request Timeout (for messages that timed-out at CAS due to the delay caused by excessive overload).
Figure 6 shows CAS behavior under heavy-load conditions (the same type of graph shown in Fig. 5 for normal load conditions with the only difference that there is one only y-axis on the left). We observed that CAS optimum performance is reached at around 100 SIP MESSAGE requests: at this point, CAS can still generate equal number of correct SIP responses (SIP 403 Forbidden). The number of SIP 408 Timeout gradually increases as the number of requests increased, starting from 99 SIP MESSAGE requests, thus showing how CAS performance degrades under system overload. Test results also show that the server could not block all requests: CAS was able to respond to an average number of 73 requests (out of the 600 requests) in less than the response timeout set at the client (which was 32 s), while an average of 531 requests expired at the client due to timeout (see Fig. 6). In any case, requests were queued at CAS that generated responses later on as seen from our test logs; that let us exclude memory (Mobicents SIP message queue length) as a possible CAS bottleneck. Hence, we believe that CAS bottleneck is the number of Java threads devoted to CAS servlet execution in Mobicents.
To completely assess the CAS component under system overload conditions, we also collected memory consumption. As Fig. 7 shows, CAS memory consumption gradually increased as the number of SIP MESSAGE requests in the burst increases. The reason is that the number of threads required to process the requests increases; hence, there is an increment in the memory required to process the requests. In particular, our experiment assessed CAS memory usage under different working conditions. First of all, we experimentally verified that our CAS component—which has been realized as a Java-based Mobicents SIP servlet application—can occupy two main runtime execution states that we call idle and non-idle. In order to reduce the memory consumption on the PC, CAS goes into the idle state whenever, for a certain time period, there is no SIP message to respond to; in that case, it takes some time for CAS to respond to every first subsequent request (due to servlet re-activation).
In idle state, CAS memory usage, collected by using the system performance monitor (Windows Task Manager), is approximately 206 MB out of the 1 GB RAM in the Windows box. In the non-idle state, CAS memory consumption increased by approximately 2.12 MB when a burst of 20 SIP MESSAGE messages was sent to it and by 13 MB when a burst of 600 SIP MESSAGE messages was sent to it (see Fig. 7), while at its optimum performance, around 100 SIP MESSAGE requests, its memory consumption increase is 5.5 MB. Finally, we observed that CAS CPU usage was always at 100% during the entire system overload test.
Our fourth (and last) set of experiments evaluated the cost of running our lightweight TransferHTTP extension at the client side. We used the standard system monitoring tool, available on Ubuntu operating system, to view current processes and to gather the memory consumption data. During the tests, the browser was used to browse the Internet and to move ongoing session (by using both content sharing and session transfer facilities); VoIP and Stream Media to Call services have also been invoked during the test runs. Table 2 shows the browser’s memory consumption test.
Table 2 Web browser memory consumption test
The SIP stack execution as a background service caused a very contained and low browser’s memory consumption increase (TransferHTTP overhead) of 5.83 MB on average. Findings showed also that the browser neither crashed nor froze, even when running the SIP stack as a background service for very long-run tests up to 4 h.