Why you should deploy a media gateway in a Lync voice deployment

Everyone’s moving to Lync 2010 for voice. It’s growing super fast and taking loads of market share from the incumbent vendors, and your organisation is keen to see what all the fuss is about. But how do you interoperate with your existing PBX? How about you want to add a SIP trunk to evaluate the cost savings/flexibility whilst still maintaining your ISDN E1/T1 services? An enterprise class media gateway is the meat in the sandwich to get the job done.

I’m not going to harp on about a particular vendor’s product, but I want to wax lyrical a bit here on why a gateway is a valuable and sometimes critical, part of your Lync voice deployment. It can mean the difference between a smooth migration and coexistence period, and a nightmare scenario where you have islands of voice kit that can’t talk to each other.

I’ll focus on an upstream deployment of a gateway in this post, meaning that the PSTN (ISDN and/or SIP trunk) is terminated at the gateway. Lync, the PBX and any other telephony infrastructure then sit behind the gateway, like in this diagram:


Any to Any Routing

Deploying a gateway capable of taking one signalling protocol (e.g. ISDN, SIP, H.323) and translating it into another is invaluable in an interoperability scenario. An example is when you find yourself needing to route calls from Lync (signalling in SIP/TLS and SRTP media in G.711 aLaw) to your 10 year old Ericsson PBX (over an ISDN E1 trunk), a gateway is the only device that can do this transcoding and feed the PBX the signal it needs.
Or maybe your old Cisco Call Manager only accepts SIP over UDP? No problems, the gateway can translate the signalling for you.

Calling/called number translation is a gateway’s bread and butter also. Taking full E.164 numbers from Lync and manipulating them into 4 digit extensions a PBX can use or a format the PSTN can understand is where a gateway makes life easy.

Migrating Users

If you’re not doing a “big bang” migration from your PBX, chances are you want to maintain a period of coexistence so you can slowly migrate your users to Lync. Gateways that can cache AD user information enable you to route calls based on whether a user is enabled for Lync or not. This means that the only thing you as an administrator needs to is enable the user for Lync and the gateway takes care of the rest.

Supporting SIP Phones and Fax Services

Say you have a big bunch of SIP phones (Cisco, Polycom, snom, etc) left over from your old PBX that you still want to use. A gateway with built-in SIP registrar functionality can keep them alive by registering your old SIP phones straight on the gateway and assigning phone numbers to them. They’re not Lync enabled, but at least you provide a dial-tone to them for basic voice functionality.

Faxing is ubiquitous in the enterprise and still plays a role today, so both analogue and server-based fax functionality needs to be maintained in a UC environment. Fax machines talking to an ATA device can talk SIP straight into a media gateway, or a fax server (Facsys, Goldfax, Rightfax, GFI etc) will easily talk straight SIP into the gateway as well and onto the PSTN.

Terminating PSTN Connectivity

SIP trunks from UCOIP qualified vendors are great and can plug straight into your Lync Server, but sometimes you may want to try out another vendor’s SIP trunk that can’t talk to a Mediation Server directly. A gateway can take this SIP trunk and turn it into the flavour of SIP that Lync requires, giving you a lot more choice in services.

Voice resiliency is a key requirement in most deployments, so multiple SIP trunks from different vendors or a backup ISDN line will typically be scoped. A gateway makes it easy to deploy all of these and manage the primary and secondary routing in and out in the event of failover.

A lot of SIP trunk providers deliver their services over a VPN, which a gateway can typically terminate also. Or if the trunk is provided encrypted over the internet, you’ll usually need to NAT it into your internal network. Media gateways are typically NAT capable, which means you can make the gateway aware of your public IP and ensure outgoing SIP packets are marked with it so traffic can route back in successfully.

The core of your Voice Infrastructure

When you have a dependency on other voice components, a gateway really becomes the heart of your environment. Sure they can be costly, but you’re investing in making your migration as smooth as possible and providing a considerable degree of flexibility into your environment.

One thought on “Why you should deploy a media gateway in a Lync voice deployment

  1. Pingback: Why you should deploy a media gateway in a Lync voice deployment | Justin Morris on UC « JC’s Blog-O-Gibberish

Leave a Reply

Your email address will not be published. Required fields are marked *