Speaking of Standards

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

Over on the “Voice of VOIPSA” weblog, I posted about an excellent overview of SIP security issues that Hannes Tschofenig presented yesterday at the 3Rd ETSI Security Workshop in France. If you aren’t familiar with the current state of SIP security, I’d highly recommend you take a read through Hannes’ slides.

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

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