Dan York

October 31, 2018, was a special day for me. Not because it was Halloween, but because after 10 years a small little document I co-authored about the "P-Charge-Info" header for SIP-based Voice-over-IP (VoIP) was published as informational RFC 8496. You can see it at either:

• https://datatracker.ietf.org/doc/rfc8496/
• https://tools.ietf.org/html/rfc8496

Ultimately, all this document does is register the Session Initiation Protocol (SIP) Header Field of "P-Charge-Info" within the "SIP Parameters" registry maintained by IANA at:

• https://www.iana.org/assignments/sip-parameters/sip-parameters.xhtml#sip-parameters-2

But the story of getting that registration to happen is a long one!

In the beginning...

The short version is this. Back in around 2007 or so, I was working for Voxeo and we were using the "P-Charge-Info" header in our large SIP-based application server to pass along billing information. Essentially, when someone made a call on our system, we wanted to pass a billing identifier that was often different from the source phone number (i.e. "CallerID"). This quote from RFC 8496 was pretty much Voxeo's use case:

As another example, a hosted telephony provider or hosted voice application provider may have a large SIP network with customers distributed over a very large geographic area using local market PSTN numbers but with only a very few actual PSTN interconnection points.

The customers may all have local phone numbers yet outgoing calls are actually routed across a SIP network and out specific PSTN gateways or across specific SIP connections to other SIP service providers. The hosted provider may want to pass a billing identifier to its SIP service providers either for the purpose of simplicity in billing or to obtain better rates from the SIP service providers.

While we at Voxeo were already using P-Charge-Info extensively, we wanted to use the P-Charge-Info header with more SIP service providers, and needed some form of documentation for how to use the header. We also were concerned about the profileration of more P-headers and wanted to register "P-Charge-Info" with IANA so that more people might find and use that header rather than inventing their own. (We were happy with P-Charge-Info and didn't want to have to support more SIP headers related to charging identifiers.)

So I began the process of submitting an Internet Draft way back in February 2008 documenting P-Charge-Info and requesting its addition to the IANA registry.

Almost immediately Tolga Asveren, then at Sonus Networks, contacted me to let me know they were using P-Charge-Info in the SIP equipment they were selling. He had some great suggestions, supplied some additional text, and was interested in working on the document with me. So I published a -01 draft 3 days after the first draft, and Tolga and I began our 10-year journey through the process of getting this document published.

Square pegs in round holes - slamming ISDN info into a SIP header

Along the way, others approached us from traditional PSTN telecom companies indicating that they were interested in using P-Charge-Info as a way of passing the "ISUP Charge Number" that was part of ISDN signaling. Though it was not something that either Tolga or I worked directly with, we were okay adding this in, and so two new parameters got added:

• Numbering Plan Indicator (NPI)
• Nature of Address (NOA)

... along with a substantial amount of new text.

A 2011 version of the document can show what this was all about.

Lost in limbo

Meanwhile, the document had gotten caught up in the need to wait while RFC 3427 was replaced by RFC 5727, which defined the whole SIP Header Field registration process.

And then I wound up leaving Voxeo to join the Internet Society (my current employer). And so my attention was no longer focused on VoIP and so this draft was truly a "back burner" kind of thing that I just worked on in random moments.

And unfortunately, it turned out that slamming legacy PSTN signalling into a SIP header caused a whole number of challenges, both with getting agreement - and also with some of the internal IETF processes. It turned out that to do this registration, we were going to have to do some other registrations - and more.

I also published a version that changed some of the parameters values in a way that was not backwards-compatible, which caused some friction.

By 2015, both Tolga and I were ready to ... just... let... it... die...

Returning from the dead - and returning to the SIP roots

And then in early 2017, Henning Schulzrinne and Richard Shockey contacted me to let us know that the US FCC was interested in the status of P-Charge-Info. The FCC had some billing issues between carriers where the carriers were in some cases already using P-Charge-Info, but the carriers really wanted an actual RFC versus an expired draft. There was also some potential interest in having the header around as one of many different tools in the FCC's efforts to combat robo-calling / spam phone calls.

So Tolga and I worked with Henning and the IETF area directors to come up with a plan to resuscitate the document. In doing so, we stripped out all the legacy PSTN signaling. Specifically we removed the NPI and NOA parameters, and all the mentions of the ISUP Charge Number.

We returned it to the simplicity of the original document way back in 2008.

The original goal had been to simply document existing usage of the P-Charge-Info header, as it was being used by various SIP providers and vendors. We returned it to that root.

Success!

After a number of further drafts, an expert review by Adam Roach, and more feedback from Area Director Ben Campbell, the draft finally entered the RFC Editor queue by way of the Independent Series Editor (ISE). Many thanks are due to Ben to sponsoring the draft. He, Jean Mahoney, and Adam were all critical in helping get it across the finish line. Thanks, too, to Henning and Richard who provided the spark for us to revive the document.

It would not have happened, either, if Tolga had not taken the lead over the past year in making edits, answering all the questions from people, proposing solutions and continually asking how to move the draft forward. I may have been the one editing the XML and submitting the new draft versions, but he was the one driving the text revisions.

It's great to see the document finally published as Informational RFC 8496. Looking back on the journey, there were:

• 16 revisions of draft-york-sipping-p-charge-info (2008-2012)
• 6 revisions of draft-york-dispatch-p-charge-info (2012-2015)
• 9 revisions of draft-york-p-charge-info (2017-2018)

Now, granted, some of those were a simple "update to keep the document from being 'expired'", but still it was all a great amount of work.

I learned a HUGE amount along the way. When the journey began in 2008, I didn't really understand much about IETF processes. Now I do - and now understand how we could have done this quite differently along the way.

Thanks to everyone who provided feedback and support over the years.

P-Charge-Info is finally registered in that IANA registry! :-)