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(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

Older versions of serctl contain a bug that make the inserted aliases to expire immediately, that has been fixed a long time ago, see: http://lists.iptel.org/pipermail/serusers/2004-January/004949.html Jan. On 14-07 19:40, Dave Bath wrote: