of today to produce a portable productivity and
collaboration tool.
The number of smartphone owners worldwide
has increased from 41 million users in 2009 to 80.5
million users in 2010 (Gartner, 2011). That figure
does not yet include other mobile devices such as
tablets, e.g. the iPad, and non- phone devices, e.g.
iPod Touch. Due to this large and growing user base,
mobile collaboration services provide tremendous
new opportunities that are not possible on PCs (Li et
al., 2008). In addition, due to the fact that
smartphones use a touch screen interface, the user
has an intuitive way to draw on the device. Our
proposed approach uses these advantages of the
mobile device, specifically the iOS devices, both
increasing user base and usability, as a leading edge
over existing whiteboard collaborative systems.
There are existing applications like the proposed
system in the Apple App Store. These are Netsketch
(Gotow, 2011) and Whiteboard Pro (GreenGar
Studios, 2011). These applications provide
collaboration on a shared whiteboard. However, the
applications only works on local network due to
absence of a server for user presence. Having a
collaboration tool work only on the local network
prevents use cases of the system where collaborators
are geographically challenged. The proposed system
works outside of the local network by utilizing an
existing presence and messaging server. In addition,
the proposed system provides voice over IP, not
found on other existing apps, that would possibly
improve the perceived usability by users.
There are existing work on using electronic
whiteboard on mobile devices. Work by
Ambikairajah et al. (2007) focuses on using tablet
PCs for use with teaching DSP education. Demeure
et al., (2005) used PDAs with whiteboards as
supplement to lectures and meetings. Liu et al.
(2002) did an earlier attempt to use wireless
technologies as a tool in a classroom environment.
The system would also work for people located
remotely from each other.
The application without its Voice over IP
capabilities has also been released on the Apple App
Store under the name DoodleTalk.
The next section contains details about how the
system was implemented from building the digital
whiteboard and voice over IP features, call signaling
and NAT traversal. Then in the succeeding section
the system is tested and results are presented.
2 DESIGN AND
IMPLEMENTATION
To implement the application, several libraries and
frameworks were used. A library that implements
the RTP stack called oRTP (Morlat, n.d.) was used.
A library that implements XMPP related functions
called xmppframework was used.
The shared digital whiteboard implemented
allows two or more people to share a digital
whiteboard. A person's changes to the digital
whiteboard can also be seen by others. This enables
communication not limited to text.
To complement the digital whiteboard feature,
voice over IP is implemented. Voice communication
will potentially allow easier communication than
with the shared digital whiteboard only. The
expected experience on the final application will be
similar to listening to a classroom lecture while
looking at notes being made shown on a digital
video projector.
The voice over IP feature is implemented by
parts in the following sequence: audio related
functions, peer to peer communication, call
signaling, and NAT traversal but most details of the
implementation will not be discussed here. The
audio related functions provide access to the voice
data captured by the microphone and also the buffers
that the speakers use when playing audio. Peer to
peer communication provides wrapping of audio
data into RTP packets, and facilities to send and
receive RTP packets. Call signaling provides
automatic discovery of the peer's IP address and port
and exchange those information with that peer to
establish a working call. Finally, NAT traversal
allows the voice over IP feature to work through
most NAT topologies.
Call signaling is derived XEP-0166 (Ludwig et
al., 2009) and the Google Talk Call Signaling
protocol document (Google, n.d.a).
NAT traversal was implemented by using STUN,
which is defined in RFC 5389 (Rosenberg et al.,
2008). It uses Google’s own STUN server that
echoes the public address and port number where a
packet originated. Even with this utility, the
application will work only on some network
topologies.
The packet sniffer used is Wireshark on Mac
OSX. The network setup used when sniffing packets
is as follows. A laptop running Mac OSX was setup
to make an ad-hoc network that shares its ethernet
connection. Then an iPod Touch is made to connect
to the ad-hoc network. That way, packets going to
and from the iPod Touch can be sniffed including
PECCS 2012 - International Conference on Pervasive and Embedded Computing and Communication Systems
130