NAME
msessmon - Multicast Session Monitor
SYNOPSIS
msessmon [ -display display ] [ -address address/port ] [ -
type displaytype ] [ -debug level ] [ -help ]
DESCRIPTION
MSessMon is a multicast-based conference monitor application
that is still in testing. It is a receive-only multicast
application that charts the reception tree to selected RTP
content senders. It works by binding to a multicast
address/port pair, address/port corresponding to the RTCP
control socket for a conference. It then monitors activity
on on this port and derives its information from this.
Initially, MSessMon presents a window displaying all
currently sending participants in the conference as a
selectable list. On selecting members of this list, a
``routemap'' is created which displays a graphical represen-
tation of the reporting recipients, using nodes and edges to
display traffic paths.
OPTIONS
-display
Use the X display display to open windows on.
-address
Monitor address/port pair address/port for multicast
RTCP transmissions instead of the compiled in defaults.
-type
Uses type as the initial type of graph rendering the
routemaps use when they are created. Currently this
can be one of:
tree A hierchial tree pattern (default)
radial Experimental Doesn't work well.
spring SpringEmbedder. Cute incremental algorithm,
but is fairly CPU intesinve.
round
roundscale Experimental algorithms that may or may not
look tasteful.
-debug
Sets debug level to level. The default debug level is
0.
OPERATION
After selecting a routemap to display, information about
this sender and the graphs for the sender are displayed in a
separate window from the main window. One of these windows
can be created for each sender. In this graph, the reci-
pients are the leaf nodes, and the sender is the root node.
Significant routers (ones that are responsible for duplicat-
ing data streams for ultimate output to two or more end-
points) are displayed as black intermediate nodes, and the
paths taken to each endpoint is displayed as colored lines
between nodes.
There are a number of operations that can be performed on
the nodes of the graph:
<Button-1> Displays a small window with the complete path
that the packet takes to get from the source
to this point.
<Button-2> Deletes an endpoint from the graph. This only
lasts until the next RR is received from the
endpoint.
<Button-3> Adds a label that with the name of the
recipient.
<Control-1> Displays a stripchart and updated information
about the endpoint.
<Control-2> Displays a static window with information
about the endpoint.
Also, upon entering a node with the mouse pointer, a label
at the top of the routemap window displays the name and
address of the endpoint. There is a menu that allows the
user to change the method of rendering the route graph, and
two commands that perform operands on the graph.
Endpoints that have not been displayed on the graph due to a
lack of informaton about the path to that node are called
``unfindable''. A little-supported feature is the ability
to display information about unfindable endpoints. With the
debug level set to something greater than 0, a Control-u in
a routemap window will display information about all unfind-
able nodes for this source.
Stripchart
The stripchart window displays the current information
available from RTCP packets from a selecte source. Current
(information garnered from the last RTCP packet from the
host), 5 minute averaged and long term averaged information
is also displayed. Clicking on the name of one of the
statistics changes the values displayed on the stripchart
below.
SEE ALSO
Schulzrinne, Casner, Frederick, Jacobson, ``RTP: A Transport
Protocol for Real-Time Applications'', Internet Draft,
available via anonymous ftp to ds.internic.net in internet-
drafts/draft-ietf-avt-rtp-*.
DISTRIBUTION
MSessMon is available via anonymous ftp to
hibp6.ecse.rpi.edu in pub/msessmon.
ACKNOWLEDGEMENTS
MSessMon was would not have been more than a passing thought
without the continued assistance and direction of by Ron
Frederick at Xerox PARC (frederick@parc.xerox.com). The
rest of the AVT working group has also been of tremendous
assistance.
Micheal Himsolt, Universitaet Passau for writing the SGraph
package.
Dr. John Ousterhout for Tk/Tcl.
Regents of the University of Victoria, Wellington, NZ, and
whoever at that institution created the stripchart widget.
AUTHOR
Paul Stewart (stewart@rpi.edu), Rensselaer Polytechnic
Institute.
BUGS
This application is not completely up to the RTP RFC level,
but then again, nothing else is at this point.
The stripchart interface code isn't completely stable, and
therefore some intermittent crashing may occur.
Sometimes information in the stripchart widget is invalid.
Unfindable endpoints aren't easily displayed.