Not sure what happened, but while I was in a MCU call between Aberdeen and Ag1, the screen kicked over to green and black just after noon. I clicked on the button to assign the floor to Aberdeen and it cleaned up the picture.

The call did begin in Enhanced CP mode with Parma as a third participant, but Parma dropped out at least an hour before the green and black problem developed.

 
The wireless mic is back in CNR.

 
Bingo, gringo! For the last three Mondays (including tonight) we have experienced a video glitch (green screen or freeze) at 1730 in the class connected in Moscow Ed 1, Boise 1 and CdA 1. This time coincides with the disconnect time of the other MCU class going on at that time.

 
Boise 1, Boise 2, Boise 3 and Boise 4 codecs have new IP addresses. They now end in .21.2, .21.3, .21.4 and 21.5 respectively. Be sure to update your favorites/bookmarks. Passwords remain unchanged.

 
The UI is now in the ViDeNet Global Dialing Scheme. This is a numbering plan for video and voice over IP. Essentially this means we are peered into a global hierarchy of gatekeepers. Our prefix is 0011629. This will not change much for our gatekeeper dialing as it stands now, except for increased flexibility in IP MCU calls. An example: an outside GDS-enabled system e.g. the University of Outer Slobovia, could dial 0011629103 to connect to MCU Conference 3 or 00116292807 to connect to Ag.

 
I have changed the Cascading Mode in the MCU Conference Template. It is now set to 'Master' instead of 'Auto'.

 
CNR operators have probably already noticed this but it should be noted that when you power up CNR, the third mic from the door in the first row wakes up in the 'on' mode. If you are getting unexpected classroom audio it may be from this mic.

 
The wireless mic in CNR is kaput because of a broken wire (yeah, I know.) We have temporarily moved Mic 3 (the Sony) from Ag to CNR. In case you haven't used this mic before you should know that both the transmitter (the part the instructor wears) and the receiver have batteries (2 AAs each.) Be sure to turn on and off the rcvr when you turn on and off the xmtr. There is a battery strength indicator on both rcvr and xmtr. If you replace the batteries in one you should change the batteries in the other at the same time. The rcvr is on the counter by the control room door.

 
The MCU had to be rebooted yesterday. It was not allowing any participants to be added to meetings due to bandwidth restrictions. But there was plenty of bandwidth available. Very mysterious.

 
More on the green screen. Last night at about 1720 or so, in Ed1-CdA1-B1-mcu connection, CdA got the green freeze frame. I do not know if Boise got it as well. We did not see green at Ed. I forced the floor to Boise and the freeze cleared. It occurs to me that this happened at about the same time as PlSc 404 (Ab-Par-IF2-TFA-mcu) is disconnecting and EdSp 540 (CNR-ISU/CdA)is connecting. Today's guess: ISDN glitch at connect/disconnect is causing freeze frame in MCU.

 
This is from Jodie:
ASM 315 (TF1- JEB 111) from 3:30 - 5:30 pm (2:30 -4:30 pm) taught by Howard Neibling had problems last week. Around 4:40 our time, the incoming video screen turned 1/2 bright neon green, with the other 1/2 being black. They lost all video and audio. I contact Don, who had me contact Matt in the control room. Matt was also able to see the weird screen being sent from JEB 111. By this time, Howard had concluded class. Matt was able to add himself to the conference, and then the conference cleared up. I talked to my other room operators and they have not seen any thing like this in other classes.
This is from me:
I saw the same video as Jodie in the MCU snapshots: Snapshots from both TF and Moscow showed the same green/black screen. I have seen the green screen in MCU calls connecting Ed and CdA. Both sites will see green for seconds or minutes. As Jodie noted above, a video switch will usually clear the problem. I think there was no trouble in last night's ASM 315 but this seems to me to be more of an occassional problem than intermittent one. My guess: some sort of transcoding glitch when bridging ISDN and IP.

 
Hey Mike--I have changed the Disconnect Time for Ent 322 to 1025. You should be safe to connect to Boise any time after that without TMS disconnecting your call. Unfortunately TMS still thinks there is no ISDN capability in CNR so I could not set up an Automatic Call Launch for CE 4/522 without utilizing an MCU conference. You will still have to manually connect that class.
Let me know if this setup does not perform as we expect.

 
New board in Model 60 fixed ISDN connectivity for the MCU. We are back to normal connections for multipoint calls.

 
Mike--I bet I know what is going on with your mysterious 10:30 disconnects. It is because our 'standard' scheduling window runs one hour and 10 ten minutes (1:10) e.g. Ent 322 connects at 9:20 and disconnects at 10:30. TMS Automatic Call Launches (like Ent 322) send a Disconnect command according to the call duration set when the event is entered into TMS. I think that TMS is not smart enough to know that you already manually disconnected, probably around 10:20, and sends a Disconnect command to your codec, dropping you from your Boise connection.
Probably the best thing to do in this case is to shorten the Ent 322 connection so that it drops at, say, 10:25. This will work fine as long as Ed doesn't run more than 5 minutes over. At the same time I think we could set the CE 4/522 class to launch automatically at 10:25. Let me know if that seems like a good plan.

 
The MCU has no ISDN connectivity at this time. Probable culprit is a blown board in the Model 60. We should have a new board tomorrow. We are set for all MCU calls to go on IP Only until tomorrow afternoon but please watch automatic call launches carefully as TMS may still be a bit flaky. Also, some connections may be not so good due to IP bandwidth limitations.

 
This is a recurring issue that has not been a problem until today. Every week, after ENT 322 on Tuesdays, I need to call B1. For some reason, the call hangs up at 10:30 exactly every week. My theory is it has something to do with the MCU, but I don't know. Normally, this is not a problem because class has not started and I just reconnect the call. However, today I was unable to connect to B1 for some reason. I called them and they were able to connect to me--actually, it turns out they didn't even need CV today, but that is not the point. My point it automatic call dropping at 10:30 every Tuesday is annoying.
Please, some technical guru (insert Matt or Don's name here), fix this annoying habit.
Thanks.

 
I have started investigating the Boise 2 issue, but have not yet gotten to the bottom of the problem. I believe all connections via the MCU are good, but I will continue to work on this in the morning. Updates to come.
D-

 
Boise 2 seems to be unable to dial out via ISDN, though it could be that the correct dial strings are not in the B2 directory. What is the correct ISDN dialing protocol for calls from B2?

 
I have turned off Duo Video and People+Content in the MCU Conference Template. If you want Duo Video & P+C to happen in an ad-hoc MCU conference you will need to re-enable it in the Conference Configuration.

 
I have run a few test calls and TMS seems to working fine for automatic call launches at this time. We do seem to be able to edit meetings now as well. Perhaps the upgrade solved some of the troubles we were having. The Monitoring section is improved in new version.
However, since we did have some call-launch problems yesterday, we should keep a close watch on automatic connects and disconnects.

 
A couple of devices have required restarts this week. Yesterday I had to hot boot the gatekeeper because it was not responding to the network. Today Don had to restart the MCU to restore ISDN connectivity.

 
Matt, we pulled the 7350 and found that it had a stretched loading belt. Did not have a new one stock, so we used rubber restorer to bring it back to life until new parts arrive. Working fine at this time, cleaned and lubricated while on the bench. New parts will be order today, replaced as soon as they arrive. On to the VHS deck!

 
Videotape machine trouble in Ag: SVHS 2 will not play back a locked picture. SVHS 1 returns an 'E-4' error when Play is pushed and an 'E-3' error--and a loud noise--when the tape is ejected. Possibly a broken belt. There is no VHS playback capability in Ag at this time.

 
WSU network monkeys seem to have fixed the WHETS H.323 connection issue. WHETS reports that they have straightened the IP path through their building, removing a few hops.

The WHETS connection may still have some issues, however. Occasionally, on a gatekeeper call, their gatekeeper will not be able to find the destination. This typically happens as the second GK call of the day e.g. AVS will go fine at 7:30 but PlSc will sometimes have a problem connecting at 9:00. Restarting our codec and/or their GK clears the problem. Today's calls went through fine. Perhaps the network changes have helped.

I have learned that WHETS changed over to an open-source software gatekeeper last summer. This could be part of the issue.

 
I have a workaround for the TMS-not-seeing-ISDN-capability-for-some-sites problem. This will allow me to schedule Automatic Call Launches for MCU calls for all sites but it may make TMS 'dumber', possibly allowing double booking.

I will start scheduling all MCU calls for Auto Call Launch but we will still need to watch these carefully. I think this will take some of the strain off busy operators at call initiation time.

 
H.323 to WHETS is still bad, the same as Wednesday. WHETS reports that they are looking into it, focusing on their gateway/gatekeeper. Jeff Snell is the investigating WSU network monkey.

WECN had trouble on Wednesday for the INRA class. Apparently Microsoft pushed some upgrades through to their servers which caused multiple reboots. All sites were dropped from their MCU a couple of times.

 
Automatic Call Launch is now partially implemented for MCU calls. TMS does not yet recognize Boise 1, Boise 3 or Moscow sites as having ISDN capability. This is not a problem for the Moscow sites as we normally connect them to the MCU via IP. At this time I am scheduling Automatic Call Launch only for MCU calls that do not involve B1 or B3.

 
Current connection to WSU WECN MCU shows none of the packet loss seen earlier in the connection to WSU WHETS MCU. It seems that the problem seen earlier today is located on the WSU network in the path to WHETS.

 
Chris, the WHETS mcu monkey, reports that WSU network monkeys are investigating errors on their network. My codec is reporting incoming packet loss at 0.5 to 5 percent with occasional spikes much higher. Video quality is K2.0.

 
About the WSU connection issues on Sept. 8: Turns out WSU was under worm attack that day. When I looked at AMP that day everything was flat lined, I assume also due to worms. I don't think they have quite eradicated all the problems over there yet as we still see a few problems in the video, e.g. on the connection going over to WHETS right now it is probably about a 1.8 on the K scale of annoyance (goes up to 5). This connection is normally sub 0.5. WHETS reports losing a switch yesterday so this may be a new issue on their campus, other than last week's attack.

 
Lost ISU-CDA tonight in EdSp 540 just before 7:00. No idea what the cause of the loss was, but the CDA operator said it was happening all day long. I did not call CDA right away, the operator finally called me (she mentioned something about having a hard time finding my number, I don't think they have the numbers in an easily accessible area).

I tried running the meeting through the MCU (no go) and we tried having CDA call Moscow (no go). Apparently ISU @ CDA is having some major issues.

Luckily, I have a tape of the class, so it can be made up by the students.

 
We are having some trouble getting through to WSU today. Rather, it seems that traffic over there is going okay but it is restricted coming this way. At about 9:50 today our connection to WHETS mcu went belly up, with packet loss reported at 70-80%. WHETS operator performed a trace route and saw a problem on WSU campus. A couple of minutes later I did a trace and there was no problem. WHETS operator then did another trace and the problem had cleared. I reconnected and the call was fine.

Connecting to WECN mcu about 10:20 showed 5-8% packet loss. After reboot and reconnect, packet loss is at 1-3%. My last trace shows some packet loss at the gigalink and severe loss at WSU side of link.

I can find no AMP data for WSU today.

 
I had trouble connecting to WHETS for PlSc 320 today. I found that I could not complete a test IP connection to TF so rebooted the Ag codec. After reboot I was able to connect to WHETS. Connection was 7 minutes late.

 
Grip router control software is operational in Ag control room. MS Office is no longer available on this machine. I am still working with Sierra Video and hope to get Office back on this machine in a way that it doesn't get messed with by Grip(e). In the mean time Office programs are available on the other computer (radish).

 
We can set MCU call duration in the Conference Configuration page. This can be changed on the fly, after the conference is already up. The call duration is in minutes so you will have to do a little arithmetic to get the call to drop at the proper time.
I apologize for not bringing this up sooner.

 
#^<&***!!! GRIP software is down in Ag control room. It is not finding the com port that lets it talk to the router although the computer thinks the com port is working fine. The only way to control the router is via the control panels.

 
I have updated user accounts and settings on the two Ag control room computers. There is now a generic 'operator' account and an account for Mike on both machines. Unfortunately, to use Grip on Carrot, these users still have to fight their way through a MS Office installer malfunction BUT at least Grip will now work after that is done (click Cancel about ten times). I have also added a Codec Control Links Page to the desktops of these accounts. All operators should have commonly used codec links in their Favorites lists. Let me know if these account settings don't work.

 
The WSU connection issue seems to have been resolved. Trace routes on Thursday indicated that the gigalink was down. ITS reported that the link had been turned off at the WSU side. Friday ITS got them to turn it back on but we were still seeing packet loss. I initiated further testing with WSU, connecting 5 codecs concurrently to UI, while ITS checked the UI network back to the gigalink. UI network to gigalink tested fine. Video testing showed the problem was specific to WHETS codecs in Murrow Hall, since connections to other buildings seemed to be fine. WSU sysad said ping data showed network problems and that they had made some changes that were likely causing the problem. I think these changes were part of the reason that they had turned off the gigalink previously. WSU sysad was able to locate the party that had made the network changes and get them fixed. Testing at 1700 on Friday showed a clean connection.

It has been brought up that this may have been cutting it a bit close to the start of the semester for network testing. That may be true. But if we had tested before the network had been changed, say two weeks ago, then we may have been thinking everything was fine until this morning when classes started. Probably early testing, combined with testing if the network changes, would be a good way to go. As it came out, I am happy that we tested when we did and were able to get resolution prior to classes starting.

 
TMS is still down, victim of a software upgrade. We have decided to give Todd the server monkey another week to work on it with T-berg before we give up and go back to the previous software version. So: All meetings, including MCU meetings, will have to be manually connected until further notice.

 
Some H.323 issues today:
1) In the meeting with Utah State and Moscow Ag 1 from 0830 to 1000 there were repeated connection drops, even when we forced the meeting down to 192 kbit/S.

2) While testing to WSU from 1200 to 1230 the Moscow Ag 3 codec indicated significant packet loss of 1-5% on receive video, resulting in considerable freezing, tiling, etc on Moscow's incoming video. WSU reported that their incoming video was fine with no packet loss. I am not sure if the Moscow Ag 3 codec is correctly listed for priority video traffic in the packet shaper as I think the IP address may have changed on that codec since I last gave the network monkeys a codec list.

3) I ran a test call to Idaho Falls 1 over IP. The connection was unable to sustain 384 kbit/s and was quite blocky. This is typical of IP connections to IF, including the IP-only rooms IF4 and IF5.

 
Endpoint software upgrades done today: Twin Falls A and Twin Falls B.

 
Endpoint software upgrades done today: Moscow AEE, Moscow Ag 2 (Ag62), Moscow FCS (Niccols).
A note on software upgrades: The upgrade disables the Web Snapshot feature. This feature can only be enabled at the codec (under >Menu>Utilities). Please check to see that Web Snapshots is turned on when you are operating a codec via the remote.

 
Endpoint software upgrades done today: Moscow Ag 1 (Ag104), Moscow Ag 3 (Ag 6), Moscow CNR (CNR14), Moscow Ed 1 (Ed 103), Moscow Ed 2 (Ed301), Don's.

 
We were unable to connect point-to-point ISDN from Ed 301 to Boise 1. The call would only negotiate at 64 kbit/s on H.221 protocol. I ran the connection through the MCU going IP to Ed and was able to get a normal ISDN connection to Boise.

 
I have upgraded the MCU software. Here is what T-berg says this will do for us:
4. New Features in D3.3
4.1 Web Call List Timeout
It is now possible to enable/disable disconnected participant timeouts from the Web participant list during an ongoing conference. To disable the participant timeout simply uncheck “Timeout Participants from Call List” when creating the conference. If disabled, disconnected participants will remain in the participant list for the duration of the conference. This feature is enabled by default and disconnected participants will be removed from the list after 2 minutes.
4.2 Video Mute Participant
It is now possible to mute incoming video from a participant. When muted the participant will still receive video but will not be visible to other participants in the conference. To use this feature simply press the new action button located in the participant list on the Web page to mute video and the action button to un-mute video.
5. Changes and Improvements in D3.3 from D3.2
· Increased size of Web participant list
· Improved video stability
· Improved audio handling during ISDN disconnection
· Improved handling of long site names
· Improved stability under heavy load
· Improved video robustness to allow for QCIF in CP layouts
· Improved handling of Duo Video

 
The initial H.323 connections in today's PSES meeting in the MCU showed restricted bandwidth. There was no difference between IP endpoints on or off campus: Moscow, Twin Falls and Idaho Falls initially showed connection speeds at 364 kbit/s, fluctuating and dipping down to about 264 kbit/s before eventually rising to 384 and stabilizing there. Call initiation was at 0720 and fluctuating call rates occured from then until about 0728. Idaho Falls 4, however, never came up to speed, eventually settling at 192 kbit/s. Over the duration of the call (from 0720 to 1100) IF4 packet loss as reported by the MCU was 0.5 to 0.8% for all bitstreams except Video Out which was at 3%.

 
There were no dropped mcu connections yesterday after 8 hours of testing. Today's 3.5 hour meeting had no troubles. It seems at this point that fixing the flapping port has solved the dropping problem.

 
T-berg says that the 'temporary network failure' message is displayed after a 'sudden drop in packets' and that the malfunctioning port noted below could be causing an overload at the MCU port, causing the drop in packets and the resulting dropped endpoints.
ITS has fixed the flapping port and I have not seen any spontaneous drops since then. I will continue testing today.

 
Unable to connect at all dialing either direction ISDN Moscow Ed 2 (Ed 301) to MCU or MEd2 to Moscow endpoints.

 
ISDN to Boise 2 is not fully functional yet. Dialing to B2 from the MCU would only connect at 64 kbit/s. I was unable to dial at all from Boise to the MCU.

 
I have contacted ITS about the MCU drops. They could see nothing wrong with the MCU's port but did find a nearby port that was 'flapping'. That is, it was going up and down of its own accord. ITS thinks this could have an impact on the MCU. I have had a single-site conference up for 8 hours now (since the flapper was fixed) and it has not dropped. I am going to leave this conference going. I have an e-mail in to T-berg to ask what exactly the error message is indicating.

 
The MCU is spontaneously disconnecting endpoints. We saw this a few times last week and it happened this morning. I saw a 'Temporary Network Failure' message (for about 1 second) then all--IP and ISDN--connections were dropped. I will call ITS to see if they have any insight into network issues.

 
I have heard a couple of videoconference user comments about the audio lag between participants' interactions when the MCU is in Continuous Presence mode. It does seem to be a bit of a problem for some groups: the lag makes it hard for some people to interact without stepping on others' words. I think it is the increased processing the MCU has to do in CP mode for the multiple on-screen images that introduces the lag. Keep an eye/ear out for this issue--maybe we should try going to Voice Switched if a lag problem is noticed by participants or an operator in a meeting.

 
New Boise dial in numbers. We have configured the B2 codec for ISDN calls, and the new numbers are as follows. Local = 208-885-0498, Long distance = 700-733-7960.

 
In response to the Idaho Falls tiling. I worked with Madge this morning and we have determined that the IMP board may have been affected by the lightening strike at the same the 40 was hit two weeks ago. However, since Dave had thought it was just a power supply, Madge had sent him just that. The IMP board carries the voltage that passes sync through the entire model 40. A new board is being sent to Dave, should be installed by Monday. I suggest that until that time, the IP path to Idaho Falls is used as much as possible to prevent,,, or reduce the tiling. I would only expect tming to the entire 40 has been effected, but IP seems to be hlding up a bit better.

 
Very bad tiling and freezing from Idaho Falls 1 today on ISDN. Other H.320 sites in the meeting, on and off net, looked fine so it was probably not a network problem. On the subject of IF1, I saw that it was only partially added to TMS and listed as [no name]. I re-added it into TMS and it looks fine.
 
