Cisco Cisco Expressway
Call connects but clears 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 Expressway and Lync servers are able to
resolve each other’s FQDNs in DNS.
is not being properly routed. To resolve this, make sure that the Expressway and Lync servers are able to
resolve each other’s FQDNs in DNS.
Expressway to Lync Server calls fail – DNS server
Expressway 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.
one of its DNS entries set to point to a DNS server which can resolve the FQDNs of the Lync pools and
servers.
Expressway to Lync calls fail – Hardware Load Balancer
If the Lync environment has FEPs with an HLB in front, ensure that the Expressway is neighbored with the
HLB. If it is neighbored with an FEP directly, trust for Expressway will be with the FEP. Expressway will
send call requests to the FEP, but the FEP 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 FEP not seeing the ACK.
HLB. If it is neighbored with an FEP directly, trust for Expressway will be with the FEP. Expressway will
send call requests to the FEP, but the FEP 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 FEP not seeing the ACK.
(Calls from Lync client – registered to the FEP – to Expressway may still work.)
Media problems in calls involving external Lync clients
connecting via an Edge server
connecting via an Edge server
RTP over TCP/UDP
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.
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.
ICE negotiation failure
This can usually be detected by the call clearing with a BYE with reason header “failed to get media
connectivity”.
connectivity”.
Video endpoints only support UDP media. ICE usually offers 3 candidates:
n
Host (private IP)
n
Server Reflexive (outside IP address of firewall local to the media supplying agent – B2BUA or Lync Client)
n
TURN server (typically the Edge Server/Expressway-E)
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 Expressway-E’s TURN server
– bind requests are only accepted by the TURN server if they come from an IP address that is ‘known’.
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 Expressway-E’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:
a=candidate:1 1 UDP 2136431 192.168.1.7 30580 typ host
a=candidate:1 2 UDP 2135918 192.168.1.7 30581 typ host
a=candidate:2 1 TCP-ACT 1688975 192.168.1.7 30580 typ srflx raddr 192.168.1.7 rport 30580
a=candidate:2 2 TCP-ACT 1688462 192.168.1.7 30580 typ srflx raddr 192.168.1.7 rport 30580
Microsoft Lync and Cisco Expressway Deployment Guide (X8.1)
Page 49 of 63
Appendix 1: Troubleshooting