1. Video Conferencing with NaradaBrokering
11/15/2018
Video Conferencing with NaradaBrokering
Mark Baker and Rahim Lakhoo
My name is Rahim Lakhoo and I’m from the Distributed Systems Group at the University of Portsmouth. And today I wish to talk about our experiences developing a Video conferencing system with the NaradaBrokering project.

2. Outline Introduction Motivation Technologies: System Architecture
11/15/2018
Outline
Introduction
Motivation
Technologies:
GridSphere,
Java Media Framework,
NaradaBrokering.
System Architecture
Experiments
Issues
Conclusions
I’m going to give a brief introduction and motivation for our work. Then give an overview to the technologies used to create the video conferencing system, namely the GridSphere portal, JMF and NaradaBrokering. We then move on to the architecture and design of the video conferencing system and our experiences with the system during testing. Finally, we cover the Issues found with this system and present our conclusions.
15 November 2018

3. 11/15/2018
Introduction
Portsmouth and Reading’s role in the Sakai VRE project is to develop and deploy a number of portlet-based tools and services.
In particular we are looking at:
Collaborative tools based on NaradaBrokering,
Semantic Web tools based on RDF,
Bridging technologies to enable legacy applications,
Peer-to-Peer technologies.
Portsmouth and Reading are developing JSR-168 portlets, on the basis that Sakai will consume portlets via the WSRP consumer developed within the project.
In this talk we will recount our experiences developing, deploying and testing chat and video conferencing services based on NaradaBrokering, GridSphere and the Java Media Framework.
Portsmouth is developing a number of tools for the Sakai Virtual Research Environment project and we are most interested in developing collaborative tools, semantic web utilities and peer-to-peer technologies. It planned that the Sakai portal will be able to consume standard JSR-168 portlets, either natively of via WSRP (Web services for Remote Portlets). And as stated before we recount our experiences developing this system.
15 November 2018

4. Collaborative Service
11/15/2018
Collaborative Service
Motivation:
Investigate NaradaBrokering that is also partially funded by the e-Science programme, which other UK Universities and organisations are interested.
Add useful tools for the Sakai Demonstrator,
To create a chat and video conferencing system that work-site users and external users may communicate with.
To provide the ability to conference with many participants, i.e. meetings or teleconferences.
Note: this work was completed in Jan 2005.
The NaradaBrokering project has been of much interest to the JISC VRE and e-Science programmes and one of our motivations was to use NaradaBrokering for video conferencing. We are hoping to add this as a useful tool to the Sakai Demonstrator. The chat and video system was designed to allow worksite/portal users and external users to hold meetings or teleconferences.
15 November 2018

5. Technologies Choices GridShpere: NaradaBrokering:
11/15/2018
Technologies Choices
GridShpere:
Supports JSR-168 and WebSphere portlets,
Provides a portal framework, not just a portal, but a development infrastructure.
Has an active support and user community.
NaradaBrokering:
Unified messaging framework with support for Grid and Web Services,
Software multi-casting with support for different transport protocols,
Supports video conferencing with Global-MMCS.
Java Media Framework:
Java-based solution for handling time-sensitive data,
Ability to capture video and compress streams in different formats,
Supports the Real-Time Protocol.
Technology choices,
GridSphere is a portal framework, which is idea for portal developers and is actively supported. It is JSR-168 compliant and supports the WebSphere portlet API, however recently the WebSphere API is being phased out.
NaradaBrokering, is a messaging framework which can support Grid and Web services, amongst others. It can also provide software multi-casting across different transport protocols, making it quite flexible. And has video conferencing support from the incorporated Global-MMCS project.
The Java Media Framework also known as JMF is a java solution for media or time sensitive data and has the ability to capture video and compress streams in different formats. It also supports the RTP protocol, which is widely used on the Internet for relaying video/media content.
15 November 2018

6. 11/15/2018
Portals - GridSphere
The GridSphere framework provides an open-source portlet-based Web portal.
The framework allows developers to manage and deploy portlets within the container.
GridSphere supports JSR-168 and WebSphere-based portlets.
GridSphere also supports GridPortlets for managing jobs and data on the Grid.
GridSphere uses Apache Tomcat as its container – though it can also use Jetty.
GridSphere is an open-source project and allows developers to manage and deploy their portlets. As stated before it supports the JSSR standard and proprietary portlet API’s. As the name suggests it also supports GridPorltets for interacting with Grid services and uses Apache Tomcat as its preferred container.
15 November 2018

