Disruptive Telephony

Have you ever been curious about the process of creating a Request For Comments (RFC) document within the Internet Engineering Task Force (IETF)?  These are the standards like, oh, “HTTP”, that power the Internet. Have you been interested in understanding how they work?

If so, someone I know, Russ White, recently completed a 7-part article series about the entire process over on the Packet Pushers Network site. Russ has nicely summarized the series on his site at:

https://rule11.tech/the-rfc-process/

He does a nice job providing an overview of the long process of starting with an idea, creating an “Internet draft”, working it through the IETF process, and then hopefully getting it published.

There are many more details, of course, but Russ lays out the high-level aspects and mentions some of the parts of the process which are harder to understand for someone new to the IETF.

If you are interested in the RFC process, I would encourage you to give Russ’ series of articles a read.

Using Markdown instead of XML

I do have one area of disagreement with Russ. He advocates for using XML for writing Internet drafts, whereas I used to write drafts in XML but have moved over the years to instead using Markdown. If you are writing simple text documents, I believe Markdown is a simpler and easier way to work.

Back in 2019, I gave at tutorial session at the IETF meeting in Prague about “Writing Internet Drafts in Markdown”. The materials are at:

• Slides
• Video 
• Github repository

[One important note - this tutorial session was given FIVE YEARS AGO and the state of Markdown tools is always evolving. I would monitor https://authors.ietf.org/drafting-in-markdown to see about new tools and ways to work with Markdown.]

The video of the tutorial session is actually a great comparison of the two ways of creating Internet drafts. In the first half, my friend Matt Miller explains how to create I-Ds using XML tools, and then around the 32-minute mark I explain how to create drafts in Markdown.

Either way - XML or Markdown - hopefully Russ’ series helps explain a bit more about the whole process of writing a RFC.

 

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! :-)

Last month the first Request For Comments (RFC) was published where I was one of the co-authors. Ironically, this RFC 7649 had nothing to do with SIP, VoIP, telecom, IPv6, DNSSEC, security... or any of the other open Internet standards I've been working on in recent years!

In fact, it's not a "standard" at all but rather an "informational" document.

This document collects together a series of best practices for how someone can fill the role of the "jabber scribe" at IETF meetings, such as the IETF 94 meeting about to happen in Yokohama, Japan, starting this weekend. (Which I will not be attending due to scheduling challenges.) You can read RFC 7659 at:

http://tools.ietf.org/html/rfc7649

As the abstract states:

During IETF meetings, individual volunteers often help sessions run more smoothly by relaying information back and forth between the physical meeting room and an associated textual chatroom. Such volunteers are commonly called "Jabber scribes". This document summarizes experience with the Jabber scribe role and provides some suggestions for fulfilling the role at IETF meetings.

The document came about because over the years that I've been involved with the Internet Engineering Task Force (IETF) I've come to both value the critical role the "jabber scribe" can play - and I've also tried to do the best I can to perform that role when I'm in working group sessions at IETF meetings. I typically volunteer as a jabber scribe in any of the sessions I'm in and try to make the experience as good as possible for remote participants.

Largely my interest is because I spent many IETF meetings as a remote participant and I knew how poor that experience can be.

A few years ago after one of the IETF meetings, I made a comment to a couple of people that we ought to write down some of the suggestions and best practices so that people could easily get some ideas for how they could help out in the role. If they were new to the idea... or even if they had been around but were interested in doing the role better.

I kept track of some ideas ... and a small group of us kept occasionally bouncing ideas around... but none of us had the cycles to write the actual document.

Then last year at, I think, the Toronto IETF meeting in July, Peter St. Andre and I were talking about it again - and this time we actually got it off the ground! More precisely, Peter kicked it off and then he and I went through several rounds of revisions and comments.

Given that Peter's authored 35+ RFCs and countless Internet-Drafts (I-Ds), he knows the IETF process inside and out and so was able to guide the document through the publishing process, including having it move through the "independent submission" stream of RFC documents. I've written a number of Internet-Drafts over the years, but none have yet progressed to an RFC. I learned a great bit from Peter through the process and look forward to using that knowledge in the future.

I greatly appreciate Peter's leadership on this - and I hope that this document will be helpful to many folks out there who are helping involve more people remotely in the IETF's standards process.

Given the timezone difference with Japan, I'm not sure how many of the IETF 94 working group sessions I'll actually be able to attend remotely... but if I do, I'll be hoping that whomever is acting as the Jabber scribe will help include those of us who are remote.

Meanwhile, it is kind of fun to have my name on an RFC, even if it's an Informational one. I look forward to being able to play even more of a role in the IETF standards process in the years ahead...

"What is a minimum set of specifications that a vendor must implement to be able to say that it is SIP-compliant?"

A friend asked me that question and my response was:

It depends.

and even more unfortunately:

I don't know.

It turns out to be a challenging question to answer... and it led me to ask:

• How do we define what "SIP" is for telecommunications in 2014?
• How do we help vendors move their products/services to be based on SIP?
• As we talk about "turning off the PSTN" and "moving all telecom to IP", how can we make it easier for companies to switch to using SIP?

The reality is that being "SIP-compliant" does turn out to depend upon where in the larger SIP interconnection ecosystem the vendor is located.

Is the vendor:

1. a SIP client, in terms of a "hard" phone, a softphone, or other application that is seeking to connect to a SIP server?
2. a SIP server seeking to connect to a SIP "service provider" to have connectivity out to the PSTN and other SIP networks?
3. a SIP service provider seeking to interconnect with other SIP service providers and to the PSTN?
4. a middlebox such as a firewall or session border controller (SBC) seeking to be in the middle of a SIP communication stream?
5. an application that interacts with SIP systems in some way? (ex. call recording, IVR, networking monitoring)

To be "SIP-compliant" really means you need to figure out what amount of "SIP" you need to implement to play your part in the larger picture. Particularly when the SIP "architecture" we describe isn't the pretty little picture we use:

but rather a much more complex reality:

Unfortunately, the "Session Initiation Protocol" (SIP) is no longer just good old RFC 3261 and a few friends. RFC 3261 provided a radical new way to do telecommunications... it was "HTTP for voice"... it was simple, easy and pretty amazing. If you have a moment, go back and read RFC 3261. It's a remarkable document and set of ideas.

However, there were two factors that started to complicate "SIP":

• the "Internet" community kept thinking of new and innovative ways that they could do more with SIP-based telecommunications; and

• the traditional telecom companies/vendors kept wanting to bring across more and more legacy PSTN functionality into the world of SIP, typically without changing that PSTN functionality so that they wouldn't have to change their business models or processes.

This combination set SIP up to slowly become more and more of an accretion of various hacks and kludges designed to either enable SIP to unleash new possibilities and/or to take over key functionality from the PSTN.

But in doing so it became so much harder to define what "SIP" was.

Back around 2008/2009, Jonathan Rosenberg tried with his "Hitchiker's Guide to SIP" that was published as RFC 5411 in February 2009:

http://tools.ietf.org/html/rfc5411

Now consider that this contained about 26 pages worth of documents to be referenced... and this was back in 2009! In the 5 years since, the "Realtime Applications and Infrastructure (RAI)" area of the IETF has been extremely busy and a similar document today would be be MUCH longer.

But does such a long list really help?

Going back to to my list of different roles within the SIP ecosystem, do we need more narrower lists for each role? A SIP client connecting to an IP-PBX may not need to implement all of the same specifications as a SIP service provider connecting to the PSTN.

What is the minimum set of SIP specifications for each role?

The good news is that for the second role I mention, the SIP server to SIP service provider, the SIP Forum has done some outstanding work with their SIPconnect initiative. You can find more info at:

http://www.sipforum.org/sipconnect

You can download the SIPconnect 1.1 technical specification and see the great amount of work they have done. The idea is that ultimately any "SIPconnect-compliant" IP-PBX or other SIP server can connect to any "SIPconnect-compliant" SIP service provider. It should "just work" with a minimum amount of testing. The goal is to allow the more rapid deployment of SIP-based IP-PBXs and making this part of the interconnection puzzle work that much better.

So if you are a vendor of a SIP server, whether you call it an IP-PBX, a call server, or whatever... or you are a SIP service provider seeking to connect to SIP servers at your customers - in either case you have SIPconnect that you can use to be "SIP-compliant".

But what about the other roles?

What if a vendor has multiple products?

What if a service provider or enterprise is just trying to get "SIP" products to work together? What should they specify beyond the vague statement that a product should support "SIP"?

Now, there are other organizations that have attempted to answer this question. The 3GPP has a list of SIP specifications and the GSMA seems to have similar documents. The ITU-T has many recommendations but since they rename everything it's hard to understand what really links back to SIP - and many of the ITU recommendations are only available to members and so you can't easily view them.

Which brings me back to these questions:

• Do we need a new IETF document that aims to update RFC 5411 with a newer list and perhaps "profiles" of what would be needed for different roles?

• Is this something the SIP Forum or some other organization should take on?

• Has someone else already created a concise list/document/specification and I just haven't yet found it?

And perhaps the even larger question:

• Do you believe this is an issue that we collectively should be working on as an industry to help make the deployment of SIP easier?

What do you think? How do we define SIP in 2014? What should we do? I'd love to hear your comments either in response to this post here on this blog or out on social media where this is posted. (Thanks!)

---

An audio commentary on this post is also available:

---

If you found this post interesting or useful, please consider either:

• following me on Twitter;
• adding me to a circle on Google+;
• following me on App.net
• subscribing to my email newsletter; or
• subscribing to the RSS feed

---

Can we create a "secure Caller ID" for IP-based communications, a.k.a. voice-over-IP (VoIP)? And specifically for VoIP based on the Session Initiation Protocol (SIP)? Can we create a way to securely identify the origin of a call that can be used to combat robocalling, phishing and telephony denial-of-service (TDOS) attacks?

That is the challenge to be undertaken by the "Secure Telephone Identity Revisited (STIR)" group meeting tomorrow morning, July 30, 2013, at 9:00 am in Berlin, Germany, as part of the 87th meeting of the Internet Engineering Task Force (IETF). The meeting tomorrow is a "Birds Of a Feather (BOF)", which in IETF language is a meeting to determine whether there is sufficient interest to create a formal "working group" to take on a new body of work within the IETF. The proposed "charter" for this new work begins:

Over the last decade, a growing set of problems have resulted from the lack of security mechanisms for attesting the origins of real-time communications. As with email, the claimed source identity of a SIP request is not verified, and this permits unauthorized use of source identities as part of deceptive and coercive activities, such as robocalling (bulk unsolicited commercial communications), vishing (voicemail hacking, and impersonating banks) and swatting (impersonating callers to emergency services to stimulate unwarranted large scale law enforcement deployments). This working group will define a deployable mechanism that verifies the authorization of the calling party to use a particular telephone number.

The agenda for tomorrow's STIR meeting begins with a presentation by Henning Schulzrinne, now CTO of the US Federal Communications Commission (FCC) but also a long-time IETF participant and one of the co-authors of the original RFC 3261 specification for SIP. Henning will be laying out the problem statement and there will be a discussion of the proposed scope of the IETF work. He'll be followed by presentations of potential solutions by Jon Peterson, Eric Rescorla and Hadriel Kaplan and then a discussion of the proposed charter and the work to be done. Given the intense debate that has occurred on the STIR mailing list over the past weeks I expect tomorrow's session to be one where some points will receive a great amount of passionate debate and discussion. (If you are interested in listening in or participating remotely in tomorrow's STIR meeting, see the information later in this article.)

Revisiting Previous SIP Identity Work

