Hey thanks, that did fix it. Now if I do a serctl show alias 1000 I see Admin listed, and it's listed under the "Your Aliases" section of serweb. I still don't understand why there wasn't an error thrown back by serctl. Does anyone know which field from the database is needed, as conceivably someone might have a phone number for longer than a year, and I don't want to have to renew all the aliases... Best regards, Dave ________________________________ From: Ezequiel Colombo [mailto:ecolombo@arcotel.net] Sent: 14 July 2004 20:17 To: Dave Bath; serusers(a)lists.iptel.org Subject: Re: [Serusers] Aliasing problem FOREVER_REL contain the value used by serctl to set the Expires time of the contact alias added. If this value is too large the value result a hugh value for the column type of the aliases table. ----- Original Message ----- From: Dave Bath <mailto:dave@fuuz.com> To: serusers(a)lists.iptel.org Sent: Wednesday, July 14, 2004 4:01 PM Subject: [Serusers] Aliasing problem 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 ________________________________ _______________________________________________ Serusers mailing list serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers