Archive | RTCWEB RSS for this section

W3C & IETF | WebRTC – Joint Face to Face Meeting

There might be a joint IETF/W3C WebRTC F2F meeting in May, somewhere on the North American East Coast.

From the W3C Chairs…

——

There has been some feedback on the dates. We propose to shift the
potential f2f meeting one day earlier to reduce the overlap with a 3GPP
meeting.

The proposed dates for the meeting is therefore 19-21 of May (Mon-Wed).

Stefan for the chairs

On 2014-01-29 09:20, Stefan Håkansson LK wrote:
> Hi all – and sorry for cross-posting!
>
> The chairs of the WebRTC WG (and the Media Capture TF) and the chairs of
> the IETF rtcweb WG are considering an joint f2f meeting. The dates we
> chairs have arrived on as feasible are May 20-22 (Tue-Thu). We are
> considering to split up the time between W3C and IETF across all three
> days. We have not yet discussed how to split the W3C time between WebRTC
> and the Media Capture TF at all yet (and perhaps we end up in focusing
> on the WebRTC WG since that part would probably benefit most from a
> joint meeting with the IETF rtcweb WG).
>
>
> The message at this stage is: please take note of these dates in your
> calendar now.
>
> The target region for this interim would be East Coast of North America,
> but we have at this stage no host or set location. If you are willing to
> host, please contact the chairs.
>
> We haven’t decided on this f2f meeting yet, and appreciate your input
> into holding one. The goals of the meeting would be to advanced the
> state of the core documents we need to finish up.
>
> Stefan for the chairs
>

The first ORCA CG meeting!

Here are the ORCA Community Group meeting details for our very first CG meeting.

Time: Thursday, February 20, 2014 10am Pacific (UTC−08:00)

Location: Hangouts

Agenda
===============
• Introduction to the CG
• Quick review of progress to date
• Overview of meeting objectives
– Existing proposals review
– New proposals & review
– API discussion
• Closing remarks
• Action items

NOTE: If you are on the public mail list but have not yet joined the Community Group but would like to attend the meeting you may certainly do so. However, if you are planning on making a contribution you will need to join the CG and make those contributions on the mail list.

Here is the link to the current CG participants and a link to join:
http://www.w3.org/community/orca/participants

Looking forward to seeing you!
/Erik

Live Blogging – IETF 88 – MTI Video Codecs

Chair: Taking the discussion back to the list.

Harold: We are witnessing a massive abuse of IETF policies. We have spent months on this.

Long line at the mic now

IMG_3040

IMG_2053

IMG_3706

Consensus Call:

NEITHER CODEC WAS SELECTED

Consensus Call:

VP8 – about 30% of the room

Jabber: 30 for VP8 and 10 for 264

Consensus Call:

H.264 – about half the room

Chair / Ted Hardie:

Regarding the consensus call, raise your hand for either or both but not neither. This is not a call but simply calrification

IMG_2892

Chair / Cullen: Agreed, hugs coming your way.

Martin: Keep in mind there are some that can’t get up and talk about that.

Chair / Cullen: We want to ask if you can’t live with either one of these codecs please get to the mic.

Tim Terryberry: Re: JR we need a royalty bearing codec if webrtc is to take off. I don’t think I need to tell the people in this room how excited everyone is about video in a browser without a plugin, ll of those are VP8.

Justin ? : Risk and Trust. Free codecs sounds good but today that’s not a reality. One of the advantages of going through an SVDO process is that the members must declare IPR, free codecs do not go through that. VP8 is not a free and the wind codec, it’s owned by Google. Google controls all of what VP8 is, can they be trusted. Who has implemented VP8 from the spec, not source.

?? – Technology is for people. The decision is for what we have today, not yesterday. Google has done a great job.

Harold Alvestrand: If people think that this announcement from Cisco of “later to be provided code” then I have real issues with the IETF process. Sooner or later we should find a way forward to rely on un-encumbered patent- less codecs, and if not now, then when?

Eric Rescorla: Mozilla intends to support 264 and VP8. We intend to support 264 via Cisco’s code/plugin on desktop. We will try hard to use the hw codecs since that works better on mobile. The user experience, during the install the codec will be installed (part of the install process). VP8 will be shipped with both mobile and desktop.

Bernard Aboba: It’s ok JR we do love you, hugs later.

Blackberry ?: Like the idea we would have a track towards better quality. The license is a big issue. VP8 is not a specification in the MPEG LA, but since it’s not there we have no mitigation there so we can’t make VP8 the MTI.

Randell Jesup: Those who are not making a browser but instead a server like asterisk or the like, their users would also have to download this plugin codec as well. It’s unclear if this would fall into the personal non-commercial use category. IT is not going to like this either, dealing with plugin codecs will make their lives potentially rather difficult.

JR: Arguing that we must choose a MTI codec or they can’t ship

Robin Raymond: I think it’s great that this new 264 codec is out there but if we make it mandatory the little guys lose. Mobile can’t download a binary, it must be part of the app before deployed. If you need H.264 you can add it if you need it but don’t force that royalty bearing codecs on all of us.

JR: Users don’t need to get plugins, apps do that.

Dean Willis: I don’t build browsers. For the last 7 years I have made my career on IPR consulting. If we were to pick 264 as MTI and since Cisco is not part the MPEG LA there seems to be risk there. Seems to me no choice works as well.

Roman Mahy: The most compelling items were the embedded platforms. My experience it was at one point very hard to find hw accelerated encoding, in the past.

Peter Thatcher: We turned on transcoding for a well known chat service and no one noticed. We are better off allowing the market to decide as Martin indicated months ago.

Justin Uberti: Regarding Adam’s comments regarding someone recording calls does not the understand the current laws. If you want to ship h.264 you can, no one is stopping you but not as the MTI codec.

John Peterson: This Wg has made plenty of decisions re: interop and we have saddled this WG with SIP /OA, but I think we should go with H.264

Roberto ?: The bias seems to be present, that larger companies have an easier time sending people here. If you choose to make 264 the MTI you are cutting out the small guys. I think the best option is to choose neither.

Matt ?: There are plenty of lawsuits against 264 so to say there is no risk with 264 that is simply not true. External plugins are not cool.

Ted Hardie (independent) : I offered JR a hug as he seemed to feel the free 264 effort was not appreciated. One of things we were trying to avoid is a plugin scenario and this (other things were added) is the reason we can’t invoke 264 as the MTI video codec. Royalties will push away numerous developers, big and small. Since 264 is now free (not free from royalty), we can add that codec as a non-mti codec.

JR: Transcoding degrades quality.

Martin Thompson: Let’s stop messing about with semantics, 264 is clearly the correct choice here so let’s get on with it.

Chair / Cullen Response: That was put to the list months ago and no one came forth with a proposal so that is not on the table today.

Jeremy ?: We could also consider both codecs.

Jean ?: Calling Nokia to the mic to clarify why there is a patent claim on VP8 and not on 264.

Peter Thatcher: Seems there are 2 broad categories, H.264 is better and the patent argument. The first is simply perspective and the second the patent being mentioned with Nokia is not resolved and if we are making a decision to implement 264 maybe those making that decision should wait until that is resolved.

Justin Uberti: Interop is misunderstood. Transcoding is cheap so that does not hold in the commercial world. VP8 is shipping in plenty of endpoints. Hardware Codecs are quite a ways off, there is LOTS of works that needs to be done here.

Monty Montgomery: If we go down this 264 path we are staking our future on a binary law environment.

Harold: To Cisco, please publish your findings

Cisco: Certainly

—-

Open Mic

JR / Cisco Conclusion

IMG_1202

JR Arguing Risk Analysis

IMG_5547

JR Arguing Risk Assessment

IMG_3772

JR Arguing Distribution

IMG_2881

JR arguing the results in Germany (re: Nokia VP8 patent being put down in Germany) may or may not be a consideration

JR arguing that VP8 is a target for patent trolls

JR arguing patent risk

IMG_0272

Distribution

IMG_6600

JR arguing both codecs perform nearly the same so let’s get past that

IMG_0263

