Welcome to the Cisco Networking Professionals Ask the Expert conversation. This is an opportunity to discuss IP Video with Cisco expert John LaRiviere. John is a Consulting Systems Engineer focusing on IP Video Solutions. During the last year and a half he supports IP Videoconferencing and Video Telephony solutions. Remember to use the rating system to let John know if you have received an adequate response.
John might not be able to answer each question due to the volume expected during this event. Our moderators will post many of the unanswered questions in other discussion forums shortly after the event. This event lasts through December 12. Visit this forum often to view responses to your questions and the questions of other community members.
I keep hearing that RSVP is a recommended approach in video QoS and signaling, but I also hear that it has scaling problems. Can you clarify this?
From Cisco's perspective RSVP is the recommended approach to provide QoS for video and audio streams as well as signiling for those streams. In the past there were scalability issues because similar flows were handled on a per-flow basis but recent enhancements have been made to RSVP such that similar flows are processed on a per-class basis. Since fewer resources are required to maintain per-class QoS guarantees, faster processing results, thereby enhancing scalability. More information on this topic can be found at http://www.cisco.com/en/US/partner/products/sw/iosswrel/ps1839/products_feature_guide09186a0080087b49.html#wp1015327 This is a downloadable PDF file.
As compared to H.261 and H.263, H.264 video compression is said to cut the necessary bandwidth in half for sending video during a videoconference. So one can see what they consider 768K bit/sec quality video at 384K bit/sec, a nice way to reduce bandwidth. The bottom line is that H.264 is more efficient at lower bandwidths than it's predecessors and should significantly improve the quality of Videoconferencing and streaming applications. A good whitepaper to take a look at can be found at http://www.wipro.com/insights/mpeg4videocoding.htm.
So your best option is to look into purchasing a new unit that supports H.323 native IP videoconferencing. Most of the manufacturers today have trade-ins for older gear so you won't have to pay full price and most of the time you can reuse your monitor and cart because the only component that has to be replaced is the Electronics Box which is also called the CODEC. After you have upgraded the endpoint to support H.323 IP videoconferencing you need to start looking at the rest of your infrastructure. The most important component is the Gatekeeper for which you can find information on at http://www.cisco.com/en/US/partner/products/sw/voicesw/ps4139/index.html
Other components that aren't required, but most customers purchase, are the Gateway and Multipoint Control unit. The Gateway allows you to connect from IP to ISDN so you can call just about any other video conferencing unit in the world. The MCU allows you to join conference calls between 3 or more video conferencing units which can also connect to ISDN through the Gateway. More information on these devices can be found at http://www.cisco.com/en/US/products/hw/video/ps1870/index.html
Hope this helps and good luck.
With todays shipping products, Cisco supports the use of MCM Gatekeeper, interacting with Cisco CallManager, as the device that controls Call Admission Control on Inter Cluster Trunks in the voice world. These are the trunks that connect different CallManager Clusters together in large enterprise, Cisco IP telephony networks. Call Admission Control (sometimes called connection admission control) is required to make sure that Quality of Service (QoS) does not break because there is more voice traffic admitted to the priority queue than the queue is provisioned for causing congestion and ultimately poor voice quality. To simplify: When making calls between clusters the CallManager is configured to use H.323 trunks to send RTP voice streams between the clusters and these H.323 trunks are configured to register to the MCM gatekeeper. So every time a call is placed from one cluster to another, the Admission Request is forwarded from one CallManager cluster to another via the MCM Gatekeeper. The ARQ goes to the GK and the GK routes the calls to the destination CallManager Cluster based on the configured dial plan. As the GK is making this decision it is also looking to see if any bandwidth restrictions are placed on the calls and takes this into consideration when determining if the call should be allowed across the network. The GK is configured with a bandwidth value that is equivalent to the provisioned size of the priority queue to restrict bandwidth appropriately. Admission rejects are communicated back to the CallManager so the CallManager can choose an alternate path like the PSTN for the call.
This is about as deep as I can get in this particular forum so if you have further interest in how MCM and Cisco CallManager interact please feel free to contact me at email@example.com and I can help get local resources involved to better handle your needs.
my question is about T.120 standard. I would like to know if this is the only way to do application sharing with Cisco IPVC equipment. The other question is: with T.120 and IPVC 3540 you can set the bandwith of the Video and of the audio stream but there is no way to limit the bandwith of the "application" data flow. This is very bad in most situation where you have limited amount of bandwidht and you could wait a little for the data refresh of the screen but not for video, voice and critical application. What we notice is that the T.120 flow "try" to take all the bandwidht that it can. Have you some indication about this problem or some work around about it?
You are correct, T.120 is the supported standard for application sharing in conjunction with the Cisco IPVC products. T.120 is standards based and directly interacts with the hardware. That said...T.120 may not be the only way you chose to do application sharing from a desktop perspective. There are other web based sharing products on the market that work great but don't interact with the IPVC products. In most cases as long as you have access to desktops as a component of the video conference T.120 may not be an absolute requirement.
The recommendation for question number 2 is to configure QoS on your network. This allows your network elements to prioritize voice and video traffic over data so that as your T.120 application (data) is taking all available bandwidth at that moment in time, it will not be affecting the voice and video. Voice and video traffic will be processed in a priority queue that the data traffic does not have access to. The general idea here is to decrease the availble bandwith for your data applications while you guarantee an appropriate amount of bandwidth for voice and video.
Hope this helps clear things up. Check out the following for info on configuring: http://www.cisco.com/en/US/partner/products/hw/switches/ps679/products_configuration_guide_chapter09186a008007f7a7.html
We currently use a mixture of H.320 and H.323 CODECs. We have noticed that the H.323 connections seem to be a little hazy. We have all our video carried across point to point ATM VCs with no other traffic. The the only difference in our set up is the router that directs the calls appropriately. The router is under no IP or memory strains. All calls are at 384K.
Can we expect to not recieve the same quality from H.323 as we did from H.320?
Unfortunately your description of the symtom is pretty unclear. Can you elaborate on what you mean by Hazy? Are you experiencing blocky or choppy video? Does the video seem to be out of focus? Do you have the ability to run the H.323 codec in H.320 instead to see if there may be something wrong with the actual endpoint? Are you experiencing any clipping of the audio? Need more information to help diagnose the problem.
To answer your question on quality differences between H.323 and H.320, there should be no perceived difference. The audio and video codecs don't care what network transport they are riding over, IP vs. TDM, so there must be something else causing the problem as long as the same codecs are being selected during the capabilities exchange.
Reply back with more information and we can go from there.