In general, every incoming call to PortaSIP must be authorized, in order to ensure that it comes from a legitimate customer of yours.
Digest authorization
When the first INVITE request arrives from a SIP phone, the SIP server replies with 401 – Unauthorized and provides the SIP UA with a challenge (a long string of randomly generated characters). The SIP UA must compute a response using this challenge, a username, a password, and some other attributes with the MD5 algorithm. This response is then sent back to the SIP server in another INVITE request. The main advantage of this method is that the actual password is never transferred over the Internet (and there is no chance of recovering the password by monitoring challenge/response pairs). Such digest authentication provides a secure and flexible way to identify whether a remote SIP device is indeed a legitimate customer.
Authorization based on IP address
Unfortunately, some SIP UAs (e.g., the Cisco AS5300/5350 gateway) do not support digest authentication for outgoing calls. This means that when the SIP UA receives a “401 – Unauthorized” reply from the SIP server, it simply drops the call, as it is unable to proceed with call setup. In this case, PortaSIP can be configured so that it does not challenge the SIP UA upon receiving an INVITE. Rather, it simply sends an authorization request to PortaBilling, using the SIP UA’s remote IP as the identification. The User-Name attribute in the RADIUS authorization request will contain the remote IP address. If an account with such an ID exists in the billing database, and this account is allowed to call the dialed destination, then the call will be allowed to go through. Also, since this scheme leaves no possibility for the remote side to supply a password, PortaSIP will instruct PortaBilling to skip the password check.
Authorization based on tech-prefix
This method of customer identification is used in circumstances similar to the IP-based authorization described above. It provides extra flexibility, since after the initial configuration is done it is easy to use the same tech-prefix on a different gateway. However, this makes it extremely insecure, since any hacker can do just the same. In this scenario, PortaSIP extracts a certain portion of the destination number from the incoming INVITE request (e.g., if the complete dialed number was 1234#12065551234, the 1234# part will be used for authentication) and then passes it to PortaBilling in the User-Name attribute.
Multi-DID control
If multiple DIDs (sets of phone numbers) have been allocated to a single user via the Account Alias feature, the PortaSwitch administrator can define whether an alias is allowed independent SIP registration. If the ability for authentication/registration is turned off, the alias cannot be provisioned on the IP phone or used for any other types of service activities. Such an alias is used solely for the purpose of routing incoming calls to that DID to the main account. This extends the available service options to cloud PBX and SIP trunking services.
If alias registration is allowed, the alias can basically be used as another account. (Of course, it still shares a balance with the main account.) This is useful for multiline telephones like SPA-941, where each line can have its own DID and be registered to PortaSIP independently.
Caching authentication during IP Phone registration
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, 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 (e.g., 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).
