WebRTC in OSS

Everyone seems to agree that WebRTC is the next big thing that is going to shake up the enterprise communications landscape. WebRTC (Web Real-Time Communication) allows for real-time audio and video communications to be developed with a simple Javascript API running in a WebRTC compliant browser such as Google Chrome. There is a seemingly endless supply of enthusiasm for the possibilities that this will bring. However, I find that when I talk to startups, web developers, and other industry people, many of them haven’t thought through the actual business scenarios that will be of interest to enterprises. One of the most common rallying cries I’ve heard is around the fact that WebRTC allows for real-time communication between two parties without using the PSTN. In my opinion, this PSTN bypass is one of the least interesting things about what WebRTC makes possible. The critical driver for WebRTC-based customer interactions in the enterprise will be around streamlining and contextualizing interactions.”
Derek Yoo
, at ThinkingPhones.com.

In a recent post entitled, “OSS social engine,” I posed a question about how OSS/BSS can help CSPs (and their customers) to improve internal communications. Like Derek, I’m not interested in PSTN bypass per se, but the “streamlining and contextualizing interactions” possibilities do intrigue me. How can technologies like WebRTC (or similar) be used to add value to the service that OSS/BSS already provide?

There are a few possible use cases listed below, but I’d love your thoughts on how embedded real-time communication could improve the OSS/BSS customer experience and perhaps even drive new revenue models.

Today I’ll look at internal communications (within business units / suppliers / contractors) rather than external communications (with customers).

Internal communications use cases could include:

  • Real-time audio / sharing link between field workforce and design teams to immediately remediate issues with a proposed design and ensure that design changes are reflected in the OSS/BSS. This could be something as simple as a dead port on equipment requiring a slight change to planned connectivity. It could be much bigger, such as civil works issues not captured during the walk-out or the current situation in the network not being accurately reflected in the OSS (ie major data integrity issues). Tools to support this could be the real-time sharing of red-line markups between the field and office as well as an audio channel. This would be the new-age multimedia equivalent of the old engineering orderwire communication channels
  • Safety systems that allow field workers to report incidents or problems. Alternatively, the office could attempt to contact field workers in potential man-down scenarios
  • Real-time dispatch and routing of field workers between jobs to evolve with changing conditions throughout the day, including real-time updates on job details (eg splicing diagrams)
  • Alerting head-office of hazards (eg working at heights to service a particular customer order) relating to a job that allows multi-media to be recorded in the OSS for future truck-rolls, to ensure that suitably qualified staff attend to these jobs and are pre-warned about the hazard. This would require interaction with skills-based routing within the field-workforce management systems of the OSS to ensure staff or contractors with working-at-heights certifications and equipment attend to this customer for future call-outs to avoid unnecessary truck-rolls
  • Communications between other business units (eg marketing, product, sales, etc) and the OSS administrative teams to ensure real-time updates to the configuration of the OSS to reflect the latest requirements. This could also facilitate engineering teams alerting sales / product / service teams of additional mandatory attributes that need to be integrated into sales order forms and collected so that they can be provisioned into the network

I’m sure there are millions of other possibilities. The question becomes whether the effort of configuring the RTC tools and the apps they’re embedded into justifies the outcomes.

PS. For those who are interested, this link on Quobis shows a high-level architectural view of one possible integration of OSS and WebRTC

Read the Passionate About OSS Blog for more or Subscribe to the Passionate About OSS Blog by Email

Leave a Reply

Your email address will not be published. Required fields are marked *