SIP Trunking in Lync Networks The Simple Way out. An IT Managers advisory document for the simple way out of a complex task

Transcription

1 An IT Managers advisory document for the simple way out of a complex task

2 Introduction: Why should you care? Like many IT managers, you might have already deployed Microsoft Lync or you may be considering doing so for the many productivity benefits it offers, such as instant messaging and presence, collaboration, and video and audio calling and conferencing. You may even be looking at Lync as a replacement for your existing legacy enterprise voice systems. One of the major challenges facing IT managers when deploying Lync as an enterprise-wide voice solution is achieving communications cost savings. Multi-national enterprises, large corporations, and even mid-market organizations are increasingly adopting cost-effective SIP trunking services. While Microsoft enables SIP trunking connectivity directly through the Mediation Server, one question often asked by IT managers in this situation is: Do I need a Session Border Controller (SBC) in my network to connect Lync to SIP trunking services? The considerations around deploying an SBC may be a bit confusing. This application note can assist your decisionmaking process by guiding you through five fundamental considerations: 1. It s not about ability, it s about interoperability Yes, a handful of SIP trunk providers are qualified to connect directly to Lync Mediation Server. But you want the freedom to be able to connect to any SIP trunk provider seamlessly and without limitations, to derive full benefit from the new technology. 2. Stay secured - better safe than sorry Along with the many benefits of SIP trunks come a bunch of security threats that Mediation Server is not designed to handle on its own. How do you keep SIP floods, fraud, DoS, port mapping and other similar threats out of your daily concerns? 3. Quality? How can I monitor my network s QoS? You want to be able to monitor the quality of service you are getting from your SIP trunk provider and take immediate action if you notice any potential problems brewing. 4. Flexibility. Without stretching Deploying an SBC will provide you with the necessary session management to integrate legacy PBX, PSTN and SIP trunking with Lync in ways that support smooth migrations and managed co-existence. 5. Media? What Media? Once connected to a SIP trunk you want to ensure that the voice quality your users are experiencing meets your expectations. You need a solution that can monitor your connections and effectively handle impairments such as packet loss, delays, jitter, DTMF transmission issue, as well as supporting flexible transcoding, fax handling and conversion from RTP to SRTP. Bottom line Deploying an SBC to connect your Lync implementation to SIP trunks is a simple and highly effective way to avoid headaches and limitations as your deployment progresses. Read on to learn more... 1

3 1. It s not about ability, it s about interoperability Yes, specific certified SIP trunk providers are qualified for direct connectivity with Lync Mediation Server. However, Mediation Server is not capable of connecting natively with many ITSPs for a wide variety of reasons. Since no Internet Telephony Service Provider (ITSP) will modify their core SBC settings just for your benefit, you need a solution that can offer proven interoperability and flexibility to ensure seamless SIP trunk connectivity. In fact, even Lync-certified ITSPs are not immune from SIP incompatibilities. The certification process does not take into account every possible scenario. Therefore, the lack of SIP normalization can result in a number of problems, including the following: - Callers from outside the organization do not hear ringback tones - Putting calls on hold results in the call being dropped - Calls get rejected when multiple Front End Pools are used - Long duration calls are dropped after 20 minutes - The original Caller ID is not presented when calls are forwarded - Callers do not hear Music on Hold being played To illustrate how an SBC solves complex compatibility issues through SIP normalization, here are a few examples: Translating SIP UDP to SIP TCP or TLS The Mediation Server supports only SIP over TLS or TCP. However, most SIP trunks only support SIP over UDP. An SBC can perform this adaptation to ensure smooth connectivity. Supporting Call Transfer and Call Forward over SIP Trunks It is possible to disable the REFER SIP message on Lync. In the case of call transfer, if REFER is not handled and normalized to re-invite, the media will traverse the Mediation Server (and require costly investment in a higher capacity server). In addition, not all ITSPs support the History-Info and Referred-By SIP headers. As a result, the ITSP will reject the call transfer or forward. An SBC will use its header manipulation capabilities to map the information sent by Lync either in the History-Info or Referred- By headers into whatever the ITSP uses usually the DIVERSION header. Avoiding Over-charging on SIP Trunking using Session Timer Most ITSPs do not support SIP session timer functionality. If a Lync call ends unexpectedly (i.e. no BYE message is sent), the ITSP will think it is still open and continue charging for it. An SBC can identify when a call ends and notify the ITSP. DTMF Handling VoIP networks handle DTMF tones in one of three methods: within the voice packets payload (known as inband ) in a dedicated signaling stream (RFC 2833) or out-of-band within the SIP signaling While Lync only supports RFC 2833, some ITSPs only support the other two options. In such cases, an SBC is needed to perform the necessary translation between inband or outband DTMF and RFC

4 1. It s not about ability, it s about interoperability (continued) Resilient Routing over SIP Trunking Upon the receipt of a SIP response error code 503 (Service Unavailable), Lync performs a failover to another SBC or gateway. However, most ITSPs do not support this release code. To overcome this limitation, the SBC s adaptation capabilities enable the mapping of release cause codes. Avoiding Dropped Calls and One-way Voice Using SRTP Normalization Lync handles SRTP (MKI/ ROC) in a proprietary way. Since most SIP trunks do not support SRTP at all, the SBC will need to perform SRTP-to-RTP ceonversion. Typically, during call-hold/unhold and long call scenarios, if the SRTP-to-RTP conversion is not handled properly, the call may experience one-way voice. Maintaining User Experience When a Lync deployment suffers from poor network conditions, individuals calling into an organization may experience delayed call progress tones (e.g. ringback tones), since in Lync these tones are played by the Lync client. An SBC placed at the enterprise network edge will detect the existence of the internal network delay and generate the necessary call progress tones itself toward the SIP trunk. Direct Inward Dialing from SIP Trunks Some ITSPs require that each DID, or DID group, within an organization be registered separately to the service to be able to accept direct inwards dialing. Lync, however, does not support registration per user/extension. In some cases, the result would be that inbound calls are limited to a single primary number (extension/user). In such a scenario, the SBC can register all DIDs with the ITSP on behalf of Lync to ensure that incoming calls are routed directly to their destination. 3

5 2. Stay secured - better safe than sorry Securing the enterprise network is one of the top considerations of any IT manager. Despite the many benefits of SIP trunking, connecting an enterprise voice network to a SIP trunk provider has the potential to expose your network to significant fraud and security threats. As its name suggests, Mediation Server is primarily designed to handle interoperability between Lync and other systems. Security is not its primary focus. The seemingly straightforward solution to this problem would be to place a firewall between the Mediation Server and the outside world. Standard firewalls, however, are not capable of analyzing VoIP packets down to the SIP level where the sensitive data exploited by hackers is found. An SBC is a voice firewall, picking up from where data firewalls leave off, providing the same kind of protection for voice traffic that data firewalls provide today for data traffic. The SBC includes mechanisms designed to deal with specifically VoIP-related security and fraud threats, including: SIP floods - SBC monitors and prevents attempts to bring down the VoIP system by overloading it with bogus call setup messages (SIP INVITE) Fraud prevention - Lync does not support fraud prevention. Hackers can use scanners on the SIP trunk to discover the enterprise network topology including IP address and usernames. With this information they can intercept calls and make outgoing calls from the Lync at the enterprise s expense. The SBC can detect such attacks and prevent them through the use of dynamically created blacklists Denial of service - The SBC is able to block attempts to disrupt service by bombarding the system with call requests. The Mediation Server could easily be overwhelmed by such an attack. The SBC can automatically block ports being attacked Secure Authentication - The SBC ensures that any authentication attempts with the SIP trunk network are secured using encryption and TLS Topology hiding - No one really wants their internal network topology to be exposed to the public view. But without an SBC in place that is exactly what you are doing. The SBC is able to strip any sensitive and potentially revealing data from outgoing messages to ensure that your internal network structure remains your own business 4

6 3. Quality? How can I monitor my network s QoS? Of course, you need to be sure your Lync system is offering the highest possible voice quality, and of course you want to be able to monitor the quality you are getting from your SIP trunk provider. In addition, you need to take immediate action if voice quality levels drop before your internal customers start complaining. Here again, the SBC offers important features that enable you to monitor and control your VoIP network s quality of service in real time: Quality of Experience Measurement and Monitoring The Mediation Server uses RTCP to obtain far-end Quality of Experience (QoE) reading. Not all SIP trunks support RTCP and information generated by RTCP is limited, so if the Mediation Server is connected directly to the SIP trunk the information that can be presented in Monitoring Server is very limited. The SBC, on the other hand, provides additional information and enables full SLA and QoE monitoring toward the SIP trunk, without the need for dedicated quality monitoring probes to be deployed in the network. QoE / Bandwidth Based Routing The SBC can route calls to another SIP trunk or TDM interface (in the case of a hybrid SBC) based on the QoE, or based on whether the connection s bandwidth towards the SIP trunk is approaching the maximum available (CAC-based). Bandwidth-based Transcoding The SBC can offer the SIP trunk a low-bandwidth coder (such as G.729) if the consumed bandwidth is approaching the maximum permitted capacity (Mediation Server can only operate with G.711 toward the SIP trunk). This ensures that calls that would otherwise be blocked can be completed successfully. 5

