VCS Lync license encrypted media

[skilambi]

Arne

I had a question about the chart showing the license usage in various scenarions with Lync. Specifically slide number 26.

https://supportforums.cisco.com/docs/DOC-19067

Under Encrypted B2B (SIP SIP call without AMG) it states Two Non Traversal. However I have another slide from Cisco attached and while it is for a single VCS and I know your scenario has two VCS (one for internal video end points and one for Lync), where for the same scenario it shows 1 Traversal. That is because the media has to be forked through VCS even through it is SIP to SIP. So if I use the same analogy for your scenario, it should be 1 Traversal and 1 Non Traversal.

I realize that normally under SIP to SIP calls it should be Non Traversal however when the media is encrypted, the media is forked through VCS consuming traversal. So in your case with 2 VCS, the first Lync gateway VCS should consume traversal and the second VCS should be Non Traversal.

Can you please clarify license usage?

Thanks

Srini

[aostense]

Hi Srini,

Your scenario describes the SIP – OCS call with the  OCS enhanced collaboration key installed on the VCS. With this option,  the VCS will have to take the media (to de-encrypt and re-encrypt), and  it will consume a traversal call license (instead of the non-traversal  licenses in my previous example).

So there are many different license scenarios for VCS talking to OCS :

1 VCS (stand alone)

2 VCSs (one VCS GW for OCS)

1 VCS with AMGW

2 VCSs with AMGW (AMGW neighbor on the VCS GW)

1 VCS with Enhanced Collaboration key (MSFT SRTP encryption)

2 VCSs with Enhanced Collaboration key

1 VCS with Enhanced Collaboration key and AMGW

2 VCSs with Enhanced Collaboration key and AMGW

In all these scenarios, you will use different licenses.

Hope this helps.

Arne

[skilambi]

Arne

Than you for the quick response. However wouldn't that license be required if you have encrypted MSFT media? How would you not have that key and still make it work? This is the snippet from the Cisco Lync design guide. On Slide 26, you are referring to encrypted media SIP TO SIP. So even with 2 VCS one of the VCS needs to have that key to decrypt the media which would consume traversal is the point I am making. I realize there are other scearios as you have highlighted in 25/26 which change licensing. I am focused only on encrypted Non HD(without AMG) SIP to SIP.

Currently both Cisco and Microsoft have implementations of the SRTP (Secure Real Time Transport) protocol for encryption of media (that is, encryption of the audio and video traffic). These implementations are interoperable with the Enhanced OCS Collaboration license key for the VCS on version x6 and later.

Srini

[skilambi]

Arne

   Any update to my last post?

Thanks

Srini

[Alok Jaiswal]

Hi Srini,

However since your scenario contains only one VCS acting as Lync gateway as well with encryption support, then you need a enchanced collaboration key on that VCS.

Plus the media is going to be encrypted and since the VCS is always in media path it will consume a traversal license on it. Even the call is SIP to SIP the media has to be traversed through VCS in this case.

Additionally check the deployment guide for Lync on Cisco site.

VCS has the capability to carry out on-the-fly modification of these headers if the

Enhanced OCS Collaboration option key is enabled on the "OCS/Lync gateway" VCS.

The choice of how to configure Lync’s encryption capabilities will depend on:



Is the connection between Lync and the "OCS/Lync gateway" VCS TLS? - if it is not TLS, then crypto keys will not pass (they may only be sent over a secure – encrypted signaling link), encryption must not be set to require on Lync server



does the "OCS/Lync gateway" VCS have the Enhanced OCS Collaboration option key enabled? - if no, encryption must not be set to require on Lync server



is the "OCS/Lync gateway" using the B2BUA? - if no, encryption must be the same on the Lync server and in the video network - if the B2BUA is in use and Encryption (in B2BUA Advanced settings) is set to Auto, the B2BUA will allow calls with video side encrypted and Lync side not, Lync side encrypted and video side not, both sides encrypted and both sides unencrypted



do all video endpoints support encrypted media, and will they offer encrypted media when initiating calls? - if no, and the B2BUA is not in use, or is not configured to allow encryption to be different on Lync and in the video network, encryption must not be set to require on Lync server

Thanks

Alok

[skilambi]

Alok

Appreciate the response. I guess to summarize all this am I correct in statting that slide 26 in the link I attached is incorrect? If I have two VCS(using B2BUA) and I have encrypted media (SIP TO SIP) what will be the license usage on each VCS? Thats what I am looking for. I understand the single VCS scenario well. All I am confirming is Slide 26 which I don't think you are confirming in your response

If you look at the link in my first post above it shows 2 Non Traversal. All I am saying is that, it is incorrect, one should be Traversal and the other Non Traversal. Please confirm that piece

Thanks

Srini

[awinter2]

Skilambi,

what needs to be taken into consideration here is that the B2BUA service is a separate application compared to the VCS "main app", although they operate on the same physical box.

Without knowing your call scenario exactly, I can say as much as that a SIP-SIP call with media encryption (Without AMGW) between an endpoint registered to a B2BUA VCS and an OCS/Lync client will normally consume two non-traversal call licenses, since the media does not pass through the VCS "main app" but via the B2BUA application. Therefore, the VCS does not really take the media, the B2BUA does. The VCS "main app" is therefore only involved in the SIP signalling.

This could become more complex as you include AMGW, VCS clusters, SIP outbound and so on, so it would be difficult to set up a table which covers every possible permutation of scenarios involving the aforementioned features and deployments.

If you could describe in more detail your exact call scenario and expected/observed license usage we will be able to help you out more.

Edit: To comment on the slide you've attached, I would assume that this slide is not from a B2BUA-related presentation but rather a Microsoft integration using the older OCS Relay feature? If that is the case, that will explain why the slide states that a traversal license will be used.

Regards

Andreas

[skilambi]

Andreas

Thank you. I think your post is the first one addressing the issue at hand which is te B2B2U component doesn't let the VCS control component know about the call. That's what I was looking for.

So let me ask for one last clarification. Yes the slide I attached is from an older OCS relay option with single VCS. The slide 26 in Arne presentation is all I am trying to confirm. I wish that deck had all this background since it is very hard to figure out how the licenses are being consumed. My recommendation is to create some decks showing the call path so that it becomes easier to understand. The slide I attached has 10 other call flows that show the media flow clearly making it easier to understand(but as you pointed out it is specific to OCS Relay and has single VCS which is not a recommended design).

So I was told that Slide 26 is two VCS, one being a Lync gateway(B2BUA) and the other for the end points. So here is the flow

Lync --- VCS(B2BUA) --- VCS-C-- Telepresence end point

In this scenario with encrypted you are telling me that since I have two VCS, the first one handles the encrypted media butsince the B2BUA component is independant of the control component, it is Non Traveral on both and the deck is correct

Now I replace this with a single VCS so basically

Lync- VCS(Control/Gateway)- Telepresence end point.

In this scenario it will be 1 NON Traversal because of the same reason as above? Did I get that right? In this OCS relay option this would have been Traversal

Srini

[awinter2]

Srini,

slide 26 shows the total license usage when using one B2BUA VCS and one additional VCS (which holds the endpoint registration) for the given call scenarios.

For the scenario "Lync --- VCS(B2BUA) --- VCS-C-- Telepresence end point", assuming SIP-SIP, OCS Collaboration key,no AMGW and VCS(B2BUA) NOT configured for optimal routing, VCS(B2BUA) would consume 1 x NT and VCS-C would consume 1 x NT.

For the scenario "Lync- VCS(Control/Gateway)- Telepresence end point" assuming the same as above, this would consume 1 x NT.

For B2BUA integrations, the presence of the OCS Collaboration option does not actually make any difference in terms of license usage since the media will in any case always go via the B2BUA.

If you look in Appendix 11 of the OCS/Lync deployment guide for X7.0 (available at cisco.com/support), you will find some useful example call scenarios showing both the call signaling and media paths and license usages, where call signaling is marked with a green line and media is marked with red.

Hope this helps,

Andreas

[skilambi]

Andreas

This is exactly what I was looking for. awesome thanks for the help

Thanks

Srini

[skilambi]

Andreas

Sorry to resurrect an old thread but I came across this slide in a presentation that is incorrect. It is a single VCS(working as GW and core which I know isn't recommended) and using the old OCS Relay function. It is encrypted HD call with AMG, SIP to SIP. I believe this is incorrect since it shows 2 NT. shouldn't there be a traversal component for the encrypted media and then the NT for the AMG?

Srini

[skilambi]

Any input? I realize Cisco is moving away from this but was just curious if the slide had an error

Srini