A deep dive into WebRTC topology

There are many prior articles on the web about the WebRTC media path topology in a multiparty scenario. Those usually cover the basic topology of full-mesh and centralized, including MCU and SFU. 

In practice, conferencing systems often exhibit complex topologies beyond this basic view. For example cascaded servers can scale to a much larger meeting or live streaming, especially when participants are geographically distributed and clustered. Separate topology for audio vs. video media paths may enable easy integration and interoperation with telephone and VoIP systems.

In this article, I take a deep dive into WebRTC media path topology — understanding the benefits and tradeoffs of various alternatives — including, but also beyond, the simplified view of full mesh, MCU and SFU.

How not to design a video conferencing product?

"Can you please stop sharing your screen so that I can share mine?" "I can't see that part of your shared screen because those buttons are overlaid on top." "How can I share my second webcam without stopping the first?" "Can you please say that again? I missed the last part." "It shows only up to nine videos even though I have a very big screen."

Do you ever feel frustrated due to some artificial restriction imposed by the video conferencing product you use? In this informal article, which some will find quite opinionated, I list some annoying product "features" when it comes to video conferencing. 

What do I do as a software architect?

"I am the Architect. I created the matrix. I’ve been waiting for you." -- The Architect

I present my view on what an architect does or should do? And what are the important things to keep in mind in my opinion? 

Topics: Introduction. Making decisions using trade-offs. Research and evaluate technology and tools. Create proof-of-concept of big picture. Systematically divide the goal into smaller solvable problems. Create knowledge base and training for others. Continuous monitoring and improvement of the system. Identify and address disruptive technologies. Conclusions.

From "TO DO" to "DONE"

What does it take to get things done? Why do some tasks get done quickly while others drag on forever? Is there a science behind it? Or just philosophy?

Here, I present my thoughts on these topics. This is largely based on my first hand experience in software industry as well as academia, working in small and large companies, collaborating in small and large teams, and observing wide range of things getting or not getting done. 

Named stream abstraction for WebRTC notification with P2P media

This is a continuation of my earlier article on WebRTC notification system and signaling paradigms which presents, among others, a named stream abstraction for WebRTC signaling. That article also mentioned my light weight notification server notify.py and sample client code webrtc.html as part of my open source rtclite project. 

In this article I present another light weight notification server streams.py and sample client code streams.html as part of that project. This enables named stream abstraction described in my earlier article. The named stream abstraction is closer to the traditional Flash Player's NetStream based publish-subscribe media, and facilitates wide range of application use cases.

Multi-language software programs

When two bilingual people talk to each other, they often tend to mix the two languages in their conversation. Have you heard of Hinglish?

As a software developer, it makes me wonder - is this doable or already done for programming languages?

Vanilla JS

I am a proponent of using Vanilla JS [1,2,3,4] wherever possible. It is plain JavaScript without external frameworks. In my last two jobs, I built many feature-rich and cross platform apps using HTML5, JavaScript and CSS, without depending on the popular frameworks such as jQuery, React or Angular. There are numerous articles on the web about the benefits (and problems) of using plain JS, i.e., without frameworks. Here, I present my thoughts and some reading list for developers who want to avoid frameworks too if possible.

A generic video-io component for WebRTC

This article proposes a generic video-io web component for WebRTC. It can enable various real-time applications such as voice/video conferencing, video messaging, video presence and video broadcast. This client side component may be connected with any signaling channel or mechanism to integrate with existing or new websites or applications. 

By encapsulating the core functions in a single easy-to-understand component, the component enables reuse of the core media features present in WebRTC. Without this, a user relies on the individual website or application developer to support and expose those media features. 

Additionally, I describe the design of a global secure application service that can act as a signaling mechanism for all such component instances.

Lessons in web software development

Here is a summary of what I feel are important to me for creating web applications as an individual developer or in a small team. My hope is to help other developers with the important topics that I assembled. These topics include local development, cross platform and responsive, loose coupling but strict APIs, flexible code, customization, avoid artificial and arbitrary restrictions, state vs. stateless, separation of data and application logic, performance, robustness, caching, one more level of indirection, security, configuration, and reduce fat!

WebRTC notification system and signaling paradigms

This article describes notification system in WebRTC, and presents some common signaling paradigms found in existing WebRTC applications: How does WebRTC work? What is a notification service? What are the signaling paradigms? Which one would you choose? Can the abstractions be converted from one another?

Reason for technology failures - chat bots, video conferencing, or you name it.

Every so often, I come across articles explaining why a piece of technology failed. For example, why chat bots failed in 2018, or why video call did not work for customer support. I think the answer to these and other similar questions can be attributed to three points: (1) not a holistic approach, (2) wrong audience, (3) unreasonable expectations. Let me elaborate further.

Writing coherent dialogs using Twilio

This article shows the complexity of writing a multistep interactive voice dialog for cloud telephony. It presents our dialog package to create such a dialog as a single and simple coherent script in Tcl. The script performs programmed interactive voice or messaging interaction using the popular cloud telephony platform, Twilio.

It should also work, after trivial modifications, with other similar systems such as Restcomm or Somleng that use TwiML or similar markups. The package can further be extended to support other popular dialog languages such as VoiceXML. The core idea can be re-implemented using other scripting languages such as Python.

Scripting VoiceXML and TwiML using Tcl

This article describes how to write XML-based programmable scripts such as for W3C's VoiceXML or Twilio's TwiML using Tcl, the Tool Command Language. The associated project is available as open source software at http://github.com/theintencity/tcl-vxml-twiml.

1. How easy is a programming language?
2. What is Tcl?
3. What are XML-based documents?
4. How do I get started?

Command line Twilio client - part 2

[This is continuation of the previous post]

The command line SIP endpoint included in my rtclite project allows SIP registration to register with a SIP server to receive SIP calls. For example, you can signup for a free SIP account at iptel.org, download rtclite and py-audio on OS X, open two terminals, run the rtclite.app.sip.caller app on one to register, and on another to place a call as follows:

A journey through real time...

I did my first project on real-time communications in 1997. In the past two decades I did numerous projects in this general area. In particular, these were related to voice over IP (VoIP), multimedia and web communication. As 2016 comes to an end, I reminisce my 20-year journey. I attempt to capture the gist of my projects. How my project themes and ideas evolved over time?