Disruptive Telephony

Want to understand Peer-to-Peer SIP (P2PSIP)? Listen to this podcast...

What if we could design SIP-based VOIP systems... but without any servers? What if we could have SIP endpoints just communicate with each other and "self-organize" into networks? What if we could essentially build an open standards-based version of Skype? How would it work? Who would use it? How would we secure it?

Those are all questions we discussed in the Squawk Box podcast / interview I did with David Bryan on July 10th. David is the co-chair of the IETF's P2PSIP Working Group and also the CEO of SIPeerior Technologies. It was a great interview where we covered all these questions and much, much more.

P2PSIP, to me, represents one of the most exciting new directions for SIP research and is something I'm definitely following closely. I wrote about my interest in P2PSIP clouds (and connecting them to larger clouds) at some length over on Voxeo's Speaking of Standards blog... it's all about clouds of SIP communication... and how we weave them all together. It's a fascinating time.

If you'd like to understand what P2PSIP is all about, please do definitely check out the Squawk Box podcast... and then, if you are so inclined, head over to P2PSIP.org to find links to learn more and download code...

Technorati Tags: sip, p2p, p2psip, telephony, peer-to-peer, voip, ietf, dan york, david bryan, squawkbox, sipeerior, cloud computing, clouds

Down at IETF 71 in Philadelphia this week

This week (March 10-14) finds me down in Philadelphia for IETF-71, the 71st meeting of the Internet Engineering Task Force (the people who write the standards for the Internet). I don't honestly know how much I'll be blogging here on this blog. I do hope to be writing some over at the "Speaking of Standards" blog on Voxeo's site. We'll see. These meetings tend to be rather intense.

If you'd like to follow along with what's happening here at IETF, I've written up some instructions about how to join in the audio streaming and IM group chats. I've also posted what I think will be my schedule, which will give you a sense of what the various VoIP-related sessions.

That's the news...

Technorati Tags: ietf, standards, ietf71

As I wrote over on Voxeo's "Speaking of Standards" weblog, one of the ironies of the language we use in this space is that we all have been talking about "SIP trunks" for a few years now, but nowhere has there actually been a formal definition of what exactly a SIP trunk really is!

Jonathan Rosenberg has now offered a definition in a new Internet-Draft titled "What is a Session Initiation Protocol (SIP) Trunk Anyway?" Here is the abstract:

The term "Session Initiation Protocol (SIP) Trunk" has become almost commonplace amongst vendors and SIP providers. Even though the notion of a 'trunk' has a well defined meaning in circuit switched systems, it has never been defined for SIP. This document provides a formal definition for a SIP trunk, discusses its scope and applications, and establishes best practices for identification and security of SIP trunks.

The document makes for good reading even if you are not overly familiar with the concepts behind SIP trunks. Jonathan is looking for feedback and there will I'm sure be continued discussion on this topic.

Technorati Tags: sip, sip trunks, ietf, jonathan rosenberg

IETF "RUCUS" BOF to be held about SPIT...

Over on the Voice of VOIPSA blog today I posted about a new session has been approved for the IETF 71 meeting coming up in Philadelphia in March called "Reducing Unwanted Communications using SIP" a.k.a. "RUCUS".Hannes Tschofenig, who submitted the proposal, has created a RUCUS web page and is looking for feedback. I'm planning to be at the RUCUS session at IETF 71 and would encourage others who want to talk about voice spam / SPIT to join in as well!

Technorati Tags: rucus, spit, spam, voice spam, voip, voip security, security, ietf, standards

A video greeting from IETF 70 in Vancouver

I was up way too early out here in Vancouver, so I wandered over to the show hotel and recorded a little greeting:

Technorati Tags: ietf

Introducing "Speaking of Standards", a new Voxeo blog about industry standards, IETF, W3C, SIP Forum, etc.

A large part of why I have NOT been writing here all that much in the past few weeks is that I've been busy in my new role with Voxeo working on a corporate blog portal. I've been covering a bit of that odyssey over on my Disruptive Conversations blog as well as in my weekly reports into the For Immediate Release podcast. It's been a great amount of work but also a lot of fun - I've been very lucky to have a colleague who does amazing things with CSS and graphics, and so the sites look a whole lot better than they would if I were left to my own devices.

I'm very pleased to say, now, that we've reached the point where I'm willing to link to our work and talk a bit about what we are doing. The main blog portal is the predictable "blogs.voxeo.com" but the weblog that we're really starting to use and could be of interest to readers of this blog is our "Speaking of Standards" blog found at:

http://blogs.voxeo.com/speakingofstandards/

I've obviously been very occasionally writing here about standards and some of that may continue, but I expect most of my writing on the subject will now occur over on this new Voxeo weblog - and I'll naturally be writing more on the subject. We'll be writing about the IETF and SIP standards, but also the W3C and standards such as VoiceXML and CCXML that I've never covered at all here. We'll be linking to events and tutorials we find and generally providing whatever information we can about standards affecting our industry, as well as Voxeo's views and implementations of those standards.

Why would Voxeo sponsor a weblog about standards? Primarily because the company and our products are all about open standards - which was one of the things that attracted me to the company after they first approached me. I've since learned that they've been leading the IVR industry in adopting open standards. As the products page says in the "Fast Facts" sidebar:

• 100% Standards based IVR
• Supports W3C VoiceXML 2.0
• Supports W3C CCXML 1.0
• Supports W3C SRGS 1.0
• Supports W3C SSML 1.0
• Supports CallXML 3.0
• First platform with XML call control
• First platform with XML conferencing
• First shipping CCXML implementation
• First SIP/VOIP IVR platform

Not bad, eh? Add to that the fact that our CTO (my manager), RJ Auburn, chairs the W3C's Working Group on CCXML and we've hired other folks involved with standards efforts... all of that is why we added a weblog on standards.

So if you would like to see our view on industry standards, find tutorials about various standards or learn about standards-related events we may be attending, I would invite you to come on over and check out "Speaking with Standards" - or subscribe to the RSS feed. While I (and others) will still be working on improving the site, it's mostly done and I'm delighted to be able to return to writing more. Let us know what you think!

Technorati Tags: ccxml, ietf, sip, standards, voicexml, voip, voxeo, w3c

I'll be out in Vancouver Dec 2-7 for the 70th meeting of the IETF.

Just confirmed travel plans today - I will be heading out to the 70th meeting of the Internet Engineering Task Force (IETF) in Vancouver, British Columbia, Canada, from December 2-7. If any readers will be out there (either for the IETF or in Vancouver in general), please do drop a note and let me know. This will be my first meeting in my new role with Voxeo and I'm very much looking forward to renewing old acquaintances and also getting more directly involved with the work of the IETF.

Technorati Tags: ietf, sip, standards, voxeo

Did you know RFC 4733 had replaced/obsoleted RFC 2833 for DTMF signaling in SIP?

Did you know that RFC 4733 replaced/obsoleted RFC 2833? I just learned this myself through a SIP Forum mailing list exchange the other day. For those not aware, RFC 2833 and now 4733 define methods of carrying DTMF signals (and other similar signaling) in RTP streams separate from the main audio component of the RTP stream. A typical example of use might be where you were using a highly-compressed audio codec for audio between two SIP endpoints where the high degree of compression might make it challenging for the DTMF tones to be correctly interpreted on the receiving end. Using "RFC 2833 compliant" signaling, the sending SIP endpoint would send those DTMF tones as separate packets within the RTP stream.

My key takeaway from learning about RFC 4733 is that we should really be talking about "RFC 4733 compliant" signaling... but given that the industry is really only now starting to really talk about "RFC 2822 compliant" signaling, I'm not sure I expect to see that happening anytime soon.

Anyway, here's the abstract from RFC 4733 - you can naturally read the rest of the document to understand more:

This memo describes how to carry dual-tone multifrequency (DTMF) signalling, other tone signals, and telephony events in RTP packets. It obsoletes RFC 2833.

This memo captures and expands upon the basic framework defined in RFC 2833, but retains only the most basic event codes. It sets up an IANA registry to which other event code assignments may be added. Companion documents add event codes to this registry relating to modem, fax, text telephony, and channel-associated signalling events. The remainder of the event codes defined in RFC 2833 are conditionally reserved in case other documents revive their use.

This document provides a number of clarifications to the original document. However, it specifically differs from RFC 2833 by removing the requirement that all compliant implementations support the DTMF events. Instead, compliant implementations taking part in out-of-band negotiations of media stream content indicate what events they support. This memo adds three new procedures to the RFC 2833 framework: subdivision of long events into segments, reporting of multiple events in a single packet, and the concept and reporting of state events.

Technorati Tags: DTMF, ietf, sip, standards

IETF approves RFC standard for adding dialstrings to SIP

In the usual (and ongoing) flurry of IETF announcements, there was one notice that caught my attention.  It announces that an Internet Draft document about "dialstrings" has been approved to become a standards-track RFC.  So what, you say?  Well here's a bit more info:

This document provides a way of incorporating a dial string into the SIP or SIPS URI scheme. A dial string is a cousin of a telephone number, but rather than taking the form of a fully-qualified E.164 or national-specific telephone number, it is a description of a literal set of dialed digits that would be delivered over a POTS line. As such, it may include pauses, omit prefixes like area codes, and its applicability is necessarily restricted to a particular context (an enterprise, a LATA, etc). Support for dialstrings was formerly a feature of the tel: URI scheme specification (back in RFC2806); since that functionality did not make it into the revision (RFC3966), it is provided here specifically for the SIP and SIPS case.

Think of it as extra digits you have to type when making a call... or extra keys you have to press to start a service.  The challenge is that SIP proxies and other services need to know that it is a string of numbers that should be handled in a special manner, rather than just thought of as part of a SIP address or something like that.  I mention it here only because it's one of those really low-level things that you can do on the PSTN but until now haven't had a (standard) way to do in SIP. It's also one that ultimately anyone implementing SIP will need to implement.  No RFC number yet, but that will come soon.  Note the nice security warning:

Dialstrings exposed to the Internet may reveal information about internal network details or service invocations that could allow attackers to use the PSTN or the Internet to attack such internal systems. Dialstrings normally SHOULD NOT be sent beyond the domain of the UAC. If they are sent across the Internet, they SHOULD be protected against eavesdropping with TLS per the procedures in [RFC3261].

Yep... as we've been saying over at VOIPSA and Blue Box, you definitely need to think about encrypting SIP if you are sending it across the Internet.  If not, bad things will happen eventually.

Technorati tags: sip, voip, voip security, ietf, standards

Attaining BLISS... (at least in the world of SIP)... a.k.a. why can't we all just get along?

 So you'd like your SIP phones to all work together, eh?  And you'd like your SIP phone from Vendor A to work with the SIP phone of Vendor B and yet give you the business functionality that you used to have in the PBX from Vendor C?

Good luck.

Yes, they will (or should!) all work together for basic call functions, but if you want to do more than just the very basics, you rapidly wind up in the realm of incompatible SIP implementations.  Different vendors support different RFCs... or interpret RFCs differently.  It's a challenge to go beyond basic functionality.

Enter "BLISS", one of the latest working groups coming out of  the IETF. It stands for "Basic Level of Interoperability for SIP Services" and, as noted in its charter, the intent is to define a basic set of functionality ("minimum interoperability requirements") to allow SIP endpoints to interoperate on 4 specific telephony services:

1. Bridged/Shared Line Appearance (BLA/SLA)
2. Call Park/Pickup
3. Do Not Disturb (DND)
4. Call Completion to Busy Signal/Call Completion on No Reply

More details are on the charter page.  These are just the initial four issues chosen to be addressed and Internet-Draft documents are already circulating on some of the items.  I see it as a necessary group if we are to actually have real interoperability between SIP endpoints, and I commend the group organizers on scoping it to an initial 4 issues (rather than making it wide open).

If you work with SIP, I'd encourage you to check out the BLISS web site, read the "problem statement" and charter... and then join the mailing list (and please read the archives to see what's happened so far).  I've joined the list... and would encourage others to consider doing so.  If we do want real SIP interoperability, we need to hammer some of these things out.

For more information, you can download the set of slides presented by Jonathan Rosenberg of Cisco at the IETF 68 meeting stating the problem and why the BLISS working group is needed.  To make it easy to see them, I'm going to embed a SlideShare version here:

See you on the list...

Technorati tags: SIP, IETF, BLISS, VoIP