News from Industry

HTTP/2 is too good to pass.

If you don’t know much about HTTP/2 then check this HTTP/2 101 I’ve written half a year ago.

In essence, it is the next version of how we all get to consume the web over a browser – and it has been standardized and deployed already. My own website here doesn’t yet use it because I am dependent on the third parties that host my service. I hope they will upgrade to HTTP/2 soon.

Watching this from the sidelines, here are 4 good reasons why you should be using HTTP/2. Not tomorrow. Today.

#1 – Page Load Speed

This one is a no-brainer.

A modern web page isn’t a single resource that gets pulled towards your browser for the pleasure of your viewing. Websites today are built with many different layers:

• The core of the site itself, comprising of your good old HTML and CSS files
• Additional JavaScript files – either because you picked them yourself (JQuery or some other piece of interactive code) or through a third party (Angular framework, ad network, site tracking code, etc.)
• Additional JavaScript and CSS files coming from different add-ons and plugins (WordPress is fond of these)
• Images and videos. These may be served from your server or via a CDN

At the time of writing, my own website’s homepage takes 116 requests to render. These requests don’t come from a single source, but rather from a multitude of them, and that’s when I am using weird hacks such as CSS sprites to reduce the number of resources that get loaded.

There’s no running away from it – as we move towards richer experiences, the resources required to render them grows.

A small HTTP/2 demo that CDN77 put in place shows exactly that different – they try loading 200 small images to a page in either HTTP/1.1 or HTTP/2 shows the improved load times of the page.

HTTP/2 has some more features that can be used to speed up web page serving – we just need to collectively start adopting it.

#2 – Avoiding Content Injection

In August, AT&T was caught using ad injection. Apparently, AT&T ran a pilot where people accessing the internet via its WiFi hotspots in airports got ads injected to the pages they browsed over the internet.

This means that your website’s ads could be replaced with those used by a third party – who will get the income and insights coming from the served ads. It can also mean that your website, that doesn’t really have ads – now shows them. The control freak that I am, this doesn’t sound right to me.

While HTTP/2 allows both encrypted and unencrypted content to be served, only the encrypted variant is supported by browsers today. You get the added benefits of encryption when you deploy HTTP/2. This makes it hard to impossible to inject 3rd party ads or content to your site.

#3 – Granularity

During that same August (which was the reason this post was planned to begin with), Russia took the stupid step of blocking Wikipedia. This move lasted less than a week.

The reason? Apparently inappropriate content in a Wikipedia page about drugs. Why was the ban lifted? You can’t really block a site like Wikipedia and get away with it. Now, since Wikipedia uses encryption (SPDY, the predecessor of HTTP/2 in a way), Russia couldn’t really block specific pages on the site – it is an all or nothing game.

When you shift towards an encrypted website, external third parties can’t see what pages get served to viewers. They can’t monetize this information without your assistance and they can’t block (or modify) specific pages either.

And again, HTTP/2 is encrypted by default.

#4 – SEO Juice

Three things that make HTTP/2 good for your site’s SEO:

1. Encrypted by default. Google is making moves towards giving higher ranking for encrypted sites
2. Shorter page load times translate to better SEO
3. As Google migrates its own sites to HTTP/2, expect to see them giving it higher ranking as well – Google is all about furthering the web in this area, so they will place either a carrot or a stick in front of business owners with websites

 

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

The post 4 Good Reasons for Using HTTP/2 appeared first on BlogGeek.me.

Hello, again. This past week in the FreeSWITCH master branch we had 90 commits! Most of the features for this week went toward the verto communicator and are: created a source map file, created the reset banner action, floor and presenter badges, and locked icon in floorLocked status, added an About screen with version information and links to FS.org and added a link to Confluence with documentation for VC, and made mute/unmute audio/video clickable. Other features this week include: refactoring the local_stream API to be more consistent and add auto complete, compatibility with Solaris 11 process privileges, improvements to the way FEC info is detected within frames by adding support for ptimes higher than 20 ms for FEC detection and improvements to jitter buffer debugging in mod_opus.

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

New features that were added:

• FS-8243 [mod_opus] Improve the way FEC info is detected within frames by adding support for ptimes higher than 20 ms for FEC detection
• FS-8161 [mod_opus] Keep FEC enabled only if loss > 10 ( otherwise PLC is supposed to be better)
• FS-8179 [mod_opus] Improvement on new jitter buffer debugging (debug lookahead FEC)
• FS-8254 [verto_communicator] Create a source map file
• FS-8263 [verto_communicator] Created the reset banner action, floor and presenter badges, and lock icon in floorLocked status
• FS-8288 [verto_communicator] Added an About screen with version information and links to FS.org and added a link to Confluence with documentation for VC
• FS-8289 [verto_communicator] Make mute/unmute audio/video clickable
• FS-8287 [mod_local_stream] Refactor local_stream API to be more consistent and add auto complete
• FS-8195 [core] Compatibility with Solaris 11 process privileges

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

