Speaking of Standards

Did AOL, the historical king of walled gardens, just become the biggest public advocate for SIP and open standards for VOIP?

That’s the point David Beckemeyer makes in his blog post challenging my view of the launch of AOL’s “Open Voice Program” as of questionable value. David counters:

However, it is significant for SIP - we now have a household brand not referring just to “VoIP” but referring to “SIP” - the standards-based protocol for VoIP, something neither Skype nor Vonage has done. SIP means interoperability and that’s a good thing for users and the VoIP ecosystem at large. A brand as big as AOL providing awareness for SIP and promoting interoperability is terrific - nobody else is doing it.

He goes on:

It’s important to note that we have never been able to do this so with Skype, even though the service has been out for four years or more - they could have offered this years ago.

Indeed… point taken, David.

While many of us in the VoIP industry have been trumpeting SIP as the VoIP protocol of choice for years, and work of groups like the SIP Forum has helped in that, outside the walls of our telecommunications/networking community a poll of people would probably find that pretty much no one has heard of “SIP” as it relates to VoIP.

On one level, why should they? It’s just a protocol and at the end of the day it shouldn’t really matter. People just want their phone to work… and SIP and other protocols are just the underlying plumbing.

But for those of us who passionately want to see that plumbing be based on open standards like SIP, David’s right… putting the AOL brand behind SIP is a good thing to help raise awareness of SIP and the need for interoperability. AOL is letting users connect any SIP device to their network. Any device. Not just “certified” ones… not “recommended” ones… any device.

It’s a beautiful thing.

And maybe, just maybe, the people who do start using the service will enjoy the freedom of choice that comes with interoperable open standards and maybe… maybe… they’ll start asking for that interoperability in other services. <rosecoloredglasses>Is that too much to hope for?</rosecoloredglasses>

And so while I still may wonder how many people will really use AOL’s service, as a huge believer in open standards… working for Voxeo, a company who bases its existence on open standards… as a believer in the messy but open process of the IETF to create SIP standards… as an advocate for open protocols and interoperability… as all of that I have to join David in applauding AOL’s move. Thank you, AOL, for jumping behind SIP and helping, in some small way, to help tear down the walls that have locked in telephony for way too long.

Go AOL! Go SIP!

Technorati Tags: aim, aim call out, aol, aol open voice, sip, ietf, standards, voip, telephony, telecommunications

What happens when a 100 or so SIP developers and engineers get together with all their gear? Well, starting today at the University of New Hampshire’s Interoperability Lab in Durham, NH, those developers will be participating in SIPit 22 and testing the interoperability of their solutions with those of everyone else. Sponsored by the SIP Forum and currently coordinated by Robert Sparks, the events provide a place for SIP implementors to test out how well their products work with others’. When you attend, you essentially arrange with others there to test your product with theirs and do so. The results are not published… it’s just a place for engineers/developers to go and work together on interop. Summaries of what occurred are released and you can get a sense of what goes one through the summary of SIPit 21 this past November in Beijing.

As you might expect, since I’m writing about this, one of our lead SIP developers is up there at SIPit 22 with our Prophecy product. As we’re working on some improvements in our SIP support that we’ll release in new versions of Prophecy over the next year or so, he’s looking forward to testing our new work and learning how well it works (or doesn’t work) with many other SIP implementations.

Given that SIP is composed of so many pieces and there are so many options in the way in which you can implement parts of SIP, events like SIPit that foster interoperability are really a key way to helping the industry grow. It’s great to see the SIP Forum continue to sponsor the SIPit events and we look forward to participating more in the future. Meanwhile, we’ll be very curious to see what results are brought home at the end of the week…

Technorati Tags: sip, sip forum, sipit, standards, ietf, voxeo, prophecy

Want to try out peer-to-peer SIP? (P2PSIP?) One of the areas of work within the IETF right now that intrigues me the most is the whole effort around “peer-to-peer” SIP, a.k.a. “P2PSIP”. The idea is that you could have “SIP without servers”, i.e. a range of SIP endpoints (hard phones, soft phones, etc.) that would learn of each other and communicate with each other using SIP over a P2P network (also referred to as a “P2P overlay” or sometimes just casually as a “P2P cloud”).

In another post at some point, I’ll write more about why P2PSIP is intriguing to me (and for Voxeo), but for the moment I thought I’d post that David Bryan, chair of the IETF’s P2PSIP Working Group, has very nicely put up a page listing existing implementations of P2PSIP technology. There are several open source implementations, as well as a commercial implementation from David’s own company, SIPeerior Technologies (he’s the CEO). All of these are implementations of exists drafts and so they will undoubtedly change as the drafts evolve and morph into RFCs over the next months and years ahead. Still, if you’d like to experiment and get a sense of what people are working on, the implementations are now out there!

P.S. David has also posted the P2PSIP presentations from IETF 71 earlier this month.

Technorati Tags: sip, p2p, p2psip, sipeerior, ietf, sipdht

On Sunday night I head down to Philadelphia for the IETF-71 meeting for the whole week. It will be a crazy week full of discussions and conversations about all the various standards under development. The RUCUS BOF I’ve mentioned before will be on Monday as is the SIPPING Working Group. MEDIACTRL Working Group (of key interest to us here at Voxeo) is on Wednesday as is SPEERMINT and PEPPERMINT (Hey, it’s IETF, you have to have cute names!). Thursday brings SIP, BEHAVE, AVT and ENUM and Friday morning winds it all up with the P2PSIP working group.

Being who I am, I’ll pretty much sit in all of the “Realtime Applications and Infrastructure” (RAI) working groups as sometimes activity in one group turns out to have great relevance to work in other groups (or to work here at Voxeo). I’ll be online the Jabber chat rooms probably much of the whole time as well.

If you’ve never seen the full agenda for an IETF meeting, it’s pretty incredible (at least to me!). In any given timeslot there are typically eight simultaneous meetings of various working groups, BOFs, research groups, etc. This makes sense if you remember that the IETF is developing standards for pretty much all aspects of the Internet. While I usually never leave the world of RAI, there are groups dealing with security, DNS, email, IPv6, network routing, time (seriously!), host configuration and pretty much every other subject you can imagine relating to the Internet. Take a look!

And yes, the days do begin with a breakfast at 8am and meetings that go until 7pm (often with additional ad hoc meetings afterwards). The good news is that the breaks between sessions usually have food and drink to keep you recharged.

For those attending who wish to stalkfind me, here below is the agenda I think I’ll be following (subject to the fact that it can, of course, change). Like I said earlier, it’s pretty much all of the RAI area.

---

MONDAY, March 10, 2008
0800-0900 Continental Breakfast - Franklin Hall Foyer

0900-1130 Morning Session I

RAI

mmusic

Multiparty Multimedia Session Control WG

1300-1500 Afternoon Session I

RAI

rucus

Ruducing Unwanted Communications using SIP BOF

1520-1720 Afternoon Session II

RAI

ecrit

Emergency Context Resolution with Internet Technologies WG

1740-1950 Afternoon Session III

RAI

sipping

Session Initiation Proposal Investigation WG

TUESDAY, March 11, 2008
0800-0900 Continental Breakfast - Franklin Hall Foyer

0900-1130 Morning Session I
One of these:

IRTF	rrg	Routing Research Group
OPS	v6ops	IPv6 Operations WG
RAI	geopriv	Geographic Location/Privacy WG

1300-1500 Afternoon Session I

RAI

bliss

Basic Level of Interoperability for SIP Services WG

1520-1720 Afternoon Session II

RAI

avt

Audio/Video Transport WG

1740-1840 Afternoon Session III
One of these:

IRTF	asrg	Anti-Spam Research Group
RAI	simple	SIP for Instant Messaging and Presence Leveraging Extensions WG

1850-1950 Afternoon Session IV

RAI

xcon

Centralized Conferencing WG

WEDNESDAY, March 12, 2008
0800-0900 Continental Breakfast - Franklin Hall Foyer

0900-1130 Morning Session I

RAI

mediactrl

Media Server Control WG

1300-1500 Afternoon Session I

RAI

speermint

Session PEERing for Multimedia INTerconnect WG

1510-1610 Afternoon Session II

RAI

peppermint

Provisioning Extensions in Peering Registries for Multimedia INTerconnection BOF

1610-1700 PGP Session
(Yes, I’m one of those people who does actually go to PGP key signings.)

pgp

PGP Key Signing

1700-1930 IETF Operations and Administration Plenary - Salon G/H

THURSDAY, March 13, 2008
0800-1700 IETF Registration - Franklin Hall Foyer

0800-0900 Continental Breakfast - Franklin Hall Foyer

0900-1130 Morning Session I

RAI

sip

Session Initiation Protocol WG

1300-1500 Afternoon Session I
One of these:

IRTF	hiprg	Host Identity Protocol
SEC	saag	Security Area Open Meeting
TSV	behave	Behavior Engineering for Hindrance Avoidance WG

1510-1610 Afternoon Session II
One of these:

RAI	avt	Audio/Video Transport WG
RAI	enum	Telephone Number Mapping WG

1700-1930 Technical Plenary - Salon G/H

FRIDAY, March 14, 2008

0800-0900 Continental Breakfast - Franklin Hall Foyer

0900-1130 Morning Session I

RAI

p2psip

Peer-to-Peer Session Initiation Protocol WG

---

As I mentioned previously, the “RUCUS” BOF about voice spam at IETF 71 in Philadelphia is one of great interest to us. Unfortunately BOF co-chair Hannes Tschofenig ran into a problem with his domain and had to move the page to a new URL: http://www.shingou.info/bof-rucus.html

If you saved the URL or sent it on to someone, you’ll need to update to using the new URL. If you didn’t visit the RUCUS page before, please do check it out - and feel free to join the RUCUS mailing list. Of course, if you can, please do join us in person in Philadelphia!

Technorati Tags: spit, ietf, spam, rucus, standards, sip

In the list of recently published RFCs, I was intrigued to see RFC 5118, “Session Initiation Protocol (SIP) Torture Test Messages for Internet Protocol Version 6 (IPv6)“. This is really a companion document to RFC 4475 that provides IPv6-related messages you can use while testing SIP. From the overview:

This document is informational, and is *not normative* on any aspect of SIP.

This document contains test messages based on the current version (2.0) of the Session Initiation Protocol as defined in [RFC3261].

This document is expected to be used as a companion document to the more general SIP torture test document [RFC4475], which does not include specific tests for IPv6 network identifiers.

This document does not attempt to catalog every way to make an invalid message, nor does it attempt to be comprehensive in exploring unusual, but valid, messages. Instead, it tries to focus on areas that may cause interoperability problems in IPv6 deployments.

As IPv6 continues to move (slowly) along, it’s great to see an example like this RFC 5118 that can aid people who are developing SIP apps for IPv6.

Technorati Tags: ietf, ipv6, standards, sip

Over on the EComm2008 blog, Lee Dryburgh posted the transcript of a fascinating interview with Jonathan Christensen, general manager of audio and video at Skype. The interview is well-worth a read as Jonathan provides a preview of his upcoming keynote at EComm 2008 with his view of Internet-based communication and talks about advances they have made at Skype with regard to wideband audio and echo cancellation. I do definitely agree with his statement around the improvements they’ve made with echo cancellation on the Mac. Ever since upgrading to the latest Skype, I’ve made many calls with it from my MacBook Pro without any headset whatsoever and have been told the quality has been excellent (and it has been for me when I’m talking to other headset-free Skype users).

Much more relevant to this blog, though, were Jonathan’s statements regarding SIP. At the beginning Jonathan mentions how he originally got very excited by the vision of SIP and ran around stirring up interest at Microsoft where he worked then. But at the end of the interview, Lee asked Jonathan to elaborate on his earlier comments about SIP. This is what Jonathan said:

Yes, so just one clarification - we use SIP. Where, by comparison to the other operators, we are one of the largest SIP users in the world. All of our SkypeOut minutes and SkypeIn minutes traverse the PSTN via SIP interfaces, basically. So, we use it as an interop protocol where we need to.

I think that the vision of the early SIP founders has been largely unrealunrealized [See comments] in the SIP world. SIP is typically just used for these very mundane trunking applications, like the one that we have, or sending calls between two networks and it’s just calls. The vision of multi-modal communications and rich end points has largely failed within the same. I think that a big part of this is that they didn’t pragmatically just solve basic problems like NAT traversal, for example. They also evolved the specification to the point that it no longer had its lightweight appeal. So, we’ll see, SIP will continue to be [the] dominant protocol in terms of this sort of narrowly defined scenarios but I think that, when it comes to rich communications, you are going to see more of this fragmentation. You’re going to see some islands of providers who are just solving the problems. Just making it work for the user and not being religious about the protocol for example.

Has the vision of rich communication over SIP been “largely unrealized”? What do you think? Are his statements true? Or exaggerated?

FYI, if you are attending EComm 2008 you’ll have a chance to hear Jonathan Christensen’s keynote directly. And if you aren’t yet attending EComm 2008, why not?

