News from Industry

There are indications out there that soon we won’t be needing plugins to support WebRTC in some of the browsers out there.

[Alexandre Gouaillard decided to drop by here at BlogGeek.me offering his analysis on recent news coming out of Apple and Microsoft – news that affect how these two players will end up supporting WebRTC real soon.] Apple Safari news

• When the webrtc-in-webkit project was first announced through the voice of its main members: Stefan H. from Ericsson, and myself, not everybody was a believer.
• For some, it was even an exercise in Futility
• A further post was even written in webrtcHacks to explain how to let apple know about one’s interest in having webrtc on iOS
• In my November 2014 presentation (slide 20) with JO Hache about the Temasys Plugin, we indicated that the goal was indeed to have an implementation in the Apple version of things by end of August 2015, to have a chance to see it in the next version of Safari which traditionally is shipped along new OS in September/October, every year
• Early July the webrtc-in-webkit project has delivered the media streams fondation, and getusermedia in webkit, with a full functional implementation in the Linux browser WebKitgtk+
• Right after that, Apple put his own resources to support GetUserMedia in the Apple specific version of the code, and worked on it until mid-August. A detailed analysis of the code changes by Apple and their technical implications can be found here

It is still unknown when this (GetUserMedia only) will find its way into Safari, and more specifically in Safari on iOS. Hopefully before the end of the year. (high, but probably unrealistic, hopes for a Sept. 9 announcement).

We can also only hope that the WebView framework apps are forced to use to display web pages according to the Apple app store rules will be updated accordingly, which would open WebRTC to iOS apps directly, catching up a little bit with the WebView on android.

How much the webrtcinwebkit project helped making this happen is also open to debate but I want to believe it did (yes, I am uber-biased). It is also possible that the specifications for Device API being stable (last call status at W3C) motivated Apple to go for it.

In any case, what is important is that it is now undeniable that Apple is bringing WebRTC to its browsers and devices, and that answers a question left open for almost 4 years now!

Microsoft Edge news

• In May 2015, the Edge team announced support for the same media streams and getuserMedia API we spoke about earlier
• In June 2015, philippe Hancke extended Google and Mozilla’s provided adapter.js to support Edge
• More recently, some action has been visible on the ORTC side of things, but with nothing testable so far (Release version 10525)
• Today (Sep. 1st) three separate announcements were made:
  • support for webm container is now in development (here)
  • support for VP9 is now in development (here)
  • support for opus is still under consideration but is now high priority (here)

Here again, a lot of good news. For a long time, it was unsure if Microsoft would do anything at all, and even now, nobody is clear on exactly what API they are going to implement and how compatible it will be with the WebRTC specs. The convergence of the WebRTC Working Group and ORTC Community Group within w3c is raising hope of better interoperability, but it was not substantiated. Until today that is. There is no other web API that would use VP9 than WebRTC. Ok, it could be to provide a better YouTube experience, but Opus is WebRTC only.

So here again, while the exact date is unknown it is undeniable that Microsoft Edge is moving in the right direction. Moreover, it’s been moving faster than most expected lately.

All good news for the ecosystem, and surely more news to come on the Kranky Geek WebRTC Live event on september 11th where three browser vendors will be present to make their announcements.

Toward a plugin free experience (finally)

During my original announcement of a plugin for IE and Safari I stated that the “goal [was] to remove the “what about IE and safari” question from the Devs and Investors’ table long enough for a native implementation to land.”

I also stated that “We hate plugins, with a passion. Some browser vendors put us in the situation where we do not have the luxury to wait for them to act on a critical and loudly expressed need from their user base. We sincerely hope that this is only a temporary solution, and we don’t want people to get the impression that plugins are the magical way to bypass what browser vendors do (or don’t do). Native implementation is always best.”

I truly believe that the day we can get rid of plugins for webrtc is now very very close. If I’m lucky, Santa Claus will bring it to me for Xmass (after all, I’ve been a good boy all year). There will still be a need for some help, but it will be in the form of a JS library and not a heavy duty plugin. Of course, you still have to support some older versions of Windows here and there, especially for enterprise market, but Microsoft, and I am writing this from Redmond, next to the Microsoft campus ;-), is putting a lot of ressources behind moving people to auto-updating versions of their software, be it Windows itself, or the browsers. Nowadays, the OS do not bring value per themselves, but bring in a lot of maintenance burden. It is in everybody’s interest to have short update cycles, and MS knows that.

For those who need to support older versions of IE for some time (Apple users will never be seen with an old Apple device :-D), there are today several options, all converging toward the same feature set, and a zero price tag. You can see more about this here.

Tsahi and I have this in common that we hate plug-ins, especially for video communication. I think we are seeing the end of this problem.

The post WebRTC Plugin Free World is Almost Here: Apple and Microsoft joining the crowd appeared first on BlogGeek.me.

One of the interesting modules added in Kamailio v4.3 is rtjson – in short, it defines a JSON document format that can be used to specify and push destination addresses when routing a SIP request. It is very handy when the attributes for routing are decided by an external application.A tutorial about using a Node.js application to decide the routing for a SIP request has been published at:

• http://kb.asipto.com/kamailio:k43-async-sip-routing-nodejs

The next diagram shows the relation between SIP, Kamailio and Node.js application.The relevant components used inside Kamailio are:

• evapi module – to asynchronously send/receive data to/from Node.js (i.e., don’t block Kamailio, allow to handle other traffic meanwhile)
• rtjson module – to fill in the internal fields corresponding to the routing attributes returned by the Node.js application
• jansson module – to access the rtjson document in kamailio.cfg for additional processing

Using this architecture, one can built external SIP routing decision engines for Kamailio that suits better various contexts. For example, do least cost routing or load balancing selection, access control policy, fraud protection, etc. inside the external application, instead of using the existing modules.Depending on the needs, using such architecture could fit better, especially when dealing with lots of SIP server nodes. Of course, Node.js platform can be replaced by any other application, standalone or on top of a framework.Read the content of the tutorial at:

• http://kb.asipto.com/kamailio:k43-async-sip-routing-nodejs

Enjoy!

We’re now 30 days away from KazooCon! Want to tell your friends about KazooCon and save money at the same time? Refer a friend, you’ll receive 25% off your ticket for each person you refer. Here’s the referral link: http://www.eventbrite.com/r/kazoocon

A quick note.

Just wanted to list out the events and venues where you’ll be able to find me and meet with me in the next month or two.

Me in San Francisco

I’ll be in San Francisco 9-11 September, mainly for the Kranky Geek event. If you want to meet and have a chat with me – contact me and let’s see if we can schedule a time together.

WebRTC Codec Wars: Rebooted

When? Wednesday, September 9, 18:00

Where? TokBox’ office – 501 2nd Street, San Francisco

TokBox were kind enough to invite me to their upcoming TechTok meetup event. Codecs are becoming a hot topic now – up to the point that I had to rearrange my writing schedule and find the time to write about the new Alliance for Open Media. It also got me to need to change my slides for this event.

Would be great to see you there, and if you can’t make it, I am assuming the video of the session will be available on YouTube later on.

Attendance is free, but you need to register.

Kranky Geek WebRTC Show

When? Friday, September 11, 12:00

Where? Google – 6th floor 345 Spear St, San Francisco

This is our second Kranky Geek event in San Francisco, and we’re trying to make it better than the successful event we had a year ago.

Check out our roster of speakers – while registration has closed, we do have a waiting list, so if you still want to join – register for the waiting list and you might just make it to our event.

Development Approaches of WebRTC Based Services

When? September 24, 14:00 EDT

Where? Online

It is becoming a yearly thing for me, having a webinar on the BrightTALK platform.

This time, I wanted to focus on the various development approaches companies take when building WebRTC based services. This has recently changed with one or two new techniques that I have seen.

The event is free and takes place online, so be sure to register and join.

Video+Conference 2015

When? Thursday, October 15, 11:00

Where? Congress Centre Hotel “Alfa”, Moscow

I have never been to Russia before, and I won’t be this time. I will be joining this one remotely. TrueConf have asked me to give a presentation about WebRTC.

The topic selected for this event is WebRTC Extremes and how different vendors adopt and use WebRTC to fit their business needs.

If you happen to be in Moscow at that time, it would be great to virtually meet you on video.

 

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

The post Upcoming Sep-Oct Events appeared first on BlogGeek.me.

WWW-Digest authentication (RFC 2617), the same used to authenticate users in SIP, requires that both server and user share and store the same secret. Storing the password in clear text is really bad, unfortunately the only alternative is to store the so called HA1 string, which is the result of MD5 hashing over username, authentication realm and password — this has become the default lately. Kamailio, as well as other SIP server side applications such as Asterisk or FreeSwitch, can work with clear text passwords as well as HA1 values (no need to repeat that you should use them with the second option!).Each SIP service that allows customers to set the passwords must have a system in place to test if the passwords are strong enough to offer a fair protection against dictionary attacks. However, not all of them had such system from the moment they started to get customers.To become safe, the options are:

1. force a reset of the passwords, so the new values are tested to see if they are strong
2. try to audit the existing HA1 values in subscriber database and detect the ones using weak values

The option a) is the best, but not easy to implement if the service provider doesn’t control the devices of the customer (CPE), especially when the customer has no IT/technical background.The option b) means more or less that the SIP provider performs a dictionary attack against itself. Tools like sipsak, sipp or sipvicious can be used for such task, but they have the drawback of doing quite some processing: build and parsing of SIP messages, plus network communication. The SIP servers with all subscriber accounts have to replicated on different machines, not to overload the production instances.But, unlike the attacker, the service provider has access to HA1 strings, knows the usernames and realsm, therefore it can skip a lot of processing done by SIP scanning tools and that can save a lot of resources and time.Not finding quickly an existing implementation for such needs, a tool named md5ha1 has been developed and published on Github, targeting to help doing audits over HA1 values, it is available at:

• https://github.com/miconda/md5ha1

It has options to load passwords from a file (e.g., 101, 123, …), generate passwords using templates (e.g., %u123 – replace %u with username) from a file or generate passwords using a set of characters with minimum and maximum length (e.g., passwords using only digits with length between 3 and 6). The readme of the project has more details about how md5ha1 can be used.Hopefully the tool is going to be useful for Kamailio community! Improvements to it are welcome, use Github platform for issues and contributions.

W3C WebRTC working group chairs [Harald Alvestrand (Google), Stefan Håkansson (Ericsson), Erik Lagerway (Hookflash)], made a decision recently to add a new editor to the working group, as Peter St. Andre (&yet) has resigned as editor.

Bernard Aboba (Microsoft) has now been appointed as editor.

Bernard’s attention to detail and advocacy for transparency, fairness and community has been refreshing. It has been my pleasure (as chair of the W3C ORTC CG) to work with Bernard whom also is an author in the W3C ORTC CG alongside Justin Uberti and Robin Raymond (editor). I look forward to working more with him in the WG.

Congrats Bernard!

/Erik

Another development year for Kamailio is gone, the project enters its 15th full season of writing code. Back in 2001, on the 3rd of September, the first commit was made for the project, at that time called SIP Express Router (aka SER), done by Andrei Pelinescu-Onciul at Fraunhofer FOKUS research institute in Berlin, Germany, respectively:
commit 512dcd9838f5aeb0bfccd02cfc156067b7f02b71
Author: Andrei Pelinescu-Onciul
Date:   Mon Sep 3 21:27:11 2001 +0000

    Initial revision
Next year we are preparing to celebrate with a special edition of Kamailio World Conference – be sure you keep it in your plans for 2016.Since September 2014, Kamailio has released two major versions, 4.2 (Oct 2014) and 4.3 (Jun 2015). Now, after the summer holidays, we are speeding up to get new stuff for next major release, planned to be numbered 4.4 — keep an eye on sr-dev mailing list to stay up to date with what is going to be new and interesting!

A fruitful rest of the year for all Kamailians out there and prepare for the party in 2016!

The beginning of the end of HEVC/H.265 video codec.

On September 1st the news got out. There’s a new group called Alliance for Open Media. There have been some interesting coverage about it in the media and some ramifications that already got published. The three most relevant pieces of news I found are these:

• Stephen Shankland over at CNET makes the most intelligent and thorough review of this announcement out of all the large media outlets. Well worth the read
• Chris Kranky decided to pitch in and explain how patents work with codecs, and how this alliance is doomed to fail. I disagree with the conclusions, but the story is solid
• Microsoft already plans on supporting VP9 video codec in their Edge browser

I’ve written about the pending codec wars just a week ago on SearchUC, concluding that all roads lead to a future with royalty free video codecs. This was before I had any knowledge on the announcement of the open media alliance. This announcement makes this future a lot more possible.

What I’d like to do here, is to cover some aspects of where this is headed and what it tells us about the players in this alliance and the pending codec wars.

The Press Release

Let’s start off with the alliance’ initial press release:

This initial project will create a new, open royalty-free video codec specification based on the contributions of members, along with binding specifications for media format, content encryption and adaptive streaming, thereby creating opportunities for next-generation media experiences.

So the idea is to invent a new codec that is royalty-free. As Chris pointed out, this is hard to impossible. Cisco in their own announcement of their new Thor codec made it quite clear what the main challenge is. As Jonathan Rosenberg puts it:

We also hired patent lawyers and consultants familiar with this technology area. We created a new codec development process which would allow us to work through the long list of patents in this space, and continually evolve our codec to work around or avoid those patents.

The closest thing to a “finished good” here is VP9 at the moment.

Is the alliance planning on banking on VP9 and use it as their baseline for the specification of this new codec, or will they be aiming at VP10 and a clean slate? Mozilla, a member company in this alliance, stated that they “believe that Daala, Cisco’s Thor, and Google’s VP10 combine to form an excellent basis for a truly world-class royalty-free codec.”

Daala takes a lot of its technologies from VP9. Thor is too new to count, and VP10 is just a thought compared to VP9. It makes more sense that VP9 would be used as the baseline; and Microsoft’s adoption of VP9 at that same timeframe may indicate just that intent. Or not.

The other tidbit I found interesting is the initial focus in the statement:

The Alliance’s initial focus is to deliver a next-generation video format that is:

• Interoperable and open;
• Optimized for the web;
• Scalable to any modern device at any bandwidth;
• Designed with a low computational footprint and optimized for hardware;
• Capable of consistent, highest-quality, real-time video delivery; and
• Flexible for both commercial and non-commercial content, including user-generated content.

Would be easier to just bio-engineer Superman.

Jokes aside, the bulleted list above are just table-stakes today:

• Interoperable and open
  • Without interoperability a codec has no life
  • Openness is what you do in an initiative like this one
• Optimized for the web
  • People consume video over IP these days. This is where the focus should be
  • It also hints for embedability in web browsers, and having Google, Microsoft and Mozilla on this alliance couldn’t hurt
• Scalable to any modern device at any bandwidth
  • Scalability here means many things. SVC for one, but that’s just a single feature out of the list of necessary needs
  • Modern devices means that anything that is built probably before 2012 or even 2014 is going to be ignored. With current lifecycle of smartphones, that seems reasonable
  • Any bandwidth means it needs to support crappy internet connections but also 4K resolutions and above
• Designed with a low computational footprint and optimized for hardware
  • This one is going to be tough. Each codec generation takes 2-3 times the computational footprint of its predecessor. I am not sure this can be met if the idea is to displace something like H.265
  • Optimized for hardware is a wink to hardware vendors that they need to support this as well. Having Intel is nice, but they are almost the non-player in this market (more on that later)
• Capable of consistent, highest-quality, real-time video delivery
  • Guess what? Everyone wants that for any time of a video codec
• Flexible for both commercial and non-commercial content, including user-generated content
  • This talks about licensing and royalties. Free should be the business model to aim for, though the language may well translate to royalty payments, though at a lower rate than what MPEG-LA and HEVC Advance are trying to get

High goals for a committee to work on.

It will require Cisco’s “cookbook”: a team comprised of codec engineers and lawyers.

The Members

What can we learn from the 7 initial alliance members? That this was an impossible feat and someone achieved just that. Getting these players into the same table while leaving the egos out of the room wasn’t easy.

Amazon

Amazon is new to video codecs – or codecs and media. They have their own video streaming service, but that’s about it.

Their addition into this group is interesting in several aspects:

• The Amazon Instant Video service has its place. Not the dominant service, but probably big enough so it isn’t ignored. Added to Netflix and YouTube, it adds its weight
• More interestingly, how will AWS be affected? Their Amazon Elastic Transcoder for example, or the ability to host real time media processing services on top of AWS

Cisco

Cisco is a big player in network gear and in unified communications. It has backed H.264 to date, mainly due to its own deployed systems. That said, it is free to pick and choose next generation codecs. While it supports H.265 in its high-end telepresence units, it probably saw the futility of the exercise continuing down this path.

Cisco though, has very little say over future codecs adoption.

Google

Google needs free codecs. This is why it acquired On2 in the first place – to have VP8, VP9 and now VP10 compete with H.26x. To some extent, you can point the roots of this alliance to the On2 acquisition and the creation as webm as the first turning point in this story.

For Google, this means ditching the VPx codec branding, but having what they want – a free video codec.

The main uses for Google here are first and foremost YouTube and later on WebRTC. Chrome is the obvious vehicle of delivery for both.

I don’t see Google slowing down on their adoption of VP9 in WebRTC or reducing its use on YouTube – on the contrary. Assume the model played out here will be the same one Google played with SPDY and HTTP/2:

• SPDY was Google’s proprietary transport mechanism to replace HTTP/1.1. It was later used as the baseline of HTTP/2
• VP9 is Google’s proprietary video codec to replace H.26x. It is now being used as the baseline of the next generation video codec to displace H.265

To that end, Google may well increase their team size to try and speed up their technology advancement here.

Intel

Intel is trying for years now to conquer mobile with little to show for its efforts. When it comes to mobile, ARM chipsets rule.

Intel can’t really help with the “any modern device” part of the alliance’s charter, but it is a good start. They are currently the only chipset vendor in the alliance, and until others join it, there’s a real risk of this being a futile effort.

The companies we need here are ARM, Qualcomm, Broadcom and Samsung to begin with.

Microsoft

Microsoft decided to leave the H.26x world here. This is great news. It is also making the moves towards adopting WebRTC.

Having Google Chrome and Microsoft Edge behind this initiative is what is necessary to succeed. Apple is sorely missing, which will most definitely cause market challenges moving forward – if Apple doesn’t include hardware acceleration for this codec in their iOS devices, then a large (and wealthy) chunk of the consumer market will be missing.

Every day that passes it seems that Microsoft is acting like a modern company ready for this day and age as opposed to the dinosaur of the 90’s.

Mozilla

Mozilla somehow manages to plug itself into every possible initiative. This alliance is an obvious fit for a company like Mozilla. It is also good for the alliance – 3 out of 4 major browser players behind this initiative is more than we’ve seen for many years in this area.

Netflix

Netflix started by adopting H.265 for their 4K video streaming. It seemed weird for me that they adopted H.265 and not VP9 at the time.  I am sure the latest announcements coming out of HEVC Advance about licensing costs for content streaming has caused a lot of headache at Netflix and tipped the scale towards them joining this alliance.

If you are a content provider operating at Netflix scale with their margins and business model, the greedy %0.5 gross revenue licensing of HEVC Advance becomes debilitating.

With YouTube, Amazon and Netflix behind this alliance, you can safely say that web video streaming has voiced their opinion and placed themselves behind this alliance and against HEVC/H.265.

Missing in Action

Who’s missing?

We have 3 out of 4 browser vendors, so no Apple.

We have the web streaming vendors. No Facebook, but that is probably because Facebook isn’t as into the details of these things as either Netflix or Google. Yet.

We don’t have the traditional content providers – cable companies and IPTV companies.

We don’t have the large studios – the content creators.

We don’t have the chipset vendors.

Apple

Apple is an enigma. They make no announcements about their intent, but the little we know isn’t promising.

• They have devices sold to think of. These devices support H.265 hardware acceleration, so they are somewhat committed to it. Hard to switch to another horse as a vertical integrator
• Safari and WebKit are lagging behind when it comes to many of the modern web technologies – WebRTC being one of them
• Apple owns patents in H.265 and are part of MPEG-LA. Would they place their bets in another alliance? In both at the same time? Contribute their H.265 patents to the Alliance for Open Media? Probably not

Once this initiative and video codec comes to W3C and IETF for standardization, will they object? Join? Implement? Ignore? Adopt?

Content providers

Content providers are banking around H.265 for now. They are using the outdated MPEG2 video codec or the current H.264 video codec. For them, migrating to H.265 seems reasonable. Until you look at the licensing costs for content providers (see Netflix above).

That said, some of them, in Korea and Japan, actually own patents around H.265.

Where will they be headed with this?

Content creators

Content creators wouldn’t care less. Or they would, as some of them are now becoming also content providers, streaming their own content direct-to-consumer in trials around unbundling and cord cutting.

They should be counting themselves as part of the Alliance for Open Media if you ask me.

Chipset vendors

Chipset vendors are the real missing piece here. Some of them (Samsung) hold patents around H.265. Will they be happy to ditch those efforts and move to a new royalty free codec? Hard to say.

The problem is, that without the chipset vendors behind this initiative it will not succeed. One of the main complaints around WebRTC is lack of support for its codecs by chipsets. This will need to change for this codec to succeed. It is also where the alliance needs to put its political effort to increase its size.

The Beginning of the End for HEVC/H.265

This announcement came as a surprise to me. I just finished writing my presentation for an upcoming TechTok with the same title as this post: WebRTC Codec Wars Rebooted. I will now need to rewrite that presentation.

This announcement if played right, can mean the end of the line for the H.26x video codecs and the beginning of a new effort around royalty free video codecs, making them the norm. The enormity of this can be compared to the creation of Linux and its effect on server operating systems and the Internet itself.

Making video codecs free is important for the future of our digital life.

Kudos for the people who dared dream this initiative and making it happen.

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

The post WebRTC Codec Wars: Rebooted appeared first on BlogGeek.me.

Hello, again. This past week in the FreeSWITCH master branch we had 116 commits! Wow, the team was really busy this week! Our features for this week are: added getenv FSAPI to mod_commands, the verto communicator saw many improvements, and the beginnings of another new module! Mod_redis is being deprecated in favor of mod_hiredis!

Join us on 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-8075 [mod_hiredis] Add mod_hiredis including support for redis limits and added support for raw redis commands. Added deprecation notices to mod_redis
• FS-8049 [mod_commands] Add getenv FSAPI
• FS-8036 [verto.js] Add chatCallback to $.verto.conf

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

• FS-8061 [verto_communicator] Adding license to package.json
• FS-8047 [build] Fixed build error in mod_basic, mod_rtmp, mod_oreka, and mod_sangoma_codec due to using __FUNCTION__ on newer compilers
• FS-8054 [mod_rayo] Fixed a warning when building on Debian
• FS-8055 [build] Add confdir variable to freeswitch.pc
• FS-7966 [windows] Working msvc 2015 build support. Does not yet include video features.
• FS-8019 [debian] Excluded few modules that fail to compile from debian/bootstrap.sh, fixed the handling of -T and -t and added debian/apt_sources.list with necessary dependencies to build master, and updated debian/README.source
• FS-8058 [mod_vpx] Build correctly against libvpx that is not installed into default system library locations

The following bugs were squashed:

• FS-8027 [verto communicator] Added watchTask flag to browserSync and add proper regex for replacements
• FS-8026 [verto_communicator] Added an auto-focus directive to both dial-pad and login so that enter will just work. On dial-pad useful to provide keyboard only input without the need to using the mouse
• FS-7995 [verto_communicator] Upon call recovery, emit an event on $rootScope so that controllers are able to properly clear states.
• FS-7945 [verto communicator] Use angular-prompt to ask the user to enter a text for the banner. If cancelled, nothing is done.
• FS-8045 [verto communicator] Make the folder structure compliant with AngularJS best practices and adjust build system.
• FS-7957 [verto_communicator] Make console less chatty by commenting liveArray updates and get initial state of the conference on liveArray boot event.
• FS-7979 [verto_communicator] Prompt for extension before transferring a conference member
• FS-8001 [verto_communicator] For this to work, passing in the parameter was missing
• FS-7979 [verto_communicator] Removed extra console.log and commented line
• FS-8025 [verto_communicator] Restored the blue background on the video controls and making icons white again, looking better.
• FS-8062 [verto_communicator] Fixed video controls tool-tips, now they are visible
• FS-8048 [verto_communicator] Fixed infinite reconnect after changing hostname and websocket url
• FS-8066 [verto communicator] Added encoded avatar url to userVariables so that mod_conference can use it when no video, or video mute
• FS-8018 [verto_communicator] Separation of concerns. Get storage service to manage all settings instead of vertoService
• FS-8043 [verto_communicator] Removed unnecessary calls to localStorage
• FS-8040 [verto_communicator] Check if we have a valid resolution reported before calling camera routines and hide controls if none are found
• FS-8092 [verto_communicator] If there is no data in localStorage, select best resolution for selected camera
• FS-7840 [verto_communicator] Use chatChannel to send and receive messages from conferences
• FS-8088 [verto_communicator] Call conference destroy upon hangup and on event destroy to properly unsubscribe from events
• FS-8046 [verto] Fixed for library not passing device preferences to dialog properly
• FS-8053 [verto] Don’t receive video on screen share
• FS-8059 [verto] Fixed typo when transferring party from conference
• FS-8060 [verto] Conditionally set video tag src to null for FF and empty string for others
• FS-8087 [verto] Fixed issue in camera selection on recovery, refactor to use localStorage, change res detection, reload on network change, pass resCheck callback into deviceParams, always make one basic call to getusermedia to ensure perms are ok, pass valid res to callback, make $.FSRTC.validRes available globally, sync minified, fix depth issue in cached json, test for valid cache before setting vars
• FS-8028 [mod_shout] Fixed random sockets being closed regression from FS-7621
• FS-8029 [jitterbuffer] Fixed robotic sound when using jitterbuffer when buffer timestamps get behind that of the packet timestamps, such as when the source clock is out of sync with our clock
• FS-8056 [mod_voicemail] Fixed a segfault on vm_inject, regression from FS-7968
• FS-7968 [mod_voicemail] Fixed verbose events
• FS-7942 [udptl] Fixed rare segfault on t.38 fax FS-8014 is a duplicate of this issue
• FS-8031 [dtls] Fixed delayed DTLS media due to changing ICE candidates
• FS-7903 [proxy_media] Fix Codec PROXY Exists but not at the desired implementation. 0hz 0ms 1ch error when using proxy media.
• FS-7989 [fixbug.pl] Add –author option
• FS-8037 [mod_sofia] Fixed so zrtp-passthru doesn’t activate unless the zrtp-hash is in the SDP
• FS-7135 [mod_sofia] Fixed response to re-invite with duplicate sdp (such as we get from session refresh) when soa is disabled to include an sdp. Fixed t.38 fax failure on session refresh
• FS-8050 [mod_av] Fixed a crash when streaming rtmp of desktop share
• FS-7640 [rtp] Fixed some comparisons in switch_rtp.c to be wraparound proof
• FS-8057 [core] Fixed a segfault when doing video call when built against libyuv but not libvpx
• FS-8069 [stun] Fixed ipv6 support missing in stun code
• FS-8071 [rtp] remove unnecessary auto adjust remote address rules when in ICE mode
• FS-8077 [mod_conference] Fix memory leak in record
• FS-8091 [core] Added some missing message names to session message name list (would have caused missing information in some log messages)
• FS-8093 [mod_silk] Remove giant stack allocation in switch_silk_decode

 

And, this past week in the FreeSWITCH 1.4 branch we had 2 new commits merged in from master. And the FreeSWITCH 1.4.21 release is here! Go check it out!
The following bugs were fixed:

• FS-7912 [mod_conference] Fixed for v1.4 branch to not allocate for conference cdr if conference cdr is disabled
• FS-8091 [core] Added some missing message names to session message name list (would have caused missing information in some log messages)

L’azienda detta il ritmo dell’innovazione nella Unified Communication grazie ai nuovi servizi di PUSH per i client per smartphones, al nuovo ambiente di installazione cloud integrato e alla ri-disegnata interfaccia utente.

LONDRA, UK XX Luglio 2015 – 3CX, azienda produttrice del centralino di nuova generazione, 3CX Phone System for Windows, annuncia oggi il lancio della Versione 14 della sua pluri-premiata soluzione di comunicazione. L’ultima release da ai rivenditori la possibilità di fornire un centralino in cloud o in locale sulla stessa piattaforma; un’ottima notizia per quei partner desiderosi di ampliare la propria offerta e di includere servizi di centralini virtuali.

Nuovi client per  iOS, Android e Windows Phone

I nuovi client per iOS e Android sono stati completamente riscritti e portano la mobilità ad un nuovo livello grazie all’uso avanzato della tecnologia PUSH e al tunnel SIP integrato. Gli utenti smartphone potranno d’ora in poi usare il proprio interno aziendale dappertutto, con la stessa semplicità di un normale telefono cellulare. Grazie al PUSH, 3CX può risvegliare il telefono in caso di chiamata entrante e la rapida registrazione e attivazione dell’interno consentono all’utente di rispondere facilmente.

Nick Galea, CEO di 3CX dichiara:

“La Versione 14 stabilisce nuovi standard di funzionamento, in particolare per i client smartphone. Ora, con il PUSH integrato nei nostri client softphone, che da priorità ai messaggi 3CX rispetto agli altri, 3CX Phone System garantisce un’imbattibile mobilità, mantenendo il vostro centralino aziendale a portata di dita, ovunque voi siate. Tutto ciò, combinato alla facilità d’uso e di gestione, rende 3CX Phone System unico sul mercato.”

Funzionalità di Centralino Virtuale Integrata

In aggiunta, ai clienti è ora offerta una nuova modalità di installazione che consente ai partner 3CX di offrire facilmente un centralino virtuale. 3CX Phone System v14 può essere installato come server di centralini virtuali in grado di gestire fino a 25 istanze su un singolo Windows Server, con una eccezionale semplicità di gestione e ad un costo per istanza estremamente competitivo. 3CX offre un centralino virtuale completo, diverso dai soliti sistemi multi-account ed in cui i dati e i servizi del centralino sono completamente separati per ciascun cliente.

Questa possibilità arriva nel momento in cui i produttori stanno assistendo ad un aumento nella domanda di soluzioni aziendali basate sul cloud. E’ previsto che entro il 2018 il mercato delle soluzioni UC/centralini virtuali supererà i 18mld di dollari di ricavi e già da oggi, con 3CX Phone System Hosted PBX, i partner 3CX sono in grado di offrire 3CX come centralino virtuale in parallelo alla versione in locale.

Gestione semplificata con nuove funzionalità e più VoIP Provider supportati

A livello di gestione del sistema, sono state aggiunte diverse funzionalità come backup & restore programmabili, maggiori messaggi di avviso ed un’interfaccia razionalizzata. 3CX inoltre integra un sistema di fault tolerance. Con l’edizione PRO è ora semplice mantenere in stand-by una copia virtuale del centralino da attivare in caso di server failure. Oltre a questo, gli amministratori potranno sfruttare una serie di nuove funzionalità, come ad esempio report schedulati inviati per email, gestione dello spazio disco per voicemail e registrazioni e diversi nuovi VoIP Provider fra cui scegliere, compresi, fra gli altri, Broadvoice, AMcom, Deutsche Telekom, Time Warner Cable e, per l’Italia, CloudItalia.

Videoconferenza Integrata aggiornata

La soluzione di videoconferenza integrata, 3CX WebMeeting, ha a sua volta beneficiato di diverse migliorie, a cominciare da una maggior qualità video dovuta ai miglioramenti della tecnologia WebRTC. Il software ora comprende diverse nuove funzionalità ideali per webinars e classi virtuali, come ad esempio il controllo remoto, la registrazione in formato standard compatibile con YouTube e feedback-polling. In aggiunta, offre la possibilità di cedere il controllo del meeting ad altri partecipanti e di pre-caricare presentazioni PowerPoint in formato XML per un minor consumo di banda. Infine, 3CX WebMeeting è gratuito per l’intera azienda per un massimo di 10 participanti contemporanei e, per garantire una miglior user experience, 3CX ha esteso la propria rete mondiale di server per consentire una gestione ottimale dei flussi video.

Nota per i Redattori

Per maggiori informazioni su 3CX Phone System 14 si prega di visitare:

www.3cx.it

Listino qui.

Download Links e Documentazione

Download 3CX Phone System v14: http://downloads.3cx.com/downloads/3CXPhoneSystem14.exe

Download 3CXPhone for iOS Client

Download 3CXPhone for Android Client

Download 3CXPhone for Windows Client

Download 3CXPhone for Mac Client

Download 3CX Session Border Controller for Windows

Leggi il  v14 Admin Manual

Leggi il v14 User Manual

Approfondimenti

• I benefici di un centralino ip web based (cloud)
  

  Una veloce panoramica sulle prospettive del voip in ambito lavorativo. Il 2010 potrebbe essere l’anno della definitiva consacrazione dell’ unified communication, in versione molto differente da quella originariamente prospettata, ed incentrata sull’utilizzo [...]

• 3CX Phone System v14: Preview tecnica
  

  La nuova major release di 3CX Phone System è pronta! Il nostro team Ricerca&Sviluppo c’è riuscito un’altra volta e ci ha fornito una versione straordinaria: pronta per il Cloud e corredata di [...]

• Al varo la versione 5 del centralino windows di 3cx
  

  Alcuni giorni fa è stata rilasciata la quinta versione del più completo centralino per piattaforma Windows che ora annovera alcune “succose” feautures come fax server integrato, codec G729 ed un piccolo client [...]

Product/ Feature Improvements

It is hard to stress how exciting this version release is for our resellers, who are passionate about the end user experience. Some of the requests came through our community, who helped us beta test before launch, and deserve a hand for kicking the tires! Some major highlights:
 

• SmartPBX got a walkthrough to make it easier for first time users, and a fix to how the Virtual Receptionist works by default.
• White Labelling for Resellers got a MAJOR upgrade. The branded experience is now much more pervasive across the board, from Forgot Password to the Report Call button. Also, the UI now helps you configure your DNS properly, a big time saver when trying to get setup.
• Remote Reboot for Devices is here! You can now reboot devices REMOTELY from the UI. This means no more site visits or requests to the customer to reboot their own phones. Now, you just make your configuration changes, click the “Reboot Device” button and you are done! Trust us, your support team will love it.
• Conference bridges now can have entry/exit tones that you can toggle on/off.
• User Portal has been ported in from the old UI.
• Updated language and time options for international clients.

  Product and Feature Improvements Product/ Feature Ticket Release Notes Advanced Callflows UI-1493 Account Caller ID settings are now enabled in Advanced Callflows. Advanced Callflows UI-1787 Admins may now control entry/exit tone settings on conference bridges, and can toggle them on/off. Billing UI-1609 Improvements to Billing API for our Hosted Cloud Branding UI-1584 Made the Forgot Password button on login an optional item for branded accounts, so Resellers can control the security experience more tightly. Branding UI-1580 Multiple Sub-branded accounts are now enabled for resellers. Additionally, masquerading in the Branding app should now work for all subaccounts, not just the top level account. Branding UI-1744 Resellers attempting to configure their Whitelabel domains will now get feedback from the UI on whether or not their DNS entries are properly configured. Branding UI-1375 The Branding UI will now provide a Domain Configuration Helper Tool, so that admins can more easily configure their domains correctly. Branding UI-1497 Call Reporting for resellers is now supported! End users can now report calls to an email of your choosing in the White Label app, so that you can troubleshoot specific call logs when the system is experiencing an error. Branding UI-1470 Branding App now allows for customized text in Browser tab. Branding UI-1473 Branding Manager now allows you to Customize the Favicon in the browser on your White Labeled portal Branding UI-1480 Branding Manager now allows you to Customize the welcome message on your White Labeled portal Device Management UI-377 You can now restart Devices remotely. General UI-1626 Improved documentation for Monster UI apps. General UI-1622 Improved password validation to require 6 characters General UI-1636 Self-Service users may no longer see trunking options, since plans don’t work on trunks. General UI-1606 Users may now tab through buttons when using the UI Kazoo UI Changes UI-1723 Kazoo can now handle European and other date formats where ‘DMY’ or 'YMD’ schemas are used. Kazoo UI Changes UI-1587 Updated Russian Translation for Kazoo UI. Kazoo UI Changes UI-1459 User Portal has been successfully ported into the new UI and is available to resellers. Kazoo UI Changes UI-1499 Account Timezones will no longer default to the timezone of the browser on account creation Kazoo UI Changes UI-343 File Uploads now will show progress of the upload. Kazoo UI Changes UI-1574 Voicemail Messages can now be listened to in the User Portal. Porting UI-1757 Added 'Cancelled’ Port state to Smart PBX and Port Manager. Porting UI-1750 Clarified scheduling information for ports Porting UI-1753 Clients will now see scheduling (date/time) information for their ports. Porting UI-1718 Porting is now attached to Project Phonebook. Porting UI-1690 Porting now uses the API instead of trying to filter by itself, resulting in a faster, more responsive experience. Provisioner Core PROV-166 Phones should now display the User/Extension rather than the sip registration information, making for a better user experience. Reporting UI-1612 Reseller Reporting Tool is now easier to use thanks to better filtering. SmartPBX UI-1206 Caller ID Prepends on Ring Groups are now supported. SmartPBX UI-1421 Created a Step by Step walkthrough to help people understand how to use SmartPBX on their first time in the app. SmartPBX UI-1657 SmartPBX now supports a default action on incoming call handing, so when users misdial, they aren’t lost into a dead menu. SmartPBX UI-1741 You can actually reboot the phone remotely now! Update firmware at night. Never again call your customers to reboot the phone. SmartPBX UI-1489 Clicking the Add User link should show a popup with a list of users to select. You should be able to select many users. SmartPBX UI-1745 Fixed a bug where the default action in menu’s wasn’t able to be properly set. SmartPBX UI-1721 Russian i18n files have been updated. SmartPBX UI-1772 Timepicker plugin now respects date format of the current user.   Kazoo Core Improvements
Some nice goodies in here. A couple major highlights:

• Outbound faxing will now send an email confirmation notice to the sender.
• Device language settings now get inherited from the account, so there is less confusion for our multi-lingual customers on setup!

Some other basic improvements, and the rest of the Core work this sprint was mostly bug fixes, so check that section for more interesting changes to the Core architecture.   Kazoo Core Improvements Product/ Feature Ticket KAZOO-3090 When an outbound fax goes through, the sender will now get an email confirmation. KAZOO-3808 Device and user language settings will now be inherited from the account, rather than defaulting to english. KAZOO-3634 Apps in the App Store can now be made “admin only” so that app functionality can be tested on production prior to launch. KAZOO-3775 Eliminated unnecessary retries on voicemail saving so that the system is more efficient. KAZOO-3637 Developers are now able to pass custom channel VAR’s to babble. KAZOO-3777 Text to Speech improved with new voices. KAZOO-3647 Webhooks created for a specific account will now be deleted when the account is deleted.   Developer Improvements
As our client base grows, so does the number of developers looking for additional access via the APIs.

Key highlights:

• We have improved access to the service docs APIs in preparation to be able to help developers who wish to store charges in the system.
• We have vastly improved the experience with Webhooks, making them easier to toggle on/off/timeout, providing email notifications when Webhooks fail, and improving the information that comes from debugs.

Developer Improvements Product/ Feature Ticket Release Notes Developer KAZOO-3636 SMS API now provides an option  to not convert caller-id and caller-ID to e164, so that caller-ID is preserved. Developer KAZOO-244  An API now exists that tracks Service Doc changes, so that a history of billable transactions for billing. This is a big deal for 2600hz as well as our resellers, as you can now track charging history for any charge on the system. Developer KAZOO-3597 API will now validate CNAM when attempting to set, and return an error if the submission is more than 15 characters. This will help prevent users from setting CNAM that is longer than the system supports. Developer KAZOO-3663 Crossbar API for Provisioner now shows 'callids’ in the logs Developer KAZOO-3689 Dialyzer now returns less warnings when performing Static Code Analysis on Kazoo code. Improves code quality. Developer UI-1454 Improved documentation for User States Developer UI-1381 The “Font Awesome” font and CSS toolkit is now available to front end developers, providing access to more icons and a more up-to-date library Developer KAZOO-3766 Upgrade for Project Phonebook to be able to retrive an auth token on login to verify that the user is who they say they are. Webhooks KAZOO-3633 Developers can now re-enable all timed-out webhooks at one time. Webhooks UI-748 Webhooks will now show the history of attempts for each hook. Webhooks KAZOO-3631 Webhooks debug info now provides request headers and payload as well as the response headers and payload for any failed attempts. Webhooks KAZOO-3632 An email notification will now be provided if a webhook is disabled. Webhooks UI-1469 Individual Webhooks can now be toggled active/inactive to make management of the hooks easier.   Bug Fixes   Bug Fixes Product/ Feature Ticket Release Notes Advanced Callflows UI-1731 Timeout/Delay Settings are now functional in the new UI. Advanced Callflows UI-1604 UI Improvement Branding UI-1760 SmartPBX now respects Branding app settings for the Support email field Branding UI-1649 Fixed a Custom Welcome Message error. Branding UI-1503 Fixed a JS error causing branding app not to load Branding UI-1575 Fixed the Branding App so it respects Default Language settings in the UI Branding UI-1593 Improved UI content to be more gender neutral. Branding UI-1743 The Whitelabel Domain Helper now displays more complete DNS requirements when resellers are configuring Whitelabelling Call Logs UI-1702 Using the “This Week” filter on call logs will now include Sundays in the Call Logs Carrier Manager UI-1455 UI Improvement Carrier Manager UI-1468 UI Improvement Carrier Manager UI-1466 Updated tabs in Carriers Manager to be more clear to the user Developer KAZOO-3751 Fixed a bug with Webhooks preventing them from sending requests due to a function clause error with ibrowse. Developer UI-1482 Removed obsolete shared_auth code Device Management UI-1685 Fixed a bug with device codecs General UI-1728 Control Panel is now hid from End Users General UI-1737 Fixed a bug when applying service plans. General UI-1701 Fixed a quickcall bug General UI-1730 Improved White-Labelling General UI-1729 Improvements to Step by Step Wizard General UI-1707 UI Fix Kazoo Core KAZOO-3628 Fixed a bug with Auto Top Up feature on hosted accounts. Kazoo Core KAZOO-3638 Backend API fix Kazoo Core KAZOO-3649 Bug fix for voicemail count. Kazoo Core KAZOO-2895 Call restrictions will now be applied after processing dial plans to enable international support. Kazoo Core KAZOO-3563 Devices will now sync to the new SIP user name, when SIP user name is updated in the settings. Kazoo Core KAZOO-3577 Fixed a bug in PBX Connector that caused changes to not take effect for about an hour. They now take effect immediately. Kazoo Core KAZOO-3626 Fixed a bug where adding more than 4 codecs to a device would crash the provisioner Kazoo Core KAZOO-3659 Fixed a bug where auto top-up transactions were being authorized, but not charged. Kazoo Core KAZOO-3648 Fixed a bug where Directories weren’t deleting from MonsterUI Kazoo Core KAZOO-3644 Fixed a bug where flushing numbers from the cache would flush ALL numbers from the cache. This fix will reduce db requests and only flush the specific numbers that have changed. Kazoo Core KAZOO-3708 Fixed a bug where running Multiple Milliwat listeners on the message bus were crashing the system. Kazoo Core KAZOO-3122 Fixed a feature code bug where different feature codes were being interpreted as the conflicting numbers. Kazoo Core KAZOO-3642 Fixed an issue where numbers in the middle of being ported it would get orphaned if the account was deleted before Port In was completed. Kazoo Core KAZOO-3551 Fixed Ecallmgr bug where it was overwriting the Freeswitch configuration db with blank data after booting/restarting the system. Kazoo Core KAZOO-2548 Kazoo will now turn off pagination when filters exist on the request Kazoo UI Changes UI-1444 Cookie will no longer update if the App Store is updated while masquerading. Kazoo UI Changes UI-1492 Fixed a bug in numberSelector Kazoo UI Changes UI-1483 Fixed Date formatting for Gregorian calendars Kazoo UI Changes UI-1578 New Accounts on our Hosted Platform will now default to per minute when an account is created, so it’s easier for Resellers to begin setting up services. Kazoo UI Changes UI-1494 UI Fix Kazoo UI Changes UI-1502 UI Fix for disappearing apps Kazoo UI Changes UI-1474 UI Improvement Kazoo UI Changes UI-1490 UI Improvement Number Manager UI-1505 UI Improvement Number Manager UI-1607 UI Improvement PBX Connector UI-1382 Fixed a bug that was causing WYSIWYG to take too long to load in Firefox PBX Connector UI-1495 Fixed number layout bug in PBX Connector PBX Connector UI-1613 Outbound trunks will now show their cost PBX Connector UI-1638 UI Improvement - Better Icons Porting UI-1776 Bug Fix Porting UI-1748 Clarified scheduling information for ports Porting UI-1739 Fixed a wild JS error Porting UI-1746 Fixed anerror with duplicate numbers Porting UI-1740 Removed empty drop down when viewing Port States Provisioner Core PROV-170 Fixed an error where the path to the yealink firmware does not include the brand name in the auto-generated files. SmartPBX UI-1771 Bug Fix SmartPBX UI-1498 Call Restrictions settings now sync between MonsterUI and KazooUI

Our third KazooCon is rapidly approaching, and we have been reflecting on the successes and failures of our first two events. We have talked to past attendees, our partners, and sponsors about what is most important to them about our products. Over the past couple of months, we have been slowly building the KazooCon agenda and today we are proud to announce it to you. As you may already know, this year’s event will occur October 5th – 6th at Broadway Studios in San Francisco, CA.

So what will take place at KazooCon and why should you come?

Huge Announcements
Every year at KazooCon we want to show you all the incredible things we’ve been working on, and admittedly sometimes we over promise and show an unfinished product. Back in January, the entire 2600Hz team discussed Kazoo, our common goals, and how we want to take the company forward. Over the past nine months we have been singularly focused on building a set of fully-featured products, and KazooCon is where we will be introducing it to the world. There is no question that this will be the most important KazooCon yet! We will announce SaaS including our brand new reseller platform, Cluster Manager, Infrastructure as a Service (IaaS) and will reveal our incredible new brand. We have been very quiet all year, but brace yourself because it’s about to get loud.

Interactive Demo’s
We heard your feedback from KazooCon 2014, and the overwhelming favorite session was the breakout demo. So we are doubling down this year and we’ll be hosting five hands-on demo’s (hint: bring your laptop). You will get a first-hand look of the of our new Kazoo API’s and our Engineers will take you through it step-by-step. Our interactive demo’s will include:

• A Look Ahead at the power of Video, WebRTC and Mobile
• Onboard Customers Automatically via Your Brand
• Provisioning including Encryption, NAPTR, SRV Records, Failover and Security
• WebHooks and WebSockets - Getting Real-Time Information to Create Call Recording and Screen Pop Integration Tools
• Debugging using Packet Captures, Wireshark and NAT

Wonderful Slate of Telephony Leaders
This year we have an exceptional slate of Business leaders and and Telecom pioneers. Telco gurus from around the world are going to wow you with their talks by presenting their own stories of success, tools for enhancement in the telecom industry, and much more. Our speakers include:

• David Messenger, Founder and CEO of Mast Mobile
• Christos Kolias, OpenFlow/ SDN Technical Lead at Orange
• Daniel Constantin Mierla, Co-Founder of Kamailio
• Michael Jerris, Co-Founder of FreeSWITCH
• Lon Baker, COO at Virtual PBX
• Greg Hobson, Market Development at IBM Cloudant
• Vernon Keenan, Co-Founder and CEO of Telnexus
• Mikhail Rodionov, CEO of SIPLabs

So what are you waiting for, join us for the Unified Communications Revolution!

Not convinced yet? Take a look at a presentation from last year!

The FreeSWITCH 1.4.21 release is here! This is a routine maintenance release and the resources are located here:

• Tarballs: http://files.freeswitch.org/releases/freeswitch/freeswitch-1.4.21.tar.bz2
• Packaging: https://freeswitch.org/confluence/display/FREESWITCH/Installation

New features that were added:

• FS-7760 [mod_sofia] Added xml fetch for channels to externally support nightmare transfer depends on channel-xml-fetch-on-nightmare-transfer profile param (default is disabled)

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

• OPENZAP-238 [freetdm] Fix some GSM compilation errors and do a bit of code cleanup
• OPENZAP-237 [freetdm] Use __func__ instead of __FUNCTION__ to comply with c99 in gcc 5.1
• FS-7043 Fixed apr1 unresolved symbols in libfreeswitch.so.1.0.0
• FS-7985 [mod_voicemail] Fixed a compilation error on 32-bit PCC platform
• FS-8047 [mod_basic] Fixed a build error on newer compiler

The following bugs were squashed:

• FS-8028 [mod_shout] fix random sockets
  being closed regression from FS-7621
• FS-8037 [core] zrtp-passthru shouldn’t activate unless the zrtp-hash is in the SDP.
• FS-7732 [mod_commands] Continue recording with uuid_transfer
• FS-7721 [core] Fixed a segfault caused when using session:recordFile() and session:unsetInputCallback in a lua script
• FS-7429 [mod_curl] Fixed to output valid json. NOTE: this may cause issues if you have worked around this invalid json already
• FS-7761 [core] Fix shutdown races running api commands during shutdown
• FS-7767 [mod_sofia] Fixed a segfault caused by invalid arguments to sip_dig
• FS-7778 [mod_sofia] Fixed a bug causing a SQL statement to fail because of a double quote instead of a single quote
• FS-7754 [freetdm] Fixed a bug relating to single digit dial-regex with analog devices
• FS-7731 [mod_xml_cdr] Fixed a curl default connection timeout
• FS-7685 [mod_say_nl] Fix Dutch numbers pronunciation
• FS-7654 [core] Fixed regressions on eavesdropping on channels playing a file and on channels with unlike rates
• FS-7866 [core] Fixed a crash when running incorrect var api expansion syntax “eval ${${external_sip_ip}:4}”
• FS-7872 [mod_verto] Gracefully fail attempting to transfer 1 legged call
• FS-7891 [mod_spandsp] Allow spandsp dtmf detector to work on rates other than 8k
• FS-7839 [webrtc] Correct firefox > 38 DTLS behavior to match new EC requirements
• FS-7917 [mod_sofia] Fixed default config, we really shouldn’t be setting ext-*-ip settings for ipv6 profiles
• FS-7951 [mod_rayo] Completely clean up mod_rayo if it fails to load
• FS-7955 [mod_sofia] Fixed a crash caused by invalid contact when using event to send a notify message
• FS-7975 [mod_voicemail] Fix record-greeting event missing VM-Greeting-Path
• FS-7969 Fixed a segfault due to pthread_setschedparam() on a thread that has exited
• FS-7962 [mod_sofia] Fixed sporadic invite/replaces failure
• FS-7486 [mod_sofia] Fixed the handling of queued requests
• FS-7750 [mod_commands] Set uuid_setvar to handle arrays

The fact that you can use WebRTC to implement a secure, reliable, and standards based peer-to-peer network is a huge deal that is often overlooked.  We have been notably light on the DataChannel here at webrtcHacks, so I asked Arin Sime if would be interested in providing one of his great walkthrough’s on this topic.  He put together a very practical example of a multi-player game.  You make recognize Arin from RealTime Weekly or from his company Agility Feat or his new webRTC.ventures brand. Check out this excellent step-by-step guide below and start lightening the load on your servers and reducing message latency with the DataChannel.

{“editor”: “chad hart“}

WebRTC is “all about video chat”, right? I’ve been guilty of saying things like that myself when explaining WebRTC to colleagues and clients, but it’s a drastic oversimplification that should never go beyond your first explanation of WebRTC to someone.

Of course, there’s more to WebRTC than just video chat. WebRTC allows for peer-to-peer video, audio, and data channels.  The Data channels are a distinct part of that architecture and often forgotten in the excitement of seeing your video pop up in the browser.

Don’t forget about the Data Channel!

Being able to exchange data directly between two browsers, without any sort of intermediary web socket server, is very useful. The Data Channel carries the same advantages of WebRTC video and audio:  it’s fully peer-to-peer and encrypted.  This means Data Channels are useful for things like text chat applications, file transfers, P2P file exchanges, gaming, and more.a

In this post, I’m going to show you the basics of how to setup and use a WebRTC Data Channel.

First, let’s review the architecture of a WebRTC application.

You have to setup signaling code in order to establish the peer to peer connection between two peers.  Once the signaling is complete (which takes place over a 3rd party server), then you have a Peer to Peer (P2P) connection between two users which can contain video and audio streams, and a data channel.

The signaling for both processes is very similar, except that if you are building a Data Channel only application then you don’t need to call GetUserMedia or exchange streams with the other peer.

Data Channel Security

There are a couple of other differences about using the DataChannel.  The most obvious one is that users don’t need to give you their permission in order to establish a Data Channel over an RTCPeerConnection object.  That’s different than video and audio, which will prompt the browser to ask the user for permissions to turn on their camera and microphone.

Although it’s generating some debate right now, data channels don’t require explicit permission from users.  That makes it similar to a web socket connection, which can be used in a website without the knowledge of users.

The Data Channel can be used for many different things.  The most common examples are for implementing text chat to go with your video chat.  If you’re already setting up an RTCPeerConnection for video chat, then you might as well use the same connection to supply a Data Channel for text chat instead of setting up a different socket connection for text chat.

Likewise, you can use the Data Channel for transferring files directly between your peers in the RTCPeerConnection.  This is nicer than a normal socket style connection because just like WebRTC video, the Data Channel is completely peer-to-peer and encrypted in transit.  So your file transfer is more secure than in other architectures.

The game of “Memory”

Don’t limit your Data Channel imagination by these common examples though.  In this post, I’m going to show you how to use the Data Channel to build a very simple two-player game.  You can use the Data Channel to transfer any type of data you like between two browsers, so in this case we’ll use it to send commands and data between two players of a game you might remember called “Memory”.

In the game of memory, you can flip over a card, and then flip a second card, and if they match, you win that round and the cards stay face up.  If they didn’t match, you put both face down again, and it’s the next person’s turn.  By trying to remember what you and your opponents have been flipping, and where those cards were, you can win the game by correctly flipping the most pairs.

Photo Credit: http://www.vwmin.org/memory-game.html

Adam Khoury already built a javascript implementation of this game for a single player, and you can read his tutorial on how to build the game Memory for a single player.  I won’t explain the logic of his code for building the game, what I’m going to do instead is build on top of his code with a very simple WebRTC Data Channel implementation to keep the card flipping in synch across two browsers.

You can see my complete code on GitHub, and below I’m going to show you the relevant segments.

In this example view of my modified Memory game, the user has correctly flipped pairs of F, D, and B, so those cards will stay face up.  The cards K and L were just flipped and did not match, so they will go back face down.

Setting up the Data Channel configuration

I started with a simple NodeJS application to serve up my code, and I added in Express to create a simple visual layer.  My project structure looks like this:

The important files for you to look at are datachannel.js (where the majority of the WebRTC logic is), memorygame.js (where Adam’s game javascript is, and which I have modified slightly to accommodate the Data Channel communications), and index.ejs, which contains a very lightweight presentation layer.

In datachannel.js, I have included some logic to setup the Data Channel.  Let’s take a look at that:

//Signaling Code Setup var configuration = {         'iceServers': [{                 'url': 'stun:stun.l.google.com:19302'         }] }; var rtcPeerConn; var dataChannelOptions = {         ordered: false, //no guaranteed delivery, unreliable but faster         maxRetransmitTime: 1000, //milliseconds }; var dataChannel;

The configuration variable is what we pass into the RTCPeerConnection object, and we’re using a public STUN server from Google, which you often see used in WebRTC demos online.  Google is kind enough to let people use this for demos, but remember that it is not suitable for public use and if you are building a real app for production use, you should look into setting up your own servers or using a commercial service like Xirsys to provide production ready STUN and TURN signaling for you.

The next set of options we define are the data channel options.  You can choose for “ordered” to be either true or false.

When you specify “ordered: true”, then you are specifying that you want a Reliable Data Channel.  That means that the packets are guaranteed to all arrive in the correct order, without any loss, otherwise the whole transaction will fail.  This is a good idea for applications where there is significant burden if packets are occasionally lost due to a poor connection.  However, it can slow down your application a little bit.

We’ve set ordered to false, which means we are okay with an Unreliable Data Channel.  Our commands are not guaranteed to all arrive, but they probably will unless we are experiencing poor connectivity.  Unless you take the Memory game very seriously and have money on the line, it’s probably not a big deal if you have to click twice.  Unreliable data channels are a little faster.

Finally, we set a maxRetransmitTime before the Data Channel will fail and give up on that packet.   Alternatively, we could have specified a number for maxRetransmits, but we can’t specify both constraints together.

Those are the most common options for a data channel, but you can also specify the protocol if you want something other than the default SCTP, and you can set negotiated to true if you want to keep WebRTC from setting up a data channel on the other side.  If you choose to do that, then you might also want to supply your own id for the data channel.  Typically you won’t need to set any of these options, leave them at their defaults by not including them in the configuration variable.

Set up your own Signaling layer

The next section of code may be different based on your favorite options, but I have chosen to use express.io in my project, which is a socket.io package for node that integrates nicely with the express templating engine.

So the next bit of code is how I’m using socket.io to signal to any others on the web page that I am here and ready to play a game.  Again, none of this is specified by WebRTC.  You can choose to kick off the WebRTC signaling process in a different way.

io = io.connect(); io.emit('ready', {"signal_room": SIGNAL_ROOM}); //Send a first signaling message to anyone listening //In other apps this would be on a button click, we are just doing it on page load io.emit('signal',{"type":"user_here", "message":"Would you like to play a game?", "room":SIGNAL_ROOM});

In the next segment of datachannel.js, I’ve setup the event handler for when a different visitor to the site sends out a socket.io message that they are ready to play.

