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.
The FreeSWITCH 1.6.12 release is here!
This is also a routine maintenance release. Change Log and source tarball information below.
Release files are located here:
New features that were added:
Improvements in build system, cross-platform support, and packaging:
The following bugs were squashed:
The future of streaming includes WebRTC.
Disclaimer: I am an advisor for Peer5.
If you look at reports from Ericsson or Cisco what you’ll notice is the growth of video as a large portion of what we do over the Internet. As video takes up an order of magnitude more data to pass than almost anything else we share today this is no wonder. Here are a few numbers from Cisco’s forecast from Feb 2016:
Source: Cisco
I think there are a few reasons for this growth:
The challenge really begins when you look at the Internet technologies available to stream these massive amounts of content:
The challenge with HLS and MPEG-DASH is latency. While this might be suitable for many use cases, there are those who require low latency live streaming:
From my course on WebRTC architectureFor those who can use HLS and MPEG-DASH, there’s this nagging issue of needing to use CDNs and pay for expensive bandwidth costs (when you stream that amount of video, everything becomes expensive).
Which brings me to the recent deal between Peer5 and Dailymotion. To bring you up to speed:
There are other startups with similar technologies to Peer5, but this is the first time any of them has publicized a customer win, and with such a high profile to top it off.
In a way, this validates the technology as well as the need for new mechanisms to assist in our current state of video streaming – especially in large scales.
WebRTC seem to fit nicely in here, and in more than one way only. I am seeing more cases where companies use WebRTC either as a complementary technology or even as the main broadcast technology they use for their service.
It is also the reason I’ve added this important topic to my upcoming course – Advanced WebRTC Architecture. There is a lesson dedicated to low latency live broadcasting, where I explain the various technologies and how WebRTC can be brought into the mix in several different combinations.
If you would like to learn more about WebRTC and see how to best fit it into your scenario – this course is definitely for you. It starts October 24, so enroll now.
Learn how to design the best architecture for our WebRTC service in this new Advanced WebRTC Architecture course.
The post Dailymotion, Peer5 and the Future of Streaming appeared first on BlogGeek.me.
This week mod_opus got a cool new feature that allows the detection of a slow or contaminated link. And verto is converting to adapter.js as well as getting DTMF shortcuts. The FreeSWITCH configuration audit is ongoing with initial minor commits and will continue throughout the year. If you are looking to volunteer to help with that or would like more information email brian@freeswitch.org or join the Bug Hunt on Tuesdays at 12:00pm Central Time.
Join us Wednesdays at 12:00 CT for some more FreeSWITCH fun! And, head over to freeswitch.com to learn more about FreeSWITCH support.
New features that were added:
Improvements in build system, cross-platform support, and packaging:
The following bugs were squashed:
WebRTC isn’t limited to JavaScript.
This is something I don’t get asked directly, but it does pop up from time to time. Especially when people come up with a specific language in mind and ask if it is suitable for WebRTC.
While the answer is almost always yes, I think a quick explanation of where programming languages meet WebRTC exactly is in order.
We will start with a small “diagram”, to show where we can find WebRTC related entities and move from there.
We’ve got both client and server entities with WebRTC, and I think the above depicts the main ones. There are more as your service gets more complicated, but that’s all an issue of scaling and pure development not directly related to WebRTC.
Learn how to design the best architecture for our WebRTC service in this new Advanced WebRTC Architecture course.
So what do we have here?
Web appThe web app is what most people think about when they think WebRTC.
This is what ends up running in the browser, loaded from an HTML and its derivatives.
What this means is that the language you end up with is Java Script.
Mobile appWhen it comes to the mobile domain, there are two ways to end up with WebRTC. The first is by having the web app served inside a mobile browser, which brings you back to Java Script.
The more common approach though is to use WebRTC inside an app. You end up compiling and linking the WebRTC codebase as an SDK.
The languages here?
There’s also the alternative of C# via Xamarin or Java Script again if you use something like Crosswalk. With these approaches, someone should already have WebRTC wrapped for you in these platforms.
Embedded appEmbedded is where things get interesting.
There are cases where you want devices to run WebRTC for one reason or another.
Two main approaches here will dictate the languages of choice:
In general, here you’ll be going to lower levels of abstraction, getting as close as possible to the machine language (but stopping at C most probably).
TURN serverSTUN and TURN servers are also necessary. Most likely – you won’t be needing to do a thing about them besides compiling, configuring and running them.
So no programming languages here.
I would note that the popular open source alternatives are all written in C. Again – this doesn’t matter.
Media serverMedia servers come in different shapes and sizes. I’ve covered them here recently, discussing Jitsi/Kurento and later Kurento/Janus.
The programming languages here depend on the media server itself. Jitsi and Kurento are Java based. Janus is mostly C. In most cases – you wouldn’t care.
Media servers are usually entities that you communicate with via REST or Websocket, so you can just use whatever language you like on the controlling side. It is a very popular choice to juse Node.js (=Java Script) in front of a Kurento server for example. It also brings us to the last entity.
App/Signaling serverThe funny thing is that this is where the question is mostly targeted at. The application and/or signaling server is what stitches everything together. It serves the web app, communicates with the mobile and embedded apps. It offers the details of the TURN server and handles any ephemeral passwords with it, it controls the media servers.
And it is also where the bulk of the development happens since it holds the business logic of the application.
And here the answer is rather simple – use whatever you want.
In general, whatever you can use to build websites can be used to build a WebRTC service.
What’s your language?Back to you. What is the programming languages you use with WebRTC?
If you are looking for developers, then what would be the languages you’d view as mandatory and which ones as preferable with applicants?
–
This as well as other topics are covered in my upcoming Advanced WebRTC Architecture course. Be sure to enroll if you wish to deepen your understanding in this topic.
The post What’s Your Preferred Language for WebRTC Development? appeared first on BlogGeek.me.
So far so good, but it is time to add some more options for you.
A selection of three different course packagesI am working to complete all lessons for the course. It takes time to work things through, go over the lessons, make sure everything is in order and record the sessions.
The interesting thing to me is the variety of people that enroll to this course – they come from all over the globe, varying from small startups to large companies. I found some interesting vendors who are looking at WebRTC that I wasn’t aware of.
A few updates about the courseThere are a few minor updates that are taking place in the course:
The course duration is 8 weeks, give or take a few days.
That said, if you want access to the recorded materials for a longer period, then you might want to consider going for the Plus or Premium packages.
The Plus package extends access to the course materials, including the forum and the office hours by an additional 2 months.
Office hours happen twice a week, at two different times to accommodate multiple time zones. During office hours I will be reviewing with the students their learning and understanding of WebRTC and assist in person in areas that will arise. I might even decide to hold a quick online lesson on relevant or timely topics during the office hours.
The Premium package extends access to the curse materials up to a full year. More about the premium package below.
GroupsIf you want to enroll multiple employees or just come join as a team, they just contact me directly.
For large enough groups, I can offer discounts. For others, just the service of proforma invoice and wire transfer (which can still be better than PayPal for you).
We will be having 3-4 medium sized groups in our course this time, which will make things interesting – especially during office hours.
The Premium PackageI decided to add a premium package to the offering.
The idea behind it is to allow those who want more access to my time, and in a more private way.
The premium package offers two substantial additions on top of the Plus package:
In the past few months I’ve noticed a lot of small companies who end up wanting an advice. A few hours of my time to explain to me what they are doing and chat about it, to see if there’s anything I can suggest. I decided to offer this service through this course as well, by bundling it as two consultation calls that go on top of the course itself.
We select together the agenda of these calls and what you want to achieve in them before we start. We then schedule the time and medium to use for the call (think something with WebRTC and a webcam, but not necessarily). And then we sit and chat.
If you already enrolledIf you already enrolled via PayPal and haven’t heard anything from me other than an order form and an invoice – don’t worry. I will be reaching out to all students a week or two before the course.
I am excited to do this, and really hope you are too.
See you next month!
Learn how to design the best architecture for our WebRTC service in this new Advanced WebRTC Architecture course.
The post Advanced WebRTC Architecture Course: Adding a Premium Package appeared first on BlogGeek.me.
This week mod_conference and mod_verto saw the most action with added sounds and user variables, whitelisting, and syncing outbound calls with the user directory respectively. The FreeSWITCH configuration audit is ongoing with initial minor commits and will continue throughout the year. If you are looking to volunteer to help with that or would like more information email brian@freeswitch.org or join the Bug Hunt on Tuesdays at 12:00pm Central Time.
Join us Wednesdays at 12:00 CT for some more FreeSWITCH fun! And, head over to freeswitch.com to learn more about FreeSWITCH support.
New features that were added:
Improvements in build system, cross-platform support, and packaging:
The following bugs were squashed:
The FreeSWITCH 1.6.11 release is here!
This is also a routine maintenance release. Change Log and source tarball information below.
Release files are located here:
New features that were added:
Improvements in build system, cross platform support, and packaging:
The following bugs were squashed:
Recording WebRTC? Definitely server side. But maybe client side.
This article is again taken partially from one of the lessons in my upcoming WebRTC Architecture Course. There, it is given in greater detail, and i recorded.
Learn how to design the best architecture for our WebRTC service in this new Advanced WebRTC Architecture course.
Recording is obviously not part of what WebRTC does. WebRTC offers the means to send media, but little more (which is just as it should be). If you want to record, you’ll need to take matters into your own hands.
Generally speaking, there are 3 different mechanisms that can be used to record:
Let’s review them all and see where that leads us.
#1 – Server side recordingThis is the technique I usually suggest developers to use. Somehow, it fits best in most cases (though not always).
What we do in server-side recording is route our media via a media server instead of directly between the browsrs. This isn’t TURN relay – a TURN relay doesn’t get to “see” what’s inside the packets as they are encrypted end-to-end. What we do is terminate the WebRTC session at the server on both sides of the call – route the media via the server and at the same time send the decoded media to post processing and recording.
What do I mean by post processing?
There are many things that factor in to a recording decision besides just saying “I want to record WebRTC”.
If I had to put pros vs cons for server side media recording in WebRTC, I’d probably get to this kind of a table:
+–No change in client-side requirementsAnother server in the infrastructureNo assumptions on client-side capabilities or behaviorLots of bandwidth (and processing)Can fit resulting recording to whatever medium and quality level necessaryNow we must route media#2- Client side recordingIn many cases, developers will shy away from server-side recording, trying to solve the world’s problem on the client-side. I guess it is partially because many WebRTC developers tend to be Java Script coders and not full stack developers who know how to run complex backends. After all, putting up a media server comes with its own set of headaches and costs.
So the basics of client-side recording leans towards the following basic flow:
We first record stuff locally – WebRTC allows that.
And then we upload what we recorded to the server. Here’ we don’t really use WebRTC – just pure file upload.
Great on paper, somewhat less in reality. Why? There are a few interesting challenges when you record locally on machine you don’t know or control, via a browser:
It all leads to the fact that at the end of the day, client side recording isn’t something you can use. Unless the recording is short (a few minutes) or you have complete control over the browser environment (and even then I would probably not recommend it).
There are things you can do to mitigate some of these issues too. Like upload fragments of the recording every few seconds or minutes throughout the session, or even do it in parallel to the session continuously. But somehow, they tend not to work that well and are quite sensitive.
Want the pros and cons of client side recording? Here you go:
+–No need to add a media server to the media flowClient side logic is complex and quite dependent on the use caseRequires more on the uplink of the user – or more wait time at the end of the sessionNeed to know client’s device and behavior in advance#3 – Media forwardingThis is a lesser known technique – or at least something I haven’re really seen in the wild. It is here, because the alternative is possible to use.
The idea behind this one is that you don’t get to record locally, but you don’t get to route media via a server either.
What is done here, is that media is forwarded by one or both of participants to a recording server.
The latest releases of Chrome allows to forward incoming peer connection media, making this possible.
This is what I can say further about this specific alternative:
+–No need to add a media server into the flow – just as an additional external recording serverRequires twice the uplink or moreDo you want to be the first to try this technique?Things to rememberRecording doesn’t end with how you record media.
There’s meta data to treat (record, playback, sync, etc).
And then there’s the playback part – where, how, when, etc.
There are also security issues to deal with and think about – both on the recording end and on the playback side.
These are covered in a bit more detail in the course.
What’s next?If you are going to record, start by leaning towards server side recording.
Sit down and list all of your requirements for recording, archiving and playback – they are interconnected. Then start finding the solution that will fit your needs.
And if you feel that you still have gaps there, then why not enroll to the Advanced WebRTC Architecture course?
Learn how to design the best architecture for our WebRTC service in this new Advanced WebRTC Architecture course.
The post Recording WebRTC Sessions: client side or server side? 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.