Yap. It is that time of the year for me.
In the past two months there have been lots and lots of summaries, predictions and even reports thrown around about different markets. That’s what you get at the passing of a year.
I had my share of such articles written recently as well:
But it is now time for something that will become a tradition here I hope, which is the yearly WebRTC Start of the Market infographic. I did one last year, so why not this time around as well?
Yes. I know. This one is almost a month into 2017, and I’ve written 2017 and not 2016 on it. In a sense, it was about practicallity – we care about what comes next more than what happened. To some of us, 2016 is almost a long forgotten memory already.About the Infographic
What’s different this year in the infographic?
Vidyo and BlogGeek.me will be hosting a webinar on 2017 WebRTC Market Outlook. I’ll be joining Nicholas Reid, which will make this all the more fun (doing a webinar solo is… lonely).
We will be covering the various stats in the infographic, go over trends and see how we think they will develop into 2017. We will also discuss the just announced Vidyo.io CPaaS and see how it fits into this outlook.
2017 is bound to be interesting and dynamic, so join us.
2017 WebRTC Market Outlook
When? Tuesday, February 7, 2017; 3 pm eastern / noon pacific
Where? OnlineThe Numbers
That’s the big question, and one I’ll be focusing on a lot this year.
Here’s what you can do next:
Thanks again for Vidyo for sponsoring this infographic.
If you think WebRTC is free, then think again.WebRTC is free
I see it everyday and it is glaringly obvious. I probably haven’t made things any better myself with this slide of mine:
WebRTC is free. But lets consider what exactly is free with this technology:
It is a hell of a lot to give for free. Especially if you went to sleep ten years ago and just woke up.What’s missing in WebRTC?
But that’s only a small piece of the puzzle. Or as another slide in my deck usually states:
There are loads of things in WebRTC that you need to do in order to get a service to production. Here’s a shortlist of things that just came to mind:
All these complementary solutions come in different shapes and sizes:
The funny thing is, that whenever you talk to one of the companies developing with WebRTC, they believe everything in WebRTC should be free.
The thing is that building these things on your own will take time and money. Lots of both to be exact.
Same thing about how you end up testing it all or monitoring it. I’d say this is how the market looks like when it comes to testing WebRTC:So what?
If you are planning a product that needs communications, you should definitely consider WebRTC first. Before anything else. It is probably going to be the cheapest technology for your needs but also the best one.
That said, you shouldn’t consider it all free. Plan it. Budget it. Write down your requirements. Decide on your architecture. Figure out who your partners should be in this road.
This is why I decided to start off the year with a giveaway. $1,000 worth of credits on VoxImplant. And all you have to do is signup for it. It just might get you started on your road with WebRTC. And who knows what will happen later on?
If you got until here and haven’t entered your email yet, then you should definitely go back up.
I decided to kick off 2017 with a few interesting initiatives. And the first one is this giveaway – a first that I am doing on my website.
I’ve been following the CPaaS space for quite some time now, and have focused on WebRTC PaaS. CPaaS, PaaS and other XaaS acronyms are confusing. For the laymen, if you want to develop something that needs communication capabilities but don’t want to host the communication service itself – that’s what you end up using. And if this is your case, then why not try out one of the interesting vendors out there?
VoxImplant was kind enough to offer $1,000 in credits for one person.
To enter, all you need to do is place your email in the large giveaway box at the top – and that’s about it.
Be sure to share this giveaway with others using that URL you’ll be getting, as that will increase your chances of winning – and if enough people join the giveaway – will get you a nice bonus as well (even if you don’t win in this giveaway).
What do you have to lose?
Join now, and maybe it will get you a bit faster to your application goal with the help of VoxImplant.
The post Jumpstart Your WebRTC Development with $1000 on VoxImplant appeared first on BlogGeek.me.
How many WebRTC RTCPeerConnection objects should we be aiming for?
This is something that bothered me in recent weeks during some analysis we’ve done for a specific customer at testRTC.
It all started when a customer using Tokbox came to us. He was complaining he couldn’t get the product he built stabilized enough and due to that, couldn’t really get it launched. The reason behind it was partially his inability to decide how many users in parallel can fit into a single session.
So we took that as a side project at testRTC. It is rather easy for us to get 50, 100, 200 or more browsers to direct towards a single service and session and get the analysis we need. So it was easy to use once we’ve written the script necessary. While we have Tokbox customers using our platform, I never did try to go deeper into the analysis until now for such customers. This time, it was part of what the customer expected of us, so it got me looking closer at Tokbox and how they implement multiparty sessions.
In the past couple of weeks we’ve done our digging and got to conclusions of our own. I haven’t meant to write about them here, but a recent question on Stack Overflow compelled me to do so – Maximum number of RTCPeerConnection:
I know web browsers have a limit on the amount of simultaneous http requests etc. But is there also a limit on the amount of open RTCPeerConnection’s a web page can have?
And somewhat related: RTCPeerConnection allows to send multiple streams over 1 connection. What would be the trade-offs between combining multiple streams in 1 connection or setting up multiple connections (e.g. 1 for each stream)?
The answer I wrote there, slightly modified is this one:
Not sure about the limit. It was around 256, though I heard it was increased. If you try to open up such peer connections in a tight loop – Chrome will crash. You should also not assume the same limit on all browsers anyway.
Multiple RTCPeerConnection objects are great:
That said, they have their own challenges and overheads:
A single RTCPeerConnection object suffers from having to renegotiate it all whenever someone needs to be added to the list (or removed).
I’d like to take a step further here in the explanation and show a bit of the analysis. To that end, I am going to use the following:
But first things first. What’s the relationship between these multiparty video services and RTCPeerConnection count?WebRTC RTCPeerConnection and a multiparty video service
While the question on Stack Overflow can relate to many issues (such as P2P CDN technology), the context I want to look at it here is video conferencing that uses the SFU model.
The illustration above shows a video conferencing between 5 participants. I’ve “taken the liberty” of picking it up from my Advanced WebRTC Architecture Course.
What happens here is that each participant in the session is sending a single media stream and receiving 4 media streams for the other participants. These media streams all get routed through the SFU – the box in the middle.
So. Should the SFU box create 4 RTCPeerConnection objects in front of each participant, each such object holding the media of one of the other participants, or should it just cram all media streams into a single RTCPeerConnection in front of each participant?
Let’s start from the end: both options will work just fine. But each has its advantages and shortcomings.Opentok: RTCPeerConnection per user
If you are following the series of articles Fippo wrote with me on testRTC about how to read webrtc-internals, then you should know a thing or two about its analysis.
Here’s how that session looks like when I join on my own and get testRTC to add the 4 additional participants into the room:
Here’s a quick screenshot of the webrtc-internals tab when used in a 5-way video call on the Opentok demo:
One thing that should pop up by now (especially with them green squares I’ve added) – TokBox’ Opentok uses a strategy of one RTCPeerConnection per user.
One of these tabs in the green squares is the outgoing media streams from my own browser while the other four are incoming media streams from the testRTC browser probes that are aggregated and routed through the TokBox SFU.
To understand the effect of having open RTCPeerConnections that aren’t used, I’ve ran the same test scenario again, but this time, I had all participants mute their outgoing media streams. This is how the session looked like:
To achieve that with the Opentok demo, I had to use a combination of the onscreen mute audio button and having all participants mute their video when they join. So I added the following lines to the testRTC script – practically clicking on the relevant video mute button on the UI:
After this most engaging session, I looked at the webrtc-internals dump that testRTC collected for one of the participants.
Let’s start with what testRTC has to offer immediately by looking at the high level graphs of one of the probes that participated in this session:
What we will be doing, is ignore the outgoing media and focus on the incoming one only. Remember – this is Opentok, so we have 5 peer connections here: 1 outgoing, 4 incoming.
A few things to note about Opentok:
For this test run that I did, I had “Conn-audio-1-0 (connection 363-1)” up to “Conn-audio-1-0 (connection 363-5)”. The first one is the sender and the rest are our 4 receivers. Since we are interested here in what happens in a muted peer connection, we will look into “Conn-audio-1-0 (connection 363-2)”. You can assume the rest are practically the same.
Here’s what the testRTC advanced graphs had to show for it:
I removed some of the information to show these two lines – the yellow one showing responsesReceived and the orange one showing requestsReceived. These are STUN related messages. On a peer connection where there’s no real incoming media of any type. That’s almost 120 incoming STUN related messages in total for a span of 3 minutes. As we have 4 such peer connections that are receive only and silent – we get to roughly 480 incoming STUN related messages for the 3 minutes of this session – 160 incoming messages a minute – 2-3 incoming messages a second. Multiply the number by 2 so we include also the outgoing STUN messages and you get this nice picture.
There’s an overhead for a peer connection. It comes in the form of keeping that peer connection open and running for a rainy day. And that is costing us:
Now, this overhead is low. 2-3 incoming messages a second is something we shouldn’t fret about when we get around 50 incoming audio packets a second. But it can add up. I got to notice this when a customer at testRTC wanted to have 50 or more peer connections with only a few of them active (the rest muted). It got kinda crowded. Oh – and it crashed Chrome quite a lot.Jitsi Videobridge: Shared RTCPeerConnection
Now that we know how a 5-way video call looks like on Opentok, let’s see how it looks like with the Jitsi Videobridge.
For this, I again “hired” the help of testRTC and got a simple test script to bring 4 additional browsers into a Jitsi meeting room that I joined with my own laptop. The layout is somewhat different and resembles the Google Hangouts layout more:
What we are interested here is actually the peer connections. Here’s what we get in webrtc-internals:
A single peer connection for all incoming media channels.
And again, as with the TokBox option – I’ll mute the video. For that purpose, I’ll need to get the participants to mute their media “voluntarily”, which is easy to achieve by a change in the testRTC script:
What I did was just was instruct each of my automated testRTC friends that are joining Jitsi to immediately mute their camera and microphone by clicking the relevant on-screen buttons based on their HTML id tags (#toolbar_button_mute and #toolbar_button_camera), causing them to send no media over the network towards the Jitsi Videobridge.
To some extent, we ended up with the same boring user experience as we did with the Opentok demo: a 5-way video call with everyone muted and no one sending any media on the network.
Let’s see if we can notice some differences by diving into the webrtc-internals data.
A few things we can see here:
To make sure we’ve handled this properly, here’s a view of the video channels’ bitrate values:
There’s the obvious initial spike – that’s the time it took us to mute the channels at the beginning of the session. Other than that, it is all quiet.
Now here’s the thing – when we look at the active connection, it doesn’t look much different than the ones we’ve seen in Opentok:
We end up with 140 incoming messages for the span of 3 minutes – but we don’t multiply it by 4 or 5. This happens once for ALL media channels.Shared or per user RCTPeerConnection?
This is a tough question.
A single RTCPeerConnection means less overhead on the network and the browser resources. But it has its drawbacks. When someone needs to join or leave, there’s a need to somehow renegotiate the session – for everyone. And there’s also the extra complexity of writing the code itself and debugging it.
With multiple RTCPeerConnection we’ve got a lot more flexibility, since the sessions are now independent – each encapsulated in its own RTCPeerConnection. On the other hand, there’s this overhead we’re incurring.
Here’s a quick table to summarize the differences:What’s Next?
Here’s what we did:
I have only scratched the surface here: There are other issues at play – creating a RTCPeerConnection is a traumatic event. When I grew up, I was told connecting TCP is hellish due to its 3-way handshake. RTCPeerConnection is a lot more time consuming and energy consuming than a TCP 3-way handshake and it involves additional players (STUN and TURN servers).download the RTCPeerConnection count deck here.
The post WebRTC RTCPeerConnection. One to rule them all, or one per stream? appeared first on BlogGeek.me.
There is no real peak telephony.
[Chad Hart is no stranger to my readers here. He runs webrtcHacks, part of the Kranky Geek team and works at Voxbone. This time, he takes a look at telephony and where it stands today – with and without WebRTC]
Back in April of 2015, I recall Google WebRTC Product Manager Serge LaChapell talking about the WebRTC team’s focus on mobile and how they wanted to kick “VoLTE’s butt”. To be fair he was referencing call connection times, but reading between the lines I like to believe he has had ambitions well beyond that – namely beating VoLTE and the traditional telephony network in minutes.
— Chad Hart (@chadwallacehart) April 15, 2015
For many years I have tried to keep track of how the traditional telecoms has fared against the emerging VoIP application world (what they sometimes derogatorily call “OTT”). I have had two hypotheses for several years now:
Let’s check the data to test these statements.Peak Telephony? Maybe Not…
Digging into the statistics from various sources, I was surprised to find I was wrong about my first hypothesis on peak telephony.The US market
Let’s start by taking a look at the situation in the US, one of the world’s largest communications markets. The Consumer Telecommunications Industry Association (CTIA) provides an annual update that sometimes includes Minutes of Use (MoU) and subscriber data. The data shows that on a subscriber-level, mobile telephony usage already peaked on a per-subscriber basis in 2007.
However, there is a growing number of data-only subscriptions for our tablets and other devices counted as subscribers. This negatively skews the numbers. Looking at “minutes” on a per capita basis is a cleaner metric, so let’s divide the minute figures by the US population. This shows a much more interesting picture where mobile phone usage for traditional calling actually went up by 16%.
Total US cellular telephony minutes appear to be rising after stalling for many years (my calculations)
Checking the data against other FCC sources, this growth may be overstated but there is no clear evidence of decline. So what’s going on? Much of cellular’s continued volumes can be attributed to fixed-mobile substitution – both in terms of people dropping their fixed lines and as the FCC reports “A significant percentage of homes with both landline and wireless phone access received all or almost all calls on wireless telephones despite also having a landline telephone.” If we assumed total PSTN calling was flat, then according to my estimates, a 30% annual decline in fixed line minutes would be required to explain the decrease. This is possible, but way faster than past usage declines in fixed so it is more likely cellular usage did indeed have a very good year in 2015.
There is no clear evidence of peak PSTN telephony in the US, so let’s check some other sources.The UK market
The UK’s Ofcom is generally a much better datasource than the FCC since they look at communications as a whole within the UK and compare it to other countries.
They are a lot more pessimistic when it comes to PSTN-based telephony. Their data is very definitive showing a continued, gradual decline in PSTN call volumes going back to 2010. With a -3% 5 year CAGR, no matter how you cut it, “operator” traffic is down.
Ofcom CMR 2016 report shows declines in operator voice usage
They have not released their global figures for 2015, but their 2014 report showed similar trends with mature markets declining (US, Western Europe, Japan & Korea). However, emerging marketings like China, India, and Russia show show growth and just make up for declines in the mature markets in 2014.Does anyone care about the PSTN anyway?
Outside of adding touch tone dialing and going cordless, the Public Switched Telephone Network (PSTN) telephony user experience hasn’t exactly changed a whole lot in a hundred years. The PSTN is only one way to make calls – now we dedicated VoIP apps, messenger apps with voice, and a growing number of video communications options. Do these new forms for RTC give us any hope of reversing traditional telephony’s demise? The data here is more positive.
Ofcom’s data shows an increasing usage of VoIP for voice calls and a very definitive increase in video call usage. This is consistent with their international research from a year earlier:VoIP Apps Save the Day
So where do newer RTC apps and features fit into all this? Using Ofcom’s methodology, the 18 countries they track produce somewhere around 10 Trillion minutes a year. Microsoft has previously claimed Skype does up to 3 Billion minutes a day – that’s a Trillion minutes a year if one assumes around a 3 Billion daily average. Even if the true annual value is half of that, clearly Skype alone is meaningful compared to PSTN volumes.
Apple does not release any figures for its FaceTime service introduced in 2011, but presumably its usage is substantial, although less than Skype’s based on Ofcom’s past user surveys. WeChat, Line, and Viber all have more than 200 million monthly active users with various VoIP features. WhatsApp now has more than 1 billion MAU. Its VoIP calling feature launched in April 2015 has more than 100 million voice calls a day. Taken together, these other VoIP services are easily more than a trillion minutes a year.
At 10 to 20% of the PSTN’s volume, clearly VoIP traffic has a ways to go before it dominates the PSTN, but there is no doubt its volumes are meaningful in comparison. Furthermore, these services are still growing. Certainly some of that growth will come at the expense of the PSTN, but it appears they are also encouraging more RTC use in general.Does WebRTC matter?
WebRTC does not factor heavily into the services cited above, but that is poised to change. At only 5 years old, WebRTC has not had that much time to widely establish itself in relation to other VoIP technologies. Still, there are a few notable standouts – particularly notably Facebook Messenger. Facebook has stated it has more than 300 million monthly active users of Messenger’s VoIP features and just this week announced it had 245 million monthly video users. Other notable users include Snapchat and of course Google’s Hangouts and Duo services.
There are a lot of other WebRTC apps showing big user gains too such as Houseparty which reported it had 20 million minutes of usage a day last month – not bad for an app that only emerged from the ruins of Meerkat a few months ago. In addition, more traditional VoIP apps like Whatsapp and Skype are starting to use WebRTC, albeit in limited circumstances today but that will certainly grow too.
In aggregate, I estimate WebRTC-based services easily have over 500 million MAU this year across 2 billion devices. Comparing this to other VoIP technologies at the 5 year mark, WebRTC is way ahead. This bodes well for WebRTC to be an incremental driver of VoIP traffic and further accelerator of RTC.Conclusions
I have been concerned that the desire of people communicate in real time reached its pinnacle long ago. Why focus on RTC if the trend is clearly toward “messaging” and other forms of textual interaction? Has telephony peaked? The evidence suggests that is probably the case for the PSTN in developed markets, but there are plenty of pockets of growth. Where declines exist, they are gradual. Even better, there is a large body of evidence that VoIP services are more than making up the gaps of any declines and then some. This indicates that we are actually using real time communications more than even. The recent and rapid rise of many WebRTC services is a further shows that this trend is very likely to continue, or perhaps even accelerate. That’s great news for the hundreds of WebRTC vendors out there and those that have yet to come.
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.
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 baseline
WebRTC 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 passwords
TURN 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 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.
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 resources
In 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 Document
Here’s step by step how I’d go about doing that.Step #1: Structure your document
First 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 overview
First 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 architecture
Now 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 features
To 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. Devices
Here 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.
NAT 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. Scalability
For scalability I make sure I cover a few areas:
Here’s how I fit it into our webinar example:4. Security
The 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.WebRTC Requirements Template and Sample Webinars Requirements Document
Oh, 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.