Cisco Cisco TelePresence Video Communication Server Expressway
Appendix 1 – Troubleshooting
Cisco VCS Deployment Guide: Microsoft OCS 2007 R2, Lync 2010 and Cisco VCS X7.1
Page 78 of 104
architecture includes a VCS Expressway with TURN enabled and the B2BUA is configured to use that
TURN server.
TURN server.
X7.0 and earlier, non-B2BUA
Handling calls traveling through Microsoft Edge Server is not supported in Cisco VCS up to and
including VCS X7.0 where the B2BUA is not used – Microsoft use a form of ICE that is not supported
in the video network.
including VCS X7.0 where the B2BUA is not used – Microsoft use a form of ICE that is not supported
in the video network.
If attempted, although calls should connect OK, and media should flow from MOC/Lync client to the
video endpoint; audio and video from the endpoint are unlikely to be received by the MOC/Lync client
because the destination information is encoded in the MOC/Lync SDP candidate lines.
video endpoint; audio and video from the endpoint are unlikely to be received by the MOC/Lync client
because the destination information is encoded in the MOC/Lync SDP candidate lines.
When using a Hardware Load Balancer in front of OCS/Lync
Cisco VCS modifies the application part of INVITEs / OKs received from MOC/Lync clients to make
them compatible with traditional SIP SDP messaging. Cisco VCS only does this when it knows that the
call is coming from OCS/Lync. If there are problems with one-way media (media only going from
MOC/Lync client to the Cisco VCS registered endpoint), check the search history and ensure that the
call is seen coming from
them compatible with traditional SIP SDP messaging. Cisco VCS only does this when it knows that the
call is coming from OCS/Lync. If there are problems with one-way media (media only going from
MOC/Lync client to the Cisco VCS registered endpoint), check the search history and ensure that the
call is seen coming from
an OCS/Lync neighbor zone (if not using B2BUA)
an OCS/Lync trusted host (when using B2BUA)
If it is not, then the call may be coming from a FEP rather than the load balancer. See the section on
configuring Cisco VCS and Hardware Load Balancers, and
configuring Cisco VCS and Hardware Load Balancers, and
set up the relevant neighbor zones without any associated search rules, but with peer addresses
containing the FEP IP addresses (if not using B2BUA)
containing the FEP IP addresses (if not using B2BUA)
configure OCS/Lync trusted hosts containing the FEP IP addresses (when using B2BUA)
OCS/Lync rejects VCS zone alive OPTIONS checks with
‘401 Unauthorized’ and INFO messages with
‘400 Missing Correct Via Header'
‘401 Unauthorized’ and INFO messages with
‘400 Missing Correct Via Header'
A response ‘400 Missing Correct Via Header’ is an indication that OCS/Lync doesn’t trust the
sender of the message.
sender of the message.
A response ‘401 Unauthorized’ response to OPTIONS is another indication that OCS/Lync
doesn’t trust the sender of the OPTIONS message.
doesn’t trust the sender of the OPTIONS message.
Ensure that OCS/Lync environment has been configured to trust the VCS which is sending these
messages, as described previously in this document.
messages, as described previously in this document.
Note, this can also be seen if a load balancer is used in front of the OCS/Lync, and OCS/Lync is
configured to authorize the VCS – OCS/Lync sees calls coming from the hardware load balancer
rather than from the VCS.
configured to authorize the VCS – OCS/Lync sees calls coming from the hardware load balancer
rather than from the VCS.
MOC/Lync client stays in ‘Connecting …’ state
MOC/Lync client does not change into the connected state until it receives RTP (media) from the
device it is in a call with.
device it is in a call with.