webrtc.is

My journey creating a scalable SBC as a Service for Microsoft Teams Direct Routing is over at Snapsonic.com.

Most business owners will agree that it’s become much harder to justify paying the increasingly exorbitant lease rates for office space in most major cities in North America. Even Canada isn’t exempt.

Once a haven for US companies looking to hire cheaper Canadian labor, Vancouver now has the lowest commercial vacancy rate. To add insult to injury, it also has the highest price of gasoline in North America.

CBRE’s Canada Q2 Quarterly Statistics Report said that downtown Vancouver’s office vacancy rate was 2.6 percent in 2019’s second quarter, down from 4.7 percent one year previously, making it the hottest commercial office space market in North America on par with Toronto, beating out 3rd place San Francisco, where the vacancy rate is 3.6 percent.

Growth in commercial office space worldwide is also being spurred by coworking. We now see coworking facilities in a large number of major cities across the globe, although the number of new coworking space openings does appear to be slowing down when compared to the previous year.

Coworking is obviously not free. It does reduce the overhead and headache of having to manage your own office (lease, insurance, maintenance, etc) but if and organization made use of coworking facilities full-time, it could likely be more expensive than a comparable stand-alone office space, per square foot.

It doesn’t take a genius to see that not only are office spaces getting harder to find, but they are also the most expensive they ever have been. For staff, who are interested in raising a family, getting them to this expensive office is also costly. This sounds like a lose-lose proposition, why are we doing this again?

Unsurprisingly, IT organizations and software organizations that have no real need for dedicated physical locations appear to be shuttering offices and opting for coworking + remote work models.

Automattic, Gitlab, Shopify (just to name a few) have successfully made this transition, in fact, some of these companies were purposefully built as distributed companies from the get-go.

Various reports and studies have been done which seem to indicate that everyone wants to work from home. In a recent study, Buffer published the State of Remote Work where 2,500 remote workers surfaced some interesting statistics:

• 99% of all respondents said they wanted to work remotely, in some capacity.
• Younger generations are 28% more likely to utilize remote work than older generations. — Upwork, 2019
• 73% of all teams will have remote employees by 2028, because of the influx of Gen Zers in the coming years. — Upwork, 2019

Zapier has also published a report(*) on the subject and the findings are quite similar in that it points to knowledge workers’ desire to work remotely:

• 95 percent of U.S. knowledge workers want to work remotely, and 74 percent would be willing to quit a job to do so.
• 26 percent of knowledge workers have quit a job because the company did not offer the option to work remotely/flexible work schedule
• Remote work is a highly desired perk. Nearly 3 in 5 knowledge workers (57 percent) say the option to work remotely is one of the perks they’d most prefer to be offered by an employer.
  (That’s more than free daily lunch (42 percent) and unlimited vacation time (39 percent). Only one quarter (25 percent) cited recreational activities, like ping pong or foosball.)
• Almost a third of Millennial knowledge workers (31 percent), and more than a quarter of Gen X work (27 percent) remotely full-time. Only 11 percent of Baby Boomers do.

Microsoft (Japan) is also researching work routines and recently published findings on a 4 day work week experiment, which increased productivity by up to 39.9%. This could very well increase even more if they adopted a virtual coworking model for the other 4 days.

Now that we have set the stage for what looks to be an unstoppable trend, let’s take a look at why this is not a no-brainer.

I interviewed a few companies (ranging from small to large) and asked them what their position was with remote work in mind. Some business owners and team members expressed concerns.

• Security & Legacy Tech —If a company has previously built out systems it could be quite expensive and time-consuming to move to a secure cloud model. This move might require a large investment to get to a similar level of security that they already have, especially if the desire is to not use VPNs or IP tunnels. Even if the company is ok with VPNs, now IT has to manage that new asset, which doesn’t come for free.
• FOMO — The fear of missing out, is a big one for team members. Many employees that have not worked remotely before quickly develop a sense of FOMO (fear of missing out). If conversations were missed, it causes a feeling of exclusion and can impact productivity and morale.
• Comradeship — Developing a positive team spirit is hard to do if team members never spend face time with each other. Humans are social animals, if we remove this face-to-face time, culture tends to be rather flaccid.
• Distractions — Some professionals have not enjoyed very much success when working from home. Some remote workers state there are too many distractions and they do not have a quiet place they can go to escape these distractions in their home. Speaking from experience, this is especially true for working parents.
• Time Zones — Spanning timezones where workers are on the opposite side of the continent or planet requires good planning and diligent project management, especially if the teams are larger. This can be a daunting task for a shop that has never done it before. Teamwork may take a hit if those in the remote time zones are few and far between, as they might not be communicating with each other or with domestic teams as regularly as you would like.

Some of these concerns are legitimate and it could be they will not be overcome with even the best remote work processes.

Case in point — In 2012, Marissa Mayer was hired as CEO of Yahoo! and was charged to return the former powerhouse to its glory days. Among the many things she had to fix were company culture and productivity. According to sources closer to Yahoo!, it was made clear that many of those working at the company were not getting their jobs done when working from home. A review of VPN logins and source repository access logs surfaced a gap in the lack of work being accomplished while Yahoo! staff were working from home.

In 2013, an internal letter was issued, the company mandated that remote work was to be all but banned. Here is an excerpt from that letter…

To become the absolute best place to work, communication and collaboration will be important, so we need to be working side-by-side. That is why it is critical that we are all present in our offices. Some of the best decisions and insights come from hallway and cafeteria discussions, meeting new people, and impromptu team meetings. Speed and quality are often sacrificed when we work from home. We need to be one Yahoo!, and that starts with physically being together.

Some of Mayer’s staff, the press, and many other groups let her have it, no one seemed to be impressed. It could be said that Mayer had little choice. She had to do whatever she could to turn the company around and for her, that meant taking some drastic measures. In a Forbes post, Yahoo! commented further…

“This isn’t a broad industry view on working from home — this is about what’s right for Yahoo, right now.”

At first blush, it would seem this was more about timing and the position Yahoo! found themselves in at the time. They did what they thought needed to be done to influence behavior.

This seems like an extreme case, but the same sentiment can be found in other IT and SaaS organizations worldwide. In fact, some of these companies are the creators of communications software and services we use for remote work every day. In fact, they openly promote the “work from anywhere” mantra in their own product marketing. It might seem a little hypocritical, but it is happening for many of the same reasons we have shown.

Now that we have heard the concerns, let’s talk about the potential upside. Here are some high-level benefits:

• Reduction in Overhead — This one is rather obvious, but it goes further than just nixing the lease cost for the office space. If there is no office, there is now no longer a requirement for furniture, desks, lunchrooms, bike rooms, office snacks, bought lunches, office insurance and much more. Depending on the size of your business, savings could be significant.
• Sans Commute — Most staffers love the idea of working from home, especially if they have been successful in doing it at previous jobs. This means spending less time on the road, more time working and less time away from their family. It also means cash savings as they no longer have to pay for transit passes, gas, insurance or parking for their vehicles.

One in four knowledge workers find their commute to be among the most stressful parts of their job.*

• Choose your Location — Since location matters less in a delocated organization, team members are generally encouraged to live wherever they want, as long as they can get good Internet, power and work effectively with their peers. They are no longer tied to living in expensive larger cities where the cost of living precludes them from buying a home. This should also contribute to happier team members in general.

Obviously, these benefits can contribute to a more attractive and economical approach to building a business, as long as you can overcome the concerns.

If you are still with me and undeterred, you are not alone. Personally, I have been working remotely 100% for several years in various roles with teams all over the world. I have learned a few things along the way. Here are the cliff notes.

Remote Work Guide: A good place to start is by creating a “remote work guide” document that embodies some or all of the elements listed here along with your own spin on things. Your teams may not have experienced working remotely before, they will need some guidance and direction, this is also where we set expectations eg. working hours, always-on video, etc. It could be an addendum to your existing company handbook or a completely new document, keep in mind it will grow with your company. (Note: Many miss this step and it’s likely the single most important contributing factor to a successful remote work strategy for your company or organization.)

