News from Industry

The Asterisk Users Conference – AstriCon – is taking place in Glendale, Arizona, during September 27-29, 2016.With a consistent group of VoIP community using both Kamailio and Asterisk projects, Kamailio will have again a strong presence on site this year, including the participation in the expo floor, coordinated this edition by Fred Posner.Along with him, you may meet around Torrey Searle, Nir Simionovich, Joran Vinzens and others that can answer your questions about Kamailio and Asterisk. Like in the past editions, several presentations will touch the use of Kamailio and integration with Asterisk — see agenda.It is definitely a must-attend event if you are looking to build flexible real time communications using Kamailio and Asterisk, or even beyond that, there are not many places around the world where you can find so much VoIP knowledge at the same time along the year!

Chad Hart joins the ClueCon Weekly Team to talk WebRTC

*It should be noted that the lip sync on this video is off due to bandwidth issues on our presenters side.

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

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

Looking forward to meeting some of you in Berlin!

Where is the IMTC focusing it efforts when it comes to WebRTC?

[Bernard Aboba, who is IMTC Director and Principal Architect for Microsoft wanted to clarify a bit what the IMTC is doing in the WebRTC Activity Group. I was happy to give him this floor, clarifying a bit the tweet I shared in an earlier post]

One of the IMTC’s core missions is to enhance interoperability in multimedia communications, with real-time video communications having been a focus of the organization since its inception. With IMTC’s membership including many companies within the video industry, IMTC has over the years dealt with a wide range of video interoperability issues, from simple 1:1 video scenarios to telepresence use cases involving multiple participants, each with multiple cameras and screens.

With WebRTC browsers now adding support for H.264/AVC as well as VP9, and support for advanced video functionality such as simulcast and scalable video coding (SVC) becoming available, the need for WebRTC video protocol and API interoperability testing has grown, particularly in scenarios implemented by video conferencing applications. As a result, the IMTC’s WebRTC Activity Group has been working to further interoperability testing between WebRTC browsers.

In the past, the IMTC has sponsored development of test suites, including a test suite for SIP over IPv6, and most recently a tool for testing interoperability of HEVC/H.265 scalable video coding. For SuperOp 2016, the WebRTC AG took on testing of WebRTC audio and video interoperability. So a logical next step was to work on development of automated WebRTC interoperability tests. Challenges include:

1. Developing basic audio and video tests that can run on all browsers without rewriting the test code for each new browser to be supported.
2. Developing tests covering not only basic use cases (e.g. peer-to-peer audio/video), but also advanced use cases requiring a central conferencing server (e.g. conferencing scenarios involving multiple participants, simulcast, scalable video coding, screen sharing, etc.)

For its initial work, IMTC decided to focus on the first problem. To enable interoperability testing of the VP9 and H.264/AVC implementations now available in browsers, the IMTC supported Philipp Hancke (known to the community as “fippo”) in enhancing automated WebRTC interoperability tests, now available at https://github.com/fippo/testbed. Sample code used in the automated tests is available at https://github.com/webrtc/samples.

The interoperability tests depend on adapter.js, a Javascript “shim” library originally developed by the Chrome team to enable tests to be run on Chrome and Firefox. Support for VP9 and H.264/AVC has been rolled into adapter.js 2.0, as well as support for Edge (first added by fippo in October 2015). The testbed also depends on a merged fix (not yet released) in version 2.0.2. The latest adapter.js release as well as ongoing fixes is available at https://github.com/webrtc/adapter.

With the enhancements rolled into adapter.js 2.0, the shim library enables WebRTC developers to ship audio and video applications running across browsers using a single code base. At ClueCon 2016, Anthony Minessale of Freeswitch demonstrated the Verto client written to the WebRTC 1.0 API supporting audio and video interoperability between Chrome, Firefox and Edge.

–

Got questions or want to learn more about the IMTC and its involvement with WebRTC? Email the IMTC directly.

 

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

The post IMTC: Supporting WebRTC Interoperability appeared first on BlogGeek.me.

Kamailio SIP Server v4.4.3 stable is out – a minor release including fixes in code and documentation since v4.4.2. The configuration file and database schema compatibility is preserved.Kamailio v4.4.3 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.3Source tarballs are available at:

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

Detailed changelog:

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

Download via GIT: # git clone git://git.kamailio.org/kamailio kamailio
# cd kamailio
# git checkout -b 4.4 origin/4.4

Relevant notes, binaries and packages will be uploaded at:

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

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!

Mod_kazoo had some API enhancements, mod_http_cache has GET and PUT from Azure Blob services, and mod_conference added a variable called conference_join_energy_level. The FreeSWITCH configuration audit is ongoing with initial minor commits and will continue throughout the year. If you are looking to volunteer to help with that or would like more information email brian@freeswitch.org or join the Bug Hunt on Tuesdays at 12:00pm Central Time.

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

New features that were added:

• FS-9480 [mod_kazoo] Add API enhancements
• FS-9457 [mod_http_cache] Allow GET and PUT from Azure Blob Service
• FS-9487 [core] Add CBR param to video file recording params
• FS-9495 [mod_conference] Add conference_join_energy_level variable

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

• FS-9551 [mod_sofia] Compare session before setting TFLAG_SKIP_EARLY
• FS-9488 [mod_http_cache] Fixed a compile error
• FS-9498 [mod_conference] Try to make video writing thread more efficient

The following bugs were squashed:

• FS-9482 [core] Fixed a segfault on the second attempt to use uuid_media_3p
• FS-9483 [mod_conference] Fixed a missing keyframe after re-invite
• FS-9484 [core] Fixed a variable type format spec
• FS-9493 [mod_conference] Fixed a possible crash when changing from normal to personal canvas on the fly
• FS-9494 [mod_conference] Fixed issues with video avatar switching when video starts/stops
• FS-9486 [mod_sofia] Fixed an issue with uuid_drop_dtmf switching between tone replace and digit
• FS-9458 [mod_avmd] Set channel variable before BEEP event is fired
• FS-6954 [core] Use channel flags to check for proxy media or bypass media
• FS-9346 [verto_communicator] Add DTMF icon while on a video call, fixing conferences with pin number
• FS-9497 [mod_av] Fixed an AV sync record issue

Yes you do. Sorry.

This is something I bumped into recently and was quite surprised it wasn’t obvious, which lead me to the conclusion that the WebRTC Architecture course I am launching is… mandatory. This was a company that had their media server on a public IP address, thinking that this should remove their need to run a TURN server. Apparently, the only thing it did was remove their connection rate.

It is high time I write about it here, as over the past year I actually saw 3 different ways in which vendors break their connectivity:

1. They don’t put a TURN server at all, relying on media servers with public IP addresses
2. They don’t put a TURN server at all, assuming STUN is enough for a peer to peer based service (!)
3. They don’t configure the TURN server they use for TCP and TLS connectivity, assuming UDP relay is more than enough

Newsflash: THIS ISN’T ENOUGH

I digress though. I want to explain why the first alternative is broken:

Why a public IP address for your media server isn’t enough

With WebRTC, traffic goes peer to peer. Or at least it should:

But this doesn’t always work because one or both of the browsers are on private networks, so they don’t really have a public address to use – or don’t know it. If one of them has a public IP, then things should be simpler – the other end will direct traffic to that address, and from that “pinhole” that gets created, traffic can flow the other way.

The end result? If you put your media server on a public IP address – you’re set of success.

But the thing is you really aren’t.

There’s this notion of IT and security people that you should only open ports that need to be used. And since all traffic to the internet flows over HTTP(S); and HTTP(S) flows over TCP – you can just block UDP and be done with it.

Now, something that usually gets overlooked is that WebRTC uses UDP for its media traffic. Unless TURN relay over TCP/TLS is configured and necessary. Which sometimes it does. I asked a colleague of mine about the traffic they see, and got something similar to this distribution table:

With up to 20% of the sessions requiring TURN with TCP or TLS – it is no wonder a public IP configured on a media server just isn’t enough.

Oh, and while we’re talking security – I am not certain that in the long run, you really want your media server on the internet with nothing in front of it to handle nasty stuff like DDoS.

What should you do then?

1. Make sure you have TURN configured in your service
   • But make sure you have TCP and TLS enabled in it and found in your peer connection’s configuration
   • I don’t care if you do that as part of your media server (because it is sophisticated), using a TURN server you cobbled up or through a third party service
2. Check out my new WebRTC Architecture course
   • It covers other aspects of TURN servers, IP addresses and things imperative for a production deployment
   • The images used in this article come from the materials I’ve newly created for it
3. Test the configuration you have in place
   • Limit UDP on your test machines, do it on live networks
   • Or just use testRTC – we have in this service simple mechanisms in place to run these specific scenarios

Whatever you do though, don’t rely on a public IP address in your media server to be enough.

The post Do you still need TURN if your media server has a public IP address? appeared first on BlogGeek.me.

