subject: The Growth of SIP Trunking Solutions [print this page] With the proliferation of SIP solutions, users can now realize the end-to-end connections between providers and enterprises. The company and the provider side will be referred to as the so-called SIP peers. The SIP peering is implemented through a SIP trunk service. In place of official receipts in the company connect to the SIP Trunk Gateway and SIP provider. This is so centrally ready access to the public telecommunications network. The head office numbers of a company can be mapped with the help of ENUM to SIP domains. This allows a global announcement / availability of SIP participants via the DNS service.
With a new acquisition of a communication system should therefore be taken to ensure that this supports the necessary functions for connection of both access techniques to the public network.
Benefits of SIP trunking
Eliminates the need to purchase a dedicated ISDN gateways allow the public network and the hiring of expensive BRI (Basic Rate Interface) and PRI (Primary Rate Interfaces), In addition, the services more flexible, since the classical rigid ISDN structure (2 channels ( S0), then 30 channels (S2M)) is omitted.
Since the ISDN gateway eliminates the public network, the bandwidth is based only on the individual needs of businesses and no longer available (or affordable) connection capacities in the public network.
The complex conversion between the internal signaling and ISDN / PSTN network is eliminated. This costs both gateway resources and processing time and increases end-to-end response times.
The transition into the public network is no longer on the country location of the entity reduced. The transitions in the public networks can be the SIP provider at each site implemented in the world. This redundancy can be to different service providers to easily deploy NGN networks.
The ITU-T and IETF have in recent years published a number of different specifications that describe the IP peering. Based on the competing standard engines currently developed each service provider's individual specifications of the SIP IP peering interface. In practice, this often leads to interoperability problems and slowed the migration to SIP as a replacement for traditional TDM connections. Also delayed by the previous lack of standardization of SIP trunking and the acceptance of this solution and provides significant uncertainties in the procurement and implementation. Usually require the most SIP trunking solutions that SIP components can be adjusted on the enterprise side of the individual configurations of the relevant SIP SIP provider. Not enough to deliver some of their VoIP VoIP manufacturer enterprise solutions provider with up to 50 profiles for some SIP providers are also different SIP profiles. Their use depends on the specific hardware and software equipment of the provider at each installation site. Moreover, with the result that the respective SIP parameters must be cared for each patch or release upgrade. Hence it is in practice always unexpected problems with the SIP trunking. The path from Customer A to Customer B uses more components whose interaction no one can guarantee 100% TIG
For the standardization of SIP trunking, it is therefore necessary to create a solid interface with the parameters necessary for this. This exact problem trying the SIP Forum to get a grip. This association published in January 2008 with the SIPconnect Technical Recommendation (version 1.0) is an important milestone in the standardization of interfaces. The paper is based on the following guidelines and indicate:
a peering reference architecture, based on the now with the service providers and users typically installed network elements.
basic protocol functions (and protocol options) that must be supported by both the ISP and the customer.
Standard procedures for the negotiation of protocol mechanisms - options and extensions, and specifies the exchange of information between the endpoints.
clear log messages and options, if several competing standards and options available.
an authentication system to improve the safety of users and as a basis for the implementation of billing systems.
Performance criteria and mechanisms to negotiate the codec, packet interval and to negotiate Funct zones and skills.
Mechanisms for transmission of fax and modem transmissions.
minimum requirements and methods for dealing with echo cancellation.
Minimum requirements for the transport of DTMF tones.
fundamental characteristics of traffic prioritization (QoS) in the networks of service providers.
Guidelines for dealing with Network Address Translation (NAT) components.
a basic security model based on the currently available authentication and authorization standards.
Meanwhile, the SIPconnect Technical Recommendation (version 1.1) were published and demonstrated at several public events and measuring the benefits of a single peering interface. As SIPconnect is driven primarily by U.S. companies and providers, one notices in Europe hardly something of a SIP trunking in the standardization area. This must until further notice the SIP interface to the specific (sometimes obscure), the provider needs to be adjusted.