7. Java Media Framework (JMF)
11/15/2018
Java Media Framework (JMF)
JMF provides an interface for Java applications to interact with media or time sensitive data.
JMF includes codecs and protocols, such as:
Support for Quick Time movies,
MP3 playback,
Video/audio capture,
Supports the Real Time Protocol (RTP),
H.263 video conferencing codec (compression format).
JMF is available in two formats:
Performance Pack, for only Linux, Solaris and Windows:
Includes native libraries for codecs and capturing from devices,
Platform Independent version:
Includes partial capability for codecs and no video capturing.
JMF is developed by Sun and allows Java applications to interact with media based data, it includes support for Quick Time movies, mp3 playback, video and audio capturing and can compress video streams using the H263 format, which provides video at medium quality with a low bit rate.
Although JMF is built with Java, it is available in 2 formats, the performance pack and a platform independent version. The performance pack is needed for video capturing and contains native libraries for this purpose. The platform independent version can receive video in the H263 format but cannot capture video from devices, such as a webcam. A detailed list of what can or cannot be a accomplished with the platform independent version of JMF is available from Sun’s website.
15 November 2018

8. 11/15/2018
NaradaBrokering
NaradaBrokering is developed by the Community Grids Lab at Indiana University.
Originally designed to provide software multi-casting for real-time collaborative systems.
Asynchronous messaging system that is JMS 1.02b compliant.
Publish, subscribe and bind architecture with JMS topics.
NaradaBrokering supports other capabilities:
Video Conferencing via Global-MMCS,
Peer-to-Peer with JXTA,
Grid and Web Services.
Provides a number of transport protocols:
HTTP/HTTPS, TCP/NIO-TCP and UDP.
NaradaBrokering has been developed by the community grids lab based at indiana university and was originally developed for software multicasting. It provides an asynchronous messaging system which is compliant to the Java Messaging Service (JMS) version 1.02b. It uses JMS topics, to which a user can subscribe or publish content.
NaradaBrokering also supports a number of other capabilities including, peer-tp-peer via JXTA and Grid services such as GRID FTP and more recently some Web services.
More interesting is that it provides a number of different transport protocols which can be useful for bypassing firewall issues, or LAN/WAN connections.
15 November 2018

9. NB Chat and Video Architecture
11/15/2018
NB Chat and Video Architecture
The NB Chat and Video System consists of portlets, portlet services and Java applets from a users perspective:
Chat portlet,
Video Conferencing portlet,
NaradaBrokering portlet service,
Userlist portlet service,
JMF applet.
The servers consist of:
NaradaBrokering,
Apache Tomcat,
GridSphere,
Global-MMCS.
We move on now to detail the system we have developed. The system consists of front end portlets, namely the chat portlet , and video conferencing portlet. The NaradaBrokering portlet service handles all the connections, while the userlist portlet tracks users online status and video sessions. The JMF applets do the capturing and displaying of video.
The backend, consists of NaradaBroker, Tomcat, GridSphere and the Global-MMCS (Global Multi-Media Collaborative System), which does the RTP session handling.
15 November 2018

10. System Architecture 15 November 2018 11/15/2018
Here we have the video and chat systems architecture:
You can see the applets down here (point) and the portlet front ends here (point) the portlet services are located here (point). MySQL provides database support for Gridsphere in our setup. The NardaBrokering and Global-MMCS is located on a remote server. Communication, occurs between the services and NaradaBrokering.
15 November 2018

11. The Chat Service (1) The Chat Service consists of:
11/15/2018
The Chat Service (1)
The Chat Service consists of:
A Chat portlet,
A NaradaBrokering portlet service,
A Userlist portlet service.
The Chat portlet provides the interface and user notification messages.
The NaradaBrokering portlet service, handles all connections and messages to be sent/received for all connected users.
The Userlist portlet service tracks connected users and stores user information.
So the portlet services, as stated before, are used by the the portlets. In this case the chat portlet provides an interface for the user and relays messages to and from the NaradaBrokering portlet service. The userlist portlet service tracks online users and displays a user list in the chat portlet.
15 November 2018

