News from Industry

If you install FreeSWITCH 1.6 on Debian 8 from official .deb packages, and then add FusionPBX on top, the server boot sequence needs a modification: now FreeSWITCH configuration depends on the presence of Postgresql server, and it would load an empty configuration if the database service is not available at the moment of start.

This fixup adds a dependency on FreeSWITCH systemd service, so that it launches only after Postgresql has started:

mkdir /etc/systemd/system/freeswitch.service.d/ cat  >/etc/systemd/system/freeswitch.service.d/fusionpbx.conf <<'EOT' [Unit] After=syslog.target network.target local-fs.target postgresql.service EOT
Filed under: Networking Tagged: freeswitch, linux, pbx, voip

Grab your copy now.

I am in the last stretch of updates for my Choosing a WebRTC API Platform report. In the past month, the report has been available at a discounted price – from $1950 down to $1250. Purchasing the report includes 1 year of updates, which means that if you get your copy now – you’ll be receiving the new update next week.

What’s new in the report?

Things are at constant change with the WebRTC ecosystem, and the best place to see it is in the API space. Since the last update, we’ve experienced the rebranding of Comverse as XURA, which affected their Forge platform as well.

Here’s what you will find in the updated report, due next week:

• Updated all vendor profiles and feature sets, so they now reflect the existing
• Added a new vendor – QuickBlox. This brings us to 24 covered platforms in the report
• I added a new KPI to the report – investment level – where I indicate for periods between updates how much investment was made in new features and capabilities in the platform. This can be an indicator to the level of commitment the vendor has to his platform and what to expect moving forward when it comes to new features being introduced
• I’ve written a new Vendor Selection Blueprint. This document can assist you in the vendor selection process by guiding you through it. It includes an Excel sheet as well as a mockup example of such a process for an imaginary use case
• Presentation deck of the visuals has been redesigned and improved, so now if you need visuals – they will be even more professional looking

What do you get when you purchase the report?

The report itself isn’t only a PDF file you print and put on your manager’s table. It includes a lot more than that:

• The report, in PDF format (obviously)
• 1 year of free updates, these will cover 1-2 more updates (I tend to publish them every 6-8 months or so)
• Site membership access to additional materials
• Online comparison matrix, to make quick comparisons easy to handle
• Presentation visuals, which you can use in your own presentations
• Vendor Selection Blueprint, to guide you through the vendor selection process
• Access to the monthly Virtual Coffee sessions as well as the archived sessions

How to purchase?

Online.

1. Go to the WebRTC PaaS report page
2. Scroll down to the end of the page
3. Select the Premium option and press the BUY NOW button
4. Use your PayPal account or a credit card to make the purchase

If you do this in the next couple of days – you are guaranteed to enjoy the discounted price.

The post Last Chance to Enjoy a $700 Discount on my WebRTC PaaS Report appeared first on BlogGeek.me.

Next week I will be joining friends old and new at PulverHWC to rediscover – How We Communicate.

Here is an email from Jeff Pulver inviting all of you to join us in Los Gatos for what is sure to be a landmark occasion.

Hope to see you there!

Erik

The Keys to the Communications Universe

Next week I return to doing the one thing that I love best – bringing together brilliant, interesting people.

Leaders, visionaries, dreamers and market makers from the worldwide communications industry have accepted my invitation to take part in the Pulver HWC Summit, May 18 – 19 at Testarossa Winery in Los Gatos, CA. I am grateful for both the people who are speaking and the tech legends who have signed up to join us for an intimate conversation. I believe understanding the message behind “How We Communicate” (“HWC”) is the next great area of growth in the communications space. Trillions of dollars of opportunity will be created and there are relationships to be forged, deals to be made, and knowledge to be shared.

There are a limited number of tickets still for sale. To join the conversation and to register, please click here. I would appreciate it if you could share this email with your friends and family involved in the communications industry.

Thank you!

Warm hugs, Jeff

The real benefits of Apple and WebRTC has been left out of the conversations.

Can you help Apple find WebRTC?

There’s been too much chatter recently about Apple adding WebRTC. I am definitely in the opinion of Fippo here:

Things are going wild on the twitter #webrtc tag. Not a day without someone writing about Apple and WebRTC. Usually with little actual information.

I am not one to say I have inside information – I don’t. I don’t even know personally any Apple employee.

What I can say for sure, is that the real discussion on why Apple is important in the ecosystem of WebRTC has been ignored – as does the only place that is important.

Apple can add WebRTC in 3 places:

1. Safari on Mac OS X
2. Safari on iOS
3. Webview on iOS

Just as a point of reference, when Google adopted WebRTC, it added it to Chrome on the desktop, then to Chrome on Android and somewhat later to Android webview. Not surprisingly, the priorities were decided based on the complexity and risk of the tasks (from the “easiest” to the most complex).

WebRTC in Mac OS X Safari

Safari on Mac OS X is nice, but at this point it won’t matter much. For the most part, Chrome is the leading browser these days – surpassing even IE; and from asking around, it seems that Mac users are used to switching from Safari to Chrome when needed – it isn’t unheard of.

Adding support for WebRTC to Safari on Mac OS X is nice, but for the most part, it won’t change things in any meaningful way.

WebRTC in iOS Safari

Safari on iOS is interesting. For iOS, there’s only a single alternative today, and that’s to port WebRTC on your own and integrate it into your app.

While this works well for most use cases, there are a few edge cases where this isn’t desirable.

Here are 4 such areas:

#1 – Porn

I had an interesting discussion two years ago with a porn vendor who wanted to start exploring WebRTC as a long term solution and a migration path from Flash.

Their main concern was that porn viewers were migrating from the desktop to their smartphones. I guess it has something to do with phone use in restrooms.

Surprisingly (or not), the main reason for him to want WebRTC was iOS. Applications on iOS require to be puritan apps to a large degree. If an app’s content doesn’t abide to the app store submission rules (and porn doesn’t), then the app won’t get approved. This becomes a kind of a headache if what you do is serve porn.

There are two ways to “fix” that today, both run in the browser (Safari on iOS that is):

1. Use HLS to stream the video, but the latency wasn’t good for this vendor. He needed low latency. In his words, “the viewer needs to be able to interact with the performer and tell her what to do”. Apparently, waiting 20 or 30 seconds until the performer responds to the viewer’s whims isn’t fast enough
2. Capture JPEG images and send them over HTML as if they are video. It means 3 frames per second or something just as stupid, but it seems porn viewers are happy with it. At least to some extent

Having WebRTC in Safari for iOS means no need to go through the approval process of Apple’s App Store, something impossible for such companies.

As you might have guessed, I learned a lot in the meeting with that company.

#2 – Click to dial

There are times when WebRTC is used for customers and potential customers to reach out to the vendor. They happen to search the internet, bump into your travel agency, and want to make a call to book a flight. Or they might have bumped into an issue with the toaster they purchased and want to ask for assistance. Whatever the case is, that person has no inclination to install an app on his phone just to make that one time interaction.

WebRTC on Safari’s iOS means that this is possible now to achieve for iOS users – and not only the Android ones.

#3 – Guest Access

In many cases, there’s a UC (Unified Communication) system already in use. While its focus is in employees communicating with each other, these systems also allow for guest access. Think of joining one of them GoToMeeting or WebEx sessions. First thing you do in them is install a client to be able to do them – or fumble around with a phone number and a PIN code. Both ugly practices.

WebRTC enables to leave that behind by sending the guest a URL in his email – not a URL with instructions in it, or an installation link – but a URL to the actual session. Along the way, you can also make that URL unique per participant if you wish. This is already available today – unless you use an iOS device.

#4 – Gaming (the gambling kind)

Apple takes 30% of all purchases made through apps. 30%

Gambling and booking usually work on profit margins that are usually lower than 10%.

That being the case, how, if at all, can they make money out of gamblers using apps without letting them pay through the app? The whole idea of gambling is the reduction of friction.

Now, getting gamblers to open a URL and play from there, with whatever interactivity they wish to add through the use of WebRTC – that’s a useful capability.

WebRTC in iOS Webview

This is where things get really interesting.

As stated earlier, most consumption on mobile today is done via apps. For WebRTC, most of these apps are developed as native apps. This happens for a couple of reasons:

1. Force of habit. That’s just life as we know it today
2. Native tends to work slightly better than HTML5 apps
3. WebRTC dictates porting it and wrapping it as an SDK on iOS today

While native is great, HTML5 is even better. It offers cross platform development capabilities across desktop, browser and mobile – and in them, across ALL operating systems. WebRTC isn’t there yet because Apple isn’t there yet.

Add to that the new technique behind PWA (Progressive Web Applications), and you may well find HTML5 enticing for your service. To support such a thing, WebRTC on iOS isn’t enough, but it is still needed. What got this piece of technology into my radar was this write up by Henrik Joreteg – Why I switched to Android after 7 years of iOS. It goes into detail on the user experience of PWAs.

Even if you decide to stick to native development, having WebRTC implemented, optimized and fine tuned by Google and Apple for their respective mobile operating systems and then just slapping a Webview in place to use them in your app is a worthwhile investment.

–

Will Apple add WebRTC to its products? Probably yes

Do we know when will it happen? No

Should we prepare for it? Maybe. You tell me

 

The post What will Happen when iOS Webviews Adopt WebRTC? appeared first on BlogGeek.me.

Time is passing fast, no doubt, feels like yesterday when we were toying with the idea of organizing a Kamailio related conference and now we are one week before its 4th edition.Every year there was an increase in the number of the attendees and we are going to run full house this edition. Of course, we take this chance to celebrate 15 years of development for Kamailio, a long journey, not always smooth, but everything ended up strengthening the project. Being the oldest very active developer, I (Daniel-Constantin Mierla) can say that Kamailio has one of the most active, challenging and pleasant to work with community, including here all the developers and users, this being the main reason of getting to where we are now with the project. Many thanks to all of you for that!Back to the next week, some last minutes updates.
The trip to Fraunhofer Fokus Institute is confirmed and if nothing unexpected happens, those that registered for workshops can choose to visit the NGNI laboratories. It will worth it, few very interesting demos will be shown on site and you can interact with some of the bleeding technologies that may shape the future of how we communicate and interact in real time with all things around us. A shuttle bus will be available to transport between Kamailio World location and Fokus institute. More details are available at:

• https://www.kamailioworld.com/k04/fokus-ngni-laboratories/

If you haven’t participated at the past editions, take a bit of time to get familiar with the address of the event:

• https://www.kamailioworld.com/k04/venue/

Like in the past, it is a single track conference, the schedule is available at:

• https://www.kamailioworld.com/k04/schedule/

The exhibitors are preparing again very interesting product or services show cases and demos for the entire duration of the conference days. Expect some local 4G/VoLTEinfrastructure from NG Voice and Core Network Dynamics. Matrix.org returns this year with an integration between SIP and the matrix federating protocol and platform.Digium will give you the chance to play with their latest SIP phones as well as see demos about the new cool Asterisk features. A consistent team from Sipwise will be around to reveal all the bits of SIP:Provider platform.Special thanks to all sponsors that allowed us to bring again an amazing group of speakers: FhG Fokus, Asipto, Sipwise, Sipgate, Simwood, Evariste Systems, Matrix.org, Digium, Core Network Dynamics, Voicetel, DIDx and Pascom.See you next with in Berlin!

This week we have a new feature in mod_callcenter adding a ring-progressively strategy, extended the XML configuration for avmd, and changes to the pastebin API for the website! Also, ClueCon 2016 is just around the corner, register today to ensure your spot! And if you would like to attend the training day on August the 12th you will need to sign-up this week! The spaces for that are very limited and we are quickly running out. Visit https://cluecon.com/ for all the information.

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

New features that were added:

• FS-9079 [mod_callcenter] Add ring-progressively strategy which is a way to ring every agent similarly to a top-down strategy but without cancelling the previous calls.
• FS-9124 [avmd] Extend XML config
• FS-9134 [core] Tweaked fscore_pb to use new pastebin API
• FS-9132 [mod_kazoo] Add more variables to default filter

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

• FS-9070 [configuration] Update config.sub and config.guess
• FS-5936 [Debian] ESL.pm packaged for Debian
• FS-9075 [Debian] Additional tweaks to help ease upgrading freeswitch-all

The following bugs were squashed:

• FS-9115 [mod_av] Initial work toward support for audio only mp4 recording
• FS-8795 [mod_png] Fixed an issue with audio only call
• FS-9131 [core] Improve validation of ice candidates to handle malformed as well
• FS-9135 [core] Handle incorrect uses of switch_core_media_set_sdp_codec_string function passing null sdp gracefully
• FS-7783 [core] Properly handle NULL var_name for switch_play_and_get_digits

Kamailio SIP Server v4.4.1 stable is out – a minor release including fixes in code and documentation since v4.4.0. The configuration file and database schema compatibility is preserved.Kamailio v4.4.1 is based on the latest version of GIT branch 4.4, therefore those running previous 4.4.x versions are advised to upgrade. There is no change that has to be done to configuration file or database structure comparing with older v4.4.x.Resources for Kamailio version 4.4.1Source tarballs are available at:

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

Detailed changelog:

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

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

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

Modules’ documentation:

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

What is new in 4.4.x release series is summarized in the announcement of v4.4.0:

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

Thanks for flying Kamailio and looking forward to meeting many of you at Kamailio World Conference 2016 next week in Berlin!

Both.

VP8 and VP9 are video codecs developed and pushed by Google. Up until recently, we had only VP8 in Chrome’s WebRTC implementation and now, we have both VP8 and VP9. This lead me to several interesting conversations with customers around if and when to adopt VP9 – or should they use H.264 instead (but that’s a story for another post).

This whole VP8 vs VP9 topic is usually misunderstood, so let me try to put some order in things.

First things first:

1. VP8 is currently the default video codec in WebRTC. Without checking, it is probably safe to say that 90% or more of all WebRTC video sessions use VP8
2. VP9 is officially and publicly available from Chrome 49 or so (give or take a version). But it isn’t the default codec in WebRTC. Yet
3. VP8 is on par with H.264
4. VP9 is better than VP8 when it comes to resultant quality of the compressed video
5. VP8 takes up less resources (=CPU) to compress video

With that in mind, the following can be deduced:

You can use the migration to VP9 for one of two things (or both):

1. Improve the quality of your video experience
2. Reduce the bitrate required

Let’s check these two alternatives then.

1. Improve the quality of your video experience

If you are happy with the amount of bandwidth required by your service, then you can use the same amount of bandwidth but now that you are using VP9 and not VP8 – the quality of the video will be better.

When is this useful?

• When the bandwidth available to your users is limited. Think 500 kbps or less – cellular and congested networks comes to mind here
• When you plan on supporting higher resolutions/better cameras etc.

2. Reduce the bitrate required

The other option is to switch to VP9 and strive to stay with the same quality you had with VP8. Since VP9 is more efficient, it will be able to maintain the same quality using less bitrate.

When is this useful?

• When you want to go “down market” to areas where bandwidth is limited. Think a developed countries service going to developing countries
• When you want to serve enterprises, who need to conduct multiple parallel video conferences from the same facility (bandwidth towards the internet becomes rather scarce in such a use case)

How is bitrate/quality handled in WebRTC by default?

There is some thing that is often missed. I used to know it about a decade ago and then forgot until recently, when I did the comparison between VP8 and VP9 in WebRTC on the network.

The standard practice in enterprise video conferencing is to never use more than you need. If you are trying to send a VGA resolution video, any reputable video conferencing system will not take more than 1 Mbps of bitrate – and I am being rather generous. The reason for that stems from the target market and timing.

Enterprise video conferencing has been with us for around two decades. When it started, a 1 mbps connection was but a dream for most. Companies who purchased video conferencing equipment needed (as they do today) to support multiple video conferencing sessions happening in parallel between their facilities AND maintain reasonable internet connection service for everyone in the office at the same time. It was common practice to reduce the internet connection for everyone in the company every quarter at the quarterly analyst call for example – to make sure bandwidth is properly allocated for that one video call.

Even today, most enterprise video conferencing services with legacy in their veins will limit the bitrate that WebRTC takes up in the browser – just because.

WebRTC was developed with internet thinking. And there, you take what you are given. This is why WebRTC deals less with maximum bandwidth and more with available bandwidth. You’ll see it using VP8 with Chrome – it will take up 1.77 Mbps (!) when the camera source is VGA.

This difference means that without any interference on your part, WebRTC will lean towards improving the quality of your video experience when you switch to VP9.

One thing to note here – this all changes with backend media processing, where more often than not, you’ll be more sensitive to bandwidth and might work towards limiting its amount on a per session basis anyway.

All Magic Comes with a Price

We haven’t even discussed SVC here and it all looks like pure magic. You switch from VP8 and VP9 and life is beautiful.

Well… like all magic, VP9 also comes with a price. For start, VP9 isn’t as stable as VP8 is yet. And while this is definitely about to improve in the coming months, you should also consider the following challenges:

• If you thought VP8 is a resource hog, then expect VP9 to be a lot more voracious with its CPU requirements
• It isn’t yet available in hardware coding, so this is going to be challenging (VP8 usually isn’t either, but we’re coping with it)
• Mobile won’t be so welcoming to VP9 now I assume, but I might be mistaken
• Microsoft Edge won’t support it any time soon (assuming you care about this Edge case)

This is a price I am willing to pay at times – it all depends on the use case in question.

 

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

 

 

The post VP8 vs VP9 – Is this about Quality or Bitrate? appeared first on BlogGeek.me.

http://ortc.org/wp-content/uploads/2016/05/ortc.html#change-log*

B.1 Changes since 01 March 2016

