WebRTC

May 15th, 2013 by Dominick Accattato

What is WebRTC

In the world of disruptive technologies, WebRTC has quickly caught the attention of the web development community. WebRTC at its core provides real-time communication between browsers. The following represents the group’s mission statement:

WebRTC is a free, open project that enables web browsers with Real-Time Communications (RTC) capabilities via simple Javascript APIs. The WebRTC components have been optimized to best serve this purpose.

Our mission: To enable rich, high quality, RTC applications to be developed in the browser via simple Javascript APIs and HTML5.

Why was WebRTC created

WebRTC has humble beginnings but grand expectations based on source code that Google decided to open source. The original code came from two companies: Global IP Sound (for voice) and On2 (for video). These two companies were acquired by Google for the codecs and security based protocols for peer to peer streaming technology. On2 was the source for the webm project and codec.

Why is it interesting

WebRTC is interesting for so many reasons, but for real-time streaming developers it brings full circle what we have been working on for over 10 years. Previous to WebRTC, people were streaming with either their own proprietary technology or through a browser plugin. The most ubiquitous plugin was, and still is the Flash Player. Flash still remains today the best option for web conferences that want to maintain backwards compatibility with older browsers and leverage a full stack of streaming technologies.

However, WebRTC is steadily gaining momentum and will eventually overcome the advantages that Flash currently has in this space. It will take a bit of time for the technology to increase adoption, but it will eventually happen and many of the leading browser vendors are behind the movement. Especially since the standards are supported by the W3C and IETF working groups.

What are the current challenges?

Currently WebRTC has some challenges. First, it still needs wider acceptance and adoption. At this moment, only Chrome (Stable) and Firefox (Nightly) have support. Internet Explorer has expressed interest, but Safari has not made any indication that they would provide support. That said, if all the other major vendors end up supporting the standard, Safari would most likely follow suit.

Also, since the technology is largely peer to peer, there isn’t a great solution for a media server yet. In addition, the technology requires implementors install either a STUN or TURN server. A STUN server basically facilitates “hole punching” which is what is needed for NAT traversal through firewalls. A TURN server is basically a STUN server with extensions that allow it to also act as a fallback media relay server. Regardless, it’s still difficult to choose the right STUN/TURN server to work with, but I’m sure this will become more clear as the standards and implementors start to roll out more products.

In addition, there is still much work to be done on the specifications. The standards boards are continuing their efforts on the creation of their working drafts. These will eventually be published standards and RFC’s.

What are the main API Interfaces?

