Tag Archive | open standards

My First @W3C #WebRTC Editor’s Call

w3c

As newly appointed co-chair in the W3C WebRTC WG, I just participated in my first Editor’s Call, and I’m impressed.

We had to address nearly dozens of Pull Requests and Issues on the associated github repos. We managed to knock down quite a few that ended up getting merged and a few that were closed today, despite not having 1 co-chair and 1 editor present.

There were some suggestions on how we could make the processes a bit more effective, allowing everyone to understand more what’s expected of them. It’s going to take a few meetings I suspect to get a real feel for how I can be adding the most value possible.

Overall, it feels like we are all trying our best to do what the new charter has set out, to get 1.0 done before getting on with the next chapter. I am excited to be part of it and look forward to continue helping!

If you have any thoughts on how the WebRTC Working Group could be doing things differently to be more effective and efficient, I would like to hear your thoughts.

WebRTC, SIP and Open Standards

Patience, not something we are good at.

Some of the SIP proponents out there are not very happy about a recent JavaScript Object Rationale Draft that was published on the IETF RTCWEB mail list ahead of the WebRTC Expo in Atlanta.  Full disclosure, I am one of the authors of that draft.

So, what’s all the hub-bub? Some of the reasoning seems to be..

  1. SIP and XMPP are the standards, everything else should take a backseat.
  2. The current WebRTC model should be the priority, stop asking for changes, you are just getting in the way of progress.

I understand the reasoning, I used to be one of those SIP advocates and I still believe that SIP has its place. To say that SIP and XMPP should rule all is just a bit much.

The one thing I am rather sure of is that SIP will not be the signalling protocol that ultimately ends up powering web communications.  It’s just not practical.  This doesn’t mean that SIP won’t be part of WebRTC, it just means that eventually we will move towards a more web-centric model.

To be clear, we are not against SDP in WebRTC.   In fact, we believe that any API proposal should have both a lower-level Object model and also provide real support for SDP at a higher level.

To that end, we have created a new Object-RTC draft proposal that outlines this model in detail, which also supports SDP Offer / Answer.  Yes, you can have have your cake and eat it too. This draft is about JavaScript, SDP (not baked into the browser) and the Open Web.

The question is, “When is the best time to submit the Object RTC proposal to the IETF and accompanying API docs to the W3C?”

We are not hell-bent on derailing the current progress being made in the respective working groups (contrary to what others may think).  So potentially, you may not see the Object RTC draft in the wild before the conclusion of the next IETF meeting in Berlin, only a few short weeks away.

Here’s to making marked progress on v1 in Berlin so we can get on with 2.0.

WebRTC or CU-RTC-Web?

From an interoperability perspective, even if WebRTC & CU-RTC-Web end up competing there will be JS libraries out there that will support both. So it seems SDP is not the big issue here, but there is an elephant in the room, the media stack

Differing media stacks (specifically codecs) could cause big problems. As an example; IE & MS endpoints may support various Microsoft codecs versus WebRTC compliant endpoints (Chrome, FireFox, Opera, Mobile Apps etc.) which would presumably support the RTCWEB MTI (mandatory to implement) Video and Audio codecs.

That is if WebRTC has such codecs. We still don’t have a MTI Video codec yet! <- This has been one the most contentious issues in the IETF RTCWEB working group to date.

If we fail to deliver a MTI video codec in WebRTC what’s the likelihood of opposing browser vendors (implementing opposing standards) supporting the same codecs? Not very good odds I would expect. In which case cross-browser communication (media: audio, video) would fail.

Although, we might get lucky and have all the browser vendors select at least 1 like audio and video codec on their own accord. Ya, right.

If you don’t want to leave it entirely up to chance, get involved! Joining the IETF is free and open standards need your support if they are to succeed. The next IETF meeting could be be very telling wrt a MTI video codec: http://www.ietf.org/meeting/86/index.html

IETF 80 Plenary – SIP under the bus

When a co-author of SIP, who now works for Skype, starts out by saying SIP is old, broken and needs to be replaced… I become rather suspect. We all know SIP is busted but throwing out SIP (software-centric according to JDR) just before we cross chasm is silly. When The W3C pipes up and says that web APIs and web sockets will replace protocols I really start to ask myself why I showed up for this. The last bit sent me directly over the edge.

In addition to all of that, the IETF upper echelon now seems to be OK with mandating policies around how one speaks of the IETF? That is just plain sad.

