12-22-03 12:30pm pdt
We connected to parma during the dean interveiw and all we had was a green screen from parma, when aberdeen call
in to us they also had a green screen.
we reloaded parma and reconneted to
them. same thing. when we took the
mcu from enhanced cp to voice switched
both sites were visable.
parma and aberdeen could see and hear us and we heard them but not see them.

 
12/8, 12/10, 12/12, Nezp 101. I had trouble connecting with LCSC. I called their Techs, through their adjustments I was able to connect by 9:00 am. Jessica said they have a new bridge.

 
Parma had problems to day with the presentation. the instructor told me the computer that is usually used in the room is broken and his did not have the right soft ware on it. causing it to be blurry. presentations from IF were fine.

 
I had a volume problem in Ed 301 when i was connecting to B3 had to call Don S to do some testing
as there was no one in B3 to test with.
( audio on the tv has to be in the 30s to get volume)
that was the problem.

 
PRI settings on the MCU have been corrected. Dial-ins (Aberdeen et al.) now will use all 6 channels as needed.

 
In today's PSES faculty meeting (MEd1 IF1 Ab Par Spt TF2 mcu1) Aberdeen connected at 64 Kbps. They were not the last site to connect to the MCU through the PRIs so I think the PRIs are okay into the MCU (Sandpoint came in after Aberdeen and was able to use 6 channels). Parma was connected first and used all 6 channels. But perhaps we should test by further loading the PRIs in a MCU call to make sure all is well.

On the up side, they looked surprisingly good, considering they were at 64 Kbps, and the audio was fine.

 
The MCU now has the new D3 software and it has some interesting features. New picture modes, including Enhanced Continuous Presence, CP 5+1 and CP 7+1, give a large voice switching window bordered by smaller windows that show the other sites. Pretty cool.

Unfortunately we lost some of the numbers in the MCU directory so be sure to check beforehand to be sure a number that you may need is there.

 
Aberdeen codec is again reachable via the web and telnet. I guess Robert figured out the problem. Still can not touch it using TMS, though, so I think that SNMP traffic may not be passing the DMZ.

 
Paula: Un-operated multipoint conferences, i.e. meetings in conference rooms vs. those with full-time Moscow operators, are set to connect in voice-switched mode. If there is a full-time Moscow operator then the conference is set up to connect in continuous presence mode. Unless participants ask for other settings, of course.

 
Hi! HYDR 501, JEB 111, B1, IF1, MCU. Tuesday's from 3:30 to 5:00 pm. The instructor requests that the MCU be set for Voice Switched only, so that all sites can see the presentation. Thanks! Paula

 
TMS was unable to fire today's Law class from the Boise codec. We will have to connect manually until we can figure out why.

 
The TMS failed today to fire PlSc 501 from the MCU, as it did last night for PlSc 4/590. I think the reason is the new password on the MCU. I have updated TMS with the new MCU password so it should be working again.

 
e-mail to Matt Hibler from Don Saraceno. Check the operator sched for assignments to Law 215! PH
As a follow up to our conversation yesterday, I will have someone from my group come over to LAW215 prior to each conference or class to ensure that the unit is on and ready for connection, as well as to facilitate the beginning of each session. Though Daryl and I do have access to that room, I may need to request another key for that room only for the UOVNSS operators, do you see that being a problem? I'm hopeful that this will actually be a it easier for each of us.

 
I talked to Robert, the ISP tech for Aberdeen, yesterday. He did finally acknowledge that the DMZ router path from the codec to the outside world is not working. We are supposed to be able to access the codec via a router IP (not the codec IP) but it is not working. Local Aberdeen computers can access the codec but not sites in the outside world. Robert said he will be checking into the possibility of a bad router. I think there may have been some security measures taken that may have disabled the path to the codec.

Roberta now knows the correct password for the Aberdeen codec.

 
Moscow Ed 103 and Coeur d'Alene 1 codecs have been upgraded to the latest software version.

 
Today's Law 215-B3 class got off to another rough start. Ryan called early because he couldn't connect to Law. I called and got Matt Hibler on the phone, he went down to 215 to check. Matt made the decision to reboot at 2:27, which put an "On Time" start out of reach. Then once it was up, I dialed both site from the mcu. The connection went well, but according to Ryan the Boise data cable was not seated properly. Once this was fixed, I redialed B3 and all was well. Class started at about 2:36.

 
All the connections last week between Moscow Ag and Twin Falls went fine at 512 Kbps. This week lets try going back up to 768 Kbps and see how it goes.

 
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.

 
I have moved the small (Marshall) LCD monitor bridge in CNR to a switched outlet. It will now power on and off with the rest of the rack i.e. you no longer have to swing it open and switch it separately.

 
Got a couple of 'temporary network error' disconnects today trying to connect to TFA at 768 while the TFB codec was in a call. After the second disconnect I tried at 384 and it stayed connected. I talked to Mark Q at the time and he saw no explanation. The graph of the traffic looked normal--there was not enough load on the line to cause the problem.

