Speaking of Standards

SIPit 25 starts four weeks from today at the University of New Hampshire’s InterOperability Lab (IOL). What is SIPit? As the UNH-IOL page for the event says:

SIPit’s, or Session Initiation Protocol Interoperability Tests, are weeklong events where people bring their SIP implementations to ensure they work together. SIPIT Events are open to anyone with a working SIP implementation. The goal of the events is to refine both the protocol and its implementations. The SIPIT events are a driving force shaping SIP into a globally interoperable protocol for real time Internet communication services.

Basically, they are a place where vendors can privately test their SIP implementations against each other. Results of the testing are not publicly released – other than an aggregate news release talking about what occurred overall. It’s a place where, as a vendor, you get a great chance to see how well your SIP-based product interoperates with that of other vendors. It’s also a place where vendors will often bring early implementations of new SIP standards to test those against other vendors working on early implementations. All in all, it definitely helps with moving us all along the path toward increasing SIP interconnection.

We’ll have a Voxeo team at this SIPit. We’ve been based on SIP since we started our company back in 1999 and we’re continually looking at ways to increase our performance and support for evolving SIP standards. We value the feedback we gain from these SIPit events and try to attend when we can.

You can attend, too, as there is still space available. The UNH IOL event page has more info and there is an online registration form as well. (Deadline to register, though, is September 4th.)

P.S. And yes, since yours truly lives about two hours west of UNH, I *am* planning to head over and meet our testing team for dinner probably in beautiful Portsmouth, NH… I’m in “marketing” now, so they don’t let me near the test equipment. I mean, in my world, all the tests just work, right? And they have really pretty charts to go with them…

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.