SPs focused on deploying trunking services know that the number of endpoints accessi-ble with the trunks directly impacts the potential market acceptance of the trunking offering. Generally, when competing with TDM trunks that offer connectivity to 100 per-cent of valid, phone numbers, there is no alternative for a SP that offers SIP trunks for
Updates bill and billing flags to indicate usage of features.
Customer Database
Enhanced Services Server
Call Agent B Call Agent A
Call Agents usually invoke Enhanced Services Servers in real time by passing SIP messaging up to the server, which then manipulates and forwards the messages.
IP Network
IP Network
1. Interacts with Call Agents to determine if an Enhanced Feature needs to be invoked
2. Depending on the features, the call signaling may be adjusted in real time to enable the feature
3. Enhanced Services often need to interact with other Enhanced Services
Figure 5-6 Features and Interconnects of a SP Enhanced Services Server
PSTN access but to also offer connectivity to 100 percent of phone numbers. Of the fea-tures of the PSTN, wide accessibility with a universal routing plan (for example, E.164 phone numbers) is the most important feature. Without this, the phone network would have splintered into a set of incompatible networks that would have required end users to maintain different devices on each network. This, for example, is the case and problem with most two-way radio network and is a major reason that they are not more widely deployed. The only other network with the same level of interconnectivity as the PSTN, and as such with the same level of success, is the Internet. On the Internet, any address entered should result in a path to the endpoint. This same expectation exists in the area of SIP trunking.
One way that an SP can ensure that it is connected to the largest number of endpoints at the lowest cost is by exchanging traffic with other SPs via a peering SBC.
A peering SBC, unlike an edge SBC, is focused on connections to a smaller number of
“peer” SPs. The trust relationship with these SPs is different than the trust relationship between SPs and customers. Because the peered SPs can be both a customer, who pro-vides the SP revenue in exchange for terminating minutes and vendors who charge the SP for terminating minutes, the trust relationship is more complex than traditional cus-tomer/vendor relationships that exist with connections to end customers via the edge SBCs. Because of this complex trust relationship, there needs to be security in place, but it is also much more likely that the two SPs will use a fully routable Internet-based IP address space for the connection, whereas with an edge SBCs, this is much less likely.
One aspect of security that is often different than with customers is contractual security. This is security derived from the legal contract that exists between the peered SPs. These contracts can require the SP who is at fault for malicious activity, whether under its control or not, to be liable to the other SP, if any damages result. Though these contracts might not practically provide any additional security, they do exist.
SPs that offer SIP trunks generally peer directly with other SPs (for example, two large SPs such as Verizon and British Telecom) or via a peering service, such as XConnect that offers connectivity to a large number of peers who have connectivity to a larger number of PSTN locations at low cost. When an SP needs to complete a call to a phone number that it does not own, it needs to send the call on a route to get to the terminating provider. However, due to the complex series of agreements in the area of peering net-works, there is no definitive logic that dictates specifically how each call will be logically routed (routed via TDM versus IP, and so on).
One aspect that is distinct between Internet peering and SIP trunk peering is that with SIP trunk peering all traffic between SPs is measured and compensated for on a per-call basis. With Internet traffic exchange peering, traffic is usually exchanged at no cost between SPs without detailed examination of the specific destination of each traffic flow.
Peering SBCs are usually deployed at shared central locations, such as large shared data center facilities. These shared facilities enable for the peering of traffic across a similar medium. This is usually done via an Ethernet connection between two providers. Each provider generally has its own peering SBC, and as such, the number of SBCs that a par-ticular call traverses from start to finish can be very large.
Chapter 5: Components of SIP Trunks 73
Another important role of peering SBCs is to ensure that traffic that is both originated and terminated by IP endpoints—when they belong to the same SP—is not converted into TDM traffic unless required. (That is, if a call is tagged for Legal Intercept,
conversion to TDM may be required.) This direct routing of calls over the IP link between customers of an SP is not always the method used to connect customers but is the ideal scenario. As SPs peer their SBCs and generate and terminate IP traffic, there is no reason that the traffic between two IP PBXs connected to two different SIP trunking networks from different but peered SPs should not stay IP end to end. Figure 5-7 shows how these connections occur most often today with a transition and interconnect over the PSTN network as they are converted to TDM traffic. However, the future deployment as connections over an end-to-end IP network is becoming more prevalent.
Within the next ten years, the end-to-end IP connection will become the dominant means for interconnecting real-time IP traffic as described. The intermediate steps of conversion to TDM traffic occurs less frequently and provides no benefit in an all IP network. When traffic between SPs is maintained as all IP, the overall interconnect cost is lower, and the variety of traffic that can be exchanged, such a wideband audio and video, are more extensive than with TDM-based interconnects.
In summary, a peering SBC provides the essential role today of enabling the SP to inter-connect to each other, ensuring that all PSTN destinations are inter-connected when offering a
Enterprise Domain 1
Narrowband Voice to Rich-Media
Interconnect Before all IP Peering SBC
After all IP Peering SBC
Enterprise Domain 2
Enterprise Domain 1 Enterprise Domain 2
SP VoIP
Figure 5-7 Before and After an all IP Connection End to End
SIP trunk for PSTN access service. In the future, this will play an essential role as more and more traffic becomes IP end to end between customers.
The features and interconnects of a SP peering SBC are shown in Figure 5-8.