Tag: video

The Live Video Streaming Nightmare: What Do You Do When YouTube Won’t Start? (And Lessons Learned)

What do you do if you go to start live video streaming of an event - and the streaming service you use won't start??? How do let people waiting to watch know? How do you fall back to another service?

Last month at the IETF 90 meeting in Toronto I experienced this nightmare of anyone doing live video streaming across the Internet. We had a presentation at noon on Thursday that we had widely publicized in social media and via email. The cameras were all set up. The producer was all ready to do the switching and encoding out to YouTube. Everything was good to go.

Then at 11:45am, I went to do my part in the process. I needed to login to the IETF YouTube account and basically click the "Start Streaming" button inside the "live event". At that point the YouTube servers would accept the encoded stream from the producer's gear and the stream would go live.

BUT... instead I got this message in a bright red bar across the top:

Ytl maintenance 500 The message read:

YouTube live is undergoing maintenance. Events cannot be created, started or stopped. Events already started will continue to stream uninterrupted.

Yes... we had no way to START the live video stream!

Over the next few minutes I kept refreshing that page but the warning stayed up there. I was getting rather nervous as the launch time approached!

Now, as it happened, we had already planned to have a second live video steam going out for the event through a different service, Livestream.com, for a different reason.

Why The IETF Uses YouTube For Live Video Streaming

To explain a bit more, we have been using Google's YouTube live video streaming for some of the larger IETF plenary sessions for five reasons:

1. The live video stream is available over both IPv4 and IPv6.

2. The stream works easily across pretty much all desktop and mobile devices.

3. Google's live streaming infrastructure seems able to scale to whatever capacity is needed.

4. The recording of the stream is immediately available after the event in the IETF's YouTube channel.

5. There is no cost for using the service beyond our local costs to produce the content (and no infrastructure that the IETF itself has to maintain).

Of these, really the most critical reason for using YouTube live streaming is the first - that it streams out over IPv6.

The IETF is the organization behind the IPv6 specification and has declared that all new IETF standards need to incorporate IPv6. Therefore in the spirit of "eating your own dog food" the IETF tries to use services that work over IPv6 whenever possible. Other live video streaming services have met the reasons 2-5 above, but not the #1 reason of working over IPv6.

We have specifically been using what Google used to call "YouTube Live" but now seems to just be calling "YouTube live events" versus Google's newer "Hangouts On Air (HOA)". These YouTube live events are events you schedule in advance and can use with advanced video encoders. An advantage is that these events provide streaming configuration info that I can provide in advance to the company running the audio and video at the event so that they can be prepared in advance. YouTube also helpfully provides a countdown timer for people visiting the event page. We haven't switched to using HOAs because they haven't yet provided the advance configuration information we want.

Anyway it has all worked well for live streaming out plenary sessions for a couple of years now.

Google Doesn't Live Stream Into Germany

However, as we discovered again that week.... Google will not stream live video into Germany! It seems Google has a legal dispute with a German intellectual property rights organization (GEMA) and Google has decided that rather than run into trouble with GEMA they will simply NOT allow live streaming into Germany.

So, alerted to this issue by some IETF remote participants in Germany who were unable to watch the live video streams of the technical plenary earlier in the week, we had arranged to also stream this Thursday session out over the Internet Society's Livestream.com account. Now, unfortunately it would not be available over IPv6 because Livestream.com still only works on legacy IPv4 networks, but Livestream.com did not have the streaming restrictions Google had and so at least people could view the stream in Germany. As a bonus, all the "subscribers" to the Internet Society's Livestream.com channel would also get notified and potentially be able to watch the stream - but the primary reason was so that people in Germany could watch the video stream.

The great thing about IETF meetings is that a massive amount of Internet connectivity is brought into the meeting hotel (because you have 1,200+ engineers who do most of their work across the Internet!) and so there are NO bandwidth problems for streaming. We could probably stream out to a dozen different live streaming services simultaneously if we set up our local software/equipment to do so.

Making The Alternate Stream The Primary Stream

The good news for us was that this "alternative" live video stream set up purely for viewers in Germany could now become the primary video stream. I rapidly updated the Google+ "event page" for this session to note the new URL for streaming and we spread the word through IETF social media channels and email lists. It wasn't 100% seamless but we were able to get people watching the live video stream.

We were also able to direct people to some of the other IETF remote meeting participation mechanisms, including audio streaming and a conferencing system called "Meetecho" that streamed the slides and lower webcam-quality video.

Throughout the hour-long event I kept checking the Live Control Room inside of YouTube to see if we could start the original stream, but we were never able to do so. A couple of times the red warning box went away, but we could not establish a connection from YouTube's streaming service to our equipment on the ground there in Toronto. Finally, as the time went on it became clear that the connection wasn't going to happen and so I just gave up trying.

The good news is that the producer was also making a local copy of the stream that we would be able to upload later to the IETF's YouTube channel.

Lessons Learned

I took away from this experience three primary lessons for all future live streaming sessions. Do note, too, that I think of these as generic lessons for all live streaming services and events. It happens that this time the failure was with Google's YouTube live events service, but the failure could have been with Livestream.com, Google's Hangouts On Air, Ustream or any of the many other live video streaming services out there.

1. Always Promote An Event Page Separate From The Streaming Service

We were able to rapidly redirect people to the new location of the live video stream in large part because we had been promoting the Google+ event page as the place to go to watch the live stream. We had promoted this on the IETF's Twitter account, Facebook page, Google+ page and also over various IETF email lists and on various other websites. All the promotion pointed people to this page.

So the good news was that all we had to do was update this page with the new info and people could switch over to watch the new stream.

We had NOT been promoting the direct YouTube link for the stream. Had we done so, we could have still updated the page through editing the description of the YouTube video and/or leaving comments - but it would not have necessarily been as easy for visitors to see.

Promoting a separate page was a deliberate choice I made based on some previous bad experiences with live streaming where I had to stop a streaming session and restart with a brand new URL. For that reason I've been promoting a separate page.

In fact, for the IETF Plenary sessions, we've been promoting a separate page under IETF control on the IETF website - http://www.ietf.org/live/ - where we can embed the live stream video and also keep the page updated. At the IETF meeting it is possible for me or someone else to easily go in and update that page. Plus it is a very simple URL that we can promote widely.

I don't honestly remember why we didn't use the www.ietf.org/live/ page to stream out this Thursday morning sponsor presentation other than that the decision to live stream the session happened the day before and for whatever reason we went with a Google+ Event page as the page to promote.

Next time we'll probably promote the www.ietf.org/live/ page.

The key point is that you have a page separate from the live streaming service where you can post updates.

2. Have An Alternate Live Stream Either Active Or Ready To Go

As I mentioned previously, in this case we happened to be set up with a second live stream out through Livestream.com purely because we wanted to test the live streaming into Germany. Had remote IETF participants in Germany not asked about this after being unable to view the earlier technical plenary, we wouldn't have had this second stream active.

Next time, we will have a second live streaming service either active or at least on standby ready to go.

At the IETF meetings, we have the luxury of having an insane amount of bandwidth and so there are not the typical connectivity constraints you find in meeting venues. The software and equipment our producer was using could go out to multiple live streaming services. There is really no reason we can't run multiple streams.

For the IETF we still have the IPv6 requirement, which unfortunately Livestream.com does not yet meet. However, it occurred to us after the session that we could have streamed to a Google+ Hangout On Air (HOA) as that would have also streamed out over IPv6 in addition to IPv4. Of course, that would mean relying on two Google services and so you run the risk of having the technical issues affecting one live streaming service also affecting the other - plus there was the whole "streaming into Germany" thing.

We'll definitely keep investigating what other live streaming services may work over IPv6. There are a good number of live video streaming services out there and the number seems to be growing. The company producing the video stream for us also had their own streaming server that we might be able to use as a backup, too. And, yes, we can also have an IPv4-only streaming service available if everything else falls through.

Now, in non-IETF environments where I do have to worry about bandwidth constraints, I will at least have a plan for how I can rapidly spin up a second stream if the first one fails. That's really the key point. What is Plan B and how fast can you make it happen?

3. Have Access To Relevant Social Media Accounts And Other Methods Of Letting People Know

This is perhaps a subset of Lesson #1, but another critical part of our success in redirecting people to the second live stream was that we had access to the relevant social media accounts and other means of spreading the word. I had access to the IETF Google+ page and could make the updates there. Someone else was able to send out a tweet with the new link to the live stream. An email was sent out to all attendees and to other relevant email lists letting them know about the link.

The key point is that when we updated the event page with the new information, we could let people know!

In The End...

... the session was streamed live across the Internet. It was recorded and made available for later viewing. And... we learned a few lessons to make sure our live streaming infrastructure is more resilient next time so that this potential "nightmare" becomes nothing more than just a minor bump and redirection.

What about you? If you do live video streaming what steps have you taken to ensure you can keep streaming in cases like this?


I also recorded an audio commentary about this situation:


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


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):

Livestreaming of video over IPv6

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):

live streaming over IPv6

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.

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:

Googleplus hangouts audio settings 450

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:


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:


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

"It’s all content! It’s just story!… They want stories! They are dying for them." – Kevin Spacey’s Brilliant Speech

Kevin spaceyDo you want to understand the future of television? of online video? of the future of creating video content? Actor Kevin Spacey really nails it in this speech at the Edinburgh International Television Festival.

If you have 45 minutes, the entire speech can be found on YouTube:
 

Some of the key points I enjoyed were around the 39-minute mark, but the whole piece is a brilliant look at where online video and television is at right now.

If you only have a few minutes, someone at the Telegraph in the UK made a 5-minute edited version that hits many of Spacey's key points:

It truly is a great analysis of where we are today... and where the opportunities are...

I loved, too, that Spacey said something very close to what I wrote here back in January 2012 about the key to reducing piracy: give the people the content they want in the channel they want at a reasonable cost. It really is that simple.

I do hope that people in leadership positions within the media industry will watch / listen to this speech... if they want their businesses to survive and thrive in our new world, I believe many of the keys can be found here in this talk.

What do you think? Do you agree with Kevin Spacey?


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


You Can Now Call Into Google+ From Regular Phones – Google Connects Google Voice To Hangouts

Want to hear the sound of Google further disrupting the world of telecom? If you have a Google Voice number and also use Google+ (as I do) with the Hangouts feature enabled, you'll soon be hearing this new sound if you haven't already.

UPDATE: I have written a follow-up post responding to several comments and expanding on several points.

An Unexpected Ringing

Yesterday a random PR person called the phone number in the sidebar of this blog to pitch me on why I should write about her client. This phone number is through Google Voice and I knew by the fact that my cell phone and Skype both started ringing simultaneously that someone was calling that number.

But as I was deciding whether or not to actually answer the call, I realized that there was another "ringing" sound coming from my computer that I had not heard before. Flipping quickly through my browser windows I found my Google+ window where this box appeared at the top of the "Hangouts" sidebar on the right:

Googleplus incoming call

Now, of course, I HAD to answer the call, even though I knew from experience that most calls to that number are PR pitches. I clicked the "Answer" button and in a moment a regular "Hangout" window appeared, complete with my own video, and with an audio connection to the phone call.

Hangouts phonecall

The PR person and I then had a pleasant conversation where I rather predictably determined quickly that she'd probably never actually readthis blog or she would have known that I've never written about her client's type of software. Be that as it may, the audio quality of the call was great and the call went on without any issues.

A subsequent test showed me that I also had access to the dialpad had I needed to send any button presses (for instance, in interacting with an IVR or robocall):

Hangout keypad

The only real "issue" with the phone call was that when I pressed the "Hang up" button I wound up still being in the Hangouts window with this message displayed:

Google+ Hangouts

The irony of course is that that phone number was never in the "video call"... at least via video. Regardless, I was now alone in the video call with my camera still running. I needed to press the "Exit" button in the upper right corner of the Hangouts window. Outside of that, the user experience for the phone call was fine.

The Future Of Google Voice?

Like many people interested in what Google is doing with Google+, I had read the announcement from Google of the new streams and Hangouts features last week and had gone ahead and installed the iOS Hangouts app onto my iPhone to try it out (marking Google's entrance into the OTT VoIP space). But nowhere in there had I seen that this connection was going to happen between Google Voice and Hangouts. I'd seen speculation in various media sites, but nothing direct.

So it was a bit of a surprise when it happened... particularly because I'd done nothing to enable it. Google had simply connected my Google Voice number to my Google+ account.

I admit that it is a pleasant surprise... although I do wish for the sake of my laptop's CPU that I could somehow configure it to NOT launch myvideo when I get an audio-only call. Yes, I can just go stop my video, but that's an annoying extra step.

It seems, though, that another feature removed from Hangouts, at least temporarily, was the ability to make outbound phone calls. Given that all signs of Google Voice were removed from Google's interface and replaced by "Hangouts", this has predictably upset people who used the service, particularly those who paid for credits to make outgoing calls. There does seem to be a way to restore the old Chat interfacefor those who want to make outgoing calls so that is at least a temporary workaround.

Google's Nikhyl Singhal posted to Google+ about the new Hangouts featuresstating these two points:

1) Today's version of Hangouts doesn't yet support outbound calls on the web and in the Chrome extension, but we do support inbound calls to your Google Voice number. We're working hard on supporting both, and outbound/inbound calls will soon be available. In the meantime, you can continue using Google Talk in Gmail.

2) Hangouts is designed to be the future of Google Voice, and making/receiving phone calls is just the beginning. Future versions of Hangouts will integrate Google Voice more seamlessly.

I'm sure that won't satisfy those who are troubled by the change, but it will be interesting to see where they go with Hangouts and voice communication.

(Note: the comment thread on Nikhyl Singhal's Google+ post makes for very interesting reading as people are sounding off there about what they'd like to see in a Hangouts / Google Voice merger.)

Will Hangouts Do SIP?

Of course, my big question will be... will Hangouts let us truly move beyond the traditional telephony of the PSTN and into the world of IP-based communications where can connect directly over the Internet? Google Voice once briefly let us receive VoIP calls using the SIP protocol - can Hangouts finally deliver on this capability? (And let us make outbound SIP calls as well?)

What do you think? Do you like this new linkage of Google Voice PSTN numbers to your Google+ account?


UPDATE #1 - I have written a follow-up post about XMPP support in Hangouts and confusion over what level of XMPP/Jabber support is still in Google+ Hangouts.


Audio commentary related to this post can be found in TDYR episode #009 on SoundCloud:


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


Video: My Discussion of DNSSEC and DANE with VoIP / SIP on The VUC

What role could DNSSEC potentially play to help better secure voice-over-IP (VoIP)? How could the DANE protocol help provide a stronger level of security to SSL/TLS certificates used in VoIP? What VoIP software out there right now works with DNSSEC?

Back on May 3, 2013, I participated in a VoIP Users Conference (VUC) call on precisely these questions. In the call that went for close to 90 minutes I outlined what DNSSEC and DANE are all about, how they work in a web browser world and how they could potentially work in a world of VoIP with SIP. We also discussed the current support for DNSSEC in the Jitsi softphone and the Kamailio SIP server. There was also a healthy question and answer period where we went off on different tangents. I referenced a presentation I made at SIPNOC 2013 and the slides for that presentation as well as other resources are available from the Deploy360 DNSSEC and VoIP page.

It was a great call and the video is available on YouTube:

If you want to just listen to the audio, you can play or download it from the VUC episode page.


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


VUC Today: The Jitsi VoIP Softphone – Join The Call To Learn More!

JitsiWhat is new with the Jitsi softphone these days? What new capabilities does it have as it continues to expand its support of SIP, XMPP and other protocols?

I've long been a fan and user of Jitsi, in part because it supports IPv6 and is the only VoIP softphone I know of right now that supports DNSSEC, something I'm continuing to experiment with, so I'm looking forward to today's "VoIP Users Conference (VUC) call at 12 noon US Eastern - about 2.5 hours from now.

You can watch it live via a Google+ Hangout On Air, or call in (potentially using Jitsi!) via:

  • sip:200901@login.zipdx.com
  • +1 (646) 475-2098
  • Skype:vuc.me

There's also an IRC backchannel where links are shared, questions are answered and other comments occur.

And for those of you using Google+, there is a Google+ Event you can join.

It should be a good show! (And yes, you can watch it / listen to it later...)


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


Alec Saunders Is A Rock Star In RIM’s Strange New Blackberry 10 Video

BlackberryOh... my. As anyone who knows me can attest, it's extremely hard to render me speechless... but I admit to sitting here this morning staring at the screen with a rather uncomprehending expression on my face and with my mouth hanging open...

Sometime after my friend Alec Saunders joined RIM last year as their VP of Developer Relations, I said to someone that while I admittedly did view his new mission as somewhat akin to tilting at windmills, he was perhaps just the kind of "rock star" that RIM needed. A very passionate and dynamic presenter... a very charismatic leader who could rally people... a creative guy with a theatre background... someone who thinks differently...

... never in my wildest ideas did I expect that we would be seeing Alec AS an actual "rock star" in a music video! But yes indeed, here he is with two other VPs from RIM in a remake of the famous REO Speedwagon song. (Alec is the main singer.)

Unbelievable.

My speechlessness soon gave way to laughter ... and appreciation for them for doing something rather different. If they were looking for a way to be "remarkable" and memorable, they found it.

Now, somewhat predictably, some of the tech press are calling this an act of sheer desperation and I'm seeing comments in social networks calling it "painful" and "cringeworthy."

But that's the point, really... the video is getting people talking about Blackberry!

Even me, who hasn't really written about RIM and Blackberry here since, oh, last year shortly after he joined RIM. :-)

The video is over the top... I did cringe a couple of times as they twisted lyrics to fit the tune. But it made me smile. And laugh. And I'll remember it!

Will it attract new developers to the BB10 platform? Will it keep existing developers staying loyal to the platform?

I don't know. They have a huge uphill battle to fight. But hey, at least this was something fun and different!

Kudos to Alec and all the folks at RIM for what was obviously a great amount of time, energy and talent into doing something definitely unique!

And here's the full video for those who want the experience:


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