WebRTC Q4 2013 – W3C, IETF, Expo Events
For anyone following WebRTC, Q4 2013 will be a busy time. Here is a list of the major events happening related to WebRTC:
IIT RTC Conference and Expo – Chicago, IL
October 15-17
http://www.rtc-conference.com/
Realtime Conference – Portland, OR
October 18-19
http://2013.realtimeconf.com/
(Standards) IETF 88 – Vancouver, BC
November 3-8
http://www.ietf.org/meeting/88/index.html
(Standards) W3C TPAC – Shenzhen, China
November 11-15
http://www.w3.org/2013/11/TPAC/
WebRTC Conference & Expo – Santa Clara, CA
November 19-21
http://www.webrtcworld.com/conference/west/
WebRTC Exhibition and Conference – Paris, FR
December 10-12
http://www.uppersideconferences.com/webrtc2013/webrtc2013intro.html
WebRTC Expo – Google Media (GIPS) Stack FTW!
At WebRTC Expo, watching a great closing panel on “where we go from here”. Craig Walker of Firespotter / Uberconference makes some great points. If Google had not open sourced the GIPs media engine, none of this would have happened in the time frame it has, it has made this technology accessible not only for browsers vendors but for the independent developer.
Great show, the next one will be even better.
WebRTC JS Object API Model
Robin Raymond has put together a new draft that proposes the replacement of SDP O/A with a JavaScript Object API model within WebRTC.
The draft:
The WebRTC JavaScript Object API Rationale
Whereas:
The WebRTC JavaScript Object API & Shim document will be along shortly (days – not months).
We wanted to get this initial informational document out right away so everyone that has any interest would be able to review the concepts and comment before we get too far along on the actual API.
“No SDP Offer/Answer” is a concept that has been bantered about for some time. It continues to rear its ugly head within the IETF and W3C Working Groups. There is evidence that some major browser vendors will not back the current SDP O/A methodology at all, but some of us continue to pin our hopes and dreams on SDP O/A nonetheless.
We are told by the developers we need something that will not only pass muster with them but will also be something that can be extended and innovated upon, uninhibited by large browser vendors or any vendor for that matter.
According to many, real adoption of WebRTC will not happen if we continue to force everyone to use this SDP Offer/Answer methodology. It is clearly blocking our way forward and the amount of specification documentation remaining needed for the browser vendors to produce a compatible SDP based WebRTC engine in a browser is much more daunting than most are willing to admit.
It’s time for a change.
What does that mean? It means we need to rewrite a portion of the current WebRTC specification and WebRTC API, which also means that many of the demo apps running out there will need some level of modification. Which is O.K. It’s better to break a few demo apps now than to proceed knowing there is a material flaw in the design, precluding the rest of the web from playing along and causing untold pain in future development.
A WebRTC JavaScript Object API Model could mark a significant turning point in the history of WebRTC.
Long live WebRTC.
Google’s open WebRTC media stack ported to QNX / Blackberry 10
The WebRTC media stack has been ported to QNX / Blackberry 10 as reported hy Hookflash in this Press Release below.
This does not mean that WebRTC browsers will now begin communicating with Blackberry apps written using the Open Peer SDK, well… not today anyhow. What it does mean is Blackberry 10 developers can write apps using this new SDK to enable P2P voice, video and messaging, across Blackberry and iOS platforms using their own user identity model or mashed up with social identities.
In the sample app (pictured above) running on a production Z10 and a Alpha Z10 device, Facebook was used to map IDs.
Here is the Press Release…
BlackBerry Live 2013, Orlando Florida – May 13, 2013 – Hookflash announces beta availability of Open Peer Software Development Kit (SDK) for BlackBerry® 10, providing developers with an effective way to integrate high quality, secure, real-time, voice, video and messaging into their own BlackBerry 10 applications.
“The Open Peer SDK for BlackBerry 10 enables a completely new generation of communications integration on the BlackBerry 10 platform,” explains Hookflash co-founder Erik Lagerway. “The Hookflash team has worked tirelessly to build this toolkit and port the WebRTC libraries to BlackBerry 10. BlackBerry developers and enterprise customers can now integrate high quality, real-time, peer-to-peer (P2P), voice, video and messaging into their own BlackBerry 10 applications. People just want good quality voice, video and text communications embedded in whatever they’re doing. Open Peer enables progressive developers in medical, finance, gaming, travel and many other verticals with this next evolution of integrated P2P communications on BlackBerry 10 smartphones.”
“BlackBerry is committed to our app partners through an open ecosystem, strong platform and commitment to supporting innovation and invention,” said Martyn Mallick, VP of Global Alliances and Business Development at BlackBerry. “We are pleased to have Hookflash bring Open Peer to BlackBerry 10, enabling developers to add rich peer-to-peer communications in their apps, and enhance the customer experience.”
The Open Peer SDK for BlackBerry 10 is the most recent addition to the Open Peer, open source family of real-time P2P communications toolkits. The BlackBerry 10 SDK joins the existing C++ and iOS SDKs already available. Mobile developers creating applications across multiple platforms can now leverage the suite of Open Peer toolkits to deliver real-time P2P communications for all of their applications. The Open Peer SDKs are available in open source and can be found on Github (http://github.com/openpeer/).
Hookflash is a globally distributed software development team building “Open Peer”, new “open” video, voice and messaging specification and software for mobile platforms and web browsers. Open Peer enables important new evolution of communications; Open, for developers and customers to create with. “Over-the-top” via the Internet, where users control their economics and quality of service. “Federated Identity” so users can find and connect without limitations of service provider’s walled gardens and operating systems and “Integrated”, communications as a native function in software and applications. Hookflash founders, lead developers and Advisors previous accomplishments include; creators of the world’s most popular softphones, built audio technology acquired and used in Skype, created technology acquired and open sourced by Google to create WebRTC, and engaged inWebRTC standards development in the IETF and W3C.
Developers can register at (http://hookflash.com/signup) to start using the Open Peer SDK today.
For more information and an Open Peer/WebRTC white paper on please visit Hookflash http://hookflash.com
Press Contact:
Trent Johnsen
Hookflash
Press@hookflash.com
855-HOOKFLASH (466-5352) ext 1Hookflash enables real-time social, mobile, and WebRTC communications with “Open Peer” for integration of voice, video, messaging and federated identity into world leading software, enterprise, applications, networks, mobile and computing devices. Hookflash and Open Peer are trademarks of Hookflash Inc. BlackBerry and related trademarks, names and logos are the property of Research In Motion Limited. BlackBerry is not responsible for any third-party products or services. Skype is a trademark of Microsoft. Google is a trademark of Google. Other company and product names may be trademarks of their respective owners.
(full disclosure, I work for Hookflash)
H.264 for WebRTC MTI Codec
I have been supporting VP8 as the MTI codec in the WebRTC / RTCWEB WG, for various reasons including…
- Royalty Free (drives innovation)
- Open Source (Source code is optimized for RTC and readily available)
- Supported by a rather large company (Google)
It seems some of us may be changing our minds (myself included), for various reasons, eg…
- H.264 is prolific in RTC today. If we are to have interoperability with other endpoints out there we need 264.
- Open Source. H.264 optimized source for ARM and X86 its coming, Cullen said so 🙂
- Supported by many rather large companies (MPEG-LA for starters)
- VP8 IPR is coming under heavy fire. Nokia being one firm that has boldly stated that they hold patents on VP8 and will enforce them, and apparently there is at least one more VP8 patent holder out there that is keeping rather quiet, which is rather disconcerting.
- Since H.264 utilizes hardware acceleration, battery consumption on mobile devices should be lower as well.
- Quality is arguably better in some cases, this can be somewhat subjective.
So where does this leave the innovators that need free software to create free software? Great question, and here are some potential answers…
- If there is Open Source H.264 software out there that has been optimized for Real-time Communication (encoding and decoding in real-time) there are no “software” fees (excluding MPEG-LA), that is one less, rather large, obstacle.
- MPEG-LA (last I looked) has stated that there are no patent fees associated with deployments under 100k endpoints. This is great for smaller deployments but larger deployments could still have a problem here?
Some are saying that the bulk of all mobile devices that could support video have a t least one license for H.264 already, so why then would there be another royalty for H.264 on that very same device? This is an interesting argument and one that may in fact provide the innovative developers with a leg up when it comes time to debate the issue with the MPEG-LA. That being said, most innovative developers I know want nothing to do with legal debates.
There is also another factor to consider, many of the MPEG-LA patent holders are behind WebRTC, so why then would they shoot themselves in the foot and hamper adoption of WebRTC by litigating those who adopt it? There has also been talk of creating a new H.264 license in the MPEG-LA related directly to WebRTC / RTCWEB, which would be free of royalties. Talk is cheap.
Those vendors who only run one codec today will have likely already chosen H.264 for their existing deployments and will likely vote 264 as the MTI codec. At the end of the day, the prudent vendors looking for the most coverage in WebRTC interoperability will support both H.264 and VP8, regardless of which codec is selected as MTI.
After weighing all the options it seems (to me at least) that H.264 is the better choice today, now we just need an open source (with a BSD or MTI license or the like) H.264 implementation that has been optimized for WebRTC.
I am interested in hearing what the developers out there think about this. What do you think? Should H.264 be the MTI (Mandatory to Implement) video codec for WebRTC?
Update: IETF + W3C Interim Feb 5-7: WebRTC, RTCWEB and SDP
UPDATE
Although we could not participate (conflict in schedule), it would seem as though there is some progress being made..
– SDP (decision made to try Plan A, if that fails try Plan B, at least we got that far)
– dataChannel (createdataChannel before createOffer or createAnswer, some talk around supporting defined protocols, decent progress here)
– trickle ICE (more definition to the protocol, great progress here)
Here are the meeting recordings from Feb 6th, and Feb 7th.
(thanks to Cullen Jennings for posting this to the mail list)
_______________
Participants in the WebRTC & RTCWEB working groups will be in Boston Feb 5-7, hosted by Acme Packet.
Topics for discussion will revolve mainly around SDP & NAT traversal – namely trickle-ICE. What’s trickle ICE? Basically, with traditional “ICE” we have to gather all the candidates before we start negotiation, whereas with “trickle ICE” we would gather candidates while we negotiate, which means setup time for calls could be markably reduced.
What we will likely not see any forward movement on at this interim meeting is any decision around MTI video codec(s).
From the IETF mail list…
Ted Hardie offered this up as a reading list…
http://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation
http://tools.ietf.org/html/draft-alvestrand-mmusic-msid
http://tools.ietf.org/html/draft-holmberg-mmusic-sdp-mmt-negotiation
http://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp
http://tools.ietf.org/html/draft-rescorla-mmusic-ice-trickle
http://tools.ietf.org/html/draft-ietf-rtcweb-jsepYou may also want to look at the proceedings from the Atlanta meeting;
in particular, this was suggested as good background reading:
http://www.ietf.org/proceedings/85/slides/slides-85-mmusic-7.ppt
Cullen Jennings added to that…
Some more background reading that is useful context
http://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-05
http://tools.ietf.org/html/draft-ietf-rtcweb-overview-05
http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-10
and Emil Imov added more re: trickle-ICE…
Just a quick note to let you know that the trickle ICE draft has been
updated as per the discussions in Atlanta’s MMUSIC session. A new draft
describing trickle ICE’s usage with SIP has also been submitted:http://www.ietf.org/mail-archive/web/mmusic/current/msg10169.html
Hookflash posts now on Tumblr
I have decided to stop posting Hookflash content here, all of my new Hookflash posts will appear over at Tumblr.
/Erik
Hookflash Concert Tour
We had a great Hookflash shaker last night! Had a blast showing off our new baby with Trent, was such a pleasure spending time with everyone.
So, what’s next you ask?
Mountain View – March 7
SFO – March 16
SoMa – March 21
Hookflash Party – Feb 29th
Be there or be square! RSVP – Trent@hookflash.com
hookflash for iPad | early access
Update: Top 60 users selected
Thank to everyone for participating! We saw some great feature suggestions and general comments. We will be sending out a message to those selected by the beginning of February. We will also be updating our progress on Twitter and LinkedIn.
Thanks again!
-Erik
For those who signed up for the hookflash for iPad early preview, thank you for signing up!
We have received thousands of early access requests, which we take as a great sign!
But now we are faced with a dilemma.
Considering Apple limits us to 100 test accounts prior to launching in the app store, who gets in!? We need 40 accounts for our own internal use and testing. That leaves 60 accounts for our early access users.
It seemed clear to us that we should let our users decide who gets in. The process would have to be fair and would need to be publicly monitored so nobody feels jilted. So here’s the deal, if you want in, this is what you need to do…
- Follow @hookflash on Twitter.
- Tweet about the feature you would like to see most in hookflash for the iPad. Could be a design element, feature, interoperability request etc. Be sure to include @hookflash in your post.
- The top 60 people with the most Twitter mentions (must include @hookflash) before January 6 2012, will get a spot in the early preview.
Tweet as many times as you like. We will announce the winners the first week in January. Who knows, maybe your suggestion will make it into the product!
For those who win, see you in hookflash! Good luck to all who decide to participate.
Our very best wishes to everyone this holiday season!
Erik Lagerway
co-founder – hookflash
WebRTC.is 