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
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 next IETF meeting will be held in London, England
March 2-7, 2014
Hilton London Metropole
225 Edgware Road
London, UK W2 1JU
Tel: +44 207 402 4141
Here is the draft agenda for RTCWEB as sent from the Working Group chairs today…
Here is very rough draft of what we currently have on the agenda.
Note that the first hour of wed conflicts with some transport stuff.
Thanks, the chairs
Draft Agenda Version 1
Tuesday 9 -11:30
Chair Admin: (chairs) – 10 min
Data Channel: (who ???) – 80 min
<Need Open Issues Here>
Transports – Harald – 45 min
- The appropriate form of the reference to draft-dhesikan
- MUST support ALTERNATE-SERVER
- MUST, SHOULD or MAY on TURN TCP candidates
- MUST, SHOULD or MAY on ICE TCP candidates
- Whether this draft should have normative references on anything SDP-related (which, conceptually, are above the transport level).
Stun/DTLS heartbeat discussion: Dan Wing – 15 min
Chair Admin: (chairs) – 5 min
JSEP: Justin – 90 min
Update from RMCAT – RMCAT Chairs – 10 min
Sec / Sec Arch: Eric Rescorla – 30 min
RTP usage: Colin -15 min
- Prepared for WG Last Call – Issues with latest changes?
NAT-Firewall: Still trying to resolve what parts of this are in this WG – Andy ( ?? minutes)
Here are the ORCA Community Group meeting details for our very first CG meeting.
Time: Thursday, February 20, 2014 10am Pacific (UTC−08:00)
• 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:
Looking forward to seeing you!
There’s a lot of noise and plenty of dust getting kicked up around WebRTC these days. Every hour it seems there is another company announcing support for WebRTC or have built an app that uses the technology. In many cases it’s an extension to the existing offer, where WebRTC is leveraged as a web-based SIP softphone for instance.
For the love of Pete, does the world need yet another phone?
What does excite me is when I start thinking about the effects that WebRTC and ORTC will have on rich media OTT (Over The Top) communications moving forward.
If we look at the success of apps like Whatsapp, Tango, Viber, Voxer, Facebook Messenger etc etc these are all OTT applications that have already won in mobile communications. Placing a phone call, is nearly the last thing a teen or twenty-something user is looking to do with their phone. Just by pure observation, we can see this demographic using mobiles devices for messaging and now video chat more and more. Btw, this is the generation that will be leading our Enterprise companies in the not so distant future.
We know this, but we still insist on integrating old tech that does not seem to be accelerating in growth. Why? To answer my own question, “because lots of us continue to buy VoIP phones and SIP PBXs for our business”. And to that I say, good for you! But that is not the real opportunity for those developers who embrace WebRTC and ORTC.
WebRTC & ORTC will allow us to push the envelope and do things we can’t do today. And to do things we can do today but in a much more efficient and enjoyable manner. Maybe RTC will find its way into social news, citizen journalism, or maybe media rich banking, healthcare and CRM apps, in your TV, mobile devices, browsers et al. The possibilities are nearly endless but one thing is quite clear, it’s not going to happen unless we change our current approach.
The IETF RTCWEB WG Chairs have not given up on the MTI video codec issue and they seem determined to see this through. Weather you feel that is a good use of our time or not there will be a vote, which is something generally not done in the IETF.
Jabber remote attendance will not be counted this time around, from WG Chair – Cullen Jennings on the subject…
“If there are any people in that category that wish to vote, could they email the chairs with full name and affiliation.”
Magnus Westerlund <email@example.com>
Cullen Jennings <firstname.lastname@example.org>
Ted Hardie <email@example.com>
Here is the full note from the chairs today…
The WebRTC ecosystem needs to avoid interoperability failure to grow
optimally. The RTCWEB working group took on the task of establish Audio
and Video MTI codecs as part of meeting that need. We have not succeeded
in finishing that task for video using normal IETF process, but it is
We (WG chairs) are proposing that the working group consent to a method
that will establish an MTI, even if the MTI chosen does not have rough
consensus. We would far prefer the normal IETF process, but it is not
proving workable for this selection.
We initially proposed a method from RFC 3929 (external review team), but
now believe that the working group would not consent to that method.
Instead we are proposing a method that leaves the decision in the hands
of the WG.
The method we propose is based on Instant-runoff voting,
http://en.wikipedia.org/wiki/Instant-runoff_voting, with the
understanding that the choice will be the winner according to the
Instant-runoff voting process.
The steps in the proposed process are these (1-5):
1) Establish a final list of alternatives, based on the WG’s input to
Gonzalo’s email on the 13th of November that requires any additions to
provided by end of the 27th of November.
2) Establish those eligible to vote. Any participant in the
working group process either electronically or in-person as of yesterday
(20th of November). Who has participated in the Working group process
will be anyone that can be identified from:
- The Blue Sheets for any RTCWEB WG session during an IETF meeting or
an interim meeting since the WG’s creation.
- posting of at least one email to the RTCWEB mailing list
The voter must at time of voting prove their eligibility, by pointing to
the mail archive or a particular blue sheet/meeting. Please verify your
3) Start the the voting period. Those eligible and willing to vote send
their ballot to a vote collector (Matt Lepinski, former Nomcom chair)
within two weeks using email. The vote collector will check when
receiving a ballot the that the voter is eligible and send a
confirmation email on receiving the ballot. During the balloting period
the vote collector will keep all ballots secret.
- The voter MUST rank ALL alternatives in their ballot from the most
preferred, marked with rank 1, the second most with 2, all the way
to the least preferred marked with rank N.
4) When the voting period is over the ballot collector will publish the
results as well as all ballots, including the voters name to the RTCWEB
WG mailing list. This enables all voting individuals to verify that
their ballot is unmodified. And allows anyone to verify the result of
5) The selection is recorded in the drafts.
— End of Process Proposal —
This message initiates the first step in the working group consensus
call process. Namely a one week comment and discussion period for the
After that week the WG chairs will update, if necessary, the proposal.
Then using the normal IETF process in which anyone is eligible to
participate, the chairs will ask for (rough) consensus to adopt this
extraordinary process to achieve the working group’s stated goals. The
end date for this consensus call is 2-weeks after the announcement of
the consensus call.
If the working group does not consent to using this extraordinary
process, we will hold a consensus call if the WG can accept
“WebRTC entities MUST support at least one of H.264 or VP8.”.
If there is failure to establish consensus even for this statement, the
chairs conclude that the WG can’t establish what to say about a MTI
The WG Chairs
Here are the choices..
The proposed alternatives
The following alternatives has been proposed:
- All entities MUST support H.264
- All entities MUST support VP8
- All entities MUST support both H.264 and VP8
- Browsers MUST support both H.264 and VP8, other entities MUST support at least one of H.264 and VP8
- All entities MUST support at least one of H.264 and VP8
- All entities MUST support H.261
- There is no MTI video codec
- 5+6, i.e. All entities MUST support H.261 and all entities MUST support at least one of H.264 and VP8
- All entities MUST support Theora.
- All entities SHOULD support both H.264 and VP8. All entities MUST at least implement one of those.
Entities that do not support both H.264 and VP8 MUST implement H.261.
The deadline to propose additional alternatives are: 27th of November 2013
This may change so keep an eye on - http://trac.tools.ietf.org/wg/rtcweb/trac/wiki/WikiStart
— Day 2 —
Here we go again, 5pm – 2am Pacific:
— Day 1 —
A bunch of us at Google’s campus in Kirkland remoting into Shenzhen TPAC W3C 2013 meetings for WebRTC Working Group.
Thanks to Justin for inviting us down!
The IRC Chat Room…
http://irc.w3.org/ (channel is: webrtc)