Cisco Cisco TelePresence Video Communication Server Expressway

<sip:10.10.2.1>;tag=d29350afae33”. This is usually caused by a misconfigured SIP URI in the endpoint. In future 
versions of B2BUA, the “From”-header will be manipulated if necessary to avoid this issue.

Look for the reason for the 488. If it mentions encryption levels do not match, ensure that you have configured 
encryption appropriately, either:

 

■

Gateway VCS has the Microsoft Interoperability option key included, or

 

■

(Lync Server 2010 only) Lync is configured such that encryption is supported (or set as 
“DoNotSupportEncryption”) – note that if the encryption support is changed on Lync then a short time must be 
left for the change to propagate through Lync Server and then the Lync client must be signed off and then 
signed back in again to pick up the new configuration.

Call Connects but Drops After About 30 Seconds

If a call connects but shortly later clears, this is likely to be because the caller’s ACK response to the 200 OK is not 
being properly routed. To resolve this, make sure that the VCS and Lync servers are able to resolve each other’s 
FQDNs in DNS.

VCS needs to have details about DNS names of Lync pools and servers, and therefore needs to have one of its DNS 
entries set to point to a DNS server which can resolve the FQDNs of the Lync pools and servers.

If the Lync environment has FE Servers with a hardware load balancer in front, ensure that the VCS is neighbored 
with the HLB. If it is neighbored directly with a FE Server, trust for VCS will be with the FE Server. VCS will send call 
requests to the FE Server, but the FE Server will record-route the message such that the ACK response should be 
sent to the HLB. The ACK sent to the HLB gets rejected by Lync Server, so Lync clears the call after the SIP timeout 
due to the FE Server not seeing the ACK.

(Calls from Lync client – registered to the FE Server– to VCS may still work.) 

Media Problems in Calls Involving External Lync clients Connecting via an Edge 
Server

The Edge server supports RTP media over both TCP and UDP, whereas the B2BUA and standards based video 
endpoints only support RTP over UDP. The Edge server and any firewalls that the Edge server may pass media traffic 
through may need to be reconfigured to allow RTP over UDP as well as RTP over TCP to be passed.

This can usually be detected by the call clearing with a BYE with reason header “failed to get media connectivity”.

Video endpoints only support UDP media. ICE usually offers 3 candidates:

 

■

Host (private IP)

 

■

Server Reflexive (outside IP address of firewall local to the media supplying agent – B2BUA or Lync Client)

 

■

TURN server (typically the Edge Server/VCS Expressway)

For ICE to work where an endpoint is behind a firewall, the endpoint must offer at least one publicly accessible 
address (the Server Reflexive address or the TURN server address). This is used both for the B2BUA to try and send 
media to, but also to validate bind requests sent to the VCS Expressway’s TURN server – bind requests are only 
accepted by the TURN server if they come from an IP address that is ‘known’.

If a Lync INVITE offers only host candidates for UDP, for example:

49

Cisco VCS and Microsoft Lync Deployment Guide

Appendix 1:  Troubleshooting