Can you clarify these comments:

“Network protocol makes a difference in your video transmission as well. TCP protocol sends a return packet for every sent packet to verify the packet was received. As you can see, this increases the traffic on the network with the return packets going back. The advantage is that getting a receipt mitigates gaps in transmission, as if a packet is not received it can be resent. This is very important in video, especially if the packets are large.”

It seems to me as if you’re implying that video traffic uses the TCP protocol. Unless I’m mistaken, audio and video both use UDP/RTP or UDP/RTCP. The reason is because of exactly what you’re describing in the above paragraph. If an audio or video packet is not received, it is simply dropped or lost due to it’s real-time nature. It is practically impossible to utilize a TCP protocol for data that is real-time like audio or video. Any attempt to resend dropped packets would cause huge delay in the transmission of the audio/video, making for a very bad experience. That’s the reason lost packets are just dropped.

@Kevin Gilbert

Yes Kevin, I apologize that my point was not entirely clear.

If you are referring only to Video Traffic related to Video Teleconferencing, you are correct that typically “audio and video both use UDP/RTP or UDP/RTCP.”

However, this article was meant to address video traffic on the whole, not just real time VTC traffic, and I don’t believe I said VTC uses TCP, although if it came out that way, I apologize. 

Archived training sessions, marketing reels, etc may all be stored on the storage systems (SAN, NAS, etc) in a large corporation and shared across the network.  In these cases, and even in cases where there is web based content that is not “real time” is being accessed through video sharing sites, the TCP protocol is used and you have to account for a receiver side buffer, which is in place due to the return packets, as to deliver all frames without error or interruption.

I’m sure that marketing departments and training directors would not take kindly to UDP on their content when real time delivery is not the priority, and that a TCP protocol can assure the receiver gets the whole message, sans dropped frames.

When the network is not built for these considerations, then you have long load times and/or video that freezes periodically to catch up.

I should have clarified as I was addressing video traffic as a whole, and not VTC traffic specifically, and was trying to do so in a few neat paragraphs.

Great Comment.
Thanks for your knowledge and I apologize for any undue confusion.

Mark C

Thanks for the clarification, Mark, and no apologies necessary. I don’t think you did specify VTC anywhere, but that is typically my first thought when discussing audio or video over a network. When I re-read the paragraph, I was unsure if you were referring to video on the whole and so I assumed VTC. Funny. I think we both made statements that were correct within the context of our unintentional assumptions. Good write-up. Thanks.

Funny how 2 people can both be right based on perspective huh?  I always approach these potential disagreements from that perspective.  Years of dealing with end users and clients make this a necessary approach, one you seem to be very aware of as well!

Thanks for reading and for your participation.  I wish more integrators would chime in here and there.  Dialog is a good thing

Best to you and your business in 2012.

Mark C