IP communications services - voice, video and chat and the many variations therein - are all the rage again. Startups are sprouting daily. Though some focus just on mobile, many are building cross-platform applications.
When building such a service, the first and most important capability that you need to build is perhaps not so obvious. It is not wideband voice. It is not chat. It is automated (and silent) client software upgrade.
When building such a service, the first and most important capability that you need to build is perhaps not so obvious. It is not wideband voice. It is not chat. It is automated (and silent) client software upgrade.
For mobile clients, automated and silent software upgrade is not yet fully possible. IOS7 allows the user to opt into automated updates, but this is not under application control. Mobile applications can, however, do a check upon launch to determine if an upgrade is needed. If so, it can surface a modal dialog which requires the user to upgrade or exit, and if they click upgrade, take them to the app store to get the latest version. The situation is better on desktops, where fully automated and silent upgrade (meaning the user does not need to know about the upgrade or give permission) is possible. Applications like Chrome and Skype have been doing this for some time.
Why is automated software upgrade so important? There are four big reasons: elimination of perpetual tech debt, elimination of security weaknesses, avoidance of IPR pitfalls, and preservation of innovation velocity.
The first reason is: every client you ship which you cannot force upgrade is a piece of tech debt which stays with you forever. Inevitably in a cloud service, you will need to modify your protocols and interfaces. This applies to client-server protocols but also to p2p protocols (e.g., RTP). If you cannot upgrade these clients, it means that the client-server protocols they support must be supported in servers indefinitely. But worse, the p2p protocols they use must continue to be supported in every other client - indefinitely. This means that, over the years of lifetime of the service, each upgrade of a client must remain interopreable with every prior version of the protocols that have ever been shipped. Consider then a service which upgrades its p2p protocols 3 times a year (a very conservative number). Over a five year lifetime there are 15 different versions of this protocol in the client. From a testing perspective, there are now 15^2 or 225 different permutations of client versions which must be verified!
In other words, non-upradeable clients represent a technical debt which actually grows linearly over time for client-server protocols, and grows exponentially for p2p protocols. As communications services often use p2p protocols, communications applications are particularly susceptible to this tech debt.
The second reason is that you put yourself in a position of introducing security vulnerabilities you cannot patch (at least without locking out those clients). If a vulnerability is discovered that is unique to that instance of the client, and this vulnerability threatens the entire network, this is a vulnerability you cannot easily patch. In pure client-server systems the vulnerabilities primarily exist in the cloud. But communications systems utilizing p2p protocols often have substantial client side business logic, introducing network vulnerabilities that are exposed through the client. As an example, a buggy client might respond to unauthenticated STUN transactions; such a client can be used as a relay for launching DOS attacks against a target.
The third reason is one of intellectual property. Voice and video communications systems in particular utilize codecs and technologies which are laden with patents. If, after deployment, you are sued for patent violations, and as a remedy you need to remove the offending technology, you will not be able to do so (again, not without locking out the users on that version of the client). This represents a nearly unremovable piece of legal risk from the system.
The fourth reason is one of innovation velocity. Let us say you wish to introduce a new feature which improves the service, but this requires a change to the p2p protocols used by the client. If both clients in a call require the change (which is almost always the case), and only the fraction f of the users have the new client, the probability that the new feature can be used is f^2. This means that the overall value of the feature is relatively low until it is in use by the vast majority of the userbase. If you want to achieve even 50% penetration of a feature (meaning it can be used in 50% of calls), you need over 70% of your clients to have it.
This issue applies to embedded voice and video systems, such as wifi phones, teleconferencing systems, and so on. Traditionally these systems have had weak software platforms that did not allow for automated software upgrade. Indeed, consumer electronics products have not traditionally allowed for even manual software upgrade. Consequently, these devices literally represent an unmoveable, forever piece of tech debt that cannot even be eliminated with emails and warnings to the user. And, unlike apps, cutting those users off is much more damaging because they have spent dollars to buy a piece of electronics that is meant to provide communications.
Invariably in the lifetime of any successful communications service, there will be a need for some major upgrade. And when they day comes, you will be thankful for having automated upgrades across the user base.
Why is automated software upgrade so important? There are four big reasons: elimination of perpetual tech debt, elimination of security weaknesses, avoidance of IPR pitfalls, and preservation of innovation velocity.
The first reason is: every client you ship which you cannot force upgrade is a piece of tech debt which stays with you forever. Inevitably in a cloud service, you will need to modify your protocols and interfaces. This applies to client-server protocols but also to p2p protocols (e.g., RTP). If you cannot upgrade these clients, it means that the client-server protocols they support must be supported in servers indefinitely. But worse, the p2p protocols they use must continue to be supported in every other client - indefinitely. This means that, over the years of lifetime of the service, each upgrade of a client must remain interopreable with every prior version of the protocols that have ever been shipped. Consider then a service which upgrades its p2p protocols 3 times a year (a very conservative number). Over a five year lifetime there are 15 different versions of this protocol in the client. From a testing perspective, there are now 15^2 or 225 different permutations of client versions which must be verified!
In other words, non-upradeable clients represent a technical debt which actually grows linearly over time for client-server protocols, and grows exponentially for p2p protocols. As communications services often use p2p protocols, communications applications are particularly susceptible to this tech debt.
The second reason is that you put yourself in a position of introducing security vulnerabilities you cannot patch (at least without locking out those clients). If a vulnerability is discovered that is unique to that instance of the client, and this vulnerability threatens the entire network, this is a vulnerability you cannot easily patch. In pure client-server systems the vulnerabilities primarily exist in the cloud. But communications systems utilizing p2p protocols often have substantial client side business logic, introducing network vulnerabilities that are exposed through the client. As an example, a buggy client might respond to unauthenticated STUN transactions; such a client can be used as a relay for launching DOS attacks against a target.
The third reason is one of intellectual property. Voice and video communications systems in particular utilize codecs and technologies which are laden with patents. If, after deployment, you are sued for patent violations, and as a remedy you need to remove the offending technology, you will not be able to do so (again, not without locking out the users on that version of the client). This represents a nearly unremovable piece of legal risk from the system.
The fourth reason is one of innovation velocity. Let us say you wish to introduce a new feature which improves the service, but this requires a change to the p2p protocols used by the client. If both clients in a call require the change (which is almost always the case), and only the fraction f of the users have the new client, the probability that the new feature can be used is f^2. This means that the overall value of the feature is relatively low until it is in use by the vast majority of the userbase. If you want to achieve even 50% penetration of a feature (meaning it can be used in 50% of calls), you need over 70% of your clients to have it.
This issue applies to embedded voice and video systems, such as wifi phones, teleconferencing systems, and so on. Traditionally these systems have had weak software platforms that did not allow for automated software upgrade. Indeed, consumer electronics products have not traditionally allowed for even manual software upgrade. Consequently, these devices literally represent an unmoveable, forever piece of tech debt that cannot even be eliminated with emails and warnings to the user. And, unlike apps, cutting those users off is much more damaging because they have spent dollars to buy a piece of electronics that is meant to provide communications.
Invariably in the lifetime of any successful communications service, there will be a need for some major upgrade. And when they day comes, you will be thankful for having automated upgrades across the user base.
RSS Feed