Media servers, server-side media handling devices, continue to be a popular topic of discussion in WebRTC. One reason for this because they are the most complex elements in a VoIP architecture and that lends itself to differing approaches and misunderstandings. Putting WebRTC media servers in the cloud and reliably scaling them is  even harder. Fortunately there are […]

The post WebRTC media servers in the Cloud: lessons learned (Luis López Fernández) appeared first on webrtcHacks.

Kurento or Jitsi; Kurento vs Jitsi – is the the ultimate head to head comparison for open source media servers in WebRTC?

Yes and no. And if you want an easy answer of “Kurento is the way to go” or “Jitsi will solve all of your headaches” then you’ve come to the wrong place. As with everything else here, the answer depends a lot on what it is you are trying to achieve.

Since this is something that get raised quite often these days by the people I chat with, I decided to share my views here. To do that, the best way I know is to start by explaining how I compartmentalized these two projects in my mind:

Jitsi Videobridge

The Jitsi Videobridge is an SFU. It is an open source one, which is currently owned and maintained by Atlassian.

The acquisition of the Jitsi Videobridge serves Atlassian in two ways:

1. Integrating Jitsi Videobridge into HipChat while owning the technology (it took the better part of the last 18 months)
2. Showing some open source love – they did change the license of Jitsi from LGPL to APL

Here’s the intro of Jitsi from its github page:

Jitsi Videobridge is an XMPP server component that allows for multiuser video communication. Unlike the expensive dedicated hardware videobridges, Jitsi Videobridge does not mix the video channels into a composite video stream, but only relays the received video channels to all call participants. Therefore, while it does need to run on a server with good network bandwidth, CPU horsepower is not that critical for performance.

I emphasized the important parts for you. Here’s what they mean:

• XMPP server component – a decision was made as to the signaling of Jitsi. It was made years ago, where the idea was to “compete” head-to-head with Google Hangouts. So the choice was made to use XMPP signaling. This means that if you need/want/desire anything else, you are in for a world of pain – doable, but not fun
• does not mix the video channels – it doesn’t look into the media at all or can process raw video in any way
• only relays the received video – it is an SFU

Put simply – Jitsi is an SFU with XMPP signaling.

If this is what you’re looking for then this baby is for you. If you don’t want/need an SFU or have other signaling protocol, better start elsewhere.

You can find outsourcing vendors who are happy to use Jitsi and have it customized or integrated to your use case.

Kurento

Kurento is a kind of an media server framework. This too is an open source one, but one that is maintained by Kurento Technologies.

With Kurento you can essentially build whatever you want when it comes to backend media processing: SFU, MCU, recording, transcoding, gateway, etc.

This is an advantage and a disadvantage.

An advantage because it means you can practically use it for any type of use case you have.

A disadvantage because there’s more work to be done with it than something that is single purpose and focused.

Kurento has its own set of vendors who are happy to support, customize and integrate it for you, one of which are the actual authors and maintainers of the Kurento code base.

Which one’s for you? Kurento or Jitsi?

Both frameworks are very popular, with each having at the very least 10’s of independent installations and integrations done on top of them and running in production services.

Kurento or Jitsi? Kurento or Jitsi? Not always an easy choice, but here’s where I draw the line:

If what you need is a pure SFU with XMPP on top, then go with Jitsi. Or find some other “out of the box” SFU that you like.

If what you need is more complex, or necessitates more integration points, then you are probably better off using Kurento.

What about Janus?

Janus is… somewhat tougher to explain.

Their website states that it is a “general purpose WebRTC Gateway”. So in my mind it will mostly fit into the role of a WebRTC-SIP gateway.

That said, I’ve seen more than a single vendor using it in totally other ways – anything from an SFU to an IOT gateway.

I need to see more evidence of use cases where production services end up using it for multiparty as opposed to a gateway component to suggest it as a solid alternative.

Oh – and there are other frameworks out there as well – open source or commercial.

Where can I learn more?

Multiparty and server components are a small part of what is needed when going about building a WebRTC infrastructure for a communication service.

In the past few months, I’ve noticed a growing requests in challenges and misunderstandings of how and what WebRTC really is. People tend to focus on the obvious side of the browser APIs that WebRTC has, and forget to think about the backend infrastructure for it – something that is just as important, if not more.

It is why I’ve decided to launch an online WebRTC Architecture course that tackles these types of questions.

Course starts October 24, priced at $247 USD per student. If you enroll before October 10, there’s a $50 discount – so why wait?

The post Should you use Kurento or Jitsi for your multiparty WebRTC video conference product? appeared first on BlogGeek.me.

Fifteen years ago, on September 3, 2001, inside Fraunhofer Fokus Research Institute, first commit to the source code repository of Kamailio has been made by Andrei Pelinescu-Onciul:Here are the references to the first three commits:# git log --pretty=format:"%h%x09%an%x09%ad%x09%s" --reverse | head -3

512dcd9 Andrei Pelinescu-Onciul Mon Sep 3 21:27:11 2001 +0000 Initial revision
888ca09 Andrei Pelinescu-Onciul Tue Sep 4 01:41:39 2001 +0000 parser seems to work
e60a972 Andrei Pelinescu-Onciul Tue Sep 4 20:55:41 2001 +0000 First working releaseThe project was initially named SIP Express Router (aka SER), years later – after a fork, a rename and a merge – it converged into into what is now the Kamailio project. It has been a fabulous journey so far, in a more than ever challenging market of real time communications.Well known for its performances, flexibility and stability, Kamailio has set a relevant footprint in open source and open communications, enabling entities world wide to prototype, launch new services and build scalable businesses, research and innovate in real time communications. More over, the project has succeeded to create an amazing community of users and contributors, the real engine behind its successful evolution.Its time to celebrate the moment, everyone involved deserving it — thank you all!In a few months the project will deliver v5.0.0, its 16th public major release, with a restructuring of the source tree to match current modern approaches and more flexibility in choosing the language for building the desired SIP routing rules. Stay tuned!Thank you for flying Kamailio!

It was a quiet week in the code with some minor build updates and improvements. The FreeSWITCH configuration audit has begun with initial minor commits and will continue throughout the year. If you are looking to volunteer to help with that or would like more information email brian@freeswitch.org or join the Bug Hunt on Tuesdays at 12:00pm Central Time.

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

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

• FS-9442 [Debian] Tweak the packages to properly install the debug symbols via freeswitch-all-dbg and freeswitch-meta-all-dbg
• FS-8608 [configuration] Beginning the default configuration and a first step is establishing that parameters should have dashes

The following bugs were squashed:

• FS-9443 [core] Fixed a segfault caused by SDP in a verto.invite with missing ICE candidates
• FS-9447 [mod_avmd] Increased the number of samples to skip to avoid false beep detection on some voicemails for Windows
• FS-9452 [libsofia] Fixed the true/false logic for using destination flag
• FS-7706 [mod_callcenter] Hangup agent channel if we failed to bridge it with member channel

This week on Friday, September 2, 2016, we will join the VoIP Users Conference (VUC) moderated by Randy Resnick for an open discussion about the evolution of Kamailio project.On September 3, 2001, the fist commit was pushed for what was then SIP Express Router (SER) project at Fraunhofer FOKUS Research Institute in Berlin, Germany, project that evolved over the time in what is now Kamailio.A lot of great things happened along the way, there were also some not-very-pleasant moments, but hey, that’s life! Join us to listen or share such moments — if Kamailio made your live easy or bad, if you have a funny story to tell or a photo/video to share, you are welcome on board!We started the celebration at Kamailio World Conference 2016, now we gather online of a non-technical debate of whether the project succeeded to deliver on its promises.Several people already confirmed the participation, like Alex Balashov, Daniel-Constantin Mierla and Fred Posner. We expect VUC regulars such as James Body to be around.Anyone can connect to VUC and listen audio or watch the video session via SIP or YouTube live streaming. For more details see:

• https://www.vuc.me

Should you want to actively participate in the discussion, contact us via email at registration [at] kamailio.org in order to plan a bit the structure. Last minute joining is also possible, but a matter of capacity for the video conferencing system.Thank you for flying Kamailio!

No. Yes. Don’t know.

I’ve recently read an article at iSchool@Syracuse. For lack of a better term on my part, pundits opining about the decentralized web.

It is an interesting read. Going through the opinions there, you can divide the crowd into 3 factions:

1. We want privacy. Also we hate governments and monopolies. This is the largest group
2. There’s this great tech we can put in place to make the internet more robust
3. We actually don’t know

I am… somewhat split across all of these three groups.

#1 – Privacy, Gatekeepers and Monopolies

Like any other person, I want privacy. On the other hand, I want security, which in many cases (and especially today) comes at the price of privacy. I also want convenience, and at the age of artificial intelligence and chat bots – this can easily mean less privacy.

As for governments and monopolies – I don’t think these will change due to a new protocol or a decentralized web. The web started as something decentralized and utopian to some extent. It degraded to what it is today because governments caught on and because companies grew inside the internet to become monopolies. Can we redesign it all in a way that will not allow for governments to rule over the data going into them or for monopolies to not exist? I doubt it.

I am taking part now in a few projects where location matters. Where you position your servers, how you architect your network, and even how you communicate your intent with governments – all these can make or break your service. I just can’t envision how protocols can change that in a global scale – and how the forces that be that need to promote and push these things will actively do so.

I think it is a good thing to strive for, but something that is going very challenging to achieve:

• Most powerful services today rely on big data = no real privacy (at least not in front of the service you end up using). This will always cause tension between our design for privacy versus our desire for personalization and automation
• Most governments can enforce rules in the long run in ways that catch up with protocols – or simply abuse weaknesses in products
• Popular services bubble to the top, in the long run making them into monopolies and gatekeepers by choice – no one forces us to use Google for search, and yet most of us view search on the web and Google as synonymous

#2 – Tech

Yes. Our web is client-server for the most part, with browsers getting their data fix from backend servers.

We now have technologies that can work differently (WebRTC’s data channel is one of them, and there are others still).

We can and should work on making our infrastrucuture more robust. More impregnable to malicious attackers and prone to errors. We should make it scale better. And yes. Decentralization is usually a good design pattern to achieve these goals.

But if at the end of the day, the decentralized web is only about maintaining the same user experience, then this is just a slow evolution of what we’re already doing.

Tech is great. I love tech. Most people don’t really care.

#3 – We just don’t know

As with many other definitions out there, there’s no clear definition of what the decentralized web is or should be. Just a set of opinions by different pundits – most with an agenda for putting out that specific definition.

I really don’t know what that is or what it should be. I just know that our web today is centralized in many ways, but in other ways it is already rather decentralized. The idea that I have this website hosted somewhere (I am clueless as to where), while I write these words from my home in Israel, it is being served either directly or from a CDN to different locations around the globe – all done through a set of intermediaries – some of which I specifically selected (and pay for or use for free) – to me that’s rather decentralized.

–

At the end of the day, the work being done by researchers for finding ways to utilize our existing protocols to offer decentralized, robust services or to define and develop new protocols that are inherently decentralized is fascinating. I’ve had my share of it in my university days. This field is a great place to research and learn about networks and communications. I can’t wait to see how these will evolve our every day networks.

 

 

The post Will there ever be a decentralized web? appeared first on BlogGeek.me.

The next SIPit – the SIP Tnteroperability Test Event – will be held at the University of New Hampshire Interoperability Laboratory, in Durham, New Hampshire, USA, during September 12-16, 2016.SIPit facilitates testing your SIP implementations, gathering of SIP professionals that develop phones, PBXes, servers or other SIP application to enable peer-to-peer an multiparty tests.There is a great testbed of various NAT networks for those of you working with NAT traversal issues, including IPv6 in the network as well as an extensive set of tests for TLS. This year, there will also be a focus on STIR – the new secure identity handling in SIP.Olle E. Johansson explains why you should participate in the next slides:Participate in SIPit from Olle E JohanssonTo register and learn more details, go to the main SIPit web site:

• https://www.sipit.net/Main_Page

Along the past 15 years, Kamailio-SER participated at many of the SIPit events, which is reflected in the robustness of the application. This edition, at least Olle will be again there to ensure the latest version stays rock solid.Many of the automatic tests on site are built using Kamailio, go there and hammer it!Thank you for flying Kamailio!

The FreeSWITCH 1.6.10 release is here!

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.10.tar.gz
• Packaging: https://freeswitch.org/confluence/display/FREESWITCH/Installation

New features that were added:

• FS-9192 [mod_sofia] Added renegotiate-codec-on-hold parameter for proxy hold when proxy media and proxy mode are disabled; it’s similar to proxy-refer
• FS-9276 [mod_sofia] Added proxy in-dialog calls sip notify and info similar to proxy hold
• FS-9440 [mod_sofia] Add transfer_destination
• FS-9154 [libsofia] Add & remove video on re-invites
• FS-9009 [mod_avmd] Add amplitude estimation
• FS-9069 [mod_avmd] Add detection time to beep event
• FS-9287 [mod_spandsp] Add channel variable to make spandsp_start_tone_detect easier to use from dialplan/embedded scripts.
• 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
• FS-9230 [mod_conference] Customize video muted banner
• FS-9441 [mod_conference] Add the option to not beep between dials in outcall
• FS-9281 [mod_verto] Add support for QQVGA resolution in Verto
• FS-9256 [mod_v8] Add DB.Finalize() in order to close statements.
• FS-9419 [mod_commands] Add event_channel_broadcast api

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

• FS-9263 [build] Attempting to find the proper lua5.2 version on openbsd
• FS-9260 [build] Fixed make detection to not fail on openbsed,  fixed libtoolize detection to attempt to find libtoolize the same version as specified libtool, and added -ltermcap for openbsd so it can correctly link to libedit
• FS-9403 [build] Add timestamp for when user was pushed into queue that lives with the channel
• FS-9449 [build] Enable clock calibration and clock_realtime on Solaris
• FS-9424 [build] Define byte order correctly on Solaris/SPARC
• FS-9317 [configuration] Added screen share examples to the vanilla configurations
• FS-9350 [configuration] Add mod_av commented to modules.conf.xml
• 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
• FS-9373 [Debian] Added mod-verto and mod-rtc to freeswitch-meta-all package
• FS-9386 [mod_snmp] Use net-snmp-config for SNMP libs if available
• FS-9385 [mod_conference] Check for ghosts before destroying a conference
• 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-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-9244 [core] Fixed debug lines
• FS-9265 [core] Fixed an issue with receiving INCOMPATIBLE_DESTINATION when there is no RTCP
• FS-9292 [core] Fixed a core dump while playing videos or showing images usually with a high number of callers
• FS-9312 [core] Fixed and unreachable code block in switch_core_media
• 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-9337 [core] Fixed invalid sdp generated with soa disabled
• FS-9352 [core] Fixed overzealous ptime adjust issues on opus
• 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-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 [core] Handle packet loss and reset decoder on memory error
• 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] Added the variable add_ice_candidates=true to enable inserting ice candidates in outgoing sdp
• FS-9436 [core] Fixed RTCP PLI media source SSRC not updating after re-INVITE
• 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
• FS-9434 [core] Fixed the SDP parser in sofia not recognizing UDP/TLS/RTP/SAVP
• 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-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-8761 [libsofia][mod_verto] Fixed a memory leak
• FS-9375 [mod_sofia] Fixed DTMF not working on OPUS after call transfer
• FS-9423 [mod_sofia] Handle null value in ACL list name
• FS-9183 [mod_sofia] Handle 415 Unsupported Media Type as 488
• FS-9376 [mod_sofia] Fixed a hold negotiation problem on a call received from a Cisco Session Manager
• FS-9381 [mod_sofia] Fixed a leak in sofia_presence_chat_send
• FS-9368 [mod_sofia] Fixed a problem with errant duplicate video frames causing video recording issues
• 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-9333 [mod_sofia] Disable video refresh by sip INFO by default because this method is outdated
• FS-9297 [mod_sofia] Fixed multiple crashes from passing invalid null values in sofia.conf
• FS-9301 [mod_sofia] Handled a race condition on startup of mod_sofia with error conditons causing segfault
• FS-9271 [mod_conference] Fixed a segfault trying to record a canvas that does not exist
• 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-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
• FS-9353 [mod_conference] Fixed a problem with clear-vid-floor producing an error while working
• FS-9425 [mod_conference] Fixed a copy and paste error where the height was not set properly
• FS-9437 [mod_conference] Delete avatar if video is enabled mid-call
• FS-9267 [mod_cv] Fixed an issue where the VPX codec returns the same image to the core when doing repeated decoding. Updates to that image match the updates to the stream so if a media bug modifies the image between key frames it messes up the picture until the next key frame is received.
• FS-9283 [mod_hiredis] Fixed an issue with using hiredis_raw on channels without media such as an originate
• FS-9302 [mod_mongo] Fixed mongo_find_one and mongo_find_n to return -ERR when the connection to the database fails
• FS-9313 [mod_opus] Fixed sprop_stereo interpretation causing bad audio
• FS-9345 [mod_httapi] Fixed an issue with HTTAPI truncating a string when responses span multiple packets
• FS-9296 [mod_httapi] Fixed video support
• FS-9343 [mod_smpp] Fixed a problem with failing to send a message via Nexmo
• FS-9259 [mod_spandsp] Fixed a missing “m=image 0” when replying to INVITE with disable image line
• FS-8783 [libsrtp] Fix alignment issue
• FS-9394 [mod_av] Fixed the h263 leak
• FS-9409 [mod_av] Wait for avformat reader thread before reading to prevent spurious EOF and skipped playback
• FS-8783 [libsrtp] Fix alignment issue
• 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

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.