Speaking of Standards

As a followup to earlier posts, I thought I should mention that notes from the IETF’s P2P Infrastructure Workshop on May 28th are now available for download:

• Spencer Dawkins’ notes and Jason Livingood’s correction
  
• Alissa Cooper’s more detailed notes

• Updated slides, including those presented at the session. Comcast also made their slides available separately.

There is much discussion continuing on the “p2pi” mailing list (see the discussion archive) which is open to anyone interested to join. Plans are underway for BOF sessions at the upcoming IETF 72 meeting in Dublin. If you’re interested, definitely do join the list!

Technorati Tags:
ietf, p2p, comcast, bittorrent, internet, networking, peertopeer, standards

“Why do you write so much about P2P SIP? Who’s really going to use it? Why do you care? Isn’t it really just a lame attempt to create an open standards version of Skype?”

As you might imagine, I’ve heard those questions more than a few times. And yet still I keep writing about it. Why? Part of the answer lies in my post back in December… today the world of SIP is all really “client/server” but the future might be quite different. Today you have SIP user agents that register and connect to SIP servers (which might be SIP proxies, SIP registrars or other types of servers). In fact, our own Prophecy product is a powerful SIP application server. Our Evolution developer portal is a massive SIP-application-server-in-the-cloud (more here) that connects to and from SIP clients.

But now imagine a SIP deployment without servers.

Imagine that you could simply distribute a series of SIP phones and have them all rapidly interconnect to each other and start communicating. Think of how fast you could potentially deploy a small office. In this time of US presidential campaigns, I think of the “advance teams” that are dropped into some office space in some city to organize an area. Imagine if they could be given a bunch of phones which just self-organized into a working communication environment? Plug the phones into a network switch and have them sort out extensions, PSTN gateways, all of that. There are all sorts of similar situations. Teams of consultants or auditors. Emergency environments. Short-term branch offices. Outside of the rapid deployment, there are just general uses in small businesses that don’t want to pay for servers. You could even see it being used in a home environment. Today this kind of thing can be done with “teleworker” phones hooked back to a central IP-PBX or hosted service (I know because I helped launch one back in 2003), but what if it could be even easier?

This is the promise of P2P SIP. Take a bunch of SIP endpoints and they form their own P2P “cloud” (or “overlay network” in P2P lingo). They discover resources like PSTN gateways or application servers. If a phone dies, the P2P cloud routes around it and continues. Communication happens.

Now the reality is not quite there today. There is a great amount of work being done within the IETF on this subject through the P2PSIP Working Group. There are P2PSIP implementations (mostly open source and a few commercial). There is a great amount of academic research going on (one example here). It is all still early days, though.

And on one level, that is what is so exciting. We are re-imagining what a network could be. We are pushing the power and intelligence truly out to the very edge of the network.

We are creating clouds.

Local clouds. Self-organizing clouds. Network “clouds” that connect to other clouds. It’s a different mindset… a different paradigm… thinking of networks not in terms of servers with their clients but in terms of nodes able to communicate with other nodes.

Will it work on a large scale? We’ll see… there’s a whole whack of security issues… privacy issues… scalability issues… but people are looking at those issues. Skype has certainly shown that a P2P telephony environment can be created and can be quite successful. (Although it should be noted that purists might not consider Skype a pure P2P network because they do have enrollment servers that deal with authentication, etc.) Other P2P networks for file sharing have shown the potential is there to build massively scalable networks. The building blocks are all around us.

So what’s the Voxeo angle, eh? Why do I care about it?

Two answers, really. First, there is the basic reality that just because you are creating a new way of connecting a telephony system it doesn’t remove the need for voice application services. You still want to run voice applications. You still need IVR systems. You still need ways to mashup voice with web services. You still need to connect to the PSTN. Some of those services may be able to live within the actual P2P cloud. Some of them will need to be in external servers or services. Obviously that’s what we do and so my interest is in how our software and services might play in this evolving space.

Second, it’s all about clouds. While there is a huge buzz these days about “cloud computing” and “virtualization“, this is what we’ve been doing here at Voxeo since our founding back in 1999! You can go right now to our Evolution developer portal, create your free account and start building voice applications that run in our massively distributed computing cloud. Behind the scenes, there’s a massively-scalable, geographically-distributed, open-standards-based, redundant (and, incidentally, patented) network architecture that virtualizes your voice and IVR applications. You have no idea what server your voice apps are running on and you don’t care. Need more ports… need more CPU cycles… the cloud adjusts for all of that. It’s all transparent to you.

Our “cloud” is then connected out into other “clouds”. You can connect to our cloud from the PSTN, SIP or Skype and then go back out to the PSTN or SIP clouds. We’re part of the massive interconnect currently being built online.

So as there is the potential to create local P2P “clouds”, my interest on multiple levels is pretty basic - how do we connect those small local clouds to our larger cloud and from there to the rest of the interconnected voice and data networks? I want to look at how our services can enable the proliferation of P2P SIP clouds.

Sure, large numbers of “production” deployments of P2P SIP are probably 3-5 years out… maybe even longer (but maybe not). At the current time there’s not a whole lot I can really do except engage in the ongoing conversations about P2P SIP and try to see what where it’s going. But that’s what I and my colleagues in our Office of the CTO do. We’re the guys up in the crow’s nest looking out and scanning the horizon for what’s coming next. Companies that expect to be around have to keep doing that. So that’s what I do. And that’s why I write about P2P SIP and why I’ll keep writing about it.

It’s all about the clouds… and how we connect them all together…

Technorati Tags:
p2p, p2psip, sip, ietf, clouds, cloudcomputing, virtualization, ivr virtualization, peer to peer, skype, voxeo, voip, voice

As I wrote about previously, the IETF is hosting a “P2P Infrastructure Workshop” next week on May 28th on the MIT campus near Boston. There have been some updates in the past week:

• The workshop agenda has been published.

• The list of submitted papers is now available.

• Copies of the submitted papers are available for download as individual files or as a ZIP file containing all papers. (Note that this link does not work with all browsers. On my Mac it worked in Safari but not in Firefox 3.)

Reading through the agenda, it sounds like it will be a great session. P2P is really the next great area of network development, in my opinion, and making sure that the environment is such that we can do it well is key to seeing innovation and growth in that space. Anything like this workshop that can help set the stage for P2P developments is definitely to be encouraged.

P.S. I had hoped to attend myself, but given that I’ve got a moving truck showing up about 36 hours after this workshop ends (I’m moving from VT to NH) I somehow don’t see me getting down there.

Technorati Tags:
ietf, p2p, networking, internet, workshops

Do “intrastate” versus “interstate” billing rates make any sense whatsoever in the world of SIP where geography ceases to be relevant?

There is a fundamental disconnect today between the legacy world of PSTN billing practices and this new world of SIP-based interconnection that we are all building. The Internet ignores geography. We can connect to any random points in the cloud, regardless of where they are physically located.

But until the day when we have truly built the IP-interconnect and can all be bypassing the PSTN, we do have to deal with the PSTN… and all the legacy tariff/billing infrastructure that goes with it. How do you mesh the two worlds?

Consider this case within the US:

• A company in Massachusetts with phone number 617-555-1111 calls a customer
  also in Massachusetts with phone number 617-555-2222.

• The Caller ID presented to the receiving party is 617-555-1111.

• The company calling is billed the intrastate rate because the call appears
  to have originated and terminated within Massachusetts. For this
  example, and purely picking a number out of the air, let’s say the call at intrastate rates would have cost $5.

• However, the company in MA was actually using a hosted telephony service
  and while the call appears to have originated from Massachusetts based
  on the CallerID presented to the user (and transmitted as “6175551111@sipgw.carrier.com” in the SIP From
  and/or P-Asserted-Identity headers), the number actually entered the PSTN
  from a data center in New York with the number 212-555-1111.

• Had the calling company presented their billing identifier as 212-555-1111, they
  would have been billed the interstate rate for calling and for this
  example let say that the call would have only cost $3. (And yes, for those of you outside the US, this is true, calls within a state are more expensive than calls between states!)

• Naturally, the calling company wants to present its Caller ID to the
  end user as its own number of 617-555-1111 but it is contracting with the
  SIP telephony hosting provider in part to get cheaper rates. The hosting provider would
  naturally like to be billed at the interstate rate versus the intrastate rate
  when the calls enter the PSTN from their data centers.