P.S. For the record, we, too, are huge users of SIP for our connections to/from the PSTN and also throughout our hosted Evolution platform as well as our on-premise Prophecy product. Developers on our hosted platform also get by default SIP *and* Skype dial-in numbers for their applications.

Technorati Tags: skype, sip, ecomm, ecomm2008, conferences, jonathan christensen

Today here at the Internet Telephony Expo in Miami Beach, Florida, the SIP Forum held a “SIPconnect Compliance Workshop” to help people understand the newly announced SIPconnect 1.0 specification. What follows are some notes about the session. There were about 40 people in attendance.

NOTE: I recorded the session and at some point the audio recording will be made available through the SIP Forum website.

---

The session began at 10:00am with SIP Forum Managing Director Marc Robins provided an overview of the SIP Forum, its activities and its members. There are now over 4,000 individual “Participant” members (membership is free) and 36 “Full” members who financially sponsor the SIP Forum. Marc also hinted at several major announcements coming up in the next weeks.

Marc next outlined the value proposition for SIPconnect. One of his main points was that “1st generation IP PBXs are dumbed down” in that they have to connect to the PSTN and can’t do direct peering. The ideal is really to connect directly into VoIP service providers. SIP is the industry standard for VoIP, but it’s difficult for people to understand which of the many pieces of SIP are relevant and necessary.

Marc stated that the industry needs an “industry-accepted interconnection method”. “SIPconnect” specifies a reference architecture - it specifies the minimum IETF and ITU specifications required to have successful interconnection between an IP-PBX and VoIP service provider. The point is really to be a “universal approach to SIP trunking”. Everyone who is certified as “SIPconnect compliant” has gone through an engineering exercise to ensure that they are truly interoperable.

Marc indicated that for SIPconnect delivers customer cost savings, enables transparent feature transport, optimizes quality of service and provides security. For IP-PBX manufacturers, Marc indicated that it can provide a competitive advantage, eliminate proprietary interfaces and generally a more seamless selling proposition for customers. For Service Providers, they get improved QoS and security, the ability to offer higher quality services for IP-PBXs and the ability to forge strong relationships with IP-PBX vendors and new relationships with distribution channels. Customers save money by not having to purchase a TDM gateway, improves voice quality by removing gateway latency and most importantly they get a foundation for future applications and services. For distributors and VARS they eliminate all the PSTN interconnection woes, they have the ability to manage QoS and also to move security issues from the customer premise into the service provider’s cloud.

Next up was Chris Gatch, the CTO of CBeyond, who provided an overview of the SIPconnect Compliance Process: What is the SIPconnect Compliant program? What does it cost? How do I join? How do I maintain my status in the program?

Steps to become SIPconnect Compliant:

• (optional) Join the SIP Forum to get a reduction in the licensing fee ($2500/yr versus $5000/yr).

• Download and complete the application.
• Complete the Compliance Survey
• Execute the Licensing and Compliance Agreement

Your application is then reviewed by a SIP Forum Certification Committee to determine compliance. Chris noted that they will work with folks because the goal is to help people to become compliant. To maintain compliance, you have to pay the annual $2500 licensing fee and keep up with the standards.

Chris provided some links and noted that the consolidated survey results are available that give some insight into how compliant products are. He noted that there are currently 7 companies who have certified 10 products. The two IP-PBX vendors who have certified are Digium and Avaya. Chris noted that it’s not about getting feeds but rather in driving interoperability and compatibility. It needs to be as meaningful as saying “FXS” or “PRI”.

Next up was Mark Enstrom from Broadsoft who discussed the “Lessons Learned” from companies as they became SIPconnect compliant. He spoke of information they gathered from informal conversations with companies that became SIPconnect compliant. Mark’s suggestions for service providers included:

• Document your processes.

• Standardize PBX configurations.
• Provide configuration guides.
• Provide an external interface for partner self-certification. (Example)

The question was raised by a participant of whether you could take a SIPconnect compliant IP-PBX and just connect it to a SIPconnect-compliant Service Provider. The answer is that this is the ideal to which the standard is a step. You still should need to do interoperability testing but it should be faster with SIPconnect-compliant products. The goal is to get to that point where it is as easy as connecting in a PRI.

For IP-PBX vendors, Mark suggested these guidelines:

• Become SIPconnect compliant

• Promote the program with service providers
• Implement the DIGEST authentication method
  • TLS is required by SIPconnect (has become a general exception for most Compliant participants)
  • DIGEST is used in deployments
• Implement optional REGISTER method (versus using static registrations)
  • Saves headaches in interop and deployment
  • Use master registration
  • Less configuration on the SBC
  • Reduces/eliminates downtime due to static registration address changes.

Mark then discussed issues around supporting fax and modem deployments, basically indicating that services providers today really need to explicitly test fax/modem deployments and document/support only a few configurations. Many service providers are still using separate interfaces for fax/modem traffic.

Mark moved into NAT and firewall issues. Service providers need to document what they support and train their customers and channels. Most firewalls are not SIP-aware. If you can use a SIP-aware firewall, you’ll be better off. Optionally, you can use port-forwarding or far-end NAT traversal if you understand the security issues.

Next Mark reminded service providers that they need to NOT forget back office integration. BSS/OSS integration needs to be factored into planning. Don’t forget to include billing systems: “If you can’t bill for it, it’s just a hobby!”

As far as the economics, the cost savings are very real with the elimination of PSTN gateways. Going direct with IP allows additional revenue opportunities, such as providing DN/DID services to smaller companies and delivering services to individual end users.

After a break, Chris Gatch came back to do a “deep dive” walking through the SIPconnect technical recommendation line-by-line with the 10 or so folks who remained. (And I stopped recording notes to focus on the spec.)

Chris later discussed some ideas around what SIPconnect 1.1 might focus on. Some of the possible areas of work include:

• Update to use RFCs since the time of SIPconnect 1.0

• Clarify DIGEST vs. TLS
• Address “Off-Net Call Flows”
• More specific recommendations around NAT and firewall issues
• Provisioning Schema Standard
• Redundancy/Recovery Use Cases
• Re-visit requirements around media capabilities

Chris emphasized that these are only ideas about what might go into the SIPconnect 1.1 spec. The workgroup for SIPconnect 1.1 is only forming now, so the scope of the 1.1 work is yet to be defined.

The meeting concluded around 1:10pm with some final remarks by SIP Forum Managing Director Marc Robins encouraging people to become more involved with the SIP Forum.

Technorati Tags: sip, sip forum, sipconnect, sip trunking, standards

For those of you attending the Internet Telephony Conference and Expo this week in Miami Beach, Floriday, the SIP Forum will be holding a SIPconnect Compliance Workshop on Friday, January 25th, from 10am-1pm. The workshop is free and the agenda is available. If you are at the show, please do come on by and learn about this initiative from the SIP Forum to help ensure interoperability for SIP trunking between service providers and IP-PBX systems. I’ll be there and it would be great to meet anyone reading this blog.

Technorati Tags: sip, sip forum, sipconnect, sip trunking, itexpo, internet telephony expo, miami

As more systems get connected using VoIP and over time security systems come into use to help prevent voice spam, a.k.a. “SPam for Internet Telephony” or “SPIT”, what happens if you have an application that makes a very large number of outbound calls? For instance, a notification system? Might the traffic from that application not look like the beginning of a flood of SPIT?

Within the IETF there’s been a bit of discussion in the past months about voice spam/SPIT and just recently RFC 5039 from Jonathan Rosenberg and Cullen Jennings was published that specifically addresses the issue of SIP and Spam.

The RFC is an excellent summary of the current thinking about the SPIT problem and potential solutions to address it. If you haven’t read the document, I would *highly* recommend it.

A concern I had, though, was that it did not appear to me that existing documents address the issue of what SPIT could look like at a network level. For instance, if a network administrator monitoring network traffic suddenly saw a large flood of SIP INVITE packets coming into his/her network, it could be:

1. a telemarketer/spammer launching a flood of SIP connections to deliver SPIT;
2. an attacker launching a DoS attack through one of the various SIP attack tools out there; or
3. a legitimate notification system starting to notify a range of SIP endpoints.

I could very easily see existing network tools that look at traffic and perform anomaly detection (and potentially source suppression) being modified to suppress large flows of SIP traffic. This last case of legitimate traffic concerned me and so I put together an Internet- Draft talking about the types of legitimate systems that might generate a significant volume of traffic that could resemble SPIT (or a DoS attack).

I put the document out primarily to stimulate discussion. Are these legitimate scenarios being addressed in current thinking about SPIT? If not, my point really is that they need to be considered.

Comments about the document are very definitely welcome. Are there other scenarios I should include? Am I accurate? Am I overstating the case? or what?

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