Disruptive Telephony

Got a great idea for a talk to give to an excellent gathering of SIP/VoIP network operators? Have a new way of handling security? Have a case study you'd like to present for how you solved an operational issue?

The SIP Network Operators Conference (SIPNOC) is an outstanding event happening in Herndon, Virginia, USA, from April 22-25. It brings together network operators working with SIP / VoIP networks for several days of talks, networking (of the human kind) and education. I've gone the past two years, speaking about IPv6, and they are truly excellent conferences. Not too big, not too small... and with an extremely high quality of people both attending and speaking.

If you think you'd like to present, TODAY, January 25, 2013, is the end of the call for presentations for SIPNOC 2013. They are seeking presentations on topics such as (see the CFP for more detail):

• Peering
• SIP Trunking
• Congestion Control
• Applications/content Development
• Interoperability
• Call Routing
• Security
• Monitoring/Troubleshoooting and Operational Issues
• Testing Considerations and Tools
• Availability/Disaster-Recovery
• WebRTC and SIP
• SIP-Network Operations Center Best Practices
• Standardization Issues and Progress
• FoIP/T.38 Deployment
• User-Agent Configuration
• IPv6 Deployment Challenges
• Emergency Services
• Scaling and Capacity Issues
• HD-Voice Deployment Challenges
• Video Interop Issues

They are seeking individual talks, panel sessions, research sessions and BOFs.

Even if you just have an idea for a session, I'd encourage you to submit a proposal so that the SIPNOC 2013 Program Committee will know of your interest and can reach out to you for more details. More info about the process can be found on the CFP page.

If you aren't interested in speaking, but are now intrigued by SIPNOC and would like to be learning from all the excellent sessions, you can go to the SIPNOC 2013 main page and find out information about how to register and attend.

If you work at or for a telecom/network operator who is involved with SIP and VoIP, I highly recommend SIPNOC as a conference you should attend - you'll learn a huge amount and make great connections.

P.S. I have no affiliation with SIPNOC other than being a speaker there in the past. SIPNOC is a production of the SIP Forum, a great group of people focused on advancing the deployment and interoperability of communications products and services based on SIP.

---

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

---

Why are so many people interested in using Google Voice with SIP? Is this a sign that people really want to use SIP-based services for VoIP? Is this all hobbyists or people looking to play around with Google Voice? Or is it people trying to solve real interconnection issues? What are people trying to do with Google Voice and SIP?

All these questions came to my mind today when I dipped into Google Analytics and noticed that for the month to date in November 2012, my old (March 2011) post about Google Voice and SIP addresses continues to receive a large amount of traffic:

Slightly over 3,000 pageviews in the first 13 days of November - and if I go back a bit I see over 71,000 pageviews since January 1, 2012. In fact, it's had about 232K pageviews since I wrote it over 1.5 years ago, and has accounted for almost 25% of all traffic to this site in that time.

And this particular article was just one in a series of articles I wound up writing about Google Voice and SIP as we all collectively tried to figure out what was going on.

Digging into the traffic sources to the page, almost all of it this month comes (somewhat predictably) from search. The search terms, at least the ones we can see (since Google now shows "Not Provided" for all searches done over SSL), show a range of interest in SIP:

And all of this for a service from Google Voice which seemed to be a temporary service and subsequently stopped working... kinda, sorta... and then did work... and then didn't work. (And I just checked... and it doesn't work for me right now.)

I find all this interest fascinating. I hope it's a good sign that people out there do want to see more usage of SIP addresses.

And I do hope that at some point Google will open up the connection again and let us connect in to Google Voice numbers using SIP URIs. It would be a great move.

Meanwhile, I'll continue to be fascinating by all the traffic still coming to those old articles...

---

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

---

Recently at Voip2day + ElastixWorld in Madrid 2012, Olle E Johansson gave a great presentation outlining where we are at with telecom and VoIP in 2012 - and where we need to go! Olle is a long-time, passionate and tireless advocate for the open Internet, IPv6, SIP and standards and interoperability. I've known Olle for years via Asterisk-related issues, via the VUC calls and via work on SIP over IPv6.

This presentation (slides available) really hits a number of key points about where we are at now:

In particular I was struck by his slides 24-28 that strike the same theme I've been writing about across multiple blogs, namely the way we are reversing the "open Internet" trend and retreating back inside walled gardens of messaging:

He goes on to walk through what happened with SIP and how the protocol evolved - and evolved away from interoperability. His conclusion is that we as customers need to take back control, avoid vendor lock-in and demand interoperability.

