News from Industry

4K isn’t part of the current round of fighting.

A quick disclaimer: I own a Chromecast dongle. I don’t use it much. My daughter plays Just Dance Now every couple of days on it. And sometimes we watch our pictures on the large screen. So I can’t be called a true user of these devices.

That said, these devices are heavily used for streaming, which means video, which means a video codec. Which means I am a bit interested in them lately. Especially now with the H.265 crisis and the newly found Alliance for Open Media.

We had two launches lately and rumors of a third one. Let’s look at each one of them from the prism of codec support and resolution.

Apple TV

Apple TV has its issues with the web. The spec of this upcoming device, from Apple’s website, include the following video formats:

H.264 video up to 1080p, 60 frames per second, High or Main Profile level 4.2 or lower

H.264 Baseline Profile level 3.0 or lower with AAC-LC audio up to 160 Kbps per channel, 48kHz, stereo audio in .m4v, .mp4, and .mov file formats

MPEG-4 video up to 2.5 Mbps, 640 by 480 pixels, 30 frames per second, Simple Profile with AAC-LC audio up to 160 Kbps, 48kHz, stereo audio in .m4v, .mp4, and .mov file formats

Running an A8 chip, it can be deduced that it might actually have H.265 capabilities, but Apple decided to not use them for the time being – the same way it removed H.265 from FaceTime on the iPhone 6.

They also aren’t going overboard with the resolution, sticking to 1080p, streamed with H.264. The nice thing here is their 60 fps support.

There’s no 4K though. And no H.265.

Amazon Fire TV

Amazon announced its own response to the Apple TV a day after the Apple TV announcement. As with all classic after-Apple announcement, this had the two obvious features: lower price point and better hardware.

The better hardware part boils down to support for 4K resolutions.

The specs indicate the following content formats:

Video: H.265, H.264, Audio: AAC-LC, AC3, eAC3 (Dolby Digital Plus), FLAC, MP3, PCM/Wave, Vorbis, Dolby Atmos (EC3_JOC), Photo: JPEG, PNG, GIF, BMP

So higher resolutions probably get streamed at H.265 while everything else is H.264.

Here’s the rub though:

1. Amazon is now part of the Alliance for Open Media – created to ditch royalty bearing codecs such as H.265
2. The HEVC Advance announced their intent to leech ask payment based on streamed content and not only devices sold. How does that get calculated into a low margin retailer such as Amazon?

This is a hardware device. No real option to add or replace video codecs easily – at least not at such high resolutions. They worked on this one for over a year, so they couldn’t have foretold the mess that H.265 patents will be today. They didn’t want (or couldn’t) risk it with VP9. So now what?

Will this 4K device be useful for watching Amazon video movies at 4K? How higher will these need to be priced to deal with the royalty headaches of H.265?

Google’s YouTube service certainly isn’t going to support H.265 for its 4K streams anytime soon.

Can’t see 4K using H.265 on a hardware device in 2015 the right choice. Sorry.

Google Chromecast

Only rumors for now, but it seems this one will be announced on September 29th. We will know soon enough how stupid my estimates really are.

Here we go – these are my own estimates:

• We really know little about the Chromecast’s specs. Even the one on the market – no clue on the video codec in it. It might be VP8 or H.264. My bet is on H.264 on the older model
• The new Chromecast won’t support H.265. It will have support for H.264 and VP9
• It won’t do 4K. It will focus on software related features to beat competition
• VP9 will be there to better work with YouTube’s new VP9 support and reduce bandwidth strains on both Google and the end customer

We will see in a a week how I fared on this one.

Bottom Line

While 4K is a higher resolution than 1080p, it is too new and too niche at this point:

• There aren’t enough TVs out there supporting 4K
• There’s not enough content available
• No one decided way of compressing such resolutions (with a nice patents minefield to go along with it)
• And there aren’t many viewers who will be able to see the difference anyway

 

Kranky and I are planning the next Kranky Geek - Q1 2016. Interested in speaking? Just ping me through my contact page.

The post Apple TV, Amazon Fire TV or a new Google Chromecast Dongle – 4K Won’t Matter appeared first on BlogGeek.me.

Hello, again. This past week in the FreeSWITCH master branch we had 57 commits. The features for this week include: added support for timestamp based counting for jitter buffer in audio mode, added support for X-headers in this 3p mode in mod_sofia, and fine-tuning FEC with repacketization and improved jitter buffer debugging with FEC in mod_opus. And, a security issue was fixed by properly handling malformed json when parsing json!

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.

Security Issues:

• FS-8160 Fixed head overflow in json parser, properly handle malformed json when parsing json with \u at the end of a json string. Thank you to Marcello Duarte who discovered and reported this issue.

New features that were added:

• FS-8053 Additional work toward handling a=sendonly, a=sendrecv, a=recvonly to change who is sending video during a call
• FS-8130  Added support for timestamp based counting for jitter buffer in audio mode
• FS-6833  FS-6834  [mod_sofia] Added support for X-headers in this 3p mode
• FS-8175  Added continue_on_answer_timeout variable to allow channel to proceed from a tripped answer timeout
• FS-8080  [mod_opus] Fine-tune FEC with repacketization (ptimes: 80 ms,100 ms,120 ms)
• FS-8179  [mod_opus] Improved jitter buffer debugging with FEC

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

• FS-8165 [Debian] Fixed build depends for mod_hiredis
• FS-5660 [Debian] Added freeswitch.py to the freeswitch-mod-python Debian package
• FS-6972 [Debian] Fixed a whitespace error in bootstrap.sh

The following bugs were squashed:

• FS-6833 FS-6834 Fixed double re-invite on media establishment in new late offer invite feature
• FS-8053 [mod_conference] Fixed some regressions from original merge and added auto mute-unmute when toggling video send/receive
• FS-8114 Fixed opus and telephone event payload types colliding on REFER
• FS-8169 Fixed uuid_displace on stereo channels can lead to memory corruption causing a crash
• FS-8167 [mod_lua] Fixed a segfault caused by using api:execute or session:execute and not quoting the first argument like api:execute(log, “Second argument”) instead of api:execute(“log”, “Second argument”)
• FS-8172 [mod_conference] Fixed broken admin controls in verto demo app caused by adding verto_dvar_ prefixed variables to the json status even when we have json status disabled
• FS-8173 [core] Properly respond RTP/AVPF to an AVPF offer instead of assuming its secure and responding with SAVPF
• FS-8178 [verto_communicator] Define first share device selected by default in settings modal
• FS-8078 [verto_communicator] Fixed display flex in safari
• FS-8180 [verto] Fixed an issue when disabling video on the creation of a dialog, video can still mistakenly be enabled causing some issues with the SDP still offering video
• FS-8155 [verto_communicator] Fixed issue with not detecting hangup when using uuid_kill or fsctl hupall calls
• FS-8146 [verto_communicator] Fixed display of long names in members list
• FS-8181 [verto] Fixed failed init if a camera isn’t available
• FS-8184 [mod_conference] Fixed possible memory leak when hanging up on a video call
• FS-8185 [core] Allow xml preprocessor to expand variables where the resulting value is much longer than the original size

And, this past week in the FreeSWITCH 1.4 branch we had 7 new commits merged in from master. And the FreeSWITCH 1.4.21 release is here! Go check it out!

Security Issues:

• FS-8160 Fixed head overflow in json parser, properly handle malformed json when parsing json with \u at the end of a json string. Thank you to Marcello Duarte who discovered and reported this issue.

New features that were added:

• FS-8175  Added continue_on_answer_timeout variable to allow channel to proceed from a tripped answer timeout

The following bugs were fixed:

• FS-8149 [mod_xml_cdr] Fixed curl dependency in makefile
• FS-8147 [mod_erlang_event] Fixed the process spawning segfault
• FS-8140 [mod_sofia] Fixed a user_name typo in sofia_handle_sip_i_invite
• FS-8131 [mod_voicemail] Fixed issues with allowing an empty password change and then locking out the user
• FS-1772 [mod_voicemail] Fixed the reset of voicemail greeting to default to allow entering 0 to restore the default greeting
• FS-8143 [mod_rayo] Fixed a crash caused by client disconnecting from mod_rayo while a message is being delivered to that client. This is caused by the XMPP context’s JID -> XMPP stream mapping not being cleaned up on XMPP stream destruction.

Yes and no.

Microsoft just announced officially that they have added ORTC to Edge. ORTC is… well… it’s kind’a like’a WebRTC. But not exactly.

Someone is doing his best NOT to mention WebRTC in all this…

Here are a few random thoughts I had on the subject:

• It is more about WebRTC than it is about ORTC. Even though WebRTC was mentioned only half as much as ORTC in the text and never in the title (god forbid)
• Getting “Hello World” to work on ORTC is harder than with WebRTC. Or it might just be me knowing WebRTC betther than ORTC
• It was perfectly timed to coincide with Skype’s own support for it
• Voice using Opus is a win. I wonder when we will see interoperability for a voice call between Edge and Chrome
• Video using H.264UC (=proprietary) and later H.264 with no mention of VP8 or VP9 is a loss. Not for Microsoft but for the industry
• Codecs, especially video ones, are going to cause major headaches moving forward. I wonder how web developers will swallow this sour pill
• Will developers start using H.264 instead of VP8 now that it is apparent all browsers supporting WebRTC in 2016 will have H.264, but some won’t have VP8?
• While Windows 10 is showing promise in its adoption (and aggressive push by Microsoft), the adoption of Edge is worrying. If numbers don’t increase, will it even matter if ORTC is there or which codecs Microsoft chose to incorporate?
• The whole idea of getting Microsoft onboard is to get enterprises market share for WebRTC – where no other browser than Microsoft’s can penetrate. But if Edge isn’t there – then who really cares? It may well be like testing your service runs well on Opera (I am sure you did)
• Here’s the rub though:
  • ORTC by the way isn’t a standard. It is a W3C Community Group
  • To get things into the HTML5 spec, ORTC needs to contribute their proposals to the W3C WebRTC Working Group
  • This process means that the APIs may change until it actually get standardized by W3C
  • It makes ORTC APIs less stable than those of WebRTC, and we’ve seen how people complained about the frequent changes in the browser APIs of WebRTC
  • Can Microsoft maintain this process?
• This means that the next version of Edge will have different APIs for ORTC than the current one, and that this will continue for at least a year if not longer
• Microsoft will need to release Edge at the same frequency that Google releases Chrome – every month or two
• It will also need to handle deprecation of APIs at a fast pace – can its target customers (enterprise) handle that?

All in all, another good indicator for the health of this community and real time communications in the web.

For a real analysis, read Alex’s ruminations on ORTC in Edge.

 

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

The post Do we Care about ORTC on Edge? appeared first on BlogGeek.me.

From Microsoft – http://blogs.windows.com/msedgedev/2015/09/18/ortc-api-is-now-available-in-microsoft-edge/

Our initial ORTC implementation includes the following components:

1. ORTC API Support. Our primary focus right now is audio/video communications. We have implemented the following objects: IceGatherer, IceTransport, DtlsTransport, RtpSender, RtpReceiver, as well as the RTCStatsinterfaces that are not shown directly in the diagram.
2. RTP/RTCP multiplexing is supported and is required for use with DtlsTransport. A/V multiplexing is also supported.
3. STUN/TURN/ICE support. We support STUN (RFC 5389), TURN (RFC 5766) as well as ICE (RFC 5245). Within ICE, regular nomination is supported, with aggressive nomination partially supported (as a receiver). DTLS-SRTP (RFC 5764) is supported, based on DTLS 1.0 (RFC 4347).
4. Codec support. For audio codecs, we support G.711, G.722, Opus and SILK. We also support Comfort Noise (CN) and DTMF according to the RTCWEB audio requirements. For video we currently support the H.264UC codec used by Skype services, supporting advanced features such as simulcast, scalable video coding and forward error correction. We’re working toward to enabling interoperable video with H.264.

More here..

ORTC support in Edge has been announced today. A while back, we saw this on twitter:

Windows Insider Preview build 10525 is now available for PCs: http://t.co/zeXQJocgLs This release lays groundwork for ORTC in Microsoft Edge

— Microsoft Edge Dev (@MSEdgeDev) August 18, 2015

“This release [build 10525] lays the groundwork for ORTC” was quite an understatement. It was considered experimental and while the implementation still differs from the specification (which is still work in progress) slightly, it already worked and as a developer you can get familiar with how ORTC works and how it is different from the RTCPeerConnection API.
If you want to test this, please use builds newer than 10547. Join the Windows Insider Program to get them and make sure you’re on the fast ring.

The approach taken differs from the RTCPeerConnection way of giving you a blob that you exchange as this WebRTC PC1 sample shows quite well. It’s more about giving you the building blocks.

In ORTC, you have to incrementally build up things. Let’s walk through the code (available on github):

Setting up a Peer to Peer connection

var gatherer1 = new RTCIceGatherer(iceOptions); var transport1 = new RTCIceTransport(gatherer1); var dtls1 = new RTCDtlsTransport(transport1);

There are three elements on the transport side:
* the RTCIceGatherer which gathers ICE candidates to be sent to the peer,
* the RTCIceTransport where you add the candidates from the peer,
* the DtlsTransport which is sitting on top of the ICE transport and deals with encryption.

As in the peerConnection API, you exchange the candidates:

// Exchange ICE candidates. gatherer1.onlocalcandidate = function (evt) { console.log('1 -> 2', evt.candidate); transport2.addRemoteCandidate(evt.candidate); }; gatherer2.onlocalcandidate = function (evt) { console.log('2 -> 1', evt.candidate); transport1.addRemoteCandidate(evt.candidate); };

Also, you need to exchange the ICE parameters (usernameFragment and password) and start the ICE transport:

transport1.start(gatherer1, gatherer2.getLocalParameters(), 'controlling'); transport1.onicestatechange = function() { console.log('ICE transport 1 state change', transport1.state); };

This is done with SDP in the PeerConnection API. One side needs to be controlling, the other is controlled.

You also need to start the DTLS transport with the remote fingerprint and hash algorithm:

dtls1.start(dtls2.getLocalParameters()); dtls1.ondtlsstatechange = function() { console.log('DTLS transport 1 state change', dtls1.state); };

Once this is done, you can see the candidates being exchanged and the ICE and DTLS state changes on both sides.

Cool. Now what?

Sending a MediaStream track over the connection

Let’s send a MediaStream track. First, we acquire it using the promise-based navigator.mediaDevices.getUserMedia API and attach it to the local video element.

// call getUserMedia to get a MediaStream. navigator.mediaDevices.getUserMedia({video: true}) .then(function(stream) { document.getElementById('localVideo').srcObject = stream;

Next, we determine the send and receive parameters. This is where the PeerConnection API does the “offer/answer” magic.
Since our sending capabilities match the receiving capabilities, there is little we need to do here.
Some black magic is still involved, check the specification for the gory details.

// Determine RtpCodecParameters. Consider this black magic. var params = RTCRtpReceiver.getCapabilities('video'); params.muxId = 1001; params.encodings = [{ ssrc: 1001, codecPayloadType: 0, fec: 0, rtx: 0, priority: 1.0, maxBitrate: 2000000.0, minQuality: 0, framerateBias: 0.5, resolutionScale: 1.0, framerateScale: 1.0, active: true, dependencyEncodingId: undefined, encodingId: undefined }]; // We need to transform the codec capability into a codec. params.codecs.forEach(function (codec) { codec.payloadType = codec.preferredPayloadType; }); params.rtcp = { cname: "", reducedSize: false, ssrc: 0, mux: true }; console.log(params);

Then, we start the RtpReceiver with those parameters:

// Start the RtpReceiver to receive the track. receiver = new RTCRtpReceiver(dtls2, 'video'); receiver.receive(params); var remoteStream = new MediaStream(); remoteStream.addTrack(receiver.track); document.getElementById('remoteVideo').srcObject = remoteStream;

Note that the Edge implementation is slightly different from the current ORTC specification here since you need to specify the media type as second argument when creating the RtpReceiver.
We create a stream to contain the track and attach it to the remote video element.
Last but not least, let’s send the video track we got:

sender = new RTCRtpSender(stream.getVideoTracks()[0], dtls1); sender.send(params);

That’s it. It gets slightly more complicated when you have to deal with multiple tracks, and have to actually negotiate capabilities in order to interop between Chrome and Edge. But that’s a longer story…

{“author”: “Philipp Hancke“}

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 First steps with ORTC appeared first on webrtcHacks.

Time for another Astricon, the Asterisk Users Conference, is approaching.Kamailio project will be present at the event, with an exhibition booth as well as talks about SIP, Kamailio and Asterisk, by Fred Posner and I. Many other developers and community members will be at the event, such as Torrey Searle, Alex Balashov, Nir Simionovich or JR Richardson, therefore it looks like a great place to come and meet other Kamailians.Astricon is the event where a lot of Asterisk and Kamailio knowledge is concentrated in the same place, if you need to learn more about one or the other and how to combine them, then this event is the right opportunity. More about the event can be found at:

• http://www.asterisk.org/community/astricon-user-conference

If you offer services or products that incorporate Kamailio, you are welcome to join our booth in the exhibition area, you can bring flyers, giveaways as well as come with a demo to show on site. Contact us via mailing list .

Kamailio project is present at IIT RTC Conference, Oct 6-8, 2015, in Chicago, with a presentation by myself about SIP Server Optimizations for Mobile Networks.We have a discount code for our community, giving an 100USD discount, which can save a bit or make some of the available tickets completely free (like Expo Plus admission). Should someone be interested, contact directly via email.More details about the event can be found at:

• http://www.rtc-conference.com/

If Kamailio friends are in the Chicago area and want to meet and chat about the project, no matter of participation to the conference, write an email at the above address and we can try to organize a meetup.

There are a few side stories around Apple lately that relate to WebRTC. I wanted to share them here.

Apple TV ships with no HTML5 support

It seems that in the Apple TV reboot, there are going to be apps. But not ones that can make use of HTML5. Just native apps. John Gruber points to a post around that topic titled Everything but the Web, concluding that Web views won’t find their way to the TV screen if Apple has anything to do with it.

He doesn’t state the reason though. If you ask me, this has nothing to do to the Apple/Flash war of the past. It also has nothing to do with design or aesthetics. It has anything to do with ecosystem control. For Apple, the ability of cross platform development is an aberration. Why on earth enable developers to write their code once and then run it elsewhere? There’s nothing outside the closed garden of Apple, so why bother?

Killing HTML5 in Mac is impossible. Killing it on the iPhone or iPad is also rather hard – too many apps already use it, and there’s that pesky browser people use. But on the TV? That’s greenfield! So why not just forget about HTML5 altogether?

If you ask me, the good people in Apple see only one reason for HTML5 to exist – and that is for people to be able to go to apple.com website. Other than that? Useless.

The future of WebKit

There have been a lot of back and forth lately about the future of the web. Should we run full steam ahead with it or sit and wait. People prefer having it change and progress less. I can’t see why – when every year thousands of new APIs are rained at us by Apple and WWDC and Google at I/O – why can’t the Web improve? Why should it stay static?

WebKit, on the other had, is a rather dead rendering engine at this point in time. It might be fast and optimized, but it is becoming a bit old when it comes to adopting and supporting standards. WebRTC isn’t there, but multiple other technologies aren’t either. It seems to be keeping up with the HTML5 and CSS notation, but the programmatic parts of JavaScript? Falling behind the other browsers.

I’ve written before on how Microsoft Edge is getting way better. Mozilla is getting their act together and modernizing the older parts of their Firefox browser (extensions for example) and Google are speeding up and optimizing Chrome now that it has become huge. But Safari? Microsoft Edge will keep Google and Mozilla on edge and get them to improve. I don’t think the other browser vendors care too much about Safari getting too good anytime soon.

I wonder how much care and affection the Safari/WebKit team gets inside Apple these days. Probably not that much.

This goes somewhat counter intuitive to the positive assertions Alex made here about Apple and WebRTC.

H.265 / VP9

Apple and H.265 take center stage in my video codec sessions lately. You can see the video codec wars session I gave at TokBox last week.

My usual spiel?

• Apple is a part of MPEG-LA
• Apple owns H.265 related patents. It may well wish to enforce them to make it difficult on others
• Apple builds hardware, so changing a video codec isn’t an easy feat – it requires time and getting old hardware off the market
• Apple has H.265 running on FaceTime in iPhone 5
• So Apple is on the H.265 camp

But then I get directed to this interesting post in 9to5Mac:

Another interesting detail: 4K videos are being recorded in H.264, and Apple is no longer making reference to H.265 support for any purpose, FaceTime or otherwise

Hmm…

Is it only me or did Apple just drop H.265 support and is shifting camps? Or at the very least, sitting on the fence. It might have something to do with the HEVC Advance stupidity that brought the gang to open up the Alliance of Open Media. They might be edging away from royalty bearing codecs and moving to the free alternative. Or they might try using it as leverage over HEVC Advance to make their licensing terms more palatable.

How do you do 4K video resolutions with a camera if not by using H.265? Use H.264? Ridiculous. But that’s exactly what seems to be happening now for the new iPhone 6.

Should they be moving to VP9 instead? Probably, but it will be hard on Apple. They rely heavily on hardware acceleration and they don’t seem to have it on their chipsets at the moment.

This is a loss to the H.26x camp at the moment.

–

Where is this all headed?

I am not sure, but here are a couple of things I’d plan if I had that task given to me.

• Rely on native development on mobile. Especially when it comes to anything Apple
• Use HTML5 for browser development. Wrap it using Chrome Embedded Framework if a standalone desktop app is needed
• Tread carefully in what I end up using on for my video codec. No simple answers there

 

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

The post Thoughts on Apple, WebRTC, HTML5, H.265 and VP9 appeared first on BlogGeek.me.

Kazoo project organizes its annual conference in San Francisco, USA, during October 5-6, 2015. Kazoo platform embeds Kamailio as its core SIP routing engine, a module with same name, kazoo, being part of Kamailio’s standard source code.Expect many people from Kamailio community to be there, a lot of talks should present interesting use cases for Kamailio for running cloud PBX service from Kazoo developers and Kazoo users. Also, I will speak about VoIP security: Kamailio and VoIP Wild World.More details about the event can be found at:

• http://www.kazoo.com

It turns out people like their smartphone apps, so that native mobile is pretty important. For WebRTC that usually leads to venturing outside of JavaScript into the world of C++/Swift for iOS and Java for Android. You can try hybrid applications (see our post on this), but many modern web apps applications often use JavaScript frameworks like AngularJS, Backbone.js, Ember.js, or others and those don’t always mesh well with these hybrid app environments.

Can you have it all? Facebook is trying with React which includes the ReactJS framework and  React Native for iOS and now Android too. There has been a lot of positive fanfare with this new framework, but will it help WebRTC developers? To find out I asked VoxImplant’s Alexey Aylarov to give us a walkthrough of using React Native for a native iOS app with WebRTC.

{“editor”: “chad hart“}

If you haven’t heard about ReactJS or React Native then I can recommend to check them out. They already have a big influence on a web development and started having influence on mobile app development with React Native release for iOS and an Android version just released. It sounds familiar, doesn’t it? We’ve heard the same about WebRTC, since it changes the way web and mobile developers implement real-time communication in their apps. So what is React Native after all?

“React Native enables you to build world-class application experiences on native platforms using a consistent developer experience based on JavaScript and React. The focus of React Native is on developer efficiency across all the platforms you care about — learn once, write anywhere. Facebook uses React Native in multiple production apps and will continue investing in React Native.”
https://facebook.github.io/react-native/

I can simplify it to “one of the best ways for web/javascript developers to build native mobile apps, using familiar tools like Javascript, NodeJS, etc.”. If you are connected to WebRTC world (like me) the first idea that comes to your mind when you play with React Native is “adding WebRTC there should be a big thing, how can I make it?” and then from React Native documentation you’ll find out that there is a way to create your own Native Modules:

Sometimes an app needs access to platform API, and React Native doesn’t have a corresponding module yet. Maybe you want to reuse some existing Objective-C, Swift or C++ code without having to reimplement it in JavaScript, or write some high performance, multi-threaded code such as for image processing, a database, or any number of advanced extensions.

That’s exactly what we needed! Our WebRTC module in this case is a low-level library that provides high-level Javascript API for React Native developers. Another good thing about React Native is that it’s an open source framework and you can find a lot of required info on GitHub. It’s very useful, since React Native is still very young and it’s not easy to find the details about native module development. You can always reach out to folks using Twitter (yes, it works! Look for #reactnative or https://twitter.com/Vjeux) or join their IRC channel to ask your questions, but checking examples from GitHub is a good option.

React Native’s module architecture

Native modules can have C/C++ , Objective-C, and Javascript code. This means you can put the native WebRTC libraries, signaling and some other libs written in C/C++ as a low-level part of your module, implement video element rendering in Objective-C and offer Javascript/JSX API for react native developers.

Technically low-level and high-level code is divided in the following way:

1. you create Objective-C class that extends React’s RCTBridgeModule class and
2. use RCT_EXPORT_METHOD to let Javascript code work with it.

While in Objective-C you can interact with the OS, C/C++ libs and even create iOS widgets. The Ready-to-use native module(s) can be distributed in number of different ways, the easiest one being via a npm package.

WebRTC module API

We’ve been implementing a React Native module for our own platform and already knew which of our API functions we would provide to Javascript. Creating a WebRTC module that is independent of signaling that can be used by any WebRTC developer is a much more complicated problem.

We can divide the process into few parts:

Integration with WebRTC

Since webRTC does not limit developers how to discover user names and network connection information, this signaling can be done in multiple ways. Google’s WebRTC implementation known as libwebrtc. libwebrtc has a built-in library called libjingle that provides “signaling” functionality.

There are 3 ways how libwebrtc can be used to establish a communication:

1. libjingle with built-in signaling

This is the simplest one leveraging libjingle. In this case signaling is implemented in libjingle via XMPP protocol.

2. Your own signaling

This is a more complicated one with signaling on the application side. In this case you need to implement SDP and ICE candidates exchange and pass data to webrtc. One of popular methods is to use some SIP library for signaling.

3. Application-controlled RTC

For the hardcore you can avoid using signaling altogether This means the application should take care of all RTP session params: RTP/RTCP ports, audio/video codecs, codec params, etc. Example of this type of integration can be found in WebRTC sources in WebRTCDemo app for Objective-C (src/talk/app/webrtc)

Adding Signaling

We used the 2nd approach in our implementation. Here are some code examples for making/receiving calls (C++):

1. First of all, create Peer Connection factory:
   peerConnectionFactory = webrtc::CreatePeerConnectionFactory(…);
2. Then creating local stream (we can set if it will be voice or video call):
   localStream =  peerConnectionFactory->CreateLocalMediaStream(uniqueLabel); localStream->AddTrack(audioTrack);     if (withVideo)        localStream->AddTrack(videoTrack);
3. Creating PeerConnection (set STUN/TURN servers list, if you are going to use it)
   webrtc::PeerConnectionInterface::IceServers servers; webrtc::CreateSessionDescriptionObserver* peerConnectionObserver; peerConnection = peerConnectionFactory ->CreatePeerConnection(servers, …., peerConnectionObserver);
4. Adding local stream to Peer Connection:
   peerConnection->AddStream(localStream);
5. Creating SDP:
   webrtc::CreateSessionDescriptionObserver* sdpObserver;
   1. For outbound call:
      1. Creating SDP:
         peerConnection->CreateOffer(sdpObserver);
      2. Waiting for SDP from remote peer (via signaling) and pass it to Peer Connection:
         peerConnection->SetRemoteDescription(remoteSDP);
   2. In case of inbound call we need to set remote SDP before setting local SDP:
      peerConnection->SetRemoteDescription(remoteSDP); peerConnection->CreateAnswer(sdpObserver);
6. Waiting for events and sending SDP and ICE-candidate info to remote party (via signaling):
   webrtc::CreateSessionDescriptionObserver::OnSuccess(webrtc::SessionDescriptionInterface* desc) { if (this->outgoing) sendOffer();         else         sendAnswer(); } webrtc::CreateSessionDescriptionObserver::OnIceCandidate(const webrtc::IceCandidateInterface* candidate)  {         sendIceCandidateInfo(candidate); }
7. Waiting for ICE candidates info from remote peer  and when it arrives pass it to Peer Connection:
   peerConnection->AddIceCandidate(candidate);
8. After a successful ICE exchange (if everything is ok) connection/call is established.

Integration with React Native

First of all we need to create react-native module (https://facebook.github.io/react-native/docs/native-modules-ios.html) , where we describe the API and implement audio/video calling using WebRTC (Obj-C , iOS):

@interface YourVoipModule () { } @end @implementation YourVoipModule RCT_EXPORT_MODULE(); RCT_EXPORT_METHOD(createCall: (NSString *) to withVideo: (BOOL) video ResponseCallback: (RCTResponseSenderBlock)callback) { NSString * callId = [createVoipCall: to withVideo:video]; callback(@[callId]); }

If want to to support video calling we will need an additional component to show the local camera (Preview) or remote video stream (RemoteView):

@interface YourRendererView : RCTView @end

Initialization and deinitialization can be implemented in the following methods:

- (void)removeFromSuperview {         [videoTrack removeRenderer:self];         [super removeFromSuperview]; } - (void)didMoveToSuperview {         [super didMoveToSuperview];         [videoTrack addRenderer:self]; }

You can find the code examples on our GitHub page – just swap the references to our signaling with your own. We found examples very useful while developing the module, so hopefully they will help you to understand the whole idea much faster.

Demo

The end result can look like as follows:

Closing Thoughts

When WebRTC community started working on the standard one of the main ideas was to make real-time communications simpler for web developers and provide developers with a convenient Javascript API for real time communications. React Native has similar goal, it lets web developers build native apps using Javascript. In our opinion bringing WebRTC to the set of available React Native APIs makes a lot of sense – web app developers will be able to build their RTC apps for mobile platforms. Guys behind React Native has just released it for Android at Scale conference, so we will update the article or write a new one about building the module compatible with Android as soon as we know all the details.

{“author”, “Alexey Aylarov”}

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 Reacting to React Native for native WebRTC apps (Alexey Aylarov) appeared first on webrtcHacks.

Elastix World 2015 takes place in Bogota, Colombia, during October 7-8, 2015. Kamailio is part of Elastix Multi Tenant (Elastix MT) distribution, therefore expect to meet many community members there.Long time community member the Kamailio Debian packager in the past, Jon Bonilla will have a talk about Scaling and load balancing SIP systems.For more details about the event, visit:

• http://www.elastixworld.com/

Hello, again. This past week in the FreeSWITCH master branch we had 35 commits. This week we had one feature: the handling of  a=sendonly, a=sendrecv, a=recvonly to change who is sending video during a call.

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-8053 Handle a=sendonly, a=sendrecv, a=recvonly to change who is sending video during a call

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

• FS-7168 [Debian] Update packages so that FS core libraries are setup as runtime dependencies
• FS-7697 Chown the /etc/freeswitch/tls directory so that the freeswitch user can have read/write for TLS certificate generation
• FS-7966 [Windows] Explore use of nuget for wix build dependency
• FS-7967 [build] SmartOS compatibility
• FS-1772 [mod_voicemail] Fixed a build error
• FS-8072 [Debian] Fixed a missed space

The following bugs were squashed:

• FS-8130  Port video buffer to also support audio and remove original STFU jitter buffer, add some more resilience to video packet loss, add codec control mechanism for both call-specific debug and codec/call specific parameters, make opus function better in packet loss and latent situations, use new codec control prams to make jitter buffer lookahead FEC optionally enabled or disabled mid-call, and add a parameter to allow jitter buffer lookahead to be enabled.
• FS-8131 [mod_voicemail] Fixed issues with allowing an empty password change and then locking out the user
• FS-8136 [mod_h26x] Do not load passthru video codecs by default
• FS-8140 [mod_sofia] Fixed a user_name typo in sofia_handle_sip_i_invite
• FS-8142 Fixed  a thread cache thread-safety and caching
• FS-8075 [mod_hiredis] Fix for failover when you pull power on redis, while redis clients under load test
• FS-8144 [mod_opus] Readability and code formatting cleanup
• FS-8126 [switch_core] Fixed the pruning of a media bug causing all media bugs on a session to be pruned
• FS-8143 [mod_rayo] Fixed a crash caused by client disconnecting from mod_rayo while a message is being delivered to that client. This is caused by the XMPP context’s JID -> XMPP stream mapping not being cleaned up on XMPP stream destruction.
• FS-8147 [event_handlers] Fixed the process spawning segfault
• FS-8149 [mod_xml_cdr] Fixed curl dependency in makefile

 

And, this past week in the FreeSWITCH 1.4 branch we had 9 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-8143 [mod_rayo] Fixed a crash caused by client disconnecting from mod_rayo while a message is being delivered to that client. This is caused by the XMPP context’s JID -> XMPP stream mapping not being cleaned up on XMPP stream destruction.
• FS-8127 [mod_conference] Fixed an audio issue caused by the codec not updating often enough when detecting rate change
• FS-8099 [mod_lua] Restored LUA dialplan ACTIONS functionality
• FS-8142 Fixed thread cache thread-safety and caching

We’re slightly more than 20 days away from KazooCon 2015 and we want you here to see the power and scalability of our new VoIP platform firsthand. So if you are still on the fence on attending, we’re revealing the top ten reasons why you need to attend the Unified Communications Revolution. Early-bird pricing ends on Sunday, September 20th, so register now and save money. So what are you waiting for, go to www.KazooCon.com and register. 

Number 10 - Demo’s, Demo’s, 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 will be hosting five hands-on demos (hint: bring your laptop). You will get a first-hand look of the of our new Kazoo API’s and our Engineering team 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; and
• Debugging using Packet Captures, Wireshark and NAT.

Number 9 - Amazing Guest Speakers
Our staff is poised to give outstanding presentations, and we have been prepping demos for weeks. But we’re not the only ones going to be on the podium this week. 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 more. We have C-Level speakers from Mast Mobile, Orange, Kamailio, FreeSWITCH, VirtualPBX, IBM Cloudant, Telnexus and SIPLABS. You don’t want to miss it!

Number 8 - Let’s make it a week in San Francisco
Join us for our official Kazoo Training directly following KazooCon from October 7-9. This three-day training will teach you about Kazoo and all of the third-party components that power the platform. You will deep-dive into Kazoo APIs, and learn how to set up a cluster, GUI, WhApps, FreeSWITCH, BigCouch and much more. Purchase both an Early-Bird KazooCon + Kazoo Training ticket and save money! Register Here!

Number 7 - The After-Party
No conference is complete without an after-party. Join us this year for some spirited libations and telco networking. If you attended last year, you bore witness to our alcohol-fueled Scrabble, Pictionary, and arcade games. Last year our Lead Designer Josh was undefeated at Mario Kart, so we’re all practicing to take him down this year. We’ve got plenty of fun and collaborative events planned for this year’s party, but we’re not spoiling the surprise.

Stay tuned as we count down to Number 1. But Register Now at www.KazooCon.com

Kamailio SIP Server v4.3.2 stable is out – a minor release including fixes in code and documentation since v4.3.1 – configuration file and database compatibility is preserved.Kamailio (former OpenSER) v4.3.2 is based on the latest version of GIT branch 4.3, therefore those running previous 4.3.x versions are advised to upgrade. There is no change that has to be done to configuration file or database structure comparing with older v4.3.x.Resources for Kamailio version 4.3.2Source tarballs are available at:

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

Detailed changelog:

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

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

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

Modules’ documentation:

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

What is new in 4.3.x release series is summarized in the announcement of v4.3.0:

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

No comments »

isVisible=false; function show_hide_searchbox(w){ if(isVisible){ document.getElementById('filterBoxSelection').style.display = 'none'; w.innerText='Filter ▼'; }else{ document.getElementById('filterBoxSelection').style.display = 'block'; w.innerText='Filter ▲'; } isVisible=!isVisible; } function checkIfSelected(chk){ if(chk.checked==1) chk.parentNode.className = "selected"; else chk.parentNode.className = "notselected"; getSelectedValues(); } function getSelectedValues(){ var a=document.getElementsByClassName('selected'); var vtVal=[] , ctVal=[] , ftVal=[]; var ct=0,vt=0,ft=0; for (x = 0; x < a.length; ++x) { try{ if(a[x].getElementsByTagName('input')[0].className=='companyType'){ ctVal[ct]= a[x].getElementsByTagName('input')[0].value; ct++; } if(a[x].getElementsByTagName('input')[0].className=='vendorType'){ vtVal[vt]= a[x].getElementsByTagName('input')[0].value; vt++; } if(a[x].getElementsByTagName('input')[0].className=='focusType'){ ftVal[ft]= a[x].getElementsByTagName('input')[0].value; ft++; } }catch(err){ } } search_VType(vtVal); search_CType(ctVal); search_FType(ftVal); } function search_VType(val){ var a=document.getElementsByClassName('interview-block'); for(x=0;x=0 && val[i]!=null){ a[x].style.display='block'; } } if(val.length==0){ a[x].style.display='block'; } } } function search_CType(val){ var a=document.getElementsByClassName('interview-block'); for(x=0;x=0 && val[i]!=null && a[x].style.display=='block'){ break; } if(i==val.length-1){ a[x].style.display='none'; } } } } function search_FType(val){ var a=document.getElementsByClassName('interview-block'); for(x=0;x=0 && val[i]!=null && a[x].style.display=='block'){ break; } if(i==val.length-1){ a[x].style.display='none'; } } } } Check out all webRTC interviews >>

Tellybean: Cami Hongell

September 2015

WebRTC in the big screen

Video Conf

Small

Voice, Video

WebRTC on the large screen.

[If you are new around here, then you should know I’ve been writing about WebRTC lately. You can skim through the WebRTC post series or just read what WebRTC is all about.]

I am not a fan of video calling in the living room. Not because I have real issues with it, but because I think it is a steep mountain to climb – I am more of the low-hanging-fruit kind of a guy.

That’s not the case with Tellybean, a company focused on TV video calling and recently doing that using WebRTC.

Cami Hongell, CEO of Tellybean, found the time to chat with me and answer a few questions about what they are doing and the challenges they are facing.
What is Tellybean all about?

Tellybean is all about easy video calling on the TV. My two co-founders are Aussies living in Finland and they had a problem. A software update or a forgotten password too often got in the way of their weekly Skype call with grandma Down Under. Once audio and video were finally working both ways, there were four people fighting for a spot in front of the 13” screen.

We realised that modern life tends to separate families and our problem was far from unique. That’s when we decided to build an easy video calling service for the TV. It had to be so easy that even grandma could use it from the comfort of her couch. At the same time as we worked hard to eliminate complexity, we also needed to keep it affordable and build a channel which would provide users an easy way of getting the service.

Today we have an app which allows easy video calls on Android TV devices of our TV and set-top box partners. Currently you can make calls between selected Tellybean enabled Android TV devices and our web app on www.tellybean.com. To make it as easy as possible to call somebody from your TV, we will release apps for Android and iOS mobiles and tablets in the future.

 

 You started by building your TV solution using Skype. What made you switch to WebRTC?

When we founded Tellybean four years ago the tech landscape looked very different from today. WebRTC wasn’t there. Android TV and Tizen weren’t there – the TV operating systems were all over the place. So initially we set out to build an easy service which would run on our own dedicated Linux box. Our intention was to allow our service to connect with other existing services by putting our own UI on top of headless clients developed using the SDK’s provided by some of the existing services. We started with SkypeKit and had a first version of it ready a few years ago. We were going to continue by adding Gtalk.

However, Skype decided to wind down the support of 3rd party developers and Google stopped Gtalk development. This happened almost at the same time as WebRTC was starting to gain traction. Switching to WebRTC turned out to be an easy decision once we looked into it and moved over to working on Android and 3rd party hardware only.

 

What excites you about working in WebRTC?

Having tried different VoIP platforms in the past, we have learned to appreciate the fact that working with WebRTC has allowed us to focus our  resources on the more important UX and UI development. Since WebRTC offers a plugin-free and no-download alternative for video calling with modern browsers, combined with our TV and upcoming mobile device approach we are able to provide easy use for a huge audience, with almost all entry barriers removed.

We are excited about having a great service which is getting a lot of interest from everybody in the Android TV value chain from the chip manufacturers to the TV and STB manufacturers as well as the operators. We’ve announced co-operation with TP Vision / Philips TVs and Nvidia and much more in the pipeline. The great support and resources available in the WebRTC community, coupled with the support from the hardware manufacturers means that  WebRTC is truly becoming a compelling open source alternative for service developers, such as ourselves.

 

Can you tell me a bit about the challenges of getting WebRTC to operate properly in an embedded environment fit for the TV?

An overall problem has been that we are moving slightly ahead of the curve.

Firstly, we need access to a regular USB camera. Unfortunately the Android TV platform and most devices lack UVC camera support. So we have been pushing everybody, Google, the device manufacturers and the chip suppliers, to add camera support. The powerful Nvidia Shield Console has camera support and we already have a few of the other major players implementing it for us.

Secondly, there are still devices that are underpowered and/or lack support for VP8 HW encoding, meaning that it is hard for us to provide a satisfactory call quality. Luckily again, most of the devices launched this year can handle video calling and our app.

The third problem relates to fine tuning the audio for our use case where the distance between the USB camera’s mic and the TV’s speakers is not a constant. Third time lucky: WebRTC provides us pretty good echo cancellation and other tools to optimize this and produce good audio quality.

 

What signaling have you decided to integrate on top of WebRTC?

Wanting to support browsers for user convenience and to get going quickly, we started out building our own solution with Socket I/O, but we are transitioning to MQTT for two reasons. Firstly, we came to the conclusion that MQTT provided us much more efficient scalability. Secondly, MQTT is much easier on the battery for mobile devices.

Current implementations of MQTT also allow us to use websockets for persistent connections in browsers, so it suits our purposes well. Additionally, some transaction-like functionality is done using REST. We are writing our own custom protocol as we go, which allows us to grow the service organically instead of trying to match a specification set forth by another party that doesn’t match our requirements or introduces undue complexity in architecture or implementation.

 

Backend. What technologies and architecture are you using there?

We have server instances on Amazon Web Services, running our MQTT brokers and REST API, as well as the TURN/STUN service required for WebRTC. We use Node.JS on the servers and MongoDB from a cloud service which allows us easy distributed access to shared data.

 

Where do you see WebRTC going in 2-5 years?

The recent inclusion of H.264 will lead to broader adoption of WebRTC in online services, and also in dedicated hardware devices since H.264 decoders are readily available. Microsoft is also starting to adopt WebRTC in their new Edge browser, so it seems like there’s a bright future for rich communication using WebRTC once all the players have started moving. Like everybody else, we would naturally like full WebRTC support from Microsoft and Apple sooner rather than later, and it will be hard for them to ignore it with all the support it is already receiving. In this timeframe, at least high-end mobile devices should have powerful enough hardware to support WebRTC in the native browsers without issues. With this kind of background infrastructure a lot of online services will be starting to use WebRTC in some form, instead of more isolated projects. With everyone moving towards a new infrastructure, hopefully any interoperability issues between different endpoints have been sorted out, which allows service developers to focus on their core ideas.

 

If you had one piece of advice for those thinking of adopting WebRTC, what would it be?

WebRTC is still an emerging technology, that will surely have an impact for developers and businesses going forward, but it’s not completely mature yet. We’ve seen a lot of good development over time, so for a specific use case, it might be a plug-and-play experience or then in a more advanced case you may need a lot of development work.

 

Given the opportunity, what would you change in WebRTC?

WebRTC has been improving a lot during the time that we’ve worked with it, so we believe that current issues will be improved on and disappear over time. The big issue right now on the browser side is obviously adoption, with Microsoft and especially Apple not up to speed yet. We would also like to see good support for all WebRTC codecs from involved parties, to avoid transcoding and to be able to use existing hardware components for a great user experience.

 

What’s next for Tellybean?

We’ve recently launched our Android TV app and are seeing the first users on the Nvidia Shield console, the first compatible device. We are now learning a lot and have a chance to fine tune our app. From a business point of view we currently have full focus on building a partner network which will provide us the platform for 100+ million TV installations in the coming years. Next we are starting development of mobile apps for Android and iOS. Later we will need to decide if moving to other TV operating systems or e.g. enabling other video calling services to connect to Tellybean TVs will be the next most important step towards achieving our aim of becoming THE video calling solution for the TV.

–

The interviews are intended to give different viewpoints than my own – you can read more WebRTC interviews.

The post Tellybean and WebRTC: An Interview With Cami Hongell appeared first on BlogGeek.me.

Hello, again. This past week in the FreeSWITCH master branch we had 75 commits! The new features for this week include: improvements to the verto communicator, allowing Freeswitch to initiate late offer calls, the addition of CUSTOM esl events menu::enter and menu::exit when a call enter and exit an ivr menu, and more work toward the new module, 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-8094 [verto_communicator] Added googEchoCancellation, googNoiseSuppression, and googHighpassFilter settings to the UI enabled by default
• FS-8107 [switch_ivr_menu] Adding CUSTOM esl events menu::enter and menu::exit when a call enter and exit an ivr menu
• FS-6833 Allow Freeswitch to initiate late offer calls
• FS-8075 [mod_hiredis] Add conf file to spec file too and updates for limit release case

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

• FS-7966 [Windows] Build now uses visual studio 2015 and builds successfully, but is still missing video functionality
• FS-8124 [verto_communicator] Adding option –debug to grunt build, dist app will be generated without minified code.

The following bugs were squashed:

• FS-8099 [mod_lua] Restored LUA dialplan ACTIONS functionality
• FS-7988 [filebug.pl] Moved -askall to -terse so old -askall behavior is default and old default is now -terse
• FS-8029 [jitterbuffer] Fixed robotic sound when using jitterbuffer
• FS-8103 [mod_rayo] Fixed handling of malformed requests
• FS-8108 [mod_lua] Removed legacy mod_lua, the regular mod_lua works with system lua now
• FS-8082 [mod_rayo] Fixed a segfault
• FS-8110 [mod_rayo] Prompt IQ error reply was being deleted after being sent for delivery. This is incorrect since message delivery thread will clean up the message
• FS-8116 [verto] Fixed device enumeration hanging on init
• FS-8118 [verto] Fixed calls not properly rejecting video when video is offered but only audio is accepted
• FS-7994 [verto_communicator] Using factory for group calls in history
• FS-8117 [verto_communicator] Calling verto.iceServers upon useSTUN changing on ModalSettings, correctly check for STUN setting in localStorage, and fixed ignoring useSTUN settings
• FS-8127 [mod_conference] Fixed an audio issue caused by the codec not updating often enough when detecting rate change
• FS-8088 [verto_communicator] Fixed members list being destroyed after switching conferences and ending the first conference

 

And, this past week in the FreeSWITCH 1.4 branch we had 9 new commits merged in from master. And the FreeSWITCH 1.4.21 release is here! Go check it out!

New features that were added:

• FS-7752 [mod_rayo] Increase maximum number of elements from 30 to 1024 to allow adhearsion to create large grammars to navigate IVR menus.

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

• FS-8055 [build] Add confdir variable to freeswitch.pc

The following bugs were fixed:

• 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-7903 [proxy_media] Fix Codec PROXY Exists but not at the desired implementation. 0hz 0ms 1ch error when using proxy media.
• FS-8056 [mod_voicemail] Fixed a segfault on vm_inject, regression from FS-7968
• FS-7968 [mod_voicemail] Fixed verbose events
• FS-8110 [mod_rayo] Prompt IQ error reply was being deleted after being sent for delivery. This is incorrect since message delivery thread will clean up the message
• FS-8082 [mod_rayo] Do not remove items from hash while iterating
• FS-8103 [mod_rayo] Handle where finishes unexpectedly before start event is received

The FreeSWITCH 1.6.0 release is here! This is the release of the Video/MCU branch!

Release files are located here:

• Tarball: http://files.freeswitch.org/releases/freeswitch/freeswitch-1.6.0.tar.gz
• Packaging: https://freeswitch.org/confluence/display/FREESWITCH/Installation (Please Note the updated location for 1.6 packages)

And we’re dropping support in packaging for anything older than Debian 8.0 and anything older than Centos 7.0 due to a number of dependency issues on older platforms.

New features that were added:

• FS-7337 [mod_sofia] Add support for Remote-Party-ID header in UPDATE request.
• FS-7561 [mod_sofia] Add Perfect Forward Secrecy (DHE PFS)
• FS-7560 [mod_nibblebill] Added new options to nibble bill for minimum charges and rounding
• FS-7587 FS-7602 FS-7499 [mod_verto] Add ipv6 support to Verto / Websockets and additional support ice/dtls ipv6 functionality
• FS-6801 [mod_sofia] Add sip_watched_headers variable to launch events when a SIP message contains a given SIP header
• FS-7564 [mod_rayo] Added new algorithms for offering calls to clients
• FS-7436 FS-7601 [mod_opus] Added FEC support
• FS-7603 [mod_event_socket] Failover for socket application in dialplan
• FS-7585 [mod_rtmp] Increased AMF buffer for larger video and add bandwidth settings to flash video
• FS-7311 [mod_sofia] Updating display name is disabled when caller_id equal “_undef_”
• FS-7513 [mod_conference] Add video-auto-floor-msec param to control how long a member must have the audio floor before also taking the video floor and make sure user does not have auto avatar when not visible
• FS-7620 [ftmod_libpri] Correctly set calling number presentation and screening fields
• FS-7138 [mod_callcenter] Added a new reserve-agents param
• FS-7436 FS-7601 [mod_opus] FEC support
• FS-7623 [mod_amqp] Allow for custom exchange name and type for producers and fixed param name ordering bug caused by exposing these params
• FS-7638 Allow ipv4 mapped ipv6 address to pass ipv4 ACLs properly
• FS-7643 [mod_opus] Added interpretation of maxplaybackrate and sprop-maxcapturerate
• FS-7641 Added video support to eavesdrop
• FS-7656 [mod_localstream] Added mod_local_stream video support, and make mod_conference move the video in and out of a layer when the stream has video or not, scan for relative file in art/eg.wav.png and display it as video when playing audio files, put video banner up if artist or title is set, and fixed a/v sync on first connection
• FS-7629 [mod_conference] Added member status in json format to the conference live array, add livearray-json-status to conference-flags to enable
• FS-7517 FS-7519 [mod_av] [mod_openh264] Added H264 STAP-A packeting support so it would work with FireFox
• FS-7664 [mod_verto] Set ICE candidate timeout to wait for only 1 second to fix media delays
• FS-7660 [mod_opus] Enabled with new API command “opus_debug” to show information about Opus payload for debugging.
• FS-7519 [mod_av] Fixed bitrate and added some presets
• FS-7693 [mod_conference] Lower the default energy level in sample configs to improve voice quality
• FS-7720 Improve play_and_detect_speech to set current_application_response channel variable as follows: “USAGE ERROR”: bad application arguments’, “GRAMMAR ERROR”: speech recognizer failed to load grammar, “ASR INIT ERROR”: speech recognizer failed to allocate a session, and “ERROR”: any other errors
• FS-7732 Continue recording with uuid_transfer
• FS-7752 [mod_rayo] Increase maximum number of elements from 30 to 1024 to allow adhearsion to create large grammars to navigate IVR menus.
• FS-7750 [mod_commands] Allow for uuid_setvar to handle arrays
• FS-7758 [mod_loopback] Emit an event if a loopback bowout occurs
• FS-7759 [mod_sofia] Added the channel variable ignore_completed_elsewhere to suppress setting the completed elsewhere cause
• FS-7771 Set a channel variable if the recording is terminated due to silence hits
• FS-7760 Added xml fetch for channels to externally support nightmare transfer depends on channel-xml-fetch-on-nightmare-transfer profile param (default is disabled)
• FS-7730 [mod_smpp] Added mod_smpp as an event handler module
  and fixed the default configs to provided sample load option for mod_sms and mod_smpp
• FS-7774 Add mod_kazoo
• FS-7780 Add new channel variable max_session_transfers. If set, this variable is used to count the number of session transfers allowed instead of the max_forwards variable. If not set, the existing behavior is preserved.
• FS-7783 Add channel variable for capturing DTMF input when using play_and_get_digits when the response does not match
• FS-7772 [mod_opus] Add functionality to keep FEC enabled on the encoder by modifying the bitrate if packet loss changes (Opus codec specific behaviour).
• FS-7799 [mod_png] Add API command uuid_write_png
• FS-7801 [mod_opus] Added support to set CBR mode
• FS-7685 [mod_say_nl] Fix Dutch numbers pronunciation
• FS-7198 Add coma separated values and reverse ranges for time-of-day and day-of-week matches
• FS-7809 [mod_opus] Added 60 ms ptime for Opus at 8 khz ( opus@8000h@60i )
• FS-7405 [mod_dialplan_xml] Fix condition regex=”all” to work with time conditions
• FS-7819 [mod_opus] Restore bitrate (if there’s no more packet loss) and added step for 60 ms
• FS-7773 [mod_sofia] Adding additional transfer events when the fire-transfer-events=true profile parameter is set
• FS-7820 FreeSWITCH automated unit test and micro benchmark framework
• FS-7769 [mod_conference] Add new multi-canvas and telepresence features
• FS-7847 [mod_conference] Add layers that do not match the aspect ration of conference by using the new hscale layer param for horizontal scale, and add zoom=true param to crop layer instead of letterbox, add grid-zoom layout group that demonstrates these layouts, and fix logo ratios and add borders too.
• FS-7813 [mod_conference] Add vmute member flag.
• FS-7846 [mod_dptools] Add eavesdrop_whisper_aleg=true and eavesdrop_whisper_bleg=true channel variables to allow you to start eavesdrop in whisper mode of specific call leg
• FS-7760 [mod_sofia] Revise channel fetch on nightmare transfer and add dial-prefix and absolute-dial-string to the nightmare xml
• FS-7829 [mod_opus] Add sprop-stereo fmtp param to specify if a sender is likely to send stereo or not so the receiver can safely downmix to mono to avoid wasting receiver resources
• FS-7830 [mod_opus] Added use-dtx param in config file (enables DTX on the encoder, announces in fmtp)
• FS-7824 [mod_png] Add functionality for capturing screenshots from both legs to uuid_write_png
• FS-7549 [mod_ladspa] Added an API for removing an active ladspa effect on a channel. For conformance reasons, the uuid_ladspa command now accepts ‘stop’ and ‘start’, while the previous functionality (without any verb) which will simply add ladspa remains intact.
• FS-7848 [mod_opus] Add support for 80 ms, 100 ms, 120 ms packetization
• FS-7519 FS-7677 [mod_av] Add H.263 codec support
• FS-7885 Add getcputime to retrieve FreeSWITCH process CPU usage
• FS-7889 [mod_conference] Move conference chat to use an event channel so messages only go to the right ‘room’ for the conference and move conference chat functionality to use event_channel.
• FS-7900 [mod_png] Allow snapshot of single legged calls
• FS-7912 [mod_lua] Added session UUID to lua error logs, if known and added session UUID to embedded language (lua, javascript, etc) logs when session sanity check fails
• FS-7760 [mod_sofia] Improved the xml fetch lookup for channels on nightmare transfer
• FS-7922 [mod_commands] Added uuid_redirect API command. This provides the equivalent functionality of the dptools “redirect” application as an api command.
• FS-7806 FS-7803 [mod_amqp] Added new properties to amqp configuration, fixed the usage for enable_fallback_format_fields, and added amqp_util_encode to fix a routing key issue
• FS-7972 [verto communicator] Creating Verto Communicator
• 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
• 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-7610 Fixed a gcc5 compilation issue
• FS-7499 Fixed a build error on 32bit platforms
• FS-7570 Fixed a compilation issue w/ zrtp enabled
• FS-7426 Only disable mod_amqp on Debian Squeeze and Wheezy
• FS-7635 Removed msvc 2005, 2008, and 2010 non working build systems
• FS-7373 Expose the custom repo and key path to the build-all command too
• FS-7648 Foundation for QA testing config , adding leave/check videomail test cases, adding videomail voicemail profile, adding video record/ playback test cases, adding set video on hold, force pre-answer prefix, and adding an eavesdrop test case.
• FS-7338 Removed mod_shout dep libs to system libs to continue cleaning up the libs for the 1.6 build process and added Debian packaging for several new modules, as well as handle system lib change for a handful of modules
• FS-7653 Sample build system for a stand alone(out of tree) FreeSWITCH module
• FS-7601 [mod_opus] [mod_silk] Removed a bounds check that can never be true in opus fec code and modify jitterbuffer usage to match the api change
• FS-7648 More work toward setting up a QA testing configuration, add condition testing for regex all and xor cases, adding profile-variable for testing cases , add lipsync tests for playback and local stream, add stereo, and configuration for mcu test
• FS-7338 Fixed bug in Debian packaging when trying to build against custom repo
• FS-7609 Enable building of mod_sangoma_codec for Debian Wheezy/Jessie
• FS-7667 [mod_java] Fixed include directory detection when using Debian java packages and use detected directory
• FS-7655 Make libvpx and libyuv optional (none of the video features will work without them) The following modules require these libraries to be installed still: mod_av mod_cv mod_fsv mod_mp4v2 mod_openh264 mod_vpx mod_imagick mod_vpx mod_yuv mod_png mod_vlc, fix build issue w/ strict prototypes, and fix a few functions that need to be disabled without YUV
• FS-7605 Fixed default configuration directory in Debian packages and fixed Debian packaging dependencies on libyuv and libvpx
• FS-7669 When installing from Debian packaging if you don’t have the /etc/freeswitch directory, we will install the default packages for you. If you already have this directory, we’ll let you deal with your own configs.
• FS-7297 [mod_com_g729] Updated the make target installer
• FS-7644 Added a working windows build without video support for msvc 2013
• FS-7666 [mod_managed] Fixed error building mod_managed on non windows platforms
• FS-7707 Fix build error on CentOS7
• FS-7655 Fixed a build error when we have PNG but not YUV
• FS-7723 Change RPMs to use -ncwait instead of -nc. This will cause the initscript to pause and wait for FS to be ready before continuing.
• FS-7648 Added a test cases for FS-7724 and FS-7687
• FS-7726 Additional configurations for a QA test case
• FS-7715 Updates to configure and spec files for next development branch and added images to spec file and fixed build/freeswitch.init.redhat since redhat likes to override settings in the script with TAGs in comments
• 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-7628 [mod_erlang_event] Removed unused variables causing a compilation error
• FS-7776 Add mod_kazoo to packaging
• FS-7845 [mod_conference] Break up mod_conference into multiple source files to improve build performance
• FS-7769 [mod_conference] Fixed a build issue
• FS-7820 Fix build system typo. Don’t assign the same variable twice.
• FS-7043 Fixed apr1 unresolved symbols in libfreeswitch.so.1.0.0
• FS-7130 Make /run/freeswitch persistent in the Debian packages, so it will start under systemd
• FS-7860 Prevent a switch_rtp header conflict
• FS-7130 Make /run/freeswitch persistent, so it will start under systemd
• FS-7728 Fixed Windows build issues minus video features
• 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
• 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-7579 [mod_conference] Fixed a bug not allowing suppression of play-file-done
• FS-7462 [mod_opus] Fix FMTP in the INVITE to use values from opus.conf.xml
• FS-7593 [mod_skinny] Fixed a bug where skinny phones would stomp on each other in database when thundering herd occurs
• FS-7597 [mod_codec2] Fixed encoded_data_len for MODE 2400, it should be 6 bytes. Also replaced 2550 bps bitrate (obsoleted operation mode) by 2400
• FS-7604 [fs_cli] Fixed fs_cli tab completion concurrency issues on newer libedit
• FS-7258 FS-7571 [mod_xml_cdr] Properly encode xml cdr for post to web server
• FS-7584 More work on rtcp-mux interop issue with chrome canary causing video transport failure
• FS-7586 [mod_conference] Change the default min-required-recording-participants option for mod_conference from 2 to 1 and silence the warning when the value is set to 1 in the configs
• FS-7607 Update URLs to reflect https protocol on freeswitch.org websites and update additional URLs to avoid 301 redirects.
• FS-7479 Fixed a crash caused by large RTP/PCMA packets and resampling
• FS-7524 [mod_callcenter] Fixing tiers, level and position should default to 1 instead of 0
• FS-7613 Fixed a crash in core text rendering
• FS-7612 Fixed invalid json format for callflow key
• FS-7609 [mod_sangoma_codec] Now that libsngtc-dev and libsngtc are in the FS debian repo, enable mod_sangoma_codec
• FS-7621 [mod_shout] Fixed a slow interrupt
• FS-7432 Fixed missing a=setup parameter from answering SDP
• FS-7622 [mod_amqp] Make sure to close the connections on destroy. Currently the connection is malloc’d from the module pool, so there is nothing to destroy.
• FS-7586 [mod_vlc] A fix for failing to encode audio during the recording of video calls
• FS-7573 Fixed 80bit tag support for zrtp
• FS-7636 Fixed an issue with transfer_after_bridge and park_after_bridge pre-empting transfers
• FS-7654 Fixed an issue with eavesdrop audio not working correctly with a mixture of mono and stereo
• FS-7641 Fixed a segfault in eavesdrop video support
• FS-7649 [mod_verto] Fixed issue with h264 codec not being configured in verto.conf.xml
• FS-7657 [mod_verto] Fixed a bug with TURN not being used. Note, you can pass an array of stun servers, including TURN, to the verto when you start it up. (see verto.js where iceServers is passed)
• FS-7665 [mod_conference] Fixed a bug with the video floor settings not giving the video floor to the speaker
• FS-7650 [mod_verto] Fixed crash when making a call from a verto user with profile-variables in their user profile
• FS-7710 [mod_conference] Added the ability to set bandwidth to “auto” for conference config
• FS-7432 Fixed dtls/srtp, use correct a=setup parameter on recovering channels
• FS-7678 Fixed for fail_on_single_reject not working with | bridge
• FS-7709 [mod_verto] Verto compatibility fixes for Firefox
• FS-7689 [mod_lua] Fixed a bug with lua not loading directory configurations
• FS-7694 [mod_av] Fixed for leaking file handles when the file is closed.
• FS-7467 [mod_callcenter] Fixing stuck channels using uuid-standby agents
• FS-7699 [mod_verto] Fixed for browser compatibility
• FS-7722 Fixed an issue with record_session including params when creating path
• FS-7489 [mod_unimrcp] Fixed a TTS Audio Queue Overflow
• FS-7724 [mod_conference] Fixed a segfault when missing fonts when trying to render banner
• FS-7519 [mod_av] Fixed a regression in the visual appearance of decode app output
• FS-7703 Fixed a bug caused by answer_delay being set in the default configurations
• FS-7679 [mod_verto] Fixed a bug causing one way audio on Chrome when video is enabled and when using a sip without video
• FS-7729 [mod_verto] Fixed the formatting for IPv6 addresses
• FS-7734 [mod_nibblebill] Fixed a deadlock
• FS-7726 Fixed a bug with recording a video session on DTMF command
• FS-7721 Fixed a segfault caused when using session:recordFile() and session:unsetInputCallback in a lua script
• FS-7429 [mod_curl] Fixed to output valid json
• FS-7746 [mod_verto] Fixed a device permission error in verto client
• FS-7753 [mod_local_stream] Fixed some glitching and freezing video when using hold/unhold
• 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-7744 [mod_conference] Fixed a bug causing the first user’s video stream to stop when another verto user calls the conference
• FS-7486 [mod_sofia] Fixed the handling of queued requests
• FS-7775 [mod_conference] Fix threading issue causing stuck worker threads
• FS-7777 [mod_imagick] Fixed a regression causing a segfault when playing png & pdf in conference
• 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-7785 [mod_opus] Fix for invalid ptime 30 ms for opus@8000h . Replaced 30 ms with 40 ms.
• FS-7762 [mod_av] Handle buffer allocation failures of large buffers
• FS-7849 [verto] Remove extra div breaking full screen in html
• FS-7832 [mod_opus] Fixes when comparing local and remote fmtp params
• FS-7731 [mod_xml_cdr] Fixed a curl default connection timeout
• FS-7844 Fix packet loss fraction when calculating loss average
• FS-7789 [mod_av] Fixed issue with audio dropping out partway through recordings
• FS-7854 Add task_runtime to tasks table in core database
• FS-7856 [mod_av] Fix some segfaults and leaks.
• FS-7866 Fixed a crash when running incorrect var api expansion syntax “eval ${${external_sip_ip}:4}”
• FS-7861 FS-7862 [mod_conference] Fixed a crash and other issues caused by multi canvas feature
• FS-7681 [mod_conference] Factor out conference->canvas and allow per canvas record and play
• FS-7869 [mod_conference] Fixed a deadlock on shutdown after playing video file that will not display video
• FS-7654 Fixed regressions on eavesdropping on channels playing a file and on channels with unlike rates
• FS-7872 [mod_verto] Gracefully fail attempting to transfer 1 legged call
• FS-7874 [mod_conference] Fixed incorrect layout group count
• FS-7870 [mod_conference] Allow jsonapi commands to pass the string id field to pass special ID’s like “last”
• FS-7882 [mod_conference] Allow JSON API commands to send third arg for muting
• FS-7888 [mod_verto] Fixed namespacing problems in javascript library masked by global verto object
• FS-7811 Use more common format CIF for blank image
• FS-7902 [mod_local_stream] Fix for queue filling up when you have a mix of video and non video files
• FS-7891 [mod_spandsp] Allow spandsp dtmf detector to work on rates other than 8k
• FS-7839 Correct firefox > 38 DTLS behavior to match new EC requirements
• FS-7769 [mod_conference] Fixed vmute on personal canvas and fixed changing layouts on personal canvas
• FS-7893 [mod_conference] Fixed a bug causing muxing write thread to occasionally not close on shutdown
• FS-7904 Fixed alpha image patching
• FS-7906 [mod_av] Correct crash from multi-threaded opening or closing of multiple files at the same time
• FS-7913 [mod_conference] Fixed miscast variable
• FS-7918 [mod_kazoo] Small fixes in mod_kazoo
• FS-7917 [mod_sofia] Fixed default config, we really shouldn’t be setting ext-*-ip settings for ipv6 profiles
• FS-7908 FS-7092 Fixed the generated sdp including telephone-event for the rates of video codecs (90000) when it should only be audio codec rates
• FS-7927 Fixed a typo in variable name: eavesdrop_annnounce_macro
• FS-7940 [mod_conference] Fixed an issue where the video image does not appear on the new canvas when switching
• FS-7930 [mod_conference] Correct termination of conference when the last member with endconf left.
• FS-7953 [verto communicator] Fixed dialing when typing extension using the keyboard.
• FS-7958 [mod_conference] Fixed a race condition causing crash in conference video MCU
• 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-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
• 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

Kamailio project considering to organize the next IRC devel meeting to sync on the plans for Kamailio short term evolution. A wiki page has been created to keep track of what should be discussed there. Feel free to add your suggestions there:

• http://www.kamailio.org/wiki/devel/irc-meetings/2015b

First proposed date is next week on Wednesday, September 16, at 14:00 UTC (15:00 London, 16:00 Berlin, …). The date can be changed based on availability of people willing to attend — add your preferred date and time to the wiki.Anyone can attend, no matter it proposed or not topics to discuss!

Looking forward to irc-ing about Kamailio next week!

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.