VoIP/IPT systems have proliferated to the extent that enterprises want to interconnect multiple IPT islands. When these islands are supported by the same IPT vendor products, then legacy (T1, PRI) trunking can be avoided. However, when two different vendors are involved, it is unlikely that IP trunks can be used for the interconnection since the signaling, management and security functions are probably not compatible. A common example is an enterprise that has islands of Avaya and Cisco IPT systems.
VoIP peering is where two equal VoIP systems/islands interconnect/interoperate using neither legacy signaling nor the PSTN. This will require multiple levels of interoperability/normalization. The Session Initiation Protocol (SIP) is the candidate to support VoIP peering between IPT vendors.
The benefits of VoIP peering between two IPT islands from the same vendor are:
* Ensuring accurate caller ID end-to-end
* Universal Resource Identifiers for the calls
* Global CDR, accounting, call monitoring and operator services
* Monitoring call quality end-to-end
* Enforcing QoS for the call
* Single point of management
* Elimination of PSTN connections within the enterprise
* Better bandwidth utilization over IP trunks vs. T1 and PRI trunks
* Increased call security within the enterprise
* Transparent feature support to the user
* Centralized shared resources like voice mail and IVR
The goals remain the same when the IPT islands are from different vendors. These goals may not be achievable for the interconnection of two different IPT vendor platforms. Further, the VAR will have to learn about the two vendor’s SIP operations before the task is accomplished. Will there be enough revenue to warrant the VAR learning the solutions?
Connecting multiple call managers together means that the signaling system, Session Initiation protocol (SIP) and other supporting protocols MUST be compatible and interoperable without problems. An excellent article written by one of the SIP developers, Henning Schulzrine, "Real-world SIP Interoperability: Still an Elusive Quest", provides an academic view of the interoperability issues.
SIP is the standard (IETF RFC 3261) that is designed to support signaling among IP devices. It has become the foundation for VoIP and IP Telephony signaling for IP phones and trunking to the PSTN. The SIP standard is implemented in many variations that all conform to the RFC 3261 standard, but are not interoperable. This is true for SIP phones and SIP trunks to the PSTN. SIP trunking does exist between call managers from the same vendor. SIP trunking within a vendor’s IPT product line may use SIP. Do not however assume that since SIP is used, that this solution will work with other vendor’s IPT systems.
There is an IETF document that may be worth reviewing, "VoIP SIP Peering Use Cases". These use cases are the most common ones deployed today.
SIP trunking goals and objectives include:
* Standardized approach
* Common header formats
* Transparent feature/function support
* Support of Unified Communications features such as presence and multimedia
* Service delivery for DTMF, multiple codecs, fax, modems etc.
* Security across the trunking interface
* Interface and cross trunk management
* Scalability to encompass the entire enterprise environment
The most likely candidates for interoperability/normalization issues are:
* Voice signaling protocols
* Telephony features
* Voice codecs used
* Security functions
* End-to-end call management
* Voice quality performance reporting
* Calls transiting firewalls
* Call Admission Control (CAC) and bandwidth management
* Call saturation levels
* Single enterprise wide dial plan
There are several possible solutions for interconnecting different IPT vendors, all of which will require some development. The possible solutions include:
* The Cisco Unified Border Element (CUBE) can be deployed between two devices that support the same VoIP protocol (SIP), but do not interwork because of differences in how the protocol is implemented or interpreted.
* In the Avaya Aura approach, SIP is used to set up sessions. All communication sessions begin by interacting with the Avaya Aura Session Manager, which then provides the addresses between which the signaling and media should flow. The architecture behind Aura follows the same deployment model as web and IP based applications. It is centralized architecture based on standards based, loosely coupled components. This architecture is similar to the way network operators use IMS to help scale their IP based communications services.
* A Session Border Controller is a device/appliance used in VoIP networks to control the signaling (SIP, H.323, SCCP...) and the media streams (voice) involved in setting up, conducting, and tearing down telephone calls or other interactive media communications. A SBC is a B2BUA (Back to Back User Agent). The SBC acts as a server for the internal network and as a client to the external network. The SBC also provides:
--Security between networks
--Codec conversion (transcoding, e.g. G.711 to G.729)
--Fax conversion T.38 to T.30 standard and reverse
--DTMF conversion to RFC 2833 and SIP INFO/NOTIFY signaling
--SIP to SIP-TLS over TCP or UDP
* Customized systems/solutions
Even if an enterprise wants to interconnect different IPT islands, there is no real incentive for two different vendors to interoperate. A black box approach, probably from a third party vendor, will be the solution. In the next blog, "VoIP Peering Solution Issues", I will discuss the peering issues in greater depth. I will also provide a list of tests that should be considered for the peering solution.
