Job: WebRTC Developer

At Hookflash we make it no secret that we are true believers in WebRTC. We are looking to grow our team of developers to assist in bringing Hookflash to the web.

Here is the posting…

The Hookflash team is looking for passionate, team-oriented and self-motivated Developers to help us bring the Hookflash experience to the Web. You will have a chance to integrate Hookflash solutions and WebRTC with the support of the backend services group using Hookflash & OpenPeer technology.

You will work in dynamic environment with a team of true professionals participating in defining, designing, developing, testing and documenting Hookflash for the modern world. You will work with colleagues in Eastern Europe, Canada and USA on Browser related solutions cooperating closely with colleagues developing Hookflash cross platform core library, the Audio / Video team, the User Management team and the Hookflash WebRTC team.

Responsibilities:

  • Design and maintain robust and loosely coupled application code in collaboration with the team architect.
  • Lead development by implementing most critical parts of the application.
  • Understand Hookflash software development process and perform all required and otherwise useful practices.

Qualifications and Experience:

  • BS/MS in Computer Science, Information Systems or similar.
  • Extensive experience developing rich web client applications.
  • Real world experience developing HTML5 UI’s including rich interaction based on JavaScript
  • Java or C++ experience would be a strong advantage.
  • Self-direction – must work independently to develop application code. This role demands proactive, ‘can-do’ nature.
  • Self-management – Must be highly organized and be able to prioritize work effectively. Successfully engage in multiple initiatives simultaneously.
  • Team-orientation – Able to put team interests above personal, help team to move faster all together and take personal responsibility for the whole team result.
  • Excellent problem solving and analytical skills
  • Experience in agile software development methodologies: SCRUM
  • Experience in applications that cross (and depend on) multiple client environments (e.g. variation in device driver, network connectivity etc.) would be a benefit.

All Hookflash job postings can be found here..

http://hookflash.com/join/

Video: Get on the #WebRTC bus or get run over!

#Hookflash video call with Cullen Jennings (aka Fluffy - Chair for the  IETF Working Group - RTCWEB) today. We discussed many items on the hit list for WebRTC / RTCWEB and the recent IETF 83 meeting in Paris, held last month.

It was interesting to hear Cullen call out to everyone, “..pay attention or risk getting run over by the WebRTC bus!”

A few of the questions asked..

  • What is WebRTC and why is it important?
  • What is the difference between WebRTC and RTCWEB?
  • Who are the driving forces behind this new technology?
  • What does WebRTC mean to the average person?
  • What problems are left to resolve eg. Video & Audio Codecs, Signalling, Security, Identity?
  • Will there be verified identity providers in this model like SSL cert providers?
  • When will we see WebRTC used by most app and web developers?
  • When will we see WebRTC hit mainstream adoption?
  • Who are the big players?
  • What does this mean to SIP or P2PSIP?
  • Where does Microsoft / Skype or other P2P offers fit in?
  • Where does Apple on mobile devices and WebKit fit in?
  • What about Google & Hangouts?
  • How would non-SIP players use this technology?

Thanks for the time Cullen!

Posted by: Erik Lagerway
Hookflash Co-founder

IETF - RTCWEB

W3C - WebRTC

@cfluffy @hookflash @elagerway

WebRTC - VUC Call

Speaking of WebRTC, here is the most recent VUC (VoIP Users Conference) call recording on the same topic…

Contributors: Randy Resnick, Tim Panton, Dan York, Jason Goecke, Serge Lachapelle, Justin Uberti, Karl Fife, James Body, Dean Bubley, Erik Lagerway.

If I have missed anyone, my apologies and please msg @elagerway so I can add you.

/Erik

You are here “.”

We live in what is shaping up to be one of the most active periods in the evolution of communication and social interaction.

Social Media is in a total frenzy (billions of users now) and IP Communications is seeing some of the most interesting innovation (WebRTC) and development activity it has seen, arguably in the history of IP itself.

Feels good to be part of it! We can’t wait to get Hookflash out into the market! We are moving towards the next evolution in mankind’s need for social interaction and communications.

Can’t wait for the wireless carriers to get fully on board with this all IP world we live in today. An all data-centric wireless offer on a good smartphone, where I get to assign the the native phone app to a provider of my choosing, for my own voice and video communications, must be imminent, don’t you think ?

RTCWEB / WebRTC video codec debate

There is a storm brewing in the IETF and W3C in relation to video codecs to be included by the browser vendors et al, as part of the proposed RTCWEB standard.

I applaud the recent plea by Dean Willis @dean_willis, who proposed that we agree on a mandatory baseline codec that is not encumbered by royalties or potential IPR issues…

In today’s meeting I made a plea for a mandatory baseline codec that is approachable to the small developer without the cost and IPR risks of either H.264 or VP8.