• FS-8236 Fixed build without libyuv on compilers that error on unused static function and fixed ifdefs for building without libyuv
• FS-8239 [mod_av] Fixed the default value to avoid failed build on CentOS 7
• FS-8255 [Debian] Fixed codename changes since Jessie was released as stable
• FS-8271 [Debian] Simplify package building for the default case
• FS-8270 [Debian] Fix for package installation failing if /etc/freeswitch/tls is missing
• FS-8285 [Debian] Removed heart attack inducing warning message when updating deb packages
• FS-7817 Removed use of _NONSTD for Windows builds of spandsp, so (hopefully) eliminate compatibility problem

The following bugs were squashed:

• FS-8221 [verto_communicator] Fix number in call history
• FS-8223 [verto_communicator] Fixing members list layout when callerid is too long
• FS-8225 [verto_communicator] Avoid duplicate members when recovering calls
• FS-8214 [verto_communicator] Better handling calls in VC, answering them respecting useVideo param
• FS-8291 [verto_communicator] Fixed contributors url
• FS-8229 [verto_communicator] Changing moderator actions bullet menu color to #333
• FS-8219 [verto_communicator] Fix for camera not deactivating after init or after hangup
• FS-8245 [verto_communicator] Fix for Video Resolutions available in “Video Quality” drop down not always correct
• FS-8251 [verto_communicator] Factory reset now clears all local storage
• FS-8257 [verto_communicator] Fixed configuration provision url because configuration doesn’t work with `grunt serve` and non pathname urls
• FS-8273 [verto] [verto_communicator] Clear the CF_RECOVERING flag in a spot that was missed
• FS-8260 [verto_communicator] Prompt for banner text
• FS-8232 [mod_conference] Conference sending too many video refresh requests
• FS-8241 [mod_conference] Fix for conference stops playing video when local_stream changes source
• FS-8261 [mod_conference] Fixed the conference segfaulting when trying to reset the banner
• FS-8220 [core] Fix for DTMF not working between telephone-event/48000 A leg and telephone-event/8000 B leg
• FS-8166 [core] Mute/unmute while shout is playing audio fails because the channel “has a media bug, hard mute not allowed”
• FS-8252 [core] Fixed a crash in rtp stack on dtls pointer
• FS-8283 [core] Handle RTP Contributing Source Identifiers (CSRC)
• FS-8275 [core] Fix for broken DTMF
• FS-8282 [core] Fix for sleep is not allowing interruption by uuid_transfer
• FS-8240 [mod_local_stream] Fixed a/v getting out of sync when running in the background and added video profile parameter for recording 264 and made it default
• FS-8216 [mod_av] Fixed a regression in hup_local_stream from last commit
• FS-8274 [mod_av] Fixed a memory leak caused by images not being freed in video_thread_run
• FS-7989 [fixbug.pl] Escape double quotes from summary and added more debugging data
• FS-8246 [mod_json_cdr] Use seconds as default value for delay parameter
• FS-8256 [mod_opus] More FMTP cleanup
• FS-8284 [mod_opus] Use use-dtx setting from config in request to callee.
• FS-8234 [mod_opus] Send correct (configured) fmtp ptime,minptime,maxptime when originating call

 

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

The following bugs were squashed:

• FS-8190 [mod_event_socket] When using nixevent, freeswitch stops sending us certain custom event that were NOT part of the nixevent command
• FS-7673 [mod_v8] ODBC NULL value incorrectly evaluated
• FS-8215 Fixed the accuracy of MacOSX nanosleep
• FS-8269 [mod_sms] Fixed a build issue
• FS-8244 [mod_dptools] Fixed a compilation issue

 

 

Some aspects are now table stakes for WebRTC API Platforms.

There are 20+ vendors out there who are after your communications. They are willing to take up the complexity and maintenance involved with running real time voice and video that you may need in your business or app. Some are succeeding more than others, as it always has been.

So how do you as a potential customer going to choose between them?

Here are a few things I’ve noticed in the two years since I first published my report on this WebRTC API space:

1. Vendors are finding it hard to differentiate from one another. Answering the question to themselves of what they do better than anyone else in this space (or at least from the vendors they see as their main competitors) isn’t easy
2. Vendors often times don’t focus. They try to be everything to everyone, ending up being nothing to most. You can see what they are good for if you look from the sidelines, feel how they pitch, operate, think – but they can’t see it themselves
3. Vendors attempt to differentiate over price, quality and ease of use. This is useless.

Table Stakes

Most vendors today have pretty decent quality with a set of APIs that are easy. Pricing varies, but usually reasonable. While some customers are sensitive to pricing, others are more focused on getting their proof of concept or initial beta going – and there, the price differences doesn’t matter in the short to medium term anyway.

The problem is mainly vendor lock-in, where starting to use a specific vendor means sticking with it due to high switching costs later on. But then, savvy developers use multiple vendors or prepare adapter layers to abstract that vendor lock-in.

Vendors need to think more creatively at how they end up differentiating themselves. From carving a niche to offering unique value.

My Virtual Coffee

This is the topic for my first Virtual Coffee session, which takes place on October 14.

It is something new that I am trying out – a monthly meeting of sorts. Not really a webinar. But not a conference either.

Every month, I will be hosting an hour long session:

• It will take place over a WebRTC service – I am dogfooding
• It will cover a topic related to the WebRTC ecosystem (first one will be differentiation of WebRTC API Platform vendors)
• It will include time for Q&A. On anything
• Sessions will be recorded and available for playback later on
• It is open to my consulting customers and those who purchased my report in the past year

If you are not sure if you are eligible to join, just contact me and we’ll sort things out.

I’d like to thank the team at Drum for letting me use their ShareAnywhere service for these sessions – they were super responsive and working with them on this new project was a real joy for me.

Virtual Coffee #1 Title: WebRTC PaaS Growth Strategies How WebRTC API vendors differentiate and attempt to grow their business When: Oct 14. 13:30 EDT (add to calendar) Where: Members only What’s next?

Want to learn more about this space? The latest update of my report is just what you need

 

The post How NOT to Compete in the WebRTC API Space appeared first on BlogGeek.me.

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

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

Detailed changelog:

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

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

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

Modules’ documentation:

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

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

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

Some people are fidgeting on their chairs now, while others are happier than they should be.

I’ll start by a quick disclaimer: I like Google. They know when you acquire companies to fit my schedule – just got back from vacation – so I actually have time to cover this one properly.

Let’s start from the end:

Google and Apple are the only companies that can make RCS a reality.

To all intent and purpose, Google just gave RCS the kiss of life it needed.

Google just acquired Jibe Mobile, a company specializing in RCS. The news made it to the Android official blog. To understand the state of RCS, just look at what TechCrunch had to say about it – a pure regurgitation of the announcement, with no additional value or insights. This isn’t just TechCrunch. Most news outlets out there are doing the same.

* Dataset subscribers have the acquisitions table updated with this latest information

Why on earth is Google investing in something like RCS?

RCS

RCS stands for Rich Communication Suite. It is a GSMA standard that has been around for a decade or so. It is already in version 5.2 or so with little adoption around the world.

What is has on offer is an OTT-style messaging capabilities – you know the drill – an address book, some presence information, the ability to send text and other messages between buddies. Designed by committee, it has taken a long time to stabilize – longer than it took Whatsapp to get from 0 to 800. Million. Monthly active users.

The challenge with RCS is the ecosystem it lives in – something that mires other parts of our telecom world as well.

Put simply, in order to launch such a service that needs to take any two devices in the world and connect them, we need the following vendors to agree on the need, on the priority, on the implementation details and on the business aspects:

• Chipset vendors
• Handset vendors
• Mobile OS vendors
• Telco vendors
• Telcos

Call it an impossible feat.

In a world where Internet speeds dictate innovation and undercut slower players, how can a Telco standard succeed and thrive? The moment it gets out the door it feels old.

Google and Messaging

Google has many assets today related to messaging:

• Android, the OS powering 1.4 billion devices, where 1 billion of them call home to Google’s Play service on a monthly basis
• Hangouts, their own chat/voice/video service that is targeted at both consumers and enterprises. It is part of Android, but also works as an app or through the browser virtually everywhere
• Firebase, a year-old acquisition that is all about powering messaging (and storage) for developing apps

As Kranky puts it, they were missing an iMessage service. But not exactly.

Google thrives from large ecosystems. The larger the better – these are the ones you can analyze, optimize and monetize. And not only by building an AdWords network on top of it.

The biggest threats to Google today, besides regulators around the globe, would be:

1. Apple, who is doing its darnedest today to show off their better privacy policies compared to Google
2. Facebook, who is vying after Google’s AdWords money with its own social network/ads empire
3. Telcos, who can at a whim decide to shut off Google’s ambitions – by not promoting Android, making it hard for YouTube or other services to run, etc.

Getting into RCS and committing to it, as opposed to doing a half witted job at an RCS client on vinyl Andorid, gives Google several advantages:

• It puts them at the good side of Telcos, which can’t be bad
• Improves Android’s standing as an ecosystem, and making it easier for Google to force the hands of handset manufacturers and chipset vendors in adjacent domains
  • Maybe getting the codecs they want embedded as part of the device for example?
  • Forcing improvements on mobile chipset designs that offer better power management/performance for all messaging apps
• Opens the door to deeply integrating Hangouts with RCS/Telco messaging
• Enabling Google to become the gateway to the telco messaging space
  • Got a device running Android? An RCS client is already there and running
  • Don’t have Android? Connect through your browser from everywhere
  • Or just install that Google RCS app – it already has a billion downloads on it, as opposed to a measly 5,000 downloads of an operator-brand app
• Becoming the glue between consumer and enterprise
  • Hangouts may well be a consumer type of a product, but it is part of the Google Apps offering to enterprises
  • Carriers are struggling in monetizing consumer services these days besides connectivity, and Google is fine with giving consumers a free ride while making money elsewhere
  • Google is struggling with getting into the enterprise space. Hangouts is marginal compared to Microsoft Lync/Skype and Cisco
  • Offering direct connectivity to the carrier’s messaging for consumers can bridge that gap. It increases the value of RCS to the enterprise, making Google a player that can integrate better with it than competition

Why Acquire Jibe?

Beside being a nice signal to the market about seriousness, Jibe offers a few advantages for Google.

