Trunks and M:N Routing

As organizations began to expand Lync Server 2010 Enterprise Voice services, a common pain point was the fact that PSTN gateways could only be associated with a single Mediation server or pool. This was an improvement over the Office Communications Server 2007 R2 limitation in which each PSTN gateway required a separate Mediation server, but it still created some unnecessary headaches in trying to design a resilient solution.

For example, a common use case for a remote site was to place a Survivable Branch Appliance or Server in the site, and configure a gateway to interact with that server. For redundancy, though, it was desirable to create a separate connection between a Mediation server pool in the datacenter to make and receive calls using that gateway in case the Survivable Branch Appliance or Server was offline. This was possible only using tricks like creating a second “virtual” PSTN gateway object with a DNS name and associating the virtual PSTN gateway to the Mediation server pool in the datacenter. The disadvantage to this approach was that it usually required organizations to skip TLS security on the gateway due to certificate subject name mismatches, depending on which pool was interacting with the gateway.

Lync Server 2013 has again improved the SIP trunk experience and now defines trunks between PSTN gateways and Mediation server roles instead of directly assigning a PSTN gateway to a Mediation role. This allows the same gateway within the topology to be referenced by multiple trunks that are accessed in a prioritized order. Trunks are now based on the Mediation Server FQDN, a listening port on the Mediation Server, the PSTN gateway FQDN, and a listening port on the PSTN gateway. This change allows more flexibility on the Lync side and allows each Mediation Server to listen on multiple ports for incoming calls.