12. The Chat Service (2) The User Interface 15 November 2018 11/15/2018
Here we have the Chat portlets interface and as you can see the user list displays all participants connected.Each user is allocated a different colour and messages, including user notification messages are time stamped. The interface is designed to resemble the popular IRC.
The User Interface
15 November 2018

13. The Chat Service (3) Configuration Interface 15 November 2018
11/15/2018
The Chat Service (3)
Here we have the configuration screen of the chat portlet, which is used to connect a user to NaradaBroker, these settings are used by the NaradaBrokering portlet service at the backend. Different protocols can be used and there is also some default chat rooms to choose.
Configuration Interface
15 November 2018

14. An Example System Set-up
11/15/2018
An Example System Set-up
Here we have an example setup, which shows 4 clients connected to the system and their respective sessions. And we have a list of objects that are stored in a users sessions and are used for the communications.
15 November 2018

15. 11/15/2018
The Chat Service (4)
Each user has a PortletSession, which hold all connection information per a user.
The Chat portlet and the NaradaBrokering portlet service use PortletSessions for the communication of messages and connection information.
Messages are sent by the NaradaBrokering portlet service to a JMS Chat topic on the broker.
Each user has an associated asynchronous MesaageListener, which stores any received messages inside their PortletSession.
All user chat messages are sent via standard portletsessions. Connection objects are also stored in a users session and are reused by the NaradaBrokering portlet service. The chat messages are posted to a JMS topic and subscribers of the topic will be forwarded messages. Each user has all information regarding their video and chat sessions stored in their session.
15 November 2018

16. The Video Service (1) The Video Service consists of:
11/15/2018
The Video Service (1)
The Video Service consists of:
A Video Conferencing portlet,
JMF Applets,
A Userlist portlet service.
The Video Conferencing portlet displays a list of available cameras and loads the relevant JMF applet.
The Userlist portlet provides the video stream topics and other details, to initiate the video conference.
The video conferencing portlet loads JMF applets with different connection parameters for each camera subscribed too. And again we see the user list portlet service being used to track users information and status.
15 November 2018

17. The Video Service (2) The Video Camera Subscription Interface
11/15/2018
The Video Service (2)
We have a screen shot here of the video conferencing portlet which has been kept simple, as you can see a user list is populated and a user can select a camera to subscribe too. Also this portlet has the ability to publish a users camera attached to their machine.
The Video Camera Subscription Interface
15 November 2018

18. 11/15/2018
The Video Service (3)
Users may publish a web-cam or subscribe to other registered web-cams.
The video conferencing portlet gathers user information from the Userlist portlet service, to display a list of any available cameras.
The video conferencing portlet generates an applet tag with the connection details.
The applet then connects to a broker to initialise a video conference.
We will again, later, see the video conferencing portlet in action during our experiments. The feature of the video portlet is to dynamically create applet tags with the correct connection details to load. The applet then connects from a users machine directly to NaradaBrokering.
15 November 2018

19. Video Service (4) There are two JMF applets:
11/15/2018
Video Service (4)
There are two JMF applets:
A transmitting applet which captures a device,
A receiving applet which displays a video stream.
The transmitting applet captures a users Web-cam as RTP data and encapsulates it within the NaradaRTPConnector.
The receiving applet uses the NaradaRTPConnector to extract the video stream and plays it with a JMF player.
This means that only one UDP port is required to be open on the broker for users to use the video conferencing.
The chat facility also only requires one TCP port on the broker.
This is unlike VRVS or Access Grid which requires a range of ports to be open.
There are two JMF applets, one for receiving and the other for transmitting video streams. The transmitting applet also initiates the capture device. All RTP messages are encapsulated with the NaradaRTPConnector and are transmitted to the RTP server from the Global-MMCS project. The system only needs 1 UDP port open for all clients, at the server end (NaradaBrokering). And only needs 1 TCP port for all clients to be able to connect to the chat facility. This is unlike other video conferencing systems such as VRVS or Access Grid, which typically requires a range of ports.
15 November 2018

