Moving at the Speed of Creativity by Wesley Fryer

Help needed with Packeteer and Videoconferencing

The past several weeks I’ve been working on facilitating a high profile, bridged H.323 videoconference that takes place next week on Tuesday. We’ve had two successful test calls with each remote endsite. From a technical videoconferencing perspective things have worked ok and will work for the event, but in our 2nd test call last week our connection had more pixelation than it had in the 1st call which took place at a different time of day. The network we’re connecting on has not implemented QoS and the bandwidth for the organization is shared. (It is a university.) They do have a videoconferencing room with a dedicated T-1 connection, but that cable is evidently pulled directly to that room and can’t be used in the auditorium where we are hosting our event. I’ve requested that we use that dedicated connection, but that’s not possible since a class meets in the videoconferencing room each day– including the day of our event. So, we are in a situation where we have to use shared bandwidth at the university. We are making this videoconferencing connection over IP and the commodity Internet, so it is subject to local as well as outside bandwidth utilization fluctuations.

I have requested that requisite ports be opened on the network firewall for the university, and they have been opened (according to the network gods) but we are still having to make the videoconferencing connection using a H.323 gatekeeper. The 768 kpbs connection this week was too pixelated to use, so we had to connect at 512, and even then there was some pixelation. If we can avoid using the gatekeeper, the packet loss should be reduced since the connection won’t have to traverse the gatekeeper.

The university in question is using the Packeteer PacketShaper network appliance, which permits IT wizards to monitor network traffic and “shape traffic in real-time with flexible policy-based QoS control.” Unfortunately the university we’re working with has not implemented QoS on their network, so the packet-prioritization we’re wanting and needing for this videoconference is not (apparently) supportable with their current infrastructure configuration. Bummer. I’ve suggested that they enter an exception for the port, IP address, and/or MAC address of the videoconferencing codec we’re using, or configure that IP to be in the DMZ of the network, but it remains to be seen if any of those suggestions can be implemented.

According to Blue Coat, the new company that owns Packeteer:

74 Percent of the World’s Largest Companies use PacketShaper.

One translation of this is: In three-fourths of the world’s largest companies, big brother is watching, and if you try to do something the network gods don’t want or like they’re going to shut you down like a garage door.


Creative Commons License photo credit: Marcin Wichary

The support info for Packeter provides a phone number to call for support, and I’ve recommended that the local IT department contact them. This was the same recommendation we received from Tandberg technical support:

Currently Tandberg has no documentation for your 3rd party equipment Packeteer Packet Shaper. Please try your vendor.

This situation highlights several things about videoconferencing and educational networks. Two that come to mind right away are:

  • Challenges and technical discussions like the ones highlighted in this post are a BIG reason why few teachers use videoconferencing in the classroom. Network security has had to tighten dramatically in the past five years due to increased threats. Unfortunately in many contexts, that has not been a good thing for people who want to videoconference (with H.323 equipment or desktop solutions like iChat or Skype.)
  • In our complex network security environment, we need smart networks. When I was working for a telecommunications provider “network neutrality” was something I explicitly avoided blogging about. In some net neutrality circles, advocates say the solution to a networking challenge like the one I’m describing here is to simply “throw more bandwidth at the problem.” Unless we can get that dedicated T-1 line for our videoconference, getting more bandwidth isn’t an option for us. We NEED a smart network. We need QoS implemented. We don’t need or have to have deep packet inspection to get the sort of packet prioritization we need to guarantee the quality of our videoconference connection. QoS can do that when it is properly implemented. This is a perfect example of why smart networks are needed.

I toyed with the idea of actually making this connection over my cell phone computer data card, but given the stakes of this videoconference I’m not confident enough in it to try that for the real event. I might try it to see how the connection is, but hopefully a solution will be found which will let us connect at 768 on the university’s network. If we had an available WiMax connection, that might have enough speed, but again reliability would be a big factor and that is quite different comparing a consumer cellular wireless data connection option and a paid, dedicated hardwire connection. The best my 3G cell connection can do at this point is 384 kpbs up, and we want more quality than that for this connection. I’d like to have high definition quality, since our hosting codec and the conference bridge supports HD, but with our limited bandwidth at the site that is not a remote possibility for next week. 🙁

Technorati Tags:
, , , , , , , , ,

If you enjoyed this post and found it useful, subscribe to Wes’ free newsletter. Check out Wes’ video tutorial library, “Playing with Media.” Information about more ways to learn with Dr. Wesley Fryer are available on wesfryer.com/after.

On this day..


Posted

in

by

Tags:

Comments

One response to “Help needed with Packeteer and Videoconferencing”

  1. Lance Avatar

    Hi,
    this post I spotted via Twitter and it grabbed my attention. As a former Videoconferencing guy who works with Packeteers Packetshapers, it felt right up my street so to speak.

    What the Packetshaper “should” have been able to do is give you the 758k bandwidth and prioritise your traffic over say web traffic. In effect it could give give you two virtual “pipes” one with 768 that only held H.323 and another where everything else went down.

    Depends of course how they set it up. But a Packetshaper should help a VC call. Of course what has most likely happened is that the University has set a bunch of rules up to prioritise traffic and the H.323 is going into the “other” pipe and getting crunched in with anything els ethat has not been classified. 🙁

    Anyway… just my two cents.