1. Added the gather() method, as noted in: Issue 165
2. Removed “public” from RTCIceGatherPolicy, as noted in: Issue 224
3. Removed the minQuality attribute, as noted in: Issue 351
4. Made send() and receive() asynchronous, as noted in: Issue 399, Issue 463, Issue 468 and Issue 469
5. Provided additional information on ICE candidate errors, as noted in: Issue 402
6. Added state attribute to RTCSctpTransport, as noted in: Issue 403
7. Provided an example of RTX/RED/FEC configuration, as noted in: Issue 404
8. Clarified payloadType uniqueness, as noted in: Issue 405
9. Updated the list of header extensions, as noted in: Issue 409
10. Added “goog-remb” to the list of feedback mechanisms, as noted in: Issue 410
11. Added kind argument to the RTCRtpReceiver constructor, as noted in: Issue 411
12. Clarified send() restrictions on kind, as noted in: Issue 414
13. Added getAlgorithm() method, as noted in: Issue 427
14. Changed RTCDataChannel protocol and label to USVString, as noted in: Issue 429
15. Clarified nullable attributes and methods returning empty lists, as noted in: Issue 433
16. Clarified support for the “direction” parameter, as noted in: Issue 442
17. Clarified the apt capability of the “red” codec, as noted in: Issue 444
18. Clarified usage of RTCRtpEncodingParameters attributes, as noted in: Issue 445
19. Clarified firing of onssrcconflict event, as noted in: Issue 448
20. Clarified that CNAME is only set on an RTCRtpSender, as noted in: Issue 450
21. Updated references, as noted in: Issue 457
22. Described behavior of send() and receive() with unset RTCRtpEncodingParameters, as noted in: Issue 461
23. Corrected dictionary initialization in the examples, noted in: Issue 464 and Issue 465
24. Corrected use of enums in the examples, noted in: Issue 466
25. Clarified handling of identity constraints, as noted in: Issue 467 and Issue 468
26. Clarified use of RTCRtpEncodingParameters, as noted in: Issue 470
27. Changed hostCandidate type, as noted in: Issue 474
28. Renamed state change event handlers to onstatechange, as noted in: Issue 475
29. Updated description of RTCIceGatherer closed state, as noted in: Issue 476
30. Updated description of RTCIceTransport object, as noted in: Issue 477
31. Updated description of relatedPort, as noted in: Issue 484
32. Updated description of RTCIceParameters, as noted in: Issue 485
33. Clarified exceptions in RTCDataChannel construction, as noted in: Issue 492
34. Provided a reference to error.message, as noted in: Issue 495
35. Clarified RTCRtpReceiver description, as noted in: Issue 496
36. Clarified default for clockRate attribute, as noted in: Issue 500
37. Removed use of “null if unset”, as noted in: Issue 503
38. Updated RTCSctpTransport constructor, as noted in: Issue 504
39. Clarified behavior of getCapabilities(), as noted in: Issue 509
40. Addressed issues with RTCDataChannelParameters, as noted in: Issue 519

Part of development for next major release Kamailio 5.0, we would like to announce that the framework (code-named kemi) which allows writing the routing blocks in embedded languages is already in place. At this moment, Lua or Python can be use as alternative to the native scripting language to write the routing blocks. More details can be found at:

• https://www.kamailio.org/wiki/devel/config-engines

Examples of SIP routing scripts that offer more or less same features as etc/kamailio-basic.cfg are available in source tree at examples/kemi. For convenience of reading, here are the links to git repository:

• the common file setting global and modules parameters as well as specifying the config engine:
  • https://github.com/kamailio/kamailio/blob/master/examples/kemi/kamailio-basic-kemi.cfg
• the part of config with routing blocks in native language:
  • https://github.com/kamailio/kamailio/blob/master/examples/kemi/kamailio-basic-kemi-native.cfg
• the part of config with routing blocks in Lua:
  • https://github.com/kamailio/kamailio/blob/master/examples/kemi/kamailio-basic-kemi-lua.lua
• the part of config with routing blocks in Python:
  • https://github.com/kamailio/kamailio/blob/master/examples/kemi/kamailio-basic-kemi-python.py

You can compare the last three above and see how different or similar they look for providing same SIP routing features using different languages.The work is not finished, lot of modules need to export now functions to embedded config interface, which is quite straightforward:

• https://www.kamailio.org/wiki/devel/config-engines#exporting_functions_to_kemi

Also, a missing part is handling the equivalents of event_route blocks in embedded languages, an ongoing discussion being open on mailing lists..Interesting that some incipient performance tests to compare the interpreters show good results for using especially Lua but also Python:

• https://www.kamailio.org/wiki/devel/config-engines#interpreters_performances

Anyone willing to help can start exporting functions from modules to embedded interface or test some more complex configs in Lua or Python.Thank you for flying Kamailio and looking forward to meeting many of you at Kamailio World Conference in less than two weeks!

tcpkali is a lightweight and  easy-to-use tool that allows you to generate a traffic load with multiple TCP sessions. You push the load in one or both directions at the same time. Also the tool works easily over a NAT’ed connection. This tool is great if you need to test QoS for VoIP applications.

Here’s an example of a bidirectional load test:

# listening machine: listen on tcp port 8000, send traffic, and use 4 threads. # the program will exit in 1 hour. tcpkali -l 8000  --listen-mode=active -m X -T 1h -w 4 # connecting machine: send traffic using 4 threads and 10 simultaneous sessions # for 1 minute tcpkali 192.168.1.109:8000 -m Y -c 10 -T1m -w 4

The above test between directly connected PC Engines APU2 boards has shown 1Gbps of traffic, and the average CPU load was about 50%.

Filed under: Networking Tagged: linux, networking, pcengines, testing, voip

The FreeSWITCH 1.6.8 release is here!

With the release of FreeSWITCH 1.6.8 we see some major improvements in the .deb based packaging. Included in this release is a fix for the freeswitch-all package. Prior to this fix, if certain FreeSWITCH Extensions were not included in the -all package, and a user attempted to install that extension via its stand-alone freeswitch-mod-extension-name package, it was possible to leave the system in a broken state. This fix does make a substantial change to the freeswitch-all package and the number of dependencies included via this package. Due to this change, a bare “apt-get upgrade” will not upgrade the package automatically and you will need to either call ‘apt-get dist-upgrade’ or call ‘apt-get upgrade freeswitch-all’ explicitly. This also brings the freeswitch-all package in line with the freeswitch-meta-all package.

Additionally with these packaging changes, Packages are now available for Ubuntu 14.04. Please see https://freeswitch.org/confluence/display/FREESWITCH/Ubuntu+14.04+Trusty for Ubuntu installation instructions.

This is also a routine maintenance release. Change Log and source tarball information below.

Release files are located here:

• Tarball: http://files.freeswitch.org/releases/freeswitch/freeswitch-1.6.8.tar.gz
• Packaging: https://freeswitch.org/confluence/display/FREESWITCH/Installation

New features that were added:

• FS-8983 [mod_avmd] Enable on outbound channel to make debugging easier
• FS-8875 [mod_avmd] Enable faster beep detection
• FS-9019 [mod_avmd] Extend syntax description to include “[start|stop]” at the end of AVMD_SYNTAX ” “
• FS-9023 [mod_avmd] Add console auto completion
• FS-9020 [mod_avmd] Implement checking of proper configuration of avmd session being started on internal/external channels. Check for read/write codec, CF_MEDIA_SET
• FS-9027 [mod_avmd] Remove assertion from INIT_CIRC_BUFFER and check buffer’s pointer to raw memory dynamically
• FS-9028 [mod_avmd] Check SMA buffer for successful memory allocation
• FS-9031 [mod_avmd] Check session initialization for errors
• FS-9039 [mod_avmd] Use FS enumeration
• FS-9050 [mod_avmd] Fixed APP interface so avmd now exposes single avmd_start_function() for handling APP calls and splits the function into independent calls
• FS-9124 [mod_avmd] Extend XML config
• FS-9024 [mod_avmd] Add events on session start/stop
• FS-9011 [mod_avmd] Add xml configuration file so that avmd parameters can be set by users in this file easily
• FS-8688 [mod_vpx] Implement vp9 processing to avoid chrome hang
• FS-8990 [mod_verto] Adding verto_login header to verto::client_disconnect event
• FS-9077 [mod_verto] Adding verto_hangup_disposition variable to indicate who hangup
• FS-8991 [verto_communicator] Adding translations for French. Thanks Tristan Mahé
• FS-8989 [verto_communicator] Adding Portuguese i18n translations
• FS-8998 [verto_communicator] Adding German, Spanish, Catalan, Chinese, Polish, Russian, Swedish and Indonesian translations.
• FS-8972 [verto_communicator] Add i18n using angular-translate and static file loader
• FS-9038 [verto_communicator] Add translations to support Danish
• FS-9006 [verto_communicator] Add-combobox for languages
• FS-9100 [mod_conference] Set recording failure error if there are zero webcams enabled in a conference and set conference flags or conference member flags with individual variables per flag
• FS-9106 [mod_conference][libvpx] Minor modifications to make vpx in dedicated encoder mode use less cpu, upped the default FPS to 30, and added a new version of previous sleep patch
• FS-8992 [core] Indicate end of candidates in SDP to aid in the resolution of an interop issue with Mozilla
• FS-9134 [core] Tweaked fscore_pb to use new pastebin API
• FS-9052 [mod_hiredis] Add connection pooling, improve dropped connection resiliency, and allow 0.10.0 of hiredis for CentOS 6
• FS-9054 [mod_hiredis] Add ignore-connect-fail profile parameter so that calls do not get killed if limit fails due to lost connection
• FS-9059 [mod_hiredis] Add session logging
• FS-9078 [libsofia] Added hepv2 and hepv3 support, added #pragma for MSVC compiler, and fixed the Windows build of HEPv2/HEPv3 code
• FS-9083 [mod_sofia] Pass On SIP headers from leg A to B
• FS-7125 [mod_sofia] Added an event “wrong_calls_state”. This is for fail2ban logging.
• FS-9080 [mod_spy] Making mod_spy work with Verto channels
• FS-9072 [mod_syslog] Allow logging of messages containing tab character
• FS-9043 [mod_kazoo] Add kz_export of multiple variables instead of calling export application
• FS-9025 [mod_callcenter] Bypass_media_after_bridge working for member channel
• FS-9079 [mod_callcenter] Add ring-progressively strategy which is a way to ring every agent similarly to a top-down strategy but without cancelling the previous calls.

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

• FS-9036 [mod_avmd] Fix warnings on Windows builds
• FS-8988 [mod_avmd] Rename files to include avmd in their name.
• FS-8875 [mod_avmd] Fixed the windows build from this change
• FS-8971 [mod_amqp] There are two different status variables with two different meanings. This splits them back apart.
• FS-8933 [scripts] WIP Fix some breakage on Raspbian as we don’t want the FS repos there yet because we don’t have armhf packages at this time
• FS-8623 [build] Fixed Solaris studio build errors building libvpx
• FS-8780 [build] Fixed the include for Windows builds that point to in tree library
• FS-8883 [build] Fixed compiling due to unused result failure on gnu compiler with –disable-debug
• FS-9000 [build] Fixed compiling on bsd and with libyuv disabled
• FS-9109 [build] A fix for misleading indentation errors on gcc 6.0
• FS-9070 [build] Update config.sub and config.guess to prevent configure failing on arm64
• FS-9091 [build][libyuv] Update libyuv to hash 69245902 from https://chromium.googlesource.com/libyuv/libyuv/ and set it to build all platform files so we don’t have missing symbols on some platforms
• FS-8623 [build][configure] Fixed Solaris studio error trying to compile char[] with c++ compiler and fixed an issue with a necessary flag having issues with the libvpx configure
  FS-8779 [Windows] Fixed the include for Windows builds that point to in tree library
• FS-9075 [Debian] Fix-up for systemd and sysvinit, re-worked the freeswitch-all package, removed some meta-all dependencies that are causing issues, tweaked the freeswitch-meta-all dependencies to more fully install FreeSWITCH, and tweaked the dependencies for freeswitch-init
• FS-9081 [Debian] Use turbo if available for newer jpeg over falling back to old jpeg62-dev
• FS-5936 [Debian] ESL.pm packaged for Debian
• FS-9093 [mod_cv] Remove unnecessary includes

The following bugs were squashed:

• FS-8982 [core] Fixed an issue with play_fsv and play_yuv writing blank_img in parallel
• FS-8918 [core] Fixed an issue with a 10 Second timeout after Notify during Proxy refer
• FS-9002 [core] Fixed an issue with rtp timeout code parsing on video but its designed for audio
• FS-8757 [core] Fixed a buffer overflow in switch_channel_expand_variables_check and switch_event_expand_headers_check
• FS-8949 [core] Fixed an issue with the send end packet for DTMF RTP event not being recognized
• FS-9042 [core] Fixed assert when recording native file
• FS-9062 [core] Fixed a jittery voice issue caused by OPUS mid-call change from 20ms to 40 ms
• FS-9131 [core] Improve validation of ice candidates to handle malformed as well
• FS-9099 [core][sofia-sip] Fixed an issue caused by the web-socket raw frame read timeout being too short and fixed the windows build of web-socket transport
• FS-9078 [sofia-sip] Fixed the linux build of HEPv2/HEPv3 code
• FS-8913 [mod_sofia] Fixed a transfer issue when using bypass_media + SRTP + Inbound late negotiation
• FS-8562 [mod_sofia] Add update support for Mitel user agents
• FS-9049 [mod_sofia] Fixed a DTMF issue
• FS-9060 [mod_sofia] Correct issues with hold and broken soa negotiations after performing a bypass media re-invite
• FS-9086 [mod_conference] Fixed the video files playing in the conference not counting in totals for calculating layout
• FS-8749 [mod_conference] Fixed an issue when loading a video (mp4) for a conference using the “conference play” command “conference pause_play”
• FS-9076 [mod_conference] Added an error prompt to notify that a conference can’t be recorded in pass-thru mode
• FS-8993 [mod_av][mod_conference] Fixed a sync issue on conference playback for a video that is faster frame rate than the conference
• FS-9056 [mod_av] Fixed an issue causing mobile H.264 video to be blank
• FS-8995 [verto_communicator] Added missing toastr in settings controller
• FS-8990 [verto communicator] Added verto_client_address to verto and presence events
• FS-8996 [verto_communicator] Fixed a typo in CAMERA_SETTINGS id and added some Italian translation
• FS-8997 [verto_communicator] Fixed fallbackLanguage
• FS-9012 [verto_communicator] Fixing sidebar in narrow resolutions clipping the video
• FS-9015 [verto_communicator] Minor fixes in Polish translation
• FS-8999 [mod_erlang_event] Fixed broken outbound connection
• FS-9004 [mod_http_cache] Set http get timeout on thread that is actively downloading with the value from the download-timeout configuration and added download-timeout parameter to prevent http_get from waiting unbound time for downloading to finish. Prevented prefetch threads from blocking if another thread is already downloading the same URL.
• FS-7317 [mod_event_socket] Fixed a hang caused by a series of blocks
• FS-8294 [freetdm] Pass in modinstdir to freetdm configure
• FS-9016 [mod_avmd] Fixed a segfault on NULL read codec
• FS-9057 [mod_rtmp] Fixed an issue with screen share feed not taking the floor if the webcam is muted and unmuted
• FS-9058 [mod_hiredis] Allow auto decrement of non-interval limits on channel hangup and fix rate counters so the keys expire after interval completes. Do not auto decrement rate counters. Do not log null responses.
• FS-9074 [mod_skinny] Fixed incorrect location of free causing memory leak of xml when certain errors occur
• FS-9082 [mod_java] Fixed an issue with loading prerequisites if modules are not placed in prefix/mod directory
• FS-9115 [mod_av] Initial work toward support for audio only mp4 recording
• FS-8795 [mod_png] Fixed an issue with audio only call

Session Description Protocol (SDP) is a fundamental, but very unintuitive concept behind how WebRTC works today. Its no wonder that the Anatomy of a WebRTC SDP post and the interactive SDP guide by Quobis CTO, Antón Román has been so popular here on webrtcHacks. With all things WebRTC, things have changed and we were due for an […]

The post Update: Anatomy of a WebRTC SDP (Antón Román) appeared first on webrtcHacks.

How will we be able to live in a world without… SDP?

The one thing I love best about the WebRTC Standards website is that it looks at a place I neglect most of the time – the IETF and W3C. While I had my share of dealings with standardizaton organizations when I was young and pretty, it isn’t something I like doing much these days.

Last month, it seems a decision was made/in the process of being made – to prohibit SDP munging. As these things go, if this happens at all it will take VERY long to happen. That said, such a change will have huge impact on a lot of services that make use of this practice.

What’s WebRTC SDP munging?

SDP munging is a process of a WebRTC application taking its future in its own hands and deciding to change the SDP. With WebRTC, once the application sets the user media and connects it with a peer connection (=setting up to start a session), it receives the SDP blob that needs to be sent to the other participant in the session. This blob holds all of its capabilities and intents for the session.

If you want to learn more about the contents of the SDP, then this article on webrtcHacks will get you started.

Here’s a quick flow of what happens:

Where SDP munging takes place in WebRTC

Now that the application holds the SDP blob, the question that must be asked is what can the application should/can do with this SDP blob?

1. The application should pass it to the other participant. Probably by placing it in an HTTP request or a Websocket message
2. The application can change it (=mung it) before well… setting and sending it

The problem is in that second part.

What’s the problem with WebRTC SDP munging?

SDP embodies everything that is wrong about SIP. Or at least some of what’s wrong about SIP

There are several aspects to it:

1. Being a textual kind of a protocol that is open as hell, it is open to interpretation of humans, making it hard to use. Interoperability is a headache with it, and now we’re leaving it at the hands of web developers. It becomes doubly hard, as there are extensions to SDP – some standardized, some in process and some just proprietary ones. And you need to sift between them all to decide what to do on the SDP level
2. When you modify the SDP, it is assumed that the browser needs to interpret your modifications. Since it already created an SDP, it had its own understanding of what you want, but now he needs to interpret it yet again but instead of doing that through an API, it needs to do it via an ugly text blob. And browsers are created by humans, so they might not interpret it the same way you did when you munged it – or different browsers might interpret it differently
3. New browser versions might not be able to interpret what you munged simply because that isn’t part of their main focus. The smaller you are, the more susceptible you will be to practicing SDP munging – what you do there might not be as popular as you though (or not defined as popular by browser vendors) – and it will break in some future version
4. SDP isn’t that fun to modify with JavaScript. So it frustrates developers which ends up leading to more bugs and inconsistencies

What happens if and when it gets prohibited?

When SDP munging gets banned, existing applications that rely on it will break.

They might break completely, but mostly, they’ll break in ways that are less predictable – codecs won’t be configured in the exact way the developer intended, bitrates won’t be controlled properly, etc.

The whole idea behind SDP munging is to get more control over what the browser decides to do by default, so disabling it means losing that control you had.

When is this change expected?

Not soon, if at all.

That said, I wouldn’t recommend ignoring it.

What I’ve understood is that there’s little chatter about this on the standards mailing lists, so this just might die out.

The reason I think it is important is because at the end of the day, munging the SDP leaves you prone to whims of browser vendors as well as leaves you open to this future option of banning SDP munging.

What should you do about it?

First of all – don’t worry. This one will take time. That said, better plan ahead of time and not be surprised in the future. Here’s what I’d do:

1. Refrain from practicing SDP munging as much as possible
2. Since we’re already starting to see some of the ORTC APIs tricking into WebRTC, you should make an active investment now and in the near future to use these APIs whenever you feel the urge to make changes in the SDP (that’s assuming what you need is supported in the API level and not only via the SDP)
3. If you aren’t sure, then check the code you have to see if you are practicing SDP munging, and if you are, make some kind of a plan on how to wean yourself from it

 

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

The post What if WebRTC SDP Munging was Prohibited? appeared first on BlogGeek.me.

This week there were improvements to mod_conference and libvpx and the addition of a xml configuration file to avmd to allow for easily configurable parameters.

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

New features that were added:

• FS-9106 [mod_conference][libvpx] Minor modifications to make vpx in dedicated encoder mode use less cpu, turned up default FPS to 30, and added a new version of previous sleep patch
• FS-9011 [avmd] Add xml configuration file so that avmd parameters can be set by users in this file easily

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