1. They are already deployed through carriers
2. Their service is cloud based, which sits well with Google. It means traffic goes through Jibe/Google – something which places Google as the gateway between the customer and the Telco – a nice position to be in

In a way, Jibe isn’t caught up in the old engineering mentality of telco vendors – it provides a cloud service to its customers, as opposed to doing things only on premise. While Google may not need the architecture or code base of Jibe Mobile, it can use its business contracts to its advantage – and grow it tenfold.

When your next RCS message will be sent out, Google will know about it. Not because it sits on your device, but because it sits between the device and the network.

Why will Telcos Accept this?

They have no choice in the matter.

RCS has been dead for many years now. Standardization continues. Engineers fly around the world, but adoption is slow. Painfully slow. So slow that mid-sized OTT players are capable of attracting more users to their services. It doesn’t look well.

And the problem isn’t just the service or the UI – it is the challenge for a carrier to build the whole backend infrastructure, build the clients for most/all devices on its network and then launch and attract customers to it.

Google embedding the client front end directly into Android and a part of the devices means there’s no headache in getting the service to the hands of customers and putting it as their default means of communications.

Google offering the backend for telcos in a cloud service means they no longer have to deal with the nasty setup and federation aspects of deploying RCS.

Only thing they need to do is sign a contract and hit the ground running.

An easy way out of all the sunk costs placed in RCS so far. It comes at a price, but who cares at this point?

The End Game

There are three main benefits for Google in this:

1. Selling more Google devices
   • If these devices come equipped with RCS, and their backend comes from the same Telco and operated by Google, then why should a Telco promote another device to its customers?
   • It isn’t limited to Android versus an iOS device – it also relates to Chrome OS versus Windows 10
   • When mobility needs will hit tablets and laptops and the requirement to be connected everywhere with these devices will grow, we might start seeing Telcos actually succeeding in selling such devices with connectivity to their network. Having RCS embedded in these devices becomes interesting
2. The next billion
   • Facebook and Google are furiously thinking of the next billion users. How to reach them and get them connected
   • With RCS as part of the messaging service a Telco has on offer, they are less dependent on third party apps to connect
   • With Google having both RCS and Hangouts, it increases the size of their applicable users base and the size of their ecosystem
3. Carrier foothold
   • Carriers are reluctant when it comes to Google. They aren’t direct competitors, but somehow, it can feel that way at times – Google Fiber and Google Fi are prime examples of what Google can do and is doing
   • This is why having cloud services owned by Google and connected to the heart of a Telco is enticing to Google. It gives them a better foothold inside the carrier’s network

Where’s WebRTC?

Not really here. Or almost not. It isn’t about WebRTC. It is about telecom and messaging. Getting federated access that really works to the billions of mobile handsets out there.

Jibe has its own capabilities in WebRTC, a gateway of sorts that enables communicating with the carrier’s own network from a browser. How far along is it? I don’t know, and I don’t think it even matters. Connecting Jibe RCS cloud offering to Google Hangouts will include a WebRTC gateway. If it will or won’t be opened and accessible to others is another question (my guess is that it won’t be in the first year or two).

An interesting and unexpected move by Google that can give RCS the boost it desperately needs to succeed.

 

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

The post Android Does… RCS !? What About WebRTC? Hangouts? appeared first on BlogGeek.me.

We’re preparing for #KazooCon! Are you ready for the Unified Communications Revolution on Monday? If you have not purchased tickets, do so right now…only five tickets remain http://ow.ly/SPQgr

The SmartPBX App combines comprehensive PBX functionality with user-friendly interface. Set up new users in minutes, manage all of your accounts, reduce installation and labor costs, and provide business-specific user features. All services are controlled via API’s, allowing you to extend the App functionality as needed. Within the interface you have the ability to create, manage, and remove services for your users.  

2600Hz offers a true Unified Communications solution, providing telco solutions that can be deployed by anyone in the continental United States. The SmartPBX App is highly scalable, redundant and clustered, providing increased functionality and time-savings when compared to traditional VoIP telecom carriers. Remotely manage your entire product offering within the SmartPBX Dashboard and quickly diagnose and solve most issues that may arise.

See SmartPBX at Work

So what Features Make 2600Hz’s SmartPBX Different?

Total Administrator Visibility - The SmartPBX dashboard provides a comprehensive overview of your entire product offering. Within the dashboard, review the total users, devices, main numbers and conference numbers. Have peace of mind knowing that your network is working properly just by looking at the dashboard.

Manage All Users & Features - Create users and manage all their settings within the Users tab of SmartPBX. Add Users, attach Phone Numbers, Devices and assign specific User Features within the UI. Manage what features your users can access including Ring Groups, Caller ID, Call Forwarding, Hot Desking, Voicemails, Faxbox, Conference Bridge, Find Me, Follow Me, Music-On-Hold and Inbound Call Recording.

Purchase, Port and Assign Phone Numbers - Provide each user with their unique direct-dial phone and extension number. Assigning and managing numbers within the UI is extremely easy, and you can purchase a number in seconds.

Provision Devices - Provision Yealink, Polycom and Cisco devices in minutes with our built-in auto- provisioning system. The UI comes pre-populated with these manufacturers and devices are continuously being added. Bring in your own devices or allow users to bring in their own. Devices can be provisioned remotely, users just need to provide their MAC and IP address, then plug in and reset their device.

Call Handling and Virtual Receptionist - Create customized greetings and call routes to give businesses that professional touch. Set up a main business phone number and utilize the pre-built Virtual Receptionist to handle inbound calls. Virtual Receptionist will professionally and automatically transfer calls to an appropriate department or person. Set time-of-day routing and holidays, effectively managing business hours.

Conference Numbers - Create a direct-dial conference number. Pre-programmed room numbers and conference room PINs allow access to the conference.

Billing and Transaction Services - Easily add credit cards on file and change accordingly. Create and set limits for users that include inbound and outbound trunks, and per minute credits.

Call Logs - Diagnose call delivery problems with ease. Every call is tracked and call problems can be reported with a single click.

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

Release files are located here:

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

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

New features that were added:

• FS-8094 [verto_communicator] Added googEchoCancellation, googNoiseSuppression, and googHighpassFilter settings to the UI enabled by default
• FS-8107 [switch_ivr_menu] Adding CUSTOM esl events menu::enter and menu::exit when a call enter and exit an ivr menu
• FS-6833 Allow Freeswitch to initiate late offer calls
• FS-8075 [mod_hiredis] Add conf file to spec file too and updates for limit release case
• FS-8053 Handle a=sendonly, a=sendrecv, a=recvonly to change who is sending video during a call

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

• FS-7966 [Windows] Build now uses visual studio 2015 and builds successfully, but is still missing video functionality
• FS-8124 [verto_communicator] Adding option –debug to grunt build, dist app will be generated without minified code.
• FS-7168 [Debian] Update packages so that FS core libraries are setup as runtime dependencies
• FS-7697 Chown the /etc/freeswitch/tls directory so that the freeswitch user can have read/write for TLS certificate generation
• FS-7966 [Windows] Explore use of nuget for wix build dependency
• FS-7967 [build] SmartOS compatibility
• FS-8072 [Debian] Fixed a missed space

The following bugs were squashed:

• FS-8099 [mod_lua] Restored LUA dialplan ACTIONS functionality
• FS-7988 [filebug.pl] Moved -askall to -terse so old -askall behavior is default and old default is now -terse
• FS-8029 [jitterbuffer] Fixed robotic sound when using jitterbuffer
• FS-8103 [mod_rayo] Fixed handling of malformed requests
• FS-8108 [mod_lua] Removed legacy mod_lua, the regular mod_lua works with system lua now
• FS-8082 [mod_rayo] Fixed a segfault
• FS-8110 [mod_rayo] Prompt IQ error reply was being deleted after being sent for delivery. This is incorrect since message delivery thread will clean up the message
• FS-8116 [verto] Fixed device enumeration hanging on init
• FS-8118 [verto] Fixed calls not properly rejecting video when video is offered but only audio is accepted
• FS-7994 [verto_communicator] Using factory for group calls in history
• FS-8117 [verto_communicator] Calling verto.iceServers upon useSTUN changing on ModalSettings, correctly check for STUN setting in localStorage, and fixed ignoring useSTUN settings
• FS-8127 [mod_conference] Fixed an audio issue caused by the codec not updating often enough when detecting rate change
• FS-8088 [verto_communicator] Fixed members list being destroyed after switching conferences and ending the first conference
• FS-8130  Port video buffer to also support audio and remove original STFU jitter buffer, add some more resilience to video packet loss, add codec control mechanism for both call-specific debug and codec/call specific parameters, make opus function better in packet loss and latent situations, use new codec control prams to make jitter buffer lookahead FEC optionally enabled or disabled mid-call, and add a parameter to allow jitter buffer lookahead to be enabled.
• FS-8131 [mod_voicemail] Fixed issues with allowing an empty password change and then locking out the user
• FS-8136 [mod_h26x] Do not load passthru video codecs by default
• FS-8140 [mod_sofia] Fixed a user_name typo in sofia_handle_sip_i_invite
• FS-8142 Fixed  a thread cache thread-safety and caching
• FS-8075 [mod_hiredis] Fix for failover when you pull power on redis, while redis clients under load test
• FS-8144 [mod_opus] Readability and code formatting cleanup
• FS-8126 [switch_core] Fixed the pruning of a media bug causing all media bugs on a session to be pruned
• FS-8143 [mod_rayo] Fixed a crash caused by client disconnecting from mod_rayo while a message is being delivered to that client. This is caused by the XMPP context’s JID -> XMPP stream mapping not being cleaned up on XMPP stream destruction.
• FS-8147 [mod_erlang_event] Fixed the process spawning segfault
• FS-8149 [mod_xml_cdr] Fixed curl dependency in makefile
• FS-1772 [mod_voicemail] Fixed the reset of voicemail greeting to default to allow entering 0 to restore the default greeting

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

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

New features that were added:

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

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

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

The following bugs were fixed:

