Speaking of Standards

Given the services we provide, one of the IETF working groups that we (Voxeo) are most interested in is the Media Server Control (mediactrl) Working Group (more information here). The charter provides a sense of what it is about:

Real-time multi-media applications often need the services of media processing elements. It is true that modern endpoints are capable of media processing. However, the physics of some media processing applications dictate that it is much more efficient for the media
processing to occur at a centralized location. By media processing, we
mean media mixing, recording and playing media, and interacting with a
user in the audio or video domains. The commercial market calls these
media processing network elements “media servers.”

Some services achieve significant efficiencies when a central node
performs media processing. Because of these efficiencies, media
servers are widely used for conference mixing, multimedia messaging,
content rendering, and speech, voice, key press, and other audio and
video input and output user interface modalities. Given the wide
acceptance of the media server, we need a standard way to control them.

Basically, the intent of the group is to arrive at a protocol suite of “media server control protocols” that standardize communication between “application servers” and “media servers”. One of the initial documents under discussion is the “requirements” document that lists the “requirements” that any proposal for a “media server control protocol” must meet. As stated in the charter, the objective of the document is:

1. A requirements document. This document will identify and enumerate
requirements for a suite of media server control protocols. Given that
one of the common media server clients is a conference application
server, we will consider the application server - media server
requirements developed by the XCON work group. Likewise, we will
consider media server control requirements from other standards
groups, such as 3GPP SA2 and CT1.

In any event, revision 3 of the requirements is out now, draft-ietf-mediactrl-requirements-03.txt, and reflects the input provided both at IETF 70 and in subsequent discussion on the mailing list. I’m personally pleased to see the inclusion of some of the security aspects that I (and others) had suggested ought to be included:

REQ-MCP-11 - The MS control protocol shall include an authentication
component to ensure that only an authorized AS can communicate
with the MS and vice versa.

REQ-MCP-12 - The MS control protocol shall use some form of
transport protection to ensure the confidentiality and integrity
of the data between the AS and MS.

REQ-MCP-13 - The MS control protocol requires mechanisms to protect
the MS resources used by one AS from another AS since the solution
need to support multiple AS controlling one MS.

Anyway, if you have any opinions about the requirements in the document, now is the time to voice them as the document is going into the final stages of approval. We need to nail the requirements as tightly as possible at the front end of the process so that later documents can reflect these requirements. (If you want to submit comments, the authors email addresses are found at the end of the document itself.)

Technorati Tags:
ietf, sip, mediactrl

Have you ever wanted to understand why SIP doesn’t work so well across NAT devices and firewalls? Have you heard of STUN, TURN or ICE but didn’t know what they were or how they worked? Over on my Blue Box podcast site I’ve just uploaded Blue Box Special Edition #22 which explores and explains all these details. In this interview I sat down with Dr. Jonathan Rosenberg, a Cisco fellow and author of a wide range of RFCs and Internet-Drafts related to SIP to talk about SIP and NAT traversal. We explore what the problem is, how ALGs and SBCs attempt to solve the problem and how the IETF has looked to address the issue through first STUN, then TURN and now finally ICE. I think you’ll find it a very educational and informative session.

On a similar note, you may also be interested in Blue Box Special Edition #20 where I sat down with Cullen Jennings to talk about overall security issues with SIP. These two podcasts together give you a solid overview of the current security issues with SIP.

Technorati Tags:
blue box, bluebox, dan york, danyork, ietf, sip, standards, voip security, jonathan rosenberg

One of the more interesting (to me) working groups within the IETF right now is the “P2PSIP” working group which is aiming to develop ways to let SIP clients communicate on a “peer-to-peer” basis, i.e. without any servers. As stated in the working group’s charter:

The Peer-to-Peer (P2P) Session Initiation Protocol working group (P2PSIP WG) is chartered to develop protocols and mechanisms for the
use of the Session Initiation Protocol (SIP) in settings where the
service of establishing and managing sessions is principally handled
by a collection of intelligent endpoints, rather than centralized
servers as in SIP as currently deployed. A number of cases where such
an architecture is desirable have been documented.

Peer-to-peer is intriguing to me primarily because it does represent a different deployment paradigm than what we are primarily using today for SIP deployments. Today SIP clients register with SIP servers and all the signaling is generally handled by those servers. With P2PSIP, the idea would be that you remove the servers and have all the routing, signaling, etc. handled by the “cloud” of P2P SIP clients. Clients get added and removed to the P2P cloud as they come and go and all the “intelligence” resides in the cloud.

Outside of the world of open standards, this architecture is best seen in voice with Skype. Skype clients connect to each other and route calls and media packets across the Skype cloud. I should note that Skype is not a pure P2P cloud. As was shown by the 2-day outage earlier this year, Skype still does very much rely on servers for authentication.

Will the P2PSIP working group wind up creating something like an open standards version of Skype? Maybe… maybe not… the effort is really only in the beginning stages. (And you can stay up with what is going on at “p2psip.org“.) There are all sorts of security and privacy issues that have to be addressed but it’s intriguing to see. It’s certainly a group I’ll be monitoring and participating in to the extent that I can.

P.S. If you are curious to experiment with open P2P architectures, you can check out OpenDHT.org, an open, publicly accessbile distributed hash table (DHT). Do be warned, though, that this is really for developers…

Technorati Tags:
ietf, sip, skype, p2p, p2psip

Afer I just posted on my Disruptive Telephony blog about current development work to create a native SIP client on the Apple iPhone and iPod Touch, I realized that I could have just as easily posted about that here instead (or cross-posted). Anyway, as I note in the post, this development work is still in its early days (and they are looking for assistance), but it’s good work to see, in my opinion. Let’s see what happens!

Technorati Tags:
apple, iphone, ipod touch, sip

Hi, I’m Dan Burnett. I’ll be posting here occasionally about the speech-related standards in W3C and IETF.

I’m an editor of VoiceXML 2.0/2.1, SSML 1.0/1.1, and MRCPv2, an author of EMMA 1.0, PLS 1.0, SCXML 1.0, and the forthcoming VoiceXML 3, and a contributor to almost every other specification from the Voice Browser and Multi-modal Working Groups.

As I mentioned previously, there is some activity related to the IETF happening within the walls of Facebook. With IETF 70 over last week, I was both surprised and pleased to see that Tony Li over at Cisco had already created a Facebook Event for IETF 71 in Philadelphia on March 10-14, 2008. If you are a Facebook user, you can add yourself to the Event if you will be attending.

Now that I know the event has been created, it will be interesting to see what usage it gets in advance of the IETF 71 meeting. I confess to being a bit skeptical about the usage of Facebook Events and Groups for coordinating or communicating in advance of meetings. In theory, they seem useful, but because you only get notified of new wall posts or discussions when you visit the Event or Group page, I don’t really see the conversations developing.

In any case, it’s an interesting experiment and I’ll be glad to join in to see what comes of it.

Out at IETF last week, there were several conversations where the people mentioned work that “another SDO” was doing. It occurred to me that outside of standards circles that acronym has little meaning, so I thought I’d just mention it for those new to the world of standards.

An “SDO” is a “standards development organization” (or sometimes “standards developing organization”), essentially an entity that exists out there to develop standards. The one we’ve been writing about here is the IETF, which sets standards for Internet-related protocols. Another one with which we in Voxeo are involved is the W3C, which has standardized HTML, XML and other web-based standards. The 3GPP is also important in the world of VoIP and mobile networks. There are, naturally, thousands of such organizations out there.

The tricky part, of course, comes when one SDO goes to use standards developed within another SDO. On the one hand, this is a great example of reusing existing work. For example, there is a draft within the MEDIACTRL Working Group of the IETF that will standardize the use of VoiceXML (a W3C standard) within the IETF’s SIP framework for media control. However, there can also be conflict when the standard being referenced evolves (or does not evolve) in the direction desired by another SDO. An example came up at the IETF meeting last week where the IETF was debating NOT including a particular element in SIP and someone who had recently attended a 3GPP meeting indicated that the 3GPP was expecting this capability to be included in SIP.

Anyway, that’s what a SDO is. If you would like to learn more about SDOs, NSBs and other TLAs (three-letter-acronyms), the Wikipedia article on Standards Organizations is a great place to start.

One of the livelier sessions at the IETF meeting in Vancouver, BC was the segment having to do with SPIT. No I am not talking about what comes out of your mouth but rather the internet telephony version of SPAM. While it’s not a big problem yet, folks in the industry are indeed concerned about it and how to prevent it before it gets to be one.

The problem (or really the good news in this case) is that for the most part SPIT does not really exist yet in the wild. This being the case however we really don’t yet know what it looks like or how to detect it.

Currently some of the work is going into figuring out what SIP header we would transmit SPIT information to clients in. The problem is that at this point I don’t think that it’s clear that we know what SPIT scores need to look like. Is a simple number from 1-100 the right way to measure this? Or do we need a more complex way of delivering multiple scores and information to explain to the user agent what the SPIT detectors have discovered.

All of this however does not yet touch on the MUCH bigger problem of how to detect SPIT. As with e-mail the problem is that much depends on the context and permissions involved in the actual message. You can not simply decide that something is SPIT based on the fact that they place a lot of calls in a short amount of time (as I have heard suggested by some people). An example of a use-case where this does not work is emergency outbound notification. For systems like this platforms NEED to be able to place very large numbers of phone calls in a short amount of time. While some might say that white listing can help with some of these cases I think e-mail has shown that for this most part this does not not work. I don’t want to miss a call telling me that something horrible when on at my child school because I forgot to enter my school’s phone number into my office PBX.

Anyway there is still much work to be done in the space and there are sure to be many more heated discussions at the IETF and elsewhere on this subject.

It’s been a long and exhausting week here in Vancouver at IETF 70. Lots of good sessions… great hallway discussions… plans for work to do… I’ve got a whole number of posts that I’ll be writing up in the days ahead.

Right now, though, it’s 4:30am here in Vancouver and it’s time for me to start heading to the airport for what looks like about 13 hours of travel time back to Burlington, Vermont (I work remotely in a home office.) RJ is already gone as he had some customer visits yesterday and today before he heads back to Orlando.

It’s been a great meeting… the next on will be IETF 71 in March in Philadelphia.

Technorati Tags:
ietf, vancouver

Today at the ENUM meeting one of the documents I discovered was the ENUM experiences internet draft. If you have ever had to implement ENUM in your product or network you know that navigating the countless RFC’s and ID’s can be a daunting task. While it does not get you out of reading the RFC’s this draft is a niceshort cut that outlines a bunch of the pitfalls that come up and clarifies a bunch of things related to processing enum records that are not always clear in the original RFC documents.