7 4. Flexibility. Without stretching Stretching the network design to achieve optimal cost control, security, and flexibility is a common task in any IT organization. Migrating from existing infrastructure (IP telephony and/or PBX) and dealing with the ever-changing demands from internal customers and management often put the IT manager in a difficult position. Deploying an SBC will give you the flexibility you need to successfully manage your Lync migration and offer the broadest possible functionality without going over budget. An SBC enables the smooth interconnection of all the components within an enterprise IP telephony deployment (Lync, legacy PBXs, IP-PBXs, SIP trunks, PSTN), something that Mediation Server cannot achieve on its own. Migration While enterprises are keen to adopt Lync as a voice solution, more often than not they need to retain their legacy telephony system during the migration process, and possibly beyond. There may be several possible reasons for this, including: A gradual migration process poses lower risk than an overnight switchover - users can be moved over to the new Lync-based system in small groups making support and training requirements much more manageable The existing telephony system might support functionality which Lync does not support (e.g. call center) Legacy stations with only twisted pair access might still need to be supported within the new environment. Running both simultaneously enables any potential bugs to be identified early on without affecting the service The incumbent telephony system can be TDM based (with E1/T1 interface), or an IP-PBX with a SIP interface. In the migration phase, an SBC is essential to ensure a successful migration by offering the following: Full interoperability with different SIP-based IP-PBXs, allowing feature transparency with Lync Accurate call routing based on Active Directory queries Call forking to allow co-existence of legacy systems and Lync (both Lync and existing telephony phone will ring simultaneously) Number and CLID manipulation based on Active Directory - to allow calls between the existing telephony system and Lync, even when numbering conventions vary Support for redundancy: the SBC will call the user s mobile, if Lync is not available Fax routing Support for effective handling of E911 calls - providing adaptation between internal Lync location info and local switching conventions (ANI) SBCs that support hybrid SIP/TDM functionality can also be utilized for migrations from TDM-based PBXs. In those cases, additional functionality is essential such as: Full interoperability with the TDM PBX, over E1/T1 or analog interfaces with different signaling options (ISDN, QSIG, CAS) Fallback to the PSTN in case of WAN failure None of the above can be achieved when the SIP trunk is connected directly to the Mediation Server. 6

8 4. Flexibility. Without stretching (continued) Number Manipulation It is often necessary to perform manipulations on dialed and source numbers when connecting with other telecoms networks and systems that demand numbers in specific formats. Lync Mediation Server has limited capabilities performing number and name manipulations: Lync can only add prefixes and not suffixes Lync does not support name manipulations - required when connecting Lync to other IP-PBX or when an organization needs to modify the outgoing calling number When performing number manipulation, Lync can only remove numbers from left The SBC provides a very sophisticated and flexible manipulation mechanism which can handle all of the above. Call Routing between SIP Trunks The SBC enables routing between SIP trunks, based on different criteria such as called or calling numbers or host names. Mediation Server cannot connect to more than one SIP trunking service simultaneously. Least Cost Routing The SBC supports least-cost routing between SIP trunks and even to the PSTN. When connecting the SIP trunk directly to the Mediation Server, all routing and manipulation configurations are performed in the Lync Front End Server. Implementing an SBC enables the configuration of additional routing and manipulation in the edge device (SBC), providing improved flexibility. 7

9 5. Media? What Media? Lync carries your voice over IP and, just like everything else, the quality of the network affects the experience of the user. Due to its real-time nature, voice is even more sensitive to network conditions than most other applications. When Lync is connected to a SIP trunk, deploying an SBC is critical for guaranteeing a high level user experience. SBC provides you with all the media transcoding that you need and a lot more: Optimal Bandwidth The low-bandwidth G.729 codec is sometimes offered by ITSP as an option for reducing bandwidth demands over the SIP trunk. Mediation Server, however, only supports G.711 towards the outbound call leg. The SBC will perform G.711- to-g.729 media transcoding before the media hits the costly WAN interface. In addition, upon voice quality or network degradation, the SBC can automatically modify the transmission rate of the RTP stream toward the SIP Trunk. Media Bypass Support Without an SBC in place in a Lync environment, incoming media is terminated on Mediation Server together with the signaling. However, the high packet rate incurred by the media streams and increased CPU demands (due to media encryption and transcoding) severely limit the capacity of the Mediation Server. Deploying dedicated high capacity hardware or increasing the number of Mediation Servers are options but are costly. A more cost-effective and scalable solution, as recommended by Microsoft, is to use a mechanism known as media bypass. Media bypass is a functional implementation of Lync, in which the real-time voice media payloads are not carried through the Lync Mediation Server, but are rather sent directly between the communicating end points (i.e. clients, IP Phones, gateways, SBCs). Deploying Lync using media bypass is more cost-effective since it doesn t require a high capacity computing platform for the Mediation Server, it keeps the latency to a minimum, and guarantees optimum voice quality. The SBC with its transcoding capabilities and security mechanisms enables Lync implementations to be connected to SIP trunking operators securely and reliably using media bypass. Handling Fax Transmissions Lync does not support fax natively. The SBC can operate with the SIP trunk over T.38 or even V.34, and route fax calls directly from the SBC to an analog gateway connected to a standard fax machine. 8

10 Concluding Formula: $DoingTheRightThing < $Uncertainty + $Risk An experienced IT manager knows that sometimes the potential downsides of taking shortcuts outweigh the cost of well-designed deployments. The expense of an SBC is relatively small compared to the overall cost of designing, implementing and operating a Lync deployment. The decision to include an SBC is, therefore, a simple one, given the value it offers in terms of security, interoperability and quality. Just look at the CapEx of the equipment (not even counting any services and additional operational expenses). The cost of an SBC typically is 5-10% of the cost of the entire solution, and in networks where the traffic is consolidated through a data center, the cost of the SBC can drop even below 5%. We can illustrate this point by looking at two hypothetical Lync scenarios for an organization with 5,000 Lync users spread over 20 locations. In the first scenario, all outbound traffic is routed via a centralized connection to a SIP trunk provider. In this case, the costs in terms of licenses and equipment are as follows: CAL PLUS ($80 each) $400,000 IP phones ($150 each) $750,000 SBA ($5,000 each) $100,000 Total: $1,250,000 The addition of a centralized SBC supporting 1,000 sessions (based on a call concentration ratio of 1:5) adds another $32,000 to the overall cost. The SBC in this case is just 2.5% of the entire deal. In the second scenario, each office is connected independently to a local SIP trunk provider. The basic license and equipment costs are the same as before (totaling $1.25m). If we assume that each site requires an SBC supporting 50 sessions, the cost of adding SBC licenses to the existing SBAs will be $4,000 per site or $80,000 overall. In this scenario, the SBC part of the deployment is still only 6.4% of the total cost. 9

11 AudioCodes Mediant Session Border Controllers AudioCodes offers the broadest range of pure SIP and hybrid (SIP/TDM) SBCs available in the market. AudioCodes SBCs are fully certified by Microsoft for interoperability with Lync 2010 and 2013 and deliver secure and reliable SIP trunk connectivity for Lync deployments thanks to their: Common underlying code base Field-proven interoperability with 3rd party systems and networks Sophisticated SIP normalization capabilities Extensive security mechanisms High-performance media processing and transcoding Unified management interface AudioCodes portfolio of SBCs ( includes a highly scalable range of reliable, feature-rich devices that are suitable for the smallest locations, right up to large headquarters and enterprise data centers. In addition, as all the products are built on the same code base, seamless interoperability between the different locations is guaranteed. If you would like to find out more about AudioCodes offering for Lync including SBCs, IP phones, media gateways, survivable branch appliances (SBAs), applications and management, visit our website: or contact your AudioCodes representative AudioCodes Ltd. All rights reserved. AudioCodes, AC, HD VoIP, HD VoIP Sounds Better, IPmedia, Mediant, MediaPack, OSN, SmartTAP, VMAS, VoIPerfect, VoIPerfectHD, Your Gateway To VoIP and 3GX are trademarks or registered trademarks of AudioCodes Limited. All other products or trademarks are property of their respective owners. Product specifications are subject to change without notice. 10