Small Teams: You are going to need some time to plan your rollout and decide which processes and tools are going to work best for your various teams. When your teams are first getting started, parcel off smaller project teams that are tech-savvy and preferably have experience using online collaboration tools. Their experience will pave the way for everyone else. Once you have a good process that seems to be working, you can roll it out in stages for everyone else.

Always-on Video Conferencing: This may sound a bit creepy but it can actually be quite effective in preserving team spirit, fending off FOMO and helping with the isolation that some feel when working remotely. It can be done in pairs, teams or even using a water cooler approach where team members drop in and out during the day. You can even use it to bridge branch offices, like a window into each remote office. Let’s be honest, organizations are going to see a bit more opposition when introducing this concept, it will need to be actively managed. As the business leader, you will need to actively work with team members to encourage participation (eg. by leading a weekly all-hands meeting or asking them to join or lead regular video calls, etc). If managed properly this idea can be a great communications centerpiece.

Weekly all-hands Video Conference: This is less about remote work and just good business practice. I have seen this work well in traditional and remote businesses, but few business leaders do it. Weekly highlights are shared by the CEO with support from other leaders in the organization. A master slide deck is prepared in Google Slides, with input from various departments. Friday afternoons are a good time as it ends the week on a high note (and serious note if things need attention) and helps start the next week off with a positive sentiment.

Coworking Passes: In addition to virtual coworking, it’s a good idea to include at least one or two days a week of onsite coworking for those that feel they need to get out of the house and be around other professionals. This has been widely adopted by some of the larger distributed organizations. Going completely virtual can be a bit of a shock to the system, this helps ease the transition and keeps everyone feeling like they are still human.

Offsite Team Events: With the reduction or elimination of in-person face time, team-building exercises now become more important. Organize quarterly or semi-annual gatherings at your favorite coworking establishment or pick a fun recreational location. If your company is large enough, you can divide these meets into geographical pods. Schedule at least one all-hands meeting per year with some fun events to ensure everyone feels like they are part of the organization. Do yourself a favor and don’t leave this to the last minute, you will have a poor turnout, piss people off and defeat the purpose.

There are literally dozens of team collaboration tools you can use to empower your remote workers. Try as many as you can. Select tools that are intuitive and self-explanatory, this will cut down on the learning curve. Make sure the vendors you select provide mobile support so your teams can be connected via phone or tablet.

Here are some that I have used and have found work well for remote teams, in no particular order:

• Cloud business phone system with SMS:
  Google Voice, Dialpad or roll your own by using CPaaS & WebRTC eg. SignalWire — (btw, I work here).
• Cloud storage, word processing, spreadsheets, slide decks:
  Google G-suite, Microsoft Office 365
• Text-based team collaboration
  Slack
• Software source repo and issue tracker
  Jira & Github
• Task Management
  Trello, Wrike
• Video & Web conferencing
  Zoom, Hangouts
• Support
  Zendesk
• Sales CRM
  Salesforce
• Product Management
  Product Board, Trello
• CRM and Marketing Management
  Hubspot
• Automation
  Zapier

As this remote work thing matures, we will see more purpose-built applications that aim to bring our teams closer together, virtually.

We are already seeing some activity in this space with the recent capital raise by Tandem, which has a sidecar collaboration application that works pretty well with Slack.

Another is Sococo, which looks more like a virtual workspace with web conferencing. They take an interesting approach to how they visualize the virtual office and how team members work together. I actually think this is an intuitive idea, although it does feel a wee bit recreational. To be fair, I have not used the service.

It is expected these solutions that personalize and aid remote teams in working better together will certainly evolve. It is still unclear if customers would opt-in for purpose-built applications or just use several disparate applications to do the same job, time will tell.

The next post will speak to the future of remote work. We will be touching on AI & bots, VR & AR in the remote work realm, some of which are being used today and some are not far off at all.

If you work in a distributed company, I’d like to hear from you. What tools do you use today and how are they working for you? How often do you use video/web conferencing as part of your daily routine? If you prefer sharing your comments or questions privately, feel free to shoot me a text message or call anytime: (877) 897–1952 (Note: All calls will be recorded).

None of the ideas expressed in this post are shared, supported, or endorsed in any manner by my employer.

This demo of the Microsoft Surface Hub 2 is pretty damn cool…

I don’t run a lot of Microsoft product anymore, switched to mac when the intel chip landed + Apple moved to a unix underpinning. That said, I have seen much better quality in products coming from Microsoft in the last few years, so maybe they deserve a second look.

Surface Hub 2 sort of reminds me of a product called Perch, built a by a local Vancouver team which was meant to serve as a portal into disparate global offices. Perch was way before it’s time. WebRTC was still in its infancy and personal device video conferencing had not really crossed the chasm, which is a shame considering where we are today.

Now there are many of video conferencing companies and products, and plenty of alternatives / platforms for developers to build on. It certainly seems plausible now that we could see the Microsoft Surface Hub 2 in boardrooms across the globe. Apparently it will be interoperable with WebRTC endpoints as well, which could make this a powerful work tool indeed. That would enable collaboration with peers over IP on various endpoints including laptops, tablets and mobile, regardless of the OS. Sharing product ideas, riffing on concepts and polishing final features on a product release using the Microsoft Surface Hub 2 as a tool, could be a refreshing new way to work.

It will be interesting to see what developments come about from the Microsoft press event in NYC in April, as reported by The Verge.

I haven’t blogged here in some time, so I figured that since the topic is relevant this would be good a good opportunity to dust off the old blog (webrtc.is / sipthat.com) and post something we have been working on at SignalWire. I am quite passionate about WebRTC and real-time communications so it’s great to be helping bring it to life at SignalWire!

We all know and love <cough> SIP, so we decided we would enable the use of SIP over WebSockets at SignalWire. This new offer also enables functionality like WebRTC with SIP over WebSockets.

This means our customers can now use off the shelf JS libraries, like JSSIP to create basic web experiences for their users, powered by SignalWire. It used to be a bit of a PITA, to create services that provided users with seamless online communications. Now it’s a breeze, and when using SignalWire it’s also very affordable.

For now, we are enabling basic calling and video capabilities, the advanced functionality (including video conferencing) will come in conjunction with a future release of a SignalWire RELAY JS library.

Personally, I can’t wait to see what creative minds will build using this technology with SignalWire on the backend.

If you want to know more about SignalWire’s new WebRTC + SIP over WebSockets offer, you can read about it on the SignalWire product blog.

For more than 6 years, we have been working on and looking forward to a simpler way to build RTC (Real Time Communications) applications on the web. In order for this technology to truly show its value, the major browser vendors needed to show up.

Now, it’s a reality!

macOS Sierra – Left: Safari Preview 32 (Safari 11.0, WebKit 12604.1.23.0.4) using H.264  Right: Chrome Version 58.0.3029.110 (64-bit). https://webrtc.github.io/samples/ using H.264

Now that Apple has joined the party in earnest, does the technology have the coverage required in order for developers to make good use of WebRTC on mobile devices? Let’s find out.

Until now, in order for WebRTC to work on iOS, we were relegated to wrapping WebRTC code in Objective-C and Swift, in our native iOS apps. Basically, we had to take the Chrome code and build an app that was sent to the app store for approval and wait in line, like all the other chumps (yours truly included). Conversely, on Android we could run much of that same code from our desktop Chrome apps, on the Android device as well, within reason of course.

Now that Safari and Chrome are shipping compatible WebRTC on mobile, we get to reuse the same code, right!? Well, mostly, they are different code bases, after all.

If ubiquitous mobile video is to take off, the battery life of the device has to last more than the length of the 10 minute video call (ok, I am exaggerating a bit, but I think you get the point) and the performance needs to be at least adequate enough to distinguish facial features. My bar is set a little higher, baby steps for now.

Without h/w acceleration the CPU is likely working too hard to encode the local video and decode the inbound video + service the other processes required at the same time. That really means there needs to be hardware onboard the device dedicated to video coding. That in turn means H.264, since there are very few vendors that offer VP8 or VP9 h/w acceleration.

