Page 1 of 2

Broadcasting stake conference - question 1

Posted: Wed Jul 09, 2008 6:26 am
by aclawson
We are interested in setting up the simulcast of stake conference to other buildings in the stake. As soon as the current project (getting the clerk machines hooked up to the FHC connections) is completed we'll be taking on the big issue.

First and most important question: how much bandwidth is needed at each end. For starters let's assume one building broadcasting to one building. Add in enough overhead to allow three clerk machines to be doing simultaneous transmits.

Will 1Mb SDSL do the trick or should it be 1.5? For the receiving building will a 1.5/734 ADSL connection do the trick?

Posted: Wed Jul 09, 2008 8:01 am
by russellhltn
I'm puzzled by your overhead requirements. Why would any clerk machines be doing transmits during stake conference?

bandwidth overhead

Posted: Wed Jul 09, 2008 3:01 pm
by aclawson
Convenience of a commonly understood resource use more than anything - just in CASE there is network use (setting MLS to download a large patch, the future probability that these machines will grab windows updates or virus definition updates) I want to make sure there is enough padding to ensure smooth transmission. Or perhaps they set something running just before conference... not really worried about what they're doing, I just want to make sure the video runs smoothly.

Take computers offline

Posted: Wed Jul 09, 2008 4:21 pm
by danpass
aclawson wrote:Convenience of a commonly understood resource use more than anything - just in CASE there is network use (setting MLS to download a large patch, the future probability that these machines will grab windows updates or virus definition updates) I want to make sure there is enough padding to ensure smooth transmission. Or perhaps they set something running just before conference... not really worried about what they're doing, I just want to make sure the video runs smoothly.
When we do our building to building simulcasts, I physically take the Cisco firewall offline, which eliminates any possibility of bandwidth contention from computers in the building, since all connections that could have a computer connected to them, hang off of the firewall. The DSL modem has an integrated router, so I'm able to connect both Slingboxes to it. So far, we haven't actually tried dual feeds using both Slingboxes concurrently. I'll be testing that soon because the Stake Pres. wants to transmit to two buildings in September. Our DSL is 1.5/734 and the 734 upstream bandwidth has given us a high quality feed. The Slingbox adjusts video quality based on available bandwidth. I'll report back here on how the dual feed test goes.

Posted: Wed Jul 09, 2008 7:59 pm
by rmrichesjr
danpass wrote:When we do our building to building simulcasts, I physically take the Cisco firewall offline, which eliminates any possibility of bandwidth contention from computers in the building, since all connections that could have a computer connected to them, hang off of the firewall. The DSL modem has an integrated router, so I'm able to connect both Slingboxes to it. So far, we haven't actually tried dual feeds using both Slingboxes concurrently. I'll be testing that soon because the Stake Pres. wants to transmit to two buildings in September. Our DSL is 1.5/734 and the 734 upstream bandwidth has given us a high quality feed. The Slingbox adjusts video quality based on available bandwidth. I'll report back here on how the dual feed test goes.
If you have difficulties with sending from one building to two others, it might be worth trying sending from building A to building B, then relaying from building B to building C. There may be situations in which relaying might work better than the 1->2 configuration.

Posted: Sat Jul 12, 2008 9:27 pm
by DenleyAn
danpass wrote:When we do our building to building simulcasts, I physically take the Cisco firewall offline...
Isn't this a fundamental violation of the Church's network security policies?

Posted: Sat Jul 12, 2008 10:01 pm
by Mikerowaved
denleyan wrote:Isn't this a fundamental violation of the Church's network security policies?
I think he means he shuts down all internet bound traffic, not disable the firewall as to allow any traffic. If on the odd chance an MLS PC needs to do a send/receive during this period, it will have to revert to dial-up.

Posted: Sat Jul 12, 2008 11:07 pm
by russellhltn
denleyan wrote:Isn't this a fundamental violation of the Church's network security policies?
I suppose from a technical standpoint it is - but if a slingbox is only thing connected to the DSL/Cable modem, would issues would that create? (I've never used a Slingbox, so I don't know.)

On the receiving end this could be an issue since it exposes the receiving machine (I assume is a PC) to the attacks from the Internet.

Posted: Sun Jul 13, 2008 11:10 am
by danpass
denleyan wrote:
danpass wrote:When we do our building to building simulcasts, I physically take the Cisco firewall offline, which eliminates any possibility of bandwidth contention from computers in the building, since all connections that could have a computer connected to them, hang off of the firewall.
Isn't this a fundamental violation of the Church's network security policies?
To clarify, the way that I take the firewall offline is that I disconnect its WAN/Internet connection. All ports in the building that have or could have a computer connected, are connected via patch panel and a network switch to the LAN side of the firewall. The Slingbox connections do not go through the firewall in order to ensure that the firewall does not interfere with our broadcasts.

The initial policy statement we received from HQ indicated that no devices should be allowed to bypass the firewall. I communicated with Troy Sheffield regarding our (stake president approved) configuration and he said that what we are doing is acceptable.

Posted: Fri Sep 05, 2008 8:59 pm
by danpass
danpass wrote:So far, we haven't actually tried dual feeds using both Slingboxes concurrently. I'll be testing that soon because the Stake Pres. wants to transmit to two buildings in September. Our DSL is 1.5/734 and the 734 upstream bandwidth has given us a high quality feed. The Slingbox adjusts video quality based on available bandwidth. I'll report back here on how the dual feed test goes.
We performed this test earlier this week. As promised, here is my report:

In addition to the information about our configuration that I posted previously, I should mention that I did not make any attempt to allocate bandwidth between the two SlingBoxes through router configuration. I would have pursued this had the need manifested itself.

At the beginning of our test the person helping me at one of the two broadcast destinations was using a MacBook with the Mac version of the Sling player software. He kept having problems with the player dropping it's connection to the SlingBox. He speculated that the Mac version of the player application was probably buggy.

After switching over to a Windows PC and running the Windows player, he had no further connection problems. The player app at both broadcast destinations had default options set as follows:

Video - Buffer settings: automatic - Optimizations: Enable SlingStream optimizer and Enable fast start - Home Network Video Quality: Full Resolution
Encoding - Medium Action

I was worried that whichever SlingBox was connected to first would get and keep a bigger slice of the bandwidth. But as it turned out, within about 15 seconds of when the 2nd SlingBox was connected to, they evened out to where they both were using about the same.

The bottom line is that while there was some loss in video quality with 2 concurrent streams versus a single stream, the audio quality was fine. The video was definitly not broadcast quality but good enough for our purposes. The members who will be viewing these broadcasts are very grateful that we will be saving them from long drives to and from some of our stake meetings