One-Way Audio\Video from CMS to Lync

[Stephen Carr]

thought I'd try here first just in case someone has seen this before (before I open a case). We've now set up the CMS system successfully to connect to Lync and most things work except the following:

calling from a Meeting App client to Lync causes one-way audio\video (Lync user can be heard and seen but not CMS user) but app sharing and presenting work both ways. Then the call drops in 30 seconds (I've seen this with trunks and timers in Lync but not with Trusted App setups). It shows as a network time out issue. If the call is initiated from Lync everything works just fine. Also, if I connect to Lync from an external mobile client and call from CMS that works fine. So it is just internal Lync clients. So, my instinct is that it is a firewall issue (something between the edge and core\Lync) but I've followed the instructions for all the ports required (all the STUN ports particularly).

Anyway, if anyone has any ideas on where to look (the logs on each device don't tell much) I'd much appreciate it.

thanks

Steve

[Martin Koch]

From how I recall it Lync/S4B will terminate the call if it does not receive media.

Deployments can be quite different, so more information including a drawing would help here.

In general in an internal deployment there should be not NAT and no need of TURN/STUN.

You have a deployment with a frontend server on the inside right?

As you write meeting app, does it only happen on a call to the client or also to any space/meeting room on the CMS?

Please review the Lync and CMS firewall/network requirements. It sounds that you 

still block something. Its a wide range of ports which have to be open in between the L/S4B

client and the server.

IF you look at page 103-109, this should give you information (you might need to check

other files if you have a different deployment type):

http://www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/Deployment_Guide/Version-2-1/Cisco-Meeting-Server-2-1-Single-Split-Server-Deployment.pdf

These ports need to be open for TCP and UDP in both directions:

Callbridge <-> Lync client (L)

32768-65535 <-> 1024-65535

I could picture you lack at least an opening from the callbridge to ports 1024-65535/udp in the lync client networks.

[Stephen Carr]

thanks for the reply. I am indeed in a split deployment and have studied the very picture you referenced (on page 103) but haven't been able to figure out what I'm missing (and yes, I'm not using NAT). By that diagram, and internal CMS client should be contacting directly to the XMPP server and the call bridge and should not try to use the TURN server, correct? I ask as the only thing that I feel may be going on from a firewall perspective would be TURN traffic going to and from the Edge server (DMZ<->internal) and that I missed a port there somehow (I've setup 447 TCP/UDP, 3478 TCP/UDP, 32768-65535 TCP/UDP going both ways) but if the internal clients aren't using that at all then I'm stumped as there are not any firewalls between the Call Bridge and Lync. Still, because it works going from Lync to CMS I have to beleive it is a port issue when the call is initiated by CMS but only if it all comes through the Edge server and I missed a port. Does that make sense and can someone verify that the internal client only used the XMPP and Call Bridge?

Steve

[Stephen Carr]

Actually, I think I may have an idea as to why this is happening. It looks like the media traffic ends up coming from the "management" interface of the CMS server (the webadmin interface) instead of the callbridge interface (all of the signalling comes through the trunk to Lync so it works fine). So, I'm guessing this is a routing issue (if the call is initiated by Lync it then uses the right interface and if the Lync call is from an external client like Android then itall goes through the trusted application trunk or to the Lync edge servers) . The Lync client sends the UDP packets to the callbridge and the CMS sends the response back from the webadmin interface. As both of these interfaces need to be accessible from our internal IP subnets... is there a way to manage this without having to add static routes or should I just put the webadmin process on the same interface (not recommended in the documentation) and change the port?

[Stephen Carr]

So, I made the callbridge interface the default interface for now and that seems to have fixed the issue. Of course my concern would be if this will cause issues for the webadmin interface for inter-CMS connectivity. Any thoughts on this and what others have done when they've setup multiple interfaces?

Steve