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
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.
In the IETF spirit that gave us 
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”).
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! 
RSS Feed