No. CSRP operators run it on their own commodity Linux servers.
However, several CSRP operators offer value-added hosted switch platform products built on top of it.
No. CSRP cannot be used to provide hosted PBX or "Class 5" type services, nor to provide applications such as calling card, hosted IVR, etc.
CSRP is a specialised "Class 4" network element. The aim of the product is to do one thing–trunk routing–and do it really well.
Not at this time. However, it is planned for the future.
In the meantime, please contact us to obtain a fully featured demo installation for your evaluation.
Pricing and support are charged on a recurring basis in a unified monthly payment, eliminating the need for up-front outlays. Discounts of 7.5% and 12% respectively are available for quarterly and annual prepayment.
CSRP is deployed in two flavours:
CSRP-SP is licenced and supported in incremental units called "silos". A silo is a service delivery cluster of servers and their redundant failover mates, broken out into the customer's desired host topology, associated for the purpose of effectuating service in a particular POP. Most installations of CSRP-SP fit into the definition of a single silo.
For CSRP-SP, charges are strictly month-to-month, so there is no contract of predetermined duration required to licence CSRP.
The CSRP-P pricing matrix is more complex, incorporating both a base silo cost and a certain number of tenant licences.
There is no limit to the number of routes that can be loaded into any of CSRP's routing tables, subject to practical limits such as disk storage.
Routing lookups are engineered to perform in the same time complexity whether a routing table has one entry or many billions.
In CSRP vernacular, jurisdictions are known as Regions and the prefixes that determine them as Region Codes. Routes are typed as "intra"-regional, "inter"-regional, or undefined (indeterminate).
Yes. CSRP can rate CDRs in real time, but use of its rating engine is not compulsory.
Yes. CSRP can issue number portability queries via SIP redirects. LRN caching is also supported.
This depends largely on call volume; specifically, it depends mainly the rate at which calls are set up, rather than the absolute number of concurrent calls running through the system at any given time.
Low-volume installations serving smaller numbers of retail SIP trunking customers and "conversational" traffic can run on one host, and most CSRP customers run single-host installations (with a redundant second host).
We recommend that larger installations processing wholesale volumes of traffic separate the proxy and database services onto separate hosts. The exact deployment topology will vary according to other needs, such as RTP relay. Highly overprovisioned deployments can require three or more active servers.
Please contact us for an answer suited to your particular needs.
CSRP is designed to run on widely available, inexpensive commodity hardware and its virtual (cloud) equivalents.
Exact hardware requirements will vary with your call throughput. For low-throughput workloads found in the retail SIP trunking industry, for example, CSRP can run equally well on practically any kind of server. Large and/or wholesale traffic volumes require more meticulous attention to hardware resources.
Please contact us for an answer suited to your particular needs.
Yes, and many customers do that.
However, it is strongly recommended to run RTP proxies on dedicated ("bare metal") hardware if you are going to provide RTP relay for a nontrivial number of calls (say, more than 50 concurrent calls). If you do not need to perform RTP relay, this is not a concern.
In general, not all virtualisation technologies are the same. Some take advantage of CPU paravirtualisation features to create virtual machines that run increasingly "close to the metal". Others, like OpenVZ, create "containers" that behave like separate hosts, but run in a shared process and memory space.
It is important to take the time to understand the implications of your chosen virtualisation technology on I/O contention. We cannot guarantee that virtualisation outcomes will be comparable or substantially comparable to running on dedicated hardware.
Yes, although we do not recommend this approach for high-throughput installations.
AWS in particular creates complications because public IP addresses are not natively homed on EC2 instances. Our best-practical recommendation is to use a cloud server provider that can give you a public IP directly on the virtual host.
Generally, any SIP endpoint can be connected to CSRP, although it was designed mainly with SIP PBXs and application servers in mind. CSRP operators regularly connect IADs, ATAs and other devices.
On the vendor side, CSRP interoperates with any SIP-speaking Session Border Controller (SBC), softswitch, proxy, or TDM gateway.
In principle, there is no reason why a VoIP phone handset could not be connected as well. However, CSRP is a "Class 4" routing element, so this is probably not very useful.
By default, CSRP does not relay media.
As CSRP is based upon a SIP proxy, normal behaviour is to simply relay SIP messages without regard to the content of encapsulated SDP bodies. The two SIP endpoints on both sides of the CSRP SIP proxy negotiate media relay parameters, including network and transport-layer destination, codec, etc. between themselves and pass media amongst themselves.
CSRP does support RTP relay through bundled components such as rtpproxy and the Sipwise rtpengine. This is commonly done to support topology hiding, NAT traversal and network bridging.
This depends on what is meant by calls. There are two kinds of call limitations:
In a SIP proxy-based architecture like that of CSRP, only the second limitation is significant. The ongoing resource consumption incurred by a call is negligible. As a practical matter, there is no limit to the amount of concurrent calls that can be set up through CSRP per se: on commodity hardware today, the number would be in the millions.
RTP media relay introduces resource consumption and can alter this arithmetic significantly, The Sipwise rtpengine can handle about 12,000 to 15,000 concurrent calls on a single host. Of course, you can deploy as many RTP relay hosts as you like; CSRP's Kamailio will distribute calls among them in a round-robin fashion (with failover).
At the time of this writing, peak CPS performance of 2500 CPS has been demonstrated in a stock CSRP installation, in a relatively low-performance virtual environment. However, this was in an idealised testing environment with simple call scenarios and using a database server with SSDs (Solid State Drives). Actual results will vary, chiefly with the hardware that can be devoted to the database workload.
No. CSRP supports relay of RTP, but cannot substantially alter the RTP that is passed through.
Yes, CSRP has an integrated SIP registrar. Routing of inbound calls to any combination of SIP registrants and static IP destinations is supported.