Justin asking, which of these represent (slide below) actual Real-time encoode/decode

Cisco response: much smaller percentage

IMG_3488

H.264 vs VP8 Deployment & Standard

IMG_9582

H.264 Shipping Date

IMG_4600

Jonathan Rosenberg on H.264 for Cisco is at the mic

IMG_2914

—- that was fast, thanks Harold! —-

Harold is at the mic..

IMG_2913

NOTE: This post may not be entirely accurate. I am not the fastest typist in the world and I ad-lib when I can to get the general gist in the post.

WebRTC, SIP and Open Standards

Patience, not something we are good at.

Some of the SIP proponents out there are not very happy about a recent JavaScript Object Rationale Draft that was published on the IETF RTCWEB mail list ahead of the WebRTC Expo in Atlanta.  Full disclosure, I am one of the authors of that draft.

So, what’s all the hub-bub? Some of the reasoning seems to be..

  1. SIP and XMPP are the standards, everything else should take a backseat.
  2. The current WebRTC model should be the priority, stop asking for changes, you are just getting in the way of progress.

I understand the reasoning, I used to be one of those SIP advocates and I still believe that SIP has its place. To say that SIP and XMPP should rule all is just a bit much.

The one thing I am rather sure of is that SIP will not be the signalling protocol that ultimately ends up powering web communications.  It’s just not practical.  This doesn’t mean that SIP won’t be part of WebRTC, it just means that eventually we will move towards a more web-centric model.

To be clear, we are not against SDP in WebRTC.   In fact, we believe that any API proposal should have both a lower-level Object model and also provide real support for SDP at a higher level.

To that end, we have created a new Object-RTC draft proposal that outlines this model in detail, which also supports SDP Offer / Answer.  Yes, you can have have your cake and eat it too. This draft is about JavaScript, SDP (not baked into the browser) and the Open Web.

The question is, “When is the best time to submit the Object RTC proposal to the IETF and accompanying API docs to the W3C?”

We are not hell-bent on derailing the current progress being made in the respective working groups (contrary to what others may think).  So potentially, you may not see the Object RTC draft in the wild before the conclusion of the next IETF meeting in Berlin, only a few short weeks away.

Here’s to making marked progress on v1 in Berlin so we can get on with 2.0.

WebRTC JS Object API Model

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.

SDP inside WebRTC is bad for SIP

WebRTC Hamster Car

For those who don’t know, SDP is an old school standards-based text format (pre-1998) for describing media, codecs, state and networking information offered by devices for use in real-time communications and more recently as the proposed format for with WebRTC. I’ve written in the past about my disdain for SDP. To me, using SDP inside the browser for WebRTC seems akin to requiring all new computers use the graphics processing unit from the Commodore 64 for all future graphics engines. As cool as it might have been in its day, it is not exactly up to the task anymore and should be left to the realm of nostalgia.

It seems the idea for using SDP from within WebRTC was to allow SIP vendors to take SDP from their devices and shove it into the browsers and immediately be able to communicate between browsers and SIP devices and to offer the JavaScript guys a simple API to program against. Sounds great, right?  Wrong.  The browser’s SDP and the SIP device SDP is already diverging in their compatibility. Be it Trickle ICE, CODECS, security, or newly proposed “features”, realistically few SIP devices are going to be compatible out of the box or remain compatible for long using SDP. Likewise, providing a simple API for JavaScript developers could have been accomplished by providing a JavaScript library, similar to the way jQuery works to abstract and simplify DOM manipulation (and many other things). In other words, the primary reasons for using SDP in the browser are negated.

My original thinking was that the SIP guys would really love SDP in the browser since SDP is the primary media description format they use. But I must recast my opinion to say it’s really bad for the SIP folks as well. Here’s why…

  • An increasing need for Session Border Controllers: As it stands, the SDP that comes from SIP devices will need to be re-written and perhaps even put through some kind of Session Border Controller (SBC)/Proxy to maintain compatibility. SIP devices could face update cycles tied to browser updates. There are some companies in the industry who sell proxies that would greatly benefit from compatibility issues (as their role is to fix them) but I would hate to think that the IETF/W3C has been usurped by those vendors to push a solution that is not to benefit the entire internet industry and end users.
    .
  • SIP feature-creep: One thing I do know about SIP vendors is they love to add their own extensions to SIP to add their favourite competitive features they offer with their devices/networks. This allows them to claim “support” for something their competition does not support. To that end, I’ve noticed a continuous stream of feature requests to the browser vendors from the SIP world (and I’m certain the alignment to a SIP vendor’s own preferred feature is pure coincidence).

All the demands being put onto the browser vendors to add feature after feature truly scares me. As I foresaw, the innovation of features is tied to the release cycle of each browser binary being built, upgraded and rolled out to end users on each platform. Instead of features being added by by the programming language available inside the browser (JavaScript) which is dynamically updatable, features are now going to have to crammed into the browser binary because of modifications required to the SDP. What could have been simple change in JavaScript on a webpage is now tied by the innovation curve of the IETF/W3C tracks and each browser implementing these features equally across all platforms (and let’s not forget to including mobile in that list).

The irony is that if the SIP vendors had insisted that the browsers only offer a good core media/RTC engine, they could have implemented many of the features they now demand from the browsers vendors themselves without waiting for Google, Mozilla, Opera, Microsoft and Apple and the rest of the industry to agree. Talk about a SIP vendor’s dream in being able to offer some unique feature for their network! But now they have to wait and wait and hope and whatever ends up being released in the browsers will work for them and not introduce even more problems and incompatibilities to their networks.

Browser vendors will become the choke-point.

Worse, browsers vendors will be reluctant and cautious to change SDP for fear of “breaking things” within existing networks if the SDP / WebRTC becomes used broadly. If SIP vendors could understand that writing SDP in the JavaScript layer was in their own best interest, they would get behind the idea of dropping SDP entirely from the browser layer and instead agree to generate their network compatible SDP from within the JavaScript layer exclusively.

Microsoft argued so strongly against SDP and offer/answer, they have not agreed to support WebRTC and instead produced a competing specification called CU-RTCWeb. Their proposal starts from the premise of having a good media engine/RTC controllable at a lower layer would be far better for the industry and they have (so far) not released their Internet Explorer browser with WebRTC support. Whatever your feelings about Microsoft or their particulars of their proposal, they are right about SDP offer/answer and without their market share being onboard, it will hurt WebRTC’s adoption rate, especially in the Enterprise. Apple is sitting on the sidelines giving no indication their position while the industry sorts this out. I’d love nothing more for the industry than to have all vendors on the same page and agree to implement “something” usable, but it seems the SDP offer/answer model is not helping and in fact hindering that effort.

Where do we go from here?

As much as I hate to say it, I think we need to hold off on releasing WebRTC as it is until we have a lower level API. SDP offer/answer is not going to cut it for the initial release, this first version of the standard needs to live on for at least a few years. We must deprecate the current WebRTC API in favour of a more suitable low-level replacement API. The revision should focus instead on the extensions that can be added in the JavaScript layer and only put the necessary hooks in the browser at the most basic level for a media and RTC engine to be controlled. Let’s not hamper innovation!

If we need compatibility with the current WebRTC API it would be easy to create a JavaScript shim that supports the current API and allows a more long innovative approach. If there is interest in creating such a shim, I would be more than happy to be part of that development effort.

Cross-posted to IETF RTCWEB Mail list

Written by Robin Raymond
Edited by: Erik Lagerway

Video: WebRTC Introduction (revisited)

For those who missed this video the first time around, here is a great introduction to WebRTC (Real-time Communication on the web via HTML5 & JavaScript) from Cullen Jennings, Cisco Fellow & Co-chair of WebRTC & RTCWEB Working Groups in the IETF / W3C & advisor at Hookflash.

Cullen covers plenty of ground, focusing on the standards work surrounding this newly proposed standard that is WebRTC. A must watch for those interested in WebRTC. Sadly, there has been zero progress regarding MTI video codecs since this video was shot/uploaded 8 months ago. This MTI video codec issue really needs to be put to bed at the next IETF meeting in July.

%d bloggers like this: