February 17, 2014
On selecting a signaling protocol to use in a WebRTC-enabled app
This is cross posted from EnThinnai Blog. Please post your comment at the original location. Thanks.
In a post that prompted me to write this, Tsahi discusses different alternative signaling protocols one can use in a WebRTC-enabled app. In this post, I approach the issue from a different angle and I hope this sheds additional light and helps you to reach a choice appropriate for you.
Continue reading "On selecting a signaling protocol to use in a WebRTC-enabled app"January 04, 2014
On User Interface Design of a WebRTC App
This is cross posted from EnThinnai Blog. Please post your comment at the original location. Thanks.
Recently, Carl Ford was musing about potential ideas for a WebRTC Hackathon. One idea he had was exploring different UI designs associated with “Video on Hold”. This post is a summary of our design thoughts decisions we made for a WebRTC application that is part of EnThinnai.
Continue reading "On User Interface Design of a WebRTC App"January 02, 2014
WebRTC App is Like a Formal Living Room
This is cross posted from EnThinnai Blog. Please post your comment at the original location. Thanks.
Inasmuch the main utility of a formal living room is to entertain visiting guests, a WebRTC allows guests to initiate a communication session with the subscriber of the app that utilizes WebRTC.
Continue reading "WebRTC App is Like a Formal Living Room"August 08, 2013
Tu Me doesn’t have to just To Go
This is cross posted from EnThinnai Blog. Please post your comment at the original location. Thanks.
It has been reported that Telefonica will shut down Tu Me and redirect its resources in shoring up another service, To Go. People have theorized that compared to competing services from OTTs, To Me has anemic traction with uncertain revenue potential. On the other hand, the reasoning continues, To Go has solid revenue opportunities, since it accrues billable minutes/SMS from existing customer base. Two years back, I gave a talk at Telecom 2018 Workshop, in which I argued that telcos will have difficult time directly competing with OTTs and suggested an alternate approach. In this post, I revisit those points in the context of Telefonica’s decision.
Continue reading "Tu Me doesn’t have to just To Go"July 30, 2013
How to control robocalling
We all hate these annoying, unsolicited calls. FCC has been trying to alleviate the problem by various means. They introduced “Do not call list”. It even ran a “challenge”, in the spirit of crowdsourcing a solution. And now the bright and smart people of IETF are trying to form a group to address this problem using technology. In the kickoff meeting, Henning Schulzrinne, CTO at FCC is quoted as saying, “Number spoofing is root of (almost) all phone evil”. If this is so, then there is a simple procedural solution and it starts with “me”.
Continue reading "How to control robocalling"July 25, 2013
Who needs Federation in WebRTC
This is cross posted from EnThinnai Blog. Please post your comment at the original location. Thanks.
In a recent post Chris Kranky on the need “to move on” and the need for expediency in wrapping up the first iteration of the API. Personally I would have benefited if the first iteration had been a low level spec. For I could have easily ported a custom Java applet. But given the passage of time, it is more important that there is an agreed standard. But this point is not the objective of this post. Instead I would like to focus on another of his points:
[WebRTC] wasn’t designed to be federated (namely that 2 WebRTC applications aren’t in fact supposed to talk to each other.
He makes this observation to explain the motivation for seeking low level control. My quibble is not with this explanation, but I want to take this sentence in isolation, interpret it literally and discuss it. (It is not fair to Chris, but I am just using his sentence as a prop. So it should be OK with him.)
Continue reading "Who needs Federation in WebRTC"July 22, 2013
On Avoiding STUN and TURN While Deploying a WebRTC-based App
This is cross posted from EnThinnai Blog. Please post your comment at the original location. Thanks.
By now it is quite passe to claim that WebRTC will be a huge disruptive technology. Indeed, there has been a predictable backlash. In all these back and forth, very often we miss to note an important aspect of this technology: there has been a deliberate attempt to avoid specifying any messages and procedures that go across the wire to an intermediate point like server. This gives enormous flexibility to app developer in designing a signaling procedure that suits the needs of the app and at the same time do not have to worry about interoperability issues between arbitrary peers and the app. This is almost true, except for NAT/FW traversal. The objective of this post is to suggest a way to overcome this as well.
Continue reading "On Avoiding STUN and TURN While Deploying a WebRTC-based App"November 29, 2012
An “App” Enabled by WebRTC
This is cross posted from EnThinnai Blog. Please post your comment at the original location. Thanks.
Some of us strongly believe that WebRTC will usher in a wide variety of innovative services, features and capabilities. At the same time, there are many skeptics dampen the (irrational?) exuberance. I am sure both sides will present their view points during this week’s WebRTC Conference & Expo. In this post, I would like to commemorate that conference by outlining one possible application.
Continue reading "An “App” Enabled by WebRTC"January 11, 2012
Integrating POTS line, Google Voice account and Obi110
In this blogpost, I note down my experiences as I integrate POTS line, Google Voice account and Obi110 and finish it off with some ideas on enhancing products like Obi110. But I want to clarify upfront that this is not a review of Obi110. It has a tone of features and my interest is very narrow and focused. So this will not do justice.
Continue reading "Integrating POTS line, Google Voice account and Obi110"December 28, 2011
To Cap or Not to Cap?
Evidently I seem to hold a contrarian position on whether Broadband access bandwidth consumption should be capped or not. My position is that ISPs are in the business of offering service at the Network Layer and they should be free to charge based on the consumption. My rationale is simple: with the freedom to charge at the Network Layer, ISPs will not be in a position to dictate usage policy or to play favoritism to one provider over another. Please note that I also contend that freedom to charge at the Network Layer includes offering differentiated service (at the Network Layer) as long as differentiation is requested by the users and are charged to them. Today I read something from an unexpected source that reinforces my position.
Continue reading "To Cap or Not to Cap?"