You can visit the following site for a good description of the API’s (http://docs.webplatform.org/wiki/apis/webrtc)

What about Flash Streaming?

I’ve thought about how this will affect the current ecosystem of Flash Streaming which basically dominates the video streaming on the Internet today. As Flash has a large adoption rate, it will continue to thrive and will even remain as a great backward compatible solution. At this point, I still feel like the Actionscript API’s are easier to work with and the aggregated technology behind Flash Streaming appears to be easier to work with, but that is a biased statement since I’ve been working with Flash Streaming for over 10 years.

Many groups are also still very interested in how WebRTC will affect Red5. I can only say that at this time, the Red5 developers including myself, are excited about the potential of WebRTC, and we plan to modernize Red5 to accommodate this new plugin-less approach.

Conclusion

So I hope I’ve drawn some attention to this very new and exciting technology. We at Infrared5 hope to put this technology to use for our clients. If you’re interested in a project based on WebRTC, just drop us a message.

More Information

Project Website: http://www.webrtc.org/

Google Code Project: https://code.google.com/p/webrtc/

WebRTC Blog: http://www.webrtc.org/blog

W3C Editor’s Draft: http://dev.w3.org/2011/webrtc/editor/webrtc.html

WebRTC Example: https://apprtc.appspot.com/?r=65920333

, , ,

The Project Discovery Phase, Dissected

March 14th, 2013 by Dominick Accattato

When clients first reach out to Infrared5, they are often extremely excited about turning their ideas into a reality. We share their enthusiasm and can’t wait to dig into the project details. However, sometimes, there are numerous great ideas and not a lot of concrete information. This can be true for any project — games to enterprise applications. When this is the case, we sometimes suggest a Discovery and Planning Phase.

The Discovery and Planning Phase allows both the client and our team leaders to work together to elicit requirements and document the system architecture in a way that is meaningful for developers, designers and the client. It is typically very collaborative in nature. This phase also ties in disciplines such as business analysis, domain driven design, technical writing and design.

It’s important to note that not every project requires a Discovery and Planning Phase. Not all discovery phases are set up the same way. Some clients have a very detailed understanding of what they are trying to accomplish. In these cases, the client may already have specifications, but they are unable to develop the very complex technical component. In these cases, we suggest a separate path; one in which a focused Proof of Concept is provided. (We will cover Proof of Concept in a future post.) For now, we’ll assume the client has a larger system and is in need of defining the project. This is what the Discovery and Planning Phase attempts to achieve.

What is a Discovery and Planning phase?
A discovery and planning phase allows for the client to have direct access to our senior software developers and/or creative lead in order to define project requirements. With these requirements in hand, our development and design team can investigate and document the software/design components of the project. The goal is to clarify scope and verify the parties are on the same page prior to beginning production. Another benefit of the discovery phase is that certain technical challenges may surface from these discussions. (Pioneering applications are a specialty of the house here at Infrared5.) These high risk items may lead to a phased approach whereby the highest risk items are given their own Proof of Concept phases. (This is discussed with the client so that they have an understanding of our findings and why we have suggested a multi project, phased approach.) In the end, clients have the opportunity to remove the high risk item if it doesn’t fit with their release date or budget.

Who is involved in the Discovery Phase?
During the Discovery Phase, the team consists of a project manager and technical lead who are in charge of assessing the technical challenges that lie ahead for the development phase. The technical leads here at Infrared5 each have their own expertise. For instance, if the client approached us with an immersive 3D game, we would allocate one of our senior game developers to the Discovery and Planning Phase. The same would be true of a complex web application. One of the potential benefits of using a group like Infrared5 is that we also maintain a diverse group of developers who are experts in their own field of discipline. From gaming to streaming applications, we employ a renowned team of developers and designers who are truly experts in their field. Also during this phase, our creative team works closely with the client in order to flesh out UI designs, experience design and branding needs of the project. The creative team helps clients define their goals and the best strategy to meet them.

What can be accomplished during the Discovery phase?
One of the common questions we get from clients is, “What are the benefits of doing a Discovery and Planning Phase?” In most cases, there are a few documents produced. These are the Technical Requirements and the Software Requirements Specifications. It can be noted however that depending on the needs of the project, this may only require one of the two or a hybrid of each. Another document which may be produced during the Discovery and Planning Phase is a High Level Technical Overview. Just as it sounds, this document is high level. It does not aim to get into too much detail at the software component level. Instead, it resolves the more general system architecture and specifies which components may be used for the development phase.
For gaming projects, there are different details to focus on and these must be determined before the developers begin programming. A Game Design Document is necessary for describing the game play and the mechanics behind some of the simulations. Often this requires the technical lead and game designer to work together.

For both gaming and applications, the creative team delivers initial design concepts and wireframes to be augmented later in the design phase. The creative team also works closely with the client in regards to the user experience.

Ultimately, the Discovery Phase ensures both parties are aligned before any, more extensive, design or development begins in later phases.

What is delivered at the end of a Discovery Phase?
At the end of the Discovery Phase, the three important documents delivered to a client are:
• High Level Technical Overview
• Technical Requirements Specification
Software Requirements Specification

In the case of a gaming project, the typical document would be:
Game Design Document

In the case of both gaming and application projects, the following design related material is provided:
• Design Concepts
Wireframes

Upon completion of the Discovery phase, Infrared5 has enough information to provide more accurate estimates and timelines for completion.Each of these documents are important and we suggest searching online in order to further your understanding of their purposes. This article illustrates what steps are taken and what is delivered at the end of our Discover and Planning Phase.

, , , ,

Red5 – Past, Present & Future

August 19th, 2010 by Dominick Accattato

Red5 is not Infrared5. Many have confused the two or assume it is one entity. Infrared5 was started by some of the original Red5 team, and does focus many services on Red5 development. However, that is where it ends.

Red5 is an open source media server that delivers live video/audio/data to a client application. In most cases that client happens to be the Flash Player, however there isn’t anything stopping a keen developer from streaming to other endpoints, i.e. Java, Silverlight, HTML5. Since the server is licensed under the LGPL, companies have the liberty to use Red5 in proprietary products. The main restriction placed on Red5 is that any modification to the original source code must be donated back to the project. This ensures that the project continues to thrive with patches and helps us deliver a more stable product to the community.
Read the rest of this entry »

, , , , ,