Mark and Kurt S are both aware of this blog now. So is Google. Members are: Michael Costa, Dan Fitzgerald, Matt Kitterman, Daryl Power, Jodie Mink, Don Saraceno, Anita Mackey, Paula Heaton. Don't forget to publish your posts--if you just post them not everyone can see them.

 
Boise continued....Got a call from Anita, Law 215 unable to connect to B3. Ip'd into the B3 codec and attempted it myself. Same problem, not able to dial out from unit. Called Erin and found that the patch cable was into B2, swapped to B3.

 
Matt, I see that we're still having problems with the TF connection. Has there been any recent discussion with ITS regarding this? Are you aware if we're still @ level 3 priority?

 
All connections to WSU went well this week. Yay!

 
Thanks Mike, I'll pass on your post to Dave A at Idaho Falls. There may be some reason he has bandwidth to that codec restricted.

On another Idaho Falls note, I have been seeing reduced frame rate video from IF2. Video from there is extremely jerky. I have not been able to find any reason for this in the codec settings. Has anyone else noticed this? I assume it is not just that people in Idaho Falls are jerky.

About the Twin Falls connection, I fell down on two counts. That connection should have been cancelled but I must of overlooked that, and I should have let you know. Sorry about that. CSI is handling the connection from now on via ISDN so our codec is not involved. Looking at the traffic graph for the UITF T1 line at NMS it looks like there is spike in traffic to TF running from about 1930 to 2100. Perhaps there was someone doing a big download at that time. I am running a class to TF right now at 768 Kbps at isif resolution and it looks awesome.

 
While I was monitoring PLSC 490 tonight, I saw that Idaho Falls was only connecting at 256 kbps. Boise also dropped out early (16:30) but I think this was because there were not students from Boise there.

Later, I again had the problem with Twin Falls of a slow connection speed (192 kbps).

 
I have changed the Echo Control Parameters on the Twin Falls A codec so that the echo problem from the classroom is reduced. I do not know how this will sound when the codec is used in the conference room so please listen carefully to received audio from conference room: We may need to re-adjust the echo control parameters if the new settings don't work in there.

 
More trouble at WSU network this morning. Call bandwidth rapidly became restricted down to 192 Kbps. Class was able to go through even though video quality degraded.

 
Mark Q called this morning about exprimenting with some QoS settings on the UITF circuit. We will be trying some Level 3 settings today starting at around 1300. It should be a good time to stress the system a bit since we will have two concurrent calls to TF going from 1330 to 1430. Usually I run that class at 768 Kbps and I may try that today. My understanding is that we should be able to do that--768 for a class, 384 for a meeting, the rest for regular internet traffic. Is that correct?

 
I had Mark Q on the phone while we were having the bandwidth clog yesterday (up to about 1360 Kbps going to TF). He changed some settings (buffer capacity, I think) while the clog was happening. At about that same time the traffic spike declined, possibly because Jodie was running around pulling the plugs on peoples' computers. :-) For one or both of these reasons the video bandwidth improved and packet loss declined and the meeting was successful from around 1600 Pacific. Last night's class was successful, I think, so we are batting .300 on that one.

 
Mike--No guarantees with babies? Shoot, they don't even come with instruction manuals! I'll let Casey know you'll be monitoring from Ed.

 
Matt--I don't have my mobile phone right now, and I am not sure when I am going to get it back. I gave it to my brother to use until his baby is born (so that his girlfriend can get a hold of him at any time to take her to the hospital). Baby is supposed to be born this weekend, but no guarantees. Instead, we may want to give them a room number (Ed 103) and I can be sure to be there to monitor.

 
Mike/Jodie--It looks like our mcu conference started a little bit too early, before the ISU mcu had built its conference to accept the call. Poky only allows incoming calls at 5 minutes before start time and our clocks may have been off by a bit. I talked to Casey and gave him Mike's mobile phone number--he now knows we are monitoring the mcu (apparently his boss told him we weren't).

 
The sites in MPH 502 are ISU-Pocatello and Twin Falls. I'll forward your post to Casey in Poky to see if he has any thoughts. Jodie--do you know if class ended early?

 
I was monitoring a class running through the MCU tonight (MPH 502 6-9pm) and I noticed that Idaho Falls was again connecting at only 192 kbps. Don't know why, and I am not sure if it messed up the class or not (at least no one called me about it). Could be that no students showed up. The monitoring screen turned black at about 6:20 (I think everyone went home), but TF was still connected.

 
Regarding today's mis-connect to B3 for the ME dept mtg--I had changed the site to B1 in TMS by way of the Conference Control Center but it apparently did not 'stick' in the event database. It seems that this way of modifying an event does not always work. Modifications do seem to work when you go in through Booking and Edit an event. Also, be aware that TMS will always try to connect over LAN first. Something to look out for when adding sites on the fly.

 
The UI-WSU link looks good both directions (for the first time since the semester started). It seems that WSU found the problem on their end.

 
Jodie--The only traffic investigation I can think of is to talk to the TF network sysad and see if she/he can explain it. If you can get me a name I can pass it on to Kurt Smith (the network guy up here).

 
Looking at the graph of traffic on the Twin Falls T1 line I see a spike from about 1420 to about 2020 yesterday. This spike ran at about 90% of line capacity almost that whole time. Really more of a plateau than a spike. This is certainly what clogged the pipe and made the TF connection last night run badly. Does anyone know the name of the TF sysad? I wonder if we should contact him/her and see if it is possible to find out what caused the traffic spike.

 
The audio from TF classroom has always been a problem. The trouble comes mainly from the mic/room configuration. There is little the operator can do to fix it. I also think part of the trouble results from sharing the codec between two dissimilar rooms. I have brought the issue up many times and Don is aware of it. Muting the system whenever possible is the correct short term solution. Another possible short term fix is to schedule as many classes as possible in the TF conference room.

 
Ag 416--TF2 has a problem tonight (M@ knows about it already), they could only connect at 192 kbps. This was a headache, but workable (Paula, they will be calling for a copy of the video). They also have a second problem--their audio stinks. I think the controller in the room has no idea how to mute the mic. So, I mute the system for them. The obvious problem with this is that they cannot ask questions whenever they want to. He needs to be taught/shown how to use the basics of the system--or he needs to be refreshed.

 
The scan converter in Ag is now controllable from the control room computer. Scanned computer video position, size, zoom, pan, etc. can be adjusted via the CORIO Control Panel program, accessible from the desktop or Start Programs list.

 
Looks like my fault on the Sandpoint dial. I must have got the dial direction wrong in TMS.

 
Hey Paula, I played with the CG today for about 15 minutes. I didn't have any troubles, but I was not trying to do anything complicated.

 
Some trouble at Aberdeen:
Jodie reported--and I heard it too--that instructor audio from Aberdeen during the PlSc 4/590 class sounded distant. Perhaps the podium microphone needs adjustment. Also, Kristi reported today that their student camera has been broken for at least a week--it will not pan, tilt or zoom.

 
Hi Mike! When you are up in Ed 103, would you check out the Character Generator? For me it has been freezing and rebooting itself. Let me know if you have problems. I was able to work with it for 15 minutes a few days ago and now it seems I can work for a minute and it reboots itself. It could be impatient operator error! Please let me know if you have success!! Paula

 
Today's AVS 474 between Ag and TF1 had totally awesome video. The codecs were able to use isif resolution at 768 Kbps. We do, however, still have a bit of trouble with echo from TF.

 
The report from WHETS Network Ops is that today's bandwidth problems between UI and WSU were caused 'mostly' by a denial of service attack. They think it has been cleared.

 
All point to point CV connections will be dialed by Moscow to the Distant Site. Please see exception below!

