Speaking of Standards

Would you like to understand what the “RTCWEB/WebRTC” initiative is all about? And how it will enable real-time communications from within web browsers without the use of additional plugins or extensions? (like those in Flash, Quicktime, etc.)

A great place to start would be this Internet-Draft at:

http://tools.ietf.org/html/draft-ietf-rtcweb-overview

As the draft URL indicates, the document truly is an “overview” of the effort:

This document gives an overview and context of a protocol suite intended for use with real-time applications that can be deployed in browsers – “real time communication on the Web”.

It intends to serve as a starting and coordination point to make sure all the parts that are needed to achieve this goal are findable, and that the parts that belong in the Internet protocol suite are fully specified and on the right publication track.

The latest version, released today, includes a reference to the WebRTC specification released yesterday by the W3C.

Definitely worth a read for anyone interested in learning more about this very important industry effort.

Last week on July 12th, the W3C’s Web Real-Time Communications Working Group (“WebRTC” – one half of the overall “RTCWEB Initiative”) held a conference call to help advance the work of the group.

Group leader Harald Alvestrand posted a summary of the call to the public webrtc mailing list. A set of minutes was later sent to the list and an IRC log is also available. The main focus right now is on getting full clarity of the requirements and beginning to define the API.

There will also be a face-to-face meeting on Saturday, July 23rd, in Quebec City, Canada. Registration is open and a good number of folks are already planning to attend. The date was chosen because IETF 81 starts July 24th there in Queubec City and many of the W3C WebRTC participants will also be joining in the RTCWEB working group meeting of the IETF. (Confused, yet?)

More discussion of all of this can be found on the public-webrtc mailing list. Great discussion currently going on… the time to join is really now if you want to help shape how this communication occurs between browsers.

Just in time for the submission deadline for IETF 81, Voxeo’s Dan Burnett was able to get in what will hopefully be the last draft of the Media Resource Control Protocol (MRCP), version 2, a.k.a. “MRCPv2″. The new document (revision 25!) is available at:

http://tools.ietf.org/html/draft-ietf-speechsc-mrcpv2

If you aren’t familiar with MRCP, I explained a bit about the problem it is trying to solve back in March when the “Last Call” was issued for comments.

Somewhat predictably, there were comments after the “last call” and so with this revision 25 Dan B has incorporated many of those comments. You can see the diff of what has changed at:

http://tools.ietf.org/rfcdiff?difftype=–hwdiff&url2=draft-ietf-speechsc-mrcpv2-25.txt

Coming in at a whopping 226 pages, this is a significant document. Here’s hoping for Dan B’s sake that this is in fact the final draft!

The IETF this week released an important new draft titled “Design Considerations for Session Initiation Protocol (SIP) Overload Control” that is available at:

http://tools.ietf.org/html/draft-ietf-soc-overload-design

The importance here is that it is a fact of life that SIP-based communication servers can get “overloaded” with messages and not be able to respond to all incoming SIP messages. A SIP server could be overloaded by situations such as:

• too many users wanting to make simultaneous calls (think of the extreme case of a crisis situation)
• a failure of upstream connectivity that limits the capacity of the SIP server
• some other program on the server itself that consumes so much CPU and other resources that the SIP application can’t operate efficiently
• some SIP endpoint(s) that are spewing bogus messages at the server.
• an attacker executing a Denial-of-Service attack

Regardless of the mechanism, SIP servers need to be able to gracefully handle an overload.

The IETF has in fact spun up a Working Group – SIP Overload Control (SOC) – focused on this exact problem and chartered to come up with mechanisms to cope with SIP overload

This Internet-Draft on overload design considerations is one of the documents of this group and is well worth a read, as it explores the various mechanisms that can be used to combat overload.

Incidentally, if you’d like to join in the SOC discussions, or even just monitor what is being discussed, the working group operates a public mailing list at:

https://www.ietf.org/mailman/listinfo/sip-overload

Overload is definitely a potential issue within SIP networks and it’s good to see this group working on the issue.

One of the interesting aspects of the Session Initiation Protocol (SIP) is that is uses the “offer/answer” model to negotiate how a session is to be established… and to also update that session while it is in progress. A basic example would be the exchange of Session Description Protocol (SDP) information during an initial SIP INVITE to determine what audio codecs to use.

As SIP uses the offer/answer model in a number of ways, some folks very helpfully put together this Internet Draft:

http://tools.ietf.org/html/draft-ietf-sipping-sip-offeranswer

The abstract is:

The Session Initiation Protocol (SIP) utilizes the offer/answer model to establish and update multimedia sessions using the Session Description Protocol (SDP). The description of the offer/answer model in SIP is dispersed across multiple RFCs. This document summarizes all the current usages of the offer/answer model in SIP communication. Also, this document tries to incorporate the results of the discussions on the controversial issues to avoid repeating the same discussions later.

If you are seeking to understand how SIP works down at a protocol layer, this document is a useful guide to an important part of SIP.

Image credit: charlesonflickr

Back in September, I wrote about the creation of the Call Control UUI Service for SIP (CUSS) working group within the IETF. Recently, I had a chance to sit down with Alan Johnston, the lead author of the primary document within the CUSS working group, to talk about what CUSS is all about. I posted the video to my Emerging Tech Talk podcast and you can now listen to Alan explain it all (without actually cussing, I might add):

With World IPv6 Day fast approaching on June 8, 2011, an Internet-Draft you may find helpful is the aptly titled:

World IPv6 Day Call To Arms

As the abstract states:

The Internet Society (ISOC) has declared that June 8th 2011 will be World IPv6 Day, on which some major organisations are going to make their content available over IPv6. With the likes of Google and Facebook providing IPv6 access to their production services and domains, it is very likely we will see more IPv6 traffic flowing across the Internet than has ever been seen before. With this in mind, it seems timely to issue a call to arms for systems and network administrators to review their organisation’s IPv6 capabilities in order to mitigate common causes of IPv6 connectivity problems in advance of the day. The increased traffic on World IPv6 Day should also create an excellent opportunity to observe the behaviour and performance of IPv6; it is thus very desirable to have appropriate measurement tools in place in advance. We discuss some appropriate tools from the network and application perspective.

A paragraph in the Introduction outlines the goal of the document:

The purpose of this document is two-fold. One is to discuss common IPv6 connectivity issues that are likely to arise on June 8th, with a focus on dual-stack networking (which is likely to be how the vast majority of sites take part). Most of the issues discussed in this text are those that would affect an end site or enterprise network running IPv6, but may be applicable elsewhere. Highlighting the issues should help raise awareness of those problems and possible mitigations. The other purpose is to encourage organisations to think about how they might get useful instrumentation in place to observe what happens in and to/from their networks on the day, both from the network and application perspective. Such measurement tools are likely to be useful in the longer term, so once deployed they could be left in place beyond June 8th.

The document then succinctly lays out connectivity issues that users may face on World IPv6 Day and strategies for dealing with those issues.

All in all a useful document and one that is worth checking out if you are planning to participate in the World IPv6 Day activity.

The Real-Time Communications in WEB-browser (RTCWEB) Working Group within the IETF will be holding an “interim meeting” on:

Date: Wednesday, June 8, 2011
Time: 16:30-20:30 CEST
10:30-14:30 US Eastern time
7.30-11.30 US Pacific time

To discuss plans related to advancing the work outlined in the group’s charter. I’ve mentioned the “RTCWEB” initiative in the past and definitely believe it is both valuable and necessary. Although that same day is World IPv6 Day and I expect to be engaged in IPv6 promotion activities, I do plan to dial in to this interim meeting to listen and participate.

If you’d like to join in, the best bet is to subscribe to the IETF rtcweb mailing list as the agenda and attendance information will be circulated on that list.

For those of you following the ongoing “RTCWEB” work to bring about standards for real-time communications from within web browsers, there are now two new public mailing lists that you can join – and are where all the RTCWEB activity is now intended to happen.

On the IETF side, as part of the new charter for the RTCWEB work, there is now a mailing list at:

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

You can subscribe and also view the archive from that page.

On the W3C side, a working group is still forming there, but the mailing list is now up for subscription at:

http://lists.w3.org/Archives/Public/public-webrtc/

The W3C list was literally created today, so there has not yet been any activity on that list.

The work of the RTCWEB initiative is now moving into the standards bodies… and so if you want to monitor or participate in the work, you’ll need to join those mailing lists.

I’ve mentioned the “RTCWEB” initiative in the past and in particular the BOF session the group was having at IETF 80 this week in Prague. That session has now been held and Christer Holmberg nicely distributed some notes for those of us who couldn’t attend.

The end result seems to be that Harald Alvestrand has now distributed a revised charter for the IETF work which again sets out this overall goal:

There are a number of proprietary implementations that provide direct interactive rich communication using audio, video, collaboration, games, etc. between two peers’ web-browsers. These are not interoperable, as they require non-standard extensions or plugins to work. There is a desire to standardize the basis for such communication so that interoperable communication can be established between any compatible browsers. The goal is to enable innovation on top of a set of basic components. One core component is to enable real-time media like audio and video, a second is to enable data transfer directly between clients.

The charter is worth a read … and if you are interested in getting more involved, the best way is to join the rtc-web mailing list. It’s definitely a critical initiative in my mind… and I’m looking forward to seeing where it goes.