• FS-7135 [mod_sofia] Fixed response to re-invite with duplicate sdp (such as we get from session refresh) when soa is disabled to include an sdp. Fixed t.38 fax failure on session refresh
• FS-7903 [proxy_media] Fix Codec PROXY Exists but not at the desired implementation. 0hz 0ms 1ch error when using proxy media.
• FS-8056 [mod_voicemail] Fixed a segfault on vm_inject, regression from FS-7968
• FS-7968 [mod_voicemail] Fixed verbose events
• FS-8110 [mod_rayo] Prompt IQ error reply was being deleted after being sent for delivery. This is incorrect since message delivery thread will clean up the message
• FS-8082 [mod_rayo] Do not remove items from hash while iterating
• FS-8103 [mod_rayo] Handle where finishes unexpectedly before start event is received
• FS-8143 [mod_rayo] Fixed a crash caused by client disconnecting from mod_rayo while a message is being delivered to that client. This is caused by the XMPP context’s JID -> XMPP stream mapping not being cleaned up on XMPP stream destruction.
• FS-8127 [mod_conference] Fixed an audio issue caused by the codec not updating often enough when detecting rate change
• FS-8099 [mod_lua] Restored LUA dialplan ACTIONS functionality
• FS-8142 Fixed thread cache thread-safety and caching
• FS-8185 [core] Allow xml preprocessor to expand variables where the resulting value is much longer than the original size
• FS-8167 [mod_lua] Fixed a segfault caused by using api:execute or session:execute and not quoting the first argument like api:execute(log, “Second argument”) instead of api:execute(“log”, “Second argument”)
• FS-8169 Fixed uuid_displace on stereo channels can lead to memory corruption causing a crash
• FS-8114 Fixed opus and telephone event payload types colliding on REFER

 

Hello, again. This past week in the FreeSWITCH master branch we had 57 commits! Some of our features for this week are: added reset button to default settings, auto-provision/config support, No Camera option, and splash screen feature in the verto communicator.

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

New features that were added:

• FS-8095 [verto_communicator] Added reset button to default settings
• FS-8095 [verto_communicator] Do not reset name and email upon logout
• FS-8102 [verto_communicator] Added auto-provision/config support
• FS-8205 [verto_communicator] Added splash screen feature
• FS-8193 [verto communicator] Added No Camera option
• FS-8183 [verto_communicator] Add google API logins, moved google ClientID to config file where it belongs, and tweaks to the CSS
• FS-8089 [verto_communicator] Opening members list when start conference
• FS-8204 [verto] Added stereo audio support for opus on FireFox and add sprop-stereo
• FS-8042 FS-8182 [mod_sofia] Added ping time (in ms) to sip_registrations table, displays as part of the show commands that show registration details, add force_ping=true user var to force options ping on individual registered endpoints
• FS-8130 Added support for timestamp based counting for jitter buffer in audio mode

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

• FS-8230 FSRTC – calling localStream.stop when it’s available or localStream.active = false to make it work on newer chrome canary
• FS-7697 [Debian] Moved chown of /etc/freeswitch/tls to postinst
• FS-7909 [Debian] Removed explicit set of WorkingDirectory
• FS-7130 [Debian] Use systemd RuntimeDirectory for /run/freeswitch

The following bugs were squashed:

• FS-8196 [verto_communicator] Fixed sidebar layout when user is moderator and added nowrap to white-space
• FS-8200 [verto_communicator] Ending screenshare if user hangup call and screenshare is now for all instead of only mods
• FS-7980 [verto_communicator] Fixed video padding-top
• FS-8224 [verto_communicator] Allowed CallerID to be set from login settings
• FS-8213 [verto] Added support to skip permission checks
• FS-8202 [verto] Stopped peer when ending screen share
• FS-8210 [verto] Fix for module being unloaded while it is in use
• FS-8190 [mod_event_socket] When using nixevent, freeswitch stops sending us certain custom event that were NOT part of the nixevent command
• FS-7673 [mod_v8] ODBC NULL value incorrectly evaluated
• FS-8031 [RTP] Fix for Firefox giving up because we replied to their stun
• FS-8130 [mod_conference] Add jb_video_low_bitrate for a bit rate to ask for when the jitter buffer is taxed
• FS-8211 [mod_conference] Fixed video recordings of layouts with overlap having flickering video
• FS-7911 [mod_conference] Fixed a memory leak
• FS-8130 Fixed a regression in bridged channels with jitterbuffers
• FS-8215 Fixed the accuracy of MacOSX nanosleep
• FS-8216 [mod_av] Fixed for occasional lip sync problems when recording

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

New features that were added:

• FS-8042 FS-8182 [mod_sofia] Added ping time (in ms) to sip_registrations table, displays as part of the show commands that show registration details, add force_ping=true user var to force options ping on individual registered endpoints

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

• FS-7130 [Debian] Use systemd RuntimeDirectory for /run/freeswitch
• FS-7909 [Debian] Removed explicit set of WorkingDirectory

The following bugs were squashed:

• FS-8169 Fixed uuid_displace on stereo channels can lead to memory corruption causing a crash
• FS-8167 [mod_lua] Fixed a segfault caused by using api:execute or session:execute and not quoting the first argument like api:execute(log, “Second argument”) instead of api:execute(“log”, “Second argument”)
• FS-8185 [core] Allow xml preprocessor to expand variables where the resulting value is much longer than the original size
• FS-7911 [mod_conference] Fixed a memory leak

Lots of Node. Little of WebRTC.

It has been quite some time since my last WebRTC book review. So when I got an indication that there is another book with WebRTC inside it, I had to read it. Which is what got me to Multiplayer Game Development with HTML5 by Rodrigo Silveira.

The promise of WebRTC in this book? Learning to “create peer-to-peer gaming using WebRTC”. I was intrigued. Spent reading it a few hours – and was happy about it, even though the WebRTC part of it was limited in its value.

This book takes the reader into a “Hello World” implementation of an online HTML5 multiplayer game. It is done by taking a step by step approach to implementing the classic snake game. First in HTML5, using a backend. And then by building on top of it all the rest.

The book itself is focused on Node.js development of the game, taking care to explain and use concepts of authoritative game servers – servers that make the main decisions in a game. It connects that to responsiveness and fluidity of the game, etc.

To those interested in real time communications, this is an interesting book. It has a lot of the same thought processes of developing signaling protocols and implementing their backend, dealing with responsiveness, latency and causality of message passing. It also handles the game lobby – the place where you connect players – you can view this as a conferencing server (the signaling part of it).

Rodrigo mentions WebRTC almost in passing – as a way of reducing latency by making use of the data channel in WebRTC, but that’s about it. There’s no real discussion or example of how to integrate it in a multiplayer game where you have an authoritative server and clients that communicate directly with each other at the same time.

That said, I felt the book is an interesting one for those developing WebRTC – and it wasn’t because of the WebRTC parts of it.

If you are interested in architecture, design, signaling or just programming – this book is a really interesting read.

I warmly recommend it.

The post WebRTC Book Review: Multiplayer Game Development with HTML5 appeared first on BlogGeek.me.

We’re less than 10 days from ‪#‎KazooCon‬. For all you late-birds out there, now is the time to buy! Only nine tickets remain. www.kazoocon.com

An update to my WebRTC API Platforms report is now available.

Updates in the reports

The last time I published an update of my Choosing a WebRTC API Platform report was 6 months ago. Since that time the market has changed quite a bit. If I had to note the most important aspects of that change, they would be:

• AT&T and Unify getting into the game of WebRTC PaaS
• Twilio introducing video support, and then full portfolio of communication APIs
• Cisco acquiring Tropo
• Comverse acquiring/merging with Acision and then rebranding as Xura

Other notables include Atlassian acquiring BlueJimp and non-WebRTC API platforms joining the game.

These frequent changes made it into the latest update to my report, along with an addition of 4 vendors (AT&T, Bistri, Bit6 and Circuit). This with the updates of what vendors are doing didn’t seem enough to cover the market properly. Which is why I have decided to open a membership section on my website to go along with the report.

New membership area (and tools)

What does this membership section includes?

• An online vendor matrix – one that will get updated a bit more frequently than the report itself. Purchasers of the report, under a valid subscription account will be able to access this online vendor matrix whenever they want and see what features companies have on offer. It should be a quick way to decide which vendors you should be looking at for the feature set you are looking for
• Visuals – I’ve taken the visuals and tables from the report, compiling them into a simple Powerpoint deck. You can download the deck and copy+paste from it whatever you need for your own presentations
• Monthly Virtual Coffee with Tsahi – a new monthly “webinar” of sorts open only to the report subscribers and my consulting clients, where I’ll be discussing the ecosystem as well as open the floor to any questions related to real time communications

So. If you purchased the report within the last year or have renewed your report’s subscription, you’ll be getting immediate access to the membership area and its tools – an email will be sent to you today with the necessary details.

Overview and sample vendor

If you want to learn more about the report, you can download the report’s table of contents and introduction section.

This time, I also wanted to give people a taste of what they’ll find in the report itself. To that end, I’ve asked AT&T to sponsor the vendor analysis section covering their platform and WebRTC APIs and they accepted. There are 23 vendors covered in the report in detail. The AT&T one is now freely available to download – you can expect the same level of detail on all other vendors in the report.

New pricing

This brings me to the last item, which is pricing.

There are now two price points for the report:

• Basic, at $1700, which is what was included until today for a higher price point (essentially, the report and any updates within a year from purchase)
• Premium, at $1950, which is the lowest earlier price point, which grants access to the new membership area

Join the Free Webinar

Want to learn more, or understand how the market is changing by non-API players? I am hosting a free webinar later today:

Development Approaches of WebRTC Based Services: There are many ways in which people approach adding real-time communications with WebRTC to their service. While the dominant approaches are probably self development and using a WebRTC PaaS vendor, there’s a wider range of approaches.

register and join me there

Got questions? Feel free to ask them in the comments area below or by contacting me directly.

The post My WebRTC API Platforms report Gains a Membership Portal appeared first on BlogGeek.me.

So I talked about Skype and Viber at KrankyGeek two weeks ago. Watch the video on youtube or take a look at the slides. No “reports” or packet dumps to publish this time, mostly because it is very hard to draw conclusions from the results.

The VoIP services we have looked at so far which use the RTP protocol for transferring media. RTP uses a packet header which is not encrypted and contains a number of attributes such as the payload type (identifying the codec used), a synchronization source (which identifies the source of the stream), a sequence number and a timestamp. This allows routers to identify RTP packets and prioritize them. This also allows someone monitoring all network traffic (“Pervasive Monitoring“) to easily identify VoIP traffic. Or someone wiretapping your internet connection.

Skype and Viber encrypt all packets. Does that make them them less susceptible for this kind of attack?

Bear with me, the answer is going to be very technical. tl;dr:

• it is still pretty easy to determine that you are making a call.
• it is also pretty easy to tell if you muted your microphone.
• it is pretty apparent whether this is a videochat.

Skype

Not expecting to find much, I ran a standard set of scenarios with Skype of Android and iOS similar to those used in the Whatsapp analysis.
A first look did not show much. Luckily, when analyzing WhatsApp I had developed some tooling to deal with RTP. I modified those tools, removing the RTP parser, and was greeted with these graphs:

While the bitrate alone (blue is my ipad3 with a 172.16. ip address, black is my old Android phone) is not very interesting, the packet rate of exactly 50 packets was interesting. Also, the packet length distribution was similar to Opus. As I figured out later from the integrated debugging (on the Android device, this must be too technical for iOS users!), this was the Silk codec. In fact, if you account for some overhead the black distribution matches what we saw from WhatsApp earlier and what is now known to be Opus at 16khz or 8khz.
So the encryption did not change the traffic pattern. Nor does it hide the fact that a call is happening.

Keepalive Traffic

When muting the audio on one device, one can even see regular spikes in the traffic every then seconds. Supposedly, those are keepalive packets.

Telling audio and video traffic apart

Let’s look at some video traffic. Note the two distinct distributions in the third graph? Let’s suppose that the left one is audio and everything else is video. This works well enough looking at the last graph which shows the ‘audio’ traffic in green and orange respectively.

The accuracy could possibly be improved a little by looking at the number of packets which is pretty much constant for audio.
In RTP, we would use the synchronization source (SSRC) field from the header to accomplish this. But that just makes things easier for routers.

Relay traffic

Last but not least relays. When testing this from Europe, I was surprised to see my traffic being routed through Redmond, Washington.

This is quite interesting in comparison to the first graph. The packet rate stays roughly the same, but the bitrate doubles to 100 kilobits/second. That is quite some overhead compared to the standard TURN protocol which has negligible overhead. The packet length distribution is shifted to the right and there are a couple of very large packets. Latency was probably higher but this is very hard to measure.

Viber

While I got some pretty interesting results from Skype, Viber turned out to harder. Thanks to the tooling it took now only a matter of seconds to discover that, like Whatsapp, it uses a relay server to help with call establishment:

Blue traffic is captured locally before it is sent to the peer, the black and green traffic is received from the remote end. The traffic shown in black almost vanishes after a couple of initial spikes (which contain very large packets at a low frequency). Visualizations of this kind are a lot easier to understand than the packet dumps captured with Wireshark.

And for the sake of completeness, muting audio on both sides showed keepalive traffic, visible as tiny period spikes in this graph:

Conclusions

VoIP security is hard. And this not really news, attacks on encrypted VoIP traffic have been known for quite a while, see e.g. this paper from 2008 and the more recent ‘Phonotactic Reconstruction’ attacks.

The fact that RTP does not encrypt the header data makes it slightly easier to identify, but it seems that a determined attacker could have come to the same conclusions about the encrypted traffic of services like Skype. Keep that in mind when talking about the security of your service. Also, keep the story of the ECB penguin in mind.

Or, as Emil Ivov said about the security of peer-to-peer: “Unless there is a cable going between your computer and the other guys computer and you can see the entire cable, then you’re probably in for a rude awakening”.

{“author”: “Philipp Hancke“}

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

The post Traffic Encryption appeared first on webrtcHacks.

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

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

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

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

Apple TV

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

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

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

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

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

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

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

Amazon Fire TV

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

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

The specs indicate the following content formats:

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

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

Here’s the rub though:

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

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

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

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

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

Google Chromecast

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

Here we go – these are my own estimates:

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

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

Bottom Line

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

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

 

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

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

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

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

Security Issues:

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

New features that were added:

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

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

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

The following bugs were squashed:

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

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

Security Issues:

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

New features that were added:

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

The following bugs were fixed:

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

Yes and no.

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

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

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

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

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

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

 

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

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

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

Our initial ORTC implementation includes the following components:

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

More here..

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

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

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

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

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

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

Setting up a Peer to Peer connection

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

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

As in the peerConnection API, you exchange the candidates:

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

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

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

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

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

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

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

Cool. Now what?

Sending a MediaStream track over the connection

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

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

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

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

Then, we start the RtpReceiver with those parameters:

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

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

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

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

{“author”: “Philipp Hancke“}

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

The post First steps with ORTC appeared first on webrtcHacks.