SIP Forum Tech WG IP PBX to Service

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: http: //www. sipforum. org Mission § 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 § 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 The TWG is strongly encouraged to not create work product that purports to be a “standard” § 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 Vo. IP-based service provider using 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 B 2 BUA 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: 1. Codec support, packetization intervals, echo, and other media capabilities. 2. Fax and modem transmissions. 3. DTMF tones. 4. Message Waiting Indication information. 5. Conveying traffic priority to the SP to support Qo. S enforcement. 6. Universal set of basic features in an IP PBX to service provider interface. 7. Basic guidelines for interfacing with an IP PBX when NAT or firewalls are on path. 8. 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