IF4, B3, Moscow CNR and Moscow Ed 2 codecs have been upgraded to the latest software versions.

 
I can not reach the Aberdeen codec via LAN/ping/web/etc. Roberta in Aberdeen can see the web page but can not access it because she does not know the password--it has apparently been changed and I don't know what it is either. I have a call in to Robert (their isp contact) and he expects he can look at it this afternoon.

The mic balance from Aberdeen needs to be adjusted--room mics are gating on while speaker is at the instructor position.

 
Is late really better that never? I wanted to make sure that yestreday's problems in Boise were reported. The first report was during the satellite program. During attempts to rid the projected image of the PIP in B2, we noticed the entire image from Boise froze. We quickly dropped the call to Boise, and reconnected. This occured at the same time the tape roll-in needed to start, so I made the decision to start the program on time regardless. The PIP issue was never resolved. That afternoon Ryan called to ask why we had connected to B2 instead of B3 for the Faculty meeting. The data cable had not been moved so the connection went directly into B2.

 
I turned Duo Video off on B1 codec. (Actually, in this case, 'Off', in Tandbergese, is 'Manual'. 'On' is 'Auto'. Found under Presentation Settings in the E software.)

 
Both servers (housing TMS, Meeting Maker and UOVNSS home page) have been having troubles. Todd is working on them. I have my Outlook calendar published here. It may be a useful backup if you can not access the other calendars.

 
Twin Falls audio is problematic regarding echo. I have adjusted the echo control parameters to reduce echo as much as possible in the classroom. The new parameters make the conference room, which shares the TFA codec with the classroom, sound not quite as nice as before, but useable. I had some trouble with TF echo recently, too: I found that they had the incoming audio cranked. If the room volume is too hot it will defeat the echo canceler. I asked the site facilitator to lower the volume to normal level and that eliminated most of the echo. Lesson: if you hear 'excessive' echo from TF, phone the site and see if their incoming audio can be lowered.

 
If we could, it would be nice to find a way to echo cancel the mics in Twin Falls A. Every time I have a class with them involved, I get a hideous echo. I always mute them, but it prevents them from being invovled in the class discussions. I have been told that they have very little control in the room itself, and cannot mute their own mics.

 
B1 is having connection spasms this evening. It is sending video at random rates (so far, I have seen 352, 284, and 216), but receiving at a constant 384. The only problem with this is that the professor is in Boise tonight.

 
Had a problem with TMS tonight. BAE 404 (5 - 8) did not autodial, so I had to go in and set up the conference, no biggie, just FYI.

Incidentally, the UOVNSS home page was also down for a while, so it took me a while to find out who I was supposed to dial.

I think I figured out what the B1 problem is: duovideo is active. I don't know how to turn it off.

Figured out why I couldn't turn it off, the prof in Boise is the one messing with it.

 
The Ed Faculty meeting going on right now is connected to B2. It is supposed to be in B3.
B2 is inadequate for 2-way videoconferencing.

 
Mark Q had an explanation for the Twin Falls drops this morning: seems there was some sort of 'data storm' originating in the Towers and targeting one of the network routers. He thinks this may be some sort of virus or attack of some kind. ITS is watching to see if they can catch the culprit.

 
10/28/03, PLSC 405, Events... disconnected simultaneously w/ the Sat dwnlnk. The first time I added TF back into the MCU, the call disconnected immediately, I called from the MCU again, this time the connection lasted about 3 - 5 minutes, then disconnected.
My 3rd time attempt was disconnected. The 4th time was a success... at 12 pm, TF-256, IF -384, Ag104-192.. at 12:10, TF-192, IF- 384, Ag104- 192, connection stayed stable for the last 20 minutes of class.

 
Once again, Idaho Falls 4 has decided to send video at a slower rate than it receives (228 vs 384). Don't know why. Class is PLSC 490 (4-5:30).

 
Matt, I think it may be time to bump up the Twin connections to 512 Kbps. Let's creep back up. Please post results.

 
There was some confusion this morning with the B3-ISU Idahowomen's Lawyers Assc meeting. Since no call direction was specified, and Ryan was attempting to connect to ISU-Cd'A, the meeting got started late. I called Guy at ISU and had the B3 codec cleared for the conference and added ISU Pocatello to the B3 directory. Connected about 15 minutes late.

 
Looks like TMS might not be working right after all. This evening there was a class scheduled from 5:00 to 8:00 (Casp 535) which did not fire. Paula ended up having to set up a conference for them to dial into because their normal MCU site (site 2) was resting in idle mode.

Everything seemed to go great after that.

 
So far this week there have been no Twin Falls freeze problems at 384 Kbps.

 
Had outgoing video problems again today with Idaho Falls for PlSc 490 (4:00-5:30). During the meeting, the outgoing video dropped to 284 kbps, but the incoming stayed at 384. This seems to happen to a certain extent every week.

 
Even though there is no access to TMS right now, it does seem to be running since it was able to fire an already-scheduled meeting at 10:00 today.

 
I have upgraded Moscow Ag 1 and Twin Falls A codecs to the latest software, version B7.3, released yesterday.
I have upgraded Moscow Ag 3 codec to the latest software, version E2.3, released yesterday.

 
10-21-03 at 5:25 Ryan called and was having problems with video in B-2 from law 215.
I worked with Trevor to try and get video up in B-2. All video was fine in law but Audio seemed hot or echoey. Trevor said the teacher was getting upset due to us trying things. I suggested that we wait till today to do all the testing. The teacher was in B-2 and could hear law and Law could see and hear B-2. Daryl

 
Sorry to hear that the problem in Twin followed the connection, but I guess that's what we needed to know. If decreasing bandwidth eliminates the freezing, please post. As far as I am aware, there should be no restrictions.

 
Mike/Matt,
Regarding the fan in CNR Marshall monitor bank, please slap when needed. However Daryl is working on locating replacement fans. May want to swap out the fans in Ed as I believe they are a year or two older.

 
All my connections to Twin Falls at 384 Kbps last week went fine in regards to freezing--there were no freezes at 384. I think Mike's connections were the same. I would like to continue the 384 connections for this week to confirm these results. In that time I will check on software upgrades for both ends. This does seem to me to be a codec issue and it may be solved by newer software.

 
There is a partial explanation to the problem we had on Wed. with PlSc 4/590. I have learned that when 'pc' or 'doc cam' is selected as the video source a 'request for floor' message is automatically sent to the MCU. So I think that Twin Falls had 'doc cam' selected as video source, but the doc cam was not turned on. Therefore they would have been sending black and requesting the floor at the same time. When a site has the floor, the other sites will see the floor site full screen regardless of the conference mode (voice switched or continuous presence). If the MCU was setting the floor to TF then the other sites would have black for video. This is only a partial explanation because
a) this isn't exactly what were seeing--we saw the continuous presence screen with all sites but Aberdeen in black. Even individual site snapshots (Parma, Moscow, everyone but Aberdeen) from the MCU were showing black; and
b) the MCU does not seem to grant floor requests from Ag when the video source is switched. The request is sent but it is not granted whereas TF's requests apparently are.

 
I found that a good rap in the lower right corner of the face of the Marshall monitor bridge will usually bring the fan back into allignment. For a while, anyway. I didn't notice one of the monitors was busted.

