SIP Trunking and E-SBCs For All Forms of UC – It’s Not Just Voice Any Longer

SIP Trunking and E-SBCs For All Forms of UC – It’s Not Just Voice Any Longer

By Stephen Leaden November 6, 2014 3 Comments
Stephen Leaden PNG
SIP Trunking and E-SBCs For All Forms of UC – It’s Not Just Voice Any Longer by Stephen Leaden

Introduction

SIP trunking is a “hot” industry trend and has been so for 24+ months now. I liken and envision SIP trunking similar to the disruption and transformation that took place when moving from legacy TDM digital IP-PBXs to IP-based Unified Communications. That disruption took, in my opinion, longer than expected because of the disruption and move of voice communications from facilities infrastructure to IT, and VoIP now integrated to the data network and the “headache” and unknown factors now associated with real-time communications running on the data network.

Now that we have crossed that threshold in time, it is now the carriers’ turn to move their networks to a full IP-based infrastructure. Carriers have been providing IP-based networks for decades now, and SIP trunking now includes a QoS standard not experienced in a non-QoS-based data network or Internet access. Think of SIP trunking as a public-side MPLS network.

SIP Trunking Benefits

SIP trunking is transformational, and in my opinion we are in an early adopter stage of a major shift away from traditional PRI trunking to SIP trunking. The benefits are significant:

  • Significant Cost Savings for An Organization – our experience has shown anywhere from 20% to 60+% annual savings leveraging SIP trunking

  • High Availability and Redundancy – SIP trunking must be high availability to work, with an active/active solution for best practice purposes. High availability means better network uptime

  • Centralizing DID Numbers Nationally To A SIP Trunk Group – SIP trunking carries a Direct Inward Dial/DID centralization feature-set: for most DID numbers (outside “Mom and Pop” telcos) you can port all DIDs nationally into one centralized trunk group. For example, we have a client who has offices in Washington State and those numbers have been ported and now reside in a centralized SIP trunk group in Florida. Inbound public-side calls originating from Washington area are routed to the SIP trunking group in Florida and traverse the internal WAN to get to the desktop in Washington. To outsiders locally in Washington calling in, the call appears to be “local.” For outbound originated calls from the Washington office to a local Washington number, calls start at the desktop, traverse the WAN then out the SIP trunk. Because geography now becomes a non-issue, a single area code philosophy can also be employed.

  • Reporting – Better SIP trunking carriers provide real-time reporting of the network, including bandwidth utilization, QoS characteristics, latency, jitter, packet loss, providers.

SIP Trunking is Complex, and Some Best Practices

Make no mistake – SIP trunking is complex and requires best practices for design and deployment. Some of those include:

  • SIP Trunking Testing and Acceptance. SIP trunking designs and implementations are complex. Ordering and delivery of SIP trunking can be fairly straightforward, however, a rigorous test and acceptance procedure around call sampling, QoS parameters, and failover testing should be developed and followed. We have developed such a test procedure for our clients and these procedures have been very effective in preventing issues before they occur in a full production environment.

  • Redundancy. Redundancy here is on multiple levels, including:

    • Redundant trunking is critical (2 -3 SIP trunks at different locations)
    • Redundant local loops
    • Redundant enterprise E-SBCs
    • Redundant edge routers
    • Redundant QoS-based WAN connectivity to each remote site
    • Back-up PRIs and POTs lines at remote sites facilitates that cushion should a hard SIP trunking or WAN outage take place.
  • Diversity. Best practices for SIP trunking requires as much diversity as possible, including:

    • Diverse Central Offices
    • Diverse routes “under the street” to the building from the Central Office
    • Diverse local loops from different providers
    • Diverse risers within the building
    • Diverse SBCs in the Central Offices
    • Carrier Diversity – more detail below

  • Carrier Diversity. Having a prime and a back-up carrier provides a level of diversity to ensure that if one carrier’s network is regionally or nationally “down” (yes, we seen it), a back-up carrier can be another source for outbound calling. We also leverage strategies to temporarily “port” DID numbers to a back-up carrier with minimal disruption of the enterprise users. As carrier SLAs are typically measured at a three 9s reliability model (99.9%, or 8 hours of downtime annually), one can expect a circuit (and possibly a regional outage) periodically.

  • Plan for SIP Trunking Growth for 2-3 Years Out. Any enterprise should plan for SIP trunking growth 2-3 years out and should include bandwidth available for all voice communications, audio conferencing and collaboration, mobile communications, and video communications, as well as growth planned for through Mergers and Acquisitions, industry and corporate growth, and other drivers for growth. More on SIP trunking and UC in a moment.

  • SIP Trunks Across Wide Geographies. QoS-based IP networks domestically typically carry minimal latency today, thus the idea of having SIP trunks dispersed across wide geographies can be introduced. For example, one SIP trunk can terminate in NY metro and the other SIP trunk terminate in California. Should a hurricane, other weather-related activity, or an electrical blackout take place in a regional area, the chances for the same outage occurring in a different part of the country can essentially eliminate the chances for an entire organizational outage.

  • Ability for the Carrier to Provide T.38 Fax Protocol. Faxing over IP is also complex and in most cases requires the T.38 protocol enabled to support such.

  • Real Time Network Reporting and Analytics. Understanding and seeing the “health” of the SIP trunks at any one point is critical. We expect any SIP trunking carrier to provide this capability, and thus real-time monitoring can be a part of the ongoing monitoring by IT staff.

  • WAN QoS. A SIP trunking centralized model “rides” the internal WAN, and all public side SIP trunking comes into a multi-site customer on the public side, however, all inbound and outbound calling to and from any of the branch or satellite locations must traverse the Wide Area Network in place. Rules for redundancy to all these locations must now consider all public side voice traffic traversing the WAN. WAN QoS policies must be turned on enterprise wide to ensure the quality of the communication enterprise-wide.

  • Bandwidth Up To 70-80%. SIP trunking carries primarily QoS-based traffic and little need for prioritization over data, and therefore voice quality will begin to degrade as the circuit volume fills beyond that threshold.

  • Dynamic Bandwidth. This feature/function is gaining ground nationally. The ability to add additional SIP trunk bandwidth and channels “on the fly” in the event of disasters or required public-side broadcast creates an opportunity to increase the available bandwidth and channels necessary during a seasonal variation or normal-vs.-emergency state period. Most carriers offer an immediate or fast ramp-up option and will not charge the customer for additional SIP channels until utilized.

  • Have a Temporary DR Plan In-Place for Change Control Purposes. Carriers have to upgrade and update software patches in routers and SBCs regularly. Your enterprise should receive adequate notice for such a change, typically performed during a low third shift period. Having a temporary DR plan in place in the event any network change fails and knocks out a regional area will help minimize any downtime experienced.

  • Determine if Carriers Can Direct DID Numbers to any of their SIP Trunking COs in an Active/Active State. Some carriers offer a full active/active “state” for all DID numbers, providing the ability to push DID numbers to either of the SIP trunking-associated Central Offices, while legacy designs force enterprises to choose or split DID groups to different Central Offices. The former is clearly the better choice if available.  