There is the disconnect. PSTN billing is still tied to the identity of the originating number as seen through the carrier’s billing systems. Yet with SIP, the caller identity can be different from the identity of the PSTN interconnect point. (And yes, “Caller ID” can be spoofed on the PSTN but there are still underlying billing identifiers in the PSTN signaling.) As long as we continue to have tariffs in North America that have different rates based on geography, we’ll continue to have this problem.

A few years back, the folks over at Sonus Networks came up with an idea to address this disconnect - pass a custom SIP header called “P-Charge-Info” in the SIP INVITE that sets up the call and include in that header the SIP address to which to charge the call. They added this header to some of their equipment and some carriers started using it. So in the case above, the SIP headers might include headers like these:

From: <sip:617555111@sipgw.carrier.com>
P-Charge-Info: <sip:2125551111@proxy.hostingprovider.com>

To the person receiving the call, nothing has changed. The “Caller ID” that is presented on their phone is the same identity they saw before. But inside the cloud, the billing identity has been changed.

[Do note that there's a double-edged sword here. If the hosting provider and the carrier agree to use P-Charge-Info as the authoritative header for billing purposes, and then in my example above the Massachusetts customer starts making a lot of calls into New York they will wind up being charged the higher intrastate rate based on the P-Charge-Info header. So some analysis of calls needs to be done before agreeing to use this special header.]

Anyway, as one of the largest providers of VoiceXML/CCXML hosting, we are always looking at ways to ensure our customers receive the fairest billing. Late last year after one of our carriers suggested we look at using the P-Charge-Info header, we did so and were quite pleased with the results. Subsequently we have now started using this with multiple carriers.

Being strong proponents of open standards, we noticed that P-Charge-Info was not yet registered on IANA’s list of SIP parameters and so we approach Sonus Networks about going through the RFC 3427 process of registering a custom P-header. They agreed and so Tolga Asveren from Sonus Networks and I submitted an Internet Draft defining the P-Charge-Info header. We received a good bit of feedback/critique and our fourth version (-03) was just posted today.

Why are we going through this registration process, which can be quite lengthy? Several reasons:

• Expanded Usage - We would like to use this with other carriers but until this draft there was no specification for exactly how the header should be used. We would like this to be available as something to point other carriers/service providers to.

• Prevention of Further P-header Proliferation - Right now, if someone is looking for a SIP header to pass billing information, odds are they will look at IANA’s registry to see what headers have been added to SIP. Today the only billing headers are those of the 3GPP defined in RFC 3455 which do differ in intent from what P-Charge-Info does. If they don’t like the RFC 3455 P-headers, they may very well go off and invent their own P-header (anyone can) to deal with passing billing information.

  Our concern is that as we all in the industry continue building this IP interconnect, sooner or later we’re going to want to find ways to exchange billing information and if we have six different headers in production use it’s going to be a real headache. In the ideal world we would have a standard header (not a P-header) for passing billing information and probably we eventually will… but that will take some time to get developed and then deployed. In the meantime, let’s document and register what’s out there now so that people can see the choices they have and not necessarily go right off creating yet another billing information header.

• Prevention of Identity Conflict - It’s very possible that someone going off and creating their own SIP P-header could very well choose to call their header “P-Charge-Info”. One would hope that someone creating a new P-header might use Google to search for the header name they are planning to use (in which case they would discover this existing usage of P-Charge-Info), but someone might not and start using it. It could then happen that some day someone out there would wind up needing to interoperate with two different pieces of equipment that both use a “P-Charge-Info” header, but in different ways. IANA registration is designed to help prevent this.

• It’s The “Right Thing” To Do - If you read section 4.2 of RFC 3427 it states very clearly:
  

  Any P-header
  used outside of a very restricted research or teaching environment
  (such as a student lab on implementing extensions) MUST meet those
  requirements [of section 4.1] and MUST be documented in an RFC and be IANA registered.

  Now obviously no one is enforcing this. There are many P-headers in common usage today that are not documented. No one will slap you down and revoke your right to use SIP if you don’t. But it’s the right thing to do for the reasons outlined above as well as to respect the process defined in RFC 3427.

So where is P-Charge-Info in the RFC 3427 process of IANA registration? Well, Tolga and I now have a fourth revision of our Internet Draft out (it’s the fourth because the first was “-00″) and we would very definitely like comment on the draft. Please do send them in via email (or leave them as comments here). Once the document has gone through more review (perhaps another draft or two) we will then continue the steps in section 4.1 of RFC 3427 and request “expert review”. Ultimately the goal is to have the document published as informational RFC so that it can be registered with IANA.

As I said, comments and feedback are definitely welcome. What do you think of the document? of the problem we are trying to solve?

Technorati Tags:
ietf, sip, standards, voxeo, sonus networks, p-charge-info, voip, telecommunications, telephony, pstn

Have you ever wanted to send information between two applications using SIP that didn’t fit into one of the existing “headers” that are using in the SIP communication exchange? Did you look through the various headers in RFC 3261 (and associated RFCs) and find that none fit exactly what you were seeking to send?

If so, what you can use instead is what is called a “private header” or “P-header” for short.

Before we jump into P-headers, let’s first take a moment to switch to the world of email. With email, there are so-called “experimental headers” that are sent in the SMTP exchange that all start with “X-”. Here are some examples:

X-Priority: 	Normal
X-Mailer: 	Apple Mail (2.753)
X-Authentication-Warning: 	blogs.voxeo.com: apache set sender to wordpress@blogs.voxeo.com using -f
X-Spam: 	exempt
X-Mail-From: 	<wordpress@blogs.voxeo.com>
X-Source-Ip: 	[(unknown)]

These “X-” headers are added by various programs to email messages that are sent and share the common characteristic that they are all informational. They do not indicate any action that has to occur. They are not SMTP commands. Each of these X-headers are purely containers of information that is passed along in the SMTP message. On the receiving end, the application accepting the SMTP connection can look at those X-headers and then potentially decide to take some action on the received message based on the contents of those X-headers. If a receiving application doesn’t no what to do with an X-header it receives, it simply ignores the header. With regard to the “informational” nature of X-headers, the idea is that if an application ignored all X-headers, the email message should still be able to be delivered. X-headers add extra information and capabilities, but don’t block the basic existing SMTP.

These “experimental” headers are now widely used by mail programs, by anti-spam software and basically all sorts of other programs that interact with email. They are a way to pass along extra information about the email message. Companies, vendors and individuals can all define and use their own X-headers to try out new services and offerings. They don’t need to check with anyone. They can just go ahead and create a new header to try it out. (Presumably checking first to see that their new name didn’t conflict with existing X-headers on their network.)

Back in the world of SIP, the IETF defined a process in RFC 3427 for extending SIP that was similar to the experimental headers of email. The fundamental difference was that in SIP instead of beginning with an “X-” the headers begin with a “P-”, as in “P-Asserted-Identity”. Otherwise, they are very similar. P-headers in SIP must, like the X-headers of email, be purely informational. They cannot be used to create new commands and must not interfere/block the regular transmission of SIP messages. They merely pass extra information that the receiving application can choose to do something with (or not).

Here are some examples:

P-Asserted-Identity: "Dan York" <sip:dan@company2.com>
P-Charge-Info: <sip:proxy1@company2.com>
P-Charging-Vector: icid-value=1234bc9876e;
                   icid-generated-at=192.0.6.8;
                   orig-ioi=home1.net
P-Visited-Network-ID: "Visited network number 1"
P-I-Made-This-Up: "Pretty silly, isn't it?"

Here is how a couple of these would look in an actual SIP message:

INVITE sip:1234@company2.com SIP/2.0
Via: SIP/2.0/UDP proxy.company2.com:5060;branch=z9hG5bK21ghi7ab34
Via: SIP/2.0/UDP sip.company1.com:5060;branch=z9hG4bKnashds7
To: sip:1234@company2.com
From: sip:dan@company1.com;tag=451248
Call-ID: 324817637683475998ababcc10
CSeq: 1 INVITE
Contact: sip:dan@company1.com
Max-Forwards: 50
P-Asserted-Identity: "Dan York" <sip:dan@company2.com>
P-Charge-Info: <sip:proxy1@company2.com>

The application receiving this SIP message can then choose to read these headers and potentially perform some action based on the contents of the headers. (If you are developing your application on our platform and using CCXML, we’ve provided instructions for how to access those SIP headers.) For instance, the “P-Asserted-Identity” header is very often used as the “Caller ID” that is displayed on the end user’s phone or other SIP device.

So what should you do if you want to start using a P-header to pass information via SIP between two applications?

First, you should head over to the IANA registry of SIP headers to see if someone has already defined a P-header that might do what you are looking to do. For instance, P-Asserted-Identity has been defined in RFC 3325. The 3GPP has defined several P-headers related to IMS in RFC 3455.

Second, if you don’t see any defined P-headers, you might want to search the IETF database of Internet-Drafts to see if there are any P-headers in a proposal stage that might work for you. The process of registering a P-header with IANA (so that people know about it and to prevent naming conflict) is documented in RFC 3427 and first involves the creation of an Internet-Draft document. For instance, I have an Internet-Draft submitted on the P-Charge-Info header that we are seeking to register with IANA.

Third, while in the IETF database you might also just want to search for the general type of information you are seeking to pass between applications. It may be that there is some work underway in an IETF Working Group that would wind up creating standard headers (versus P-headers) to pass the information you are seeking to pass.

Finally, if you are unable to find any current or in-progress P-headers, you can create your own. Keep in mind that it should start with “P-” and the general convention has been to put a dash between any words in the name and to use initial capitals, as in “P-Asserted-Identity”.

For more information about creating P-headers, please do read RFC 3427.

Technorati Tags:
sip, ietf, standards

It’s hard these days to escape news about peer-to-peer (P2P) applications and the concerns raised by service providers about those P2P apps. With recent FCC hearings about Comcast “delaying” P2P traffic, the topic is getting a great amount of discussion across the blogosphere and in the media in general. To look at the issue from a technical point-of-view and see if there are technical solutions that could help in the area, the IETF recently announced a “workshop on P2P Infrastructure” to be held on May 28th on the campus of MIT in the Boston area.

From a voice perspective, any kind of latency / delay is something to be avoided at all costs. As researchers look at P2P SIP as a future deployment model, getting the infrastructure right is a key factor in the future success of P2P SIP. Now, serious deployments of P2P SIP won’t happen for some time now (probably a few years), but the reality is that it will also take some time for any technical solutions to: 1) work their way through IETF; 2) be incorporated into vendor equipment; and 3) actually be deployed in service provider networks. So now is really a good time to get started.

If you are interested in P2P applications in general and are in the Boston area (or can get there), please do consider attending this workshop. There is a wiki page for the workshop that will be updated as the workshop gets closer and a ‘p2pi’ mailing list that is open to anyone to join.

Here is part of the announcement that explains what the workshop will be about:

The Real-time Applications & Infrastructure (RAI) Area Directors, Jon
Peterson and Cullen Jennings, would like to announce an IETF workshop on
P2P Infrastructure to be held on May 28, 2008 at 50 Vassar St, Room
34-101 on the MIT campus in Cambridge, MA USA.

Several large ISPs have encountered issues with P2P traffic. The
transfer of static, delay-tolerant data between nodes on the Internet is
a well-understood problem, but traditional management of fairness at the
transport level has largely been circumvented by applications designed
to achieve the best end-user transfer rates. This results, at peak
times, in networks running near absolute capacity, and in which all
traffic incurs delays; the applications that bear the brunt of this
additional latency are real-time applications like VoIP and Internet
gaming. This has led to need for further discussion of the proper
approaches to P2P application development, and infrastructure management
in environments where P2P is commonly used. This workshop intends to
discover where additional IETF standards work is needed, or existing
work might be reapplied, to alleviate these difficulties. In particular,
the workshop will draw on the experiences of Comcast and BitTorrent,
representatives of both of whom will present their perspectives on the
problem space.

