5.11. Registration Caching and Handling

ABC-SBC’s registration cache mediates the registration flow between SIP User Agents and SIP registrars. It keeps track of SIP User Agent contacts and shields SIP registrar from overload. It also facilitates NAT traversal. In case a user agent is located behind a NAT it will use a private IP address as its contact address in the Contact header field in REGISTER messages. This unroutable address would be useless for anyone trying to contact the user agent from the public Internet.

_images/register-fixing.png

Figure 1: SBC and NAT traversal: Registration handling

In order for a SIP User Agent to be reachable the ABC-SBC will manipulate its registration information. The SBC remembers the User Agent’s transport address and replaces the information in the Contact header with its own IP address before forwarding downstream, see Fig. SBC and NAT traversal: Registration handling. This is the information that is then registered at the registrar. Calls destined to the user will then be directed to the SBC. The SBC then forwards the calls using previously stored information about the User Agent’ transport address and initial unmodified contacts.

The registration cache implements the following functions:

  • Contact fixing: SIP contacts of User Agents behind NATs include private IP addresses which are not routable from the public Internet. Therefore the ABC-SBC rewrites the IP address in the Contacts with its own and holds the original Contact in its cache. If the ABC-SBC connects to multiple networks using multiple IP addresses, the IP address is used which is associated with the interface over which the REGISTER request is forwarded. When later incoming requests towards the User Agent reach the ABC-SBC, the ABC-SBC restores the original address.
  • Keeping NAT-bindings alive. If periodic request-response traffic was not crossing the NAT behind which the User Agent is located, the NAT address binding would expire and the client would become unreachable. Thefore the ABC-SBC steers User-Agents to re-register often.
  • Registration off-loading. Various circumstances can cause substantial registration load on the server: most often it is self-inflicted by the keep-alive functionality, but it may be also on the occasion of a registration storm caused by a router outage, broken client or Denial of Service attack. The ABC-SBC fends off such overload by using high-performance in-memory registration cache that serves upstream registrations at high-rate, handles them locally, and propagates them down-stream at a substantialy reduced rate. That’s the case if the registrations were to create new bindings, deleting existing ones or if they were to expire downstream. The propagated registration changes become effective on the ABC-SBC only if confirmed by the downstream server. If a registration expires without being refreshed the ABC-SBC issues a reg-expired event.

The folowing Subsection, Registration Handling Configuration Options, documents the specific actions that implement the cache functionality. Note that the procedures described here refer to individual URI registration as envisioned in the RFC 3261. Provisioning of bulk registration for PBXs as specified in the RFC 6140 is described in the Section Table Example: Bulk Registration.

5.11.1. Registration Handling Configuration Options

The ABC SBC can handle SIP registrations in two ways, either caching them locally and forwarding them to a downstream registrar, or acting itself as a SIP registrar.

If the ABC-SBC fronts a registrar, the action Enable REGISTER caching is applied on incoming REGISTERs from a User Agent to cache and translate its Contacts. On the reverse path towards the User Agent, the action Retarget R-URI from cache(alias) restores the original Contacts.

  • Enable REGISTER caching - cache contacts from REGISTER messages before forwarding, create an alias and replace the Contact with alias@SBC_IP:SBC_PORT;contact_parameters. This method should only be applied to REGISTER messages to be forwarded to a registrar. This action has effects only on REGISTER requests, see Fig. Enable Register caching.

    _images/100002010000021300000213E664823B.png

    Figure 2: Enable Register caching

  • Retarget R-URI from cache (alias) - Look up cached contact under alias and rewrite the request URI with it. Apply this action to messages sent to clients whose registration were cached previously using the “Enable REGISTER caching” action. This scenario is depicted in Fig. Retarget R-URI from cache. When an INVITE arrives to a user that has previously registered its contact information (UserB) the ABC SBC will forward the INVITE to the PBX which acts in this case as the SIP proxy and Registrar. The PBX will look for the registration information of UserB which in this case are aliasB@_SBC-IP_ and use this information for routing the request. When the INVITE with the Request URI set to aliasB@_SBC-IP_ arrives at the SBC, the ABC SBC will check its registration cache and retrieve the actual contact information of the user, namely UserB@2.2.2.2 and use this information as the Request URI and forward the message to this address.

  • Parameters: Enable NAT handling:source IP and port of the REGISTER request; Enable sticky transport: use the same interface and transport over which the REGISTER was received.

Note: if no matching entry is found in the cache, the ABC-SBC returns a 404 SIP response.

_images/1000020100000232000002378C5B7C9B.png

Figure 3: Retarget R-URI from cache

If the ABC-SBC is used as registrar, the two following actions are used instead: Save REGISTER contract for REGISTERs and Restore contact for incoming requests towards the User Agent.

  • Save REGISTER contact in registrar  - act as local registrar by saving the contact and replying with a 200 response.
  • Restore contact from registrar  - use contact stored within internal registrar

5.11.2. Registrar off-load

Registration throttling can be combined with both registrar and registrar cache modes. The action REGISTER thottling enforces high re-registration rate towards User Agent Client and reduced rate towards registrar. The high upstream rate serves the purpose of preserving connectivity by keeping address binding along the SIP path alive. The reduced rate makes sure that the connectivity traffic doesn’t overload the downstream registrar. The action must preceed any other REGISTER-processing action, otherwise it’s load-reducing function will take no effect:

  • REGISTER throttling  - force SIP user-agents to shorten re-registration period while propagating the REGISTERs upstream to registrar at longer intervals. This is useful to keep NAT bindings open without imposing the refreshing load on registrar.
    • Parameters: Minimum registrar expiration: expiration time used in direction to registrar. Maximum UA expiration: maximum expiration time in direction to User Agent Client.

Note that these two parameters have vast impact on the volume of SIP traffic: they steer the registration rates towards upstream SIP client and downstream SIP registrar.

The Maximum UA expiration “knob” steers the SIP traffic rate between upstream SIP client and the ABC-SBC. The lower value is enforced, the higher the registration rate will be. The SIP standard suggests one registration per hour which is not good enough to keep NAT bindings alive. Forcing the re-registration interval down to 180 seconds will cover a satisfactory share of population behind NATs. Further reducing the re-registration window will cause substantical increase in bandwidth consumption. See Section SBC Dimensioning and Performance Tuning for additional details. Note that non-compliant SIP clients may fail to honor the recommendation provided by the ABC. The ABC will still keep their registration bindings alive but IP and transport layer connectivity may not stay alive.

The Minimum registrar expiration “knob” steers how much SIP traffic passes through to the downstream registrar. Basically this parameter suggests to the downstream registrar how long a registration shall remain valid. The configured value is recommendatory only: the downstream registrar may accept it or change it in its final responses to REGISTER requests. The value in the response from the downstream registrar is used as the actual time-to-live for the cached registration binding. Registration renewals are not passed from the User Agents to the registrar until this time-to-live is about to expire. The longer this window is, the less traffic will be forwarded to the registrar. On the other hand, a client’s failure to renew its contact will remain undetected by the downstream registrar and result in “hanging contacts” if the client is actually unavailable.

In the normal case when reduction of the upstream rate is desirable, the ratio of registrar-to-UA must be greater than 2.0 – otherwise the server registration window will not be long enough to capture more than one client registration. Typically the ratio is higher, 10.0 at least. The throttling action MUST be placed before any other register processing actions to take effect.

It is also important to understand the time-to-live of the cached registered contacts in detail. Briefly, the bindings stay active for the time requested by SIP registrar in response to forwarded REGISTER requests. They will be deleted if any of the following conditions occurs:

  • the UAC fails to re-register its contact before the time-to-live of the contact set by the downstream registrar expires. That also means that a failure of a User Agent Client to renew its contact within the “client window” are tolerated by the ABC as long as the time-to-live period is not over. A “reg-expired” event is generated. (See Section Events) Example of a registratio cache view when only the “UAC-side” timeout expires is shown in Figure Client-side Expired Registration Contact.
  • the UAC explicitely deregisters using procedures described in RFC3261. In this case a “reg-del” event is generated.
_images/uac_side_expired.png

Figure 4: Client-side Expired Registration Contact

5.11.3. Registration Caching and Handling by Example

To enable registrar caching, you must let all REGISTER requests be processed by using the actions REGISTER throttling  and  Enable REGISTER caching. The throttling action takes additional parameters: Minimum registrar expiration and Maximum UA expiration. The former specifies the “throttle” which reduces the registration traffic propagated towards a registrar. The value is normally in order of tens of minutes, we chose a whole hour in our configuration example. The other parameter, Maximum UA expiration, determines the traffic pace towards the SIP User Agents. The value is normally in order of minutes to keep REGISTER messages flowing and holding IP connectivity through firewalls and NATs upright. We chose an extremelly aggresive value in our example, half a minute.

Figure Registrar handling shows a screenshot with such a 3600/30 throttling ratio configuration. The rules are part of a “public” realm serving REGISTERs coming from the public Internet.

_images/10000201000003D800000341F3E29B91.png

Figure 5: Registrar handling

You also need to configure how incoming messages for the registered users will be processed. Particularly the URIs coming back in incoming requests must be recovered to the original form in the initial REGISTERs received by the ABC-SBC. To do so, enable the action Retarget R-URI from cache, with the enable NAT handling  option turned on for all traffic routed to the public realm. The configuration is shown in Fig. Restoring cached contacts.

_images/10000201000003CC0000026F40E74B4A.png

Figure 6: Restoring cached contacts

With this configuration in place, the actual SIP call flows may appear like in the following diagram Call Flow Registration Throttling.

_images/registration_callflow.png

Figure 7: Call Flow Registration Throttling

The example sequence shows the primary function of the registration throttle: increasing the traffic towards SIP User Agent (left-hand side) and reducing it towards the registrar (right-hand side). It also demonstrates how SIP equipment may differ from the expected traffic pattern and how the ABC-SBC will deal with it.

The sequence begins with an initial REGISTER. The SIP telephone proposes a “time-to-live” in the message, 600 seconds in this example. (The SIP message element is really called “expires” but we found the “TTL” name more explanatory.) The ABC-SBC choses to send the traffic to downstream registrar less often, and overrides this value to a longer period of 3600 seconds. The registrar downstream finds it too high though and agrees to keep contacts for only 1800 seconds in its 200 SIP response. Now the ABC-SBC knows how often it must refresh the registrations downstream: every half an hour.

In the direction towards the client, the ABC-SBC compells the client to re-register more often by advertising it would only keep the registered contacts for no longer than 30 seconds.

As a result, the client keeps registering every half a minute, and the ABC-SBC passes on the registration to the downstream registrar every half an hour. If the client is late with a renewal request, the address binding remains in ABC-SBC registrar cache. If the client is however re-registering too late with respect to the registrar TTL, the cached registration will expire, same way like of there was no cache. The late re-registration will then create a newly registered contact.