Question: Does this mean that mobile apps written with VP8 will not be able to deliver decent mobile video conferencing?

Answer: No, not at all, but they will likely not be as performant as those taking advantage of hardware acceleration.

Suffice to say that SVC (Scalable Video Coding) usage would be another reason why we need h/w acceleration, but that’s for another day.

The majority of desktop and mobile WebRTC apps written today, are using VP8 for video.

Since Apple and Microsoft both use H.264 and Google uses VP8 and H.264 (recently shipped Open H.264 – on the desktop and mobile). Also, many of the Enterprise RTC developers are already on that H.264 bandwagon.

Question: If Apple and Microsoft devices ship with H.264, what is the case with Google Chrome on desktops and android, are they preferencing VP8?

Answer: Chrome for desktop and android now have H.264 native. Many of the Android devices that ship today all have H.264 hardware acceleration onboard. In order to understand which units have H.264 and hardware acceleration, you can run use the Android APIs to pull a list of available codecs, but in the case of WebRTC, you will only get H.264 in Android WebRTC if there is a h/w encoder on the device.

Here is a recent test:
Host 1 – (before joining):
macOS Sierra, Macbook, Safari (Technology Preview 32)

Host 2 (after joining):
Android 7, Samsung 7, Chrome 55

setRemoteDescription OperationError: Failed to set remote video description and params.     Likely because Safari is not seeing H.264 on Android.

Host 1 (after joining):

According to the Chrome Status page, Chrome for Android should have H.264. So why is the session barfing when trying to set up video? The logs do not lie…

Safari – offer:
a=rtpmap:96 red/90000
a=rtpmap:98 ulpfec/90000
a=rtpmap:99 H264/90000

Chrome on android – answer:
a=rtpmap:96 red/90000
a=rtpmap:98 ulpfec/90000
a=rtpmap:97 rtx/90000

Err, huh? No H.264 in reply?
So, I updated to latest Chrome on android (58) and tried again…

… et voilà!!

Shipping your product with H.264 enabled, means you may potentially need to deal with the MPEG-LA royalty police for H.264 royalties, but there are some grey areas.

In the case of Apple and Microsoft, where H.264 royalties are already being paid for by the parent vendor, the WebRTC developer is riding on the coattails of papa bear, at least in theory.

Cisco’s generous OpenH.264 offer means that those using this binary module, can do so at potentially no cost:

We will not pass on our MPEG-LA licensing costs for this module, and based on the current licensing environment, this will effectively make H.264 free for use on supported platforms.

Q: If I use the source code in my product, and then distribute that product on my own, will Cisco cover the MPEG LA licensing fees which I’d otherwise have to pay?

A: No. Cisco is only covering the licensing fees for its own binary module, and products or projects that utilize it must download it at the time the product or project is installed on the user’s computer or device. Cisco will not be liable for any licensing fees incurred by other parties.

That seems to mean (I am no lawyer) every developer shipping WebRTC apps supporting Open H.264 binary module, get a free ride. Those using some other binary, or shipping the above source code for that module, could be on the hook for those royalties. That said, since there are royalties being paid by parent vendors where devices are shipping H.264 anyways, developers may not get hassled regardless.

So what did we learn here?

