With Andreas Wintervold
Welcome to the Cisco Support Community Ask the Expert conversation with Cisco expert Andreas Wintervold. This is an opportunity to learn and ask questions about design, best practices and troubleshooting tips for Video Communication Server and Microsoft Office Communications Server/Lync integrations using back to back user agent (B2BUA.)
Andreas Wintervold is a VCS escalation engineer at the Collaboration Infrastructure Business Unit at Cisco Norway. He currently focuses on Microsoft integrations (OCS and Lync), VM VCS (Virtualized VCS on VMware vSphere) and VCS deployments in complex networks. He is an expert in most Tandberg products, Cisco TelePresence products, and Microsoft. He has over three years of experience, starting as a support engineer at Tandberg (later acquired by Cisco), and he holds most of the Tandberg certifications.
Remember to use the rating system to let Andreas know if you have received an adequate response.
Andreas might not be able to answer each question due to the volume expected during this event. Remember that you can continue the conversation on the Collaboration,Voice and Video sub-community forum shortly after the event. This event lasts through July 13, 2012. Visit this forum often to view responses to your questions and the questions of other community members.
I am considering integrations VCS with OCS. I would like to understand what are the benefits of integrating VCS with OCS/Lync using the B2BUA method (introduced in X7) of integrating with OCS/Lync compared to the OCS Relay method used in X6 and earlier?
Looking forward for a response.
the B2BUA application has been written from ground up, improving stability, eliminating bugs and offering easier configuration and troubleshooting.
While the OCS Relay method in some scenarios required complex CPL to be present on the VCS, using B2BUA means that no CPL is required in order to register FindMe accounts onto OCS/Lync.
Currently, the B2BUA for OCS/Lync integration always takes media, which means that the OCS/Lync gateway VCS can in some cases remove itself from the call signaling/media path, which could potentially lead to lower license consumption on this VCS.
On a general note, using B2BUA will be the way to go forward as I expect the OCS Relay application to be removed from future VCS releases.
Hope this helps in answering your question.
I am going to integrate the Lync with VCS for one of my Customer for the first time.
Please let me know what important things I need to keep in mind and any other quick notes, you want to share with me??
I am following Lync Integration Deployment Guide .
for the upcoming X7.2 software release, which is scheduled for release in about a month's time, we will also be releasing an updated Lync deployment guide. If you are able to wait until then, I would consider doing so since the updated guide will be simpler and more structured as we will be removing the material for OCS Relay and OCS itself, so that the new deployment guide only focuses on B2BUA integrations with Lync.
In general I would advise you to run through the entire deployment guide first, making sure you understand all of the pre-requisites and detailed instructions. In addition, I would recommend that you plan your deployment, deciding which features you will be using, for example
- If you are planning on a shared-domain integration, FindMe is strongly recommended
- Considerations for presence, presence server should be located on the OCS/Lync gateway VCS
- Will you be needing any static SIP routes from the Lync environment towards the VCS for Multiway/MCU connectivity?
- Proper DNS resolution between the VCS and Lync environment is vital with these types of deployments
Thanks for the explaination. I would have to integrate with X7.1 only because Customer will not wait for X7.2
BTW, when are you planning to give us a webcast or a video presentation on Lync Integration with a demo setup , just as we had from Tim Walker on TMSXE.
there won't be any webcast/video presentation for this Ask the Expert event, this is a pure Q&A spanning over two weeks.
Couple of questions for you.
Can a C-series or EX series endpoint share content with a Lync client?
I noted in the deployment guide that there is a limit of 50 concurrent calls to/from Lync with VCS running in B2BUA. Is that a hard limit or a practical one? Will clustering increase that and if so what would be the maximum?
If using a different domain for the MCU and static SIP routes on Lync, how would one be able to overcome having more than the 50 concurrent calls being sent to a single VCS in a cluster?
What are the advantages of buying the Enhanced OCS Collaboration feature key?
A C-series or EX-series endpoint can send content to an OCS or Lync client (Sending the content in the main video channel since OCS/Lync does not support the BFCP protocol).
By default however, the OCS/Lync client only supports receiving CIF resolution when using the H.263 video codec, which means that the presentation will not be easily readable (In the case of for instance Powerpoint) and quite pixelated.
This will improve if you have the Advanced Media Gateway (AMGW) in your video environment, as the AMGW does transcoding between H.264 and Microsoft's RT Video codec, enabling higher resolutions from standards-based video endpoints towards OCS/Lync clients (Up to 720p from what I recall).
In X7.1 and earlier, there is a limit of 50 calls through the B2BUA on a single VCS. This limit will be increased to 100 in the upcoming X7.2 software for the VCS (A call through AMGW will consume two calls however), and this will allow a theoretical maximum of 400 calls in a fully loaded VCS cluster.
For traffic routed from Lync towards the VCS via one or more static SIP routes however, it will be a challenge to utilize the full potential call capacity since Lync can't (as far as I know) easily dynamically load balance outgoing calls between all VCS cluster peers simultaneously. A static SIP route in Lync can be pointed to the VCS cluster name (Round robin DNS A-record pointing to all cluster peers) but Lync will not switch from one host to another unless the "active" host fails, at least that's the behavior I'm seeing in my lab environment.
Using FindMe registrations in Lync could help with load balancing, since Lync would pass a call to a FindMe address to the specific VCS which registered the FindMe, and although this approach works well with static/MeetMe type conferences, it is not suitable for dynamic conference aliases such as Multiway.
The Enhanced OCS Collaboration option key enables media encrypted calls (SRTP) between OCS/Lync and the endpoints on the VCS side, as well as adding support for calls involving Microsoft Edge servers. It should be noted that for calls via MS Edge, it is also required to have a VCS Expressway available (For TURN/ICE).
Regarding the Enhanced OCS Collaboration key, do you need to purchase it just for your "OCS/Lync Gateway" VCS, or do you need to also buy it for your Expressway to support calls involving Edge Servers? This isn't clear to me from the documentation--just that you have to buy it, not which device(s) you need to buy it for.
the Enhanced OCS Collaboration key only needs to be installed on your OCS/Lync gateway VCS(s).
Do I need any special option keys or licenses to set up an integration between VCS and OCS/Lync?
for a basic OCS/Lync integration, no option keys or licenses are required (Apart from call licenses if you are planning to call between OCS/Lync and VCS-side endpoints).
You will however possibly want to have the FindMe option key for leveraging rich presence from the VCS into the OCS/Lync environment, as well as the Enhanced OCS Collaboration key if you require encrypted media exchange.
I have a couple of other questions.
How can I troubleshoot issues with a VCS <> OCS/Lync integration?
What are the best practices when deploying a VCS <> OCS/Lync integration?
as far as troubleshooting goes, the OCS/Lync deployment guide contains an Appendix covering initial troubleshooting, as well as appendices describing known limitations/caveats and interoperability issues. This is the first place I recommend you check if you experience problems during or after the initial deployment.
If the deployment guide is not helpful in identifying the cause of your issues, the best way forward is problably to capture a diagnostics log on your OCS/Lync gateway VCS while reproducing the problem, for instance placing a test call if the problem lies with establishing calls between the VCS-side endpoints and OCS/Lync.
For the diagnostics log, you should ensure that the 'Network log level' and 'B2BUA calls log level' are set to DEBUG before starting the log.
This log should be included when you raise a case with TAC.
As for best practices, no two deployments are the same, but in my personal opinion, the most streamlined deployment is a B2BUA-based single-domain integration between the VCS and OCS/Lync where you leverage FindMe registrations onto OCS/Lync.
What this does is that when a Lync user calls another Lync user, the call will also be forked to the corresponding FindMe account on the VCS, which further will cause the users video device to ring, and vice versa for calls originating from the VCS side.
Using FindMe registrations onto OCS/Lync will allow the VCS to push rich presence (Offline, Online, Busy/In-Call) into the OCS/Lync environment, which is nice both for personal FindMe accounts as well as for static/virtual meeting rooms on your MCU's.
With a single-domain integration, the endpoints and infrastructure devices (MCU, TPS, TCS and GW) should be registered with a domain which is different for the single-domain shared by the VCS and Lync, meaning that if the Lync/FindMe domain is 'cisco.com', you should register endpoints and infrastructure devices as for instance 'video.cisco.com', 'vc.cisco.com' or similar.
We will be releasing a revised deployment guide after the X7.2 release for the VCS, which will focus entirely on B2BUA and Lync (Meaning that OCS Relay and OCS has been trimmed out), which should hopefully provide more straightforward deployment instructions and guidelines.
Hope this helps!