Dan York

Just a guy in Vermont trying to connect all the dots...

Author's posts

44% of SIP Implementations at SIPit 29 Supported IPv6!

Sipitlogo
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:
https://www.sipit.net/SIPit29_summary

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 TinyURL.com, 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:

http://www.time.com/time/specials/packages/article/0,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 http://www.time.com/time/specials/packages/article/0,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):

Tinyurlshortening

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

Tinyurlresults

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

http://tinyurl.com/3hy8poy

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 http://tinyurl.com/3hy8poy

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 "tinyurl.com" would clue them in that this is a web address.

You're done!


Bonus: Creating an even-more-readable custom URL

Now, "tinyurl.com/3hy8poy" 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 TinyURL.com 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 TinyURL.com 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:

http://tinyurl.com/7billionpeople

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 http://tinyurl.com/7billionpeople

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

Notice...

... 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 TinyURL.com.

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 TinyURL.com 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:


Looking for a New Gig? Consider a Job at the Internet Society!

IsoclogoInterested in a new work role? Looking to make a change from what you are doing now?

If you have a passion for the Internet - and for protecting the openness of the Internet - then please consider applying for one of open positions at the Internet Society. We have several new positions open, including:

  • Sr. Manager, Next Generation Leaders Programme
  • Internet Development Manager for Africa
  • Application Development Specialist
  • Sr. Director of Business Development and Resource Mobilization

I'm excited about joining the Internet Society and would love to welcome others onboard!


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


Want Your Kids To Curl? Youth Curling Open House Nov 5th in Petersham, MA

Petershamyouthcurling

Would your kids like to try out the sport of curling? Did they see it on the Olympics and thought it looked cool? Or did you see it on the Olympics and think it might be something fun for your kids to try? (Or are you a "youth" reading this post and are interested yourself?)

If so, the Petersham Curling Club is holding a Youth Curling Open House this coming Saturday, November 5, 2011, from 1-3pm. Anyone with interest is welcome to attend.

The Petersham Curling Club has had a great youth curling program and is now looking to let even more people know about the program.

No experience is necessary... just bring your passion and excitement! (Well, and clean sneakers and warm clothes.)

Petersham, MA, is in north central Massachusetts near Athol, MA, and Royalston, MA. The curling club is right off of Route 2 for those coming from other parts of Mass. For me, it's about 45 minutes from Keene, NH, driving straight down Route 32 (the club is on Route 32 in MA). Directions can be found on the club's site.

The Petersham Curling Club is a great 2-sheet facility with very welcoming members and excellent instructors. I'm playing in the evening men's curling league this year and my daughter is in the Saturday morning youth program. It's a great bit of fun ... and they're looking to add even more youth players this year!

Looking forward to the Youth Curling Open House - should be a good bit of fun!

What Would Be Really Cool Is If Google+ Ripples Had…

... some way to search through a large Ripple to find a name (like yours, if you shared the post), so that you could see where that person was in the big giant picture. For instance, in this massive Ripple experiment that I referenced in my post about Ripples:

GoogleRipplesSearch

Right now there's no easy way I've seen to find a person in a Ripple of this size...


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


Klout’s Other Major Fail: Violating Historial Integrity/Accuracy

Kloutlogo
There is a fundamental rule in database theory that when data is recorded in a database, it is "immutable". It cannot be changed. Applications may act on the data, but the integrity of the underlying data is intact.

Consider a database tracking temperatures over time. The temperature sensor at my house might record into the database that it is 31 degrees F right at this time and date.

That data should always remain intact.

If I query the temperature database tomorrow for today's temperature at 8am, the database should say that it was 31 degrees F. If I query the database 5 months from now... or 5 years from now... the database should always spit back the 31 degree temperature.

The historical answer will always be identical.

This is just a fundamental principle of databases that are tracking data over a period of time.

Klout's Revision of History

In the ongoing kerfuffle about Klout's changes to their "influence metric", nicely summarized by Mathew Ingram over at GigaOm (lots of links to read), one point I haven't seen made is this:

Klout revised its (and your) history!

Consider this... back on Monday when I wrote about how I disliked the way Klout is treating its metric like a game, I included this screenshot:

Klout

Now consider this screenshot taken right at this moment that shows my current Klout score and the trend of my score over the last period of time:

