SIP Forum Tech WG:
IP PBX to Service Provider
Interoperability Task Group
Rohan Mahy
Tech WG chair
rohan@ekabal.com
Richard Shockey
Task Group chair
rich.shockey@neustar.biz
SIP Forum Introduction
Non-profit industry trade organization:
Mission
http://www.sipforum.org
 Advance the adoption of products and services based on the Session Initiation Protocol.
To accomplish this mission, the Forum advances interoperability by:
 Holding live interoperability test events;
 Defining and creating operational compliance tests.
− Creates white papers, implementation guides, recommendations
− Creates technical documents dealing with issues that fall outside the scope of the IETF or other relevant
standards bodies
− Builds awareness about what existing and emerging SIP-compliant technologies can do for users and customers
Open to anyone
 Free individual members (“participant”)
 Paying corporate members (“full”)
Activities performed in working groups




Marketing working group
Service provider working group
Test event working group
Technical working group
2
Technical Working Group
Overview
To produce technical documents, software, training and not-for-profit
services for and using SIP-based technology

Purpose: to inform, guide and stimulate the use and implementation of SIP
The TWG is strongly encouraged to not create work product that purports
to be a “standard”


Strive to complement the activities of other standards bodies as may be guided by regular contact
with them
Standards-like documents should only be created when there is a consensus among these other
bodies in favor of the SIP Forum creating a specific, narrowly-defined standards-like document
Tech WG works via Task Groups
 Formed to tackle a specific problem area
 Transitory, or permanent as required
 Should create usable outputs
− Recommendations
− IETF-like process for outputs
•
Rough consensus & running code
 Volunteers do the work
− Task group lead
− Contributors
3
Current Task Groups
“IP PBX” to Service Provider interconnect
 PBX to service provider SIP interconnect
 Consider, modify, or replace SIPconnect
( http://www.sipconnect.info )
 Taking concrete proposals now for interface specs and requirements
 Resulting recommendation will not prevent additional functionality
IP Phones / IP PBX (proposed)
 Describe “feature packs” to make it easier for customers to find
phones with specific features
 Provide examples of service like sipping-service-examples
 Possible home for device configuration work
4
IP PBX to SP:
Promotes SIP “Trunking”
Greater network and cost efficiencies
•
Eliminate need for expensive TDM gateways
Higher quality of service
•
Reduce voice latency with TDM conversion no longer needed (TDM gateway
removed)
Increased features and functionality
•
•
•
•
•
Access to Direct Inward Dialing (DID) capabilities to smaller size customer
Seamless calling with Internet-based SIP endpoints
End-to-End IP Feature Transparency
Opportunity to purchase enhanced applications from service providers
Access Technology Agnostic
5
IP PBX to SP:
Current State of Interoperability
There is not currently a well-defined, standard operational approach for interfacing
an IP PBX with a VoIP-based service provider using SIP.
SIP Implementations vary greatly among different service providers and IP IPBXs
•
•
SIP is currently defined in ~28 RFCs and ~ 170 IETF Drafts
SIP is also very flexible. Not every vendor implements consistently.
Only basic interoperability is commonly possible
•
•
•
‘basic trunking’ or ‘proxy to proxy’ routing
‘single user account’ that works with a single user ITSP service.
Both models have considerable drawbacks
6
IP PBX to SP:
What Works Today?
Single User Accounts
•
Most PBXs can act as a B2BUA and derive basic service from an ITSP using a single user
identity.
•
This model has many limitations, such as:
•
•
•
Individual user features are not possible
Basic Trunking
•
•
Basic ‘proxy to proxy’ routing between an IP PBX and service provider
This model also has many limitations, such as:
•
•
•
•
DID is not supported due to single outbound calling identity
No easy model for billing traceability, unless per call authentication is used
No support for dynamic IP address assignment (SBCs need a REGISTER)
Individual user identity is generally not conveyed
What’s Missing? Single responsible party with multiple identities
7
Discussion of Group Scope
Output
Recommendation(s) defining existing specs you must implement to minimally comply,
to interface between an IP PBX and an ITSP using SIP and RTP/RTCP
Definition of what we mean by an IP PBX:
(ex: could be traditional PBX or collection of SIP stuff, could use other protocols inside)
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.
8
Discussion of Group Scope
Some of the specific objectives of the task group are:
•
•
•
•
•
•
Define a reference architecture describing common network elements for SP 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 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.
Scope of minimum/default recommended features:
•
•
•
•
•
•
•
•
Codec support, packetization intervals, echo, and other media capabilities.
Fax and modem transmissions.
DTMF tones.
Message Waiting Indication information.
Conveying traffic priority to the SP to support QoS enforcement.
Universal set of basic features in an IP PBX to service provider interface.
Basic guidelines for interfacing with an IP PBX when NAT or firewalls are on path.
Basic security model based on existing standards to authenticate and authorize utilization
of the service provider’s resources by an IP PBX. Also, ensure confidentiality and
authenticity between the service provider and IP PBX.
9
How to get involved
Join the SIP Forum Tech WG mailing list: techwg@sipforum.org

List Info (to Subscribe and view Archives):
− http://sipforum.org/mailman/listinfo/techwg
Get involved with a Task Group



Announced on Tech WG mailing list
All members (individual and full) can participate
Full members can set priorities of which Task Groups are most needed
Contacts
 IP PBX to SP interconnect Task Group: Richard Shockey
− rich.shockey@neustar.biz
 Tech WG chair: Rohan Mahy
− rohan@ekabal.com
 Test event chair: Robert Sparks
− rjs@nostrum.com
 SIP Forum Board of Directors
− board@sipforum.org
10