News from Industry

There’s scaling and then there’s scaling.

The post from last week about the future of WebRTC live broadcast left some interesting impressions. Comments on that post and in Facebook. Red5 even did a follow up post on it.

One thing that was missing from these comments is an understanding of what scale means. Or rather the different types of scaling that are required when it comes to real time video.

Here are a few different aspects of scaling real time video.

#1 – Streams per machine

This is something that was raised on one of the comments on Facebook:

Most of the SFUs out there can actually handle 100’s and even 1000’s of connections (our data is not public but look at JVB:https://jitsi.org/Projects/JitsiVideobridgePerformance) and with most of them it should be possible without much effort to configure multiple SFUs in cascade to scale almost without any limit in my opinion.

That answers the question how many parallel sessions can you conduct on a single machine?

What is this one good for?

When you know how many sessions / streams you plan on having, you can then calculate how many machines you’ll need to run that scenario. From there, it is easier to extrapolate costs.

But that’s not our only vector of scale.

#2 – Streams per session

How many streams can we “bundle” per session?

In the comment above, what was failed to be mentioned was that these tests of 100’s and 100’s of connections were when each session had no more than 33 streams in it. So if what I want is to live broadcast a singer to 1000’s of viewers in real time – this SFU solution won’t be suitable for my need.

It is nice to be able to do multiparty video or to broadcast live with low latency, but always ask yourself – what’s the upper limit here for this single session? How many participants can I cram into that session without making things impossible on my infrastructure?

There are, in general, two critical challenges here:

1. When the number of users per session grows, the amount of communications between peers should be limited. At the extreme, a broadcaster should not be harassed by viewers directly (which is wher e the SFU starts breaking at scale and why I assume Jitsi preferred not to check above 33 participants)
2. When the number of users per session grows beyond a single machine, how does that compute? You’ll need to be able to distribute the session somehow either by cascading or using some other means of architectural magic

It is also worth pointing out that the larger the group, the more fragmentation issues you’ll have across parallel sessions – if the size of a session is dynamic, then on what kind of a machine should you start it? One which is free or one which is already somewhat busy? Can you dynamically route a session to other machines when the need arise? How do you load balance this?

#3 – Failure diffusion

This one is related because the higher the scale and capacity, the more of an issue this will be.

Let’s assume we can get a machine to run 10,000 streams in parallel. I am optimistic today. Let’s also assume that this all happens in a single process running in our machine.

What happens if there’s a bug somewhere (and believe me – there already is), which happen to cause the system to crash? Whenever we hit the bug, 10,000 streams get disconnected.

Now let’s further assume that each session holds 10 streams on average. And the bug was invoked due to one of these streams doing something slightly unorthodox. Now we have one session causing the disconnection of 999 more sessions on that machine.

Which leads us to the question –

Can I run multiple processes on the same machine, each catering a smaller number of sessions? Maybe even only a single session? How does that impact memory and performance? Is it even desirable?

For some, this might be necessary in their architecture – and it is very far from how telecom services are architected…

When Talking About Scaling…

Make sure you refer to the specific aspects you wish to scale.

 

Planning on introducing WebRTC to your existing service? Schedule your free strategy session with me now.

 

The post Different Requirements of Scaling real time video appeared first on BlogGeek.me.

It is in the viewer side.

Live broadcast is all the rage when it comes to WebRTC. In 2015 it grew 3-fold. It is a hard nut to crack, but there are solutions out there already – including the new Spotlight service from TokBox.

WebRTC Live Broadcast Today

If you look closely, most of the deployments today for live broadcast using WebRTC look somewhat like the following diagram:

How you live broadcast using WebRTC today

What happens today, is that WebRTC is used for the presenter – the acquisition of the initial video happens using WebRTC – just right to the broadcast server. There, the media gets transcoded and changes format to the dialects used for broadcasting – Flash, HLS and/or MPEG-DASH.

The problem is that these broadcast dialects add latency – check this explanation about HLS to understand.

With our infatuation to real time and the strive of moving any type of workload and use case towards real time, there’s no wonder that the above architecture isn’t good enough. With my discussions, many entrepreneurs would love to see this obstacle removed with live broadcasts having latency of mere seconds (if not less).

The current approaches won’t work, because they rely heavily on the ability to buffer content before playing it, and that buffering adds up to latency.

WebRTC Live Broadcast Tomorrow

This is why a new architecture is needed – one where low latency and real time are imperatives and not an afterthought.

Since standardization and deployment takes time, the best alternative out there today is utilizing WebRTC, which is already available in most browsers.

How WebRTC live broadcast will look like tomorrow

The main difference here? The broadcast server needs to be able to send WebRTC at scale and not only handle it on its ingress.

To do this, we need a totally different server side WebRTC media implementation than the alternatives on the market today (both open source and commercial).

What happens today is that WebRTC implementations on the server are designed to work almost back-to-back – they simulate a full WebRTC client per connection. That’s all nice and well, but it can’t scale to 100’s, 1000’s or millions of connections.

To get there, the sever will first need to split the dependency on the presenter – it will need to be able to process media by itself, but do that in a way that optimizes for large scale sessions.

This, in turn, means rethinking how a WebRTC media stack is architected and built. Someone will need to rebuild WebRTC from the ground up with this single use case in mind.

I am leaving a lot of the details out of this article due to two reasons:

1. While I am certain it can be done, I don’t have the whole picture in my mind at the moment
2. I have a different purpose here, which we are now getting to

A Skillset Issue

To build such a thing, one cannot just say he wants low latency broadcast capabilities. Especially not if he is new to video processing and WebRTC.

The only teams that can get such a thing built are ones who have experience with video streaming, video conferencing and WebRTC – that’s three different domains of expertise. While such people exist, they are scarce.

Is it worth it?

Optimizing down from 20 seconds latency to 2 seconds latency. That’s what we’re talking about.

Is investing in it worth the effort? I don’t have a good answer for this one.

 

Planning on introducing WebRTC to your existing service? Schedule your free strategy session with me now.

The post The Future of WebRTC Live Broadcast appeared first on BlogGeek.me.

Two messaging services. Focused on consumers. Doing practically the same thing. Do they compete or cooperate under Facebook’s roof?

Messenger and WhatsApp are the biggest messaging platforms toady. Messenger announced 800M monthly active users recently, while WhatsApp celebrated hitting the 1 billion mark. As they both strive to continue with this rapid growth, I have to question – are they joining forces or competing fiercely between themselves.

The reason I raise it stems with how they implemented web support and VoIP:

• Messenger unbundled from Facebook, opening its own independent site, which acts as a full messenger client. If you want to make calls, you use WebRTC for that
• WhatsApp created a web frontend tethered to the phone app. It cannot work without the phone nearby. And when it comes to VoIP, it might be using the same codecs as WebRTC, but not the vinyl implementation

They are taking different architectural approaches. But they end up implementing the same feature set.

WhatsApp in 2015

Here’s what WhatsApp did or was rumored to be working in the last year:

• Experimenting with video calling
• Planning to introduce tools for businesses to communicate with users
• Adds voice calling
• Introducing WhatsApp web

Messenger in 2015

Here’s what Messenger did in the last year:

• Facebook adds video calling to Messenger
• Unbundling Messenger from Facebook accounts – rely on phone numbers
• Unbundling Messenger from Facebook
• Introduced Businesses on Messenger
• Other notable additions include Transportation, sending money

 

Not much of a difference…

Running such a thing at scale of 100’s of millions of people is painfully hard. Doing that twice under the same roof is even harder:

• It seems like they develop everything twice or separate infrastructure and architecture.
• There’s no federation between the two – you can’t send a message from a Messenger user to a WhatsApp user – even though both belong to the same company

Where would each of these services go next for growth?

The above slide from eMarketer shows how in some countries, the main competitor of WhatsApp is Facebook Messenger – and vice versa. I think each of them tries independently to raise his users base – with no real regard of the other’s footprint at any given location.

This one from Activate goes to show how growth for both these platforms come from the same areas – and where they overlap or compete on the same set of users.

–

Something doesn’t work out here for me, though it is hard to lay a finger on it.

WhatsApp is probably still a strange bird in Facebook, far from the rest of the company and its DNA. Getting it in line with Facebook will take considerably more time.

 

The post Are WhatsApp and Messenger competitors or partners in Facebook? appeared first on BlogGeek.me.

Probably not.

I wrote about Peer-to-Peer and WebRTC recently, and got this interesting question due to it from Fabian Bernhard on LinkedIn:

Without arguing about the quality of a specific Open Source media stack, would you say that WebRTC was as big a thing if it didn’t run in a web browser?

I guess the answer is no it wouldn’t be that big a thing.

Here’s where I am getting at it. There are two popular slides I usually use:

The one above explains that WebRTC sits at an intersection – it appeals both to VoIP people as well as to Web people.

The second slide above is about what makes WebRTC so transformative – it is about the fact that it is Free, but also because it is available for Web people.

Without the web browser part, we would have been left with only Free.

We’ve had open source media engines before. GStreamer is a popular one. Codecs were a bit harder to come by – especially those that don’t require patent payments (royalty free). It wasn’t the best thing out there, but it worked – people still use it today.

WebRTC made the open source version of a media engine as good as a commercial one – it came out of an acquisition of a commercial media engine vendor after all.

But that’s where it stops – it wouldn’t have made such a transformation in the market – it would be more of the same with a small evolutionary step. Nothing to write home about.

The browser bit, though… that made VoIP available and open to everyone with some HTML and JS experience – a lot larger pool of talent – and one dabbling a lot in experimentation. This is what got us so many use cases.

Mobile might be different

For mobile only use cases, WebRTC would have made all the difference – same as it does today. The idea behind it in mobile isn’t that it offers a browser experience or that it is available in the browser (it isn’t on iOS). The idea is that it would have been the cheapest route to a product than anything else out there. And with the trend of communications moving in-app, that would still make the impact it does there relevant.

Which brings us full circle.

Let’s assume mobile is eating up the world. Let’s assume it is only a matter of time until content creation and not only content consumption moves from the PC to mobile. Once that happens – who cares about what happens in the browser?

It will all be in-app anyway.

And there – WebRTC is making a difference.

 

Kranky Geek India takes place in Bangalore on 19 March 2016. Register to join us!

The post Would WebRTC be as Big a Thing if it Didn’t Run in a Web Browser? appeared first on BlogGeek.me.

This week we had the addition of a real-time counter for calls in a queue. And in other news we would like to thank everyone that contributed to supporting the FreeSWITCH developers during their summit! They were able to make some exciting progress on some much needed planning and syncing thanks to your support!

Join us Wednesdays at 12:00 CT for some more FreeSWITCH fun! This week we have Jun Sun from Netspectrum! And, head over to freeswitch.com to learn more about FreeSWITCH support.

New features that were added:

• FS-8822 [mod_callcenter] Added a real-time counter for calls in a queue

Improvements in build system, cross platform support, and packaging:

• FS-8808 [core] Fixed ^D in fs_cli with editline to delete char under cursor, not just backspace
• FS-8818 [core] Refactor X-PRE include to not toss error if there are no files that match the include

The following bugs were squashed:

• FS-8812 [core] Respect in_thread_only parameter in switch_channel_check_signal()
• FS-8809 [core] Fixed an undeclared MAP_POPULATE causing compliation failure
• FS-8816 [core] Fixed switch_core_hash_insert_destructor not checking switch_hashtable_insert_destructor() returns
• FS-8821 [core] Added checks for status of executed operation
• FS-8830 [core] Added SDP line separator fix for SDP generated by the core. Sofia when giving an SDP through SOA was parsing the SDP and rewriting it. For endpoints that use the core SDP as is will have more accurate SDP now.

Wondered how you can quickly start your own IMS platform? Thanks to Franz Edler, from University of Applied Sciences, Vienna, Austria, a set of configuration files as well as a WMware Debian image were made available for those that want to start building an IMS platform using Kamailio. Read this documentation written by Franz (original version in pdf format can be downloaded from here)!Kamailio IMS in a BoxHere is a stripped-down version of Kamailio-IMS system – it means that the IMS functions have been reduced to the core functions, all advanced functions like NAT, RTP-relay, antiflood, capturing, dispatching etc… have been omitted (disabled). It is a good starting point for educational purposes. All three servers (P-CSCF, I-CSCF and S-CSCF) and the HSS (from original Fraunhofer OpenIMScore) are running on one machine. The clients are typically provided by the host system.The additional functions which are included in the existing config-files are disabled in a first step and may be added (enabled) gradually. Also an application server (IMS-AS) may be easily added as a further Kamailio instance. This is perfect for educational purpose, if you want to become an IMS expert.The benefit is that all these servers and function are running on one physical machine. There is a VMware image available for this configuration and also the log-file and all relevant config-files in a separate zip-file. Now you can start immediately with the VMware image or – as I always suggest – do it yourself (compile and configure) by following the steps documented in the log-file.The figure below shows the configuration I used:All parameters and passwords used are documented in the log-file.If anything is missing or if you have hints for correction or improvement, just let me know via the sr-users@lists.sip-router.org mailing list.All files are available via dropbox:

• The VMware image:https://www.dropbox.com/s/pwwx009hiigt27v/Debian_8.2-step5-basicKamailio%26basicIMScore.zip?dl=0
• The log-file and the config-files: https://www.dropbox.com/s/ehkzi9pbhlp7njc/Kamailio-IMS%20config-files.zip?dl=0

Good luck, FranzNR: the version above was slightly edited for web and few more explicit details.Read previous articles about Kamailio and IMS!If you build some specific systems using Kamailio and want to share the details with the community, do not hesitate to contact us, we will be more than happy to post an article about it on Kamailio web site!Thanks for flying Kamailio and looking forward to meeting many of you at Kamailio World 2016!

The Call Center World 2016 trade show takes place again in Berlin, during February 22-25, 2016.


While not directly linked to call center solutions, Kamailio SIP Server is often deployed along side a call center system to add more flexibility in SIP routing, redundancy and perform SIP firewalling.

Should you come around and want to meet, contact us at asipto.com.

WebRTC use cases? An endless list of opportunities.

Here are a few, off the top of my head, of use case I’ve came across in the past year or so, where WebRTC was used or seriously planned to be used.

• Simple video chat
• Web conferencing
• International voice calling
• Receiving a call in the browser
• Hospital clowns
• Performing digital art on stage
• Visiting a museum at night
• Praying
• Porn
• Adult gaming
• Gaming
• Doctor visitation
• Group therapy
• Jail visits
• Banking
• Retail
• Drug prescription
• Document signing
• Live broadcasting
• Radio stations
• Music jams
• Karaoke
• Gym classes
• Dance classes
• Teaching and learning online
• Expert consulting
• Contact centers
• CRM integration
• Job interviews
• Virtual classes
• One on one tutoring
• Web meetings
• Webinars
• Dating
• Video streaming
• P2P CDN
• Private messaging
• File sharing and sending
• Assisting hard of hearing people
• Assisting the blind
• Assisting people who need live translation
• Language learning from a tutor
• Practicing language with native speakers
• Security cameras
• Collecting sensor data

Did I miss any WebRTC use cases? Definitely.

What will you do with WebRTC today?

–

And if you built anything – might as well publicize it on the WebRTC Index.

The post WebRTC Use Cases appeared first on BlogGeek.me.

These developers are working hard to bring you more great things from FreeSWITCH. Make their week a little easier by donating to keep them fed. Keep them firmly planted in front of their laptops! Donate today!

Not too big, but not small either.

Here’s a shocker – Facebook Messenger has been updated 19 times on Android in 2016. WhatsApp has had 25 releases in the same time span. And we’re not even in the middle of February.

We are talking about the two messaging applications with the largest number of monthly active users, with WhatsApp surpassing the one billion milestone. gulp.

Should we place messaging apps under weight watchers?

To deliver an app that weighs 26 MB to a billion people (I am thinking WhatsApp here), you end up sending over 23 petabytes of data (translation: a shitload of bits). Doing that 25 times since January 1st…

I took a stab at looking into the consumer messaging apps (some of the enterprise ones are larger, though less frequently updated). Here’s what I found:

#1 – They are all fattening up

The scatter graph above is a bit scattered, but it is easy to see that most apps are increasing in size over time. Since September 2014 until January 2016. They all migrated from the 10-20 MB sizes into the 20-40 MB sizes. That’s a doubling in their weight in less than two years.

We don’t think about it much, but we’re in a serious need of a diet here:

1. This loads our networks. Not as much as video traffic, but still significant
   • Most users have more than one such app on their phone
   • These apps update frequently
   • It adds up
2. With WhatsApp reaching the one billion mark, where will it be headed next?
   • To maintain its growth it needs to search for additional users
   • These need to come from developing countries
   • And there, bandwidth and data is scarce
   • The smaller the app, the easier it is on users to handle
3. Most of the messaging apps don’t seem to care about how fat they are

#2 – Size doesn’t equate feature richness

The bar chart above shows how big the latest version of each of these messaging apps is.

Te results are rater surprising:

• Skype is the bloated of them all at this point in time, but I don’t remember anything new or interesting that Skype on Mobile introduced in the last two years. And yet – it managed to double its size
• Those in the vicinity of one billion users/downloads are trying to stay on the skinny size – Facebook Messenger, WhatsApp and Hangouts are all rather small compared to the rest of the pack – and somehow, Facebook Messenger is even smaller than WhatsApp (I’d expect it to be the opposite)
• WeChat and LINE, which can be seen as e-commerce platforms are larger than most, but somehow Skype and Viber manged to be even bigger

–

I wonder when a diet will be called for. And maybe it already is.

 

Kranky Geek India takes place in Bangalore on 19 March 2016. Register to join us!

The post What’s the Size of Your Messaging app? appeared first on BlogGeek.me.

Next European edition of Kamailio Advanced Training will take place in Berlin, Germany, during March 7-9, 2016.The content will be based on latest stable series of Kamailio 4.3.x, released in June 2015, the major version that brought a large set of new features, currently having the minor release number v4.3.3.The class in Berlin is organized by Asipto  and will be taught by Daniel-Constantin Mierla, co-founder and core developer of Kamailio SIP Server project.Read more details about the class and registration process at:

• http://www.asipto.com/sw/kamailio-advanced-training/

This week we saw the addition of FreeSWITCH initiating late offer calls. This week the FreeSWITCH developer team is meeting to discuss improvements and future features for FreeSWITCH. You can support this effort by donating to help keep them fed while they work. Donations can be made here: FreeSWITCH Developer Summit

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:

• FS-6833 [mod_sofia] Allow Freeswitch to initiate late offer calls

Improvements in build system, cross platform support, and packaging:

• FS-8778 [mod_verto] Define __bswap_64 for FreeBSD as well
• FS-8779 [mod_shout] Properly detect lame/lame.h for FreeBSD
• FS-8808 [mod_avmd] Code refactor to fix indentation and conditional loops.

The following bugs were squashed:

• FS-8768 [mod_callcenter] Releasing database handle after reserving agent
• FS-8802 [core] Fixed an issue caused by the sent timestamp of RTP rolling over to 0 and hitting an error condition causing it to stop sending audio
• FS-8726 [core] Fixed a spurious case of a thread stuck and saturating CPU
• FS-8789 [mod_conference][mod_av] Fix warning thats printed when it shouldn’t be and remove ability to swap to personal canvas while recording and prevent recording while personal canvas is on.
• FS-8805 [verto] Added a sanity check on array

The registration for the 4th edition of Kamailio World Conference & Exhibition is now open – more details and the registration form are available on the website of the event [1].
The event spans over three days, May 18-20, 2016, taking place in Berlin, Germany. The first day contains the technical tutorials, the following two days are for conference presentations and exhibition.The Call for Speakers is still in progress, however, a short list with a relevant group of speakers was made available [2]. The first version of the agenda will be published in the near future, for now you ca see the structure of the event.Looking forward to meeting many of you in Berlin!

• [1] – https://www.kamailioworld.com/k04/registration/
• [2] – https://www.kamailioworld.com/k04/speakers/

Back in October 2013,  the relative early days of WebRTC, I set out to get a better understanding of the getUserMedia API and camera constraints in one of my first and most popular posts. I discovered that working with getUserMedia constraints was not all that straight forward. A year later I gave an update after the […]

The post getUserMedia resolutions III – constraints unleashed appeared first on webrtcHacks.

If you aren’t using AppRTC yet then you should start.

I had a few customers last month who had quality issues with their service. They were trying to understand the root cause of these issues, and at times, the question raised was “is WebRTC up for the task?”

• Does the poor audio quality we experience in our service derive from the codec, the browser’s implementation or something in our own backend?
• Are the video stutters stem from heavy packet loss and that’s just life – or are we adding some of our own issues into the mix?
• The average bitrate we reach in a call. Is it because the browser is limiting us? Is it because the connection is bad? Is it…

The list goes on.

The fact that now you get a fully implemented media engine in the browser for free is great. The problem is, it gives you (or your developers) the opportunity to blame the browser: It isn’t us. Google’s engineers did such a crap job with X that we just can’t fix it.

More often than not – this won’t be the problem.

When in doubt – check AppRTC

Google launched AppRTC quite some time ago.

AppRTC is Google’s way of showcasing WebRTC in their simplest version of the “Hello World” program. This being WebRTC, there are many moving parts, but to some extent, AppRTC is rather baseline – especially in its dealings with media.

This makes AppRTC a great baseline reference when you have issues with the media paths of your own service or just want something to compare it with.

Got an issue? Test what happens when you run AppRTC and compare it with your own service. If you see that your service isn’t performing in the same manner, chances are the problem is on your end – and now you can start diverting focus and resources towards searching the problem instead of blaming the browser.

Where to look for the problems?

• Your NAT traversal servers, if they are being used
• Are you doing any backend processing for the media? Map your pipeline there. Check each step of that pipeline to see if it is to blame
• Transcoding never fails to fail you – check there if you use it
• Jitter buffers are notoriously… jittery. Make sure the implementation fits your use case
• Network routes and handling dynamic bitrates and packet losses might be handled nicely by the browser, but is your backend up for the task as well?

Don’t forget test.webrtc.org either

Google has another great analysis tool – test.webrtc.org

You open the settings, insert your own STUN and TURN server configuration – and start the test.

It will then check the system and network connections to give you a nice view of what the browser is experiencing – something you can later use to understand the environment you operate in.

Why is this important?

With WebRTC, it is easy for developers to blame the browser. This isn’t productive.

Your first task should be to create a baseline reference you can trust. One that enables isolating the issues you are experiencing systematically.

AppRTC is a good place to start.

The post Are You Using AppRTC as Your WebRTC Baseline Reference? appeared first on BlogGeek.me.

Our next Kranky Geek event is taking place in India.

Kranky Geek events? We did them twice. Both times in San Francisco. Both were very successful events. In both we didn’t know if these are one time gigs or something we want to continue doing.

Then we sat down to plan 2016, and came up with three planned events. The first one is taking place in Bangalore, India.

As with any Kranky Geek, this one is about developers of real time communications.

Like previous Kranky Geek events, it is free to attend. Sponsors take the burden of enabling us to plan this event and then pay for everything around it.

Google has been taking the lead here and helping us a lot in getting these events off the ground – in a way taking the leap of faith in our ability to manage these events.

India

Google asked us to do an event in India, so we happily obliged. For me, it would be the first time in India, making the excitement on my end even higher.

India makes sense in a lot of ways. Many of the vendors I end up looking are vendors that are local to India. Others are vendors with large development teams in India who end up doing a lot of the WebRTC development. Kranky Geek India gives me personally a great opportunity to meet many of these people in person.

To make things short:

Where? Bangalore, India

Exact location: MLR Convention Center

Date and time: March 19, 11:00 until we finish

How do I register? here

 

Our sponsors this time are Google, TokBox and IBM. Expect a large cadre of interesting speakers and topics – some local and some international in nature.

I’d love to see you with us at the event!

The post Join us for Kranky Geek India: March 19 appeared first on BlogGeek.me.

The development (master) branch of Kamailio enters now in pre-release phase for version 4.4.0. Therefore, no new feature are going to be pushed to master until a dedicated branch for 4.4 is created (in about 4 weeks or so). The full release should be out by mid of March 2016.If you are a registered developer and in doubt to push or not a commit to master, push it first on a personal branch (or attach to an email) and discuss it on sr-dev. The new modules can be a bit more dynamic if there is need to get them to the right shape (e.g., like decision to rename functions, parameters or adjust database structure).We hope to get many people involved in testing, to reach a stable state before releasing 4.4.0. If you want to get involved and need assistance, don’t hesitate to write to mailing lists. Based on my quick review, there were no major changes to old core components, meaning we should have preserved quite a good level of stability overall.Help with updating the wiki page for migration from 4.3 to 4.4 as well as what is new in 4.4 is very appreciated. We will post updates about them very soon.Many thanks to everyone involved in development of 4.4 and the early testers that played with master branch so far.Thank you for flying Kamailio!Looking forward to meeting many of you at Kamailio World 2016!

Just making sure you’re not missing out…

If you don’t know, in the last year I’ve been part of a great team of partners. We are building together a WebRTC monitoring and testing service called testRTC. The service is up and running for some time now with an increasing number of customers.

The most crappy part of our service was our website (not the one customers are using, but rather the one potential customers look at). So we updated it recently.

One of the main additions to that website is the new blog there. I’ve got an editorial calendar for it running until March with weekly content that I want to share with you, but felt that BlogGeek.me isn’t the best of places for it – it was too focused on testing or too related to testRTC.

What will you find in our testRTC blog?

• Announcements about our service and the versions we are rolling out
• Useful tips for testers, like the one we published yesterday about .y4m files and Chrome
• Things we think you should take care of in your testing practices
• Insights into our design decisions for our internal architecture
• Test script samples of how testRTC can be used to handle certain WebRTC testing issues

So some of the content will be relevant to everyone while other parts of it for those using testRTC.

Subscribe now and follow us

If this sounds interesting, I suggest you subscribe to our blog or social media link(s):

• Subscribe to our blog via RSS or email
• Follow us on twitter
• Follow us on LinkedIn

 

The post Subscribe to the New testRTC Blog appeared first on BlogGeek.me.