Klouttrend

Hmmm... where is that "62"?

Instead Klout now shows that my score was 59-ish.

They changed my history.

Now, in my case, I don't really care. My life will not be any better or worse based on whatever changes happen to my Klout Score. Makes zero difference to me.

But for all those people complaining on the Internet about how their Klout score dropped dramatically... not only did it drop, but...

YOU NEVER HAD THAT HIGHER SCORE!

You might claim you had a Klout score of 50, 60, 70, 80, whatever... but nope, you didn't... the chart shows quite clearly that your score never achieved whatever milestone you thought it did.

Oops.

Changing Algorithms Without Changing History

Now I personally have no issue with Klout changing their algorithm to make it better. In fact, I applaud them for doing so. Algorithms need to change as more experience is attained and more data is collected.

I want better metrics.

So change the algorithm. Go ahead.

But personally I'd love history to be kept intact. Show the change in the algorithm NOW. Sure, the trend graph would show a big drop. Okay. Then, like in Google Analytics, we can all make a notation that the algorithm was changed on such-and-such a date and our score now reflects the new algorithm. No big deal.

The Counterpoint

But what if the algorithm had a fundamental error in it? Shouldn't you go back and revise all the data?

Consider my temperature example - what if I found that the thermometer in my house was actually off by 4 degrees? That it was actually 4 degrees colder outside that it was showing?

Wouldn't it make sense to go back and change all the historical readings for that sensor to be 4 degrees colder? (Assuming I could pinpoint the time at which it started being inaccurate... or just made the assumption that it had always been inaccurate.)

And yes... there's certainly a school of thought that says you should go back and revise history. The other school of thought would be to leave history alone and indicate that from this point forward the sensor data will now be more accurate.

It's obvious which school of thought Klout fits in.

Klout's Ecosystem "Problem"

The "problem" Klout has... and I put "problem" in quotes because it's the kind of "problem" any small startup would LOVE to have... is that they've had a lot of companies and developers using Klout's APIs to build other applications and systems that interact with Klout's metric. In fact, Klout is claiming over 3500 "partners and developers".

And you have to imagine that some % of those developers are engaging in tracking Klout scores over time. They want to track the trend of their own score... or their competitors score... or their clients' scores... or whatever.

All of that trend data just got rendered inaccurate.

It doesn't matter if Application X says that your client had a Klout score of 43 last week.... the official Klout database now says that the client's score was really 32... and it never was 43.

Oops. Now the application has "bogus" data.

Klout's Reporting Problem

Plus, if you were presenting reports or charts regularly to a client (or your management) showing them their Klout score, now you have to go back to the client and say "I'm sorry, but Klout revised their algorithm and you never had that score I told you."

You look like an idiot for trusting a metric that changes like this.

Of course, you're not alone, as Bob LeDrew so eloquently pointed out in his post yesterday "A Klout Upside The Head"... obviously many people are taking Klout's metric very seriously. (And way more seriously than I would even remotely consider.)

The fact that some people are using Klout's metric for business decisions would, in my mind, point to Klout needing to consider historical accuracy/integrity a bit stronger.

Sure, change the algorithm if you need to... but keep the history intact so that your partners and users don't look like idiots.

A Wake-up Call?

In the end will this kerfuffle make people be a little bit more critical of the Klout Score?
Will people realize it is only one of the metrics they should consider?
Will they take a look at other metrics that are emerging?

As the CEO of (Klout competitor) PeerIndex noted yesterday, there are many different ways of defining "influence"... and the market and all these companies are very young.

Will people realize that they shouldn't blindly rely on one simple metric?

While I'd love to believe people might - and we can only hope that at least some people will, I guess I'm cynical enough to think that people want nice, simple, easy metrics... and Klout is delivering that. Give it a few days for all this to blow over and sadly people will probably be right back caring about their Klout Score.

Only now perhaps they'll take occasional screenshots to be able to back up later claims about the score whenever Klout does its next revision of history...


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


My Wife’s Interview About Breast Cancer In The Keene Sentinel

Lori keenesentinel 2
While I've already tweeted, Facebooked and Google+'d about it, I should record here for the sake of completeness that my wife was recently interviewed for what turned out to be an excellent article and photo of her in our local Keene Sentinel newspaper.

The article, titled "KEEPING THE FAITH" by columnist Sherry Hughes, is now available online and was on the front page of the Friday, October 21, 2011, dead-tree edition of the Sentinel as part of a feature on Breast Cancer Awareness Month.

As she will say herself, this was pushing my wife WAY outside of her comfort zone... in stark contrast to me, she is an intensely private person and severely dislikes having her picture taken (even with hair!). She agreed to do the interview when asked by a friend... and then proceeded to do it even after finding out that a photographer would be coming.

It turned out to be an excellent, inspiring and uplifting article (admittedly, I'm intensely biased :-) and I thought the photo of her turned out great. I'm extremely inspired, personally, by how open she's been about it all... "it is what it is", as she says.

Anyway, that's the last chapter in our ongoing cancer saga... a bit of unexpected publicity and a chance to tell her story...

 

Google+ Ripples Provides Awesome Visualization Of Sharing – Check Out These Examples!

Want to see a VERY cool way of visualizing the spread of a post on Google+ out to other G+ users? Using the new "Ripples" featured announced today, this is very trivial to do. Check out this example (of a post that is deliberately being shared around to test Ripples):

Keyanmobli ripples

Now, if you follow the link (or click on the image) to the actual Google+ page, you can then move around the image, zoom in on certain sections and do all the typical kind of movement you might expect in a Google product.

But where it gets even cooler is down at the bottom of the page where you can "watch the spread":

Watchthespread

Press the "play" icon and you can watch the spread of the story as it goes throughout Google+. It's a very cool way to visualize how the story moves through G+.

Now, there is a caveat here. The post must be shared PUBLICLY in order for it to be included in the Ripples visualization.

This makes sense in order to protect where people have shared a post with only a smaller circle. But what this does mean is that if you want to try it yourself and see a Ripples view, you need to share an item out and include "Public" in the sharing:

Gplussharepublic

Now here's a second example of an actual post (versus a contrived example) that was shared out widely. In this case it is a post/rant by Felicia Day expressing irritation about sites that don't use RSS. Note a couple of interesting aspects of the visualization:

  • There's a big circle where Wil Wheaton shared it out and then obviously had it re-shared by many.
  • In the timeline, look at the gap where Susan Beebe then created another bubble of sharing of the post.

Again, watching the spread is rather fun on this post:

Feliciadayrsspost

Now, to view the Ripples on any post on Google+, you simple go to the "down arrow" in the upper right corner of any post to get the "options" menu, and there at the bottom will be "View Ripples":

GoogleViewRipples

Incidentally, that post from Chris Brogan also has an interesting sharing pattern:

ChrisBroganRipples

It may be some time before we understand the full value of this Ripples mechanism, but already I can see that it can be useful in helping understand how messages flow. And certainly as Google+ starts to expand out into business usage, I could see charts like these being very useful for PR/communications staff or firms to be able to measure and show the sharing that a particular piece of content gets.

What do you think? Have you tried out the Ripples yet? Do you see value in them?

P.S. Naturally you might want to discuss this post on Google+ since it is about that service...


UPDATE #1, Oct 27th: Since I included all these well-shared posts as images, I thought I would also show you that Ripples starts working as soon as your post is shared once on Google+. Here is the Ripple for this blog post after I put the link in Google+. As you can see, it has so far been shared exactly once:

TinyRipple

Now, of course, if any of you reading this post share my post inside Google+, then the Google+ activity page should update to show the other shares.


UPDATE #2, Oct 28th: I meant to point out in the commentary on "watch the spread" that this was very similar to the playback feature in Google Wave. I didn't... but TechCrunch did.


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


Is Skype Soon To Release New APIs? Skype Renames Public API And Extends "Plugged into Skype" Partner Program

Pluggedintoskype
Today brings two changes from Skype to their developer programs. First, in an effort to bring some clarity to their existing application programming interfaces (APIs), they have renamed the "Skype Public API" to be called the "Skype Desktop API." As noted in a Skype blog post:
In Aug 2004, we made the Skype Desktop API available to encourage third-party innovation and integration with Skype. The Skype Desktop API allows Partners to access Skype functionality through the Skype desktop client via a text-based command protocol. The intent is not to duplicate Skype functionality but to complement the Skype desktop client with additional features and/or capabilities (e.g., call recording).

This is the API that pretty much all developers have had to use until recently where you application interacts directly with a Skype client. This also means that you have to have a Skype client running to use the API, which has been an additional annoyance for many developers. Developers have long desired an ability to connect directly into the Skype cloud without needing to run a client. Many of us had hoped that "SkypeKit" would be that client-less connection... but it, too, requires a client.

UPDATE: Multiple friends pointed out to me that SkypeKit is a bit more nuanced than this. SkypeKit does NOT require a "full" Skype client, i.e. a full working version of the Skype program. It does, however, require a "runtime" component to be running on a local system. It is that runtime (for Linux, MacOS X, Windows) that then makes the connection out to the Skype cloud. While this may not be a "client", per se, it does still require Skype code running alongside your application. Many of us would like to see "web APIs" from Skype that let you connect in to Skype's cloud without any kind of additional required Skype software. It is those kind of APIs to which I am referring in the paragraph below.

We know, though, from conversations at conferences and events that Skype has been working on developing new APIs... and perhaps this renaming is a precursor to the release of those new APIs. We can only hope... as they have been a l..o..n..g.. time in coming.

The other bit of news was that Skype is now promoting the use of the "plugged into Skype" logo for products using the newly-renamed Desktop API. Previously this program was promoted for SkypeKit products when SkypeKit emerged from beta back in June 2011 . Again from the post:

Plugged into Skype lets Skype users know that the application is built by a partner to work on Skype but was not built by Skype.

There is naturally a page in Skype's developer site (login required) all about how you can use the logo, original image files, etc., etc.

All of this is good to see as Skype, like everyone, is trying to woo developers to build apps on their platform (and add them to Skype's new "App Directory"). Making their program clearer can only help. (And hey, this is only their, what? ... 6th attempt at a developer program? Eventually they may figure it out.)

Meanwhile... is this renaming setting the stage for the release of some new client-less APIs? Let's hope so...


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


Running The 2011 Harpoon Brewery Octoberfest 5K…

Harpoonoctoberfestrace2011
It was, quite honestly, the hardest 5K race I've yet run.

Even with the promise of beer and bratwurst at the end, the Harpoon Brewery Octoberfest Race on October 9, 2011, was still a very tough race.

Why? One simple reason....

The first mile was pretty much entirely UPHILL!

Not "up and down hills".... not "uphill with breaks now and then"... no, it was just solidly a hill that went on and on at a pretty good angle the whole way. This picture doesn't really show it, but that's part of the big hill:

Octoberfestrun

The hill was really the worst part. You ran up the hill for about a mile, then went off into a development where you went down and then back up ... and then you followed the same road back.

So the good news was that you went back down that same hill you climbed! The other good news is that at least you started climbing the hill!

Two other points you might gather from that photo:

  • There were a LOT of runners! A record-breaking 1,124 runners, in fact! The biggest race I've yet run in, personally.

  • It was in the middle of the day with the sun beating down on us. I usually run in the early morning, and even most of the races I've run have started at no later than 9am, so this was a switch. Thankfully it was Vermont in October so it didn't get too hot.

As I mentioned in my previous note, registration for the race did, in fact, get you two beers and a bratwurst... right on your race bib!

Octoberfestraceticket

The race results are now posted on CoolRunning.com and a "find" on my name would show you that I finished #574 out of 1124. I was 66th out of the 95 runners among men ages 40-49 with a net time of 33:18 and a pace of 9:15/mile.

Not my fastest 5K ever, but given the course I'll take it!

Naturally I had to indulge in the bratwurst and at least one of the two free beers:

Octoberfest afterward

As you can tell, I did NOT go the extra bit to run in any kind of Germanic costume... but there were certainly lots of others running in costume, including the group of men that were in the image I used in my last post:

Rosemaryswenches

I was actually amazed by some of the costumes... which can't have been much fun to run in!

And yes, as you might expect for an Octoberfest gathering (or at least an American version of one) there was indeed the requisite "oompah" band:

IPhoto

All in all it was a great race on a great day for a great cause ... and followed up by great food and great beer!

Now I'm looking forward to next year - at least then I'll know the course!

P.S. For my runner friends, here was the course as measured/shown by the Nike+ app on my iPhone... the race was actually a bit over a 5K... really more like 3.5 miles:

Octoberfestcourse