Any MCU connnections will be connected by TMS, Moscow. Ask Matt if you have questions, 5-7945.

TEMPORARY EXCEPTIONS:
If Aberdeen is involved the meeting/class, they will dial into MCU 1.
If Sandpoint is involved they will dial into the MCU Assigned.

Due to current billing issues do not dial Aberdeen or Sandpoint.

 
TF is unable to access their codec via web from TF1 podium computer.

 
Tested the connection from TF to Pocatello. Neither was able to direct connect to the other. Poky requests that we route the Wednesday night 6-9 class through the mcu. Jodie will be submitting a request for the mcu.

 
Yesterday had some trouble connecting to Twin Falls. The best bandwidth that their codec could negotiate was 194 Kbps or 256 Kbps. They were unable to connect at 384 for a time. Today I talked to Kurt Smith about the T1 clog. He looked at the circuit log and said that there was a spike in traffic at the time we were having trouble and that was probably what caused it. He also noted that at this point we are in the 'best effort' phase of videoconferencing on that circuit--we have not implemented any Quality of Service yet. Mark Quigley says that there is to be a new router installed at Twin and that will likely be the time to start setting up QoS. Mark is contacting the TF sysad to confirm duplex and speed settings on the TF router. He is also updating the DNS entry for that codec.

 
All classes going through JEB 111, we want to try to channel them throught the MCU, even if its a point to point call. One of us will go over to JEB 111 and get the class started and then monitor it here in Ag Sci 6.

 
CNR control room computer has been de-wormed (have to get it to stop hunting mice) and it's port has been re-enabled. I moved the monitor to an unswitched power outlet so that it will be more apparent when the computer is actually turned on. Both CNR computers are now windows and virus scan updated.

 
New wireless mic is now installed in CNR. It works well and is a better design than the old one.

 
The new IP addresses for Twin Falls are:

Twin Falls 1/2: 129.101.165.106

Twin Falls 3: 129.101.165.126

