News from Industry

The features this week include added detection time to beep event in mod_avmd and event_channel_broadcaster API in mod_commands.

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-9069 [mod_avmd] Add detection time to beep event
• FS-9419 [mod_commands] Add event_channel_broadcast api

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

• FS-9424 [build] Define byte order correctly on Solaris/SPARC

The following bugs were squashed:

• FS-9409 [mod_av] Wait for avformat reader thread before reading to prevent spurious EOF and skipped playback
• FS-9415 [mod_spy] Increasing loop so we can also look for variable_verto_user and variable_verto_host to fix mod_spy not reacting on verto channels
• FS-9183 [mod_sofia] Handle 415 Unsupported Media Type as 488
• FS-9422 [core] Fixed an issue with Freeswitch Exit/Crash on SDP negotiation by removing renegotiate-codec-on-hold and renegotiate-codec-on-reinvite
• FS-9410 [core] Fixed PLI Missing Media Source SSRC
• FS-9423 [core] Handle null value in ACL list name

This week we had some great improvements to mod_verto, mod_sofia, mod_conference, mod_avmd, and mod_v8. These changes include support and minor configuration improvements.

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-9281 [mod_verto] Add support for QQVGA resolution in Verto
• FS-9440 [mod_sofia] Add transfer_destination
• FS-9441 [mod_conference] Add the option to not beep between dials in outcall
• FS-9069 [mod_avmd] Add detection time to beep event
• FS-9256 [mod_v8] Add DB.Finalize() in order to close statements.

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

• FS-9161 [mod_verto] Added example Verto settings to example configs
• FS-9362 [mod_sofia] Fixed sofia compile error on newer clang included in new osx
• FS-9449 [build] Enable clock calibration and clock_realtime on Solaris
• FS-9424 [build] Define byte order correctly on Solaris/SPARC
• FS-9447 [mod_avmd] Increase default value of samples to skip to increase robustness against false detections
• FS-9439 [mod_loopback] Check chained loopback for loopback_bowout

The following bugs were squashed:

• FS-9375 [mod_sofia] Fixed DTMF not working on OPUS after call transfer
• FS-9434 [core] Fixed the SDP parser in sofia not recognizing UDP/TLS/RTP/SAVP
• FS-9425 [mod_conference] Fixed a copy and paste error where the height was not set properly
• FS-9436 [core] Fixed RTCP PLI media source SSRC not updating after re-INVITE
• FS-9437 [mod_conference] Delete avatar if video is enabled mid-call
• FS-9423 [mod_sofia] Handle null value in ACL list name
• FS-8783 [libsrtp] Fix alignment issue

I get a feeling that the room system is actually about to change. And that’s probably a good thing.

For many years, video conferencing was defined by the “codec”. The “codec” in this case wasn’t H.264 or any other specification of a video compression standard. It was the term given to the grey box sitting inside a meeting room connected to a camera. For me, a better term for it was always the “room system”. The first ones started as designed, proprietary hardware, running proprietary embedded operating systems. They were connected to a specific camera that was either a part of the box or connected to the box externally – but in most cases was again a proprietary camera.

There have been attempts in the past to replace the room system with something less expensive. I even remember GIPS (remember them? Google acquired them 6 years ago and made WebRTC out of them) writing a post on their blog on how to build your own video conferencing system from an Intel machine and a Logitech webcam. It was nice, but it really didn’t change the industry.

Little has changed in the video conferencing room system. When I stopped following that industry closely, which was a few years ago, things were still in the same trajectory:

• Use proprietary hardware (the industry leaned towards the TI DSP at the time)
• Use Embedded Linux as the OS (at the time, this was actually a refreshing sidestep from VxWorks)
• Use an external proprietary camera (sourced from Sony if you wanted expensive highend or from another vendor if you wanted expensive “lowend”)

Software was taking the same design concepts of embedded platforms and closed systems at the time. You wrote ugly proprietary code from scratch with specialized UI frameworks. No fun at all.

When I decided to write my first posts about WebRTC, I wanted to share my views o f what WebRTC will do to the video conferencing room system. I noted three changes we will see:

So how will we handle it now?

1. Commodity hardware, probably still with proprietary cameras
2. Android operating system
3. WebRTC multimedia and a web browser for signaling and everything else

I wrote it more than 4 years ago. And it still hasn’t happened. What I did fail to see, was how two additional changes are going to affect this industry:

1. Migration towards cloud based deployments, services and business models (specifically in the video conferencing industry)
2. Open hardware. Or at the very least, the constant grind of Moore’s Law and the stupidly capable hardware we have today

Hardware is cool again. IoT (the Internet of Things) made sure of that. Everything from wristbands, to drones, to self driving cars. Somehow, hardware startups had to also look at the video conferencing system.

Highfive was an early indication of that. A company conceived in 2012, just about the time I’ve written my own thoughts on the video conferencing room system. To some extent, also Double Robotics, who made use of an iPad and a Segway-like device. Both employed cloud for their distribution, selling a service around their devices. They were pioneers in selling their own video “codec” (=room system) coupled with a service they host and manage.

In the past month, things seem to be progressing in this same trajectory. Three items on the news recently caught my attention:

#1 – HELLO

HELLO is a video conferencing room system created by Solaborate. Solaborate is a social business/collaboration platform that has been around for several years now. Their CEO, Labinot Bytyqi was interviewed here a few years ago about Solaborate. I am not sure how they are fairing since then, but they must have been busy.

It seems that they are now adding a hardware component to the Solaborate platform in the form of HELLO. And what better place to go about doing that than a Kickstarter campaign?

HELLO Kickstarter

The thing I liked most is the image they shared of their first prototype:

For the uninitiated, that’s the Logitech C920 webcam, cut from its plastic contraption and glued together to something that looks like one of them Linux or Android-in-a-stick devices. Probably what holds the quad core ARM processor. Commodity hardware at its best.

Solaborate took a low goal for their Kickstarter campaign, passing it and then some. They will probably end up below the million dollar mark, but with a rather solid number of backers considering this is at the end of the day an enterprise product.

Oh – and did I mention they use WebRTC?

#2 – Pluot

Pluot is a new startup I came across over TechCrunch when they reported that Pluot raised $2.5 million.

The idea isn’t any different than the previous set of vendors. You get a small box and a camera, connected to the Pluot service.

From a hardware standpoint, it isn’t much different than the HELLO box. The camera from the picture is a Logitech C920 one.

The box, if you ask me, is too similar to an Intel NUC.

And it is actually running an Intel off-the-shelf commodity hardware:

The Pluot device is an Intel NUC running Ubuntu Core. […]

All the WebRTC media streams are peer-to-peer. […] That’s why we’re using an Intel Core i3 instead of a cheaper ARM option.

And yes. It is using WebRTC. And guess what? As with Skype, Pluot is also based on Electron (and Chromium as an extension of it):

So we scratched our own itch and built a little appliance, using WebRTC and atom-shell (which is now electron).

Pluot took a different business model approach – one used extensively by mobile operators: the box is free and you pay for the monthly subscription service only.

Commodity hardware, commodity software, commodity video conferencing core inside a Chromium shell, powering the whole video conferencing service.

#3 – Cisco trimming its workforce

In seemingly unrelated news, Cisco is trimming down its workforce. Everywhere in the news that this is mentioned, it also comes with an indication that the cuts are mainly on the hardware side of the house. There’s a need to focus more on software these days.

As one of the biggest players in video conferencing room systems, I wonder what that means. Is it a move towards leaner, more software focused room systems? Is the room systems in Cisco considered hardware or software in essence? Will we see a shift in business models?

–

The room system is slowly starting to change and take a new shape.

This change isn’t just a technical one in the specification of the hardware and software, but goes a lot deeper than that. These changes come with a change of how the room system is built, which parts are developed and which are “sourced” from open source alternatives (or paid third parties), who offers the service and how the business model look like.

 

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

The post Are WebRTC room systems interesting again? appeared first on BlogGeek.me.

A new feature went into mod_sofia, proxy in-dialog calls sip notify and info similar to proxy hold.

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-9276 [mod_sofia] Added proxy in-dialog calls sip notify and info similar to proxy hold

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

• FS-9403 [build] Add timestamp for when user was pushed into queue that lives with the channel

The following bugs were squashed:

• FS-9380 [core] Fixed a problem with ext-rtp-ip not being used when originating
• FS-9401 [core][mod_amqp] Fixed a leak in usage of hash itterator
• FS-8761 [libsofia][mod_verto] Fixed a memory leak

Low latency is critical for interactive live streaming.

Microsoft acquired last week Beam, a company focused on a gamer interactive live streaming service.

According to CrunchBase, Beam has been around for almost 2 years before getting plucked by Microsoft. The investment in them has been smaller than 0.5M USD.

For some reason unknown to me, there are people who love watching other people play games. I guess it is similar to some extent to people sitting down to watch a soccer game. Another thing I can’t really understand. It is the reason why Twitch was acquire by Amazon for almost a billion dollar – a month prior to Beam’s founding.

What Beam worked on was a way to enable viewers to be a part of the game and up their engagement. You do this by allowing viewers to push feedback to the gamers – add challenges to them, buy virtual goods for them, etc. From Beam’s website:

We make it possible for streamers to involve viewers in their gameplay, no matter what game they’re playing.

Want to let your viewers choose your weapon, make quests for you, or even fly a drone around your room? You can do that, all in realtime. Our SDK allows developers to create interactive experiences for existing games with as few as 25 lines of code.

In the console world, there are two major players – Microsoft Xbox and Sony PlayStation. With the acquisition of Beam, Microsoft is trying to build an ecosystem of viewers around the gamers and games offered in Xbox. Will they share the SDK and platform with Sony? It is too soon to tell, especially now that Microsoft is opening up and trying to build large ecosystem around its services as opposed to its operating systems. It might just be that Microsoft is trying to become a big player in gaming in general – not just console ones but also mobile.

Back to Beam and video streaming.

To enable higher and richer interactions between viewers and gamers, and offer the kind of  that, latency higher than a second are detrimental. This makes HLS and MPEG-DASH protocols irrelevant. Flash is on its way out the window. The only other technology that can get to a sub-second latency for real time video streaming then is WebRTC.

 

WebRTC is exactly what Beam has been using in their “protocol” dubbed FTL. It used WebRTC to stream video to the viewers instead of the more traditional mechanism of Flash.

I have been a believer in WebRTC for live streaming and broadcast for over a year now. It is just another place where WebRTC makes a lot of sense, but it will take time for us to get there. The main reason for that is that current implementations are too focused on video chat scenarios – trying to leverage the WebRTC implementation found in Chrome and hooking it up to backend media servers that are again geared towards video chat use cases.

There are 4 different techniques that WebRTC can be leveraged in interactive live streaming (or streaming at all):

1. Use WebRTC’s data channel as a replacement for HTTP(S) to send video packets
   • Theoretically, this should be faster than HTTP and enables optimization to buffering
   • No one has taken that route yet as far as I can tell
2. Build a kind of P2P CDN on top of WebRTC’s data channel
   • Think BitTorrent inside the browser
   • Peer5 and a view other vendors are doing just that
3. Use WebRTC in its full glory – voice and video channels opened and streamed
   • Acquire the original live stream using WebRTC or some other mechanism, and then use WebRTC to connect the viewers via a VOD like architecture to the broadcast
   • Probably the most wasteful of all approached
   • And the one I am guessing Beam is currently employing
4. Optimize on (3) to offer something akin to a Flash/HLS streamer
   • Handle multiple bitrates and resolutions
   • Be able to get high density of streams in a single machine

Options (1) and (2) require knowledge of networking.

Option (2) requires knowledge of P2P networks.

Option (3) requires WebRTC knowledge at its basic level.

Option (4) means you practically implement a WebRTC stack of your own with a focus on live streaming.

My guess is that with time, we will see vendors implementing options (2) and (4) which will be the winning architectures for live streaming.

Option (2) will be deployed to support today’s use cases, while option (4) will be deployed to support future use cases, where interactivity between viewer and broadcaster are important.

Beam took the right challenge on itself. It got it acquired in a short timespan and in a way redefine live streaming and low latency.

For Microsoft, this is yet another acquisition in the WebRTC space, and another area in which it now relies on this technology – even without supporting it on IE.

 

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

The post Microsoft Acquires Beam, Showing the Value of WebRTC to Interactive Live Streaming appeared first on BlogGeek.me.

I was meaning to write something about Skype, Linux and WebRTC. But never got around to it. Until now.

The reason why I decided to write about it eventually? This tweet by Alex:

IMTC (Microsoft, Cisco, polycom, unify, sonus, …) to provide free (no cost) and free (do what you want) webrtc plugin for I.E. And Safari.

— Dr. Alex. Gouaillard (@agouaillard) August 3, 2016

Hmm. The IMTC is planning to offer a FREE plugin for IE and Safari.

Sounds like Temasys, and from the person who worked at Temasys at the time of releasing their plugin – now a commercial one rather than a free offering.

While some like this plugin, others don’t. They tried it and decided that the warning messages it pops up when being installed aren’t worth the effort.

The Electron WebRTC app approach

What did catch my eye was the Skype for Linux announcement. This is an alpha release of the Skype app for Linux – something that Microsoft have been neglecting for quite some time now.

The interesting bit isn’t that Microsoft is actively investing in a Linux version for Skype and acknowledging this part of the user base, but rather how they did that and the stance they have.

Here are a few lines from the announcement on the Skype community site:

The new version of Skype for Linux is a brand new client using WebRTC, the launch of which ensures we can continue to support our Linux users in the years to come.

[…] you’ll be using the latest, fastest and most responsive Skype UI, so you can share files, photos, videos and a whole new range of new emoticons with your friends.

The highlighted text is my own addition.

Here are my thoughts:

• This is implemented on top of WebRTC and not ORTC. In a way, we’ve gone full circle with Microsoft – from ORTC, to adding WebRTC support in Edge to using WebRTC to develop their own products where needed
• Microsoft gives the best reasoning behind using WebRTC in its own development: to ensure continued support for Linux
  • For the most part, using WebRTC equates better support for more devices and platforms than any other technology out there today
  • Yes. You still need to put some effort into getting it working on some platforms – but with a lot less of a hassle than any other technology and at a lower cost
• Responsive Skype UI = HTML5. So there’s some browser engine / rendering engine for HTML in there somewhere
• Latest and fastest…

It turns out Microsoft decided to use Electron.

What is Electron? It is a framework around Chromium that can be used to created desktop apps from web apps. And it is the most popular platform for doing it these days.

The irony.

Microsoft. Who owns, develops and promotes IE and Edge. Who was against WebRTC and for ORTC. That Microsoft used Chromium (effectively Chrome) to bring its Linux Skype app to market.

A few years ago, that would have been unheard of. Today? It makes too much sense – it actually increased the value of Microsoft in my eyes. Making the most practical decision of all and putting the ego aside.

Back to a WebRTC Plugin

So.

The IMTC is now investing its time and effort in a WebRTC plugin. Call me skeptic, but I can’t see this heading in the right direction.

Here’s why:

• The IMTC is an interoperability group. Its strength lies in getting multiple vendors into the same room and having them test their products against each other. “their products” being products that follow the same specification and end up being deployed in the same network and service
• Companies put their money into the IMTC to enable them that testing services
• The problem with WebRTC and the IMTC is that WebRTC doesn’t really require interoperability per se – besides that between browser vendors. And browser vendors aren’t exactly the type of audience the IMTC caters for. To be exact, Microsoft is the only browser vendor who is part of the IMTC – and that’s probably for their Skype for Business product and not Edge or IE
• Writing and maintaining a WebRTC plugin is hard work. It gets updated too frequently to be considered a one-time effort, so maintaining it comes at a cost – a type of cost that is new to the IMTC and its member companies

I believe it will be hard for the IMTC to maintain such a plugin on their own, and if the idea is to open source it to the larger community so the external community can take it up and continue to work and maintain it for the IMTC then that’s just wishful thinking. Open source projects are not synonymous with community development – they don’t all get picked up, adopted, used and maintained by the masses. The webrtc-everywhere project on github shows that – 2 contributors, a few forks, but not much of a collaboration or community around it.

Since the IMTC is a group of vendors who all seek reaching interoperability of the spec while maintaining a technical advantage on the rest of the vendors (I was there once), I can’t see them cooperating for a long term development of such a thing and putting the resources into it while contributing back to the community.

Furthermore, do we really need a WebRTC plugin?

Yes. I know. Safari. Important. IE. All those poor enterprise guys forced to use it. You can’t live without it and such.

But guess what? That same target market? How receptive do you think it will be for a plugin? What will be the install rate and usage rate for a plugin in such environments?

–

I have a warm place in my heart for the IMTC, but I think it is losing its way when it comes to WebRTC. I can’t see how a free plugin for WebRTC today will make a change. There are better things to focus on.

What to do in 2016 with WebRTC on IE/Safari?

There are two use cases here:

1. I need to use the service daily
2. I just want to get on a URL and do whatever needs to be done (call a doctor for example)

The first one can be solved with an installed PC app. A quaint choice maybe, but one which seems to be popular by comms vendors who started from the web. Think Slack or even Whatsapp – they both have a PC app. If you are using a service daily, the idea goes, you might as well just have it somewhere handy in the background of your PC instead of having to have it opened in a browser tab all the time.

The second one is where things get nasty. Asking for a plugin installation for it is just like asking for an app installation for it. Maybe worse if the installer of the plugin comes with a large set of browser warnings (because browsers now hate plugins). So you might just rethink the app option – or just ask the user to come back with a better browser.

My suggestion?

Explore the option of using Electron instead of a plugin.

 

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

The post WebRTC Plugin? An Electron WebRTC app is the only viable fallback appeared first on BlogGeek.me.

The ClueCon 2016 is preparing to start next week in Chicago, IL, USA. Organized mainly by the FreeSwitch developers, the event brings together VoIP enthusiasts from around the world.Many Kamailio friends and community members will be at the event, be sure it worth attending it.Our Fred Posner, from Palner Group/LOD Communications, will present about pairing Kamailio and FreeSwitch to build scalable and secure VoIP systems.The friends at Asterisk PBX project are represented by Matthew Fredrickson of Digium, touching in his presentation the use of Asterisk and Kamailio to enhance SIP presence services.Karl Anderson of 2600hz, which were contributing lately a lot of code to Kamailio’s presence and database extensions, will talk about their open source Kazoo Cloud PBX platform.We spotted some of the big supporters of Kamailio World Conference, respectively Simon Woodhead from Simwood eSMS, Matthew Hodgson from Matrix.org, Mira Georgieva from Zoiper, as well as long time Kamailio friends or developers such as Alexandr Dubovikov from Homer Sipcapture, Emil Ivov from Jitsi/Atlassian, Cezary Siwek, Giovanni Maruzelli, Michael Ricordeau and Tristian Foureur from Plivo.Wishing everyone great season holidays!Thank you for flying Kamailio!

In this github repo, I put together my knowledge about WWAN cards setup, alongside with all initialization scripts.

Filed under: Networking Tagged: 3G, GSM, linux, pcengines, UMTS

Way back in 47 (version that is), Chrome started to mandate the use of HTTPS in conjunction with getUserMedia. To use HTTPS you need a SSL/TLS certificate.  Xander Dumaine covered this a bit for us before, but I still see a lot of people out there struggle with it. As it so happens, the certificate for my […]

The post Let’s Encrypt – how get to free SSL for WebRTC appeared first on webrtcHacks.

This week the ability to add and remove video on re-invites was added.

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-9154 [libsofia] Add & remove video on re-invites

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

• FS-9386 [mod_snmp] Use net-snmp-config for SNMP libs if available
• FS-9385 [mod_conference] Check for ghosts before destroying a conference

The following bugs were squashed:

• FS-9357 [core] Handle packet loss and reset decoder on memory error
• FS-9381 [mod_sofia] Fixed a leak in sofia_presence_chat_send
• FS-9382 [core] Fixed an issue with video broken between two users in verto
• FS-9390 [core] Fixed a ‘Segmentation fault’ during call setup
• FS-9369 [core_media] Added the variable add_ice_candidates=true to enable inserting ice candidates in outgoing sdp
• FS-9394 [mod_av] Fixed the h263 leak

Guess what? Mozilla is removing Hello from Firefox.

It will still be available as an add-on, but it seems to have degraded in its importance to Mozilla, which is understandable.

Goodbye HelloWhat is/was Hello?

Hello was Mozilla’s attempt to build a video calling service. Something that is baked right into the browser, but can be used by any browser supporting WebRTC. Think FaceTime or Hangouts but without the app or even a website.

Mozilla partnered for Hello with TokBox (a Telefonica company), which provided the backend to the service – mainly NAT traversal as far as I can tell.

When Hello was announced, I had my doubts and questions about it.

What went wrong?

A few things were wrong from the onset in Firefox Hello:

1. While it debuted on a desktop browser, its main purpose was mobile. The problem is that Firefox OS got scrapped/pivoted, leaving Hello with no real use
2. It came at a low point in Mozilla’s history. Mozilla partnered during 2014 with 3 vendors, trying to reduce Google’s hold on it: Yahoo, Cisco and Telefonica
   • Yahoo is all but dead – it just got acquired by Verizon
   • Telefonica needed Firefox OS on mobile, and now that that hasn’t matured, my guess is that its interests lie elsewhere these days, so having Telefonica/TokBox as part of Hello probably isn’t helping too much today
   • Cisco only wanted to protect its H.264 investments, which it succeeded
   • This cost Mozilla in focus and diluted its brand from being a pure open alternative
3. Firefox has no real network effect or user base to rely on. It doesn’t connect users to one another but rather it connects viewers to web pages. Having hundreds of millions of viewers doesn’t equate monthly active users for a personal communication tool that is baked into the same product
4. Hello was simple, but offered nothing interesting/innovative/new/needed. People who used apps continued to use apps. Those that wanted to meet over URLs used URLs. Having the button in the browser wasn’t enough to make people leap for the opportunity to use it
5. While available in all WebRTC supporting browsers (=Chrome & Firefox), it was really a Firefox thing. This limited the user base, and especially the ability to start or to really receive a call over a mobile device

The main issue though is that a free video calling service isn’t that much of a deal these days (if this surprises you – just ask Google).

So Mozilla started by embedding Hello right into the browser. Then making it into a system add-on. And now it is making it into just another add-on. I assume it has a lot to do with the usage they’ve seen over the past year for Hello (and its non-adoption). It makes no sense to continue investing the time and effort in it if no one is using it – and having it officially released with the browser once every few months is a waste. Better throw it out of the browser and simplify the browser releases.

The next step might be to sunset the add-on/service altogether and say goodbye to Hello.

Is this predictive to Google’s Duo app?

Google announced Duo and is about to release it. Simplifying things a bit (and dumbing it down), Duo is a FaceTime clone. I covered Allo/Duo a few months back.

On face value, there’s no reason why Google Duo won’t meet a similar fate as Mozilla Hello.

That said, there are a few notable differences:

• Duo is a mobile only app, whereas Hello focused on desktop browsers
• Duo will probably be released on Android and iOS, covering 100% of the mobile market from day one
• Google has a large users base on Android and the ability to get Duo in front of users. It also has the social graph of these people – via the phone’s address book
• While Google kept Duo simple, it did bake two features into it:
  • Speed of connectivity, taking it to the extreme by adding QUIC into the mix
  • Caller’s video sent even before you accept the call

Will this be enough for Google Duo to get the adoption? I don’t know.

Where do we go from here?

In 2016 there should be no doubt anymore:

If you plan to monetize a video calling service, you need a serious business plan.

Most services I see launched have no business plan. They attempt to grow to millions of users. There’s a lot of dumb luck involved in it.

I’ve had my doubts about the viability of Wire as a company due to the same reasons. The only progress made by Wire is open sourcing their app – this doesn’t strike me like a business plan or a signal of strength and healthy growth.

 

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

The post Surprise: Free Video Calling is no Guarantee for Success (or Adoption) appeared first on BlogGeek.me.

This week we saw the addition of customized video mute banners in mod_conference.

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-9230 [mod_conference] Customize video muted banner

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

• FS-9373 [Debian] Added mod-verto and mod-rtc to freeswitch-meta-all package

The following bugs were squashed:

• FS-9355 [core] Fixed a segfault in case of null frame
• FS-9356 [core] Fixed an issue with DTMF not recognized when coming from a Cisco SIP trunk
• FS-9353 [mod_conference] Fixed a problem with clear-vid-floor producing an error while working
• FS-9259 [mod_spandsp] Fixed a missing “m=image 0” when replying to INVITE with disable image line
• FS-9289 [core] Fixed a MOH issue with b side hold causing silence for the a leg
• FS-9365 [core] Fixed the SDP format on reply to RE-INVITE to be RFC-4566 compliant
• FS-9357 [verto communicator] Fixed an issue with VP9 codec screensharing on mod_conference (mux/transcode) not working
• FS-9342 [verto_communicator] Fixed a problem with settings not being saved when closing the settings panel
• FS-9368 [mod_sofia] Fixed a problem with errant duplicate video frames causing video recording issues
• FS-8783 [libsrtp] Fix alignment issue
• FS-9376 [mod_sofia] Fixed a hold negotiation problem on a call received from a Cisco Session Manager

This was a quiet week with a few bug fixes and a minor configuration update.

Join us Wednesdays at 12:00 CT for some more FreeSWITCH fun! And, head over to freeswitch.com to learn more about FreeSWITCH support.

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

• FS-9350 [configuration] Add mod_av commented to modules.conf.xml

The following bugs were squashed:

• FS-9342 [verto_communicator] Properly saving settings to localStorage when closing the settings panel
• FS-9345 [mod_httapi] Fixed an issue with HTTAPI truncating a string when responses span multiple packets
• FS-9343 [mod_smpp] Fixed a problem with failing to send a message via Nexmo
• FS-9352 [core] Fixed overzealous ptime adjust issues on opus

The 96th meeting of IETF (the Internet Engineering Task Force) takes place in Berlin, Germany, during July 17-22, 2016. Ahackaton tied to the IETF meeting is organized during the weekend, July 16-17 .Among the major standardization topics to be discussed, from Kamailio point of view, are: SIP, WebRTC, TURN, IPv6, TLS and DNS (DNSEC/DANE).Daniel-Constantin Mierla and Olle E. Johansson from the Kamailio community will be present at the event.Together with Lorenzo Miniero from Janus WebRTC Gateway project, they plan to organize a meetup (for drinks/dinner) on Monday evening, July 18 — likely to happen at a restaurant nearby IETF meeting, starting around 20:00. If you are in Berlin and want to join, contact us (email to sr-users mailing list or contact directly one of these three persons). Each participant will take care of own expenses, we aim to have an open discussion about what’s new lately and where we head on in real time communications space.Looking forward to meeting some of you next week in Berlin!Thanks for flying Kamailio!

This week we have three great features to announce! First, the addition of mod_sms_flowroute! Second, amplitude estimation in mod_avmd. This particular addition will be neat for those math enthusiasts out there. And finally, mod_dptools got two new API calls.

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-9009 [mod_avmd] Amplitude estimation
• FS-9310 [mod_sms_flowroute] Added native support for Flowroute SMS API over HTTP(S)
• FS-9264  [mod_dptools] Add detect_audio and detect_silence API calls

The following bugs were squashed:

• FS-9241 [mod_sofia] Use tls_public_url instead of tls_url in INVITE Contact when NAT is detected
• FS-9316 [mod_sofia] Fixed an issue caused by INVITE with empty SDP from Cisco VCS not setting up video
• FS-9328 [core] Fixed switch_jb_peek_frame bug where it uses the len of the whole packet and does not subtract the len of the rtp header when copying and returning the size of the packet read.
• FS-9333 [mod_sofia] Disable video refresh by sip INFO by default because this method is outdated
• FS-9337 [core] Fixed invalid sdp generated with soa disabled

Kamailio SIP Server v4.2.8 stable is out! This is a minor release including fixes in code and documentation since v4.2.7.Kamailio v4.2.8 is based on the latest version of GIT branch 4.2.  If you are running previous 4.2.x versions are advised to upgrade to 4.2.8 (or to 4.3.x/4.4.x series). If you upgrade from older 4.2.x to 4.2.8, there is no change that has to be done to configuration file or database structure comparing with older v4.2.x.Resources for Kamailio version 4.2.8Source tarballs are available at:

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

Detailed changelog:

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

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

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

Modules’ documentation:

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

What is new in 4.2.x release series is summarized in the announcement of v4.2.0:

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

Note: the branch 4.2 is an old stable branch. The latest stable branch is 4.4, at this time with v4.4.2 being released out of it. The project is officially maintaining the last two stable branches, these are 4.4 and 4.3. Therefore an alternative is to upgrade to latest 4.4.x – be aware that you may need to change the configuration files and database structures from 4.2.x to 4.3.x/4.4.x. See more details about them at:

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

Important: this version marks the end of planned releases from branch 4.2. From now on the focus is on maintaining the branches 4.4 and 4.3 for stable releases.Thank you for flying Kamailio! Enjoy the summer holidays!

This week was filled with bug fixes and build improvements. This week also marks the one month mark until ClueCon, so be sure to sign up and book a hotel room so you don’t miss out!

Join us Wednesdays at 12:00 CT for some more FreeSWITCH fun! And, head over to freeswitch.com to learn more about FreeSWITCH support.

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

• FS-9317 [configuration] Added screen share examples to the vanilla configurations
• FS-9320 [mod_local_stream] When the entity playing the local_stream video file has a greater or equal frame rate, reduce the buffering
• FS-9315 [mod_http_cache] Added support for video file formats

The following bugs were squashed:

• FS-9301 [mod_sofia] Handled a race condition on startup of mod_sofia with error conditons causing segfault
• FS-9302 [mod_mongo] Fixed mongo_find_one and mongo_find_n to return -ERR when the connection to the database fails
• FS-9221 [mod_conference] Add inactive support for calls to prevent termination if just the video stream is removed
• FS-9303 [mod_conference] Removed unnecessary checks as the video flag is not sent to file open unless using transcode mode, you can record mp4 but it will only contain the audio if in passthru mode
• FS-9305 [mod_conference] Fix for fs_cli crashing due to vid-logo-img incorrectly being set to nothing after originally setting it to a bad image
• FS-9307 [mod_conference] Fixed a race condition caused by trying to use a closed file handle when playing a video file after closing files before video threads are done
• FS-9313 [mod_opus] Fixed sprop_stereo interpretation causing bad audio
• FS-9312 [core] Fixed and unreachable code block in switch_core_media
• FS-9314 [mod_conference] Fixed a crash when starting conference in mux mode while specifying or defaulting to a layout group that does not exist. We will now fall back to transcode mode in this case

Huawei ME909s-120 is the newest modem of Huawei LTE/UMTS family, and it is sold for around $70 at TechShip.se and at Aliexpress.

The modem is immediately recognized as CDC Ethernet device in Debian 8 kernel, and is visible as usb0 interface. In the scripts below, the ttyUSBx serial ports are aliased to ttyWWANxx, and usb0 is renamed to lte0, in order to avoid any naming conflicts with other devices, and also to avoid possible name changes  due to a kernel upgrade.

cat >/etc/udev/rules.d/99-huawei-wwan.rules <<'EOT' SUBSYSTEM=="tty", ATTRS{idVendor}=="12d1", ATTRS{idProduct}=="15c1", SYMLINK+="ttyWWAN%E{ID_USB_INTERFACE_NUM}" SUBSYSTEM=="net", ATTRS{idVendor}=="12d1", ATTRS{idProduct}=="15c1", NAME="lte0" EOT cat >/etc/chatscripts/sunrise.HUAWEI <<'EOT' ABORT BUSY ABORT 'NO CARRIER' ABORT ERROR TIMEOUT 10 '' ATZ OK 'AT+CFUN=1' OK 'AT+CMEE=1' OK 'AT\^NDISDUP=1,1,"internet"' OK EOT cat >/etc/chatscripts/gsm_off.HUAWEI <<'EOT' ABORT ERROR TIMEOUT 5 '' AT+CFUN=0 OK EOT cat >/etc/network/interfaces.d/lte0 <<'EOT' allow-hotplug lte0 iface lte0 inet dhcp     pre-up /usr/sbin/chat -v -f /etc/chatscripts/sunrise.HUAWEI >/dev/ttyWWAN02 </dev/ttyWWAN02     post-down /usr/sbin/chat -v -f /etc/chatscripts/gsm_off.HUAWEI >/dev/ttyWWAN02 </dev/ttyWWAN02 EOT
Filed under: Networking Tagged: 3G, GSM, pcengines