Siemens (Finally) Launches a Cloud UC Service

 Siemens Enterprise Communications has launched a new cloud communications solution. Leveraging SIP, open standards and its highly scalable softswitch-based OpenScape suite, it is looking to provide partners and customers with more flexible deployment options. The cloud solution includes virtualized, multi-tenant versions of Siemens’ OpenScape Voice, OpenScape UC and OpenScape Web Collaboration software, hosted in four geo-redundant data centers. The service features top-notch availability, survivability, governance and data privacy features, including:

  • Highest availability, TIA-942 class data center, voice redundancy, secure endpoints
  • Edge survivability option, local trunking, IPSec VPN, local firewalls, SBC and media server
  • Multi-tier role-based access management, automated management and provisioning, application-level data center protection
  • End-to-end encryption in the cloud, local country data storage, multitenant capability, data protection audits

Cloud-based voice and UC services will be available only through partners, who will handle customer needs assessment, CPE installation, billing, 1st and 2nd level tech support and ongoing equipment maintenance. The service will be first launched in the U.S., Germany and the Netherlands. Initial partners include Black Box in the U.S., mr.net and Telefonbau Schneider in Germany, and Televersal, ICT Trends Group and onecentral in the Netherlands.

The cloud solution is considered optimal for organizations with about 350 to 1,000 users, with a need for highly packaged, tightly integrated solutions. Users can choose from a variety of features and capabilities grouped in Base Packs and Booster Packs. The estimated end-user list pricing ranges between $5 and $30 per seat per month, based on required functionality.

What I like about this announcement:

Siemens has finally launched a cloud solution – something it started exploring about two years ago by demonstrating a proof of concept with Amazon’s EC infrastructure. With the incredible (I think, almost unreasonable) amount of hype surrounding cloud technologies and the cloud business model, it was about time for Siemens to finally bring this effort to fruition. I have to agree that there is a group of customers out there that would indeed appreciate the opportunity to outsource its communications infrastructure to avoid CAPEX, focus on core competencies or gain access to superior technologies and expertise. This customer segment would remain out of reach for Siemens, unless it finds an appropriate role for itself in the hosted/cloud-based communications marketplace.

It should be noted that Siemens has had a multi-tenant voice platform for years and some service providers such as Postrack and Engage have been using it to deliver services to end users just like others use BroadSoft’s or Metaswitch’s platforms. Other vendors such as Alcatel-Lucent, Cisco and Mitel have also deployed multi-tenant communication managers with service provider partners.

The new approach has significant advantages, however. It gives Siemens continued control over the platform and its capabilities. But more importantly, it empowers partners that cannot or do not wish to manage their own data centers to deliver services using Siemens’ feature-rich and highly scalable platform. Siemens allows partners to use its brand, co-market or white label their cloud services. This is an opportunity for them to gain differentiation as well as new recurring revenue streams. This model provides a fast and economical entry point for small MSPs and VARs to become hosted service providers. It is noteworthy that Siemens announces the new solution along with six partners already lined up.

Issues that Siemens will need to address:

Siemens is not alone in this market. Other telephony vendors are experimenting with new delivery models as well. For example, Mitel offers the Mitel Anywhere service, which it sells directly to business customers. Now it is exploring opportunities with data center providers such as Host.net and Hosting.com, which can host the platform on behalf of small MSPs and VARs. Siemens and other vendors will need to find ways to differentiate or be fast to market with the right partnerships while the market is still nascent and untapped.

 More importantly, this new delivery model is still unproven and it is not clear how all market participants in the value chain will reposition themselves for competition in the evolving marketplace. Will the MSPs and VARs be successful in penetrating the CPE customer base? Will the vendors be able to successfully manage their channels to ensure customer satisfaction and optimal benefits from the cloud services? How will carriers be involved to ensure proper bandwidth and QoS management – critical elements for real-time communications services delivered over the WAN? Who will manage the carrier relationship? How will the hosted IP PBX and UC solutions be aligned with SIP trunking and IP VPN services to provide superior benefits to multi-site organizations?

Open Standards, SIP and SOA: Summer of Love in the Communications Market?

Avaya-Nortel: SIP Architecture Becomes Foundation for New Product Roadmap
As I listened to Avaya’s new roadmap announcement on January 19th and wondered if they made all the right decisions, I couldn’t help thinking about the complexity of an M&A process and its implications for everyone involved. This article is not about the specific product choices Avaya made, although I thought they did a good job taking multiple factors into consideration including product features and capabilities, customer and partner investment protection concerns, and vision for the evolution of the total portfolio and architecture. Extending the life of most Nortel products for another 18 to 30 months and continued support for Nortel’s more advanced and unique products such as Nortel’s AS5300 were good calls. I was surprised to see so many end users inquire about the fate of the Call Pilot and I am glad Avaya had some good news for these customers. I also thought Avaya’s decision to keep and evolve ACE was the right one as I believe ACE and application enablement will be key for its competitive positioning going forward.

It is only natural that Avaya intends to eventually merge and integrate all products and solutions into the Aura architecture. Aura is a technological framework (and not just packaging or a marketing term) based on SIP and SOA, and it makes sense for Avaya to look to integrate its now extended product line into the same vision or framework. It will be critical for Avaya to continue evolving this framework with an eye on new technological developments and customer and partner needs.

Application Enablement and Openness Drive New Competitive Dynamics
I think we should, however, look at the Avaya-Nortel acquisition from another angle as well. It provides an example of portfolio integration challenges and possibilities in the context of current technology trends towards greater openness and interoperability.

The shift to open standards, SIP and SOA is now making such acquisitions less painful than they used to be in the past – for the merging vendors, the channel partners, and their business customers. It will take Avaya less time and effort to integrate the best-of-breed applications of both vendors into its Aura framework because of the greater openness and interoperability of both vendors’ advanced communications solutions. Customers can more cost-efficiently mix and match platforms and aplications, not only from these two vendors, but from other vendors as well, since communications are becoming more software-centric and standards-based. Overall, today, customer investments are better protected and less vulnerable in case of abrupt changes in competitive dynamics.

In Avaya’s case, SIP, Aura and ACE will play key roles in delivering a more flexible and cost-effective migration path to its customers. Other vendors have their own next-generation architectures and application enablement environments that allow them to integrate with competitors’ platforms and applications. The capabilities of each vendor’s application enablement technologies vary from a more limited set designed to integrate communications with messaging and presence platforms (e.g. Avaya’s AES) to a broad range of capabilities including integrations with messaging, presence, business process, Web 2.0, mobile, and contact center applications, TV and video broadcasting, etc (e.g. Nortel’s ACE).

As unified communications become further integrated with digital content, business process applications and other, non-communication technologies enabling “contextually-rich communications” and “communications-enabled business processes (CEBP)”, vendors will need to open their solutions and create tools for customers, partners or their professional services arms to develop custom solutions addressing specific customer needs. Such tools and application enablement environments can be made available to large communities in the cloud so that multiple parties can contribute to the process of creating new applications and mashups. Some of these new mashed-up applications that can be deployed out of the box can eventually become productized to provide a more cost-efficient alternative to SMBs and a new revenue stream for vendors.

Application enablement capabilities will be key for all communications vendors going forward, but they will be even more critical for vendors providing best-of-breed solutions designed to operate in multi-vendor environments.

Of course, vendors have a long way to go before standards become truly open and customers can seamlessly, quickly and easily integrate multi-vendor applications. SIP, though touted as the communications standard of the future, in its pure form offers only a limited set of features. Entirely or partially proprietary solutions still offer better features and capabilities than most open-standard ones. Therefore, although most vendors claim SIP support, the different versions of SIP used along with the proprietary enhancements are not entirely interoperable.

Most likely, the cloud and cloud-based communications will help push further the frontiers of openness and interoperability. Instead of connecting multi-vendor applications and platforms individually at each customer’s premises, vendors can integrate more economically and on a larger scale in the cloud, delivering choice and flexibility to their customers unmatched in the premises-based world. In the beginning, many of these cloud-based services will be simple and will only offer some lowest common-denominator capabilities, but will enable some integrations out of the box, sparing customers the hassle and the cost of complex integration processes taking place in premises-based installations.

Partnerships, Alliances and M&A in a More Open Communications World
Customer demand for application integration will drive vendor efforts towards greater interoperability and co-opetition. Improving standardization and openness in communications technologies, in turn, will enable vendors to more easily engage in partnerships and alliances in order to deliver greater value to their customers.

There are multiple reasons why companies wish to merge. Most often, they are looking for new revenues streams, but also – for opportunities to more tightly integrate their technologies and deliver a one-stop shop value proposition to customers. Will more open architectures reduce the appeal of complex M&A processes in favor of partnerships and alliances? Should we expect further market concentration or the proliferation of more innovative and nimble market participants providing business customers with a wide array of options?

Power in the top tier has become concentrated, but the SMB market remains quite fragmented. While it will become less appealing to go through an M&A for the purposes of ensuring technology integration, it will also become less challenging to integrate portfolios in case of an M&A. M&A will likely take place for the purposes of acquiring installed bases, skill sets and business models (e.g. professional/managed services), simply eliminating a competitor, or for geographic expansion. I believe both trends (consolidation and fragmentation) will persist, but the drivers behind vendors’ business model decisions will change. What do you think?

%d bloggers like this: