Hey Ezequiel,

Many thanks for the quick response! Yeah, sorry, I should have mentioned I already have persistent storage for the user tables – they’re all stored using mode2, I was just checking with all the references to “aliases stored in cache” that they were actually written to the db as well.

Could you explain what the FOREVER_REL value is? Why would the value be too high? Too large a number of the type of storage in the mysql table?

Also, does anyone know why the serctl script says the alias was added, but it doesn’t seem to have been..?

Many thanks again everyone,

From: Ezequiel Colombo [mailto:ecolombo@arcotel.net]
Sent: 14 July 2004 19:54
To: Dave Bath; serusers@lists.iptel.org
Subject: Re: [Serusers] Aliasing problem

Dave, you must turn no the persistent storage of the usrloc table. After this the contacts added in the memory table can be dumped to mysql.

You can also check in the script serctl if the value of the variable FOREVER_REL is appropiate or is too high for your mysql aliases table and cause the INSERT to fail. In my network i have reduced this value to FOREVER_REL=31536000 (one year).

... FROM README FILE OF USRLOC MODULE ...

1.3.10. db_mode (integer)

   The usrloc module can utilize database for persistent contact
   storage. If you use database, your contacts will survive
   machine restarts or sw crashes. The disadvantage is that
   accessing database can be very time consuming. Therefore,
   usrloc module implements three database accessing modes:

     * 0 - This disables database completely. Only memory will be
       used. Contacts will not survive restart. Use this value if
       you need a really fast usrloc and contact persistence is
       not necessarry or is provided by other means.
     * 1 - Write-Through scheme. All changes to usrloc are
       immediately reflected in database too. This is very slow,
       but very reliable. Use this scheme if speed is not your
       priority but need to make sure that no registered contacts
       will be lost during crash or reboot.
     * 2 - Write-Back scheme. This is a combination of previous
       two schemes. All changes are made to memory and database
       synchronization is done in the timer. The timer deletes
       all expired contacts and flushes all modified or new
       contacts to database. Use this scheme if you encounter
       high-load peaks and want them to process as fast as
       possible. The mode will not help at all if the load is
       high all the time. Also, latency of this mode is much
       lower than latency of mode 1, but slightly higher than
       latency of mode 0.

Warning

   In case of crash or restart contacts that are in memory only
   and haven't been flushed yet will get lost. If you want
   minimize the risk, use shorter timer interval.

Default value is 0.

Example 1-10. Set db_mode parameter
...
modparam("usrloc", "db_mode", 2)
...

----- Original Message -----

From: Dave Bath

To: serusers@lists.iptel.org

Sent: Wednesday, July 14, 2004 3:40 PM

Subject: [Serusers] Aliasing problem

Hey guys,

I have been playing with SER for a few days now, and apart from having to rebuild all the RPMs to get it working on FC1 with mysql4 (mysql4 is apparently not officially supported in FC1 ?!) everything was smooth and dandy. Really enjoying using such a powerful and flexible product.

However, I have one problem, and I’ve done my best to trawl all the groups and lists, and debug it myself and I cannot work out what is going on – perhaps I just don’t understand how it works properly. I am trying to set numerical aliases so that incoming routing can be handled more easily by a PSTN gateway. I am trying the command:

Serctl alias add 1000 sip:admin@<sipserver>

I get a reply that the alias has been added (once a previous message on this list pointed out that I needed to add lookup(“aliases”); to ser.cfg)!

The problem is the mysql table is still empty – although serctl says that the alias has been added, it doesn’t seem to have been. When I try and call “1000” I get a 404 not found, but calling “admin” works fine.

Does anyone have any ideas?!

Also, on a slight side note, I was assuming that the aliases are reboot-safe… they’re stored in the database and will get reloaded if ser is rebooted. Is this the case by default or does an option need to be enabled?

Sorry for the long post. Many thanks to everyone who has worked on this, and it would be fantastic to get this last bit sorted out.

Cheers,

Dave

Inmarsat Ltd

Global Satellite Communications

Regional BGAN Engineer

_______________________________________________
Serusers mailing list
serusers@lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers