Home ▸ Activities ▸ Technical WG Overview and Charter ▸ SIPconnect 2.0 Task Group

SIPconnect 2.0 Task Group

Chair: Marc Robins, SIP Forum Managing Director
Task Group Editors: To Be Assigned
Mailing List: Currently using the Tech WG list (techwg@sipforum.org) [Subscribe] [Archive]
Approved Effective: 16 July 2014
Current SIPconnect 2.0 Document (download link)
Archived Documents (SIPconnect v.1.1 and SIPconnect v.1.0)
Visit the SIPconnect Overview Page

SIPconnect 2.0 Task Group Charter

The SIPconnect Technical Recommendation is an important industry initiative that builds on existing IETF standards to define a method for interconnection between IP PBXs and VoIP service provider networks, and specifies a reference architecture, required protocols and features, and implementation rules necessary for seamless IP peering between IP PBXs and VoIP service providers.

The SIPconnect Technical Recommendation Version 2.0 has been formally ratified by the SIP Forum (as of December, 2016).

In addition the SIP Forum has developed a SIPconnect Certification Testing Program. Whilst SIPconnect 1.1 is becoming widely implemented within the industry the SIP Forum recognizes that there are areas in which the specification required further work to keep up to date with new requirements and trends. The SIPconnect 2.0 Task Group was therefore chartered to define these new requirements and the protocol support, implementation rules, and features required to fulfill the requirements and to enable interoperability between SIP-enabled IP-PBXs, SBC’s and SIP-enabled service providers.

Operations

This Task Group is not currently operational, as the Group has achieved its mission. There are no currently scheduled activities.

Task Group Output

This task group produced a SIP Forum SIPconnect 2.0 recommendation that defines a common set of implementation rules for implementers who desire to interface an IP PBX with a SIP-enabled service provider. The recommendation specifies which standards must be supported, provides precise guidance in the areas where the standards leave multiple options, supplements functionality gaps in existing protocols, and identifies a baseline set of features that should be common to an IP PBX to service provider interface. Such guidelines do not preclude the implementation of additional SIP functionality and primitives that do not conflict with the common implementation rules of the recommendation.

For purposes of this task group a SIP-enabled IP PBX is defined as a private, multi-user communications system that supports a clearly-defined baseline set of SIP standards along with other (optional) protocols. The task group took account of the role SBC’s on both the enterprise IP-PBX side and the service provider side. At a high level, the interface to the service provider utilizes a combination of SIP signaling and media transport using RTP/SRTP. The interface to end-users of the IP PBX can be SIP or any other protocol capable of establishing a voice session (such as WebRTC, H.323, directly connected analog “black phone”, etc.) While vendor implementation choices vary (i.e. the PBX may be comprised of multiple servers and SIP endpoints), the SIP signaling exchanged with a service provider must be traceable to a single account identity, which may be a separate identity from users of the PBX. In this respect, the PBX is to be viewed logically as a single SIP user agent for the purposes of the interface specification. This does not preclude, however, the capability for media to be exchanged directly between the service provider and PBX-controlled IP endpoints such as IP phones and media terminal adaptors.

Some of the specific objectives of the task group were to:

Update the reference architecture that sets forth the common network elements necessary for service provider to IP PBX peering (E.g. to include SBC’s).
Specify the basic protocols (and protocol extensions) that must be supported by each element of the reference architecture.
Specify the exact RFCs or other existing standards associated with these protocols that must or should be supported by each element of the reference architecture.
Update the security model based on existing standards to authenticate and authorize utilization of the service provider’s resources by an IP PBX. The security model should also define methods for ensuring the confidentiality and authenticity of messages exchanged between the service provider and IP PBX.
Specify the consensus method for supporting IPV6 and IPV4/6 Dual Stack components within the reference architecture.
Specify the consensus method for supporting secure media (SRTP).
Specify the consensus method for supporting Video enabled devices.
Specify the consensus method for supporting emergency calling (NG911/NG112) and the transport of location information.