IF1 and TF1 audio seemed to be echoing somewhat today. I an not sure the echo cancellation parameters we have set on the TFA codec are working out.

Speed and duplex settings on Coeur d'Alene 1 have been matched to 10/Full on both the codec and the network port. Let's see if that clears any of the IP connection speed and packet loss issues such as what we saw yesterday.

 
We've changed the mics in CNR 14 to latch, similar to what I remember in ED103. "Wax on,,, Wax off".
We also found that the far left/rear mic was not operational. Checked and found phoenix connectors had been unplugged from the mixer. Seems that all is currently happy in CNR world. Don

 
I initiated IP certification of our MCU with Sprint but their IP connections require endpoint registration with their gatekeeper. As a matter of policy I do not like to unregister (de-register?) the MCU from our gatekeeper. I had just started working with the Sprint tech on neighboring our gatekeeper with theirs when he accidentally disconnected the phone call. As this was for the now non-IP Scientech meeting I did not pursue it further by calling them back. We are still ISDN certified from the MCU.

 
'Videoconference' is better. By the way, it is one word, like 'videotape'.

 
Well I guess I'd better post this one since Anita has already replied to it.:-)
I wonder if we could eliminate the phrase 'compressed video' from our vocabulary and replace it with 'videoconference'. Users do not care that the video is compressed, just as they don't care that the video on a DVD is compressed. They just want to meet at a distance. 'Compressed video' is just too clunky and does not further users comprehension or appreciation of the process.

 
Heads up! ISDN calls into Boise 1 from both JEB codecs are not being routed properly by the model 40 in Boise. I am currently working with the TAC team to solve this problem. Currently unable to access the Boise model 40, Keith #1 is scheduled to reboot the 40 tonight. I plan to continue working with Madge on this first thing tomorrow morning. Once we gain access, we will also continue our work on the ISDN capability in B2.

 
Just for reference: I was requested to make some cabling changes to the new AGN unit. According the InSors technician, the inputs and outputs (#'s 10 and 12)used for the telephone interface had been incorrectly wired at the factory. All other inputs and outputs were correct. Made the requested changes as needed.

 
While monitoring the JEB111/IF5 (Battelle) conference I noticed that the connect rate to IF dropped to 192K during the conference. I can only assume that the reason for this was due to limited bandwidth on the IF/Moscow data circuit.

 
I have installed Novell client on the CNR 14 classroom computer so users can access shared drives.

 
Received a call from JEB111 regarding the CID meeting. The report was no video from Idaho Falls, video fine at the start of the meeting. Checked via the web interface and found that the codec had been switched to DOC Cam, I switched it back to Main Cam and everything returned to normal. Someone in the room must have accidentally changed inputs.

 
The mouse A/B switch in Ag is working again. I guess it just needed the shaking I gave it when I moved the carrot computer.

 
I have added Idaho Falls 5 and Boise 4 (A1) to TMS.

 
I have upgraded the MCU to the latest software version (D3.1). The interface (GUI) looks identical to the previous version so there should be no new things to learn. I have successfully tested connecting both directions via IP (Ag 2), ISDN on-net (Ag 1), and ISDN PRI (Parma). Here is what Tandberg claims this new software version will do for us:

4.1 Continuous Presence Auto Switching
This feature is used when there are more than 6 video participants in a CP 5+1 conference, or more than 8 in a CP 7+1 conference. The MCU will automatically rotate the non-speaking sites into the smaller windows of the continuous presence layout.
This feature has a user set value of 0-60 seconds in which the MCU will wait before switching a site into the continuous presence image. ‘0’ seconds disables this feature, and is the default setting.

4.2 2nd Channel Dial In Number for 2x64k
For legacy systems, D3.1 has added a second dial in number for 2x64k calls. This is used for dial in only, and must be a different number than any of the three conference numbers.

4.3 Video Improvements
- Quicker, improved video switching when changing between H.263 and H.264.
- Sending PC images to Viewstation FX does not introduce horizontal lines at bottom of screen.
- Improvements to eliminate possible ‘green video’ to and from sites.
- Reduced ‘blocking’ when switching between sites in large conferences.

4.4 Miscellaneous Features/Improvements
- Improved stability during high capacity conferences.
- Added SNMP trap information to increase accuracy of CDR calculations. New SNMP traps are ‘CallSysUpTime’ and ‘LogCallSysUpTime’.
- Improved H.323 clearout, where disconnecting H.323 sites would remain in a ‘disconnecting’ state.
- Improved H.243 cascading with other vendors.
- Improved robustness for handling complex networks. Including many connections with different amounts of packet loss and jitter

 
For billing/routing I ran a test call to Aberdeen today from 3:44 to 3:47 Pacific. 700-730-0959 dialing to 700-731-6655. I'll put it in my dial log too.

The video looked good and the connection went throught fine. It sure helps to have a PRI clocking source.
-----Original Message-----
From: Don Saraceno
Just to note a couple of AT&T issues.
First, due to the continuing problems with LCSC, as well as some of the green glitches we've been experiencing locally, I have opened a ticket for the stress testing of the two PRI's here on campus. The testing will take place at midnight tonight, on both circuits. The ticket # is: 451704088. Matt had reported tiling that appeared to be in a specific portion of the raster. I did take a look at the conference, and though the tiles were noticeably changing, they seemed to be isolated to one portion of the raster. Interesting!
Secondly, I have received confirmation from Grant Ross that he "THINKS" that they (AT&T) have located the billing/routing problems with the Aberdeen circuit. Grant suggests that we make a test call to verify. Matt, please schedule a test time, log it as a test, and please be specific about the dialing time.

 
Dave A. has changed the Idaho Falls 4 codec password to reflect its new location. He has used the same password naming convention.

I am still trying to get Idaho Falls 5 fully added into TMS. Working with Jordan on this. We had Chris check the network port duplex/speed setting on the codec and found it to be wrong. He changed it--no help for this problem but may improve video quality.

 
I talked to the Aberdeen participant in Wednesday's call that seemed to be experiencing PRI trouble. He reported that on his end he was seeing red flashes that were frequent but not constant. He described them as fairly annoying but not terrible. Also, he reported that the main (switched) video window would occasionally switch to a non-speaking site.

 
We seem to still be experiencing PRI trouble. I can not tell if it is at the PRI itself or at the Madge or the way the MCU is handling PRI calls.

In yesterday's MCU-hosted CALS Leadership meeting Aberdeen and Parma, the two sites coming in via PRI, would frequently do the 'green screen' flash. I know they did this exactly simultaneously because the conference was in continuous presence mode and all seven sites were on the screen at the same time.

I had rebooted the MCU the day before in hopes of clearing the dial-in problem experienced by Aberdeen on Thursday, noted below. This has cleared the PRI dial-in problem in the past and seems to have worked yesterday since Aberdeen dialed in fine.

I have a call in to the Aberdeen participant to get his assessment of incoming video and audio. I am curious if they are seeing the same thing on their end.

 
Whooee, that was marginal. In the just-completed PlSc 501 MCU class:

--Aberdeen unable to dial in on PRI. I had to dial to them from the MCU.

--Twin Falls audio was distant-sounding coming from the A21 podium position. It sounded as if the podium microphone was off. TF presenter reported that it was very difficult to hear incoming audio (volume too low?)

--There was some video freezing on our incoming video (TF-mcu-Ag) from TF. It was not frequent but it was for fairly long duration, 10-15 seconds about three times in the first 20 minutes of the class.

--Aberdeen had fairly frequent video and audio glitching, with the video flashing green/black and audio cutting out. Their audio mix was very poor as well, with room mics and podium mic fighting eachother for audio.

 
In today's Registrar's Meeting CNR apparently spontaneously dropped its H.323 connection to the MCU at 0854. Cause unknown.

 
Today Twin Falls connected point-to-point over IP at 384 kbit/s to Coeur d'Alene 1. All reports from Jodie and connection stats from the web indicated a good connection. I don't know if we have been running many TF/CdA connections (this is the first I've noticed) but I thought we should note that this path seems to work well.

 
I spoke with Megan at Twin Falls today. Here is a contact name for the evening classes at Twin.
Chris, 308-5191 (Jodies work cel #)

Megan set the audio to the standard levels, the levels were too low, Chris had to turn them up.
With the new mic we may need to have a new set of "standards".

 
I bet everyone already knows this, but the video switcher in Ag 104 is dying (I swear I heard a death rattle this evening). The switcher bar is buggy, and the auto transition key is wierding out on me right now.

 
The box that switches monitor/keyboard/mouse between the two computers in the Ag control room seems to be broken in the mouse section. For now there are two mice for the two computers--the monitor and keyboard are still switched in the old way.

 
There was an apparent spontaneous reboot of the MCU today at approximately 1350. I do not know if there was a power interruption or something else.

 
I ran a couple of test calls with the CAMBR Post Falls site. The first call I ran JEB 28 - MCU - PF at 768 kbps. There was no trouble staying connected. Packet loss was generally around .5%:

I also tested point-to point Ag 3 - PF. In that test the codec was indicating 1-2% packet loss. I was seeing considerable freezing and tiling on the local video from PF. PF user reported that incoming video was perfect, except for the smudges on the our camera lens.

I ran several trace routes to Post Falls during the test. Some of them showed not-too-bad latency throughout the trace while others showed extreme latency at the CAMBR gateway. I don't know how valid a trace is when it traverses a NAT as it does here. I am not even really sure of trace route validity for analyzing H.323 issues, but it is about the only tool I have.

Time of day could influence this connection: one would expect worse performance later in the day when there is more traffic on the net.

 
We heard some retransmit echo from Twin Falls 1 today in PlSc 501. It was not as bad as it was before but it was worse than when we tested on Tuesday.

Also, I think I am hearing some retransmit from B1, though Ryan says the incoming audio volume is not high.

 
H.323 IP connection to B2 seems to be poor. In today's LCSC-bridged Park and Rec meeting the LCSC tech reported that they were only managing 192 kbps on the B2 connection. I tried to bridge B2-Ag1-LCSC but it did not go through. I then bridged it using the UI MCU to connect B2 and Ag1 to the LCSC MCU. While the B2 connection was able to maintain a 384 kbps pipe, the video was poor quality, barely useable. The MCU reports 1478 (sic) ms jitter and about 1.2% packet loss on the incoming video. Outgoing video shows jitter around 30 ms and 0% packet loss. Luckily the audio was not too bad: though there was significant audio artifacting, it remained intelligible.

 
Had a problem with TF A this afternoon. I connected with that IP at noon and had no problems, but a later connection (to a different room, but same IP) lead to some sound problems. I had the audio cranked up to a high level, but the Twin Falls sight said they could barely hear us. I tried a few changes, but nothing seemed to work. I am not sure if they talked to the local tech person or not (I forgot to check), but I tried to call a bunch of the numbers we have on the phone list and I could not get a hold of anyone.

 
Parma was able to dial in this morning following mcu reboot.

 
More apparent PRI trouble: Casey reported he was unable to dial in on ISDN for ME 412 today. He did a test call to his CdA site and it went through okay. I tried to call to the mcu from Parma and the call never even started to come in at the mcu. May be related to the CdA2 green screen thing Mike reported yesterday. I will reboot the mcu at the next opportunity and test again.

 
Had a strange problem in Ag 62 this morning. Throughout the meeting, the audio kept making a strange popping sound. I tried muting all of the sites, but the sound persisted. I did not notice any link between the popping and any other audio phenomenon (ie, did not pop when specific site spoke, when screen changed, etc.). I also could not identify any sound in my room which may be causing a feedback which was popping. The popping was not particularly loud or too distracting, but it may be something to keep an eye on.

CDA was also doing the green screen thing again.

 
New Parma IP location (24.116.39.206) seems to be unreachable via telnet or SNMP and therefore not reachable by TMS.

 
Confirmed PRI dial in problem to MCU in test with Parma. Parma would only connect on one channel when dialing this direction but could connect on all six when dialing to Ag. MCU dialing to Parma connected on all six channels.

After booting the MCU Parma and Poky were able to dial in.

While a simple restart of the MCU seems to have solved the trouble I am still a little worried as we have had this PRI trouble for a little while and we have done reboots in that time and the trouble has either not cleared up or has recurred. Since there does not seem to be any trouble connecting PRI sites to sites other than the MCU e.g. Parma to Ag went through fine, the problem may be between the Model 60 and the MCU or the MCU itself.

 
Tested the ISDN connection from Poky to the MCU this morning. Poky could only connect with two channels when they dialed in but we got all six channels when we dialed to them.

 
For today's PlSc 501 in the MCU Aberdeen connected at only 64 kbps. They did not dial in until 11:29 so I did not have a chance to try to reconnect them before class started.

 
Pocatello could not dial in ISDN to ME 412 (MCU) today. Only one channel would connect and the rest would not bond. Had to bring them in IP.

 
I downloaded and installed GripLite on the Ed103 computer. It seems to be working okay. I did not use the former install much, being more of a button-pushing type operator, so I am not sure if it is the same as it was before. A desktop icon should show up for all logins, otherwise you should be able to get to it via the start menu.

I like having this machine on XP! Be sure to update your Favorites and links lists. Let me know if you want a list of codecs to import.

 
Ed103 has its computer back (yeah!), but we will need to have Griplite re-installed. I am sending this into cyberspace in the hope that someone out there knows how to do it, if not, then let me know and I will figure it out (assuming we have the software somewhere)..

 
Today's ME 412 (EO, IF2, ISU): Idaho Falls only connected at 320 kbps (ISDN on-net). I tried to disconnect IF site to do a reconnect but the call would not clear even with a Disconnect All command. I rebooted the MCU and was able to rebuild the class and it started on time.

Also about ME 412: The Pocatello connection will be ISDN until we can improve the reliability of the IP connection, per Casey . Casey will be dialing in. I will make the necessary changes in the MCU assignment.

 
Good Morning!! Child Labor Law Meeting, 9:00 am - 9:45 am 3/11/04. Here is a log of issues I saw. Event started, off campus sites were introducing themselves, Aberdeen and Parma flashed a green screen. When Aberdeen was speaking, Parma disconnected, I brought them back in...
9:15 Parma flashed green screen, Moscow speaking, all mic were muted except Idaho Falls.
9:35 Parma flashed green screen, Moscow speaking, all mics were muted. In between 9:35 and 9:40, Parma asked to 2 questions the audio was consistantly broken. 9:40, green screen flash in Aberdeen when Parma speaking. 9:43, Parma asked another question, audio was normal, no green screen flash.. Conference ended! During this conference I did not switch from Enhanced CP. You're all are doing a great job! I appreciate YOU!! Paula

 
Mike--That seems similar to the problem I noted on March 1st. I wonder if there is something wrong with the PRIs or how we have them configured to work with the MCU, though Don says that CdA2 is 'on net' and should not be affected by PRI trouble.

 
Had a problem with CDA2 in the CALS Leadership meeting this morning. When they first connected, all we got from them was a green screen. I disconnected and reconnected, and the picture cleared up.

As the meeting continued this morning, I noticed that Aberdeen and Parma also had brief periods (fractions of a second) where the screen flashed to green.

 
For a while today it seemed that changes made to UI's and ISU's packet shapers had yielded some improvement to the latency graph but now it is not so clear. There was the usual latency spike yesterday, though it was later than usual and not as severe as most days.

The mcu is back registered with the gatekeeper.

 
Mark says that ITS has made some changes to our packet shaper. Also said that the gigapop reports that it has fixed the instability issues it was experiencing.

 
Today's LOC meeting with mcu connection to Pocatello had to go ISDN because the IP connection would not go through. Casey says that the trouble was to do with their packet shaper and that he did not believe it was related to the other ISU IP troubles we are having.

 
FYI--Dan and I have still not recieved access to TMS. I don't think either of us really cares, but it could come in handy and save somebody a little hassle if we need to change conference times.

 
It looks to me like there may be an improvement in packet loss with the MCU unregistered. It looks like loss on Wednesday, while the MCU was registered, was about 3%. Today, unregistered, it is just under 1%. Of course I can't tell where any of them are being dropped, or whether it is related to the daily ISU 'latency storm' blowing out on the net. Also, I think the improvement may be natural variation--some days it will be better or worse than others.

The meeting going on now with CNR-ISU (not through the MCU) is experiencing a high degree of packet loss and extremely poor video. The call rate has been stepped-down to 352 kbps by the codecs.

 
This morning's SmokePing graph showed less than 0.2% packet loss and about 60 ms rtt from ISU to UI but the 30 hour graph shows a 'latency storm' running from about 9 a.m. to 9 p.m., peaking about when we were testing yesterday. Casey reports that this is a typical daily occurrence, though yesterday's was the worst since last Thursday, the first day that was graphed, but still not nearly so bad. As I write, the graph does seem to be ramping up again.

 
Just completed a short test call with Casey with the MCU unregistered from the gatekeeper. The packet loss did seem to be reduced compared to some of the tests we have done recently but the video was not improved. We plan on testing later during the daily 'latency storm'.

 
I unregistered the MCU from the gatekeeper this morning and had Brian run another MTR traceroute. The new trace showed 0% packet loss on the last two hops. These two had shown as much as 20% loss over the last few days.

I will re-register the MCU at 10:00 and will unregister again at 11:30. I want to see if there are any corresponding data points on the SmokePing graph.

 
Did a test call to Bozeman in an effort to isolate the packet loss to ISU while Mark sniffed packets (that's the kind of guy he is). During that call there was considerable packet loss and jitter, so much that the call rate eventually got down to 128 kbps. The connection eventually dropped but that could have been Montana hanging up. Mark saw increasing delay on the traceroutes behind the gigapop. ISU SmokePing showed 4.4% packet loss and over 100 ms rtt to the UI MCU during the test.

Currently the ISU SmokePing graph shows 8.73% packet loss and over 100 ms rtt going from Poky to the UI MCU. For comparison it shows about a 60 ms rtt and 0.14% packet loss to the WSU INRA MCU.

 
Had another problem with a Dell computer tonight. Tried to connect a Dell laptop to the Tandberg in Ed 301, but once it was connected, the Tandberg itself would not recieve the signal. Everything seemed to be connected correctly, and I checked all the wires twice, but nothing would bring up the screen (yes, I used the function keys to switch the output). The screen would flash on the laptop when I tried to switch outputs, but it never made it over to the Tandberg. I remember Daryl and I having a similar problem with a Dell in Ag 62.

 
More on ISU-Pocatello IP connection: Following our test on Friday, Casey talked to Randy and was told to procede with testing to try and identify the problem. Casey asked Brian to test further. Brian ran MTR, which combines traceroute and ping functions from a Linux box. According to the MTR report Brian sent me there was no packet loss until the last two hops to the UI MCU, which are on the UI campus. I passed that info on to Mark. He found that the MCU was not in the border traffic shaping policy as high priority video. After that was changed, Brian ran MTR again and there was no real improvement in the packet loss at the MCU or the hop before it.

While this does seem to indicate a problem with the UI network, I am not sure if ping and traceroute data is comparable to video traffic. I think video packets may behave differently than ping/traceroute packets. I would like to do our own tests to see what this might mean.

ISU's SmokePing report from their MCU to ours is currently showing a median ping RTT average of 69.5 ms and average packet loss of 0.14%, considerably less packet loss than the 5% to 8% reported by MTR.

 
Our control room computers are being infested with spyware. These nasty programs are loaded when you install certain programs. The CNR computer was slammed pretty hard, possibly when a free program called 'Clock Sync' was loaded. The Ed computer was possibly infected from a program called WinAmp. Not only are these spys and advertising popup programs very annoying they also adversely impact computer performance, making browsers, etc. behave in unexpected ways and stealing system memory. Spyware is also hard to get rid of once it is installed--it took 2 hours to get CNR relatively clean. Please do not install any programs on our computers.

 
In today's Ag Processes meeting the three sites that were coming in on the PRI would all occasionally simultaneously glitch with green or black video. Parma, Aberdeen and Sandpoint every few minutes would 'green glitch' then come back. Audio seems to be affected as well. At one point Parma audio did not come back and I did a reconnect to clear that problem.

 
The ISU IP link seems to be improved. This is from Brian:
Well somebody did something about 18:00 last night it went from seconds with a greater then 50% packet loss to an average of 71ms and change with 0% loss, so I would say the next step would be to give it a shot this morning.
I agree with Casey's assessment of our test this morning:
Matt and I just tested the link. It is much improved over yesterday afternoon, but still not what I would expect from a true 384 connection. The video was not as sharp as I would expect, and there was some pixelization and freezing, but nothing compared to yesterday. It will be interesting to see what this afternoon will bring.
We'll see how it goes this afternoon.

 
It seems that the IP connection from Pocatello for ME 412 has been bad all semester from a quality standpoint as well as the connection trouble noted below. Usually the instructor is in Idaho Falls so the problem was not so apparent until he switched to Poky. I connected to the class yesterday and it was indeed very bad: much pixelization, blockiness and audio defects. Their incoming is apparently fine. This is what Brian at ISU found:
Just installed SmokePing 1.26 and actually got the graph for UI MCU to start working and so far things do not look good. I seeing 5 second, yes you read that correctly not millisecond, 5 second, average round trip time with an average packet loss of 57%. I want to let this run for awhile and gather some more stats, but with these numbers I'm surprised anything at all is getting across.
I'm not sure what this means but it doesn't sound good. I will pass this on to the the network monkeys on this end.

 
About the Idaho Falls audio problem 2: I have also learned that EO has no way to feed that codec any sort of mix-minus audio from that studio. In order to get the class on tape they can only record Program video and audio. They also feed Program to the codec. This means that when they are 'tag teaching' a class, and the instructor is sometimes in IF, they will be feeding incoming audio back to the codec. It is surprising that it works at all.

 
ME 412 connections to Pocatello: We are still having trouble with this connection. About 2/3 of the time the connection will go bad on the Poky end. This happens after the MCU successfully calls them and Idaho Falls. But the Engr 2 codec takes longer to negotiate. When it does finally complete the 'handshake' process Poky gets a 'faulty connection' error and loses video. At this point the MCU is still happy, passing video from Poky and reporting a healthy connection. A Pocatello re-connect will clear the problem. Casey thinks the trouble is with the Poky MCU but it could also be made worse by the 'CLI factor'.

 
About the Idaho Falls audio problem: I found that EO had the audio hitting their codec pretty hard and they lowered it a bit. This reduced the distortion (over-modulated audio) I was hearing. I do not know if this solved the problem but we were unable to duplicate the bad audio in a test call after the change.
Dave has a tape of the audio problem and it sounds digital to me, like it was going on at the audio codec level. Perhaps it just couldn't handle the distortion. So once again we are in 'optimistic wariness' mode for a videoconference site (IF2).

 
Ryan called and was not connected to FCS. I called lynette and Donovan forgot about the meeting I reconnected the meeting .meeting time 9:30 was still on time

 
Ag Ed 306, at 5 pm tonight... class break, class started again Twin Falls students were still seeing what was on the MCU at the beginning of break. We could hear and see each other. I disconnected and reconnected, all was fine. Last week,Twin Falls was disconnected during this time frame. HMMMMM... What's happening, where, around 5:00 pm pst

FSC411, Tuesdays, 3:30 - 5:30 pm, When I switch from Enhanced CP to Voice Switched. CdA 1 gets a green screen for a few seconds before switching. This has been consistant for the 6 classes we've had..

MCU software glitches??

You folks out in CV Land pat yourselves on the back. "You're doing a great job!

 
FCS dropped at 1:30 for no aparent reason they said they did not hit the disconnect button I reconnected them (dp)

 
FCS was supposed to connect at 9:00am to Cda2 auto fire, niccoles was not ready. I called lynett and she said they were on a conference call and would be ready in about 15 min but go ahead and fire the EQ. I fired it at 9:24 and it was ready. We still need them to be ready at the time TMS fires.

 
Hi Matt, Dave Anderson called you at 1:13 pm. He wanted to report that CE482, IF2, M2, point to point that had an audio issue similar to the one he'd reported to you last week that went through the MCU. Bob Stiger is presenting from IF and it sounds like a clicking noise when Bob begins to speak. Sound similar to morse code. Please call Dave. Paula

 
INRA connection to WSU today went fine.

 
Monday, Tuesday and Wednesday Evening from 4 to 6, I've had classes that Twin Falls Classroom is present.
The feed back is disruptive to the presentor. I've had them muted throught the MCU. This is not a solution because when a Twin Falls student wants to speak he/she should beable to without my interference.

Ag Ed 450, Monday 4-6pm, When a student want to say something and I have them muted though the MCU there is a problem! The instructor asked where a student went they say he was adjusting the volume, in front. Maybe they wanted to speak and couldn't because I had the MCU muted for them....
FCS 411, Tuesday, 3:30 - 5:30pm, The instructor ask both the Moscow and Twin Falls site to mute their mics because the she could not speak and think with her voice coming back to her. I had Moscow and Twin muted as per instructors request. The Cda site used the Elmo and showed Twin how to use the remote control to mute their mics. When I switched from Enhanced CP to voiced switched, I got the green screen.
Ag Ed 306, Wednesday, I connected Twin and Ag 104 through the MCU so I could mute Twin to avoid the feedback. Around 5pm Twin dropped from the conference. I reconnected.

It seems like in the year 2004 there can be a economical, practical solution to this Twin Fall Audio issue.
Paula

 
Mark reports that Duane found a problem with a switch at WSU that was causing errors and corrected it. I did a test call to WHETS and it looked fine. I have not tested the INRA connection yet but I expect it will also be clean when I do. Whew.

 
Today's Ag to WSU INRA class experienced the same trouble we had with earlier WHETS classes noted below. I have notified Mark and he is working with Duane at WSU to identify and resolve the problem.

 
CAMBR site contacts Bill and Eric have been notified by e-mail, by me on 2/6 and by Anita on 2/5, that they will need to dial in, per Don. But they have not done so yet. As happened on Monday, today Post Falls did not dial in for ECE 542. Monday I remotely connected them but today I found that their system was not turned on. Steve said that he had a tape and that he surmised that he was supposed to play it today.

Connection problems (aside from coordination problems above) persist with this site, with what sounds like fairly severe packet loss yielding unacceptable audio: Steve was going to try a speakerphone connection for audio today in an effort to improve audio. I think packets are being lost traversing the Post Falls NAT. Evidence of this is that the MCU and TMS see different IP addresses from the Post Falls codec: TMS reports the actual IP and the MCU reports the NAT address. This makes me think that some packets may be taking different routes to the codec.

 
I re-saved all the Ag router salvos and they seem to working again.

 
All the salvos set up on the new router in Ag seem to be non-functional at this time. I am experimenting to see if they can be brought back to life.

 
Connection issues with WSU have re-emerged. WSU is seeing massive pixelization in the video from us, along with audio trouble. Our incoming from them is clean as a whistle. We had the same trouble on Thursday but thought it was cleared by a reboot of the WHETS gatekeeper. Their network people are investigating. I have a call in to Mark Q to check from this end.

 
Not sure what was going on with the audio coming from Idaho Falls yesterday. IF and JEB were both connected via standard ISDN on net, ISU was via IP. IF and EO both phoned me to report trouble but of course I could not tell what they were hearing. The way Steve described it, it kind of sounded like there might have been some problem with the IF audio board--somehow the incoming audio may have been getting into the outgoing audio and/or the instructor mic was being over-driven and/or there was a stray open mic. I operated a class with Ag and IF2 later in the day and it sounded fine then so maybe they found the problem. I have a call in to DaveA but have not heard back yet. I hope the trouble was in IF, otherwise it may be another issue with the mcu.

 
The audio in TF Classroom. is really bothersome. Same issue, the feedback seems to stay consistant. Last night Ag Ed 306, Bob Haggerty complained about it. At break I disconnected and called in through the MCU so I could mute TF.

Monday's AgEd 450 connection, the feedback was really bugging me so I had the codec volume low. Lori Moore said she did not hear anything in the classroom. I could hear it in the control room.

Wednedsay, Ag Ed 306 connection, I could not hear the feedback except through the headphones. However, Bob could hear it in the classroom.

 
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.