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.