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
- matt.kitterman@gmail.com,
7:31 AM
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.
- matt.kitterman@gmail.com,
3:05 PM
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.
- matt.kitterman@gmail.com,
8:21 AM
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.
- matt.kitterman@gmail.com,
9:11 AM
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.
- matt.kitterman@gmail.com,
7:22 AM
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.
- matt.kitterman@gmail.com,
2:42 PM
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.
- matt.kitterman@gmail.com,
2:39 PM