I came across an interesting case where a customer has Lync, and everything works correctly, except when calling out to a specific company. The call connects, but no audio in either direction. All other PSTN calls worked as expected.
I don’t plan to comment on this customer’s particular configuration, just the specific issue in this case.
The customer has a hosted environment in a data-centre. They have Lync Server 2010, with two Front End servers in a pool. The pool has collocated AV, and Mediation.
Also, both the front end servers were dual-homed, with a NIC in the corporate network, and another NIC in a ‘SIP VLAN’ provided by the data-centre as a ‘managed network’. This then connects via MPLS to a preferred ITSP.
I’ve tried to sketch it as best I can with limited knowledge of their environment.
The Front End Servers have their default gateway on the internal network, and a static route to the ITSP SBC via the managed MPLS network (i.e. to reach 188.8.131.52 go out 2nd NIC via 10.10.10.1, therefore over the dedicated SIP network).
All calls across the SIP Trunk have been working for several months. Nothing had changed. But it had recently been reported that all calls to particular company would connect, but no audio in either direction.
Some of you other experienced Lync guys (maybe with a networking background) out there may have already figured it out.
Yep, both customers were using the same ITSP for their SIP Trunks, on the same MPLS network. That in itself shouldn’t cause any issues. But it’s how the data-centre had split up the SIP Network which was causing the issue, more on that below.
The first angle of attack from the ITSP and Data Centre was to blame Lync causing the problem, saying that it was performing some ‘magic’ to automatically discover the SIP peer on it’s own. And that Lync must have been configure for ‘Media Bypass’.. After ruling that out, and explaining what Media Bypass means in Lync terms, we moved back to the network configuration for answers.
The ITSP’s network had a supernet configured as 10.10.10.0/24 which was reachable over the MPLS network.
So, here’s roughly what was occurring…
1 = Customer calling +44123456789 over SIP Trunk to ISTP sends SIP INVITE as usual.
2 = Company receives call over SIP Trunk, it replies, and establishes the call.
3 = The ITSP SBC had informed both devices that their media address was, in fact, each other…
The Session Border Controller at the ITSP was seeing two endpoints on the same /24 subnet, and establishing a call with each other. So it setup the session between them as expected and chucked the Mediation Server’s IP in the SDP, and it was the ITSP side ‘doing the magic’, not Lync. It turned out the SBC was configured for ‘Media Release’, ‘Anti-Tromboning’, or ‘Anti-Hairpinning’ – choose your preferred terminology. Which, don’t get me wrong, is a great feature for them to offer. But it would have been nice for them to realise it was enabled.
The data-centre, being security concious, had split up the /24 network into 8 subnets (/29) which were actively being blocked from routing between each other. In the understanding that each subnet should not need to access anything other than the ITSP’s network. Well in this case, they do.
So, in short… Does the Lync Mediation Server have any special ability to discover the remote media IP and try to bypass the SBC? No. It does what it’s told from the upstream device.