The following comes from a prior colleague of mine when we supported Windows Networking and LCS, Steve Hahn now working with CPCC. I modified the details to exclude IP, Domain and User information.
February 16 2012, Steve shared an update on this configuration.
Since you now can have multiple valid PSTN gateways defined now on a Mediation server, you may run into the situation where you have some gateways that are “down” (be it an incoming gateways for the workaround).
- If your primary gateway is not available – Lync will try the other gateways until it either fails or makes an outgoing call. It just works.
- If your primary gateway is not available – and you try to CONFERENCE a user that came in on a random incoming gateway (or even a valid outgoing gateway) – the conference may fail.
We have a load balancer set up for our incoming Mediation Server from our CS1000 environment. (Since we are running Exchange 2007, we are not using DNS load balancing).
In order to make the change to our new Lync environment, we had set up the PSTN Gateway setting as described in the on-line documentation to point to the Lync Mediation servers:
1. In the Define new IP/PSTN Gateway dialog box, do the following:
· Click Gateway FQDN or IP Address, and then type the peer’s FQDN or IP address.
· Optionally, click Listening port for the IP/PSTN gateway, and then type the listening port that the peer will use for SIP messages from the Mediation Server pool. (By default, the ports are 5066 for TCP and 5067 for TLS on a gateway, PBX, or SBC. On a Survivable Branch Appliance at a branch site, the default ports are 5081 for TCP and 5082 for TLS.
· Under Sip Transport Protocol, click the SIP transport protocol that the peer uses.
Multiple Gateway Support:
We also looked for changes, to make sure we didn’t miss anything:
PSTN Gateway Changes in 2010:
In OCS R2, not only did we not have the requirement of putting multiple IP’s as a gateway, you were not even given the option for multiple gateways per mediation server:
With everything set up the same was as OCS (since we knew of no differences), incoming calls were failing. Lync was the one rejecting the calls.
We saw this packet in the trace:
TL_INFO(TF_PROTOCOL) 2200.341C::04/17/2011-20:48:25.024.00011a7d (S4,SipMessage.DataLoggingHelper:sipmessage.cs(613))
>>>>>>>>>>>>Outgoing SipMessage c=[<SipTcpConnection_25EFBFE>], <IP>:5068-><IP>
SIP/2.0 488 Not Acceptable Here
FROM: “user alias”<sip:6922;phone-context=<FQDN>;user=phone>;tag=215b9538-150a010a-13cc-40030-f88-24151298-f88
CSEQ: 1 INVITE
VIA: SIP/2.0/TCP <IP>:5068;branch=z9hG4bK-f88-3cadc0-3f9a141
SERVER: RTCC/188.8.131.52 MediationServer
And in the next frame:
USER-AGENT: RTCC/184.108.40.206 MediationServer
<?xml version=”1.0″ encoding=”us-ascii”?><reportError xmlns=”http://schemas.microsoft.com/2006/09/sip/error-reporting“><error callId=”21359d78-150a010a-13cc-40030-f88-14963252-f88″ fromUri=”;user=phone”>;user=phone”>sip:6822;phone-context=dialstring@<domain>;user=phone” fromTag=”215b9538-150a010a-13cc-40030-f88-24151298-f88″ toTag=”” requestType=”INVITE” contentType=”application/sdp;call-type=audio” responseCode=”488″><diagHeader>10013;reason=”Gateway peer in inbound call is not found in topology document”</diagHeader><progressReports /></error></reportError>————EndOfOutgoing SipMessage
Focusing on the message “Gateway peer in inbound call is not found in topology”, we looked at the traffic:
Notice that the INBOUND call has the source IP changed for inbound calls when going through the load balancer (source it not <IP>). This was not an issue in OCS R2, but is it for Lync???
As it turns out, it *IS* an issue for Lync. In order for an incoming call to come into Lync, the address must be part of the topology – in PSTN Gateways.
Once we had a 2nd gateway defined in our topology (that looks incorrect since there is no gateway listening on 5068 as a gateway), the problem went away.
Not only that, the configuration will not save unless you associate this “Gateway” with a Mediation Pool. So this adds an invalid outgoing IP to your Mediation servers.
I do see the point of restricting incoming calls to only defined IP addresses. But maybe there should be an “incoming” PSTN Gateway setting so we do not have to associate an invalid gateway with a Mediation Server pool.