News from Industry

Wasn’t there enough complications already?

I use Hangouts all the time. At testRTC, we use it for most of our demos and customer meetings. As good and complete as Hangouts is in terms of the feature set that I need, it can be quite confusing at times. Something that probably stems from its dual use nature: Google Hangouts is both a consumer messaging app and an enterprise unified communications app. And while the two rely on the same technology – they are not the same.

If there is one other similar service that does that it is Skype, and even with it, it is mostly by branding and not by the service itself (I am not sure how uniform the Skype and Skype for Business apps and infrastructure are, but they sure are getting worse in the last year or two).

Can a single app rule them all? By the way things look today – no.

And yet this latest move by Google leaves me somewhat baffled.

At Google I/O’s keynote yesterday, Google came out with a slew of announcements. The ones interesting for me here are those related to messaging or to WebRTC:

• Allo – a new messaging app to fend off Facebook Messenger
• Duo – a new video chat app to fend off Apple FaceTime
• Firebase – a new version which I won’t be covering here

Allo

Allo is Google’s “Smart Messaging App”.

It is yet-another-messaging-app – until you see the suggestions it gives you.

I use Switfkey as my Android keyboard, and it “learns” what you click so future clicking is shorter. The smart messaging replies in Allo are the next step for me – instead of doing it on the word level it does it on the conversation level.

The smarts in Allo seems to be split into two parts – what Allo does on his own, which is suggestions inside the conversation. On top of it, Google added something they call Google Assistant, which goes “out” of the conversation to offer suggestions for external actions. The example in the I/O keynote was restaurant reservation.

This competes directly with messaging and bots. Specifically Facebook. Maybe others.

Where can this lead us?

• If I were Google, I’d make this into a bot or a layer that can be stitched into everything
• Messaging services could use it directly, which will allow Google to sift every interaction and offer their suggestions and automation – no matter the app
• Would messaging apps adopt it? I don’t know, but why shouldn’t they try it out?

Duo

Duo IS WebRTC. Or at least what you can do with it.

A not about Duo, WebRTC and purism – Duo is mobile only (for now), closed app, running on Android and iOS.

I’ll repeat that.

Duo is mobile only (for now), closed app, running on Android and iOS.

No web browser. No complaints about unsupportive Safari or IE browsers. And from Google.

To those who decide to skip WebRTC just because it doesn’t run on IE or not supported by Safari (without really understanding what WebRTC means) – this should be the best wake up call. Coming directly from Google, the company who wants everything running in the browser.

Recognize anyone in the Duo app?

If tech media outlets taught me anything this time, is that you should be suspicious at what they write.

Ingrid Lunden on TechCrunch did a nice write up on Duo, offering the gist of it:

• 1:1 video chat app, like FaceTime
• Focus is on super fast (responsiveness) and media quality
• You see the caller’s video before you answer a call. A nice gimmick I guess
• Based on WebRTC

This is where things flal apart a bit in her coverage:

The other thing that Duo is touting is the engineering that has gone into making the video in the app work. Google says it will work the same whether your network is superfast or patchy. This in itself, if it really bears out, would be amazing for anyone who has cursed his or her way through a bad Hangout or Skype call.

Duo was built by the same team that created WebRTC and it uses WebRTC, engineering director Erik Kay said today on stage at I/O. It was built using a new programming protocol, Quic, which Google unveiled last year as a route to speeding up data-heavy applications that travel over the web.

So Duo has this magic of working better than Hangouts and Skype. Great. So why didn’t Google just build it into Hangouts? Especially considering both use WebRTC…

That reference to the QUIC protocol – to be sure – this does NOTHING to the actual media – only to the time you wait until the smartphone “dials”. You shave a few hundreds of milliseconds there, but that won’t move the needle in the industry either way.

Mashable’s Raymond Wong explains QUIC and how it is a serious advantage:

Google says people don’t place as many video calls with their friends and family because connections can sometimes be spotty and drop. Duo uses a new protocol called QUIC that’s supposed to be more robust than any other video calling infrastructure out there.

QUIC won’t make the call more robust or get calls work better. It will just make them make the initial connection faster or having the mute button appear QUICker on the other end’s device. QUIC is a nice touch of how Google can go to extremes sometimes with optimizing the technology. Sometimes it makes a lot of sense, but other times less so. QUIC is definitely a step forward from TCP, but its effect on video calling isn’t huge.

What do we have here? Apple FaceTime, done by Google, working on both Android and iOS. Nothing more and nothing less.

 

There’s also Jibe

An acquisition from last year, placing Google as a serious RCS player.

No mention of it in I/O. Probably because its focus is on “fixing”/”improving”/”popularizing” the basic Google Messenger app, which does SMS.

This being something that needs to be synchronized with carriers – it will take time to materialize.

The future of Hangouts

Is the enterprise.

With Allo and Duo, why should consumers even care about Hangouts from now on?

Can this succeed?

Can such an approach succeed for Google? Having multiple communication apps, two of them announced in the same day.

Can they reach mass adoption?

Google is taking the path of unbundling here, but doing it to what was until now the same service – communications. They split it into multiple smaller apps, tearing real time voice and video calling from current messaging apps. It feels somewhat like iMessage and FaceTime, but Allo is more capable than iMessage (sans SMS) and Duo is a bit more capable than FaceTime (the knock knock feature).

I can’t really decide if taking this unbundling approach is better or worse. Will it increase engagement of users with these services or hurt them. And where does Google Hangouts fit in here, if at all?

The post Allo, Duo, Hangouts or Jibe? Help… appeared first on BlogGeek.me.

A refresher on what I’ve written in 2014 (here and here).

Can you guess the signaling and transport here?

WebRTC as a protocol comes without signaling. This means that you as a developer will need to take care of it.

The first step will be selecting the protocol for it. Or more accurately – two protocols: transport and signaling. In many cases, we don’t see the distinction (or just don’t care), but sometimes, they are important. A recent question in the comments section of one of the two posts mentioned here in the beginning, got me to write this explanation. Probably yet again.

WebRTC Transport Protocols and Browsers

This actually fits any browser transport protocol.

A transport protocol is necessary for us to sent a message from one device to another. I don’t care what is in that message or how the message is structured at this point – just that it can be sent – and then received.

HTTP/1.1

5 years ago browsers were simple when it came to transport protocols. We essentially had HTTP/1.1 and all the hacks on top of it, known as XHR, SSE, BOSH, Comet, etc. If you are interested in the exact mechanics of it, then leave a comment and I’ll do my best to explain in a future post (though there’s a lot of existing explanation around the internet already).

I call the group of solutions on top of HTTP/1.1 workarounds. They make use of HTTP/1.1 because there was no alternative at the time, but they do it in a way that makes no technical sense.

Oh – and you can even use REST to some extent, which is again a minor “detail” above HTTP/1.1.

Since then, three more technique materialized: WebSocket, WebRTC and recently HTTP/2.

WebSocket

The WebSocket was added to do what HTTP/1.1 can’t. Provide a bidirectional mechanism where both the client and the web server can send each other messages. What these messages are, what they mean and what type of format they follow was left to the implementer of the web page to decide.

There’s also socket.io or the less popular SockJS. Both offer client side implementations that simulate WebSocket in cases it cannot be used (browser or proxy doesn’t support it). If you hear that the transport is socket.io – for the most part you can just think about it as WebSocket.

When your WebSocket work great, they are great. But sometimes it doesn’t (more on that below, under the HTTP/2 part).

WebRTC’s Data Channel

To some extent, the Data Channel in WebRTC can be used for signaling.

Yes. You’ll need to negotiate IP addresses and use ICE first – and for that you’ll need an additional layer of signaling and transport (from the list in this post here), but once connected, you can use the data channel for it.

This can be done either directly between the two peers, or through intermediaries (for multiple reasons).

Where would you want to do that?

1. To reduce latency in your signaling – this is theoretically the fastest you can go
2. To reduce load on the server – now it won’t receive all messages just to route them around – you’ll be sending it things it really needs
3. To increase privacy – not sending messages through the server means the server can’t be privy to their content – or even the fact there was communication

For the most part, this is quite rare as transport for signaling in WebRTC.

HTTP/2

I’ve written about HTTP/2 before. Since then, HTTP/2 has grown in its popularity and spread.

HTTP/2 fixes a lot of the limitations in HTTP/1.1, which can make it a good long term candidate for transport of signaling protocols.

A good read here would be Allan Denis’ writeup on how HTTP/2 may affect the need for WebSocket.

 

WebRTC Signaling Protocols

Signaling is where you express yourself. Or rather your service does. You want one user to be able to reach out to another one. Or a group of people to join a virtual room of sorts. To that end, you decide on what types of messages you need, what they mean, how they look like, etc.

That’s your signaling protocol.

As opposed to the transport protocol, you aren’t really limited by what the browser allows, but rather by what you are trying to achieve.

Here are the 3 main signaling protocols out there in common use with WebRTC:

SIP

I hate SIP.

Never really cared for it.

It has its uses, especially when it comes to telephony and connecting to legacy voice and video services.

Other than that, I find it too bloated, complex and unnecessary. At least for most of the use cases people approach me with.

SIP comes from the telephony world. Its main transport was UDP. Then TCP and TLS were added as transport protocols for it. Later on SCTP. You don’t care about any of these, as you can’t really access them directly with a browser. So what was done was to add WebSocket as a SIP transport and just call it “SIP over WebSocket”. Before WebRTC got standardized (it hasn’t yet), SIP over WebSocket got standardized and already has an RFC of its own. Why is it important? Because the only use of SIP over WebSocket is to enable it to use WebRTC.

So there’s SIP. And if you know it, like it or need it. You can use it for your WebRTC signaling protocol.

XMPP

I hate XMPP.

Not really sure why. Probably because any time I say something bad about it, a few hard core fans/followers/fanatics of XMPP come rushing in to its rescue in the comments section. It makes things fun.

XMPP has a worldview revolving around presence and instant messaging, and use cases that need it can really benefit from it – especially if the developer already knows XMPP and what he is doing.

If you like it enough – make sure to slam me in the comments – you’ll find their section at the end of this post…

Proprietary

I hate NIH. And yet a proprietary signaling protocol has a lot of benefits in my view.

In many cases, you just want to get the two darn users into the “same page”. Not much more. I know I am dumbing it down, but the alternative is to carry around you extra protocol messages you don’t need or intend using.

In many other cases, you don’t really want to add another web server to handle signaling. You want your web server to host the whole site. So you resolve into a proprietary signaling protocol. You might not even call it that, or think of it as a signaling protocol at all.

How to Choose?

Always start from the signaling protocol.

If there’s reason to use SIP due to existing infrastructure or external systems you need to connect to – then use it. If there’s no such need, then my suggestion would be to skip it.

If you like XMPP, or need its presence and instant messaging capabilities – then go use it.

If the service you are adding WebRTC to already has some logic of its own, it probably has signaling in there. So you just add the relevant messages you need to that proprietary signaling.

In any other case, my advice would be to use a proprietary signaling solution that fits your exact need. If you’re fine with it, I’d even go as far as picking a SaaS vendor for signaling.

 

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

The post WebRTC Signaling Protocols and WebRTC Transport Protocols Demystified appeared first on BlogGeek.me.

This week the possibility to create dedicated audio/video tags for each dialog was added to verto! Also, ClueCon 2016 is just around the corner, register today to seal your spot! And if you would like to attend the training day on August the 12th you will need to sign-up this week! The spaces for that are very limited and we are quickly running out. Visit https://cluecon.com/ for all the information.

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-9157 [verto] Added the possibility to create dedicated audio/video tags for each dialog in verto

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

• FS-8623 [build] Fix libvpx Solaris Studio build
• FS-9152 [mod_avmd] Fixed warnings on FreeBSD
• FS-9155 [Centos] Fixed lang_es and lang_pt package to have the right language module

The following bugs were squashed:

• FS-9151 [mod_av] Fixed playback a mp4 file on a session without video not ending
• FS-9010 [mod_avmd] Dynamic passing of parameters
• FS-8584 [mod_callcenter] Request agents and tiers when reloading queue

If you install FreeSWITCH 1.6 on Debian 8 from official .deb packages, and then add FusionPBX on top, the server boot sequence needs a modification: now FreeSWITCH configuration depends on the presence of Postgresql server, and it would load an empty configuration if the database service is not available at the moment of start.

This fixup adds a dependency on FreeSWITCH systemd service, so that it launches only after Postgresql has started:

mkdir /etc/systemd/system/freeswitch.service.d/ cat  >/etc/systemd/system/freeswitch.service.d/fusionpbx.conf <<'EOT' [Unit] After=syslog.target network.target local-fs.target postgresql.service EOT
Filed under: Networking Tagged: freeswitch, linux, pbx, voip

Grab your copy now.

I am in the last stretch of updates for my Choosing a WebRTC API Platform report. In the past month, the report has been available at a discounted price – from $1950 down to $1250. Purchasing the report includes 1 year of updates, which means that if you get your copy now – you’ll be receiving the new update next week.

What’s new in the report?

Things are at constant change with the WebRTC ecosystem, and the best place to see it is in the API space. Since the last update, we’ve experienced the rebranding of Comverse as XURA, which affected their Forge platform as well.

Here’s what you will find in the updated report, due next week:

• Updated all vendor profiles and feature sets, so they now reflect the existing
• Added a new vendor – QuickBlox. This brings us to 24 covered platforms in the report
• I added a new KPI to the report – investment level – where I indicate for periods between updates how much investment was made in new features and capabilities in the platform. This can be an indicator to the level of commitment the vendor has to his platform and what to expect moving forward when it comes to new features being introduced
• I’ve written a new Vendor Selection Blueprint. This document can assist you in the vendor selection process by guiding you through it. It includes an Excel sheet as well as a mockup example of such a process for an imaginary use case
• Presentation deck of the visuals has been redesigned and improved, so now if you need visuals – they will be even more professional looking

What do you get when you purchase the report?

The report itself isn’t only a PDF file you print and put on your manager’s table. It includes a lot more than that:

• The report, in PDF format (obviously)
• 1 year of free updates, these will cover 1-2 more updates (I tend to publish them every 6-8 months or so)
• Site membership access to additional materials
• Online comparison matrix, to make quick comparisons easy to handle
• Presentation visuals, which you can use in your own presentations
• Vendor Selection Blueprint, to guide you through the vendor selection process
• Access to the monthly Virtual Coffee sessions as well as the archived sessions

How to purchase?

Online.

1. Go to the WebRTC PaaS report page
2. Scroll down to the end of the page
3. Select the Premium option and press the BUY NOW button
4. Use your PayPal account or a credit card to make the purchase

If you do this in the next couple of days – you are guaranteed to enjoy the discounted price.

The post Last Chance to Enjoy a $700 Discount on my WebRTC PaaS Report appeared first on BlogGeek.me.

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

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

Hope to see you there!

Erik

The Keys to the Communications Universe

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

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

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

Thank you!

Warm hugs, Jeff

The real benefits of Apple and WebRTC has been left out of the conversations.

Can you help Apple find WebRTC?

There’s been too much chatter recently about Apple adding WebRTC. I am definitely in the opinion of Fippo here:

Things are going wild on the twitter #webrtc tag. Not a day without someone writing about Apple and WebRTC. Usually with little actual information.

I am not one to say I have inside information – I don’t. I don’t even know personally any Apple employee.

What I can say for sure, is that the real discussion on why Apple is important in the ecosystem of WebRTC has been ignored – as does the only place that is important.

Apple can add WebRTC in 3 places:

1. Safari on Mac OS X
2. Safari on iOS
3. Webview on iOS

Just as a point of reference, when Google adopted WebRTC, it added it to Chrome on the desktop, then to Chrome on Android and somewhat later to Android webview. Not surprisingly, the priorities were decided based on the complexity and risk of the tasks (from the “easiest” to the most complex).

WebRTC in Mac OS X Safari

Safari on Mac OS X is nice, but at this point it won’t matter much. For the most part, Chrome is the leading browser these days – surpassing even IE; and from asking around, it seems that Mac users are used to switching from Safari to Chrome when needed – it isn’t unheard of.

Adding support for WebRTC to Safari on Mac OS X is nice, but for the most part, it won’t change things in any meaningful way.

WebRTC in iOS Safari

Safari on iOS is interesting. For iOS, there’s only a single alternative today, and that’s to port WebRTC on your own and integrate it into your app.

While this works well for most use cases, there are a few edge cases where this isn’t desirable.

Here are 4 such areas:

#1 – Porn

I had an interesting discussion two years ago with a porn vendor who wanted to start exploring WebRTC as a long term solution and a migration path from Flash.

Their main concern was that porn viewers were migrating from the desktop to their smartphones. I guess it has something to do with phone use in restrooms.

Surprisingly (or not), the main reason for him to want WebRTC was iOS. Applications on iOS require to be puritan apps to a large degree. If an app’s content doesn’t abide to the app store submission rules (and porn doesn’t), then the app won’t get approved. This becomes a kind of a headache if what you do is serve porn.

There are two ways to “fix” that today, both run in the browser (Safari on iOS that is):

1. Use HLS to stream the video, but the latency wasn’t good for this vendor. He needed low latency. In his words, “the viewer needs to be able to interact with the performer and tell her what to do”. Apparently, waiting 20 or 30 seconds until the performer responds to the viewer’s whims isn’t fast enough
2. Capture JPEG images and send them over HTML as if they are video. It means 3 frames per second or something just as stupid, but it seems porn viewers are happy with it. At least to some extent

Having WebRTC in Safari for iOS means no need to go through the approval process of Apple’s App Store, something impossible for such companies.

As you might have guessed, I learned a lot in the meeting with that company.

#2 – Click to dial

There are times when WebRTC is used for customers and potential customers to reach out to the vendor. They happen to search the internet, bump into your travel agency, and want to make a call to book a flight. Or they might have bumped into an issue with the toaster they purchased and want to ask for assistance. Whatever the case is, that person has no inclination to install an app on his phone just to make that one time interaction.

WebRTC on Safari’s iOS means that this is possible now to achieve for iOS users – and not only the Android ones.

#3 – Guest Access

In many cases, there’s a UC (Unified Communication) system already in use. While its focus is in employees communicating with each other, these systems also allow for guest access. Think of joining one of them GoToMeeting or WebEx sessions. First thing you do in them is install a client to be able to do them – or fumble around with a phone number and a PIN code. Both ugly practices.

WebRTC enables to leave that behind by sending the guest a URL in his email – not a URL with instructions in it, or an installation link – but a URL to the actual session. Along the way, you can also make that URL unique per participant if you wish. This is already available today – unless you use an iOS device.

#4 – Gaming (the gambling kind)

Apple takes 30% of all purchases made through apps. 30%

Gambling and booking usually work on profit margins that are usually lower than 10%.

That being the case, how, if at all, can they make money out of gamblers using apps without letting them pay through the app? The whole idea of gambling is the reduction of friction.

Now, getting gamblers to open a URL and play from there, with whatever interactivity they wish to add through the use of WebRTC – that’s a useful capability.

WebRTC in iOS Webview

This is where things get really interesting.

As stated earlier, most consumption on mobile today is done via apps. For WebRTC, most of these apps are developed as native apps. This happens for a couple of reasons:

1. Force of habit. That’s just life as we know it today
2. Native tends to work slightly better than HTML5 apps
3. WebRTC dictates porting it and wrapping it as an SDK on iOS today

While native is great, HTML5 is even better. It offers cross platform development capabilities across desktop, browser and mobile – and in them, across ALL operating systems. WebRTC isn’t there yet because Apple isn’t there yet.

Add to that the new technique behind PWA (Progressive Web Applications), and you may well find HTML5 enticing for your service. To support such a thing, WebRTC on iOS isn’t enough, but it is still needed. What got this piece of technology into my radar was this write up by Henrik Joreteg – Why I switched to Android after 7 years of iOS. It goes into detail on the user experience of PWAs.

Even if you decide to stick to native development, having WebRTC implemented, optimized and fine tuned by Google and Apple for their respective mobile operating systems and then just slapping a Webview in place to use them in your app is a worthwhile investment.

–

Will Apple add WebRTC to its products? Probably yes

Do we know when will it happen? No

Should we prepare for it? Maybe. You tell me

 

The post What will Happen when iOS Webviews Adopt WebRTC? appeared first on BlogGeek.me.

Time is passing fast, no doubt, feels like yesterday when we were toying with the idea of organizing a Kamailio related conference and now we are one week before its 4th edition.Every year there was an increase in the number of the attendees and we are going to run full house this edition. Of course, we take this chance to celebrate 15 years of development for Kamailio, a long journey, not always smooth, but everything ended up strengthening the project. Being the oldest very active developer, I (Daniel-Constantin Mierla) can say that Kamailio has one of the most active, challenging and pleasant to work with community, including here all the developers and users, this being the main reason of getting to where we are now with the project. Many thanks to all of you for that!Back to the next week, some last minutes updates.
The trip to Fraunhofer Fokus Institute is confirmed and if nothing unexpected happens, those that registered for workshops can choose to visit the NGNI laboratories. It will worth it, few very interesting demos will be shown on site and you can interact with some of the bleeding technologies that may shape the future of how we communicate and interact in real time with all things around us. A shuttle bus will be available to transport between Kamailio World location and Fokus institute. More details are available at:

• https://www.kamailioworld.com/k04/fokus-ngni-laboratories/

If you haven’t participated at the past editions, take a bit of time to get familiar with the address of the event:

• https://www.kamailioworld.com/k04/venue/

Like in the past, it is a single track conference, the schedule is available at:

• https://www.kamailioworld.com/k04/schedule/

The exhibitors are preparing again very interesting product or services show cases and demos for the entire duration of the conference days. Expect some local 4G/VoLTEinfrastructure from NG Voice and Core Network Dynamics. Matrix.org returns this year with an integration between SIP and the matrix federating protocol and platform.Digium will give you the chance to play with their latest SIP phones as well as see demos about the new cool Asterisk features. A consistent team from Sipwise will be around to reveal all the bits of SIP:Provider platform.Special thanks to all sponsors that allowed us to bring again an amazing group of speakers: FhG Fokus, Asipto, Sipwise, Sipgate, Simwood, Evariste Systems, Matrix.org, Digium, Core Network Dynamics, Voicetel, DIDx and Pascom.See you next with in Berlin!

This week we have a new feature in mod_callcenter adding a ring-progressively strategy, extended the XML configuration for avmd, and changes to the pastebin API for the website! Also, ClueCon 2016 is just around the corner, register today to ensure your spot! And if you would like to attend the training day on August the 12th you will need to sign-up this week! The spaces for that are very limited and we are quickly running out. Visit https://cluecon.com/ for all the information.

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-9079 [mod_callcenter] Add ring-progressively strategy which is a way to ring every agent similarly to a top-down strategy but without cancelling the previous calls.
• FS-9124 [avmd] Extend XML config
• FS-9134 [core] Tweaked fscore_pb to use new pastebin API
• FS-9132 [mod_kazoo] Add more variables to default filter

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

• FS-9070 [configuration] Update config.sub and config.guess
• FS-5936 [Debian] ESL.pm packaged for Debian
• FS-9075 [Debian] Additional tweaks to help ease upgrading freeswitch-all

The following bugs were squashed:

• FS-9115 [mod_av] Initial work toward support for audio only mp4 recording
• FS-8795 [mod_png] Fixed an issue with audio only call
• FS-9131 [core] Improve validation of ice candidates to handle malformed as well
• FS-9135 [core] Handle incorrect uses of switch_core_media_set_sdp_codec_string function passing null sdp gracefully
• FS-7783 [core] Properly handle NULL var_name for switch_play_and_get_digits

Kamailio SIP Server v4.4.1 stable is out – a minor release including fixes in code and documentation since v4.4.0. The configuration file and database schema compatibility is preserved.Kamailio v4.4.1 is based on the latest version of GIT branch 4.4, therefore those running previous 4.4.x versions are advised to upgrade. There is no change that has to be done to configuration file or database structure comparing with older v4.4.x.Resources for Kamailio version 4.4.1Source tarballs are available at:

• http://www.kamailio.org/pub/kamailio/4.4.1/src/

Detailed changelog:

• http://www.kamailio.org/pub/kamailio/4.4.1/ChangeLog

Download via GIT: # git clone git://git.kamailio.org/kamailio kamailio
# cd kamailio
# git checkout -b 4.4 origin/4.4Binaries and packages will be uploaded at:

• http://www.kamailio.org/pub/kamailio/4.4.1/

Modules’ documentation:

• http://www.kamailio.org/docs/modules/4.4.x/

What is new in 4.4.x release series is summarized in the announcement of v4.4.0:

• http://www.kamailio.org/w/kamailio-v4-4-0-release-notes/

Thanks for flying Kamailio and looking forward to meeting many of you at Kamailio World Conference 2016 next week in Berlin!

Both.

VP8 and VP9 are video codecs developed and pushed by Google. Up until recently, we had only VP8 in Chrome’s WebRTC implementation and now, we have both VP8 and VP9. This lead me to several interesting conversations with customers around if and when to adopt VP9 – or should they use H.264 instead (but that’s a story for another post).

This whole VP8 vs VP9 topic is usually misunderstood, so let me try to put some order in things.

First things first:

1. VP8 is currently the default video codec in WebRTC. Without checking, it is probably safe to say that 90% or more of all WebRTC video sessions use VP8
2. VP9 is officially and publicly available from Chrome 49 or so (give or take a version). But it isn’t the default codec in WebRTC. Yet
3. VP8 is on par with H.264
4. VP9 is better than VP8 when it comes to resultant quality of the compressed video
5. VP8 takes up less resources (=CPU) to compress video

With that in mind, the following can be deduced:

You can use the migration to VP9 for one of two things (or both):

1. Improve the quality of your video experience
2. Reduce the bitrate required

Let’s check these two alternatives then.

1. Improve the quality of your video experience

If you are happy with the amount of bandwidth required by your service, then you can use the same amount of bandwidth but now that you are using VP9 and not VP8 – the quality of the video will be better.

When is this useful?

• When the bandwidth available to your users is limited. Think 500 kbps or less – cellular and congested networks comes to mind here
• When you plan on supporting higher resolutions/better cameras etc.

2. Reduce the bitrate required

The other option is to switch to VP9 and strive to stay with the same quality you had with VP8. Since VP9 is more efficient, it will be able to maintain the same quality using less bitrate.

When is this useful?

• When you want to go “down market” to areas where bandwidth is limited. Think a developed countries service going to developing countries
• When you want to serve enterprises, who need to conduct multiple parallel video conferences from the same facility (bandwidth towards the internet becomes rather scarce in such a use case)

How is bitrate/quality handled in WebRTC by default?

There is some thing that is often missed. I used to know it about a decade ago and then forgot until recently, when I did the comparison between VP8 and VP9 in WebRTC on the network.

The standard practice in enterprise video conferencing is to never use more than you need. If you are trying to send a VGA resolution video, any reputable video conferencing system will not take more than 1 Mbps of bitrate – and I am being rather generous. The reason for that stems from the target market and timing.

Enterprise video conferencing has been with us for around two decades. When it started, a 1 mbps connection was but a dream for most. Companies who purchased video conferencing equipment needed (as they do today) to support multiple video conferencing sessions happening in parallel between their facilities AND maintain reasonable internet connection service for everyone in the office at the same time. It was common practice to reduce the internet connection for everyone in the company every quarter at the quarterly analyst call for example – to make sure bandwidth is properly allocated for that one video call.

Even today, most enterprise video conferencing services with legacy in their veins will limit the bitrate that WebRTC takes up in the browser – just because.

WebRTC was developed with internet thinking. And there, you take what you are given. This is why WebRTC deals less with maximum bandwidth and more with available bandwidth. You’ll see it using VP8 with Chrome – it will take up 1.77 Mbps (!) when the camera source is VGA.

This difference means that without any interference on your part, WebRTC will lean towards improving the quality of your video experience when you switch to VP9.

One thing to note here – this all changes with backend media processing, where more often than not, you’ll be more sensitive to bandwidth and might work towards limiting its amount on a per session basis anyway.

All Magic Comes with a Price

We haven’t even discussed SVC here and it all looks like pure magic. You switch from VP8 and VP9 and life is beautiful.

Well… like all magic, VP9 also comes with a price. For start, VP9 isn’t as stable as VP8 is yet. And while this is definitely about to improve in the coming months, you should also consider the following challenges:

• If you thought VP8 is a resource hog, then expect VP9 to be a lot more voracious with its CPU requirements
• It isn’t yet available in hardware coding, so this is going to be challenging (VP8 usually isn’t either, but we’re coping with it)
• Mobile won’t be so welcoming to VP9 now I assume, but I might be mistaken
• Microsoft Edge won’t support it any time soon (assuming you care about this Edge case)

This is a price I am willing to pay at times – it all depends on the use case in question.

 

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

 

 

The post VP8 vs VP9 – Is this about Quality or Bitrate? appeared first on BlogGeek.me.

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

B.1 Changes since 01 March 2016

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

Part of development for next major release Kamailio 5.0, we would like to announce that the framework (code-named kemi) which allows writing the routing blocks in embedded languages is already in place. At this moment, Lua or Python can be use as alternative to the native scripting language to write the routing blocks. More details can be found at:

• https://www.kamailio.org/wiki/devel/config-engines

Examples of SIP routing scripts that offer more or less same features as etc/kamailio-basic.cfg are available in source tree at examples/kemi. For convenience of reading, here are the links to git repository:

• the common file setting global and modules parameters as well as specifying the config engine:
  • https://github.com/kamailio/kamailio/blob/master/examples/kemi/kamailio-basic-kemi.cfg
• the part of config with routing blocks in native language:
  • https://github.com/kamailio/kamailio/blob/master/examples/kemi/kamailio-basic-kemi-native.cfg
• the part of config with routing blocks in Lua:
  • https://github.com/kamailio/kamailio/blob/master/examples/kemi/kamailio-basic-kemi-lua.lua
• the part of config with routing blocks in Python:
  • https://github.com/kamailio/kamailio/blob/master/examples/kemi/kamailio-basic-kemi-python.py

You can compare the last three above and see how different or similar they look for providing same SIP routing features using different languages.The work is not finished, lot of modules need to export now functions to embedded config interface, which is quite straightforward:

• https://www.kamailio.org/wiki/devel/config-engines#exporting_functions_to_kemi

Also, a missing part is handling the equivalents of event_route blocks in embedded languages, an ongoing discussion being open on mailing lists..Interesting that some incipient performance tests to compare the interpreters show good results for using especially Lua but also Python:

• https://www.kamailio.org/wiki/devel/config-engines#interpreters_performances

Anyone willing to help can start exporting functions from modules to embedded interface or test some more complex configs in Lua or Python.Thank you for flying Kamailio and looking forward to meeting many of you at Kamailio World Conference in less than two weeks!

tcpkali is a lightweight and  easy-to-use tool that allows you to generate a traffic load with multiple TCP sessions. You push the load in one or both directions at the same time. Also the tool works easily over a NAT’ed connection. This tool is great if you need to test QoS for VoIP applications.

Here’s an example of a bidirectional load test:

# listening machine: listen on tcp port 8000, send traffic, and use 4 threads. # the program will exit in 1 hour. tcpkali -l 8000  --listen-mode=active -m X -T 1h -w 4 # connecting machine: send traffic using 4 threads and 10 simultaneous sessions # for 1 minute tcpkali 192.168.1.109:8000 -m Y -c 10 -T1m -w 4

The above test between directly connected PC Engines APU2 boards has shown 1Gbps of traffic, and the average CPU load was about 50%.

Filed under: Networking Tagged: linux, networking, pcengines, testing, voip

The FreeSWITCH 1.6.8 release is here!

With the release of FreeSWITCH 1.6.8 we see some major improvements in the .deb based packaging. Included in this release is a fix for the freeswitch-all package. Prior to this fix, if certain FreeSWITCH Extensions were not included in the -all package, and a user attempted to install that extension via its stand-alone freeswitch-mod-extension-name package, it was possible to leave the system in a broken state. This fix does make a substantial change to the freeswitch-all package and the number of dependencies included via this package. Due to this change, a bare “apt-get upgrade” will not upgrade the package automatically and you will need to either call ‘apt-get dist-upgrade’ or call ‘apt-get upgrade freeswitch-all’ explicitly. This also brings the freeswitch-all package in line with the freeswitch-meta-all package.

Additionally with these packaging changes, Packages are now available for Ubuntu 14.04. Please see https://freeswitch.org/confluence/display/FREESWITCH/Ubuntu+14.04+Trusty for Ubuntu installation instructions.

This is also a routine maintenance release. Change Log and source tarball information below.

Release files are located here:

• Tarball: http://files.freeswitch.org/releases/freeswitch/freeswitch-1.6.8.tar.gz
• Packaging: https://freeswitch.org/confluence/display/FREESWITCH/Installation

New features that were added:

• FS-8983 [mod_avmd] Enable on outbound channel to make debugging easier
• FS-8875 [mod_avmd] Enable faster beep detection
• FS-9019 [mod_avmd] Extend syntax description to include “[start|stop]” at the end of AVMD_SYNTAX ” “
• FS-9023 [mod_avmd] Add console auto completion
• FS-9020 [mod_avmd] Implement checking of proper configuration of avmd session being started on internal/external channels. Check for read/write codec, CF_MEDIA_SET
• FS-9027 [mod_avmd] Remove assertion from INIT_CIRC_BUFFER and check buffer’s pointer to raw memory dynamically
• FS-9028 [mod_avmd] Check SMA buffer for successful memory allocation
• FS-9031 [mod_avmd] Check session initialization for errors
• FS-9039 [mod_avmd] Use FS enumeration
• FS-9050 [mod_avmd] Fixed APP interface so avmd now exposes single avmd_start_function() for handling APP calls and splits the function into independent calls
• FS-9124 [mod_avmd] Extend XML config
• FS-9024 [mod_avmd] Add events on session start/stop
• FS-9011 [mod_avmd] Add xml configuration file so that avmd parameters can be set by users in this file easily
• FS-8688 [mod_vpx] Implement vp9 processing to avoid chrome hang
• FS-8990 [mod_verto] Adding verto_login header to verto::client_disconnect event
• FS-9077 [mod_verto] Adding verto_hangup_disposition variable to indicate who hangup
• FS-8991 [verto_communicator] Adding translations for French. Thanks Tristan Mahé
• FS-8989 [verto_communicator] Adding Portuguese i18n translations
• FS-8998 [verto_communicator] Adding German, Spanish, Catalan, Chinese, Polish, Russian, Swedish and Indonesian translations.
• FS-8972 [verto_communicator] Add i18n using angular-translate and static file loader
• FS-9038 [verto_communicator] Add translations to support Danish
• FS-9006 [verto_communicator] Add-combobox for languages
• FS-9100 [mod_conference] Set recording failure error if there are zero webcams enabled in a conference and set conference flags or conference member flags with individual variables per flag
• FS-9106 [mod_conference][libvpx] Minor modifications to make vpx in dedicated encoder mode use less cpu, upped the default FPS to 30, and added a new version of previous sleep patch
• FS-8992 [core] Indicate end of candidates in SDP to aid in the resolution of an interop issue with Mozilla
• FS-9134 [core] Tweaked fscore_pb to use new pastebin API
• FS-9052 [mod_hiredis] Add connection pooling, improve dropped connection resiliency, and allow 0.10.0 of hiredis for CentOS 6
• FS-9054 [mod_hiredis] Add ignore-connect-fail profile parameter so that calls do not get killed if limit fails due to lost connection
• FS-9059 [mod_hiredis] Add session logging
• FS-9078 [libsofia] Added hepv2 and hepv3 support, added #pragma for MSVC compiler, and fixed the Windows build of HEPv2/HEPv3 code
• FS-9083 [mod_sofia] Pass On SIP headers from leg A to B
• FS-7125 [mod_sofia] Added an event “wrong_calls_state”. This is for fail2ban logging.
• FS-9080 [mod_spy] Making mod_spy work with Verto channels
• FS-9072 [mod_syslog] Allow logging of messages containing tab character
• FS-9043 [mod_kazoo] Add kz_export of multiple variables instead of calling export application
• FS-9025 [mod_callcenter] Bypass_media_after_bridge working for member channel
• FS-9079 [mod_callcenter] Add ring-progressively strategy which is a way to ring every agent similarly to a top-down strategy but without cancelling the previous calls.

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

• FS-9036 [mod_avmd] Fix warnings on Windows builds
• FS-8988 [mod_avmd] Rename files to include avmd in their name.
• FS-8875 [mod_avmd] Fixed the windows build from this change
• FS-8971 [mod_amqp] There are two different status variables with two different meanings. This splits them back apart.
• FS-8933 [scripts] WIP Fix some breakage on Raspbian as we don’t want the FS repos there yet because we don’t have armhf packages at this time
• FS-8623 [build] Fixed Solaris studio build errors building libvpx
• FS-8780 [build] Fixed the include for Windows builds that point to in tree library
• FS-8883 [build] Fixed compiling due to unused result failure on gnu compiler with –disable-debug
• FS-9000 [build] Fixed compiling on bsd and with libyuv disabled
• FS-9109 [build] A fix for misleading indentation errors on gcc 6.0
• FS-9070 [build] Update config.sub and config.guess to prevent configure failing on arm64
• FS-9091 [build][libyuv] Update libyuv to hash 69245902 from https://chromium.googlesource.com/libyuv/libyuv/ and set it to build all platform files so we don’t have missing symbols on some platforms
• FS-8623 [build][configure] Fixed Solaris studio error trying to compile char[] with c++ compiler and fixed an issue with a necessary flag having issues with the libvpx configure
  FS-8779 [Windows] Fixed the include for Windows builds that point to in tree library
• FS-9075 [Debian] Fix-up for systemd and sysvinit, re-worked the freeswitch-all package, removed some meta-all dependencies that are causing issues, tweaked the freeswitch-meta-all dependencies to more fully install FreeSWITCH, and tweaked the dependencies for freeswitch-init
• FS-9081 [Debian] Use turbo if available for newer jpeg over falling back to old jpeg62-dev
• FS-5936 [Debian] ESL.pm packaged for Debian
• FS-9093 [mod_cv] Remove unnecessary includes

The following bugs were squashed:

• FS-8982 [core] Fixed an issue with play_fsv and play_yuv writing blank_img in parallel
• FS-8918 [core] Fixed an issue with a 10 Second timeout after Notify during Proxy refer
• FS-9002 [core] Fixed an issue with rtp timeout code parsing on video but its designed for audio
• FS-8757 [core] Fixed a buffer overflow in switch_channel_expand_variables_check and switch_event_expand_headers_check
• FS-8949 [core] Fixed an issue with the send end packet for DTMF RTP event not being recognized
• FS-9042 [core] Fixed assert when recording native file
• FS-9062 [core] Fixed a jittery voice issue caused by OPUS mid-call change from 20ms to 40 ms
• FS-9131 [core] Improve validation of ice candidates to handle malformed as well
• FS-9099 [core][sofia-sip] Fixed an issue caused by the web-socket raw frame read timeout being too short and fixed the windows build of web-socket transport
• FS-9078 [sofia-sip] Fixed the linux build of HEPv2/HEPv3 code
• FS-8913 [mod_sofia] Fixed a transfer issue when using bypass_media + SRTP + Inbound late negotiation
• FS-8562 [mod_sofia] Add update support for Mitel user agents
• FS-9049 [mod_sofia] Fixed a DTMF issue
• FS-9060 [mod_sofia] Correct issues with hold and broken soa negotiations after performing a bypass media re-invite
• FS-9086 [mod_conference] Fixed the video files playing in the conference not counting in totals for calculating layout
• FS-8749 [mod_conference] Fixed an issue when loading a video (mp4) for a conference using the “conference play” command “conference pause_play”
• FS-9076 [mod_conference] Added an error prompt to notify that a conference can’t be recorded in pass-thru mode
• FS-8993 [mod_av][mod_conference] Fixed a sync issue on conference playback for a video that is faster frame rate than the conference
• FS-9056 [mod_av] Fixed an issue causing mobile H.264 video to be blank
• FS-8995 [verto_communicator] Added missing toastr in settings controller
• FS-8990 [verto communicator] Added verto_client_address to verto and presence events
• FS-8996 [verto_communicator] Fixed a typo in CAMERA_SETTINGS id and added some Italian translation
• FS-8997 [verto_communicator] Fixed fallbackLanguage
• FS-9012 [verto_communicator] Fixing sidebar in narrow resolutions clipping the video
• FS-9015 [verto_communicator] Minor fixes in Polish translation
• FS-8999 [mod_erlang_event] Fixed broken outbound connection
• FS-9004 [mod_http_cache] Set http get timeout on thread that is actively downloading with the value from the download-timeout configuration and added download-timeout parameter to prevent http_get from waiting unbound time for downloading to finish. Prevented prefetch threads from blocking if another thread is already downloading the same URL.
• FS-7317 [mod_event_socket] Fixed a hang caused by a series of blocks
• FS-8294 [freetdm] Pass in modinstdir to freetdm configure
• FS-9016 [mod_avmd] Fixed a segfault on NULL read codec
• FS-9057 [mod_rtmp] Fixed an issue with screen share feed not taking the floor if the webcam is muted and unmuted
• FS-9058 [mod_hiredis] Allow auto decrement of non-interval limits on channel hangup and fix rate counters so the keys expire after interval completes. Do not auto decrement rate counters. Do not log null responses.
• FS-9074 [mod_skinny] Fixed incorrect location of free causing memory leak of xml when certain errors occur
• FS-9082 [mod_java] Fixed an issue with loading prerequisites if modules are not placed in prefix/mod directory
• FS-9115 [mod_av] Initial work toward support for audio only mp4 recording
• FS-8795 [mod_png] Fixed an issue with audio only call

Session Description Protocol (SDP) is a fundamental, but very unintuitive concept behind how WebRTC works today. Its no wonder that the Anatomy of a WebRTC SDP post and the interactive SDP guide by Quobis CTO, Antón Román has been so popular here on webrtcHacks. With all things WebRTC, things have changed and we were due for an […]

The post Update: Anatomy of a WebRTC SDP (Antón Román) appeared first on webrtcHacks.

How will we be able to live in a world without… SDP?

The one thing I love best about the WebRTC Standards website is that it looks at a place I neglect most of the time – the IETF and W3C. While I had my share of dealings with standardizaton organizations when I was young and pretty, it isn’t something I like doing much these days.

Last month, it seems a decision was made/in the process of being made – to prohibit SDP munging. As these things go, if this happens at all it will take VERY long to happen. That said, such a change will have huge impact on a lot of services that make use of this practice.

What’s WebRTC SDP munging?

SDP munging is a process of a WebRTC application taking its future in its own hands and deciding to change the SDP. With WebRTC, once the application sets the user media and connects it with a peer connection (=setting up to start a session), it receives the SDP blob that needs to be sent to the other participant in the session. This blob holds all of its capabilities and intents for the session.

If you want to learn more about the contents of the SDP, then this article on webrtcHacks will get you started.

Here’s a quick flow of what happens:

Where SDP munging takes place in WebRTC

Now that the application holds the SDP blob, the question that must be asked is what can the application should/can do with this SDP blob?

1. The application should pass it to the other participant. Probably by placing it in an HTTP request or a Websocket message
2. The application can change it (=mung it) before well… setting and sending it

The problem is in that second part.

What’s the problem with WebRTC SDP munging?

SDP embodies everything that is wrong about SIP. Or at least some of what’s wrong about SIP

There are several aspects to it:

1. Being a textual kind of a protocol that is open as hell, it is open to interpretation of humans, making it hard to use. Interoperability is a headache with it, and now we’re leaving it at the hands of web developers. It becomes doubly hard, as there are extensions to SDP – some standardized, some in process and some just proprietary ones. And you need to sift between them all to decide what to do on the SDP level
2. When you modify the SDP, it is assumed that the browser needs to interpret your modifications. Since it already created an SDP, it had its own understanding of what you want, but now he needs to interpret it yet again but instead of doing that through an API, it needs to do it via an ugly text blob. And browsers are created by humans, so they might not interpret it the same way you did when you munged it – or different browsers might interpret it differently
3. New browser versions might not be able to interpret what you munged simply because that isn’t part of their main focus. The smaller you are, the more susceptible you will be to practicing SDP munging – what you do there might not be as popular as you though (or not defined as popular by browser vendors) – and it will break in some future version
4. SDP isn’t that fun to modify with JavaScript. So it frustrates developers which ends up leading to more bugs and inconsistencies

What happens if and when it gets prohibited?

When SDP munging gets banned, existing applications that rely on it will break.

They might break completely, but mostly, they’ll break in ways that are less predictable – codecs won’t be configured in the exact way the developer intended, bitrates won’t be controlled properly, etc.

The whole idea behind SDP munging is to get more control over what the browser decides to do by default, so disabling it means losing that control you had.

When is this change expected?

Not soon, if at all.

That said, I wouldn’t recommend ignoring it.

What I’ve understood is that there’s little chatter about this on the standards mailing lists, so this just might die out.

The reason I think it is important is because at the end of the day, munging the SDP leaves you prone to whims of browser vendors as well as leaves you open to this future option of banning SDP munging.

What should you do about it?

First of all – don’t worry. This one will take time. That said, better plan ahead of time and not be surprised in the future. Here’s what I’d do:

1. Refrain from practicing SDP munging as much as possible
2. Since we’re already starting to see some of the ORTC APIs tricking into WebRTC, you should make an active investment now and in the near future to use these APIs whenever you feel the urge to make changes in the SDP (that’s assuming what you need is supported in the API level and not only via the SDP)
3. If you aren’t sure, then check the code you have to see if you are practicing SDP munging, and if you are, make some kind of a plan on how to wean yourself from it

 

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

The post What if WebRTC SDP Munging was Prohibited? appeared first on BlogGeek.me.

This week there were improvements to mod_conference and libvpx and the addition of a xml configuration file to avmd to allow for easily configurable parameters.

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-9106 [mod_conference][libvpx] Minor modifications to make vpx in dedicated encoder mode use less cpu, turned up default FPS to 30, and added a new version of previous sleep patch
• FS-9011 [avmd] Add xml configuration file so that avmd parameters can be set by users in this file easily

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

• FS-9109 [build] A fix for misleading indentation errors on gcc 6.0
• FS-9100 [mod_conference] Set recording failure error if there are zero webcams enabled in a conference
• FS-9078 [sofia-sip] Fixed the Windows build of HEPv2/HEPv3 code
• FS-9075 [Debian] Fix-up for systemd and sysvinit
• FS-9075 [Debian] Tweaked the freeswitch-meta-all dependencies to more fully install FreeSWITCH
• FS-9075 [Debian] Removing some meta-all dependencies that are causing issues
• FS-9075 [Debian] Tweaks to the dependencies for freeswitch-init

The following bugs were squashed:

• FS-9076 [mod_conference] Added an error prompt to notify that a conference can’t be recorded in pass-thru mode
• FS-9086 [mod_conference] Fixed the video files playing in the conference not counting in totals for calculating layout
• FS-9062 [core] Fixed a jittery voice issue caused by OPUS mid-call change from 20ms to 40 ms
• FS-9099 [sofia-sip][core] Fixed the windows build of web-socket transport and fixed an issue caused by the web-socket raw frame read timeout being too short
• FS-9078 [sofia-sip] Fixed the linux build of HEPv2/HEPv3 code

If the only thing you have is IP calling, then why are you investing in a Slack integration this late in the game?

Looking for gold in Slack by adding WebRTC calls to it?

Slack is a rising star. It has a small and growing set of users, some of which are happy to pay for the service. When it works, it is great. When it doesn’t, well… it then just feels like any other UC or enterprise communication service. I find myself using Slack more and more. Not necessarily because I need to, but rather because I am drawn to it by the teams I collaborate with. I like the experience.

In the last few months it seems that everyone is rushing to Slack, trying to build their own WebRTC integration with it. The latest casualty? LyteSpark.

Browsing Slack’s App Directory, I found the following WebRTC based services under the Communications category:

• Google Hangouts
• Skype
• appear.in
• GoToMeeting free
• Room
• UberConference
• Limnu
• Blue Jeans
• Screenleap
• Yodel
• Videolink2.me
• Quickchat
• KOMASO

There are others, not in the marketplace, and probably a few others in other categories or ones that I just missed.

The problem with many of them is that Slack is actively adding VoIP now – using WebRTC of course.

As I always stated, WebRTC downgrades real time communications from a service to a feature. And now, Slack is adding this feature themselves.

The problem now becomes that these WebRTC services are competing with the built-in feature of Slack – something that will be infinitely easier and simpler to use – especially on mobile, where it is just there. What would be the incentive then to use a Hangouts bot when I can just start the same functionality from Slack without any integration? This is doubly so for free accounts, which are limited to 10 integrations.

The only WebRTC services that can make sense in such a case, are those that have some distinct added value that isn’t available (or easily available through roadmap of Slack). It boils down to two capabilities:

1. Seamless integration with PSTN calling. This is what OttSpott does. I think this is defensible simply because I don’t see Slack going after that market. They will be more inclined to focus on IP based solutions. Just a gut feeling – nothing more
2. Solving a higher level problem than pure voice or video calling. Maybe a widget integration with the customer’s website for click-to-call capabilities, though it can be some other capabilities that focus on a smaller niche or vertical

This Slack-rush of WebRTC services seems a bit unchecked. Basking under the light of WebRTC doesn’t work anymore, so time to move to some other hype-rich territory, and what better place than Slack? Problem is, without a real business problem to solve (conducting a video call over the web isn’t a business problem), Slack won’t be the solution.

 

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

The post The WebRTC Slack-Rush appeared first on BlogGeek.me.

GPUs is most probably where we’re headed.

A couple of months ago, I was approached by SURF. An Israeli vendor specializing in server media processing. As many of its peers, SURF has been migrating from hardware based DSP systems to software systems in their architecture. As they’ve entered the WebRTC space, they wanted to have a whitepaper on the topic, and I accepted the challenge.

The end result? WebRTC Server Side Media Processing: Simplified

Download the whitepaper

Two things that I wanted to share here:

#1 – WebRTC Server Side Media Processing is real

What made writing this whitepaper so interesting for me was the fact that there really is a transition happening – not to using WebRTC – that already happened as far as I can tell. It is something different. A transition from simple WebRTC services that require a bit of signaling to services that process the media in the backend. This processing can be anything from recording to gatewaying, streaming, interoperating or modifying media in transit. And it seems like many commercial use cases that start simple end up requiring some kind of server side media processing.

In the span of the last two months, I’ve seen quite a few services that ended up building some WebRTC server side media processing for their use case. Maybe it is just related to the research I did around this are for the whitepaper, but I think it is more than that.

#2 – The Future Lies in GPUs

As I was working on the whitepaper, this one got published by Jeff Atwood – it is about AI winning a game of Go. Or more accurately, how GPUs are a part of it:

GPUs are still doubling in performance every few years

The whole piece is really interesting and a great read. It also fits well with my own understanding and knowledge of video compression (=not that much).

Two decades ago, video compression was a game of ASIC – the ugliest piece of technology possible. Hard to design and develop. You wanted to implement a new video codec? Great. Carve a few years for the task and a couple of millions to get there. They are hard to design and hard to program for.

Later it was all DSP. Still hard and ugly, but somewhat cheaper and with some flexibility as to what can get done with them. DSPs is what powers most of our phones when it comes to recording and playing back videos. It works pretty well and made it seem as if the device in our pocket is really powerful – until you try using its CPU like a real PC.

GPUs were always there, but mostly for gaming. They do well with polygons and things related to 2D and 3G graphics, but were never really utilized for video compression. Or at least that’s what I thought. I heard of CUDA in passing. Heard it was hard to program for. That was something like 5 years ago I believe.

Then I read about GPUs being used to break hashes, which was an indication of their use elsewhere. The Jeff Atwood piece indicated that there are other workloads that can benefit from GPUs. Especially ones that can be parallelized, and to some extent, video compression is such a task. It is also where SURF is focusing with its own server media processing, which places them in the future of that field.

GPUs are no longer used only for gaming or in our PCs and laptops – they are also being deployed in the cloud. They assist companies running Audocad in the cloud (heard such a story in the recent WebRTC Global Summit event), so why not use them for video compression when possible?

–

If you are interested in WebRTC and how media processing is finding its way to the server, and how that fits in with words like cloud and GPU, then take a look at this new whitepaper. I hope you’ll enjoy reading it as much as I’ve enjoyed writing it.

Download and read this new WebRTC whitepaper.

The post WebRTC and Server GPUs? A whitepaper appeared first on BlogGeek.me.