He also points people over to his "SIP 2012" effort where he is undertaking to compile a list of what really defines "SIP" in 2012, i.e. more than just RFC 3261. (I'll note he's looking for feedback on these ideas.)

All in all an excellent presentation... and yes indeed we all collectively do need to "WAKE UP" and demand better solutions!

---

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

---

At this year's SIP Network Operators Conference (SIPNOC) on June 25-27, 2012 in Reston, VA, I was shooting photos of the various presenters as well as trying to take some shots that captured the general feel of the excellent event. As with shooting any event, I find the actual taking photos to be the insanely easy part... it is the curation of the photos that takes the longest amount of time. Over the past bit, though, I finally was able to reduce the 500+ photos I shot down to a meaningful set and I've now posted the SIPNOC 2012 photos up to Flickr:

A special thanks to Spencer Dawkins who took some shots of me speaking.

I've licensed them all under a simple Creative Commons Attribution license so that they can be used by others. If you're in the photos and want an original, you can download them from Flickr... and you're also welcome to contact me if you have any issues downloading a file.

SIPNOC 2012 was a great event and kudos to the SIP Forum for making the event happen! I'm looking forward to next year's event!

---

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

---

With today's big news in the VoIP / Unified Communications (UC) / telecom space of Avaya's acquisition of Radvision, pretty much all of the coverage has predictably focused on the video angle. While that's certainly important, I have a far bigger question:

What about Radvision's SIP and H.323 stacks?

More specifically -

will Avaya continue to support and promote the strong usage of Radvision stacks by other vendors?

Of all the coverage I've seen so far, only Tom Keating touched on this in his brief post:

They also developed a H.323 stack used in hundreds of VoIP and videoconferencing products before SIP became the dominant VoIP protocol of choice.

Beyond the popular H.323 stack, Radvision's SIP stack has also been used in a good number of products out there - and Radvision also developed stacks for RTP, MGCP and many other VoIP protocols. Just follow the links off of Radvision's developer page at:

http://www.radvision.com/Products/Developer/

to see the wide range of developer solutions they have developed over the years.

For those not familiar with this topic, a "stack" in developer-speak is basically a set of libraries that you can incorporate into your products to enable those products to communicate over a given protocol. So if you want to "SIP-enable" your product, you can license a "stack" from a company like Radvision rather than developing your own stack or using one of the various open source stacks that are out there. Licensing the stack also typically gets you support from the vendor and the ability to request changes/customizations/etc.

Radvision has enabled a good number of companies out there to get into the VoIP world. They have been a supplier of stacks to companies all across the VoIP / UC space.

Now they've been acquired by one of the largest vendors in the VoIP/UC space.

Will Avaya continue to support the widespread usage of Radvision's various stacks by other vendors?

Or will they restrict or reduce the usage? Or increase the costs? If so, what will the other vendor's do?

Can the various vendors using Radvision stacks trust Avaya to continue the developer program? Particularly when they may compete directly against Avaya?

Will there be more attention paid now to other providers of SIP and VoIP stacks?

THAT is the question that I'm most curious about in the midst of this merger...

Other Articles

Some of the pieces worth reading on this topic include:

• Zeus Kerravala on NoJitter: Why Avaya Buying Radvision Makes Sense (Updated: Deal Is Official)
• Henry Dewing's Blog at Forrester: Avaya Acquires Radvision
• Carl Ford on TMCnet: Avaya Buys Radvision for $230 Million
• TechCrunch: RadVision Finally Finds A Home With Telecom Giant Avaya — For $230 Million
• eWeek: Avaya to Buy Radvision, Ramping Competition With Cisco
• TheNextWeb: Done deal: Avaya buys video conferencing tech firm RADVISION for $230m in cash (some useful links)

P.S. Hat tip to Forrester's Henry Dewing, too, for at least recognizing the usage of Radvision's stacks, although he did not ask the question I'm asking here.

---

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

---

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:

• following me on Twitter;
• adding me to a circle on Google+;
• subscribing to my email newsletter; or
• subscribing to the RSS feed

---

Heading to Burning Man this coming week? Would you like to use your mobile phone to connect up with others on the playa in Black Rock City?

If so, check out this video from Chris Pirillo about the work being done by a team of folks to supply local cell phone coverage... the vans with satellite and cell hookups are already enroute... it uses software from OpenBTS and Tropo.com to let burners leave each other voice messages, exchange SMS messages and more. Here's the video:

And here are some blog posts that provide more information:

• The Long and Winding Road to Burning Man
  
  
• Tropo + OpenBTS + Burning man = Awesome
  
  
• Voice Board and Group SMS for Burning Man
  
  
• Papa Legba FAQ (about the deployment at Burning Man and what you need to do to participate)

I'm not personally going to be at Burning Man, but this does sound very cool!

---

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

---

Last week at the eComm conference in San Francisco I spoke about how IPv6 will impact telecommunications and what we as a community should be doing about it. The session was recorded on video and will be posted at some point in the next few months. In the meantime, I have posted my slides on SlideShare - they may not be terribly useful without my narrative... but you may find some of the links of interest:

P.S. If you are interested in me giving a presentation like this to an audience you know of, please feel free to contact me.

---

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

• following me on Twitter;
• subscribing to my email newsletter; or
• subscribing to the RSS feed

---

Will you be out in San Francisco next week for eComm, the "Emerging Communications Conference & Awards"? If so, I'll see you there, as I'm speaking on Wednesday. If not... are you interested in going? I still have a pass or two available as a speaker. (Drop me a note... quickly!)

I've always enjoyed eComm as it truly is a gathering of the thought leaders of the communications space... whether those people are working with VoIP or mobile or unified communications or whatever. It's where the "alpha geeks" of comms go to hang out... to network... to listen and learn as they share with each other what they are working on truly out there on the bleeding edge of communications.

Some people have called eComm the "TED of Telecom" and in many ways that's an apt comparison... quick, focused presentations to a high quality audience.

Check out the schedule and the long list of speakers... some truly great people will be there. I expect to be learning a good bit.

My own talk on Wednesday will be on the IPv6 theme I've been on lately. I titled it "How IPv6 Will Kill Telecom - And What We Need To Do About It". I'll be talking about many of the IPv6 issues I've blogged about or spoken about lately... but bringing that all together into a concise presentation. Should be a good bit of fun.

I'm also teaming up with Andy Abramson and Michael Graves to produce a series of daily audio interviews of speakers for the VoIP Users Conference (VUC). We'll be broadcasting live every morning at 7:45am Pacific. Stay tuned for more info.

eComm 2011 looks to be a great show again and I'm psyched to be heading out there to be part of it. If you're going, see you there!

---

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

• following me on Twitter;
• subscribing to my email newsletter; or
• subscribing to the RSS feed

---

Before writing my story yesterday about Skype killing off Skype For Asterisk, I had reached out to Skype's PR agency to see if there was any statement from Skype. There wasn't at the time, but today they sent over this statement from Jennifer Caukin, a spokeswoman for Skype:

Skype made the decision to retire Skype for Asterisk several months ago, as we have prioritized our focus around implementing the IETF SIP standard in our Skype Connect solution. SIP enjoys the broadest support of any of the available signaling alternatives by business communications equipment vendors, including Digium. By supporting SIP in favor of alternatives, we maximize our resources and continue to reinforce our commitment to delivering Skype on key platforms where we can meet the broadest customer demand.

Being a huge advocate of open standards, I of course applaud Skype's commitment to supporting SIP. However, as I noted two years ago in my detailed review of what was then "Skype For SIP" (and is now "Skype Connect") the fundamental difference between Skype For Asterisk and Skype's SIP offering is this:

Skype For Asterisk is/was two-way - you can make outbound calls TO Skype users.

You can't do that with Skype Connect. You can receive calls from Skype users. You can receive calls to PSTN numbers that come in across the Skype network. You can make outbound calls to PSTN numbers via the Skype network. But you can't make outbound calls to Skype users.

Skype For Asterisk could.

And therein lay much of its power.

Additionally, Skype For Asterisk passed along your Skype presence which could be used for call routing... and also supported Skype chat, too.

Neither of which Skype Connect can do right now.

Skype For Asterisk provided a 2-way, multichannel connection into the Skype cloud in a way that Skype's SIP-based offering simply doesn't at this point in time. (Having said that, of course, SFA is certainly no where near as easy to set up or understand, a point Dave Michels made today.)

However, as Alec Saunders pointed out today, the economics also clearly favor Skype Connect in terms of monthly and per-minute billing versus the low one-time fee of Skype For Asterisk. Tim Panton also indicated that the Skype For Asterisk program had some challenges including the licensing of the product.

While perhaps understandable as a business decision, I know that Skype For Asterisk will be missed by many in the technical community.

Now, let's see what Skype will truly do with their SIP support in the time ahead...

P.S. And while it is of course easy to try to blame someone like Microsoft for this demise, as I noted in my first post, the acquisition deal isn't even remotely done yet...

---

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

• following me on Twitter;
• subscribing to my email newsletter; or
• subscribing to the RSS feed

---