Example solution discussions might include, but are not limited to:
deployment of application servers or caches to reduce network load; new
rendez-vous mechanisms to optimize P2P network topology; enabling
applications to signal their bandwidth needs (and priority or lack
thereof) to networks; enabling networks to signal bandwidth constraints
to elastic and inelastic applications; and, new approaches to fairness
that are coupled with incentives for applications. Contributions from
subject matter experts in the problem and solution space are
welcome. The primary outcome should be a direction for one or more IETF
efforts exploring the best practices for addressing these challenges.

The organizers would like to stress that this is a technical workshop
exploring engineering issues and practices. The public policy
implications of P2P applications are not in the scope of this workshop.

If you would like more information about how to participate in the workshop, please read the full announcement.

Technorati Tags:
ietf, standards, p2p, peer-to-peer, p2psip, sip, voip, comcast, bittorrent, Internet, networking

If you want to get a sense of what an IETF meeting is all about, I’ve now uploaded a set of photos from the recent IETF 71 meeting in Philadelphia.

If you get the sense that we spent a lot of time sitting in chairs… you would be correct! It’s all about chairs, hallway conversations and, of course, (for those of us with no aversion to speaking publicly) the microphone! (Unless, that is, someone relocates the mic.

IETF meetings also naturally involve a whole lot of email, even while we are there at the meeting. Given that we had a very solid wireless network (even if access points were sometimes on chairs) and we also had a 100 Gbps (yes, you read that correctly - 100 Gigabits per second!) connection to the Internet via Comcast you’ll notice that basically every picture has a very high density of laptops. If there were 1300 people at the meeting, probably 1295 of the attendees had a laptop there with them.

Technorati Tags:
ietf, ietf71, philadelphia, comcast, standards

Want to try out peer-to-peer SIP? (P2PSIP?) One of the areas of work within the IETF right now that intrigues me the most is the whole effort around “peer-to-peer” SIP, a.k.a. “P2PSIP”. The idea is that you could have “SIP without servers”, i.e. a range of SIP endpoints (hard phones, soft phones, etc.) that would learn of each other and communicate with each other using SIP over a P2P network (also referred to as a “P2P overlay” or sometimes just casually as a “P2P cloud”).

In another post at some point, I’ll write more about why P2PSIP is intriguing to me (and for Voxeo), but for the moment I thought I’d post that David Bryan, chair of the IETF’s P2PSIP Working Group, has very nicely put up a page listing existing implementations of P2PSIP technology. There are several open source implementations, as well as a commercial implementation from David’s own company, SIPeerior Technologies (he’s the CEO). All of these are implementations of exists drafts and so they will undoubtedly change as the drafts evolve and morph into RFCs over the next months and years ahead. Still, if you’d like to experiment and get a sense of what people are working on, the implementations are now out there!

P.S. David has also posted the P2PSIP presentations from IETF 71 earlier this month.

Technorati Tags:
sip, p2p, p2psip, sipeerior, ietf, sipdht

It’s been a long and exhausting week… There are so many things I have wanted to write about… the RUCUS BOF… the MEDIACTRL session… the IPv6 experiment in the first plenary… the P2P video presentation in the technical plenary… the SIPPING and SIP sessions… the SPEERMINT and PEPPERMINT sessions… meeting the co-author of a draft I wrote who I had never met… the VERY lively P2PSIP session this morning… my challenges streaming video with hot laptops… cheese steaks and random strangers… the 100 Gbps network that Comcast brought in (yes, you read that correctly!)… so many sessions… so many great conversations… so many great people… so much great work going on… so many great stories to tell…

Alas, those stories will have to wait for late Sunday or Monday (or next week)… right now it’s time for me to head offline for some family time before I head out Sunday afternoon to Orlando for VoiceCon!

Technorati Tags:
ietf, ietf71

How many conferences have you attended where the WiFi network - if there even is one - has been really poor? Or charged you an arm and a leg to use it?

That doesn’t happen at IETF meetings… bandwidth is usually decent and accessible in in all meeting rooms and common areas - at no charge to meeting attendees. Why? Because the IETF brings in its own network!

Indeed, there’s even a document on “Meeting Network Requirements” which spells out how to arrange such a network. Here’s the abstract:

The IETF Meeting Network has become integral to the success of any IETF meeting. Building such a network, which provides service to thousands of heavy users, spread throughout the event venue, with very little time for setup and testing is a dramatic challenge. This document provides a set of requirements, derived from hard won experience, as an aid to anyone involved in designing and deploying future networks.

If only other conferences could have a network like this!

P.S. Here’s a piece in the Philadelphia Business Journal that goes into this: “1,500-strong laptop invasion to hit Marriott for Net task force” (hat tip to Comcast’s IETF71 blog).

Technorati Tags:
ietf, conferences, wifi