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…

---

If you found this post interesting or helpful, please consider either subscribing via RSS, becoming a fan on Facebook, or following us on Twitter.

---

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 found this post interesting or helpful, please consider either subscribing via RSS, becoming a fan on Facebook, or following us on Twitter.

---