msessmon - Multicast Session Monitor

     msessmon [ -display display ] [ -address address/port ] [ -
     type displaytype ] [ -debug level ] [ -help ]

     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.

          Use the X display display to open windows on.

          Monitor address/port pair  address/port  for  multicast
          RTCP transmissions instead of the compiled in defaults.

          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.
               roundscale     Experimental algorithms that may or may not
                              look tasteful.

          Sets debug level to level. The default debug  level  is

     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
          <Button-3>     Adds a label that with the name of the
          <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.


     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

     Schulzrinne, Casner, Frederick, Jacobson, ``RTP: A Transport
     Protocol   for  Real-Time  Applications'',  Internet  Draft,
     available via anonymous ftp to in  internet-

     MSessMon    is    available    via    anonymous    ftp    to in pub/msessmon.

     MSessMon was would not have been more than a passing thought
     without  the  continued  assistance  and direction of by Ron
     Frederick at  Xerox  PARC  (   The
     rest  of  the  AVT working group has also been of tremendous

     Micheal Himsolt, Universitaet Passau for writing the  SGraph

     Dr. John Ousterhout for Tk/Tcl.

     Regents of the University of Victoria, Wellington,  NZ,  and
     whoever at that institution created the stripchart widget.

     Paul  Stewart  (,   Rensselaer   Polytechnic

     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.