Just a guy in Vermont trying to connect all the dots...
Dan York
Author's posts
Oct 03
SIP Forum IPv6 Task Group Call – Weds, Oct 3rd, 19:00 CEST, 1:00pm US Eastern
The SIP Forum IPv6 Task Group will be having its next conference call today, October 3, 2013, at: 19:00 CEST, 18:00 BST (UK) and 1:00 pm US Eastern (and see other times). Task Group co-chair Andy Hutton sent out this agenda and call-in information:
- Status of the draft for developers
- Status of mine and Gonzalo’s draft to update RFC 3263
- Happy Eyeballs for SIP
3.1. Connection oriented
3.2. UDP - IPv6 and related protocols
4.1. MSRP
4.2. XCAP/HTTP
4.3. ICE/turn
4.4. Other related protocols
Anyone is welcome to join the SIP Forum’s IPv6 mailing list and also to join in the effort. The group is working to “evaluate current best practices and enable and promote migration to SIP over IPv6.”
It’s great to see the work they are doing because we definitely do need to have IP-based telecommunications working over IPv6!
Oct 02
Successful Live Video Streaming Over IPv6 Using Google+ Hangouts On Air and YouTube
SUCCESS! We did prove this week that you can do live streaming of video from an event out over IPv6. As we wrote about earlier this week, one of our objectives at ION Krakow was to prove that we could to a live stream / webcast out of an event over IPv6. Well, to be more precise, we wanted people to be able to receive the livestream over IPv6.
As it turned out, the network at PLNOG 11 (where ION Krakow occurred) was IPv4-only so we were streaming our video signal from ION Krakow only over IPv4 out to Google’s servers which were then streaming the video out over both IPv4 and IPv6.
We did have a few challenges with the actual broadcast (which I mention at the end), but the key point is…
it worked!
People were able to watch the live stream on both Google+ Hangouts On Air (HOA) and YouTube over IPv6 connections. In our article we’d asked if some people watching could send us screen shots and several people did exactly that – as shown below.
Live Streaming To A Dual-Stack Computer
Longtime IPv6 advocate Shumon Huque tweeted out a screenshot showing that he was watching the live stream on our YouTube channel and was getting most of the video stream connections coming in over IPv6 (click/tap the image for a larger view):
He’s using the very cool IPvFoo/IPvFox browser extension to show the connections from the web page and whether they are over IPv4 or IPv6. Being on a dual-stack computer, Shumon’s web browser is going to use a “Happy Eyeballs” algorithm to determine for each requested connection whether IPv4 or IPv6 is fastest and so you will see situations like this where parts of the connection are still over IPv4.
Live Streaming To An IPv6-ONLY Computer
Lee Howard at Time Warner Cable took it a step further and turned IPv4 completely OFF on his Macbook Air. He then sent us this screenshot showing he was watching the video streaming over Google+ Hangouts on Air and also showing the output of a terminal window showing that his wireless interface had only IPv6 running (click/tap the image for a larger view – and yes, we blanked out part of his IPv6 addresses for his own privacy):
This proved to us rather definitively that our live stream was fully available to people over IPv6!
Challenges Unrelated to IPv6
We did have a couple of challenges with the actual broadcast content that were unrelated to IPv6. First, I missed a key setting in Google+ HOA where you specified the audio connection separate from the video connection. As a result for the first hour and 45 minutes until we figured out the problem we were streaming audio from my laptop’s microphone instead of from the event a/v system! (Oops!) The good news is that I was also running a separate audio recording directly from the mixer and so now I can go back and upload a new video that merges the camera video with the full audio stream.
The second issue was that we unfortunately discovered that Google+ Hangouts On Air have a 4-hour maximum time limit when the HOA stopped broadcasting right in the middle of the IPv6 panel! We had to restart the HOA which restarted the YouTube stream and required all viewers to go to new URLs to watch. The good news here is that I was separately recording the video stream to disk so even though we weren’t broadcasting the stream I have a local copy that I can now cut up and upload to YouTube.
There were a host of other “lessons learned” for this experiment that we’ve captured for the next time we do a live stream using Google+ HOA. Thank you to everyone who participated in our experiment!
Conclusion – It Worked!
The great news out of all of this is that we proved that you can run a livestream for an event in such a way that people can watch the video stream over IPv6 – including on an IPv6-only network. This is excellent to see and a good step for the continued IPv6 deployment.
Kudos to the teams at Google for making both Google+ Hangouts / HOA and YouTube all work over IPv6. Given the large size and ease of use of those services, this is great to have available.
The great thing is, of course, that livestream producers don’t have to do anything to make their live streams available over IPv6. Simply by using Google+ HOA or YouTube the livestream becomes available over both IPv4 or IPv6.
This is how it should be!
And notice again that the live stream goes out over IPv6 even if you are broadcasting from an IPv4-only network. (Again, as it should be.)
We look forward to learning that other livestreaming services provide a similar functionality and allow viewers to watch a live stream over IPv6. We’ll probably look to use this Google+ HOA setup again for our next livestream, although we may also try out “YouTube Live” to see if that works any better for us. (And if there are other livestreaming services out there that will be supporting IPv6, please do let us know and we’ll be glad to look at your service.)
Many thanks to everyone who joined in to help us prove that live video streaming could be done over IPv6 using readily available services[1], and thanks in particular to both Lee and Shumon for sending in these screenshots to confirm availability over IPv6! We’ll be uploading the individual sessions to our YouTube channel and I also intend to write up some general guidelines for live streaming over IPv6.
Great news!
[1] Yes, we could have installed one of the various live streaming servers on our own infrastructure and run it over IPv6, but not every company or organization has the ability to do this. We wanted to try out the existing public live streaming services that anyone can easily use.
UPDATE: In speaking with someone today about this test and the livestreaming, it occurred to me that this really is NOT a milestone, i.e. “the first live streaming over IPv6″, because the reality is that everyone using Google+ HOA or YouTube for live streaming has been getting IPv6 connectivity for those viewers with IPv6 networks. This “live streaming over IPv6″ has just been part of what Google has been offering for some time now. We may have been one of the first ones to actively try to measure and demonstrate that we were live streaming over IPv6… but lots of other people have been doing it for quite some time now… but they just haven’t necessarily known about it.
And really, why should they care? Live streaming over IPv6 should “just work” without the users on either the broadcasting or viewing end ever noticing.
Oct 02
A Critical Audio Setting In Live Streaming With Google+ Hangouts On Air (That I Missed!)
Do you have the correct audio stream configured in Google+ Hangouts On Air (HOA) when you are doing live streaming of an event using a HOA? When we ran our live stream out of ION Krakow on Monday, I mentioned that we hit the undocumented 4-hour maximum time limit, but we actually had a larger issue that for the first 1 hour and 45 minutes -
our live stream's audio was terrible!
Truly un-listenable at times. :-(
It turned out that while I had correctly configured Google+ HOA to use the proper video setting for the "Wirecast Virtual Camera", I didn't realize that I had to separately configure the audio seeting to specifically pull in the audio stream from my capture device:
I just mistakenly assumed that HOA would pull the audio from the camera... but instead it was getting the "Default microphone", meaning the mic on my laptop.
Interestingly, we didn't discover this in testing because when I was doing the testing with a wireless microphone I was sitting at my laptop and so naturally the audio quality was excellent. I did walk up to the front of the room at one point but even then there was no one in the room and my voice could be heard well.
The good news is that I had a separate recording going from the house mixer into my Zoom H4N, so I have a complete audio track for the event. Now I just have to go back and create a new video recording, stripping out the old bad audio track and syncing the backup recording. Not ideal but will at least give us videos of the sessions that we can upload.
The bad news is, of course, that the experience of the initial viewers was quite poor and I'm sure some of them did not stay around to watch more of the session under the assumption it would remain that way.
Why did it take so long for us to fix it?
Well, I was the one operating the livestream and I was speaking at the beginning and then moderating a panel discussion, so it was purely the case that I wasn't in a position to be able to diagnose and sort out the fix. During the break I finally had a chance to do so.
It was also a valuable lesson in monitoring. To look at the audio levels I was watching the graphical meters in Wirecast but I wasn't watching the level in the Google+ HOA screen! That was ultimately how I realized what was wrong. It also pointed out that we need to be running a second machine that is watching the actual livestream so that we can hear the issues ourselves.
All in all a valuable set of lessons that I'll be adding to my checklist for the next time we do a livestream using Google+ Hangouts On Air.
P.S. The key point of the whole exercise was to prove we could livestream an event out over IPv6, which did in fact prove to be successfu1!
If you found this post interesting or useful, please consider either:
- following me on Twitter;
- adding me to a circle on Google+;
- subscribing to my email newsletter; or
- subscribing to the RSS feed.
Oct 01
Speaking at ENOG6 On Oct 2 About DNSSEC And DANE – Will Be Streamed Live
What is the current status of DNSSEC deployment? What is going on with DANE? What are some of the remaining challenges?
Tomorrow, Wednesday, October 2, 2013, I’ll be speaking about these DNSSEC/DANE topics at the “Eurasia Network Operators Group (ENOG) 6” event happening in Kiev, Ukraine.
My particular presentation is in the plenary block beginning at:
- 15:00 Eastern European Summer Time (EEST), which will be
- 14:00 in most of Europe (CEST) and
- 8:00am US Eastern.
I’m the second presentation in the block and so I’ll start whenever the previous presenter finishes… probably sometime around 15:30. My talk will be probably around 30 minutes at the most.
The session will be streamed live as part of the ENOG webcast available at:
http://www.enog.org/live-stream/
(And no, I don’t think the actual livestream is available over IPv6, as we did yesterday, but the ENOG website is available over IPv6.)
If you’d like a preview, my slides are available from the ENOG6 Presentations page, in both PDF and PPT.
I’m looking forward to giving the presentation… it’s a good group of people here at ENOG. They also do NOT typically hold back in terms of asking questions from the microphones which makes for good sessions and dialogue.
And if you are at ENOG6, please do say hello… I’ll be around all day tomorrow (and am here tonight).
Oct 01
OpenDNSSEC Offering Free DNSSEC Training Oct 10-11 in Stockholm, Sweden
Interested in learning more about how to use OpenDNSSEC to secure your DNS infrastructure with DNSSEC? We recently learned from a post by Patrik Wallström in the DNSSEC LinkedIn Group that there will be a free training class in Stockholm, Sweden, on October 10 and 11, 2013. More information and a registration link can be found at:
https://www.opendnssec.org/support/trainings/
Patrik notes:
You are welcome to attend a free training course in OpenDNSSEC. It is a two-day training, where you get a mixture of theory and hands-on experience. We will be using virtual servers hosted by Amazon, so please bring your own laptop.
The full agenda for the training class can be found on the .SE site.
It’s great to see this training happening in Stockholm – and Patrik notes that people can contact him to discuss offering this training in your community (his contact info is on the training page).
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?
I 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:
- Google+ Hangouts On Air have a 4 hour maximum; or
- 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:
- following me on Twitter;
- adding me to a circle on Google+;
- subscribing to my email newsletter; or
- subscribing to the RSS feed.
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
We’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:
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
What 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.
