Leveraging Industry Standards for Success – A Case Study

Telecom is an example of an industry that has created national and international standards for communications in ways that benefit companies large and small. As a consultant, I’ve frequently advised companies about specific standards and how they can be aligned with business strategies. Let’s consider an example.

During the last 15 years, facsimile communications has been dramatically affected by technological forces.  The circuit-switched network is being replaced by IP networks throughout the world, as I noted in a previous post.  As a result, all fax communications company have had to develop a strategy for the transition to IP. The vendor community anticipated this in the late Nineties and key new standards for sending fax messages over IP were developed by the Internet Engineering Task Force (IETF) and the International Telecommunications Union (ITU). The IETF focused on integrating fax with Internet email and the ITU split its efforts between supporting the IETF Internet Fax standards by reference (T.37) and devising a new standard for real-time fax communications (T.38).

Standards adoption often takes time and such was the case for IP fax. There were some early adopters of the email based approach (for example, Panafax and Cisco), but despite backing by both the ITU and IETF, the market didn’t take off. One big reason was the emergence of voice communications over IP (VoIP), primarily based upon the IETF’s Session Initiation Protocol (SIP), which gained increasing momentum during the first decade of the 21st century.

Several of us in the ITU and IETF took a small but critical step which allowed T.38 IP fax to ride this wave. In the year 2000, we completed an annex to T.38 which specified how it could be used with SIP.  As a result, when implementors wanted to add fax support to their SIP-based Voice over IP solutions, the steps required to enable a Voice over IP session to spawn a T.38 fax session had already been specified in a T.38 annex. During this same period, Voice over IP gateways were emerging as the preferred approach to connect the existing circuit-based network to the emerging IP network based on SIP. Cisco and other gateway manufacturers such as Audiocodes and Cantata (later renamed Dialogic) cut over to T.38 as their favored solution to support fax over IP.  The fax board manufacturers such as Brooktrout (later Dialogic) followed suit and T.38 became the most widely adopted solution for Fax over IP.  The use of T.38 for IP fax was also supported by the Third Generation Partnership Project (3GPP) for 4th generation mobile networks and by the SIP Connect initiative for SIP Trunking driven by the SIP Forum.

When I was advising my fax industry clients in the late Nineties, I suggested they keep a close eye on the trends in both fax over IP and Voice over IP in deciding upon their product directions. At this time, the IETF standards for Internet Fax via email got early momentum, but in the standards community, we kept working on both the email and real-time IP fax solutions. As noted above, the step of ensuring that T.38 could eventually be used with SIP in a standards-based solution became very important as Voice over IP became a much bigger industry trend than Fax over IP.  As a result, fax solutions that would work over the emerging voice over IP networks became successful and are still being sold by many communications vendors today. The story didn’t stop there. There are other important trends that have emerged in recent years such as the needs for enhanced security and the transition from physical products to software-based solutions in the Cloud that communications vendors need to bake into their strategies going forward.

If you have been in business scenario where leveraging industry standards helped your company’s products gain success, please feel free to weigh in with your comments. If you’d like to explore strategies on how to evolve your company’s solutions and leverage current or potential industry standards, you can reach me on LinkedIn or on our web site.

Advertisements

More Business Disruption: Telecom’s Move to IP

In the late Nineties, the Telecom business was dominated by big companies who had built their phone network over many years using switching technology. But a massive storm was on the horizon as the same IP technology which helped revolutionize commerce on the world wide web started to be applied to phone-based voice communications. Early attempts at Voice over IP were primarily targeted to the long distance market. International long distance calling was expensive, so a number of startups began to bypass the traditional long distance network with a much lower cost IP network. The quality wasn’t great, but the price per call over international routes dropped dramatically and IP infrastructure and solutions gathered momentum.

The early leader in IP protocols for voice was the H.323 protocol developed within the traditional standards group for phone networks, the International Telecommunications Union (ITU). But competitive protocol models were also on the rise. The Internet Engineering Task Force (IETF) developed a new IP communications protocol, the Session Identification Protocol (SIP) and both the IETF and ITU worked on a softswitch protocol called Megaco (later standardized by the ITU as H.248).

Around 2001, two important organizations endorsed SIP and the train which would ultimately displace much of the traditional switched phone network was set in motion. Microsoft had been an early user of H.323 and had added it to their instant messaging client support and included multi-point data sharing using T series protocols from the ITU. But Microsoft decided their future communications would be SIP-based and quickly phased out use of H.323. Then, the Third Generation Partnership Project (3GPP), a standards group which had specified the very popular second generation wireless protocol GSM, said that they would be using SIP to build their next generation network and shift both data and voice services over to IP.

But first, the core SIP protocol needed to be finished. IETF participants likely spent millions of manhours and devised an updated version of SIP which got standardized in June, 2002 as RFC 3261, along with 4 other RFCs for related methods and operations. But this was just the beginning. In the time since, the IETF has produced at least 100 SIP-related documents which are either standards track or informational to guide SIP developers.

On the business side, it took quite a while, but the current public phone networks have largely cut over to IP, although there are still elements of the switched network in place.  In the world of mobile communications, the fourth generation network specified by 3GPP was the first to use SIP in its core. The related Long Term Evolution (LTE) network has been deployed throughout the world, although the voice portion of the network (Voice over LTE) has lagged behind. The move to LTE and SIP has required a massive investment in new capital equipment and software by mobile service providers and most of that deployment dates from about 2012. On the business side the industry has experienced lots of turmoil during the period between 2001 and 2012.  One of the biggest equipment vendors, Nortel, declared Chapter 11 and chunks were sold off to other companies before the company went out of business. Many of the remaining vendors have gone through multiple mergers and acquisitions, greatly reducing both the number of telecom related companies and the number of employees.

The other major SIP endorser from 2001, Microsoft, has shifted its IP voice communications strategy numerous times, but one of it’s flagship offerings,  Skype for Business, is predominately based on SIP.  Microsoft’s use of SIP is primarily within enterprises, though they have also been a strong advocate of SIP Trunking, which enables enterprises to connect to the service provider IP phone network. In the meantime, Microsoft has many competitors in the enterprise voice and communications space, but SIP remains a dominant technology. Vestiges of circuit-based phone systems remain, but all of the major players have long since switched their current product and service offers to be IP-based.

IP and SIP are doing well, but voice is now a much smaller portion of the communications business and service providers make much of their money from data services. The era of premise-based equipment is also winding down, as the shift to IP has enabled companies to move both service provider and enterprise applications to the massive conglomeration of servers known as The Cloud. I’ll be writing more in future posts about lessons learned from the Telecom move to IP and on how the move to the Cloud is also causing major business disruptions.

If you or your company participated in the Telecom move to IP, feel free to weigh in with comments. If you’d like to explore strategies on how to evolve your application solutions or other products and services to in the face of rapid business and technical change, you can reach me on LinkedIn or on our web site.

 

Reshaping Enterprise Communications: A Tale of Two Companies

In my last few posts, I’ve described several factors which have encouraged communications solution providers to transition away from hardware and focus on software-based application solutions.

Let’s consider two companies and how they adjusted the path of their technical and business models to address these directions. Avaya is an example of a company whose solutions had a substantial amount of proprietary hardware around the time they split off from Lucent in the year 2000. Avaya had a leading market share in multiple markets targeted to enterprises, including PBXs, which provided telephone infrastructure for enterprises, and Call Centers, which used Avaya components to meet customer needs for highly scalable inbound and outbound communications. But the advent of IP-based technology and new protocols such as SIP began to change all of that. The mantra of IP-based communications was that voice was just another application that ran on an IP stack. This massive technical change was a major challenge for Avaya, since they’d built their business based on selling PBX and call center solutions based on their own hardware, but the cost of sustaining this business model was high. So starting around 2002, they executed a pivot to adjust to the new situation. First, they introduced new IP-based versions of their PBX technology ranging from IP phones to an IP-based PBX and a suite called IP Office for small to medium sized businesses. In parallel, they told potential partners that they wanted to move out of the hardware business and focus on value provided by their software. Third, they created a partner program, the Avaya DeveloperConnection program (later shortened to DevConnect), and encouraged partners to either build on or connect to Avaya solutions. As a result, Avaya was able to cultivate relationships with hardware appliance companies for products like media gateways and focus more on building out their application software. The DevConnect program also fit well with Avaya’s increased role as an integrator. Solutions for customers could be built using not only Avaya technology, but also DevConnect certified products. So Avaya had an approach to building out software-based solutions using IP, but they also had a large installed-base of hardware-based solutions, so they were not as nimble as some of their competitors.

The advent of SIP helped to encourage new market entrants into the communications software space. A prominent example was Microsoft. Starting around 2007, Microsoft introduced it’s new communication solution, Office Communication Server 2007 or OCS.  OCS used SIP as its backbone protocol and touted the ability for enterprises to eliminate the cost of a PBX and replace it by software running on Commercial Off the Shelf (COTS) servers. Enterprises still needed to connect to the telephone networks run by service providers, which were heavily based on circuit-switched technologies, so Microsoft started its own partner and certification program to qualify 3rd party products such as media gateways. Microsoft also had a lot of marketing muscle, since their applications such as Microsoft Office were widely used within enterprises, so they had a ready audience among the information technology managers at customers. In 2010, Microsoft -re-branded their offer and called it Microsoft Lync. Microsoft quickly became a big player in the new Unified Communications market and began to take market share away from traditional PBX vendors such as Avaya. Microsoft also continued to be aggressive in cultivating relationships with 3rd party hardware partners, who added support for Lync compatible IP phones and newer IP-based products such as Session Border Controllers (SBCs). Microsoft has since re-branded Lync to be Skype for Business, but the underlying technology and business model is an evolution of Lync.

The market battle for leadership in communications for enterprises continues, but the momentum has shifted heavily to software-based solutions and most hardware components are provided by other vendors. One exception to this direction is Cisco. They have maintained a strong presence in the hardware side of communications by virtue of their leading market position in routers and have incorporated additional functions such as media gateways and SBCs upon their routers. However, Cisco also has built their own software-based Unified Communications suites and Contact Center solutions, so they use the software-based applications model, but pair it up with Cisco network components to create their solutions.

In summary, the advent of SIP is one of several factors which have radically changed the landscape for communications solutions. In this post, we’ve considered how Avaya and Microsoft built their business strategies based on the strong move to IP-based software solutions over the last decade. In my next post, I’ll talk about another important technology development, virtualization, which is in the process of re-shaping how both application software and communications infrastructure products are being developed and brought to market today.

If you participated in the evolution described here, please feel free to weigh in with your comments. If you’d like to explore strategies on how to evolve your application solutions or other communications products, you can reach me on LinkedIn.

 

How IP Media Changed the Voice Business

This post is about a critical technical development in the history of Voice over IP which had a wide-reaching impact on the development of voice and related communications solutions. I’m referring to IP media, which was introduced early in the 2000s and has been ramping up every since.

In my last two posts, we discussed two important technologies which were instrumental in the early and middle years of voice-based solutions. The first post covered the introduction of voice boards and the second post reviewed the impact of media gateways on voice solutions.

On the business side, the introduction of media gateways provided a stepping stone which encouraged the pioneers of Voice over IP and other voice solution providers to decide where they offered the most strategic value to their customers.  In particular, should they focus on applications or upon enabling technology which could either complement applications or be used to build underlying infrastructure. The introduction of IP media pushed companies further down this decision path.

Two directions emerged. Several manufacturers of voice boards began to kick the tires on creating software-based versions of their voice boards. In the post on voice boards, we noted how control of voice and media functions was controlled using Application Program Interfaces (APIs) and that private APIs tied to particular vendor product families gained much more market traction than attempts at standards-based APIs. Hence, an early product in the space, Host Based Media Processing (HMP) from Dialogic®, offered the value proposition of being software-based, but was still controlled using the same set of APIs that were used with Dialogic voice boards. In parallel, another movement emerged. Two startup companies, Snowshore and Convedia, introduced a new category of product called the Media Server. In the last post, I mentioned how the Session Initiation Protocol (SIP) started to gain traction early in the 2000s. The Media Server concept took SIP as a starting point and added the ability to manipulate media by using a markup language, which was typically based on the  Extensible Markup Language (XML) recently standardized by the World Wide Web Consortium (W3C). The implications were profound, both on the technical and business sides, but like many new innovations, the transition to using this new approach took many years to develop. For example, by the time Media Servers truly hit the mainstream, the two originating companies had both been acquired by larger organizations who were able to make the needed capital investment to build sustainable businesses for media servers.

Of the two approaches, IP Media controlled by APIs essentially was an incremental development and IP Media managed by Media Servers introduced radical change. Let’s consider why this was the case. IP Media controlled by APIs retained the API-based model for control of media. For existing voice application developers, this was great.  They could start the transition away from including voice board hardware in their solutions and thus vastly simplify their go-to-market strategies. As a result, many voice application developers now raised the flag and said they were now out of the hardware business and their solutions were totally software-based. In reality, this typically meant their application software would run on industry standard Commercial Off the Shelf (COTS) PCs or servers using Intel or compatible CPUs such as those offered by AMD. But by using IP Media, the solution providers could skip the step of adding voice boards to their computer-based solutions and eliminate all of the complications of integrating 3rd party hardware. They did have to be careful to have enough CPU horsepower to run both their applications and IP media software, but it represented a major step forward. Voice and multi-media application solutions had now become a separate business in the Voice over IP market.

