When a customer sponsors a Feature Request (FR), it is given priority. This allows PortaOne to focus development resources on what is most important to our customers. Once the feature has been developed, it is integrated into the next available Maintenance Release, along with new features developed for other customers. The combined code goes through a rigorous testing process, which ensures that this and all other functionalities work correctly. The single release image is then distributed to all PortaOne customers. Thus the software’s behavior is the same across all platforms, documentation is unified, and support procedures are identical. Compared to creating and maintaining customized software versions for every customer, this is the only feasible approach.
While you allow other customers access to your custom-developed feature, you also receive many more custom-developed features of theirs with every update. This community development approach allows our hundreds of customers from around the world to combine their creative ideas to help make PortaOne’s products the best in the industry.
We release new features with every MR (Maintenance Release) upgrade, using an agile development schedule so that a Maintenance Release is produced every 7 weeks! This ensures that the amount of changes in each new release is not overwhelming. So the update procedure is quick and the learning curve for customers is easy.
In addition to new features, every MR contains enhancements to improve functionality, system stability enhancements, and bug fixes.
Yes, you can. All of our PortaSwitch products share the same core, and so the billing algorithms, database structure and other components are the same.
When upgrading to Procinctus, no reinstallation is necessary. You simply add more servers to the PortaSwitch private cloud and then apply a new configuration using the PortaSwitch Configuration Server GUI. However, when upgrading to Oracularius, the database has to be exported from MySQL and re-imported into Oracle.
A standard PortaSwitch installation can process up to 25 million minutes per month. Note that the real measure of performance is the number of call attempts per second (since each request has to be processed by the system), while the number of processed calls and minutes is derived from it, based on your traffic patterns (average length of call, call success rate, duration of peak hours, etc.).
Thus the value of 25M is an estimate based on industry norms (5 minutes ALOC, 50% ASR and 10-12 “busy” hours per day). The actual number in your system will ultimately be determined by your traffic patterns and other factors such as the hardware used, network connection quality, and so on.
For traffic exceeding 30 million minutes per month, PortaOne offers two high-capacity, fully redundant configurations:
PortaSwitch can handle up to 10,000 concurrent calls. Note that the real measure of performance is the number of call attempts per second (since each request has to be processed by the system), while the number of concurrent calls is derived from it, based on your traffic patterns (average length of call, call success rate, etc.). A system which processes traffic with a lower ASR (average success rate) will handle fewer concurrent calls than an identical system which handles traffic with a better ASR.
Thus the value of 10,000 is an estimate based on industry norms (5 minutes ALOC, 50% ASR). The actual number in your system will ultimately be determined by your traffic patterns and other factors such as the hardware used, network connection quality, and whether or not you proxy the voice stream for a large amount of calls.
PortaSwitch can handle up to 75 call attempts per second on a multi-processor machine.
That means there are no artificial limitations on the number of registered customers, processed calls, or other parameters for the usage that each server (or the system as a whole) can handle. Naturally, the maximum performance capacity of a specific server depends on the hardware deployed, the system configuration, and the complexity of the rating formulas and routing plans used.
If you only require a billing platform, then you can purchase PortaBilling separately. However, PortaSIP relies on PortaBilling to supply the information for authorization, call processing and routing. As a result, PortaSIP cannot be used unless PortaBilling has been purchased.
If you already have an external billing system and wish to keep it for whatever reason, you can still use PortaSwitch in conjunction with it. Simply let PortaSwitch do all the rating and service management (so PortaBilling functions as an OCS for PortaSIP), and then export the CDR/xDR records from PortaSwitch into your own billing system. We already have several large customers using this model.
This really depends on the codec being used and your business model. For normal SIP calls, when the voice traffic flows directly between two endpoints, bandwidth requirements are minimal, as you only need to allocate bandwidth for calls where media are being proxied by PortaSIP. Usually these are calls between individual subscribers using SIP phones, where NAT traversal is required.
You need to install each server using the installation image we provide. So if your servers are equipped with a remote access tool (such as Dell DRAC Enterprise) which allows remote access to the server’s monitor/keyboard and provides a means of virtually connecting the CD/DVD or USB flash drive on your desktop to a server, then the installation can be fully performed remotely. Otherwise, you will need to insert the physical installation DVD or USB into the server and perform installation using the server’s monitor and keyboard.
To use the client application:
- The PortaSwitch GUI is completely web-based. All you need is a computer with a web browser installed. No additional software is required.
To install PortaSwitch:
- The exact number of servers will depend on your PortaSwitch configuration type. A general outline of recommended hardware requirements for each type of server can be found here.
Please note that all servers must:
- Have two network (Gigabit Ethernet) ports and server-grade network adapter(s).
- Be connected to IP KVM (or use a remote access card like Dell DRAC or HP iLO Advanced) and to a remote power switch.
- Have sufficient usable disk space and RAID write cache enabled.
- Have server-type (Xeon or Opteron) CPUs released in 2010 or later, with 64-bit support and a frequency of 2.2GHz or higher.
- During installation, a DVD-ROM optical drive or USB port is required.
PortaOne also provides a Hardware Compatibility Utility to check if your servers meet the necessary requirements. You can download the CD image here, burn it onto a disc, and run the program on any of your server machines. The utility will check all components for compatibility with Oracle Linux.
If you are unsure about what type of hardware to choose, PortaOne’s engineering team will be happy to recommend a shopping list. Contact firstname.lastname@example.org for additional information.
Yes, they can. If your desired language is not already in PortaSwitch, we can provide additional language support for both the web interface and the IVR.
To translate the web interface, you just need to modify the language template (an XML file which we provide) and return it to us. This is a simple matter of adding text strings to an XML file. Once we receive the modified XML file, we will install and update the web interface in your desired language.
The web interface of PortaBilling currently supports the following languages (as of MR 55):
- Chinese Simplified
- Chinese Traditional
- Portuguese Brazilian
IVR for prepaid calling applications is currently available in the following languages:
- Chinese Mandarin
IVRs for IP Centrex applications (error notifications, self-care IVRs, voicemail announcements, etc.) are currently available in the following languages:
To add an IVR in your desired language, the following is necessary:
- Consulting with a native speaker and creating grammar rules;
- Programming the grammar modules;
- Having the prompts recorded by a professional speaker in a studio (usually this represents the largest cost, since speaker and recording studio charges are quite high).
PortaSwitch includes PortaSIP, a class 4 & 5 soft switch that performs most of the functions normally associated with Session Border Controllers, including:
- NAT traversal, STUN / ICE
- Voice/video media proxying
- Hiding network topology
- Prevention of DoS (denial of service) attacks
- Control of call-initiation rate
- Load-balancing via a single “entry point” IP address
- Multi-protocol support (SIP over UDP, SIP over TLS, etc.)
An external SBC is not needed in the majority of cases, unless required by your corporation’s specific network security. For additional information about PortaSIP, visit our website’s product page.
Yes, PortaSwitch has a variety of call center features. In addition to Auto Attendants, PortaSwitch also provides Call Queues and Hunt Groups.
Callers can decide which group they want to reach (e.g. 1 for technical support, 2 for sales, or 3 for accounting). Once the caller makes a selection, PortaSwitch can dial numbers in the group randomly or in a specific order. (For example, you may want all calls going to the technical support team to first reach the junior support group before the senior group).
While PortaSwitch tries to establish the call, end users can be played music, as well as an announcement indicating where they are in the queue.
PortaSwitch does not perform any transcoding. This is, in fact, one of the prerequisites for us to provide you with an unlimited license. PortaSwitch can transport a call using any voice or video codec, as long as it is supported by both endpoints.
Yes, PortaSwitch can process both voice and video calls. Any voice/video codec mutually supported by the endpoints can be used.
Yes. PortaSwitch’s powerful CPE Provisioning module allows service providers to configure a large number of end-user devices (such as desktop IP phones, mobile apps, SIP ATAs, routers, etc.) remotely. On the PortaSwitch side, you create a device profile (preferred codecs, server IP address, etc.) and manage your CPE inventory. Once a profile is created and a specific device is assigned to a customer, PortaSwitch will create an individual configuration file for each phone/device.
When your customers receive an IP phone, they just need to connect to the Internet. The IP phone will then fetch the configuration file online and begin provisioning. If you decide later to change a setting on a single IP phone, or change global settings for all IP phones, you only need to update the profile in PortaSwitch. The IP phones will then fetch the updated configuration file next time they go online.
Currently the provisioning module covers more than 20 vendors (Yealink, Linksys/Cisco, Polycom, Grandstream, etc.) and nearly 100 different CPE models. New vendors/models can be easily added upon request.
PortaSwitch’s real-time routing engine supports the following:
- LCR (Least Cost Routing);
- Policy routing (user assigns preferences for vendors, minimum ASR, sound quality, etc.);
- Individual routing plans (custom routing plans based on vendor preference);
- Fail-over routing (if Carrier A fails, the call will go to Carrier B automatically);
- Adaptive routing (the system monitors ASR, PDD and ALOC for each vendor; if the quality drops below a certain threshold, the system will prevent calls from going to the given vendor for a certain period of time);
- Profit guarantee routing (ignores a route if the termination cost is higher than the amount charged to the customer);
- Load capacity routing (when the load on a connection to a specific carrier nears the maximum capacity, the amount of new call attempts is gradually reduced).
Yes. PortaSwitch comes equipped with a variety of system tools to let you track how many concurrent sessions you have running, how many calls are being dropped, or how the overall system is performing.
Yes. You (the administrator) can give your customers access to PortaBilling’s self-care portal, where they can manage their own lines, extensions, hunt groups, auto attendant IVR, etc.
Yes. Once you purchase PortaSwitch, you can rent out a Virtual Environment (partition) on your server. Your customers can then have access to their own PortaSwitch environment, while paying you a premium for using the service.
There are several companies who have been doing this for many years already. Additional information can be found here.
Yes, it can. With PortaSwitch’s DID Inventory Management feature, you can buy multiple DIDs from a supplier, keep them in an inventory, and assign them to individual phone lines as needed. When someone calls a DID number, the call goes through PortaSwitch and rings on an IP phone on your customer’s end.
DID Inventory supports bulk DID upload (i.e. you purchase a large number of DIDs in advance and then allow your resellers/customers to use some of them) as well as real-time on-demand DID provisioning (i.e. customers request additional DID numbers from a specific area code or country, which are provisioned from external carriers in the background). This way there are no “unused” DIDs in the system, which drastically reduces operating costs.
Yes, PortaSwitch can be configured to display your company logo on every page of the web interface. There are no extra costs associated with this feature.
PortaSwitch is ready for the IPv4 → IPv6 transition. At this moment, PortaSwitch servers use IPv4 addresses on public interfaces (those that customers connect to), due to the fact that the majority of hosting facilities still operate using IPv4 and many users are still using IPv4-only networks. This allows customers on “old” IPv4 networks to continue services as they are used to, while IPv6 customers and networks seamlessly connect to IPv4 addresses via a gateway. On the middle-ware side, PortaSwitch ensures that it properly understands and processes requests which contain IPv4 or IPv6 data. Full support for public IPv6 interfaces will be added in future releases, once there is sufficient penetration of IPv6 into end-user networks.
Class 4 Services:
- Real-time xDR/CDR
- Carrier selection
- Routing policies (Time of day, Priority, etc.)
- E911 emergency services
Class 5 Services:
- Caller name delivery
- Caller ID delivery on call waiting
- Visual MWI
- Customer-originated trace
- Three-way calling
- Distinctive ringing
- Speed calling
- Do not disturb
- Call hold
- Call transfer
- Music on hold
- Local number portability
- NAT traversal functionality
- Secure calls/Voice VPN
- Call waiting, call swap
- Call back last missed call
- Last called number redial
- Speed dial
- Overflow routing
- When busy
- On no answer
Plus many more… For a complete list of the features supported, please see our PortaSIP guide. Note that some features (e.g. the ability to initiate call transfers) depend on the IP phone being used.
Yes. PortaSwitch is an open system, where you are provided with the source code, as well as an XML API and a description of the database model.
An application (such as your own web portal) can easily retrieve and manipulate data using the XML API (SOAP). This allows you to integrate with PortaSwitch using any application running on any operating system and written in any programming language.
Any SIP phone (assuming it is compliant with SIP RFC) should work fine with PortaSwitch, so you are free to choose the vendors that best meet your business and network requirements.
We have done interoperability testing with certain vendors (Cisco, Grandstream, Polycom, Sipura/Linksys, Yealink, etc.) to confirm that their phones work properly with PortaSwitch, and we also use those phones during quality assurance testing for each new release.
PortaSwitch is fully RFC compliant, so it should work with any other SIP RFC compliant carrier equipment. Our customers have successfully connected with vendors using Cisco GWs, Genband (Nextone), Sonus, Acme Packet (Oracle) and other SBCs and gateways.
In order to facilitate a connection to equipment that has certain peculiarities, or which is not 100% RFC compliant, PortaSwitch includes a Service Policies module, which allows SIP dialogs to be adjusted and tweaked per endpoint.
Yes, PortaSwitch can be installed in a virtual container, such as VMWare and Oracle Virtual Box. In fact, the PortaOne development team and QA actively use Oracle Virtual Box environments for development and testing. The question is whether such a set-up makes sense for production deployment.
PortaSwitch already provides a “private cloud” environment where all available "physical" servers are installed with a unified copy of the software – so, essentially, they represent a common pool of resources. Specific application instances are then assigned to run on individual servers in the cloud, and can easily be relocated among the servers.
For the purpose of server consolidation, therefore, this is more efficient than using virtual machines. Let’s say you have a physical server with 2 quad-core CPUs and 16GB of RAM, and you wish to co-allocate the PortaBilling web server and the PortaSIP server on it. If you were to use virtualization, you would end up with two virtual machines. This means that there would be two copies of the operating system (and a full set of all background processes for each) running simultaneously, while each virtual machine would have access only to a portion of the RAM, e.g. 8GB. If you use the PortaBilling configuration management framework, however, PortaSIP and the web server are assigned to the same physical machine, and only one copy of the operating system will be running there, leaving more computing resources available for your applications. Also, the whole 16GB of RAM will be available for applications.
The “Achilles heel” of virtualization is real-time processing: since the hypervisor needs to switch context between multiple virtual machines, there is no guaranteed real-time processing capacity for them. This means that there may be some tiny delays in execution. A delay of 50 milliseconds or so is not even noticeable for a web application; but for an application which does media processing, this would result in a significant degradation in sound quality.
Another popular use of virtualization is for increasing service reliability and protecting against hardware failures. In the case of PortaSwitch, however, clustering and high-availability are already built in. Plus, by using a “native” PortaBilling or PortaSIP cluster, you enable not just disaster recovery, but also load-sharing.
So while it is, of course, possible to run PortaSwitch in a virtualized environment such as VMWare, it should be understood that this will not provide any major reduction in hardware costs or significant improvements in server management. A better option is to utilize physical servers in a PortaSwitch private cloud computing environment.
For a production system with a fair amount of real-time traffic processing, running PortaSwitch in a public cloud has all the shortcomings of using a virtual environment. At the same time, it is ideal for projects where a “temporary” system is required and one does not expect a lot of calls/messages/sessions to be processed, e.g. a staging system for application development or testing. In this case, using a public cloud is a good option. Currently, we support Rackspace’s public cloud, and are working closely with other providers (AWS, Oracle Cloud, etc.) to make this possible in other public clouds.
Yes. PortaSwitch supports the SMPP protocol for interconnecting with other carriers’ SMSC or wholesale SMS aggregators for sending and receiving messages.