Thursday, February 10, 2005
SIPconnect , direct IP peering and what is missing
The SIPconnect Interface Specification launched by Cbeyond Communications in 2004 with support from Avaya, BroadSoft, Centrepoint Technologies, Cisco Systems, and Mitel is a standards-based method of interconnection between IP PBXs and VoIP service provider networks. It specifies a reference architecture, required protocols and features, and implementation rules necessary for seamless peering between IP PBXs and VoIP service providers.
Of course this is a good start to provide IP-based connectivity, but the scope of the architecture is quite limited, namely to the IP-based User-Network-Interface (UNI) between an IP PBX and a VoIP service provider. The achitecture consists of the IP PBX, the Call Control Server (CCS) and the Media Server (MS) of the VoIP Service provider, and a Trunking Gateway (TGW) to the PSTN. So basically a company running an IP PBX may only interface with a VoIP service provider saving the own gateway to the PSTN. All calls out of the IP PBX are routed via the VoIP service provider.
There is an additional element, but only optional (Henry ;-) - the unfamous Session Border Controller (SBC).
What is missing are two major points:
1. How VoIP service providers interconnect (the Network-Network-Interface NNI) and the routing mechanisms to achieve this (e.g. carrier/infrastucture ENUM). But this may be any issue for VoIP service provides only. The SIP Forum Service Providers Working Group is currently looking after these issues.
2. and even more important, the answer to the question why IP PBX need VoIP service providers to peer with each other on the Internet.
At the SIPconnect home page in the FAQ section it is stated under the topic:
How does SIPconnect benefit business users?
Business customers are the end users who will ultimately benefit from direct IP peering.
Businesses that take advantage of SIPconnect where their IP PBX peers directly with their communications service provider eliminate the need for expensive TDM gateways, and increase the efficiency with which they use local access facilities. They also increase their opportunity to purchase enhanced applications from service providers and can more easily extend the functionality of their IP PBX across service provider networks.
I personally understand the term "direct IP peering" in such a way that IP PBX connected to the Internet are peering directly with each other and not with and via VoIP services providers.
The best and simplest way to achieve this is the usage of ENUM to peer directly between IP PBX. This requires only the addition of an ENUM client into the PBX Software and the reachability of the IP PBX via a public SIP URI. Examples are the open source Asterisk and the SIP Express Router (SER) from iptel.org. An animated example scenario is contained in my presentation (slide 10) given at the Domain Pulse event.
This does not prevent IP PBX to use either their own gateways to the PSTN or the IP-based peering as defined by SIPconnect if a E.164 number is not found in ENUM.
The approach is basically the following:
1. An IP PBX is first querying ENUM for the number dialled. If an entry is found in ENUM, the other party (other IP PBX or residential user) is contacted directly.
2. If no entry is found, the call is forwarded to the VoIP service provider.
3. The VoIP service provider first tries to find another VoIP service provder hosting the number dialled, e.g. by querying Infrastructure ENUM. Only of this also fails, the call is routed via the PSTN.
The basic idea is to keep the call on IP for all end-points that can be reached on IP, not only for saving money, but even more important to improve QoS and enable all additional features possible with SIP-SIP communication.
Of course this is a good start to provide IP-based connectivity, but the scope of the architecture is quite limited, namely to the IP-based User-Network-Interface (UNI) between an IP PBX and a VoIP service provider. The achitecture consists of the IP PBX, the Call Control Server (CCS) and the Media Server (MS) of the VoIP Service provider, and a Trunking Gateway (TGW) to the PSTN. So basically a company running an IP PBX may only interface with a VoIP service provider saving the own gateway to the PSTN. All calls out of the IP PBX are routed via the VoIP service provider.
There is an additional element, but only optional (Henry ;-) - the unfamous Session Border Controller (SBC).
What is missing are two major points:
1. How VoIP service providers interconnect (the Network-Network-Interface NNI) and the routing mechanisms to achieve this (e.g. carrier/infrastucture ENUM). But this may be any issue for VoIP service provides only. The SIP Forum Service Providers Working Group is currently looking after these issues.
2. and even more important, the answer to the question why IP PBX need VoIP service providers to peer with each other on the Internet.
At the SIPconnect home page in the FAQ section it is stated under the topic:
How does SIPconnect benefit business users?
Business customers are the end users who will ultimately benefit from direct IP peering.
Businesses that take advantage of SIPconnect where their IP PBX peers directly with their communications service provider eliminate the need for expensive TDM gateways, and increase the efficiency with which they use local access facilities. They also increase their opportunity to purchase enhanced applications from service providers and can more easily extend the functionality of their IP PBX across service provider networks.
I personally understand the term "direct IP peering" in such a way that IP PBX connected to the Internet are peering directly with each other and not with and via VoIP services providers.
The best and simplest way to achieve this is the usage of ENUM to peer directly between IP PBX. This requires only the addition of an ENUM client into the PBX Software and the reachability of the IP PBX via a public SIP URI. Examples are the open source Asterisk and the SIP Express Router (SER) from iptel.org. An animated example scenario is contained in my presentation (slide 10) given at the Domain Pulse event.
This does not prevent IP PBX to use either their own gateways to the PSTN or the IP-based peering as defined by SIPconnect if a E.164 number is not found in ENUM.
The approach is basically the following:
1. An IP PBX is first querying ENUM for the number dialled. If an entry is found in ENUM, the other party (other IP PBX or residential user) is contacted directly.
2. If no entry is found, the call is forwarded to the VoIP service provider.
3. The VoIP service provider first tries to find another VoIP service provder hosting the number dialled, e.g. by querying Infrastructure ENUM. Only of this also fails, the call is routed via the PSTN.
The basic idea is to keep the call on IP for all end-points that can be reached on IP, not only for saving money, but even more important to improve QoS and enable all additional features possible with SIP-SIP communication.
Comments:
Post a Comment
