WebRTC is the most secure technology for video communications. And yet – developers can screw this for you.
There is a rise in security breaches and data theft incidents in 2016. You see this from the amount of information out there. I’ve written about WebRTC and security for quite some time, but a recent post I’ve read compelled me to write about it again.
The post? Red Cross Blood Service in Australia leaks personal data.
The gist:
It probably happens more often than not. You build a service. You take care of its security. And then, someone down the lines screws you over with his maintenance processes. To some extent, this is just as bad as social engineering, where a hacker tries to gain access by fooling people to believe he is someone else.
Make sure to download the WebRTC Security checklist. Print it and stick it on the wall behind your monitor so you don’t forget.WebRTC Security baselineWebRTC comes with a few security concepts that are quite new and innovative in VoIP:
The thing people forget is that WebRTC is just a piece of technology. A building block. It is up to the developers to decide how to use it in their own product. During that integration, security breaches can be created quite easily.
In the WebRTC course I launched two months ago, I’ve added a lesson dealing with WebRTC security. It goes through the mechanisms that exist in WebRTC and the areas that need to be further secured by the application.
Two big issues left to developers today are TURN passwords and access to backend server resources.
#1 – TURN passwordsTURN servers predate WebRTC. They are used by SIP (or at least are found in the spec), and there, the notion is that the user agent (=device/endpoint) is secure and “named”. So a username and password mechanism was created to get a TURN binding. The reason you want such a mechanism in the first place is because TURN servers are bandwidth hogs – they relay media, and by doing that they cost a lot in terms of bandwidth. So if you are paying for it, you don’t want others to piggyback on it.
The problem with this approach in WebRTC is that the username and password needs to be passed from your JavaScript code inside the browser to the server. Which means that information is available in the clear for many use cases – those where you don’t need or want the user to identify with the network at all.You also don’t want someone sniffing your code in the browser and then reusing these credentials elsewhere.
The current approach out there is to use temporary passwords (I like calling them ephemeral – it makes me sound intelligent). Ones that become useless in an hour or two.
This means that someone in your backend randomly creates a password that is short-lived and shares it with both the TURN server and the client.
The above illustrates how this is done.
Great.
Now lets add a media server into the mix.
Who should be generating that password and passing it around to whom? Should the Media Server now be in charge of it, or is it up to the App Server still to take care of this?
Which leads me to the second important security aspect of WebRTC when it comes to your development – backend server resources you need to protect.
#2 – Backend server resourcesIn many cases, I find that when the work is outsourced, the end result tends to be a jumble of an architecture if things aren’t thought out properly from the beginning.
This usually causes the wrong servers to need to connect and communicate directly with the User. While not an issue on its own, it can easily turn into a headache:
What I suggest in many cases is:
I am not a security expert. I know a bit about it and try to stay informed, but I am by no means an expert in it.
You should make sure to take security into consideration when developing your service and don’t assume WebRTC does everything for you. It doesn’t, but it is the best starting point you’ll get.
If you want to learn more about WebRTC, I will be opening the course again for another round. Probably during April.
If you are a corporate looking to have an open access to course materials throughout the year for your workforce – I am going to announce such a plan soon, but feel free to reach out to me before that happens.
Just do me a favor – don’t leave WebRTC security to chance.
Need a reminder? Download the WebRTC Security checklist. Print it and stick it on the wall behind your monitor so you don’t forget.The post The Best WebRTC Security is Prone to the Stupidest Developer appeared first on BlogGeek.me.
Slack is an über popular and fast growing communications tool that has a ton of integrations with various WebRTC services. It also acquired a WebRTC company a year ago and launched its own audio conferencing service earlier this year which we analyzed here and here. Earlier this week they launched video. Does this work the same? Are […]
The post Slack Does WebRTC Video – Here’s How (Gustavo Garcia) appeared first on webrtcHacks.
Got a requirements document to write for WebRTC? Here’s a step by step guide to doing just that.
Here is something that I do with my customers quite often. In many cases, when I consult vendors, they are in the process of building a new product or integrating an existing product with some new communication capabilities. This involves using WebRTC and outsourcing the actual development.
More often than not, I find myself writing the baseline of the requirements document for the customer, to server as a WebRTC RFP (Request For Proposals) that get used to communicate the requirements with the potential outsourcing vendors.
I wanted to share the process that I use in writing the first draft of this document. To make this a bit more useful, let’s assume that what we want to do is build a webinars service, where a few people can join as the speakers in the webinar and people online can “listen in”.
I’ve created a WebRTC requirements template and a sample webinars requirements document that you can use when you need to write the requirements for your own product.
Get the WebRTC Requirements Template and Sample Webinars Requirements DocumentHere’s step by step how I’d go about doing that.
Step #1: Structure your documentFirst things first. To make sure I don’t forget anything, I like to split my requirements document into 4 sections:
As you can see in above, I place TBD for each section in the document. I do that for all sub sections that I add to the document as well. This way, I can easily search the areas that haven’t been filled in properly yet when I work on it. Most often than not, writing these WebRTC requirements take a couple of hours and span a few days because they are collaborative in nature.
I tend to leave out the mechanics around the project – such as the price model I am looking for, or the timeline of the project. These tend to change between companies and they often better reflected elsewhere than in the technical requirements that I try to describe here.
Step #2: Write the overviewFirst thing I do once I have the template ready for my needs is write the overview part.
I try to keep the overview short and sweet, with a focus on making sure people understand what it is that I am trying to achieve in the service – what my challenges are and what I consider as success.
Usually, 2-3 paragraphs should be enough.
Step #3: Describe the architectureNow it is time to start thinking about our architecture. By that, I don’t mean the architecture of the solution, what processes, servers and switches I want – I leave that for the vendor to fill in. What I mean is the entities I have in my service, trying to focus around the session – the types of media and signaling I want running there.
I do this by going analog, and just jot it down on my whiteboard and taking a picture of the end result. I find this more natural for me than using Powerpoint or Vizio. Later on, I might redo it as a Powerpoint diagram, but more often than not, I just leave it as is.
Above is the drawing I just did to describe the BlogGeek.me Webinar I just invented.
After the visual, I explain the different entities that are in the drawing and the relations between them. This part is really important, as oftentimes, it will reveal entities or flows that I haven’t thought about earlier.
In the case of the BlogGeek.me Webinar, we’ve got multiple potential Speakers who interact using audio and video with each other in the Webinar, which then gets sent to multiple Viewers and also to an external Storage.
I try to keep things focused and to the bare minimum that is necessary for the understanding of the service.
Step #4: Fill in the featuresTo some extent, this step is the main chunk of what the product does. For me, this is a brain dump of the things a user should be able to do in the system.
There are different types of features you might be needing. I focus on those that relate to the communication part of the product and nothing else.
Here’s a checklist of what I usually go through when doing this:
Make sure you answer all the questions above as requirements in the document if they make sense and add your own to the list.
Here are a few of the ones I’ve written for the webinars product:
Notice how I’ve indicated that connectivity via PSTN is optional in a future phase? This serves two purposes for me:
Now it is time to go over the non-functional requirements. These are the boring and ugly details that can make or break a service, so spend enough time on this one.
What do I mean by non-functional? These will usually be things you will take for granted, but the vendor won’t. To reduce friction and arguments in the future, I add these. In most likelihood, if you don’t write these down, a vendor will ask about a few of these things anyway – so just write them down to reduce the unnecessary round trips and to make sure you and the vendor are on the same page.
I tend to split this section to 5 subsections, each with its own focus:
1. DevicesHere I list all the devices I want to support. Browsers, operating systems, mobile devices, etc.
Each gets its own special treatment. Things I usually look at here are:
In many ways, I derive the requirements here based on the WebRTC Device Cheat Sheet that I published.
2. NAT traversalNAT traversal is often overlooked. There are two areas where I cover NAT traversal – here and in the Security subsection below.
Here, I define who takes care of it – do I expect the vendor to bring a NAT traversal solution, will I be doing it, or should they use a third party hosted service (there are a few out there offering it).
The second part that I sometimes decide here, but not always, is where I want it deployed – along with the media servers or closer to the connecting user. It is a matter of architecture needs that I prefer leaving to the vendor to fill in but not always (can’t really say when in a definitive way).
In my webinar example, I decided to make things easy and just use a third-party hosting service:
3. ScalabilityFor scalability I make sure I cover a few areas:
Here’s how I fit it into our webinar example:
4. SecurityThe security part is slightly tricky. First, because I am not an expert. But also because almost nobody is.
What I usually place here is the basics of how I’d like to see the backend (encryption between the servers), but I do cover two important areas:
The DevOps section deals with things required to run this product on a daily basis. I tend to fill in three main things here:
Now that we’ve written t all, time to go over the whole document to make sure things aren’t missing:
Here’s what I decided to add to the webinar example:
As you can see, for me, open source was really important.
Now that you are done – go share the document with your colleagues, and once approved internally, it is time to share with potential outsourcing vendors.
Why so short?To some, this approach may seem a bit shallow. It doesn’t include all corner cases or describe in a lot of detail what goes on. The thing is, that there is a balance between what you can effectively do and achieve as a small startup or even a big company with a new project than what you’d do on a long running multi-year millions of dollars project.
For me, this proves itself as a good way to capture the essence of what it is that needs to be developed and getting replies from potential vendors to building the product. Once I get the replies, it is time to go over them and see who makes the most sense – a lot based on how they replied to the RFP in the first place.
What’s next?So here’s how you should write your next WebRTC requirements document:
Step #1: Structure the document to make sure all bases are covered
Step #2: Focus on the overview – explain what your product needs to achieve
Step #3: Draw the architecture and explain it
Step #4: Write down your functional requirements
Step #5: Write down all non-functional requirements
Step #6: Do a one-over to make sure you didn’t miss anything
I’ve built a WebRTC Requirements Template document for you. You can copy it and fill it in with the requirements of your own product. It already holds many of the questions you’ll need to answer, so it can serve as a guide for you.
Now, to write this article, I also had to create a real-world example (remember our webinar service?). This example is also shared so you can see how I write things down.
Get the WebRTC Requirements Template and Sample Webinars Requirements DocumentOh, and if you still need help – I do offer a consulting service, where a lot of the time invested is placed into writing these requirements documents, finding suitable potential vendors and going over their responses.
The post How to Write the WebRTC Requirements for Your New Product? appeared first on BlogGeek.me.
Want to learn more about WebRTC in education?
Next week, testRTC will be hosting a webinar titled How WebRTC ushers the next wave of e-Learning innovation. As a co-founder of testRTC, I am tasked with the actual creation and hosting of the webinar, which means I will be speaking about what vendors are doing WebRTC when it comes to education and where I see their challenges.
I haven’t done a webinar in quite some time, so this is going to be fun for me.
We’ve decided to use Crowdcast as our webinars platform for it. Partially because it is a WebRTC based service, and I do love dog fooding. But also because I received some good reviews about it.
If I had to pick two very active verticals in the domain of WebRTC, these would be healthcare and education. We see this also at testRTC, where we help these vendors in testing and deploying their services to production.
Next WednesdaySo here’s what we’re doing next Wednesday – me and you:
The examples part of the webinar is probably going to be the most interesting one.
I remember talking almost 3 years ago with a startup in India about their use case. It was related to education and it blew my mind. It was so starkly different than what I assumed a startup in India would do within their local market for education that I saw it as my own private lesson. Since then, I talked with tens of vendors in this space. Each doing his own thing. Each focusing on solving a problem in tutoring. They are so wide in variety that you can’t even look at them as a single market.
But this is exactly what we will try to do here. I am going to categorize them a bit – I wonder where you will find yourself in that categorization.
The challengesLearning has its challenges for the student, the teacher and now also for the platform.
My intent is to look at the challenges of the platform – what are the things necessary to put these different education systems in production and how to make sure they work properly.
For the various types of education platforms, I’ll give you tips for where you should focus with your testing – what are the weak spots to look for – so you can find and deal with them before your customers do.
The bonusI am not going to say what the bonus is now – it will ruin the surprise. I will say though, that this is something you’ll find immediately useful.
The bonus will be available only to those who will be with me during the webinar itself, so register now and save your place.
What’s next?Register of course!And feel free to write down your questions in advance – Crowdcast allows for that.
The post WebRTC and Education – the Webinar Edition (and a Bonus) appeared first on BlogGeek.me.
Different ways to do the same thing.
One of the biggest problems is choice. We don’t like having choice. Really. The less options you have in front of you the easier it is to choose. The more options we have – the less inclined we are to make a decision. It might be this thing called FOMO – Fear Of Missing Out, or the fact that we don’t want to make a decision without having the whole information – something that is impossible to achieve anyway, or it might be just the fear of committing to something – commitment means owning the decision and its ramifications.
WebRTC comes with a huge set of options to select from if you are a developer. Heck – even as a user of this technology I can no longer say what service I am using:
In my online course, there’s a lesson discussing NAT traversal. One of the things I share there is the need to place the TURN server as close as possible to the edge – to the user with his WebRTC client. Last week, in one of my Office Hour sessions, a question was raised – how do you make that decision. And the answer isn’t clear cut. There are… a few options.
My guess is that in most cases, the idea or thought of taking a problem and scaling it out seems daunting. Taking that same scale out problem and spreading it across the globe to offer lower latency and geolocation support might seem paralyzing. At the end of the day, though it isn’t that complex to get a decent solution going.
The idea is you’ve got a user that runs on a browser or a mobile device. He is trying to reach out to your infrastructure (to another person probably, but still – through your infrastructure). And since your infrastructure is spread all over the globe, you want him to get the closest box to him.
How do we know what’s closest? Here are two ways I’ve seen this go down with WebRTC based services:
Via DNSWhen your browser tries to reach out the server – be it the STUN or TURN server, the signaling server, or whatever – he ends up using DNS in most cases (you better use DNS than an IP address for these things in production – you are aware of it – right?).
Since the DNS knows where the request originated, it can make an informed decision as to which IP address to give back to the browser. That informed decision is done in the infrastructure side but by the DNS itself.
One of the popular services for it is AWS Route 53. From their website:
Amazon Route 53 Traffic Flow makes it easy for you to manage traffic globally through a variety of routing types, including Latency Based Routing, Geo DNS, and Weighted Round Robin.
This means you can put a policy in place so that the Route 53 DNS will simply route the incoming request to a server based on its location (Latency Based Routing, Geo DNS) or based on load balancing (Weighted Round Robin).
appear.in, for example, is making use of route53.
Amazon Route 53 isn’t the only such service – there are others out there, and depending on the cloud provider you use and your needs, you may end up using something else.
Via Geo IPAnother option is to use a Geo IP type of a service. You give your public IP address – and get your location in return.
You can use this link for exampleto check out where you are. Here’s what I get:
A few things that immediately show up here:
That said, this is pretty close!
Now, this is a link, but you can also get this kind of a thing programmatically and there are vendors who offer just that. I’ve head the pleasure to use MaxMind’s GeoIP. It comes in two flavors:
There’s a kind of a confidence level to such a service, as the reply you get might not be accurate at all. We had a customer complaining at testRTC servers which jinxed his geolocation feature and added latency. His geo IP service thought the machine was in Europe while in truth it was located in the US.
The interesting thing is, that different such services will give you different responses. Here’s where I am located base (see here):
As you can see, there’s a real debate as to my exact whereabouts. They all feel I live in Israel, but the city thing is rather spread – and none of them is exact in my case.
So.
There are many Geo IP services. They will differ in the results they give. And they are best used if you need an application level geolocation solution and a DNS one can’t be used directly.
TelemetryWhen inside an app, or even from a browser when you ask permission, you can get better location information.
A mobile device has a GPS, so it will know the position of the device better than anything else most of the time. The browser can do something similar.
The problem with this type of location is that you need permission to use it, and asking for more permissions from the user means adding friction – decide if this is what you want to do or not.
What’s next?I am sure the DNS option is similar in its accuracy level to the geo IP ones, though it might be a bit more up to date, or have some learning algorithm to handle latency based routing. At the end of the day, you should use one of these options and it doesn’t really matters which.
Assume that the solution you end up with isn’t bulletproof – it will work most of the times, but sometimes it may fail – in which case, latency will suffer a bit.
Planning on introducing WebRTC to your existing service? Schedule your free strategy session with me now.
The post WebRTC, TURN and Geolocation. How to Pick the Best Server to Work With? appeared first on BlogGeek.me.
Kranky Geek last week was quite a rush.
Wow.
What can I say. Last week, our Kranky Geek event was so much fun.
I won’t bore you with the details. We’ve focused this time on WebRTC in mobile. Got the best speakers possible – really. And had a blast of an event. I received so much positive feedback that it warms my heart.
I’d like to thank our sponsors for this event: Google, Vidyo, Twilio and TokBox. Without them, this event wouldn’t have been possible.
The videos are available online, and below you’ll find the playlist of the event:
Tomorrow we’re doing another Kranky Geek event. This time in Sao Paulo, Brazil. Different theme. Different sessions. I am dead tired, but working hard with Chad and Chris to make that a huge success as well. See you soon!
The post Kranky Geek 2016 SF: Mobile WebRTC appeared first on BlogGeek.me.
All you wanted to know but didn’t know how to ask.
2 billion Chrome browsers? 7 billion WebRTC enabled devices by 2017? 50 billion IoT devices?
At the end of the day, who cares? What you are really interested in is to make sure that the WebRTC product you develop will end up working for YOUR target customers. If these customers end up running Windows XP with Internet Explorer 6 then you couldn’t care less about Apple, Safari and iOS support. But if what you are targeting is a mobile app, then which browser supports webRTC is less of an issue for you.
To make things a bit simpler for you, I decided to create a quick Cheat Sheet. A one pager to focus you better on where you need to invest with your WebRTC efforts.
This cheat sheet includes all the various devices and browsers, and more importantly, how to get WebRTC to work on them.
So why wait? Grab your copy of the cheat sheet by filling out this form:
The post My WebRTC Device Cheat Sheet appeared first on BlogGeek.me.
Time for a quick reality check when it comes to browsers and WebRTC.
I know you’ve been dying for Apple to support WebRTC in Safari. I am also aware that without WebRTC in your Microsft Internet Explorer 6 that you have deployed in your contact center there is no way for WebRTC to become ubiquitous or widely adopted. But hear me out please.
Browsers market shareThe recent update by NetMarketShare on the desktop browsers market share is rather interesting:
It shows the trend between the various desktop browsers for the last year or so.
Here are some things that comes to mind immediately:
What happens between Microsoft Edge and Apple Safari is even more interesting. Apple Safari is falling behind Microsoft Edge:
Something doesn’t add up here.
The Edge numbers should rise a lot higher, due to the successful upgrades we’ve seen for Windows 10 in the market. And it doesn’t. We already noticed how Chrome and to some extent Firefox enjoyed that switch to Windows 10.
I am not sure how the slip of Apple Safari market share from almost 5% in the beginning of this year to below 4% can be explained. Is it due to the slip in Mac sales in recent months or is it people who prefer using Chrome or Firefox on their Macs?
–
There’s one caveat here of course – these numbers are all statistics, and statistics do tend to lie. When going to specific countries, there will be a different spread across browsers, and to a similar extent, your service sees a different type of browser spread because your users are different. Here’s the stats from Google Analytics for this blog:
For me, it is titled towards browsers supporting WebRTC, and Safari is way higher than Edge and Internet Explorer put together.
Back to WebRTCEvery once in a while, someone would stand up and ask: “But what about Internet Explorer?” when I talk about WebRTC. It is becoming one of these questions I now expect.
Here’s what you need to think about and address:
I am working on a quick cheat sheet for you. One which will enable you to make fast decisions for browser support. It will extend also into apps and mobile. Probably by next week.
Until then, if you plan on picking up browsers to support, think of your target audience first. Don’t come up with statements like “IE must be supported” or “Without Safari I can’t use this technology”. You are just hurting yourself this way.
Planning on introducing WebRTC to your existing service? Schedule your free strategy session with me now.
The post Desktop browsers support in WebRTC – a reality check appeared first on BlogGeek.me.
Kranky Geek is coming to town!
WebRTC is maturing. We’re 5 years into this roller coaster and it seems most companies have already understood that they need to use WebRTC in one way or another. To many, this is going to be an excruciatingly painful journey. They will need to change their business model, think differently about how they develop products and even rewrite their core values.
One of the reasons we decided to launch Kranky Geek over two years ago was to have a place where developers can teach developers about WebRTC. Somewhere that isn’t already “tainted” with the telecom views of the world – not because they are bad – just because WebRTC can accomplish so much more. What we are going to do next with WebRTC takes place in November and will happen in two separate locations:
Kranky Geek San FranciscoSan Francisco is where Kranky Geek started and where I feel at home when it comes to this event. We will be doing our 3rd Kranky Geek event in San Francisco (and 4th in total).
It will take place on November 18, at Google’s office on Spear street.
Our focus this time around is going to be mobile. We’ve got sessions lined up that should cover most of the aspects related to WebRTC and mobile. Things like using React, cross platform development, video compression, specific aspects in iOS as well as specific aspects in Android related to WebRTC.
If you are into mobile development with real time communications – then this is an event you don’t want to pass up.
There is also a new attendance fee that was added – $10 that gets donated to Girl Develop It. You may notice we don’t have a woman speaker this time – it is hard to find women speakers in this domain, so if you are one or know one – make sure to let us know for our future events.
I’d like to thank our sponsors who made this thing possible:
This will be my first time in Brazil and also the first time we run Kranky Geek in Barzil. As with San Francisco, the event is hosted at Google’s office in São Paulo.
Our focus for São Paulo will be back to the basics of WebRTC. We are trying this time to fill in the gaps – share resources and insights that developers who use WebRTC in their daily activities need. This is why we have a few sessions that are targeted at debugging and troubleshooting WebRTC in this event.
Registration for the São Paulo event is free.
For the São Paulo event, we got the help of a few sponsors as well:
I have my own session to prepare for the upcoming Kranky Geek, along with a lot of work to make these two events our best yet. There are also changes and modifications that need to make their way to the website – but rest assured – these events have great content lined up for you.
If you happen to be in the area, my suggestion is come to the event – it is the best place to learn and interact with people who know way better than I do what WebRTC is in and out.
And if you want to meet me – just contact me. I’ll be “in town” for an extra day or so.
–
See you all at Kranky Geek!
The post Get Ready for Kranky Geek San Francisco AND São Paulo appeared first on BlogGeek.me.
WebRTC 1.0 uses SDP for negotiating capabilities between parties. While there are a growing number of objects coming to WebRTC to avoid this protocol from the 90’s , the reality is SDP will be with us for some time. If you want to do things like change codecs or adjust bandwidth limits, then you’re going to need to “munge” […]
The post How to limit WebRTC bandwidth by modifying the SDP appeared first on webrtcHacks.
No article today.
My course is launching today: Advanced WebRTC Architecture Course.
I’ve got some solid attendance for it, along with a good bulk of high quality material lined up.
Hopefully, this will be a success.
If you are taking the course – then good luck and please share your thoughts with me – I’ve built this course for you and I’d like you to benefit from it as much as possible.
If you aren’t taking it but still want to attend – feel free to enroll. I’ll be closing up course signups end of this week, with no clear indication if and when I’ll be running it next.
Now quiet please – there are people studying in here. Somewhere. Hopefully.
The post Quiet please – people are studying appeared first on BlogGeek.me.
WebRTC course starts Monday next week.
At long last, the wait will be coming to an end and my recent sleepless nights as well. I’ve been working these past months to put up the content for the course, not knowing how it will end up.
Most of the materials have been recorded, uploaded and prepared already, waiting for me to just manually add all the people who enrolled. There’s a lot of material in that course, and a lot more that I am sure is still missing in there. Trying to cover WebRTC in its entirety isn’t easy.
Through the process of putting this stuff up and out there, I’ve learned a lot myself.
The course is split into 7 sections:
Most of the lessons are already ready. There are around 6 lessons that I still need to write. Hopefully, they will be available on launch day, but if not, then the following week.
I want to answer a few quick questions here – things I’ve been asked time and again in the past month:
Is this a one-time thing?Yes and no.
The course takes place October 24 and lasts for 2 months. Those who enroll for office hours get an extended duration of 4 months (as well as office hours).
I don’t plan on doing this an ongoing thing where you can enroll whenever and do the course. I will be taking the time throughout these two months to listen to the students and see if there’s anything that requires updating in “real time”. I can’t do it if this is an ongoing thing.
This might change in the future, but for now, there’s this timing.
I might do that some months from now, after I rest a bit from the effort and decide if it makes financial sense to run it again.
If you have your own timing issues, then understand that the course is self-paced. You can “leave” for a week or two and come back, do it faster or slower.
Is the course for me?I can’t really say.
Here are a few types of students that I have already enrolled for the course:
The course doesn’t include too much code. There’s the occasional piece of code shown, but the idea isn’t to explain to you how to develop with WebRTC. In truth – most of you won’t develop with WebRTC directly anyway – you’ll end up using a framework or a third party for that.
The intent is to give you the understanding of the limits and capabilities of WebRTC. To know how to yield this amazing tool and how to use it effectively in your product.
How is the course conducted?If you enrolled, then you will be receiving an email a day or two prior to the course.
I will be registering you to the course mini-site inside the BlogGeek.me website. Once you login, you will be able to access all course sections and lessons.
Each lesson has a page of its own in the site. Most lessons have a recorded video session as the main bulk of it, along with text and additional reading material. In most cases, that additional reading material is important.
You can “tune in” to any lesson you wish and learn it at your own pace and in your free time.
There is an online forum for the course. Students will be able to raise their questions, issues and feedback there. If things require changes on my end, I’ll try making the changes to the lessons as we move along, maybe even adding course materials and lessons if the need will arise. I will also be using the forum to ask questions myself, and check out on the progress of students.
For those taking office hours, these will take place twice a week at different times to accommodate different time zones. In there, I will answer questions as they come and basically make myself available to you “in the flesh”. I haven’t decided yet which WebRTC service to use for that – suggestions are welcome.
I am still debating if I should use quizes as part of the course, placing them at the end of each section or not. If you have an opinion – please voice it (even if you’re not going to attend the course).
Enroll today
Learn how to design the best architecture for our WebRTC service in this new Advanced WebRTC Architecture course.
The course starts next week.
There’s a Q&A page that may answer additional questions you might have.
Official course syllabus is also available in PDF form.
I’d be happy to meet you if you decide to enroll to the course. This is a new thing for me and I an quite excited about it.
If you are not sure about the course – email me. If there’s no fit – I’ll tell you immediately. If this might help you, I’ll explain to you what you will gain from it so you can make a better decision
Until next Monday – have an awesome week.
The post Advanced WebRTC Acrhitecture Course – Updates appeared first on BlogGeek.me.
Phosfluorescently utilize future-proof scenarios whereas timely leadership skills. Seamlessly administrate maintainable quality vectors whereas proactive mindshare.
Dramatically plagiarize visionary internal or "organic" sources via process-centric. Compellingly exploit worldwide communities for high standards in growth strategies.
Wow, this most certainly is a great a theme.
Donec sed odio dui. Nulla vitae elit libero, a pharetra augue. Nullam id dolor id nibh ultricies vehicula ut id elit. Integer posuere erat a ante venenatis dapibus posuere velit aliquet.
Donec sed odio dui. Nulla vitae elit libero, a pharetra augue. Nullam id dolor id nibh ultricies vehicula ut id elit. Integer posuere erat a ante venenatis dapibus posuere velit aliquet.