Mike and Dan should be getting an e-mail from Todd with Windoze NT login information for TMS access, if approved. TMS lives (and dies) at http://129.101.156.185/tms/. I can show you how to get around in TMS, particularly the Monitoring section, which is the best route to extending or terminating a conference.

 
Okay Matt. You probably did not tell me that, but I just remember using the MCU from before the advent of TMS, and back then I could manually change the length.

So, next question: should I be able to log into TMS, or should I just call you (or whoever) when I need to increase the meeting length?

 
Mr. Mike--Any meeting that has been set to automagically connect (using TMS) will also be ended automagically by TMS. The only way to change the end time is to do so in TMS. Otherwise, TMS will take control of the meeting and end it as scheduled. I may have said otherwise sometime back when we first started using TMS--sorry if I did, I did not understand the process then (like I do now???)

 
Okay folks, I have a problem. I have tried to lengthen a number of meetings going through the MCU, and it never works. Each time, I go into the Conference Configuration and change the max call duration to a larger number, then I save it. Once it is saved, I go back to the conference, but it still ends whenever it was originally scheduled to end. Obviously, this can be...problematic...at times. Does anyone see a problem with what I am doing or have they experienced the same problem?

 
Regarding the Boise connection below:
If this was #20043904 Water Resources Tech Review meeting on 1/22: At connection time I was watching the MCU and everything looked good then. I could see video from all sites in the MCU snapshot window. All connections were complete by 11:20:15, according to the Connection Log. As far as I know we were not contacted by the Moscow (Morrill) participant (it looked like it might have been Bob Mahler).

Or was this #20043929 Water Resources meeting on 1/21? According to the Connection Log all connections were complete by 07:20:25. I was not monitoring this meeting.

 
Hi Anita. Hope all is well with you.
I wanted to let you know of some problems we had with the video link to Boise (B3) yesterday. We spent the first 15 minutes of our meeting trying to get video on the Boise end. Donna Cosgrove, after some effort was able to make contact with Keith at the Boise Center who quickly resolved the problem for us. This was a situation where we had a meeting with state officials in charge of one of our contracts. We can't expect them to know how to fix problems with the video link, which means that we need someone from Boise to be on hand at the start of a connection. If this is a one time incident, then it is no big deal. But if you are encountering lots of problems with the Boise connection, then it is a concern. Seems like recently the connections have been good until yesterday. Thanks, Gary Johnson

 
Due to the apparent popularity of the 'enhanced continuous presence' video mode in multipoint calls I think I will start scheduling most meetings that way. Please let me know if you get any feedback, positive or negative, about this from videoconference users or if you have any feelings about it. It is something new so probably not all users will be happy but it seems that many that have tried it so far like it.

 
The instructor for EdAd 526 last night noticed that the lights were too dim in B3 and asked the students there to turn on all the lights. The trouble is that they turn the lights down in order to be able to see the video from their projector but when the lights are down remote sites can not see the faces of people in that room.

 
Reading through some web sites about the recently revealed H.323 vulnerabilities, I came across this from Tandberg by way of NISCC:

Some malformed H323 signaling can result in denial-of-service (DOS) for TANDBERG videoconferencing endpoints. The endpoints will appear to hang for a while, then restart automatically, returning to normal service. [my emphasis]
There are no known issues which involve compromising of audio or video in an encrypted conference, or other loss of sensitive data. We expect to have product update(s) resolving these known issues in Q2-2004.
For further information on this issue contact: security@tandberg.net

This is not unlike how I would describe the troubles we are having.

I talked to Huba about this an he did not think I was crazy to suspect an attack. He said he will point his intrusion detection system at the MCU. He says there is no attack signature available yet from Symantec Deep Threat Management Services but he may be able to see some activity if someone is trying to hack in. He says that so far there has been no malicious code detected that exploits the H.323 vulnerability but denial of service has been detected. I have written to Jordan about the availability of a software patch but have not heard back yet.

 
Today's ECE 542 was scrubbed due to connection problems.
The connection went through ok to Post Falls and Engineering but the conference (3) would spontaneously clear i.e. not only would the endpoints drop, the conference would end after about a minute. I tried rebooting the MCU but that did not help. At the same time I was trying to connect Twin Falls and Idaho Falls into Conference 1 via IP. Neither IP connection would not go through so I used ISDN for IF. After we gave up on PF, TF was able to connect.

 
Today Daryl experienced numerous spontaneous drops of Don's codec in a test call to MCU Conference 1. Later, the connection seemed to stabilize but mcu web pages were not loading properly e.g. when a new conference started in conference 1 he was still seeing a snapshot from Don's codec. Also, at times, the whole upper Conference Status pane of the Conference 1 page would be blank. I have had some spontaneous drops from the MCU recently with the Moscow Ag 3 codec.

 
According to Dave A, Idaho Falls now has increased IP bandwidth available for videoconferencing. Therefore we should be connecting to them via H.323 as a 'default'. If we have any troubles we can always go back to 'tried and true' ISDN (H.320) connections.

 
The CDA1 site disconnected for no apparent reason tonight at about 6:35. I couldn't redial right away, but after calling the room and then trying the Tandberg again, everything worked fine. I don't know what happened. Evie said it just hung up. It is possible that it was Ed103 that hung up.

 
Mark could not see any trouble with the network connection on the mcu. One suggestion he had is to try the other network adaptor in the mcu and see if the problem persists. Today's mcu meetings went flawlessly. Another possible reason for the errors is an attack of some kind. Also, I think the trouble may be related to the web interface. Oy, I wish I knew more.

 
I had to do a hard reboot of the MCU today. Web pages from the mcu were not loading completely and they were not responding to mouse commands. I power cycled the mcu remotely and it started responding. I think there are some IP network issues with the mcu. I will call Mark Q and see if he has any thoughts about it.

 
Today's connection between Moscow/Boise/Pocatello required a reboot of the mcu to complete. Moscow and Poky sites were IP and they seemed to be the trouble. The Poky connection would not complete negotiation so decided to restart the conference but the mcu was unable to completely disconnect Moscow. Connection to Poky then went through but had to reboot the mcu clear the Moscow site from the mcu. After reboot all connections went through lickety-split. TMS is down but I don't think it crashed and brought the conference down. Connect Time was 5 minutes after scheduled meeting Start Time.