I mentioned that the introduction of the IP-based Media Server was a more radical step. So, I’ll review a few points to back up that assertion.

  1. The need to have a private API controlled by a single vendor went away.  The new concept of “the protocol is the API” replaced the programmatic approaches which had required developers to use programming languages such as C, C++ or Java for media operations. Instead, simple operations like playing back voice prompts or collecting digits could be accomplished using the combination of SIP and an XML-based markup language, thus eliminating the need for a programmatic language to carry out these operations.
  2. The application developer could focus clearly on making their applications best-of-breed and partner with media server vendors, who would focus on creating world-class voice and multimedia solutions.
  3. The application developers no longer needed to include media processing in their applications at all, thus reducing the CPU cycles needed for those media operations, However, the application developers did need to partner closely with the media server vendors and ensure their SIP + XML commands would work correctly when issued over an IP network to the paired media server.
  4. The concepts of the standalone application server and the standalone media server got included in the new IP Multimedia Subsystem (IMS) architecture, which was being standardized by the Third Generation Partnership Project (3GPP) as a linchpin for the next generation of mobile networks.

So the move toward IP Media was a major step forward for the Voice over IP industry and encouraged further market segmentation. For the first time, companies could specialize in applications and include the ability to support voice, tones and other multimedia, and do all of this in software which would run on industry standard COTS servers. In turn, hardware component and appliance vendors were able to focus on more distinct market segments where they could utilize either embedded solutions technology or start making the move toward running  media on COTS servers.

In my next post, I’ll talk more about how the business models for voice and unified communications solutions have evolved due to the more wide spread use of server and appliance based technology for applications, signaling and media.

Impact of Media Gateways on Voice Solutions

This is the latest in a series of posts on how voice development has been moving from hardware to software centered models. In my last post, we reviewed the classic approach to developing voice-centered solutions, which typically utilized voice boards. In this post, I’ll review how media gateways helped change the model.

In the classic voice model, the voice board often was used both for voice processing and to connect to a phone network, which might be either digital or analog. When Voice over IP (VoIP) began to emerge, new options became available for voice solutions. In the early days of VoIP, the H.323 stack was used to connect to IP networks, but the Session Initiation Protocol (SIP) got some crucial support in the 2000-2001 time frame from Microsoft and the Third Generation Partnership Program (3GPP), the leading standards organization for mobile phone networks. Within a few years, voice developers began to add SIP to their development capabilities. This had multiple implications.

Let’s look at some business side drivers. After the dot com crash and the related “Telecom Downturn,” which decimated the ranks of engineering staffs of the large vendors known as The Equipment Manufacturers (TEMs), these companies were looking for ways to reduce the amount of hardware in their solutions. In the classic voice solution, the voice board processed media and also connected to the circuit-switched networks. When SIP became popular, many of the TEMs started saying they wanted to move away from the hardware business. Some of these companies started processing media as part of their voice applications and others continued to rely upon voice boards for this processing.  In either case, if they outsourced the connection to the network to another box, they could reduce the number of hardware dependent elements in their solution and simplify the process of building and shipping their solutions.

Enter the Media Gateway. As the application developer included SIP in their solutions, they could connect to a media gateway via SIP and then let the media gateway take over the role of connecting to the existing circuit-switched network. This had been possible before SIP with H.323, but SIP offered much more flexibility for doing the complex call processing needed by the voice developers and continued to gain market momentum. In turn, various hardware companies started building purpose-built media gateway appliances to connect to digital or analog networks. The gateways supported the most common networks such as ISDN first, but eventually some gateways got more sophisticated and added Signaling System #7 (SS7) support as well.  This decomposition  of the voice solution offered benefits for both types of vendors. The solution vendors could start their move away from hardware and focus more on software, whereas the media gateway vendors were able to specialize in connections between SIP and the circuit-switched networks. Each type of company could specialize in their area of expertise and the solutions providers could add value to their solutions by buying best-of-breed media gateways.  Since the network protocols were standards-based,  the gateways needed to have robust standard protocol implementations and this helped create a competitive market for media gateways.

As a result, solution developers took another step along the path of reducing their dependency on embedded hardware, since they could now outsource the network connection to a media gateway.  In the next post, I’ll talk about developments in IP-based media which continued the evolution toward software-based voice applications.

If you participated in the evolution described here, please feel free to weigh in with your comments. If you’d like to explore strategies on how to evolve your company’s solutions to meet customer needs, you can reach me on LinkedIn.

On the Road Again – SIPNOC 2014

I’ll be speaking next week at the SIPNOC conference in Herndon, Virginia.  SIPNOC is sponsored by the SIP Forum and covers a wide variety of topics related to SIP — the Session Initiation Protocol — with a particular focus on the needs of service providers.   It runs from June 9 – 12.

WebRTC continues to be a hot topic in the telecom industry and I’ll be on a panel with several other participants to discuss the relationship between SIP and WebRTC.   SIP has been the primary protocol for Voice over IP and is widely deployed.  WebRTC is much newer, but offers an interesting mix of audio, video and data capabilities and it can be accessed via popular browsers from Google and Mozilla.  WebRTC also has a rapidly growing eco-system.  Are SIP and WebRTC complementary standards which work well together or going in totally different directions?  Come to the panel and find out!

I am also delivering a presentation on a very exciting development in IP fax communications over SIP.  The presentation is entitled: Securing IP Fax – A New Standard Approach.  It’s been a long time coming, but there will soon be a new security standard for implementors of IP Fax over SIP networks.  In particular, the Internet Engineering Task Force is working on using an existing security standard known as DTLS and adding this as a security layer for T.38 fax.    I’ll be talking about the pending standard, why it’s needed and what kind of benefits can be expected for the many users of T.38 IP fax once the new standard is deployed.

I’ve attended SIPNOC as a speaker since its beginning four years ago.  It’s an excellent conference and offers an in-depth perspective on the latest news in SIP as delivered by an all star cast of speakers.  I hope you’ll be able to join us.

WebRTC – Solution for Over The Top Communications?

WebRTC offers an intriguing mix of web-based access and real-time communications.   Part of the excitement has been due to the aggressive approach which has been taken by browser companies such as Google and Mozilla in adding WebRTC to recent versions of their production browsers. 

As a result, any user of these browsers could potentially be connected to other users of WebRTC applications. One example where this could come into play is in Over the Top (OTT) applications. The term Over the Top usually means that an application runs over a broadband IP network and is usually not a packaged service sold by the Internet service provider (ISP). For example, Skype provides a way to do audio and video communications over IP networks. Its base level of service allows for connection to other Skype users at no charge for both audio and video communications. Skype also includes sophisticated features like encryption of calls. For ISPs, Skype potentially competes with a bundled voice offering and a user might elect to use the combination of Skype and a mobile phone for all of their voice communications. This means the ISP gets to sell the customer a broadband IP connection, but may not get any other bundled service revenue.

Let’s suppose you’re an ISP that would like to offer an alternative to Skype for your customer community. What does WebRTC bring to the table? On the media side, WebRTC can support both audio and video communications. It also has built-in security methods for authentication and securing of sessions. For the application, the ISP can create this from scratch or layer this onto a WebRTC enabled browser and automatically take advantage of the WebRTC “hooks” which are built into a browser such as Chrome or Firefox. To truly complete the OTT application, there is still more to do such as determine which signaling to use, and what addressing scheme should be used to interconnect users. For a good analysis of the signaling side, see this recent blog post from webrtchacks.

So, let’s assume the ISP completes the OTT application using WebRTC. What is the potential value add compared to a application like Skype? One potential benefit is the capability for the user to communicate with other users that have WebRTC-enabled applications. One limitation of Skype is that it is a closed community and uses proprietary technologies. As a result, Skype users can currently only communicate with other Skype users unless they go off the network. By contrast, with WebRTC, there will be a standards-based interface based on JavaScript APIs, so that the ISP could structure their application so that it can talk to other WebRTC-enabled applications. There are also a wide variety of WebRTC to SIP gateways that have already been brought to the market, so this offers the potential to interconnect the WebRTC enabled application with the existing base of SIP applications. Hence, WebRTC offers the potential to help break down the silos which currently dominate multimedia communications and enable different applications to communicate either directly via WebRTC or indirectly through WebRTC to SIP gateways.

One way to look at WebRTC is that it offers a very robust “toolkit” of multimedia communications capabilities that can run over web interfaces. The example we have discussed in this blog of an OTT application is just one possibility of how a developer or ISP might use this toolkit. As the web development community learns to take advantage of WebRTC, there will no doubt be a wide range of applications which will emerge. On the business side, WebRTC is a disruptive technology, so we can also anticipate a wide array of different business models to emerge which will build on its open standards hooks.