Cisco Cisco Expressway
Problems with Certificates
If a non-Lync application is used to create certificates to load onto Expressway for use with Lync (for example when
purchased from a certificate authority) it is vital that the Subject name and Subject Alternate Name contain the same
details as they would if the certificates were created by Lync.
purchased from a certificate authority) it is vital that the Subject name and Subject Alternate Name contain the same
details as they would if the certificates were created by Lync.
Specifically, if both Subject name and Subject Alternate Name are used, then the name entered in the Subject name
must also appear in the Subject Alternative Name list.
must also appear in the Subject Alternative Name list.
Video Endpoint Reports that it does not Support the Microsoft Client SDP
If a video endpoint reports that it does not support the Microsoft client SDP, for example by responding “400 Unable to
decode SDP” to a SIP INVITE message containing the Microsoft multi-part mime SDP sent to it:
decode SDP” to a SIP INVITE message containing the Microsoft multi-part mime SDP sent to it:
1.
Check whether the Microsoft Server is sending calls to the Expressway incoming IP port, rather than the
B2BUA IP port that should be receiving the incoming SIP messages.
B2BUA IP port that should be receiving the incoming SIP messages.
2.
Reconfigure Microsoft Server to send calls to the B2BUA IP port.
Microsoft Client Cannot Open a TLS Connection to Expressway
Microsoft Debug says Lync Fails to Open a Connection to Expressway, even though the To Microsoft destination via
B2BUA zone is active and messaging is sent from Expressway to Microsoft infrastructure.
B2BUA zone is active and messaging is sent from Expressway to Microsoft infrastructure.
The local host name and domain name fields must be configured in the Expressway System > DNS page so that
Expressway can use its hostname (rather than IP address) in communications. The Microsoft infrastructure needs to
use the Expressway FQDN to open a TLS connection to the Expressway.
Expressway can use its hostname (rather than IP address) in communications. The Microsoft infrastructure needs to
use the Expressway FQDN to open a TLS connection to the Expressway.
Microsoft Responds to INVITE with "488 Not acceptable here"
There can be two causes for this message:
From IP address
This is normally seen if the B2BUA forwards an INVITE from a standards-based video endpoint where the ‘From’
header in the SIP INVITE only contains the IP address of the endpoint, e.g. “From:
<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.
header in the SIP INVITE only contains the IP address of the endpoint, e.g. “From:
<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.
Encryption mismatch
Look for the reason for the 488. If it mentions encryption levels do not match, ensure that you have configured
encryption appropriately, either:
encryption appropriately, either:
■
Gateway Expressway 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.
“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 drops soon after it connects, it is likely that the caller’s ACK response to the 200 OK is not being properly
routed. Check that the Expressway and FE servers are able to resolve each other’s FQDNs in DNS.
routed. Check that the Expressway and FE servers are able to resolve each other’s FQDNs in DNS.
Expressway to Microsoft client calls fail – DNS server
Expressway needs to have details about DNS names of Microsoft FE 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 FE pools and servers.
one of its DNS entries set to point to a DNS server which can resolve the FQDNs of the FE pools and servers.
54
Cisco Expressway with Microsoft Infrastructure Deployment Guide
Appendix 1: Troubleshooting