Enterprise SBCs: Why They're So ImportantEnterprise SBCs: Why They're So Important

Session border controllers provide security, but their value to the enterprise goes much deeper--they can help you unify dial plans and tie together legacy elements.

Enterprise Session Border Controllers or E-SBCs provide a simple and manageable way to deliver strong security boundaries between enterprises and carriers when deploying SIP trunks. E-SBCs can also provide substantial benefits well beyond security, especially when bundled with Session Management. Session Management describes an evolving set of capabilities that provide E-SBCs with, among other things, the ability to manipulate dial plans, allowing organizations to deploy SIP trunks without the need for wholesale overhaul of their dial plan. In addition, Session Management within E-SBCs offers the ability to address SIP interoperability challenges by providing administrators with tools to modify and normalize SIP traffic between vendors' systems.

With Session Management, enterprises can consolidate their dial plan and eliminate complex routing configurations across multiple PBXs and platforms. This ultimately sets the stage for the adoption and migration to large scale carrier-provided SIP trunks for carrying voice and other media including video.

We'll explore a few of the benefits and tricks in more detail in the following article.

Normalizing Dial Plans
Normalizing a dial plan can be complex and the options limited when the enterprise is attempting to connect and integrate legacy PBXs. Many legacy PBXs have limited support for how digits can be manipulated, or may simply limit the number of digits allowed. Likewise, many legacy carrier trunks have been configured to accommodate these limitations by passing a subset of the digits dialed when forwarding a call to an enterprise PBX.

In addition to providing a security boundary between your enterprise IP Telephony deployment and carrier networks, an E-SBC can also be used to normalize your dial plan as well as manage call delivery to multiple destinations through Session Management. In a centralized deployment model, the E-SBC can manipulate digits from multiple sources and provide a relatively simple and low-risk option for transition to an enterprise dial plan.

Consider a case in which you are configuring the E-SBC to normalize calls routed to a legacy PBX via a SIP trunk. In this case you could deploy an e.164 dial plan at the enterprise level while preserving a 4- or 5-digit dial plan for legacy PBX deployments. You could deploy the E-SBC to terminate a SIP trunk that is replacing a legacy PRI: In this case your legacy PBX may have been configured with a 5-digit dial plan and your previous provider was only sending you the last 5 digits of the called number. In the new SIP configuration, you could have the SIP provider send you the full e.164 number (11 digits in the case of North America Numbering Plan, NANP) and have the E-SBC strip the first 6 digits when it forwards calls to the legacy PBX. As a result, you remove the need for any reconfiguration of the legacy PBX while positioning yourself to integrate and transition to a new IP PBX or Rich Media solution like Microsoft Lync. By using this approach you align the enterprise to a common dial plan, and by using an e.164 dial plan you guarantee against any number overlap.

Next page: Illustrating the Scenario

The figure below illustrates this scenario. We are able to support the legacy PBX by normalizing the dial plan to the original dial plan, while introducing a new element of the dial plan to support the implementation of Lync into the voice environment. Both the legacy and new environments are able to take advantage of the same SIP trunk provided by a centralized carrier, which can result in substantial cost savings as well.

Looking at the figure in detail, it shows that in this example, if you are creative when selecting your new dial plan for Lync, you may also be able to preserve 5 digit dialing across both environments (legacy and new). In the case below, users in the legacy environment would be able to 5-digit-dial the Lync user by using 3-2122, as long as the leading digit, 3, is unique in the legacy environment. This would require modifying the route plan on the legacy PBX in this case.

On the Lync side, users would simply click to dial legacy users. Lync in turn would send the full e.164 number to the E-SBC, and the E-SBC would route the number to the legacy PBX after stripping the first 6 digits.

UDP vs. TCP with Lync
Microsoft Lync continues to gain adoption as a viable augmentation or alternative to traditional IP Telephony deployments. By migrating to Lync, enterprises can not only move away from the limitation of their legacy PBXs but can also take advantage of full rich media capabilities including, voice, video, messaging and desktop collaboration.

Migrating to Lync also provides an enterprise with the ability to eliminate separate hard phones. With Lync, users can escalate communications from IM to voice or video with just a few simple clicks without the need for a separate application or physical phone sets.

Lync provides many of the key features found in traditional PBXs and offers a simple and affordable way to integrate with existing telephony without the need for full rip and replace. But while Lync integrates well with enterprise telephony, it can be a challenge when integrated with carrier SIP trunks.

Many carriers require the use of UDP (connectionless-based) instead of TCP (connection-based) when deploying SIP trunks to an enterprise. UDP does not require the same overhead and processing burden found with TCP, and as a result can scale much better in large deployments. This is the primary reason carriers only support UDP. However, Lync uses TCP rather than UDP.

To address this challenge, an E-SBC can be deployed in between carrier SIP trunks and Lync. The E-SBC can be configured to terminate connections from the carrier using UDP while terminating the SIP connection from Lync using TCP. The E-SBC will in turn proxy sessions between the carrier and your Lync environment.

Next Page: SIP Early Offer vs. Delayed Offer

SIP Early Offer vs. Delayed Offer
Another key benefit of many E-SBCs is their ability to manipulate SIP packets during call setup. This helps address inconsistencies in how vendors have implemented the SIP standard. One specific area that has been problematic in the past is SIP Early Offer vs. Delayed Offer.

Early and Delayed Offer refers to the point at which the capabilities of a call negotiation are presented in a SIP exchange for call setup. With Delayed Offer, the calling party does not send capabilities (e.g., "I can do G.711 or G.729 encoding") in the initial SIP INVITE packet, but waits for the called party to respond with the offer of capabilities. This approach allows the calling device to choose the codec to use for the session once the capabilities are received from the called party.

In contrast, with Early Offer, the calling party sends the capabilities in the initial SIP invite. This approach allows the called party to choose the preferred codec.

Many carriers only support Early Offer because they want control over codec selection. Unfortunately, this presented issues for earlier implementations of Cisco Unified Communications Manager, CUCM. To support Early Offer in older CUCM deployments, you were forced to route all signaling and media traffic through one of the CUCM subscribers (i.e., one of the call control servers), since a software Media Termination Point was required. The result was a less-than-efficient call path as well as limited deployment scalability.

To address this issue, an E-SBC can be used to modify SIP packets in the call setup exchange. In this case you configure the CUCM SIP trunk to use Delayed Offer and have the E-SBC convert the call setup exchange to Early Offer. The E-SBC does this by adding the capabilities to the initial SIP invite and including the codec offer (G.711, G.729, etc). As a result, CUCM can be configured for Delayed Offer, resulting in unpinning of the media path from the subscribers. The end result is a more efficient and scalable deployment.

Next Page: Addressing Fax Issues

Addressing Fax Issues
Faxing has been an issue that has plagued IPT deployments since the beginning and continues to be problematic with carrier SIP trunks. Newer protocols like T.38 help address this issue, but not all implementations support T.38.

Without T.38, you are forced to use fax-over-IP and rely on higher-quality and higher-bandwidth codecs like G.711. Unfortunately, not all IP PBXs can accurately select and guarantee the proper codec in this case, especially if your deployment includes support for multiple codecs.

The main challenge is how a fax call is detected. With legacy TDM implementations, fax tones could be detected after the initial call goes off hook and thus be redirected to a fax machines. This had the benefit of allowing administrators to mix fax machines into the same dial plan as subscriber phones.

With SIP, the codec is selected prior to the call being established (going off hook at the receiving end), which potentially clashes with the requirement that the called party must determine if this is a voice or fax call before that called party can go off hook.

With inbound calls from the carrier, this problem can often be solved by configuring your fax numbers/devices in unique regions on your PBX that only allow G.711 (If your PBX supports this kind of dial plan configuration). Since this is Early Offer, the called party (i.e., your IP PBX/fax machine in this case) selects the codec, and with this configuration, it would select G.711 by default.

For outbound it becomes more complex. Some IP-PBXs make it difficult to force a specific codec on outbound calls to a carrier because again, with SIP Early Offer, the carrier selects the codec for calls offered by the enterprise PBX.

One way to address this challenge is to simply convert your enterprise to G.711. This would certainly simplify your design, but substantially increases your bandwidth consumption and WAN costs. Another way to address this is to let the E-SBC manipulate the capabilities during the call setup exchange, and only offer G.711 as the codec for fax calls. This requires you to uniquely identify fax numbers in your enterprise within the E-SBC. The easiest way to do this is to assign fax numbers in contiguous blocks and configure the E-SBC to modify the capabilities based on this new range.

However, if you're like most enterprises, your dial plan is not that clean and you have fax numbers intermixed throughout the dial plan. In this case, you could use your IP-PBX to prepend specific digits to dedicated fax numbers on outbound calls.

For example, let's assume you have your IP PBX prepend 003 to the front of the calling party for outbound calls placed from fax machines. Once you've done this, the E-SBC can simply match on any calling party field that starts with 003. In turn the E-SBC would modify the capabilities during call set up and remove all codecs being offered except G.711. In addition, the E-SBC would strip the prepended 003 from the calling party number to return it to an e.164 format before forwarding it onto the carrier. This ensures that only G.711 is selected as the codec for the call.

Conclusion & Wrap Up
Enterprise Session Border Controllers with Session Management are essential tools for enterprise SIP deployments. Regardless of your enterprise size, E-SBCs provide substantial benefits well beyond simple security, especially when bundled with Session Management.

The ability to manipulate dial plans allows organizations to ease into SIP trunk deployments without wholesale overhaul of their existing dial plans. And addressing SIP interoperability challenges is one of the key benefits administrators can take advantage of, with tools that modify and normalize SIP deployments between vendors. With Session Management, enterprises can consolidate their dial plan and eliminate complex routing configurations in multivendor PBX and platform environments.

The future of this space is changing rapidly, and enterprises that position and deploy well thought out SIP strategies will bring substantial cost savings and competitive advantage in the long run.

Jim Allen has several years of experience with architecture, design and deployment of network and collaboration technologies. In his recent role he has been instrumental in the adoption and deployment of collaborative technologies including voice, video and web collaboration within the medical device industry. In addition, he has been lead architect for carrier SIP trunk deployments leading to substantial operating cost reduction, increased communication flexibility and stronger competitive advantage. During his 30-year career he has worked for several Fortune 500 companies as well as working as an independent consultant. He is currently on the technical advisory boards for three leading collaborative technology manufacturers.