on 12-03-2012 09:06 AM - edited on 03-25-2019 06:29 PM by ciscomoderator
With Mahesh Anjan
Mahesh Anjan is a product manager in the Collaboration and Communications Group at Cisco. He is an expert in deployment of video communication services, enterprise video solutions, and other telepresence products as well as unified communications. He has vast experience in VCS and Cisco Unified Communication Manager interoperability deployments. Anjan has worked at Cisco since 2005. He holds a bachelor’s degree in electronics and communication engineering from the University of Bangalore, a master’s degree in computer engineering from Wichita State University, and an MBA from the University of North Carolina at Chapel Hill. He holds service provider HCS specialist certification.
The following experts were helping Mahesh to answer some of the questions asked during the session: Viraj Raut and Alan Ford.
You can download the slides of the presentation in PDF format here. The related Ask The Expert sessions are available here. The webcast recording is available here.
A. In some deployments where H.323 registrations are needed, a gatekeeper will be useful. In addition, if there is a need for interworking between protocols such as H.323-SIP, a gatekeeper (VCS) helps.
A. RTMT is something that we have frequently leveraged in our lab setup. However, if you are having an issue and you call the TAC they will request the entire snap-shot of the SDI and SDL logs and I would be careful to run any of the SDI/SDL logs during the typical weekday because of the number of calls going through your network. So try to avoid running in real -time. There is an option in RTMT that you can run real-time, however it's going to dump a lot of trace and its going to be very bulky. See if you can get those traces during off-peak period. There are many tools out with which you can get the trace from packet capture but typically in our lab environment we use a packet capture or Wireshark to get the traces.
A. Do you have the VCS-interop script on the SIP trunk? If you look at "search history" on the VCS, do you see the call reaching the VCS , and if so, according to the call history, who ends the call? Do other endpoints on CUCM work fine calling to VCS endpoints?
A. It all depends upon your quantity of call flows. I would really not recommend in an Enterprise call set-up that you would extract the call logs. It all depends on the call volume. It can significantly decrease your performance quality and also the call-processing capability. So make sure that you don't run during peak hours. Execute during off-peak hours during which call-traffic is very low. Getting the logs will have significant impact on the processing capability as well.
A. Answer provided in this Ask the Expert Event.
A. Answer provided in this Ask the Expert Event.
A. Answer provided in this Ask the Expert Event.
A. Do you have a TAC SR number? I'll look into this more for you. It may well be a known bug that is fixed in CUC.
A. VCS does EO by default. Early Offer is preferred for easy setup and call negotiation. However B2B UAs usually prefer DO as it can accurately negotiate the audio and video codec before sending the call to the endpoints.
A. If the question was H.225 trunk to VCS, the answer is that it is not supported.
A. Yes, with version 1.8 or later on the codec.
A. If you have an MCU in the picture you should be able to do a BFCP.
A. It will be best to speak with your Cisco contacts to the product managers to get the exact details.
A. Before 1.7.4.1 CTS Version (for example a CTS calling a 9971) we need to actually send the call to an MXE media engine like MXE 5600 or any of the MXE series. You had to send the call to the MXE first, and then from MXE back to the UCM. UCM would send the signaling to the other sites. That's how we typically used to call between the CTS and the lower end points like 9971. Now with Native Interop the capability is not restricted. You can make a point-to-point call between a CTS and 9971 instead of traversing the call via MXE. We call this methodology Native Interop.
A. Answer provided in this Ask the Expert Event.
A. This can be done either way based on if the MCU will be used for ad-hoc conferences or scheduled conferences. You may need to refer to the design guides to get the best recommendations.
It actually depends on your network scenario. MCU is been typically used as a conferencing resource on the VCS. So if you have a VCS deployment you need to have a multiway conference and your end points can actually join via the conference factory. But on the UCM side we are actually providing the flexibility for the customer to use the MCU wherever it is. If we have a VCS deployment you will have an MCU hanging off the SIP trunk to the VCS. But providing the same flexibility to the UCM because we want to have a three party ad-hoc conference on the fly. In that case you need to have the MCU on the Call Manager. It is heavily driven by usage on UCM and that's what you want to leverage. I would recommend putting the MCU on the UCM side rather than on the VCS.
A. There is no official support to schedule the conferences if the MCU is on the UCM. We are using the TMS heavily on the MCU that are registered to the VCS as of now. But we do have that requirement in the roadmap and possibly you will hear something from Cisco very soon.
A. Answer provided in this Ask the Expert Event.
A. Answer provided in this Ask the Expert Event.
A. Answer provided in this Ask the Expert Event.
A. Answer provided in this Ask the Expert Event.
A. Answer provided in this Ask the Expert Event.
A. If you look at the case study, we actually moved that end point back to the VCS and when we had the call back going back from Sony to the 9971, it always negotiated on the 97 so on the UCM we didn't had a mid-call invoid that was coming out of UCM. We actually avoided that issue by moving that end point. We pretty much had the media going on 97. We didn't had the UCM to act back on 105. We avoided that situation altogether.
A. Payload type is mostly decided based on the protocol. In most cases the Call agent/B2BUA can request the answering endpoint to use the payload type it requests. However most video endpoints do not honor it. With the call with CUCM for H.323-SIP this will result in the endpoints sending media at their preferred PT and result into one way video or black screen on the endpoints. Using the VCS then can rectify this scenario.
A. The RTMT tool can be used to display location information that translates to the bandwidth used. With UCM 9.0 there is a separate menu item under serviceability under "Tools->locations ->effective path" to see the configured and the available bandwidth.
If you go to the RTMT there is a way that you actually add the counter based on which UCM device pool you have and it pretty much shows the region bandwidth that has been set. So you can monitor via the RTMT counter. That's how you monitor from the UCM stand point. There is a pretty good option in UCM RTMT that allows you to monitor the bandwidth, once it negotiates the bandwidth of that particular counter. For example if you enter 384, you already have calls going you can pump in some X number of calls based on that region bandwidth. Once you actually exhaust that bandwidth, you will end up getting a busy tone. You can go in and see the counter and the available bandwidth so there are number of parameters. For example, "bandwidth used", "bandwidth available"...So the counters appropriately reflect the number of calls that are going through the network.
A. We have made some enhancements on 9.0 UCM and if you see on the EX 90 screen take for example there is a call security. It will show a lock icon on the right hand bottom corner of the EX90 screen. That's how you determine and call status to be secured. And not only by display. If you get into the log side you will see there is actually a crypto line that's been added to the STP. So if you refer the appendix you can find a case study which deals with an encryption between a CTS and an EX 90 registered to the VCS. This case study actually has an STP snap-shot of how you can determine the security of the call state directly from the STP. This is a good study on the appendix. If you go to slide 104 you will be able to get relevant information.
A. Answer provided in this Ask the Expert Event.
A. Answer provided in this Ask the Expert Event.
A. Answer provided in this Ask the Expert Event.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: