Comments on: Cisco just entered the WebRTC PaaS Game by Acquiring Tropo https://bloggeek.me/cisco-acquire-tropo/ The leading authority on WebRTC Sat, 02 Jul 2022 12:01:12 +0000 hourly 1 By: Tsahi Levent-Levi https://bloggeek.me/cisco-acquire-tropo/#comment-118062 Sun, 03 Jan 2016 18:36:31 +0000 https://bloggeek.me/?p=9700#comment-118062 In reply to ashutosh zaodo.

I don’t think it matters in the bigger scheme of things. SVC was always interesting and useful, but not a game changer. I don’t believe it is that even today.

]]> By: ashutosh zaodo https://bloggeek.me/cisco-acquire-tropo/#comment-118061 Sun, 03 Jan 2016 18:08:33 +0000 https://bloggeek.me/?p=9700#comment-118061 it will be interestimg to note how Google vidyo development on webrtc will work in the market as against cisco

]]> By: Tsahi Levent-Levi https://bloggeek.me/cisco-acquire-tropo/#comment-118060 Fri, 08 May 2015 17:51:45 +0000 https://bloggeek.me/?p=9700#comment-118060 In reply to Kile Brown.

Thanks for the comment Kile. You make a good point. I’d only question the value of voice and SMS versus “OTT” moving forward, and the need for a carrier network.

It will definitely be interesting to see if Cisco/Tropo will win the heart of the enterprise or will Twilio or some other vendor take that role.

]]> By: Kile Brown https://bloggeek.me/cisco-acquire-tropo/#comment-118059 Fri, 08 May 2015 15:17:59 +0000 https://bloggeek.me/?p=9700#comment-118059 One of the things that Cisco did very effectively in optical transport in the early 2000s was to push their optical networking gear via enterprises (where they were selling routers) and then sponsor those solutions into carriers (RBOCs and CLECs). This helped drive optical transport sales in areas where they weren’t approved/certified by a number of larger carriers. And eventually, the amount of business and co-marketing that they brought carriers helped those carriers overlook some of the performance issues in the equipment.

Where this deal has some similarity is that Cisco can go to large Enterprise customers and say, “Hey, we can enable X service through using our PaaS that is embedded in Y Carrier’s network.” That drives use of the carrier’s service and revenue for Cisco-Tropo.

The reason for the strategy shift from a developer-based API model to a carrier network-based PaaS was because key ingredients to the developer-API-based resale of SMS/voice minutes are exposed to a supply they don’t control – DIDs and minutes. Plus, it’s a very competitive, commodity, low-margin business. Keep doing what you’re doing, and you’ll keep getting what you’ve got–just a little more of it if you do a good job doing it. Of course, I don’t think they realized that getting an application server in a carrier network is not easy and takes much longer than their “I’ll just write this code tonight and make it work” way of working. I know of at least one casualty along that path.

Their global distribution deal with Ericsson is probably blown up. Their deal with Huawai as well.

Interesting that their WebRTC API, Phono really hasn’t been an area of focus, partially because of the open source nature of WebRTC, the real-world lack of demand (I think WebRTC is in the Gartner Hype Cycle’s Trough of Disillusionment phase) and all of the work they were doing with AT&T (and with E///) where E/// was very protective of the the AT&T WebRTC business (that it was basically giving away). Cisco can help productize WebRTC to Enterprises in a way that Tropo never could–in a way that few companies can today. Because the value of WebRTC to an enterprise lands in IT, Marketing and Operations – Cisco has enough breadth and market savvy to make that possible.

]]>