SIP
Almost every enterprise owns voice communications platforms from more than one major vendor, and even if you standardize on a single IP-PBX vendor today, your company could acquire another firm that uses a different vendor, and you’ll be called upon to try and integrate the two systems. Or your vendor could merge with another vendor and product lines could be rationalized in ways that threaten to strand your investment.
The acceptance of the Session Initiation Protocol (SIP) as the universally-acknowledged standard for call/communications setup has led to expectations, or at least hopes, that multiple vendors’ PBX systems will be able to work together while preserving extensive functionality. This goal proved elusive in the TDM world, where the QSIG standard aimed to provide this ability but was rarely implemented to its full extent.
Today, standards-compliant SIP phones can connect, in an interoperable way, to just about all major IP-PBX platforms—with limited functionality. That’s because the Internet Engineering Task Force (IETF), which created and governs the SIP standards, consciously decided to build SIP around the idea of “primitives,” i.e., basic functions that can be combined to create more advanced features like call park and pickup. Cullen Jennings, distinguished engineer at Cisco and IETF Real Time Applications Area Director, explained: “It’s not that SIP vendors don’t have call park and pickup, it’s that there’s a ton of different ways that you might be able to do call park and pickup in SIP, and no specific one was really specified or worked out [within the standard]. Different vendors went off and did different things in different directions.”
To get a sense of the scale of the problem, consider one of the newer IETF-sanctioned efforts around SIP interoperability: A working group called BLISS
(Basic Level of Interoperability for SIP Services). The name says it all, and the working group’s charter spells out the problem:
SIP's approach to supporting more advanced features and applications has been to specify a number of primitive operations, including refer, dialog replacement and joining, and event packages, and then to allow those primitives to be combined in many ways to realize different features. This approach avoids the need for standardized definitions of a feature, which can severely limit innovation and broad applicability.
While this approach brings great flexibility and generality, it complicates interoperability. Without any kind of standardized definition of a particular feature, each implementation creates its own definition and corresponding set of call flows and primitives used to realize this feature. In practice, this has resulted in a poor track record for interoperability for more advanced features which make assumptions on supported SIP extensions and behaviors from other elements.
The problem is exacerbated by the desire for these features to work across many types of SIP endpoints, including SIP hardphones, softphones, and gateways to the PSTN and other VoIP networks including non-centralized environments, and for the desire to work across domain boundaries and to interwork with the PSTN, when applicable.
The BLISS working group narrowed its initial focus to four features, whose implementation the group plans to have submitted as IETF Best Current Practices (BCPs) by the end of this year:
From the BLISS website, here’s an example of the “Problem Statement” for interoperability in the feature of Call Park:
Service/Feature may be implemented/provided Partially on UA [user agent, i.e., the end station, typically the phone] Partially on server Fully on UA Fully on server Service/Feature may be implemented/provided Using non-signalling channel (DTMF etc.) Using signalling channel (SIP methods, ) Using specific call-flows Service/Feature may have various interpretations. When service/feature is provided by a server, UA might assume one approach when
the server is providing a service in another.
By way of illustration:
Call park requires some kind of 'indication' to be emitted by the phone that signals a park request. There are many ways to do this:
1. …the phone emits a DTMF feature code (rfc2833) on the call; this is captured by the PBX, interpreted as an invocation request, mapped to the park feature. The call is then parked at the PBX, and can be picked up elsewhere.
2. Similar to 1, except invocation is done via some kind of signaling channel mechanism (INFO, proprietary methods, etc.)
3. Phone is a bit more intelligent, and knows the user wants to invoke Park. So, it REFERs to the park server, having it replace its call with the participant
4. conference mechanism; park is implemented by viewing the park server as a conference bridge. So, the invoking UA [user agent] creates an ad-hoc conference bridge, transfers the correspondent into it.
and there are more.
Interop failures are anticipated when a UA assumes one mechanism, and the PBX and other phones assume different ones, we have no hope of interop.
That’s the theoretical problem, and the Call Park example illustrates just one feature on one leg of the network. SIP is also the core of the standards that will connect call control servers to other servers for applications such as messaging and contact centers; and the associated SIMPLE (SIP for Instant Messaging and Presence-Leveraging Extensions) will be the key in any attempts to standardize presence federation (which we’ll discuss later).
Cullen Jennings explains why, ultimately, standards don’t necessarily equal interoperability: “Fundamentally we’ve got really a large number of RFCs around SIP, of doing different features and extensions to it, and vendors are going to pick and choose some set of those that they implement. Certainly nobody’s going to implement all of them. And nobody should implement all of them. [They’ll be] trying to pick the ones that are relevant and meet their customer needs.
“So it’s really hard from an IETF point of view to say, The following things work or don’t work. What we can say is, Well, if you want to do X, we have a standard to do it. And what your vendor may or may not implement, your mileage may vary.”
So, bottom line: A vendor’s claim to be “SIP-compliant” for a given feature probably will never represent a guarantee that this particular feature will be able to be invoked from a business desk phone built by that vendor, talking to a platform built by another vendor, even if that other vendor also claims “SIP compliance” for the same feature. Note that this doesn’t mean they won’t interoperate; it means they won’t necessarily interoperate.
On the other hand, if the efforts of the BLISS working group were to gain momentum and general acceptance, then if two vendors both claimed that their implementation of a given feature complied with the BLISS Best Current Practice for that feature, in theory that ought to mean you could trust they’d interoperate. Or comparable “best practices” efforts from groups like the SIP Forum could also provide similar assurance. The question is whether we’ll ever get to that point. We’re definitely not there yet.
[You can discuss/comment on this article in the Comments section
here.]
