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