[AG-TECH] Multicast Debugging Information

[Bill Nickless]

Thank you Ed,

I agree completely that the first and foremost priority is to make the 
meeting work for the attendees.  You're absolutely right.

However, if the network doesn't work properly for a meeting, that fact 
needs to be communicated to the network people so that it can be fixed.

And it's still true that the network people need to know all of the things 
I mentioned below: source/group IP addresses and a receiver that's not working.

The beacon can fill that requirement--but the node operators still have to 
be sure the beacon client is running, and then tell the network people 
about problems they run across.

At 01:25 PM 2/20/2003 -0800, Ed Ritenour wrote:
>Bill
>
> From an operations point of view I agree with the first three items, but our
>goal is to make the meeting a success. We have found that our users don't
>necessarily care if the video is down as long as they can still participate in
>the meeting. To do that they need need audio and slides. We have found from
>past experience that it is unlikely a network problem will be resolved during
>the testing process anyway and waiting up to the last minute to attempt
>bridging or calling into an audio bridge makes it difficult to have successful
>start.  By moving forward early on there is still time to finish up the power
>point slides and any other in room issues. The client is still happy and 
>if the
>network comes up during the meeting that is all for the better. I realize this
>makes it more difficult for troubleshooting so we should provide as much
>inforamtin then ensure the clients needs are met.
>
>Ed

===
Bill Nickless    http://www.mcs.anl.gov/people/nickless      +1 630 252 7390
PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7     nickless at mcs.anl.gov