• FS-9109 [build] A fix for misleading indentation errors on gcc 6.0
• FS-9100 [mod_conference] Set recording failure error if there are zero webcams enabled in a conference
• FS-9078 [sofia-sip] Fixed the Windows build of HEPv2/HEPv3 code
• FS-9075 [Debian] Fix-up for systemd and sysvinit
• FS-9075 [Debian] Tweaked the freeswitch-meta-all dependencies to more fully install FreeSWITCH
• FS-9075 [Debian] Removing some meta-all dependencies that are causing issues
• FS-9075 [Debian] Tweaks to the dependencies for freeswitch-init

The following bugs were squashed:

• FS-9076 [mod_conference] Added an error prompt to notify that a conference can’t be recorded in pass-thru mode
• FS-9086 [mod_conference] Fixed the video files playing in the conference not counting in totals for calculating layout
• FS-9062 [core] Fixed a jittery voice issue caused by OPUS mid-call change from 20ms to 40 ms
• FS-9099 [sofia-sip][core] Fixed the windows build of web-socket transport and fixed an issue caused by the web-socket raw frame read timeout being too short
• FS-9078 [sofia-sip] Fixed the linux build of HEPv2/HEPv3 code

If the only thing you have is IP calling, then why are you investing in a Slack integration this late in the game?

Looking for gold in Slack by adding WebRTC calls to it?

Slack is a rising star. It has a small and growing set of users, some of which are happy to pay for the service. When it works, it is great. When it doesn’t, well… it then just feels like any other UC or enterprise communication service. I find myself using Slack more and more. Not necessarily because I need to, but rather because I am drawn to it by the teams I collaborate with. I like the experience.

In the last few months it seems that everyone is rushing to Slack, trying to build their own WebRTC integration with it. The latest casualty? LyteSpark.

Browsing Slack’s App Directory, I found the following WebRTC based services under the Communications category:

• Google Hangouts
• Skype
• appear.in
• GoToMeeting free
• Room
• UberConference
• Limnu
• Blue Jeans
• Screenleap
• Yodel
• Videolink2.me
• Quickchat
• KOMASO

There are others, not in the marketplace, and probably a few others in other categories or ones that I just missed.

The problem with many of them is that Slack is actively adding VoIP now – using WebRTC of course.

As I always stated, WebRTC downgrades real time communications from a service to a feature. And now, Slack is adding this feature themselves.

The problem now becomes that these WebRTC services are competing with the built-in feature of Slack – something that will be infinitely easier and simpler to use – especially on mobile, where it is just there. What would be the incentive then to use a Hangouts bot when I can just start the same functionality from Slack without any integration? This is doubly so for free accounts, which are limited to 10 integrations.

The only WebRTC services that can make sense in such a case, are those that have some distinct added value that isn’t available (or easily available through roadmap of Slack). It boils down to two capabilities:

1. Seamless integration with PSTN calling. This is what OttSpott does. I think this is defensible simply because I don’t see Slack going after that market. They will be more inclined to focus on IP based solutions. Just a gut feeling – nothing more
2. Solving a higher level problem than pure voice or video calling. Maybe a widget integration with the customer’s website for click-to-call capabilities, though it can be some other capabilities that focus on a smaller niche or vertical

This Slack-rush of WebRTC services seems a bit unchecked. Basking under the light of WebRTC doesn’t work anymore, so time to move to some other hype-rich territory, and what better place than Slack? Problem is, without a real business problem to solve (conducting a video call over the web isn’t a business problem), Slack won’t be the solution.

 

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

The post The WebRTC Slack-Rush appeared first on BlogGeek.me.

GPUs is most probably where we’re headed.

A couple of months ago, I was approached by SURF. An Israeli vendor specializing in server media processing. As many of its peers, SURF has been migrating from hardware based DSP systems to software systems in their architecture. As they’ve entered the WebRTC space, they wanted to have a whitepaper on the topic, and I accepted the challenge.

The end result? WebRTC Server Side Media Processing: Simplified

Download the whitepaper

Two things that I wanted to share here:

#1 – WebRTC Server Side Media Processing is real

What made writing this whitepaper so interesting for me was the fact that there really is a transition happening – not to using WebRTC – that already happened as far as I can tell. It is something different. A transition from simple WebRTC services that require a bit of signaling to services that process the media in the backend. This processing can be anything from recording to gatewaying, streaming, interoperating or modifying media in transit. And it seems like many commercial use cases that start simple end up requiring some kind of server side media processing.

In the span of the last two months, I’ve seen quite a few services that ended up building some WebRTC server side media processing for their use case. Maybe it is just related to the research I did around this are for the whitepaper, but I think it is more than that.

#2 – The Future Lies in GPUs

As I was working on the whitepaper, this one got published by Jeff Atwood – it is about AI winning a game of Go. Or more accurately, how GPUs are a part of it:

GPUs are still doubling in performance every few years

The whole piece is really interesting and a great read. It also fits well with my own understanding and knowledge of video compression (=not that much).

Two decades ago, video compression was a game of ASIC – the ugliest piece of technology possible. Hard to design and develop. You wanted to implement a new video codec? Great. Carve a few years for the task and a couple of millions to get there. They are hard to design and hard to program for.

Later it was all DSP. Still hard and ugly, but somewhat cheaper and with some flexibility as to what can get done with them. DSPs is what powers most of our phones when it comes to recording and playing back videos. It works pretty well and made it seem as if the device in our pocket is really powerful – until you try using its CPU like a real PC.

GPUs were always there, but mostly for gaming. They do well with polygons and things related to 2D and 3G graphics, but were never really utilized for video compression. Or at least that’s what I thought. I heard of CUDA in passing. Heard it was hard to program for. That was something like 5 years ago I believe.

Then I read about GPUs being used to break hashes, which was an indication of their use elsewhere. The Jeff Atwood piece indicated that there are other workloads that can benefit from GPUs. Especially ones that can be parallelized, and to some extent, video compression is such a task. It is also where SURF is focusing with its own server media processing, which places them in the future of that field.

GPUs are no longer used only for gaming or in our PCs and laptops – they are also being deployed in the cloud. They assist companies running Audocad in the cloud (heard such a story in the recent WebRTC Global Summit event), so why not use them for video compression when possible?

–

If you are interested in WebRTC and how media processing is finding its way to the server, and how that fits in with words like cloud and GPU, then take a look at this new whitepaper. I hope you’ll enjoy reading it as much as I’ve enjoyed writing it.

Download and read this new WebRTC whitepaper.

The post WebRTC and Server GPUs? A whitepaper appeared first on BlogGeek.me.

A new module named NSQ has been imported in Kamailio’s GIT repository, authored by Emmanuel Schmidbauer from Weave Communications. Emmanuel has become also a registered developed in order to maintain the module.In short, the module provides a NSQ connector for Kamailio configuration file, allowing to interact with NSQ servers from kamailio.cfg. NSQ is a real time distributed messaging platform, you can read about NSQ at nsq.io.More about the NSQ module is available at:

• http://www.kamailio.org/docs/modules/devel/modules/nsq.html

The module will be part of the future major release Kamailio v5.0.0! While waiting for that release you can play with NSQ using the git master branch.Thank you for flying Kamailio!

Progressing nicely – of course.

Checking the pulse of WebRTC

It’s been 5 years since WebRTC came to our lives. Different people count it from different times. I heard in the last month or two the years 2009, 2010 and 2011 stated as the year of birth of WebRTC. While no one should really care, for me, WebRTC started with Google’s announcement of WebRTC in May 2011. It was the first time Google publicly stated its plans for its GIPS acquisition, and it came out as an open source package that was planned to get integrated into browsers and be called WebRTC. I was a CTO at a business unit licensing VoIP products to developers. The moment I saw it, I knew everything was going to change. It was one of the main reasons I left that job, and got to where I am today, so it certainly changed everything for me.

As we head towards Mat of 2016, it is time to look a bit at the 5 years that passed – or more accurately the 5th year of WebRTC.

One one hand, it seems that nothing changed. A year ago, Chrome and Firefox supported WebRTC. That’s on Windows, Mac OS X, Linux and Android. Today, we’re pretty much in the same position.

On the other hand, adoption of WebRTC is huge and its impact on markets is profound; oh – and both Microsoft and Apple seem to be warming up to the idea of WebRTC – each in his own way.

If you are interested in a good visual, then my WebRTC infographic from December 2015 is what you’re looking for. If it is numbers and trends today, then read on.

951 Vendors and Project – and growing

I’ve been tracking the vendors and projects of WebRTC since 2013, actively looking for them and handpicking relevant projects that are more than 10 lines of code and any vendor I saw. It turned into one of the services I have on offer – access to this actively growing (and changing) dataset of WebRTC vendors.

Earlier this month, the WebRTC dataset had the following interesting numbers:

• 951 vendors and projects that I track
  • There are a few that shutdown throughout the years, but not many
  • There are a few that I know of and don’t make it into the list, because they want to remain private at this point
  • There are data points I’ve stored and haven’t processed yet – many of them additional vendors (got around 80 in my backlog at the moment)
• 2015’s average was 26 vendors added every month
• 2016 shows a slight increase to that average. 3-4 months aren’t enough to make this definitve yet
• For now, there are 41 acquisitions related to WebRTC in one way or another
  • Some of them are less relevant, such as Mitel acquiring Polycom
  • Others are all about WebRTC, such as Talko’s acquisition by Microsoft

What is interesting is that these vendors and projects are always evolving. They aren’t only limited to startups or large enterprises. They aren’t specific to a certain vertical. They cut through whole industries. Just this week a new use cases popped – movers who can give a price quote without being on site. Will it fly? Who knows.

We’ve been witnessing a surge in communication services. We are not limited today by concepts of Telephony or Unified Communications. These became use cases within a larger market.

What is different now is that the new projects and vendors don’t come with VoIP pedigree. They are no longer VoIP people who decided to do something with WebRTC. Most of them are experts in communications – not digital communications, but communications within their own market niche. Check out the interview from last week with Lori Van Deloo of BancSpace – she knows her way in banking.

API Platforms are Maturing

Communication API platforms using WebRTC are maturing. Many of them have the basics covered and are moving further – either vertically or horizontally. Vertically by deepening their support of a specific capability or horizontally by adding more communication means. You can read my WebRTC API report on it. I am in the process of updaing it.

What is interesting is how this space is being threatened from two different domains:

1. Unified Communication platforms turned Enterprise Messaging turned developer ecosystems. Cisco Spark and Unify’s Circuit are such examples. They are an enterprise UC solution that can be used (and is actively being marketed as) a long tail development platform for general communication needs
2. Specialized component vendors who are offering widgetized approach of their service, enabling its integration elsewhere. Gruveo, appear.in and Veeting do it a lot; Drum ShareAnywhere and a lot of others are also examples of it

This is affecting the decision making process of those who need to roll out their own services, making the technology more accessible, but at the same time more complex and confusing when the time comes to pick a vendor to lean on.

Verticals are Fragmenting Further

What does a communication solution in healthcare looks like?

If you ask a Unified Communications vendor, it will be able having a room system everywhere and enabling doctors/nurses/patients communicate.

I had conversations with these types of health related vendors:

• Contact centers for doctor visitations of a healthcare insurer
• IOT measurement device a user takes home, connects to the phone and from there to a doctor
• Online group treatment
• Serving rural areas from an established hospital in developing countries
• Assisting/learning/teaching/participating in remote surgery
• Medical tourism
• Counseling for enterprise employees
• Care for seniors
• Secure messaging for doctors
• Medical clowns
• Fitness related

Each of these is a world unto its own, and to think we’ve looked at them all through the prism of Unified Communications or even the “healthcare vertical”.

WebRTC brought with it the ability to hone in on specific market needs.

–

WebRTC is already ubiquitous. As with any technology, its has its rough edges and challenges.

I’ve dealt with developing VoIP products for the better part of the last two decades – I can tell you hands down that never before did we have the alternatives to do what we can today. If you have VoIP on your mind, then WebRTC should be the first thing to try out as a component in your solution.

The post Where are we with WebRTC? appeared first on BlogGeek.me.

Lorenzo will be talking about the SIPCAPTURE stack HOMER. “A robust, carrier-grade and modular VoIP and RTC Capture Framework for Analysis and Monitoring with native support for all major OSS Voice platforms and vendor-agnostic Capture agents. HOMER counts thousands of deployments worldwide including notorious industry vendors, voice network operators and fortune 500 enterprises, providing advanced search, end-to-end analysis and packet drill-down capabilities for ITSPs, VoIP Providers and Trunk Suppliers using and relying on VoIP services and RTC technologies – All 100% Open-Source.”