As with every other SIP solution for voice communications, there is a place for session border controllers (SBC) in a Microsoft Lync configuration. However, leave it to Microsoft to make their solution different enough that it warrants some discussion.
SIP Trunks
Let’s start with SIP trunks. As you probably already know, an SBC will sit on an enterprise’s network edge between the on-premise communication system (in this case, Lync) and the SIP carrier. Specifically, it will sit behind the carrier’s edge router in the enterprise’s DMZ. An SBC does a lot of different tasks, but it is primarily concerned with security, routing, transcoding, network address translation, and topology hiding. With one slight caveat, this is also the case when it’s used with Lync.
The typical SIP trunk inbound call flow to Lync is as follows. The call will traverse the carrier’s MPLS network and land on the edge router assigned to the enterprise. The edge router will deliver the call to the SBC as IP packets. The SBC will apply its rules for security, routing, SIP adaptation, etc. and then send the call to the Lync Mediation Server. The Mediation Server will direct the call to the intended user. Once media begins to flow, the Mediation Server also performs the trancoding that converts the carrier’s media (typically G.729) to Microsoft’s proprietary Real-time Audio (RTAudio) codec.
An outbound call follows the reverse path back to the carrier.
I mentioned that there is one caveat in terms of the SBC. Even though one of the tasks performed by an SBC is media transcoding, no SBC on the market today will transcode RTAudio. That must occur in the Mediation Sever. However, if Lync Media Bypass is enabled, all voice calls will be sent as G.711 which bypasses the Media Server. With Media Bypass, calls go straight to the SBC.
All of that is well and good. Although the Mediation Server is unique to Lync, the idea of an SBC connecting SIP trunks to some component in a communications system is universal. The big difference comes when we talk about mobile users.
Remote Users
I will pick on Avaya for a second. When you want to bring in a mobile SIP soft client (e.g. an iPhone running Avaya’s One-X Mobile for IOS or Mediatrix’s Media5-fone) into an Avaya Communication Manager you do so through an SBC. As with SIP trunks, the SBC sits on the enterprise’s network edge, but instead of utilizing a carrier SIP trunk, it connects directly to the Internet. The mobile SIP clients send calls across the Internet to the SBC. The SBC will then send the call onto the Avaya Session Manager. Media flows directly between the SBC and either an IP phone or a media resource in an Avaya gateway. Similar configurations exist for non Avaya SIP communications systems.
However, Microsoft chose to go a very different route. You do not use an SBC with mobile Microsoft clients. Lync has its own set of servers (edge server, reverse proxy, etc.) to support mobile users. Those servers ultimately perform the same tasks as an SBC in terms of security and network connection, but they are proprietary Microsoft tools.
This also means that if you want to connect a remote client it must be a Microsoft Lync client. You can’t use a third party SIP client like that Media5-fone as I do with Avaya. That said, Microsoft offers a plethora of clients on all sorts of devices. So, it’s not that you can’t get in. You simply need to do so with one of their clients.
Does all that make sense? An SBC is a very important component in a Lync configuration, but how it’s used differs somewhat from what the rest of the world does.
I plan to continue to dig deeper into Lync issues so please stick around.
Tao, Zen, and Tomorrow 