Recently Cisco made significant efforts around open sourcing our H.264 implementation, including covering the MPEG-LA licensing costs for distribution and working with Mozilla to add support for H.264. However, in this attempt to unstick the logjam that has occurred in the standards bodies, the Internet Engineering Task Force (IETF) failed to reach consensus on the selection of a common video codec.
Cisco’s Jonathan Rosenberg explored this topic more in a recent Collaboration blog post. Read on to find out how we’re planning to move forward and why this conversation is definitely not over!
Tags: Cisco, collaboration, firefox, Google, H.264, html5, ietf, Jonathan Rosenberg, Mozilla, open source, video, WebRTC
Cisco recently announced that we would open source our H.264 implementation under favorable open source terms, and more importantly, provide a binary distribution of that implementation that could be downloaded and integrated into browsers and other applications. We said we’d cover the MPEG-LA licensing costs for this distribution as well. Mozilla responded by saying that, based on this, they would add H.264 to Firefox, using our technology.
Part of our motivation for making this announcement was to unstick the logjam that has occurred in the standards bodies. The Internet Engineering Task Force (IETF) is defining the standards for how real-time voice and video will work natively in the browser. Selection of a common video codec is part of that process. The group has been highly divided on this topic, with two camps – one (including Cisco), in favor of industry standard H.264, and others in favor of Google’s VP8 technology.
We hoped that our announcement, and Mozilla’s agreement to support H.264 as a common codec, would provide enough impetus to sway the standards to a concrete decision so that the industry could move forward. Alas, that was not the case. Despite what we felt was a fairly objective analysis on the reasons why H.264 was a better choice for the overall success of real-time communications on the web (click here for a recording), the IETF failed to reach consensus.
Obviously, we’re very disappointed by this. Read More »
Tags: Cisco, collaboration, firefox, Google, H.264, html5, ietf, Mozilla, open source, video, WebRTC
What’s new and exciting with EIGRP (Enhanced Interior Gateway Routing Protocol)? Actually, lots… First a bit a background on EIGRP.
EIGRP is an advanced distance vector routing protocol used extensively by enterprise customers. It is very popular because it is simple to deploy and support. Some major attributes are:
- EIGRP does not mandate many network design requirements and is therefore perceived as “forgiving” and “flexible”. For example, EIGRP does not require support for multiple routing sub-domains or Areas.
- While route summarization is a recommended best practice to minimize route table size, it is optional with EIGRP.
- EIGRP can scale to support thousands of routers in a Hub and Spoke configuration. The Hub and Spoke design is especially popular in WAN networks.
For additional information on EIGRP, please click here. There is also a great BLOG that compares EIGRP and OSPF that I think you will find informative and is posted here.
While EIGRP has a large customer following, some customers have hesitated because of concerns of EIGRP being “proprietary”, which would prevent them from multi-vendor network support. In some cases this has caused customers to design their networks to limit usage of EIGRP, even though they would like to deploy it ubiquitously. One result has been non-optimal network design and traffic flow, resulting from multiple IGP (Interior Gateway Protocol) redistribution points.
That brings me back to what is new and exciting with EIGRP. Read More »
Tags: EIGRP, Enhanced Interior Gateway Protocol, ietf, ietf working group, IGP, Interior Gateway Protocol, ipv4, IPv6, IPv6 deployment, OSPF, WAN, WAN networks
The communications industry has come a long way from fixed, inflexible telephone service optimized for voice to dynamic IP-based connections offering converged voice, data, and video capabilities. Now, both residential and business users are increasingly more mobile and distributed, as are the cloud-based services, applications, and content they want to utilize. Service providers must therefore support a more diverse customer base with more distributed content and applications across multiple geographies, yet still maintain a secure, reliable, and consistent quality of experience regardless of device and physical location.
In the face of greater traffic demands and the risk of becoming lower-margin “commoditized pipes,” network operators must react to three key challenges: Read More »
Tags: Cisco ONE, David Ward, ietf, ONF, Sanjeev Mervana, SDN, standards
”Each success only buys an admission ticket to a more difficult problem.”
-- Henry Kissinger
Following the early successes with network programmability, the natural question that arises is “where do we go form here?” Certainly some good things have been accomplished, but in many ways the real work is just beginning. David Ward just posted some musings on where we go next with programmatic interfaces for the network--its a good read and I encourage you to check it out.
Tags: Cisco ONE, ietf, ONF, SDN, standards