Speaking of Standards

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

---

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.

---

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

---

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

---

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

---

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

---