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 (firstname.lastname@example.org). 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 (email@example.com), 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.