Speaking of Standards

Want to learn about the Session Initiation Protocol (SIP)? Would you like to understand how the SIP protocol works and why it is the dominant open standard for communication today? Want to understand the challenges SIP faces and what’s being done to overcome them?

If so… and if you will be attending VoiceCon in Orlando, FL, March 22-25, you’ll be able to join my (Dan York) 3-hour tutorial on “SIP Fundamentals and Prospects” on Tuesday, March 23rd, from 2-5pm. The abstract VoiceCon has posted is this:

SIP (Session Initiation Protocol) has become the dominant protocol for IP communications. This workshop explains SIP — how it works, the major issues impacting deployments and how SIP will evolve in the future.

The session focuses on the technical aspects of SIP and how it is used. It analyzes in detail the major components of SIP architecture, SIP addressing and registration, session establishment, SIP message routing and connecting SIP across the PSTN. You will learn about SIP extensions and how SIMPLE works for IM/presence. The workshop also examines some of the challenges SIP faces, including NAT traversal (and the tools developed to cope with it: STUN, TURN and ICE) and security. The tutorial concludes with an assessment of how SIP may evolve and its role in peer-to-peer environments. You will receive an inventory of SIP resources—books, papers and organizations.

I’m very much looking forward to the session… although I still do have some work to finish up on the materials. For the past while my friend David Bryan has given these tutorials at VoiceCon events, but given that he also chairs IETF working groups he would need to clone himself since this VoiceCon is the same week as IETF 77 in Anaheim, California. It’s a wee bit hard to flip between coasts… and as anyone who has ever been to an IETF event knows, the meetings are intense and he is needed out there.

If you can’t attend VoiceCon this year, I’ll probably do some SIP tutorial webinars in the future and perhaps you’ll see something popping up over at Voxeo University… stay tuned. And if you are at VoiceCon, please do stop by and say hello… or send me an email in advance letting me know.

---

If you found this post interesting or helpful, please consider either subscribing via RSS, becoming a fan on Facebook, or following us on Twitter.

---

Over at Ars Technica, author Gilad Shaham has started a series of posts about the SIP protocol. So far the two installments are:

• Wired for sound: how SIP won the VoIP protocol wars
• VoIP in-depth: An introduction to the SIP protocol, Part 1

The first article gives some background about SIP and goes on to explain how SIP prevailed over H.323 as the dominant standard for VoIP traffic today. The second article goes through the details of basic SIP messaging and explains how SIP proxy servers and registrars fit into the picture, complete with some diagrams that nicely explain call flows. The author indicates that the next article in the series will dive into SIP calls in more detail.

If you are new to VoIP or to the SIP protocol, both of these articles are great tutorials that will help you learn more about what SIP is all about. If you are familiar with SIP, you still may find some interesting tidbits mixed into the text. The articles are good to see and I’m looking forward to reading the next installments!

---

If you found this post interesting or helpful, please consider either subscribing via RSS, becoming a fan on Facebook, or following us on Twitter.

---

NOTE: David Bryan, co-chair of the IETF’s P2PSIP Working Group, left this text as a comment to my earlier post about P2PSIP and Skype. Given it’s length and great content, I thought it should run as a guest post and David was fine with that. The text below is entirely his.

---

So a few points, in no particular order:

Lee mentioned (as have others before) that P2PSIP is “copy-cat Skype”. This always bothers me, not because we came first (we certainly didn’t) but because it wasn’t my vision for P2PSIP (although others certainly had that view) . When I came up with P2PSIP and brought it to the IETF, I wanted to do things SIP couldn’t do at all. SIP can theoretically build a system that looks like Skype. To me, the interesting areas for P2PSIP were distributed softswitches/corporate IM (config-free small office, etc.), rapid response (quickly set up a communications system after a natural disaster), ad-hoc clusters for IM/app sharing (think Google wave away from the Internet), and vendors adding voice to apps without becoming an ISP. You could do a Skype-like service with P2PSIP (sort of: see below) but that wasn’t really the idea that got me started creating P2PSIP.

To me, Skype’s success was solving the NAT issue and getting the user experience right. P2P was a means to an end/efficiency multiplier, but not the reason for the success. Skype just worked. SIP’s major flaw is embedded IP addresses. Skype avoids this, uses media relays (P2P, but could have been centralized) and “falls back” (in the worst case) to tunneling over port 80. Users love this. Administrators and protocol purists hate it as it breaks traffic characterization, shaping, etc. Skype’s closed garden (one protocol stack) also ensured things just worked. Closed gardens and HTTP tunnels are at odds with the SIP goal of vendor/carrier interoperability. The two achieve different goals. (Today, many folks believe ICE with ISP-provided relays has addressed the SIP NAT problem. It looks promising, but until we have a Skype-sized Internet deployment, some say the jury is out. Time will tell.)

You could theoretically deliver a Skype-like experience with either a SIP or P2PSIP solution. Pure P2PSIP is very decentralized (every node is a peer and central servers are only used for obtaining a certificate), so you would need a hybrid approach if you want to maintain customer control. You could also use regular SIP with ICE, and many, many servers if you could solve the scalability problems. The best approach might be conventional SIP between the endpoints and a cloud of servers, with the servers sharing information using P2P. This ends up looking much like a SIP version of Skype’s super-peer model, executed in the cloud.

All this still begs the question of what happens to the Skype ecosystem of hardware, etc. If you go SIP, what do you break in the process? As Dan York and Shidan Gouran point out, Skype has many options, lots of great engineers, and lots of cash, but nobody outside of Skype knows what they will do.

As an aside to Lee’s comment on P2PSIP as a standard (it is fair to say adoption in product has been very slow, I’m sorry to say): The standard is moving, just at the (glacial) pace of standards, which can be frustrating for idea guys like Lee or I. In the early days, P2PSIP had lots of ideas, chatter, and excited non-standards folks, so work moved quickly. Today, with an accepted draft in progress and a more mainstream standards audience, iterations have slowed. That said, things are moving, there is strong interest, and a lot of hard work by the editors and participants.

My biggest worry is the protocol becoming too cumbersome. We are building a very flexible, universal DHT protocol with mandatory ICE and TLS/DTLS security. This is great for some scenarios, but overkill for others (ad-hoc, for example), and I worry the bulk may make it unsuitable for some of the scenarios I first imagined. I think many of these may migrate to the cloud. DHTs will be used, but as a means to distribute data among servers, not all the way to the edge as I first anticipated. Things change. Progress is good. I’m very excited to see how DHT principals in the cloud might solve many of the problems posed of a pure P2P approach. (eComm talk for SF, Lee?)

---

David Bryan is co-chair of the IETF P2PSIP Working Group and maintainer of http://www.p2psip.org/ More about David can be found at http://www.ethernot.org/ or on Twitter at @davidbryan.

---

---

If you found this post interesting or helpful, please consider either subscribing via RSS, becoming a fan on Facebook, or following us on Twitter.

---

On Monday over on the Emerging Tech Talk video podcast, I posted a brief interview with SIPit coordinator Robert Sparks that I recorded at the SIPit 25 event held in September 2009 at the University of New Hampshire InterOperability Lab (IOL) in Durham, NH, USA.

In the interview, we covered questions such as: What is the SIPit test event all about? How does it make communications systems better? What do participants do at the event? How can companies get involved?

More information about SIPit can be found at http://www.sipit.net/
Robert Sparks has also posted a summary of the SIPit25 event at:
http://www.ietf.org/mail-archive/web/rai/current/msg00720.html

From a Voxeo perspective, I know that our test team gained some valuable insight into interoperabilty with products from other vendors. We’ll be incorporating what we learned into future versions of our product. Getting this type of real-time feedback is why the SIPit events are so powerful. We definitely hope that other vendors will join in to future SIPit sessions.

Meanwhile, here is Robert Sparks…

Technorati Tags: sip, sipit, ietf

---

If you found this post interesting or helpful, please consider either subscribing via RSS, becoming a fan on Facebook, or following us on Twitter.

---

SIPit 25 starts four weeks from today at the University of New Hampshire’s InterOperability Lab (IOL). What is SIPit? As the UNH-IOL page for the event says:

SIPit’s, or Session Initiation Protocol Interoperability Tests, are weeklong events where people bring their SIP implementations to ensure they work together. SIPIT Events are open to anyone with a working SIP implementation. The goal of the events is to refine both the protocol and its implementations. The SIPIT events are a driving force shaping SIP into a globally interoperable protocol for real time Internet communication services.

Basically, they are a place where vendors can privately test their SIP implementations against each other. Results of the testing are not publicly released – other than an aggregate news release talking about what occurred overall. It’s a place where, as a vendor, you get a great chance to see how well your SIP-based product interoperates with that of other vendors. It’s also a place where vendors will often bring early implementations of new SIP standards to test those against other vendors working on early implementations. All in all, it definitely helps with moving us all along the path toward increasing SIP interconnection.

We’ll have a Voxeo team at this SIPit. We’ve been based on SIP since we started our company back in 1999 and we’re continually looking at ways to increase our performance and support for evolving SIP standards. We value the feedback we gain from these SIPit events and try to attend when we can.

You can attend, too, as there is still space available. The UNH IOL event page has more info and there is an online registration form as well. (Deadline to register, though, is September 4th.)

P.S. And yes, since yours truly lives about two hours west of UNH, I *am* planning to head over and meet our testing team for dinner probably in beautiful Portsmouth, NH… I’m in “marketing” now, so they don’t let me near the test equipment. I mean, in my world, all the tests just work, right? And they have really pretty charts to go with them…

---

If you found this post interesting or helpful, please consider either subscribing via RSS, becoming a fan on Facebook, or following us on Twitter.

---

Long-time readers will know that I have a fascination with the ideas behind P2PSIP, which I explained once before in a post “P2PSIP and pushing voice down into local clouds”. While it has very little directly to do with my work here at Voxeo, I’ve continued to help a team of folks with the IETF who are working on an Internet-Draft providing an overview of the security concerns related to P2PSIP.

Given the upcoming IETF 75 meeting, I published an updated version of the Internet-Draft last week. It is available at:

http://tools.ietf.org/html/draft-matuszewski-p2psip-security-requirements

Those of you interested in SIP, P2P networks or security in general may find it of interest. Here’s the abstract:

This document provides a security overview and analysis for the Peer- to-Peer Session Initiation Protocol (P2PSIP) overlay network. It discusses security threats for the P2PSIP architecture and its components. It compares security difference between client/server (C/S) and P2P implementations of SIP, and then partitions the P2PSIP architecture into layers and analyzes the security issues in each layer and the security relationship among the layers.

My particular contribution in this revision was writing a new section on “Interconnection to other networks“. Many, if not most, P2PSIP networks will want to interconnect with the legacy PSTN or with other SIP networks. This section takes a look at what the security ramifications are and what an implementor of a P2PSIP network should consider.

Comments and feedback about this draft are of course welcome. At IETF75 in Stockholm I know that members of the author team will be asking the P2PSIP Working Group to accept this as a “working group document” (another step on the path to becoming a RFC) and there will undoubtedly be further revisions of the document.

---

If you found this post interesting or helpful, please consider either subscribing via RSS, becoming a fan on Facebook or following us on Twitter.

---

Technorati Tags: sip, p2p, p2psip, security, ietf, standards

---

If you found this post interesting or helpful, please consider either subscribing via RSS, becoming a fan on Facebook, or following us on Twitter.

---

Last November, Skype announced that they were seeking a someone to head up the Skype Developer Community program. I wrote about this over on my DisruptiveTelephony blog and Jim Courtney wrote a more detailed piece on his Voice on the Web site. Jim quoted – and agreed with – my statement:

For those of us watching the emerging communication/telephony space, we’ve seen Skype make several different attempts over the years to create a successful developer program. Given their incredible user base and platform, it’s been curious to see that they haven’t yet found the right formula.

Skype has tried several times to create a strong developer program. In fact, we here at Voxeo were part of one of the first early attempts, their “Voice Services” program back in 2005 which eventually faded away. We still are huge fans of Skype, use it heavily internally and are very pleased that we are able to provide inbound Skype connections to voice applications on our platform. We want Skype to succeed.

So I was immensely pleased when, a bit over a month ago, Skype announced that they were hiring CounterPath CTO Jason Fischl as their Director of Developer Relations to head up their Developer Program, among other tasks. Through my work in the IETF and meeting at various events, Jason and I have become friends and so I was personally thrilled for him to step into this role. He is a smart guy with great communication skills. His work as CTO of CounterPath, arguably the largest provider of softphones out there (probably mostly known for X-Lite, but producer of many others), has given him a great view into softphone technology. And through all that, he has a wealth of connections into the developer community. Hiring Jason was a great move on Skype’s part.

What is interesting to look at from a standards point-of-view, though, is that in the hiring of Jason, Skype also imported some solid and current SIP-related credentials. Jason has been very active in the real-time communication area of the IETF – the area that deals with the SIP protocol – and has been involved in many of the IETF working groups in the area.

In fact, he is currently one of the co-chairs of the Basic Level of Interoperability for SIP Services (BLISS) Working Group whose aim it is to facilitate basic interoperability between SIP endpoints (hardphones, softphones, etc.). Primarily BLISS is aiming to solve the issue that SIP allows multiple ways to do things (such as signal “Do Not Disturb”) and different vendors have implemented different mechanisms. BLISS is trying to help make the interop cleaner. The working group is also where some cool new work like a RESTful API for automated call handling is being developed.

Jason is also the lead author on the Internet-Draft about using Secure RTP over DTLS, which has been identified as “the way forward” for establishing secure, encrypted media sessions between SIP endpoints to replace today’s reliance on ’sdescriptions’. (After a lengthy series of meetings/discussions and something like 13 other proposals including Phil Zimmermann’s ZRTP.) Assuming Jason continues his IETF work and this document proceeds to becoming an RFC, there will be an amusing bit of irony to have the IETF’s main method for secure media co-authored by someone at the proprietary Skype. (Although in truth Skype has a huge SIP backend infrastructure for PSTN connectivity.)

Jason is also the editor of a highly-regarded draft on a certificate management system for SIP and has been involved with a number of other drafts. All in all he’s got very solid SIP credentials and background in open standards and open source. He’s a good guy to have at Skype and I certainly wish him all the best on coming up with Skype’s nth Developer Program. We look forward to seeing how it evolves (and seeing how we can work with the folks at Skype).

Not that I’m setting high expectations or anything… okay, Jason?

---

UPDATE: There’s also an interview with Jason up on YouTube about his new role.

---

If you found this post interesting or helpful, please consider either subscribing via RSS, becoming a fan on Facebook or following us on Twitter.

---

Technorati Tags: skype, jasonfischl, developers, sip, ietf

---

If you found this post interesting or helpful, please consider either subscribing via RSS, becoming a fan on Facebook, or following us on Twitter.

---

Last Friday afternoon, the 74th meeting of the Internet Engineering Task Force (IETF) drew to a close in San Francisco. It was quite an interesting meeting on a number of levels and while I was not there in person, I was following along on the live audio streams, Jabber chat rooms and mailing lists. I’ll be writing up some of my thoughts over the next few days.

Right now, though, I thought I’d point out to those of you following along where you can find resources to understand what went on at IETF 74. Basically all info from the IETF meetings is online, at pointers such as:

• IETF 74 Agenda – links to working group agendas and drafts associated with the groups. The logs for the Jabber chat rooms are also available as one of the icons in the line next to each timeslot.

• Presentation materials – the slides used in the various presentations and links to the minutes for each meeting. (Minutes are only now starting to appear and more will be added over the next few weeks as working group minutes are submitted.)
• Audio file archive – MP3 recordings of all sessions… but you definitely need to reference the IETF 74 Agenda to find the room and session that you want to hear.

With those links, you should be able to explore all parts of the IETF 74 meeting.

Now the work of the IETF moves back online into the many, many mailing lists for the next few months. The next face-to-face meeting will be IETF 75 in Stockholm, Sweden, July 26-31, 2009. The hosts of the meeting are “.SE” and they have put together a website at http://www.ietf75.se/ that talks all about Stockholm, the meeting venue, travel, etc. I have not been to Stockholm for past meetings, and I’m not yet sure if I am going to this one this year, but I’ve heard from folks who have gone that it is quite an amazing city. After that it’s on to Hiroshima, Japan, in November 2009 and on to other cities after that…

---

If you found this post interesting or helpful, please consider either subscribing via RSS or following on Twitter.

---

Technorati Tags: IETF, SIP, standards

---

If you found this post interesting or helpful, please consider either subscribing via RSS, becoming a fan on Facebook, or following us on Twitter.

---

