Cisco Cisco TelePresence Video Communication Server Expressway
Appendix 1 – Troubleshooting
Cisco VCS Deployment Guide: Microsoft OCS 2007 R2, Lync 2010 and Cisco VCS X7.0
Page 78 of 104
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.
Call to PSTN (via OCS/Lync PSTN gateway) or other
devices requiring caller to be authorized fails with 404
not found
devices requiring caller to be authorized fails with 404
not found
In Some OCS/Lync configurations, especially where OCS/Lync PSTN gateways are used, calls are
only allowed if the calling party is authorized. This actually means that the calling party’s domain must
be the OCS/Lync server shared domain.
only allowed if the calling party is authorized. This actually means that the calling party’s domain must
be the OCS/Lync server shared domain.
For calls from endpoints that are not part of a FindMe this means that the endpoints must register to
the video network with a domain that is the same as the OCS/Lync domain.
the video network with a domain that is the same as the OCS/Lync domain.
For calls from endpoints that are part of a FindMe the endpoints can register with any domain so long
as the FindMe ID has the same domain as the shared OCS/Lync domain and in the FindMe
configuration Caller ID is set to FindMe ID (instead of Incoming ID).
as the FindMe ID has the same domain as the shared OCS/Lync domain and in the FindMe
configuration Caller ID is set to FindMe ID (instead of Incoming ID).