Please update your address books, directories and favorites lists.

 
PRI to Twin Falls is now disconnected. All calls to Twin are now IP only. Tested with two concurrent calls at 768 Kbps--one to TF2 other to TF3--and it looked solid. There was no measured packet loss or jitter. SNMP traffic (TMS) now passes to TF.

 
Did more stress testing on the UI-WSU gigalink yesterday. Ran 4 calls at 1920 Kbps and one call at 768 Kbps simultaneously with no trouble. Also ran 4 calls into our MCU at 1920 with no trouble.

 
Upgraded Idaho Falls 2 codec software to version B7.0 (from version B3.0).

 
Aberdeen codec is back connected to the network. Robert discovered that the IP address on the codec had been changed to match the web IP. Apparently the IP we use to web into the codec is really the IP of the router and the codec has another 'non-routable' IP address. This non-routable address (192.168.0.47) is what had been changed to the web IP address (63.227.132.18). I disabled AutoAnswer to prevent incoming calls while we have billing issues with Aberdeen.

 
Jordan upgraded the Parma codec software to version B7.0 (from version B4.0).
Jordan upgraded the Boise 3 codec software to version B7.0 (from version B6.2).
Jordan upgraded the Moscow Ed 2 codec software to version B7.0 (from version B6.2).

 
Upgraded Moscow Ag 1 codec software to version B7.0 (from version B6.1).

 
Upgraded IF1 codec software to version B7.0 (from version B4.3).
Upgraded MCNR codec software to version B7.0 (from version B6.1).

 
Still no SNMP traffice to Twin Falls codec. This is the checklist TMS generates when it tries to talk to TF codec:
Please Check:
Is the System switched on?
Yes.
Is the System connected to the LAN?
Yes.
Are there more than two Telnet sessions to the system?
No.
Is the SNMP Community Name correct?
Yes.
Is remote administration activated on the system?
I don't know. I can't find any place to turn this on or off.
Has the IP address for the system changed?
No.

 
I have upgraded the Twin Falls codec to software version B7.0 (from version B5.1). One interesting feature of the new software is the Snapshots option. Interesting, but so far useless since I can not figure out how to enable its operation. It may be inoperable until the codec is in a conference. The Snapshots web page incorporates camera source and preset controls so it could be quite useful.

 
Ran some tests yesterday with WSU over the fiber giga link. We had 3 simultaneous 1920 Kbps connections going with no trouble: there was no measured jitter or packet loss or any kind of visible video aberration. We did not get to testing all possible connections but we did connect MAg1, MEd1 and MCNR to three of WSU's codecs: WHETS codec 8, WHETS codec 9 and Holland 24. I think we might want to go farther with load testing. If we include our MCU and WSU's Cleveland 312 codec in a test with the codecs listed above we can run 4 simultaneous links at 1920 Kbps. Then if we can load the circuit with some sort of data traffic we should have a pretty good idea of it's robustness. We should do more testing when we can get data network folks involved who can load and monitor the circuit while we are running the video links. We also need to test cascading MCUs and gateway calls to Engineering Outreach.

 
We are back to manual connections only for all calls until TMS is fixed. I called Eric at Tandberg today but he is on vacation until Monday.

 
TMS appears to be hosed. When I try to schedule or change a meeting I get this useful message: 'You can have a maximum of 0 video participants in this meeting. You have added 3 video participants. Please go back and remove some video participants before you continue'.

 
New dialing instructions per Don/Anita:
For billing reasons, Aberdeen to always dial out to campus.
For technical reasons, off-net calls are not possible from CdA.

 
Frequent freezes from CdA2 in today's meeting. Comment from CdA participant on functionality of meeting by videoconference: 'Next time I'll drive down".

 
Update on ghosting issues in Ed 103. I traded the spare camera for cam 1 then cam 2. The ghosting issue did not change. There was not a camera selected on the camera control box. I selected cam 1 and all the ghosting and blurriness disappeared. I worked with Don on this yesterday, he's thinking! hmmm! Today7/17/03 everything is normal so far.

 
The video from JEB 111 main camera has a 'milky' cast to it.

 
In today's PSES faculty meeting (MAg Ab Par TF2 IF1) we were watching a presentation from Parma. They had selected PC for video source and we were seeing nice SVGA video passed through the MCU. After a few minutes, however, TF reported they were only seeing the main camera. The Parma presenter switched the source so that we were seeing the main cam and moved the shot to the projection screen. This is very confusing to me: how could two sites connected to the MCU be seeing two different video feeds from the same site when Duo Video is not active? Anybody have any clues?

 
Moscow AEE system has an intermittent crackle/click/static problem in the outgoing audio. I noticed it on Tuesday when Anita was setting up the system and I was connected from Ag. It seemed to clear up but Casey in Poky reported that it was a problem in the AEE Internship Review meeting (MAEE ISU(Poc) TF2) yesterday. We will need to check this out, I think.

 
7/10/03, Remember how I said Ed 103 had not had the ghost images for sometime? when I started camera's this 9:10 am they were ghosting, sequence, 2, then 3, then 1. Rebooted cam 1 and 2, shadow still there. Direction of the ghosting on cam 1 is left to right, w/ some ghosting right to left, cam 2's ghosting is right to left.

 
Regarding Blogger:
Don't forget to publish your posts. If they are not published they do not show up on the uovnss blog home page (http://uovnss.blogspot.com).

All control room computers should have http://uovnss.blogspot.com as the home page when you open IE browser.

