November 2011 archive

Awesome Video of NY Marathon – See What 47,000 Runners Looks Like!

Amazing video from the NY MTA showing the different waves of runners starting the 2011 New York City Marathon this past Sunday on the Verrazano-Narrows Bridge. Truly incredible to see what 47,000 runners looks like...

Video: Voxeo’s New 60,000 Sq. Ft. Co-Working Office Space Featured in Fox News Interview

Want to see what Voxeo's cool new office space looks like? The 60,000 square feet that also includes "co-working" space for startups?

Kudos to my former colleagues at Voxeo and to CEO Jonathan Taylor in particular for this great video interview on Orlando's Fox 35... check it out:

It's both a very cool space for Voxeons and also a great idea to create a startup incubator right there in the heart of downtown Orlando.

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

First Update Started To “Migrating Apps to IPv6” – Any Further Feedback?

After moving through a job change and reaching a steady state with a family medical issue, I’ve finally got some cycles ahead of me to get back to something I’ve wanted to do for several months now… get an update out to this book!

I’m currently writing more text and am looking to do the following to the book in this update:

  1. Add a few more graphics to illustrate points, particularly the “happy eyeballs” concept.
  2. Expand coverage of the “privacy address” issue.
  3. Expand on the issues around Carrier-Grade / Large-Scale NAT.
  4. Add in some of the lessons from World IPv6 Day on June 8th.
  5. Add examples / case studies from people who have gone through the migration of their app over to IPv6.

On this final point, I have a few developers who I am contacting to see if they are willing to share their story, but I am definitely open to including more case studies. If you have migrated one of your applications to work on IPv6, I’d love to hear from you.

Beyond this list, do any of you have other points you would like to see included in the book? Or areas in the book that you would like to see expanded?

Please either leave a comment here or drop me an email to let me know. Thanks!

I’m not sure of the exact timeframe but I’m hoping to get an update out by the end of November.

P.S. Note that any of you who bought the ebook directly from O’Reilly will be automatically notified when the new version is published online.

My Report into For Immediate Release Podcast #623 – Oct 31, 2011

In this week's For Immediate Release episode #623, my report covered:

And if you listened to the very end of my report you would have heard an additional contribution from a "helper". :-)

You can, of course, listen to the episode online now.

Video: Google’s Matt Cutts on "Cloaking" and Why It Is Bad

Matt Cutts at Google recently posted this useful video explaining what "cloaking" is ... and why it is bad for both the user experience and also for SEO / search engine results. He also explains how cloaking is different from providing distinct content for mobile audiences versus regular visitors.

I'll admit that I've never had enough interest in "gaming" Google to go to the desperate measure of this kind of cloaking... but obviously people are out there and doing it:

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

Vim is 20 Years Old Today!

Amazing to read via Ars Technica that Vim is 20 years old today! In the proverbial “vi vs emacs” religious war, I’ve always come down firmly on the side of vi/vim…. but mainly because I started using vi 25+ years ago back in the mid-1980s when vi represented a quantum leap forward from “ed” and “ex”! 🙂

I climbed the steep learning curve for vi/vim many years ago, wrote my .vimrc macros and continue to use it extensively even today. Of course, today on my Mac and Linux systems I’m using vim vs. actual “vi”.

The Ars Technica article has a great history of Vim and is well worth a read for those who use vim as their editor-of-choice. (And even for those who don’t…)


Want to Learn About Deploying IPv6, DNSSEC? Attend the ION Conference in Toronto on Nov 14th

Would you like to learn about how to deploy IPv6? Would you like to hear from people who are already using IPv6 within their networks? Would you like to learn a bit about DNSSEC and how it can help you secure your online presence?

If so, please join us in Toronto, Ontario, Canada, for our next "Internet ON" (ION) Conference on Monday, November 14, 2011, starting at 12:30pm and sponsored by the Internet Society (my new employer). The sessions on the agenda include:

  • New ISOC Initiative – Bridging the Divide Between IETF Standards and Industry-wide Deployment
  • Panel Discussion: Challenges and Opportunities in Deploying IPv6, DNSSEC, and Other Key Technologies
  • World IPv6 Day Recap (my presentation)
  • Ask the Expert: Next Steps to Implementing IPv6
  • Closing Remarks and Q&A

