News from Industry

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.”

The kamailio.org website has been updated to use a responsive theme. The old skin was built during 2010-2011, the corresponding wordpress theme was not updated for few years, lacking the responsive layout.The new look keeps the same clean and clear approach. One of the major changes was the need to widget-ize the sidebar on the right, which used to be the main navigation menu for most of the resources provided by Kamailio project. Several of them were left on the new right sidebar and the rest along with new resources were indexed by the menus at the bottom of the pages.The main page for kamailio.org is planned to be reorganized with a fresh design in the near future as well, building on top of the framework provided by the new wordpress template.Suggestions on how to organize the website and its menus for better accessibility or more suggestive navigation are very welcome! Email us to .Thank you for flying Kamailio!

This week we added support for hepv2 and hepv3 in sofia! Also, mod_spy now works with verto channels.

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-9078 [libsofia] Added hepv2 and hepv3 support and added #pragma for MSVC compiler
• FS-9083 [mod-sofia] Pass On SIP headers from leg A to B
• FS-9080 [mod_spy] Making mod_spy work with Verto channels
• FS-9024 [avmd] Add events on session start/stop

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

• FS-9091 [build][libyuv] Update libyuv to hash 69245902 from https://chromium.googlesource.com/libyuv/libyuv/ and build all platform files so we don’t have missing symbols on some platforms
• FS-9093 [mod_cv] Remove unneeded includes
• FS-9081 [Debian] Use turbo if available for newer jpeg over falling back to old jpeg62-dev

The following bugs were squashed:

• FS-8757 [core] Fixed a buffer overflow in switch_channel_expand_variables_check and switch_event_expand_headers_check
• FS-9057 [mod_rtmp] Fixed an issue with screen share feed not taking the floor if the webcam is muted and un-muted
• FS-9082 [mod_java] Fixed an issue with loading prerequisites if modules are not placed in prefix/mod directory
• FS-9060 [mod_sofia] Correct issues with hold and broken soa negotiations after performing a bypass media re-invite

Well… Almost.

For those who haven’t been following the path Skype is taking, here’s a quick recap of the last year or so:

• Lync got “merged” with Skype, rebranding it as Skype for Business – so now all of Microsoft’s voice and video calling services are Skype
• Skype for Web was announced at about the same time
• A Skype SDK was launched
• And now, Skype for Web is running on Microsoft Edge without any plugin installation
• Oh, and they announced bots too

Skype on Edge sans plugins was to be expected

That last bit near the end? Of Skype not needing plugins when executed on Edge? That was rather expected.

Microsoft is hard at work on adding RTC to Edge – be it ORTC or WebRTC – or both.

The main UC and consumer messaging service of Microsoft are based on Skype, so it is only reasonable to assume that Skype would be utilizing Edge capabilities in this are AND that Edge would be accommodating for Skype’s needs.

This accommodation comes by way of the first video codec that Edge supports – H.264UC – Skype’s own proprietary video codec. Edge doesn’t interoperate with any other browser when it comes to video calling due to this decision. In a way, The Edge team sacrificed interoperability for Skype support.

Browser vendors tend to care for themselves first. And then for the rest of the industry:

• Google Chrome does that by having undocumented features for Google Hangouts
• Mozilla Firefox does that by working with Cisco on H.264 & Telefonica on Hello
• Microsoft Edge does that by sacrificing video interoperability for Skype support
• Apple Safari does that… by not doing WebRTC favoring its FaceTime?

Google Hangouts route to plugin-less world

Hangouts today is in the same predicament as Skype in a lot of ways.

1. Its support for the browser of the mothership is native (Chrome-Hangouts; Microsoft-Skype)
2. Both require plugins on browsers other than their own – and will stay that way for the forseable future
3. Both are no consumer/enterprise services, trying to cater both
4. Both aren’t as big or as active as their newer competitors (Facebook, WhatsApp and WeChat to be specific)

Where do they diverge?

No Plugin+SDK=Interesting

Skype has added the SDK bit before Hangouts.

Skype now offers its large user base and infrastructure to 3rd party developers to build their own services. The documentation is quite extensive (too much to go through to get things done if you ask me – especially compared to the WebRTC API platforms) and the intent is clear.

Skype doesn’t have a glorious record with developers. Maybe this time around it will be different.

And it added bots.

They did that ahead of the rumored bot support by Google.

Where’s Hangouts?

Meanwhile, Hangouts is just the same as it were two or three years ago.

The backend probably changed. It now sometimes do P2P calling. And it has a new UI. And the old one. And you can never know which one will pop up for you. Or where to write (or read) that text message.

Something needs to change and improve with Hangouts.

Skype seems to be moving forward at a nice pace. Cisco Spark has its own forward motion.

But Hangouts has stalled – especially considering we’re talking about Google – a company that can move at breakneck speeds when needed.

I wonder what’s ahead of us from both these services.

The post Skype will go the Hangouts Route with WebRTC (or vice versa?) appeared first on BlogGeek.me.

Since July, 2013, the W3C Object Real-Time Communications (ORTC) Community Group has been actively working on a next generation WebRTC API, called ORTC. Robin will discuss the latest updates of the ORTC API, the remaining challenge areas, and the implementation status of ORTC-lib. And he will show the detailed event capabilities for ORTC-lib.

Links:
http://ortc.org/
http://hookflash.com/

Two weeks ago Microsoft’s Bernard Aboba (and former webrtcHack’s interviewee) gave an update on Edge’s ORTC and WebRTC at the Microsoft Build conference. He covered some big topics including VP8 and WebRTC 1.0 support. You can see the update video here or read the follow-up post for details. Then last week Microsoft announced plug-in free Skype […]

The post Sharpening the Edge – extended Q&A with Microsoft for RTC devs appeared first on webrtcHacks.