September 2013 archive

Sep 30

Lesson Learned The Hard Way – Google+ Hangouts On Air (HOA) Have A Maximum Time Limit of 4 Hours

I learned a hard lesson today that Google+ Hangouts On Air (HOA) are limited to 4 hours in length. Today when we were live streaming our five-hour ION Krakow conference out of Poland using a Google+ Hangout On Air (HOA) everything was going along fine. (It was, indeed, working over IPv6!) People were watching on both our Google+ page as well as our YouTube channel. All was fine.

Then, all of a sudden... it stopped. No warning. Nothing. I didn't even notice that the red "Broadcasting" button was gone from the G+ HOA window.

Someone pinged us on Twitter to let us know the stream was down... and sure enough, the HOA had stopped broadcasting... right in the middle of one of our panel sessions!

I had to quickly exit that HOA and then relaunch a new HOA, which resulted in a new HOA for people to join on our Google+ page... and then pointing people to a YouTube URL with our channel name ending in "/live" to get our live stream (in our case, http://www.youtube.com/user/depoy360/live).

What Happened?

Why did the Google+ Hangout On Air just quit broadcasting on us?

Gplus hoa four hoursI didn't have a definite answer... but if you look at the first YouTube recording of our ION Krakow event, you'll notice the interesting time amount that I'm highlighting in the image to the right.

Yep... 3:59:59!

So I was thinking either:

  1. Google+ Hangouts On Air have a 4 hour maximum; or
  2. there was some kind of software or network glitch conveniently at the 4 hour time mark. (And unicorns might be grazing in my back yard when I get back from my trip, too.)

I searched online tonight and couldn't find any reference to a time limit. I saw nothing in the Google+ HOA FAQ or even in the HOA Terms of Service. I looked through the Google+ HOA Technical Guide, too, and found again nothing there.

The Answer (Maybe?)

Then I wound up searching Google's Support site with the phrase "hangouts on air maximum time" and... ta da... there was an answer in Google's product forums from May 2012 that said:

the time limit for Hangouts On Air is 4 hours. At 4 hours, the broadcast will automatically stop.

which is exactly the experience we had today. There was also another answer in a product forum from December 2012 that said:

Hangouts On Air can last up to 4 hours. You’ll receive a warning when you have 1 hour remaining, and then subsequent warnings as you approach the 4 hour limit.

If there were any warnings, I have no idea where they went to. I certainly don't remember seeing any warnings! It just stopped.

What was worse what that the Google+ HOA window stopped broadcasting but still continued to show the video stream as per usual - so when I was just glancing at the window it all looked fine. I didn't notice that the big red button was missing.

Thankfully for me...

Now... being the paranoid type, I was recording the video out of Wirecast onto my local hard drive at the same time I was sending it to Google+ HOA, so I do now have a copy of the video of the several minutes in the middle of our panel that didn't get streamed. But:

  • It was a poor user experience for anyone watching to just have it stop.
  • We now have two video segments instead of one big one. (although that's not necessarily a bad thing... I just would have liked to break the segment at a break in the panels)
  • This means additional post-production work to stitch it all together.
  • We had no warning.

This last point is perhaps the biggest annoyance... if we had known there was a four-hour limit, we could have planned for that. We could have stopped and restarted in one of the breaks, for instance. We just didn't want to do that because then it means viewers have to start watching a new video stream, and we thought that some number of users might miss that they had to start watching a new stream.

We wanted the viewer experience to be as simple and painless as possible.

So consider this a warning for you all... should you decide to try using Google+ Hangouts On Air to live stream sessions longer than 4 hours, well, you need to first have some plan to break the HOA into smaller segments!

P.S. And yes, if you listen to our ION Krakow recording on YouTube, the first 1 hour and 45 minutes have terrible audio quality... but that will be the subject for a post tomorrow. Essentially, I missed that HOA had a separate setting for bringing in the audio from our camera (which was supplied by the A/V mixing board) and so I was using audio from my laptop's mic. :-( Thankfully: 1) we fixed it; and 2) I was running a backup audio recorder pulling an aux feed from the house mixer so I can bring that audio back in from that separate recorder.

P.P.S. I'll also be putting up a blog post in the next few days about how we successfully did do this live video streaming over IPv6.

If you found this post interesting or useful, please consider either:

Sep 30

Lesson Learned The Hard Way – Google+ Hangouts On Air …

I learned a hard lesson today that Google+ Hangouts On Air (HOA) are limited to 4 hours in length.... and to read the rest of the story, visit Disruptive Conversations...

(Good lesson that I shouldn't be posting articles at 1:00am! But leaving this post up here for a bit because there are now social media links out there pointing to this URL...)

Sep 30

Live Streaming ION Krakow Over IPv6 – Using Google+ Hangouts or YouTube Live

ion_krakow2013_blue_jpgWe’re doing something a little different (and risky) with our live streaming of ION Krakow today out of Krakow, Poland.  Instead of using our “regular” method of live streaming using the Internet Society’s Livestream.com account, we’re trying out a Google+ Hangout On Air (HOA) which will simultaneously broadcast the session live on our Deploy360 YouTube channel.  You should be able to watch the live webcast on either:

Why are we doing this?  Primarily because we accepted the challenge by Wes George on Twitter to “eat our own dogfood” and see if we could get livestreaming going out over IPv6.

Live streaming over IPv6

Livestream.com is currently IPv4-only and so we went looking at other options.  Without setting up our own server infrastructure, the two possible options that we’ve found seem to be:

I say “possible” because this will be our first test and we’re not honestly entirely sure whether the broadcast will go out over IPv6.  It turns out that PLNOG only has an IPv4 network and so our connection back to Google’s servers will be IPv4.  In theory, Google’s content distribution network (CDN) should then serve the video streams out over IPv4 or IPv6.  We’ll see (and we’d like your help – see below).

As far as the two services, YouTube Live was of most interest to me when testing because it allows us to schedule an event in advance and promote that URL – and then have the video go live at that URL at the appointed time.  However, I was unable to get my software to work consistently with YouTube Live (and didn’t have a whole lot of time to test).

I’m going instead with a Google+ Hangout On Air because the video chain worked well and it also broadcasts over on our YouTube channel.  So people should be able to see the livestream on either Google+ or on YouTube – and shouldn’t have to login to see the stream, at least on YouTube.

The downside of a Google+ HOA is that you can’t set up a URL that you can promote in advance.  We have to wait until we go live this afternoon here to have a URL we can publicize.  So instead we have to tell people to watch our Google+ page and YouTube channel… which is okay but not ideal.

How You Can Help – Show Us It’s IPv6

We’d like to prove that today’s live stream is going out over IPv6… but we’re here at PLNOG on a IPv4 network, so we have no way of knowing.   What we’d love is if some of you out there who are running the IPvFoo or IPvFox browsers add-ons/extensions could capture some screenshots and let us know as a reply to a post on our Google+ page. What I am looking for is something like this:

Googleplus-ipv6.jpg

That can show which of the various connections are using IPv6.

If you are interested in helping, please monitor this post on our Google+ page so that you can see if others have already sent some in.  We would appreciate several different screenshots (but we don’t need 100! :-) ).

And if it turns out that we don’t see any streaming over IPv6… well… it will be worth the attempt – and we will figure this out eventually!

The Technical Setup

For those curious, I’m using a Canon Vixia camera connected via HDMI to a Blackmagic Intensity Extreme box that connects into my MacBook Pro.  On my MBP I’m running Wirecast software as an encoder that will then broadcast out to Google+.  I also have a Logitech HD webcam ready as a standby.  I have a feed coming into my camera from the house audio so that I’m getting the event microphones.  I’m then monitoring the audio from headphones connected to my MBP.

And, being paranoid about ensuring I capture the content, I’m recording the video stream locally on my MBP as a backup.

We’ll see… let the grand experiment begin in about 3.5 hours…

Sep 30

FIR #723 – 9/30/13 – For Immediate Release

FIR On Strategy episode 1 is up; Speakers and Speeches podcast on social visual communication is up; Scoble-Israel interview coming on Tuesday; FIR mobile app available for three platforms; Quick News: Pinterest introduces article pins, self-publishing could become a $52 billion business, Klout introduces Cinch, Lloyd's List goes digital-only; Ragan promo; News That Fits: Six lessons for content marketers from digital-first magazine leaders, Michael Netzley's Asia report, marketers lack confidence in their own digital abilities, Media Monitoring Minute from CustomScoop, listener comments, GE launched Ideas Lab with content from Atlantic Media Strategies, Dan York's report, Wave 7 survey results; music from KA Morton; and more.

Sep 26

How To Securely Transfer A DNSSEC-Signed Domain Between DNS Operators – SIDN’s EPP Keyrelay

sidn-epp-keyrelayWhat happens if you want to transfer a DNSSEC-signed domain from one DNS operator to another? Perhaps you are consolidating domains into one operator… or the new operator has better security… or is less expensive…

It turns out that there has not been an easy way to do this while ensuring that the DNSSEC “chain-of-trust” remains intact.   If the old DNS operator (often referred to as the “losing operator” when talking about domain transfers) just stops serving DNS records, the new DNS operator (referred to as the “gaining operator“) can start serving DNS records – but there will be a time delay while a new DS record is recorded in the registry for the top-level domain (TLD) for whatever domain is being transferred. During that time,  validation would fail because the DNSSEC records being served would not match the DS record contained in the TLD registry.  This might only be a brief period of time… but as we start using DNSSEC more widely – and particularly for services like DANE that provide added integrity to SSL interactions – keeping the domain “always secure” will become increasingly important.

One solution that has been suggested – and successfully demonstrated! – is that of “EPP keyrelay” proposed by SIDN, the registry operator for .NL.  Antoin Verschuren from SIDN Labs wrote up this solution in a document titled “EPP keyrelay: solving the last obstacle for DNSSEC deployment” (PDF).  The mechanism has also been submitted as an Internet Draft to the IETF as: draft-gieben-epp-keyrelay.

Essentially, the mechanism introduces a new command into the Extensible Provisioning Protocol (EPP) used by DNS operators, registrars and registries and uses registry as a broker to transfer DNSSEC key information from the new DNS operator to the old DNS operator as part of the transfer process.

The document and Internet-Draft do indeed present an interesting solution to this challenge of domain transfer. Both are being discussed within the larger DNSSEC and DNS community – and I know that Antoin and the team at SIDN Labs would welcome further feedback – and implementation, of course!  It’s great to have SIDN Labs providing a solution and we look forward to seeing how this work evolves – we definitely do need to ensure that domains can remain “always secure”, even when being transfered.

 

 

 

Sep 26

TDYR #038 – Heading To Poland And Ukraine For ION Krakow And ENOG 6

TDYR #038 - Heading To Poland And Ukraine For ION Krakow And ENOG 6 by Dan York

Sep 26

Renesys Chronicles Today’s Internet Blackout in the Sudan (Now Restored) (Featured Blog)

The team over at Renesys has once again provided a great analysis of an Internet outage in a country, this time in Sudan. In the article simply titled "Internet Blackout in Sudan", Doug Madory writes: A few hours ago, we observed a total Internet blackout in Sudan and, as we publish this blog, the Internet remains largely unavailable. By count of impacted networks, it is the largest national blackout since Egypt disconnected itself in January 2011..." More...

Sep 26

Renesys Chronicles Today’s Internet Blackout In The Sudan (Now Restored) (Featured Blog)

More...

Sep 25

2 Excellent New Tutorials On IPv6 Address Planning From ISOC and SURFnet

Example Router TopologyHow should you plan out your IPv6 addresses? What is the best way to allocate IPv6 address blocks to your various networks and subnets? What factors should you be considering when mapping out a plan for how best to use your IPv6 addresses?  These are all great questions and were in fact topics I covered in two recent IPv6 webinars – but we’re very pleased to announce two recent documents that go into this topic in great detail (and we’ve added both to our new IPv6 Address Planning page):

IPv6 Address Planning: Guidelines for IPv6 address allocation

The first IPv6 address planning document is one written for our Deploy360 site by Tim Rooney at BT Diamond IP after he was reviewing our IPv6 content roadmap and contacted us about writing this document for our web portal.  It’s a brand new document that we’re publishing for the first time today.  Tim does an excellent job walking through the issues around why you need an IPv6 address plan, how you should set one up, suggestions for how to number subnets and then several examples of exactly how you could allocate addresses to subnets based on a plan.  He concludes with some recommendations and observations.

It’s a solid document that I think will be quite useful for anyone starting out with IPv6.  We greatly appreciate Tim’s contribution to our site and thank him for the time he spent on the document.  (And we’re always open to new contributors!)

SURFnet: Preparing An IPv6 Address Plan

In a bit of synchronicity, the great team over at SURFnet came out with a new version of their IPv6 address planning document last week.   They first came out with this document in 2011 and with the help of RIPE NCC made it available in both Dutch and English.  In this new and improved version they’ve changed the flow of the text a bit and added in more information.  The document starts out with a brief review of IPv6 addressing and then gets into the details of creating an address plan. It provides some excellent suggestions and recommendations and includes some detailed examples of how you could structure an address plan.  The document also contains sections around how you manage the assignment of IPv6 addresses out to end devices (hosts).

This document, too, is an outstanding document for anyone getting started with IPv6.  Thanks to the SURFnet team for coming out with this new version!

While the two documents cover similar ground, they both offer provide different and useful perspectives on how to create an IPv6 address plan.  The combination of the two documents will be quite helpful for anyone looking to get started with IPv6.

We strongly encourage you to read both documents (and please do share them with others!) and provide any comments and feedback back to the authors.  We’ve added them to a new IPv6 Address Planning page where we will also be adding other resources on this topic (and please let us know if you are aware of some resources we should consider adding). Now… let’s get those IPv6 networks deployed!

Sep 25

SURFnet: Preparing An IPv6 Address Plan

SURFnet's IPv6 Addressing GuideThe team at SURFnet has created an excellent document called “Preparing an IPv6 Address Plan” that walks through the many different steps and concerns that you need to consider when creating a plan.  The September 2013 version of the document is available from SURFnet’s website.

After briefly touching on the basics of IPv6 addressing and also the idea of simply not having an IP address plan, the document gets into a very detailed description of how you might go about creating an IPv6 addressing plan.  It includes several examples and some excellent recommendations. The document concludes with some good suggestions around managing and addressing hosts (end-user devices) now that you have your address plan.

It’s an excellent document and it is great that SURFnet has made this available and has continued to update it with the latest information.

Please visit our IPv6 Address Planning page for other similar resources that can assist with developing an IPv6 address plan.