Speaking of Standards

Today SIPit coordinator Robert Sparks announced to several mailing lists that registration is open for SIPit 29, to be held October 24-28, 2011, in Monte Carlo, Monaco. The event has its own website at:

http://www.etsi.org/plugtests/SIPIT29/

and the “About” page gives a bit more detail.

I’ve written about SIPit events before – and we as a company have found them immensely valuable. They are a great place to bring your latest SIP software and hardware and test it against a wide range of other SIP implementations. Basically it’s an inexpensive way to get a week’s use of a better interoperability test lab than you will probably ever be able to build on your own.

The SIPit events also are great for our industry in that they help vendors make their equipment work better together… and the more we have of that the sooner we’ll be able to move beyond the PSTN and get the full value of rich communication possible in a pure IP communications environment.

I do hope many of you will consider going to SIPit 29!

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.

In just 13 days, the 81st meeting of the Internet Engineering Task Force (IETF) will kick off up in the beautiful world of Quebec City in Canada. It will be the usual jam-packed week of meetings on the very wide range of topics covered by the IETF.

Of particular interest to those of us in the real-time communications area will be the ongoing discussions of the RTCWEB initiative that is looking at how to bring real-time communications directly into web browsers.

There is still time to register to attend IETF 81 if you have not already done so.

Voxeo’s head of standards, Dan Burnett, will be attending on our behalf. Please contact him if you would like to meet up with him at the event. You can expect to find him in most of the various SIP and RAI events. (Sadly, my schedule does not permit me (Dan York) to attend this event… I’m looking forward to getting back to one of these IETF meetings soon!)

How will IPv6 impact telecommunications? Out at eComm 2011 two weeks ago I gave a talk titled “How IPv6 Will Kill Telecom – And What We Need To Do About It” and while the video won’t be online for some time, my slides are available. Granted, the particular style of presenting I use means that the slides themselves may not be as valuable without the narration… but you may find the links and issues raised to be useful:

P.S. I have had a couple of people ask if I would be open to presenting a variation of this presentation for their company or conference… and my answer is that yes, I’m usually very open to giving presentations if my schedule allows. Webinars/webcasts are easy to line up… and delivering the presentation in person may certainly be an option. Please just contact me and we can figure out what makes sense.

We are very pleased to see today that the W3C has published CCXML (Call Control XML) as a formal “Recommendation“. Within the W3C standards process, this is the the highest level that a standard can attain and is the result of a great amount of work by a great number of people over many years. To celebrate, we have :

• issued a news release celebrating the milestone and discussing Voxeo’s involvement and our use of CCXML within our products; and
• created a CCXML Resource page where you can find links to CCXML-related tutorials, white papers, source code and more.

As the news release mentions, Voxeo’s CTO RJ Auburn has been involved with CCXML since the early days and is the chair of the CCXML working group within the W3C. Voxeo’s Dan Burnett is now the chair of the overall Voice Browser Working Group under which CCXML and VoiceXML fall. Voxeo Prophecy was the first commercial implementation of CCXML, was the first (and remains the only) engine to support 100% of the CCXML specification and pass the entire W3C test suite for CCXML, and has been licensed out by other companies looking to include CCXML inside their products and services.

We are delighted to see this formal step in the W3C standards process and look forward to seeing even more applications being built out there that use the power of CCXML!

If you’re looking for a humorous way to start off your Tuesday morning, here’s a video created using XtraNormal that someone shared in the IPv6 Enthusiasts group on LinkedIn:

Of course… you may only find this humorous if you are a network geek… (as I am).

The big news out of Google this week was their support of XMPP-Jingle as the “primary signaling” protocol for Google Talk calls to and from Google, iGoogle and Orkut. From the announcement by Peter Thatcher (my emphasis added):

We are pleased to announce that we have launched support for Jingle XEP-166 and XEP-167 for Google Talk calls to and from Gmail, iGoogle, and Orkut. We have also added the same level of support to libjingle (http://code.google.com/p/libjingle), which is used by many native clients. From this point on, it will be our primary signalling protocol, and the old protocol will only remain for backwards compatibility.

and further down:

But the future is Jingle, and the old protocol will eventually go away.

This is obviously a huge endorsement for XMPP – and the XMPP Standards Foundation (XSF) naturally had a post up on the topic.

Now, this is not a “surprising” move because Google has been very involved in the development of Jingle and, as noted by the XSF, Google’s original Google Talk VoIP protocol was a precursor to Jingle. Still, it’s great for Jingle to have the formal endorsement – and perhaps more importantly, the deployment – of Google. The XSF note also points out how this usage by Google can lead to improved interop and more developers using Jingle.

Of course, the obviously question asked by some out there, including in the Hacker News discussion thread, was: why not use SIP?

The truth is that while SIP is an excellent protocol for so many use cases, there are some situations where it’s not the best… and where in this case XMPP-Jingle is a better choice.

We’ve seen that choice here within Voxeo. While we are a HUGE user of SIP – and have our giant SIP cloud sitting out there hosting applications – when we created our Phono SDK to let people easily build voice and IM clients directly in a web browser, we chose to use XMPP-Jingle for part of the path. You can see that in our Phono architecture post:

Why did we use XMPP? Low latency, firewall-friendly… and also with the necessary IM and presence support. It was a lot easier to implement that inside a browser versus a full-blown SIP stack.

It’s great to see Jingle getting this kind of support from Google … and we’re looking forward to seeing increased Jingle usage out there.

By the way, if you want to learn more about Jingle, check out XEP-0166 and XEP-0167.

Posts by others:

• XMPP Foundation: Google: “The Future is Jingle”
• Hacker News discussion thread on this topic
• Tom Keating: Google Talk Adopts Jingle As Default VoIP Protocol
• Digitizor: Jingle Becomes The Default Protocol For Google Talk’s VoIP

We are very pleased to be the hosts this week for the face-to-face meetings of the W3C’s Voice Browser Working Group (VB) and Multimodal Interaction Working Group (MMI) at Voxeo’s main office in Orlando, Florida.

The MMI Working Group meets Monday and Tuesday. Both groups meet together on Wednesday morning, and then the VB group meets Wednesday afternoon through Friday.

The MMI Working Group will be working on the MMI Architecture Specification and EMMA 1.1. (No web page up yet on EMMA 1.1, but use cases are available as is EMMA 1.0.)

The Voice Browser Working Group will be working on SCXML and VoiceXML 3. Given that Voxeo’s Dan Burnett is the Co-Chair of the Voice Browser Working Group and lead editor on the VoiceXML 3 specification, we’re glad to serve as the host for one of the group’s face-to-face meetings.

We welcome all the W3C working group participants to Orlando and do hope they enjoy both our new office and also the surrounding area!