We're looking forward to providing a great session for people to ask questions and talk about how to get these technologies actually deployed in networks today.

The ION conference is part of the larger 2011 Canadian ISP Summit that takes place on the following two days and is included as part of the registration for the Canadian ISP Summit.

However, registration for the ION conference is FREE if you just want to attend the half-day session on Monday. You can sign up through the Canadian ISP Summit registration page, where one of the available options is for the ION ONLY registration.

(NOTE: If you do sign up for the free ION Only registration, the lunch and dinner listed on the agenda are not included. Those are part of the full registration.)

If you do want to register for the full Canadian ISP Summit, which has a great agenda of technical and business talks , we have a discount code of "ISOCDC" which can get your $50 off the registration if used by November 11, 2011.

We just had a very successful ION event in Buenos Aires last month and we're looking forward to great conversations and discussions up in Toronto - I hope to see you there!

P.S. A couple of people have already asked me if I'm going to be able to spend more time in Toronto (and meet them). Unfortunately due to family medical issues I'm just in Toronto for Monday and will be flying back Tuesday morning. Normally I would have loved to stay for this full event because some of the other sessions look great - and Toronto is also an outstanding place to visit.

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

Oops! Google’s GMail iPhone/iPad/iOS App Pulled From AppStore

Well, Google's iPhone/iPad/iOS app was there for a little bit in Apple's AppStore... but now it's been pulled down because of "a bug that broke notifications". I did download the app a few hours ago to my iPhone and iPad and saw the errors mentioned in the blog post on both the iPhone:

Gmail iphone error

and the iPad:

Gmail ipad error

It's too bad, because in my initial usage, the app seems to work very well. Here's a shot of my inbox that looks like, well, pretty much any other email inbox:

Gmail ipad inbox

As Google's blog post indicates, the app has some cool features and use of gestures. I'll be using it for the next few days to see how it works.

Meanwhile, Google's team is obviously going off to make the notifications work!

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

44% of SIP Implementations at SIPit 29 Supported IPv6!

Last week (Oct 24-27) was the 29th SIPit interoperability test event hosted by ETSI in Monaco. Organizer Robert Sparks has provided his usual outstanding summary of what occurred:

The key point for me, given my new role, was right up at the top:

44% of the implementations present supported IPv6.

Now, of course ideally we'd like that to be 100%, but hey, it's at least a good start!

There is also some narrative further down the report about "IPv6 Focused Tests" with some interesting info. One interesting note seems to be this:

Most UAs that supported dual-stack had a configuration to tell the application to ignore any returned AAAAs due to issues encountered in deployments where endpoints autoconfigured IPV6 that didn't actually work.

In the web world this has been referred to as the "happy eyeballs" problem where a browser will try a DNS AAAA record to get to a site over IPv6 and then eventually will fail back to trying the A record to go over IPv4. The delay will cause the user to be very UNhappy. There are a couple of ways to address the issue with the usual one being to try both IPv6 and IPv4 addresses simultaneously and then connect over whichever one responds back first. (There is an entire "happy eyeballs" Internet-Draft that goes into this topic for those interested.)

From this simple sentence it would sound to me like the implementations are NOT supporting a "happy eyeballs" approach for SIP but are rather providing an "ignore IPv6" configuration setting. I wasn't there so I don't know... but I would hope that over time all dual-stack SIP implementations would move to supporting this kind of approach (versus disabling IPv6).

It was also good to see that tests occurred in a mixed environment:

We successfully tested calls going though a mix of v4 and v6 hops (accruing Via and Route/Record-Route headers with addresses in both families.

Wearing my security hat I was also pleased to see this:

80% of the endpoints present supported SRTP using sdes

Again, you'd love 100%, but at least this shows the availability of SRTP should companies decide to enable SRTP.

Lots of other great commentary in the SIPit 29 summary around STUN/TURN/ICE and many other issues. Definitely worth a read if you are interested in SIP.

And... if you a creator of SIP-related hardware and software, watch the SIPit website for news of the next SIPit event so that you, too, can join in the testing!

And if you have not heard of SIPit before, here's a video I did back in September 2009 with organizer Robert Sparks:

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

How To Shorten a Web Address (URL) To Put In a Print Newsletter

macro pixels url cliche
Have you wanted to put a web address (technically called a "URL") in a printed newsletter, article or other document so that readers could go to that website? But when you look at the web address, it is a big long ugly address that no one in their right mind is going to type?

There's an easy solution!

Driven mostly by the character limitations of social networks like Twitter, there is an entire series of services out there that offer "URL shortening"[1]. The first that many of us found was, which still works great. Personally, my choice these days has been bitly, primarily because it provides tracking statistics on the number of people who use your link. There are literally another 100 or so URL shortening services out there that you can choose from.

Regardless of what service you choose to use, the steps are basically the same.

1. Identify the long URL you want to shorten

For example, say that you wanted to include in a newsletter, article, church bulletin or similar printed document the link to this TIME Magazine special report on "The World at 7 Billion". Unfortunately, TIME's website uses absolutely hideous URLs:,28804,2097720_2097782,00.html

That's a URL that not even an engineer could love! It's too long, so it will probably split across lines if it is in a printed newsletter... and it has all those numbers which would be extremely easy for someone to mess up if they were actually to try to copy this URL from the newsletter. Imagine if you were going to put this into a printed newsletter with text like this:

To learn more about challenges facing the world as we now have more than 7 billion people on this planet, read the TIME Magazine special report at,28804,2097720_2097782,00.html

How many readers are really going to be able to copy that into their browser without any errors? How many will even try?

2. Enter the long URL in a URL shortening site

On you have identified the long URL, you just need to go to whatever shortening service you want to use (TinyURL in this case) and enter in the long URL (I just do a copy/paste from the browser address window):


Once you click the button to shorten the URL, you'll get back a screen like this containing your shortened URL:


In this case that big long hideous URL was shortened to just:

That's it!

3. Copy the short URL into your print newsletter/document

Now all you need to do is copy that short URL into your newsletter text. For instance, here's that same text as above:

To learn more about challenges facing the world as we now have more than 7 billion people on this planet, read the TIME Magazine special report at

MUCH better! Odds are that most folks can enter that URL successfully into their browser and get to the article.[2] You can, of course, even make it a bit more readable by dropping the "http://" off the front of the URL if you can safely assume of our readership that the "" would clue them in that this is a web address.

You're done!

Bonus: Creating an even-more-readable custom URL

Now, "" is probably something that most people could easily copy over into their browser, but what if you could make it even easier for readers to remember the URL?

Note in the site this box for a "Custom alias":

Tinyurlshortening alias1

What you can do is enter whatever text you want in that box, and, if that URL is available, the service will use that text as the shortened URL. For instance, I tried "7billion" and "7billionppl" but both were already taken. However, "7billionpeople" worked:

Tinyurl alias2

So now I can give out this URL to point to the article:

Let's take a look at my proposed printed newsletter text again:

To learn more about challenges facing the world as we now have more than 7 billion people on this planet, read the TIME Magazine special report at

Now that ought to be something that people can easily remember and/or copy over into their browser without any errors.


... my customized URL was longer than the original shortened URL.

That's okay! It's far shorter than that big ugly URL used by TIME's website, and it is far more "readable" than the random group of letters and numbers originally provided by

Remember... the goal is to put something in print that people can actually be successful in typing into their browser address window. If you have to make it a little bit longer in order to make it more readable, that may be okay.[3]

One final note - URLs from a shortening service generally CANNOT be re-used. Once the shortened URL (custom or randomly generated) has been created, it is fixed forever and always to point at whatever longer URL was entered in the service. I say this because if you are playing around to see what kind of custom URLs might be available, you need to make sure that the real longer URL is what you are shortening... because you won't have a second chance.

Again, there are at this point literally hundreds of URL shortening services out there. They all work pretty much the same and will let you make your print newsletters/documents MUCH more readable - and make it so that readers just might actually type in the link and go do the site you are referencing!

[1] For those who want more details about the "URL shortening" process, there is a lengthy Wikipedia article on the topic.

[2] One reason that I'm a fan of using bitly for URL shortening versus is that bitly tracks who actually uses your URL and shows you statistics and charts so you can see that your URL is actually being used. Now, unlike TinyURL, you do have to register for a free bitly account in order to use their service.

[3] And I could have spent some time trying to find a shorter URL that wasn't taken... but there's a tradeoff between shortness and readability. "7billipeople" was probably available, too, but people aren't going to recognize that

Image credit: chrisdlugosz on Flickr

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