You may want to set your computer to open this page when you start IE. It is pretty easy to set up: First browse to http://uovnss.blogspot.com. Then click on Tools and choose Internet Options. Under Home Page click on Use Current. Then say Apply and OK and you are done. When you have IE configured this way you can tell at a glance if there is anything you need to respond to. If there is, you can click on the Blogger button and log in and post a response.

 
Thanks Don. Alas, I could not get any video out of the spare camera I swapped for camera 1.

 
Matt, as we discussed, let's start by swapping out cam 1. I believe Paula swapped 1 and 3 which apparently made little to no change. I don't think this is a control line problem, but will be the easiest to eliminate.

 
More trouble with ghost images in Moscow Ed 1 cameras. There was no trouble for an hour of class then the ghosting started. It went away when I powered up the cameras in this order: 2, 3, 1. Then ghosts came back after about half an hour. It apparently spontaneously cleared up again about an hour later. Engineers: any idea what is going on here?

 
Moscow Ed 1 and CdA 1 codecs are back on LAN.

 
Moscow Ed 103 codec and CdA1 codec have lost their LAN connections. I see that Ed 103 is now running E1.2 software. Is this correct for this codec?

 
I had the same trouble with Ed103 cameras 1 and 2 last week. Not only was I seeing a ghost of cam 1 in cam 2, I was seeing cam 2 ghosting in cam 1. And they were crawling from opposite directions! Power cycling resolved the trouble, as it did for Paula. Today, however, I could not clear the problem by turning the cams off and on. I tried turning them on in different orders but did not find a sequence that worked. I ran the class with camera 1 turned off. After class I turned Camera 1 on last (after 2 and 3 were already on) and the problem was gone.

 
Don, Remember the other day I was telling you about, the transparent image repeatedly rolling across the image of Camera 2? Well tonight it began doing that about 45 minutes into the class, I have it on VHS tape. This rolling image makes Camera 1's image really blurry. I have figured out that the rolling image is camera 2 in transparent form. The rolling is from right to left. At some time the rolling began on cam 1's blurry image. At the class break I turned cam 1 & 2 off and back on again. The problem stopped.
Paula

 
MCU took a massive hit of some kind today at 1322. Four of the sites in one conference as well as one of two in another dropped. IF was the first to disappear. IF was doing some testing with their portable unit at the time, connecting to the mcu.

 
Regarding TMS and CaSP 536: Wednesdays both CdA1 and B3 are in use for Law 975 immediately prior to CaSP 536, which also involves those rooms. Therefore the scheduled start time for 536 is 4:55. I'll shave a few more minutes off of 975 and see if I can get a 4:52 start time for CaSP 533 (starting next week in JEB). I manually added Boise to your class yesterday since TMS is not playing nicely with B3. Well, parts of TMS don't want to play anyway. The Graphical Monitor module in TMS can see B3 in a meeting just fine but if you flip back to the conference in the Conference Control Center it shows B3 as disconnected. TMS will not allow ISDN dialing from the MCU to B3 so I have been trying to have TMS fire B3 to dial in, but that hasn't been working.

 
TMS, CASP 536, at 5:50 the message Sched mtg in 5 min, at 4:55 sched mtg 1 min, at 4:56 connected, Ed 103 & Cda, at 4:59 Boise was connected. TMS says CASP 536 for 4:55.
TMS says ADED 577 connects at 4:50 and it did. Matt will you adjust the dial time for CASP 536 so we have a five minute lead time? Thanks! Paula

 
CdA2 troubles:
Participant in today's mcu conference in CdA2 reported her incoming audio became a screech or whine and she disconnected. When I reconnected her the problem cleared. Participant also reported multiple freezes. The received audio from CdA2 is about twice as hot as other sites. When CdA2 unmutes their mic their AGC pumps up mic audio to extreme levels and room noise becomes a major problem until there is some actual voice audio and the AGC resets. Point-to-point (Ag-CdA2) later in the day ran flawlessly.

 
The wireless instructor mic from CNR is now in Ed. There is no wireless mic in CNR.

 
The wireless instructor mic in Ed 103 is dead. I took it to engineers for repair.

 
Regarding operator support at CdA1--
Joe is doing a great job operating the camera in CdA.

 
Regarding operator support at Boise--
Erin left the B3 room unattended on the first day of class. The CaSP 536 students needed to unmute their mic but did not know how and disconnected themselves instead. They apparently did know enough to call Erin since she came into the room just after I got them reconnected. Then she left again. Boise accidentally disconnected themselves again later.

 
Regarding operator support at remote locations--
Today's research seminar had no operator in Twin Falls or Idaho Falls. Neither location had a decent cmera shot and I had to mute IF due to noise. Parma support was good, with a good camera shot and participants knowledgable in use of the mute button.

 
CdA2 today had a couple of 30 second freeze and a spontaneous disconnect from MCU. CdA participant reported audio cutting out and severe tiling.

I have disconnected the Iomega external CD-R drive from the CNR control room computer since it was not working properly and was generating annoying error messages. Will reinstall/reconnect at a later date.

 
Regarding Boise connectivity--
When I request system information for Boise 1 and 3 in TMS I get this message: Receive or Send method failed. The socket is not connected. This is odd since the rest of the connection seems okay: I can web into the codecs, etc. Might have to ask Tandberg what this means.

 
Still unable to reach the Twin Falls codec via TMS. It still returns a SNMP error. I talked to the network person at TF and he checked out the SNMP service to the codec IP using a 'SNMP walker' program. According to him SNMP traffic is going fine to the unit. I think the problem may be with TMS or the server that it is running on.

 
Tested the giga link to WSU today. Ran two simultaneous 768 calls to the WECN mcu at WSU while Mark Quigley hit the link with FTP traffic. At that load Mark saw about 20 Mbps of traffic on the link, about 2000 packets per second. Mark shut down the link and the traffic was rerouted to the old route to WSU with only a minor glitch. Turning the link back on there was no perceivable glitch in the video. The video quality was good throughout.

 
Wow,,, I made it. OK, right to my immediate concern. Some of you may already be aware of my recent conversation with Boise. If not, that's most likely a good thing. What I would appreciate from all of you involved in operations, to carefully monitor the begining of every class and meeting. What I need to know is: 1) Are our sessions starting on time? 2) Are the untis accessible if you attempt to IP in?
3) Is there a facilitatitor in the room to check connectivity prior to each session? 4) If they are available, do they appear willing to help if they are problems that arise?
This information needs to be as accurate as possible please. Anything else that you can think of would also be appreciated.
Thanks-

 
New MCU Procedures:
From now on we will be firing all calls that use the MCU from TMS. This means that MCU meetings will fire automagically (if everything works as planned and I get things scheduled properly). I see this as a sort of 'shake down period' for TMS before we go to full implementation. There are some known bugs in TMS and probably some unknown ones so we will have to see how it goes. I think there will be a new version out sometime soon so it can only get better, right? If it is a couple of minutes prior to your MCU meeting and it still hasn't fired, you probably will want to go to the MCU web page and manually do it. Unfortunately there is no way to modify or delete a meeting sheduled in TMS in the last 5 minutes before the meeting starts.

 
The new Tandberg codec has been installed in Ed103. The IP is 129.101.85.60. Please update your Favorites lists to include this. I'll send out the password via e-mail when one is assigned.

 
Tested from MCU to ISU(CdA) successfully. Will move the Monday night AdEd 577 class to the MCU. Should improve reliability and monitoring ability.

 
Apparently no students in Boise for CaSP 534. If none registered we will drop the MCU and go point to point to CdA1. Also, due to Memorial Day holiday, the instructor wants to extend class time to 8:30 to reach required number of classroom hours for the course.

 
We were unable to dial from Ed 301 to ISU Coeur d'Alene tonight for AdEd 577. Evi was able to dial from CdA. May try connecting this via the MCU in future so we can have better monitoring abilities.

 
The new Tandberg codec has been installed in Coeur d'Alene 1. The IP is 129.101.75.134. I'll send out the password via e-mail when one is assigned. Please update your Favorites lists to include this.

 
The new Tandberg codec has been installed in Boise 1. The IP is 129.101.93.150. Please update your Favorites lists to include this. I'll send out the password via e-mail when one is assigned.

 
Hey Anita, welcome to Blogland.
Ed Souza did say he was following the registrar's time schedule for finals so what you have below is correct for PlSc 408.
Re: the video in B1: we had some trouble with fuzzy video from their camera last week or so. It appeared that perhaps a camera control cable was loose. A problem with the VCR sounds like a new issue. Did Phil Wilt have a tape to play but it was fuzzy?

 
Anita, I do not know about PLSC 408, but for PLSC 438 they will not be using Ed103 at all during finals week. (They rescheduled to use a room in Renfrew).

 
Don fixed the camera controller in Ed 103. It should work fine now!
Thanks Matt for checking the CNR14 DVD deck. I'll check out Ed 103's this afternoon.

 
Re: CD playback in DVD players:
The DVD player in CNR14 recognizes and plays CDs just fine. Maybe there is something wrong with the player in Ed103.

 
Just to keep you up to date on our H.320/H.323 gateway (Radvision) status:
I had to reboot the Radvison this morning, a typical monday morning occurance. I don't know what is causing it to lose it's network connection but when it came back up I see our friend at Purdue is still trying to access the gatekeeper every 5 seconds or so. This person/machine did give up on these requests for a while but has started up again.

 
Something is wrong with the camera control in Ed 103. On the control room control device, 1 now controls Camera 2, 2 controls nothing, and eveything else works fine. This means that one of the cameras (front left corner of the room) has no control. Has anyone been messing with the controls in here? The remote still turns every camera on, and they are still the same numbers on the remote.

 
Sounds like we got the shaft with the DVD player. That is a huge list of things which it will not recognize.

 
Hello! I'm checking out the DVD Player in Ed 103. The DVD User's Guide says this machine will not recognize lazer discs, CD-I, CD-ROM, CD-R, CD-RW, DVD-ROM. I've tried commercially recorded and burnt cds. The guide says it will play an audio cd or a video cd. Maybe I should try the music cd's that Ben receives in the mail do you think those discs are different than the ones one can buy in the music stores? The machine does work I played the movie Spirit in it the day the new MCU was being tested and have moved about in the directories using the remote TTFN!

 
From: Don Saraceno [mailto:saraceno@uidaho.edu]
Sent: Wednesday, April 23, 2003 12:59 PMFYI, I will working from home until 12:15 tomorrow, then I'll need to leave for Grangeville. Please contact me via e-mail (ui account) if you need to reach me. On Friday, I may need to take my wife to Spokane, so cell phone may be the best.

 
Hi Mike! Thanks for the reply! Please see the blog I wrote 4/17/03 11:57:23, for an explanation about the classroom computer.

