Login Form

Lost Password?

No account yet? Register


SIP internet drafts statistics

  • 42 SIP related internet drafts (IETF).
  • 0 new and updated drafts posted in the last 14 days.

Read more ...

Home arrow ACTIVITIES arrow Technical WG arrow SIPconnect TG
SIPconnect Task Group Print E-mail



Chair: Richard Shockey (richard "at" shockey dot us)
Mailing List:
Currently using the Tech WG list ( This e-mail address is being protected from spam bots, you need JavaScript enabled to view it ) [Subscribe] [Archive]
Approved Effective: 30 June 2005
Current Documents: SIPconnect Technical Recommendation Documents and Presentations
  Visit the SIPconnect Page HERE!

SIPconnect logo

Task Group Charter

The deployment of IP PBXs among enterprises of all sizes is increasing rapidly. According to leading industry market research, including studies conducted by Frost & Sullivan, Synergy Research and CompTIA, IP PBX revenues are expected to surpass traditional TDM-based PBXs for the first time during 2005. Additionally, SIP, or Session Initiation Protocol, is fast becoming the dominant industry standard. Many new IP PBXs support SIP phones and SIP routing between one or more PBXs. Deployment of SIP infrastructure by service providers is also increasing, driven by the demand for commercial VoIP offerings. The result of these parallel deployments is an emerging need for direct IP peering between SIP-enabled IP PBXs and SIP-enabled service providers.

Existing SIP standards define a comprehensive set of building blocks that are currently used to achieve basic interconnection between SIP-enabled IP PBX systems and a service provider’s SIP-enabled network. While such an interconnection allows the service provider to build service offerings for traditional PSTN call origination and termination, implementation details vary considerably among PBX vendors, and support for the delivery of personalized services to end-users of the IP PBX is typically limited.

The SIPconnect Task Group is chartered to address these limitations. This task group will propose one or more SIP Forum Recommendations that define the protocol support, implementation rules, and features required for predictable interoperability between SIP-enabled IP PBXs and SIP-enabled VoIP service providers.



This Task Group is currently operational and approved by the SIP Forum.  Activities are ongoing and take place on conference calls and the TWG mailing list ( This e-mail address is being protected from spam bots, you need JavaScript enabled to view it ).


Expected Outputs

This task group will produce one or more SIP Forum recommendations that define a common set of implementation rules for implementers who desire to interface an IP PBX with a SIP-enabled service provider. The recommendation(s) will specify which standards must be supported, provide precise guidance in the areas where the standards leave multiple options, supplement functionality gaps in existing protocols, and identify a baseline set of features that should be common to an IP PBX to service provider interface. Such guidelines will not preclude the implementation of additional SIP functionality and primitives that do not conflict with the common implementation rules of the recommendation(s).

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. At a high level, the interface to the service provider utilizes a combination of SIP signaling and media transport using RTP. The interface to end-users of the IP PBX can be SIP or any other protocol capable of establishing a voice session (such as SCCP, 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 are:

  • Define a reference architecture that sets forth the common network elements necessary for service provider to IP PBX peering.
  • 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.
  • Specify standard methods for negotiating protocols, protocol extensions, and exchanging capability information between endpoints.
  • Specify consensus methods of formulating protocol messages where multiple options exist.
  • Define a practical method of authentication that provides adequate user security and billing traceability to a single identity.  This method must preserve the optional identification of users and endpoints ‘behind’ an IPX.
  • Specify minimum standards and consensus methods for CODEC support, packetization intervals, and capability negotiation.
  • Specify a consensus method for handling fax and modem transmissions.
  • Specify minimum standards and consensus methods method for handling handle echo cancellation.
  • Specify a consensus method for transporting DTMF tones.
  • Specify a consensus method for conveying Message Waiting Indication information.
  • Specify a consensus method for conveying traffic priority to the service provider to support proper QoS enforcement.
  • Specify a universal set of basic features that should be embodied in an IP PBX to service provider interface.
  • Specify a basic set of guidelines for interfacing with an IP PBX when Network Address Translation and/or packet filtering devices are utilized in the communications path. The reference architecture should contemplate NAT and firewall related challenges and define methods to minimize their impact.
  • Define a basic 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.

Areas that are explicitly beyond the scope of the Task Group are:

  • Layer 3 network design and QoS considerations, including per-call QoS mechanisms such as RSVP
  • Element management, network management, and OSS specifications




See complete list...


April 2014
30311 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 1 2 3