IMS Usrloc PCSCF Module

Jason Penton

Smile Communications

Edited by

Richard Good

Smile Communications

Table of Contents

1. Admin Guide
1. Overview
2. Dependencies
2.1. Kamailio Modules
2.2. External Libraries or Applications
3. Parameters
3.1. hash_size (int)
3.2. timer_interval (int)
3.3. db_url (int)
3.4. db_mode (int)
3.5. hashing_type (int)
3.6. lookup_check_received (int)
4. RPC Commands
4.1. ulpcscf.status
5. Statistics
5.1. registered contacts
5.2. impus
5.3. expired contacts
2. Frequently Asked Questions

List of Examples

1.1. Set hash_size parameter
1.2. Set timer_interval parameter
1.3. Set db_url parameter
1.4. Set db_mode parameter
1.5. Set hashing_type parameter
1.6. Set lookup_check_received parameter

Chapter 1. Admin Guide

1. Overview

This module serves as a storage engine for PCSCF contacts, much like the standard Kamailio module, usrloc, is a storage engine for standard SIP contacts. The concept of a contact in IMS, PCSCF specifically, is very different to that of std. SIP and as a result we have built this new module. Alot of the design has been borrowed from the std. usrloc module. For example. An IMS contact, in PCSCF, needs things like:

  • Diameter Rx session for signalling bearer status. i.e. this is effectively QoS from the network to make sure the signalling link can be 'trusted'

  • IPSEC Security Assocation for secure signalling between UE and PCSCF (first point of contact)

  • IMPU, each contact can have a number of associated public identities (IMPU).

2. Dependencies

2.1. Kamailio Modules

The following modules must be loaded before this module:

  • None.

2.2. External Libraries or Applications

The following libraries or applications must be installed before running Kamailio with this module loaded:

  • None.

3. Parameters

3.1. hash_size (int)

The number of entries of the hash table used by to store the contact records is 2^hash_size. For hash_size=4, the number of entries of the hash table is 16.

Default value is 9.

Example 1.1. Set hash_size parameter

...
modparam("ims_usrloc_pcscf", "hash_size", 10)
...

3.2. timer_interval (int)

Number of seconds between two timer runs. The module uses timer to delete expired contacts.

Default value is 60.

Example 1.2. Set timer_interval parameter

...
modparam("ims_usrloc_pcscf", "timer_interval", 30)
...

3.3. db_url (int)

Database URL

Default value is "mysql://kamailio:kamailiorw@localhost/kamailio".

Example 1.3. Set db_url parameter

...
modparam("ims_usrloc_pcscf", "db_url",
       "dbdriver://username:password@dbhost/dbname")
...

3.4. db_mode (int)

This is the database mode to be used for the PCSCF usrloc data persistent storage. Currently this module supports the Write-Through scheme only.

  • 0 - This disables DB mode. Only memory will be used for usrloc and data will not survive a restart.

  • 1 - Write-Through Scheme. All changes to usrloc are immediately refelcted in the database. This is slow but very reliable. This mode will ensure that no registration data is lost as a result of a restart or crash.

Default value is 0.

Example 1.4. Set db_mode parameter

...
modparam("ims_usrloc_pcscf", "db_mode", 1)
...

3.5. hashing_type (int)

This is used to specify how contacts are stored in the internal memory hashing structures. This is an important parameter, not only for efficiency, but also for functionality. IMS can get rather confusing when it comes to contacts, SIP URIs and Implicitly registered SIP URIs (IMPUs). Originally the hash for storage of contacts was performed over the full contact URI viz (27821234567@10.0.0.10:12345;user=phone). This scheme is useful (from a performance perspective) in circumstances where you have many SIP URIs being registered from the same host/port. However, this causes problems in IMS environments where an implicit registration set of IMPU's is implicitly registered on behalf of a UA when it registers. This is because the implicit contact being used in subsequent requests could use a different SIP URI, for example john.doe@10.0.0.10:12345. In this case the P-CSCF would not be able to retrieve the initial contact as the hash over the different contact would in most cases be different. It was therefore proposed to hash the contact by IP:PORT only, effectively identifying a "device" - assuming a 1-1 relationship between an IP:PORT pair. In our example, we would get to the same hash slot using the second SIP URI as we got using the initial registered SIP URI. Within this slot we can now search for the appropriate contact (remember there are still collision possibilities) and then traverse through the linked list if iumplcit IMPUs to find the contact currently being used. Of course if it is not found, then you can deny the request.

  • 0 - This uses the original hash over AOR method. By default we are backwards compatible...

  • 1 - Use the newer hash over the Host from Contact-Header.

  • 2 - Use the newer hash over the source-IP from where the request was received (useful for NAT-Scenarios)

Default value is 0.

Example 1.5. Set hashing_type parameter

...
modparam("ims_usrloc_pcscf", "hashing_type", 1)
...

3.6. lookup_check_received (int)

If set to 1 (default), the Host in the contact will be checked against the Host, from which the request was received.

  • 0 - Upon lookup, do not check the host against received.

  • 1 - Compare the host in the contact against the received info.

Default value is 1.

Example 1.6. Set lookup_check_received parameter

...
modparam("ims_usrloc_pcscf", "lookup_check_received", 0)
...

4. RPC Commands

exported RPC commands.

4.1. ulpcscf.status

Status of pcscf_usrloc, AORs, max slots, etc.

5. Statistics

Exported statistics are listed in the next sections.

5.1. registered contacts

Number of AOR contacts in registered state - cannot be reset.

5.2. impus

Number of IMPUs - cannot be reset.

5.3. expired contacts

Number of expired contacts - can be reset.

Chapter 2. Frequently Asked Questions

2.1. Where can I find more about Kamailio?
2.2. Where can I post a question about this module?
2.3. How can I report a bug?

2.1.

Where can I find more about Kamailio?

Take a look at http://www.kamailio.org/.

2.2.

Where can I post a question about this module?

First at all check if your question was already answered on one of our mailing lists:

E-mails regarding any stable Kamailio release should be sent to and e-mails regarding development versions should be sent to .

If you want to keep the mail private, send it to .

2.3.

How can I report a bug?

Please follow the guidelines provided at: http://sip-router.org/tracker.