Welcome to the Cisco Networking Professionals Ask the Expert conversation. This is an opportunity to discuss video conferencing over IP concerns with Cisco expert Sam Chon. Sam has worked in the video telephony industry for six years and has been with Cisco for the past two. Feel free to post any questions relating to Video Conferencing over IP.
Sam may 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 February 9. Visit this forum often to view responses to your questions and the questions of other community members.
I have a couple of questions to begin with:
What IOS feature sets, versons, and hardware are necessary to implement desktop videoconferencing over a frame-relay WAN? We are generally working with 2611s, 2621s, and 3662s.
We want to have methods for controlling VC sessions across our Frame-relay circuits. Criteria include:
- Packet Priority (production data has to take priority over VC, but VC needs immediate forwarding?)
- VC session bandwidth allocation by group (VPs get more bandwidth that general staff)
- scheduling of VC conferences.
We are looking at implementing CU-Seeme's Conferencing server as a meeting point and for controling access through the network, for authentication and Bandwidth. Which of the functions that I mentioned above is best handled by the router and what is best handled by a VC server.
Thanks, - Russ
The IOS feature set you need is for the Multimedia Communications Manager (MCM) which is part of enterprise plus. Look for the H.323 option specifically. It is available on the 25xx, 26xx, 36xx, and 72xx platforms. The MCM has two logical s/w components - 1) H.323 standards-compliant GK and 2) a QoS proxy. In tandem these features should help you in your frame-relay design.
-Packet Priority. The MCM supports proxy capability for IP Precedence, i.e., when a multimedia call passes through the MCM will change the TOS field in the packet header to whatever you define. We recommend setting five but you should consult with a Cisco SE to determine the right value for your specific network requirements.
- VC session b/w allocation by group. This can be accomplished by setting up a separate GK zone for that subset grouping of people you define as high priority. All other users can be maintained in a "generic" zone with different b/w values.
-Scheduling of VC conferences is not supported by the MCM. This is generally a function of MCUs when 3+ callers are needed or seperate enterprise software that handles pt-pt and multipoint call scheduling. There are several vendors that make such software that we partner with. Contact your local rep for more details.
As for CU See Mee, I'm sure they make a fine product, but I encourage you to look at the combinatio of Cisco's MCM and IPVC product set. Call control, bandwidth management, QoS, AAA, are all handled by the MCM in the router. IPVC will provide MCU and gateway functionality to expand the scope of your application.
My inquiry is focused on delivering the same level of reliability as IP Telephony for a
Today the Cisco call manager manages the bandwidth in a Hub and Spoke topology.
If the configured bandwidth on a link is over subscribed, the call manager reroute the call
to the PSTN.
Why such mechanism is not available for video?
Today, if the bandwidth limit is reached, the call is refused and the user receives in the
best case a busy tone. This situation is not acceptable for a business application.
What are the alternative networks we can use as a backup to garantee a successful call on a
least cost routing scheme ?
Thank you in advance
Your criticism of H.323 video conferencing is an accurate one. I am not aware of any H.323 gatekeeper that can define multiple paths to an endpoint (i.e., an IP route and PSTN route via GW) then dynamically or even serially try the best available path. Current users will have to make a decision to "dial" an alternative path if a call attempt over the initial path fails for whatever reason. This is a pressing feature necessary for scalable telephony deployments as you have already noted in Call Manager. This being the case, note that the team at Cisco has already identified the issue and is working towards eventual resolution so stay tuned.
In the short term, however, do not despair. While the existing implementation is far from perfect, H.323 presents significant opportunities for improvement even under the current state of affairs when compared to H.320 based video networks. Cost savings in endstations, infrastructure, and network usage provide financial advantages and greater accessibility and scalability provides practical justification.
I suggest that you continue your input into this forum as we do value your input regarding VC solutions.
Hope this helps...
The solution to 'dial' an alternative path if a call attempt over the initial path fails is not feasable as for the following reasons:
- The latency introduced by one gateway is about 600 ms. Configuring an alternative path over the public ISDN would introduce 2x600 ms = 1.2 s.
- The inconsistency of dialing plans between ISDN world and the IP/e.164 world makes directory management and administration very complicated.
I propose to offer a alternative IP path over a public IP network, charged on a utilisation basis.
The proxy/gatekeeper would be MPLS enabled.
Before a call is established, the router would send a RSVP request on the private IP network. If unsufficiant resources the RSVP request would backtrack to the originating router and chose the public IP route.
Do you think this solution will be developped by Cisco in a forseable future?
I agree with you on both points you made - a) two gateways is a suboptimal alternate path because of the added latency and the complexity of dial strings b) an alternative IP WAN path (MPLS) would be a better way of carrying traffic. Further, having RSVP determine link availability would be ideal.
We have implemented RSVP for video calls using the Cisco MCM Proxy but at this point we send a call reject message back if the bandwidth is insufficient. We do not, redirect to some sort of alternate path.
I will input your recommendations to our BU for consideration.
On the public IP network issue, note that Cisco is not a service provider. While we certainly sell MPLS to SPs, the dependency of having an adequate public path to carry video traffic is based on the SPs ability/desire to implement MPLS in their core. Those of us interested in making video conferencing a ubiquitous technology must collectively communicate the business need to SPs to provide such services IMO.
Alternate MPLS path.
I am working with SP in order to set up an architecture that would allow us to route refused calls to public IP networks.
If the call is proxied by an MPLS enabled router that has two connections:
- one to the private network
- the ohter one to an MPLS ready public IP network
The traffic engineering feature of MPLS should allow us to route the call accordingly.
Is this architecture feasable now if the SP uses MPLS?
I don't know the answer to yur question definitively because to the best of my knowledge such a scenario has never been tried. In principle your idea should work as H.323 media streams have no particular awareness of what path might be taken from one point to another. As long as there are favorable b/w and latency consitions for real-time media streams, your scheme should work. The MPLS proxy would be making route decisions independent of GK so this should not present an obstacle either. I wonder what latency or other issues may be created by an MPLS proxy that may affect video quality. I'm interested in hearning the results of your trial.
Proprietary CODECS and Proxy MCM
Would the Cisco MCM proxy recognise suplementary capabilities such as the PictureTel Siren 14 or the Polycom 60 field/sec.
In other words, does the proxy negociate the capabilities localy with each the endpoint by interpretating the H.245 mesages or does it pass the capability exchange transparantly?
Proprietary codecs will pass through the proxy. The MCM does not touch H.245 messages or caps exchanges between terminals. The proxy changes information in the IP header and not the data payload. So we change IP source address and can set the TOS field to a specified value.
At a site you would require some number of H.323 terminal units. It does not matter whether these are group/room systems or desktop units as long as they are standards compliant. The next necessary componant I would recommend is the Cisco MCM gatekeeper/QoS proxy. This device provides call control, bandwidth management, AAA features, QoS for media streams, etc... Optionally you may add Multipoint Control Units (MCU) such as the Cisco IPVC 3510/3540 and gateways such as the Cisco IPVC 3520/3525. Finally, to the extent that video is intended to pass across your IP WAN links, check b/w and percent utilization. Depending upon the size and number of concurrent streams and also your percent saturation of existing traffic, you may need to adjust the size of such links.
I need to find a content provider for Cisaco IP TV. Does "Direct TV" or a company similar doing this now? I need wholesale movies, and rights, so that a hotel can rent the movies to the guest, exactly like "On Command" except better. Much better, I hope.
Cisco provides IPTV as a delivery/enabling mechanism for video content using RTSP. I don't believe we have any relationships with content providers to provide such content as entertainment or news. You would need to establish your own relationships and IPTV could potentially be used that content. If you are able to establish such a relationship, also look at the products Cisco recently required through the acquisition of Pixstream as that could also provide a high quality streams to viewers.
In order for H.323 to be viable in complex networks, QoS is a given and Cisco supports many different methods for providing QoS. Of the various methods available, is there a recommended approach for H.323? For example, is there a significant difference between LLQ and CB-WFQ when it comes to video? What about RSVP?
Cisco recommends using LLQ over CB-WFQ. When faced with many concurrent flows, even CB-WFQ will eventually starve video of enough b/w to perform. A priority queue for multimedia traffic therefore is preferred. RSVP is also a necessary component for call admission control (CAC, path determination across a mesh-router network, and application b/w-reservation. Another tactic may be to look at application specific routing (ASR) available in the Cisco MCM. If you have the luxury of multiple paths to separate video traffic from conventional data flows, the ASR feature in MCM allows you to select a specific interface for MM traffic.
I have a customer that wants to run video conferencing over a VPN connection between to PIX firewalls. Will there be any major performance issues. The VPN connection speeds at both ends are 2Mbps each. The encryption method is DES.
Dave- There are a couple of things to watch for here: The firewall's ability to pass H.323 traffic, the sustained bandwidth (and potential congestion over the WAN) and end-to-end latency.
Not all firewalls can pass H.323 traffic, since H.323 uses dynamic UDP ports for the audio and video streams. The PIX does have H.323 support, but you should consult with your local PIX expert on the details. A way to work around this is to use the Cisco Multimedia Conference Manager, and IOS-based Gatekeeper/Proxy, which makes operation through firewalls possible by channeling all traffic through the PIX from a single IP address.
Bandwidth: A 2 MB link is a good start towards removing potential congestion. If possible, you should configure some sort of priority queuing for the videoconferencing traffic so that it doesn't get stuck behind large file transfers or email attachments. Another consideration is potential congestion as the traffic traverses the internet. If you're staying with one SP, then you're traffic path is more predictable. If you need to go through one or more peering points, then it is more difficult to say.
Delay: The encryption/decryption process is going to add some additional delay to the traffic. Since videoconferencing is an interactive medium, more delay makes it more un-natural. It is possible to adapt to the delay, and many videoconferences do haveend-to-end delays up to 1 second, but less is better.
Dave - I agree with Mr. Pomeroy's points in his previous reply. The critical issues are QoS over the VPN path (is there an SLA available?) and added latency by both the firewall and encryption elements. The goal, as recommended by the ITU, is to maintain roundtrip latency to <150ms. While higher latencies throuh a network will work for video-confernecing there may be a noticeable performance impact on the user.