[Serusers] Aliasing problem - sr-users

14 Jul 2004

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,

D

________________________________

From: Ezequiel Colombo [mailto:ecolombo@arcotel.net] 
Sent: 14 July 2004 19:54
To: Dave Bath; serusers(a)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 <mailto:dave@fuuz.com>  

	To: serusers(a)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(a)lists.iptel.org
	http://lists.iptel.org/mailman/listinfo/serusers