Archive for January, 2008

Notes from the SIP Forum SIPconnect Compliance Workshop

Friday, January 25th, 2008

1B3DCB2E-8184-471F-878D-12C1E30C7FC6.jpgToday 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 Forum to host SIP Connect Compliance workshop at IT Expo this Friday in Miami

Tuesday, January 22nd, 2008

1B3DCB2E-8184-471F-878D-12C1E30C7FC6.jpgFor 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:
, , , , , ,

Can legitimate SIP traffic be mistaken as SPIT? (voice spam)

Wednesday, January 16th, 2008

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:
, , , , ,

A great overview of SIP security issues from the 3rd ETSI Security Workshop

Wednesday, January 16th, 2008

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:
, , , , , ,