News

contact@portaone.com

Toll-free calls (phone & Skype)
+1 866 747 8647
Calls & faxes from abroad:
+1 604 628 2508

PortaOne, Inc.
Suite 408, 2963 Glen Drive
Coquitlam, BC, V3B 2P7
Canada

19 August 2010

Caching Authentication during IP Phone Registration Introduced with MR22 Results in 100% PortaSwitch Performance Increase

A new feature for caching authentication results allows service providers to double PortaSwitch's capacity in terms of registration attempts processed per second, and to protect the system from a “registration storm” (whether unintended or part of a denial-of-service attack).

Under normal circumstances, when an IP phone goes online it provides PortaSwitch with information about its current location on the Internet (in SIP terms, this is called registration). It then periodically repeats this so as to keep the contact information updated (this is called re-registration, although technically the information exchanged between the IP phone and PortaSwitch is not any different from that exchanged during initial registration). Subsequent registrations occur at the interval programmed into the IP phone, which is usually somewhere between 10 minutes and one hour.

Since the IP phone is the initiator of the registration, there is really nothing PortaSwitch can do to control the process and make re-registrations more or less frequent. (It can, however, advise the IP phone of a time to re-register again, but nothing prevents the IP phone from ignoring this and sending another registration request sooner).

When dealing with a network which contains a large number of IP phones whose re-registration interval is not automatically provisioned from PortaSwitch along with other configuration settings, the average rate of registration is a significant concern.


For example, let’s assume, 30,000 properly configured IP phones (which re-register every 30 minutes) would generate about 17 requests per second for processing by both PortaSIP (parsing SIP messages and generating responses) and PortaBilling (performing account authentication).

Yet just 500 IP phones registering too often (e.g. once every 30 seconds) due to a mis-configuration or a firmware bug would result in the same load on the system – and what happens when the number of such “impatient” phones starts growing is easy to imagine.

In order to prevent a situation where a few “rogue” IP phones create a significant load on PortaSwitch, the SIP proxy in PortaSIP performs caching of successful registration information.

During the initial registration, the credentials provided by an IP phone are validated in PortaBilling as usual, and this information is stored in the database following successful registration. Later, when a new registration request arrives from an IP phone, PortaSIP first checks its location database to see whether there is already a registration for that phone number, with the matching contact data (IP address and port on which it is accessible).

If a previous registration exists and occurred recently, then PortaSIP simply replies back to the IP phone confirming successful registration. This saves resources on the PortaSIP side (since this process is much shorter than the normal dialog for handling a SIP REGISTER request) and creates zero load on the billing engine (since no authentication request is sent).

This process is repeated upon subsequent re-registrations, until eventually the registration information becomes “too old” or the IP address and/or port provided in the request do not match the ones stored in the database (i.e. the IP phone is attempting to register from a new location). At that time the normal registration process will take place: the IP phone receives a challenge request, it sends back a reply calculated using its username and password, and an authentication request is then sent to the billing engine for verification.

In spite of how this may sound, simply confirming registration without verification by billing carries absolutely no security risks in this scenario. If an “evil hacker” sends a REGISTER request spoofing the real customer’s IP address and port, he will only accomplish a reconfirmation of the original customer’s location. If he uses a different IP address or port in an attempt to intercept the customer’s incoming call, the cached information will not be used, and thus he would have to provide valid password information.

The “caching interval” is set to one half of the “recommended registration” interval, so this does not really create more “stale” sessions (where a phone is considered to be online when it has actually already disconnected from the Internet) than the normal scenario. The performance increase is tremendous: on a system with a 5-minute caching time, the amount of registrations per second that a single PortaSIP instance can handle increases 100% (from 400 per second to 800).

The detailed description of this and other features incorporated in PortaSwitch MR22 can be reviewed in the PortaSwitch New Features Guide.

For more information about PortaSwitch and its features please contact your support team or application engineers.

Superb reliability and scalability with
24/7 professional technical support

icon1.png

Open architecture

PortaOne provides both APIs and source code for PortaSwitch to allow an easy integration
 
icon2.png

Scalability for growth

Our platforms can easily scale up by adding more servers to match your project success
 
icon3.png

Reliability and redundancy

Clustering and geo‑redundancy for high availability configuration and zero downtime updates
 
icon4.png

Agile development

More than 20 software builds per year - new features are available every 7 weeks
 
icon5.png

24/7 technical support

Over 60% of our 300 engineers are in the technical support services, praised as the best in industry