News from Industry

The FreeSWITCH 1.6.5 release is here! This release contains everything since version 1.6.2. This is a pretty big release for the 1.6 branch so upgrading now is a really good idea. This is a routine maintenance and security release and the resources are located here:

Release files are located here:

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

Security issues:

A bug allowing for a remotely exploited DoS attack through custom crafted network traffic via cJSON has been fixed. We classify this issues as High Severity. A patch was added by Anthony Minessale in commit 4bdca81 to resolve this issue. All versions versions from 1.4.4 through the previous release are vulnerable. We highly recommend updating to the current release version as soon as possible.
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-7392

New features that were added:

• FS-8243 [mod_opus] Improve the way FEC info is detected within frames by adding support for ptimes higher than 20 ms for FEC detection
• FS-8161 [mod_opus] Keep FEC enabled only if loss > 10 ( otherwise PLC is supposed to be better)
• FS-8179 [mod_opus] Improvement on new jitter buffer debugging (debug lookahead FEC)
• FS-8313 [mod_opus] Introduced new configuration setting ‘decoder-stats’ to show decoder stats at end of call (how many times it did PLC or FEC)
• FS-8254 [verto_communicator] Create a source map file
• FS-8263 [verto_communicator] Created the reset banner action, floor and presenter badges, and lock icon in floorLocked status
• FS-8288 [verto_communicator] Added an About screen with version information and links to FS.org and added a link to Confluence with documentation for VC
• FS-8289 [verto_communicator] Make mute/unmute audio/video clickable
• FS-8290 [verto_communicator] Automatically mark dedicated encoder if out/in bandwith isn’t set to ‘Server default’ and adding help text on how to enable dedicated remote encoder
• FS-8030 [verto_communicator] Added ngSanitize as a dependency, vertoFilters module and picturify filter and changed chat image display behavior (break line before rendering).
• FS-8293 [verto_communicator] Added built in speed test feature which gives feedback of available bandwidth and customizes call settings based on bandwidth available
• FS-8401 [verto_communicator] Added Speaker selection in settings modal and video page and refactor the sinkid function into verto lib
• FS-8545 [verto_communicator] Fixed a read lock regression and do not allow video floor on a member with a reservation id set
• FS-8195 [core] Compatibility with Solaris 11 process privileges
• FS-8547 [core] Add error log into stats to log when quality impacting events begin and end
• FS-8321 [core] Add variable media_mix_inbound_outbound_codecs to mix inbound and outbound codecs. BEHAVIOR CHANGE
• FS-8281 [core] Expose SRTP and SRTCP crypto keys as channel variables to aid with debugging
• FS-8287 [mod_local_stream] Refactor local_stream API to be more consistent and add auto complete
• FS-8375 [mod_conference] Add the field conferenceMemberID to the event broadcasted to inform a verto client about joining a conference.
• FS-8543 [mod_conference] Improve mute handling on conference and WebRTC
• FS-8545 [mod_conference][verto_communicator] Improve controls for screen share
• FS-8546 [mod_conference][mod_verto] Make original video demo back-compatible with livearray-json-status
• FS-8529 [mod_conference] Added video-floor to personal canvas mode
• FS-8377 [mod_hiredis] Adding expanded support for limit_* functionality and fixed the handling of hiredis limit release when using an interval. The expectation for interval is to NOT decrement the limit.
• FS-8380 [mod_av] Improve the handling of vw and vh core file parameters to avoid video cropping and crashing
• FS-8415 [mod_sofia] Added support for early media with 180 using early_use_180=true
• FS-8416 [mod_xml_radius] Added the ability to format the variable in the param field
• FS-8534 [rtcp] Added calculated RTT average (RTCP SR) value to help with detecting congested network links
• FS-8549 [mod_http_cache] Add support for AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables in S3 profiles
• FS-8559 [mod_shout] Should have “mpga” in it’s list of supported extensions

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

• FS-8236 [build] Fixed building without libyuv on compilers that throw an error on unused static function and fixed ifdefs for building without libyuv
• FS-8350 [build] Fix Windows build errors.
• FS-8389 [build] Fixed msvc 2015 build warnings
• FS-8316 [build][Debian] Fixed new build warning from latest clang and resolved the build warnings in the modules too
• FS-8255 [Debian] Fixed codename changes since Jessie was released as stable
• FS-8271 [Debian] Simplify package building for the default case
• FS-8270 [Debian] Fix for package installation failing if /etc/freeswitch/tls is missing
• FS-8285 [Debian] Removed heart attack inducing warning message when updating deb packages
• FS-7817 Removed use of _NONSTD for Windows builds of spandsp, so (hopefully) eliminate compatibility problem
• FS-8271 [Debian] Adding some logging, and more cautious handling of spaces in parameters. Now the default will build packages with the upstream FS package repos. This is a change in the default behavior of the Debian packaging system with the justification that in 1.6 it is now required to use the FS public repo for dependencies because system dependencies have been removed from the FS codebase which used to be included. And defaulting to automatically download the binary dependencies because without major changes to package building in cowbuilder(which is the primary supported method of building FS packages), you can’t access the network to build the binary packages from the source package. If using system apt repo list, then include the supplementary ones too
• FS-7928 FS-7618 [Debian] Systemd and package build improvements
• FS-8362 [Debian] Now if you install with freeswitch-all you will get the default fonts too
• FS-8426 [Debian] Put freeswitch.pm into /usr/share/perl5 so it can be found on both Wheezy and Jessie
• FS-8333 [build][Debian] Added mod_hiredis.deb
• ESL-111 [python] Fixed esl/python/Makefile to create install directory
• FS-8233 [automation] In order to clean up build dependencies for the automated tests, convert the tests/*/Makefile.am into an include file for the top level Makefile.am. This will greatly simplify dependency tracking, and allow tests to be rerun easily on FS source code changes.
• FS-7820 [automation] Use a more appropriate function for printing diagnostics
• FS-8194 FS-7910 FS-7937 Various systemd service improvements
• FS-8298 [mod_gsmopen] Fixed a build error
• FS-8398 [Ubuntu] Added event_handlers/mod_amqp to avoided modules for Ubuntu 14.04 Trusty
• FS-8239 [mod_av] Fixed the default value to avoid failed build on CentOS 7
• FS-8427 [build][mod_av] Fixed an incompatible type for %ld in prinrtf compiler error
• FS-8248 [mod_event_socket] Moved python binaries into site arch path to match standards

The following bugs were squashed:

• FS-8221 [verto_communicator] Fix number in call history
• FS-8223 [verto_communicator] Fixing members list layout when callerid is too long
• FS-8225 [verto_communicator] Avoid duplicate members when recovering calls
• FS-8214 [verto_communicator] Better handling calls in VC, answering them respecting useVideo param
• FS-8291 [verto_communicator] Fixed contributors url
• FS-8229 [verto_communicator] Changing moderator actions bullet menu color to #333
• FS-8219 [verto_communicator] Fix for camera not deactivating after init or after hangup
• FS-8245 [verto_communicator] Fix for Video Resolutions available in “Video Quality” drop down not always correct
• FS-8251 [verto_communicator] Factory reset now clears all local storage
• FS-8257 [verto_communicator] Fixed configuration provision url because configuration doesn’t work with `grunt serve` and non pathname urls
• FS-8273 [verto] [verto_communicator] Clear the CF_RECOVERING flag in a spot that was missed
• FS-8260 [verto_communicator] Prompt for banner text
• FS-8067 [verto_communicator] When no email is present make sure mm is the default avatar in the circle this way the talk indicator works on PSTN and SIP callers.
• FS-8247 [verto_communicator] When websocket disconnects go to splash screen to wait for the reconnect
• FS-8300 [verto_communicator] Fixing reload bug so reloading twice is no longer needed
• FS-8331 [verto_communicator] Do not show reconnect splash when user has clicked logout
• FS-8365 [verto_communicator] Fixed a bug with the chat notifications not going away unless you exited and came back to it
• FS-8336 [verto_communicator] Updating mic and video overlay controls upon receiving member update from live array and use conferenceMemberID when checking if the updated member is the local user
• FS-8222 [verto_communicator] Updated getScreenId.js in order to detect plugin issues and attached an ‘ended’ event to screenshare stream in order to detect ‘stop sharing’ click
• FS-8542 [verto_communicator] Fixed the tooltips of video controls
• FS-8556 [mod_verto] Screen shares are not recoverable so do not try
• FS-8293 [mod_verto] Fixed some regressions where speed test caused excessive downlink bandwidth
• FS-8232 [mod_conference] Conference sending too many video refresh requests
• FS-8241 [mod_conference] Fix for conference stops playing video when local_stream changes source
• FS-8261 [mod_conference] Fixed the conference segfaulting when trying to reset the banner
• FS-8297 [mod_conference] A fix for auto STUN switching IPs quickly and WebRTC video not working
• FS-8130 [mod_conference] Fix for micro cut-offs and unstable voice issues and fixed a regression causing excessive mark bit detection in some cases
• FS-8317 [mod_conference] Fix for playing multiple files at once to stack them for immediate playback, sometimes breaking and the floor layer becoming unusable for the rest of the conference.
• FS-8328 [mod_conference] Fixed missing ‘else’ keyword
• FS-8307 [mod_conference] Fixed an issue with the order of codecs causing loss of RTP stream
• FS-8280 [mod_conference] Fixed an issue with FS sending redundant stop-recording event notifications
• FS-8384 [mod_conference] Fixed some locking contention issues between external commands and the video engine
• FS-8527 [mod_conference] Do not send the video of last_video_floor_holder to video_floor_holder if the videos are related
• FS-8053 [mod_conference][mod_sofia] Fix for WebRTC’s SDP containing a=sendonly for video, but the client still receiving the video stream
• FS-8220 [core] Fix for DTMF not working between telephone-event/48000 A leg and telephone-event/8000 B leg
• FS-8166 [core] Mute/unmute while shout is playing audio fails because the channel “has a media bug, hard mute not allowed”
• FS-8252 [core] Fixed a crash in rtp stack on dtls pointer
• FS-8283 [core] Handle RTP Contributing Source Identifiers (CSRC)
• FS-8275 [core] Fix for broken DTMF
• FS-8282 [core] Fix for sleep is not allowing interruption by uuid_transfer
• FS-8315 [core] Fix for rtp_media_timeout not working
• FS-8304 [core] Fix for choppy audio during calls
• FS-8320 [core] Fixed broken ZRTP not responding to HELLO packet
• FS-8338 [core] Fix for ringback not working correctly on stereo channels. Also fixed an issue when setting the ringback variable with an outbound call via the bridge app, if the inbound leg is stereo the ringback tone is still rendered as mono causing the resulting ringback to be higher pitched and incorrect.
• FS-8366 [core] Fixed a segfault in rxfax
• FS-8275 [core] Fixed an issue with broken RFC2833 DTMF
• FS-8368 [core] Reduce logging for audio/video sync because some call lines were repeating too often for callers in a conference
• FS-8372 [core] Fixed a no media bug caused by sofia sending the wrong response to RTP/SAVPF without DTLS
• FS-8381 [core] Reset jitter buffer if period loss is too high
• FS-8382 [core] Fixed a segfault with inbound-proxy-media enabled
• FS-8397 [core] Fixed a race condition incrementing the event-sequence number
• FS-8154 [core] Fixed a segmentation fault occurring while eavesdropping on video call
• FS-8391 [core] Fixed a SDP parsing error for rtcp-fb
• FS-8414 [core] Fixed ptime not updating on codec renegotiation causing audio issues between two legs of a call
• FS-8417 [core] Fixed SIP offering a=sendonly sometimes replying with a=inactive
• FS-8404 [core] Media engine will default to PCMU/PCMA if you don’t specify any codecs
• FS-8411 [core] Replace ping_frame with video_ping_frame in a couple places that were missed causing issues like being unable to record just one side of a video call
• FS-8425 [core] Fix for DTMF sometimes missed on PSTN call
• FS-8240 [mod_local_stream] Fixed a/v getting out of sync when running in the background and added video profile parameter for recording 264 and made it default
• FS-8287 [mod_local_stream] Fixed a segfault from refactor
• FS-8216 [mod_av] Fixed a regression in hup_local_stream from last commit
• FS-8274 [mod_av] Fixed a memory leak caused by images not being freed in video_thread_run
• FS-8318 [mod_av] Fix for recording being out of sync when video from chrome has packet loss
• FS-8392 [mod_av] Fixed rtpmap to allow both H263 and H263+ codecs to be offered
• FS-8373 [mod_av] Fix for bad recording quality when using fast encoding
• FS-8256 [mod_opus] More FMTP cleanup
• FS-8284 [mod_opus] Use use-dtx setting from config in request to callee.
• FS-8234 [mod_opus] Send correct (configured) fmtp ptime,minptime,maxptime when originating call
• FS-8243 [mod_opus] Adding back the missing part removed in 8b088c2 so FEC works in most surroundings
• FS-8295 [mod_opus] FMTP fixes to continue the cleanup of FEC
• FS-8302 [mod_opus] Fix some printing/logging because switch_opus_show_audio_bandwidth() was not returning TRUE/FALSE as expected
• FS-8130 FS-8305 [mod_opus] Fix some warnings and errors caused by dtx and/or jittery webrtc, refactor of last patch, and add suppression of scary harmless message about opus FEC
• FS-8296 [mod_opus] Improve the way Opus is initialized when a call comes in
• FS-8179 [mod_opus] Fixed a regression setting fec_decode breaking output on stereo calls
• FS-8287 [mod_opus] Fixed a segfault from refactor
• FS-8319 [mod_opus] Fixed and cleaned up switch_opus_has_fec() and switch_opus_info() to avoid FALSE positives for packets with FEC at high frame sizes.
• FS-8344 [mod_opus] Toggle FEC ON only on the last frame which is to be packed
• FS-7929 [mod_sofia] Fixed an issue when processing SIP messages while using camp-on
• FS-6833 [mod_sofia] Add content-type header to ack with sdp
• FS-6834 [mod_sofia] Found and fixed a few missing content-types in requests/responses with SDP that were outside the norm
• FS-7834 [mod_sofia] Fixed MOH not working with inbound-bypass-media and resume-media-on-hold
• FS-8115 [mod_sofia] Disabled unnecessary session timer re-invites for webrtc
• FS-8536 [mod_sofia] Update to send Keyframe when getting SIP INFO with picture_fast_update
• FS-7989 [fixbug.pl] Escape double quotes from summary and added more debugging data
• FS-8246 [mod_json_cdr] Use seconds as default value for delay parameter
• FS-8308 [mod_format_cdr] Fix to double encode if urlencoding json that is already encoded
• FS-8311 [mod_voicemail] Fix for leave-message event not containing verbose data for a forwarded voicemail
• FS-8306 [mod_amqp] If the exchange doesn’t exist, then create it, else fail. This resolves several error cases. And now command queues can specify the queue to subscribe to. This enables very interesting use cases that would involve single job queue, and multiple consumers.
• FS-8335 [mod_easyroute] Fixed a small error check that results in error message not being displayed
• FS-8378 [mod_esf] [core] Fixed a crash when using esf_page over loopback when transcoding and added tests for esf over loopback. Also refactor a bit to clarify code and get better debug in gdb
• FS-8370 [mod_rayo] Fixed another place in where a message was freed after being queued for delivery. This resulted in a freed object being serialized, crashing FS
• FS-8413 [mod_lua] Fixed a segfault calling session:getVariable(nil) in lua script.
• FS-8537 [mod_lua] Fixed a segfault caused by passing nil to various lua functions
• OPENZAP-240 [mod_freetdm] Fixed a failure to parse caused by using incorrect length when parsing AT responses
• OPENZAP-238 [mod_freetdm] Several core and gsm improvements including fixing signaling status reporting, a small memory leak, fixing caller id and dnis on inbound calls, span stop functionality, and compilation errors in gcc
• FS-8553 [configuration] Include verto_contact into the dial-string in the samples
• FS-8363 [configuration] Don’t register gateways from directory because it registers over what appears to be ipv6 but doesn’t work correctly

The FreeSWITCH 1.4.26 release is here! This release contains everything since version 1.4.23. And this is a pretty big release and one of the final routine maintenance releases for the 1.4 branch  so upgrading now is a really good idea.

The FreeSWITCH 1.4 branch is reaching end of life and the FreeSWITCH Team highly recommends beginning your migration to the 1.6 branch.

This is a routine maintenance and security release and the resources are located here:

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

Security issues:

A bug allowing for a remotely exploited DoS attack through custom crafted network traffic via cJSON has been fixed. We classify this issues as High Severity. A patch was added by Anthony Minessale in commit 4bdca81 to resolve this issue. All versions versions from 1.4.4 through the previous release are vulnerable. We highly recommend updating to the current release version as soon as possible.
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-7392

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

• FS-8269 [mod_sms] Fixed a build issue
• FS-8244 [mod_dptools] Fixed a compilation issue

The following bugs were squashed:

• FS-8246 [mod_json_cdr] Use seconds as default value for delay parameter
• FS-8282 [core] Fix for sleep is not allowing interruption by uuid_transfer
• FS-8166 [core] Mute/unmute while shout is playing audio fails because the channel “has a media bug, hard mute not allowed”
• FS-8338 [core] Fix for ringback not working correctly on stereo channels and an issue when setting the ringback variable with an outbound call via the bridge app, if the inbound leg is stereo the ringback tone is still rendered as mono causing the resulting ringback to be higher pitched and incorrect.
• FS-8215 Fixed the accuracy of MacOSX nanosleep
• FS-7673 [mod_v8] ODBC NULL value incorrectly evaluated
• FS-8190 [mod_event_socket] When using nixevent, freeswitch stops sending us certain custom event that were NOT part of the nixevent command
• stereo the ringback tone is still rendered as mono causing the resulting ringback to be higher pitched and incorrect.
• FS-8354 [mod_conference] Reverted a back ported patch for rate change detection because it introduced a regression that caused an audio issue
• FS-8335 [mod_easyroute] Fixed a small error check that results in error message not being displayed
• FS-8370 [mod_rayo] Fixed another place in where a message was freed after being queued for delivery. This resulted in a freed object being serialized, crashing FS
• FS-8378 [mod_esf] [core] Fixed a crash when using esf_page over loopback when transcoding and added tests for esf over loopback. Also refactor a bit to clarify code and get better debug in gdb
• FS-8308 [mod_format_cdr] Fix to double encode if urlencoding json that is already encoded
• FS-8413 [mod_lua] Fixed a segfault calling session:getVariable(nil) in lua script.

ORTC, WebRTC, H.264, VP8, RID, RtpEncoding, Simulcast and much more. Google, Microsoft and Hookflash leading the discussion, join us!

http://ortc.org/2015/11/04/w3c-ortc-cg-meeting-10-november-20-2015/

Testing WebRTC is tricky.

If there’s something I learned this past year from talking to companies when showcasing the testRTC service, is that vendors don’t really test their WebRTC products.

Not all of them don’t test, but most of them.

Why is that? Here are a few reasons that I think explain it.

#1 – WebRTC is a niche for them – an experiment

You’ve got a business to run. It does something. And then someone decided to add communications to it. With WebRTC no less.

So you let them play. It isn’t much of an effort anyway. Just a few engineers hammering away. Once you launch, you think, you’ll see adoption and then decide if it is worthwhile to upgrade it from a hobby to a full time business.

The thing is, there’s a chicken and egg thing going on here. If you don’t do it properly, how will adoption really look? Will it give you the KPIs you need to make a reasonable decision?

WebRTC is rather new. As an industry, we still don’t have best practices of how to develop, test and deploy such services.

#2 – It’s a startup. Features get priority over stability

Many of the vendors using WebRTC out there are startups. They need to get a product out the door.

It can be a proof of concept, a demo, an alpha version, a beta one or a production version. In all cases, there’s a lot of pressure to cram more features into the product and show its capabilities than there are complaints about its stability or bugs.

Once these companies start seeing customers, they tend to lean more towards stability – and testing.

As we are seeing ourselves by running testRTC (=startup), there’s always a balancing act you need to do between features and stability.

#3 – They just don’t know how

How do you test WebRTC anyway?

VoIP?

If you view it as a VoIP technology, then you are bound to fail – the VoIP testing tools out there don’t really have the mentality and mindset to help you:

• Testing browsers continuously because they get updated so frequently isn’t something they do
• They don’t really know how to handle the fact that there’s no signaling protocol defined

The flexibility and fast paced nature of the web and WebRTC aren’t ingrained into their DNA.

Web?

If you view this as a web technology, then you’ll miss all the real time and media aspects of it. The web testing tools are more interested in GUI variability across browsers than they are with latencies and packet loss.

• How do you different network configurations? Does a firewall affect your results?
• You do know that you need multiple browsers for the simplest use case testing with WebRTC. How do you synchronize them within the test?

While web tools are great for testing web apps, they don’t fit the VoIP nature that exist in WebRTC.

#4 – They don’t have the tools

You know, if you wanted to test WebRTC a year or two ago, your best alternative was to use QA teams that click manually on buttons – or build your own test infrastructure for it.

Both alternatives are wasteful in resources and time.

So people sidestepped the issue and waited.

These days, there are a few sporadic tools that can test WebRTC – changing the picture for those who want to be serious about testing their service.

Don’t take WebRTC testing lightly

I just did a webinar with Upperside Conferences. If you want to listen in on the recording, you can register to it online.

Whatever your decision ends up being – using testRTC or not – please don’t take testing WebRTC implementations lightly.

The post 4 Reasons Vendors Neglect Testing WebRTC Services appeared first on BlogGeek.me.

One OS to rule them all?

It seems like Apple has decided to leave its devices split between two operating systems – Mac and iOS. If you are to believe Tim Cook’s statement, that is. More specifically, MacBook (=laptop) and iPad (=tablet) are separate devices in the eyes of Apple.

This is a strong statement considering current market trends and Apple’s own moves.

The iPad Pro

Apple’s latest iPad Pro is a 12.9 inch device. That isn’t that far from my Lenovo Yoga 2 Pro with its 13.1 inch. And it has an optional keyboard.

How far is this device from a laptop? Does it compete head to head in the laptop category?

Assuming a developer wants to build a business application for Apple owners. One that requires content creation (i.e – a real keyboard). Should he be writing it for the Mac or for iOS?

Tim Cook may say there’s no such intent, but the lines between Apple’s own devices are blurring. Where does one operating system ends and the other begins is up for interpretation from now on. One which will change with time and customer feedback.

Apple had no real intent of releasing larger iPhones or smaller iPads. It ended up doing both.

Microsoft Windows 10

Windows 10 is supposed to be an all-encompassing operating system.

You write your app for it, and it miraculously fits smartphones, tablets, laptops and PCs. That’s at least the intent – haven’t seen much feedback on it yet.

And I am not even mentioning the Surface Tablet/Laptop combo.

Google Chrome OS / Android

Google has its own two operating systems – Android and Chrome OS. Last month Alistair Barr informed of plans in Google to merge the two operating systems together.

The idea does have merit. Why invest twice in two places? Google needs to maintain and support two operating systems, while developers need to decide to which to build their app – or to develop for both.

Taking this further, Google could attempt making Android apps available inside Chrome browsers, opening them up to even a larger ecosystem not relying only on their own OS footprint. Angular and Material Design are initiatives of putting apps in the web. A new initiative might be interpreting Android’s Java bytecode in Chrome OS, and later in Chrome itself.

Who to believe?

On one hand, both Microsoft and Android are consolidating their operating systems. On the other, Apple doesn’t play by the same rule book. Same as we’ve seen lately in analytics.

I wonder who which approach would win in the end – a single operating system to rule them all, or multiple based on the device type.

The post Can Apple Succeed with Two Operating Systems When Google and Microsoft are Consolidating? appeared first on BlogGeek.me.

This week the FreeSWITCH team added a built in bandwidth test to the verto communicator and a calculated RTT value to help with detecting congested network links. This week we have David Taht joining us on the ClueCon weekly call to talk about FCC firmware policies. Join us Wednesdays at 12:00 CT for some more FreeSWITCH fun! And head over to freeswitch.com to learn more about FreeSWITCH support.

New features that were added:

• FS-8293 [verto_communicator] Added built in speed test feature which gives feedback of available bandwidth and customizes call settings based on bandwidth available
• FS-8534 [rtcp] Added calculated RTT average (RTCP SR) value to help with detecting congested network links
• FS-8416 [mod_xml_radius] Added the ability to format the variable in the param field

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

• FS-8427 [build][mod_av] Fixed an incompatible type for %ld in prinrtf compiler error
• FS-8426 [Debian] Put freeswitch.pm into /usr/share/perl5 so it can be found on both Wheezy and Jessie
• ESL-111 [python] Fixed esl/python/Makefile to create install directory
• FS-8248 [mod_event_socket] Moved python binaries into site arch path to match standards

The following bugs were squashed:

• OPENZAP-240 [mod_freetdm] Fixed a failure to parse caused by using incorrect length when parsing AT responses
• OPENZAP-238 [mod_freetdm] Several core and gsm improvements including fixing signaling status reporting, a small memory leak, fixing caller id and dnis on inbound calls, span stop functionality, and compilation errors in gcc
• FS-8425 [core] Fix for DTMF sometimes missed on PSTN call
• FS-8536 [mod_sofia] Update to send Keyframe when getting SIP INFO with picture_fast_update
• FS-8384 [mod_conference] Fixed a locking contention

The FreeSWITCH 1.4 branch had a bug fix added this week.

The following bugs were squashed:

• FS-8413 [mod_lua] Fixed a segfault calling session:getVariable(nil) in lua script.

The Accounts Manager App is a dynamic web portal providing multi-tenant functionality for worry-free scaling. Manage all of your accounts, and provide granular control to ensure customers have an enjoyable experience. Set limits for trunks, create call restrictions and manage credit balances – all within the App. 

 The Accounts Manager App has consolidated customer relationship management within a single User Interface. Accounts can be set up remotely, enabling you to sell across the continental United States. You no longer need to worry about logging into separate systems or figure out what client is on which platform.  

What Accounts Manager Provides 

Unified and Intuitive Interface 

Add and edit new accounts and sub-accounts, monitor customers, select a carrier strategy, maintain service plans and restrictions - in one interface. 

Simplifying Account Set-Up 

Set up accounts for all of your customers. Create business account names, add the admin contact or manage the account yourself. 

Set Limits and Create Call Restrictions 

Create and set limits for your customers that include inbound, outbound, and two-way trunks. Set up call restrictions based on tolls, location, Emergency Dispatcher, and manage your customer’s credit balance. 

Manage Permissions 

Manage what your clients can and can’t view. This includes user and account settings, billing options, inbound and outbound trunking, and UI errors.

A long, boring straight line.

In some ways, WebRTC now feels like a decade ago, when every time we said “next year will be the year of video”. For WebRTC? Next year will be the year of adoption.

Adoption is hard to define though. What does it really means when it comes to WebRTC?

• Browser vendors supporting it? (3 out of 4 with rumors about the fourth)
• The number of WebRTC-enabled devices? In the billions already
• Vendors using WebRTC? I am tracking now over 800 vendors and projects

WebRTC has been picked up by carriers (AT&T, Comcast and others if you care about name dropping), most (all?) video conferencing and unified communication vendors, education, banking and healthcare industries, contact centers.

While all is well in the world of WebRTC, there is no hype. A year and a half ago I wrote about it – the fact that there is no hype in WebRTC. It still holds true. Too true. And too steadily.

The chart below is a collection of 2 years of data of some of the data points I follow with WebRTC. I hand picked here 4 of them:

• The number of github projects mentioning WebRTC
• The number of questions/answers on Stack Overflow mentioning WebRTC
• The number of users subscribed to the discuss-webrtc Google group
• The number of LinkedIn profiles of people deciding to add WebRTC to their “resume”

In all of these cases (as well as other metrics I collect and follow), the trend is very stable. There’s growth, but that growth is linear in nature.

There are two minor areas worth mentioning:

1. LinkedIn had a correction during September/October – a high increase and then an immediate decrease. Probably due to spam accounts that got caught by LinkedIn. I’ve seen this play out on Google+ account stats as well about a year ago
2. github and StackOverflow had a slight change in their line angle from the beginning of 2015. This coincides with Google’s decision to host its samples and apprtc on github instead of on code.google.com – probably a wise decision, though not a game changer

Some believe that the addition of Microsoft Edge will change the picture. Statistics of Edge adoption and the statistics I’ve collected in the past two months show no such signs. If anything, I believe most still ignore Microsoft Edge.

Where does that put us?

Don’t be discouraged. This situation isn’t really bad. 2015 has been a great year for WebRTC. We’ve seen public announcements coming from larger vendors (call it adoption) as well as the addition of Microsoft into this game.

Will 2016 be any different? Will it be the breakout year? The year of WebRTC?

I doubt it. And not because WebRTC won’t happen. It already is. We just don’t talk that much about it.

If you are a developer, all this should be great news for you – there aren’t many others in this space yet, so demand versus supply of experienced WebRTC developers favors developers at the moment – go hone your skill. Make yourself more valuable to potential employers.

If you are a vendor, then find the most experienced team you can and hold on to them – they are your main advantage in the next years when it comes to outperforming your competitors when it comes to building a solid service.

We’re not in a hyped up industry as Internet of Things or Big Data – but we sure make great experiences.

The post WebRTC Demand isn’t Exponentially Growing appeared first on BlogGeek.me.

Daniel Pocock has sent a very informative email about FOSDEM 2016 and Real Time Communications – read it here., with useful details about volunteering and speaking opportunities.FOSDEM 2016 takes place in Brussels, Belgium, during January 30-31, 2016, being one of the biggest gathering events for open source developers world wide. It will host a Real Time dev room, as the successor of Telephony and XMPP dev rooms.Members of Kamailio community will be at the event, continuing the tradition of several years in a row to meet there and discuss what is new about the project and real time communications.

There’s a new home for the WebRTC Data Channel – it found its use lately in context.

Ever since WebRTC was announced, I’ve been watching the data channel closely – looking to see what developers end up doing with it. There are many interesting use cases out there, but for the most part, it is still early days to decide where this is headed. In the last couple of weeks though, I’ve seen more and more evidence that there’s one place where the WebRTC Data Channel is being used – a lot more than I’d expect. That place is in adding context to a voice or video call.

Where did my skepticism come from?

Look at this diagram, depicting a simplified contact center using WebRTC:

We have a customer interacting with an agent, and there are almost always two servers involved:

1. The web server, which got the two browsers connected. It acts as the signaling server for us, and uses HTTP or Websockets for its transport
2. The media server, which can be an SBC, connecting both worlds or just a media server that is there to handle call queuing, record calls, etc.

The logic here is that the connection to the web server should suffice to provide context – why go through all the trouble of opening up a data channel here? For some reason though, I’ve seen evidence that many are adopting the data channel to pass context in such scenarios – and they are terminating it in their server side and not passing it direct between the browsers.

The question then is why? Why invest in yet another connection?

#1 – Latency

If you do need to go from browser to browser, then why make the additional leg through the signaling server?

Going direct reduces the latency, and while it might not be much of an issue, there are use cases when this is going to be important. When the type of context we are passing is collaboration related, such as sharing mouse movements or whiteboarding activity – then we would like to have it shared as soon as possible.

#2 – Firewalls

We might not want to go through the signaling server for the type of data we wish to share as context. If this is the case, then the need to muck around with yet another separate server to handle a Websocket connection might be somewhat tedious and out of context. Having the WebRTC data channel part of the peer connection object, created and torn down at the same time can be easier to manage.

It also has built in NAT and Firewall traversal mechanisms in place, so if the call passes – so will the context – no need to engineer, configure and test another system for it.

#3 – Asymmetry

At times, not both sides of the session are going to use WebRTC. The agent may as well sit on a PSTN phone looking at the CRM screen on his monitor, or have the session gateway into a SIP network, where the call is received.

In such cases, the media server will be a gateway – a device that translates signaling and media from one end to the other, bridging the two worlds. If we break that apart and place our context in a separate Websocket, then we have one more server to handle and one more protocol to gateway and translate. Doing it all in the gateway that already handles the translation of the media makes more sense for many use cases.

#4 – Load Management

That web server doing signaling? You need it to manage all sessions in the system. It probably holds all text chats, active calls, incoming calls waiting in the IVR queue, etc.

If the context we have to pass is just some log in information and a URL, then this is a non-issue. But what if we need to pass things like screenshots, images or files? These eat up bandwidth and clog a server that needs to deal with other things. Trying to scale and load balance servers with workloads that aren’t uniform is harder than scaling uniform work loads.

#5 – Because We Can

Let’s face it – WebRTC is a new toy. And the data channel in WebRTC is our new shiny object. Why not use it? Developers like shiny new toys…

The Humble WebRTC Data Channel

The data channel has been around as long as WebRTC, but it hasn’t got the same love and attention. There’s very little done with it today. This new home it found with passing context of sessions is an interesting development.

 

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

The post WebRTC Data Channel find a home in Context appeared first on BlogGeek.me.

Gholamreza Sabery Tabrizy has published a Github repository with Ansible playbooks for deploying a Kamailio active-passive HA node using Pacemaker and Corosync.You can see more details at:

• https://github.com/ghrst/Kamailio-HA

With few tunings to the options, it can be used as a starting point to build your own Kamailio HA node.Enjoy!PS: if you wrote or if you are aware of tools or articles related to Kamailio, email a short note to one of our mailing lists and we will publish on kamailio.org news sections.

This week the FreeSWITCH team added support for early media with a 180 to mod_sofia and continued the expansion of mod_hiredis limit functionality. This week we have Justin Grow from Flowroute joining us on the ClueCon weekly call. He will be talking about Flowroute APIs and configuring FreeSWITCH to work with Flowroute.

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

New features that were added:

• FS-8377 [mod_hiredis] Fixed the handling of hiredis limit release when using an interval. The expectation for interval is to NOT decrement the limit.
• FS-8415 [mod_sofia] Added support for early media with 180 using early_use_180=true

The following bugs were squashed:

• FS-8411 [core] Replace ping_frame with video_ping_frame in a couple places that were missed causing issues like being unable to record just one side of a video call
• FS-8413 [mod_lua] Fixed a segfault calling session:getVariable(nil) in lua script.
• FS-8308 [mod_format_cdr] Fix to double encode if urlencoding json that is already encoded
• FS-8414 [core] Fixed ptime not updating on codec renegotiation causing audio issues between two legs of a call
• FS-8417 [core] Fixed SIP offering a=sendonly sometimes replying with a=inactive
• FS-8404 [core] Media engine will default to PCMU/PCMA if you don’t specify any codecs

The FreeSWITCH 1.4 branch had a bug fix added this week.

The following bugs were squashed:

• FS-8308 [mod_format_cdr] Fix to double encode if urlencoding json that is already encoded

A few use cases where WebRTC can be found in gaming.

When WebRTC first came out, everyone were in frenzy trying to figure out which verticals will end up using WebRTC. One of the verticals that keeps popping up, but never sticking around for long is gaming.

When discussing WebRTC and gaming, there’s more than a single use case – there are a few dominant one; and I wanted to share them here this time.

#1 – Social Games

Remember Cube Slam? Google’s first demo of WebRTC, where you can play a game with someone else and see him on the other side?

That was a demo. Jocly Games is the best example I have. Jocly Games offer turn by turn board games where your opponent is another player somewhere. If you wish, you can see each other during the game by the help of WebRTC. I’ve interviewed Michel Gutierrez, the CEO of Jocly Games two years ago.

Roll20 does a similar thing for multiplayer RPG games.

#2 – Motion Sensor

While I haven’t seen any serious game using this, the fact that you can get a camera feed into a game means you can track movement. And if you can track movement – you can use it to control something.

How about a game of Snake?

#3 – Multiplayer Gaming

Multiplayer games require synchronization between players. The better the connection the more responsive the game. And where latency is important, there’s room for WebRTC’s data channel.

Two and a half years ago, Mozilla released a proof of concept of sorts. Its own WebRTC demo, focused on the data channel. It was a game called BananaBread. It is a first person shooter where the players communicate their positions and actions directly with each other using the data channel.

This year, I reviewed a book about multiplayer game development in HTML5. While the WebRTC part of it was skinny compared to the rest, it did mention its capability.

In the wild, I haven’t seen any evidence of this being used a lot. I assume it is due to the relative complexity of implementing it and taking care of cases where some players can’t use the data channel or must relay it via TURN servers.

#4 – Controller and Display

This is something I haven’t seen up until recently, and now I’ve seen it several times in the same month.

AirConsole uses this technique. To some extent, Ericsson’s Remote Excavation demo takes the same approach.

The idea is one device holds the controls over the other. In our case, a game controller and the PC/console running the game (on a browser of course). Once the two pair up using a WebRTC data channel, the latency involved in passing commands from the controller to the device are minimized.

What am I missing?

4 different typical use cases. None used in any popular game. None considered “best practices” or common approaches to game development.

• Are there more use cases for gaming with WebRTC?
• Is any of them making headway in large scale commercial games that I am unaware of?
• Is there a reason why none of them is catching up?

 

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

The post Is there any Room for WebRTC in Gaming? appeared first on BlogGeek.me.

There has been more noise about WebRTC making it possible to track users. We have covered some of the nefarious uses of WebRTC and look out for it before. After reading a blog post on this topic covering some allegedly new unaddressed issues a week ago I decided to ignore it after some discussion on the mozilla IRC channel. But this has some up on a the twitter-sphere again and Tsahi said ‘ouch’, here are my thoughts.

Claims

The blog post (available here) makes a number of claims about how certain Chrome behavior makes fingerprinting easier:

• Chrome started caching certificates for 30 days recently, creating a cookie-like attack surface for privacy
• this allows cross-origin tracking of users
• the incognito mode behavior is inconsistent with respect to this

Caching certificates

First, there is a claim that the way Chrome caches certificates changed recently:

In the past, Google Chrome used to generate a new self-signed certificate for every WebRTC PeerConnection. But now (using Chrome 46, or maybe earlier as i did not check) it generates a self-signed certificate which is valid for one month and uses it for all PeerConnections of a particular domain.

The code used to demonstrate this behaviour is rather odd, too. It uses the getStats API to the query the fingerprint, which is also available more easily in the SDP.

Chrome has cached certificates in this way for about two years, this is not real news. One of the reasons for this is that it is rather expensive to generate the current private keys for DTLS, especially on mobile devices. In the future, there will be more control over this behaviour. Neither Firefox nor Edge currently cache certificates.

To be fair, the WebRTC team made a serious blunder here. Until Chrome 45, the certificate was not cleared when cookies were cleared, only when all data was cleared. The bugfix for this only appeared in the Chrome 47 release notes:

Issue 510850 DTLS cert should be cleared when cookies are cleared

Cross-Origin Tracking

So this part is not really news. The second claim made in the blog post is that this enables cross-origin tracking:

To test this go to http://www.kapejod.org/tracking/test.html and to http://kapejod.org/tracking/test.html. Open the network tab of Chrome’s developer console and compare the urls of the requested “tracking.png”. They should contain the same fingerprint, now!

They do. Now, let’s look at this test page:

// make up some random id var transactionId = 'xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx'.replace(/[xy]/g, function(c) {var r = Math.random()*16|0,v=c=='x'?r:r&0x3|0x8;return v.toString(16);}); var fragment = document.createDocumentFragment(); var div = document.createElement("DIV"); div.innerHTML = '<iframe src="http://kapejod.org/tracking/identify.html?'+transactionId+'" width="1" height="1" style="display:none;"/>'; fragment.appendChild(div); document.body.insertBefore(fragment, document.body.childNodes[document.body.childNodes.length - 1]);

It includes the URL http://kapejod.org/tracking/identify.html. Let’s also look at the code there as well. It executes the code shown above and logs the fingerprint to the console:

console.log('your fingerprint is: ' + fingerprint);

Now why is the fingerprint the same? Well, the iframe is always included from kapejod.org. Which means the Javascript is executed within the context of this origin.
So Chrome can use the persisted fingerprint. As well as any cookies and localStorage data. The attack surface here is no worse than setting a cookie.

Another thing related to this (and I am surprised this has not yet been mentioned) are the deviceIds returned by navigator.mediaDevices.enumerateDevices. Those are also persisted with the same lifetime as cookies. The W3C mediacapture specification has a paragraph about security and privacy considerations on this:

The identifiers for the devices are designed to not be useful for a fingerprint that can track the user between origins, but the number of devices adds to the fingerprint surface. It recommends to treat the per-origin persistent identifier deviceId as other persistent storages (e.g. cookies) are treated.

Again, WebRTC and other HTML5 techniques increase the fingerprint surface. But by design, this is not worse than cookies or equivalent techniques like localStorage.

Incognito Mode

Last but not least the blog post makes claims about the incognito mode:

But to make it generate a new one you have to close ALL incognito tabs. Otherwise you can be tracked across multiple domains.

Again, this behaviour is consistent with the incognito mode behaviour for things like localStorage. In both Chrome and Firefox. In incognito mode, open a site, set something in localStorage. Open another tab. Close first tab. Navigate to same site. Check localStorage. Boo!

tl;dr

There is no real news here. In Germany, we call this ‘olle kamellen’.

{“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 OMG WebRTC is tracking me! Or is it? appeared first on webrtcHacks.

Announcing an upcoming free webinar on the challenges of WebRTC testing.

This week I took a trip to San Francisco, where the main goal was to attend WebRTC Summit and talk there about the challenges of WebRTC testing. This was part of the marketing effort we’re placing at testRTC. It is a company I co-founded with a few colleagues alongside my consulting business.

During the past year, we’ve gained a lot of interesting insights regarding the current state of testing in the WebRTC ecosystem. Which made for good presentation material. The session at the WebRTC Summit went rather well with a lot of positive feedback. One such comment made was this one that I received by email later during that day:

I liked much your presentation which indeed digs into one of the most relevant problems of WebRTC applications, which is not generally discussed in conferences.

My own favorite, is what you can see in the image I added above – many of the vendors our there just don’t make the effort to test their WebRTC implementations properly – not even when they go to production.

I’ve identified 5 main challenges that are facing WebRTC service developers:

1. Browser vendor changes (hint: they are many, and they break things)
2. NAT traversal (testing it isn’t trivial)
3. Server scale (many just ignore this one)
4. Service uptime (checking for the wrong metric)
5. Orchestration (a general challenge in WebRTC testing)

The slides from my session are here below:

Overcoming the Challenges in Testing WebRTC Services from Tsahi Levent-levi

 

That said, two weeks from now, I will be hosting a webinar with the assistance of Amir Zmora on this same topic. While some of the content may change, most of it will still be there. If you are interested, be sure to join us online at no cost. To make things easier for you, there are two sessions, to fit any timezone.

When? Wednesday, November 18

Session 1: 8 AM GMT, 9 AM CET, 5 PM Tokyo

Session 2: 4 PM GMT, 11 AM EDT, 8 AM PDT

Register now

 

Test and Monitor your WebRTC Service like a pro - check out how testRTC can improve your service' stability and performance.

The post WebRTC Testing Challenges: An Upcoming Webinar and a Recent Session appeared first on BlogGeek.me.

Fraunhofer Fokus Research Institute, the place where SIP Express Router (SER) project started (which over the time resulted in Kamailio project), is organizing the 6th edition of FUSECO Forum during Nov 5-6, 2015, in Berlin, Germany.The two days event combines practical workshops with panels and keynote presentations, revealing what is the trend in real time communications, from classic telephony, 4/5G to IoT, smart cities and machine to machine communications.For more details, see:

• https://www.fokus.fraunhofer.de/go/fuseco-forum-2015

Representative from Kamailio community will be at the event, myself included, along with Dragos Vingarzan (initial developer of IMS extensions) and Elena-Ramona Modroiu (core developer).

I wonder. Can Apple maintain its lead without getting deep and dirty in analytics?

Apple decided to “take the higher ground”. It has pivoted this year focusing a lot around privacy. Not maintaining user keys for one, but also collecting little or no information from devices and doing as much as possible analytics on device. For now, it seems to be working.

But can it last?

Let’s head 5 or 10 years into the future.

Now lets look at Google and Facebook. Both have voracious appetite to data. Both are analytics driven to the extreme – they will analyze everything and anything possible to improve their service. Where improving it may mean increasing its stickiness, increasing ROI and ARPU, etc.

As time goes by, computing power increases, but also the technology and understanding we have at our disposal in sifting through and sorting out huge amounts of data. We call it Big Data and it is changing all the time. A year or two ago, most discussions on big data were around Hadoop and workloads. This year it was all about real time and Spark. There’s now a shift happening towards machine learning (as opposed to pure analytics), and from there, we will probably head towards artificial intelligence.

To get better at it, there are a few things that need to be in place as well as ingrained into a company’s culture:

1. You need to have lots and lots of data. The more the merrier
2. The data needs to be available, and the algorithms put in place need to be tweaked and optimized daily. Think about how Google changes its search ranking algorithm all the time
3. You need to be analytics driven. It needs to be part and parcel of your products and services – not something done as an afterthought in a data warehouse to generate a daily report to a manager

These traits are already there for Google and Facebook. I am less certain regarding Apple.

Fast forward 5 to 10 years.

• Large companies collect even more data
• Technologies and algorithms for analytics improve
• Services become a lot more smart, personalized and useful

Where would that leave Apple?

If a smartphone (or whatever device we will have at that time) really becomes smart – would you pick out the shiny toy with the eye candy UI or the one that gets things done?

Can Apple stay long term with its stance towards data collection policies or will it have to end up collecting more data and analyzing it the way other companies do?

The post Can Apple’s On-Device Analytics Compete with Google and Facebook? appeared first on BlogGeek.me.

FreeSWITCH got some neat improvements this week with work going into improving the handling of vw and vh core file parameters in mod_av to avoid video cropping and crashing, the addition of a new configuration setting in mod_opus to show the decoder stats at the end of the call, and exposing SRTP and SRTCP crypto keys as channel variables to help with debugging.

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

New features that were added:

• FS-8281 [core] Expose SRTP and SRTCP crypto keys as channel variables to aid with debugging
• FS-8313 [mod_opus] Introduced new configuration setting ‘decoder-stats’ to show decoder stats at end of call (how many times it did PLC or FEC)
• FS-8380 [mod_av] Improve the handling of vw and vh core file parameters to avoid video cropping and crashing

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

• FS-8389 [build] Fixed msvc 2015 build warnings
• FS-8398 [Ubuntu] Added event_handlers/mod_amqp to avoided modules for Ubuntu 14.04 Trusty

The following bugs were squashed:

• FS-8222 [verto_communicator] Updated getScreenId.js in order to detect plugin issues and attached an ‘ended’ event to screenshare stream in order to detect ‘stop sharing’ click
• FS-8392 [mod_av] Fixed rtpmap to allow both H263 and H263+ codecs to be offered
• FS-8373 [mod_av] Fix for bad recording quality when using fast encoding
• FS-8397 [core] Fixed a race condition incrementing the event-sequence number
• FS-8154 [core] Fixed a segmentation fault occurring while eavesdropping on video call
• FS-8391 [core] Fixed a SDP parsing error for rtcp-fb
• FS-8319 [mod_opus] Fixed and cleaned up switch_opus_has_fec() and switch_opus_info() to avoid FALSE positives for packets with FEC at high frame sizes.
• FS-8344 [mod_opus] Toggle FEC ON only on the last frame which is to be packed

The FreeSWITCH 1.4 branch had a few bug fixes added this week.

The following bugs were squashed:

• FS-8338 [core] Fixed an issue when setting the ringback variable with an outbound call via the bridge app, if the inbound leg is stereo the ringback tone is still rendered as mono causing the resulting ringback to be higher pitched and incorrect.
• FS-8378 [mod_esf] [core] Fixed a crash when using esf_page over loopback when transcoding and added tests for esf over loopback. Also refactor a bit to clarify code and get better debug in gdb
• FS-8370 [mod_rayo] Fixed another place in where a message was freed after being queued for delivery. This resulted in a freed object being serialized, crashing FS

Someone should build a generic fallback…

If you don’t know Socket.io then here’s the gist of it:

• Socket.io is a piece of JS client code, and a server side implementation
• It enables writing message passing code between a client and a server
• It decides on its own what transport to use – WebSocket, XHR, SSE, Flash, pigeons, …

It is also very popular – as a developer, it lets you assume a WebSocket like interface and develop on top of it; and it takes care of all the mess of answering the question “but what if my browser/proxy/whatever doesn’t support WebSocket?

I guess there are use cases where the WebRTC data channel is like that – you’d love to have the qualities it gives you, such as reduced server load and latency, but you can live without it if you must. It would be nice if we’d have a popular Socket.io-like interface to do just that – to attempt first to use WebRTC’s data channel, then fallback to either a TURN relay for it or to WebSocket (and degrading from there further along the line of older transport technologies).

The closest I’ve seen to it is what AirConsole is doing. They enable a smartphone to become the gamepad of a browser. You get a smartphone and your PC connected so that whatever you do in the phone can be used to control what’s on the PC. Such a thing requires low latency, especially for gaming purposes; and WebRTC probably is the most suitable solution. But WebRTC isn’t always available to us, so AirConsole just falls back to other mechanisms.

While a gaming console is an obvious use case, and I did see it in more instances lately, I think there’s merit to such a generic framework in other instances as well.

Time someone implemented it

The post Where’s the Socket.io of WebRTC’s Data Channel? appeared first on BlogGeek.me.