io.on('signaling_message', function(data) {         //Setup the RTC Peer Connection object         if (!rtcPeerConn)                 startSignaling();         if (data.type != "user_here") {                 var message = JSON.parse(data.message);                 if (message.sdp) {                         rtcPeerConn.setRemoteDescription(new RTCSessionDescription(message.sdp), function () {                                 // if we received an offer, we need to answer                                 if (rtcPeerConn.remoteDescription.type == 'offer') {                                         rtcPeerConn.createAnswer(sendLocalDesc, logError);                                 }                         }, logError);                 }                 else {                         rtcPeerConn.addIceCandidate(new RTCIceCandidate(message.candidate));                 }         }         });

There are several things going on here.  The first one to be executed is that if the rtcPeerConn object has not been initialized yet, then we call a local function to start the signaling process.  So when Visitor 2 announces themselves as here, they will cause Visitor 1 to receive that message and start the signaling process.

If the type of socket.io message is not “user_here”, which is something I arbitrarily defined in my socket.io layer and not part of WebRTC signaling, then the code goes into a couple of WebRTC specific signaling scenarios – handling an SDP “offer” that was sent and crafting the “answer” to send back, as well as handling ICE candidates that were sent.

The WebRTC part of Signaling

For a more detailed discussion of WebRTC signaling, I refer you to http://www.html5rocks.com/en/tutorials/webrtc/infrastructure/”>Sam Dutton’s HTML5 Rocks tutorial, which is what my signaling code here is based on.

For completeness’ sake, I’m including below the remainder of the signaling code, including the startSignaling method referred to previously.

function startSignaling() {         rtcPeerConn = new webkitRTCPeerConnection(configuration, null);         dataChannel = rtcPeerConn.createDataChannel('textMessages', dataChannelOptions);         dataChannel.onopen = dataChannelStateChanged;         rtcPeerConn.ondatachannel = receiveDataChannel;         // send any ice candidates to the other peer         rtcPeerConn.onicecandidate = function (evt) {                 if (evt.candidate)                         io.emit('signal',{"type":"ice candidate", "message": JSON.stringify({ 'candidate': evt.candidate }), "room":SIGNAL_ROOM});         };         // let the 'negotiationneeded' event trigger offer generation         rtcPeerConn.onnegotiationneeded = function () {                 rtcPeerConn.createOffer(sendLocalDesc, logError);         }   }   function sendLocalDesc(desc) {         rtcPeerConn.setLocalDescription(desc, function () {                 io.emit('signal',{"type":"SDP", "message": JSON.stringify({ 'sdp': rtcPeerConn.localDescription }), "room":SIGNAL_ROOM});         }, logError); }

This code handles setting up the event handlers on the RTCPeerConnection object for dealing with ICE candidates to establish the Peer to Peer connection.

Adding DataChannel options to RTCPeerConnection

This blog post is focused on the DataChannel more than the signaling process, so the following lines in the above code are the most important thing for us to discuss here:

rtcPeerConn = new webkitRTCPeerConnection(configuration, null); dataChannel = rtcPeerConn.createDataChannel('textMessages', dataChannelOptions); dataChannel.onopen = dataChannelStateChanged; rtcPeerConn.ondatachannel = receiveDataChannel;

In this code what you are seeing is that after an RTCPeerConnection object is created, we take a couple extra steps that are not needed in the more common WebRTC video chat use case.

First we ask the rtcPeerConn to also create a DataChannel, which I arbitrarily named ‘textMessages’, and I passed in those dataChannelOptions we defined previously.

Setting up Message Event Handlers

Then we just define where to send two important Data Channel events:  onopen and ondatachannel.  These do basically what the names imply, so let’s look at those two events.

function dataChannelStateChanged() {         if (dataChannel.readyState === 'open') {                 dataChannel.onmessage = receiveDataChannelMessage;         } } function receiveDataChannel(event) {         dataChannel = event.channel;         dataChannel.onmessage = receiveDataChannelMessage; }

 

When the data channel is opened, we’ve told the RTCPeerConnection to call dataChannelStateChanged, which in turn tells the dataChannel to call another method we’ve defined, receiveDataChannelMessage, whenever a data channel message is received.

The receiveDataChannel method gets called when we receive a data channel from our peer, so that both parties have a reference to the same data channel.  Here again, we are also setting the onmessage event of the data channel to call our method receiveDataChannelMessage method.

Receiving a Data Channel Message

So let’s look at that method for receiving a Data Channel message:

function receiveDataChannelMessage(event) {                 if (event.data.split(" ")[0] == "memoryFlipTile") {                 var tileToFlip = event.data.split(" ")[1];                 displayMessage("Flipping tile " + tileToFlip);                 var tile = document.querySelector("#" + tileToFlip);                 var index = tileToFlip.split("_")[1];                 var tile_value = memory_array[index];                 flipTheTile(tile,tile_value);         } else if (event.data.split(" ")[0] == "newBoard") {                 displayMessage("Setting up new board");                 memory_array = event.data.split(" ")[1].split(",");                 newBoard();         } }

Depending on your application, this method might just print out a chat message to the screen.  You can send any characters you want over the data channel, so how you parse and process them on the receiving end is up to you.

In our case, we’re sending a couple of specific commands about flipping tiles over the data channel.  So my implementation is parsing out the string on spaces, and assuming the first item in the string is the command itself.

If the command is “memoryFlipTile”, then this is the command to flip the same tile on our screen that our peer just flipped on their screen.

If the command is “newBoard”, then that is the command from our peer to setup a new board on our screen with all the cards face down.  The peer is also sending us a stringified array of values to go on each card so that our boards match.  We split that back into an array and save it to a local variable.

Controlling the Memory game to flip tiles

The actual flipTheTile and newBoard methods that are called reside in the memorygame.js file, which is essentially the same code that we’ve modified from Adam.

I’m not going to step through all of Adam’s code to explain how he built the single player Memory game in javascript, but I do want to highlight two places where I refactored it to accommodate two players.

In memorygame.js, the following function tells the DataChannel to let our peer know which card to flip, as well as flips the card on our own screen:

function memoryFlipTile(tile,val){         dataChannel.send("memoryFlipTile " + tile.id);         flipTheTile(tile,val); }

Notice how simple it is to send a message to our peers using the data channel – just call the send method and pass any string you want.  A more sophisticated example might send well formatted XML or JSON in a message, in any format you specify.  In my case, I just send a command followed by the id of the tile to flip, with a space between.

Setting up a new game board

In Adam’s single player memory game, a new board is setup whenever you load the page.  In my two player adaptation, I decided to have a new board triggered by a button click instead:

var setupBoard = document.querySelector("#setupBoard"); setupBoard.addEventListener('click', function(ev){         memory_array.memory_tile_shuffle();         newBoard();         dataChannel.send("newBoard " + memory_array.toString());         ev.preventDefault(); }, false);

 

In this case, the only important thing to notice is that I’ve defined a “newBoard” string to send over the data channel, and in this case I want to send a stringified version of the array containing the values to put behind each card.

Next steps to make the game better

That’s really all there is to it!  There’s a lot more we could do to make this a better game.  I haven’t built in any logic to limit the game to two players, keep score by players, or enforce the turns between the players.  But it’s enough to show you the basic idea behind using the WebRTC data channel to send commands in a multiplayer game.

The nice thing about building a game like this that uses the WebRTC data channel is it’s very scalable.  All my website had to do is help the two players get a connection setup, and after that, all the data they need to exchange with each other is done over an encrypted peer-to-peer channel and it won’t burden my web server at all.

A completed multiplayer game using the Data Channel

Here’s a video showing the game in action:

Demo of a simple two player game using the WebRTC Data Channel video

As I hope this example shows you, the hard part of WebRTC data channels is really just in the signaling and configuration, and that’s not too hard.  Once you have the data channel setup, sending messages back and forth is very simple.  You can send messages that are as simple or complex as you like.

How are you using the Data Channel?  What challenges have you run into?  Feel free to contact me on Twitter or through my site to share your experiences too!

{“author”: “arin sime“}

Sources:

http://www.html5rocks.com/en/tutorials/webrtc/infrastructure/

http://www.w3.org/TR/webrtc/#simple-peer-to-peer-example

https://www.developphp.com/video/JavaScript/Memory-Game-Programming-Tutorial

Want to keep up on our latest posts? Please click here to subscribe to our mailing list if you have not already. We only email post updates. You can also follow us on twitter at @webrtcHacks for blog updates and news of technical WebRTC topics or our individual feeds @chadwallacehart, @victorpascual and @tsahil.

The post Gaming with the WebRTC DataChannel – A Walkthrough with Arin Sime appeared first on webrtcHacks.

40 days until the Communications Revolution! Time to book your hotel. Join us at KazooCon for talks from FreeSWITCH, Kamailio, Mast Mobile, Virtual PBX, IBM Cloudant, Telnexus and many more! Register now and save: www.KazooCon.com

One of WebRTC’s benefits is that the source to it is all open source. Building WebRTC from source provides you the ultimate flexibility to do what you want with the code, but it is also crazy difficult for all but the small few VoIP stack developers who have been dedicated to doing this for years. What benefit does the open source code provide if you can’t figure out how to build from it?

As WebRTC matures into mobile, native desktop apps, and now into embedded devices as part of the Internet of Things, working with the lower-level source code is becoming increasingly common.

Frequent webrtcHacks guest poster Dr. Alex Gouaillard has been trying to make this easier. Below he provides a review of the building WebRTC from source, exposing many of the gears WebRTC developers take for granted when they leverage a browser or someone else’s SDK. Alex also reviews the issues complexities associated with this process and introduces the open source make process he developed to help ease the process.

{“editor”: “chad hart“}

Building WebRTC from source sometimes feels like engineering the impossible. Photo courtesy of Andrew Lipson.

Building WebRTC from source

Most of the audience for WebRTC (and webrtcHacks)  is made of web developers, JavaScript and cloud ninjas that might not be less familiar with handling external libraries from source. That process is painful. Let’s make it clear, it’s painful for everybody – not only web devs.

 What are the cases where you need to build from source?

1. Writing a native app – mobile, desktop, IoT,..)
2. Some kind of server (gateway, media, ….)
3. Plugin (either for IE, Safari, Cordova, …)

 You basically need to build from source anytime you can’t leverage a browser, WebRTC enabled node.js (for the sake of discussion), SDK’s someone how put together for you,  or anything else.

 These main cases are illustrated below in the context of a comprehensive offering.

Figure 1: map of a WebRTC solution

Usually, the project owners provide precompiled and tested libraries that you can use yourself (stable) and the most recent version that is compiled but not tested for those who are brave.

Pre-compiled libraries are usable out of the box, but do not allow you to modify anything. Sometimes there are build scripts that help you recompile the libs yourselves. This provides more flexibility in terms of what gets in the lib, and what optimizations/options you set, at the cost of now having to maintain a development environment.

Comparing industry  approaches

For example, Cisco with its openH264 library provides both precompiled libraries and build scripts. In their case, using the precompiled library defers H264 royalty issues to them, but that’s another subject. While the libwebrtc project includes build scripts, they are complex use, do not provide a lot of flexibility for modifying the source, and make it difficult to test any modifications.

The great cordova plugin from eFace2Face is using a precompiled libWebRTC (here) (see our post on this too). Pristine.io were among the first one to propose build script to make it easier (see here; more about that later).

Sarandogou/doubango’s webrtc-everywhere plugin for IE and Safari does NOT use automated build scripts, versioning or a standard headers layout, which causes them a lot of problems and slows their progress.

The pristine.io guys put a drawing of what the process is, and noted that, conceptually, there is not a big difference between android and iOS build as to the steps you need to follow. Practically, there is a difference in the tools you used though.

My build process

Here is my build process:

 

Please also note that I mention testing explicitly and there is a good reason for that, learned the hard way. I will come to it in the next section.

You will see I have a “send to dashboard” step. I mean something slightly different than what people usually refer to as a dashboard. Usually, people want to report the results of the tests to a dashboard to show that a given revision is bug free (as much as possible) and that the corresponding binary can be used in production.

If you have performance tests, a dashboard can also help you spot performance regressions.  In my case here, I also want to use a common public dashboard as a way to publish failing builds on different systems or with different configurations, and still provide full log access to anyone. It makes solving those problem easier. The one asking the question can point to the dashboard, and interesting parties have an easier time looking at the issue or reproducing it. More problems reported, more problems solved, everyone is happy.

Now that we have reviewed the build from source process a bit, let’s talk about what’s wrong with it.

Building from Source Sucks

Writing an entire WebRTC stack is insanely hard. That’s why Google went out and bought GIPS, even though they have a lot of very very good engineers at disposal. Most devs and vendors use an existing stack.

For historical reasons most people use google’s contributed WebRTC stack based on the GIPS media engine, and Google’s libjingle for the network part.

Even Mozilla is using the same media engine, even though they originally went for a Cisco SIP soft phone code as the base (see here, under “list of components”, “SIPCC”) to implement the network part of WebRTC. Since then, Mozilla went on and rewrote almost all that part to support more advanced functionality such as multi-party. However, the point is, their network and signaling is different from Google’s while their media engine is almost identical. Furthermore, Mozilla does not attempt to provide a standalone version of their WebRTC implementation, which makes it hard for developers to make use of it right away.

Before Ericson’s OpenWebRTC announcement in October 2014, the Google standalone version was the only viable option out there for most. OpenWebRTC has advantages on some parts, like hardware support for H.264 on iOS for example, but lacks some features and Windows support that can be a showstopper for some. It is admittedly less mature. It also uses GStreamer, which has its own conventions and own build system (cerbero), which is also tough to learn.

The webrtc.org stack is not available in a precompiled library with an installer. This forces developers to compile WebRTC themselves, which is “not a picnic”.

One needs first to become accustomed to Chrome dev tools which are quite unique, adding a learning step to the process. The code changes quite often (4 commits a day), and the designs are poorly documented at best.

Even if you manage to compile the libs, either by yourself or using resources on the web, it is almost certain that you cannot test it before using it in your app, as most of the bug report, review, build, test and dashboard  infrastructure is under the control of Google by default.

Don’t get me wrong, the bug report and review servers allow anybody to set up an account. What is done with your tickets or suggestions however is up to Google. You can end up with quite frustrating answers. If you dig deep enough in the Chrome infrastructure for developers, you will also find how to replicate their entire infrastructure, but the level you need to have to go through this path, and the amount of effort to get it right is prohibitive for most teams. You want to develop your product, not become a Chrome expert.

Finally, the contributing process at Google allows for bugs to get in. You can actually looks at the logs and see a few “Revert” commits there.

Figure 2: Example of a Revert commit message.

From the reverted commits (see footnote[1]: 107 since January 2015), one can tell that revisions of WebRTC on the HEAD are arbitrarily broken. Here again, this comment might be perceived as discriminatory against Google. It is not. There is nothing wrong there; it always happen for any project, and having only 107 reverts in 6 months while maintaining 4 commits a day is quite an achievement. However, it means that you, as a developer, cannot work with any given commit and expect the library to be stable. You have at least to test it yourself.

My small side project to help

My goals are:

1. Provide information to the community that is not documented elsewhere, or not consolidated. The blog posts on www.webrtcbydralex.com fulfill this goal.
2. Learn more about WebRTC
3. Prepare a course for the local university.
4. Do something useful of my current “long vacations”

   Yes, vacations in Boracay, Philippines, once voted #2 most beautiful beach in the world by tripadvisor are nice. But I very quickly get that I-need-to-code urge, and they have Wi-Fi on the beach ….

5. Have fun!

More importantly I would like to lower the barrier of adoption / collaboration / contribution by providing:

• WebRTC installers that sync with chrome revisions that developers could use blindly out of the box (knowing they’ve been tested)
• Code for anyone to set up their own build/try/package pipeline, either locally or in the cloud
• Easy patching and testing framework to enhance Webrtc. As an example, provide an h264 compliant WebRTC lib based on work from Kaiduan Xue, Jesup Randell, and others.
• More examples and applications for Devs to start from. A first example will be a stand-alone, h264 compliant, appRTCDemo desktop app.
• Public dashboard for a community to come together, contribute build bots and de duplicate the tests efforts going on at almost every vendor for the base stack.
• Public dashboard for people to submit their fail builds as a way to ask question on the mailing list and get faster answers.

Example of my dashboard

What we did exactly

We leveraged the CMake / CTest / CDash / CPack suite of tools instead of the usual shell scripts, to automate most of the fetch, configure, build, test, report and package processes.

CMake is cross platform from the ground up, and makes it very easy to deploy such processes. No need to maintain separate or different build scripts for each platform, or build-toolchain.

CTest help you manage your test suites, and is also a client for CDash which handle the dashboard part of the process.

Finally CPack handle packaging your libs with headers and anything else you might want, and support a lot of different packagers with a unified syntax.

This entire suite of tools have also designed in such a way that “a gifted master student could use it and contribute back in a matter of days”, while being so flexible and powerful that big companies like Netflix or Canonical (Ubuntu), use it as the core of their engineering process.

Most of the posts at webrtcbydralex.com will take you through the process, step by step of setting up this solution., in conjunction with a github repository holding all the corresponding source code.

The tool page provides installers for WebRTC for those in a hurry.

{“author”: “Alex Gouaillard“}

[1] git log –since=1.week –pretty=oneline | grep Revert | wc -l

Want to keep up on our latest posts? Please click here to subscribe to our mailing list if you have not already. We only email post updates. You can also follow us on twitter at @webrtcHacks for blog updates and news of technical WebRTC topics or our individual feeds @chadwallacehart, @victorpascual and @tsahil.

The post Making WebRTC source building not suck (Alex Gouaillard) appeared first on webrtcHacks.

Next European edition of Kamailio Advanced Training will take place in Berlin, Germany, during September 28-30, 2015.The content will be based on latest stable series of Kamailio 4.3.x, released in June 2015, the major version that brought a large set of new features.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 coordinating the training session in Berlin!

Hello, again. This past week in the FreeSWITCH master branch we had 56 commits. This week the features are: a wonderful perl script, filebug.pl, to help file bugs from the command line, and more work on improving verto communicator including integration of Gravatars, some filter options, and grunt.

Join us on 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-7988 Add a perl script to help file bugs from the command line and add fixbug.pl to tree
• FS-8009 [verto communicator] Create a grunt project with livereload support. Documentation can be found here.
• FS-8010 [verto communicator] Add options for googAutoGainControl, googNoiseSuppression, and googHighpassFilter
• FS-7855 [verto communicator] Pass userVariables back to the live array to allow for displaying the Gravatar associated with a member’s email address

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

• FS-7965 [mod_conference] Fixed an error thrown when compiling with GCC
• FS-7985 [mod_voicemail] Fixed a compilation error on 32-bit PCC platform
• FS-8015 [mod_conference] Add project dir to include for mod_conference so it picks up mod_conference.h for Windows

The following bugs were squashed:

• FS-7970 Fixed crash in video_bug_thread caused by double free
• FS-7971 [mod_opus] Fixed a rate mismatch and correctly advertise telephone-event and CN rates based on the advertised rates of offered codecs
• FS-7960 Fixed check_ice routine in switch_core_media.c to not use dropped candidates
• FS-7975 [mod_voicemail] Fix record-greeting event missing VM-Greeting-Path
• FS-7969 Fixed a segfault due to pthread_setschedparam() on a thread that has exited
• FS-7962 Fixed sporadic invite/replaces failure
• FS-8004 Send keyframe on receiving nack with multiple consecutive packets
• FS-8005 [mod_opus] Fix for rare decoder error when doing PLC, OPUS_GET_LAST_PACKET_DURATION might return 0
• FS-8006 Changed the typedef of switch_core_video_thread_callback_func_t for consistency
• FS-7932 [mod_verto] Removed the param from the getMute function in verto class, not needed on underlying method
• FS-8008 [mod_verto] Separate verto default config to have sep v4 and v6 listeners
• FS-8016 [mod_conference] Reduce buffering of video in conference mux
• FS-7977 [verto communicator] Fixing default resolution and cleaning code
• FS-7992 [verto communicator] Fixed device list at settings
• FS-8017 [verto communicator] Fixed uses of serialized verto in local storage
• FS-7986 [verto communicator] Fix for devices not refreshing if system config changes
• FS-7998 [verto communicator] Don’t prompt when recovering call, just do it.
• FS-8003 [verto communicator] Use audioInDevices instead of audioDevices to match verto plugin

Containers have become rather popular lately and Docker is the technology leader. Containers make it easy to prototype and test, but many see them as a way to scale on demand, therefore pushing towards production deployments.Searching the web about Kamailio and Docker reveals plenty of resources, from bare dockerfiles to detailed blog articles to combine Docker, Kamailio and other VoIP applications such as Asterisk.Here are links to such resources:

• http://blog.alezzandro.com/post/112533470033/fast-kamailio-deployment-using-docker
• http://dougbtv.com/2015/05/21/high-availability-asterisk-coreos/
• https://blog.irontec.com/voip-y-la-guerra-por-el-crecimiento-horizontal-con-el-trio-docker-kamailio-y-asterisk/ (spanish)
• https://github.com/linuxmaniac/pkg-kamailio-docker
• https://github.com/Ntipa/docker-kamailio
• https://hub.docker.com/r/guardianproject/kamailio-base/

Some Docker resources exist for Siremis, the web management interface for Kamailio:

• https://github.com/sboily/dockerfile/tree/master/siremis
• https://hub.docker.com/r/quintana/siremis/

Note that we haven’t explicitly tested those resources, it is up to you to select one, adjust and test as you need. This post has the role to provide a starting point for using Kamailio with Docker.If you are aware of other resources relevant for Kamailio and Docker, write to mailing list  to get them listed here.Enjoy!

It is time for a quick vacation.

In the past, I tried publishing here while on vacation, I’ll refrain from it this time.

Please do your best not to acquire anyone until end of August.

See you all next month!

The post Quick vacation appeared first on BlogGeek.me.