Hi Matt, I did use a "burnt cd" I'll bring a commercial CD and try it soon.

 
I know for sure that you cannot use the control room computer to play a CD, but the DVD player should work. Right now the control room computer is not connected to the audio board for playback, only recording. Question: Why couldn't the professor use the classroom PC for playback?

 
Regarding compact disk playback: did you try a pre-recorded CD or a pirate or both? From my shockingly limited experience in the DVD world, I have the impression that there may be some compatibility issues with 'burnt' CDs.

 
Question for you guys! In Ed 103 and CNR 14, is there a way to play a music CD from the Control Room to the classroom? In my experimenting, the DVD player does not recognize CD's and the IOMEGA recorder looks like it can play CD's but I did not find an audio source for it on the audio board. I'll experiment with the DVD player again, it does say DVD/CD/VIDEO CD. Maybe it was the CD that I used. Mike do you have experience with this? May the BLOG be with YOU!

 
Yes! I agree with Mike! I do like the audio in CNR 14 better! Today, I sat through a 2 1/2 hour meeting with CNR14 & B2. B2's audio continued to cut out from 8:30 to 10:30.. (on a good note... when we could hear B2 their audio sounded uniform) When CNR spoke I could hear a lot of loud feed back. I disconnected at 8:35, connected the meeting in MCU 2, audio still cutting out, at 9:30 disconnected and reconnected in MCU 2 again. No change in audio.... I'm looking forward to updated equipment in B2!

 
Sorry, haven't checked blogger for a while, so this question is a little late, but could we do the same audio setup in Ed as is in CNR? It would be nice to have the monitors split between what is going out and what is coming in without needing to switch the AFL or use the PFL. (By the way, great idea Matt!)

 
Paula--Regarding the tiling, etc: I have seen lots of aberations lately on network ISDN calls, too. For instance, Tuesday was particularly bad for freezes: CdA instructor reported multiple long incoming video freezes while her outgoing video (as received at other sites) remained active. She lost audio at the same time, even though we could hear her. Part of this problem may be the audio echo from TF1 classroom. Also, and this is highly subjective, the overall quality of video on the network seems to be down: video seems softer, there is more blockyness to it. It may be my imagination, though, or maybe I need glasses.

 
4/16/03, Computer in the classroom in Ed 103 could not complete assignment, warning was given! 4/16/03, EDSP548, presenter wanted to run a PPT Presentation on a timer to coincide with music from the CD player. Music played fine, the PPT worked fine until we put the 2 together. The timed PPT kept freezing up. Unfortunately the music was shut off and the PPT worked with out a problem, snag, hitch. Presenter was disappointed... Any ideas?

 
Thanks Matt for the new Audio Config I can't wait to hear the difference!
4/16/03, EdSp548, Ed103, Sandpt & CDA1. System had numerous moments when audio switched to Cda and they would green checker board type tileing. If Cda was the site that spoke last and Moscow spoke to them, I could see the tileing. Occasionally, when Sandpoints audio went louder than usual I would see the tileing. Inbetween 7:05 and 7:30 the distant sites froze 3 times at 30 seconds each.

 
New Audio Config at CNR
I panned the inputs on the mixer for the incoming and outgoing audio (lefty innie, righty outtie) so that incoming and outgoing audio is heard in distinct (left and right) monitors. I think this makes it easier to isolate problems and hear what is going on. Please try it out and let me know what you think. All routing, recording, etc. is unaffected, the only difference is what you hear in the control room.

 
Steve at EO reports that he has been having trouble connecting to Boise 3. He has been experiencing frequent video freezes and audio not being passed. This evening he was unable to connect and had to reboot the JEB28 codec. They were able to connect after that via the MCU after reboot. I wonder if this is related to the T1 trouble we have been having.

 
The gateway is back up (thanks for asking) as of about noon today. ITS claims to not have done anything to fix it and I did not either, other than turn it off to prevent possible unauthorized use while we could not control it. But when Don got to the gateway location today, Mark from ITS was already there and said it was working. One possible explanation is there was something wrong with the data cable, which does not explain why I could not get into it via the serial port, but it’s the only explanation I have.

 
Radvision gateway is down. We can not communicate with it because the password has been changed. I suspect it has been hacked. The power is off on the unit to prevent unauthorized use. We will have to use the mcu for a gateway until further notice. I will try to contact Radvision to see if they can get us in a backdoor.

 
Idaho Falls connected to PlSc 408 in mcu2 from their INRA room to avoid problems on the T1.

 
Gateway (Radvision) is still down. Since the microwave is bad today also, had to run EO-WHETS class using mcu conference 3 as gateway.

 
Odd.

 
Dan's trouble was video freezes, not touchscreen lockup.
Also: when I got into the Ag104 control room today the thermostat was set at 90. Is there a conspiracy afoot?

 
Actually was frozen for about 5 minutes before we decided to reset.

 
Dan also had trouble yesterday with CdA1: fairly frequent freezes of about 10 seconds duration.

 
Had a problem with CDA tonight, when they first connected, they were not receiving any audio. I told them to reboot because their CLI screen was frozen. After this everything seemed to work fine.
NOTE: The people in CDA said the room heater was left on and it was over 90 degrees in there, could this have caused the problem?

 
I see Twin Falls classroom (TF1) video is back up. Anyone know what happened to fix that?

 
Completed successful test with Ted Beer at the University of Canterbury,New Zealand. This was a one-way test only (ISDN NZ to Moscow Ag) as they want to initiate the call for the meeting tomorrow. They are 19 hours ahead of us (Moscow time + 19 hours = NZ time). They will be scheduling the meeting this afternoon. It was a nice fall day in NZ.

 
Well, here is my daily entry, another wonderfully uneventful day for me.

Don--I will wait on dialing LCSC again until I have more info.

To all, I let Paula know already, but I will need all of next week's evening work off because of a prior engagement working in my church's Easter production. You are all invited if you want to come, just let me know and I will give you more information.

 
For the 4/16 Kempton meeting: tested MCU IP connection to WSU Vancouver. Could not dial to Vanc, probably due to their firewall. Vanc could dial in to mcu. Connection looked good. This connection is good enough since the meeting is in mcu conference 1 (incoming IP calls go into conference 1 by default) and they are willing to dial this direction. However WHETS Vancouver will work on the firewall issue and we may do further testing.

 
Unable to reach the Radvision gateway from the network, even after repeated reboots. Don has call in to Mark Quigley to check out the network connection.

 
From Don--
From: Don Saraceno
Sent: Monday, April 07, 2003 10:00 AM
Dan, in addition to the EdSp549 class, please continue dial outs to NIC for the Tuesday evening PSYCH316 class. We will make the necessary changes with all NIC classes once this semester is complete.
Mike, I have spoken with Leslie at LCSC, and she will speak with Harold following today's class. We are making an attempt to change the dial direction of the NezPerce102 classes.
Due to the reported audio difficulty with NIC when attempting to dial us, this may take some looking into. I apologize for any confusion cause by these e-mails, please don't hesitate to call if you have any questions.

 
From Don--
From: Don Saraceno
Sent: Monday, April 07, 2003 8:14 AM
There are to be absolutely NO "off-net" calls to be made from any of
the campus sites (including the mcu) prior to discussing this with me.
Currently there is only one exception to this rule, this is Dan's Monday
dial outs to NIC, Dan please continue dialing as we have for that class.
This restriction means NO emergency calls and no tests until I've been
notified.
I will notify the entire group once we've head from AT&T regarding the
rate issue. At that time we may discuss change dialing policies all
together.

 
Whew. Finally got the Ed 301 codec to accept a softrware upgrade. Had to do it via ftp and it was not pretty. Now all the on-campus Tandbergs are at B6.1.

The weekend starts now--let the wild rumpus begin.

 
I found I had the wrong IP address for the Twin Falls codec, both in my records and in the Ag codec directory as well as in my favorites file. It is correct in the mcu directory. Please make sure that 204.134.224.106 is the IP in your codecs and bookmarks.

 
Daryl installed Lou's new codec. I tweaked some network settings (gatekeeper mostly) and populated the directory with IP addresses. I put 20 entries in for Don's office.

 
Hey Paula--Welcome to the blog! I looked at the audio settings on the B3 codec. The audio gain on the mics looks like it may be too low. Also they have Noise Reduction turned off and I don't think they have the Echo Canceller properly set up. Probably need to work with them to get that room adjusted (perhaps their 'consultants' already did this). We should probably upgrade their software too--they are still at B4.1. New version (B6.1) seems to have better error correction and may help with the tiling. And thanks for the kudo!

 
You all, out there in UOVNSS land, are doing a great job!! Whether our customers say it or not, They appreciate you!!!
My Event with ED 103, B3 & IF1 yesterday afternoon, I made a VHS recording of it and gave it to Daryl. B3's audio was hollow sounding at the end of the conference when B3 spoke, I saw the green checker board tileing occasionally....

 
Saw Don/Daryl carrying in a bunch of Tandberg boxes yesterday.

 
Ah, another eventful day at UOVNSS

 
Tested IP connection to North Dakota--successful
Tested ISDN connection to METNet (Montana)--successful

 
We moved the dangling monitor in Ag104 today. It is now the left front monitor. The old left front monitor is now used in a roll-around unit. We will check if we can use the old dangling bracket to replace the remote monitor bracket in CNR14. The tilt allowed by the bracket from Ag104 should take care of most of the glare on the CNR14 monitor.

 
Twin Falls was unable to switch the video from conference room to classroom today at 9:30. Operator error probably--Jodie was away. Normally the instructor is in Aberdeen but today he was in Twin. No one told me this. The Aber students (correctly, it turns out) switched their outgoing video to the student cam. Instructor was asking if we could see him but I could only see students in Aber since I had assigned them the floor while trying to work with Twin on their problem. I did not know his voice was coming from TFsince all we had was black from there. So it seemed like there were two problems: video switching in Aber and room switching in TF. I talked to the students in Aber and learned that instructor was in TF. By then Linda had started the migration to the TF conference room. What a pain.

 
From Paula--
Thursday, today I have a medical appt and will take my lunch at 3:30
- 4:30, I came in at 7:30 so my day ends at 4:30 see ya tomorrow...
Dan is covering for me in Ed 103 from 2:30 to 4:30.

Friday, Annie has an eye appt at 8:30 in the morning, I'll hopefully
be back by 10:30. Daryl will you set up the meeting in JEB 111?

Thanks!!!! Any problems let me know! Paula

 
Hey Mike, glad you're here! For chat we should get icq and/or Trillian loaded on the computers. That way you and Dan can just annoy eachother :-).

 
Ok, I am on. Interesting idea, too bad I can't chat because I work evenings--maybe I can chat with Dan...or is that just going to be annoying for everyone who is trying to send and receive "legitimate" messages. Ok, no chatting...usually.

 
I am now leaving for the day. CdA1 is connected to mcu3 and there is no one in the room. Since we can not disconnect them from here I asked Paula to either reboot the mcu at 5 or get someone in CdA to disconnect.

 
Just finished our meeting and as we discussed I have started this web log ('blog') as a sort of pass-down log. What that means is that this is a place to enter issues, thoughts, ideas, problems, etc. that may be useful to others in the group.

 
This is the first message