• Apple has joined the party, now we have a full complement of browser vendors!
• If you want to leverage WebRTC video to deliver a ubiquitous mobile and desktop experience for your users, you should likely consider including both H.264 and VP8.
• VP8 is (still) free and powers most of the WebRTC video out there today.
• You can make use of the Open H.264 project and get a free H.264 ride, albeit baseline AVC.
• WebRTC on Android does not support software encoding of H.264, so unless there is local hardware acceleration, H.264 will not be in the offer.
• H.264 is not fully enabled (or buggy) in Chrome 55 (I was using it on Samsung S7 Edge (Android 7), but it does work with Chrome 58.
• WebRTC is not DOA!
• SDP still sucks and ORTC can’t come soon enough!!

The W3C and IETF are also closing in on shipping WebRTC as a web standard, here’s a great update from Google on that as well. Latest W3C WebRTC editor’s draft, latest charter.

As a side note, it would be interesting to see something like this open sourced; VP8 / H.264 conversion without transcoding, if only to service the existing desktop apps currently running VP8 <-> mobile H.264. It would likely overwhelm the mobile device, but it would be cool if it worked!

Disclaimer: The views expressed by me are mine alone and do not necessarily represent the views or opinions of my employer.

Update:

Looks like VP8 is not there after all, bummer. More political jostling afoot, which sucks for the development community.

—

This is a big deal, to have Apple / Safari onboard is really the final major obstacle in the adoption of this awesome standard.

More info (thanks Marc Abrams !!)…
Based on the beta for macOS High Sierra – that was made available yesterday…
– https://cl.ly/3q0p1O3…­
– Test samples: webrtc.github.io/samples/ (It passed most of the tests)
– Video codec support is VP8 and H.264 (I have not seen a test that shows H.265 or HEVC but I know it’s there)
– Audio codec support is Opus, ISAC16, G.722 and PCMU
– Basic datachannel support is there but none of the tests seem to work

AWESOME!!! This took a bit longer that many of us were expecting, but hey better late than never!

Next week I will be joining friends old and new at PulverHWC to rediscover – How We Communicate.

Here is an email from Jeff Pulver inviting all of you to join us in Los Gatos for what is sure to be a landmark occasion.

Hope to see you there!

Erik

The Keys to the Communications Universe

Next week I return to doing the one thing that I love best – bringing together brilliant, interesting people.

Leaders, visionaries, dreamers and market makers from the worldwide communications industry have accepted my invitation to take part in the Pulver HWC Summit, May 18 – 19 at Testarossa Winery in Los Gatos, CA. I am grateful for both the people who are speaking and the tech legends who have signed up to join us for an intimate conversation. I believe understanding the message behind “How We Communicate” (“HWC”) is the next great area of growth in the communications space. Trillions of dollars of opportunity will be created and there are relationships to be forged, deals to be made, and knowledge to be shared.

There are a limited number of tickets still for sale. To join the conversation and to register, please click here. I would appreciate it if you could share this email with your friends and family involved in the communications industry.

Thank you!

Warm hugs, Jeff

http://ortc.org/wp-content/uploads/2016/05/ortc.html#change-log*

1. Added the gather() method, as noted in: Issue 165
2. Removed “public” from RTCIceGatherPolicy, as noted in: Issue 224
3. Removed the minQuality attribute, as noted in: Issue 351
4. Made send() and receive() asynchronous, as noted in: Issue 399, Issue 463, Issue 468 and Issue 469
5. Provided additional information on ICE candidate errors, as noted in: Issue 402
6. Added state attribute to RTCSctpTransport, as noted in: Issue 403
7. Provided an example of RTX/RED/FEC configuration, as noted in: Issue 404
8. Clarified payloadType uniqueness, as noted in: Issue 405
9. Updated the list of header extensions, as noted in: Issue 409
10. Added “goog-remb” to the list of feedback mechanisms, as noted in: Issue 410
11. Added kind argument to the RTCRtpReceiver constructor, as noted in: Issue 411
12. Clarified send() restrictions on kind, as noted in: Issue 414
13. Added getAlgorithm() method, as noted in: Issue 427
14. Changed RTCDataChannel protocol and label to USVString, as noted in: Issue 429
15. Clarified nullable attributes and methods returning empty lists, as noted in: Issue 433
16. Clarified support for the “direction” parameter, as noted in: Issue 442
17. Clarified the apt capability of the “red” codec, as noted in: Issue 444
18. Clarified usage of RTCRtpEncodingParameters attributes, as noted in: Issue 445
19. Clarified firing of onssrcconflict event, as noted in: Issue 448
20. Clarified that CNAME is only set on an RTCRtpSender, as noted in: Issue 450
21. Updated references, as noted in: Issue 457
22. Described behavior of send() and receive() with unset RTCRtpEncodingParameters, as noted in: Issue 461
23. Corrected dictionary initialization in the examples, noted in: Issue 464 and Issue 465
24. Corrected use of enums in the examples, noted in: Issue 466
25. Clarified handling of identity constraints, as noted in: Issue 467 and Issue 468
26. Clarified use of RTCRtpEncodingParameters, as noted in: Issue 470
27. Changed hostCandidate type, as noted in: Issue 474
28. Renamed state change event handlers to onstatechange, as noted in: Issue 475
29. Updated description of RTCIceGatherer closed state, as noted in: Issue 476
30. Updated description of RTCIceTransport object, as noted in: Issue 477
31. Updated description of relatedPort, as noted in: Issue 484
32. Updated description of RTCIceParameters, as noted in: Issue 485
33. Clarified exceptions in RTCDataChannel construction, as noted in: Issue 492
34. Provided a reference to error.message, as noted in: Issue 495
35. Clarified RTCRtpReceiver description, as noted in: Issue 496
36. Clarified default for clockRate attribute, as noted in: Issue 500
37. Removed use of “null if unset”, as noted in: Issue 503
38. Updated RTCSctpTransport constructor, as noted in: Issue 504
39. Clarified behavior of getCapabilities(), as noted in: Issue 509
40. Addressed issues with RTCDataChannelParameters, as noted in: Issue 519

Last Thursday we had the first virtual w3c webrtc wg interim meeting. Once we sorted out a few technical details it went quite well!

Meeting Home Page:
https://www.w3.org/2011/04/webrtc/wiki/January_14_2016#Virtual_Interim

ORTC, WebRTC, H.264, VP8, RID, RtpEncoding, Simulcast and much more. Google, Microsoft and Hookflash leading the discussion, join us!

http://ortc.org/2015/11/04/w3c-ortc-cg-meeting-10-november-20-2015/

We have an immediate WebRTC development contract opportunity that has just come up in the Seattle area. The contract requires 4-5 full-time developers onsite, remote will not fit the bill on this one.

For this contract we are looking for a team lead, 2 x Node.js, 2 x common JS developers

You have built commercial web applications using WebRTC libraries and are intimately familiar with the WebRTC and ORTC specs and respective libraries.

Start date: ASAP

If you are interested please forward your resume [email protected]

From Microsoft – http://blogs.windows.com/msedgedev/2015/09/18/ortc-api-is-now-available-in-microsoft-edge/

Our initial ORTC implementation includes the following components:

1. ORTC API Support. Our primary focus right now is audio/video communications. We have implemented the following objects: IceGatherer, IceTransport, DtlsTransport, RtpSender, RtpReceiver, as well as the RTCStatsinterfaces that are not shown directly in the diagram.
2. RTP/RTCP multiplexing is supported and is required for use with DtlsTransport. A/V multiplexing is also supported.
3. STUN/TURN/ICE support. We support STUN (RFC 5389), TURN (RFC 5766) as well as ICE (RFC 5245). Within ICE, regular nomination is supported, with aggressive nomination partially supported (as a receiver). DTLS-SRTP (RFC 5764) is supported, based on DTLS 1.0 (RFC 4347).
4. Codec support. For audio codecs, we support G.711, G.722, Opus and SILK. We also support Comfort Noise (CN) and DTMF according to the RTCWEB audio requirements. For video we currently support the H.264UC codec used by Skype services, supporting advanced features such as simulcast, scalable video coding and forward error correction. We’re working toward to enabling interoperable video with H.264.

More here..

W3C WebRTC working group chairs [Harald Alvestrand (Google), Stefan Håkansson (Ericsson), Erik Lagerway (Hookflash)], made a decision recently to add a new editor to the working group, as Peter St. Andre (&yet) has resigned as editor.

Bernard Aboba (Microsoft) has now been appointed as editor.

Bernard’s attention to detail and advocacy for transparency, fairness and community has been refreshing. It has been my pleasure (as chair of the W3C ORTC CG) to work with Bernard whom also is an author in the W3C ORTC CG alongside Justin Uberti and Robin Raymond (editor). I look forward to working more with him in the WG.

Congrats Bernard!

/Erik

The new charter for the WebRTC Working Group has been approved. Current members will need to re-join, from the WebRTC WG mail list…

Hi all,

Great news, the new W3C WebRTC Working Group charter [1] has been officially approved by the W3C Director [2].

The revised charter adds a deliverable for the next version of WebRTC, has an updated list of deliverables based on the work started under the previous charter, clarifies its decision policy, and extends the group
until March 2018.

The charter of this Working Group includes a new deliverable that require W3C Patent Policy licensing commitments from all Participants.

Consequently, all Participants must join or re-join the group, which involves agreeing to participate under the terms of the revised charter and the W3C Patent Policy. Current Participants may continue to attend meetings (teleconferences and face-to-face meetings) for 45 days after this announcement, even if they have not yet re-joined the group. After 45 days (ie. September 10, 2015), ongoing participation (including meeting attendance and voting) is only permitted for those who have re-joined the group.

Use this form to (re)join:
https://www.w3.org/2004/01/pp-impl/47318/join

Instructions to join the group are available at:
http://www.w3.org/2004/01/pp-impl/47318/instructions

Thanks,
Vivien on behalf of the WebRTC WG Chairs and Staff contacts

[1] http://www.w3.org/2015/07/webrtc-charter.html
[2] https://lists.w3.org/Archives/Member/w3c-ac-members/2015JulSep/0024.html

As newly appointed co-chair in the W3C WebRTC WG, I just participated in my first Editor’s Call, and I’m impressed.

We had to address nearly dozens of Pull Requests and Issues on the associated github repos. We managed to knock down quite a few that ended up getting merged and a few that were closed today, despite not having 1 co-chair and 1 editor present.

There were some suggestions on how we could make the processes a bit more effective, allowing everyone to understand more what’s expected of them. It’s going to take a few meetings I suspect to get a real feel for how I can be adding the most value possible.

Overall, it feels like we are all trying our best to do what the new charter has set out, to get 1.0 done before getting on with the next chapter. I am excited to be part of it and look forward to continue helping!

If you have any thoughts on how the WebRTC Working Group could be doing things differently to be more effective and efficient, I would like to hear your thoughts.

Big thanks to everyone (especially Bernard) for putting in the extra work required here for our next CG meeting:

1. Addressed Philipp Hancke’s review comments, as noted in: Issue 198
2. Added the “failed” state to RTCIceTransportState, as noted in: Issue 199
3. Added text relating to handling of incoming media packets prior to remote fingerprint verification, as noted in: Issue 200
4. Added a complete attribute to the RTCIceCandidateComplete dictionary, as noted in:Issue 207
5. Updated the description of RTCIceGatherer.close() and the “closed” state, as noted in: Issue 208
6. Updated Statistics API error handling to reflect proposed changes to the WebRTC 1.0 API, as noted in: Issue 214
7. Updated Section 10 (RTCDtmfSender) to reflect changes in the WebRTC 1.0 API, as noted in: Issue 215
8. Clarified state transitions due to consent failure, as noted in: Issue 216
9. Added a reference to [FEC], as noted in: Issue 217

With the forthcoming re-charter @W3C WebRTC Working Group, there were also a few managerial changes:

• Peter Saint Andre (@andyet fame), will be joining as co-editor
• Erik Lagerway, yours truly (co-founder @hookflash), will be joining as co-chair
• Vivien Lacourba, W3C staff, will be helping out Dominique Hazael-Massieux with increased W3C staff time in the WebRTC Working Group

I am personally flattered and over the moon excited to have been asked to co-chair the WebRTC Working Group and look forward to working with Harald and Stefan to help usher in the next era of WebRTC standards work.

/Erik

It’s been about a year since we uploaded the ORTC Lib presentation on slideshare …

We have been rather busy since then…

Good things are coming! :)

With more than 40 members and growing, Vancouver WebRTC now has a new venue! Chris Simpson from PoF rallied to get us into their new presentation lounge, the “Aquarium”, thanks Chris!

Our next event is on June 25th from 6-8pm and we have a great evening planned with Omnistream and Perch presenting!

Come check it out!