Category: Standards
-
/
Russ White On The Process Around Creating RFCs in the IETF
Continue Reading: Russ White On The Process Around Creating RFCs in the IETFHave 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…
-
/
My First RFC – 7649 On “The Jabber Scribe Role at IETF Meetings”
Continue Reading: My First RFC – 7649 On “The Jabber Scribe Role at IETF Meetings”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:
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…
-
/
Join Live Today at 9:00 CDT – Internet Video Codec BOF at IETF92
Continue Reading: Join Live Today at 9:00 CDT – Internet Video Codec BOF at IETF92Can we create a royalty-free (RF) video codec that can be deployed ubiquitously and become the new open standard for video communication across the Internet?THAT is the fundamental question of the Internet Video Codec (NETVC) Birds-of-a-Feather (BoF) happening at IETF 92 in Dallas today, March 24, 2015, from 9:00-11:30 CDT (UTC-5). You can listen and participate live using the following links:
You also may want to view the presentation that will be used during the session.
The goal of the overall effort is defined as this:
- Development of a video codec that is:
- Optimized for real-time communications over the public Internet
- Competitive with or superior to existing modern codecs
- Viewed as having IPR licensing terms that allow for wide implementation and deployment
- Developed under the IPR rules in BCP 78 (RFC 5378) and BCP 79 (RFCs 3979 and 4879)
- Replicate the success of the CODEC WG in producing the Opus audio codec.
The BOF proposal contains more of a narrative:
The Internet needs a royalty-free (RF) video codec that can become the backbone for universal deployment of video related technologies. Royalty-bearing codecs put constraints on implementors that are…
- Development of a video codec that is:
-
/
Google Finally Kills Off GoogleTalk and XMPP (Jabber) Integration
Continue Reading: Google Finally Kills Off GoogleTalk and XMPP (Jabber) IntegrationGoogleTalk is dead, Jim!
By way of a comment to a post I wrote back in May 2013 about Google seeming to kill off XMPP/Jabber support in Google+ Hangouts (spoiler: They did!), I learned from a friend that the GoogleTalk API was officially deprecated as of February 23, 2015. I confirmed this by finding a Google+ post from Google’s Mayur Kamat.
Now, this is not a surprise. Google has been clear that Hangouts was the replacement and also that Hangouts does not support XMPP:
Still, I’m sad to see the XMPP integration die off. It is just a continuation of the descent of messaging services into walled gardens … a topic I’ve been writing about for many years. UPDATE: Please see the post “No, it’s not the end of XMPP for Google Talk” on the XMPP Standards Foundation site. The XSF notes that XMPP is still used inside of Google and that XMPP federation can still occur with a third-part XMPP client. However, because Google does not support the secure use of XMPP via TLS, many public XMPP servers will not connect to its server. I join the XSF in wishing that Google would embrace secure messaging and better…
-
/
How Do We Define ‘SIP’ For Telecom In 2014?
Continue Reading: How Do We Define ‘SIP’ For Telecom In 2014?“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:
- a SIP client, in terms of a “hard” phone, a softphone, or other application that is seeking to connect to a SIP server?
- a SIP server seeking to connect to a SIP “service provider” to have connectivity out to the PSTN and other SIP networks?
- a SIP service provider seeking to interconnect with other SIP service providers and to the PSTN?
- a middlebox such as a firewall…
-
/
What Devices And Software Support The Opus Audio Codec? Here Is A List
Continue Reading: What Devices And Software Support The Opus Audio Codec? Here Is A ListWhat devices support the Opus audio codec? What softphones? hardphones? call servers? Obviously given that Opus is the “mandatory to implement” audio codec for WebRTC, it will be in many web browsers… but what other I was asked this question by a colleague recently and when I couldn’t easily find a list on the Opus codec web site, I turned to the VUC community inside of Google+ and posted there. The great folks there naturally were a huge help, and quickly came up with this list: UPDATE: No sooner had I hit “Publish” then I discovered that Wikipedia has a list of devices and software supporting the Opus codec. As that list is much longer than this one below, I’d encourage you to look at that list.
- Web browsers supporting WebRTC:
- Google Chrome
- Mozilla Firefox
- Softphones:
- Blink
- Counterpath Bria
- Jitsi
- Linphone
- Mumble
- (Maybe Skype? They talked about it.)
- “Hard” IP phones:
- Mobile applications:
- Acrobits (iOS)
- Counterpath Bria (iOS)
- csipsimple (Android)
- Switches / Call Servers / IP-PBXs:
What other devices or software supports the Opus codec? (Or what other lists are out there listing devices supporting the Opus codec?) Please do let me know either by comments…
- Web browsers supporting WebRTC:
-
/
Reminder – Opus Codec Presentation Streaming LIVE From IETF 87 in 2 Hours
Continue Reading: Reminder – Opus Codec Presentation Streaming LIVE From IETF 87 in 2 HoursWant 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 -
/
Why The Opus Codec Matters – Even If You Don’t Care About Audio
Continue Reading: Why The Opus Codec Matters – Even If You Don’t Care About AudioWhat 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…
-
/
Moving Beyond Telephone Numbers – The Need For A Secure, Ubiquitous Application-Layer Identifier
Continue Reading: Moving Beyond Telephone Numbers – The Need For A Secure, Ubiquitous Application-Layer IdentifierDo “smart” parking meters really need phone numbers? Does every “smart meter” installed by electric utilities need a telephone number? Does every new car with a built-in navigation system need a phone number? Does every Amazon Kindle (and similar e-readers) really need its own phone number?
In the absence of an alternative identifier, the answer seems to be a resounding “yes” to all of the above.
At the recent SIPNOC 2013 event, U.S. Federal Communications Commission CTO Henning Schulzrinne gave a presentation (slides available) about “Transitioning the PSTN to IP” where he made a point about the changes around telephone numbers and their uses (starting on slide 14) and specifically spoke about this use of phone numbers for devices (slide 20). While his perspective is obviously oriented to North America and country code +1, the trends he identifies point to a common problem:
What do we use as an application-layer identifier for Internet-connected devices?
In a subsequent conversation, Henning indicated that one of the area codes seeing the largest amount of requests for new phone numbers is one in Detroit – because of the automakers need to provision new cars with navigation systems such as OnStar that need an…