Larry over at WHETS said that their network people were 'trying something' and that is what caused the drops this morning.

 
In CNR 14, the Marshall monitor bank (the 10 mini-monitors, minus #9 because it is broken) was making wierd noises this morning. I couldn't figure out what the problem was, and it was annoying, so I slapped it (lightly). The noise stopped. Now, I do know that this is probably not the preferred method to deal with this problem, so I am posting this to let you know there may be an "issue" with these monitors.

Just call me Mr. Fix-It-Temporarily-With-Physical-Abuse.

The noise just started again. Nuts.

 
Had some problems with AVS 472 (7:30 - 8:30) this morning. The connection is to WHETS codec 9, and for some reason we kept dropping or getting dropped from the connection. Happened once before class started and another time 10 minutes into class. No problems after that.

 
Boise 1 is back up. There is a new password (see new phone list).

 
The phone and codec list has been updated and published. I made the codec IPs clickable links. At the bottom of the page I included clickable links to frequently used codecs. You may want to make sure these are in your favorites/bookmarks lists. Let me know if there are any others I should add.

 
Boise 1 is offline. This morning I found B1 to be offline. It is back on now but it is inaccessable because the password has been changed. They are not connected to the ITS Sysads meeting that they are scheduled to be in right now.

 
Idaho Falls 4 did eventually get connected last night for PlSc 4/590, though I don't know how.

 
Mike--good idea. That is the next thing I want to try. Let's go the rest of this week at 384 and see if the problem goes away. I sure will miss that 768 quality, though.

 
The AVS 404 morning connection to Twin Falls using the TF codec froze again, so I reconnected at 384 kbps instead of 768. From now on I am just going to dial at 384 to start with.

 
PlSc 4/590 tonight--
1) Boise 1 seems to not be able to accept calls. I had to connect them via web from their end. Also, their dialing directory has been erased;
2) Idaho Falls 4 is unable to connect from either direction;
3) Aberdeen is unable to dial to the MCU. I had to dial out from MCU to Aberdeen.

 
The Twin Falls freeze problem followed the connection to the TF conference room. We moved AVS 474 to the conference room to see if we could isolate the freeze trouble but about 4 minutes into class today TF called and reported that their incoming video was frozen. A reconnect cleared the freeze. Froze again at 1344. Reconnected at 384 Kbps.

 
Boise 3 was not switched/ready to accept call for today's FCS Faculty meeting at 1130. I called and Ryan got it changed at 1135. There was the same problem last thursday for Law 974.

 
Regarding IP connections to WHETS--Our gatekeeper is now 'neighbored' with the WSU gatekeepers. This just means they are talking to eachother when doing their gatekeeperly things. So now we do not have to register our codecs with the WHETS gatekeeper to do a WHETS MCU GK call. As long as our codec is registered with our GK, you only need to dial the number of the conference/class/meeting. For instance this semester we frequently connect to '2' at WHETS. Now, instead of going in to our codec and re-registering with 134.121.235.189, we can just dial '552'. ('55' is the prefix for the WHETS GK.) This will work as long as our codec is registered with our GK (129.101.195.222) and all our IP-capable endpoints should be registered.
Isn't being neighborly fun?

 
More freezes on Twin Falls incoming video on Wed. and today in AVS 474 class. Reconnect cleared the freezes.

 
PLSC 490 (16:00 - 17:30) had a problem with Idaho Falls 241 outgoing video again. The video going in said it was being recieved at 384, but the video going out was only being sent out at 216 kbps. This was not for the whole class, beginning connection was good, I really noticed the change at 16:45.

 
IF4 and Moscow Ag 3 codecs have been upgraded to E2.2 software. I was able to do the upgrade on the Moscow codec via TMS but I had to do the Idaho Falls codec from my computer as there were network errors when I tried to run it from TMS. The E2 software has some interesting features, including H.264 support.

 
The Idaho Falls portable 880 codec (IF4) has been added into TMS, though it is not always fully reachable by TMS. This is not an uncommon issue--off-campus codecs sometimes don't respond to TMS Inteligent Diagnostics queries. For instance, right now B1, CdA1, IF1, IF4 and TFa codecs don't respond to ID. Sometimes they do, sometimes they don't. Sometimes there is a telnet error returned, sometimes there is a SNMP error, sometimes the failure is not specified.

 
About the Twin Falls freeze issue--The trouble does not seem to be related to network traffic. I am begining to wonder if there might be some problem with the routing in TF. Or perhaps a problem with the TF codec.

 
About last night's Idaho Falls connection--this sounds like it could have been caused by using IP to connect instead of ISDN but we will keep an eye on it.

 
Having issues with the morning AVS 404 class again (connection between Ag 104 and TF 1 through the TF codec). Our view was fine, but they said that their view was frozen. The same thing happened last week, except it was our view that kept freezing.

I reconnected at 384 kbps (instead of 768) and everything seemed to work fine after that.

 
Tonight the video from Idaho Falls 1 to Ag 104 was having some issues (AgEc 301, 16:30-17:45). The Tandberg site claimed that everything was going fine at 384 kbps, but the video kept freezing and tiling. Very annoying, but the class only met for 20 minutes to review a test taken on Monday, so no one cared.

 
Wednesday and today Twin Falls experienced frozen incoming video at the start of the AVS 474 class connected to Moscow Ag 1 at 1320 Pacific. There was full motion when we first connected but then TF's video froze. A reconnect cleared the freeze both times.

 
The call rate must have changed a couple of times: when IF first connected they were at 384, then it went down to 320. It was only a one-way reduction, however: when their outgoing rate went down to 320, their incoming rate was still at 384, at least at the begining of class. So the IF students would not have seen any degradation of video.

 
While monitoring PlSc 4/590 today, I noticed that Idaho Falls was coming in at 320 kbps again. I also noticed that this did not happen until after Aberdeen was added to the conference.

Note: Later in the same conference, Idaho Falls jumped back up to 384 kbps and held till the end.