Speaking of Standards

The IETF this week released an important new draft titled “Design Considerations for Session Initiation Protocol (SIP) Overload Control” that is available at:

http://tools.ietf.org/html/draft-ietf-soc-overload-design

The importance here is that it is a fact of life that SIP-based communication servers can get “overloaded” with messages and not be able to respond to all incoming SIP messages. A SIP server could be overloaded by situations such as:

• too many users wanting to make simultaneous calls (think of the extreme case of a crisis situation)
• a failure of upstream connectivity that limits the capacity of the SIP server
• some other program on the server itself that consumes so much CPU and other resources that the SIP application can’t operate efficiently
• some SIP endpoint(s) that are spewing bogus messages at the server.
• an attacker executing a Denial-of-Service attack

Regardless of the mechanism, SIP servers need to be able to gracefully handle an overload.

The IETF has in fact spun up a Working Group – SIP Overload Control (SOC) – focused on this exact problem and chartered to come up with mechanisms to cope with SIP overload

This Internet-Draft on overload design considerations is one of the documents of this group and is well worth a read, as it explores the various mechanisms that can be used to combat overload.

Incidentally, if you’d like to join in the SOC discussions, or even just monitor what is being discussed, the working group operates a public mailing list at:

https://www.ietf.org/mailman/listinfo/sip-overload

Overload is definitely a potential issue within SIP networks and it’s good to see this group working on the issue.

The big news out of Google this week was their support of XMPP-Jingle as the “primary signaling” protocol for Google Talk calls to and from Google, iGoogle and Orkut. From the announcement by Peter Thatcher (my emphasis added):

We are pleased to announce that we have launched support for Jingle XEP-166 and XEP-167 for Google Talk calls to and from Gmail, iGoogle, and Orkut. We have also added the same level of support to libjingle (http://code.google.com/p/libjingle), which is used by many native clients. From this point on, it will be our primary signalling protocol, and the old protocol will only remain for backwards compatibility.

and further down:

But the future is Jingle, and the old protocol will eventually go away.

This is obviously a huge endorsement for XMPP – and the XMPP Standards Foundation (XSF) naturally had a post up on the topic.

Now, this is not a “surprising” move because Google has been very involved in the development of Jingle and, as noted by the XSF, Google’s original Google Talk VoIP protocol was a precursor to Jingle. Still, it’s great for Jingle to have the formal endorsement – and perhaps more importantly, the deployment – of Google. The XSF note also points out how this usage by Google can lead to improved interop and more developers using Jingle.

Of course, the obviously question asked by some out there, including in the Hacker News discussion thread, was: why not use SIP?

The truth is that while SIP is an excellent protocol for so many use cases, there are some situations where it’s not the best… and where in this case XMPP-Jingle is a better choice.

We’ve seen that choice here within Voxeo. While we are a HUGE user of SIP – and have our giant SIP cloud sitting out there hosting applications – when we created our Phono SDK to let people easily build voice and IM clients directly in a web browser, we chose to use XMPP-Jingle for part of the path. You can see that in our Phono architecture post:

Why did we use XMPP? Low latency, firewall-friendly… and also with the necessary IM and presence support. It was a lot easier to implement that inside a browser versus a full-blown SIP stack.

It’s great to see Jingle getting this kind of support from Google … and we’re looking forward to seeing increased Jingle usage out there.

By the way, if you want to learn more about Jingle, check out XEP-0166 and XEP-0167.

Posts by others:

• XMPP Foundation: Google: “The Future is Jingle”
• Hacker News discussion thread on this topic
• Tom Keating: Google Talk Adopts Jingle As Default VoIP Protocol
• Digitizor: Jingle Becomes The Default Protocol For Google Talk’s VoIP

Would you like to learn more about IPv6 and how it relates to creating communications applications? Want to understand more about how IPv6 does or does not impact the SIP protocol?

If so, you may be interested in a free 1-hour session I’m giving on Thursday, May 5, 2011. The topic is:

IPv6 and How It Impacts Communication Applications

It’s part of Voxeo’s “Developer Jam Session” series and is targeted at a technical audience. I’ll briefly cover IPv6 basics, talk about how it impacts communication apps, the SIP protocol and then have some demonstrations of SIP-over-IPv6. You can learn more about the session and register on the Jam Session web page.

If you attend live on Thursday you’ll be able to ask questions during the session. If you can’t attend, the session will be recorded for later viewing. (And if you register, we’ll make sure you know as soon as we post the recording.)

Looking for a softphone that lets you easily make VoIP calls over IPv6 using the SIP protocol? I was looking to do this and after trying several of the common SIP softphones I knew of, several people pointed me over to Linphone which turns out to work like a charm! I knew of Linphone from a number of years back, but I mistakenly thought it was Linux-only… nope! It truly is cross-platform with binary versions for Windows and Mac OS X, and source available for Linux distros – plus versions for iPhone, Android and Blackberry.

With really just one configuration change, here is what it looked like to make a SIP call using IPv6 addresses (well, almost what it looked like since I did mask the actual addresses, being as security-paranoid as I am):

In the top address field I simply entered the SIP address using the standard format:

sip:user@ipddress

with the exception that because it is an IPv6 address I enclosed the address in square brackets (per RFC 3986). That’s it. I was off and making my call.

The One Configuration Step (and the caveat)

All I had to do to make this work was go into the settings (which you get by going to the “Windows” menu and choosing “Preferences” on Mac OS X) and checking off the box that says to use IPv6:

After checking that box and pressing “Done”, Linphone changed my identity to show my local IPv6 address and let me start making calls to IPv6 addresses.

The caveat

Now whether this “just works” does depend upon how you are connected via IPv6.

In my case, I use Tunnelbroker.net to have IPv6 in my home office (which I explained previously how to configure for Apple devices and for generic devices). The effect of doing this is that…

I am directly connected to the IPv6 side of the Internet.

So for me, the screen above with the radio button next to “Direct connection to the Internet” works fine. If you are behind a IPv6 NAT or gateway device, you may need to adjust the settings here.

Indeed, when I used Linphone for testing with IPv4, I did need to change the options myself, because for IPv4, my home network is behind a NAT / firewall. In my case I went for the second of the three options and provided my external IP address:

So you may need to adjust these settings in order to have Linphone work with IPv6.

Now, Linphone is a pretty bare-bones SIP client… it doesn’t have all the features and frills of many of the other clients out there… but that’s okay… all I wanted to do was test out the ability to make calls using SIP over IPv6. And for that it worked great!

As a bonus, it does not require you to set up a SIP account and register with a SIP registrar. You can just use it for direct computer-to-computer calling… which again is exactly what I needed in this case.

I’ll be writing more about making SIP calls over IPv6 in the weeks and months ahead… but in the meantime I thought I’d pass along this info.

I’ve tried Jitsi, the rebranded “SIP Communicator”, but it seemed to require me to set up a SIP account before I could make calls… and I don’t have an IPv6-compliant SIP system to which I can register.

In any event, I’m greatly impressed with Linphone… kudos to the team there for making it work so well over IPv6!

P.S. Thanks to some Voxeo colleagues for the recommendation of Linphone and also to someone in the #ipv6 IRC channel on Freenode (mentioned in this post).

Would you like to learn about IPv6 and how it works with VoIP? On this Friday, November 26th, at 12 noon US Eastern time, the VoIP Users Conference crew will gather on their weekly conference call to discuss IPv6 with Olle Johansson. Olle is well known within the Asterisk community and will be discussing his work with Asterisk and IPv6 along with other topics. The proposed agenda right now is:

• IPv6 – how to get it into your network today
• VoIP and IPv6 – why is this a good marriage?
• Experiences from Asterisk 1.8 IPv6 support
• Living in a dual stack world
• Dual stack considered bad for VoIP?
• Implementations out there – a call for help? Which devices used in the VUC community supports IPv6? Any experiences?
• Setting up a VUC IPv6 testbed
• Follow-up call planning – monitoring the IPv6 migration process in the VUC community.

More info about the call is at:

http://www.voipusersconference.org/2010/ip-v6/

Info about how to join the conference call is available on the VUC site, but can be summarized as:

• SIP: sip:200901@login.zipdx.com
• Skype: vuc.me
• PSTN: +1 425-906-3916
• iNum: +883 5100 123 94882

There is also an active IRC backchannel during the call (#vuc on freenode).

If you’re interested in IPv6 it should be a fun and informative call. If you can’t attend, the call will be recorded for later listening.

P.S. And yes, Friday is the day after US Thanksgiving and a holiday for most US companies… but VUC is global and meets every Friday.

This morning I submitted a new version -07 of P-Charge-Info. Not much changed in the draft. Primarily I updated the IPR language to use the language of the IETF Trust as of February 2009 and added a reference pointing to RFC 3968.

The P-Charge-Info draft has been rather delayed on its path to becoming an Informational RFC primarily because just as I was about to request “expert review” per the process in section 4.1 of RFC 3427, the SIP and SIPPING working groups decided to revisit RFC 3427 and restructure how changes are made to SIP in general.

The result has been “RFC 3427bis”, a.k.a. draft-peterson-rai-rfc3427bis and section 4 defines a new lighterweight process for registering SIP headers. (Well, it speaks of a “Designated Expert” process, but my criticism of the existing draft is that it doesn’t easily explain what someone has to do to register a new SIP header.) While this RFC3427bis draft has not been ratified as an RFC, the RAI area is proceeding as if it has been and has already replaced the SIP and SIPPING working groups with SIPCORE and DISPATCH.

At this point I’m done with P-Charge-Info in that I’ve incorporated all comments that people have had and all I am looking to do now is move it through the end of the process to an Informational RFC. I will be contacting the RAI Area Directors shortly to sort out exactly what the next step is to get this moving along. In my ideal world, I’d like to see this published by the end of this calendar year.

I do, though, still welcome comments, so if you have any please feel free to pass them along.

P.S. For info about why I originally wrote this draft, see “P-Charge-Info and incredible disconnect between PSTN billing and the new world of SIP

Otmar Lendl recently posted a thoughtful piece called “What’s wrong with Speermint and Drinks” that digs into the differences between and the challenges of the IETF’s Speermint and Drinks Working Groups. Otmar started out explaining why they are necessary:

First of all, why do we need these WGs at all? The quick answer is that VoIP interconnection based on plain SIP and ENUM did not work out as envisioned by the authors of the respective RFCs. There are a number of reasons for that (see draft-lendl-speermint-background), and I don’t expect that the IETF can do anything to change this.

He then points out the fundamental problem facing these groups and really the “SIP/VoIP space” in general:

Call routing was rather simple in the full mesh world (be it PSTN or RFC3263 SIP), it only needed some directory service to map Public Identities (PI = phone numbers or SIP URIs) to operators. In a lot of cases, these directories are static simple mappings like “route anything starting with +49 to Deutsche Telekom”.

This is no longer sufficient. Any solution to the current world-wide call routing problem needs to cope with arbitrary interconnection graphs, not just the trivial case of full meshes. A directory will not suffice any more: we need a full blown routing algorithm.

I repeat: The current graph of interconnection between carriers has no special properties any more. We have a text-book routing problem to solve.

That is the challenge. The old world of the PSTN was relatively simple. Fewer players in the interconnection game… and because there were so few they could do “full mesh” interconnectivity between the various players.

It’s a different world, today. There are many players in the call routing game and pretty much anyone can enter that game. Otmar’s point is that the current proposed solutions focus more on central registries and other mechanisms traditionally used in the world of the PSTN. He argues that we really need more of a “routing” solution that allows multiple registries and systems – and indeed works like other Internet routing protocols.

For those interested in the underlying SIP plumbing that is being built to better interconnect all of us using SIP out there, Otmar’s post is well worth a read (fair warning that it does dive into details and terminology).

I don’t know that there are any easy answers out there (or it would have been solved already)… but the conversation is ongoing and will continue for quite some time.

If you aren’t thinking about the security of your VoIP systems, you should be, because the tools to attack those systems keep getting better. Over on the Voice of VOIPSA blog, I recently wrote about the release of a new suite of security test tools that make some of the attacks now “point-and-click”.

For a variety of reasons, many of these attacks are against SIP or unencrypted RTP, so they are definitely good to understand.

P.S. Note that VOIPSA (VoIP Security Alliance) does have a lengthy list of VoIP security tools already… this new suite is just one more to be added to the list.

Technorati Tags: sip, sip security, voip, voip security, security, voipsa

Over on ZDNet’s blog “A Developer’s View“, John Carroll had a surprising piece entitled “SIP is the future of telecommunications” that was really quite well-done. I say “surprising” only because I’ve been reading John’s blog at ZDNet for quite some time and can’t recall ever hearing him discuss telephony before.

In his post, he talks about his attendance at ITEXPO last week in L.A., and writes this:

One thing that has already been rolling along for quite some time, but has become extremely apparent given recent developments in the industry, is that Session Initiation Protocol (SIP) isn’t just a protocol that is “popular” in Voice over IP (VOIP) environments. It is, for all intents and purposes, THE VOIP protocol, at least among traditional telecommunications providers. It is the protocol that networks choose when they want to IP-enable their largely SS7 environments (SS7 is the signaling protocol used in the global circuit-switched network used to communicate within and between almost every telecommunications company in existence). SIP plays a central role in the IP Multimedia Subsystem (IMS), a family of protocols which is supposed to define the architecture of next-generation mobile networks capable of streaming various kinds of text, voice and video data to mobile phone subscribers even as they roam between networks.

We agree. Back in 1999 and 2000, we made a decision that was viewed as rather crazy at the time to base our entire infrastructure on SIP. Our Prophecy voice application platform, our Evolution hosted developer portal, our extremely large “cloud” infrastructure… all of it is based on SIP. It was a bit of a gamble at the time, but 8/9 years later it turned out to definitely have been the right move to make then.

John goes on to talk about the power of “SIP trunking” and the many advantages it brings. It’s a good article that I’d recommend reading.

John ends with this teaser:

Tomorrow, I’ll talk about a product I saw at the conference that, at first blush, I wasn’t sure I would find interesting when first invited to speak to the responsible parties. That product just so happens to come from Microsoft…and no, it isn’t Office Communications Server (OCS).

Having attended ITEXPO as well, I know exactly what he’s talking about… and I’ll say only that it has a lot to do with magic blue buttons.

It’s too bad I didn’t realize John was out there at ITEXPO as it would have been nice to meet up. The irony is that I was often in the Speaker/Press Room and odds are that I probably walked right by him or saw him sitting at a table. Anyway, another time…

Meanwhile, I’ll look forward to his post tomorrow to see his take on Microsoft’s outreach there at the show.

Technorati Tags: sip, ietf, voip, standards, voice, telecom