Yesterday Skype announced the beta program for “Skype For SIP“, a new service that allows some forms of SIP connectivity between a premise-based SIP server/IP-PBX and Skype’s cloud and the PSTN. Over the weekend I put together a very lengthy post on my external DisruptiveTelephony blog that goes into the service in great detail, but the net of it is that when you sign up for the “Skype For SIP” service, you will be able to:

• Receive inbound calls to your SIP server from Skype users.
• Receive inbound calls to “Online Numbers” (formerly “SkypeIn”) that are routed to your SIP server.
• Place outbound calls to PSTN phone numbers using what was called “SkypeOut” and at Skype’s cheap rates.

The calls from Skype users are free to all involved. The Online Numbers only cost you $60 per year and the outbound calls are at Skype’s various rates.

The program, at www.skypeforsip.com, is accepting applications into the beta program now. Skype isn’t clear on when it will leave beta, but is clear that they will be evolving the program over the next weeks and months.

Note that what you are NOT able to do is to place calls from your SIP server to Skype users. So the interaction with Skype clients is one way – you can receive calls from Skype clients but not call those (at least not yet). As IfByPhone CEO Irv Shapiro notes in his blog post, Skype also has the “Skype For Asterisk” service available in a beta form and it does provide two-way connectivity to Skype users.

From a Voxeo point-of-view, what’s interesting is that this seems to have the potential of providing to users of our premise application platform, Prophecy, a similar kind of inbound Skype connectivity to what we’ve had for about four years now in our hosted application platform (and about which I wrote about last year). According to the info from Skype, Skype users would be able to call into applications by calling a Skype name which would then route the call over SIP to Prophecy. It’s a bit different from our hosted Skype connectivity in that it is a Skype name directing you to the entire platform, whereas in our hosted environment you have a Skype address for each application. Prophecy users would also, it seems, be able to use Skype For SIP to have outbound PSTN connectivity (a.k.a. “SIP trunking”) subject to Skype’s rates.

We’ll have to see how that all shakes out once we can try the software out, but it’s interesting nonetheless. Kudos to Skype for lowering their walls a bit and providing this kind of SIP support.

UPDATE: I also have a video podcast, Emerging Tech Talk #28, up on the subject.

---

If you found this post interesting or helpful, please consider either subscribing via RSS or following on Twitter.

---

Technorati Tags: sip, skype

---

If you found this post interesting or helpful, please consider either subscribing via RSS, becoming a fan on Facebook, or following us on Twitter.

---

It’s no secret that within the Internet Engineering Task Force IETF), work on the SIP-related protocols under the “Realtime Applications and Infrastructure” (RAI) area has frequently seemed to get bogged down under the weight of everything that is trying to be done. Back at IETF 73 in Minneapolis, there was in fact a special “open session” with discussion about how best to restructure internal IETF processes and working groups so that work related to SIP could progress faster.

To this end, RAI Area Directors Jon Peterson and Cullen Jennings today issued a statement and request for feedback related to reorganizing the RAI area. It began:

Since the open area meeting in Minneapolis, Cullen and I have given some thought to the best way to try to act on the discussion and suggested changes. As a continuing part of that process, though certainly not the last step, we’d like some input from the community on the following proposal and accompanying draft.

The rest of the text is in Jon’s email to the RAI general mailing list. They are very definitely looking for feedback in how to improve the process. (And the best place to send that feedback is to the RAI mailing list, which is open to anyone to join.) I think the proposal is a good start, because the reality is that much of the “new” work does indeed get bogged down in either the existing SIP or SIPPING working groups.

I think there’s a larger issue that the pool of people contributing documents and working on SIP-related issues is not growing very quickly… but this change could make it so that people find a more positive reception to new work than in previous years. We’ll have to see.

Related to this reorganization, Jon and Cullen also posted an Internet Draft that is intended to update/replace RFC 3427 that defines how the SIP protocol can be changed. I have some thoughts on this that I need to think about before writing down… but in the meantime I thought I’d mention that they are looking for feedback on this document as well.

---

If you found this post interesting or helpful, please consider either subscribing via RSS or following on Twitter.

---

Technorati Tags: ietf, standards, sip, rai

---

If you found this post interesting or helpful, please consider either subscribing via RSS, becoming a fan on Facebook, or following us on Twitter.

---