20. Chat and Video Services
11/15/2018
Chat and Video Services
The presentation layers are separated from the logic – an MVC design pattern.
All inter-portlet communications are undertaken with either PortletSessions or via portlet services.
The portlet services interact with external sources, while the portlets only deal with the layout and passing of information to the services.
During the design of the chat and video services, all inter portlet communications are done with either portlet sessions or portlet services. The portlets themselves only deal with the layout and user interface, while the logic is contained within the portlet services.
15 November 2018

21. NB Chat and Video System Experiment
11/15/2018
NB Chat and Video System Experiment
The Chat and Video Portlet was tested with four cameras and five users.
Each participant was connected to the chat room and four cameras where published.
All participants subscribed to all four cameras.
To stress test the system all participants subscribed multiple times to all four cameras.
The limitations of the number of subscriptions each user could make, was only limited by their system resources.
The maximum obtained was 18 subscriptions with one published camera, by a single user.
The broker and GridSphere consistently utilised 500 MBytes of memory, peaking to 643 MBytes.
So, we held a small experiment to see how the system runs. We had 4 cameras and 5 users. Each test user was connected to a chat room and published a camera. All participants connected to all 4 cameras, after which the system was stressed by subscribing to as many camera as possible. We found that 18 subscriptions was the maximum obtained by any one client on linux, 16 on windows. Limiting factor was clients machine resources. We also noticed high memory consumption during the testing where NaradaBrokering and GridpSphere consistently used 500MB.
15 November 2018

22. NB Chat and Video System Experiment
11/15/2018
This is a screenshot of the video conferencing portlet during that experiment. Each window is a JMF applet which a user can place to their liking.
15 November 2018

23. 11/15/2018
Issues
The RTPLinkManager in NaradaBrokering (0.99RC4) has ‘hardwired’ ports, even though there is a configuration file.
NaradaBrokering’s RTP session configuration file is not dynamic; it requires a broker restart.
When many messages are sent to the broker memory usage increases and eventually the broker fails.
The system suffers from session bloating with this portlet and thus consumes a lot of memory.
Memory is not reclaimed by the system.
JMF has compatibility issues with web-cams and Linux.
Refreshing the chat room messages automatically requires other technologies, such as AJAX and/or JavaScript.
Closing the an applet’s connection is problematic; needs the whole browser to be shutdown.
So now we come to the issues we have found during the development of the system. Firstly there are some hardwired ports in NaradaBrokering even though it has a configuration file. The RTP manager is an example of this. Narada also provides the ability to have private pre-defined video sessions, where users IP addresses are listed in a configuration file. However, the broker needs to be restarted for any changes made to the configuration file to take affect. Because all the connection settings per user are held in the users session, the system suffers from session bloating because of this. Memory used by Tomcat and NaradaBrokering during the experiments was not reclaimed by the OS, implying that there is a memory leak some where. JMF has compatibility issues with some web-cams even under windows., While installation on Linux is not so straight forward. The Sun forums are full of users with installation issues on other platforms other than linux. Refreshing the chat room messages needs some javascipt or AJAX type mechanism to reload the text area, instead of the whole screen. And applets connection seem to stay alive even though the applet window is closed, and other information is held in sessions. Thus to clear this information the whole browser needs to be killed rather than just a browser tab.
15 November 2018

24. 11/15/2018
Conclusions
As proof of concept the system does work, however, some of the technologies and standards need to mature.
Installing JMF is still problematic for platforms other than Windows and seems to be a dormant project, with few updates.
JSR-168 does not accommodate for the concept of portlet services, thus portlets could be very large and not easily reusable.
NaradaBrokering’s RTP support and JMS API needs to be extended to improve its capabilities.
Finally we conclude:
That as a proof of concept the system does work, however the technologies, namely JMF and Naradabrokering need to mature.
JMF is problematic for users to install on platforms other than windows and seems like a dormant project with very few updates.
JSR-168 does not currently cover portlet services or inter-portlet communication, it will be interesting to see what the next revision of JSR-168 will offer (286).
NB’s rtp support and its implementation of JMS needs to be extended to improve its capabilities, such as dynamic handling of private video sessions.
15 November 2018

25. References http://www.gridpshere.org http://www.naradabrokering.org
11/15/2018
References
These are some references that some may find useful.
15 November 2018

26. Questions? http://dsg.port.ac.uk http://acet.rdg.ac.uk 11/15/2018
Any questions?