News from Industry

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.

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

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

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

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

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

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

Enjoy!

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

A quick note.

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

Me in San Francisco

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

WebRTC Codec Wars: Rebooted

When? Wednesday, September 9, 18:00

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

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

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

Attendance is free, but you need to register.

Kranky Geek WebRTC Show

When? Friday, September 11, 12:00

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

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

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

Development Approaches of WebRTC Based Services

When? September 24, 14:00 EDT

Where? Online

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

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

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

Video+Conference 2015

When? Thursday, October 15, 11:00

Where? Congress Centre Hotel “Alfa”, Moscow

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

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

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

 

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

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

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

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

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

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

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

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

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

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

Congrats Bernard!

/Erik

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

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

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

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

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

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

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

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

The Press Release

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

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

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

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

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

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

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

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

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

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

Would be easier to just bio-engineer Superman.

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

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

High goals for a committee to work on.

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

The Members

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

Amazon

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

Their addition into this group is interesting in several aspects:

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

Cisco

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

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

Google

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

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

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

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

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

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

Intel

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

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

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

Microsoft

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

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

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

Mozilla

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

Netflix

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

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

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

Missing in Action

Who’s missing?

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

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

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

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

We don’t have the chipset vendors.

Apple

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

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

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

Content providers

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

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

Where will they be headed with this?

Content creators

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

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

Chipset vendors

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

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

The Beginning of the End for HEVC/H.265

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

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

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

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

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

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

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

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

New features that were added:

• FS-8075 [mod_hiredis] Add mod_hiredis including support for redis limits and added support for raw redis commands. Added deprecation notices to mod_redis
• FS-8049 [mod_commands] Add getenv FSAPI
• FS-8036 [verto.js] Add chatCallback to $.verto.conf

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

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

The following bugs were squashed:

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

 

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

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

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

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

Nuovi client per  iOS, Android e Windows Phone

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

Nick Galea, CEO di 3CX dichiara:

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

Funzionalità di Centralino Virtuale Integrata

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

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

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

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

Videoconferenza Integrata aggiornata

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

Nota per i Redattori

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

www.3cx.it

Listino qui.

Download Links e Documentazione

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

Download 3CXPhone for iOS Client

Download 3CXPhone for Android Client

Download 3CXPhone for Windows Client

Download 3CXPhone for Mac Client

Download 3CX Session Border Controller for Windows

Leggi il  v14 Admin Manual

Leggi il v14 User Manual

Approfondimenti

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

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

• 3CX Phone System v14: Preview tecnica
  

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

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

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

Product/ Feature Improvements

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

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

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

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

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

Key highlights:

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

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

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

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

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

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

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

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

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

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

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

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

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

New features that were added:

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

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

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

The following bugs were squashed:

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

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

{“editor”: “chad hart“}

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

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

Don’t forget about the Data Channel!

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

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

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

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

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

Data Channel Security

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

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

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

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

The game of “Memory”

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

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

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

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

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

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

Setting up the Data Channel configuration

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

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

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

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

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

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

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

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

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

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

Set up your own Signaling layer

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

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

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

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

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

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

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

The WebRTC part of Signaling

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

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

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

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

Adding DataChannel options to RTCPeerConnection

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

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

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

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

Setting up Message Event Handlers

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

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

 

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

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

Receiving a Data Channel Message

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

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

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

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

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

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

Controlling the Memory game to flip tiles

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

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

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

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

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

Setting up a new game board

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

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

 

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

Next steps to make the game better

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

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

A completed multiplayer game using the Data Channel

Here’s a video showing the game in action:

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

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

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

{“author”: “arin sime“}

Sources:

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

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

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

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

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

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