As some background, the Internet Architecture Board (IAB) laid out some of the challenges to "secure origin identification" in IP-based communication last November and took a very high-level look at the overall issue. Next, in preparation for what became this STIR effort, Jon Peterson, Henning Schulzrinne and Hannes Tschofenig authored a draft problem statement and requirements document.

The "Revisited" part of the group name is a nod to the fact that this whole issue of asserting "identity" has been explored within the SIP community in the past. Way back in 2006, RFC 4474 defined what has been called "SIP Identity" and provided a method for cryptographically signing certain SIP headers to identify the origin of a call. Unfortunately, RFC 4474 turned out not to work well with the way SIP was actually deployed and so usage has been virtually non-existent. An effort to update that document, what is called "RFC4474bis", has also been proposed and some of those ideas may be incorporated into the new proposed work for the STIR group.

There have also been other efforts such as the "P-Asserted-Identity (P-A-I)" defined in RFC 3325. The challenge here, though is that theoretically P-A-I is supposed to be limited to usage within a trusted network, although in practice it may be seen by other networks. There have also been several efforts to define or document identifiers for billing purposes (including my own P-Charge-Info) although these efforts are trying to solve a slightly different problem.

The point here really is that the STIR effort is drawing upon a rich body of "SIP identity" work that dates all the way back to some early drafts in 2002. Much thought has been given to this issue and many of the people involved with STIR have also been involved with earlier efforts and understand well some of the challenges faced by that past work.

An Important Difference

One important difference between STIR and earlier "SIP identity" efforts is that initially the STIR effort is only focused on telephone numbers. The draft charter explicitly states this:

As its first work item, the working group will specify a SIP header-based authorization mechanism to verify the originator of a SIP session is authorized to use the claimed source telephone number, where the session is established with SIP end to end. This is called an in-band mechanism. The mechanism will use a canonical telephone number representation specified by the working group, including any mappings that might be needed between the SIP header fields and the canonical telephone number representation.

and later:

Expansion of the authorization mechanism to identities using the user@domain form deferred since the main focus of the working group is to develop a solution for telephone numbers.

Previous "identity" work was also undertaken to include a "SIP URI" or "SIP address" and while the ultimate STIR mechanism (or a variant thereof) might also work for SIP URIs, the focus in this initial work is all around securing the origin identification of telephone numbers.

This initial focus makes a great amount of sense given that so much of the SIP traffic today is a result of telecom service providers moving their regular calls to telephone numbers off of the legacy PSTN networks and over to IP networks where they use SIP. Additionally, a great amount of the "problem" traffic seen in VoIP today can be created by attackers who use simple VoIP software to generate their calls to regular telephone numbers.

Remotely Participating In Tomorrow's STIR BOF

If you are interested in participating in the meeting (or at least listening in) on Tuesday, July 30, the meeting will go from 9:00 - 11:30 local time in Berlin, Germany. Berlin is in Central European Summer Time (CEST) which is UTC+2 (and 3:00 am US EDT / midnight US PDT for my friends back in the USA).

You can hear the audio stream at:

• http://ietf87streaming.dnsalias.net/ietf/ietf874.m3u

You can also join the Jabber chat room at:

• xmpp:[email protected]

The slides and other meeting materials can be found at (and note that materials may not be uploaded until shortly before the session and so you may need to refresh your browser):

• http://datatracker.ietf.org/meeting/87/materials.html#stir

Alternatively you can use the "MeetEcho" conferencing system that integrates the audio, the slides and the Jabber chat room at:

• http://www.meetecho.com/ietf87/stir

More information about participately remotely can be found on the IETF 87 Remote Participation page.

To get the most out of the meeting, you'll also want to read these three Internet Drafts that will be part of the solutions being discussed:

• draft-peterson-secure-origin-ps
• draft-rescorla-stir-fallback
• draft-kaplan-stir-cider

.... and be prepared for what should be a LIVELY discussion!

If you are unable to participate remotely, the session will be recorded and you will be able to listen to the archived audio stream, view the Jabber chat logs and also playback the MeetEcho recording.

Getting More Involved

Beyond listening to tomorrow's BOF session, the best way to get involved - either to actively participate or to at least monitor the effort - is to join the STIR mailing list at:

https://www.ietf.org/mailman/listinfo/stir

The list is open to anyone to join. There are no membership or corporate requirements or fees - anyone with an email address may participate.

WARNING! - As can be seen in the list archive, there is currently a large volume of discussion and it will probably continue for some time. If you do join the mailing list you may want to consider setting up rules to sort the STIR email into a folder - or just prepare for the volume to be added to your inbox.

The other way to be involved is to monitor and read the documents that are created for the STIR effort. Newer documents are being created with "stir" in the document name and so they can be easily found at:

http://datatracker.ietf.org/doc/search/?name=stir&activedrafts=on

Other documents that are useful to understand this effort are linked to earlier in this article and can also be found in the text of the proposed STIR charter. After tomorrow's STIR BOF session there will be more information about how the effort will proceed within the IETF. The meeting tomorrow should result, I expect, in the recommendation to go ahead with formally creating a working group and undertaking this work, but we'll see what outcome occurs.

Can a method of secure origin identification for SIP-based VoIP calls be created? Given that basically all telecom traffic is in the process of moving to be based on IP, the need for a secure origin identifier is very clearly here - and many of us do believe we can develop a system that will work in today's environment.

What do you think? Are you ready to join in and help?

---

Update: Added the additional charter text about "Expansion of the authorization mechanism to identities..."

---

If you found this post interesting or useful, please consider either:

• following me on Twitter;
• adding me to a circle on Google+;
• following me on App.net
• subscribing to my email newsletter; or
• subscribing to the RSS feed

---

Want to learn more about the Opus codec and why it is so important? As I mentioned at the end of my last post about why Opus matters, there will be a special presentation about Opus as part of the IETF 87 Technical Plenary happening in about 2 hours starting at around 17:45-18:00 in Berlin, Germany (Central European Summer Time, UTC+2, 6 hours off of US Eastern time).

There are three options for watching and participating live:

• using a WebRTC-capable browser (latest editions of Chrome and Firefox) and connecting to: http://www.meetecho.com/ietf87/tech_plenary
• listening to the audio stream at for either Potsdam 1 or Potsdam 3 (the plenary is in the combined room and I don't know which stream will be used)
• watching a video live stream at: https://new.livestream.com/internetsociety/ietf87techplenary

The technical plenary begins at 17:40 but there are some other reports before the Opus section. The agenda can be found online and includes:

1. IAB Chair Report
2. IRTF Chair Report
3. RSE and RSOC Chair Report
4. Technical Topic: Opus Codec

a. Introduction
b. Overview of Opus
c. Testing
d. History of Opus in the IETF
e. Opus Deployment Panel
f. Future Work

5. Open Mic

I suspect that the Opus session will begin closer to 18:00 local time, but you can tune in around 17:40 to see the start of the session.

It should be quite an interesting session!

---

If you found this post interesting or useful, please consider either:

• following me on Twitter;
• adding me to a circle on Google+;
• following me on App.net
• subscribing to my email newsletter; or
• subscribing to the RSS feed

---

What makes the Opus codec so interesting? Why is there such a buzz about Opus right now? If you are not in telecom or doing anything with audio, why should you even remotely care about Opus?

In a word...

Innovation!

And because Opus has the potential to let us communicate with each other across the Internet with a richer and more natural sound. You will be able to hear people or music or presenters with much more clarity and more like you are right there with them.

Opus can help build a better user experience across the Internet.

You see, the reality is that today "real-time communication" using voice and video is increasingly being based on top of the Internet Protocol (IP), whether that communication is happening across the actual Internet or whether it is happening within private networks. If you've used Skype, Google+ Hangouts, any voice-over-IP (VoIP) softphones, any of the new WebRTC apps or any of the mobile smartphone apps that do voice or video, you've already been using IP-based real-time communication.

Dropping The Shackles Of The Legacy PSTN

Part of the beauty of the move to IP is that we no longer have to worry about the constraints imposed upon telecom by the legacy Public Switched Telephone Network (PSTN). Chief among those constraints is the requirement to use only part of the sound frequencies we can hear. You all know the "sound" of the telephone - and you hear it in any movie or TV show when someone is using the phone. It's that certain "sound" that we are all used to... that's what the "phone" sounds like.

In technical terms, we call this "narrowband" audio and it has a frequency range of only 300-3400 Hz.

There are historical reasons for this limitation in telecom, but moving to IP-based communications removes those limits. With VoIP we can use what is called "wideband" audio to have a full rich sound to our voice or video call.

Have you had a really good Skype connection with someone where it sounded like they were almost right there in the room with you?

That is wideband audio.

The Codec Problem

Now, for voice or video over IP to work, you need to use something called a "codec" to translate the sound of your voice to digital bits and carry them across the network (and to do the opposite for whomever you are speaking with). There are MANY audio codecs out there and they come in all sorts of flavors and with all different kinds of capabilities. The problem has been that there hasn't been a codec that:

1. is optimized for interactive Internet applications;
2. is published by a recognized standards organization; and
3. can be widely implemented and easily distributed at little or no cost.

In particular that last point about the cost of licensing, especially for wideband codecs, often caused developers to shy away from giving us the rich voice quality that we can now have with IP. Or, in the case of companies like Skype or Google, they went out and bought companies who created wideband codecs so that they could use those codecs in their products. (See my story from 2010 about Google buying GIPS.)

Now there are free codecs out there that developers can use. For narrowband, there has been the ubiquitous G.711 which provides an IP version of "PSTN audio". There have been many others, including notably Speex.

But the struggle has been that there hasn't been a widely accepted "G.711 for wideband" equivalent that developers can just bake into their products and start using. Instead there have been a number of different, incompatible codecs used in different products.

Enter Opus...

So to address these points, back in 2010, engineers within the IETF got together and formed the CODEC Working Group to come up with a codec that could meet these requirements and become the ubiquitous wideband codec used across the Internet. Skype was involved early on through contributing their SILK codec. The folks at Xiph.org contributed their CELT codec. People from many other companies got involved and there were huge technical discussions on the mailing lists and at IETF meetings.

And it worked... the Opus codec was standardized in RFC 6716 in September 2012.

You can read all about the codec at:

http://www.opus-codec.org/

The key points are at the beginning:

Opus is a totally open, royalty-free, highly versatile audio codec. Opus is unmatched for interactive speech and music transmission over the Internet, but is also intended for storage and streaming applications.

Open, highly-versatile... and royalty-free.

At that site there is some great information, including:

• examples of Opus compared to other codecs
• a comparison of Opus to other audio codecs with a variety of charts and graphics
• a presentation by Jean-Marc Valin that dives way down into the technical details
• documentation and sample libraries

There is also a FAQ and many other great pieces of information.

So Why Does Opus Matter?

Opus matters because it lets developers focus on creating a high quality user experience and not having to worry about codec incompatibilities and licensing issues.

Opus matters because it lets developers easily create applications with high quality audio. They can just start using available libraries and communicating with other applications and devices using a common wideband codec.

Opus matters because it can work in very low-bandwidth environments enabling real-time communications across Internet connections that might not previously have supported such communications. As we start to get more Internet connectivity out to the 5 billion people not yet on the Internet, the ability to work over different kinds of connections is critical.

Opus matters because it can help foster innovation in applications and the user experience. Opus is the default audio codec for WebRTC, and so all the zillion new WebRTC-based apps and startups are already beginning with a far superior audio experience than we've had before.

Opus matters because it will enable even more ways that we can connect with family members or friends and have the experience of being "right there". It can help musicians collaborate better across the Internet. It can help podcasters and journalists deliver higher quality interviews across the Internet. It can, in the best conditions, give us that rich audio experience we get when we are right with someone - even though we may be thousands of miles away.

Opus can help us deliver on the potential of the Internet to create more powerful user experiences and to help us better communicate.

THAT is why Opus matters.

Learn More At Monday's IETF 87 Technical Plenary

To understand more about the current status of Opus, who is using it and where it is going, the IETF 87 Technical Plenary on this coming Monday evening in Berlin, Germany, will have a special segment focused on Opus that will include a number of people involved with the Opus work. The agenda for the session can be found at:

http://trac.tools.ietf.org/group/iab/trac/wiki/IETF-87

It is happening from 17:40-19:40 Berlin time, which is Central European Summer Time, which is currently UTC+2 and 6 hours ahead of where I live in US Eastern time. If you can't be there in person, there are several remote options:

• using a WebRTC-capable browser (latest editions of Chrome and Firefox) and connecting to: http://www.meetecho.com/ietf87/tech_plenary
• listening to the audio stream at for either Potsdam 1 or Potsdam 3 (the plenary is in the combined room and I don't know which stream will be used)
• watching a video live stream at: http://new.livestream.com/internetsociety (Look for the "Technical Plenary" event)

If you are unable to watch the meeting in real time it will be archived for later viewing.

The first option above to listen to the session using the Opus codec (and WebRTC!) is a very cool one. The panel also includes people who have actually implemented Opus including people from Google and also Emil Ivov from the Jitsi softphone. Their insight into what they did will be great to hear.

What's Next?

So if Opus is so great, how do you get it?

Well, if you are using any of the WebRTC apps popping up all across the Internet, you are already using Opus. As I noted above, the Jitsi softphone supports Opus. In an interesting bit of synchronicity, I noticed that Michael Graves wrote today about the Blink softphone now supporting Opus. More and more communications apps are starting to implement Opus.

If you are a developer of communications apps or services (or a product manager), you can look at how to incorporate Opus into your application or service. There is documentation and software available to help with the process, and many people are out there who can help.

If you are a user of IP-based communications apps or services, ask the company or vendor behind those services when they will support Opus. See if you can get it on their radar as something to implement.

And regardless of what you do with audio, let people know that this new way of communicating exists - help spread the word about Opus - let people know that audio across the Internet can be even better than it has been to date.

As you can tell, I'm excited about the potential - and very much looking forward to seeing what happens as Opus gets more widely deployed.

What do you think? If you are a telecom developer, or a vendor of such services, have you implemented Opus already? Are you thinking about it? (and if not, why not?)

---

An audio commentary on this post is available at:

---

If you found this post interesting or useful, please consider either:

• following me on Twitter;
• adding me to a circle on Google+;
• following me on App.net
• subscribing to my email newsletter; or
• subscribing to the RSS feed

---

Seeking to understand the basics of WebRTC and why there is so much interest in it? There is a new July 2013 issue of the IETF Journal out this week that includes an article I wrote titled "WebRTC: Moving Real-Time Communication into the Web Browser" that looks at WebRTC from a high-level user perspective.

My aim with this IETF Journal article links was to summarize some of the links on my my WebRTC/RTCWEB page and is admittedly similar in style to my 2012 post, "How WebRTC Will Fundamentally Disrupt Telecom (And Change The Internet)", although this newer article focuses on the work happening within the IETF and provides links to get more involved.

On that note, the RTCWEB working group within the IETF will be meeting next week in Berlin (twice, actually) and has an agenda for IETF87 focused primarily on security questions and looking at the "data channel" aspect of WebRTC/RTCWEB. It should, as always, be an interesting session to listen in to.

If you can't get to Berlin, there are audio streams you can listen to remotely and a Jabber chat room where you can raise questions. Links to both can be found on the top of the agenda page. Do keep in mind that the times listed are local to Berlin, Germany.

---

If you found this post interesting or useful, please consider either:

• following me on Twitter;
• adding me to a circle on Google+;
• following me on App.net
• subscribing to my email newsletter; or
• subscribing to the RSS feed

---

In about 15 minutes, at 5:30pm US Eastern At around 6:00pm US EDT, Henning Schulzrinne, CTO of the US Federal Communications Commission (FCC) will be speaking on "The End of Plain Old Telephone System (POTS): Transitioning the PSTN to IP" at the technical plenary of the 86th IETF meeting happening this week in Orlando, Florida.  You can listen or watch here:

• Audio stream – either Caribbean 3 or Caribbean 4
• Jabber chat: [email protected]
• Meetecho conferencing  (webinar)

Henning's slides are also available for download.

It should be quite an interesting session!

---

If you found this post interesting or useful, please consider either:

• following me on Twitter;
• adding me to a circle on Google+;
• following me on App.net
• subscribing to my email newsletter; or
• subscribing to the RSS feed

---

Sadly, the Big "C", the current unwelcome guest in our family, has claimed another activity that I enjoy. Next week is the 85th meeting of the Internet Engineering Task Force (IETF). Some 1,200+ engineers will gather in Atlanta, Georgia, to discuss/debate/argue/evolve the open standards that make up the Internet. Things like TCP, HTTP, DNS, SIP, IPv6... all those protocols and their many, many offspring.

For people who enjoy the process that creates these standards - and who enjoy the people that make up the IETF - these three-times-yearly face-to-face meetings are amazing places to be. One of the many aspects I enjoy of my work with the Internet Society is that I get to go to the IETF meetings and be part of all that is going on.

Unfortunately, I won't be in Atlanta.

As I've mentioned in the past and written about publicly, my wife is in the second year of treatment for breast cancer. Every three weeks she goes in for an infusion of a drug called Herceptin, which is an antibody that goes after the HER2 protein. She has the treatment on a Monday and then is usually extremely fatigued for the next few days. Generally by Wednesday afternoon or Thursday she's feeling a bit better, but still fatigued. Unfortunately it seems that she's perhaps experiencing more of a "cumulative fatigue," as the recent treatments seem to have had more of an effect - it seems like they are getting harder instead of easier. As a spouse, it's rather painful to watch what these treatments do to her. We can only hope that these are in fact helping fight her cancer.[1]

Next week happens to line up with one of those treatment weeks. I was away for a couple days during the last treatment week and while we have truly incredible friends and family around to help (and they have been helping), the reality is that they can't be there all the time. And so with me away my wife is single-parenting two very active children while feeling like she is moving through molasses.

So I need to be here. The good news is that we only have a few more of these treatments and she'll be free of them by mid-January. Hopefully after that our lives can start to return to a bit more of a normal routine, albeit our "new normal" of a post-chemo-and-still-taking-Tamoxifen world.

The other good news is that the IETF provides multiple ways for people to participate remotely in the meetings. With thousands of engineers all around the globe participating in IETF activities, I'm obviously not the only person who can't attend a given meeting face-to-face. Some people can't travel for family or work reasons... some can't for financial reasons... some can't because they can't get visas to visit the country where the meeting is taking place. Many folks need to participate remotely.

The great aspect for me is that Atlanta is in the same time zone as I am so I won't need to be up in the middle of the night to participate. I can just work "regular" hours and be listening to the audio streams and participating in the jabber chat rooms.

No, it's not as good as being there. You miss out on all the hallway conversations, side meetings, meals, etc., and you can't be there at the microphones to make your points in your own voice. But it is at least possible to participate.

To all the folks I know who will be there in Atlanta, I hope you have a great and productive event! I'll look forward to seeing you all at IETF 86 in March... meanwhile, I'll see you all online during IETF 85. :-)

[1] And yes, sometime I need to write a rant in my series of cancer columns about the fact that the current research regarding Herceptin has so far only shown that "52 weeks" of treatment is effective. It might, in fact, be equally effective in a much shorter timeframe... but the studies have apparently not yet been done to show that.

---

If you found this post interesting or useful, please consider either:

• following me on Twitter;
• adding me to a circle on Google+;
• subscribing to my email newsletter; or
• subscribing to the RSS feed

---