SIP Trunking – Not Just for Voice any Longer

The BIG news is that, because SIP trunking is native IP, QoS-based, and public side, SIP trunking now becomes the going-forward strategy for all forms of UC transport on the public side, including:

  • Voice over SIP - Remains (and will remain) the most common reason why enterprises will introduce SIP trunking in their organizations.

  • Video-Over-IP - SIP trunking is video-ready, and SIP trunking, together with E-SBCs, can be leveraged for QoS-designed videoconferencing (desktop or room-based, premise-based or cloud-based), different than ISDN dial up capability. H.323, H.264, and T.120 CODECs are available on SIP trunking and in SBCs for video-over-SIP. I believe that video growth will be the next “BIG THING” in 2015 and preparation for such growth and use for any enterprise is crucial. Video bandwidth exceeds voice bandwidth typically by a factor of 12 (1Mb+ for HD-quality video compared with 85k for G.711 or G.722 HD non-compressed voice CODECs).

    Why does Video over SIP trunking make sense for public-side video conferencing? QoS-based video traffic is one significant reason – Internet public side is only best effort and provides no QoS. E-SBCs can also help normalize SIP idiosyncrasies from the carrier to the enterprise side and will help facilitate video “routes,” when required, using Session Management. Video traffic can also be measured and reported on by the same E-SBCs.

  • Mobility - All “one number reach” mobility traffic that includes a mobility component should leverage SIP trunks both inbound and outbound to the smart device. This way, QoS is ensured on SIP for all mobile calls and can be tracked and measured on via E-SBC traffic reports.

  • Web-based Audio Conferencing and Collaboration - Again SIP trunking will guarantee QoS-based traffic over SIP as opposed to traversing the Internet for non-QoS-based traffic. Again, E-SBCs can manage traffic elements and statistically report on mobile-related traffic.

  • SIP Trunking is a Perfect Venue for Federating - As SIP trunking is IP and QoS ready, SIP trunking can be used for off-site remote users, softphones, mobile users, and Federated partners. Again, E-SBCs can help measure various traffic types, secure the connections, and provide session-management functions that will facilitate traffic flows among multiple forms of UC.

  • IM/Chat, Presence - Because E-SBCs can ensure secure and can measure traffic types, IM/chat and presence functions should also be considered via SIP trunking.

Conclusion

SIP trunking is complex, and many of the best practices and SIP trunking for all types of UC cited in this post should provide insight to the complexities and best practices around SIP trunking. As SIP trunking continues in the “early adopter” stage of deployment and is in the process of going fully mainstream, we have experienced maturity issues with some of the carriers, having unexpected errors during change windows. By leveraging a best practices approach, an enterprise will be able to deploy SIP trunking confidently and begin to leverage multiple forms of UC over SIP trunking as the organization’s UC needs and implementation requirements grow.

 

3 Responses to "SIP Trunking and E-SBCs For All Forms of UC – It’s Not Just Voice Any Longer" - Add Yours

Gravatar
Kevin Kieller 11/10/2014 10:59:48 AM

Good article Stephen.

Readers should keep in mind that with Lync the SIP only participates in calls to and from the PSTN. All federated communications go through the Lync Edge server. For more information about SIP and SBCs and Lync see: http://www.nojitter.com/post/240169234/living-with-lync-where-the-sbc-fits-in.

Kevin
Gravatar
Steve Leaden 11/11/2014 8:51:42 AM

Thanks Kevin for your comments. For Lync-only UC Federation, I think your comments apply. If considering UC Federation to non-Lync users (other manufacturers) and using 3rd party integration such as NextPlane, for example, I would think that SIP trunking and UC Federation still applies.

Thanks again for your comments - appreciated Kevin.

Steve
Gravatar
Kevin Kieller 11/12/2014 10:44:02 AM

Steve,

Nope. Federation from Lync to other non-Lync platforms, whether via the Lync XMPP or via NextPlane, all flow through the Lync Edge Server and do not involve SBCs or SIP at all. If you have already deployed you Edge server or servers, adding the federated scenarios features is straight forward. If you have not set up Edge Servers, you must do that first.

Kevin

To Leave a Comment, Please Login or Register

UC Alerts
UC Blogs
UC ROI Tool RSS Feeds