Speaking of Standards

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

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!

Leaping into the fray now is Jonathan Rosenberg, author of a zillion Internet-Drafts and multiple RFCs, with his new I-D titled, appropriately “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

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