SIPconnect is a standards-based method of interconnection between IP PBXs and VoIP service provider networks. It specifies a reference architecture, required protocols and features, and implementation rules necessary for seamless peering between IP PBXs and VoIP service providers.
The SIPconnect Interface Specification was launched by Cbeyond Communications in 2004 with support from Avaya, BroadSoft, Centrepoint Technologies, Cisco Systems, and Mitel. Subsequent to an initial draft released by this group, the SIPconnect group and the SIP Forum worked to transfer this activity into the SIP Forum's Technical Working Group for further development and formalization into the current SIP Forum Recommendation. The charter for the SIPconnect Task group can be found here.
SIPconnect accelerates the adoption of direct IP peering between IP PBXs and VoIP service providers, delivering a well defined interface and approach to such. SIPconnect provides clear guidelines to PBX vendors and service providers regarding how IP peering should be implemented. A consensus approach will drive faster adoption.
Business customers are the end users who will ultimately benefit from direct IP peering.
Businesses that use SIPconnect compliant IP PBX's peering directly with their communications service provider eliminate the need for expensive TDM gateways, and increase the efficiency with which they use local access facilities. They also increase their opportunity to purchase enhanced applications from service providers and can more easily extend the functionality of their IP PBX across service provider networks.
The ability to provide Direct Inward Dialing (DID) capabilities with lower cost service offerings is a huge and immediate selling point for most small business customers. While many small business are unable to afford a full T1 or PRI line with which DID is normally provided, direct IP peering enables VoIP service providers to offer multiple direct phone number through any IP connection.
Direct IP peering is a huge “value add” for businesses and for service providers alike - those purchasing and interconnecting with IP PBXs. When an IP PBX vendors’ product supports an industry-accepted standard that addresses quality of service and security issues, reduces equipment and transport costs, increases features and functionality and eliminates the complexity of PSTN interconnection for your PBX, you have a sizeable competitive edge.
By using an industry-accepted standard for connecting with customer premises equipment, service providers can offer higher quality services with advanced features tailored to IP PBX users. They can also forge relationships with IP PBX vendors based on this interconnectivity, which can go a long way toward winning customers and establishing new relationships with the various distribution channel entities, including interconnects, system integrators and VARs.
One of the biggest challenges for value added resellers (VARs), Interconnects and other channel partners tasked with installing IP PBXs for their customers is the PSTN interconnection. When a VoIP service provider handles the interconnection to the legacy TDM world, and effectively manages the complexity associated with this interconnection, not only are gateways unnecessary at customer locations, but the time-consuming task of custom configuring and troubleshooting such equipment is also eliminated.
According to leading industry market research, revenues and shipments from IP PBX's will dominate the VoIP Market. In fact, a 2006 study by InfoTech predicts that IP PBX line shipments will make up 90% of premises gear shipments by the year 2010.
Yes. Bandwidth.com, Cbeyond Communications, PAETEC and XO Communications currently offer SIP Trunks based on SIPconnect. They offer an integrated voice and broadband Internet service that interfaces directly with an IP PBX via SIP. Products from many companies including Acme Packet, Avaya, Broadsoft, Cisco Systems, Digium, Dialogic Corporation, GENBAND, Ingate, Samsung and Sonus support SIPconnect.
Recommendation is the term given to all SIP Forum technical publications. The SIP Forum does not (itself) define the SIP standard. This is the responsibility of the IETF. However, from time to time, there are areas the IETF SIP working group chairs do not feel should be defined by the IETF, yet still need defined for industry-use. The SIP Forum is the place where this is done at the suggestion of the IETF SIP working group chairs. The resulting documents are called Recommendations by the SIP Forum.
SIPconnect is designed to interface with IP PBXs on a customer premise, while IP centrex services or hosted PBX services are typically designed to remove the need for a premise-based phone system.
SIPconnect requires and builds upon SIP, but the scope of interconnecting an IP PBX to a service provider network is broader than call signaling alone. SIPconnect also addresses higher level issues such as media standards, feature support, billing and security.
How does SIPconnect help or deal with the presence of Network Address Translation in customer networks?
The exact method a service provider uses to establish network connectivity with a customer is beyond the mandate of SIPconnect; however, the recommendation that a PBX register with a service provider network creates the opportunity for dynamically binding a private IP PBX with a routable IP address through most firewalls.
TLS is neither required nor precluded from use in the SIPconnect Interface Specification. Once TLS is more broadly supported, it may be recommended in a future version of SIPconnect.
How does SIPconnect create the option for a service provider to deliver personalized services to users of an IP PBX?
There are two methods prescribed in SIPconnect for conveying the identity of IP PBX users to a service provider. In one method user identity is placed in the “FROM” field of a SIP message and billing account information is derived from the authentication credentials of the main billing account. In the second approach, the “FROM” field identifies the billing account and user identity is provided in the P-Preferred-Identity field specified in RFC 3325.
The need for parent and child users arises from the dual nature of an IP PBX. Service providers need to authenticate an IP PBX as a single logical entity for billing purposes and account level service restrictions. On the other hand, service providers desire to offer personalized services to users of an IP PBX. A parent account is a higher level billing account, and a child account is specific to a single user or telephone number.