I believe that some sort of baseline codec is required to jump start the protocol. It’s OK if this isn’t the best possible codec. Market forces will assure that commercial implementations converge on a higher quality when the market requires it.
While I proposed today that H.261 could serve as a baseline, we know this would be “extremely basic”. In other words, it might not pass the “good enough to use” test required for a successful launch.
Stephane and several others suggested H.263 as an alternative during the after-meeting chat. While it is not as IPR-safe a choice as H.261, it is relatively mature and the known challenges have generally failed. Implementations are reasonably available and should make it possible for smaller implementers, students, and hobbyists to play ball. It’s not all that network efficient and is outright piggy at higher resolutions, but it probably works “well enough to use.”
So I propose we set H.263 as the baseline ( I expect a bit of profiling may be necessary to further qualify the baseline) and run with that for now. If the situation changes, we can always replace it before final publication.
—
Dean

The problem I see with this is that H.263 is a lower quality codec and quality is king, especially on new iPads where consumers outlaid a heap of cash. It’s also still not clear if this codec is completely unencumbered of any potential IPR claims.

Although, to Dean’s point, we need to agree on basic codecs in order to get this thing out the door, so he has my vote on that one.

Currently, Google’s webrtc.org project uses the open sourced GIPS code, which includes the ISAC codec for Audio. Google also opened up the IPR on their webm project Video codec, VP8.

VP8 is inline with H.264 in terms of quality and compression (close enough for a discussion here at least). H.264 has clearly defined royalties making it a potentially poor choice for developers looking to deploy a product for free or low cost. The developer could end up handing over most of it’s revenue to the MPEG-LA and associated IPR holders of H.264. Even then it’s not clear when receiving the green light from the visible patent holder that a developer will be in the clear, consider the exiting Motorola vs. Microsoft lawsuit.

So why then would we not just use VP8? After all, Google just opened the flood gates right?

Additional IP Rights Grant (Patents)

“This implementation” means the copyrightable works distributed by Google as part of the WebM Project.

Google hereby grants to you a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, transfer, and otherwise run, modify and propagate the contents of this implementation of VP8, where such license applies only to those patent claims, both currently owned by Google and acquired in the future, licensable by Google that are necessarily infringed by this implementation of VP8. This grant does not include claims that would be infringed only as a consequence of further modification of this implementation. If you or your agent or exclusive licensee institute or order or agree to the institution of patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that this implementation of VP8 or any code incorporated within this implementation of VP8 constitutes direct or contributory patent infringement, or inducement of patent infringement, then any patent rights granted to you under this License for this implementation of VP8 shall terminate as of the date such litigation is filed.

See also: Software License

Hmm, not so fast.

The IPR issues surrounding VP8 could be even more foggy than H.264. Here Paul Jones describes some of the issues he sees in VP8 to Basil Gohar and the rest of the list…

Basil,


> What you are asking for is something no one in the media industry offers
> for something comparable.
I know, but the reluctance to do so means that Google knows that there *may
be* IPR on VP8.  This is just the facts of life.  I believe it’s extremely
important that people know and understand that nobody knows the IPR
situation with VP8.  If they did, they would offer indemnity, because there
is nothing to worry about, but nobody can.

> As was pointed out elsewhere on this list, even
> the H.264 standard has been updated to include additional patents over
> time deemed to be “essential”.  One could be non-infringing in the past
> and suddenly find yourself infringing.
Indeed, but I have a significantly higher level of confidence that I can
identify all of the legitimate companies with IPR on H.264, whereas I
haven’t a clue where to start (outside of Google) for VP8.

So where does this leave the developer? The WebRTC proposed standard hangs in the balance and anyone who is working with Google on the webrtc.org project must be asking themselves this question as well?

Would Google fight for the developers if an IPR claim arose regarding the implementation of VP8?

In answer to one of Paul’s comments, Jean Marc Valin had this to say…

> If I owned IPR on VP8 (which I don’t personally; can’t speak for my
> employer), I certainly would not tell you and I would not join a patent
> pool, either.  I would wait until you adopt VP8, build it into software and
> hardware products, have it massively deployed, and then I’d come along and
> collect my royalties.  There is absolutely no financial incentive for an IPR
> holder to join a patent pool.

I assume this is why we’ve seen all these lawsuits against Google,
Microsoft, Cisco, Apple… over their use of Vorbis and Speex, right?
Seriously, I can count at least 10 free AV codecs and none of them have
had any patent lawsuits that I’m aware of.

So, as of today, it is still very unclear what will make it into the browser, although it might be safe to assume that Google will include whatever mandatory baseline codec is selected by the IETF Working Group but will also include VP8. It seems clear that they will not include H.264 at this point, after all, they yanked it out of YouTube, or did they? Hmm, maybe it’s not so clear.

And recently Mozilla seems to have had a change of heart around H.264.

Well, we are not waiting for the decision to come down, that much is certain. There is safety in native software, which is where we will focus until this mess is sorted.

But make no mistake, we are watching closely and will be participating more in the standards discussions as things progress.

W3C: http://www.w3.org/2011/04/webrtc-charter.html
IETF: http://tools.ietf.org/wg/rtcweb/

/Erik @elagerway